功能特性团队的五大优势

阅读数:1811 2009 年 12 月 17 日

话题:敏捷精益文化 & 方法

Mike Cohn 和另外几个人展示了他们的案例,同时指出:组织软件团队,应该根据软件的“特性(feature)”而不是“组件(component)”,还说明了这样做的原因。

Cohn 回想起以前与一个从事视频游戏开发的客户合作的经历。那家公司就是围绕组件组织开发团队,这让他们开发出来的游戏“武器不足以杀死怪兽,颜色过于昏暗,玩家看不清秘密通道,而其中的障碍让最耐心的玩家也难以忍受。”

他通过这个故事来建议实施敏捷的公司采用“基于功能特性来划分团队”的方式:团队负责开发端到端的功能,而不是“软件组件”。他继而总结了基于功能特性划分团队的 5 大优势

  • 功能特性团队能更好地评估设计决策的影响。” 实现端到端的功能可以来收集真正有用的反馈:用户的要求 / 需求是不是很好地被满足了;而贯穿整个架构的工作可以检验内部的 / 技术方面决策的产出。
  • 功能特性团队可以减少因为交接而引起的浪费。”指望通过交接传递信息会带来风险,基于组件的团队可能不能满足其他组件团队的需要,或者提供的组件可能根本不是人家真正想要的。
  • 它能确保总是让合适的人去讨论问题。”基于功能特性划分的团队可以营造一种每个人相知相容的环境,让大家都处于价值链中。
  • 组件团队给项目日程带来风险。”所有组件团队的产出必须整合在一起,这样才能得到有形的价值。要计划这种活动是很困难的,因为这依赖于来自不同团队的未知信息。
  • 它能让大家关注于需要交付的功能特性。”让团队能在每个迭代结束的时候能交付“可工作的软件”,这是敏捷的核心。功能特性团队能帮助每个人时刻把这一条放在首位。

最近,对于功能特性团队最有名的佐证是来自于 Bas Vodde 和 Craig Larmen 合著的《Scaling Lean & Agile Development》一书。Mike Cottmeyer 在他的文章中这么说道:

Larmen 和 Vodde 总结认为:理想的功能特性团队是应该跨职能、跨组件以及同地协作的。团队开发完整的用户功能,一般由 6 到 8 名具备通用技能、同时各具专长的人组成。换句话说,这就是我们 Scrum 团队的原型。

【Larmen 和 Vodde】同时也指出了功能特性团队所面临的几大挑战... 对于这点我非常感谢他们。常见的障碍包括... 代码的并发访问、共享设计责任、学习新技能的难度以及公司组织结构。他们认为:通过一些现代的工具,这些挑战还是能被克服的... 但这需要时间。

就在这篇文章中,Cottmeyer 也提到出了来自 Dean Leffingwell 的截然相反的意见,Leffingwell 在他的《Scaling Software Agility》一书中力挺组件:

组件团队【Leffingwell 推荐】跟功能特性团队【Vodde/Larmen 以及 Cohn 推荐】有很多共同属性,包括团队规模不大、同时团队包括了成功交付 user story 所必须的技能。Leffingwell 提到的组件团队是被充分授权的、自组织、自我管理的团队。简而言之,他们是典型的 Scrum 团队。但是,有个很大的不同,他们面向的是组件的功能特性,而不是最终用户所要的功能特性。

Leffingwell、Cottmeyer 以及 Vodde 还在文章的评论栏进一步展开讨论,分享他们的见解

之前关于团队结构的一些讨论,包括对功能特性团队的其他观点,请参照之前 InfoQ 的文章

查看英文原文:Five Benefits of Feature Teams