終於，我們開始跑scrum了。

在跑scrum的過程中，免不了要把需求寫成user story，再在每個story中定義什麼叫做『完成』。PO每個sprint都會明確告訴我們說：『這個需求，我的驗收條件就是要看到以下三件事情被做到。』一旦明確定義了，那麼等到sprint結束，上面三點只要有任何一點沒做到，就叫做未完成故事，這個sprint也就變成未完成sprint了。記得嗎？敏捷世界裡有這麼一句話：

Done is better than perfect.

因為我們想要用很短的時間『完成』一些事，而不是花很多時間做一件很完美的事，所以，明白告訴團隊成員什麼叫做『完成』就變得異常重要。否則，你說你的，我做我的，那不就跟我現在的工作一樣了嗎？反正做不完大不了延期交貨嚕...。萬萬不可。我們不就是為了不想再走老路才開始跑敏捷流程的嗎？

大師怎麼看

我們來看看大師的看法先。在Essential Scrum一書中，作者Kenneth S. Rubin就舉了一個好例子。他說，當他問兒子是否做完全部作業，兒子總是很有自信地回答：『是的。』然而等他參加家長會親自老師時，老師卻說：『不完全是。』這就怪了，同樣一份作業，為什麼老書的回答跟兒子不同，莫非兒子說謊騙老爸？

幸好作者沒有像某些父母一樣，不由分說地認為孩子說謊而痛打一頓。他向兒子詳細詢問後才發現事實是：兒子做完了『他打算做的部分』，換言之，其他部分他不認為是他應該做的。因此，他跟兒子就此約定：『以後我們說把功課做完時，意思是做到老師要求我們做的部分。』為什麼？原因很簡單。在這場作業的交易中，老師是客戶，是需求提出者。兒子是執行者，是scrum團隊中的member。這份作業到底做完了沒，怎樣也該是客戶說了算吧？

簡單說，沒有做到客戶（或是PO）要求的事，就不算完成。

驗測是QA的事，還是RD的事？

有讀過我一些文章的朋友，也許已經猜到我會把風向帶到這裡來了。沒錯，我就是這麼好猜！試想，今天這個使用者需求，標題是：『身為停車場系統使用者，我希望客戶用100元紙鈔或是任何台幣的硬幣都可以繳費。』這時，假設PO把DoD定義成：

1. 100元紙鈔可以用來繳費，並正確找零。
2. 1元、5元、10元、50元硬幣可以用來繳費，並正確找零。

今天RD拿到這份工作，按照以前的習慣，就是直接動手開始敲程式碼，編譯，上傳，下班。然後說自己『做完了』，就像剛剛那個作者的兒子一樣。身為PO，你認為他的工作做完了嗎？完全還沒。為什麼？因為敲完的程式碼不是我要的產品，正確的功能才是。寫作業的人要保證作業內容是正確的，或是至少在他能力能檢查出來的範圍內已經找不出錯誤了，才叫做完成作業，因為這是老師（PO）要求的，工程師工作時也是啊！

保證產品功能正常是製造此功能的人的責任，你必須在能力所及範圍內再也驗測不出錯誤了，這才能回頭跟你的PO説：『我做完了。』

『在等測試』，算是完成任務嗎？

Well, an easy guess，當然不是。我們說過啦！做到再也檢查不出任何錯誤是RD的責任，如果今天老闆跑來問你進度，你回答：『我都做完了，現在在測試環境等QA測試。』你覺得老闆會滿意你的工作效率然後跑去問QA，還是對你的信用打折扣，認為你把份內工作推給別人了還敢講話這麼大聲。

這很難講，這樣看你老闆有沒有一顆敏捷的心。

也許這時候你會疑惑，『我把驗冊都測完了，QA測什麼？』嗯...這是一個又很難回答又很好回答的問題。這樣吧，你看看Scrum怎麼定義Scrum團隊：PO、SM、Member。沒有看到QA吧？對了。真要講下去也許要講很久，也超出本篇範圍，我們再找時間專門聊這個話題吧。你可以先去拜讀邰曉梅老師的大作：『海盜派測試分析』。

Done is better than perfect。你仔細回想，其實會發現，scrum流程裡面的很多活動與原則，都圍繞在這一句話上，這就是我們為什麼要把流程切成一個一個sprint，為什麼時間到就要Demo與回顧，為什麼每天都要站立會議...。其實都是為了先把時間切割，然後在固定的時間內，『完成』預計要做的事。

Definition of Done，多麼重要，不是嗎？