规模化敏捷safe认证_【洞见】规模化敏捷借鉴性思考

导语

敏捷运动是软件开发领域发展史上重要的里程碑。敏捷方法(Agile Method，简称AM)驱动团队高效运转、产品质量不断提升、交付周期显著缩短，使得敏捷理念逐渐深入人心。目前，在小团队中实施AM的效果已经得到验证，但对于大型组织(譬如农行研发中心)，如何规模化运用AM还是一个需要深入探索的领域。

01

敏捷运用推广的现状及面临的挑战

敏捷(Agile)作为一种软件开发理念，与之伴随出现了很多实践框架和方法，如Scrum、Kanban和XP。这些方法已经成为敏捷化软件开发的事实标准，十年前类似持续集成这样被大家认为是“极限”的方法，现在也已经成了开发团队的一个标配。 但是，推广应用AM面临如下问题：在小规模团队中卓有成效的许多敏捷化手段，一旦移植到大规模团队，似乎失去了原有的魔力。在敏捷扩展方面，开发并不是最大的难题，要想延续敏捷化的既有效果，需要在很多方面做出改变，比如产品规划、产品管理、组织协同和后期运维等，而实现这些改变需要花费很长的时间。 在这些涉及到传统管理的领域，现有的敏捷方法就显得力不从心，重点在于这种规划、管理、协作也要有快速反应的能力，才能适应这个改变速度越来越快的世界。

02

规模化敏捷简介

在大体量组织敏捷化领域，业界进行了多年的探索。巨大而迫切的市场需求，催生了Scrum@Scale、SAFe、Less、DAD等多种适合大型组织的“规模化敏捷”框架。其核心思想就是在经典敏捷开发的基础上增加管理协调的机制。下面就是几种典型的大规模敏捷框架。

Scrum@Scale

Scrum@Scale是一个对Scrum进行扩展的框架，由Scrum框架的发明者Jeff Sutherland设计。Scrum@Scale通过使用Scrum来扩展Scrum，彻底简化了规模扩展的设计。它仅仅包含一些Scrum团队，这些团队通过Scrum of Scrums和MetaScrums进行整合。Scrum of Scrums允许Scrum扩展到上百个团队，MetaScrum使得创新产品能快速部署，将Scrum扩展到整个组织。

SAFe(Scaled Agile Framework)

SAFe的设计和主要方法论由Dean Leffingwell主导，是目前发展较快的规模化敏捷框架之一，特点是将敏捷实践在企业中分层而治，从团队级(Team level)到项目群级(Program level)乃至投资组合级(Portfolio level)；引入了新的角色、组件和事件，糅合了精益-敏捷知识体系。

LeSS(Large-Scale Scrum)

LeSS由Craig Larman和Bas Vodde共同设计，框架采用Scrum的基本指导原则，另外采纳了一些其他方法来管理大规模的敏捷项目，是一个轻量级的规模化敏捷框架。LeSS框架想要解决的问题是，如何将Scrum的原则、元素尽可能简单够用地运用到多个团队合作开发产品的场景里去。

DAD(Disciplined Agile Delivery)

规范敏捷交付(DAD)基于敏捷和精益原则，由Scott W. Ambler首先提出DAD的概念并领导相应过程框架的开发。DAD包括了人员管理、基于价值的解决方案、增量交付以及持续学习等方法。DAD与其它敏捷框架的区别在于它是一个流程化的解决方案，而其它框架的主要特点是提供一系列的指导原则。DAD帮助团队形成一个已经敏捷和流程化的解决方案。

03

SAFe框架介绍

规模化敏捷框架出现的时间不算很长，目前都处在快速发展和演变中。以SAFe为例，SAFe于2011年正式发布1.0版本，历经多次升级，融入了敏捷、精益、系统思考等思想。目前最新版本是2020年发布的5.0版本。 下图是官方网站上所给出的SAFe全景图，展现了SAFe的完整体系、理念和实践原则，如组织级敏捷性、精益组合管理、敏捷产品交付、团队和技术敏捷性、持续学习的文化、精益敏捷领导力七大核心竞争力，以及愿景、路线图、里程碑、共享服务、CoP(由团队成员和其他专家组成的非正式团队)、系统团队、精益用户体验(UX)、度量等重要概念。 相对于敏捷理念的深入人心，规模化敏捷在国内还相对陌生，但是近年来还是有不少企业在积极探索并尝试规模化敏捷的落地实践。根据近几年在TiD大会敏捷论坛的交流情况，一些大型企业(如华为、京东等)正在尝试应用规模化敏捷。华为基于SAFe框架进行适配，聚焦PI(Program Increment)需求，实施了PI计划，并提出从规模敏捷到商业敏捷的演进构想。京东APP通过敏捷发布火车方式实现了固定周期发布。另外，还有一些中小型互联网企业(比如美图)也在借鉴规模化敏捷的思想进行实践。

04

规模化敏捷借鉴的思路

在规模化敏捷方面，目前并没有哪一种框架能够整体照搬，但是可以从特定切入点入手进行适配，在框架中寻找既能解决组织中目前面临的特定问题，同时对组织现有的架构流程不造成冲击的局部解决方案来进行试点。下面以SAFe框架为例，选取框架中三个可借鉴点进行分析，结合银行研发中心的真实场景，探讨可借鉴之处。

敏捷发布火车(ART)

敏捷发布火车的目标是交付持续的价值流。敏捷发布火车通过围绕着一个共同的项目群愿景、使命和待办事项列表来对齐人和工作，将团队对齐到一个共同的商业和技术使命上。 敏捷发布火车(ART)是典型的虚拟组织，它包含定义和交付价值所需要的所有人员，具备定义、实施、测试和部署新系统功能所需要的软件、硬件、固件和其他所有能力。这种方式打破了可能存在的传统职能筒仓。 敏捷发布火车在一个PI时间盒内采用一系列固定长度的迭代来逐步开发和交付。敏捷发布火车基于以下框架运作： ●固定的时间表：火车按照已知的、可靠的时间表从站台出发，时间表由预先选定的项目群增量的节奏决定，如果一个特性错过了前一列火车，它可以搭乘下一列火车。 ●固定的PI时间盒：火车上所有的团队都同步到相同的PI时间区间(通常是8-12周)，并使用相同的迭代开始/结束日期和迭代持续时间。 ●已知的速度：每列火车都能对它在每个PI中能交付多少“货物”(即新的特性)进行可靠的估算。 ●专职的人员：不论人员在职能组织中的汇报结构如何，敏捷发布火车上需要大多数人员都是专注于该火车的全职人员。 ●发布火车工程师(RTE)：是一列敏捷火车(Train)总的 Scrum 主管。其中每列敏捷火车有一个 RTE。RTE 主持发布计划会议，负责一列敏捷火车的总体执行，包括在执行过程中移除阻止火车前进的障碍，以及管理各个团队之间的集成。 敏捷发布火车解决了传统敏捷开发可能遇到的一个常见问题，即为同一个解决方案工作的几个团队是独立且异步运行的，使得整个系统的例行集成变得非常困难。“团队正在迭代冲刺，但系统没有”，这不仅会拖延交付周期，而且增加了延后发现问题所带来的风险，降低交付质量。敏捷发布火车确保了系统作为一个整体进行迭代冲刺。 以农行研发中心为例，一个典型的研发类项目，除了主办方之外，通常还有若干协办方，而协办方往往需要对自身系统进行改造，增加功能模块或者调整接口。目前的开发模式下，主办方、协办方、后台系统部门都是独立且异步运作的。即使是在研发中心推广了敏捷开发模式，也是局限在项目组范围内；由于目标无法在系统级别对齐，导致出现“团队正在迭代冲刺，但系统没有”的现象，使得整个系统的集成变得并不顺畅。敏捷发布火车正是瞄准上述痛点的解决方案。如果采用敏捷发布火车的方式，将项目所有团队都纳入火车，对齐各个团队的进度，明确发车时刻表，构建并维护交付流水线，可以让各个团队都找到一致的开发和发布节奏。通过敏捷发布火车定期交付整体价值，能够有效避免因各团队进度不一致、系统发布项被某些团队的依赖项拉下导致整体无法交付的问题。

PI及PI计划(PI Plan)

在SAFe中把一个ART交付增加价值的时间盒叫做项目群增量，用于构建和验证完整的系统增量，并向客户演示价值从而获得快速反馈。每个PI都利用节奏和同步去达成目标，长度通常是8-12周，是一个固定的节奏。常规的PI模式是4个开发迭代，然后进行一个创新与计划迭代。正如迭代是针对敏捷团队而言的，PI是针对ART而言的。 每个PI中始于PI计划，PI计划可以认为是最关键的活动。PI计划作为ART的心跳，提供了一个合适的窗口来对齐目标，同步节奏，协调各个团队之间的依赖，并分析潜在的风险。PI计划可以被粗浅地看成是大号Sprint计划，使用Scrum相关技术和手段、待办列表等，使ART上的所有团队朝着共同使命和愿景努力。 PI 计划其实是幕后管理团队的Sprint Planning，因为计划的粒度变大了，所以计划的周期由两个星期扩大到三个月是合理的。在PI计划的过程中，会对未来三个月的工作强度产生共识，对哪个特性优先级更高、哪个功能要提前准备有了清晰的认识。即使哪个功能或者依赖的内容有所变化，团队也可以根据计划知道总体的进展情况，并通过使用其它可供选择的保留功能，在Sprint Planning时做出相应的调整，不至于陷入开发进度完全停滞的状态。从这个角度看，计划是为了更好地应对变化：因为对某些场景思考过，不是完全陌生的状态，遇到变化才不会不知所措。 PI计划带来的最直观好处就是实施组织级别的敏捷计划，在多个团队间达成一致目标，将计划的层次从各个敏捷团队提升到组织级别，使各团队在组织整体计划下明确各自的目标和路线图，梳理好协同关系，避免敏捷团队各自为战，避免进度不一致和接口错位。 经过多年的建设，众多农行信息化系统已经形成了成熟且复杂的体系。与之对应的是，研发中心承担的项目复杂度也随之增加。目前，仅靠单一团队去承担项目已经是凤毛麟角。多数项目需要不同的开发团队配合，特别是大型复杂项目的研发和工程实施，往往需要多达数十个团队协同工作，如分布式核心工程、两地三中心改造等。如何在这种场景下保持敏捷，做好计划协同管理？SAFe框架中的PI及PI计划给我们提供了很好的借鉴。 如果将工程实施管理规划成PI，将工程例会转换成PI计划，不仅仅是参与项目的每个团队内部敏捷化，而且将整个工程都敏捷化起来。通过PI确定目标和交付价值，各个团队为实现交付价值的目标在PI计划中去明确待完成的任务、资源需求、交付成果，识别潜在的风险，找到团队协同的节奏。就像Sprint Planning一样，将一切为了达成目标需要完成的工作进行识别、估算，公开且做出承诺。PI计划使计划和里程碑变得更清晰，团队间协同更顺畅，进度和成果交付更可控。

架构跑道

架构跑道在SAFe体系中是一个很不起眼的概念。敏捷开发一个原则就是避免大规模提前设计(BDUF)，而架构跑道的概念提供了一种敏捷架构的方式。SAFe中对架构跑道的定义是：在系统有足够的技术基础、没有过多的重新设计以免导致延迟的前提下，能够支持实现近期高优先级特性时，我们就说有架构跑道的存在。简单地理解，架构跑道就是架构模板，组织级架构库沉淀的最佳实践。对于匹配的特性可以拿来即用，避免重新设计。 架构跑道提供了快速实现新特性的必要技术基础，这是确保开发流动的一个关键使能。但是，架构跑道会不断地被新特性所消耗，因此必须持续投入，通过实施使能不断延长跑道，从而支持新功能的实现。 如果对于架构跑道的投资不足，敏捷发布火车交付价值的过程就会变缓，对于每个特性的交付可能都需要整体的重新设计。另一方面，如果投资过多，则可能会产生永远都用不到的架构“库存”，这些“库存”可能会反过来阻塞系统的正常发展。因此，对于架构跑道的投入需要平衡。 目前，农行研发中心的架构审查制度已经很成熟，贯彻执行也很到位，在架构管控方面发挥了非常重要的决策作用。但是只是对架构进行审查，尚无法支撑架构最佳解决方案的积累和重用。产品的技术手册只是单一技术层面视角，缺少从架构层面出发、组合使用各种基础技术软件匹配领域问题的技术手册，导致不同的团队面对类似的复杂问题需要重复进行架构设计。 为此，我们可以借鉴架构跑道的理念，通过架构跑道提供各级架构方案的样例，包含适用场景、最佳组合方案和使用说明，覆盖从组件级别的组合到系统领域间的架构使用方案。架构跑道的建立，可以让团队在架构设计上敏捷起来，既可以直接沿用已有的架构方案，也可以在已知的架构跑道上演进。即使是新手团队，在跑道内也不容易翻车。架构设计敏捷起来后，带来的明显改进是可以缩短设计周期，进一步提升效率，并且设计质量可以得到保障。

05

规模化敏捷的展望

类似于SAFe这样的规模化敏捷框架的出现，并且经过几年的演化，已经建立起了一套完整的整体框架、流程和可落地实施的方案。SAFe在敏捷社区被赞誉为在组织层面上能够与 Scrum 相媲美，并且得到了若干厂商的支持。SAFe目前所具备的工具支持、冠名厂商支持、认证计划和官方标准，这一整套都为大型组织的规模化敏捷提供了实践指南。 然而，社区中并不是只有对SAFe的赞誉。实际上，有些成员表现出一定的负面反馈。比如SAFe试图建立规模化敏捷的标准化框架，随着版本的演化，体系越来越庞大，导致SAFe自身变得不怎么敏捷，让初识框架的新手无所适从。 当前，把以SAFe为代表的规模化敏捷框架定论为日臻完善可能过于乐观，但是可以肯定的是，这些框架已经进入成熟期。SAFe、Scrum@Scale、Less，DAD各具特点，都具备适合其生长的特定土壤。大型组织所面临的规模化敏捷挑战越来越迫切，规模化敏捷框架面临的挑战已经不再是理论的演化，而是去迎接现实世界实践的洗礼。规模化敏捷会不会像Scrum一样星火燎原，未来拭目以待。

(来自：我们的开心)