团队为什么不能太大？
之前在看敏捷实践的相关书籍时，都会说敏捷团队的人数不能太多，最好控制在9人以下，一般一个团队是由5到9人组成。如果人数太多的话，会导致整体的效率降低。在看书的时候不以为意，但是真正到实际应用场景中，才明白当团队大了给团队造成的问题。最近我所在的项目在高峰时刻人数达到了敏捷团队原则的3倍。因为人数的问题，给团队造成了很大的沟通成本。
一、会议效率低
在我们的日常敏捷实践中，会有几个常见的会议：每日站会、迭代计划会议、代码评审、迭代回顾会议。当人员太多的时候，会议的沟通效果则会变得比较差。
以每日站会为例，通常大家的做法是站在物理看板前进行站会。当团队太大时，一个物理看板前站不下全部的团队成员，势必会造成一些成员站在看板外围，这样会影响成员对站会的关注度。另外当物理区域变大时，则需要每位成员更加大声的去表达自己所要叙述的内容才能确保每个人听到。在迭代计划会议时，人数太多则比较不容易对卡的点数达成一致意见。需要经过多轮次的讨论才能对某一张卡的描述以及点数达成一致。所以每次的迭代计划会议，经常会开很长的时间。
二、不能照顾到每位成员
在项目管理中，对人的管理是项目经理的一项重要工作，需要经常掌握每一位项目成员的工作情况、遇到的风险或者问题。但当项目成员较多时，团队的管理者没有精力完全照顾到每位成员的工作和思想情况。很有可能在某位成员的问题爆发出来之后，才意识到之前的隐患没有兼顾到。
三、成员的同伴压力过大
同伴压力是指因害怕被同伴排挤而放弃自我做出顺应别人的选择。 团队成员在某个决策面前，当分别有1个人、5个人、20个人和自己的想法不一致时，会因为不同的同伴压力而做出不同的选择。当面对20个人与自己的想法不一致时，有可能就不会提出自己真实的想法，这对于团队想要做高质量的交付来说真的不是一件好事情。
团队太大时，该如何做？
一、划分小组
小组其实就是我们常说的stream，我们一般会按照业务模块进行小组的划分。每个小组负责一个对应的业务流，这样能够保证业务的延续性。我们在划分小组的时候就可以按照敏捷团队的大小去划分，一般控制在5个人左右，因为加上PM、TL和UX这样通用的角色后，小组人员最好要控制在10人以内。
二、寻找关键角色
当PM和TL无法关注到项目组的每个成员时，则需要在团队中寻找关键角色，在节省效率的同时还可以发展团队中的第二梯队。每个小组中的BA是需要关注的关键角色，BA对于团队的开发进度、每个成员的做卡情况都是非常了解的。另外就是小组中TL的backup，在团队组建后，需要尽快识别小组成员的能力，以便准备TL的backup，并且在团队活动中给予其关注及相应的支持。
当然，最好的解决办法就是不要让团队那么大。但是在实际的项目中，我们不得不面对这样的现状，只能尽可能的想办法去对这样的团队进行一个拆解，以便更好的进行敏捷实践。
