实战大规模敏捷

内容简介：实战大规模敏捷

敏捷团队只是企业敏捷开发和测试环境的要素之一。当企业需要更高水平的开发和测试能力或应对更大的项目时，可以在企业层面将各自独立的敏捷团队整合到同一敏捷环境中。

人们认为，把几个敏捷团队放在一起根本不可能共同去实施一个项目，但这并非事实。在团队层面敏捷能够优化队伍、提升效率以产出更多价值和更好的成果；类似地，企业规模的敏捷开发能够在项目层面获得相同的效果。这也就是采用大规模敏捷的最大原因。

通过大规模敏捷，各个团队可以共同集中资源、安排优先事项，共同为整个项目承担责任，而不是只关注自己的团队或特定的任务。然而要做到这一点实非易事。从职场文化上来看，这就像是要求财务部门为了公司的高级目标而自愿退居市场部门身后一样。不仅如此，财务部门还得向市场部门贡献自己的时间与专业技能来帮助后者创造绩效！财务报表先放着，必须先把产品宣传册搞出来！呵呵……

我们曾同一家在线礼品市场的领军级电商企业（年营收5亿美元）合作。他们成功实现了大规模敏捷，过程中也遇到了人们能想到的各种障碍，并进行了相应的调整。这家客户并没有循规蹈矩，而是在实践大规模敏捷的过程中寻找适合自身的方案与最佳实践，选择了行之有效的路线并一路随时修正方向。与他们合作并见证他们克服挑战的过程开拓了我们的视野。我们明白了哪些东西是有用的，哪些是不切实际的，及怎样做才能成功实现目标。

迁移到大规模敏捷环境

这家电商企业有6个敏捷团队，他们各自独立运作，但都在为同一个项目提供支持。这个项目包含多个功能驱动型团队（如登录、结账、礼品选项、消息、交付、支付、账单和评价），这些团队的工作彼此交错，服务对象则是一些相互关联的线上品牌。各个团队皆为敏捷团队，习惯了沟通、合作与责任分担。但要把这种合作氛围扩展到他们熟悉的领域之外却是团队未曾接触的理念。从敏捷到大规模敏捷的区别，就像是从国家内部的省份间合作到国与国之间的国际合作一样。

总体上，大规模敏捷需要更高层次的思维、包容与耐心。

但相比大规模敏捷遭遇的挑战，放弃它带来的成本似乎更高。因为这些团队之间没有实现敏捷，随之而来的沟通障碍与效率低下的团队合作让敏捷环境的许多优势丧失殆尽。从头至尾，整个项目沦落到几乎没能实现和交付一项明确的功能。客户希望通过企业层面的大规模敏捷让整个项目得到广泛认可。

这家公司将6个包括3至10人的独立队伍整合为一个团队。主要的方式是为整个项目设置具有明确指标的短期迭代；并根据迭代、技能差异、团队依赖来灵活安排团队成员贡献他们各自的技能。他们没有特意去塑造某种大规模敏捷的形式，而是以循序渐进的方式来调整团队和安排会议，根据团队反馈与数据分析结果来逐步前进。

与此同时，各个团队依旧保有自己的每日站会（daily standup），有自己的scrum master和技术领导。大规模敏捷的目的并不是淘汰独立团队的形式，而是让各个团队能够为同一个项目协作努力。

从开始阶段到项目过程中，这家电商企业部署了一些工具，应用了一些实践方法以实现大规模敏捷：

单一的任务列表：一开始6个团队都有自己的任务列表。开始大规模敏捷后他们就把所有团队的列表合而为一。大家需要像在自己团队内部那样来安排优先事项，但因为涉及到多个子团队，他们要设法让优先事项、关联事项都对彼此透明。单一的任务列表解决了这个问题。现在大家依照同一份任务列表实施敏捷行动，由此引出了产品委员会。

产品委员会：产品委员会基于战略层面运作，每天召开一小时的会议。通过专注于以下领域，委员会在所有团队间维持敏捷文化氛围：

• 最高优先事项
• 当前的迭代（sprint）活动
• 未计划事项
• 需要在项目层级和跨团队层面做出的决策

• 为下一次迭代所做的准备，包括两种情况：

  • 某个团队需要其他团队的协作来完成下一次迭代。例如A团队要完成迭代15中的任务需要一些B团队在迭代14中的成果。
  • 在团队之间重新分配资源：根据之后迭代的情况，团队可能需要一些自身当前不具备的技能。这时就需要考虑在必要时，将各团队或团队成员集中起来以完成最优先事项。

产品委员会的最重要角色是引入与增进文化氛围的变迁，这种有些戏剧化的改变就是从部门或团队级的敏捷升格为项目层级的敏捷。结果当然可能出现某种状况：例如完成项目的最优路线中，A部门的需求需要让位于B部门，甚至在必要时为后者贡献时间与技能。所有利益方都必须意识到这一点并支持这种做法。

Scrum of scrums：如同产品委员会从战略层面制定单一的任务列表一样，各团队的scrum master也需要有机联合为同一个scrum master服务。由此引出所谓“scrum of scrums”。在大规模敏捷环境中代表各个团队的scrum master组成一个小组。小组在战术层面运作，专注于执行。小组每两天碰一次头，讨论各项预期、需要克服的障碍和任何团队内部或团队之间的各种问题。

引入“产品委员会”和“scrum of scrums”时，公司遭遇了团队成员的一些质疑。很多团队成员想到的是官僚作风，所谓“委员会的决定”之类。事实上，如果成员不能全心参与到这些会议，不把它们当作一种通向开放和无私分享的途径，不去共同探讨优先事项、技能组合、面临的障碍和机遇，这些委员会也就形同虚设。大规模敏捷要起效靠的是将好的商业实践应用到项目中，重要的是实际行动而非纸上谈兵。

这家客户为平息对产品委员会和scrum of scrums的质疑而采取的一项重要的附加手段，不是减少会议频率，而是开更多的会！召开这些额外的临时会议的目的是为了消除个体层面的怀疑。这么做是为了强调一个观点，这家客户实施大规模敏捷实质是优先看重人力资源，且项目的成功取决于此。因此企业的行动需要增强这种优先级，不仅体现在管理层面，更要体现在所有层级的每一位团队成员。由此发起了两类会议：“精益咖啡会议”（lean coffee session）和“敏捷咖啡会议”（agile coffee session）。这些会议为所有团队的成员提供了非正式的途径来讨论各种话题，包括技术上或人际关系方面的事项、担忧和建议。这些会议有助于有机扩散大规模敏捷的文化，这种扩散并非从上至下，而是相反。

敏捷教练（稍后进一步讨论）在转变团队成员对会议的看法上扮演了关键角色，这些会议不只是理论争辩和观点分享，更多的是作出决策和即时行动。与会成员发现这些会议导向了实时行动和开放交流后，他们就乐于参与其中了。

主动汇报：很多团队成员习惯于将数据收集当作被动的汇报工具，与他们的日常工作无甚关联。但在大规模敏捷环境下，只有实时应用收集到的团队数据才会有效促进项目进展。由此引入了主动汇报。类似地，敏捷教练会帮助团队成员将数据视为主动而非被动的工具。

大规模敏捷需要同时在宏观和微观层面收集数据，并进行数据分析和实时响应。这家企业的案例里，统计信息和数据来自整个项目和所有为项目提供支持的团队。这些数据包括如下内容：

• 故事分数（story point）的完成数量（即Velocity）
• 按照原因对积压的用户故事（user story）进行分类（例如“被阻塞的”）
• 团队之间的依赖
• 根据以往的迭代执行效率来预测项目的完成情况

这一层级的汇报需要一些企业级的工具，这些 工具 用来在项目、团队和成员层级收集数据。这家公司之前就使用 TFS 进行代码与bug追踪，结果他们发现拿它用于项目层级的报告也挺容易。重点在于这套工具需要应用到所有层级，用在所有种类的报告与回顾上，不能拿Excel工作簿或者Word文档来应付了事。

在项目、团队与迭代层级的回顾阶段会进行数据分析。根据分析结果采取的行动包括合并、拆分团队和调动团队成员。精益咖啡会议和敏捷咖啡会议有助于让这些转变更加平滑自然。

敏捷教练：这家公司请到了外部的敏捷教练，不过根据不同案例中技能组的情况，外部和内部人员都可以充任这一角色。本案例中，请到的敏捷教练引入并激励了企业的敏捷文化，鼓励并促成了团队的表现，并引导团队学会与内部、外部的团队、管理者与其他利益方进行协作。在团队成员改变固有思维和接受新理念的过程中敏捷教练起到了关键的作用。

大规模敏捷过程中不该出现的问题

为了让6个敏捷团队有效协作，这家领军级电商必须解决一些遗留问题：

未能将人员置于比项目更高的优先地位：在这家客户成功实施大规模敏捷的过程中，由项目至上的文化转变成人员至上的文化是核心要素。如果没有这种核心的转变，公司不可能得到团队与部门内部必要的信任和尊重，自然也就无法有效完成任务和迭代。咖啡会议就是用来促成这一变化的。所有层级的担忧都应该得到听取和重视，这样所有人才会愿意去信任上层体系。

未能有效处理数据：大规模敏捷中的主动汇报与回顾能反映出问题所在，乃至揭示处理它们的方法。通过研究数据，公司发现往往问题的根源和解决方案的瓶颈恰恰来自于抱怨这些问题最多的人身上！正是经过分析的数据证明了这一点。

未能使用可扩展规模的工具：公司里有的敏捷团队想用Excel工作簿来实施大规模敏捷。对于这种情况来说

工具就成了瓶颈。让所有团队都迁移到TFS环境是至关重要的。

未能实现协调一致与透明化：有些项目参与者觉得开会是浪费时间，不管会议是开发层级、scrum master层级还是利益关系方层级。他们认定会议上大家不会开诚布公，开会也不会直接引发行动。因此，委员会与scrum of scrums在透明原则下作出的努力与进展，成为了提升项目参与度的不可或缺的要素。

未能给团队成员设置敏捷成果的考核标准。实现大规模敏捷是体系与人员的职责，最终的成功需要两者共同努力。这家公司发现他们需要提供、选择、参与、撤出和调动各种资源来激发团队活力。公司对内部与外部利益方定下了考核标准，如果团队成员不能提供所需的技能，缺乏应有的态度，他或她就是项目成功的阻碍，会被立即调到其他项目中。公司会主动拒绝或调动这些人员：

• 一门心思只想着在自己擅长领域干活表现，对其他事情不管不顾的成员
• 对适应持续变化的环境不感兴趣的成员
• 不想与同事持续沟通，获取信息和反馈结果影响了项目总体效率的成员

成功之路

企业级大规模敏捷事关交付与控制。这家公司的成果正是交付与控制的结果：

• 在规模化初期，开始的两个迭代用来建设团队、组建工具、设置产品列表。第四个迭代开始交付。第六个迭代起团队开始持续交付。Velocity数据能够了解和预测各个团队何时交付自己负责的功能。
• 大规模敏捷开始之前几乎没有明确的功能得以实现和接受。随着大规模敏捷开始实施，积压的用户故事比例从80%降到了50%，直至最终下降到了稳定、可接受的10%以下。

数字摆在这里，而与这些数字同样重要的是一种协作、信任和充满信心的文化；这种文化是实现这些数据所反映成果的关键因素，并最终成就了一个规模更大、更加忠诚敬业的队伍。平台根据团队成员的特质与项目情况进行调整，使得雇员能够亲身体会大规模敏捷的成果。这家客户不仅成功完成了项目，更是形成了能够实现更多类似成就的企业文化。

作者介绍

Yousef Awad 是Integrant的CEO，他在开发、数据库管理和项目管理方面有着亮眼的从业经历。Integrant有超过130位员工，提供定制的.NET软件开发服务和测试团队，帮助IT部门掌控项目，有效扩展内部团队。除了Integrant的事业之外，Yousef还热心于让儿童和青年体会编程的力量。Yousef正在努力为低龄儿童开设代码课程，为他们提供手把手的指导。他欢迎相关的探讨，可以通过info@integrant.com与他联络。

查看英文原文： Agile Scaling in Action

感谢薛命灯对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号： InfoQChina ）关注我们。

以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

• 大规模知识图谱数据存储实战
• 深度学习在 Airbnb 大规模搜索排名上的实战经验
• 阿里巴巴大规模应用 Flink 的实战经验：常见问题诊断思路
• 直面算法霸权：大规模造福工具还是大规模杀伤性武器？
• 大规模微服务实战经验
• Firmament - 大规模集群任务调度

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。