组件团队：

基本概念：在传统的开发模式下，我们习惯于按照系统的架构模块，或者系统分层组织团队，也有的团队按照系统需求、开发、测试结合系统架构混合组织的方式。这种团队组织的方式，我们称之为组件团队，是指每个团队只是完成系统功能的某一个部件，而不是一个端到端用户可见的功能。

利：

1、团队自身-内部沟通成本低：职责多样但层次简单、团队间依赖度低、沟通（一般发生在单一团队内部）成本低；

2、团队自身-内部交流快，且容易培养单一技能专家：组件可以促进讨论。相对于团队外部，人们更倾向于和团第内部人员讨论。组件内部人员的积极沟通，有助于形成技术类的专家。

3、组织级别-组件共享：一个团队组件可供多个团队实用，减少相同功能多次开发的情况。

4、组织级别-职责明确：长期稳定的团队、其由组件作为边界来决定的职责简单而明确

弊：

1、团队自身-职能单一化：因组件团队职能单一，限制了团队成员学习，团队成员容易被替换

2、组织级别-组件之间存在等待上的浪费：每个组件团队专注于自己的模块，由于各模块、分层需求的工作量不同，很容易产生等待，最终产生低价值交付。

3、组织级别-各组织层面沟通困难：存在较强的部门墙，很难避免团队之间的依赖，跨团队的协调和依赖管理更加复杂，不利于跨组件或者各个层之间的沟通

4、项目级别给项目的日程带来风险：因为组件团队只完成项目的其中一部分，整个价值的体现需要所有组件组合在一起才可以。因为各个组件是相互以来的，从而去计划各个组件工作的活动是很困难的，存在一定无法完成目标的风险。

5、组织级别-无法按期交付：存在在无法按期交付产品的风险，延期交付价值的时间

特性团队：

基础概念：以用户为中心，按照用户场景作为边界来组织团队是比较推荐的做法。这种以用户为中心的团队叫做特性团队。特性团队的特点：

利：

1、快速响应变化-能更好的评估设计决策的影响：端到端的开发，可以直接面对客户，了解客户的需求，以便生产出客户所需的产品

2、用户价值导向-减少因为交接而产生的浪费：因为组件团队之间在传递信息的时候可能存在信息偏差，导致团队所提供的并非客户想要的

3、落实责任-确保总能让合适的人去讨论问题：因为特性团队是作为一个“完整”的团队，每个人都可以参与到完整的流程中，团队信息是共享，大家都是价值链中的一员，所以，在实际工作中，每个角色都能参与其中。

4、让团队关注于需求交付的功能特性：因敏捷的核心是“在每个迭代结束的时候交付可工作的软对“，这也是团队的核心，团队每个成员会把这个作为首要工作去完成。

5、个人：因团队是特性跨职能，提供了一个团队自身或团队学习的机会

弊：

1、人员利用率：全职，专注避免异地办工，专注于快速响应，关注等待的事情而非等待人。从全局的角度看，人员无法达到100%的利用

2、概念一致性：不同功能的特性团队采用不同的交互方式，造成用户的学习成本，用户体验比较差

3、公共资源争夺：业务线争夺公司的公共资源，特性团队争夺业务线的资源

参考资源：https://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-12