ScrumDay miniEvent EP1: รายละเอียดที่ขาดหายไปของ Definition of Done เมื่อนำมาใช้ใน Software Development #LearningWithSCK

ที่มาที่ไป เคยจัด Scrum Day มาเมื่อหลายปีแล้ว ตอนนั้นจัดในโรงหนัง อยากจัดอีก แต่ก็ไม่ได้จัดสักที ก็เลยเปิดเป็น Zoom มาเล่าก่อน เรื่องที่เล่าวันนี้ ยึดโยงจากเอกสาร Scrum Guide 2016 ซึ่งคิดว่าเป็นปีที่ดีที่สุดแล้วในการอธิบายเรื่องเหล่านี้

• เวลาเข้าไปในบริษัท พบว่า ทำงาน Scrum เป็น Sprint นี่แหละ แต่มีความเข้าใจเรื่อง DoD ผิดเยอะมาก
• ประสบการณ์ DoD แรก ได้จากการไปเรียน Certified Scrum Master ไม่ก็ Developer คนสอนเป็น Software Engineer ที่ได้มา และคล้ายคลึง จะหน้าตาแบบนี้

ก็เลยใช้มันมาเรื่อยๆ จะเห็นว่ามีความเป็น Engineer อยู่เยอะมาก

ปัญหาที่พบตอนนี้ของพี่หนุ่มคือ ไม่รู้ว่าหน้าตา DoD เป็นอย่างไร หรือต้องเอามาจากไหน

ต้องพาย้อนไปดูการทำงานแบบ Waterfall ก่อน

โครงการพัฒนาซอฟต์แวร์ ยังไงก็ต้องมี Phase ซึ่งก่อนจะเข้าสู่การทำงานโครงการได้ มันจะต้องมีสารตั้งต้นก่อน

• ภาครัฐ เรียกว่า TOR
• ภาคเอกชน เรียกว่า RFP (Request For Proposal)

มันจะมีสิ่งที่ต้องส่งมอบอยู่ในเอกสารเหล่านั้น (ลอง Search หาใน Google ได้)

//ช่วง Off-Record เปิดตัวอย่าง TOR ของกรมสรรพากรให้ดู

ซึ่ง Checklist พวกนี้ มักถูกนำมาใช้ตอนท้ายที่เป็น Phase: Acceptance Tests (on UAT, Staging, Pre-Prod) การตรวจรับมอบงาน

ถ้าไม่ผ่าน ก็จะข้ามเส้นไป Production ไม่ได้ หรือถ้ารับจ้างทำของ ถ้าส่งไม่ครบ ก็ไม่ได้รับเงินค่าจ้าง

(ย้ำอีกครั้ง) Scrum เป็นแค่เครื่องมือหนึ่ง และ Scrum เดี่ยวๆ ใช้ทำ Software ไม่ได้

พอย้ายมาใช้ Scrum Framework

สิ่งที่ต้องแจ้งก่อน Scrum ไม่มีลิสต์เอกสารพวกนั้นอยู่ มันจะมีอยู่สองคำ

1. Increment
2. Definition of Done (DoD)

หัวใจสำคัญของ Scrum คือ Sprint

• Sprint คือ Time-box ที่ใช้เวลาไม่เกิน 1 เดือน ซึ่งที่นิยมใช้กันก็คือ 10 วัน
• During Sprint ก็อยู่ประมาณวันที่ 2–9

• ผลิตภัณฑ์ == Software Version ล่าสุด
• Potentially Releasable == พร้อมเปิดให้บริการ หรือ ทดลองใช้งานจริง
• เพราะฉะนั้นก็ต้องอยู่บน Production หรือ Pre-Production หรือ Staging

ที่มาของ Scrum มาจาก Iterative and Incremental Development

พี่หนุ่ม เรียนกับคุณ Bas Vodde

• Iteration == Sprint แปลว่า เราต้องได้ของที่ ทดสอบเสร็จเรียบร้อย แล้วให้ User ประเมินว่า ใช่/ไม่ใช่
• Testing = Functional Tests (Pass 100%) และ Non-Functional Tests (Pass 100%)

• Evaluation คือ Environment ที่ใช้ในการประเมินผลว่า จะจ่ายเงินหรือไม่จ่ายเงิน ซึ่งที่ทุกคนที่มาฟังตอบส่วนมากคือ Production (ฉันด้วย 555) แต่ถ้ามาดูการทำงานเป็นรอบๆ ก็ต้องคุยกันก่อนว่า จะตรวจกันที่ไหน (อาจจะถอยลงมา 1 Env เช่น Pre-Production หรือ Staging)

• เสร็จ ระหว่าง Sprint ไม่ใช่ ท้าย Sprint
• จบ Sprint คือการแพ็คของเรียบร้อย
• และผ่านตามข้อกำหนดว่า “เสร็จ” คืออะไร ซึ่ง Scrum Team เป็นคนกำหนดคำนิยามไว้
• สุดท้ายแล้วคนใหญ่สุดในการตัดสินใจปล่อยของ คือ Product Owner

สมมติว่าต้องเปลี่ยนการทำงานมาเป็น Sprint เหล่า TOR หรือ RFP ก็คือ Potentially Releasable Increment (ในบริบทพี่หนุ่ม)

จากประสบการณ์ของพี่หนุ่ม กล่าวว่า “DoD เป็น subset ของ Incremental”

การจะบอกว่างานเสร็จ ต้องมี Bullet (ตัวอย่าง) พวกนี้ครบ จบในทุก Sprint

เวลานำของเข้ามาใน Sprint จะต้องมี Sprint Goal เสมอ

• ซึ่งก็จะมี Product Backlog Item(s) ที่ถูกเรียงลำดับ แนบติดมาด้วย (ต้องทำอะไรบ้าง เพื่อไปสู่เป้าหมาย)
• พอเดินทางเข้ามาใน Sprint แล้ว ระหว่าง Sprint ก็คือวันที่ 2–9 จะผ่าน กระบวนการพัฒนา ตรวจสอบ ทดสอบ ส่งมอบ ให้มีของถูกสร้างออกมา
• ถ้าเป็น Software ก็ต้องเอาเหล่า checklist มาเป็นบรรทัดฐาน เพราะมันคือ Increment

การทำงานอาจจะแบ่งได้สองแบบ เช่น

1. ไปด้วยกันทั้งก้อน ผ่าน checklist ก่อนได้เป็นก้อนสีเหลือง
2. ไปทีละชิ้น ผ่าน checklist แล้วก็ไปทับถมกันในก้อนสีเหลือง

ซึ่งการใช้งานจริงๆ ต้องใช้แบบที่ 2. นะจ๊ะ

ยกตัวอย่างการนำไปใช้งานจริง

• ใช้รายการเหล่านี้ในการตรวจรับและส่งมอบงานกับลูกค้า (กรณีเราเป็นคนรับจ้าง)
• ถ้าใน Scrum ก็คือ การตกลงระหว่าง PO และ Development Team
• ซึ่งรายการพวกนี้ จะเกิดการตกลงกันตั้งแต่ช่วงต้นโครงการ

• เช็คกับ Development Team ว่าสามารถทำได้ทั้งหมดในทุก Sprint ไหม ถ้าทำได้ก็จบ
• แต่ถ้าทำไม่ได้ ก็ต้องมีตารางมา Track ว่าแต่ละ Sprint ทำได้กี่ข้อ ซึ่งตรงนี้เรียกว่า Definition of Done และแยกอีกช่อง คือ Undone ซึ่งคำนี้ไม่มีใน Scrum
• แต่ก็ต้องคุยว่า เหตุที่ทำไม่ได้เพราะอะไร
• ซึ่งจะยอมให้ค้าง Undone ค้างไม่เกิน 3 Sprints เอาจริงๆ มีค้างคามา ก็ต้องกลับมาเก็บงานอยู่ดี
• อะไรที่ทำไม่เสร็จ เขียนเป็น PBI ออกมาเลย เช่น Flow การจ่ายเงินด้วย QR Code ต้องผ่าน Security Scan และผ่านการตรวจสอบ

Scrum เน้นเรื่องความชัดเจน โปร่งใสเป็นสำคัญ ต้องคุยกันตั้งแต่ต้น

• กรณีที่ทำได้ แต่ทำไม่ทัน แนะนำให้โยกมาเป็น Undone สร้างเป็นใบงานและจัด Prioirty อีกที
• กรณีที่ทักษะของทีมไม่สามารถทำได้ เพราะไม่มีประสบการณ์ แปลว่ามี Gap
• คนที่มีหน้าที่ปิด Gap ตรงนี้ แบบในนิยามของ Scrum ที่พี่หนุ่มถูกสอนมา เป็นความรับผิดชอบของ Scrum Master
• ถ้า Scrum Master เคยทำมาจนคล่อง ก็ขึ้นมาสอน พาทำ ทำให้ดูเป็นตัวอย่าง จนทีมสามารถทำได้
• ถ้า Scrum Master ไม่เคยทำ ก็ต้องดูว่า จะเชิญผู้เชี่ยวชาญคนไหน เข้ามาช่วย แล้วก็เชิญท่านๆ เหล่านั้นมาฝึกทีม
• ถ้าเจอทีมที่มีความรับผิดชอบ มีวุฒิภาวะ พวกเขาจะขวนขวายเอง เดินไปบอกหัวหน้างาน เดินไปบอก HR เองเลย (ซึ่งส่วนใหญ่ ไม่ค่อยเกิดขึ้นเท่าไหร่หรอก)

จริงๆ แล้ว Scrum ไม่ได้ผิดอะไร ไม่ได้แย่อะไร เค้าแค่ถูกเฟรมมาให้ใช้กับอะไรก็ได้ เพราะฉะนั้นถ้าอยู่ในวงการ Software ก็เลยต้องมาลงรายละเอียดเรื่องพวกนี้ก่อน

พี่หนุ่มวาดไว้เมื่อประมาณปี 2015 (มั้ง)

สำหรับ ScrumDay miniEvent พบกันใหม่ในอีก 2 สัปดาห์ (จริงเหรอ ถามจริ๊งงง 55)