สรุปคอร์ส Agile 101

ในงานพัฒนาซอฟต์แวร์ requirement ของฟีเจอร์หรือแอปในบริการหนึ่งๆ เปลี่ยนบ่อยมาก ไม่ว่าจะมาจาก business unit, การเปลี่ยนแปลงทางเทคนิคที่คาดเดาไม่ได้ หรือ feedback จากลูกค้าที่อยากได้ประสบการณ์ที่ลื่นไหลและตอบโจทย์จริงๆ ซึ่งสำคัญไม่แพ้เป้าหมายทางธุรกิจโดยรวม การตัดสินใจว่าจะทำอะไรก่อนหลัง คือก้าวแรกของการวางแผนพัฒนาซอฟต์แวร์ให้มีประสิทธิภาพ

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

คอร์ส Agile 101 เผยแพร่บนเว็บไซต์โครงการ pmd47 Digital Citizen สอนโดย Agilist องค์กรที่เทรน Agile ให้บริษัทและหน่วยงานชั้นนำทั่วประเทศ

จำบ้าน Scrum ด้วยตัวเลข 3 ตัว

3 : 5 : 3

3 ตัวแรก > 3 บทบาท: Product Owner, Scrum Master, Developers

หน้าที่ของ Product Owner

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

หน้าที่ของ Scrum Master

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

หน้าที่ของ Developers

• พัฒนาและปรับปรุงซอฟต์แวร์ตาม definition of done ที่ PO กำหนด
• เขียนแผนการพัฒนา

5 ตัวกลาง > Scrum events

แต่ละ sprint ประกอบด้วย 5 event ดังนี้

3 ตัวสุดท้าย > Scrum artifacts

ให้นึกภาพเป็นโน้ตที่ลิสต์รายการงานในแต่ละ sprint

• Product backlog
  • ถังของงานที่ยังไม่ได้ทำ แต่วางแผนจะทำในอนาคต
  • รายการเหล่านี้เรียกว่า product backlog item
• Sprint backlog
  • รายการที่หยิบและจัดลำดับจาก product backlog มาทำใน sprint ที่จะถึง
  • กรอบเวลาของแต่ละรายการถูกวางในช่วง sprint planning
• Product increment
  • ผลลัพธ์ของแต่ละ sprint อาจเสร็จ 100% หรือเสร็จแค่บางส่วน
  • นำไป review กับ stakeholder เพื่อเก็บ feedback สำหรับ sprint ถัดไป จึงเรียกว่า “increment”

ในชีวิตจริง ทีมอาจไม่ได้ทำตาม Scrum guide เป๊ะทุกข้อ แต่ก็ได้ไอเดียดีๆ ไปปรับใช้ในบริบทขององค์กรตัวเอง สุดท้ายการปรับตัวสำคัญกว่าทฤษฎี หัวใจจริงๆ ของ Scrum คือทุกคนในทีมเป็นเจ้าของความสำเร็จของ product ร่วมกัน ไม่มีลำดับชั้นในทีม มีแต่การสื่อสารที่ขับเคลื่อนให้งานเสร็จ