ขั้นตอนการทำ Software Demo เมื่อจบ Sprint

หลังจากที่ตกลงทำซอฟต์แวร์กันเรียบร้อยแล้ว Project Manager จะเริ่มวางแผนการทำงานออกมาเป็น Sprint เพื่อกำหนดกรอบระยะเวลาและสิ่งที่จะส่งมอบได้อย่างชัดเจน ในแต่ละโปรเจกต์ เราจะแบ่งเป็น Sprint ละ 1-2 สัปดาห์ โดยเมื่อจบ 1 Sprint เราจะมีการนัดลูกค้าหรือผู้ใช้งานระบบเข้ามาประชุมเพื่อที่จะ Demo งานที่เราได้ทำให้เขาดูพร้อมกับรับ Feedback ตัวงานที่ทำลงไป

Demo คืออะไร

การ Demo เป็นเหมือนการรีวิวงานให้กับลูกค้าหรือผู้ใช้งานระบบได้เห็นภาพในกระบวนการทำซอฟต์แวร์ เราจะมีการนัดลูกค้าหรือผู้ใช้งานระบบเข้ามา Demo เพื่อที่จะได้ดูฟีเจอร์ที่ทางทีมพัฒนาได้ทำไว้ทุกครั้งที่จบ Sprint Cycle

ขั้นตอนการทำ Software Demo

1. นัดหมายวัน Demo กับลูกค้าหรือผู้ใช้งานระบบ เมื่อมีการแบ่งการทำงานออกเป็น Sprint แล้ว Project Manager จะรู้ว่าจะต้องมีการนัดลูกค้าหรือผู้ใช้งานระบบเข้ามาดู Demo วันไหนบ้าง หลังจากนั้นให้แจ้งกับลูกค้าว่าเราจะมีการนัด Demo ทุก ๆ กี่วัน และทำการลงปฏิทินไว้เพื่อนัดหมายเลย

2. Internal Demo เป็นการซ้อมภายในทีมก่อนที่จะไป Demo ให้ลูกค้าหรือผู้ใช้งานระบบจริงดู

   1. 1. Project Manager จะต้องทราบถึงรายละเอียดการ Demo ของรอบ Sprint นั้น ๆ ว่าจะมีฟีเจอร์ไหนที่เสร็จบ้าง หลังจากนั้นให้ List ตัวฟีเจอร์ที่จะต้อง Demo แล้ววางแผนการเล่น เพื่อที่ลูกค้าหรือผู้ใช้งานระบบจะเห็นภาพและเข้าใจได้ง่าย

      2. ทางทีมพัฒนาระบบ (Developer) จะต้องแจ้งกับ Project Manager หากมีส่วนไหนที่ยังไม่พร้อมที่จะ Demo เพื่อที่ Project Manager จะได้วางแผนสลับเอาฟีเจอร์ที่พร้อมใช้งานมากกว่าเข้ามา Demo แทนก่อนก็ได้ เพราะว่าการ Demo ยังไม่ได้ถือเป็นการ UAT (User Acceptance Testing) ที่ทุกฟีเจอร์ต้องสามารถพร้อมใช้งาน เราจึงสามารถที่จะยืดหยุ่นปรับเปลี่ยนแผนการ Demo ได้

      3. ในการเล่นฟีเจอร์ให้ลูกค้าดูระหว่างการ Demo ทีม Developer หรือทีม Quality Assurance จะเป็นคนรัน Demo ให้ โดยทางทีมจะต้องเตรียมข้อมูลที่ใช้ในการ Demo ให้พร้อม เช่น Data ต่าง ๆ, Excel file, PDF File สำหรับการเล่นในระบบ แต่ Project Manager จะต้องสามารถตอบได้ว่าส่วนที่ Demo นั้น คือส่วนไหนของระบบ และมีความเข้าใจเกี่ยวกับฟีเจอร์นั้น ๆ ด้วย

3. External Demo เป็นการเล่นตัวซอฟต์แวร์ในส่วนของฟีเจอร์ที่ทำเสร็จใน Sprint นั้น ๆ ให้ลูกค้าหรือผู้ใช้งานระบบดู

   1. 1. Project Manager แจ้ง Agenda ให้แก่ลูกค้าและผู้ใช้งานระบบว่าวันนี้จะมี Demo ฟีเจอร์ส่วนไหนของระบบบ้าง

      2. ทีม Developer และทีม Quality Assurance เล่นฟีเจอร์ให้ลูกค้าหรือผู้ใช้งานระบบดูตาม Flow ที่ได้เตรียมไว้กับ Project Manager

      3. หากมีคำถามทางลูกค้าหรือผู้ใช้งานสามารถสอบถามระหว่างการ Demo หรือรอให้ถามทีเดียวตอน Demo เสร็จก็ได้

      4. หากลูกค้าหรือผู้ใช้งานระบบมีติดขัดการใช้งานหรือต้องการปรับเปลี่ยนอะไรบางอย่างหลังจากที่ได้ดู Demo ไปแล้ว Project Manager ต้องพึงระวังไว้ว่านั่นเป็นความผิดปกติของระบบจริง ๆ หรือเป็น Change Request (CR) ที่ลูกค้าเพิ่งคิดความต้องการนี้ออกมาภายหลังโดยอยู่นอกเหนือจาก Requirement ที่ตกลงกันไว้ตอนแรก

ข้อดีของการ Demo หลังจบ Sprint

1. ทำให้ลูกค้าหรือผู้ใช้งานระบบได้เห็นความคืบหน้าของโปรเจกต์ ว่าตอนนี้ทำไปถึงไหนแล้ว ยังเป็นไปตาม Timeline ที่ได้ตกลงกันไว้หรือไม่

2. ทำให้ลูกค้าหรือผู้ใช้งานระบบสามารถเห็นภาพของซอฟต์แวร์ในแต่ละฟีเจอร์ได้อย่างชัดเจนว่า ฟีเจอร์ตัวนี้สามารถตอบโจทย์การทำงานอย่างที่ต้องการให้เป็นหรือไม่ หากมีความต้องการในการปรับเปลี่ยนส่วนใด ก็สามารถ Feedback เพื่อทำการแก้ไขได้เลยสำหรับส่วนที่อยู่ใน Scope แต่หากเป็นส่วนเพิ่มเติมจาก Requirement ที่ตกลงไว้ตอนแรกก็ต้องคุยกันให้เข้าใจว่าต้องทำเป็น Change Request (CR) โดยทางเราจะคิดค่าใช้จ่ายเพิ่มเติมโดยประเมินตามความต้องการที่เพิ่มเข้ามา

3. ทีมพัฒนาระบบจะได้รับ Feedback เพื่อนำไปพัฒนาระบบต่อได้อย่างรวดเร็วใน Sprint ถัดไป ไม่ต้องรอไปจนจบโปรเจกต์แล้วค่อยกลับมาแก้ โดยเฉพาะอย่างยิ่งฟีเจอร์หลักที่จะเป็นตัวส่งผลกระทบให้แก่ฟีเจอร์อื่น ๆ หากแก้ไขได้เร็วก็จะทำให้ทีมทำงานสามารถประหยัดเวลาลงไปได้

การทำ Demo จะช่วยทำให้ลูกค้าหรือผู้ใช้งานระบบสามารถมองเห็นความคืบหน้าของโปรเจกต์ รวมถึงหากมีสิ่งใดที่อยากให้ปรับเปลี่ยนระหว่างการทำโปรเจกต์ ทางทีมพัฒนาระบบก็จะได้รับ Feedback ที่สามารถนำไปทำงานต่อใน Sprint ถัดไปได้เลย ช่วยลดระยะเวลาและความเสียหายที่จะเกิดขึ้นในอนาคตได้ สำหรับใครที่กำลังทำซอฟต์แวร์อยู่ก็อย่าลืมนำการ Demo นี้ไปปรับใช้กันดูนะคะ

References:

• What Is a Sprint Demo and How Do You Conduct One (Remotely)?

• Digital Product Development Process : กระบวนการสร้างดิจิทัลโปรดัก