随着“敏捷”逐渐被国内越来越多的从业者接受，自然而然的，越来越多的大规模的敏捷模式也逐渐的映入到了大家的眼帘：LeSS，SAFe，Spotify......于是我们跟当年不知道如何选择单个团队的敏捷实践模式一样，又陷入了不知如何开展大规模敏捷实践的困境当中。
基于这个原因，笔者在《小团队，大敏捷》这个主题中对于业界主流的大规模敏捷框架做了比较详细的分析比较之外，鲜明的提出了自己的观点：
其实我们不需要做选择题，这几个大规模敏捷框架从本质上说并不是“非此即彼”的。
与单个敏捷团队的实践原则相同，大规模敏捷框架同样是适合的才是最好的。可以采用“LeSS起步，SAFe挂挡，瞄着Spotify”的方式，在团队发展不同的阶段采用不同的框架，甚至并不需要在意现在用的是LeSS还是SAFe，是Spotify亦或者其他......
说了这么多，似乎又开始有点“玄学”的味道了。你说了那么多道理，你自己的“人生”又过得如何？
真枪实弹，一直是本专栏坚持的风格。今天笔者就结合一些实际的工作案例，将近些年在哈啰的大规模敏捷实践跟大家做个详细的分享。
希望能够抛砖引玉，帮助大家更好的理解大规模敏捷实施的要点，少走弯路少进“坑”，进而开拓出一条属于自己的大规模敏捷实践的路来。
也欢迎各位业界大咖批评斧正。
是以为序。
一句话广告时间
毋容置疑，任何产研团队的组织方式和工作方式的选择都应该是以支持业务发展为第一要务。
哈啰被大家认识和熟悉肯定是因为共享单车，但是你还知道哈啰的其他出行服务么？下面用一页官方PPT给各位同学简单介绍一下哈啰目前的业务状况，让大家有个基本了解：
哈啰从2016年上线Hellobike至今，经过了近6年的发展，目前已经形成了单车、助力车等6条主要的业务线，其他创新业务仍在不断孵化中。目前业务覆盖了几百个城市，为上亿用户提供服务。
相应的，产研团队也从最初的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”是个什么鬼？
别急，别急，我们今天先破个题。在后续的文章里，我会结合一些实际的工作案例，跟大家掰开了，揉碎了仔细探讨，敬请期待！
最后，留个小调查。
各位同学在大型团队协同中遇到的最棘手的问题是什么？你们是如何解决的呢？
欢迎留言，我们一起互动！^_^
