關於準備就緒與完成的定義

本文是我在過去十年裡，在四十多個團隊身上親身經歷的。

準備就緒的定義（DoR，Definition of Ready）：一切從幻想開始

起初，大家都想讓自己感到非常安全。
團隊想要確保萬無一失。
一開始就需要控制和分析。
人們希望不計一切代價地降低不確定性。

但隨著時間的流逝，很明顯（可能永遠也不會？），
事前的分析往往與實際情況不符。
我們發現有更多要做的。
通過實際去開發解決方案。
嘗試、反饋、改善。
因此，準備就緒的定義範圍在逐漸縮小。

完成的定義（DoD，Definition of Done）：品質檢查清單的故事

起初，只有手動測試。
但測試人員可能會有偏見。
當有新事物出現時，
他們必須重新測試其他所有東西！

他們開始學習單元測試（Unit Tests），
了解所有自動化測試工具。
了解 DORA 指標可能非常有幫助。
了解像結對程式設計（Pair Programming）這樣的優秀實踐。
了解 DevOps 不僅僅是工具，而是思維。
增加完成的定義以提高品質並減少浪費。

有時，是自然而然便發生了。
有時，需要一點指引或刺激 :)

但最重要的是：

您想要實施的任何實踐或工具都必須是深思熟慮下的選擇，每個人都要理解那個工具的目的及使用它的影響。
不僅僅是為了在清單上的方形小格打個勾，然後說「我們是敏捷的」。

後記：

• 如果你的「準備就緒的定義」正在增加而不是減少，這可能是一個警示燈。重要的是要調查和理解為什麼團隊需要它增加。
• 保證是一個大紅燈的情況：如果你的產品待辦事項正在被細化並變成「準備就緒」，在沒有開發人員和測試人員參與的情況下。每個人都是拼圖的一部分。最好一起對齊並將工作精煉與細化，而不是在團隊中形成迷你穀倉（Mini-silos）與交接（Hand offs）。
• 建議去了解一下來自行為驅動開發（BDD，Behavior Driven Development）的三個朋友會議（3 Amigos Meeting）。如果對的人在對的時間討論對的事情，這可以大大提升團隊的理解程度並讓「準備就緒的定義」大幅度缩小（甚至消失）。
• DoR 可能代表「不要過度精煉」（Don't Over Refine）－馬克·戴維斯
• 在 Scrum 指南中沒有詳細說明「準備就緒的定義」。這個主題在產品待辦清單的章節有所提及：
  
  「Scrum 團隊能在一個衝刺（Sprint）內完成的產品待辦事項被認為是準備好在衝刺規劃會議（Sprint Planning）中所選擇的。
  這些待辦事項通常在精煉會議後達到這種程度的透明度。
  產品待辦清單的精鍊是將產品待辦事項拆解並進一步定義為更小更精確的項目的行為。這是一個持續進行的活動，用於添加細節，例如：描述、順序、大小。這些屬性往往隨工作領域的不同而有所不同。」