上一篇我们介绍了SAFe的团队层，本文介绍SAFe的项目群层——敏捷发布火车，文章内容是基于SAFe4.0与SAFe5.0 的总结。
注：资料来源：分别来自https://www.scaledagileframework.com/#，和《SAFe4.0 参考指南》
SAFe团队被组织为一个虚拟的项目群结构，称为“敏捷发布火车”（ART）。每个ART都是长期存在和自组织的，由5～12个敏捷团队以及利益相关者组成，他们共同计划、承诺、执行、检视和调整，以及交付解决方案。
图1 敏捷发布火车架构图
敏捷发布火车：SAFe中一个项目群增量包括四个开发迭代和一个创新与计划（IP）迭代。SAFe框架把这个时间盒称为一个项目群增量。敏捷交付火车会在项目群增量中进行价值的增量式交付，每个项目群增量的周期是8～12周（默认是10周）的时间盒，通过多个迭代进行重要的、有价值的系统开发。每个敏捷交付火车包含5～12个敏捷团队（50～125人），敏捷交付火车包含价值交付所需要的团队角色和基础架构，用以支持交付全面测试的、可工作的、系统级的软件。
规模大小是火车效率的一个主要考虑因素，50～125人是一个敏捷发布火车上最典型的人员数量范围。人数上限是基于“邓巴数”理论进行设置的，“邓巴数”指出了在人类社会群体中可以维持有效交往和稳定社会关系的人数上限。大型火车的人数限制也遵循这个上限，虽然这样的规模也同时会面临其他挑战。人员数量下限大多是基于大型企业实施SAFe的经验观察得出的。然而，低于50人的火车依然可以非常有效地运作，也可以在团队协作方面提供许多优于传统方法的敏捷实践。只不过较小规模的火车通常会做一些适当的调整来满足企业自身的情况。
敏捷发布火车的组织依赖于价值流的规模，考虑到规模限制的不同，可以有以下三种敏捷发布火车的组织形式，如图2所示：
图2 基于价值流规模的敏捷发布火车组织
SAFe全景图中显示的这个项目群增量节奏，只是一种建议的方式，组织可以自行定义，多少个迭代以及IP迭代时间。软件的对外发布可以独立于项目群增量节奏，价值流或者每列火车可以根据情况自行决定。
“敏捷发布火车”的隐喻可以用来进行几个关键概念的解释：
1）火车按照可靠的时间表离开和到达车站，标准的敏捷发布火车速度和可预测的计划（在很多情况下，发布也是基于节奏的），这样给项目提供了固定的开发节奏。
2）所有的“货物”，包括原型、模型、软件、硬件和文档等，都包含在火车上。
3）不论人员的人事汇报线结构如何，火车上的大部分人员都是全职的。如果你想参加相应的工作，就需要加入到火车上。
（1）敏捷发布火车包含的角色：敏捷团队、发布火车工程师、产品管理者、系统和解决方案架构师/工程师、用户体验设计师、业务负责人、系统团队、DevOps、共享服务等。敏捷团队：包含产品负责人、Scrum Master，敏捷发布火车是由多个自管理、自组织的敏捷团队组成，他们一起做计划，给出承诺并执行工作。大部分的敏捷发布火车都是特性团队和组件团队的混合体，1）精益更加倾向于特性团队，因为他们可以提供更快的速度和更少的依赖关系。2）组件团队可以用在系统重用性很高、具有很强的技术特性要求，以及处理关键的非功能性需求等情况下。但是组件团队应该遵循一项原则，即每一个组件都是系统中的一个潜在的、可替代的组成部分，并具有良好定义的接口。这样就可以支持模块化、关注点的隔离，以及组件的重用。
敏捷发布火车是由多个自管理、自组织的敏捷团队组成，他们一起做计划，给出承诺并执行工作。然而，火车不可能自发地组建和驾驶，它需要被指引和给出方向，这样团队就可以对齐到共同的使命，在统一的架构设计和用户体验指导下完成工作。同时它还需要发布火车工程师来辅助任务的完成。发布火车工程师、产品管理者、系统和解决方案架构师/工程师这三个角色构成了项目群层敏捷发布火车的“三驾马车”，如下图。
图2 项目群管理、内容管理和架构的“三驾马车”
这三个主要的职能有助于确保项目群层的愿景和产品路线图的成功实现：
项目群执行——发布火车工程师（RTE）是火车上的仆人式领导和首席ScrumMaster。他协助团队在项目群中使用各种机制优化价值流，这些机制包括项目群看板、检视和调整工作坊、项目群增量计划等。RTE的职责在于促进项目群层级的流程和执行、升级问题障碍、管理风险，并帮助驱动项目群层级的持续改进。
内容管理——产品经理可看成是客户需求在组织内部的代言人，他们和客户以及产品负责人一起理解和沟通需求、定义系统的特性，并参与验证。他们是项目群待办事项列表的负责人。
解决方案管理者和产品管理者是SAFe中主要的内容授权者，分别指导价值流层和项目群层的相关工作，他们主要负责价值流和项目群待办事项列表。他们创建愿景，和客户一起工作并理解客户的需要、定义需求、指导价值流和项目群看板工作的开展。他们用加权最短作业法（WSJF）对工作进行优先级排序，通过产品路线图对发布进行排期，确认客户的回应，并提供快速反馈。
技术——系统架构师/工程师是一个独立的个人或者一个小型的多功能团队，他们真正运用系统思考来定义整个系统架构，从而有助于定义非功能性需求，决定主要的系统部件和子系统，同时他们还协助定义接口和接口之间的协作关系。
用户体验设计师、系统架构师和系统工程师负责定义架构跑道，从而支持新特性的开发。他们同时也为共同的解决方案行为、共享的组件和分离的关注点提供指导。
业务负责人：在SAFe中，业务负责人是由3～5个利益相关者组成的关键团队，这些利益相关者分担对特定的敏捷发布火车所交付的客户价值的诚信、治理、效率和投资回报（ROI）的责任。这是一个由管理者承担的关键角色，发挥着指导敏捷发布火车产出正确成果的作用。SAFe的业务负责人的具体职责和活动使他们能够履行对企业的义务，同时授权团队做出最好的成绩。他们负责理解企业的战略主题，并给予火车一定的影响。
系统团队帮助构建基础架构、协助集成、执行敏捷发布火车级的测试。系统团队具有评估非功能性需求的能力，并协助发布火车的系统演示。
DevOps是火车的一个组成部分，他们确保向最终用户快速交付价值。这个角色提供了开发和部署操作紧密结合的机制。
共享服务帮助火车实现一些特殊的职能，这些职能可能不是一个火车专用的。
在大型的价值流中，以上这些角色也会参加解决方案的项目群增量计划前会议和项目群增量计划后会议。
（2）敏捷发布火车包含的工件：史诗、能力、特性、使能、非功能性需求，项目群/价值流待办事项列表、项目群和价值流看板、项目群增量（PI）、PI目标。SAFe描述了功能性的系统行为的一个层次结构：史诗>能力>特性>故事。
史诗：在SAFe中，史诗驱动着企业中的许多经济价值。史诗是重大举措的容器，而通常这些举措是大型的、跨部门的，甚至横跨多个价值流和ART的活动。史诗需要大量投资并具有深远影响。因此，制订并分析一个史诗的成本、影响和机会是至关重要的。所以，史诗在真正实施前需要一个轻量级的业务论证和财务审批。它们的实施必须被分解成若干的小块（例如：价值流、项目群史诗、能力或特性等），并且把它们放置到相应的发布火车待办事项列表中。
史诗有两种：一种是业务史诗，另一种是使能史诗，它们可能出现在投资组合、价值流或项目群这三种不同的层级中。其中投资组合史诗最大且最有影响力，业务史诗捕获并反映新的业务能力，投资组合中这种能力只能通过多个价值流的合作才能完成。史诗使能揭示了实现这种能力必需的架构和其他的技术举措。
特性处于故事（Story）和能力（Capability）之间，故事由单个团队在一个迭代中完成，能力是价值流层级的服务或较大的业务需求，能力可以跨越多个敏捷发布火车。
使能：技术类需求，用来促成和支持业务需求，分三类：探索、架构和基础设施的工作。
非功能性需求（NFR，或系统质量）描述了系统的属性，如安全性、可靠性、可维护性、可扩展性和可用性（通常是指某种“特质”）。它们还可以是该系统的设计约束或限制（它们可称为设计约束）。这些需求保证整个系统的可用性和有效性。
项目群和价值流待办事项列表是一个存储列表，用于记录为构建解决方案将要开展的相关工作。待办事项列表包含将要实现的特性（项目群待办事项列表）和能力（价值流待办事项列表），这些内容可以用来实现用户需要并产生业务收益，此外还包括使能，用于预先学习和构建架构跑道。待办事项列表管理责任人是产品管理者（项目群待办事项列表）和解决方案管理者（价值流待办事项列表）。有效地识别、细化、调整优先级以及排序待办事项列表条目（使用WSJF方法）是解决方案获得经济上成功的关键。
未完待续......
,
