转自：http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-12
如果我们的产品开发团队只有在10人以内，我们使用一个跨职能的Scrum团队，可以很容易地按照scrum和敏捷的方式开发产品。 但是，如果产品团队规模较大，比如是几十人，甚至几百人的开发团队的时候，我们就需要考虑团队的结构和组织方式。
在一个大的开发组织中，Scrum会把大的开发团队划分成多个5-9人的小团队，那么我们应该按照什么方式来划分呢？
在传统的开发模式下，我们习惯于按照系统的架构模块，或者系统分层组织团队，也有的团队按照系统需求、开发、测试结合系统架构混合组织的方式。这种团队组织的方式，我们称之为组件团队，是指每个团队只是完成系统功能的某一个部件，而不是一个端到端用户可见的功能。
组件团队看起来像这个样子：
按照Scrum和敏捷的交付模式，组件团队有如下一些限制：
第一：按照组件来组织团队，很难避免团队之间的依赖，跨团队的协调和依赖管理更加复杂，不利于跨组件或者各个层之间的沟通。
第二：每个团队专注在自己的模块，由于各模块、或分层需求工作量的不同，很容易产生等待，并且容易产生低价值的交付。
第三：由于职责单一，限制了学习，使得专业更加单一化
第四：Sprint结束的时候无法提交可交付的增量产品功能，延迟价值交付
按照Scrum和敏捷的交付模式，以用户为中心，按照用户场景作为边界来组织团队是比较推荐的做法。这种以用户为中心的团队叫做特性团队。
特性团队的特点：
- 长期稳定的团队，逐个端到端完成客户特性
- 以客户为中心的特性驱动
- 跨职能、完整团队
- 共享代码库，统一的持续集成
- 拥有通用型专家
特性团队看起来像这个样子：
特性团队的好处：
- 团队内可以做到端到端，所以减少了等待，周期加快
- 比较容易在一个Sprint中交付可用的产品增量
- 减少了团队之间依赖，计划会更容易
- 责任范围的扩大，各种不同领域的专家在一个团队，增加了
- 个人学习和团队学习的机会
