เริ่มต้นที่ต้องบอกก่อนว่า เรื่องที่จะคุยวันนี้ยึดโยงจากเอกสาร The Scrum Guild ปี 2016 ซึ่งน่าจะเป็นเอกสารที่ดีที่สุดสำหรับเอามาเป็น reference ได้

ปัญหา คือ เขาไม่รู้ว่า Definition of Done (DoD) ที่ดีควรเป็นอย่างไรหรือเอามาจากไหน

ถ้าหากเราถามว่า DoD หน้าตาควรเป็นอย่างไร ให้เราลองนึกถึง TOR ของภาครัฐ หรือ เอกชน ที่มีการระบุเงื่อนไขในการส่งมอบ และตรวจรับ ประมาณนี้

เงื่อนไขในการส่งมอบ และตรวจรับ

ซึ่งมันจะเกิดการพูดคุยและตกลงกันตั้งแต่ก่อนเริ่มการพัฒนา และจะถูกใช้ เมื่อจะติดตั้งขึ้น Production หรือ ตรวจรับงาน หากเราใช้การพัฒนาแบบ Waterfall มันจะเกิดขึ้นช่วง phase ท้ายๆ เพื่อเตรียมการ deploy หรือ ส่งมอบ

ปกติเราอาจจะตรวจรับกันที่ Pre-Production Environment หรือ UAT Environment ขึ้นอยู่กับแต่ละบริษัท โดยจะใช้เงื่อนไขในการส่งมอบและตรวจรับ จะถูกใช้ในการรับมอบงานที่ทำกัน

ในกรณีที่เป็น Scrum การทำงานจะถูกปรับเป็นรอบๆ ทำให้จะต้องมีการปรับเปลี่ยนเพื่อให้เหมาะสม ซึ่งใน scrum จะมี 2 คำที่มีการพูดถึง Incremental และ Definition of Done

ถ้าหากเรามาดูใน Scrum guide จะมีการพูดถึง

a time-box of one month or less during which a “Done” (Definition of Done) ,useable, and Potentially Releasable Product Increment is created.
  • Time-Box: มีการกำหนดรอบของการทำงาน เช่น 1 sprint = 10 วัน
  • During: ช่วงระหว่างการพัฒนา 2-9 วัน
  • which a “Done” (Definition of Done) ,useable, and Potentially Releasable Product Increment is created: มีผลิตภัณฑ์ (Software Version ล่าสุด) ที่พร้อมขาย เปิดบริการให้ หรือทดลองใช้งานจริง
Potentially Releasable Product Increment = สิ่งที่ต้องส่งมอง

ซึ่งมันจะเป็นตัวที่บอกถึงความคาดหวังว่า ในการทำงาน 1 sprint นั้นควรจะเป็นอย่างไร

ถ้าหากเราอิงตามข้อความนี้ นั้นแปลว่า ของพวกนี้จะต้องถูกติดตั้ง หรือ พร้อมติดตั้งบน Production หรือตัวที่ใกล้เคียง Production

ดังนั้นหากเราต้องปรับเปลี่ยนจาก waterfall มาเป็น sprint เงื่อนไขในการส่งมอบและตรวจรับก็จะถูกเอามาใช้ในแต่ละ sprint เพื่อเป็นตัวที่ใช้สำหรับบอกว่า ของในรอบนั้นพร้อมที่จะเอาขึ้น production หรือไม่ ดังนั้นใน 1 sprint ทีมพัฒนาจะต้องทำให้ได้ตามเงื่อนไขในการส่งมอบและตรวจรับ

โดย flow การทำงานจะไหนจากซ้ายไปขวาแบบนี้

ซึ่งภาพการทำงานก็จะเป็น การเอา Product Backlog Item แต่ละตัวเข้าไปพัฒนา เมื่อเสร็จแล้ว ก็เอามาเช็คกับเงื่อนไขในการส่งมอบและตรวจรับ ทีละ PBI เพื่อตรวจสอบว่าผ่านข้อตกลงหรือไม่ ถ้าผ่านก็เตรียม deploy ขึ้น production

การใช้งานจริง

เมื่อใช้งานจริง DoD ตามประสบการณ์ที่ sck ทำกันมาหน้าตาจะเป็นแบบนี้

โดย DoD จะต้องถูกแจกแจงออกมาเป็นข้อๆ โดย lists นี้เป็นข้อตกลงของ product owner กับ development team เป็นคนตกลงกัน ตั้งแต่ก่อนเริ่ม Sprint 1

โดยรายละเอียดที่ใส่จะต้องพูดคุยกับคนที่เกี่ยวข้องกับการนำของขึ้น production เช่น ทีม Infrastructure, DevOps, Security, Support เป็นต้น

ซึ่งต้องเอาไปถามว่า development team ว่าสามารถทำตามข้อตกลงเหล่านี้ได้ทุก sprint ไหม?

  • ถ้าหากทีมสามารถทำได้ครบทุกข้อ เราจะเรียกว่า Definition of Done
  • ถ้าหากทีมไม่สามารถส่งมอบตามข้อตกลงนั้น เราจะเรียกว่า Undone

โดย Undone ที่พูดถึงนี้ ไม่มีใน Scrum แต่ลองให้เอาไปใช้ดู เผื่อสามารถช่วยเหลือให้ทีมสามารถส่งงานตาม DoD ได้

ซึ่งมันอาจจะเกิดขึ้นได้หลายกรณี เช่น load test ไม่สามารถทำได้ในทุก sprint เป็นต้น

การทำแบบนี้เป็นเหมือนการทำ Risk Managements เพื่อให้สามารถรู้ได้ว่ามีอะไรที่เกิดโอกาศเป็นความเสี่ยงในการเอาของขึ้น production บ้าง

จากประสบการณ์ของพี่หนุ่มจะต้องพยายามไม่ให้งานที่เป็น undone ค้างเกินกี่ sprint เพื่อให้สามารถทำได้ตามข้อตกลงทัั้งหมด

โดยหากมีงานชิ้นไหนที่เป็น undone ใน sprint ที่ผ่านๆ มา ก็จะต้องกลับมาเก็บงานนั้นให้เรียบร้อยเสมอ (ซึ่งต้องทำเมื่อพร้อม หรือ สามารถทำได้แล้ว)

การกำหนดข้อตกลง DoD จะต้องทำให้ชัดเจนตั้งแต่ต้น เพื่อสร้าง Transparency ให้แก้ทีมและทุกคนที่เกี่ยวข้อง

คนที่ต้องเป็นคนรับผิดชอบในการปิด gap ให้ทีมสามารถส่งมอบงานตาม DoD คือ Scrum Master ซึ่งจะต้องสอน ให้คำปรึกษา และพาทำ แต่ถ้าหาก scrum master ไม่มีประสบการณ์ในเรื่องนั้น ต้องดูว่าจะเชิญผู้เชี่ยวชาญคนไหนเพื่อเข้ามาช่วยเหลือในเรื่องนั้นๆ

จบด้วยภาพสรุป

Speaker: