“发展”与“扩展”不一样
- Dominic Price，“Unlearning these five fallacies will make you more innovative”（避免这五大错误让您更具创新性）
在同一个问题上增加更多的人只会使解决这个问题变得更加困难。但是，朋友们，如果您能够随着发展而变得更有效，那就是扩展。
几十年来，Scrum 指南为帮助团队和公司满足这些需求建立了基线。但是，将 Scrum 扩展到单个团队之外需要一种不同的方法。为了实现这一目标，我们创建集群 Scrum 技术（有时也称为 SoS）。
集群 Scrum 的历史
集群 Scrum 方法由 Scrum 框架的两位先驱 Jeff Sutherland 和Ken Schwaber 于 1996 年首次实施。Sutherland 和 Schwaber 都需要一种方法来协调八个业务部门，每个业务部门有多个产品线，并使各个团队彼此同步。因此，他们尝试了一种新的方法来扩展 Scrum 团队以实现这一目标。经过这次体验，Sutherland 在 2001 年发表一篇题为“Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies”（敏捷可以扩展：在五家公司中发明和重塑 Scrum）的文章，该文章首次公开提到了集群 Scrum。
从那时起，作为一种与扩展敏捷开发密切相关的实践，集群 Scrum 越来越受欢迎。集群 Scrum 提供了一个帮助团队扩展的结构，Scrum@Scale 指南对此进行了介绍，并且其他规模化敏捷框架也进行了参考。
如果您在单个团队层面上遇到 Scrum 难题，那您就无法在团队网中扩展这些练习。拉下安灯拉绳，在开始扩展前解决团队面临的挑战。
什么是集群 Scrum？
集群 Scrum 是一种规模化的敏捷开发技术，它可将需要通过合作交付复杂解决方案的多个团队联系在一起。
它通过透明度、检查和大规模调整，帮助团队开发和交付复杂的产品。当所有高绩效的 Scrum 团队成员都朝着共同的目标努力，获得信任、尊重并完全一致时，就会非常成功。
为了支持这一点，团队规模至关重要。Hackman 和 Vidmar 的研究表明，从理论上讲，4.6 人是“完美的团队规模”。规模太小或太大的团队可能难以交付复杂的产品。
记住《人月神话》（The Mythical Man-Month）一书中的布鲁克斯定律：向进度落后的软件项目增加人手，只会使项目更加落后。
团队规模越大，团队成员之间的沟通渠道就越大，这使得建立信任和实现共同目标变得更加困难。
因此，将一个非常庞大的团队分成两三个较小的团队有助于发展人际关系并保持预期的结果。
拆分团队时要注意！平衡团队间的技能、重新定义已建立的团队界面和仔细划分工作职责至关重要。可能会出现意外的依赖关系和潜在的新瓶颈，从而减慢交付速度。高度关注回顾和改进故事的优先顺序将有助于克服这些挑战。
如果创建多个团队来实现一个共同的目标，就需要进行协调。这就催生了对集群 Scrum 的需求。
集群 Scrum 的目的
集群 Scrum 是一个由代表组成的虚拟团队，具有指向原始交付团队的嵌入式链接。与典型的组织层次结构或基于项目的团队相比，这些相互关联的团队结构减少了沟通途径。目的是协调规模较小的独立团队。应用集群 Scrum 的团队不仅可以协调交付，还能确保在每个冲刺结束时提供完全集成的产品。因此，集群 Scrum 是一个能够向客户交付价值的发布团队。
组织通常使用此方法作为扩展敏捷和组织更大、更复杂产品的交付的第一步。
集群 Scrum - 规模化结构
新成立的集群 Scrum 团队采用几乎相同的实践，参与相同的活动，并且拥有与 Scrum 团队相同的角色。要在每个冲刺结束时提供可交付的集成式产品，可能需要额外的角色，如架构师或质量保证负责人。
例如，有首席产品负责人角色。首席产品负责人负责监督产品负责人团队，并帮助指导总体产品愿景。
这个角色不需要由专职人员来履行，该角色应仅在扩展方面承担与产品负责人相同的职责。
另一个新角色是 集群 Scrum 大师，该角色应该专注于其他团队可见的进度和障碍待办事项列表，推动排定优先级或消除障碍，并不断提高集群 Scrum 的有效性。
这些新角色使用 15 分钟的规模化每日 Scrum 作为关键会议，以进行调整、改进并克服障碍。每个团队或产品负责人的代表应讨论团队障碍、实现冲刺目标的风险或对其他团队的依赖性，然后讨论所发现的可供其他团队利用的改进。
结论和考虑因素
集群 Scrum 被广泛使用，是扩展 Scrum 的关键方法。扩大规模的一个重要先决条件是使团队组成正确，为团队提供足够的时间和空间，让他们在 Tuckman 群组开发模式的各个阶段（组建、冲击、规范和执行）中成长。
团队准备就绪后，以下是一些可能有用的注意事项：
- 将规模化的每日 Scrum 会议保持在 15 分钟，与您团队的每天 Scrum 一样
- 在最后一次团队每日 Scrum 结束后进行 15 分钟的规模化每日 Scrum
- 针对集群 Scrum 制定工作协议
- 就已完成的集体和个人定义达成一致并进行共享！
- 制定例行程序或日程安排，以规模化的每日 Scrum 为重点
- 开始跟踪您受困于障碍的天数
- 跟踪规模化每日 Scrum 按时启动和完成的次数
- 专注于首先提供具有依赖关系的故事，以降低风险并支持其他团队
- 跟踪和直观显示演示会议之前的几天
说实话，扩展敏捷没有所谓的正确方法。但是，许多组织使用扩展敏捷的框架在改进流程、团队和文化方面取得了巨大成功。详细了解目前使用的顶级敏捷框架，以及敏捷教练的“大规模敏捷性”部分的更多信息。
