วันนี้อ่านเจอบทความเรื่อง Using Definition of Ready
เลยเอามาสรุปหน่อยดีกว่า
เป็นเรื่องที่น่าสนใจ เกี่ยวกับ requirement ที่ทีมพัฒนาจะรับเข้ามา
โดยทีมพัฒนาจะตัดสินใจได้อย่างไร ว่า requirement นั้นมันพร้อมรับเข้ามาพัฒนาหรือไม่
ดังนั้นทีมพัฒนาและเจ้าของ requirement ควรตกลงกัน
ให้ชัดเจนว่า requirement ควรเป็นแบบใด
จึงจะถือว่าพร้อมสำหรับการพัฒนา หรือทำการกำหนด Definition of Ready (DoR) ขึ้นมานั่นเอง
เริ่มต้นด้วย Definition of Done
หลายๆ คนน่าจะเคยได้ยินกับคำว่า DoD หรือ Definition of Done มาก่อนแล้ว
เป็นข้อตกลงระหว่งทีมพัฒนากับเจ้าของ requirement ว่างานหรือ feature
ที่จะทำการพัฒนานั้น เสร็จและพร้อมส่ง ด้วยเงื่อนไขหรือข้อตกลงอะไรบ้าง
แต่สิ่งที่มันยังขาดหายไปก็คือ ข้อตกลงของ requirement
ที่จะรับเข้ามาพัฒนาว่า ควรจะมีลักษณะและข้อตกลงอะไรบ้าง
ซึ่งนั่นก็คือ Definition of Ready (DoR) ที่เราจะพูดถึงนั่นเอง
โดยเรื่องนี้จะเกี่ยวข้องกับคุณภาพของ requirement ที่พร้อมสำหรับนำไปพัฒนา
แน่นอนว่า มันคือ ข้อตกลงระหว่างเจ้าของ requirement กับ ทีมพัฒนานั่นเอง
รูปภาพแสดงขั้นตอนของ DoR และ DoD สำหรับ Product Backlog
โดยนำรูปมาจาก Improve Sprint Throughput with “Definition of Ready”
โดยที่ DoR นั้นจะช่วยทำให้เราเห็นความพร้อมของ requirement
ซึ่งมันสำคัญต่อทีมพัฒนาและเจ้าของ requirement อย่างมาก คือ
ทีมจะเข้าใจเกี่ยวกับ requirment มากขึ้น ช่วยทำให้การ estimate ดีขึ้น
ช่วยทำให้เจ้าของ requirement จัดการและเตรียมตัวได้ดีขึ้น
DoR นี้สามารถประยุกต์ไปใช้ส่วนอื่นๆ ได้
เช่น Product Backlog และ Sprint Review ของ Scrum เป็นต้น
ลองมาเริ่มสร้าง DoR ของ Product Backlog กันก่อน
สิ่งที่ทีมใหม่ๆ มักจะได้รับความเจ็บปวดมากๆ ก็คือ
การที่เจ้าของ requirement ไม่ได้เตรียมตัว เกี่ยวกับ requirement มามากนัก
เพื่อให้เพียงพอต่อการพัฒนา ทำให้เกิดการพูดคุย ถกเถียง ตั้งคำถามมากมาย
สุดท้ายก็รับเข้ามาทำการพัฒนา และเป็นต้นเหตุที่ก่อให้เกิดปัญหามากมาย
ซึ่งจะเป็นการขัดจังหวะการพัฒนาของทีมอย่างมาก ส่งผลให้ทีมพัฒนา
ไม่สามารถส่งของตามที่ได้ estimate ไว้ได้
ดังนั้นควรมีการกำหนด DoR ขึ้นมา เพื่อตอบโจทย์สิ่งเหล่านี้
- ใช้สำหรับวัดความพร้อมของ Product Backlog
- ทำให้แน่ใจว่ามันมีรายละเอียดที่เพียงพอ
- ช่วยเหลือทีมพัฒนาเพื่อระบุว่า สิ่งที่เจ้าของ requirement ต้องการนั้นมันมากจนเกินไปหรือไม่
- ช่วยทำให้ทีมพัฒนาสามารถอธิบาย หรือ บอกคนอื่นๆ ได้ว่าสิ่งที่ต้องการคืออะไร
- ลดความกดดันของทีมพัฒนาต่อสิ่งที่จะรับเข้าไปพัฒนา
- ลดการเปลี่ยนแปลงของ requirement ลงได้
แนะนำให้เริ่มกำหนด DoR น้อยๆ ก่อน เพื่อทำให้มั่นใจว่าทีมมีความเข้าใจตรงกัน
ว่าคำว่า พร้อม หรือ Ready ของ Product Backlog เป็นอย่างไร
ตัวอย่างของ DoR เช่น
- Product Backlog ต้องมีคุณสมบัติ INVEST
- Product Backlog ต้องอยู่ในรูปแบบของ User Story
- Product Backlog ต้องมี acceptance criteria ที่สามารถทดสอบได้
- Product Backlog ต้องมีการออกแบบ User Interface มาด้วย
- ใน Product Backlog นั้นๆ มีใครบ้างที่เกี่ยวข้อง เช่น ผู้ใช้งาน และ ระบบที่เกี่ยวข้อง
- และสุดท้าย Product Backlog ที่จะพร้อมจริงๆ ต้องถูก estimate เสมอ หรือมักเรียกว่า Ready-Ready
แนะนำให้เขียน Definition of Ready ใน flip chart ใหญ่ๆ
แล้วนำไปแปะในจุดที่ทุกๆ คนที่เกี่ยวข้องเห็นได้ชัดเจน
โดยเจ้าของ DoR นั้นคือ ทีมพัฒนา และ เจ้าของ requirement
ไม่ใช่ทีม management นะ
DoR สามารถที่จะปรับเปลี่ยนไปได้เรื่อยๆ ตามลักษณะของงาน
และใช้เพื่อปรับปรุงการทำงานในแต่ละรอบได้อีกด้วย
รวมทั้งมีประโยชน์ทั้งเจ้าของ requirement และ ทีมพัฒนา
ดังนั้น เรามาเริ่มสร้าง Definition of Ready ของ requirement กันเถอะนะ …
และหวังว่าไม่น่าจะมี requirment ที่มีเนื้อหาในรูปแบบดังต่อไปนี้นะ
- เหมือนเดิม
- เอาเหมือนระบบนั้น เหมือนระบบนี้
- ช่วยๆ กันทำไปเถอะ
- ทำงานแบบมีประสิทธิภาพ
แหล่งความรู้เพิ่มเติมเกี่ยวกับคำว่า Ready-Ready ใน Scrum
Reference Website
