BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Anand Vishwanath 关注 0 他的粉丝 ,译者 金明 关注 0 他的粉丝 发布于 2012年1月21日. 估计阅读时间: 3 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

没这么极端 by 徐 毅

可以看看《管理3.0》里Jurgen的建议,不错的。不管是职能型还是跨职能的团队,只要能够给他们的客户创造价值,那就是好的。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT