Definition of Ready & Definition of Done

เพราะคำว่า "พร้อม" และ "เสร็จ" ถ้าไม่ตกลงร่วมกัน จะตีความกันคนละโลก

ลองดูคำพูดที่เจอบ่อยในหลายทีม:

• "story นี้พร้อมแล้ว เอาเข้า sprint ได้"
• "งานนี้เสร็จแล้ว ส่ง QA ได้"
• "done แล้ว รอแค่ deploy"

ปัญหาคือแต่ละคนอาจหมายถึงคนละอย่าง

คำว่า ready

บางคนหมายถึง:

• มี title แล้ว
• มี acceptance criteria แล้ว
• dev พอเริ่มได้แล้ว

แต่ QA อาจมองว่า:

• criteria ยัง test ไม่ได้
• dependency ยังไม่ชัด
• ยังไม่มี mockup

คำว่า done

dev อาจหมายถึง:

• code เขียนเสร็จ
• merge แล้ว

แต่ทีมอาจยังต้องการอีก:

• QA ผ่าน
• regression ผ่าน
• deploy staging แล้ว
• PM review แล้ว

ดังนั้น DoR และ DoD มีไว้เพื่อลดพื้นที่ของการตีความไม่ตรงกัน

เกณฑ์ว่า story นี้พร้อมพอจะเริ่มทำหรือยัง

DoR ช่วยป้องกันการเอา story ที่ยังไม่ชัดเข้า sprint แล้วไปเสียเวลาคุยกันกลางทาง

ตัวอย่าง checklist ของ DoR

มองจากมุม QA

QA มีบทบาทมากใน DoR เพราะมักเป็นคนเห็นก่อนว่า criteria ยัง test ไม่ได้ เช่น:

• คำว่า "เร็ว", "เหมาะสม", "ปลอดภัย" ยังไม่ชัด
• failure path ไม่ถูกพูดถึง
• state เปลี่ยนแล้วควรเกิดอะไรยังไม่รู้

ถ้า QA ไม่ flag ตรงนี้ story อาจเข้า sprint ไปทั้งที่จริงยังไม่ ready

เกณฑ์ว่า story นี้เสร็จพอจะนับเป็นเสร็จจริงหรือยัง

DoD ช่วยป้องกันไม่ให้ทีมเรียกงานที่ยังค้างเรื่องสำคัญว่า "เสร็จแล้ว"

ตัวอย่าง checklist ของ DoD

ประเด็นสำคัญ

DoD ไม่ได้เหมือนกันทุกทีม

ทีม startup อาจใช้ DoD ที่เบากว่า แต่ระบบที่มี compliance หรือ financial risk สูง อาจต้องมี DoD เข้มขึ้น

เป้าหมายไม่ใช่ให้ทุกทีมมี checklist ยาวที่สุด แต่คือให้ทีมมีมาตรฐานที่เหมาะกับความเสี่ยงของงาน

จำแบบสั้น

• DoR = "พร้อมให้เริ่มหรือยัง"
• DoD = "พร้อมให้นับว่าเสร็จหรือยัง"

"มี DoR/DoD แล้วทีมจะช้าลง"

จริง ๆ ถ้าทำดี จะช่วยให้ทีมเร็วขึ้นในภาพรวม เพราะลด:

• การคุยซ้ำกลาง sprint
• bug ที่เกิดจาก requirement เบลอ
• งานที่นับว่า done แต่จริง ๆ ยังไม่พร้อม

"เขียนไว้ใน wiki ก็พอ"

ถ้าไม่มีใครเปิดดูในชีวิตจริง เท่ากับไม่มี

DoR/DoD ที่ใช้ได้จริงควร:

• อยู่ใน ticket template
• ถูกหยิบขึ้นมาดูเวลาถก
• review เป็นระยะ

"QA เป็นคนถือ DoD คนเดียว"

ไม่ใช่ QA คนเดียว

QA ช่วยผลักดันส่วนของ testing และ risk แต่ DoD ของทีมควรเป็นข้อตกลงร่วมกัน

ถ้ามองจากมุม testability และ release risk

สิ่งที่ QA มักช่วยใน DoR

• acceptance criteria ต้อง testable
• edge cases สำคัญต้องถูกพูดถึง
• dependency และ env needs ต้องชัด
• story ใหญ่เกินไปควรถูก split

สิ่งที่ QA มักช่วยใน DoD

• criteria ผ่านครบ
• regression ที่เกี่ยวข้องผ่าน
• ไม่มี defect severity สูงค้างโดยไม่มีการรับ risk
• smoke หรือ staging verification ผ่าน

QA ไม่จำเป็นต้องเขียน checklist คนเดียว แต่ควรเป็นคนช่วยให้ checklist นี้ป้องกัน quality gap ได้จริง

เคส 1: story ยังไม่ Ready

story เขียนว่า:

ปัญหา:

• ไม่รู้ว่ารวดเร็วแค่ไหน
• ไม่รู้ field อะไรบ้าง
• ไม่รู้ success/failure path

แบบนี้ยังไม่ควรเข้า sprint แม้ dev จะพอเริ่มทำ UI ได้

เคส 2: story ยังไม่ Done

dev บอกว่า:

• code merge แล้ว
• local test ผ่าน

แต่:

• ยังไม่ deploy staging
• QA ยังไม่เทสต์
• critical defect ยังไม่ปิด

แบบนี้ยังไม่ควรเรียกว่า done ตามมาตรฐานทีมที่ดี