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
评论