Daniel 上回被老闆釘在牆上之後，回家痛定思痛，他專研了許久，發現果真拆分工作的粒度跟維度，的確是會關鍵性地影響產品的價值。
隔幾個月後，Daniel 又完成了一個重大的案子，當然也興高采烈的找老闆跟業務團隊來 Demo，大家看了也很高興，因為 Daniel 這一次不只把 MVP 劃分得很好，連下個月跟下下個月可能需要改善什麼、可能需要追加什麼功能，以及上線後要觀察哪些指標，在發生什麼事情時要做什麼調整…等，都有了初步的規劃，這讓老闆跟業務主管很是高興。
Demo 結束之後老闆問 Daniel 說看起來你們 MVP 的東西全部都做完了，那麼你什麼時候要上線？Daniel 說這個很快，我們下週整包交給 QA測一測再回來，我們再做一兩個禮拜的壓力測試與正式環境設定調整，再做個最後通盤測試，應該不出一個月就可以直接上線了。
筆者有一陣子對於煮飯非常有興趣，於是在工作之餘，試圖花了一點時間去研究考國內的丙級廚師執照的考試規則。最後雖然沒有真的去考，但在跟在研究規則的當下，我認真的發現，假設各位在台灣要拿一個丙級的廚師執照，燒菜燒得好吃固然很好，但那根本就不是重點（應該說不是最關鍵的事），重點是你的衛生習慣一定要好，生熟食廚具有沒有分開，雞蛋有沒有一顆一顆打開檢查再往始打蛋，最後，燒的菜一定要熟，流程一定要順，除此之外，你只要確認燒出來的那盤個東西就是那道菜就可以了。
為什麼？因為你如果菜都燒不熟，或者是客人吃了會拉肚子，那你燒的菜再好吃、賣相再漂亮也沒有用啊！
有研究過敏捷開發的人都會經常聽到兩個名詞，分別是驗收條件（AC）與完成定義驗（DoD）。AC 與 DoD 有什麼不同？簡單來說：
AC 是針對「需求」所訂定的驗收標準，DoD 是針對工程所定義的完成標準，也就是，當你一年中依序做了很多個工作項目時，這些項目的 AC 會有所不同，因為需求不同，而 DoD 理當是保持一致，或越來越進步才行。
以燒菜為例，假設你今天要做一個三杯雞，那麼一盤雞肉要有多重、雞肉跟配菜的比例要多少、醬油要多少、麻油要多少、香油米酒各要多少，這些都是都可以是三杯雞的驗收條件，因為它們會影響這道菜好不好吃，甚至是決定做出來的東西是不是三杯雞。至此，各位讀者應該可以想像三杯雞的驗收條件與九層塔炒蛋、蛤蠣絲瓜的驗收條件肯定不一樣，對吧？
那麼 DoD 呢？ DoD 要求的是工程, 也就是從頭到尾的過程當中，你做了哪些事情以及怎麼做的。完整落實的 DoD 要求的是施工品質，也就是燒菜的過程當中，任何有機會降低品質的事情你都不能做。例如廚師的手有沒有洗，鍋子有沒有採用政府認證的合格鍋具，做菜當中師傅的頭髮有沒有包覆，有沒有戴口罩，排油煙機有沒有符合標準，多久洗一次，最後，送到顧客桌上的過程當中服務生有沒有用手碰到盤裡的菜… 等。
除此之外，任何會降低未來施工品質或提高未來流程改善的難度的事情，你也都不能做。例如你不可以因為顧客吃不出來就把掉在地上的雞排撿回油鍋再炸，當你發現出餐太慢的時候，你應該考應通盤檢討廚房的動線、外場的送餐流程，與內外場之間溝通的管道是否暢通，而不是一味地加人或高壓式的訂定 KPI，一旦不達標就把人炒魷魚… 等等。
這些事情就算都做得不好你還是可能驗收（因為三杯雞還是三杯雞嘛），但是對一個對服務跟衛生條件都要求的餐廳來說，DoD 跟 AC 一樣都是必須得要求的事情。
回到軟體開發，我今天要做一個銀行的存款功能，最基本的存款之後帳戶的錢要依規定增加，這個是 AC 的其中一部分。AC 可不可以增加可以存美元入日幣帳戶？每個月跨行存款上限五萬元？未認證用戶不得存款款…等等？當然可以，這些都是功能面的驗收標準，只要你做得到這件事情，那麼對用戶來說存款的用戶體驗就沒有問題。
那 DoD 呢？譬如當你開發完畢之後你要隔多久才能上線給用戶使用？每當你跟老闆說你開發完了的時候這一個功能的進度離能上線給用戶使用還有多遠？是馬上能使用呢？還是還要壓力測試呢？還是還沒通過安全性測試呢？還是還沒經過人工的應用性測試或功能測試呢？還是你自己只測過一次了？還是你其實測都沒測，只是把程式碼打完而已？上面這些問題如果回答 yes 的比例越高，那代表你的工程程度越高；反之你就要回頭看一下你的軟體工程實力是否有增進的必要性。
在開發軟體的時候，開發者跟需求方對 AC 先行取得共識自然是很好也很重要的事情，但同一方面如果沒有高程度的軟體施工品質也就是你的 DoD 太初階的話，其實你很難提供真正很好的軟體服務。
敏捷開發講究的是快速迭代、快速回饋、快速調整，因為這樣才能持續改善。如果你花一週所開發的產品在你開發完之後還需要三週才可能上線，那麼等你收到上線後的數據，進行分析後再提出改善需求，等到需求再回到你手上的時候， 已經又好幾週過去了。
這時，請問你要怎麼快速迭代快速回饋以及快速調整？沒有辦法。
這就是為什麼 DoD 的提升對於軟體開發從業人員來說是非常重要的事情，因為 DoD 的成熟度從根本上就決定了你的應變能力，這是學任何軟體技術、市場調查、與人員管理等，都幫不上忙的事情。
試想，今天 Daniel 在 Demo 的時候只能在自己的電腦上 Demo，另外一個團隊 Michael 也做一模一樣的事情，花一模一樣的時間開發，在同一個場合 Demo，但是他明天就可以上線，或他甚至根本已經在正式環境中 Demo 了，如果你是老闆，你對誰的評價會更高一點？再說現實一點，如果你是老闆，你覺得誰對公司的收益有更高的幫助？這答案不言而喻，對吧？
這也就是為什麼只要是談敏捷開發，就一定會談順便談的事情叫做單元測試、自動化驗收測試、自動化部署，與數據監控，因為這些都是除了驗收標準以外，可以從基礎上直接影響你預判狀況的能力，以及遇到狀況時採取行動的應變力的重要因素。沒有這些，你光驗測都要兩個禮拜了你要怎麼敏捷開發？你就只能「開發」了。
我們都直接部署上產線才DM的你們呢？
謎之聲：「 AC 訂得好，做了對的事；DoD 能落實，用對的方式做事。」
iThome鐵人賽
看影片追技術