SAFe（Scaled Agile Framework，規(guī)模化敏捷框架）
常規(guī)的敏捷框架適用于中小型項目團(tuán)隊，而且不具有擴(kuò)展性。基于常規(guī)的敏捷框架，SAFe 定義了一個可擴(kuò)展的敏捷框架模型，它適用于大型團(tuán)隊的合作開發(fā)，可以幫助提高團(tuán)隊之間的協(xié)作性，降低團(tuán)隊管理的復(fù)雜性。
精益企業(yè)的規(guī)模化敏捷框架（SAFe）是一個可擴(kuò)展/可配置的框架，可幫助企業(yè)在最短的可持續(xù)交付周期內(nèi)以最優(yōu)化質(zhì)量和最大化價值交付世界上最重要的系統(tǒng)。它可以幫助多個敏捷團(tuán)隊甚至更大規(guī)模的集團(tuán)組織進(jìn)行協(xié)調(diào)同步，協(xié)作和交付。
SAFe將敏捷的力量，精益產(chǎn)品開發(fā)，系統(tǒng)化思維相結(jié)合。其廣泛的知識體系基于精益敏捷原則和價值觀，它們更好地指導(dǎo)了業(yè)務(wù)所需的角色，職責(zé)，工件和活動。
配置
SAFe支持各種開發(fā)環(huán)境，具有四種開箱即用配置，具體配置項目如下：
必不可少的最簡SAFe
基于投資組合SAFe
基于大型解決方案SAFe
全局完整的SAFe
團(tuán)隊組織和計劃實施，兩個層面共同構(gòu)成了一個名為Agile Release Train（ART 敏捷發(fā)布火車）的結(jié)構(gòu)。ART是針對于多個團(tuán)隊，利益相關(guān)方和項目資源的持續(xù)化解決方案任務(wù)列表。
目前，你只需要把它當(dāng)做傳統(tǒng)SCRUM里面的Product BackLog來理解即可，即我們實施解決方案，需要完成哪些研發(fā)，設(shè)計，測試任務(wù)。
ART通過共同愿景，路線圖和積壓計劃表，使管理層，團(tuán)隊和利益相關(guān)方與共同使命保持一致；
ART提供了可持續(xù)發(fā)展價值所需的上層功能（用戶功能）和底層推動支持（技術(shù)基礎(chǔ)設(shè)施）；
ART工作推進(jìn)中，團(tuán)隊迭代是同步的，使用相同的持續(xù)時間，相同的開始和結(jié)束日期；
每個ART周期在兩周左右，每個周期都提供有價值且經(jīng)過測試的系統(tǒng)級增量；
程序增量（PI）為規(guī)劃，執(zhí)行，檢查和調(diào)整工作提供了更長，更固定，更有節(jié)奏的時間周期；
ART使用大規(guī)模的面對面程序增量研發(fā)計劃，來確保團(tuán)隊協(xié)作、進(jìn)度基線對齊和快速適應(yīng)變更；
ART建立并維護(hù)一個持續(xù)的交付渠道，以便于定期開發(fā)和釋放有價值的增量。這使團(tuán)隊可以隨時根據(jù)市場需求發(fā)布自己想要的解決方案；
ART為系統(tǒng)架構(gòu)設(shè)計和使用體驗（UX）設(shè)計提供了通用且一致的方法；
ART融合DevOps持續(xù)交付。DevOps是一種思維方式，文化和技術(shù)實踐，提供了計劃，開發(fā)，測試，部署，發(fā)布和維護(hù)解決方案。同時提供了所有人之間溝通，集成，自動化和密切合作的可能性；
角色
通過必要的協(xié)調(diào)和治理，以下角色有助于使多個團(tuán)隊與共同使命和組織愿景保持一致：
系統(tǒng)架構(gòu)師/工程師
是一個應(yīng)用系統(tǒng)化思維的個人或小型跨學(xué)科團(tuán)隊。充當(dāng)此角色的人員定義了系統(tǒng)的整體架構(gòu)，確定了新的非功能需求（NFR），確定了關(guān)鍵元素和子系統(tǒng)，并確定了它們之間的接口和協(xié)作規(guī)范。
產(chǎn)品經(jīng)理
提供客戶的內(nèi)部聲音，與產(chǎn)品所有者和客戶合作，以溝通了解他們的需求，從而定義系統(tǒng)功能并參與驗證。產(chǎn)品經(jīng)理負(fù)責(zé)管理產(chǎn)品的積壓計劃表，并使用經(jīng)濟(jì)學(xué)方法確定功能和其推動因素的優(yōu)先級。
首席Scrum Master
無實權(quán)領(lǐng)袖，也叫發(fā)布快線工程師（RTE）。此角色的主要工作是使用諸如計劃看板，檢查調(diào)整（I＆A）事件，PI計劃等機(jī)制來幫助改善團(tuán)隊工作計劃中的價值流動，使其更加流暢。
商業(yè)負(fù)責(zé)人
代表利益相關(guān)方的小組，他們對治理，合規(guī)和投資等業(yè)務(wù)和技術(shù)負(fù)責(zé)，為ART開發(fā)的解決方案買單。他們是重要的利益相關(guān)者，評估項目適用性并積極參與ART活動。
客戶
是價值的最終裁定者，是敏捷開發(fā)流程和價值流的重要組成部分。他們在SFAe中負(fù)有特定的責(zé)任和角色定位。
上面提及的三個要素有助于協(xié)調(diào)ART的推進(jìn)，它們分別是：PI規(guī)劃，系統(tǒng)演示和I＆A事件。接下來我會將簡要介紹所有要素。
SAFe的十大關(guān)鍵要素
哪怕是一個最簡的SAFe也確定了10個關(guān)鍵要素，這些要素適用于所有SAFe配置。這對于成功的精益和敏捷開發(fā)是必不可少的。如果企業(yè)在建立新解決方案時融入這些元素，那么他們將很好地獲得SAFe的全部優(yōu)勢。
1. 精益敏捷原則
其中包含了九個小的基本原則，這些原則合集為SAFe實踐提供了信息。如果這些實踐不能直接適用于當(dāng)下特定的環(huán)境，那么基本原則就會為他們指出連續(xù)的明確的發(fā)展路徑，確保他們在盡可能短的時間內(nèi)開始嘗試這些實踐。
2. 完備的敏捷和培訓(xùn)團(tuán)隊
被完備組建的敏捷與培訓(xùn)團(tuán)隊，都需要產(chǎn)生一個可行的，經(jīng)過測試的解決方案增量。團(tuán)隊內(nèi)實施跨職能，自組織和自管理，ART允許價值更快地流動，同時最小化成本。產(chǎn)品經(jīng)理，系統(tǒng)架構(gòu)師/工程師和RTE提供權(quán)限并簡化開發(fā)過程。產(chǎn)品所有者和Scrum Masters幫助開發(fā)團(tuán)隊實現(xiàn)其目標(biāo)。客戶在整個開發(fā)過程中發(fā)揮著關(guān)鍵作用。
3. 節(jié)奏和同步
節(jié)奏是一種固定的，周期性模式的事件，就像是項目進(jìn)展中的心跳一樣重要。它確保定期舉行各種團(tuán)隊會議，制定計劃和大型解決方案活動，使其成為團(tuán)隊中默認(rèn)的常規(guī)（例如每日站立，PI計劃，系統(tǒng)演示，I＆A事件，解決方案演示）。同步則允許從多個方面理解并解決問題。 例如，它將一個系統(tǒng)中的不同資產(chǎn)結(jié)合在一起，以評估解決方案的可行性。
4. 程序增量（PI）計劃
PI的基石，SAFe中沒有比PI規(guī)劃更強(qiáng)大的事件。此活動是ART的心跳活動，本計劃的制定，共識與實施，使ART的所有團(tuán)在未來愿景上保持一致。
5. DevOps和可交付性
SAFe接近于DevOps的“CALMeR —— culture, automation, Lean-flow, measurement, recovery”方法，這使企業(yè)能夠縮小開發(fā)和運(yùn)營的差距。可交付性側(cè)重于企業(yè)根據(jù)市場需求更頻繁地為客戶提供價值的能力。DevOps和可交付性共同作用，使組織能夠通過頻繁發(fā)布和快速驗證來實現(xiàn)更好的經(jīng)濟(jì)效益。
6. 系統(tǒng)演示
ART進(jìn)展的主要衡量標(biāo)準(zhǔn)，是系統(tǒng)演示中解決方案提供的客觀證據(jù)。每兩周，敏捷發(fā)布列車（ART）上的所有團(tuán)隊都要整合工作，并會向利益相關(guān)方進(jìn)行演示，然后利益相關(guān)方提供反饋，幫助團(tuán)隊保持正確的前進(jìn)防線并及時糾正偏差。
7. 檢查和調(diào)整（I＆A）
每個程序增量迭代（PI）都要周期性舉辦的重要活動。I＆A是為了定期反映問題，收集數(shù)據(jù)，解決問題、匯集團(tuán)隊和利益相關(guān)方一起評估解決方案。這是一個定期機(jī)會，有助于提高下一個PI的速度，質(zhì)量和可靠性。
8. 創(chuàng)新和規(guī)劃（IP）迭代
每次程序增量迭代中，為了多方目的，計劃至少一次創(chuàng)新和規(guī)劃迭代（PI）。它可以看作為了實現(xiàn)PI目標(biāo)的估算緩沖區(qū)，并為創(chuàng)新，團(tuán)隊繼續(xù)教育，PI規(guī)劃和I＆A活動提供時間。這就像是坦克中的額外燃料：如果沒有它，我們的敏捷發(fā)布火車可能會開始在“極端的暴政”迭代失衡
9. 架構(gòu)跑道
架構(gòu)跑道由現(xiàn)有的代碼，組件和技術(shù)基建儲備組成。這些代碼，組件和技術(shù)基建儲備必須支持高優(yōu)先級，近期的任務(wù)安排，確保不會出現(xiàn)過度的延遲交付和中途返工。這樣就能加速價值交付流程。
10. 精益敏捷領(lǐng)導(dǎo)力
為了確保SAFe實施的有效性，企業(yè)的管理人員和管理人員必須對敏捷精益的采用與成功承擔(dān)領(lǐng)導(dǎo)責(zé)任。因此，領(lǐng)導(dǎo)者必須接受培訓(xùn)，并成為更精干的思考者和團(tuán)隊培訓(xùn)者。只有當(dāng)領(lǐng)導(dǎo)者積極參與并負(fù)責(zé)實施時，SAFe轉(zhuǎn)型才能成功。
下面的因素可能會影響你是否確定在企業(yè)中實施 SAFe
如果你已經(jīng)在團(tuán)隊級別成功應(yīng)用和嘗試過敏捷，現(xiàn)在有意在更大的層面，跨團(tuán)隊來考慮組織層的計劃和投資組合實行。
如果你有多個團(tuán)隊在各自獨(dú)立應(yīng)用敏捷，一旦遇到障礙，延期或失敗，就會影響其他團(tuán)隊，甚至整個公司目標(biāo)的實現(xiàn)。
如果你渴望跨組織的擴(kuò)張敏捷實踐，但不確定需要什么新的角色、哪些存在的角色 ( 例如：管理 ) 需要改變以及如何改變。
如果你試圖在整個組織中實施敏捷實踐，但你還在與跨業(yè)務(wù)部門達(dá)成一致策略的問題和文檔層面到程序到團(tuán)隊層面一致對齊的問題上苦苦掙扎。
如果你的組織需要提升產(chǎn)品開發(fā)和交付周期，你已經(jīng)聽說過像 John Deere 這樣的公司熟練的用 SAFe 擴(kuò)展敏捷實踐獲取的成功，你想自己嘗試下敏捷的帶來的好處。
首先，SAFe 框架在投資組合層由投資組合管理委員會（Program portfolio Manager）來負(fù)責(zé)定義和驅(qū)動投資策略如何形成和資金的組合形式，然后將其體現(xiàn)成為敘事詩（Epics）。一個 Epic 可以是一列單獨(dú)的敏捷火車（Agile Release Train）來執(zhí)行， 也可以是幾個火車的組合。Epic 是直接面向客戶的、設(shè)計架構(gòu)級別的業(yè)務(wù)解決方案。
接著，在第二層計劃層由產(chǎn)品經(jīng)理（Product Manager）負(fù)責(zé)把等待安排的計劃（Backlog）進(jìn)行排序，并且把投資策略轉(zhuǎn)化成具體的新功能（Feature），同時和業(yè)務(wù)負(fù)責(zé)人一起設(shè)計出項目的愿景和路線。
最后，在第三層團(tuán)隊由產(chǎn)品負(fù)責(zé)人（Product Owner）和團(tuán)隊成員根據(jù)上面的定義細(xì)化出用戶故事（User Story）和驗收標(biāo)準(zhǔn)，開發(fā)團(tuán)隊可以從候選的用戶故事里面優(yōu)先選擇可以提前開始的內(nèi)容，其余的留到故事池里面等待后續(xù)的選擇。
由此可見，SAFe 從三個層面保證了團(tuán)隊和企業(yè)的投資組合的最終愿景一致。同時，在實施過程中，需要一系列的里程碑事件來保證最終的實現(xiàn)和高層愿景設(shè)計的持續(xù)一致。而里程碑事件的制定主要通過計劃發(fā)布（Release planning）和系統(tǒng)的展示（System Demo）來保證。
SAFe 的幾個關(guān)鍵的角色：
SAFe 執(zhí)行過程中，我們必須掌握幾個關(guān)鍵角色：
Scrum 火車 工程師 (Release Train Engineer, 簡稱 RTE)
Scrum 主 管 (Scrum Master, 簡稱 SM)
如圖 2 所示，基于 SAFe 的一個企業(yè)級的投資策略往往由多列敏捷發(fā)布火車（Agile Release Trains）來組成。
RTE 是一列敏捷火車（Train）總的 Scrum 主管，其中每列敏捷火車有一個 RTE 。請注意一列敏捷火車是由多個團(tuán)隊組成的。RTE 負(fù)責(zé)一列敏捷火車的總體執(zhí)行，包括在執(zhí)行過程中移除阻止火車前進(jìn)的障礙，以及管理各個團(tuán)隊之間的集成（Integration）。
而 Scrum 主管 (Scrum Master) 是團(tuán)隊級別上 Scrum 的負(fù)責(zé)人，確保 scrum 的正確使用并使得 Scrum 的收益最大化。
SAFe 在計劃管理面有一個時間控制，就是遞增的 Sprint 計劃（Program Increments，簡稱 PI）, 用來對一列敏捷火車的提交和發(fā)布時間進(jìn)行總體規(guī)劃。而在團(tuán)隊管理層主要是通過 Sprint 來做為一個時間箱標(biāo)準(zhǔn)，一般一個 Sprint 為 2 到 4 周。
SAFe 的計劃和發(fā)布
讓我們來認(rèn)識下 SAFe 下和計劃和發(fā)布相關(guān)的幾個重要概念，這是實現(xiàn)和運(yùn)用大規(guī)模的敏捷框架的最重要的部分。
遞增的 Sprint 計劃 （Program Increment, 簡稱 PI）
在首個 Sprint 開始之前，需要召開一個遞增的 Sprint 計劃。用來計劃和確定一列敏捷發(fā)布火車的時間維度，通過定量的時間遞增（Sprint）來保證編碼實現(xiàn)和我們計劃任務(wù)（Mission）的持續(xù)一致。如圖 3 所示，一個 PI 周期可以是 8 到 12 周的長度，包含一個位于最末端的 IP (Innovation and Planning) Sprint。
PI 將在固定的時間箱內(nèi)計劃出一個可量化、可實現(xiàn)和最終可測量驗收的計劃路線圖。
每個 Sprint 都需要經(jīng)歷同樣的工作： 設(shè)計，編碼和用戶故事的測試。
任意一個 Sprint 都必須產(chǎn)出是對計劃任務(wù)有價值的內(nèi)容，在較短的時間箱（2 周）內(nèi)防止實現(xiàn)和計劃任務(wù)的偏離。一旦發(fā)現(xiàn)偏離，可以及時糾正。
所有的敏捷火車都共享同一個發(fā)布項目時間表，比如在 2016 年的 2 月份的發(fā)布是從 2015 年 11 月 15 日到 2016 年 2 月 19 日，那么所有的敏捷火車都遵守這個項目發(fā)布時間表。
在每列敏捷火車中，代碼編寫、提交和測試是基于單個 Sprint 時間范圍內(nèi)有節(jié)奏的進(jìn)行，但是各個發(fā)布火車代碼的最終發(fā)布和部署是根據(jù)實際情況來決定的。也就是說，并不是每個火車一定在 IP Sprint 后才可以發(fā)布。比如說，一列敏捷火車的代碼在第二個 Sprint 可以完成，那么它就可以在第二個 Sprint 來發(fā)布。當(dāng)然在部署到最終產(chǎn)品環(huán)境之前，一定要完成對所有的用戶故事的驗證測試。
創(chuàng)新和計劃（Innovation and Planning， 簡稱 IP）
IP Spring 是位于整個增量計劃周期里的最后一個階段，也是兩周的時長。
通常在第一周，我們會對整個新功能進(jìn)行系統(tǒng)級別的驗證和回歸測試，估算下一次增量計劃的緩沖時間，總結(jié)我們在實施項目過程中哪些是做的好的地方，可以繼續(xù)；哪些地方需要改進(jìn)，總結(jié)經(jīng)驗和教訓(xùn)。最后，我們可以對下一次的增量發(fā)布進(jìn)行提前計劃。
在 IP Spring 的第二周，可以在這個階段對即將發(fā)布的代碼進(jìn)行規(guī)劃，包括各個相關(guān)團(tuán)隊做發(fā)布包等的籌備。但是也有例外的情況，如果項目的時間比較緊張，開始和測試不能在 IP Sprint 完成，那么 IP sprint 的第一個周也可能用作一個回歸測試。
發(fā)布計劃（Release Planning）
在我們進(jìn)入首個 Sprint 階段之前，需要舉行一個發(fā)布計劃會議。
發(fā)布計劃需要遵循下面的的幾點(diǎn)：
一般來時，推薦進(jìn)行時長兩天的面對面的計劃會議。
在上一個 PI 的基礎(chǔ)上，計劃下一個發(fā)布計劃的 PI。
始終保持開發(fā)工作和業(yè)務(wù)需求以及計劃一致，從而保證每個 Sprint 的產(chǎn)出對用戶或者業(yè)務(wù)而言是有價值的。
對將要實現(xiàn)的新功能進(jìn)行排序，篩選出優(yōu)先級前十的功能和特征。
辨識出每個 sprint 的 sprint 目標(biāo)、存在的風(fēng)險，并且把各個團(tuán)隊之間的依賴和阻礙記錄到計劃展示板（Program Board）中。
確保大家對新功能的優(yōu)先排序保持理解一致。
敏捷的團(tuán)隊需要做哪些工作
在每個 Sprint 的開始階段，需要進(jìn)行 Sprint 計劃會議。通過會議，確定在本 Sprint 需要完成哪些用戶故事，保持開發(fā)人員，測試人員和相關(guān)人員的理解是一致的。以及用戶故事提交順序安排。如圖 5 所示，對相臨近的 Sprint 可以進(jìn)行同樣的計劃和安排。不需要把所有 Sprint 都提前進(jìn)行計劃，可以遵循近詳細(xì)，遠(yuǎn)粗略的原則。
另外，在實踐中我們引入一個探針（Spike）的概念。如果在某個 Sprint 開始時，我們無法精確估算將要完成的工作量，那么我可以加一個探針來探測我們大約需要的工作量和時間。探針的使用一般在整個 PI 周期的第一個 Sprint 里使用。前提是可能需求不夠清晰，也可能是我們對自己要進(jìn)行的開發(fā)輔助工作量不好衡量。例如，我們在 Sprint 1 需要完成用戶故事 A，但是在完成用戶故事 A 前，需要做大量相關(guān)代碼的重構(gòu)工作，但是在用戶故事里面這個工作沒有體現(xiàn)，而且我們對代碼重構(gòu)的工作量也不能準(zhǔn)確估算，這個時候我們可以引入探針。
每天一個 Scrum 會議， 簡短的更新進(jìn)度和問題。
在 Sprint 結(jié)束前，對所完成用戶的故事進(jìn)行展示。并且，開展一個回顧會議 (Respective)。
敏捷發(fā)布火車需要做哪些工作
每列敏捷的發(fā)布火車都需要做下面一些事情：
在正式的 Sprint 開始之前，需要召開發(fā)布計劃會議（Release Planning）。在一個 PI 完成后，而下一個 PI 開始前，這個會議在上一個 PI 的 IP Sprint 期間召開。
由 RTE 來主持一個 Scrum 會議，會議的頻率根據(jù)項目的具體情況而定。 會議參與人包括本次發(fā)布火車上各個團(tuán)隊的主要負(fù)責(zé)人、產(chǎn)品經(jīng)理、產(chǎn)品負(fù)責(zé)人等必要的人員。會議的內(nèi)容包含各個團(tuán)隊工作進(jìn)度的更新、目前存在的主要問題等。如果問題是跨團(tuán)隊的，需要一起討論解決方案
實踐經(jīng)驗總結(jié)
本人進(jìn)行的實踐項目是一個面向 IBM 內(nèi)部銷售代表使用的 WEB 電子上午網(wǎng)站，需要支持客戶在使用中提出的業(yè)務(wù)功能改進(jìn)方案。業(yè)務(wù)功能的支持團(tuán)隊是由位于中國和美國的六個團(tuán)隊組成的 ， 我們采用了 SAFe 的框架來實施敏捷。請注意在此提供的經(jīng)驗總結(jié)僅供參考， 而不是必要的法則。那么，讓我來開始分享下我們的經(jīng)驗吧。
必要的敏捷火車 scrum 會議
由 RTE 主持的 Scrum 會議上，RTE 維護(hù)出一個包含所有團(tuán)隊工作進(jìn)度的列表。 讓處于同一列敏捷火車的團(tuán)隊成員知道除了自己之外，其它團(tuán)隊的進(jìn)度。如果發(fā)現(xiàn)某個團(tuán)隊的一些用戶故事不能及時部署到對應(yīng)的測試環(huán)境，RTE 需要調(diào)查原因，移除障礙，從而保證整列敏捷火車高速前進(jìn)。如圖 6 所示，在工作列表的縱列是本列敏捷火車的相關(guān)團(tuán)隊，橫列是各個團(tuán)隊在不同測試環(huán)境下的工作進(jìn)度。紫色的部分列出了沒有完成的用戶故事在某個 Sprint 下。淺藍(lán)色代表用戶故事已經(jīng)提交到兩個測試環(huán)境，但是測試還沒有結(jié)束。淺黃色背景代表在用戶驗收環(huán)境的驗收測試已經(jīng)完成，可以部署到產(chǎn)品環(huán)境了。
工作進(jìn)度列表對各個團(tuán)隊的工作狀態(tài)顯示的一目了然，最主要的是可以保證整個敏捷測試的策略是清晰的。例如，哪些部分現(xiàn)在可以測試了，哪些部分受到阻礙以及哪些部分有依賴，不能進(jìn)行端到端的測試等。
工作進(jìn)度列表是實時更新的，更新的頻率取決于敏捷發(fā)布火車會議的頻率。
知識全面的敏捷測試人員
在單個 Sprint 期間，敏捷測試包括用戶故事的測試和端到端的測試。我們的項目涉及到六個開發(fā)團(tuán)隊。所以一個端到端測試，需要經(jīng)歷四五十個測試步驟。而我們的團(tuán)隊是分布到美國和中國的不同時區(qū)，所以在順利的情況下，完成一個端到端的測試也需要至少兩天的時間。那么在敏捷的框架下，我們的測試箱是有限的。如何在有限時間內(nèi)完成如此步驟繁雜的測試呢？需要我們的測試人員對業(yè)務(wù)知識的了解是是全面的，擁有各個團(tuán)隊的相關(guān)業(yè)務(wù)知識背景和訪問權(quán)限。
通常情況下，我們前端的測試人員會在中國時間內(nèi)完成其它團(tuán)隊的測試，從而確保一個端到端的測試用例在一個工作日內(nèi)完成。除非發(fā)現(xiàn)異常情況，那樣我們必須等待美國其它團(tuán)隊的測試人員重新確認(rèn)測試結(jié)果。
實時更新的用戶故事
產(chǎn)品負(fù)責(zé)人把新功能分劃成具體的用戶故事過程中，用戶故事不是一塵不變的。隨著需求的逐步確認(rèn)和溝通，用戶故事的內(nèi)容和驗收標(biāo)準(zhǔn)需要實時更新。請注意，通過問題隊列來跟蹤需求是不好的敏捷實踐。它會導(dǎo)致敏捷火車上的相關(guān)人員對用戶故事有不用的理解。
產(chǎn)品負(fù)責(zé)人有責(zé)任實時更新用戶故事和驗收標(biāo)準(zhǔn)。
來源：developerWorks Rational 專區(qū)，
