การวางแผนสปรินต์: แนวปฏิบัติ Agile ดีที่สุด

แนวคิดหลัก

พื้นฐานการวางแผน

แนวปฏิบัติที่ดีที่สุดในการวางแผน Sprint เริ่มต้นจากความเข้าใจในหลักการพื้นฐาน การวางแผนที่มีคุณภาพต้องการแนวทางที่เป็นระบบ ซึ่งรวมถึงการวิเคราะห์ Sprint ก่อนหน้า การประเมินความสามารถของทีม และการกำหนดเป้าหมายที่ชัดเจน

1. การเตรียมการวางแผนต้องเริ่มต้นล่วงหน้า Product Owner ต้องเตรียมและจัดลำดับความสำคัญของ backlog อย่างน้อยหนึ่งวันก่อนการประชุม ทีมพัฒนาต้องมีโอกาสศึกษา User Story ล่วงหน้าและถามคำถามเพื่อความชัดเจน
2. กฎคลาสสิกกล่าวว่า: สำหรับแต่ละสัปดาห์ของ Sprint จะใช้เวลาวางแผนสองชั่วโมง สำหรับ Sprint สองสัปดาห์หมายถึงสี่ชั่วโมง แต่ประสบการณ์แสดงว่าการแบ่งเวลานี้เป็นสองขั้นตอนๆ ละสองชั่วโมงจะมีประสิทธิภาพมากกว่า

ขั้นตอนการเตรียมการ

การปรับปรุงการวางแผน Sprint เป็นไปไม่ได้หากไม่มีการเตรียมการที่มีคุณภาพ ขั้นตอนนี้มักถูกประเมินต่ำ แม้ว่าจะเป็นสิ่งที่กำหนดความสำเร็จของกระบวนการทั้งหมด

• Definition of Ready (DoR) — เกณฑ์ความพร้อมของ User Story สำหรับการรวมเข้าใน Sprint แต่ละ Story ต้องมีเกณฑ์การยอมรับที่ชัดเจน การประเมินความซับซ้อน และการพึ่งพาอาศัยงานอื่น หากไม่ปฏิบัติตาม DoR การวางแผนจะกลายเป็นความสับสนวุ่นวาย ที่ทีมใช้เวลาหาข้อมูลรายละเอียดแทนที่จะเน้นการดำเนินงาน
• Backlog refinement ต้องดำเนินการอย่างสม่ำเสมอ ไม่ใช่เฉพาะก่อนการวางแผน Sprint เท่านั้น แนะนำให้จัดสรร 10% ของเวลา Sprint สำหรับกระบวนการนี้ ทีมสามารถจัดการประชุม refinement สั้นๆ หลายครั้งต่อสัปดาห์ ค่อยๆ ดำเนินการกับ Story สำหรับ Sprint ในอนาคต
• การวิเคราะห์ Velocity ช่วยให้ทีมเข้าใจความสามารถที่แท้จริงของตนเอง สำคัญคือต้องพิจารณาไม่เพียงแต่ความเร็วเฉลี่ยของ 3-5 Sprint ล่าสุดเท่านั้น แต่ยังรวมถึงปัจจัยที่อาจส่งผลต่อประสิทธิภาพ: วันหยุด เทศกาล หนี้ทางเทคนิค หรือการพึ่งพาอาศัยภายนอก

การประชุมวางแผน

กลยุทธ์ที่มีประสิทธิภาพสำหรับการวางแผน Sprint รวมถึงแนวทางที่เป็นระบบต่อการประชุมเอง การวางแผน Sprint ประกอบด้วยสองส่วน: การกำหนด "อะไร" ที่จะทำ และ "อย่างไร" ที่จะดำเนินการ

1. ทีมร่วมกับ Product Owner กำหนดเป้าหมายของ Sprint ที่รวมเอา User Story ที่เลือกทั้งหมดเข้าด้วยกัน เป้าหมายต้องเฉพาะเจาะจง วัดผลได้ และเข้าใจได้สำหรับผู้เข้าร่วมทุกคน เป้าหมายที่ไม่ดี: "ปรับปรุงประสบการณ์ผู้ใช้" เป้าหมายที่ดี: "ผู้ใช้สามารถลงทะเบียนผ่านโซเชียลมีเดียด้วยการคลิกเพียงครั้งเดียว"
2. ทีมพัฒนาแบ่งย่อย Story ที่เลือกเป็นงานย่อยและประเมินเป็นชั่วโมง กระบวนการนี้ช่วยเปิดเผยความซับซ้อนและการพึ่งพาอาศัยที่ซ่อนอยู่ แต่ละงานควรใช้เวลาไม่เกิน 8 ชั่วโมง — หากมากกว่านั้น ต้องแบ่งเป็นงานย่อย

บทบาทและความรับผิดชอบ

การปฏิสัมพันธ์ในทีม Agile สร้างขึ้นจากความเข้าใจที่ชัดเจนในบทบาทของผู้เข้าร่วมแต่ละคนในกระบวนการวางแผน

• Scrum Master อำนวยความสะดวกในกระบวนการ ควบคุมกรอบเวลาและช่วยทีมในการตัดสินใจ เขาไม่ควรบังคับการตัดสินใจ แต่ต้องถามคำถามที่ถูกต้องและนำการอภิปรายไปในทิศทางที่สร้างสรรค์
• Product Owner รับผิดชอบการจัดลำดับความสำคัญของ backlog และการตัดสินใจเกี่ยวกับฟีเจอร์ที่ควรพัฒนาเป็นอันดับแรก เขาต้องพร้อมอธิบายคุณค่าทางธุรกิจของแต่ละ Story และตอบคำถามของทีมพัฒนา
• ทีมพัฒนา รับผิดชอบในการส่งมอบผลลัพธ์ สำคัญคือ commitment ต้องมาจากทีมเอง ไม่ใช่การบังคับจากภายนอก เท่านั้นจึงจะบรรลุแรงจูงใจและความรับผิดชอบในระดับสูง

ข้อผิดพลาดที่พบบ่อย

• การประเมินความสามารถเกินจริง — ข้อผิดพลาดที่พบบ่อยที่สุดในการวางแผน Sprint ทีมมีแนวโน้มที่จะรับงานมากกว่าที่สามารถทำได้ โดยเฉพาะในช่วงเริ่มต้นโครงการหรือหลัง Sprint ที่ประสบความสำเร็จ คำแนะนำสำหรับการวางแผน Sprint แบบ Agile รวมถึงหลักการ "ประเมินต่ำดีกว่าประเมินสูง" การไม่ปฏิบัติตามข้อผูกพันทำลายความไว้วางใจของ stakeholder และลดแรงจูงใจของทีม
• การไม่มีเวลาสำรอง — ข้อผิดพลาดที่สำคัญอีกประการหนึ่ง ในแผน Sprint ควรจัดสรร 10-20% ของเวลาบัฟเฟอร์สำหรับงานที่ไม่คาดคิด บัก หรือการสนับสนุนทางเทคนิค เวลาสำรองนี้ไม่ควรเติมด้วย Story เพิ่มเติม "เผื่อไว้"
• การเพิกเฉยต่อการพึ่งพาอาศัย นำไปสู่การติดขัดในช่วงกลาง Sprint การพึ่งพาอาศัยภายนอกทั้งหมดต้องถูกระบุและดำเนินการในขั้นตอนการวางแผน หากงานพึ่งพาทีมอื่นหรือผู้ให้บริการภายนอก จำเป็นต้องตกลงกำหนดเวลาล่วงหน้าและได้รับการยืนยัน

การติดตามกระบวนการ

แนวปฏิบัติที่ดีที่สุดในการวางแผน Sprint รวมถึงการปรับปรุงกระบวนการวางแผนอย่างต่อเนื่อง ใน Retrospective ทีมควรวิเคราะห์ไม่เพียงแต่ผลลัพธ์ของ Sprint เท่านั้น แต่ยังรวมถึงคุณภาพการวางแผนด้วย

เมตริกสำหรับการวิเคราะห์:

• ความแม่นยำของการประเมิน (การเปรียบเทียบเวลาที่วางแผนและเวลาที่ใช้จริง)
• เปอร์เซ็นต์ของ Story ที่เสร็จ
• จำนวนการเปลี่ยนแปลงใน Sprint หลังการวางแผน
• เวลาที่ใช้ในการวางแผน

Burndown Chart ช่วยตติดตามความคืบหน้าระหว่าง Sprint และระบุปัญหาในระยะเริ่มต้น หากกราฟแสดงว่าทีมไม่ทันดำเนินงานตามที่วางแผนไว้ จำเป็นต้องดำเนินมาตรการแก้ไข: จัดลำดับความสำคัญงานใหม่หรือยกเลิก User Story ที่สำคัญน้อยที่สุด

การปรับเปลี่ยนการวางแผน

• ทีมระยะไกล ต้องการแนวทางพิเศษในการวางแผน Sprint จำเป็นต้องใช้เครื่องมือเฉพาะสำหรับการทำงานร่วมกันและรับประกันการสื่อสารที่มีคุณภาพของผู้เข้าร่วมทุกคน แนะนำให้จัดการวางแผนเป็นการประชุมสั้นๆ หลายครั้งแทนการประชุมยาวครั้งเดียว
• โครงการขนาดใหญ่ที่มีหลายทีม ต้องการการประสานงานการวางแผนในระดับโปรแกรม Scrum of Scrums หรือ SAFe (Scaled Agile Framework) ให้โครงสร้างสำหรับการซิงโครไนส์งานของหลายทีม
• โครงการบำรุงรักษา ที่ใช้เวลาส่วนใหญ่ในการสนับสนุนและแก้ไขบัก ต้องการการจองส่วนหนึ่งของ capacity สำหรับงานที่ไม่ได้วางแผน โดยปกติ 30 ถึง 50% ของเวลา Sprint จะจัดสรรสำหรับการสนับสนุน และเวลาที่เหลือสำหรับพัฒนาฟีเจอร์ใหม่

อ่านเพิ่มเติม:

เรียนรู้การจัดการโครงการ โดยอ่านบทความของเรา สามเหลี่ยมการจัดการโครงการ: ขอบเขต เวลา ต้นทุน

ทำให้งานง่ายขึ้นสำหรับคุณและทีม โดยทำความรู้จักกับ บอร์ด Kanban คู่มือการจัดการกระบวนการ

ช่วยทีมให้มุ่งเน้นความต้องการที่แท้จริงของผู้ใช้ด้วยบทความ Agile Personas: การปรับปรุงการพัฒนาที่เน้นผู้ใช้

บทสรุป

การวางแผน Sprint ที่มีประสิทธิภาพต้องการแนวทางเชิงระบบและการปรับปรุงอย่างต่อเนื่อง 

จำไว้ว่าการวางแผนที่สมบูรณ์แบบไม่มีอยู่จริง ใช้ Retrospective ไม่เพียงแต่สำหรับวิเคราะห์ผลลัพธ์ แต่ยังเพื่อปรับปรุงกระบวนการวางแผนเองด้วย เฉพาะผ่านการปฏิบัติและการปรับปรุงอย่างต่อเนื่องเท่านั้น ทีมจึงจะบรรลุประสิทธิภาพสูงสุดในการทำงานกับระเบียบวิธี Agile

แนะนำให้อ่าน

"Scrum: The Art of Doing Twice the Work in Half the Time"

หนังสือเล่มนี้เปิดเผยว่าเฟรมเวิร์ก Scrum ช่วยให้ทีมบรรลุผลลัพธ์ที่โดดเด่นในเวลาที่น้อยลง

ที่ Amazon

"User Story Mapping: Discover the Whole Story, Build the Right Product"

การทำแผนที่ User Story แบบ Visual ช่วยให้ทีมเข้าใจเป้าหมายผลิตภัณฑ์ได้ดีขึ้นและวางแผน Sprint อย่างมีสติ

ที่ Amazon

"Essential Scrum: A Practical Guide to the Most Popular Agile Process"

โครงสร้าง บทบาท และวิธีการที่ให้ความเข้าใจลึกซึ้งเกี่ยวกับการใช้ Scrum ในงานประจำวัน

ที่ Amazon