Background
Scrum和Extreme作为敏捷方法论的普遍实践之一，为许多敏捷团队提供指导，但是当团队人数超过10人时，随着人数的增多，scrum会变得越来越低效并难以实施。在我们的团队达到30人时，我们就体会到了诸多不适，比如每日站会时间超过30分钟；有同学直接用“这张卡片正在开发中”来做每日更新；代码审查会议过长；团队凝聚力不强，出现小团队的行为等。我认为在scrum下，这种现象的出现是必然的，因为scrum是为小规模团队提供敏捷指导的，它所规定的人员配比如下图所示，我们看到团队尺寸必须在5-9人之间。Kniberg也曾指出当团队成员超过10人时，尝试考虑把其中两个人踢出去吧[1]。
当超大团队出现的时候，还是要想一想出现的原因是什么，是不是前期对产品的划分出现了问题，导致所有的产品功能没有解耦；是不是交付1.0.0版本之前出现大量bug和蹦石而出的新需求，需要更多人救火；是不是因为签订新合同后盲目激增了交付团队人数。如果无论是什么原因，都避免不了目前超大团队形成的情况，那么就积极应对吧，说不定会探索出更美妙的scrum plus版。
Exploration
解决问题的思路也很直白，可以分为两种，第一种是划分成多团队，使各个小团队可以自行执行scrum事件；第二种是维持大团队，同时修改scrum事件的规则使之适应目前的团队尺寸。
假设在这个团队总共30人，其中2名产品负责人(product owner/BA)，2名测试人员(QA)，2名产品设计(UX)，1名敏捷经理(scrum master/PM)，和2名技术决策者(Tech Lead)，其余21人为开发人员。
首先我们先来探索划分为多团队的模式。
我们假定多团队还是公用一个产品backlog（如果不是的话，那么大概率可以直接按照backlog来划分成完全独立的团队），那么团队的构成可以如下图所示：
每个团队都是全功能团队。但是纵向的会有交流沟通和协作。比如3个团队共享2个UX，那么这2个UX先生就要在设计上追求统一语言，时刻保持同步，使3个team能交付出风格统一的功能。同时，设计也能向他所在的team同步信息，比如team B已经开发过这个组件，可以直接跟他们协商来获取这个组件的信息。
在这种模式下的scrum和XP活动的改变：
-
站会：每个team分别组织站会，之后派出一个代表来参加大站会，大站会的参会人还有PM，客户，和其他除去两个team之外的成员。这样能保证大部分团队成员节约站会时间，同时每个小组每天会有1名成员掌握所有团队的进度信息。
-
Sprint Planning会议：产品负责人会对迭代目标做出介绍，并阐述想要交付的价值，然后对sprint backlog中的卡做描述。没错，开sprint planning会议的时候，需要提前把sprint backlog准备好。这就会增加一个sprint preparation会议来做这件事情，等下会介绍具体做什么。
参会人为团队所有成员，以保证迭代目标和价值在大团队内是统一的，并且成员会熟悉下个迭代的主要功能有哪些，不至于造成业务上下文丢失。 -
Sprint Planning Preparation会议：每个team单独进行，由产品负责人把backlog中属于本team的故事卡做介绍，并由本team的开发成员进行估点，最后把估完点的故事卡放入下个迭代的sprint backlog中，完成下个迭代的准备工作。改动后的sprint backlog的形成如下图所示：
-
Retrospective会议：每个迭代发生一次，所有团队成员共同参加。这种多团队的划分模式也是属于team决策的一部分，团队成员也会对这个决策发生反馈，所有团队共同提供反馈，也可以借此会议跟其他team的成员交流。
-
Code Review会议: 每个team单独进行，每天发生一次。同时每个team有1个人参加另一个team参加，这样保证如果在技术上两个team有交叉，那么可以由这个人指出。
-
Refactor会议：团队所有开发成员，每个迭代发生一次。团队的技术决策是整个team一致的，是不受业务影响的，所以每个开发成员都要对正在发生的技术变革有感知，要在这个会议上提出想法，承担行动。
这种模式有很明显的团队边界，虽然可以周期性轮换少数团队成员去其他团队，但是整个大团队的凝聚力会下降。另外，团队中的开发成员有技术栈偏向，会出现Team A紧缺前端开发，然而Team B前端资源空闲的状态，这时不容易再去调配两个team的资源，因为开发team各自比较独立，会有业务上下文不足和团队融合上的顾虑。
为了消除小团队间资源供需不平衡的状态， 探索出了维持大团队的模式。
在上图中，业务团队的结构保持不变，每组业务人员都负责一部分业务功能，并与另外一组保持紧密沟通。但是在开发人员上，没有team的划分，而是根据业务功能进行短暂的划分。在每个迭代中的故事卡，都有自己归属的功能。功能块有大有小，可以按照故事卡总点数和资源需求情况给功能块分配开发人员。
功能块所需要的时间应该控制在一个迭代之内，如果预计工作量会超过一个迭代的话，就需要把功能块做进一步的拆分，或者把不同功能块拆分到两个迭代中。
在上图中，功能块中的人员颜色是有区别的，是想表达成员在完成一个功能块之后，可以参与到其他未完成的功能块中，也可以参与到新的功能块中，即开发人员是流动的，不会一直只与同一个人，或同几个人在同一个功能块中。
在这种模式下的scrum和XP活动的改变：
-
站会：每个功能块派出一个人来同步这个功能块中每张卡的进度。这时，站会更偏向于根据功能块更新进度，而不是根据功能卡更新进度，会节约大量站会时间，并且不会让听的人太快切换业务上下文。
-
Sprint Planning Preparation会议：由产品负责人按功能块组织这个会议，如果多个功能块的业务上有交叉，可以组合在一起开。这样开发人员只对自己当前的功能块熟悉，在估点会议上节约了很多时间，但是在sprint planning会议中要集中注意听这个迭代所有的故事卡，并分析自己要开发的功能是否跟其他功能有依赖。
-
Sprint Planning会议：同上个模式一样，在planning会议上需要由产品负责人把所有功能块的卡讲述一遍，然后团队共同决定把哪些卡放入sprint backlog中。
-
Code Review会议: 分技术栈组织，例如不同功能块的所有后端开发。这个会议可以弥补开发人员在其他功能块上业务缺失严重的问题，同时可以保证后端开发在代码认知，代码风格，代码结构上的一致。
这种模式可以很好的解决多模式下开发资源供需不同的问题。同时，也能避免scrum会议超时。团队凝聚力也会因为人员的流动性而削弱团队边界感。
Conclusion
在团队超大的时候，我们依然在寻求更严谨的scrum形式，探索scrum的活动可以产生的变形，多团队和维持大团队分功能块开发这两种模式都是我们执行过的。在初期按照小团队的scrum形式来执行所有的scrum活动时，团队中有很多的抱怨声音，也感到大家在超长的会议上筋疲力尽，这两种模式是我们探索出让大多数人可以更舒服的模式。虽然这两种模式都缺乏时间的考验，和更多的实验，但他们确实在项目扩张上帮助到了我们，也希望给大家以参考。
Reference
[1] 硝烟中的Scrum和XP - Henrik Kniberg
