随着“敏捷”逐渐被国内越来越多的从业者接受，自然而然的，越来越多的大规模的敏捷模式也逐渐的映入到了大家的眼帘：LeSS，SAFe，Spotify…于是 我们跟当年不知道如何选择单个团队的敏捷实践模式一样，又陷入了不知如何开展大规模敏捷实践的困境当中。
其实我们不需要做选择题，这几个大规模敏捷框架从本质上说并不是“非此即彼”的。
与单个敏捷团队的实践原则相同，大规模敏捷框架同样是适合的才是最好的。可以采用“LeSS起步，SAFe挂挡，瞄着Spotify”的方式，在团队发展不同的阶段采用不同的框架，甚至并不需要在意现在用的是LeSS还是SAFe，是Spotify亦或者其他…
今天笔者就结合一些实际的工作案例，将近些年在哈啰的大规模敏捷实践跟大家做个详细的分享。
哈啰背景介绍
毋容置疑，任何产研团队的组织方式和工作方式的选择都应该是以支持业务发展为第一要务。
哈啰被大家认识和熟悉肯定是因为共享单车，但是你还知道哈啰的其他出行服务么？下面用一页官方PPT给各位同学简单介绍一下哈啰目前的业务状况，让大家有个基本了解：
相应的，产研团队也从最初的100多人，发展到了千人以上的规模，妥妥的中大型研发团队了。
笔者有幸参与了这一发展的全过程，并且一直致力于推广Scrum的敏捷实践，在哈啰逐步形成了大大小小的50+以上的Scrum 团队。那么这些研发同学日常是如何组织的呢？不啰嗦，直接上图：
为了方便大家理解，稍微做一下解读：
- 每一个最小的方框，表示一个最基本的团队单元，即一个Scrum Team，是由不同的角色组成的跨职能敏捷团队
- 多个Scrum Team 共同服务于某个业务线一个具体的产品（实线圆角框），如哈啰单车产品，单车运维端产品（哈啰内部运维人员使用的APP）
- 不同业务线的产品整合在一个统一的APP中，如图虚线框所示（哈啰用户端APP，哈啰运维端APP）
哈啰研发团队整体的组织结构就是这样，应该比较好理解。
这个图大家是不是有似曾相识的感觉？对，Spotify ！
笔者在前文介绍Spotify的内容中提到，Spotify“发明”了一系列的团队组织名称，其本质上与哈啰的实践内涵大体相同。我们稍微花点时间类比一下:
- Spotify Squad（小队） 对应 哈啰 Scrum Team
- Spotify Tribe（部落） 对应 哈啰某个业务线产品（ 哈啰APP单车产品 ）
- Spotify Chapter （分会）对应 Scrum Team 角色实际归属的行政组织（单车产品小组，单车前端小组，PMO 等等）
- Spotify Guild（协会） 对应 哈啰 社区 （敏捷社区，前端社区等）
除此之外，哈啰同一业务线不同的产品也有相应的协作关系，即最外围的实线框的部分，我们“戏称”为Alliance （联盟）。
虽然我们最初在设定团队组织方式的时候并没有刻意去模仿Spotify，但自然而然的发展成了现在这个样子。
因为哈啰与Spotify组织的功用内涵基本一致，这里就不赘述了。
关于Scrum团队的基本组成方式我想稍微再啰嗦两句：
我们都知道Scrum Team是一个相对固定的跨职能虚拟工作团队，里面含有不同的角色，如PO，开发，UI，测试等等。但这些角色在组织里的实际“行政归属”（即在组织架构里可以看到的单位）是怎样的其实各大敏捷框架里面都没有谈及。
以笔者过往的经验来看，无外乎两种方式。
一种是和哈啰相同的方式，实际组织架构与Scrum Team 不重叠。即同一角色来自于相同的行政组织，打散加入到不同的Scrum Team；另外一种则是整个Scrum Team 就是一个实际的行政组织，整个Team的“直线领导”就是Team的PO，或者是技术Leader的情况。
笔者强烈建议采用实际组织架构与Scrum Team 不重叠的的方式，即哈啰目前的方式，原因有三：
- 标准的Scrum Team中是没有明确的Team
Leader的，更利于集体决策和团队自发的自我管理。Team与实际组织架构不重叠的方式更符合敏捷团队的内涵； - 不同角色的个人专业发展由相对专业的人负责（直接领导为角色相关领域的专家）更为有的放矢和延续性；
- 不同角色的专业视野及跨团队信息传播和交流更为便利，避免信息深井。
特别是在中大型敏捷团队中，后一种方式的组成的团队，往往不能站在全局的角度思考问题，产生的副作用将会被团队规模放大，不利于整体协同。
大规模敏捷组织带来的挑战
哈啰的研发团队规模是随着业务成长逐渐发展，在业务由少变多、组织规模由小变大的过程中，研发团队主要面临着以下4个方面挑战：
挑战1：团队急剧扩张，跨团队协同越来越困难
本质上这是一个信息沟通的问题。我们都清楚，随着信息节点的增加，信息沟通渠道的增长是指数级的( N*(N-1)/ 2)，以前靠吼就可以搞定的事情，现在团队多了，无论是做决策还是具体实施，都需要更多的上传下达的工作。
沟通成本大大增加，跨团队协同越来越难是所有人一致的感受。
挑战2：不同业务发展诉求不同：成熟业务求稳，创新业务求快
哈啰仍属于创业阶段，在维持原有业务的基础上，新的业务不断孵化涌现。
成熟业务经过了几年的发展，客观上并没有那么多需要快速发布的新功能。相反，因为用户基数大，为了控制业务或者产品调整造成的影响，任何动作都更倾向于稳；而创新业务往往商业模式都没有完全确定，需要快速的试错和调整，对于产品新功能的发布则希望越快越好…
矛盾在于不同业务线都融合在一个产品中提供给用户（用户不可能装N个APP），如何调和需要慎重拿捏。
挑战3：在业务和团队协同复杂度上升的同时，仍需做到快速响应，适应变化
如挑战1所述，多个团队、多个业务线在达成一致和做好协同的复杂度在提升，但“你大爷还是你大爷”-- 变化并未减少。
如何在内外部变化产生的时候仍能够做到快速响应，特别是在不同业务线功能和资源优先级发生冲突的时候如何快速调整，需要一个长期可行的预案做保障。
挑战4：如何确保大型组织持续保持高效能并不断提升
大型组织中任何小的问题都会因为团队的规模的原因而被迅速放大。
对于如何让大型组织持续保持高效能并不断提升，我想是每一个团队管理者都无法回避的“灵魂拷问”，也是一张必须要交的答卷。
如何应对？哈啰的实践
在揭晓哈啰的解法之前，我们再回头看看这四个挑战。
如果我们直接把“大规模敏捷组织带来的挑战”中的“敏捷”这两个字去掉，应该不会有人会反对吧？我想这是任何大规模组织都会面临的问题，看你如何解决而已。
笔者近些年越来越体会到，这几个难题用别的方式也能够解决，不过用敏捷的方式似乎更容易一点。
那哈啰具体是如何应对的呢？
简单的说，答案是“3+X”。嗯，有高考内味儿了。
3就是：严格统一的迭代节奏；拉毛线；SOS。估计你看到这里一脸黑人问号：
统一的迭代节奏？敏捷不都这么玩么，有什么特别？
拉毛线？公虾米？
SOS？是搞不定了要求救了么？
还有“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 Kick off。
垃圾邮件？也许是。但我认为这一种成本最低的方式记录所有参与方达成的共识，一个受控的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 规划会议。
合适的才是最好的，PMO还是要根据团队和组织的情况来选择具体的实施方式。
SOS
不卖关子啦，其实这个SOS就是大家都知道的Scrum of Scrums：在Team的每日站会之后，PMO再开一个站会。
板上每帖子代表需要关注的事项。红色、黄色、绿色分别对应高、中、低不同的优先级。
在SOS会上，PMO重点关注需要跨团队协调的事项。对已经有可能影响交付的重要事项，跟进以及推动解决，从而确保团队迭代的整体交付。
通过“严格统一的迭代节奏”，来建立一个大规模组织协同的基本框架。
究其根本，仍是利用敏捷模式本身的优势。需要每个团队的Scrum细节实施到位，加上节奏保持一致；
确定性以及规则简单非常重要。通过固定的2周迭代，各参与方非常清楚什么时间该做什么事，节约了大量的沟通成本。并借助工具（每日站会，wiki等），让所有人都能够在迭代进行中方便快捷的按需获取有用信息和及时上报问题（这就是我们常说的“Pull”的沟通方式）。
- 通过“拉毛线”在迭代开始之前让各团队对于Sprint的整体有一个全局认识，帮助各团队之间厘清依赖关系，降低迭代进行中“意外事件”发生的概率；
- 通过SOS，让PMO这个横向组织关注跨团队事项的跟进，及时发现问题，做好预警或者解决问题。
最后再回到本文开始举的阅兵的例子。
要想全员走出复制黏贴的效果，教官一定会先强调“每个人的动作做标准，个人对齐统一的标准”；在这个基础上，通过“行进中看齐你右侧的人”这个简单的规则来做微调，从而达到整齐一致的效果。
同样，哈啰是将“严格统一的迭代节奏”做为团队协同的基本规则，各团队都要对齐；通过“拉毛线”和“SOS”的方式补强在大型组织中横向的沟通效果，起到“微调”的效果，从而达成解决挑战1~3的目的。
扫一扫
1668
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
