其实在刚看到这个问题的时候，并不知道什么是特性团队什么是组件团队。后面查了他们对应的英文名称，才恍然大悟。特性团队对应的应该是Feature team，组件团队对应的是compenent team.
特性团队是长期存在的，跨功能的，跨组件的团队，该团队可以一个接一个的完成许多端到端的客户特性。敏捷的一个Scrum Team就是一个典型的特性团队，因为这个团队可以完成端对端交付。而组件团队则不同于特性团队，他是一个聚焦于一个产品的特定组件或者领域的团队，组件团队是分工协作的产物。比如前端团队、后端团队；比如开发团队、测试团队、运维团队等类似的划分。我们转型前就是这种传统的team。
特性团队的利：
1、 最小化团队之间的依赖关系以增加灵活
2、 快速响应变化，快速迭代，能更好的评估设计决策的影响：端到端的开发，可以直接面对客户，了解客户的需求，以便生产出客户所需的产品
3、 用户价值导向，减少因为交接而产生的浪费
弊：
1、 要求熟练的工程实践和方法、工具
2、 传统组织当中人仍然归属于部门或工作组，更关注日常的kpi考核指标，对特征团队的认可和配合程度会有一定程度的折扣
3、 要求团队成员T-shape,不仅仅是关注自己的专业，而要为了满足团队整体的交付而拓展知识领域的宽度
组件团队的利：
1、 清晰的个人职责，长期稳定的团队、其由组件作为边界来决定的职责简单而明确
2、 团队内部交流快，且容易培养单一技能专家：
3、 组织级别-组件共享：一个团队组件可供多个团队实用，减少相同功能多次开发的情况。
弊：
1、 为交付最大数量的代码行进行优化，而非价值
2、 “瀑布式”开发，风险滞后
3、 主要基于现有的专业知识，较低水平和动力去学习新技能，同时，团队自身职能单一，限制了团队成员发展。
我们目前的组织采用的是两者结合的方式，既考虑业务交付，又考虑人员发展。
