软件企业大规模敏捷策略研究

陈 刚，贺晋宁

（中兴通讯股份有限公司，江苏 南京 210012）

软件企业大规模敏捷策略研究

陈 刚，贺晋宁

（中兴通讯股份有限公司，江苏 南京 210012）

大规模敏捷开发是软件企业的重要改进方向。文章对大型软件开发的特点进行了分析，并比较了几种业界常见的大规模敏捷开发方法，结合实践经验，提出了一系列针对性的策略，将有助于软件企业成功实施大规模敏捷。

软件；企业；大规模敏捷；策略

1 敏捷开发的产生

传统的软件开发方法是在20世纪70年代产生，有瀑布模型、螺旋模型、喷泉模型、RUP 4类，它们注重文档的完整，程序的易读性，结构的完整性，属于重型软件开发方法。随着市场环境的变化，传统软件开发方法面临着严重的挑战。由此人们开始对软件开发过程的本质重新进行思考和探索，在20世纪90年代，一系列轻量级开发方法相继被很多软件大师提出。2001年2月在美国犹他州的雪鸟滑雪场召开了软件开发大会。本次会议发布了“敏捷宣言”，包括4个核心价值观和12条基本原则，这标志着敏捷开发的诞生。

敏捷开发具有很多优点，例如不断变化、充分发挥人的创造力和主动性、迭代开发过程中一直保持软件产品的可用状态等。这些优点吸引了越来越多的软件企业研究和应用敏捷开发。

2 敏捷开发在小团队中的应用

经过多年的业界探讨和尝试，在敏捷方法论层面Scrum和XP得到了广泛认同。两者被认为是针对新产品开发一个非常完美的搭配，从管理和技术两个方面支持了敏捷开发的实施。

Scrum是一种轻量化的敏捷软件开发管理框架，每隔1～4周，每个人都能看到能实际工作的软件，并且据此决定是发布这个版本还是继续开发以加强其功能，这样将原先的长周期的开发过程切割成若干个小段，用户反馈速度大大提升。一个Scrum团队要求在5～9人之间。Scrum团队包括3类角色：（1）产品负责人，负责维护产品订单的人，代表利益相关者的利益；（2）Scrum Master，为Scrum过程负责的人，确保Scrum的正确使用并使得Scrum的收益最大化；（3）开发团队是由负责自我管理开发产品的人组成的跨职能团队。

极限编程（Extreme Programming，XP）是一种轻量级的、灵巧的软件开发方法，同时也是一个非常严谨和周密的方法，其基础和价值观是沟通、简单、反馈、勇气和尊重。XP是一种近螺旋式的开发方法，将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其他一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。XP有13个核心实践，同样也被认为十分适合小团队实施。

基于这两种方法，瀑布式的小型软件开发团队（10人以内）可以在3～6个月内转型为敏捷开发团队，交付能力有机会获得较大提升。当然，实施过程也有很多风险和困难，需要有周密的策划，包括管理层支持、建立转型小组、痛点驱动、迭代式改进、逐步应用各类实践、系统化的敏捷培训等。

3 大规模敏捷的困惑

早期的敏捷理论是针对小型团队的，这也让很多人认为敏捷开发只能在小型团队中实施。不少软件企业的敏捷开发起步也是从个别开发小组试点开始的，在取得初步成效后，会吸引更多的开发小组来实施敏捷。但这些小的敏捷团队仿佛是在各自的孤岛里，难以对企业的整体研发能力带来结果性的影响。而在不少软件企业，一个完整的软件团队会远超一个Scrum团队的规模。由此带来疑惑，把一个大型软件团队都纳入敏捷开发，实施大规模敏捷是否真的可行。

所谓大型软件团队通常是指几十甚至数百人的规模从事同一产品的研发。为了方便项目管理及质量监控，大型团队通常会使用瀑布模式，按照需求分析、概要设计、详细设计、编码、测试、软件交付的流程来进行开发。每个阶段都有相应的角色负责本阶段的工作，由此需要定义多种角色包括需求分析人员、设计人员、开发人员、系统测试人员等。软件企业为了支撑这样的软件开发过程，会实施矩阵式管理，一个项目会需要贯穿多个行政部门，而同一行政部门则要支持多个项目。由此，一个大型团队会有若干个多部门的职能团队组成。很显然，在一个大型团队实际运作的复杂度远超小型团队。而小团队的痛点问题大型团队都可能遇到，并且还会有大型团队自身的痛点，特别是各职能团队之间的协调问题，最容易引发各种矛盾，带来内部的浪费，从而导致影响交付效率和质量。面对这些问题，经典的Scrum管理框架难以解决项目管理方面的挑战。而XP方法论在人员较多的情况下，本身的高学习门槛的问题也会放大，阻碍导致团队成员技术能力进一步提升。

4 大规模敏捷开发方法论

企业的难点也成了业界研究的热点。在2010年以后，大规模敏捷开发方法得到了深入的研讨和探索。大规模敏捷开发方法重点关注的是多个Scrum团队比较紧密地工作在一个产品上的时候，必须解决不同团队之间的协同的挑战。目前有一些大规模敏捷的解决方案，最有影响力的就是敏捷方案管理（Scrum of Scrums，SoS）、大规模混乱（Large-Scale Scrum，LeSS）、规模化敏捷框架（Scaled Agile Framework，SAFe）。

4.1 SoS

当多个Scrum团队工作在同一个产品上的时候，虽然努力想做到全功能的特性团队，希望能在一个团队里做完所有的事情，而不需要依赖其他的团队，但这明显只是一个非常理想的状态；团队之间不可避免会有依赖，需要协同。SoS的做法就是每个Scrum团队选出1～2个代表，团队的代表聚在一起分享进度和协同解决依赖。SoS非常简单，其主要形式就是一个（或一系列）会议。最频繁的情况是每天一次，最少的情况下是每周一次。在SoS会议上，各团队的代表需要回答4个问题：从上次会议到现在你们团队做了哪些任务？到下次会议之前你们团队计划完成哪些任务？你们团队有哪些困难需要其他团队协助的？你们有没做什么会影响其他团队工作的决定的？

需要注意的是SoS相对比较简单，可以帮助Scrum团队人数增加时管理的扩展，可以帮助部分解决团队间协作的问题，却无法从根本上解决大型团队整体管理的诸多问题。

4.2 LeSS

LeSS是大规模的Scrum，是将Scrum原则和理念应用到同一产品线的多个团队中。LeSS由10项原则、2种框架、大约50条指南（解释在组织中如何应用LeSS框架以及需要什么类型的改变）及600条试验组成（规模化敏捷开发时可以尝试或避免的）。

10项原则：透明、经验过程控制、精益思想、系统思考、排队论、大规模Scrum仍然是Scrum、以少为多、关注整个产品、以用户为中心、向完美持续改进。其中前两项属于Scrum的基本原则，3～5项属于Meta类原则，6～10项属于LeSS特有原则。

2种框架：LeSS和LeSS Huge。前者是简化版框架，适用于2～8个团队的产品群体（例如50人左右）。后者是大型框架，适用于单个产品超过百人或千人规模的产品群体。简化版框架由一名PO面向多个Scrum团队，增加的活动为多团队的联合回顾会（可选）。而大型LeSS引入需求领域的概念，增加了2个新的角色即领域产品负责人（APO）和产品负责人团队（包括PO和所有APO）及一个领域待办事项列表（APB），活动增加了联合评审会（可选）和联合回顾会（可选）。

特性团队是LeSS实施的关键点。LeSS继承了Scrum的思想，认为一个严格意义上的Scrum团队就是一个特性团队。为完成产品待办列表中的一个条目（一个客户特性）而进行所有的工作。团队的目标是鼓励成员学习更多技能和整个团队进行完整特性的开发。特性团队是跨职能的，由测试人员、开发人员、分析人员等组成，单一功能团队将不再存在。组件团队是开发人员围绕系统组件组合的，会带来很多弊端，特性团队不是围绕组件集合，而是组成可以在任何模块中工作的跨组件团队，目标是完成特性开发工作。特性团队将团队之间的协调难题从团队之间的项目管理转移到代码层面的协调。这种转变也带来新的挑战包括扩展技能、代码并发访问、分担设计职责等。

实施LeSS将对组织结构带来变革性影响，使组织管理趋向偏平化，矩阵化的管理将不再建议继续适用。为解决行政部门弱化后专业技能培养的问题，实践社团（CoP）作为试验的内容被重点推荐，以非正式的渠道帮助在组织内部横向传播知识。

4.3 SAFe

SAFe定义了一个可扩展的敏捷框架模型，适用于大型团队的合作开发，可以帮助提高团队之间的协作性，降低团队管理的复杂性。SAFe自发布后一直根据用户的反馈不断地迭代演进，2017年6月22日更新到4.5版本。

尽管版本不断更新，SAFe的基本框架一直保持不变，从团队（Team）、项目集（Program）和投资组合（Portfolio）3个层面清晰定义了规模化敏捷的框架。

在第1层投资组合，由投资组合管理委员会（Program Portfolio Manager，PPM）来负责定义和驱动投资策略如何形成和资金的组合形式，然后将其体现成为史诗（Epics）。一个Epic可以是一列单独的敏捷发布火车（Agile Release Train，ART）来执行，也可以是几个火车的组合。Epic是直接面向客户的、设计架构级别的业务解决方案。在第2层项目集，由产品经理（Product Manager，PM）负责把等待安排的计划（Backlog）进行排序，并且把投资策略转化成具体的特性（Feature），同时和业务负责人一起设计出项目的愿景和路线。在第3层团队，由产品负责人（Product Owner，PO）和团队成员根据上面的定义细化出用户故事（User Story，US）和验收标准，开发团队可以从候选的用户故事里面优先选择可以提前开始的内容，其余的留到故事池里面等待后续的选择。

由此可见，SAFe从3个层面保证了团队和企业的投资组合的最终愿景一致。同时，在实施过程中，需要一系列的里程碑事件来保证最终的实现和高层愿景设计的持续一致，而里程碑事件的制定主要通过发布规划和系统的展示来保证。

在LeSS里，从根本上围绕业务驱动项目重组企业，不需要管理者和专家。而在SAFe中，管理者还有架构师和专家有了一席之地。SAFe是借鉴了精益、敏捷和瀑布流开发方式的细致、重量级的方法。SAFe为企业大规模实施敏捷带来了系统化的思路，带来几方面的好处，首先引入了大型需求、架构如何从愿景到实施团队的层次化管理。其次，业务师、架构师、PMO、质量管理等人员可以考虑如何在各层级的介入；再次，对传统项目、传统管理方法的改造，比如如何利用精益敏捷方法对传统需求价值评估、如何从“项目管理”到“持续内容管理”的转变、对传统单项目管理思维的优化、从里程碑治理到基于事实的治理等。正如其名字的隐喻，SAFe期望让传统的软件企业在规模化敏捷过程中感到“安全”。

5 大规模敏捷开发的落地策略

任何敏捷开发方法在实施运用时，都不可避免地要与企业的实际状况相结合，才能发挥其应有的作用，对于大规模敏捷开发的方法更是如此。经过实践探索，总结了6条大规模敏捷开发落地的策略。

5.1 管理层重视支持并亲力亲为

对于小团队而言，管理层的支持体现在给予资源支持，提供改进的空间和氛围。而对于大型团队，敏捷开发会涉及组织结构的调整和人员角色重新调整，这个对既有的管理机制会带来很大的冲击，原先有的岗位可能消失，运作方式会发生很大的变化。因此管理层不仅需要理解其中的因果关系，也要亲自参与和领导这场变革。

5.2 痛点驱动与愿景驱动相结合

小团队往往从痛点分析出发启动敏捷开发，对于大型团队也仍然适用。不同的是，大型团队的敏捷实施对于企业发展方向会带来重大影响，企业的高层和团队的管理层都需要理解这种变革将会把企业和团队带领向何方。以痛点为出发点，以愿景为方向，才能保证大规模敏捷开发的顺利实施。在实施中，愿景可以转化为以半年或一年为粒度的里程碑目标。

5.3 对敏捷理论采用拿来主义

业界大规模敏捷开发的理论方法都有其特点、优点、缺点及产生的背景。完全照搬难以获得期望的效果，需要将这些方法与企业和团队的实际情况相结合，有选择地引入实践帮助团队的有效改进。例如，LeSS中的特性团队对于团队交付能力会有质的帮助，而SAFe的敏捷发布火车概念，可以很好地在项目管理层面将敏捷开发契入既有的企业管理框架。

5.4 夯实Scrum团队层面的敏捷基础

Scrum团队是大型团队敏捷的基本单元，在组织层面管理变革时不能忽视这一重要基础。需要不断培养合格的SM，帮助Scrum团队向自组织方向发展。

5.5 重视敏捷教练的培养与文化建设

敏捷教练是大规模敏捷开发实施的骨干力量。无论是管理教练和技术教练，都有其重要价值，可以帮助各种实践在团队内部有效实施，凝聚成为若干个实践案例。管理方式的变革和技术实践的演进对普通员工都会带来现实的压力和影响，需要通过培训、学习、交流等各类活动帮助其快速适应这种变化，建立善于学习、乐于分享的敏捷文化。

5.6 鼓励创新与实践沉淀相结合

对于管理者往往期望将最佳实践在组织内部快速复制，从而减少其他人的摸索成本，提升整体的研发能力。最佳实践也往往会沉淀为组织规范，但在敏捷开发中最佳实践这个词本身会有争论，会限制其他团队的更新、更好的实践产生。因此，组织规范不应成为改进探索的约束，相反应鼓励更多团队在相互学习的基础上进一步创新，以获得更多的优秀案例。在企业内部，这也会促使过程改进工作重心由星形集中化推动向网络形横向互连的变化。

6 结语

大规模敏捷开发是对软件企业发展的重要的命题。SoS，LeSS，SAFe等大规模敏捷方法都具有重要的参考价值。而要有效实施，则需要企业内部的管理者有充分的理解和参与，才能将理论与实际相结合。需要注意的是，这种实施过程不是一蹴而就的，需要有长期的探索和演进。在此过程中，无论是管理者还是敏捷教练，都需要不断回顾和重温敏捷宣言，反思实施过程，才能及时发现和解决各种问题，保证改进方向的正确性。

[1]拉尔曼.精益和敏捷开发大型应用指南[M].孙摇媛，李摇剑，译.北京：机械工业出版社，2010.

[2]拉尔曼.精益和敏捷开发大型应用实战[M].孙媛，顾全，译.北京：机械工业出版社，2011.

[3]莱芬韦尔.敏捷软件需求：团队、项目群与企业级的精益需求实践[M].北京：清华大学出版社，2015.

Study on large scale agile strategy in software enterprises

Chen Gang, He Jinning
（ZTE Corporation, Nanjing 210012, China）

The large scale agile development is an important improvement direction for the software enterprises. This paper analyzes the characteristic of large scale software development, compares several common large scale agile strategy methods. Based on practical experiences, puts forward a series of pertinent strategies, which will help the software enterprises to successfully implement large scale agile.

software; enterprises; large scale agile; strategy

陈刚（1977— ），男，江苏宝应人，工程师。