星期五晚上,太太對先生說: 「明天早上做早餐給我吃,要有水果、沙拉和優格。」
隔天早上,先生早起準備了有水果和沙拉的早餐,完成後就自己在客廳邊看電視邊開吃了。
太太不知道早餐做好了,在房間裡用手機看連續劇,看到肚子太餓受不了走出房間看到準備好的早餐沒有優格,生氣的對先生說: 「你做好早餐怎麼沒有跟我說,害我在房間裡面一直等。 而且我跟你說要有優格,你怎麼沒有?」
先生:「我忘記了」
午餐換太太做。先生說:「午餐我想吃肉和白飯」
太太做好了有肉和白飯的午餐,就叫先生來吃飯。
先生吃了一口肉覺得太鹹了,生氣的說:「這也太鹹了吧,難道你沒有試吃嗎?」
太太:「因為我自己不想吃,所以我也懶得試吃,直接叫你來吃」
晚上兩人開了自省會議,訂好準備餐點的規則,通用於每一餐:
1. 每餐的準備都要確實做完雙方的個別餐點要求。
2. 要先試吃,要把餐點的味道調整成夫妻都可以接受的口味。
3. 準備好餐點,要通知對方,才算完成這一餐的準備。
達到這3個條件,才算 "完成一餐的準備"
夫妻對每餐個別的要求相當於對每項工作的驗收標準 (Acceptance Criteria)
- 早餐要有水果、沙拉和優格
- 午餐要有肉和白飯
通用於每餐的3條規則,就是夫妻兩人對準備餐點"完成的定義"(Definition of Done)
-------------------------------------------------------------------------------------
將Scrum 運用在軟體開發(註1)的創始人之一 Jeff Sutherland曾經說過,
軟體開發團隊無法按時交付可用的軟體大致上可分類為6個原因:
1. "完成的定義" 不佳 (Poor definition of done)
2. 工作前置作業沒準備好 (Stories not READY)
3. 功能失調的領導力 (Dysfunctional leadership)
4. 技術債 (Technical debt)
5. 組織債 (Organizational debt)
6. 教練效率低 (Ineffective coaching)
所以"完成的定義"對軟體開發團隊是很重要的。
當一個產品待辦事項或者產品增量被描述為「完成」時,每個人都必須瞭解什麼是「完成」的 定義。 - Scrum 指南
也就是說,大家對完成一件事的定義有共識,而且實際達成了定義的要求才算完成工作。就像是夫妻對"準備餐點" 的"完成的定義"。
好的 "完成的定義" 至少需要涵蓋2個條件:
1. 完成的產品要符合驗收標準
(每餐的準備都要確實做完雙方的個別餐點要求)
2. 團隊對於品質的協議
(要先試吃,要把餐點的味道調整成夫妻都可以接受的口味)
也可以從3個程式開發工作層面來看:
1. 工作層 (task level),例如
- 程式碼有做單元測試, 而且被2人以上審視過。
- check-in 的程式碼不會讓build失敗。
2. 物件層 (Item/ Story level),例如:
- 每個物件都通過測試。
- 通過產品負責人的審視,並且被產品負責人接受。
3. 發布層 (release level),例如:
- 所有完成的物件都被發布到正式環境(production server)
- 通知技術支援團隊,並且提供相關訊息與訓練。
每個工作環境 "完成的定義"都是獨特的,沒辦法複製其他公司或網路上的範例達到效果。需要靠開發團隊和產品負責人共同討論。
註1
Takeuchi 和 Nonaka 於 1986年在哈佛商業評論借用了橄欖球中的Scrum(爭球) 說明一個關於領導和經營公司的理論,之後才被Jeff Sutherland和Ken Schwaber運用在軟體開發。