Agile 🏈 做到什麼時候才能到頭啊?談做完的定義 DoD

Jayden Lin
Aug 31 · 6 min read

筆者任職 Yahoo ,《軟體需求溝通 ─ 從外商公司學跨部門協作開發》線上課程講師,紛絲團《程式猿吃香蕉🍌》

最近有位以前的同事問我,她帶團隊常常改了 A 功能壞了 B 功能,要怎麼定義「做完」這件事情來要求他的團隊?這種鳥日子,什麼時候才能到頭啊?

為什麼「做完」這件事情很難定義?因為隨著時間過去,你的團隊會成長,商業的需求會改變,做完的定義 (Definition of Done,DoD) 也是會改變的,甚至是在每一次開發的迭代週期後都可以改變。

以譬喻的方式來說,健身教練沒有辦法給你同一份訓練菜單,用白紙黑字定義你「做完」後,就可以變成健美先生,因為你的體質會隨時間改變,此外,健美的標準可能也會改變,菜單也要對應的調整。

做完的定義 (Definition of Done,DoD) 之於軟體產品也是一樣的道理。隨著時間過去,不僅你的團隊會改變,利害關係人(Stakehodler) 在意的需求也會跟著改變。既然變化那麼多,那我們該怎麼辦呢?

先說結論,即使現實世界變化很多,但我們依然可以化繁為簡,將做完這件事情定義為:

完成一個可用的軟體 (Working Software)

以下我們來詳細談一談,什麼是做完的定義 (Definition of Done,DoD)。

▍做完的定義 (Dod) 與可用的軟體 (Working Software)

先前我有一篇文章談到以可用的軟體(Working Software) 來衡量軟體進度是最好的方式。因此在每一次進度中,做完這件事情,可以理解為完成了一個版本的可用的軟體 (Working Software) 。

根據定義,可用的軟體 (Working Software) 是:

  • 完全整合的 (Fully-integrated)
  • 可以被測試的 (Testable)
  • 可以被驗證的 (Verifiable)
  • 並且可以準備交付給使用者或是部署到正式環境的

因此完成一個新功能的時候,可以用上述的條件作為標準來檢視「做完」照這件事。如果都符合了,便可以稱為做完。當然不同的專案和團隊,所要求的測試和驗證程度不同,我們可以用上述的條件做為大綱,而細節程度的拿捏可以依照實際情況自行調整 。

▍做完的定義 (Dod) :不同程度的做完

既然我們要以可用的軟體 (Working Software) 當作標準來當作「做完」。但是先前的文章也有提到, 以可用的軟體作為軟體進度衡量是需要技術力支撐的,以我朋友的例子來說,如果團隊現況就是改了 A 會壞 B ,短時間無法改變,那麼做完的定義 (DoD) 細節程度的拿捏可以依照實際情況自行調整,以下為範例:

(1) 如果是接手老舊系統,很難全面做單元測試,至少可以先要求:

🔖 API Endpoint POST/PUT/DELETE(有修改狀態的)都要完成自動化測試
🔖 UI 手動測試要完成

在某種程度上,也算是完成了完全整合的 (Fully-integrated) 、可被測試的 (Testable) 等等條件。

(2) 等待團隊訓練起來了,之後可以再加上這些要求:

🔖 新進的程式碼要有 80% 單元測試 Code Coverage
🔖 用 Selenium 自動化測 UI 某些關鍵路徑,要完成測試才算做完

同樣的,當團隊擴大之後,或是程式碼 (Code base) 愈來愈多,做完的要求更是大不相同,以下舉幾個以前在參與跨國開發時遇到的例子:

🔖 設計師跟工程師都要先做完 Mock up review 
🔖 Core team 先評估過共用函式庫(Common Library)的使用
🔖 要求單元測試要 90% 以上
🔖 UI 測試需要撰寫文件說明該怎麼測

這些在專案一開始時都沒有要求,但隨著專案規模愈來愈大,或是一些現實層面的管理問題,而陸續補上這些內容。

▍做完的定義 (DoD) 是共同的認知 (Shared Understanding)

可用的軟體 (Working Software) 是一種共同的認知 (Shared Understanding),是要團隊成員都同意的。以蓋房子的例子來說,到底要先蓋客廳還是先蓋臥室?從客戶、PM、工程師、設計師是要有共識的。如果決定要先蓋臥室,在測試時不會有人突然跳出來說:「怎麼先蓋臥室?客廳是壞的!」

同樣,做完的定義 (DoD) 是基於可運行軟體的定義來展開,因此它也是一種共同的認知 (Shared Understanding),當然你可以逐條寫下清單,哪些是要做完的項目,但更重要的是,要花時間說服大家並且讓他們理解這份清單。

以我朋友的例子來說,他便需要說服客戶與老闆目前的情況,現況就是改了 A 會壞 B,以及測試只能做到什麼樣的程度等等,團隊需要時間來改進。

▍做完的定義 (DoD) :現實層面考量

即使法官判刑有時都需要依賴法官的「心證」,在軟體開發上,光憑白紙黑字很難完全描述做完的定義(DoD),如果強制說以白紙黑字為準,代表公司團隊間的信任已經瓦解,很容易淪為公司政治上的踢皮球遊戲。因此真正執行時,還需要仰賴團隊間的信任。

從前我習慣將需求都寫成文件,但是「別人憑什麼要看你寫的文件?」這是我在職涯早期,某位前輩教誨過我的話。

其實這句話說得一點都沒錯,做完的定義 (DoD) 重點在於建立共同的認知 (Shared Understanding),也許多約一個會議,多花時間做坐下來與對方多談幾句話,建立共同的認知更為重要。

(附上最近常聽的一首歌「憑什麼」)

▍小結

以上是我對做完的定義 (DoD) 的探討,它可以依照可用的軟體 (Working Software) 的定義進行展開、可以隨著時間演化變動、可以依照現實情況調整,最後,建立共同的認知 (Shared Understanding) 才是 DoD 的目的。

若是喜歡我分享的內容,歡迎幫我按個拍手,可拍 50下,給我一點鼓勵,或是加入我的粉絲團《程式猿吃香蕉🍌》,一起分享軟體知識與心得!

程式猿吃香蕉

喜歡將軟體知識以簡單生動的方式講給你聽

程式猿吃香蕉

『來點更營養的軟體知識,吃香蕉吧!』我們是一群軟體開發愛好者,喜歡將軟體知識以簡單生動的方式講給你聽,順口好消化,營養又健康!

Jayden Lin

Written by

Yahoo 擔任 Lead Engineer,負責廣告系統,帶團隊做跨國開發。也是《程式猿吃香蕉》團隊創辦人,喜歡將實用的軟體知識以簡單生動的方式講給大家聽 😄😄😄

程式猿吃香蕉

『來點更營養的軟體知識,吃香蕉吧!』我們是一群軟體開發愛好者,喜歡將軟體知識以簡單生動的方式講給你聽,順口好消化,營養又健康!