专家建议：以特性团队扩展敏捷项目

敏捷实践在由 5 到 9 个人组成的小型团队里面实施得很好。但是如果客户希望得到更多的软件功能，并且准备好了为之付出更多的钱，又会如何？你如何能够安全地增长敏捷团队的规模，从而提升生产率？

Martin Fowler 警告了未及成熟就增长敏捷团队规模的行为，因为那可能会导致沟通的破坏，而且可能会破坏代码库本身的内聚性。

因为新加入的成员不理解当前的代码库如何工作，所以他们以不一致的方式去做一些修改——例如引入一个竞争性的框架，这时就会导致 代码库内聚性的破坏。如果太多的新人加入，团队的领袖无法保持对整个代码库的监控，代码库越来越滋生更多问题。这些问题又互相恶化，因为没有人能够找到一 致的方式进行修改。

Martin 建议从小型团队开始，缓慢地增长团队规模。

从其他做过大型项目（超过 50 人）的人那里，我得到的最为坚定的建议之一是项目应该始于小规模——或许只是十来个开发人员。他们应该通过构建早期的部分，弄清楚系统核心的设计元素与交互。只有当设计被明确下来，才应该考虑增长团队规模直至完整。

Esther Derby 讨论了超越 Scrum of Scrums 的实践，可能会有助于扩展团队。

• 只要可能，就尽量围绕着场景的边界来组织团队，而不是组件的边界（场景可能是一个特性集，例如销售系统中的“订单”）。
• 使跨越场景的沟通公开化。使用集成团队以在接口处理与系统集成上达成一致。集成团队应该编写验收测试，以确认跨越边界的集成。
• 设置“组件守护者”——他们的目的是审查代码与指导团队，以维护组件或共享服务的完整性。
• “技术委员会”（由集成团队成员、组件守护者以及测试专家组成）应该专心于整个系统的完整性。

James Shore 建议基于精益原则“单件流”，创建高效的工作单元。

精益工作单元通过同步流，几乎完美地契合了敏捷中跨越职能、一地办公团队的理念。不同于阶段式的流程——由组到组（需求、再设计、再编码、再测试）一环一环地移交职责，敏捷团队一次承担一个或两个特性的责任，整个团队作为整体工作于其上，直至特性完成。

Siddharta Govindaraj 提议了一则名为特性团队的类似方法，并举了一个可行的团队组建案例。

假定有一个尚未开始的新故事。来自主干团队的小组成员将决定谁想要这个故事的特性团队的一员。在最简单的情形下，这个特性团队会 包括一个或两个开发人员以及一个测试志愿者。你们可以在 sprint 的开始阶段，或者之后及时（JIT）做出这个决定。一旦组成特性团队，他们就有责任共 同努力，交付故事。一旦交付，特性团队就会被拆散，每个团队成员会选择一个新的故事，加入了一个新的特性团队。

在敏捷团队规模增长的时候，哪些实践让你从中受益了呢？

查看英文原文： Experts advise growing Agile projects with feature teams