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

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

Advertisements
此条目发表在Best Practices分类目录。将固定链接加入收藏夹。

发表评论

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