作者 | 曾雪松

背景

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

我有幸在兩種完全不同風(fēng)格的項(xiàng)目上進(jìn)行過交付，讓我們且稱之為項(xiàng)目A和項(xiàng)目B。

項(xiàng)目A是一個(gè)客戶為主導(dǎo)的巨大項(xiàng)目組，管理為明確縱向?qū)蛹壒芾?，橫向開發(fā)團(tuán)隊(duì)來自于不同的供應(yīng)商，并且采用瀑布式開發(fā)，由另一個(gè)事業(yè)部進(jìn)行測試反饋，部門墻極其嚴(yán)重。

項(xiàng)目B則是一個(gè)由業(yè)務(wù)主導(dǎo)，每個(gè)敏捷團(tuán)隊(duì)有對應(yīng)相關(guān)的業(yè)務(wù)領(lǐng)域，客戶則是和供應(yīng)商共同組成一個(gè)個(gè)敏捷團(tuán)隊(duì)，共同達(dá)成業(yè)務(wù)目標(biāo)。

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

故事

總覽

首先，假設(shè)我們所需要達(dá)到的目標(biāo)是由一個(gè)個(gè)大大小小功能（顏色模組）組成一個(gè)完整的軟件，為了達(dá)到我們的交付目標(biāo)，我們需要將每個(gè)功能進(jìn)行開發(fā)，測試，將功能模塊進(jìn)行累加，最終獲得一個(gè)完整而達(dá)標(biāo)的軟件。

同時(shí)兩個(gè)項(xiàng)目都使用了大致相同的開發(fā)流程，為了保證質(zhì)量，項(xiàng)目中都有基礎(chǔ)的代碼審計(jì)，CI/CD，應(yīng)用測試，用戶測試，等基本質(zhì)量保證，軟件開發(fā)的基礎(chǔ)流程如下圖：

在這種基礎(chǔ)流程都相近的情況下，每個(gè)環(huán)節(jié)在不同架構(gòu)下執(zhí)行的的方式卻有巨大的差異。

在討論項(xiàng)目A的流程前，讓我們先看看我們熟知的敏捷開發(fā)是怎么保證質(zhì)量的：

項(xiàng)目B的情況

項(xiàng)目b的每一個(gè)小敏捷團(tuán)隊(duì)將業(yè)務(wù)需求從路徑圖（Roadmap）拆解下來，落到各大的業(yè)務(wù)功能的Epic中，再拆解成具有小的業(yè)務(wù)價(jià)值的用戶故事，最后再落到每個(gè)具有開發(fā)意義的任務(wù)，注意，這里提的一直是業(yè)務(wù)價(jià)值，我們還沒有開始討論如何進(jìn)入開發(fā)。

Epic 更多是獨(dú)立且較大的目標(biāo)，用于我們識別在關(guān)鍵時(shí)間點(diǎn)需要實(shí)現(xiàn)的大型業(yè)務(wù)目標(biāo)。而用戶故事則是一個(gè)簡短的描述、一個(gè)用于表達(dá)用戶或客戶的需求的角色和一個(gè)用于描述需求的價(jià)值或期望結(jié)果的價(jià)值陳述，在用戶故事中比較關(guān)鍵描述是關(guān)于此價(jià)值點(diǎn)的“靜態(tài)““動態(tài)”與“非常態(tài)“，靜態(tài)更多的是對價(jià)值點(diǎn)的描述，在To C中往往是靜態(tài)設(shè)計(jì)圖（UI）的描述，動態(tài)則是交互，系統(tǒng)間的交互或者功能的用戶旅程（UX），而非常態(tài)則是描述系統(tǒng)在錯誤或者誤差情況下的表現(xiàn)，以確保當(dāng)前的價(jià)值點(diǎn)在絕大多數(shù)情況下得以運(yùn)行（AC）。最終用戶故事將被團(tuán)隊(duì)中的技術(shù)領(lǐng)導(dǎo)拆解成可以單獨(dú)執(zhí)行的開發(fā)任務(wù)，最終沒個(gè)獨(dú)立的開發(fā)任務(wù)可以由不同的開發(fā)人員執(zhí)行。

在一個(gè)大型的價(jià)值目標(biāo)被拆解成了Epic->用戶故事->開發(fā)任務(wù)的過程中需要全團(tuán)隊(duì)的多輪確認(rèn)，多輪確認(rèn)確保所有人達(dá)成統(tǒng)一共識 ，在最大的程度上解決溝通差帶來的不確定性。最終需要通過迭代計(jì)劃會議在團(tuán)隊(duì)內(nèi)部對價(jià)值達(dá)成共識后，才會進(jìn)行項(xiàng)目開發(fā)。

進(jìn)入開發(fā)任務(wù)后每個(gè)階段，參考下圖：

我們可以看到4重質(zhì)量保證：

• 結(jié)對編程：兩個(gè)人的腦子總比一個(gè)人想的全。（其他好處不用贅述）
• 團(tuán)隊(duì)中的代碼版本差異識別：每對Pair的代碼在一天結(jié)束時(shí)會被整個(gè)開發(fā)團(tuán)隊(duì)審核（當(dāng)然可以提高代碼質(zhì)量了）
• 代碼審計(jì)：當(dāng)對應(yīng)開發(fā)任務(wù) - PR(每筆代碼)完成后，會被整個(gè)團(tuán)隊(duì)提意見（我聽過比較離譜的就是：Our PR is waiting for more comments）,修正完成后代碼才會進(jìn)入測試階段。
• 測試: 最后的最后，才會進(jìn)行測試，整個(gè)測試則是由小團(tuán)隊(duì)內(nèi)部完成，在沒有測試的情況下，“非常態(tài)”的AC就是整個(gè)測試的通過條件。

再這樣一輪一輪的開發(fā)任務(wù)到用戶故事的價(jià)值交付后，又組成了一個(gè)Epic價(jià)值交付，最終通過Bug Bash的方式最后確認(rèn)價(jià)值以達(dá)到交付標(biāo)準(zhǔn)，我們可以上線整個(gè)Epic用于用戶的檢驗(yàn)。

總結(jié)一下敏捷開發(fā)的特點(diǎn)：

• 業(yè)務(wù) -> 開發(fā) -> 測試由一個(gè)全職能敏捷團(tuán)隊(duì)完成
• 大多數(shù)內(nèi)容由團(tuán)隊(duì)內(nèi)部確定
• 由上向下“順時(shí)針“開發(fā)
• 盡可能的小型功能，快速迭代
• 小型逆時(shí)針回調(diào)細(xì)節(jié)確認(rèn)
• 業(yè)務(wù)導(dǎo)向：業(yè)務(wù)決定質(zhì)量

用圖來表示最終內(nèi)建的結(jié)果，在最終快要上線時(shí)，經(jīng)過團(tuán)隊(duì)內(nèi)質(zhì)量把控后僅與實(shí)際有極少差距，僅需要在日常使用中進(jìn)行基礎(chǔ)運(yùn)維即可達(dá)到我們的價(jià)值目標(biāo)：

項(xiàng)目A的情況

這時(shí)候讓我們再來看項(xiàng)目A，系統(tǒng)被產(chǎn)品部門完成設(shè)計(jì)后，交予開發(fā)部門進(jìn)行任務(wù)劃分，每個(gè)開發(fā)團(tuán)隊(duì)承擔(dān)不同的功能開發(fā)任務(wù)，每個(gè)功能點(diǎn)再由單獨(dú)開發(fā)人員進(jìn)行開發(fā)并自行測試（本地），最后由客戶方進(jìn)行功能驗(yàn)收后（功能展示+代碼審核），代碼合入主線進(jìn)行轉(zhuǎn)測。

說到這兒，舉個(gè)例子，產(chǎn)品部門提供了本次需要交付的20個(gè)功能的設(shè)計(jì)圖，開發(fā)團(tuán)隊(duì)把設(shè)計(jì)圖分給交付團(tuán)隊(duì)（大多由供應(yīng)商組成），團(tuán)隊(duì)成員小王負(fù)責(zé)對其中一張?jiān)O(shè)計(jì)圖（類似于一個(gè)Epic）的功能進(jìn)行開發(fā)，開發(fā)完成后開驗(yàn)收會議，對代碼和功能進(jìn)行審核驗(yàn)證，進(jìn)入測試流程。所以開發(fā)階段歸納下來的話，如圖：

這樣乍一看確實(shí)沒有什么問題，開發(fā)流程中的各種實(shí)踐也在做，那這種項(xiàng)目研發(fā)模式問題出在哪兒呢？這個(gè)時(shí)候我們看項(xiàng)目A的關(guān)鍵質(zhì)量保證動作：測試。

項(xiàng)目A的測試步驟：

先拋結(jié)論，在測試階段，80%時(shí)間用于確定問題+定位問題（標(biāo)紅）。所以我們可以著重討論一下這兩個(gè)階段。

確認(rèn)問題：在確認(rèn)問題階段， 往往由測試組發(fā)起，通過層層追溯，可以追溯到開發(fā)人員（也就是小王），跟小王確認(rèn)表現(xiàn)層的“靜態(tài)”/“動態(tài)”/“非常態(tài)”問題后，測試順利成章地建立一個(gè)問題工單，并分配給小王，宣告此單插在了小王頭上，小王需要修正再找測試回歸。乍一看又沒什么問題，是個(gè)好流程，但是執(zhí)行起來此流程會出現(xiàn)：

• 因?yàn)闇y試標(biāo)準(zhǔn)中有較多主觀的感官感受，導(dǎo)致在跟開發(fā)確認(rèn)問題時(shí)經(jīng)常出現(xiàn)主觀問題，此時(shí)需要產(chǎn)品介入，并用主觀感受進(jìn)行判定。（缺少用戶旅程細(xì)節(jié)）

舉例：（一個(gè)電話拉會）“小王，我覺得這個(gè)頁面幀數(shù)好低，你要優(yōu)化一下?！薄鞍?？？？”（此處省略battle的10分鐘）終于電話給了產(chǎn)品，產(chǎn)品一句話：“是幀數(shù)有點(diǎn)低?。⌒⊥?，這你得改”“…”

• 需要產(chǎn)品介入的場景往往流程會變得極長。測試在做測試中，會考慮很多“非常態(tài)“問題，在非常態(tài)問題中，往往會導(dǎo)致”靜態(tài)“”動態(tài)“的變更，然后經(jīng)過工單追蹤，產(chǎn)品組漫長的重新設(shè)計(jì)，然后再由開發(fā)進(jìn)行更改。
• 當(dāng)存在“扯皮”問題，又是另外一副光景。

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

• 開發(fā)的專注思考時(shí)間被切碎。在轉(zhuǎn)測后，需要大量地確認(rèn)問題，也就是跟測試打電話，測試往往是發(fā)現(xiàn)問題第一時(shí)間就會確認(rèn)問題，這樣導(dǎo)致開發(fā)人員每天專注于代碼工作的時(shí)間被切碎，效率直接下降。

定位問題： 定位問題同樣占據(jù)了開發(fā)人員的大量時(shí)間，總體來說：

• 大量追溯代碼：確認(rèn)問題后，有時(shí)會需要確定整個(gè)功能代碼中的問題點(diǎn)，問題很難定位，尤其遇到比較棘手的概率，性能問題需要對整個(gè)代碼進(jìn)行回顧與重構(gòu)。
• 涉及他方代碼：當(dāng)在長時(shí)間確認(rèn)問題后，問題有時(shí)會涉及他人代碼，比如框架代碼，他人功能代碼，硬件代碼，這時(shí)候需要你找到相關(guān)人（打電話），解釋，最終把工單走到他人名下（當(dāng)然沒人愿意接單，長時(shí)間Battle在所難免）。
• 定位到無法修改的問題：當(dāng)然在這里又有專門的流程做這件事，問題就出現(xiàn)在因?yàn)閳F(tuán)隊(duì)間的互相的部門/信任墻，需要長流程（COC：需求變更會議）來共同確認(rèn)問題，需要引入大量具有決策權(quán)的角色：另外團(tuán)隊(duì)的架構(gòu)師，產(chǎn)品經(jīng)理，測試經(jīng)理，還有可憐的小王。最終一個(gè)無法修改的工單往往需要2周或者更多的時(shí)間進(jìn)行關(guān)閉。
• 流程反復(fù)：當(dāng)出現(xiàn) 確認(rèn)問題->定位問題->確認(rèn)問題->定位問題…這個(gè)如此反復(fù)的流程時(shí)，對開發(fā)和測試的神經(jīng)都是一個(gè)極大的考驗(yàn)。

后續(xù)的修改流程往往較為順利，但是也會出現(xiàn)一個(gè)工單反復(fù)無法通過回歸的問題，這畢竟是少數(shù)，也不是我們主要探討的范疇。項(xiàng)目在強(qiáng)流程驅(qū)動下最終的結(jié)果就是：

所有人每天都在加班，所有人每天都在增加流程以確保質(zhì)量，所有人都很痛苦，當(dāng)然這里包括小王。

用圖來表示開發(fā)結(jié)束后的狀態(tài)，空隙區(qū)域代表不確定問題，空隙部分需要測試->開發(fā)->產(chǎn)品逆流程更改

總結(jié)

說了這么多細(xì)節(jié)，我想現(xiàn)在跳出來問“為什么會出現(xiàn)這樣的問題？”這個(gè)問題我也想留個(gè)大家做一點(diǎn)思考，我做了一些簡單而又主觀的總結(jié)，放在這里：

• 共識缺失：當(dāng)大家都在自己的職能部門做自己的工作時(shí)，往往會主觀地做這件事兒，當(dāng)這件事兒在后續(xù)流轉(zhuǎn)時(shí)，沒有通過一個(gè)整體共識的話，往往需要從底端流程不斷向上確認(rèn)達(dá)成共識。
• 大規(guī)?！澳鏁r(shí)針”回調(diào)：因?yàn)檎w共識由測試發(fā)起，加上部門墻重，往往導(dǎo)致從測試->開發(fā)->產(chǎn)品的逆時(shí)針開發(fā)流程，代碼重構(gòu)與返工的工作量極大。
• 價(jià)值產(chǎn)出慢：當(dāng)最終功能在大量回調(diào)時(shí)，價(jià)值產(chǎn)出很慢，導(dǎo)致驗(yàn)證慢，最終導(dǎo)致逆向反饋增加。
• 流程決定質(zhì)量：還是由測試流程來確定質(zhì)量的情況下，在產(chǎn)品只進(jìn)行Happy Pass的情況下，所有人的彌合質(zhì)量的成本都在成倍增加。

看完了項(xiàng)目A和項(xiàng)目B的整體, 我們最后再來聊聊效率，我們發(fā)現(xiàn)，在同等的質(zhì)量要求下，敏捷效率反而高很多，在流程更短的情況下卻交付出了同樣質(zhì)量很高的產(chǎn)品，最后我們通過對比總結(jié)一下，為什么敏捷在保證質(zhì)量的同時(shí)還能有更高的效率？

我們暫且停在這兒，我要引用SAFe中的一張圖來結(jié)束我今天的闡述，也在用實(shí)例回答：“為什么企業(yè)要做大規(guī)模敏捷？”

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