专家建议:以特性团队扩展敏捷项目
- - InfoQ cn敏捷实践在由 5到9个人组成的小型团队里面实施得很好. 但是如果客户希望得到更多的软件功能,并且准备好了为之付出更多的钱,又会如何. 你如何能够安全地增长敏捷团队的规模,从而提升生产率. Martin Fowler警告了 未及成熟就增长敏捷团队规模的行为,因为那可能会导致沟通的破坏,而且可能会破坏代码库本身的内聚性.
敏捷实践在由 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
译者 金明 是ThoughtWorks咨询师,SCJP,系统分析师。关注敏捷方法学,特别是敏捷实施和项目管理的实践。