ทำไมเราต้องมี DOR และ DOD
Credit Picture : http://www.ontheagilepath.net/2015/04/the-waste-of-the-definition-of-done-and-definition-of-ready-when-not-actively-used-in-your-daily-work.html
ถ้าเราไม่มี DOR (Definition of Ready) จะเกิดอะไรขึ้น?
1. ความเสี่ยงสูงที่ Product Backlog จะไม่เสร็จใน Sprint เพราะ Product Backlog ไม่มีความพร้อมเนื่องจาก Requirement ไม่ชัดเจน
2. Scope of work (SOW) ของ Product Backlog กว้างเกินกว่าที่จะทำให้สำเร็จใน Sprint3. Scrum Team คิดว่า Product Backlog เสร็จแต่ที่จริงแล้วยังเหลืองานบางส่วนที่หลงลืมและอาจจะส่งผลกระทบ เมื่อต้องการส่งมอบ Product ให้กับลูกค้าตามเวลาที่กำหนด
DOR — Definition of Ready
คือคำนิยาม ความพร้อมของ Product Backlog Item ที่จะสามารถดึงเข้าใน Sprint โดยที่ทาง Scrum Team จะช่วยกันกำหนด Check list คำว่าพร้อมของ Product Backlog และตามหลักการแล้ว DOR จะต้องมีความชัดเจนประมาณ 80% ขึ้นไป ถึงจะลดความเสี่ยงของการดึง Backlog เข้าไปทำใน Sprint
ยกตัวอย่างเช่น
DOR — Team A
- หน้าจอ Design (UX/UI) ผ่านการ Approve เรียบร้อยแล้ว
- System Architecture ผ่านการ Approve และสร้างไว้แล้ว
- Requirement Document มีและคลอบคลุม Product Backlog นั้นๆ
ถ้า Product Backlog ผ่าน Criteria ด้านบน แสดงว่า Product Backlog นั้นพร้อมที่จะดึงเข้าใน Sprint และมีโอกาสสูงที่จะ Develop สำเร็จได้ภายใน Sprint
Credit Picture : http://lcarvalho.pt/2019/01/definition-of-done-vs-definition-of-ready/
ถ้าเราไม่มี DOD (Definition of Done) ปัญหาที่เกิดตามมาคืออะไร?
1. Product Backlog ที่ทำใน Sprint ทิ้ง Undone work ส่งผลกระทบถึงคุณภาพโดยตรงต่อ Product และทำให้เกิดควมเสี่ยงโดยตรงต่อการส่งมอบ
2. ส่งผลถึงความร่วมมือกันในทำงาน เนื่องจากไม่ได้มองคุณภาพของ Backlog เป็นภาพเดียวกัน ทำให้เกิดเหตุการณ์ที่เรียกว่าหลาย Done เช่น Done Done / Done Done Done ทีมไม่มีเป้าหมายคุณภาพเดียวกัน
3. โดยความเป็นจริงแล้ว Product Backlog ต้องการทำให้เป็น User Story แต่กลับกลายเป็น Task แทน ทำให้เกิด Dependencies ระหว่าง Product Backlog Items
DOD — Definition of Done
คือคำนิยาม ที่จะบ่งบอกว่า Done ของตัว Product Backlog และของทีม ต้องประกอบ Criteria อะไรบ้าง ถึงจะเรียกว่า Done
ยกตัวอย่างเช่น
DOD ของ Team A
- Front end finished
- Back end finished
- Unit test finished
- Test cases created
- Execute test finished
- Automate test created
Product Backlog Item ถ้าจะ Done ได้ ต้องได้รับการติ๊กถูกจาก Criteria ด้านบนทั้งหมด จะเห็นว่า DOD จะส่งผลถึงคุณภาพของ Product โดยตรง และเป็นหัวใจในการสร้างทีมทางอ้อมเพื่อให้มีเป้าหมายด้านคุณภาพเดียวกัน ทำให้ทีมเกิดความเป็นน้ำหนึ่งใจเดียวกันในการช่วยกันทำงานใน Sprint
Credit Picture : https://www.quora.com/What-is-the-difference-between-the-Definition-of-Done-DoD-and-the-Definition-of-Ready-DoR-in-Agile-processes
สมการ Potentially Shippable Product
Potentially Shippable Product = Definition of Done + Undone Work
Credit : https://innovagility.com/2018/07/17/understanding-undone-work-part-2/
ถ้า Definition of Done ของทีมไม่แข็งแรงพอ จะมี Undone work เกิดขึ้นเสมอ และเมื่อยิ่งเวลาผ่านไปนานขึ้นงาน Undone work ยิ่งพอกพูนมากเรื่อยๆ Undone work คือ ความเสี่ยงที่อาจจะทำให้เราส่งมอบ Product ไม่ได้ตรงตามกำหนด (Unknown risk) ลองคิดสภาพว่าถึงเวลาที่ต้องการส่งมอบแล้วจะมีเหตุการณ์ที่ว่า โอ้ว……ลืม……, อ๋อ……..ขาดอันนั้น, ทำไมปัญหามันเยอะจัง
ดังนั้นถ้าเรา Build Scrum Team ขึ้นมาใหม่ ห้ามลืมการกำหนด DOR และ DOD นะครับ
