【读书笔记】《Scrum 精髓 - 敏捷转型指南》【第12章 Scrum 团队结构】

【读书笔记】《Scrum 精髓 - 敏捷转型指南》【第12章 Scrum 团队结构】_第1张图片
文/秋之川

【目录】

【概述】

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

【特性团队与组件团队】

特性团队是一个跨职能、跨组件的团队,能够从产品列表中抽取并完成最终客户想要的特性。

组件团队专注于开发组件或子系统,这些只能实现最终客户想要的部分特性。

组件团队有时称为资产或子系统团队。

【多团队之间的协调】

协调多个团队的两个方法:

SoS (Scrum of Scrums)

执行 SoS 的团队由各个开发团队中的成员组成。每个开发团队根据哪个成员能最清楚说明团队依赖问题来指派参会人员。也可以由这些团队的 ScrumMaster 承担。

执行 SoS 的方式很多,参会者可以确定最合适的方式。一般不会每天都开,而是根据需要每周开几次,与会者回答的问题跟每日站会相似。

版本火车

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

火车的隐喻暗示特性出站时间有一个公开的时刻表,所有参与产品开发的团队都需要在约定的时间把东西放到火车上。

Leffingwell 定义的版本火车规则如下:

1、频繁、定期规划和解决方案的发布(或潜在可发布增量,PSI)日期是固定的(日期固定,质量固定,范围可变)。

2、各团队的迭代时间长度相同。

3、建立大小适中的、全局的、客观的里程碑。

4、在顶层、系统级以及特性和组件级做持续的系统集成。

5、版本增量(PSI)可以定期(一般是60天到120天)提交客户进行预审、内部评审和系统级的 QA。

6、系统级固化迭代,用于减少技术债并为特殊的版本级验证和测试提供时间。

7、对于构建类似构构件的团队,某些特定的基础设施组件(接口、系统开发工具箱、公用的安装程序和许可工具、用户体验框架、数据和 Web 服务等)一般都必须提前准备就绪。

【目录】

你可能感兴趣的:(【读书笔记】《Scrum 精髓 - 敏捷转型指南》【第12章 Scrum 团队结构】)