规模太大——最佳 Scrum 团队规模指南

收听本文的音频版本

无论您是在小型初创公司工作还是在大公司开发新产品，您都可能会遇到一个团队中有太多人的情况。 尽早识别迹象将使您免于进入团队中效率最低的阶段。

每个产品都是不同的，开发它们的团队也是如此。 因此，拆分团队还需要您做出一些反映您的情况的决定。 需要考虑的一些事项是：

• 当队友不再一起工作时如何保持专业知识的完整性
• 您是否应该按职能划分（例如，前端和后端团队）？
• 新团队是否应该有单独的积压工作？
• 产品管理团队是否应该相应成长？

你应该什么时候开始创建第二个团队？

开始考虑团队拆分或添加新团队的最明显迹象是您的预算增加时。 这可能发生在初创公司的新一轮投资或企业产品的新目标中。 如果预算增长如此之大，以至于您的团队将增长 3 倍或更多，那么您将不得不拆分当前团队以分配专有技术，这是不言而喻的。 然而，当预算增加是渐进式的并且你最终在名册中增加了一些新人时，这些决定就变得不那么明确了。 例如，如果您计划将您的团队从 7 人增加到 11 人，那是否需要拆分？ 敏捷促进了小型团队，但它也促进了个人和互动，而不是流程和工具。 拥有两个或更多团队不可避免地会创建更多能够同步工作的流程。

专家怎么说？

亚马逊的创始人杰夫·贝佐斯（Jeff Bezos）一直在为会议和团队使用两个披萨规则。 这意味着每个人在午餐时应该只有两个比萨饼可以喂饱的人数。

Scrum 指南建议让 3 到 9 名团队成员实际执行 sprint backlog。 这意味着您不会将产品所有者或 scrum master 包括在总数中，除非他们中的任何一个正在实施 sprint backlog 项目。

这些数字似乎很直观，但背后也有一些数学原理。 如果你考虑一个团队，每个人都像一个节点，他们连接到其他节点。 这些是队友之间的人际关系。 他们可以是友好的、有竞争力的、恶意的或有爱心的。 无论两个人之间的关系是什么，它仍然是一个需要每个人都有一定心理能力的联系。 随着团队的发展，这些链接的数量不会线性增长。 节点之间链接的公式是 \(n(n-1)/2\)。 这是链接增长图表：

该图表从数学的角度清楚地说明了为什么团队在规模不大的情况下运作效率最高。 如果我们采用 Scrum 指南建议的 3 到 9 个团队成员，我们最终会得到 3 到 36 个链接。 如果我们增长到 15 人，我们将拥有超过 100 个链接。 只有当他们的职责非常明确并且很少重叠或者如果有一些非官方的子组时，这样的团队才能有效地运作。 在基于敏捷原则工作时，既不是这种情况，也不是所希望的。

团队变得太大的迹象

每日站会

有时被称为每日站会，每日站会是整个团队的聚会，讨论冲刺的进展和障碍。 Scrum 指南建议将这些时间设置为 15 分钟，这是对团队规模的一个很好的试金石。 如果您开始注意到您的团队超过了 15 分钟栏，那么它可能表明以下两种情况之一：

• 每日站会效率不高。 人们正在进入太多细节。 或者没有明确的发言顺序，队友发言需要时间。 也许产品负责人或 Scrum Master 正在利用每日 Scrum 作为提供与 sprint 无关的各种更新的机会。
• 团队太大了。 如果每天的 Scrums 效率很高，但你仍然超过了 15 分钟，那么你可能只是团队中的人太多了。 您还应该开始注意到人们正在失去兴趣，因为一个人可以接收多少信息是有限的。如果提供更新的人太多，就很难跟踪每个人的进度并了解团队的状态. 这使人们转向内心，只反思自己的进步，而不是寻找帮助他人的机会。

梳理和冲刺计划

梳理和冲刺计划都是与分解用户故事和估计其交付时间或规模相关的活动。 虽然拥有更多人可以帮助团队做出更好的决策，但拥有太多人可能会使团队陷入僵局。 总是有不同的方法来完成相同的任务，并且每一方的争论的数量随着团队中的人数而增加。

与每日 Scrum 一样，不要将低效的计划会议与团队规模过大混为一谈。 归根结底，让 Scrum 仪式变得高效和有效是 Scrum Master 的工作。

回顾展

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

然而，与 sprint 计划一样，太多的团队成员创建了太多的链接，所有这些都是潜在的冲突点。 开始注意你是否在回顾过程中发现越来越少的共同点。 这可能表明团队太大并且会从拆分中受益。

如何拆分团队

从表面上看，拆分团队是一项相对容易的任务。 将团队成员分成两组，确保每个人都有类似的经验，并为新团队定义目标。 但是，有很多事情需要考虑，这可能会对新团队未来的成功产生重大影响。

团队士气

可能要记住的最重要的事情之一是团队士气。 归根结底，团队中的人将不得不在新的组合中工作。 如果团队在敏捷原则方面成熟，那么他们应该能够自己进行拆分。 这是最理想的结果，因为团队成员最了解他们的内部关系——谁与谁合作得最好，谁可以从单独的团队中受益。

跨职能团队

Scrum 提倡跨职能团队“具备创建产品增量所需的所有技能”。 这适用于扩展到两个或更多团队时。 对于很多开发人员来说，尤其是如果他们是敏捷新手，自然倾向于沿着技术路线思考。 例如，团队通常希望拆分为后端团队和前端团队。 这在极少数情况下可能是有意义的，但作为产品经理，您应该在大多数情况下建议不要这样做。 一个由前端人员组成的团队无法自行交付产品增量，自然会开始更多地考虑技术能力，这是他们团结起来的原因。 相反，他们应该关注客户以及如何满足他们的需求。

另一个有趣的考虑是团队中的非开发角色。 在各种情况下，团队可能包括设计师、业务分析师或 QA 专家。 一旦你拆分了一个团队，特别是如果你没有雇佣太多新人，那么如何处理这些角色就会出现两难境地。 他们应该在团队之间分配时间吗？ 你是否应该雇佣新的人，他们只专注于一个团队？ 他们应该与开发团队合作还是成为产品团队的一员？

对此确实没有好的单一建议，因为每种产品都如此不同。 这些决定最好与团队一起做出，请记住，您可能需要在此过程中纠正路线。

团队应该有单独的积压工作吗？

如果一个团队被拆分，那么很自然的问题是他们应该处理相同的待办事项还是有单独的待办事项。 我们可以从 Scaled Agile Framework 中获得指导。

Scrum@Scale

Scrum@Scale 是由 Scrum 指南的创建者开发的一种方法。 Scrum@Scale 不是很规范，也没有具体概述如何处理产品积压。 但是，它确实注意到了两点：

• 团队级别的流程与 Scrum 指南中的规定相同。
• 产品负责人组成一个产品负责人团队，他们在其中创建一个统一的积压工作。 这样做是为了避免重复工作并在公司内部创建可见性。 同时，团队有他们单独的待办事项，这些待办事项从统一的待办事项中提供项目。

所以本质上，Scrum@Scale 用他们各自的 PO 和 backlog 来描绘新团队。 它只是添加了一些额外的结构来协调团队之间的工作。 Scrum@Scale 最适用于几个、几十个或数百个团队，但即使您与两个团队一起工作，它也可以提供一些有价值的见解。

大规模 Scrum (LeSS)

LeSS 提倡一种有趣的方法来处理产品 backlog。 在 LeSS 中，产品负责人与两到八个团队一起工作。 一个 PO 似乎不可能与这么多团队合作。 LeSS 理念是 PO 在抽象级别上工作，并将产品待办事项项细化职责委托给团队。 在这种情况下，跨职能开发团队还应该包括业务领域知识，以便能够交付产品增量。 在 LeSS 中，只有一个 backlog。

如何保持最新

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

优先安排会议

如果你参加的是单个团队的每日例会，继续这种习惯很可能是徒劳的。 将每日例会视为一个了解团队脉搏并提醒他们您可以参与讨论的机会。

您是否参加 sprint 计划会议将取决于团队的成熟度。 如果团队中有很多新面孔，或者他们很长时间没有使用敏捷，那么您的一些指导将是必要的。 即使您有信心让团队在您不出席的情况下进行计划，如果出现任何问题，请确保在他们的计划期间可以随时加入或与团队进行语音聊天。

Sprint 评审必须始终是您的首要任务，所有评审都应参加。 Sprint 审查是一个从任何当前利益相关者和团队本身获得第一手反馈的机会。 这是验证假设的时候，不应错过。

与 Scrum Master 进行更多互动

虽然您可能会减少对某些 Scrum 仪式的参与，但您应该加倍加强与 Scrum Master 的合作。 团队分裂后现在可能不止一个，在这种情况下，您需要与他们所有人密切合作。

确保您可以信任他们对团队的进展和冲刺期间出现的任何问题给出诚实的看法。 这些关系将使您无需参加所有的 Scrum 仪式就能保持最新状态。

介绍 Scrum 的 Scrum

有时称为元 scrum，scrum of scrums 是一种新的仪式，通常作为 scrum 过程规模引入。 它是更高级别的每日 Scrum 的复制品。 每个团队指定一名大使，所有这些大使每天都在 scrum of scrums 中开会讨论进展和障碍。 该仪式还用于强调任何可能需要解决的跨团队技术问题。

考虑扩大产品团队

如果您的 Scrum 设置需要产品经理积极参与团队，请考虑在产品方面增加更多人员。 有几种方法可以解决这个问题。

初级产品经理。 一种途径是为自己承担更具战略意义的角色，同时增加初级产品经理来处理一些日常琐事。 他们可以承担一些任务，例如质量保证 (QA)、为用户故事编写规范或为新功能创建高级模型。

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

结论

随着团队的壮大，您可能会开始注意到一些迹象表明它变得太大，尤其是在：

• 每日站会。 如果您在每日例会期间超过了 15 分钟的时间范围，并且看到人们开始失去兴趣。
• 冲刺计划。 如果您在 sprint 计划中越来越频繁地陷入僵局。
• 回顾展。 如果你开始注意到在回顾过程中达成妥协变得越来越难。

所有这些都表明您可能需要拆分团队。 拆分团队似乎是一件容易的事，但它也会产生持久的后果，每个产品经理在这样做时都有一些事情需要考虑：

• 团队士气。 理想情况下，您应该让团队决定他们希望如何拆分，以尽量减少废弃的良好工作关系的数量。
• 跨职能团队。 团队应该具备创建产品增量所需的所有技能。
• 产品积压。 确定您的团队是否有单独的或单一的统一积压工作。

跟踪两个或更多团队将需要您确定优先级。 一个有效的产品经理应该计划他们将如何与新团队保持同步：

• 优先安排会议。 想想哪些敏捷仪式值得你花时间，哪些可以忽略。
• 与 Scrum 大师互动。 使用 scrum master 作为您的团队代理并从他们那里收集信息。
• 扩大产品团队。 添加人员与您一起工作，并帮助您完成日常重复性任务或进行用户研究和市场分析。

通过利用这些建议，您应该能够进行干净的团队拆分。 如果您的团队不断壮大，并且您将来会增加更多团队，您应该阅读 Scaled Agile Framework，它为大规模敏捷提供结构和流程建议。