SAFe 5.0介绍（二）- 敏捷团队层介绍

 

一、团队层介绍

在SAFe 5.0 基本层级中，我个人认为又分为了两个层级，一个是面向团队层级，另外一个是面向项目集团队层级；在SAFe 4.0中，这两个层级是分开了，但是后来将其进行了完全的合并，是因为两者形成了一个闭环，项目集为团队输送Backlog中的Story，团队按照节奏进行开发和演示，当一定数量的Story完成后就会根据客户的所需进行集成，并进行系统测试，一旦测试通过，就会把新的Story给到团队的Backlog；这样就行成了闭环。具体的实施可以见下图：

1. 在团队实施SAFe时，一定要遵循精益敏捷的原则；
2. 真正的敏捷团队和ART（敏捷发布火车）都是完全跨职能组织的。他们拥有一切可以为解决方案增量而服务的要素。他们是自组织和自管理的，这就可以使价值能够以最小的开销进行快速的流动。如果敏捷团队不能定义、构建和测试他们的工作，那么这就不是真正的敏捷团队。如果ART（敏捷发布火车）不能交付解决方案或解决方案的一部分，那么就不能称之为ART。
   1. 注：ART（敏捷发布火车）是 Agile team 中长期存在的一支团队，和其他相关方一起，在 价值流中增量式开发、交付一个或多个解决方案。所以ART更加关注的是解决方案的交付，这点和敏捷团队（Agile Team）是不一样的，你可以把他们理解为是两个层面的团队。
3. 节奏和同步：节奏提供了一种韵律，当做事情具备了一定节奏感的时候，其实就证明这件事情就已经做的很顺了；对于敏捷中，固定时间的Sprint就是一种节奏；而同步可以使多个观点得到同时的理解，当多个团队
4. PI计划（项目集增量计划）：这是SAFe中非常重要的一个计划，它为ART提供了决策，并且将业务和技术目标进行统一；实际上PI计划和ART处于同一层级。
5. 使用SAFe的企业创建了跨越全套产品和服务的客户体验。他们采用DevOps的思维方式、文化和技术进行实践，根据客户的需求进行频繁和高质量的发布。只有频繁的交付才能获得更高的质量和市场的反馈，从而帮助企业获得更大的利润，增加客户的满意度。当有了计划以后，就可以按照DevOps的方式进行交付。
6. 系统演示：对于ART团队的主要衡量标准是进行系统演示，并获得了相关方的认同；每两周，对火车上的所有团队的工作进行集成，使之成为一个全系统，然后演示给火车的相关方。相关方负责保证火车的正常行驶，并提供相应的反馈。
7. 检视和适应：这是每个PI都要举行的重要活动。需要一个固定的时间以收集数据和解决问题。这个会议会将团队和相关方召集在一起，以对解决方案进行评估，并且定义为提高下一个PI的速度、质量和可靠性所需的改进。
8. IP（创新和规划）冲刺：创新和规划会发生在每个PI，并且会有多个目的。它扮演了满足PI的目标的缓冲，并为创新、继续教育、PI规划，以及检视和适应提供了专用的时间。IP冲刺活动实现了许多精益敏捷的原则，这些原则可以使业务敏捷性。
9. 架构跑道：包括了高优先级、近期要实施的代码、组件和技术架构；如果没有对架构跑道进行充分地投资，那么火车就会减速，并使ART难以预测。所以要尽可能的减少架构跑道不要延迟和重新设计。
10. 精益敏捷领导力：要想让SAFe更加的有效，公司的领导和管理层必须要承担起精益敏捷在组织中落地的职责；管理者必须要成为精益敏捷的领导者，当然首先他们要进行培训，让他们具备这样的思维模式。如果他们不具备这样的技能，那么企业的转型将是失败的，无法达到所预期的收益。

对于本篇文章，我们不会关注在解决方案层级（参见下一篇章），我们首先讲一下敏捷团队的事情，参看下图中红色方框中的内容：

二、敏捷团队

在SAFe中，敏捷团队是一个跨职能组织的团队，每个团队的人数在5-11个人，他们负责在固定的时间盒内负责对所交付的增量进行定义、构建和测试。

在SAFe的敏捷团队中，包括了两个关键的角色，一个是 Scrum Master；另外一个是Product Owner。

没有敏捷团队就不可能有火车，他们为ART以及整个公司提供了动力。ART负责交付大型解决方案的价值。在火车上的团队都要和其他团队进行协作，为所指定的愿景和路线图做出相应的贡献，并参与ART的活动。此外，他们还需要构建持续交付的管道和DevOps的能力。

三、产品负责人

产品负责人是敏捷团队的成员，负责定义用户故事，并对团队的待办列表进行优先级的排序，确保特性和组件故事的完整性。产品负责人要让团队的产出价值最大化，确保故事能够满足用户的需要，以及遵循了“完成的定义”。对于大多数敏捷企业来说，产品负责人是一个非常关键的角色，通常都是全职的岗位，最多可以支持两个敏捷团队。他的职责如下：

• 准备和参与PI规划
• 冲刺执行：维护团队待办列表；冲刺规划；BDD；验收故事；参与团队演示和回顾
• 项目集执行
• 检视和适应

产品经理	产品负责人
负责维护项目集待办列表	负责维护团队待办列表
定义特性、PI和发布	定义冲刺和故事
负责制定愿景、路线图、价格和ROI	为愿景、路线图和ROI的实现而努力

在SAFe中，产品经理和产品负责人的区别

四、Scrum Master

Scrum Master的角色是帮助团队成员进行沟通、协调和合作；总的来说，这个人是协助团队交付最终的目标。Scrum Master是一个服务型的领导，他能够通过有效的精益敏捷实践帮助团队进行自组织和自管理。他的职责如下：

• 展示精益敏捷领导力
• 支持团队的规则
• 引导团队朝着目标前进
• 领导团队进行持续改进
• 引导会议
• 支持产品负责人的工作
• 清除障碍
• 推广SAFe质量实践
• 构建高绩效团队
• 与其他团队进行协调
• 负责火车上的事宜
• 支持SAFe在组织中的适应性
• 提高组织效率
• 引导ART事件的准备
• 支持估算

五、团队看板

     团队看板是一种方法，可以将工作进行可视化管理，并建立在制品（WIP）限制，测量吞吐量以及持续改进流程。SAFe团队可以选择自己的敏捷方法，但是大多数团队都会选择Scrum这个轻量型的管理工作的框架；当然，如果你是开发团队，也可以选择XP的实践。看板系统可以运用于SAFe的组合级、大型解决方案级和基础级。看板系统可以帮助实现以下工作：

• 可视化工作流和限制WIP
• 使用累积流量图等工具对工作进行度量
• 对价值流进行改进

六、团队Backlog

     团队待办列表包括了来自于项目集待办列表中的用户故事和触发故事，以及来自团队本地提出的故事。它还可以包括其他一些工作项，代表了团队需要完成的工作。产品负责人的职责是团队待办列表，它包含了很多类型的故事，产品负责人必须要在冲突的需求之间进行平衡，合理的分配资源；这种资源的分配既要考虑到团队的需求，还要考虑到敏捷发布火车（ART）。

七、PI目标和PI计划

项目集增量（PI）目标是敏捷团队或者火车为即将到来的项目集增量中要达成的商业和技术目的的摘要。在PI规划中，团队要创建PI目标，下图为团队PI目标。

项目集增量（PI）规划是基于节奏的、面对面的活动，它是敏捷发布火车的心跳，可以使敏捷发布火车上的所有团队可以共享使命和愿景。下图为标准的1天PI会议日程安排：

PI规划是一件非常重要的事件，需要进行准备、协调和沟通。发布火车工程师进行协助，参与人员会包括商业所有者、产品管理、敏捷团队、系统和解决方案架构师/工程师、系统团队和其他相关方，这些人都需要提前进行通知并做好准备。

八、项目集增量（PI）

PI是一个时间盒，在这个时间盒内，ART交付形成工作的增量价值，并且对其进行测试。每一个PI的长度是8-12周，每个PI大概有4个冲刺。

九、系统演示

系统演示是测试和评估完整的解决方案并获得相关方的反馈。这些相关方包括：商业负责人、发起人、其他的敏捷团队、开发管理、提供输入的客户，这些反馈是很重要的，他们会给ART一些指导或者让他们进行调整。

系统演示发生在每个冲刺即将结束的时候，它提供了ART在这个冲刺中所有集成的新功能的全景图，它也为ART提供了系统层级的进展数据，可以使他们知道自己的速率。为了达成这种要求，需要扩展工程实践以帮助ART进行持续的集成。在每一个PI即将结束的时候，ART还会举办一个PI系统的演示，以演示在这个PI阶段开发出来的所有特性。因为PI的范围比较广，所以PI系统演示时参与的人员会更多一些，包括：客户、组合代表、其他的相关方。这个演示通常是检视和适应事件的一部分内容。对于大型的解决方案火车，系统演示会通过解决方案演示来展示。