SAFe: Scaled Agile Framework
SAFe的全稱是Scaled Agile Framework enterprise
上圖黃色柱形中的每一個小圈代表的是一個scrum迭代，共有五個迭代。兩個小圈中間的省略號。。。的意思是有很多團隊在跑迭代。SAFe有兩層，Team層和program層（很多團隊之間的依賴比較大，人數為50 - 125）。Team 層包含有scrum master, PO, 開發測試人員。Program 層也稱作火車層，跟team層一一對應。
RTE：release train engineer 發布火車工程師，類似於chief scrum master的角色
Product manager: 可以理解為管理所有PO
System architecture: 系統工程架構師
Business owners: 老板/客戶業務方的老板/研發的老板，會給PR的價值打分數
版本火車：在發布周期很短的情況下，不按照以前的項目方式（如果在截止日期前沒做完，則延期），而火車的發車時間是固定的，如每月發一版。但是每個月發布的內容是不固定的，這么處理的目的就是為了建立快速發布的能力；真正達到敏捷，敏捷的范圍scope是可以變的，如果這個版本沒趕上，下個版本再發，客戶那邊也比較容易接受
版本火車+feature 開關：如果有代碼沒寫完，有開關
PI planning: 通常是會有上百個人開兩天會，有非常詳細的會議議程。首先Business Owner會就將來的戰略/目標進行發言，接着架構師就公司的架構技術進行發言。接下來會進行scrum分解來計划這五個迭代要做什么；在開會之前，PO和product manager要商量哪些特征feature要做的,怎么拆分成更小的故事story；第一天會議結束后，會就風險/問題/依賴關系進行分心並討論計划是否要變；第二天在繼續做分解討論，最后進行信心投票；business owner會進行價值value 打分；做完之后大家按照計划來執行。在執行過程中，在團隊層（Team level）面，會有每日站會；火車層（Program level）也會有相應的會議，要注意兩者之間要進行互通/同步
在全部五個迭代中，前四個迭代有冤圓圈表示，最后一個沒有圓圈，而是寫着IP （也即innovation and planning創新計划）迭代；五個迭代中通常留出最后一個做創新/回顧，但是不做新的需求；在開始計划的時候，前四個迭代真正完成所有需求
Enabler: 技術方面的故事
紅色折線：架構跑道；技術類的基礎工作，需要技術/架構團隊經常做系統/架構優化，支持實現新的feature或者換屆由新的業務造成的系統壓力
DevOps: 開發和運維，怎樣更好地進行合作，打破中間的裂縫
分而治之的思想: 分成多個 sub-epic
SAFe是企業層面的Scrum
若企業已從Portfolio（投資組合）、team（團隊）、計划（Program）三個層面清晰定義了敏捷的框架，你可以按照以下的方式來定義和細化你的敏捷架構。
首先，SAFe架構Portfolio層，由PPM來負責定義和驅動投資策略如何形成和資金的組合形式，然后將其體現成為敘事詩(Epics)。一個Epics可以是一列單獨的敏捷火車（Agile Release Train）來執行，也可以是幾個火車的組合。Epics 是直接面向客戶的，設計架構級別的業務解決方案。
接着，在第二層計划層由產品經理（Product Manager）負責把等待安排的計划（Backlog）進行排序，並且把投資策略轉化成具體的新功能（Feature），同時和業務負責人一起設計出項目的願景和路線。
最后，在第三層團隊由產品負責人（Product Owner）和團隊成員根據上面的定義細化出用戶故事（User Story）和驗收標准，開發團隊可以從候選的用戶故事里面優先選擇可以提前開始的內容，其余的留到故事池里面等待后續的選擇。
由此可見，SAFe 從三個層面保證了團隊和企業的投資組合的最終願景一致。同時，在實施過程中，需要一系列的里程碑事件來保證最終的實現和高層願景設計的持續一致。而里程碑事件的制定主要通過計划發布（Release planning）和系統的展示（System Demo）來保證。
SAFe 的幾個關鍵的角色：
SAFe 執行過程中，我們必須掌握幾個關鍵角色：
- Scrum 火車 工程師 (Release Train Engineer, 簡稱 RTE)
- Scrum 主 管 (Scrum Master, 簡稱 SM)
如圖 2 所示，基於 SAFe 的一個企業級的投資策略往往由多列敏捷發布火車（Agile Release Trains）來組成。
RTE 是一列敏捷火車（Train）總的 Scrum 主管，其中每列敏捷火車有一個 RTE 。請注意一列敏捷火車是由多個團隊組成的。RTE 負責一列敏捷火車的總體執行，包括在執行過程中移除阻止火車前進的障礙，以及管理各個團隊之間的集成（Integration）。
而 Scrum 主管 (Scrum Master) 是團隊級別上 Scrum 的負責人，確保 scrum 的正確使用並使得 Scrum 的收益最大化。
圖 2.大規模的敏捷的火車
SAFe 在計划管理面有一個時間控制，就是遞增的 Sprint 計划（Program Increments，簡稱 PI）, 用來對一列敏捷火車的提交和發布時間進行總體規划。而在團隊管理層主要是通過 Sprint 來做為一個時間箱標准，一般一個 Sprint 為 2 到 4 周。
SAFe 的計划和發布
讓我們來認識下 SAFe 下和計划和發布相關的幾個重要概念，這是實現和運用大規模的敏捷框架的最重要的部分。
遞增的 Sprint 計划 （Program Increment, 簡稱 PI）
在首個 Sprint 開始之前，需要召開一個遞增的 Sprint 計划。用來計划和確定一列敏捷發布火車的時間維度，通過定量的時間遞增（Sprint）來保證編碼實現和我們計划任務（Mission）的持續一致。如圖 3 所示，一個 PI 周期可以是 8 到 12 周的長度，包含一個位於最末端的 IP (Innovation and Planning) Sprint。
PI 將在固定的時間箱內計划出一個可量化、可實現和最終可測量驗收的計划路線圖。
每個 Sprint 都需要經歷同樣的工作： 設計，編碼和用戶故事的測試。
任意一個 Sprint 都必須產出是對計划任務有價值的內容，在較短的時間箱（2 周）內防止實現和計划任務的偏離。一旦發現偏離，可以及時糾正。
所有的敏捷火車都共享同一個發布項目時間表，比如在 2016 年的 2 月份的發布是從 2015 年 11 月 15 日到 2016 年 2 月 19 日，那么所有的敏捷火車都遵守這個項目發布時間表。
在每列敏捷火車中，代碼編寫、提交和測試是基於單個 Sprint 時間范圍內有節奏的進行，但是各個發布火車代碼的最終發布和部署是根據實際情況來決定的。也就是說，並不是每個火車一定在 IP Sprint 后才可以發布。比如說，一列敏捷火車的代碼在第二個 Sprint 可以完成，那么它就可以在第二個 Sprint 來發布。當然在部署到最終產品環境之前，一定要完成對所有的用戶故事的驗證測試。
圖 3.SAFe 的遞增的 Sprint 計划
創新和計划（Innovation and Planning， 簡稱 IP）
IP Spring 是位於整個增量計划周期里的最后一個階段，也是兩周的時長。
通常在第一周，我們會對整個新功能進行系統級別的驗證和回歸測試，估算下一次增量計划的緩沖時間，總結我們在實施項目過程中哪些是做的好的地方，可以繼續；哪些地方需要改進，總結經驗和教訓。最后，我們可以對下一次的增量發布進行提前計划。
在 IP Spring 的第二周，可以在這個階段對即將發布的代碼進行規划，包括各個相關團隊做發布包等的籌備。但是也有例外的情況，如果項目的時間比較緊張，開始和測試不能在 IP Sprint 完成，那么 IP sprint 的第一個周也可能用作一個回歸測試。
發布計划（Release Planning）
在我們進入首個 Sprint 階段之前，需要舉行一個發布計划會議。
發布計划需要遵循下面的的幾點：
- 一般來時，推薦進行時長兩天的面對面的計划會議。
- 在上一個 PI 的基礎上，計划下一個發布計划的 PI。
- 始終保持開發工作和業務需求以及計划一致，從而保證每個 Sprint 的產出對用戶或者業務而言是有價值的。
- 對將要實現的新功能進行排序，篩選出優先級前十的功能和特征。
- 辨識出每個 sprint 的 sprint 目標、存在的風險，並且把各個團隊之間的依賴和阻礙記錄到計划展示板（Program Board）中。
- 確保大家對新功能的優先排序保持理解一致。
圖 4. 計划展示板
敏捷的團隊需要做哪些工作
在每個 Sprint 的開始階段，需要進行 Sprint 計划會議。通過會議，確定在本 Sprint 需要完成哪些用戶故事，保持開發人員，測試人員和相關人員的理解是一致的。以及用戶故事提交順序安排。如圖 5 所示，對相臨近的 Sprint 可以進行同樣的計划和安排。不需要把所有 Sprint 都提前進行計划，可以遵循近詳細，遠粗略的原則。
另外，在實踐中我們引入一個探針（Spike）的概念。如果在某個 Sprint 開始時，我們無法精確估算將要完成的工作量，那么我可以加一個探針來探測我們大約需要的工作量和時間。探針的使用一般在整個 PI 周期的第一個 Sprint 里使用。前提是可能需求不夠清晰，也可能是我們對自己要進行的開發輔助工作量不好衡量。例如，我們在 Sprint 1 需要完成用戶故事 A，但是在完成用戶故事 A 前，需要做大量相關代碼的重構工作，但是在用戶故事里面這個工作沒有體現，而且我們對代碼重構的工作量也不能准確估算，這個時候我們可以引入探針。
每天一個 Scrum 會議， 簡短的更新進度和問題。
在 Sprint 結束前，對所完成用戶的故事進行展示。並且，開展一個回顧會議 (Respective)。
圖 5. 團隊計划
敏捷發布火車需要做哪些工作
每列敏捷的發布火車都需要做下面一些事情：
- 在正式的 Sprint 開始之前，需要召開發布計划會議（Release Planning）。在一個 PI 完成后，而下一個 PI 開始前，這個會議在上一個 PI 的 IP Sprint 期間召開。
- 由 RTE 來主持一個 Scrum 會議，會議的頻率根據項目的具體情況而定。 會議參與人包括本次發布火車上各個團隊的主要負責人、產品經理、產品負責人等必要的人員。會議的內容包含各個團隊工作進度的更新、目前存在的主要問題等。如果問題是跨團隊的，需要一起討論解決方案
實踐經驗總結
本人進行的實踐項目是一個面向 IBM 內部銷售代表使用的 WEB 電子上午網站，需要支持客戶在使用中提出的業務功能改進方案。業務功能的支持團隊是由位於中國和美國的六個團隊組成的 ， 我們采用了 SAFe 的框架來實施敏捷。請注意在此提供的經驗總結僅供參考， 而不是必要的法則。那么，讓我來開始分享下我們的經驗吧。
必要的敏捷火車 scrum 會議
由 RTE 主持的 Scrum 會議上，RTE 維護出一個包含所有團隊工作進度的列表。 讓處於同一列敏捷火車的團隊成員知道除了自己之外，其它團隊的進度。如果發現某個團隊的一些用戶故事不能及時部署到對應的測試環境，RTE 需要調查原因，移除障礙，從而保證整列敏捷火車高速前進。如圖 6 所示，在工作列表的縱列是本列敏捷火車的相關團隊，橫列是各個團隊在不同測試環境下的工作進度。紫色的部分列出了沒有完成的用戶故事在某個 Sprint 下。淺藍色代表用戶故事已經提交到兩個測試環境，但是測試還沒有結束。淺黃色背景代表在用戶驗收環境的驗收測試已經完成，可以部署到產品環境了。
工作進度列表對各個團隊的工作狀態顯示的一目了然，最主要的是可以保證整個敏捷測試的策略是清晰的。例如，哪些部分現在可以測試了，哪些部分受到阻礙以及哪些部分有依賴，不能進行端到端的測試等。
工作進度列表是實時更新的，更新的頻率取決於敏捷發布火車會議的頻率。
圖 6. 團隊進度列表
知識全面的敏捷測試人員
在單個 Sprint 期間，敏捷測試包括用戶故事的測試和端到端的測試。我們的項目涉及到六個開發團隊。所以一個端到端測試，需要經歷四五十個測試步驟。而我們的團隊是分布到美國和中國的不同時區，所以在順利的情況下，完成一個端到端的測試也需要至少兩天的時間。那么在敏捷的框架下，我們的測試箱是有限的。如何在有限時間內完成如此步驟繁雜的測試呢？需要我們的測試人員對業務知識的了解是是全面的，擁有各個團隊的相關業務知識背景和訪問權限。
通常情況下，我們前端的測試人員會在中國時間內完成其它團隊的測試，從而確保一個端到端的測試用例在一個工作日內完成。除非發現異常情況，那樣我們必須等待美國其它團隊的測試人員重新確認測試結果。
實時更新的用戶故事
產品負責人把新功能分划成具體的用戶故事過程中，用戶故事不是一塵不變的。隨着需求的逐步確認和溝通，用戶故事的內容和驗收標准需要實時更新。請注意，通過問題隊列來跟蹤需求是不好的敏捷實踐。它會導致敏捷火車上的相關人員對用戶故事有不用的理解。
產品負責人有責任實時更新用戶故事和驗收標准。
結束語
通過上述對 SAFe 基本特征的介紹，以及項目實踐經驗的分享，讀者可以對 SAFe 的概念和實施方式有一個基本的了解，在將來項目實施大規模的敏捷框架時，可以借鑒相關的實踐經驗。
敏捷原則
我們最重要的目標，是通過持續不斷地及早交付有價值的軟件使客戶滿意。
欣然面對需求變化，即使在開發后期也一樣。為了客戶的競爭優勢，敏捷過程掌控變化。
經常地交付可工作的軟件，相隔幾星期或一兩個月，傾向於采取較短的周期。
業務人員和開發人員必須相互合作，項目中的每一天都不例外。
激發個體的斗志，以他們為核心搭建項目。提供所需的環境和支援，輔以信任，從而達成目標。
不論團隊內外，傳遞信息效果最好效率也最高的方式是面對面的交談。
可工作的軟件是進度的首要度量標准。
敏捷過程倡導可持續開發。責任人、開發人員和用戶要能夠共同維持其步調穩定延續。
堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強。
以簡潔為本，它是極力減少不必要工作量的藝術。
最好的架構、需求和設計出自自組織團隊。
團隊定期地反思如何能提高成效，並依此調整自身的舉止表現。
Scrue 框架(敏捷)
接着，Ella對整個Scrum框架進行了講解。PO從干系人那邊得到需求作為輸入，跟開發團隊保持緊密溝通，清楚想做的特征在技術上能否實現，風險怎樣。得到輸入后，需要將其轉化為需求列表product backlog（需求列表是動態的，PO可以隨時更新；按照優先級排序；漸進明細，高需求的顆粒度較小。基本只要幾天的工作量，排在下面的就是簡單描述，需求還不是很明確）。Development team是開發團隊。一個大圈（通常1-4周），最開始定義好一個圈是幾周。迭代第一天會有sprint planning，PO跟團隊解釋前面幾條具體要做什么。結束后，輸出，團隊在固定的sprint里面能做完幾條需求。Scrum master的角色有點類似於項目經理，但還是有區別；scrum master會進行協調組織，每天會有15分鍾的站會，會后更新燃盡圖，識別問題風險；sprint最后有兩個會，sprint review 迭代評審會，叫PO過來給他演示進行驗收；sprint retrospective 迭代回顧會：流程/工具/合作/溝通/人/，哪些做得不錯，哪些需要改進；有些改進項可能會進入sprint backlog。