无论你在小型创业公司工作还是在大公司的新产品线工作，当团队人数越来越多时总会达到一个临界点。尽早识别这个临界点可以让您的团队避免进入低效阶段。
每个产品都是不同的，团队合作也是如此。因此，拆分团队也需要做一些反映团队情况的决定。
在做决定时有以下几点需要考虑：
团队不在一起工作时如何确保专业知识的完整性？是否应该按职能划分？（如：前端团队和后端团队）新的团队应该有单独的backlog吗？产品管理团队是否应该相应增长？
什么时候开始创建第二个团队？
开始考虑团队拆分或增加新团队最明显的迹象就是团队的预算增加，这可能发生在创业公司的新一轮投资或企业产品的新目标中。
如果预算增加较多你的团队规模会增长3倍甚至更多，这个时候你就不得不拆分现有的团队以延续原有的技术知识。
然而，当预算增加呈递增式时，你的决定就变得没有那么明确，最终的结果就是在名册上增加一些新人。
如果说，你计划将自己的团队由7个人增加到11个人，需要做拆分吗？敏捷提倡小团队，但也同样提倡个体和互动高于流程和工具，拥有两个或以上的团队必可避免的要创建更多流程以便能够同步工作。
专家怎么说？
亚马逊创始人贝索斯曾将两个披萨原则用在会议和团队中，那就意味着无论是会议还是团队应该只有两个披萨可以喂饱午餐的人数。
Scrum指南建议有3到9名成员实际执行sprintbacklog，这就意味着总数中不可能包含PO或者ScrumMaster，除非他们他们当中有人在执行sprintbacklog项。
这些数字看起来更有直观意义，但他们背后也有数学原理。如果将团队中的每个人都看做一个节点，并将他们链接到其他节点。这就是队友之间的人际关系。
他们之间可以是友好的、竞争的、恶意的或者关怀的，无论两人之间的关系是什么，都需要每个人有一定的心理承受能力。
随着团队人数的增长，这些链接之间的数字不会呈线性增长。节点之间的链接公式，如下图的链接增长图所示：
图表从数学角度清楚的说明了为什么当团队规模不是特别大的时候能实现运营效率的最大化。
如果我们遵从Scrum指南的建议采用3到9人的团队规模人数，最终的链接值为3到36。如果把团队人数增加到15人，链接值将超过。
这种规模的团队只有在团队中每个人的责任定义都非常明确且很少重叠或者一些非官方的小组才能有效运营。基于敏捷原则工作时既非案例也非期望。
团队变大的信号
1.每日Scrum
每日Scrum是整个团队的聚会，用于阐述sprint进展和遇到的困难，有时候也被称为每日站会。
Scrum指南建议每日站会要在15分钟内完成，这个时间限制对团队规模来说是很好的试金石。如果你注意到自己的团队开始超过15分钟线，那么可以表明两件事：
站会效率较低。大家陷入太多细节当中。或者没有明确的发言顺序需要团队成员轮流点名。也有可能PO或ScrumMater利用站会时间提出与sprint无关的各种更新。团队规模过大。如果站会效率很高，但是你的团队开会时间仍然超过15分钟，那就很有可能是你的团队人数过多导致的。你还应该注意到团队中的一些人，正在逐渐失去兴趣因为一个人可以接收的信息量是有限制的。如果太多人提供更新，那么跟踪每个人的进度并了解团队的状态就会变得很难。
这使得人们只会向内看，只看到自己的进步而不是寻找机会去帮助他人。
2.梳理和Sprint规划
梳理和迭代规划都是与分解用户故事和预估交付时间或规模大小有关的活动。
虽然有更多的人可以帮团队做出更好的决策，同样的拥有太多人也容易让团队陷入僵局。
同一任务可以由不同的方法来完成，并且每一边的论点数量都会随着人员数量的增加而增加。与站会一样，不要把低效的计划谈话与团队规模过大混淆。
最终，让scrum仪式变得更高效且有效是scrummaster的工作。
3.回顾
在回顾会议期间，团队成员可以解决任何争论或冲突并提出改善其工作流程的方法。回顾会议教会我们妥协的艺术，因为它让我们在不同团体直接寻求共同点。团队也因为它的成员愿意在他们的分歧上适当妥协而变得强大。
然而，和sprint规划一样，团队成员过多那么链接点也会很多，所有这些链接点都是潜在冲突。
如果你在回顾会议时发现大家的共同点越来越少的时候你就应该开始注意，这很有可能是由于团队规模过大，团队拆分是最佳选择。
如何拆分团队？
表明上看，拆分团队是一个相对简单的任务。将团队成员分成两组，确保每组中都有相似经历的成员，明确新团队的目标。
然而，在拆分团队时还有很多因素需要考虑进去，以免影响团队以后的成功。
1.团队士气
需要时刻牢记的最重要的事情之一就是团队士气。一天结束时，团队中的成员将不得不在新的组织架构中工作。
如果团队在敏捷原则方面是成熟的，那么他们应该能够自己分裂。这是最理想的结果，因为团队成员最了解他们的内部关系——谁与谁关系最好以及谁能从分离的组织中收益。
2.跨职能团队
Scrum推动跨职能团队“拥有创建产品增量所需的所有技能”，扩展到两个甚至更多团队时也是如此。
对于很多开发者尤其是一些敏捷新手来说，自然趋势是与技术线路一起思考的。
例如，团队经常想将拆分成前端和后端。这在某些罕见的情况下可能会有意义，但作为产品经理，你应该在大多数时间提出反对意见。
一个全是前端开发者的团队无法自行提供产品增量，并且自然地就开始思考技术能力也就是将他们团结起来的原因。相反，他们更应该
转载请注明地址:http://www.1xbbk.net/jwbls/5231.html
