在國內做咨詢的這段時間里，前后幫助三個客戶，在數(shù)十個團隊做敏捷轉型。在這個過程中，見到了不同思想的團隊Leader，也遇到了能力參差不齊的團隊成員，他們都面臨著共同的問題：一方面有著自上而下的壓力，卻缺乏視野和自學能力，不知道自己究竟應該做什么；另一方面，敏捷的定義模糊且眾說紛紜，自己又缺乏自主的獨立思考能力，對怎么才算敏捷轉型成功充滿疑惑。

在被客戶無數(shù)次的問及以上問題后，我自己也感到疑惑，因為即使在ThoughtWorks內部，這也沒有標準答案，甚至我在面對不同客戶時，會根據(jù)當前的目標產(chǎn)生不同的答案。因此我一直在不斷思考一個問題：當下一個客戶再問我類似問題的時候，我能不能有一個更明確，更體系化的答案。在和工作在各業(yè)務的同事交流后，我得到了一些答案，在此先做一些整理，分享給大家，期望引發(fā)后續(xù)的討論。

團隊敏捷轉型的三個階段

我們假設，敏捷轉型的開始是瀑布式開發(fā)，我把這個階段定義為Agile 0，根據(jù)我們的敏捷成熟度模型（AMM）里提及的最終形態(tài)定義為Agile 5，期間會經(jīng)歷三個階段。

階段一（Agile 0 - 1）：建立敏捷流程，縮短交付周期

這個階段，引入迭代或者建立看板是重點，類似于下圖：

（Scrum運作全景圖）

這個階段的主要目標，就是將需求的反饋、開發(fā)質量的反饋、以及改進周期縮短在一個迭代內（通常2-4周）。 為達到目的，Coach主要會做以下一些事（Actions）：

• 培訓 - 給團隊培訓敏捷流程、各角色的職責，以及各種工具的使用（比如Jira）。
• 現(xiàn)場指導 - 先帶領團隊走完整的敏捷流程，通常會有幾個迭代；然后觀察團隊自己執(zhí)行流程，并幫助團隊改進；最后不再參與這類活動。
• 需求梳理 - 指導PO和BA建立需求全景圖（比如Story Map）、拆分Story、排優(yōu)先級、和團隊其他成員協(xié)作等；制定Story編寫規(guī)范，Story價值流和建立Story看板。

這個階段主要培養(yǎng)的目標，是Scrum Master或者類似的角色，讓他們能了解敏捷流程的運作方式，并能帶領團隊在Coach不在場的情況下，依然按敏捷流程運作。

要走過這個階段，有一些關鍵指標：

• 交付周期 <= 3周：如果是迭代開發(fā)，則應該每個迭代小于3周，并且每個迭代都Release；如果是用Kanban，則Story的Lead Time應該小于3周。
• 上線的已知缺陷數(shù) = 0：有些企業(yè)會給缺陷分級，只要求把高優(yōu)先級的修復，但是我們推動敏捷，要求質量不可妥協(xié)，因此需要轉變客戶的想法，讓客戶把缺陷修復放到高優(yōu)先級。
• Finish Rate / WIP：如果是迭代開發(fā)，為了改變瀑布式開發(fā)硬塞需求的習慣，一定要控制Finish Rate大于80%。如果是看板，那就要控制到WIP，讓每個人專注于一件事的完成。

有些人說為什么不從技術實踐開始？設想一下在瀑布式開發(fā)中，開發(fā)團隊幾周甚至一個月才交一次版本給測試團隊，在這種情況下，開發(fā)怎么會有動力寫自動化測試？運維怎么會有動力做自動部署？需求沒有妥協(xié)的空間，設計沒有妥協(xié)的空間，導致團隊的痛點永遠是按時交付，質量一定會被犧牲掉的。因此只有先強制縮短交付周期，讓團隊痛點轉移，才能改變開發(fā)人員對質量的觀念。至于這個過程中導致的交付速率降低，我們會說：

• 在敏捷轉型前期一定是有所付出的，然而你投入越多，進展就會越快，收益就會來的越早。
• 沒有質量的交付不能稱為完成，只能叫半成品或者次品。

由此我們來討論第二階段

階段二（Agile 1 - 3）：引入技術實踐，質量內建，減少返工

這個階段的主要目標，是提升開發(fā)人員的質量意識，從而提升開發(fā)階段產(chǎn)出的質量水平，減少后續(xù)環(huán)節(jié)的返工。用質量內建的話來說，在缺陷時就立刻修復。這樣做的好處就是同時提高了質量和團隊整體效率。 其實在軟件開發(fā)中，生產(chǎn)過程隨著開發(fā)結束而結束，隨之而來的都是檢查和傳遞，因此產(chǎn)品的質量實際是由開發(fā)階段就確定的，如下圖：

（Story的生命周期）

只有提升生產(chǎn)過程的質量，才能減少返工，提高效率，因此我們在這個階段會引入技術實踐，縮短質量驗證的反饋周期，主要包括：

• 單元測試：單元測試的反饋周期最快，也在測試金字塔的最底層。要求開發(fā)人員編寫單元測試，一方面可以提升開發(fā)人員的代碼設計能力，提升代碼質量，另一方面可以提升開發(fā)人員的質量主人翁意識，讓開發(fā)階段的交付物質量有所提高。
• 集成測試：包括API測試和組建測試、契約測試等。這依然是要求開發(fā)人員來編寫，提高開發(fā)人員的能力和意識。
• UI自動化測試：如果是帶頁面的項目，這個階段通常都會引入UI測試，一般會要求測試人員編寫，這個階段的主要作用是幫助團隊提高回歸測試的效率。
• CI：通過CI服務器，將以上測試定期運行，并可視化報告，讓所有團隊看到。同時要求團隊第一時間修復CI。
• CD Pipeline：建立自動部署流水線到生產(chǎn)環(huán)境，并集成冒煙測試，E2E測試等自動化測試，同時實現(xiàn)回滾。
• Git：建立使用Git的規(guī)范，建立分支策略或者指導客戶做純主干開發(fā)，培訓客戶使用GIT高級功能，同時解決一些疑難雜癥。
• Operation相關技術：指導客戶實踐藍綠部署、云和容器、金絲雀發(fā)布等。幫助客戶設計更好的部署架構和技術架構，同時幫助客戶架構師做更好的決策。

這個階段培養(yǎng)的主要目標就是開發(fā)，建立開發(fā)的質量意識，幫助開發(fā)寫出更好的開發(fā)，培養(yǎng)開發(fā)處理復雜問題的能力。同時開闊團隊視野，讓團隊成員了解更多的技術，學習如何利用新技術提升自己效率。

除了第一階段的指標繼續(xù)改進外，這個階段我們會重點關注的一些指標：

CI相關指標：做CI的背后其實是為了培養(yǎng)團隊能力

• CI觸發(fā)頻率 > 開發(fā)人員個數(shù)：確保開發(fā)人員每天每人有提交。
• CI通過率 > 80%：確保開發(fā)人員在提交代碼前做了本地自檢。
• 最近一周內的CI修復時長 < 8h：確定團隊對CI有足夠的關注，沒有CI紅過夜。

質量相關指標：

• 一次通過率 > 80%（或者迭代手動Test的缺陷數(shù)接近于0）：Story開發(fā)完成后，會對完成的功能做一輪手動測試。這時得到的缺陷數(shù)，代表了開發(fā)階段的質量，缺陷數(shù)越少，說明開發(fā)人員的自動化測試和CI做的越好。一次通過率可以作為更高的要求，因為包括了后續(xù)的測試環(huán)境和生產(chǎn)環(huán)境中，產(chǎn)生問題的返工。
• 單元測試覆蓋率 > 80%（大家不要糾結為啥是80%，你也可以改成79%，或者100%）：首先要確保單元測試的數(shù)量在持續(xù)增加，同時要有Code Review的機制來保證單元測試的質量。另外，如果覆蓋率造假，那一次通過率一定不會得到改善。
• 測試金字塔：收集各層測試的數(shù)據(jù)，并關注是否是一個良好的金字塔，給個參考比例1:2:7。這里需要特別關注的一點，如果發(fā)現(xiàn)頂層測試數(shù)量太多，通常說明開發(fā)人員對自動化測試的關注不足，需要加大對單元測試和集成測試的推廣力度。

交付相關指標：

• CD Pipeline的Cycle time < 1h：這個一定要嚴格控制，假設一個團隊有8個開發(fā)，每人每天提交一次，那一天至少提交8次，如果Pipeline跑的太慢，就會影響到大家的代碼提交。當然，你也可以把這個時間要求減少，只是我的經(jīng)驗里，有些部署環(huán)境復雜、UI測試寫的有點多的團隊中，1h完成已經(jīng)是一件非常難的事了。
• 一個月內 Product Incident <= 1：差不多就是1年小于10個的標準，這個數(shù)字可以根據(jù)不同行業(yè)有不同要求，銀行業(yè)通常會更嚴格，而創(chuàng)新互聯(lián)網(wǎng)企業(yè)對線上事故的容忍度會更高。
• 其他SLA指標：比如服務可用率、響應速度、負載等，這些指標關系到的是部署架構和技術架構的設計和實現(xiàn)。

這個階段會耗時比較長，因此會有兩階的跨度，第一階是起步，往往會有教練帶著團隊做重構，寫自動化測試Demo，定規(guī)范和總結最佳實踐。到第二階后，這些能力就由團隊自己去傳播了，教練只會偶爾參加一下Code Review來看看團隊是否走在正確的路上。

小結：

總的來看，以上兩階段就是幫助客戶建立流程，定義參與角色并找到適合的工具，然后通過度量追蹤整個轉型過程，并逐步引入敏捷實踐來提升相關指標。

（敏捷轉型內容示意圖）

階段三（Agile 3 - 5）：提升價值交付效率和響應力

到Agile 3為止，我們一直在告訴客戶你要做什么，通過改變客戶團隊成員的行為，來改變他們的思想，特別是開發(fā)人員的質量意識和團隊成員的能力?；谝延械某晒?，這個階段的目標，就是培養(yǎng)成員的自我提升意識，團隊的自我改善能力，并幫助團隊建立自我改進的習慣。

因為團隊專注于自我改進，因此大家會有自己的改進線路，不過無論如何，都會專注于以下幾個方面：

• 更高級的能力建設：能進入這個階段的團隊說明已經(jīng)具備了支撐快速變化業(yè)務的基本能力，因此可以推動更高級的能力建設，比如引入微服務、代碼共享、特性團隊等（這些能力也能在階段三之前引入，但是只有在有了階段二的基礎后，才能真正做好）。
• 以Coaching為主：我們Teaching的內容會變少，Coaching的內容會變多，會讓客戶自己組織更多的分享，鼓勵客戶自學，并建立學習型文化。我們會和一些關鍵人物定期的做交流溝通，來幫助他們解決他們所面臨的問題。
• 與業(yè)務走的更近：團隊可以更好的理解業(yè)務，同時能給業(yè)務提供更有價值的建議，因此很多業(yè)務在決策早期就會引入技術團隊的成員。另外團隊也能更好的做出業(yè)務想要的東西。 在這個過程中，文化貫穿始末。因為團隊能力變強，所以更容易建立業(yè)務和技術團隊的信任，形成信任文化；因為團隊養(yǎng)成了自我改善的習慣，所以更容易形成學習型文化；因為大家有信任、有能力，所以會打破原來的控制型文化，培育出創(chuàng)新型文化。這些文化的建立，能更好的幫助企業(yè)在未來保持良好增長。

這個階段度量的內容會關注在響應力、創(chuàng)新上，這里給些參考：

• 交付周期 < 5d：這是響應力的象征。
• 假設驗證率：這個指標可以用來考核PO，理論上學到的知識越多，這個數(shù)字就會越高。
• 其他業(yè)務指標：這時團隊關注的是如何幫業(yè)務走向勝利，因此在軟件開發(fā)時就會大量埋點用于業(yè)務分析。

總結

整個轉型的過程，其實是行為改變思想，再通過思想影響行為的過程，當團隊中的人員能力慢慢提升，思想也在隨之改變，所有人都能對什么是正確的事作出更好的判斷，繼而走向持續(xù)改進的道路。所以如果定義團隊轉型成功，我認為就是幫助團隊建立起了一群能自己做持續(xù)改進的自組織特性團隊。 團隊要經(jīng)歷這三個階段必然是一個漫長的過程，很多錢多氣粗的企業(yè)一定想知道有沒有什么捷徑，我的答案是有：敏捷轉型的過程就是培養(yǎng)大家能力的過程，既然終點是所有人都擁有很強的能力，那為什么不在一開始就找這樣的人來工作呢？

PS：

2005年，作為敏捷方法實踐領頭羊的ThoughtWorks走入中國，并將敏捷方法論首次引進中國。今天，我們想對中國企業(yè)敏捷實施情況做個總結報告，讓更多人關注并加入敏捷實施的行列。本調查針對已經(jīng)實施敏捷的中國企業(yè)，了解哪些實踐比較普遍，在實施過程中有哪些困難。

我們將在2017年北京TID大會（7月18日）分享第一輪結果，參與填寫本調查并留下郵箱的朋友，將會優(yōu)于業(yè)界其他人收到最終報告。

更多精彩洞見，請關注微信公眾號:思特沃克