541
《SAFe 4.0參考指南：精益軟件與係統工程的規模化敏捷框架》SAFe團隊層
SAFe?團隊層
3.1 團隊層介紹
我們、工作、知識是一個整體。
——本書作者
摘要
SAFe團隊層是項目群層的組成部分，但有時會分開討論。所有的SAFe團隊都是敏捷發布火車（ART）的一部分——ART是項目群層的核心組成部分。團隊層為敏捷團隊的活動提供了組織、工件、角色和流程模型。由每個敏捷團隊自己負責定義、構建和測試來自團隊待辦事項列表中的用戶故事，這些工作在一係列固定周期的迭代內進行，通過使用共同的迭代節奏，並與其他團隊同步和對齊，從而保證整個係統開發的迭代執行。所有團隊都使用ScrumXP或團隊看板，開發和交付高質量的係統，並每兩周進行一次係統演示，從而確保在ART上的所有團隊可以共同創建出一個經過集成和測試的係統，利益相關者可以通過快速反饋進行評估和響應。係統演示提供了一個常規的 “拉動事件”，用於在特定節點拉取不同團隊的成果，讓困難的集成和測試工作盡量提前。這種方法與“階段–門限”模型有所不同，“階段–門限”模型通常在項目生命周期的後期才進行集成和測試工作。
詳述
團隊層描述了敏捷團隊如何驅動敏捷發布火車。敏捷團隊采用SAFe ScrumXP或團隊看板，同時應用內建質量的實踐，確保最終產品質量。每個團隊有5～9名團隊成員（ScrumXP），並包括所有必要的角色，確保在每一次迭代中構建一個高質量且有價值的發布增量。ScrumXP角色包括Scrum Master、 產品負責人、全職工作的團隊成員，以及其他能為團隊創造價值的資源。看板團隊的角色沒有嚴格的定義，許多SAFe看板團隊也使用ScrumXP的角色。每個團隊都會得到項目群層中成員的支持，這些成員包括：發布火車工程師、產品經理、係統架構師/工程師、係統團隊、共享服務、DevOps和其他必要的角色。因此，團隊應該完全有能力在每次迭代中定義、開發、測試和交付可以工作並經過測試的係統。
項目群增量和迭代
所有團隊遵循相同的迭代起止日期和時間周期，也就是有相同的迭代和項目群增量（PI）邊界，以便與ART上的其他團隊保持同步和集成。每個PI都起始於團隊的PI計劃，他們構建團隊的PI目標，再匯總成項目群的PI目標，這些目標有助於指導團隊的迭代執行。
團隊會按照事先確定的迭代目標，計劃和執行迭代，每個迭代的時間盒為兩周。每個迭代提供有價值的新功能增量，迭代過程按照以下模式循環進行：迭代計劃、承諾交付一些功能 、通過構建和測試用戶故事執行迭代、演示新功能、執行迭代回顧，在下一個迭代再重複進行這些活動。在每次迭代結束時，團隊也需要支持係統演示，它是ART的關鍵集成點。在一個包含多個ART的大型價值流中，團隊還需要支持解決方案的演示，整個解決方案由多個ART全麵集成和測試，進行整體演示。
創新與計劃（IP）迭代為團隊提供了一個探索和創新的機會，有專門的時間用於計劃、回顧並通過正式和非正式渠道進行學習。如果發布處於PI的邊界上，團隊需要做最終的係統審核、驗證和文檔工作。為了能提供一個緩衝，團隊不會在IP迭代中計劃用戶故事的實現，所以對於每個PI而言，資源利用率不會達到100%。這樣做增加了流動、吞吐量和交付的可靠性。
PI的時間盒可以用於將大型的、係統級的功能聚合為有價值且可評估的項目群增量。這些功能可以在PI的邊界上進行發布，也可以更加頻繁的發布。項目群應該有節奏地開發，並支持任何時間的發布。
每個PI的迭代數量
SAFe把開發周期分為PI內的一係列迭代。在SAFe全景圖中描述了如何通過PI計劃會議啟動一個PI，接下來是4個實施迭代，最後是1個創新與計劃迭代。這種模式具有啟發性，不過有些武斷，其實在一個PI中有多少個迭代是沒有固定規則的。經驗表明，PI持續時間一般是在8～12周的效果最好，並且傾向於最短的持續時間。
用戶故事和團隊待辦事項列表
團隊使用用戶故事來交付價值，產品負責人負責用戶故事的創建和接收。用戶故事承載客戶的需求，通過價值流進入到實現階段。團隊待辦事項列表由用戶故事和使能故事組成，其中大部分故事是在PI計劃中，當產品經理向團隊展示願景、路線圖和項目群待辦事項列表時進行確定的。在團隊層基本的需求管理流程是：用戶故事的識別、排序、排期、細化、實施、測試和接收。
參考資料
[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
3.2 敏捷團隊
敏捷團隊所向無敵。
——SAFe 語錄
摘要
正如敏捷宣言（2001年）中所描述的那樣，敏捷運動是軟件和係統開發方式的一個重要轉折點。SAFe正是基於這種變革而構建起來的，它通過授權敏捷團隊作為構建單元來創造和交付價值。
敏捷團隊是由獲得授權並富有激情的成員組成的。如果沒有這種有效的敏捷團隊，組織就無法將敏捷進行規模化，也無法實現企業級精益–敏捷開發的大型業務收益。精益–敏捷領導者的主要職責在於構建和指導這些敏捷團隊。
SAFe 敏捷團隊是一個跨職能小組，他們有能力和權力來定義、構建和測試解決方案價值，所有的這些活動都在一個短迭代的時間盒內完成。團隊應包含必要的成員來成功地交付價值，適當的時候由項目群層或者價值流層的專家提供支持。這也遵循SAFe的原則#9——去中心化的決策，通過授權團隊對需求和設計進行決策，從而讓每個團隊對自己的工作負責。
在SAFe中，敏捷團隊並非獨立的單元，而是作為敏捷發布火車的一部分，敏捷發布火車上的團隊相互協作，他們負有交付大型價值的責任。所有的團隊都在火車上，沒有團隊就無法組成火車。團隊在火車上運作，基於共同願景與其他團隊相互協作，並參與敏捷發布火車的關鍵儀式。團隊與火車是不可分割的，它們作為一個整體的價值遠大於每個部分簡單相加的總和。
詳述
敏捷團隊是由專職成員組成的一個小團隊（在Scrum中是5～9人），他們具有一些必備技能，可以在短時間盒內定義（細化和設計他們的組件/特性）、構建（實現這些組件/特性）以及測試（運行測試用例並驗證組件/特性）價值增量。
在敏捷發布火車中，敏捷團隊獲得授權、自我組織、自我管理並對滿足客戶需求和期望的交付結果負責。這些團隊開發軟件、硬件、固件，或者都有所涉及，但通常情況下，團隊具備交付特性所必要的屬性。
企業將工作交予團隊和火車，而不是把人員分配到工作任務上，從而有助於創建團隊，以及規模化團隊，而且這些團隊都是長期存在的，並且專注於持續提升交付解決方案的能力。在這種情況下，SAFe 與傳統方式有所不同，傳統方式中是由經理來指導個人活動的；而在SAFe中是由團隊來決定構建什麼，以及如何構建他們的特性和組件。精益–敏捷領導者為團隊提供願景、領導力和自主權，從而培養和促進高績效團隊。這將不再需要給團隊的每個成員分配工作任務，而把去中心化的決策方式交到了團隊成員的層級。
角色和責任
SAFe摒棄了職能式的、基於筒倉的，以及階段–門限的開發模型。在那些模型中，用戶價值是在漫長的軟件生命周期最後階段，依賴於各個獨立職能部門的輸入而進行交付的。敏捷團隊執行或參與所有這些職能，在每個迭代中都會進行價值的交付：
團隊負責管理自己的工作。
團隊估算工作的大小和複雜度。
團隊在架構指導下根據所關注領域決定技術設計。
團隊承諾在迭代或項目群增量時間盒中完成的工作。
團隊負責價值和構建，從而持續提升交付成果的質量。
團隊承諾不斷地提升工作方式。
緊密合作
團隊隻有通過不斷溝通和合作，以及快速、有效和授權的決策能力，才能完成他們所承擔的責任。如果有可能的話，團隊最好能夠在同一地點，每小時、每天、每周都進行溝通。標準的團隊會議要依賴於所選擇的框架，但可能包括每日站立會議、迭代計劃、團隊演示，以及每個迭代最後的回顧。每個團隊成員都完全專注於單一的團隊，在每周的工作時間內緊密合作。團隊成員和其他團隊持續並積極合作，對依賴進行管理並解決障礙。
團隊成員之間的關係完全基於彼此的信任，而共同的任務、共同的迭代目標和團隊的PI目標有助於促進信任的達成。團隊的合作通過持續的反饋環不斷提高，這樣的反饋模式也構建了團隊的持續學習環。每一次真實的價值交付，都能增進信任，降低不確定性和風險，並有助於提升團隊的自信。敏捷團隊的激勵因素來自於共同的願景和向客戶交付價值的承諾。
團隊可以選擇敏捷方法
SAFe 團隊所使用的敏捷實踐，主要基於Scrum和團隊看板。大部分 SAFe 團隊應用Scrum作為基本的項目管理和交付框架。Scrum產品負責人參與並支持去中心化的決策製訂，而這對於團隊的授權是至關重要的。Scrum Master 支持團隊達成交付目標，並幫助構建一個高績效和自我管理的團隊。
其實Scrum也並不是唯一可用的實踐。團隊通過采用注重用戶體驗（UX）的工程實踐和內建質量的多種實踐，來推動有紀律的開發和質量。這些實踐包括集體所有權、結對工作、編碼標準、測試先行和持續集成，通過在開發過程中直接嵌入質量和運行效率而使事情變得更加精益。敏捷架構有助於完成高質量的解決方案開發。
然而，由於SAFe是基於流的係統，大部分團隊也在應用看板進行工作的可視化，建立WIP限製，並使用累積流圖來顯示瓶頸和關鍵機會來提升吞吐量。有些團隊（尤其是維護團隊、DevOps和係統團隊）經常將看板作為自己的基本實踐，Scrum中的計劃和承諾活動在這些團隊中可能無法有效應用，因為工作內容以活動為主並且是按需發生的，優先級的變化也更加頻繁。
敏捷團隊在火車上
SAFe敏捷團隊並不是獨立運行的，他們在敏捷發布火車上互相協作來構建可工作解決方案的有價值的增量。不管團隊是否應用Scrum、看板或兩者的結合，所有團隊都在一個共同的框架下運作，這個框架管理並指導整個火車的運行。這些團隊共同製訂計劃、共同執行集成和演示、共同學習，如圖3.2-1所示。
圖3.2-1 敏捷團隊共同計劃、共同集成和演示、共同學習
共同計劃
所有團隊共同參加PI計劃會議（如果可能的話，所有的團隊成員最好都要參加）。在計劃會議上，大家一起計劃和承諾一係列的PI目標。大家都有一個共同的願景和路線圖，共同協作以達成目標。在計劃和執行中，有清晰的工作授權。產品負責人是大型產品管理團隊的一部分（看板團隊有時對此角色使用不同的名稱）。每個團隊的待辦事項列表都是從項目群待辦事項列表中衍生而來的。
此外，作為敏捷發布火車的一部分，為了與經濟框架保持一致，所有敏捷團隊都使用相同的方法進行估算。這提供了一種有意義的方式，有助於決策者根據經濟情況決策並指導行動。雖然工作方式隨著使用的方法不同而不同，但結果往往是相同的，後續在“Scrum”和“團隊看板”的相關章節（3.4～3.6節）中會有進一步討論。
共同集成和演示
交付高質量的複雜係統需要團隊之間的緊密配合與相互協助。為此，團隊按照相同的敏捷發布火車節奏工作，在每個迭代開始時共同提出和溝通迭代目標。在敏捷發布火車同步時，各個團隊也會互相更新狀態，通過與其他團隊的成員進行交互，從而積極地管理相互之間的依賴關係。
當然，這裏所說的目標不是簡單地讓團隊向著目標進行“衝刺”，而是指讓係統向著有質量和有價值的增量進行“衝刺”。為此，團隊在內部和這個火車上，都應用了內建質量並在迭代內進行持續集成，同時所有團隊共同協作，從而可以在每個迭代完成時進行係統演示。
共同學習
所有SAFe的團隊成員都參與持續改進（參見1.4節中的第4個支柱）。除了團隊級別的回顧會議和隨時發生的流程提升之外，團隊也會參與更大的檢視和調整會議，通過這種方式識別優先級，按優先級對改進故事進行排序，並將其放入後續的PI計劃會議中進行處理。用這種方式，團隊完成了一個迭代，敏捷發布火車完成了一個PI，就可以讓“環路閉合”。當然，學習並非僅在回顧會議中進行，學習也是在實踐社區中不斷發生的，實踐社區的建立可以幫助個人和團隊不斷提升本職能和跨職能的技能。
參考資料
[1] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.
[2] Lencioni, Patrick. The Five Dysfunctions of a Team: A Leadership Fable. Jossey-Bass, 2002.
[3] Cohn, Mike. Succeeding with Agile: Software Development Using Scrum. Addison-Wesley, 2009.
[4] Manifesto for Agile Software Development. https://agilemanifesto.org/.
3.3 產品負責人
業務人員和開發人員必須相互合作，項目中的每一天都不例外。
——敏捷宣言
摘要
產品負責人（Product Owner，PO）是團隊的一員，負責定義用戶故事和確定團隊待辦事項列表的優先級，從而銜接項目群優先級事項的執行，並維護團隊所負責的特性和組件在概念和技術上的完整性。產品負責人是質量保證的關鍵人物，並且是團隊中唯一有權力接收已完成用戶故事的人。對於正在向敏捷方式轉型的企業來說，產品負責人是一個新的並且非常重要的角色。產品負責人通常是全職的，一個產品負責人通常可以支持一個團隊（最多兩個團隊）。
該角色是開發團隊與外界的重要接口，例如與產品經理（負責項目群待辦事項列表）合作，為PI計劃會議做準備。
詳述
產品負責人是敏捷團隊的成員之一，他是團隊與客戶之間的接口，負責與產品管理人員以及其他利益相關者（包括其他產品負責人）協作來確定團隊待辦事項列表中用戶故事的優先級，以便解決方案能夠有效處理項目群優先級事項（特性/使能），同時保持技術的完整性。理想情況下，產品負責人與團隊的其他人在同一地點辦公，產品負責人與團隊擁有同一個經理、擁有同樣的激勵機製和文化。但是產品負責人也會參加產品經理的會議討論有關計劃、待辦事項列表和願景的梳理等。
責任
SAFe產品負責人的主要責任如下。
籌備和參加PI計劃會議
作為產品管理團隊的一員，產品負責人積極參與項目群待辦事項列表細化和準備PI計劃會議的工作，同時也積極參與PI計劃。在PI計劃之前，產品負責人更新團隊待辦事項列表，審查和參與製訂願景、路線圖和進行內容展示。
在PI計劃期間，產品負責人參與用戶故事定義，為團隊澄清產品需求，以便團隊進行用戶故事估算和用戶故事排序，並為項目群增量起草團隊目標。
迭代執行
待辦事項列表梳理——產品負責人的主要職責是從係統架構師/工程師和其他利益相關者那裏獲得輸入信息，並構建、裁剪和維護團隊待辦事項列表。待辦事項列表主要是由用戶故事組成，但也包括缺陷和使能。待辦事項列表基於用戶價值、時間和其他團隊依賴關係進行優先級排序，團隊依賴關係在PI計劃會議上確定並在PI執行期間進行優化。
迭代計劃——作為籌備迭代計劃工作的一部分，產品負責人審查和重新排定待辦事項列表（參見3.5節中的“迭代計劃”的內容），有時還需要與其他產品負責人協調相互的依賴關係。在迭代計劃會議上，產品負責人負責澄清用戶故事細節和用戶故事優先級，並負責接收最終迭代計劃。
準時製（Just-in-Time，JIT）的用戶故事細化——待辦事項列表中的大部分條目都會細化成用戶故事進行實施。這可能會發生在迭代之前、迭代計劃過程中或迭代執行過程中。雖然任何團隊成員都可以寫用戶故事和接收標準，但產品負責人對保持整個流程的順暢性負有主要責任。通常比較好的做法是，在團隊待辦事項列表中的用戶故事可供兩個迭代執行。如果故事過多，則會導致產生隊列等待；如果故事過少，則會抑製流動的進行。
支持ATDD——產品負責人參加用戶故事接收標準的製訂和起草，並提供示例以支持ATDD（Acceptance Test-Driven-Development，接收測試驅動開發）規範製訂。可參考8.2節的內容。
故事接收——產品負責人是唯一可以接收用戶故事完成的團隊成員。接收用戶故事包括驗證用戶故事符合接收標準，通過了適當和長期的接收測試，或者通過其他方式能夠驗證用戶故事滿足完成的定義。通過故事接收，產品負責人履行了質量保證的職能，主要側重功能是否適合使用。
理解使能工作——雖然產品負責人無需推動技術決策，但是他們需要理解後續使能工作的範圍，並與係統和解決方案架構師/工程師協同工作來幫助做決策，並為那些實現新商業功能的關鍵技術基礎設施排定順序。這通常需要進行人力物力安排，可參考4.8節中的描述。
參加團隊演示和回顧——作為團隊不可或缺的成員和團隊需求負責人，產品負責人在團隊演示、評審和接收用戶故事，以及迭代回顧（參見3.12節）中發揮著重要作用。在回顧活動中，團隊成員聚集在一起，改進流程。產品負責人也積極參與敏捷發布火車的“檢視和調整”工作坊。
項目群執行
迭代和團隊都服務於一個更大的目標——頻繁、可靠和持續地發布以便實現解決方案的增值。在每個PI的過程中，產品負責人與其他團隊的產品負責人協調各團隊的功能相關性，通常產品負責人需要每周參加產品負責人協調會議來保障這一點。詳細信息請參閱4.10節。
產品負責人在為項目群和價值流利益相關者進行演示的過程中也起到關鍵作用。
檢視和調整
團隊可以在PI的檢視和調整工作坊上來處理那些較大的障礙。在工作坊中，各團隊產品負責人協同工作來定義和實施改進故事，以提高項目群的速度和質量。
PI係統演示在檢視和調整工作坊中進行，產品負責人在為項目群利益相關者進行PI係統演示時發揮重要作用。
產品負責人也參與PI係統演示的準備，以確保能夠為利益相關者展現解決方案的最關鍵環節。
內容授權
對於大規模項目，一個人不可能身兼數職——既處理產品和市場策略也服務於某一個敏捷團隊。因為在項目群中，產品經理和產品負責人分擔“內容權力”，所以職責劃分是非常重要的。通常的職責劃分如圖3.3-1所示。
產品經理 產品負責人 團隊
麵對市場/客戶。識別市場需求。與市場/業務人員在一起辦公。
負責願景、路線圖、項目群待辦事項列表、定價以及ROI。
通過對特性和使能排定優先級來實現PI目標並發布內容。
建立特性的接收標準。 協調解決方案、技術和團隊交互。與團隊一起辦公。
參與製訂願景和項目群待辦事項列表。負責團隊待辦事項列表及實施。
定義迭代和故事。接收迭代增量。
通過合理排序故事實現迭代目標和迭代內容。
建立故事接收標準，接收故事並發布到產品基線。 麵對客戶/利益相關者。
負責故事估算並實現其價值。
參與意圖式架構製訂。負責浮現式設計。
協助細化待辦事項列表和創建故事。
與其他團隊進行集成。
圖3.3-1 發布內容治理
產品經理、產品負責人和敏捷團隊的人員配比
項目取得成功的一個重要因素是企業內各個崗位的人員配比。不合適的崗位人員配比會嚴重影響執行速度。因此，產品經理、產品負責人以及敏捷團隊的人數必須是大體平衡的，以便正確地駕駛敏捷發布火車，否則整個係統將花費大量的時間在等待定義、澄清和接收等工作中。SAFe框架建議的人員配比如圖3.3-2所示。
每個產品經理通常可以支持最多4個產品負責人，每個產品負責人最多可以負責1～2個敏捷團隊的待辦事項列表。
參考資料
[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011, chapter 11.
[2] Larman, Craig, and Bas Vodde. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley, 2010, chapter 3.
3.4 Scrum Master
好的領導者首先必須是個好仆人。
—— 羅伯特·K·格林裏夫
摘要
大多數SAFe團隊采用的是ScrumXP，這是一種用於有效地進行敏捷項目管理和產品交付的輕量級的團隊框架。Scrum Master的角色由團隊中的一員承擔，主要職責是幫助自組織、自我管理的團隊實現其目標。Scrum Master通過教學和指導SAFe，實施並支持SAFe的原則和實踐，識別和消除不利因素的影響，引導流動。
SAFe團隊從Scrum、看板、XP和其他精益敏捷方法中挑選最佳實踐來調整他們的過程。雖然Scrum Master這個角色主要基於標準的Scrum模型，但是大多數團隊——甚至是那些基於事務或工作流的團隊（主要應用看板）——也有效地采用了Scrum Master這個角色來幫助團隊達成目標，並協調與其他團隊的溝通活動。
詳述
Scrum Master對於敏捷團隊來說是一個專門的角色，他會花大量的時間幫助團隊成員進行溝通、協調、合作；一般來說，Scrum Master會協助團隊達成他們的交付目標。Scrum Master是基於團隊的管理代理人和仆人式領導，他通過有效的敏捷實踐，幫助團隊實現自組織、自我管理和交付工作。Scrum Master支持和實施Scrum流程的規則以及團隊認可的其他規則。Scrum Master也幫助團隊在敏捷發布火車上與其他團隊進行協調配合，在必要的時候向管理層溝通當前的狀態。
在團隊中的責任
優秀的SAFe Scrum Master是基於團隊的仆人式領導：
展現精益–敏捷的領導力——展現出具有精益–敏捷思維的領導者行為。幫助團隊擁抱SAFe的核心價值觀，采納和應用SAFe原則，並實施SAFe實踐。
支持規則——雖然Scrum的規則是輕量級的，但依然是規則，Scrum Master負責遵循實行這些規則，包括Scrum規則、在製品限製，以及團隊認可的其他規則。
引導團隊向著目標前進——Scrum Master接受培訓並成為團隊引導者，不斷地挑戰舊有的軟件開發範式，同時保持團隊專注於迭代目標。Scrum Master在質量、可預測性、流動和速度等方麵幫助團隊。以當前產品增量目標為基準，幫助團隊關注於日常工作和迭代目標。
領導團隊進行持續改進——幫助團隊進行改進，並對自己的行為負責。引導團隊進行回顧。教給團隊如何解決問題，並幫助團隊成為自身問題的解決者。
引導會議——引導所有的團隊會議，包括每日站會、迭代計劃、團隊演示和迭代回顧。
支持產品負責人——在團隊中產品負責人有專門的職責。Scrum Master支持產品負責人的工作，促進健康的團隊內部優先級和範圍的動態調整。
消除障礙——很多阻礙問題都超出團隊授權，或是需要來自其他團隊的協助。Scrum Master需要積極解決這些問題，以便團隊能夠保持專注於迭代目標的達成。
宣傳推廣SAFe質量實踐——SAFe提供了指導，幫助團隊持續改進交付物的質量，達成完成定義（DoD）。Scrum Master幫助團隊培養技術自律和匠藝精神文化，這是卓越敏捷團隊的標誌，Scrum Master還培育和支持相關實踐的社區。
建立高效團隊——致力於不斷提高團隊的動力和績效。幫助團隊管理人際衝突、挑戰和成長機會。必要時可以把人員問題上升到管理層，但這僅限於通過內部解決無法達成目標時才進行。Scrum Master 還可以通過人事變動幫助團隊和個人開展工作。
保護和溝通——與管理層和外部利益相關者進行溝通。保護團隊不受那些不可控插隊工作的影響。
在敏捷發布火車上的責任
Scrum Master幫助協調團隊之間的合作，以便團隊真正地成為“在火車上的團隊”。
與其他團隊進行協調——一般而言，Scrum Master作為代表，參加Scrum of Scrums會議，把會議上的信息傳達回團隊（細節信息參見4.10節）。經常和係統團隊、用戶體驗、DevOps、共享服務，以及發布管理團隊進行協調。需要注意的一點是，團隊間協調的責任不能完全委托給Scrum Master，每一個團隊成員在這方麵都負有責任。
引導敏捷發布火車儀式的準備和就緒——幫助團隊準備敏捷發布火車活動，包括PI計劃會議，係統演示，以及檢視和調整工作坊。
協助估算——指導團隊建立標準化的估算方法，幫助團隊和敏捷發布火車進行大型特性及能力的估算。
角色來源
Scrum Master可以是全職或兼職的，這取決於團隊規模、環境和其他職責。然而對企業來說，接受每個敏捷團隊有一個全職Scrum Master是一件有挑戰的事情。畢竟，如果企業組建了100個新的敏捷團隊，將100個開發團隊成員全職地放在這個新職責上，而不再做開發或測試工作，這看起來不太經濟，而且行政上的可操作性也不高。就更不要說給每個團隊配備一個全職或者兼職的顧問，來幫助團隊學習和掌握新的思想了。可能在團隊有機會證明這個角色的價值之前，這種變革就已經胎死腹中了。
因此，SAFe提供了務實的方法和假定，通常情況下，Scrum Master是由敏捷團隊的成員、項目經理、團隊領導或者其他角色兼職擔任。然而在SAFe推行的初始階段，這個角色的活動會很密集，這時候組織會發現讓外部顧問指導團隊，使團隊在Scrum和SAFe執行中熟練起來很有益處。通常來說，外部的Scrum Master教練和谘詢師能夠同時指導多個團隊。
參考資料
[1] www.scrumalliance.org.
[2] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
3.5 ScrumXP
“……一套整體的，或者說是‘橄欖球’的方法——團隊在來回傳球的過程中作為一個整體而行動，也許能更好地服務於當今的競爭需求。”
——野中鬱次郎和竹內弘高，《新型的新產品開發遊戲》
摘要
多數SAFe團隊采用Scrum作為他們基本的團隊級別項目管理框架。Scrum是一個輕量的、有紀律的、高效的過程，適合於跨職能、自組織團隊在SAFe環境下使用。Scrum規定了三個角色：Scrum Master、產品負責人和開發團隊成員（參考資料[3]）。Scrum Master是仆人式領導，他幫助團隊遵守Scrum規則，並且清除團隊內外的阻礙。產品負責人負責定義需求，他是團隊待辦事項列表的負責人（在Scrum中稱為產品待辦事項列表，在SAFe中稱為團隊待辦事項列表）。通過將精益質量管理實踐延伸到軟件開發，並結合來自於極限編程（XP）的工程實踐，SAFe的ScrumXP團隊為SAFe提供了基礎的敏捷單元。
但是，SAFe的ScrumXP團隊當然並不是孤立的，每個團隊都是更大的敏捷發布火車的一部分，團隊之間相互協作構建大型的係統，從而努力達成目標。為此，為了確保整個係統的迭代和增量式演進，所有的敏捷團隊都會共同計劃、共同集成和演示、共同學習。
詳述
ScrumXP敏捷團隊是一個包括5～9人的自組織、自管理的跨職能團隊，並且盡可能工作在一起。這樣的規模和結構優化了團隊溝通、互動和交付價值的能力。自組織意味著團隊中沒有團隊主管或經理角色來給團隊分配任務、估算工作量、為特定的目標做承諾，或是製訂明確的解決方案。團隊在獲知迭代的意圖之後，獨立地決定在意圖範圍內哪些是他們可以實際承諾的，以及他們將如何構建這個價值增量。
團隊是跨職能的，因此具備用於交付增量的所有角色和技能。團隊自組織和跨職能的性質，以及持續地溝通、有建設性的衝突、充滿活力的互動，這些都可以為團隊成員創造一個高效的團隊氛圍和更愉快的工作環境。
Scrum定義了兩個特殊的角色：產品負責人和Scrum Master，他們是SAFe ScrumXP 團隊的成員，各自被賦予特定且具體的職責。每個角色在本書中都有一個同名的章節做詳細闡述。下文是對其各自職責的一個概括。
產品負責人（PO）
每個ScrumXP團隊有一個產品負責人負責團隊待辦事項列表。產品負責人與團隊其他成員的互動是重要的、日常性的，並且高度聚焦於工作的事項。因此，最有效的模式是每個團隊擁有一個專職的產品負責人，或者最多兩個團隊擁有一個產品負責人。這有助於產品負責人在迭代執行過程中對團隊進行有效的支持，包括回答問題，在開發中提供更多的功能細節，評審、接收並將已完成的故事發布到產品基線。
Scrum Master（SM）
Scrum Master是團隊的引導者和敏捷教練，其主要職責包括：確保團隊遵循開發流程，向團隊提供Scrum、XP和SAFe實踐的培訓，以及提供持續改進的環境。Scrum Master也負責領導團隊移除阻礙。Scrum Master可以是全職的，或是由團隊成員兼職。此外，一些專職的Scrum Master可以支持2～3個Scrum團隊。
Scrum流程
Scrum流程本身是一個輕量級的項目管理框架，能夠促進快速、迭代式高級解決方案能力的構建，並且有利於持續改進以支持更高效的產能和更好的交付。其流程圍繞著迭代進行（注：Scrum采用術語“衝刺”（sprint），SAFe采用更通用的術語“迭代”（iteration），迭代是一個短周期時間盒，在SAFe中是兩周，在此期間團隊定義、開發、測試和接收結果。以下是Scrum流程的進一步描述。
迭代計劃
迭代開始於迭代計劃，該計劃也是一個遵循時間盒（不超過4小時）的會議，產品負責人可以展示迭代相關的故事。團隊評審故事，定義接收標準，必要時將大故事拆分成更小的故事，估算故事點數，最後根據已知的團隊速度（每個迭代交付的故事點數）承諾可以完成的故事。許多團隊進一步將故事拆分成任務，以小時為單位來估算任務，以此完善對工作的理解。最終，團隊承諾一係列的迭代目標。
其實早在迭代開始之前，Scrum團隊就通過梳理團隊待辦事項列表為新迭代準備內容，以確保團隊對於將在新迭代中交付的工作有一個預先的了解。
可視化工作
在執行過程中，團隊以每隔幾天就可以交付一兩個故事的速度進行開發和測試。這種串行的工作方式限製了在製品數量，並幫助避免了迭代瀑布化。團隊采用大型可視化信息雷達（big visual information radiators，BVIR）掌握並跟蹤迭代執行過程。在整個迭代過程中，團隊的故事板用於可視化故事及其進度。在故事板中團隊往往把每一列作為一個實現的步驟，隨時間從左至右移動故事，如圖3.5-1所示。
圖3.5-1 團隊故事板示例
有些團隊在部分步驟中應用在製品限製，從而在迭代中創造“拉動”過程，持續平衡工作以提高產能。事實上，很多團隊把Scrum和看板的最佳實踐結合起來，以促進工作的流動性。在這種情況下，簡單的故事板演變成了結構化的看板板（Kanban board）。更多信息可以參見3.6節的內容。
協調每日站會
團隊每天都舉行一個正式的儀式——每日站會（Daily Stand up Meeting，DSU），用於了解團隊目前的狀況，提出問題，以及向其他團隊成員尋求幫助。在會議中，每個團隊成員描述昨天做了什麼，今天將要做什麼，以及遇到的任何阻礙。由於這是一個每天進行的協調會，因此Scrum Master應該保持會議簡短且聚焦，每日站會不應超過15分鍾，而且是在故事板前站立完成的。
團隊溝通並不僅限於每日站會，團隊成員在整個迭代過程中保持互動。溝通的便利性是ScrumXP推薦團隊成員盡可能在一起工作的主要原因。
價值演示和過程改進
在每個迭代的結尾，團隊要進行一次團隊演示和迭代回顧。在演示過程中，團隊展示迭代中每一個完成的故事，其總和就是此次迭代團隊的價值增量。這不是一個正式的狀況報告，而是一次有形的迭代成果的評審。接下來，團隊進行一個簡短的回顧，反思在迭代過程中，哪些地方做得好，以及當前有什麼阻礙。然後，團隊生成一些改進故事，放入下一個迭代執行。
內建質量
正如一條SAFe的宗旨所說，“你不能規模化糟糕的代碼。”因此，SAFe的一個核心價值觀是“內建質量”。內建質量需要從代碼和組件層麵抓起，由此生成解決方案；否則，要想確保從組件集成到係統和解決方案過程中的質量，就是一件非常困難的事情，有時候甚至是完全做不到的。
為了確保團隊在代碼和組件方麵的內建質量，SAFe指出了5種來自於極限編程（XP）中的工程和質量實踐，用以擴充Scrum項目管理實踐。它們是：持續集成、測試先行、重構、結對工作和集體代碼所有權。除了這5個實踐之外，一些團隊還會采用更多的極限編程實踐，如結對編程、隱喻（參考資料[2]）。
ScrumXP團隊“在火車上”
如果一個大型係統包括了不同的技術平台，涵蓋硬件、軟件以及係統工程等多種領域，在這種情況下，即使團隊是跨職能的，讓一個7、8個人的團隊交付最終用戶價值也往往是不現實的，我們需要多個團隊一起協作。為此，SAFe敏捷團隊運作在敏捷發布火車之上，敏捷發布火車可以幫助對齊任務目標，提供協作環境，使團隊可以相互協作以具備構建更大型解決方案的能力。作為敏捷發布火車的一部分，ScrumXP團隊共同計劃、共同集成和演示、共同學習，如圖3.5-2所示。
有關團隊如何參與“共擔職責的項目群”的更多細節，參見3.2節的內容。
ScrumXP 團隊領導力
管理者通常不是跨職能團隊的一部分。然而，最初的團隊組建往往會圍繞著特性、組件和子係統來進行，而敏捷發布火車的設計和架構，往往是管理者的職責，同時要以團隊的輸入為基礎。因此，團隊管理人員的日常管理職責存在一個質的轉變，即從指導團隊具體技術實現的專家管理者，轉變為使能員工、發展員工的精益–敏捷領導者。
圖3.5-2 SAFe敏捷團隊共同計劃，共同集成和演示，共同學習
參考資料
[1] Kniberg, Henrik. Scrum and XP from the Trenches. lulu.com, 2015.
[2] Beck, Kent and Cynthia Andres. Extreme Programming Explained: Embrace Change, 2nd edition. Addison-Wesley, 2004.
[3] Sutherland, Jeff and Ken Schwaber. https://www.scrumguides.org.
3.6 團隊看板
造成庫存擠壓的唯一原因，是因為使用了過量的人力。
——艾利·高德拉特
也有可能是因為職責劃分太過專門化了？
——本書作者
摘要
盡管出於不同的目的，看板係統廣泛應用於SAFe的投資組合、價值流、項目群和團隊等各個層級。本節將闡述團隊看板，一種可以幫助團隊通過可視化工作流來促進價值流動、建立在製品限製、度量生產能力和持續改進流程的方法。
SAFe團隊可以自行選擇敏捷方法，多數團隊會選擇Scrum方法，它是一種輕量級、有效和普遍適用的管理方法。開發團隊也會采用極限編程，從而專注在軟件工程和代碼質量上。有些團隊，特別是係統團隊、DevOps團隊，以及維護團隊，會選擇看板來作為他們主要的敏捷方法。在有些場景下可能會導致團隊選擇使用看板方法，比如快速響應、救火式的工作特點、快速變化的優先級、“在下個迭代裏確切計劃要做哪些工作”是沒有意義的行為等。本節將描述如何使看板係統較好地適用於SAFe敏捷團隊，與此同時，這些SAFe團隊是“在火車上的”，並且需要遵循特定的火車規則。
詳述
通常，看板被描述為一個拉動係統，當團隊有能力勝任某項工作時，是通過“拉動”而不是“推動”的方式來完成這項任務的。本節將討論團隊看板，一種可以幫助團隊通過可視化工作流，從而促進價值流動、建立在製品限製、度量生產能力，以及持續改進流程的方法。
看板係統是建立在工作流狀態基礎之上的，大多數狀態是有在製品（WIP）限製的，即一個新的工作項隻有在該狀態的WIP小於限製的時候，才能夠加入到該狀態的隊列裏。有一些狀態是沒有WIP限製的，例如開始和結束狀態。
WIP限製由團隊自己定義和調整，從而快速適應複雜係統開發中流動的變化。在SAFe裏，團隊看板應用於敏捷發布火車的節奏與同步中。這確保了團隊間的對齊，依賴管理，以及快速地、基於集成的學習環，也為推進更大型的解決方案提供了客觀證據。
看板描述
看板（Kanban，意為“可視化的信號”）的本質是一個用於可視化和管理工作的方法。雖然對於如何將看板用於軟件開發有很多種理解，但一般來講用於開發的看板係統包括以下幾個主要方麵：
係統包含一係列需要經曆的工作狀態的定義；
所有的工作都是可視化的，每個任務的進度都會被跟蹤；
團隊對於每個工作狀態的在製品（WIP）限製數達成一致，並在必要時更改WIP以優化工作流；
團隊製訂工作管理政策；
度量流動。工作項從進入係統開始被跟蹤，直至離開；這樣就可以持續地指示在製品數量以及當前的前置時間（Lead Time，一個工作項通過係統所需的平均時間）；
通過分配服務等級進行排序，而服務等級是由延遲成本決定的。
可視化流動和限製WIP
啟用看板之初，團隊通常會創建一個大致的工作流程，並設定初始的WIP限製。圖3.6-1展示了一個團隊的初始看板例子，他們目前的工作流程是：分析–評審–構建–集成–測試。
在圖3.6-1中，該團隊還決定創建兩個緩衝區（“準備就緒”）來更好地管理流動的變
化。一個是在“評審” 狀態之前，這可能需要團隊外的領域專家（產品經理或者其他專家），而這些專家的工作時間有限或者不均衡。另外一個緩衝區是在 “集成和測試” 狀態之前，在這個團隊的例子裏，需要使用共享的測試設備和資源。因為集成和測試是由同一群人在同一個環境上完成的，所以這兩個步驟被視為同一個狀態。考慮到成本因素，團隊允許對
“評審”與“集成和測試”兩個狀態設置更高的WIP。
圖3.6-1 團隊初始看板示例
團隊看板的改進是迭代式進行的。在定義初始流程和WIP，並且執行一段時間之後，團隊的瓶頸將會顯現出來。如果沒有的話，團隊可以梳理工作的流程，或進一步降低WIP，直至某些狀態出現明顯的空閑或者過載，這會有助於團隊向更優化的流進行調整。通過驗證假設，以調整WIP，從而使工作流程步驟得以合並、拆分，或者重新定義。
度量流動
為了更好地理解和改進流動與流程，看板團隊采用客觀的度量，包括平均前置時間、WIP、吞吐量。其中常用的一種度量方式是累積流圖（Cumulative Flow Diagram，CFD），如圖3.6-2所示。
圖3.6-2 累積流圖展示了前置時間和WIP按天的變化
每一個工作項都是有時間戳的，包括其進入工作流的時間（從團隊待辦事項列表拉入開始實施狀態）及完成時間。“到達曲線”表示拉入工作流的工作項數量，“離開曲線”表示完成並被接收的工作項數量。兩條曲線在X軸的差值是平均前置時間——也就是一項工作通過係統所花費的時間。在Y軸的差值是WIP——也就是在任何時間點上，係統中所有工作項的數量。吞吐量——指在給定時間段內完成的工作項數量，它也是一個非常關鍵的指標。SAFe中看板團隊以迭代為工作節奏，因此會度量每個迭代的故事吞吐量。
累積流圖為團隊提供數據，以計算他們迭代的吞吐量。
為此，團隊用平均WIP除以平均前置時間，得到平均每天可以處理的故事數量，然後再乘以14。其結果就是每個迭代以故事數量計算的平均吞吐量，這有助於製訂計劃。（這對於計算團隊速度也是很重要的，相關內容將在本節後麵描述。）
累積流圖也將明顯的流動變化進行了可視化。這可能是團隊沒有意識到的係統內部阻礙，或者是外部力量幹擾了流動。累積流圖是一個客觀的度量工具，可以幫助看板團隊持續改進。
通過服務等級改進流動
此外，團隊需要有能力管理依賴、確保與裏程碑保持一致。看板使用服務等級機製幫助團隊優化工作項的執行。服務等級提供了一種方法，基於延遲成本區分工作項。對於每一類服務等級都有一個特定的執行策略。例如：
1.標準——大部分工作項都屬於這個服務等級：沒有特定的日期依賴的新功能開發。對於標準類別的任務，它的延遲成本是線性的，它的價值隻有在完成交付的時候才會達成，但對它沒有固定完成日期的要求。
2.固定日期——有固定日期的工作項意味著裏程碑和預先設定日期的依賴關係。其延遲成本是非線性的。需要及時“拉動”這些工作任務進入開發狀態，以期按時交付。有些工作項需要額外的分析，以便調整期望的前置時間。有些工作項在落後於計劃進度時需要將其類別改為“加速”。
3.加速——“加速”類別工作項有著難以接受的延遲成本，因而需要立即引起團隊關注；它可以在違反當前WIP限製的情況下被“拉動”進入開發狀態。通常在係統裏同一時間內隻允許有一個“加速”類別的工作項，並且團隊可以設定“蜂擁”策略，以便該工作項迅速通過係統。
如果團隊發現很多工作項都需要加速，那麼係統極有可能是超負荷負載的。有可能是需求超過處理能力，也有可能是輸入流程缺乏紀律。這時需要對工作流程重新進行調整。
如圖3.6-3所示，通常情況下服務等級被可視化為“泳道”。
此外，團隊可以把不同類別的工作項對應到特定顏色上（參見4.11節），如“新功能”“研究探針”（Spike）“建模”等，這有助於團隊進一步理解正在執行的工作項。
密切關注工作流的結構可以給看板團隊提供改進的機會。例如，累積流圖中發生的變化可能揭示了平均WIP在增加（這將導致前置時間拉長）。這也許是某種更深層次問題的一個表象，現在團隊有能力做出識別。定期省思和調整流程是獲取高度可視化益處的必要措施。
圖3.6-3 看板上的服務等級
SAFe 看板團隊“在火車上”
SAFe 看板團隊在更大的框架下運作，這需要多個敏捷團隊甚至跨多個敏捷發布火車來構建一個解決方案。為了實現這一目標，團隊除了需要遵守常規看板原則之外，還需要遵守特定的SAFe規則。這些規則包括：團隊之間共同製訂計劃，共同集成和演示，共同學習，如3.2節描述的那樣。共同製訂計劃是一個值得進一步討論的話題，如下文所述。
估算工作內容
通常，看板團隊在估算或者任務分配上花費的時間沒有Scrum團隊那麼多。團隊查看要做的工作項，把較大工作項進行必要的拆分，然後致力於完成拆分出來的故事，通常不會在意故事的大小。然而，SAFe團隊需要具備對PI計劃的需求進行估算的能力，以及參與對較大工作項做經濟估算。同時，為了能夠做預測，需要對團隊的速度、其他團隊的速度，以及敏捷發布火車的速度有一致的理解。
為估算建立一個共同的起點
最初，一個新的看板團隊並不清楚其吞吐量，因為吞吐量是基於曆史數據計算出來的。啟動之初，SAFe 看板團隊必須有一種方法來估算工作，這往往從第一個PI計劃會議開始。這在一定程度上與Scrum團隊一致，看板團隊的初始能力估計是從標準化估算開始（參見3.9節的描述）。然後，看板團隊把估算過的故事加入到迭代中，如Scrum團隊所做的一樣。團隊的初始能力是他們所假設的速度，至少在第一個PI時是這樣的。
計算“導出”速度
從啟動開始，看板團隊可以使用累積流圖來計算每次迭代的故事吞吐量（或者也可以先簡單地相加再計算平均值）。由此看板團隊通過用吞吐量乘以故事平均大小（通常是3~5點）來計算“導出”速度。這樣，SAFe Scrum團隊和SAFe 看板團隊都可以參與到大的經濟框架中來，從而為投資組合運行提供基本的經濟環境。
估算大的工作項
在投資組合和價值流層級，通常需要估算更大的工作項（諸如史詩或能力）來確定它們的潛在經濟可行性。此外，對敏捷發布火車和價值流路線圖的開發需要同時具備估算知識（工作項的大小），以及敏捷發布火車的速度（ART的吞吐量）。為了做到這點，看板團隊會把大的舉措分解為故事並進行估算，與Scrum團隊所采取的方式類似。這提供了更細顆粒度的解決方案來幫助估算大規模工作任務。故事用標準化的故事點數進行估算，這為企業提供了從各個團隊聚合估算的能力，而且在整個過程中避免了過度的爭論。
參考資料
[1] Anderson, David. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010.
[2] Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban. Pragmatic Programmers, 2012.
3.7 團隊待辦事項列表
待辦事項列表的定義：
1. 隱藏在舒適表麵下的大型列表
2. 未完成的任務或未處理資料的聚集
上述第一種待辦事項列表的燃盡速度緩慢，而第二種待辦事項列表的燃盡速度迅速。
摘要
團隊待辦事項列表代表了一個團隊為提升係統需要做的所有事情的集合，它包含了用戶故事和使能故事，其中大部分都來自於項目群待辦事項列表，有些則是來自團隊自己的具體場景。團隊待辦事項列表由產品負責人負責，雖然產品負責人是待辦事項列表的“責任人”，但這並不意味著隻有產品負責人可以創建用戶故事，而是需要產品負責人對工作進行優先級排序。
由於用戶故事和使能故事都是待辦事項列表的一部分，所以通過有效配置資源以確保投資可以在需求衝突中得到平衡，這一點顯得尤為重要。資源的配置需要把敏捷發布火車看成一個整體，並根據火車的需要進行協調。
詳述
雖然“待辦事項列表”看起來是一個簡單的概念，然而在其背後卻有許多微妙的影響。
待辦事項列表需要包含所有要做的事情，如果工作項處於列表中，那麼就需要被完成；如果工作項不在列表中，那麼就不會被完成。
待辦事項列表是一個“希望實現工作項”的列表，而不是一個承諾。工作項可被估算（推薦）也可以不用估算，但無論哪種情況都不會包括承諾該項工作的具體完成時間。
待辦事項列表有唯一的責任人——團隊的產品負責人。這樣可以保護團隊免受多方麵利益相關者的幹擾，因為每一個利益相關者的關注重點都有所不同。
所有的團隊成員都可以將自己認為重要的用戶故事放入待辦事項列表。
待辦事項列表包含用戶故事、使能故事和“改進故事”，其中“改進故事”是從團隊迭代回顧會議的結果中識別出來的改進內容。
團隊待辦事項列表是一個簡單而統一的形式，但也隱藏了敏捷在規模化過程中的複雜性。圖3.7-1說明了團隊待辦事項列表的三個主要來源。
圖3.7-1 團隊待辦事項列表的分解圖
項目群待辦事項列表中包括將要實現的特性，通常會計劃在敏捷發布火車中進行交付。在PI計劃會上，計劃在項目群增量（PI）中交付的特性會被分解成故事，並且暫時分配進入團隊待辦事項列表以便在下一個迭代進行實現。此外，也會計劃一些將來需要開展的工作，在這種情況下，團隊待辦事項列表也可以包含一些尚未拆分成故事的特性。有時需要由多個團隊共同交付一個特性，在這種情況下，就需要為相關團隊創建相應的工作，然後對其進行估算，並在團隊待辦事項列表中進行維護。
團隊也需要根據自己的實際情況開展工作。除了需要實現那些來自於特性的故事之外，團隊也會有一些自己創建的故事，比如新功能、重構、缺陷、研究探針，以及技術債等。這些由團隊自己創建的故事也需要加以識別，可以寫成使能故事，進行估算，並排序放入待辦事項列表中。
敏捷發布火車上的團隊並不是孤立存在的，不同團隊的待辦事項列表中的用戶故事可能會相互關聯，從而滿足利益相關者的目標。這些故事可能會包含對特性、能力甚至史詩故事的研究和估算探針，同時也會反映團隊之間的依賴關係，以及對外部的承諾。
通過容量分配優化價值交付和係統健康
與敏捷發布火車一樣，每個團隊都會麵臨待辦事項列表中內部和外部工作項的平衡問題，內部工作項包括維護、重構、技術債等；外部工作項是指立即能交付價值的新用戶故事。“永遠保持新功能的開發”在一定程度上比較有效，甚至可以立即滿足市場需要，但是這種效果將是短暫的，因為可能會由於沉重的技術債務而影響交付速度。為了避免速度的降低，以及推遲由於技術過時導致的大量係統更換，團隊需要持續關注解決方案的技術演進，及時修複缺陷和改進提升，從而保證現有客戶的滿意度。
產品負責人對於工作項的排序是一件複雜和極具挑戰的事，他需要在3種不同類型的工作中進行價值比較：1）缺陷；2）重構、重新設計和技術升級；3）新的用戶故事。而且這些工作項按需發生，持續增加。大多數情況下，工作項來自項目群待辦事項列表，然後通過容量分配有助於團隊形成一種機製，用於明確在給定時間周期內開展哪些類型的活動，如圖3.7-2所示。
圖3.7-2 團隊待辦事項列表的容量分配
一旦團隊做出決定，他們就可以從每個“切片”中選擇最高優先級的工作項，放入迭代中進行實現。對於那些在項目群中已經承諾的故事，在PI計劃的時候就已經進行了優先級的排定；但是對於團隊自己添加的本地故事，產品負責人需要按照價值/規模大小，或者采用WSJF（加權最短作業優先）進行優先級排序。此外，為了平衡長期的產品健康和價值交付，分配到各個工作項類型的百分比可能會有所不同（例如，在每個PI中都會有所不同）。
待辦事項列表梳理
在本節的討論中，可以看出待辦事項列表中的有些故事已經比較完善，並準備就緒可以進行下一步的實現了，這樣的故事不會帶來太大的風險和意外。因為，整個團隊都參與了討論，大家采取了基於流的方法，通常是每個迭代（或者每周）至少有一個團隊對將要實現的故事（有時也會討論特性）開展一個工作坊，進行討論、估算，並且建立初步的接收標準。
對於這個會議，業界沒有標準的術語，在SAFe 中稱為待辦事項列表梳理會，但是需要指出的一點是，待辦事項列表梳理是一項持續的工作，而不僅僅是一次會議就能解決全部問題的。應用接收測試驅動開發（ATDD）的團隊，通常會在前期投入更多的時間用於開發特定的接收測試，有時也會開展一些相關會議，稱為規格說明工作坊（specification workshop）。此外，由於多個團隊都在做待辦事項列表的梳理，可能會出現新的問題、依賴關係和故事。在這種方式中，待辦事項列表梳理的流程會有助於把當前計劃中存在的問題暴露出來，並升級到敏捷發布火車的同步會議中進行更進一步的討論。
參考資料
[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
3.8 迭代
我平生從來沒有做過一次偶然的發明。我的一切發明都是經過深思熟慮，嚴格試驗的結果。
——托馬斯·愛迪生
摘要
迭代是敏捷開發的基本組成單元，每個迭代都是一個固定的時間盒，團隊在這個固定時間內構建一個商業價值或產品功能的增量。SAFe的迭代長度是2周，這為團隊提供了一個開發產品特性和組件的基本開發節奏。在這個短周期之內，團隊需要完成迭代待辦事項列表中用戶故事的開發，與其他團隊的輸出結果進行集成，以及準備整個係統的演示等一係列工作。迭代是連續的，一個接著一個進行，以穩定的速度提供持續的商業價值交付。
迭代的節奏是SAFe提到的第一個節奏，SAFe項目群增量的時間盒更長，由一組和諧的短迭代組成。PI時間盒為敏捷發布火車上所有的團隊提供了一個外部節奏，團隊在這個時間盒裏共同計劃、共同集成和演示、共同學習成長。
詳述
由於快速學習是SAFe學習環的關鍵目標，所以敏捷團隊需要盡可能快地執行PDCA （Plan-Do-Check-Adjust）循環，包括計劃、執行、檢查、調整四個步驟，如圖3.8-1所示。
每個PDCA循環就是一個迭代，每個迭代以固定的、可預測的開發節奏產生新的價值增量，同時也優化以前迭代產生的價值增量。在兩周時間內，每個團隊通過計劃、構建、測試、集成和演示等一係列工作完成係統增量的輸出。在短暫的迭代時間內，團隊、產品負責人、產品經理（PM）和其他利益相關者能夠通過可工作的係統完成技術和業務假設條件的驗證。每個迭代都會觸發一次“集成點”，就是所謂的“拉動事件”，通過團隊成員的一致努力把係統的不同方麵進行集成，集成包括功能、質量、校準和可用性等。
計劃迭代
迭代計劃會議是PDCA循環中的“計劃”步驟。所有團隊成員在會議中對團隊目標達成一致，此目標在團隊PI目標中描述，在團隊和係統演示中展示最終結果。
盡管團隊使用ScrumXP或看板會帶來一些計劃活動上的不同，但是在計劃會議中，團隊會檢查待辦事項列表來設定迭代目標，並從係統角度明確需要在迭代結束時進行集成和演示的詳細內容。
執行迭代
迭代執行對應PDCA循環中的“執行”步驟，它描述了開展工作的過程。團隊在迭代執行中，開發和測試新功能，以增量的方式交付用戶故事，當用戶故事完成後盡快向產品負責人進行演示，並且通過演示來顯示團隊的工作進展情況。
在執行階段還包含一個更小的PDCA循環，即每日站會。團隊成員每天都麵對麵地評估迭代目標的進展情況，更新自己的工作進度。每日站會就是一個以天為單位的PDCA循環，它允許團隊每天計劃、檢查，以及調整他們的迭代計劃。
團隊演示
團隊演示對應PDCA循環中的“檢查”步驟。在演示會議上，團隊向產品負責人演示經過充分測試的價值增量，並且獲得產品負責人的反饋。團隊也會根據演示的結果來調整下一個迭代的團隊待辦事項列表。在演示會上某些用戶故事會被產品負責人接收，另外一些會根據迭代中所收集到的反饋進行改進。
團隊演示後，團隊成員緊接著會參與整個係統的演示。在敏捷發布火車中，係統演示是一個必需的、正式的“集成點”，也是一個“拉動事件”，它會對多個團隊的成果進行集成，確保在項目群層級進行盡早的集成和驗證。在迭代中，每個團隊都可以站在係統的角度，對自己的工作進行持續集成和評估，從而滿足整個係統的要求。
改進流程
迭代回顧會“檢查”整個迭代的工作，對應PDCA循環中的“調整”步驟。在迭代回顧會議中，團隊成員一起評估開發流程和上一個迭代中改進故事的執行情況，識別問題及其發生的根本原因，當然也會回顧工作中做得好的地方，團隊把識別出的改進故事放到待辦事項列表中，放入下一個迭代中實現。迭代回顧是團隊進行持續改進（SAFe精益–敏捷思想的支柱之一）的關鍵方式之一。不論是立刻進行，還是在檢視和調整工作坊時進行，迭代回顧都可以驅動項目群層的流程改進。
在下個迭代計劃會議開始前，待辦事項列表會根據演示會議和回顧會議的決策重新進行調整。產品負責人根據需要，對新的和原有的待辦事項進行重構或重新排序。
參考資料
[1] Cockburn, Alistair. “Using Both Incremental and Iterative Development.” STSC CrossTalk 21 (2008): 27 – 30.
[2] Maurya, Ash. Running Lean: Iterate from Plan A to a Plan That Works. O’Reilly Media, 2012.
3.9 迭代計劃
堅守對決定的承諾，但保持靈活的操作方法。
——湯姆·羅賓斯
摘要
基於團隊的迭代計劃是去中心化的控製，以及授權快速、局部決策的主要機製之一。在Scrum中，團隊進行計劃，從產品待辦事項列表中選取故事，並承諾在接下來的迭代中進行實現。
這個基本流程對SAFe來說也是最為基礎的，而且適用於更廣泛的敏捷發布火車層麵，因為SAFe團隊是敏捷發布火車不可分割的組成部分。所以，在PI計劃會議中團隊的待辦事項已經確定或部分確定。此外，團隊不僅可以從之前的迭代中獲得反饋，而且也能從係統演示和其他團隊那裏獲得反饋。雖然，按照事情發展的自然規律和事實變更的模式來說，迭代計劃應該涉及更大的範圍。但是，此處的迭代計劃流程與Scrum中的方式大致相同，都需要敏捷團隊在時間盒會議中對下一個迭代進行計劃。迭代計劃會議的輸出如下：
1.迭代待辦事項列表，包括本迭代承諾的故事，以及故事的接收標準
2.迭代目標陳述，通常是描述本迭代中業務目標的一兩句話
3.團隊對於達成目標所需要做的工作的承諾
詳述
迭代計劃的目的是組織工作並為迭代定義切合實際的範圍。每個敏捷團隊為下一個迭代（依據迭代待辦事項列表）確定需要完成的故事，並將這些故事匯總成一組迭代目標。迭代待辦事項列表和目標是基於團隊能力來設定的，同時也考慮了每個故事的複雜性、規模大小，以及與其他故事和其他團隊的依賴關係。
在迭代計劃的結尾，團隊對迭代目標做出承諾，並對故事做必要的調整，從而可以實現更大的目標。在這個過程中，管理層不會幹擾或調整迭代範圍，以便使團隊能夠集中精力製訂出有效的目標。
迭代計劃的輸入
在SAFe中，迭代計劃是細節層麵的細化，也是對在敏捷發布火車PI計劃過程中創建的初始迭代計劃的調整。團隊通過預先詳盡闡述的團隊待辦事項列表製訂迭代計劃（他們通常在上一次迭代期間召開待辦事項列表的梳理會議）。計劃會議的輸入有如下內容：
在PI計劃中創建的團隊和項目群PI目標
團隊PI計劃待辦事項列表，包括在PI計劃時確定的故事
基於當
最後更新：2017-05-19 16:02:16