Hello! Big Agile! - 哈啰的大规模敏捷实践 (中)

在前文中我们介绍了哈啰研发团队的组织情况，以及在日常工作中碰到的四大挑战：

• 挑战1：团队急剧扩张，跨团队协同越来越困难
• 挑战2：不同业务发展诉求不同：成熟业务求稳，创新业务求快
• 挑战3：在业务和团队协同复杂度上升的同时，仍需做到快速响应，适应变化
• 挑战4：如何确保大型组织持续保持高效能并不断提升

同时，我们也抛出了哈啰的“3+X”应对方案：

严格统一的迭代节奏；拉毛线；SOS；+ X

那么其具体含义和做法到底是什么呢？今天我们结合一些实际的案例来深入探讨一下。

单就这几个挑战本身来看，不仅仅存在于大规模敏捷组织，而是任何大规模组织都需要面对的问题。其本质主要是需要解决以下2个问题：

挑战1~3是需要在大型组织中建立一个高效的沟通及决策机制。

挑战4是需要建立一个合理的评价体系。

重复一下我之前的观点：你也可以用其他方式来解决这2个问题，只不过用“敏捷”的方式更容易一点。

何解？

首先，因为敏捷工作模式本身就是为了更好的应变产生的，其设计的方方面面都是为更充分的沟通、更有效的做决策服务的。所以只要你的单个团队的“敏捷基础”打的牢，在大型组织中只需要将部分机制做相应的补强，即可达成建立高效的沟通和决策机制的目的。

其次，因为“敏捷”工作模式是“经验型”而非“预测型”的，更注重团队绩效，更重视“趋势”而非“绝对值”，评价体系的建立相对会更加有说服力，更加利于在更大范围达成共识。

接下来我们就回到哈啰的“3+X”中逐一跟大家介绍。

严格统一的迭代节奏

毫不夸张的说，此为解决挑战1~4的基础，怎么强调都不过分。

举个例子，大家应该都见过国庆阅兵的盛况，上万人的队伍应该是妥妥的大型组织吧？阅兵方阵能做到整齐划一，能让大家找到共同的节奏非常重要。

类比一下，在大型敏捷团队中，所有团队都遵守严格统一的迭代节奏，就好比标兵在阅兵队伍中的作用一样，是大型敏捷实施的节拍器和定海神针。

固定2周一个迭代，各团队严格遵循统一的时间节点

在哈啰，所有敏捷团队都遵循统一的迭代周期和时间点，如下图所示：

注：图中“产”特指产品经理(PO)，“业”特指业务方，“研”特指开发人员，“测”特指测试人员

以上是哈啰敏捷流程的核心，有些背后的逻辑需要做一些补充说明：

• 不是说2周一迭代么？这是一个4周的Schedule啊？

其实这张图是一个从业务方提出需求到发布上线的全过程，包含需求迭代和研发迭代两个阶段，但，这两个阶段并不耦合。

怎么理解？我们先把这个图一分为二来看。

前面2周（图中 Sprint 1）是需求输出的过程，通常是产品经理（PO）和业务方以及研发专家沟通好需求的可行性及一些需求细节，形成用户故事或PRD，并根据业务优先级和对于需求实现的初步估算的结果整理好优先级，放入需求池中。

后面2周（图中 Sprint 2）是“纯”研发的迭代。一般我们希望周一能够开始真正开始写代码，所以会在前一周的周五进行迭代规划会议（Planning Game），确认Sprint范围。迭代kickoff之后，则依据各重要时间节点要求，有序完成迭代的所有活动。

换句话说，需求迭代和研发迭代通过一个共同的需求池来发生联系，是一个异步的过程：即需求迭代阶段负责产出需求，形成完整的PRD，排好优先级后放入需求池；研发迭代根据需求的优先级从需求池中选取迭代的需求，开发、测试并发布上线。图中所示Sprint 1的时间段，PO整理需求的同时，研发团队也并没有闲着，在进行上一个迭代的开发工作。

所以，在哈啰研发的迭代周期仍是2周。图中4周的时间轴只是为了更清晰的表述，方便理解而已。

• 时间节点均为最晚完成时间

需要特别说明的是，以上时间节点均为需要完成的最晚节点。

首先，在需求输出阶段，并不存在两周一定要完成的硬性要求，研发团队只从需求池中获取需求：如果已经进入需求池了，就按优先级拿取需求作为迭代规划会议的输入；否则，请等下一个迭代。

其次，在研发阶段，达到发布要求的需求也可以在研发迭代的任何时间发布。但如果最晚迭代第二周周三之前没完成产品验收，则不会纳入发布上线的功能范围，需等到下一个发布窗口再发。

大家可以类比一下SAFe中的ART（Agile Release Train）的概念：为什么取名为Train，因为Train是不等人的，到时间能上请早，不能上请等下一班。

注：除了重大的紧急修复，用户端APP，Native部分仍需遵循2周一发的节奏，避免对用户造成过多的干扰。

End of Story！按我说的办！

在过往推广敏捷的过程中，关于迭代周期笔者经常会被问及以下问题：

“大（鼻子）老师，我们团队的迭代周期可不可以不是2周，因为，我们......不一样”？

在小规模团队阶段，我的回答是：“可以啊，只要你们团队成员达成共识就行。但不要轻易变来变去，要不先调三个月的？”

在大规模团队的场景，我的回答是：“2周就是2周，End of Story！按我说的办！”

这背后，究竟有什么深层次的原因，让一位敏捷教练有了如此分裂的回答，是人性的扭曲？还是道德的沦丧？......

呃，有点串台了，拉回来。

那为什么我的态度会差别如此之大呢？主因还是团队规模。

首先，越大的组织规则越应该遵守“字少事大”的原则。

毫不夸张的说，这也是笔者在大型团队推广敏捷时最大的体会，没有之一。

一个非常显而易见的事实是，越大的组织，团队会更加多样性，个性化的诉求就会越多。

这时候，你要做的不是增加规则的细节，让规则越来越冗长；而是恰恰相反，需要精简规则，让绝大多数人容易理解，容易操作，是为“字少”；既然规则已经比较简单了，执行就一定要更加严格，否则团队执行结果就完全不可控了，此为“事大”。

所以笔者认为，在小规模组织中，团队尽可以相对自由的去做一些尝试，找到自己合适的节奏，实在不行改回来就是；但是在大型组织中，迭代节奏是整个流程的根本。牵一发动全身，调整迭代周期试错成本非常高，一定不要轻易尝试。

其次，从实践的结果看迭代周期定为2周是最优的

任何大型组织都是从中小组织发展而来的，我们可以从过往的经验中学习。长期的实践告诉我们，2周的设定是相对较优的。

即便是在团队规模较小的时候，哈啰绝大多数尝试1周或者3周作为迭代周期的敏捷团队，最终都回到了2周这个初始“推荐值”上来。

究其原因，可能有如下几点：

• 2周是一个既不太长也不短的时间。1周的迭代实际投入开发的时间较短，实现不了太复杂的功能；3周或更长的时间，在业务情况多变的现实下，产品又往往会经受业务方比较大的压力，不利于维持迭代内需求的稳定。
• 有用户端APP的的互联网企业，也不可能过于频繁的发布版本，从而造成对终端用户的打扰。对应到挑战2，2周是一个创新业务和成熟业务都相对能够接受的方案。对于新业务，需要考虑不发布用户端版本也能够调整业务的技术方案，如H5；成熟业务也尽可以两个迭代发布一次大的版本。
• 另外一个不大起眼的原因是，一般业务及财务数据的统计都以月为单位进行，2周的迭代更容易对齐这些统计口径。

以上便是我的回答看上去有些“粗暴”的原因。

看到这里，可能有一些同学仍然会问：敏捷不是很灵活的么？大规模“敏捷”这么“僵化”的么？

我的观点是，任何流程的产生都是为了更大范围的协作。在小规模团队中，没有流程也很容易达成共识，推动事项落地；在大规模团队中则一定需要流程来统一大家的认识，达到协同的目的。所以，流程看似“僵化”，其实是大型组织必不可少的。

再回到“所有团队统一使用固定迭代周期”的目的上来，究其本质其实是为了更好的应变。

笔者在前文分析过，使用周期较短的迭代周期的敏捷项目方式其实并不一定会比传统项目方式做的更快。那为什么还用敏捷方式？答：应变。

一个迭代的结束固然是一个产品功能的“交付节点”，但何尝又不是一个可以对后续方向做修正的“调整节点”？

在单一敏捷团队中如此，在大规模敏捷实施中更是如此。

在一个传统的大型组织中，各个团队的项目计划往往各不相同，项目进度千差万别。在项目进行过程中，但凡涉及到跨团队的资源和优先级变更，去做调整一定是一个头两个大。更不用说遇到重大变化，需要大面积的调整项目节奏：无论是决策是否变更乃至后续的变更方案制定，变更实施，都是极为困难的。

但，如果各个团队的迭代周期都是同频的，我们判断变更对团队整体的影响以及做出调整计划则相对要容易的多：因为一个迭代结束后，所有团队都可以同时调整方向，甚至可以在不同的业务线之间以团队为单位做灵活的资源调配，确保整体目标达成。

所以唯有保持所有敏捷团队迭代节奏一致，才能够在大型组织中同样做到短时间响应变化。

除了迭代周期，还有一些哈啰敏捷团队必须严格执行的“规定动作”：

• Kickoff 邮件

这个邮件的内容非常简单，向相关方正式宣布团队的新Sprint Kickoff。

垃圾邮件？也许是。但我认为这一种成本最低的方式记录所有参与方达成的共识，一个受控的Sprint开始了 ！

• 使用物理白板的每日站会

虽然我们已经引入了JIRA作为项目管理工具，其中也有电子白板的功能，但笔者认为，面对实体白板，所有团队成员都可以自由移动任务状态和发言的站会，是比使用电脑里的电子白板更好的交互方式。所以强烈建议团队使用实体白板，毕竟“个体和互动高于流程和工具”，不是么？

BTW，期盼能够配置有触屏的电视作为白板，老板给批点预算。^_^

• 使用JIRA和Wiki

绝非广告。

笔者在哈啰引入项目管理系统时候也做过选型比较。一个朴素的感觉是，既然经过了这么多年的发展，项目管理工具并没有形成“一统江湖”的局面，那么市面上的主流的工具各有优劣：

有的工具容易上手，使用简单，但对于后续数据的提取和分析支持就比较弱；有的工具使用门槛较高，易用性上不大好，但后续的数据分析和提取能力却很强。所以各有利弊。

我实际的感受是，虽然JIRA在使用上有一定门槛，但对于后续的数据分析还是挺好用的。当然报表展示可能需要做一些定制化，哈啰的方式就是从JIRA里提取相关数据，通过二次开发，做了一层“皮”，用来做项目数据的分析和报表展示。

虽然JIRA中也有一些Release Plan的相关功能，但对于一般业务同学去使用还是有一定的难度。

所以，我们同时采用了Wiki作为辅助的信息传递工具，把一些业务方比较关心的发布节点和发布功能列举在Wiki上，方便大家查阅。

拉毛线

下面聊聊拉毛线。拉毛线到底是个什么鬼？难道是......

赞！这个怀旧风格的照片主播哪里拍的？咦，哈啰研发团队妹纸这么多的么？主播上招聘链接，我要加入......

好吧，我不严谨了。我不应该滥用“程序员鼓励师”，真实情况其实是......

好啦，不开玩笑了，上图片！我说的“拉毛线”确实是在.....拉毛线！

这是早期我们“拉毛线”的场景，堪比大型桌游现场。后面团队越来越多了，就发展为下面的“墙游”版本了。

一句话，“拉毛线”是在迭代规划会议之前，所有PO或团队代表都需要参与的一个30分钟左右的站立会。

先简单解释一下板的设计：

• 第一排代表不同的Scrum Team
• 列就是Team接下来的Sprint需要做的需求，按照优先级从上至下排列
• 如果需求与其他Team的需求有依赖关系，就用一根毛线把他们连起来

那么我们在这个“加长版”站立会上干什么呢？主要三件事。

• PO再次确认互相依赖

会前，PO作为具体功能的Owner，需要确认好自己Team所要开发的功能的依赖或被依赖的关系；

会上，PO会逐一的简单介绍一下自己Team的此次Sprint的主要工作内容以及“拉毛线”。

通过这种方式，我们可以让团队对于此次Sprint的交付内容有一个全局性的了解。

会上如果发现一些依赖被遗漏的情况，需要会后赶紧做沟通确认或者调整，避免临时发现导致功能因相互依赖没有理顺，无法上线的情况；会后，PO可以和相关团队明确团队联调的时间节点。

• PO再次确认优先级是否需要调整

会上如果发现某个需求上的“毛线”特别多，则需要再次确认该需求优先级是否合适。

如果当前优先级太低，则有无法完成的风险，进而会对其他Team的最终交付造成影响。所以，PO需要将这个需求的优先级提高，确保此功能的完成。

• PMO看耦合

PMO除了组织会议之外，需要关注的则是团队整体的耦合情况：是否有某个Team长期被多支Team依赖；是否毛线总体数量过多？

因为，从根上讲，只有软件系统架构解耦才能降低复杂度，才能更敏捷。Spotify正是从软件架构的角度去优化设计，降低耦合，从而能够做到Team的工作不互相依赖，从根本上提升发布的灵活性。

PMO需要结合会上的发现，持续推动架构人员优化现有软件架构。尽量让毛线越来越少，才能发布更自由，应变更灵活。

综上，哈啰的“拉毛线”会议，其实是一个“缩水版”的SAFe PI 规划会议。

这里再啰嗦两句。

笔者有时会被海外的敏捷同仁圈友“凡尔赛”到：“又组织了一次上百人的全员的PI规划会议，累趴了”云云。

跟单个敏捷团队的规划会议（Planning Game）一样，SAFe的PI规划会议和在Spotify类似的规划会议都是全员参与的。虽然磨刀不误砍柴工，但其成本却也是不容忽视的。这永远是在“长期收益与短期收益，确定收益与不确定收益”寻求平衡的“舞蹈”。

至少目前在我所在的创业公司，我暂时还没有去说服老板做类似尝试的打算。我想，这也是敏捷“本土化”、“本司化”逃避不开的课题。

合适的才是最好的，PMO还是要根据团队和组织的情况来选择具体的实施方式。

P.S.：这块“墙游”板就在公司最重要的会议室外面，一般人我不告诉他为什么。^_^

SOS

不卖关子啦，其实这个SOS就是大家都知道的Scrum of Scrums：在Team的每日站会之后，PMO再开一个站会。

板上每帖子代表需要关注的事项。红色、黄色、绿色分别对应高、中、低不同的优先级。

在SOS会上，PMO重点关注需要跨团队协调的事项。对已经有可能影响交付的重要事项，跟进以及推动解决，从而确保团队迭代的整体交付。

稍微总结一下，哈啰

• 通过“严格统一的迭代节奏”，来建立一个大规模组织协同的基本框架

究其根本，仍是利用敏捷模式本身的优势。需要每个团队的Scrum细节实施到位，加上节奏保持一致；

确定性以及规则简单非常重要。通过固定的2周迭代，各参与方非常清楚什么时间该做什么事，节约了大量的沟通成本。并借助工具（每日站会，wiki等），让所有人都能够在迭代进行中方便快捷的按需获取有用信息和及时上报问题（这就是我们常说的“Pull”的沟通方式）。

• 通过“拉毛线”在迭代开始之前让各团队对于Sprint的整体有一个全局认识，帮助各团队之间厘清依赖关系，降低迭代进行中“意外事件”发生的概率；

• 通过SOS，让PMO这个横向组织关注跨团队事项的跟进，及时发现问题，做好预警或者解决问题。

最后再回到本文开始举的阅兵的例子。

要想全员走出复制黏贴的效果，教官一定会先强调“每个人的动作做标准，个人对齐统一的标准”；在这个基础上，通过“行进中看齐你右侧的人”这个简单的规则来做微调，从而达到整齐一致的效果。

同样，哈啰是将“严格统一的迭代节奏”做为团队协同的基本规则，各团队都要对齐；通过“拉毛线”和“SOS”的方式补强在大型组织中横向的沟通效果，起到“微调”的效果，从而达成解决挑战1~3的目的。

挑战1~3讲完了，那么挑战4怎么应对，“X”又到底是个虾米东东？

今天的篇幅也差不多了，我卖个关子，我们“下”回分解！^_^