更好的对齐，能带来更多的自主性，二者相辅相成。
—— 史蒂芬·邦吉， 作家，战略顾问
敏捷发布火车
敏捷发布火车（Agile Release Train, 简称ART）是由多个敏捷团队组成的长期团队。他们与其他的干系人一起，围绕价值流增量式地开发，交付和运作一个或多个解决方案。
详解
敏捷发布火车使各团队能向共同的业务目标和技术目标对齐。每个火车是一个（通常由50-125人组成的）虚拟团队，他们共同进行计划、承诺、开发、交付。敏捷发布火车是围绕着企业的重要开发价值流而组织的，它唯一的目标，是通过创造能为终端用户带来利益的解决方案，从而实现对价值的承诺。
敏捷发布火车是跨职能的，并且拥有定义，实施，测试，部署，发布，运营解决方案所需的所有能力 —— 软件，硬件，固件等等。发布火车交付的是持续的价值流，如图1所示：
图1 长期存在的敏捷发布火车
敏捷发布火车的运作遵循一套共同原则：
- 固定的时间计划：火车根据已定义的PI（Program Increment）节奏，按已知、可靠的时间表发车。如果一个功能错过了发车时间，没能进入当前PI，则可以被规划至下一个PI中。
- 每两周交付系统增量：每辆火车每两周都交付一个新的系统增量，各团队的增量将集成并进行演示，这也提供了很好的系统评估机制。
- 采用同步：一辆发布火车上的所有团队，都遵循相同的PI周期（通常是8-12周），PI的开始、结束时间以及时长都是一致的。
- 已知的火车速率：每辆发布火车都能够可靠地预估一个PI可交付的货物（新功能）总量。
- 敏捷团队：敏捷团队拥抱“敏捷宣言”和SAFe核心价值观及原则。他们运用Scrum，极限编程（XP），Kanban，和其他提升内建质量的实践。
- 全职的成员：发布火车上的大多数成员，都能够全职投入ART的工作，不论他们的职能汇报关系如何。
- 面对面的PI Planning：ART周期性地进行工作规划，主要是举行面对面的PI规划会议。
- 创新和规划（IP）：创新和规划（IP）迭代发生在每个PI的末尾，它为PI的规划、创新、持续学习和基础设施建设提供了估算的缓冲（保护）带。
- 检视和适应（I&A）：每个PI结束时都会举行一次检视和适应（I&A）活动，用来演示和评估系统的当前状态，团队和管理层则通过一个结构化的解决问题工作坊，来确定改进项。
- 按节奏开发，按需发布：ARTs运用节奏和同步来帮助管理研发过程的不确定性。然而，发布则通常与开发节奏解耦。ARTs可以在任何时候发布一个或部分解决方案，取决于管理需要及发布标准。
此外，在更重要的价值流中，多个敏捷发布火车协作，组成更大范围的“解决方案火车”。ART中的关键成员参与解决方案火车的活动，包括PI规划会前后的计划活动。
敏捷发布火车围绕价值组织
敏捷发布火车是典型的虚拟组织，它拥有定义、交付和运营解决方案所需的所有成员。这种新的组织打破了传统职能型组织架构中可能存在的筒仓现象。如图2所示。
图2 传统职能型组织
在这样的职能型组织中，开发人员与开发人员一起工作，测试人员和其他测试人员协作，架构人员和系统工程师相互合作，而运营人员则自己工作。虽然组织这样发展有其原因，但在这样的组织中，价值无法快速流动，因为它必须跨越所有筒仓。职能经理则必须参与日常事务，来帮助工作在筒仓间的传递，信息延迟，责任推诿，工作进展缓慢也因此成为常态。
然而，ART运用系统思考（SAFe原则第二条）和围绕价值进行组织（SAFe原则第十条），来组建一个跨职能组织，来促进价值从创意，到部署和发布，再到运营的流动。如图3所示。
图3 敏捷发布火车是完全跨职能的
这个完全跨职能组织——无论是实体组织（直接汇报关系）还是虚拟组织（汇报关系不变）—— 都拥有定义、交付、运营解决方案所需的一切人和资源。它是自组织和自管理的。这打造了一个更加精简的组织，不再需要传统的日常任务和项目管理，价值流动更快，开销更小。
敏捷团队赋能发布火车
敏捷发布火车包含了定义、开发、测试功能的团队，以及部署、发布、运营解决方案的团队。每个团队选择适合的敏捷实践，主要基于Scrum，XP和Kanban。每个敏捷团队有5-11个全职成员， 他们涵盖了在每个迭代建立高质量价值增量所需的所有角色。团队可能是聚焦技术的——交付软件、硬件，或任何组合——或是聚焦业务的。每个敏捷团队有两个特殊的角色，Scrum Master和Product Owner。当然，ART中的敏捷团队是跨职能的，如图4所示。
图4 敏捷团队是跨职能团队
除了围绕开发价值流组建ART外，在火车上的各敏捷团队也需要围绕价值来组建。否则，组建能够交付持续价值流的ART的潜在优势也就不复存在了，因为团队间需要努力管理各种相互关系和依赖。
为了简化团队设计，SAFe应用了四种基本的团队拓扑结构，定义如下：
1.对齐工作流的团队 — 围绕工作流进行组织的团队，有能力为客户或最终用户直接交付价值。
2.复杂的子系统团队 — 围绕特定子系统进行组织的团队，这类子系统需要深厚的专业技能和专业知识。
3.平台团队 — 围绕平台开发和支持进行组织的团队，这类平台负责为其他团队提供服务。
4.赋能团队 — 这支团队可利用其专业能力协助其他团队，帮助其他团队熟练掌握新技术。
这些团队拓扑结构中的每一个都对应着一组特定的职责和行为，它们共同为在SAFe中如何组织敏捷团队提供了一个更清晰和更好的模型。详情信息和如何应用这些拓扑结构的指南，在“敏捷团队”一文中详述。
当设计ART及其组成团队时，按它们所映射的拓扑结构来可视化这些团队也是很有用的。为了使团队类型更清晰，我们使用图5中的图标来代表不同类型的团队。一个对齐工作流的团队在末端有一个箭头的形状，以强调流动。正方形用来代表复杂的子系统团队，长方形代表平台团队，赋能团队则用一个虚线椭圆来标识。
图5 在ART敏捷团队中应用团队拓扑结构
ART中的关键角色
除了敏捷团队外，下列角色帮助保证ART的成功执行：
- 发布火车工程师（RTE）是一个服务式领导，负责引导敏捷发布火车中各项活动的执行，障碍的移除，风险和依赖管理，以及持续改进。
- 产品管理（Product Management）负责定义“做什么样的产品”，这是由产品的愿景、路线图以及产品待办列表中的新功能来决定的。他们与客户及产品负责人合作，理解和沟通需求，同时也参与解决方案的验证。
- 系统架构/工程师，是定义系统整体架构的个人或团队，他们在团队和组件之上的抽象层工作，定义非功能需求（NFR）、主要系统元素、子系统以及接口。
- 业务拥有者（Business Owners）是ART的关键干系人，对ART的业务成果负有最终责任。
- 客户是解决方案的最终买家。
除了这些ART中的关键角色外，以下职能在ART的成功中也起着至关重要的作用：
- 系统团队通常协助构建和维护开发、持续集成及测试环境。
- 共享服务团队是一个专家组，例如数据安全，信息架构师，数据管理员（DBA）等，他们也是ART成功的必要角色，但不专属于某个特定的发布火车。
定义敏捷发布火车
敏捷发布火车的参数和边界，干系人，以及在价值流中的关系，都能在下图6这张“ART画布”中得到体现和提炼。
图6 ART画布
节奏和同步
敏捷发布火车还解决了传统敏捷开发中最常见的一个问题：在同一个解决方案中协作的团队，常常是独立运作并且异步的。这使得常规性的系统集成工作变得异常艰难。换句话说，团队在做迭代，而系统却没有。这增加了问题和困难的滞后发现带来的风险。如图7所示。
图7 异步敏捷开发
然而，ART运用了节奏和同步机制来保证系统是作为一个整体进行迭代。
图8 对齐的开发：整个系统在迭代
节奏和同步保证了关注点始终在整个系统的演进及客观评估上，而不是针对其中的元素。每个迭代结束时的系统演示，为系统的持续迭代演进提供了客观证据。
敏捷发布火车的执行，DevOps，和持续交付
敏捷发布火车的目标是持续为客户提供价值。这一目标是由一个持续交付流水线来支撑的，它包含支持新功能发布所需的工作流，活动，和自动化工具。图9说明了在ART的DevOps支撑之下，这些流程是如何并行且持续运行的。
图9 DevOps能力支撑下的持续探索，持续集成，持续部署是连续和并发的
每个ART都建立和维护（或共享）一个持续交付流水线，包括尽可能独立地交付解决方案价值所需的资产和技术。流水线中的前三个元素共同支撑小批量新功能的部署，以快速满足市场需求。
- 持续探索是不断挖掘市场和用户需求，通过定义愿景、路线图、和验证一系列假设来满足这些需求的持续过程。
- 持续集成是指从Program待办列表中选取功能，在测试环境中进行开发、测试、集成和验证，并做好部署和发布准备的过程。
- 持续部署是将已验证通过的功能部署至生产环境，进行测试并做好发布准备的过程。
- 按需发布是指向最终用户提供价值，从对假设的验证结果中衡量和学习，并执行解决方案的过程。
对持续交付流水线的开发和管理是由DevOps所支撑的，这是每个ART所拥有的能力。
系统的流动由Program Kanban进行可视化、管理和度量。
敏捷发布火车交付全部或部分价值流
敏捷发布火车的组织，决定了谁将在一起做计划和工作，哪些产品、服务、功能或组件将由ART交付。ART的组织是SAFe的“艺术（art）”的一部分。关于这部分的扩展内容在“实施图线图”系列文章中详述，特别是在 “识别价值流和发布火车” 和 “创建实施计划” 等文章中。
高效的敏捷发布火车通常由50-125人组成。这个上限是基于邓巴数计算的，它提出了一个可以形成有效并稳定的社交关系的人数上限。而下限数字则主要来源于经验观察。尽管如此，低于50人的火车依旧可以提供良好的价值，并且相对于传统敏捷实践，它在敏捷团队的协同方面体现出了更多的优势。
基于对规模的限制，ART的设计有以下两个主要的模式：
- 较小的价值流可以由单个ART来实现
- 较大的价值流则必须由多个ART共同支持
图10 ART实现全部或部分价值流
在后面一种情况下，企业应用大型解决方案SAFe的元素和实践，组建解决方案火车来帮助敏捷发布火车中的各个角色和供应商进行协同，以支持开发和交付一些世界级的大型系统。
原文地址：https://www.scaledagileframework.com/agile-release-train/
关于译者：
Scrum中文网翻译组：Scrum中文网是全球第一个Scrum中文网站，中国最早的Scrum和敏捷教育及推广机构，也是国际Scrum联盟（ScrumAlliance）官方授权教育机构和大规模敏捷SAFe官方机构SAI在中国的授权合作伙伴。Scrum中文网是中国敏捷教练的摇篮，启蒙和培养了数万名敏捷专业人士，帮助数百家知名企业成功转型敏捷。
