Scrum คืออะไร เริ่มใช้งานอย่างไร
Scrum (สกรัม) คือการนำแนวคิดในการทำงานแบบ Agile (อไจล์) มาปฏิบัติตามขั้นตอนของสกรัม เพื่อระบุปัญหาที่มีความซับซ้อน เปลี่ยนแปลงบ่อย เพื่อให้สามารถส่งมอบผลิตภัณฑ์ที่ตอบสนองต่อการเปลี่ยนแปลงที่เกิดขึ้นได้อย่างรวดเร็ว
สกรัม
การพัฒนาผลิตภัณฑ์แบบอไจล์(Agile) ด้วยรูปแบบของสกรัม(Scrum)
ช่วยให้การพัฒนาผลิตภัณฑ์แบบอไจล์มีขั้นตอนการการดำเนินงานและผลลัพธ์ที่ชัดเจน โปร่งใส สามารถตรวจสอบประสิทธิภาพของแต่ละขั้นตอนการดำเนินงาน สามารถปรับปรุงและวัดผลการปรับปรุงที่เกิดขึ้นได้ โดยบทความนี้จะยึดเนื้อหาตามคู่มือสกรัมฉบับล่าสุด ณ วันที่เขียนบทความ คือคู่มือสกรัมฉบับปี 2017 (Scrum Guide 2017) เป็นหลัก
ก่อนที่จะเข้าสู่เนื้อหาของสกรัม หากยังไม่เข้าใจว่าการพัฒนาผลิตภัณฑ์แบบอไจล์คืออะไร สามารถเข้าไปอ่านเพิ่มเติมได้ที่
ทำสกรัมเพื่ออะไร (Scrum Achievement)
- กำหนดทิศทางและความสามารถของผลิตภัณฑ์ อะไรควรมี อะไรไม่ควรมี
- เพิ่มคุณค่าให้ผลิตภัณฑ์
- ส่งมอบผลิตภัณฑ์ได้รวดเร็วและบ่อยมากขึ้น
- วงจรอายุการใช้งาน(Life cycle) ของผลิตภัณฑ์ที่ยั่งยืน
ทฤษฏีสกรัม (Scrum Theory)
สกรัม เน้นการนำความรู้จากประสบการณ์เฉพาะที่เคยลงมือทำจริง(Empiricism) มาพัฒนาการดำเนินงานในปัจจุบันให้ดียิ่งขึ้น ประกอบด้วย 3 ส่วน
- ความโปร่งใส (Transparency) คือทีมจะต้องเห็นภาพชัดเจนและเข้าใจตรงกัน มาตรฐานเดียวกัน ไม่ตีความหมายต่างกัน เช่น นิยามของคำว่างานเสร็จ หมายถึง การผลิตเสร็จ หรือ ผลิตและทดสอบเสร็จ หรือ ได้รับการเซ็นรับรอง หรือ ส่งมอบให้ผู้ใช้แล้ว ต้องนิยามและตกลงให้เข้าใจตรงกัน
- การตรวจสอบ (Inspection) คือการนำผลลัพธ์การดำเนินกิจกรรมต่างๆของสกรัม(Scrum Artifact) มาตรวจสอบและวัดผลว่าบรรลุตามที่กำหนดไว้หรือไม่
- การปรับเปลี่ยน (Adoption) คือหากผลลัพธ์ไม่เป็นไปตามที่กำหนด จะต้องปรับเปลี่ยนการดำเนินงาน หรือจำนวนทรัพยากรที่ใช้ เพื่อให้บรรลุผลตามที่กำหนดหรือใกล้เคียงได้มากที่สุด
User Story
User Story ใช้สำหรับระบุความต้องการของผู้ใช้ให้ชัดเจน และระบุเกณฑ์การทดสอบว่าผลิตภัณฑ์ที่พัฒนาขึ้นมาตอบสนองความต้องการได้จริงหรือไม่ โดย User Story ที่ดีต้องทำให้ Developer เข้าใจสโคป(Scrope) ของงานได้อย่างชัดเจนว่าอะไรที่เกี่ยวข้องแล้วต้องพัฒนาขึ้น และอะไรที่ไม่เกี่ยวข้องจะได้ไม่ต้องเสียเวลาพัฒนา ส่วนรายละเอียดเพิ่มเติมเกี่ยวกับการเขียน User Story ที่ดี สามารถอ่านเพิ่มเติมได้ที่
Product Backlog
งานทั้งหมดที่ต้องทำเพื่อพัฒนาผลิตภัณฑ์ ส่วนใหญ่นิยมเขียนในรูปแบบของ User Story โดยมีรายละเอียดของงาน เกณฑ์การทดสอบงาน การประเมินความซับซ้อนและเวลาที่ต้องใช้ในการพัฒนาด้วย เมื่อพัฒนาเสร็จและส่งมอบแล้ว อาจนำผลตอบรับจากผู้ใช้มาทบทวนและปรับปรุงผลิตภัณฑ์เพิ่มเติม โดยเขียนเป็น User Story ใหม่
เมื่อ Product Backlog มีการเปลี่ยนแปลง Product Owner จะต้องจัดเรียงความสำคัญใหม่ และแก้ไขรายละเอียดของ User Story ที่มีความสำคัญสูงให้พร้อมสำหรับนำไปพัฒนาได้ทันที การทำ Product Backlog จะมีการเปลี่ยนแปลงอยู่เรื่อยๆ ตามความต้องการของผู้ใช้และตลาดเพื่อให้ผลิตภัณฑ์ของเราตอบสนองความต้องการได้มากที่สุด
การประเมินเวลาที่ใช้ในการพัฒนางาน
การประเมินจะมี 2 ส่วน คือขนาดของงาน ความซับซ้อน และความเสี่ยงในการพัฒนางานจะเรียกว่า Story Point ส่วนเวลาที่ต้องใช้ในการพัฒนางาน เรียกว่า Estimate Time
สาเหตุที่ต้องมี 2 ส่วนเนื่องจากการพัฒนางานประเภทซอฟต์แวร์นั้นมีความเป็นศิลป์ ทำให้แต่ละคนมีการออกแบบโค้ดไม่เหมือนกัน วางความซับซ้อนในโครงสร้างเพื่อรองรับการเปลี่ยนแปลงหรือการทดสอบต่างกัน จึงมีความซับซ้อนทำการพัฒนาและใช้เวลาไม่เท่ากัน อีกทั้งประสบการณ์และความสามารถที่ต่างกันด้วย จึงควรใช้ทั้งสองค่าร่วมกัน ในช่วงแรกของการพัฒนาผลิตภัณฑ์ค่าประเมินอาจจะไม่แม่นยำ แต่เมื่อทีมดำเนินงานไปเรื่อยๆ ค่าประเมินจะแม่นยำมากขึ้น
ค่าประเมินทั้งสองจะมีผลต่อการจัดเรียงความสำคัญของงานใน Product Backlog เพราะ Product Owner จะทราบว่างานแต่ละชิ้นต้องใช้ทรัพยากรในการพัฒนาเท่าไร คุ้มกับมูลค่าที่จะได้เมื่องานเสร็จหรือไม่
นิยามของงานเสร็จ (Done)
- ต้องมีการนิยามให้ชัดเจนและเข้าใจตรงกันทั้งทีมและทุกทีม เช่น งานเสร็จคือพัฒนาเสร็จ หรือ งานที่มีระบบตรวจสอบการทำงาน หรือ งานที่มีคู่มือใช้งาน หรือ งานที่ทดสอบผ่านแล้ว หรือ ทดสอบใช้งานร่วมกับของเดิมผ่านแล้ว หรือ งานที่ส่งมอบให้ผู้ใช้แล้ว
- ทำให้ทีมเข้าใจตรงกัน และรู้ขีดจำกัดว่ารองรับปริมาณงานได้มากเท่าไร
- งานใหม่จะต้องผ่านการทดสอบว่าสามารถใช้งานร่วมกับของเดิมได้
- Developer ต้องพัฒนาให้เสร็จตามนิยามที่ตกลงไว้ร่วมกัน
- Product Owner จะเป็นคนเลือกว่างานที่เสร็จนั้นจะส่งมอบแก่ผู้ใช้หรือไม่
- เมื่อทีมเก่งขึ้นจะนิยามคำว่า “งานเสร็จ” ใหม่ เพื่อเพิ่มคุณภาพของชิ้นงาน
Increment
งานที่ทำเสร็จพร้อมสำหรับส่งมอบให้แก่ผู้ใช้งาน(แม้จะยังไม่ส่งมอบให้ผู้ใช้งาน) โดยหมายถึงงานที่เสร็จในสปรินท์ปัจจุบันและงานจากสปรินท์เก่าที่ผ่านมาทั้งหมด
สปรินท์(Sprint) รอบเวลาการดำเนินงานแบบสกรัม
เนื่องจากธุรกิจในปัจจุบันมีการแข่งขันที่สูง และความต้องการของผู้ใช้งานเปลี่ยนแปลงบ่อย เมื่อสถาณการณ์และเวลาเปลี่ยนไปผู้ใช้งานอาจต้องการของอย่างอื่นที่ไม่ใช่สิ่งที่เราคิดไว้ในตอนแรก และต้องพัฒนาผลิตภัณฑ์ของเราให้สามารถต่อกรความสามารถของผลิตภัณฑ์ของคู่แข่งได้ทันเวลา
สกรัมจึงแบ่งรอบการดำเนินงานเป็นช่วงเวลาสั้นๆ เรียกว่าสปรินท์(Sprint) คือช่วงเวลาในการดำเนินงานที่จะสามารถส่งมอบผลิตภัณฑ์ เมื่อจบสปรินท์จะต้องได้รับชิ้นงานตามที่วางแผนไว้และสามารถนำไปส่งมอบให้แก่ผู้ใช้ ทำให้ผู้ใช้ไม่จำเป็นต้องรอจนงานเสร็จทั้งหมดก่อนจึงจะได้รับ แต่สามารถนำบางส่วนไปใช้งานก่อนได้เลยและส่วนอื่นๆ ทยอยตามมาเพิ่มเติมในภายหลัง
- ความยาวของสปรินท์จะมีช่วงเวลาระหว่าง 1–4 สัปดาห์
- ไม่ควรมีการเปลี่ยนแปลงที่ส่งผลกระทบต่อเป้าหมายของสปรินท์
- ไม่มีการลดคุณภาพของชิ้นงาน
- สโคปงานอาจเปลี่ยนแปลงได้ โดยต้องตกลงกันระหว่าง Product Owner และ Developer
เป้าหมายของสปรินท์ (Sprint Goal)
คือวัตถุประสงค์ของสปรินท์นั้นว่าต้องการทำอะไร เช่น ต้องการทำให้มีผู้ใช้ใหม่เพิ่มขึ้น X % หรือ ต้องการแนะนำสินค้าที่เกี่ยวข้องให้แก่ผู้ใช้ เป็นต้น ทำให้ทีมเห็นเป้าหมายตรงกัน รู้ว่าต้องทำงานอะไรบ้าง และรู้ว่าต้องทำงานชิ้นนี้ไปเพื่ออะไร
การยกเลิกสปรินท์
Product Owner เป็นคนเดียวที่สามารถยกเลิกสปรินท์ได้ โดยจะยกเลิกถ้าหากเป้าหมายของสปรินท์มีการยกเลิก เช่น ยกเลิกการพัฒนาฟีเจอร์นี้เนื่องจากตลาดไม่ต้องการแล้ว เมื่อทำการยกเลิกสปรินท์งานที่ทำเสร็จไปแล้วอาจนำไปใช้ต่อ ส่วนงานที่ยังทำไม่เสร็จจะนำกลับเข้าสู่ Product Backlog เมื่อจะนำเข้าสปรินท์จะทำการประเมินงานใหม่อีกครั้ง
Sprint Backlog
งานที่ Product Owner และ Developer ตกลงกัน โดยเลือกจาก Product Backlog เข้าสู่ Sprint Backlog เพื่อให้ Developer รู้ว่าต้องทำงานชิ้นไหนบ้างในสปรินท์เพื่อที่จะบรรลุเป้าหมายของสปรินท์ และ Developer ต้องพัฒนาให้เสร็จจนพร้อมสำหรับส่งมอบแก่ผู้ใช้เมื่อจบสปรินท์ และใน Sprint Backlog ควรมีงานอย่างน้อย 1 ชิ้น ที่มาจากการทำ Sprint Retrospective เพื่อปรับปรุงประสิทธิภาพการทำงานของทีม
ตำแหน่งในทีมสกรัม
สกรัมเหมาะสำหรับทีมขนาดเล็กที่พร้อมปรับตัว พัฒนา และเปลี่ยนแปลง สมาชิกในทีมสกรัมต้องมีความสามารถที่หลากหลาย สามารถบริหารและดำเนินงานกันเองได้ด้วยสมาชิกภายในทีม สามารถหาแก้ไขปัญหาได้เอง โดยไม่ต้องรอความช่วยเหลือจากนอกทีม โดยประกอบด้วย
1. Product Owner
- บริหารจัดการ Product Backlog ให้ชัดเจน
- จัดลำดับความสำคัญของงานใน Product Backlog และสามารถอธิบายเหตุผลได้
- ทำให้ทีมเข้าใจรายละเอียดของ Product Backlog ตรงกัน
- หาทางเพิ่มผลการดำเนินงานให้มีประสิทธิภาพมากขึ้น
2. Developer
- สมาชิกมีจำนวน 3–9 คน เพื่อให้สามารถรับปริมาณงานได้ไม่น้อยเกินไป และไม่เสียเวลาในการประสานงานมากเกินไป
- พัฒนางานตามที่วางแผนเอาไว้
- ไม่มีการแบ่งทีมย่อยภายใต้ทีมพัฒนาอีก เช่น ทีมออกแบบ ทีมทดสอบ
- สมากชิกทีมแต่ละคนจะมีความสามารถเฉพาะทางของตนเอง เช่น ความสามารถในการออกแบบ แต่ความรับผิดชอบงานจะเป็นของทั้งทีม หากงานออกแบบไม่เสร็จทั้งทีมต้องมาช่วยกันรับผิดชอบ
3. Scrum Master
- ทำให้ทีมเข้าในสกรัมและนำไปใช้ได้อย่างถูกต้อง
- ช่วยเหลือการดำเนินงานในขั้นตอนต่างๆ
- รู้ว่าการดำเนินงานแบบไหนดีหรือไม่ดีต่อทีม
- ทำให้ทีมเข้าใจขอบเขตของผลิตภัณฑ์
สนับสนุน Product Owner
- หาเทคนิคในการบริหารจัดการ Product Backlog
- ช่วยจัดลำดับความสำคัญ Product Backlog ให้ผลิตภัณฑ์มีคุณค่ามากที่สุด
สนับสนุน Developer
- พัฒนาให้ Developer สามารถบริหารตัวเอง และมีความสามารถหลากหลาย
- ช่วยให้สามารถผลิตงานที่มีคุณภาพ
- กำจัดอุปสรรคที่มีผลต่อการพัฒนาผลิตภัณฑ์
สนับสนุนองค์กร
- สอนให้องค์กรเข้าใจสกรัม ประโยชน์ และนำไปใช้ได้อย่างมีประสิทธิภาพ
กิจกรรมของสกรัม (Scrum Events)
การทำกิจกรรมของสกรัมเพื่อให้การดำเนินงานเป็นขั้นตอนชัดเจน ตรวจสอบ วัดผลได้ และลดการประชุมที่ไม่จำเป็น การทำสกรัมจะประกอบไปด้วยกิจกรรมต่างๆ ดังนี้
1. วางแผนสปรินท์ (Sprint Planing)
ใช้เวลาไม่เกิน 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)
การประชุมประจำวัน (Daily Meeting) หรืออาจะเรียกว่า Standup Meeting เพราะเป็นการล้วมวงยืนประชุมในเวลาสั้นๆ ใช้เวลาไม่เกิน 15 นาที เน้นให้ Developer แจ้งความคืบหน้าในการพัฒนางานแก่กัน
- เพื่อตรวจสอบและแจ้งความคืบหน้าของงานในสปรินท์
- เพื่อเป็นการวางแผนทำงานในแต่ละวัน
- โดยแต่ละคนแจ้งให้ทีมทราบว่า 1.ทำอะไรไปในเมื่อวาน 2.วันนี้จะทำอะไรเพิ่มเติม 3.ปัญหาที่เกิดขึ้นในการพัฒนา
- แจ้งให้ทีมทราบหากมีงานอื่นแทรกเข้ามา
- หากพบปัญหาหรือการเปลี่ยนแปลงที่ส่งผลต่อการบรรลุเป้าหมายของสปรินท์ อาจจัดประชุมหลังทำสกรัมประจำวันเพื่อวางแผนงานที่เหลือในสปรินท์ใหม่ โดยอาจเปลี่ยนแปลงสโคปงาน หรือโยกย้ายงานที่จำเป็นน้อยกว่าออกจากสปรินท์
- Scrum Master ช่วยควบคุมเวลาไม่ให้เกิน 15 นาที และป้องกันไม่ให้คนภายนอกรบกวนการทำสกรัมประจำวัน
3. ตรวจสอบผลลัพธ์ของสปรินท์ (Sprint Review)
ใช้เวลาไม่เกิน 2 ชั่วโมง สำหรับสปรินท์ 2 สัปดาห์ ตรวจสอบงานที่พัฒนาและแสดงผลลัพธ์ของงานในสปรินท์ให้แก่ผู้เกี่ยวข้อง(Stakeholders) เพื่อรับฟังข้อเสนอแนะ และทบทวน Product Backlog ที่จะทำต่อไปให้สอดคล้องกับโอกาสและสถานการณ์ของตลาดในปัจจุบัน
- Product Owner อธิบายว่ามีงานอะไรเสร็จหรือไม่เสร็จ
- Developer อธิบายการดำเนินงาน และปัญหาที่เกิดขึ้นรวมถึงวิธีที่แก้ไข
- Demo งานที่พัฒนาขึ้นในสปรินท์
- พิจารณาคุณค่าของงานที่ได้พัฒนาขึ้นมาและเลือกงานที่จะส่งมอบให้แก่ผู้ใช้
- ทบทวนทรัพยากรที่มี ทีมงาน, เวลา, เครื่องมือ, ตลาด
- ทบทวนทิศทางตลาดและสถานการณ์ที่เปลี่ยนไป
- Product Owner อธิบายงานที่เหลือใน Product Backlog เกริ่นคร่าวๆว่าจะทำอะไรเป็นลำดับต่อไปและจะเสร็จเมื่อไร โดยดูได้จาก Burndown Chart เป็นต้น
4. ตรวจสอบการดำเนินงานของสปรินท์ (Sprint Retrospective)
ใช้เวลาไม่เกิน 1.5 ชั่วโมง สำหรับสปรินท์ 2 สัปดาห์ ตรวจสอบการดำเนินงานในสปรินท์ที่จบลง ทั้งในเรื่องของทีมงาน ความสัมพันธ์ภายในทีม ความรู้ เครื่องมือ สภาพแวดล้อมในการทำงาน เป็นต้น
- โดยแต่ละคนแจ้งให้ทีมทราบว่าสปรินท์ที่จบลงมีอะไรที่ดีและไม่ดีบ้าง
- จัดลำดับความสำคัญของผลกระทบของสิ่งที่ไม่ดีและต้องการปรับปรุง
- ทีมเสนอแนวทางในการแก้ไขสิ่งที่ไม่ดี เพื่อเพิ่มประสิทธิภาพในการดำเนินงานและคุณภาพของผลิตภัณฑ์
- สรุปวิธีการดำเนินการที่จะใช้ในสปรินท์ถัดไป(ถ้ามี) โดยจะต้องสามารถวัดผลวิธีการดำเนินงานแบบใหม่ เพื่อนำมาเปรียบเทียบกับวิธีดำเนินงานแบบเก่าว่าแบบไหนมีประสิทธิภาพมากกว่ากัน
- Scrum Master เข้าร่วมในสถานะสมาชิกทีม และช่วยควบคุมเวลา
5. ชี้แจงรายละเอียด Product Backlog (Product Backlog Refining)
ใช้เวลาไม่เกิน 10% ของสปรินท์ จัดเมื่อไรก็ได้ในสปรินท์โดยให้ทีมตกลงกันเอง ระหว่าง Product Owner และ Developer เพื่อชี้แจงรายละเอียดงาน ประเมินเวลาที่ใช้ในการพัฒนาชิ้นงาน และจัดลำดับความสำคัญของงาน
- Product Owner อธิบาย User Story ต่างๆ ใน Product Backlog
- งานที่มีลำดับความสำคัญสูงต้องมีรายละเอียดงานให้ครบ เพื่อให้ Developer สามารถประเมินความซับซ้อนและเวลาที่ต้องใช้ในการพัฒนางานได้อย่างแม่นยำ
- Developer ประเมินความซับซ้อนและเวลาที่ใช้ในการพัฒนางาน
- Product Owner นำผลการประเมินมาช่วยจัดลำดับความสำคัญใหม่
- Product Owner สรุปงานที่เหลือใน Product Backlog เทียบกับงานที่ทำในสปรินท์ปัจจุบัน เพื่อดูว่างานทั้งหมดจะพัฒนาเสร็จเมื่อไร (สามารถใช้ Burndown Chart ช่วยประเมินเวลาที่จะพัฒนาได้)
Sprint Cheatsheet
สรุปการดำเนินสปรินท์ฉบับย่อ
ผลลัพธ์จากกิจกรรมของสกรัม (Scrum Artifacts)
คือผลลัพธ์ที่ได้จากการทำกิจกรรมสกรัมต่างๆ เพื่อนำมาใช้ในการตรวจสอบและวัดผลการปรับเปลี่ยนวิธีการดำเนินงานแต่ละสปรินท์ ช่วยให้สามารถเปรียบเทียบว่าวิธีการดำเนินงานแบบใหม่กับแบบเก่า แบบใดที่ดีกว่ากันได้อย่างชัดเจนและโปร่งใส
เช่น ตรวจสอบจาก Product Backlog ที่ครบถ้วนชัดเจนมากขึ้น ทีมผลิตงานได้ปริมาณมากขึ้น หรือมีอุปสรรคในการดำเนินการน้อยลงจากการทำ Sprint Retrospective เป็นต้น
การทำสกรัมให้มีประสิทธิภาพ
- ทุกคนช่วยกันทำงานเพื่อบรรลุเป้าหมายของทีม ไม่ใช่เฉพาะของเรา
- ให้ความสำคัญกับงานในสปรินท์ก่อน
- พัฒนาผลิตภัณฑ์ในทางที่ถูกต้อง ไม่ซ่อนปัญหา
- เปิดใจกว้างต่องานทั้งหมดที่มี และความท้าทายในการทำงาน
- เคารพการทำงานของคนอื่น เพื่อให้แต่ละฝ่ายสามารถทำงานได้อิสระ
สรุปวิธีการทำงานแบบอไจล์ด้วยสกรัม
ก่อนมีสปรินท์แรก
- จัดตั้งทีมสกรัมโดยขนาดของทีมต้องมีขนาดเล็ก ประกอบด้วย Scrum Master 1 คน, Product Owner 1 คน, Developer 3–9 คน
- กำหนดระยะเวลาของสปรินท์ระหว่าง 1–4 สัปดาห์
- นิยามคำว่างานเสร็จให้เข้าใจตรงกัน
- ออกแบบผลิตภัณฑ์ให้ตอบโจทย์ผู้ใช้ โดยเขียนในรูปแบบ User Story และใส่ไว้ที่ Product Backlog
วงจรสปรินท์ (Sprint Loop)
- Sprint planing 1 เลือกว่าจะทำ User Story ไหนบ้าง
- Sprint planing 2 ออกแบบว่าจะพัฒนา User Story นั้นอย่างไร
- Daily Scrum เพื่อรายงานความคืบหน้าและปัญหาที่เกิดขึ้น
- Sprint Review เพื่อตรวจสอบงานที่พัฒนา และฟังข้อเสนอแนะ
- Sprint Retrospective เพื่อตรวจสอบประสิทธิภาพในการดำเนินงาน และหาแนวทางปรับปรุง
- Product Backlog Refining เพื่ออธิบายรายละเอียดงานที่เหลือ
หากยังเห็นภาพไม่ชัดเจนให้ย้อนกลับไปดูภาพบนสุดของบทความ จะแสดงขั้นตอนต่างๆทั้งหมดของการทำสกรัม
จะเห็นได้ว่าการทำงานแบบอไจล์ด้วยสกรัมนั้นมีการวัดผล และปรับปรุงพัฒนาอยู่ในทุกขั้นตอน นอกจากนี้คู่มือสกรัมได้ระบุไว้ว่า การทำสกรัมต้องนำไปใช้ตามคู่มือทั้งหมดโดยไม่มีการปรับเปลี่ยน ไม่เช่นนั้นจะไม่ถือว่าเป็นผลลัพธ์จากการทำสกรัม อย่างไรก็ตามในความเห็นของผม มันก็ขึ้นอยู่กับสถานการณ์ของแต่ละองค์กร
อย่าทำสกรัมเป็นพิธีกรรม แต่จงทำสกรัมให้เป็นอไจล์
การทำสกรัมให้เป็นอไจล์ต้องมีการวัดผลการดำเนินงานและนำไปปรับปรุงพัฒนาจึงจะเรียกว่าอไจล์ ถ้าแค่ใช้แบ่งงานเป็นชิ้นเล็กๆเพื่อทยอยส่งมอบ โดยไม่สนใจผลตอบรับและนำมาปรับปรุงจะไม่ใช่อไจล์ แต่เป็นแค่การทยอยส่งงานโดยเอากิจกรรมของสกรัมมาทำเป็นพีธีกรรม
Follow Scrum events with Scrum theory getting empiricism to improve product and process for Scrum achievement.