Activity

การทำกิจกรรมของสกรัมเพื่อให้การดำเนินงานเป็นขั้นตอนชัดเจน ตรวจสอบ วัดผลได้ และลดการประชุมที่ไม่จำเป็น การทำสกรัมจะประกอบไปด้วยกิจกรรมต่างๆ ดังนี้

1. วางแผนสปรินท์ (Sprint Planing)

https://hygger.io/blog/run-proper-sprint-planning-meeting/

ใช้เวลาไม่เกิน 4 ชั่วโมง สำหรับสปรินท์ 2 สัปดาห์ โดยจะแบ่งการวางแผนสปรินท์ออกเป็นสองส่วน

ส่วนที่หนึ่ง: เลือกว่าจะทำงานอะไร

• Product Owner จะกำหนดเป้าหมายของสปรินท์ว่าจะส่งมอบอะไร เพราะอะไร และเพื่ออะไร ทำให้ทีมเข้าใจว่าต้องทำงานชิ้นไหนบ้างเพื่อให้เกิดอะไร
• Product Owner เลือก User Story จาก Product Backlog มาแจ้งให้ทีมทราบว่าต้องทำงานชิ้นไหนบ้างเพื่อที่จะบรรลุเป้าหมายของสปรินท์
• Developer จะเลือกงานที่ Product Owner เลือกไว้ใน Product Backlog เข้าสู่ Sprint Backlog เอง เพราะรู้ขีดจำกัดว่างานใดที่สามารถนำไปพัฒนาได้หรือต้องรองานส่วนอื่นเสร็จก่อน และปริมาณงานที่ทีมสามารถพัฒนาได้เสร็จในสปรินท์

ส่วนที่สอง: ออกแบบวิธีว่าจะทำงานอย่างไร

• Developer ออกแบบแนวทางที่จะใช้ในการพัฒนางานแต่ละชิ้น
• ระบุส่วนที่ต้องรีบทำก่อนส่วนอื่น(ถ้ามี)
• แบ่งชิ้นงานขนาดใหญ่ให้เป็นชิ้นงานเล็กๆ
• อาจทำการประเมินความซับซ้อนและเวลาที่ใช้ในการพัฒนางานใหม่
• อาจนำผลการประเมินมาจัดเรียงความสำคัญของงานใหม่
• อาจมีการต่อรองปริมาณใน Sprint Backlog กับ Product Owner ใหม่ หากพบว่าการพัฒนามีความยากกว่าที่ประเมินไว้ในตอนแรก

2. สกรัมประจำวัน (Daily Scrum)

https://standuply.com/blog/daily-standup-meeting-excel-template/

การประชุมประจำวัน (Daily Meeting) หรืออาจะเรียกว่า Standup Meeting เพราะเป็นการล้วมวงยืนประชุมในเวลาสั้นๆ ใช้เวลาไม่เกิน 15 นาที เน้นให้ Developer แจ้งความคืบหน้าในการพัฒนางานแก่กัน

• เพื่อตรวจสอบและแจ้งความคืบหน้าของงานในสปรินท์
• เพื่อเป็นการวางแผนทำงานในแต่ละวัน
• โดยแต่ละคนแจ้งให้ทีมทราบว่า 1.ทำอะไรไปในเมื่อวาน 2.วันนี้จะทำอะไรเพิ่มเติม 3.ปัญหาที่เกิดขึ้นในการพัฒนา
• แจ้งให้ทีมทราบหากมีงานอื่นแทรกเข้ามา
• หากพบปัญหาหรือการเปลี่ยนแปลงที่ส่งผลต่อการบรรลุเป้าหมายของสปรินท์ อาจจัดประชุมหลังทำสกรัมประจำวันเพื่อวางแผนงานที่เหลือในสปรินท์ใหม่ โดยอาจเปลี่ยนแปลงสโคปงาน หรือโยกย้ายงานที่จำเป็นน้อยกว่าออกจากสปรินท์
• Scrum Master ช่วยควบคุมเวลาไม่ให้เกิน 15 นาที และป้องกันไม่ให้คนภายนอกรบกวนการทำสกรัมประจำวัน

3. ตรวจสอบผลลัพธ์ของสปรินท์ (Sprint Review)

https://www.quickscrum.com/Sprint-Review-Meeting

ใช้เวลาไม่เกิน 2 ชั่วโมง สำหรับสปรินท์ 2 สัปดาห์ ตรวจสอบงานที่พัฒนาและแสดงผลลัพธ์ของงานในสปรินท์ให้แก่ผู้เกี่ยวข้อง(Stakeholders) เพื่อรับฟังข้อเสนอแนะ และทบทวน Product Backlog ที่จะทำต่อไปให้สอดคล้องกับโอกาสและสถานการณ์ของตลาดในปัจจุบัน

• Product Owner อธิบายว่ามีงานอะไรเสร็จหรือไม่เสร็จ
• Developer อธิบายการดำเนินงาน และปัญหาที่เกิดขึ้นรวมถึงวิธีที่แก้ไข
• Demo งานที่พัฒนาขึ้นในสปรินท์
• พิจารณาคุณค่าของงานที่ได้พัฒนาขึ้นมาและเลือกงานที่จะส่งมอบให้แก่ผู้ใช้
• ทบทวนทรัพยากรที่มี ทีมงาน, เวลา, เครื่องมือ, ตลาด
• ทบทวนทิศทางตลาดและสถานการณ์ที่เปลี่ยนไป
• Product Owner อธิบายงานที่เหลือใน Product Backlog เกริ่นคร่าวๆว่าจะทำอะไรเป็นลำดับต่อไปและจะเสร็จเมื่อไร โดยดูได้จาก Burndown Chart เป็นต้น

4. ตรวจสอบการดำเนินงานของสปรินท์ (Sprint Retrospective)

http://1ab.in/dko

ใช้เวลาไม่เกิน 1.5 ชั่วโมง สำหรับสปรินท์ 2 สัปดาห์ ตรวจสอบการดำเนินงานในสปรินท์ที่จบลง ทั้งในเรื่องของทีมงาน ความสัมพันธ์ภายในทีม ความรู้ เครื่องมือ สภาพแวดล้อมในการทำงาน เป็นต้น

• โดยแต่ละคนแจ้งให้ทีมทราบว่าสปรินท์ที่จบลงมีอะไรที่ดีและไม่ดีบ้าง
• จัดลำดับความสำคัญของผลกระทบของสิ่งที่ไม่ดีและต้องการปรับปรุง
• ทีมเสนอแนวทางในการแก้ไขสิ่งที่ไม่ดี เพื่อเพิ่มประสิทธิภาพในการดำเนินงานและคุณภาพของผลิตภัณฑ์
• สรุปวิธีการดำเนินการที่จะใช้ในสปรินท์ถัดไป(ถ้ามี) โดยจะต้องสามารถวัดผลวิธีการดำเนินงานแบบใหม่ เพื่อนำมาเปรียบเทียบกับวิธีดำเนินงานแบบเก่าว่าแบบไหนมีประสิทธิภาพมากกว่ากัน
• Scrum Master เข้าร่วมในสถานะสมาชิกทีม และช่วยควบคุมเวลา

5. ชี้แจงรายละเอียด Product Backlog (Product Backlog Refining)

https://agilecheetah.com/deliver-valuable-solutions-through-scrum-part-iii/

ใช้เวลาไม่เกิน 10% ของสปรินท์ จัดเมื่อไรก็ได้ในสปรินท์โดยให้ทีมตกลงกันเอง ระหว่าง Product Owner และ Developer เพื่อชี้แจงรายละเอียดงาน ประเมินเวลาที่ใช้ในการพัฒนาชิ้นงาน และจัดลำดับความสำคัญของงาน

• Product Owner อธิบาย User Story ต่างๆ ใน Product Backlog
• งานที่มีลำดับความสำคัญสูงต้องมีรายละเอียดงานให้ครบ เพื่อให้ Developer สามารถประเมินความซับซ้อนและเวลาที่ต้องใช้ในการพัฒนางานได้อย่างแม่นยำ
• Developer ประเมินความซับซ้อนและเวลาที่ใช้ในการพัฒนางาน
• Product Owner นำผลการประเมินมาช่วยจัดลำดับความสำคัญใหม่
• Product Owner สรุปงานที่เหลือใน Product Backlog เทียบกับงานที่ทำในสปรินท์ปัจจุบัน เพื่อดูว่างานทั้งหมดจะพัฒนาเสร็จเมื่อไร (สามารถใช้ Burndown Chart ช่วยประเมินเวลาที่จะพัฒนาได้)

• WordPress
• Link