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