译者：单冰从事项目管理十几年，先后管理传统型项目团队及敏捷创新型团队。负责京东AI事业部敏捷创新、团队工程效率改进及敏捷教练工作。曾经负责手机端京东App项目管理工作5年，带领千人团队实施敏捷转型工作，版本发布从2个月提升为2周版本。大型互联网企业敏捷项目管理实战经验丰富，擅长团队创新、敏捷转型、系统化思维、Scrum方法、KANBAN方法等。敏捷之旅北京站组织者，参与敏捷大会分享活动，敏捷之旅讲师，2018Tid大会讲师，2018全球技术周讲师。参与翻译SAFe案例及《SAFe4.5参考指南》。专业认证：CSP-SM、A-CSM、CSM、LeSS、SAFe4.5认证SA、管理3.0认证、PMP。
原文地址 https://www.scaledagileframework.com/agile-release-train
正 文
The more alignment you have, the more autonomy you can grant. The one enables the other.
—Stephen Bungay, Author and Strategy Consultant
更多的一致性，能给予更多的主动权。二者相互使能。
——史蒂芬·邦吉，作家和战略顾问
敏捷发布火车
Agile Release Train
The Agile Release Train (ART) is a long-lived team of Agile teams, which, along with other stakeholders, incrementally develops, delivers, and where applicable operates, one or more solutions in a value stream.
敏捷发布火车(ART)是一个由敏捷团队组成的长期团队，它与其他干系人一起，增量开发、交付，并在适用的情况下运营，在价值流中实现一个或多个解决方案。
详情
Details
Agile Release Trains align teams to a common business and technology mission. Each is a virtual organization (typically 50 – 125 people) that plans, commits, develops and deploys together. ARTs are organized around the enterprise’s significant Value Streams and exist solely to realize the promise of that value by building Solutions that deliver benefit to the end user.
敏捷发布火车将团队的共同业务任务与技术任务对齐起来。每个虚拟的组织(通常有50 - 125人)，他们一起做计划、一起提交代码、一起开发和部署。敏捷发布火车是围绕企业的重要价值流组织起来的，它的存在是为了通过构建实现解决方案来实现对价值的承诺，从而为最终用户带来利益。
ARTs are cross-functional and have all the capabilities—software, hardware, firmware, and other—needed to define, implement, test, deploy, release, and where applicable, operate solutions. An ART delivers a continuous flow of value, as shown in Figure 1.
敏捷发布火车组成是跨职能的团队，具有定义、实现、测试、部署、发布和操作解决方案所需的所有能力(包括：软件、硬件、固件等其他能力)。敏捷发布火车交付的是一个持续的价值流，如图1所示。
ARTs operate on a set of common principles:
- The schedule is fixed – The train departs the station on a known, reliable schedule, as determined by the chosen PI cadence. If a Feature misses a timed departure, it can catch the next one.
- A new system increment every two weeks – Each train delivers a new system increment every two weeks. The System Demo provides a mechanism for evaluating the working system, which is an integrated increment from all the teams.
- The PI timebox is fixed – All teams on the train are synchronized to the same PI length (typically 8 – 12 weeks) and have common iteration start/end dates and duration.
- The train has a known velocity – Each train can reliably estimate how much cargo (new features) can be delivered in a PI.
- Agile Teams – Agile Teams embrace the ‘Agile Manifesto’ and the SAFe values and principles. They apply Scrum, Extreme Programming (XP), Kanban, and other Built-In Quality practices.
- Dedicated people – Most people needed by the ART are dedicated full time to the train, regardless of their functional reporting structure.
- Face-to-face PI Planning – The ART plans its work at periodic, largely face-to-face PI Planning events.
- Innovation and Planning (IP) – IP iterations provide a guard band (buffer) for estimating and a dedicated time for PI planning, innovation, continuing education, and infrastructure work.
- Inspect and Adapt (I&A) – An I&A event is held at the end of every PI. The current state of the solution is demonstrated and evaluated. Teams and management then identify improvement backlog items via a structured, problem-solving workshop.
- Develop on Cadence. Release on Demand – ARTs apply cadence and synchronization to help manage the inherent variability of research and development. However, releasing is typically decoupled from the development cadence. ARTs can release a solution, or elements of a solution, at any time, subject to governance and release criteria.
敏捷发布火车是建立在一系列共同原则上的:
时刻表是固定的——火车按照已知的、可靠的时刻表出站，由所选择的PI节奏决定。如果一个功能错过了当前固定的发布时间，它可以赶下一个发布时间发布。
每两周产生一个系统增量——每两周每列火车交付一个系统增量。集成来自所有团队的增量并进行系统演示，这提供了工作系统的评估机制。
PI的时间盒是固定的——敏捷发布火车上的所有团队都同步相同的PI长度(通常是8 - 12周)，并且有共同的迭代开始/结束日期和持续时间。
列车的交付速度是已知的——每列火车可以可靠地估算有多少货物(新功能)可以在PI中交付。
敏捷团队——敏捷团队尊崇“敏捷宣言”和SAFe的价值观和原则。团队采用Scrum、极限编程(XP)、KANBAN和其他内建质量等方法的敏捷实践。
固定的团队——敏捷发布火车，需要大多数人都是全职投入到发布火车上，不管他们的职能汇报关系如何。
面对面的做PI计划会议——敏捷发布火车的计划会是定期做的工作，主要是面对面的做PI计划会议这件事。
创新和规划(IP- Innovation and Planning)——迭代中的创新和规划为团队预估工作、开展定时的PI计划会、做创新、持续学习和基础架构建设提供了一个保护 (缓冲)的条件。
检查和调整(I&A- Inspect and Adapt) ——I&A活动在每一个PI的结尾进行。对解决方案的当前状态进行演示和评估。团队和管理层通过一个结构化的并且解决问题的研讨会，来确定改进计划。
按节奏开发，按需要发布——敏捷发布火车应用同步和节奏开发来帮助管理原本的易变的开发需求。然而，发布通常要与开发节奏解耦。通过规范发布标准，敏捷发布列车可以在任何时候发布解决方案或者方案中的某个元素。
Additionally, in larger value streams, multiple ARTs collaborate to build larger solutions via a Solution Train. Some ART stakeholders participate in Solution Train events, including the Solution Demo and Pre- and Post-PI Planning.
此外，在更大的价值流中，多个敏捷发布火车协作构建更大的解决方案火车。有一些ART的干系人参与解决方案火车的活动（会议），包括解决方案演示活动和PI计划会前后的计划活动。
组织
Organization
ARTs are typically virtual organizations that have all the people needed to define, deliver, and operate the solution. This new organization breaks down the traditional functional silos that may exist, as shown in Figure 2.
敏捷发布火车是一个典型的虚拟组织，它拥有定义、交付和执行解决方案所需的所有人员。这个新的组织打破了之前可能会存在的传统职能筒仓现象，如图2所示。
In such a functional organization, developers work with developers, and testers work with other testers, architects and systems engineers work with each other, and operations work by themselves.
While there are reasons why organizations have evolved that way, the value doesn’t flow quickly, as it must cross all the silos. The daily involvement of managers and project managers is necessary to move the work across. As a result, progress is slow, and handoffs and delays rule.
在这样的全职能组织中，功能团队的开发人员与其他开发人员在一起工作，功能团队的测试人员与其他的测试人员一起工作，架构师和系统工程师也和他的团队在一起工作，而实际的工作由他们自己完成。虽然有一些原因可以解释为什么组织会以这种方式发展，但是这种情况下业务的价值不会很快速地流动，因为它必须跨越所有的竖井。日常参与工作的职能经理和项目经理穿插于各种工作之间也是必须的。因此，工作进展的过程会是缓慢的，并且信息传递和延迟也是很正常的。
Instead, the ART applies systems thinking (SAFe Principle #2)and builds a cross-functional organization that is optimized to facilitate the flow of value from ideation through deployment and release, and into operations, as Figure 3 illustrates.
相反，敏捷发布火车应用了系统思考(SAFe原则#2)，并构建了一个跨职能的组织，该组织经过优化来促进价值流动，从想法到部署、发布，再应用于实践操作。如图3所示。
Together, this fully cross-functional organization—whether physical (direct organizational reporting) or virtual (line of reporting is unchanged)—has everyone and everything it needs to define, deliver, and operate solutions. It is self-organizing and self-managing. This creates a far leaner organization; one where traditional daily task and project management is no longer required. Value flows more quickly, with a minimum of overhead.
总之，这个完全跨职能的组织——无论是物理的(直接的组织汇报关系)还是虚拟的(汇报线不变)——他们是进行定义、交付和运营解决方案所需的人和事。他们是自组织和自管理的。这样就产生了一个更精简的组织;不再需要传统的日常任务分配和项目管理。让价值流动得更快，开销最小。
敏捷团队推动发布火车执行
Agile Teams Power the Train
ARTs include the teams that define, build, and test features and components, as well as those that deploy, release, and operate the solution. Individual teams have a choice of Agile practices, based primarily on Scrum, XP, and Kanban. Software quality practices include architecture & design quality, code quality, systems quality, and release quality practices (see Built-In Quality). Hardware quality is supported by exploratory early iterations, frequent system-level integration, design verification, modeling, and Set-Based Design. Agile architecture supports software and hardware quality.
敏捷发布火车包括定义、构建和测试特性或组件的团队，以及部署、发布和实施解决方案的团队。各个团队可以选择不同的敏捷实践，主要基于Scrum、XP和KANBAN。软件质量的实践包括架构和设计的质量、代码质量、系统质量和发布质量实践(参见内建质量)。早期的探索性迭代开发、频繁的系统级集成、设计验证、建模和基于底层的设计来支持硬件质量。敏捷架构系统支持软件和硬件质量。
Each Agile team has five to eleven dedicated individual contributors, covering all the roles necessary to build a quality increment of value for an iteration. Teams can deliver software, hardware, and any combination. And of course, Agile teams within the ART are themselves cross-functional, as shown in Figure 4.
每个敏捷团队有5到11个专职人员全心投入，涵盖了所有构建迭代增值和内建质量所需要的所有角色。团队有能力交付软件、硬件和任意的组合。当然，敏捷团队在敏捷版本火车中本身就是跨职能的团队，如图4所示。
Critical Team Roles(关键的团队角色)
Each Agile team has dedicated individual contributors, covering all the roles necessary to build a quality increment of value for an iteration. Most SAFe teams apply a ScrumXP and Kanban hybrid, with the three primary Scrum roles:
- Scrum Master – The Scrum Master is the servant leader for the team, facilitating meetings, fostering Agile behavior, removing impediments, and maintaining the team’s focus.
- Product Owner – The Product Owner owns the team backlog, acts as the Customer for developer questions, prioritizes the work, and collaborates with Product Management to plan and deliver solutions.
- Development Team – The Development Team has three to nine dedicated individual contributors, covering all the roles necessary to build a quality increment of value for an iteration.
每个敏捷团队都有全职投入的员工，覆盖为每个迭代构建符合质量要求的价值增量所需的所有角色。大多数SAFe的团队采用Scrum XP和KANBAN的混合方法，三个Scrum角色:
- Scrum Master——Scrum Master是团队的仆人式领导，引导会议，培养团队的敏捷行为习惯，为团队消除障碍，保持团队的专注，不受外界干扰。
- 产品负责人——产品负责人掌握团队的待办事项列表，站在客户的角度处理开发人员提出的问题，负责确定工作优先级，并与产品管理层共同完成计划和交付的解决方案。
- 开发团队——开发团队有3到9个专职人员投入，涵盖了迭代创造有质量保证的价值增量所需的所有角色。
Critical Program Roles(关键的项目角色)
In addition to the Agile teams, the following program-level roles help ensure successful execution of the ART:
- Release Train Engineer (RTE) is a servant leader who facilitates program-level execution, impediment removal, risk and dependency management, and continuous improvement.
- Product Management is responsible for ‘what gets built,’ as defined by the Vision, Roadmap, and new Features in the Program Backlog. They work with customers and Product Owners to understand and communicate their needs, and also participate in Solution validation.
- System Architect/Engineer is an individual or team that defines the overall architecture of the system. They work at a level of abstraction above the teams and components and define Nonfunctional Requirements (NFRs), major system elements, subsystems, and interfaces.
- Business Owners are key stakeholders of the ART and have ultimate responsibility for the business outcomes of the train.
- Customers are the ultimate buyers of the solution.
除了敏捷团队之外，下面的项目群级角色有助于成功的执行敏捷发布火车:
- 发布火车工程师(RTE)作为仆人式领导，负责引导项目群级的执行、负责移除障碍、控制风险和解决依赖关系管理，以及持续改进。
- 产品管理者负责“构建什么样的产品”，这是通过定义版本计划、产品路线图、在需求列表中定义新的特性功能而得到的。他们需要与客户、产品负责人一起理解和沟通需求，并参与验证解决方案。
- 系统架构师/工程师是定义整体系统架构的某个人或团队。它们在团队和组件级别之上，并定义非功能性需求(NFRs)，包括主要的系统元素、子系统和系统接口。
- 业务负责人是敏捷发布火车的关键干系人，对发布列车的业务结果负最终责任。
- 客户是解决方案的最终的付款方。
In addition to these critical program roles, the following functions play an essential part in ART success:
- A System Team typically assists in building and maintaining the development, continuous integration, and test environments.
- Shared Services are specialists—for example, data security, information architects, database administrators (DBAs)—that are necessary for the success of an ART but cannot be dedicated to a specific train.
除了这些关键的角色之外，以下功能团队在成功敏捷发布火车的工作中扮演着重要的角色:
- 系统团队通常协助构建和维护开发、持续集成和测试环境。
- 共享服务作为专家角色——例如，数据安全、信息架构师、数据库管理员(DBAs)——这是保证敏捷发布火车成功所必需的角色，但不能专门用于特定的一个发布火车。
敏捷发布火车的定义
Define the ART
The parameters and boundaries of the ART, as well as its stakeholders, and relations to the value streams can be captured and summarized in the ‘ART canvas’, as Figure 5 shows.
敏捷发布火车的参数和边界，以及它相关的干系人与价值流的关系可以在“敏捷发布火车画布”中获得并进行总结，如图5所示。
开发节奏
Develop on Cadence
ARTs also address one of the most common problems with traditional Agile development: Teams working on the same solution operate independently and asynchronously. That makes it extremely difficult to integrate the full system routinely. In other words, ‘The teams are sprinting, but the system isn’t.’ This increases the risk of late discovery of issues and problems, as shown in Figure 6.
敏捷发布火车还解决了传统敏捷开发中最常见的一个问题：团队工作在同一个解决方案上时，通常是相互独立而且是异步的开发节奏，这样使常规的系统集成工作变得非常困难。换句话说，各团队都在做开发冲刺，但没有协调一致的系统。这样就会导致发现问题较晚，也增加了发现问题较晚带来的风险，如图6所示。
Instead, the ART applies cadence and synchronization to assure that the system is sprinting as a whole, as shown in Figure 7.
相反，敏捷发布火车采用同步开发节奏来保证整个系统作为一个整体共同冲刺发布，如图7所示。
根据团队规模限制，敏捷发布火车的团队设计主要有两种模式(图9):
较小的价值流可以通过单个敏捷发布火车实现
更大规模的价值流则需要多个敏捷发布火车配合支持来实现
In the latter case, enterprises apply the elements and practices of the Large Solution Level and create a Solution Train to help coordinate the contributions of ARTs and Suppliers to deliver some of the world’s largest systems.
在后面这种情况下，企业级应用大型解决方案实践的关键要素，创建一个解决方案的发布火车，来帮助协调敏捷发布火车和供应商，以支持一些世界级的大型系统的交付。
扩展学习
Learn More
[1] Knaster, Richard and Dean Leffingwell. SAFe Distilled, Applying the Scaled Agile Framework for Lean Software and Systems Engineering. Addison-Wesley, 2017.
[1]理查德· 克纳斯特、迪恩· 莱芬韦尔《SAFe精髓，运用规模化敏捷框架实现精益软件与系统工程》。Addison-Wesley出版社, 2017年。
[2] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
[2] 迪恩· 莱芬韦尔。《敏捷软件需求：团队、项目群与企业级的精益需求实践》。Addison-Wesley出版社, 2011年。
[3] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.
[3] 迪恩· 莱芬韦尔。《规模化敏捷软件开发:大型企业最佳实践》。Addison-Wesley出版社, 2007年。
