在專案進行的過程中, 常常遇到一件事情. 有件工作需要 10 天完成, 某個工程師領了這個工作, 到了第 10 天結束時, 跟大家說我只完成 90%, 所以還有 10% 要完成.

如果你是老闆, 你會覺得剩下 10% 還需要 1 天嗎？我想大多數的人不會這樣好傻好天真, 通常剩下這 10% 往往需要更多天才能完成. 90% 或是 10% 這些都是假的, 都是自己想像的時間. 因此, 敏捷中不相信百分之幾完成, 它只有分做完沒做完兩種. 為了讓大家對做完有共識, 避免日後來跟我說, 我說的做完是開發完成, 而不是你說的可以上線. 為了避免這樣的誤解, 我們需要有完成的定義 (Definition of Done).

當多個團隊一起開發時, 因為人多資訊傳遞不易, 在 LeSS 中非常強調需要有完成的定義. 在開始要導入 LeSS 時, 當你把團隊組件和 backlog 準備完後, 接下來便是要定義完成的定義. 這會有兩個好處:

(1) 透明性

讓所有人對於何謂做完有共識, 都清楚要做到什麼程度, 讓 Daily Scrum 時不會浪費時間在確認開發人員是否真的做完.

(2) 持續改善

完成的定義可以拿來當作持續改善的工具. 團隊一開始定義的做完, 通常不會太多或是太嚴謹, 在每次回顧會議討論調整, 我們就可以把新增的項目加到完成的定義中. 這部分我們後面會提到.

在制定完成的定義時, 以下幾件事情需要注意

(1) 端到端

完成的定義不該只程式開發階段, 需要看的是整體端到端的部分, 要交付到用戶手上, 那些事情該做, 就都要寫到完成的定義中. 例如, 一般常見的問題開發人員只會寫以下項目:

程式開發完畢並 check-in 到版控系統
有進行單元測試並且通過

但是要交付到客戶手上, 可能還需要加上以下項目

部署到 SIT 測試並通過
在 SIT 環境測試通過後有部署到 production 環境, 並確認沒有問題
要準備好發佈說明, 讓用戶知道有哪些更新

這樣才是完整的完成的定義, 包含了從想法到最後教到客戶手上, 這中間所有需要完成的事情.

(2) 涵蓋各個角色的事情

除了要包含端到端整體的流程, 還需要包含所有角色, 或者是所有階段. 我們往往只看開發這個角色, 並且也只有在功能開發這個階段. 但是在你的環境中, 你的團隊可能不只有開發人員, 也許還要用戶體驗設計師和測試人員. 你必須要都考量進去, 否則只是半成品, 之後還需要再進行一些事情, 才能真的交付給客戶.

(3) 討論如何未完成的事情

上面寫到需要考慮端到端和各個角色的情況, 但在真實世界中, 團隊不見得能在迭代中完成這麼多事情, 只會做部分的事情, 那這個會導致什麼呢?

a. 同事誤以為你完成了
大家會以為這件事你已經做完後, 便會想要安排後續的工作. 例如: 準備和你的東西做整合, 或者給你其他新的需求去開發. 但是事實上你還需要時間來收尾.
最可怕的是你的主管以為你真的完成, 誤以為專案目前都是按照進度, 沒有規劃好一些因應措施, 等到後面才發現還有事情要再處理, 往往可能剩的時間已經不多了.

b. 後面需要安排時間來補救
這些號稱完成的需求, 不是真的完成, 沒有具備可以發布的品質, 你需要後面再安排來做完. 所以會類似 hardening sprint 的概念, 在那個迭代中, 不會再開發新功能, 時間多數是用來進行測試, 或是完成之前沒有完成的工作, 以確保這些事情做完後, 可以真正把需求交付給客戶. 很多人說這不是 Scrum, 不是好的實務 (practice). 但是你就是沒有做完, 你還是需要他們來補救.

(4) 利用完成的定義持續改善

很多團隊一開始無法訂出完整的完成的定義, 可能是團隊的能力不足, 或是時間緣故. 不管是什麼理由, 在 LeSS 中我們把它視為是一種改善的機會, 可以讓我們有機會持續加強.
例如, 一開始團隊列出的完成的定義如下:
a. 需求開發完代碼有 check-in 到 git
b. 測試有執行通過
c. 沒有修復的 bug 有替代解法或是不會對客戶有重大影響

大家可能會覺得這個太簡單了. 但是, 有可能團隊剛組成, 很多東西還沒有準備好, 需要時間來處理. 因此, 你可能會在後面的迭代補上未來得及處理的工作. 並且再重新討論一次完成的定義, 修改如下:

a. 需求開發完代碼有 check-in 到 git
b. 測試有執行通過
c. 沒有修復的 bug 有替代解法或是不會對客戶有重大影響
d. 代碼需要通過檢視

為什麼不考慮測試自動化呢? 可能團隊那時候還沒有能力, 他們還沒選好工具. 也可能已經有工具, 但是不知如何針對 legacy code 撰寫自動化測試. 因此, 他們需要安排教育訓練, 需求時間去練習. 因此, 在一段時間之後, 團隊熟悉測試自動化的技能, 且再重新討論一次完成的定義, 修改如下:

a. 需求開發完代碼有 check-in 到 git
b. 測試有執行通過
c. 沒有修復的 bug 有替代解法或是不會對客戶有重大影響
d. 代碼需要通過檢視
e. 需要撰寫單元測試

再一段時間後, 團隊單元測試的技能也純熟了, 並且個案數也達到一定的數量, 這時候我們可以再繼續調整完成的定義

a. 需求開發完代碼有 check-in 到 git
b. 測試有執行通過
c. 沒有修復的 bug 有替代解法或是不會對客戶有重大影響
d. 代碼需要通過檢視
e. 需要撰寫單元測試
f. 單元測試的涵蓋率並且達到 70 %

在 LeSS 中這樣的活動會一直反覆進行, 每次改善一點, 但是這樣的活動回一直持續. 它不會把完成的定義變成一個教條, 或是一次性的活動.