有關SAFe實質(zhì)概要介紹
面向企業(yè)的Scrum-SAFe
常規(guī)的敏捷框架適用于中小型項目團隊，而且不具有擴展性?；诔Ｒ?guī)的敏捷框架，SAFe定義了一個可擴展的敏捷框架模型，它適用于大型團隊的合作開發(fā)，可以提高團隊之間的協(xié)作性，降低團隊管理的復雜性。
若企業(yè)已從Portfolio（投資組合）、team（團隊）、計劃（Program）三個層面清晰定義了敏捷的框架，你可以按照以下的方式來定義和細化你的敏捷架構。
首先，SAFe架構Portfolio層，由PPM來負責定義和驅(qū)動投資策略如何形成和資金的組合形式，然后將其體現(xiàn)成為敘事詩(Epics)。一個Epics可以是一列單獨的敏捷火車（Agile Release Train）來執(zhí)行，也可以是幾個火車的組合。Epics 是直接面向客戶的，設計架構級別的業(yè)務解決方案。
接著，在第二層計劃層由產(chǎn)品經(jīng)理（Product Manager）負責把等待安排的計劃（Backlog）進行排序，并且把投資策略轉(zhuǎn)化成具體的新功能（Feature），同時和業(yè)務負責人一起設計出項目的愿景和路線。
最后，在第三層團隊由產(chǎn)品負責人（Product Owner）和團隊成員根據(jù)上面的定義細化出用戶故事（User Story）和驗收標準，開發(fā)團隊可以從候選的用戶故事里面優(yōu)先選擇可以提前開始的內(nèi)容，其余的留到故事池里面等待后續(xù)的選擇。
由此可見，SAFe 從三個層面保證了團隊和企業(yè)的投資組合的最終愿景一致。同時，在實施過程中，需要一系列的里程碑事件來保證最終的實現(xiàn)和高層愿景設計的持續(xù)一致。而里程碑事件的制定主要通過計劃發(fā)布（Release planning）和系統(tǒng)的展示（System Demo）來保證。
SAFe 的幾個關鍵的角色：
SAFe 執(zhí)行過程中，我們必須掌握幾個關鍵角色：
Scrum 火車 工程師 (Release Train Engineer, 簡稱 RTE)
Scrum 主 管 (Scrum Master, 簡稱 SM)
如圖 2 所示，基于 SAFe 的一個企業(yè)級的投資策略往往由多列敏捷發(fā)布火車（Agile Release Trains）來組成。
RTE 是一列敏捷火車（Train）總的 Scrum 主管，其中每列敏捷火車有一個 RTE 。請注意一列敏捷火車是由多個團隊組成的。RTE 負責一列敏捷火車的總體執(zhí)行，包括在執(zhí)行過程中移除阻止火車前進的障礙，以及管理各個團隊之間的集成（Integration）。
而 Scrum 主管 (Scrum Master) 是團隊級別上 Scrum 的負責人，確保 scrum 的正確使用并使得 Scrum 的收益最大化。
圖 2.大規(guī)模的敏捷的火車
SAFe 在計劃管理面有一個時間控制，就是遞增的 Sprint 計劃（Program Increments，簡稱 PI）, 用來對一列敏捷火車的提交和發(fā)布時間進行總體規(guī)劃。而在團隊管理層主要是通過 Sprint 來做為一個時間箱標準，一般一個 Sprint 為 2 到 4 周。
SAFe 的計劃和發(fā)布
讓我們來認識下 SAFe 下和計劃和發(fā)布相關的幾個重要概念，這是實現(xiàn)和運用大規(guī)模的敏捷框架的最重要的部分。
遞增的 Sprint 計劃 （Program Increment, 簡稱 PI）
在首個 Sprint 開始之前，需要召開一個遞增的 Sprint 計劃。用來計劃和確定一列敏捷發(fā)布火車的時間維度，通過定量的時間遞增（Sprint）來保證編碼實現(xiàn)和我們計劃任務（Mission）的持續(xù)一致。如圖 3 所示，一個 PI 周期可以是 8 到 12 周的長度，包含一個位于最末端的 IP (Innovation and Planning) Sprint。
PI 將在固定的時間箱內(nèi)計劃出一個可量化、可實現(xiàn)和最終可測量驗收的計劃路線圖。
每個 Sprint 都需要經(jīng)歷同樣的工作： 設計，編碼和用戶故事的測試。
任意一個 Sprint 都必須產(chǎn)出是對計劃任務有價值的內(nèi)容，在較短的時間箱（2 周）內(nèi)防止實現(xiàn)和計劃任務的偏離。一旦發(fā)現(xiàn)偏離，可以及時糾正。
所有的敏捷火車都共享同一個發(fā)布項目時間表，比如在 2016 年的 2 月份的發(fā)布是從 2015 年 11 月 15 日到 2016 年 2 月 19 日，那么所有的敏捷火車都遵守這個項目發(fā)布時間表。
在每列敏捷火車中，代碼編寫、提交和測試是基于單個 Sprint 時間范圍內(nèi)有節(jié)奏的進行，但是各個發(fā)布火車代碼的最終發(fā)布和部署是根據(jù)實際情況來決定的。也就是說，并不是每個火車一定在 PI Sprint 后才可以發(fā)布。比如說，一列敏捷火車的代碼在第二個 Sprint 可以完成，那么它就可以在第二個 Sprint 來發(fā)布。當然在部署到最終產(chǎn)品環(huán)境之前，一定要完成對所有的用戶故事的驗證測試。
圖 3.SAFe 的遞增的 Sprint 計劃
創(chuàng)新和計劃（Innovation and Planning， 簡稱 IP）
IP Spring 是位于整個增量計劃周期里的最后一個階段，也是兩周的時長。
通常在第一周，我們會對整個新功能進行系統(tǒng)級別的驗證和回歸測試，估算下一次增量計劃的緩沖時間，總結我們在實施項目過程中哪些是做的好的地方，可以繼續(xù)；哪些地方需要改進，總結經(jīng)驗和教訓。最后，我們可以對下一次的增量發(fā)布進行提前計劃。
在 IP Spring 的第二周，可以在這個階段對即將發(fā)布的代碼進行規(guī)劃，包括各個相關團隊做發(fā)布包等的籌備。但是也有例外的情況，如果項目的時間比較緊張，開始和測試不能在 IP Sprint 完成，那么 IP sprint 的第一個周也可能用作一個回歸測試。
發(fā)布計劃（Release Planning）
在我們進入首個 Sprint 階段之前，需要舉行一個發(fā)布計劃會議。
發(fā)布計劃需要遵循下面的的幾點：
一般來時，推薦進行時長兩天的面對面的計劃會議。
在上一個 PI 的基礎上，計劃下一個發(fā)布計劃的 PI。
始終保持開發(fā)工作和業(yè)務需求以及計劃一致，從而保證每個 Sprint 的產(chǎn)出對用戶或者業(yè)務而言是有價值的。
對將要實現(xiàn)的新功能進行排序，篩選出優(yōu)先級前十的功能和特征。
辨識出每個 sprint 的 sprint 目標、存在的風險，并且把各個團隊之間的依賴和阻礙記錄到計劃展示板（Program Board）中。
確保大家對新功能的優(yōu)先排序保持理解一致。
圖 4. 計劃展示板
敏捷的團隊需要做哪些工作
在每個 Sprint 的開始階段，需要進行 Sprint 計劃會議。通過會議，確定在本 Sprint 需要完成哪些用戶故事，保持開發(fā)人員，測試人員和相關人員的理解是一致的。以及用戶故事提交順序安排。如圖 5 所示，對相臨近的 Sprint 可以進行同樣的計劃和安排。不需要把所有 Sprint 都提前進行計劃，可以遵循近詳細，遠粗略的原則。
另外，在實踐中我們引入一個探針（Spike）的概念。如果在某個 Sprint 開始時，我們無法精確估算將要完成的工作量，那么我可以加一個探針來探測我們大約需要的工作量和時間。探針的使用一般在整個 PI 周期的第一個 Sprint 里使用。前提是可能需求不夠清晰，也可能是我們對自己要進行的開發(fā)輔助工作量不好衡量。例如，我們在 Sprint 1 需要完成用戶故事 A，但是在完成用戶故事 A 前，需要做大量相關代碼的重構工作，但是在用戶故事里面這個工作沒有體現(xiàn)，而且我們對代碼重構的工作量也不能準確估算，這個時候我們可以引入探針。
每天一個 Scrum 會議， 簡短的更新進度和問題。
在 Sprint 結束前，對所完成用戶的故事進行展示。并且，開展一個回顧會議 (Respective)。
圖 5. 團隊計劃
敏捷發(fā)布火車需要做哪些工作
每列敏捷的發(fā)布火車都需要做下面一些事情：
在正式的 Sprint 開始之前，需要召開發(fā)布計劃會議（Release Planning）。在一個 PI 完成后，而下一個 PI 開始前，這個會議在上一個 PI 的 IP Sprint 期間召開。
由 RTE 來主持一個 Scrum 會議，會議的頻率根據(jù)項目的具體情況而定。 會議參與人包括本次發(fā)布火車上各個團隊的主要負責人、產(chǎn)品經(jīng)理、產(chǎn)品負責人等必要的人員。會議的內(nèi)容包含各個團隊工作進度的更新、目前存在的主要問題等。如果問題是跨團隊的，需要一起討論解決方案
實踐經(jīng)驗總結
本人進行的實踐項目是一個面向 IBM 內(nèi)部銷售代表使用的 WEB 電子上午網(wǎng)站，需要支持客戶在使用中提出的業(yè)務功能改進方案。業(yè)務功能的支持團隊是由位于中國和美國的六個團隊組成的 ， 我們采用了 SAFe 的框架來實施敏捷。請注意在此提供的經(jīng)驗總結僅供參考， 而不是必要的法則。那么，讓我來開始分享下我們的經(jīng)驗吧。
必要的敏捷火車 scrum 會議
由 RTE 主持的 Scrum 會議上，RTE 維護出一個包含所有團隊工作進度的列表。 讓處于同一列敏捷火車的團隊成員知道除了自己之外，其它團隊的進度。如果發(fā)現(xiàn)某個團隊的一些用戶故事不能及時部署到對應的測試環(huán)境，RTE 需要調(diào)查原因，移除障礙，從而保證整列敏捷火車高速前進。如圖 6 所示，在工作列表的縱列是本列敏捷火車的相關團隊，橫列是各個團隊在不同測試環(huán)境下的工作進度。紫色的部分列出了沒有完成的用戶故事在某個 Sprint 下。淺藍色代表用戶故事已經(jīng)提交到兩個測試環(huán)境，但是測試還沒有結束。淺黃色背景代表在用戶驗收環(huán)境的驗收測試已經(jīng)完成，可以部署到產(chǎn)品環(huán)境了。
工作進度列表對各個團隊的工作狀態(tài)顯示的一目了然，最主要的是可以保證整個敏捷測試的策略是清晰的。例如，哪些部分現(xiàn)在可以測試了，哪些部分受到阻礙以及哪些部分有依賴，不能進行端到端的測試等。
工作進度列表是實時更新的，更新的頻率取決于敏捷發(fā)布火車會議的頻率。
圖 6. 團隊進度列表
知識全面的敏捷測試人員
在單個 Sprint 期間，敏捷測試包括用戶故事的測試和端到端的測試。我們的項目涉及到六個開發(fā)團隊。所以一個端到端測試，需要經(jīng)歷四五十個測試步驟。而我們的團隊是分布到美國和中國的不同時區(qū)，所以在順利的情況下，完成一個端到端的測試也需要至少兩天的時間。那么在敏捷的框架下，我們的測試箱是有限的。如何在有限時間內(nèi)完成如此步驟繁雜的測試呢？需要我們的測試人員對業(yè)務知識的了解是是全面的，擁有各個團隊的相關業(yè)務知識背景和訪問權限。
通常情況下，我們前端的測試人員會在中國時間內(nèi)完成其它團隊的測試，從而確保一個端到端的測試用例在一個工作日內(nèi)完成。除非發(fā)現(xiàn)異常情況，那樣我們必須等待美國其它團隊的測試人員重新確認測試結果。
實時更新的用戶故事
產(chǎn)品負責人把新功能分劃成具體的用戶故事過程中，用戶故事不是一成不變的。隨著需求的逐步確認和溝通，用戶故事的內(nèi)容和驗收標準需要實時更新。請注意，通過問題隊列來跟蹤需求是不好的敏捷實踐。它會導致敏捷火車上的相關人員對用戶故事有不用的理解。
產(chǎn)品負責人有責任實時更新用戶故事和驗收標準。
結束語
通過上述對 SAFe 基本特征的介紹，以及項目實踐經(jīng)驗的分享，讀者可以對 SAFe 的概念和實施方式有一個基本的了解，在將來項目實施大規(guī)模的敏捷框架時，可以借鑒相關的實踐經(jīng)驗。
本文摘自IBM的網(wǎng)站
