原文地址 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.

详情

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.

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.

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.

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.

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.

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.

 开发节奏

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.

Instead, the ART applies cadence and synchronization to assure that the system is sprinting as a whole, as shown in Figure 7.

Cadence and synchronization assure that the focus is constantly on the evolution and objective assessment of the full system, rather than its individual elements. The system demo, which occurs at the end of the iteration, provides the objective evidence that the system is sprinting.

敏捷发布火车的执行、DevOps和持续交付

ART Execution, DevOps, and Continuous Delivery

ARTs aim to continuously deliver value to their Customer. This is supported by a Continuous Delivery Pipeline, which contains the workflows, activities, and automation needed to provide the availability of new features release. Figure 8 illustrates how these processes run concurrently and continuously, supported by the ART’s DevOps capabilities.

Each ART builds and maintains (or shares) a pipeline with the assets and technologies needed to deliver solution value as independently as possible. The first three elements of the pipeline work together to support the deployment of very of small batches of new functionality, which are released as the market demands.

• Continuous Exploration is the process of constantly exploring market and user needs, and defining a Vision, Roadmap, and set of hypotheses to address those needs.
• Continuous Integration is the process of taking features from the program backlog and developing, testing, integrating, and validating them in a staging environment where they are ready for deployment and release.
• Continuous Deployment is the process that takes validated features from continuous integration and deploys them into the production environment, where they’re tested and readied for release.
• Release on Demand is the process of delivering the value to the end user, measuring the results of the hypotheses and learning from them, as well as operating the solutions.

每个敏捷发布火车会构建和维护(或共享)一个发布流水线系统，它包括尽可能独立地交付解决方案价值所需的资产和技术。流水线系统的前三个元素协同工作，完成根据市场需求发布的小批量的新功能的部署。

• 持续探索是一个不断探索市场和用户需求的过程，并且定义一个版本、路线图和一些假设来完成。

• 持续集成是这样的一个过程，它从产品待办列表进行计划安排，选取功能进行开发，并在准备部署和发布的环境中进行开发、测试、集成和验证。持续部署是从持续集成中获得完成验证的功能，并将其部署到生产环境中的过程，在生产环境中对这些新功能进行测试并准备发布。

• 按需发布是将价值交付给最终用户的过程，衡量预计的结果并且从中不断学习，同时实施解决方案。

Development and management of the continuous delivery pipeline are supported by DevOps, a capability of every ART. SAFe’s approach to DevOps uses the acronym ‘CALMR’ to reflect the aspects of Culture, Automation, Lean flow, Measurement, and Recovery.

采用DevOps来支持持续交付管道的开发和管理，这是每一个敏捷发布火车具有的能力。SAFe的DevOps方法使用缩写“CALMR”来体现：企业文化、自动化、精益流程、度量、修复。

Flow through the system is visualized, managed, and measured by the Program Kanban.

系统中的流程通过开发KANBAN来实现可视化、管理和度量。

 敏捷发布火车负责交付全部或部分的价值流

ARTs Deliver All or Part of a Value Stream

The organization of an ART determines who will plan and work together, as well as what products, services, features, or components the train will deliver. Organizing ARTs is part of the ‘art’ of SAFe. This is covered extensively in the Implementation Roadmap article series, particularly in ‘Identify Value Streams and ARTs‘ and ‘Create the Implementation Plan.’

One primary consideration is size. Effective ARTs typically consist of 50 – 125 people. The upper limit is based on Dunbar’s number, which suggests a limit on the number of people with whom one can form effective, stable social relationships. The lower limit is based mostly on empirical observation. However, trains with fewer than 50 people can still be very effective, and provide many advantages over legacy Agile practices for coordinating Agile teams.

Given the size constraints, there are two main patterns of ART design (Figure 9):

• Smaller value streams can be implemented by a single ART
• A larger value stream must be supported by multiple ARTs

根据团队规模限制，敏捷发布火车的团队设计主要有两种模式(图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.

[2] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

[3] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.

[3] 迪恩· 莱芬韦尔。《规模化敏捷软件开发:大型企业最佳实践》。Addison-Wesley出版社, 2007年。