建站
咨詢
售后
建站咨詢
新聞中心
作者 | 曾雪松
背景
軟件工程里一個重要的指標(biāo)就是“可用的軟件”，敏捷宣言里也同樣告訴我們“工作的軟件高于詳盡的文檔”，那“可用的軟件”、“工作的軟件”意味著什么呢？在我的理解里，可以經(jīng)歷用戶 “千錘百煉”的軟件就是一個“可用的軟件”。曾經(jīng)聽到過這樣的說法：“一個有Bug的軟件怎么能叫軟件呢？”雖然這話在我們業(yè)內(nèi)人士聽起來有些可笑，但是這就是使用軟件用戶最真實的需求。所以如何在提高代碼質(zhì)量，最大程度地減少軟件中的Bug同時，平衡軟件迭代速度與交付效率是我今天想跟大家討論的問題。
我有幸在兩種完全不同風(fēng)格的項目上進(jìn)行過交付，讓我們且稱之為項目A和項目B。
項目A是一個客戶為主導(dǎo)的巨大項目組，管理為明確縱向?qū)蛹壒芾?，橫向開發(fā)團隊來自于不同的供應(yīng)商，并且采用瀑布式開發(fā)，由另一個事業(yè)部進(jìn)行測試反饋，部門墻極其嚴(yán)重。
項目B則是一個由業(yè)務(wù)主導(dǎo)，每個敏捷團隊有對應(yīng)相關(guān)的業(yè)務(wù)領(lǐng)域，客戶則是和供應(yīng)商共同組成一個個敏捷團隊，共同達(dá)成業(yè)務(wù)目標(biāo)。
好了，完成了簡單的背景介紹，我就要來說說下面的故事了。
故事
總覽
首先，假設(shè)我們所需要達(dá)到的目標(biāo)是由一個個大大小小功能（顏色模組）組成一個完整的軟件，為了達(dá)到我們的交付目標(biāo)，我們需要將每個功能進(jìn)行開發(fā)，測試，將功能模塊進(jìn)行累加，最終獲得一個完整而達(dá)標(biāo)的軟件。
同時兩個項目都使用了大致相同的開發(fā)流程，為了保證質(zhì)量，項目中都有基礎(chǔ)的代碼審計，CI/CD，應(yīng)用測試，用戶測試，等基本質(zhì)量保證，軟件開發(fā)的基礎(chǔ)流程如下圖：
在這種基礎(chǔ)流程都相近的情況下，每個環(huán)節(jié)在不同架構(gòu)下執(zhí)行的的方式卻有巨大的差異。
在討論項目A的流程前，讓我們先看看我們熟知的敏捷開發(fā)是怎么保證質(zhì)量的：
項目B的情況
項目b的每一個小敏捷團隊將業(yè)務(wù)需求從路徑圖（Roadmap）拆解下來，落到各大的業(yè)務(wù)功能的Epic中，再拆解成具有小的業(yè)務(wù)價值的用戶故事，最后再落到每個具有開發(fā)意義的任務(wù)，注意，這里提的一直是業(yè)務(wù)價值，我們還沒有開始討論如何進(jìn)入開發(fā)。
Epic 更多是獨立且較大的目標(biāo)，用于我們識別在關(guān)鍵時間點需要實現(xiàn)的大型業(yè)務(wù)目標(biāo)。而用戶故事則是一個簡短的描述、一個用于表達(dá)用戶或客戶的需求的角色和一個用于描述需求的價值或期望結(jié)果的價值陳述，在用戶故事中比較關(guān)鍵描述是關(guān)于此價值點的“靜態(tài)““動態(tài)”與“非常態(tài)“，靜態(tài)更多的是對價值點的描述，在To C中往往是靜態(tài)設(shè)計圖（UI）的描述，動態(tài)則是交互，系統(tǒng)間的交互或者功能的用戶旅程（UX），而非常態(tài)則是描述系統(tǒng)在錯誤或者誤差情況下的表現(xiàn)，以確保當(dāng)前的價值點在絕大多數(shù)情況下得以運行（AC）。最終用戶故事將被團隊中的技術(shù)領(lǐng)導(dǎo)拆解成可以單獨執(zhí)行的開發(fā)任務(wù)，最終沒個獨立的開發(fā)任務(wù)可以由不同的開發(fā)人員執(zhí)行。
在一個大型的價值目標(biāo)被拆解成了Epic->用戶故事->開發(fā)任務(wù)的過程中需要全團隊的多輪確認(rèn)，多輪確認(rèn)確保所有人達(dá)成統(tǒng)一共識 ，在最大的程度上解決溝通差帶來的不確定性。最終需要通過迭代計劃會議在團隊內(nèi)部對價值達(dá)成共識后，才會進(jìn)行項目開發(fā)。
進(jìn)入開發(fā)任務(wù)后每個階段，參考下圖：
我們可以看到4重質(zhì)量保證：
- 結(jié)對編程：兩個人的腦子總比一個人想的全。（其他好處不用贅述）
- 團隊中的代碼版本差異識別：每對Pair的代碼在一天結(jié)束時會被整個開發(fā)團隊審核（當(dāng)然可以提高代碼質(zhì)量了）
- 代碼審計：當(dāng)對應(yīng)開發(fā)任務(wù) - PR(每筆代碼)完成后，會被整個團隊提意見（我聽過比較離譜的就是：Our PR is waiting for more comments）,修正完成后代碼才會進(jìn)入測試階段。
- 測試: 最后的最后，才會進(jìn)行測試，整個測試則是由小團隊內(nèi)部完成，在沒有測試的情況下，“非常態(tài)”的AC就是整個測試的通過條件。
再這樣一輪一輪的開發(fā)任務(wù)到用戶故事的價值交付后，又組成了一個Epic價值交付，最終通過Bug Bash的方式最后確認(rèn)價值以達(dá)到交付標(biāo)準(zhǔn)，我們可以上線整個Epic用于用戶的檢驗。
總結(jié)一下敏捷開發(fā)的特點：
- 業(yè)務(wù) -> 開發(fā) -> 測試由一個全職能敏捷團隊完成
- 大多數(shù)內(nèi)容由團隊內(nèi)部確定
- 由上向下“順時針“開發(fā)
- 盡可能的小型功能，快速迭代
- 小型逆時針回調(diào)細(xì)節(jié)確認(rèn)
- 業(yè)務(wù)導(dǎo)向：業(yè)務(wù)決定質(zhì)量
用圖來表示最終內(nèi)建的結(jié)果，在最終快要上線時，經(jīng)過團隊內(nèi)質(zhì)量把控后僅與實際有極少差距，僅需要在日常使用中進(jìn)行基礎(chǔ)運維即可達(dá)到我們的價值目標(biāo)：
項目A的情況
這時候讓我們再來看項目A，系統(tǒng)被產(chǎn)品部門完成設(shè)計后，交予開發(fā)部門進(jìn)行任務(wù)劃分，每個開發(fā)團隊承擔(dān)不同的功能開發(fā)任務(wù)，每個功能點再由單獨開發(fā)人員進(jìn)行開發(fā)并自行測試（本地），最后由客戶方進(jìn)行功能驗收后（功能展示+代碼審核），代碼合入主線進(jìn)行轉(zhuǎn)測。
說到這兒，舉個例子，產(chǎn)品部門提供了本次需要交付的20個功能的設(shè)計圖，開發(fā)團隊把設(shè)計圖分給交付團隊（大多由供應(yīng)商組成），團隊成員小王負(fù)責(zé)對其中一張設(shè)計圖（類似于一個Epic）的功能進(jìn)行開發(fā)，開發(fā)完成后開驗收會議，對代碼和功能進(jìn)行審核驗證，進(jìn)入測試流程。所以開發(fā)階段歸納下來的話，如圖：
這樣乍一看確實沒有什么問題，開發(fā)流程中的各種實踐也在做，那這種項目研發(fā)模式問題出在哪兒呢？這個時候我們看項目A的關(guān)鍵質(zhì)量保證動作：測試。
項目A的測試步驟：
先拋結(jié)論，在測試階段，80%時間用于確定問題+定位問題（標(biāo)紅）。所以我們可以著重討論一下這兩個階段。
確認(rèn)問題：在確認(rèn)問題階段， 往往由測試組發(fā)起，通過層層追溯，可以追溯到開發(fā)人員（也就是小王），跟小王確認(rèn)表現(xiàn)層的“靜態(tài)”/“動態(tài)”/“非常態(tài)”問題后，測試順利成章地建立一個問題工單，并分配給小王，宣告此單插在了小王頭上，小王需要修正再找測試回歸。乍一看又沒什么問題，是個好流程，但是執(zhí)行起來此流程會出現(xiàn)：
- 因為測試標(biāo)準(zhǔn)中有較多主觀的感官感受，導(dǎo)致在跟開發(fā)確認(rèn)問題時經(jīng)常出現(xiàn)主觀問題，此時需要產(chǎn)品介入，并用主觀感受進(jìn)行判定。（缺少用戶旅程細(xì)節(jié)）
舉例：（一個電話拉會）“小王，我覺得這個頁面幀數(shù)好低，你要優(yōu)化一下。”“?。?？？”（此處省略battle的10分鐘）終于電話給了產(chǎn)品，產(chǎn)品一句話：“是幀數(shù)有點低啊！小王，這你得改”“…”
- 需要產(chǎn)品介入的場景往往流程會變得極長。測試在做測試中，會考慮很多“非常態(tài)“問題，在非常態(tài)問題中，往往會導(dǎo)致”靜態(tài)“”動態(tài)“的變更，然后經(jīng)過工單追蹤，產(chǎn)品組漫長的重新設(shè)計，然后再由開發(fā)進(jìn)行更改。
- 當(dāng)存在“扯皮”問題，又是另外一副光景。
舉例：測試打電話給小王，小王說“這不是我的問題，你找xx團隊的小李 ”，小李接上電話，“這是你小王開發(fā)的啊”..(再次省略battle時間)最終問題很有可能上升到客戶方確定問題邊界，這樣1個小時就過去了。
- 開發(fā)的專注思考時間被切碎。在轉(zhuǎn)測后，需要大量地確認(rèn)問題，也就是跟測試打電話，測試往往是發(fā)現(xiàn)問題第一時間就會確認(rèn)問題，這樣導(dǎo)致開發(fā)人員每天專注于代碼工作的時間被切碎，效率直接下降。
定位問題： 定位問題同樣占據(jù)了開發(fā)人員的大量時間，總體來說：
- 大量追溯代碼：確認(rèn)問題后，有時會需要確定整個功能代碼中的問題點，問題很難定位，尤其遇到比較棘手的概率，性能問題需要對整個代碼進(jìn)行回顧與重構(gòu)。
- 涉及他方代碼：當(dāng)在長時間確認(rèn)問題后，問題有時會涉及他人代碼，比如框架代碼，他人功能代碼，硬件代碼，這時候需要你找到相關(guān)人（打電話），解釋，最終把工單走到他人名下（當(dāng)然沒人愿意接單，長時間Battle在所難免）。
- 定位到無法修改的問題：當(dāng)然在這里又有專門的流程做這件事，問題就出現(xiàn)在因為團隊間的互相的部門/信任墻，需要長流程（COC：需求變更會議）來共同確認(rèn)問題，需要引入大量具有決策權(quán)的角色：另外團隊的架構(gòu)師，產(chǎn)品經(jīng)理，測試經(jīng)理，還有可憐的小王。最終一個無法修改的工單往往需要2周或者更多的時間進(jìn)行關(guān)閉。
- 流程反復(fù)：當(dāng)出現(xiàn) 確認(rèn)問題->定位問題->確認(rèn)問題->定位問題…這個如此反復(fù)的流程時，對開發(fā)和測試的神經(jīng)都是一個極大的考驗。
后續(xù)的修改流程往往較為順利，但是也會出現(xiàn)一個工單反復(fù)無法通過回歸的問題，這畢竟是少數(shù)，也不是我們主要探討的范疇。項目在強流程驅(qū)動下最終的結(jié)果就是：
所有人每天都在加班，所有人每天都在增加流程以確保質(zhì)量，所有人都很痛苦，當(dāng)然這里包括小王。
用圖來表示開發(fā)結(jié)束后的狀態(tài)，空隙區(qū)域代表不確定問題，空隙部分需要測試->開發(fā)->產(chǎn)品逆流程更改
總結(jié)
說了這么多細(xì)節(jié)，我想現(xiàn)在跳出來問“為什么會出現(xiàn)這樣的問題？”這個問題我也想留個大家做一點思考，我做了一些簡單而又主觀的總結(jié)，放在這里：
- 共識缺失：當(dāng)大家都在自己的職能部門做自己的工作時，往往會主觀地做這件事兒，當(dāng)這件事兒在后續(xù)流轉(zhuǎn)時，沒有通過一個整體共識的話，往往需要從底端流程不斷向上確認(rèn)達(dá)成共識。
- 大規(guī)模“逆時針”回調(diào)：因為整體共識由測試發(fā)起，加上部門墻重，往往導(dǎo)致從測試->開發(fā)->產(chǎn)品的逆時針開發(fā)流程，代碼重構(gòu)與返工的工作量極大。
- 價值產(chǎn)出慢：當(dāng)最終功能在大量回調(diào)時，價值產(chǎn)出很慢，導(dǎo)致驗證慢，最終導(dǎo)致逆向反饋增加。
- 流程決定質(zhì)量：還是由測試流程來確定質(zhì)量的情況下，在產(chǎn)品只進(jìn)行Happy Pass的情況下，所有人的彌合質(zhì)量的成本都在成倍增加。
看完了項目A和項目B的整體, 我們最后再來聊聊效率，我們發(fā)現(xiàn)，在同等的質(zhì)量要求下，敏捷效率反而高很多，在流程更短的情況下卻交付出了同樣質(zhì)量很高的產(chǎn)品，最后我們通過對比總結(jié)一下，為什么敏捷在保證質(zhì)量的同時還能有更高的效率？
我們暫且停在這兒，我要引用SAFe中的一張圖來結(jié)束我今天的闡述，也在用實例回答：“為什么企業(yè)要做大規(guī)模敏捷？”
我想答案是：質(zhì)量高，效率快，大家都開心。
網(wǎng)站欄目：為什么企業(yè)要做大規(guī)模敏捷？
標(biāo)題網(wǎng)址：http://m.5511xx.com/article/dhdioip.html
