敏捷团队的大小

在大型团队中运用敏捷已经是一个现实——旧的“敏捷 = 小团队”的等式不再成立。虽然如此，团队的大小仍然是一个问题。团队的大小有多重要？有什么是我们应该注意的？我们又应该怎么做？

当有人提出团队的大小应该在 6 个人到 24 个人之间时， ScrumDevelopmentList 上引发了一场有趣的讨论：

分解团队——根据不同的情况，团队规模应该在 6 个人到 24 个人之间。 什么？Scrum 的建议大小是 7 个人加减 2 个人。这个不是 Scrum 论坛吗？

随后的口舌都围绕在 Scrum 和团队大小的定义。尘埃稍定之后，Roy Morien 提出了他的意见和问题：

Scrum 强调定期的短会、协作活动、“信息发射器（information radiators）”等等，凭着这些 Scrum 在相当程度上克服了这个困难，至少在哲学理论上如此。但单凭 Scrum 本身无法完全克服大型团队的难题。这个问题已经延续了数十年……James Martin 十多年前就提出过“SWAT”（如果我没记错的话，这个词代表 Specialists with Advanced Tools，拿着先进工具的专家）团队的概念，这是一种人数很少的团队……5 个或者 7 个人左右，它强调的就是小型和高效。

在我看来，更有价值更有意义的讨论应该是关于敏捷方法和敏捷项目管理方法在“放大”到大型团队和大型项目上的能力。或者更确切地说，应该是当采用敏捷方法时，最佳的团队大小，多个团队共同完成一个项目的可行性及其中的困难。

那么……直接的问题……最佳的团队大小是多少（先不管那些 Scrum 官僚的规定）？Scrum 是否能够被放大，运用到更大的团队？如何在多团队的环境中运用 Scrum 的原则和实践？有没有任何研究、实验、真人真事或者出版物可以为这个问题的答案提供证明？

目前在 ScrumDevelopmentList 上还没有直接的答案。 Tom Scott 在博客中提到了 Dave Thomas 在 Spa 2007 上的演讲，Dave 的演讲涉及了这个问题：

[“小团队如何完成大项目？”这个问题的] 答案是什么？将大项目分解成若干独立的小项目。这不是什么令人惊讶的答案。不过如何组织工作和安排项目的问题仍待解决。今年早些时候我参加了 Spa 2007，在会上 Dave Thomas 给我们勾勒了一个方法。

目标是让项目有自由空间去创造出特定问题的解决方案，以及协调项目之间的活动。其方法是将工作组织成四个阶段：

• 预想（Envisioning）
• 定义（Definition）
• 开发（Development）
• 发布（Release）

另外，Pascal Pratmarty 在他的博客上谈到了《低效率与大型团队》

团队的扩张什么时候才是有利的？我们真的需要大型团队来处理大型项目吗？

太多人喜欢用开发团队的人数来衡量一个软件项目的重要性，这个事实令我感到悲哀。

更多人当然意味着更多潜在的脑力，但要想发挥这些潜力也更加困难。实际上，我注意到在人数众多的团队中常见的两个毛病，沟通不畅和缺乏动力。

小型团队比大型团队效率更高也更具生产力，这已经是一项共识。但大型团队仍然被用在需要产生大量代码的场合，因为小型团队没有能力应付这么大的代码量——或者，真的是这样吗？

查看英文原文： Agile Team Size