听听这篇文章的音频版本

无论你是在一家小型初创公司工作，还是在一家大公司开发新产品, you are likely to come to a point when you have too many people in one team. 尽早识别这些迹象将使您避免进入团队最低效的阶段.

Every product is different and so are the teams working on them. 因此，拆分团队还需要您根据自己的情况做出一些决定. 需要考虑的事情有:

• 当团队成员不再一起工作时，如何保持专有技术的完整性
• 应该沿着函数拆分吗.g.，前端及后端团队)?
• 新团队应该有单独的待办事项吗?
• Should the product management team grow accordingly?

你应该什么时候开始创建第二支团队?

当你的预算增加时，最明显的迹象就是开始考虑拆分团队或增加一个新团队. 这可能会出现在创业公司的新一轮投资或企业产品的新目标中. If the budget increase is so substantial that your team will grow 3x or more, 那么很显然，你将不得不拆分当前的团队来分发专有技术. 然而, 当预算增加是渐进式的，你最终会在花名册上增加一些新成员时，决策就变得不那么明确了. 如果你计划将团队从7人扩大到11人，是否需要拆分? 敏捷促进了小团队，但它也促进了个人和交互，而不是过程和工具. 拥有两个或更多的团队不可避免地会创建更多能够同步工作的流程.

专家怎么说?

Jeff Bezos, the founder of Amazon, has been using the 双比萨规则 对于会议和团队. 这意味着每个披萨的人数应该只够两个披萨在午餐时吃完的人数.

的 Scrum指南 建议典型的scrum团队规模在3到9个团队成员之间，他们实际执行sprint待办事项安排. 这意味着你不会包括 产品负责人 or scrum master in the total unless either of them is implementing the sprint backlog items.

这些数字似乎有直观的意义，但背后也有一些数学. 如果你考虑一个团队，每个人都像一个节点，他们连接到其他节点. 的se are the interpersonal relationships between teammates. 的y can be friendly, competitive, spiteful, or caring. Whatever the relationship is between two people, it still a link that requires some mental capacity from each person. 随着Scrum团队规模的增长，这些链接的数量并不是线性增长的. 的 formula for links between nodes is \(n(n-1)/2\). 以下是链接增长图表:

这张图表从数学的角度清楚地说明了为什么团队规模不太大时运作效率最高. 如果我们把Scrum指南建议的3到9个团队成员作为Scrum团队的平均规模, 我们最终得到3到36个链接. If we grew to 15 people, we would have over 100 links. 这样的一个小组只有在其职责非常明确和很少重叠的情况下才能有效运作，或者有一些非官方的小组. Neither is the case or desired when working based on 敏捷原则.

团队变得太大的迹象

每日例会

有时被称为每日脱口秀, 每日scrum是整个团队的一次聚会，讨论sprint的进度和障碍. Scrum指南建议将这些时间设定为15分钟，这是衡量Scrum团队最大规模的一个很好的试金石. If you start noticing that your team is overrunning the 15-minute bar, 然后它可以表示两种情况之一:

• 每天的会议效率不高. 人们太注重细节了. 或者没有明确的发言顺序，队友发言需要时间. 也许产品负责人或scrum管理员利用每日scrum作为提供各种与sprint无关的更新的机会.
• 这个团队太大了. 如果每天的会议是有效的, 但你还是超过了15分钟, then you might simply have too many people on the team. 你还应该开始注意到，人们正在失去兴趣，因为一个人能接受的信息是有限的. 如果太多人提供更新, 跟踪每个人的进度和了解团队的状态变得很困难. 这使得人们只关注自己的进步，而不是寻找机会帮助别人.

梳理和冲刺计划

梳理和冲刺计划都是与分解用户故事并估计其交付时间或规模相关的活动. While having more people can help the team arrive at better decisions, having too many people might drive the team to a deadlock. 总是有不同的方法来完成同样的任务，每一方的争论数量随着团队人数的增加而增加.

与每日scrum一样，不要将低效的计划会议与团队规模过大混为一谈. 最终，它是 Scrum管理员的工作 to make the scrum ceremonies be efficient and effective.

回顾

回顾期间, 团队成员可以解决任何争论或冲突，并提出改进工作流程的方法. 回顾教会了我们妥协的艺术，因为它让我们在不同的各方之间寻求共同点. 一个团队有多强大，它的成员就有多愿意在分歧上妥协.

然而, 和冲刺计划一样, 太多的团队成员会产生太多的链接, 所有这些都是潜在的冲突点. 开始注意你是否在回顾中发现越来越少的共同点. It may be a sign that the team is too big and would benefit from being split.

如何分割团队

On its face, splitting the team is a relatively easy task. 将团队成员分成两组, make sure each has similarly experienced people, 并为新团队定义目标. 然而, 有很多事情需要考虑，这些事情可能会对新车队未来的成功产生重大影响.

团队士气

Probably one of the most important things to keep in mind is team morale. 在一天结束的时候，团队中的人将不得不在新的组合中工作. If the team is mature in terms of 敏捷原则, then they should be able to make the split themselves. 这是最理想的结果，因为团队成员最清楚他们的内部关系——谁与谁合作最好，谁可以从单独的团队中受益.

跨职能团队

Scrum提倡跨职能团队“拥有创建产品增量所需的所有技能”.” This holds true when scaling to two or more teams. 对于很多开发者来说, 特别是如果他们是敏捷的新手, the natural tendency is to think alongside technical lines. For example, teams often want to split into the back-end and front-end teams. This might make sense in some rare occasions but as a 产品经理, you should advise against it most of the time. 一个由前端人员组成的团队无法单独交付产品增量，自然会开始更多地考虑技术能力, 是什么把他们联系在一起的. 相反，他们应该关注客户以及如何满足他们的需求.

Another interesting consideration is the non-development roles in the team. 在各种情况下，团队可能包括设计师、业务分析师或QA专家. 一旦你分裂了一个团队, especially if you are not hiring too many new people, a dilemma arises regarding what to do with these roles. 他们应该把时间分配给不同的团队吗? Should you hire new people, who would be dedicated to one team only? Should they work with the development teams or be part of the product team?

对于这一点，确实没有一个好的建议，因为每个产品都是如此不同. 的se decisions are best made together with the team, keeping in mind that you might need to course-correct along the way.

团队应该有单独的待办事项吗?

如果一个团队分裂了, 那么很自然的问题是，他们是应该处理相同的待办事项，还是应该有不同的待办事项. 我们可以看看 规模化敏捷框架 为指导.

Scrum@Scale

Scrum@Scale is a methodology developed by the creator of the Scrum指南. Scrum@Scale不是很规范，也没有具体概述如何处理产品积压. 然而，它确实指出了两点:

• 的 team-level process is the same as laid out in the Scrum指南.
• 产品负责人组成产品负责人团队，在那里他们创建一个统一的待办事项列表. 这样做是为了避免重复工作，并在公司内部创建可见性. 同时，团队有各自的待办事项列表，这些待办事项列表从统一的待办事项列表中提供条目.

因此，实质上，Scrum@Scale将新团队与各自的订单和待办事项映像到一起. 它只是增加了一些额外的结构来协调团队之间的工作. Scrum@Scale与几个一起使用效果最好, 数以千万计, 或数百个团队，但即使您与两个团队合作，它也可以提供一些有价值的见解.

大规模Scrum (少)

少 promotes an interesting approach to the product backlog. In 少, a product owner works with two to eight teams. It might seem impossible for one PO to work with so many teams. 少的理念是，PO在抽象层次上工作，并将产品待办事项列表项细化的责任委托给团队. 在这种情况下, 跨职能开发团队还应该包括业务领域知识，以便能够交付产品增量. 在少中，只有一个待办事项.

如何跟上时代

对于产品经理来说，多个团队意味着更多的跟踪进度和响应查询的工作.

优化会议

If you were attending the daily scrums of a single team, continuing this habit will most likely be unproductive. 把每天的scrum看作是一个了解团队情况的机会，并提醒他们你可以参加讨论.

您参加sprint计划会议的情况将取决于团队的成熟度. 如果团队中有很多新面孔，或者他们没有使用敏捷很长时间, then some guidance from your side will be necessary. Even if you feel confident in letting the team plan without your attendance, 确保在团队制定计划的过程中，如果有任何问题出现，你可以去拜访或与他们进行语音聊天.

Sprint审查仍然是你的首要任务，所有的审查都应该参加. Sprint评审是一个从任何当前涉众和团队本身获得第一手反馈的机会. It’s a time when assumptions are validated and it should not be missed.

更多地参与Scrum master

While you might be reducing your engagement with some of the scrum ceremonies, you should double down on your partnership with the scrum master. 的re might be more than one now after the team split, 在这种情况下, 你需要与他们所有人密切合作.

确保你可以信任他们，让他们诚实地看待团队的进展和在冲刺期间出现的任何问题. 这些关系将使您保持最新状态，而无需参与所有scrum仪式.

引入Scrum中的Scrum

有时被称为meta scrum, scrum of scrum是一种新的仪式，通常随着scrum过程规模的扩大而引入. It is a replica of the daily scrum at a higher level. 每队指定一名大使, 所有这些人每天都在scrum的scrum中会面，讨论进展和障碍. 此仪式还用于突出可能需要解决的任何跨团队技术问题.

考虑扩大产品团队

如果你的scrum设置要求产品经理积极参与到团队中, consider adding more people to the product side. 有几种方法可以做到这一点.

初级产品经理. 一种方法是让自己担任更具战略性的角色，同时增加初级产品经理来处理一些日常琐事. 的y could take on some tasks like quality assurance (QA), 为用户描述编写规范, or creating high-level mockups for new features.

业务分析师. 另一种方法是让一个或多个业务分析师在团队中或与团队一起工作. 产品经理可以与业务分析师一起确定产品假设，然后让业务分析师通过研究或新功能找到验证这些假设的方法.

结论

随着团队的成长, you are likely to start noticing some signs that it is becoming too big, 特别是在:

• 每日例会. 如果你在每天的会议中超过了15分钟的时间框架，并且发现人们开始失去兴趣.
• Sprint计划. If you end up in deadlocks during sprint planning more and more often.
• 回顾. 如果您开始注意到在回顾期间达成妥协变得越来越困难.

All of these point to the fact that you might need to split the team. 拆分团队似乎是一件简单的事情，但它也会产生持久的后果，每个产品经理在这样做时都要考虑以下几点:

• 团队士气. 在理想的情况下, 你应该让团队决定他们想要如何分裂，以尽量减少破坏良好工作关系的数量.
• 跨职能团队. 团队 should have all the skills necessary to create a product increment.
• 产品待办事项列表. Decide if your teams will have separate or a single unified backlog.

Keeping track of two or more teams will require you to prioritize. 一个高效的产品经理应该计划如何与新团队保持同步:

• 优化会议. 思考一下哪些敏捷仪式值得你花时间，哪些可以忽略.
• 与scrum管理员交流. Use scrum masters as your team proxies and gather information from them.
• 扩大产品团队. 添加一些人与你一起工作，帮助你完成日常重复性任务或进行用户研究和市场分析.

通过使用这些建议，你应该能够有一个清晰的团队划分. 如果你的团队不断壮大，你将在未来增加更多的团队, 你应该读一下 规模化敏捷框架, which provides structure and process suggestions for 大规模敏捷.