特性团队VS组件团队

在讨论敏捷开发时，经常会遇到特性团队和组件团队之争。为什么呢？因为敏捷开发推崇特性团队，实现端到端交付，而在传统组织架构里，是以组件团队来运作的，怎么样能够更好的协作，达成更高的研发效能呢？下面对这两种团队做一些分析。

特性团队：

1、特性团队能够更好地评估设计决策带来的影响。在一个Sprint结束的时候，特性团队可以构建一个端到端的功能，遍历应用程序所涉及的所有技术。

2、特性团队减少了交接带来的浪费。一个群体或个人向另一个群体或者个人交接工作是一种浪费。在组件团队的情况下，有一些风险，包括过多或者过少的开发功能或者错误的开发功能，或开发一些根本不需要的功能。

3、特性团队确保正确的人在讨论。因为跨职能的特性团队包括从想法到可以运行以及测试某一个功能所涉及的所有技能，因而能确保拥有这些技能的团队成员可以每天进行沟通。

4、组件团队会制造一些进度方面的风险。组件团队的工作只有在它被特性团队集成到产品后才是有价值的。集成组件团队的工作量必须由特性团队来估算，这些工作将发生在当前的Sprint或以后的Sprint。估算这种类型的工作量时困难的，因为这需要特性团队在不知道组件质量的情况下估算集成的工作量。

5、特性团队保持对交付特性的关注。按交付功能的方式来组织团队，而不是按照架构元素和技术，它能持续提醒S敏捷开发关注每个Sprint的功能交付。

组件团队：

这里指的组件团队，是指一个团队开发软件给项目的另一个团队而不是最终用户使用。组件团队在每个Sprint结束的时候也要交付高质量、经过测试的、潜在可交付的代码。那些因为只有开发人员的团队，开发完后需要提交给测试团队的，不能算一个完整的组件团队。

因为一个组件团队的工作需要交付给另一个团队，所以只有在特性团队要求的时候再构建组件。在如下场景下，组件团队有存在的价值：

1、组件团队要开发供多个特性团队使用的功能。当一个组件开发的功能同时提供给多个团队使用时，可以由组件团队来进行开发，也可以让一个特性团队来开发，然后其他特性团队在需要的时候进行重构和泛化这个功能。

2、使用组件团队可减少共享的专家。在一些多团队的项目中，许多团队会涉及一些专业性较强的学科，这会涉及到专家的分享。当分享太多时，将带来一些不利因素，这些专家的时间变得很零碎。这时可以考虑创建一个组件团队，提高专家的生产效率。

3、多种方法的风险大于单个组件团队的不足。如果我们选择使用多个特性团队贡献力量的方式来开发共享的组件或服务，需要避免两个风险：每个特性团第为同一个问题采用不同的解决方案；特性团队的每个开发建立在先前特性团队的基础上，这样做没有一个清晰的愿景。

4、可以促进讨论。相对于团队外部，人们更倾向于和团第内部人员讨论。组件内部人员的积极沟通，有助于形成技术类的成果。

组件团队能够带来一些好处，但是当组件完成后，应该解散组件团对，在一个大型项目中，大部分主要团队应该是特性团队。