สรุปคอร์ส Agile 101

ในงาน software development บ่อยครั้งที่ requirement ในการทำฟีเจอร์หรือพัฒนาแอพใน service ต่างๆ มักมีการเปลี่ยนแปลง ไม่ว่าจะมาจากทาง business unit ก็ดีหรือ techncial change ที่คาดเดาไม่ได้ก็ดี รวมไปถึง customer feedback ที่ต้องการให้การใช้งานราบรื่น ตอบโจทย์ลูกค้าก็มีความสำคัญไม่แพ้ business goal การเรียงลำดับความสำคัญว่าจะทำอันไหนก่อน หลัง เป็น step แรกในการวางแผนพัฒนาซอฟต์แวร์ให้มีประสิทธิภาพยิ่งๆ ขึ้นไป

หลักการนึงที่ทุกคนในสายงานพัฒนาซอฟต์แวร์นี้ต้องรู้จักก็คือ Agile methodology เป็นกระบวนการ ที่ทำงานให้คนในทีมเห็นภาพการทำงานเหมือนกัน มี goal เหมือนกัน เพื่อจะขับเคลื่อน output ออกมาให้ stakeholder ที่เกี่ยวข้องพีงพอใจ

Scrum’s house จำง่ายๆ ด้วย 3 ตัวเลข

3 : 5 : 3

3 ตัวแรก > 3 Role คือ Product owner, Scrum master, Developers

Product owner มีหน้าที่

• เก็บ requirement ความต้องการของ business unit (in house) หรือ ความต้องการของลูกค้า ดูว่าควรทำอะไร
• และจะทำอะไรก่อนหลัง (prioritize) ให้ align กับ product vision
• ตั้ง acceptance criteria ว่าหลังจากเริ่มแพลนแล้ว output ที่คาดหวัง หน้าตาเป็นไง ถือเป็น definition of done สำหรับทีม
• คาดว่าจะเกิด business value ยังไง อาจเป็นแง่ ROI, user acquisition
• ประสานงานกับทีมที่เกี่ยวข้องต่างๆ เช่น ระบบที่ต้องการไปเชื่อมด้วย เตรียมข้อมูลสำหรับ test และควรทำ UAT (User Acceptance Test) ด้วยตัวเอง เพื่อตรวจสอบก่อนถึงมือผู้ใช้งานจริง

Scrum master มีหน้าที่

• ช่วยให้ทีมปฏิบัติตามหลัก scrum framework ได้ถูกต้อง และมีประสิทธิภาพ
• ช่วยให้ทีม Dev และ PO สื่อสารกัน เข้าใจ requirement ตรงกัน
• ช่วยเพิ่ม collaboration ระหว่าง stakeholder หากจำเป็น

Developers มีหน้าที่

• พัฒนา รังสรรค์ซอฟต์แวร์ให้ดียิ่งขึ้น ตาม defenition of done ที่ PO อยากให้เกิด
• เขียนแผนงานการ dev

5 ตัวกลาง > Scrum events

โดยใน 1 sprint จะประกอบด้วย 5 event ดังนี้

3 ตัวหลัง > Scrum artifacts

เปรียบเสมือน note ในการ list item ที่ทำในแต่ละ sprint

• Product backlog
  • เป็น bucket ของสิ่งที่ยังไม่ได้ทำ แต่มีแผนจะทำในอนาคต
  • สิ่งพวกนี้เรียก product backlog items
• Sprint backlog
  • pickup & prioritize product backlog items จาก product backlog มาทำใน sprint ที่จะถึงนี้
  • ตีกรอบ timeline แต่ละ items ใน phase sprint planning
• Product increment
  • output ในแต่ละ sprint อาจทำงานได้ 100% หรือ ทำงานได้บางส่วนก็ได้
  • review กับ stakeholder เพื่อรับ feedback มาปรับปรุงใน sprint ถัดไป จึงเรียกว่า increment

ในชีวิตจริง อาจไม่ได้ทำตาม scrum guide นี้เป๊ะๆ แต่ทีมทำงานก็พอได้ไอเดียในแต่ละบริบทองค์กร สุดท้าย การปรับตัวก็สำคัญกว่า theory อยู่ดี ซึ่งจริงๆแล้ว หลักการของ scrum คือการให้ทุกคนใน scrum team มีส่วนร่วมกับ product success ไม่มีชั้น hierarchy ในทีม มีแต่การสื่อสารให้การพัฒนาชิ้นงานสำเร็จลุล่วงครับ