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

敏捷实践在由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

This entry was posted in Best Practices. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s