為什麼企業要做大規模敏捷？

軟體工程裡一個重要的指標就是“可用的軟體”，敏捷宣言裡也同樣告訴我們“工作的軟體高於詳盡的文件”，那“可用的軟體”、“工作的軟體”意味著什麼呢？在我的理解裡，可以經歷使用者 “千錘百煉”的軟體就是一個“可用的軟體”。曾經聽到過這樣的說法：“一個有Bug的軟體怎麼能叫軟體呢？”雖然這話在我們業內人士聽起來有些可笑，但是這就是使用軟體使用者最真實的需求。所以如何在提高程式碼質量，最大程度地減少軟體中的Bug同時，平衡軟體迭代速度與交付效率是我今天想跟大家討論的問題。

我有幸在兩種完全不同風格的專案上進行過交付，讓我們且稱之為專案A和專案B。

專案A是一個客戶為主導的巨大專案組，管理為明確縱向層級管理，橫向開發團隊來自於不同的供應商，並且採用瀑布式開發，由另一個事業部進行測試反饋，部門牆極其嚴重。

專案B則是一個由業務主導，每個敏捷團隊有對應相關的業務領域，客戶則是和供應商共同組成一個個敏捷團隊，共同達成業務目標。

好了，完成了簡單的背景介紹，我就要來說說下面的故事了。

首先，假設我們所需要達到的目標是由一個個大大小小功能（顏色模組）組成一個完整的軟體，為了達到我們的交付目標，我們需要將每個功能進行開發，測試，將功能模組進行累加，最終獲得一個完整而達標的軟體。

同時兩個專案都使用了大致相同的開發流程，為了保證質量，專案中都有基礎的程式碼審計，CI/CD，應用測試，使用者測試，等基本質量保證，軟體開發的基礎流程如下圖。

在這種基礎流程都相近的情況下，每個環節在不同架構下執行的的方式卻有巨大的差異。

在討論專案A的流程前，讓我們先看看我們熟知的敏捷開發是怎麼保證質量的：

專案b的每一個小敏捷團隊將業務需求從路徑圖（Roadmap）拆解下來，落到各大的業務功能的Epic中，再拆解成具有小的業務價值的使用者故事，最後再落到每個具有開發意義的任務，注意，這裡提的一直是業務價值，我們還沒有開始討論如何進入開發。

Epic 更多是獨立且較大的目標，用於我們識別在關鍵時間點需要實現的大型業務目標。而使用者故事則是一個簡短的描述、一個用於表達使用者或客戶的需求的角色和一個用於描述需求的價值或期望結果的價值陳述，在使用者故事中比較關鍵描述是關於此價值點的“靜態““動態”與“非常態“，靜態更多的是對價值點的描述，在To C中往往是靜態設計圖（UI）的描述，動態則是互動，系統間的互動或者功能的使用者旅程（UX），而非常態則是描述系統在錯誤或者誤差情況下的表現，以確保當前的價值點在絕大多數情況下得以執行（AC）。終端使用者故事將被團隊中的技術領導拆解成可以單獨執行的開發任務，最終沒個獨立的開發任務可以由不同的開發人員執行。

在一個大型的價值目標被拆解成了Epic->使用者故事->開發任務的過程中需要全團隊的多輪確認，多輪確認確保所有人達成統一共識 ，在最大的程度上解決溝通差帶來的不確定性。最終需要透過迭代計劃會議在團隊內部對價值達成共識後，才會進行專案開發。

進入開發任務後每個階段，參考下圖：

我們可以看到4重質量保證：

• 結對程式設計：兩個人的腦子總比一個人想的全。（其他好處不用贅述）

• 團隊中的程式碼版本差異識別：每對Pair的程式碼在一天結束時會被整個開發團隊稽核（當然可以提高程式碼質量了）

• 程式碼審計：當對應開發任務 - PR(每筆程式碼)完成後，會被整個團隊提意見（我聽過比較離譜的就是：Our PR is waiting for more comments）,修正完成後程式碼才會進入測試階段。

• 測試: 最後的最後，才會進行測試，整個測試則是由小團隊內部完成，在沒有測試的情況下，“非常態”的AC就是整個測試的透過條件。

再這樣一輪一輪的開發任務到使用者故事的價值交付後，又組成了一個Epic價值交付，最終透過Bug Bash的方式最後確認價值以達到交付標準，我們可以上線整個Epic用於使用者的檢驗。

總結一下敏捷開發的特點：

• 業務 -> 開發 -> 測試由一個全職能敏捷團隊完成

• 大多數內容由團隊內部確定

• 由上向下“順時針“開發

• 儘可能的小型功能，快速迭代

• 小型逆時針回撥細節確認

• 業務導向：業務決定質量

用圖來表示最終內建的結果，在最終快要上線時，經過團隊內質量把控後僅與實際有極少差距，僅需要在日常使用中進行基礎運維即可達到我們的價值目標：

這時候讓我們再來看專案A，系統被產品部門完成設計後，交予開發部門進行任務劃分，每個開發團隊承擔不同的功能開發任務，每個功能點再由單獨開發人員進行開發並自行測試（本地），最後由客戶方進行功能驗收後（功能展示+程式碼稽核），程式碼合入主線進行轉測。

說到這兒，舉個例子，產品部門提供了本次需要交付的20個功能的設計圖，開發團隊把設計圖分給交付團隊（大多由供應商組成），團隊成員小王負責對其中一張設計圖（類似於一個Epic）的功能進行開發，開發完成後開驗收會議，對程式碼和功能進行稽核驗證，進入測試流程。所以開發階段歸納下來的話，如圖

這樣乍一看確實沒有什麼問題，開發流程中的各種實踐也在做，那這種專案研發模式問題出在哪兒呢？這個時候我們看專案A的關鍵質量保證動作：測試。

專案A的測試步驟：

先拋結論，在測試階段，80%時間用於確定問題+定位問題（標紅）。所以我們可以著重討論一下這兩個階段。

確認問題：在確認問題階段， 往往由測試組發起，透過層層追溯，可以追溯到開發人員（也就是小王），跟小王確認表現層的“靜態”/“動態”/“非常態”問題後，測試順利成章地建立一個問題工單，並分配給小王，宣告此單插在了小王頭上，小王需要修正再找測試迴歸。乍一看又沒什麼問題，是個好流程，但是執行起來此流程會出現：

• 因為測試標準中有較多主觀的感官感受，導致在跟開發確認問題時經常出現主觀問題，此時需要產品介入，並用主觀感受進行判定。（缺少使用者旅程細節）

  舉例：（一個電話拉會）“小王，我覺得這個頁面幀數好低，你要最佳化一下。”“啊？？？”（此處省略battle的10分鐘）終於電話給了產品，產品一句話：“是幀數有點低啊！小王，這你得改”“…”

• 需要產品介入的場景往往流程會變得極長。測試在做測試中，會考慮很多“非常態“問題，在非常態問題中，往往會導致”靜態“”動態“的變更，然後經過工單追蹤，產品組漫長的重新設計，然後再由開發進行更改。

• 當存在“扯皮”問題，又是另外一副光景。

  舉例：測試打電話給小王，小王說“這不是我的問題，你找xx團隊的小李 ”，小李接上電話，“這是你小王開發的啊”..(再次省略battle時間)最終問題很有可能上升到客戶方確定問題邊界，這樣1個小時就過去了。

  
  

• 開發的專注思考時間被切碎。在轉測後，需要大量地確認問題，也就是跟測試打電話，測試往往是發現問題第一時間就會確認問題，這樣導致開發人員每天專注於程式碼工作的時間被切碎，效率直接下降。

定位問題： 定位問題同樣佔據了開發人員的大量時間，總體來說：

• 大量追溯程式碼：確認問題後，有時會需要確定整個功能程式碼中的問題點，問題很難定位，尤其遇到比較棘手的機率，效能問題需要對整個程式碼進行回顧與重構。

• 涉及他方程式碼：當在長時間確認問題後，問題有時會涉及他人程式碼，比如框架程式碼，他人功能程式碼，硬體程式碼，這時候需要你找到相關人（打電話），解釋，最終把工單走到他人名下（當然沒人願意接單，長時間Battle在所難免）。

• 定位到無法修改的問題：當然在這裡又有專門的流程做這件事，問題就出現在因為團隊間的互相的部門/信任牆，需要長流程（COC：需求變更會議）來共同確認問題，需要引入大量具有決策權的角色：另外團隊的架構師，產品經理，測試經理，還有可憐的小王。最終一個無法修改的工單往往需要2周或者更多的時間進行關閉。

• 流程反覆：當出現 確認問題->定位問題->確認問題->定位問題…這個如此反覆的流程時，對開發和測試的神經都是一個極大的考驗。

後續的修改流程往往較為順利，但是也會出現一個工單反覆無法透過迴歸的問題，這畢竟是少數，也不是我們主要探討的範疇。專案在強流程驅動下最終的結果就是：

所有人每天都在加班，所有人每天都在增加流程以確保質量，所有人都很痛苦，當然這裡包括小王。

用圖來表示開發結束後的狀態，空隙區域代表不確定問題，空隙部分需要測試->開發->產品逆流程更改

說了這麼多細節，我想現在跳出來問“為什麼會出現這樣的問題？”這個問題我也想留個大家做一點思考，我做了一些簡單而又主觀的總結，放在這裡：

• 共識缺失：當大家都在自己的職能部門做自己的工作時，往往會主觀地做這件事兒，當這件事兒在後續流轉時，沒有透過一個整體共識的話，往往需要從底端流程不斷向上確認達成共識。

• 大規模“逆時針”回撥：因為整體共識由測試發起，加上部門牆重，往往導致從測試->開發->產品的逆時針開發流程，程式碼重構與返工的工作量極大。

• 價值產出慢：當最終功能在大量回撥時，價值產出很慢，導致驗證慢，最終導致逆向反饋增加。

• 流程決定質量：還是由測試流程來確定質量的情況下，在產品只進行Happy Pass的情況下，所有人的彌合質量的成本都在成倍增加。

看完了專案A和專案B的整體, 我們最後再來聊聊效率，我們發現，在同等的質量要求下，敏捷效率反而高很多，在流程更短的情況下卻交付出了同樣質量很高的產品，最後我們透過對比總結一下，為什麼敏捷在保證質量的同時還能有更高的效率？

圖片來源：SAFe

我們暫且停在這兒，我要引用SAFe中的一張圖來結束我今天的闡述，也在用例項回答：“為什麼企業要做大規模敏捷？”

我想答案是：質量高，效率快，大家都開心。