滿足善變用戶:追求用戶價值覆蓋率,而不是代碼覆蓋率!

jopen 9年前發布 | 5K 次閱讀 代碼

文/ThoughtWorks-伍斌 

在用戶價值多變的情況下進行軟件開發,為了能更快速地向用戶交付有價值的軟件,開發團隊應該專注于用戶價值覆蓋率,而不是代碼覆蓋率。

代碼覆蓋率(Code Coverage)[1]是一種用來描述程序的源代碼被特定的測試套件所測試的程度的度量手段。與具有低代碼測試覆蓋率的程序相比,具有高代碼測試覆蓋率的程序會被更加全面地加以測試,并且其缺陷會更少。

代碼覆蓋率是 Miller 和 Maloney 兩人在 1963 年出版的 Communications of the ACM 雜志上首先提出的。對于那時以用戶價值變化很少的科學計算為主的軟件應用開發來說,開發團隊將軟件開發質量的重心放到代碼覆蓋率上是適宜的。但隨著強調用 戶體驗的互聯網時代的到來,在當前大量的軟件開發過程中,用戶價值的變化速度已經大大超過 50 多年前的水平。如果開發團隊繼續“將軟件開發質量的重心放到代碼覆蓋率上”,那么會造成大量的工作時間被浪費在開發和測試已無用戶價值的代碼之上,從而導 致開發有用戶價值的代碼時間減少,進而延期交付對用戶有價值的軟件產品。

下圖以一個新項目的開發過程為例來說明上述問題。

滿足善變用戶:追求用戶價值覆蓋率,而不是代碼覆蓋率!

上圖中紅圈代表團隊識別出來并要實現的用戶價值,藍圈代表系統已有的代碼所實現的功能,兩個圈相交的部分,表示代碼實現了用戶價值的部分。

在項目啟動時,紅圈較小,且隨著識別的用戶價值的增多而不斷地增大,另外,它會隨著用戶價值的變化而不斷變化,從而產生移動。此時由于編程工作剛剛起步,所以藍圈很小。

隨著項目的進展,代碼實現也逐漸變多。但由于下面 3 個原因,代表代碼實現的藍圈會與代表用戶價值的紅圈發生偏離:

1)由于諸如程序員和領域專家各講各自的方言所致的誤解等原因,代碼僅實現部分甚至沒有實現原先識別的用戶價值;

2)當針對原先識別的用戶價值的代碼編寫完畢后,團隊識別出原先的用戶價值有部分功能需要刪減(用上圖中最下邊那個右邊缺了半圓的紅圈來代表);

3)團隊又識別出新的尚未編寫代碼的用戶價值(用上圖中最下邊那個左邊多了半圓的紅圈來代表)。

而在面對上述第 2 個原因中那些不再具備用戶價值代碼時,程序員會將其刪除嗎?在自動化測試覆蓋不全面、手工測試反饋較慢、代碼邏輯和耦合復雜、進度很緊等等這些很“骨感” 的現實情況下,程序員往往選擇不去刪除。“誰會保證在刪代碼時,不會把系統搞掛?”程序員不刪那些已經不具備用戶價值的代碼,又加劇了紅圈與藍圈的分離。 隨著過時的用戶價值不斷被刪減,那些不會被刪除的已經失去用戶價值的代碼就會越積越多,這使得藍圈右側刪不掉的尾巴會越拖越長。

在這種情況下,就出現了“代碼覆蓋率悖論”:如果 IT 企業只將注意力放到提高代碼覆蓋率,而忽視提高不斷變化的用戶價值覆蓋率,那么就導致團隊會把時間浪費在閱讀和測試哪些已經失去用戶價值的代碼上,從而延誤開發那些新演進出來的用戶價值,無法快速滿足用戶需求。

相對“用戶價值”這個“終”來說,代碼僅僅是一個階段的“始”。要快速地交付用戶價值,我們需要“以終為始”地進行軟件開發,將注意力放到以紅圈所代表的用戶價值這個“終”之上,隨著它的不斷變化來持續追求用戶價值的覆蓋率,而不是追求代碼覆蓋率。

[1] 引自:https://en.wikipedia.org/wiki/Code_coverage

內容來源:ThoughtWorks 洞見

 本文由用戶 jopen 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!