搜狐原文地址： https://www.sohu.com/a/347301169_468635
譯者：單冰
從事項目管理十幾年，先后管理傳統型項目團隊及敏捷創新型團隊。負責京東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所示。
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.
敏捷發布火車的目標是不斷地為客戶交付價值。這是由一個連續交付流水線來支撐的，它包含了提供新功能發布所需的工作流、發布活動和自動化系統。圖8說明了這些流程如何在敏捷發布火車的DevOps功能的支持下同步并發和連續地運行。
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.’
敏捷發布火車的組織決定了誰和誰將一起計劃和工作，以及火車將交付什么樣的產品、服務、特性功能或組件。敏捷發布火車組織是SAFe的一種“藝術”。特別是在“確定價值流、敏捷發布火車”和“創建實施計劃”方面，在實施路線圖一系列的文章中對此進行了廣泛的討論。
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.
首先需要考慮的是規模。高效的敏捷發布火車通常由50 - 125人組成。上限是基于Dunbar’s數字，這取決于一個人可以和多少人建立有效的、穩定的社會關系是有上限的。下限主要基于以往經驗和觀察得到的。然而，少于50人的發布火車是非常高效的，為了協調多個敏捷團隊，提供了許多優于傳統敏捷實踐的方法。
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.
[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年。
