从传统模式向敏捷模式转变－Scrum团队结构

Scrum团队是Scrum组织的的重要资产。团队的组织方式和相互之间的关系，对组织成功采用Scrum有重大影响。

特性团队与组建团队

• 特性团队是一个跨职能、跨组件的团队，能够从产品列表中抽取并完成最终客户想要的特性。
• 组建团队专注于开发组件或子系统，这些组件或子系统只能实现最终客户想要的部分特性。（UI组属于组件团队？）

Scrum更倾向于组建特性团队。

使用组件团队的大多数组织都认识到事情刚开始有结果就会出现问题——因为交付的职责分到两个或多个组件团队中，而每个团队为此指定的优先级可能差异非常大。按照这种当时使用组件团队时，因为现在可能是多点失败而不是单点失败，所以某个功能无法完成的几率陡增。
一个很好的办法是组建一个跨职能的特性团队，成员具备完成多个特性的技能和能力，不必将完成的部分特性转包给组件团队。但特性团队可能会给可重用产品的开发和维护工作带来混乱并招致大量技术债。
对于特性团队还是组件团队，没有一个普遍适用的方法。大多数大型和成功的Scrum组织往往采用混合模式，以特性团队为主，把组件团队作为资源集中使用时更加经济合理，偶尔有个别组件团队。

多团队之间的协调

Scrum规模扩大体现在有多个规模适中的Scrum团队。在团队不止一个时，我们可以用SoS和“版本火车”方法来协调。

SoS(Scrum of Scrums)

SoS

SoS可以使多个团队协调彼此之间的工作，执行SoS的团队由各个开发团队中的成员组成。每个开发团队根据那个成员能最清楚说明团队依赖问题来指派参会人员，但可以随着时间的推移换人，只要他当时是团队的最佳代言人，能够清楚阐述团队的问题。
SoS一般不会每天都开，而是根据需要每周开几次。SoS的参与者回答的问题与每日例会上回答的问题相似。

版本火车

版本火车根据按照一个共同的节奏协调跨团队的合作，使多个团队的愿景、规划和相互依赖关系保持一致。版本火车关注的是在大型的产品界别上实现快速、灵活的工作流。

版本火车

版本火车规则：

• 频繁、定期规划和解决方案的发布日期是固定的。
• 各团队的迭代时间长度相同。
• 建立大小适中的、全局的、客观的里程碑。
• 在顶层、系统级以及特性和组件级做持续的系统集成。
• 版本增量可以定期提交客户进行预审、内部评审和系统级的QA。
• 系统级固化迭代，用于嘉绍技术债并为特殊的版本级验证和测试提供时间。
• 对于构建类构件的团队，某些特定的基础设施组件一般都必须提前准备就绪。