Scrum - คู่มือฉบับย่อ

Agile กลายเป็นหนึ่งในคำที่นิยมมากในอุตสาหกรรมการพัฒนาซอฟต์แวร์ แต่การพัฒนาแบบว่องไวคืออะไร? พูดง่ายๆก็คือการพัฒนาแบบว่องไวเป็นวิธีการดำเนินการของทีมพัฒนาซอฟต์แวร์และโครงการต่างๆ

เพื่อให้เข้าใจว่ามีอะไรใหม่ให้เราสรุปวิธีการแบบเดิม ๆ ในการพัฒนาซอฟต์แวร์แบบเดิมข้อกำหนดของผลิตภัณฑ์จะได้รับการสรุปก่อนดำเนินการพัฒนา

น้ำตกจำลอง

รูปแบบการพัฒนาซอฟต์แวร์ที่ใช้กันมากที่สุดที่มีคุณลักษณะนี้คือ Waterfall Model ตามที่แสดงในแผนภาพต่อไปนี้ อย่างไรก็ตามในกรณีส่วนใหญ่จะมีการเพิ่มฟังก์ชันการทำงานใหม่และข้อกำหนดก่อนหน้านี้อาจมีการเปลี่ยนแปลง แบบจำลองน้ำตกไม่มีโครงสร้างเพื่อรองรับการเปลี่ยนแปลงอย่างต่อเนื่องในข้อกำหนดดังกล่าว นอกจากนี้ผู้ใช้จะไม่มีความชัดเจนในการทำงานของผลิตภัณฑ์จนกว่าผลิตภัณฑ์จะพร้อมใช้งานอย่างครบถ้วน

แบบจำลองส่วนเพิ่มซ้ำ

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

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

การพัฒนาที่คล่องตัว

การพัฒนาแบบว่องไวขึ้นอยู่กับการพัฒนาแบบเพิ่มขึ้นซ้ำ ๆ ซึ่งข้อกำหนดและแนวทางแก้ไขพัฒนาขึ้นโดยการทำงานร่วมกันเป็นทีม แนะนำวิธีการทำซ้ำแบบแบ่งเวลาและกระตุ้นการตอบสนองต่อการเปลี่ยนแปลงอย่างรวดเร็วและยืดหยุ่น เป็นกรอบทางทฤษฎีและไม่ได้ระบุถึงแนวปฏิบัติใด ๆ ที่ทีมพัฒนาควรปฏิบัติตาม Scrum เป็นกรอบกระบวนการ Agile ที่กำหนดแนวทางปฏิบัติที่จำเป็นต้องปฏิบัติตาม

การนำวิธี Agile ไปใช้ในช่วงแรก ได้แก่Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development (1997) และDynamic Systems Development Method (DSDM) (1995) สิ่งเหล่านี้เรียกรวมกันว่าagile methodologiesหลังจากที่ Agile Manifesto ตีพิมพ์ในปี 2544

ประกาศ Agile

Agile Manifesto ได้รับการเผยแพร่โดยทีมนักพัฒนาซอฟต์แวร์ในปี 2544 โดยเน้นถึงความสำคัญที่ต้องให้กับทีมพัฒนารองรับความต้องการที่เปลี่ยนแปลงการมีส่วนร่วมของลูกค้า

Agile Manifesto มีดังนี้:

“ เรากำลังเปิดเผยวิธีที่ดีกว่าในการพัฒนาซอฟต์แวร์โดยการทำและช่วยเหลือผู้อื่น จากผลงานชิ้นนี้เราได้ให้ความสำคัญกับ:

บุคคลและปฏิสัมพันธ์กับกระบวนการและเครื่องมือ
ซอฟต์แวร์ที่ใช้งานได้กับเอกสารที่ครอบคลุม
การทำงานร่วมกันของลูกค้าในการเจรจาสัญญา
การตอบสนองต่อการเปลี่ยนแปลงตามแผน

นั่นคือในขณะที่สิ่งของทางด้านขวามีค่า แต่เราให้ความสำคัญกับรายการทางด้านซ้ายมากขึ้น "

… Manifesto for Agile Software Development, Authors: Beck, Kent, et al. (พ.ศ. 2544)

คำจำกัดความของรายการ Agile Manifesto

รายการประกาศทางด้านซ้ายสามารถอธิบายได้ดังนี้:

รายการ Manifesto	คำอธิบาย
บุคคลและปฏิสัมพันธ์	ต้องให้ความสำคัญกับ: องค์กรตนเองและแรงจูงใจในตนเองของสมาชิกในทีม ปฏิสัมพันธ์อย่างต่อเนื่องสำหรับการทำงานการชี้แจงข้อมูลระหว่างสมาชิกในทีม
ซอฟต์แวร์การทำงาน	การส่งมอบซอฟต์แวร์ที่ใช้งานได้ในช่วงเวลาสั้น ๆ ช่วยให้ลูกค้าได้รับความไว้วางใจและความเชื่อมั่นในทีม
การทำงานร่วมกันของลูกค้า	การมีส่วนร่วมของลูกค้ากับทีมพัฒนาอย่างต่อเนื่องช่วยให้มั่นใจได้ว่ามีการสื่อสารถึงการปรับเปลี่ยนที่จำเป็น
การตอบสนองต่อการเปลี่ยนแปลง	มุ่งเน้นไปที่การตอบสนองอย่างรวดเร็วต่อการเปลี่ยนแปลงที่เสนอซึ่งทำได้ด้วยการทำซ้ำในระยะเวลาสั้น ๆ

องค์ประกอบสำคัญของ Agile Manifesto คือเราต้องไว้วางใจผู้คนและความสามารถในการทำงานร่วมกัน ด้วยเหตุนี้วิธีการแบบ Agile ที่เฉพาะเจาะจงจึงพัฒนาขึ้นเพื่อแตะความสามารถของสมาชิกในทีมโดยเน้นการทำงานเป็นทีมและการทำงานร่วมกันตลอดวงจรชีวิตของโครงการ

หลักการสำคัญของ Agile

Agile Manifesto ขึ้นอยู่กับหลักการต่อไปนี้:

หลักการ	คำอธิบาย
ความพึงพอใจและการจัดส่ง	ความพึงพอใจของลูกค้าผ่านซอฟต์แวร์ที่ใช้งานได้ตั้งแต่เนิ่นๆและต่อเนื่อง
ต้อนรับการเปลี่ยนแปลง	ยินดีต้อนรับความต้องการที่เปลี่ยนแปลงแม้จะอยู่ในขั้นตอนต่อไปของการพัฒนา
ส่งบ่อย	ส่งมอบซอฟต์แวร์ที่ใช้งานได้บ่อยครั้ง (รายสัปดาห์แทนที่จะเป็นรายเดือน)
การสื่อสารคือกุญแจสำคัญ	ตรวจสอบการเชื่อมโยงอย่างใกล้ชิดของนักพัฒนากับนักธุรกิจทุกวัน
สิ่งแวดล้อมและความน่าเชื่อถือ	สร้างโครงการเกี่ยวกับบุคคลที่มีแรงบันดาลใจ ให้การสนับสนุนที่จำเป็นและไว้วางใจพวกเขา
การสื่อสารแบบตัวต่อตัว	ส่งเสริมการสนทนาแบบเห็นหน้ากันเพื่อให้แน่ใจว่าการสื่อสารมีประสิทธิภาพและประสิทธิผล
ซอฟต์แวร์เป็นตัววัดความก้าวหน้า	ซอฟต์แวร์ที่ใช้งานได้คือตัวชี้วัดความก้าวหน้าขั้นต้น
การพัฒนาที่ยั่งยืน	ส่งเสริมการพัฒนาที่ยั่งยืนด้วยความสามารถในการรักษาความก้าวตลอดการพัฒนา
ความสนใจในรายละเอียด	ใส่ใจอย่างต่อเนื่องในความเป็นเลิศทางเทคนิคและการออกแบบที่ดี
พลังน้อย	ความเรียบง่ายเป็นสิ่งสำคัญ
การจัดทีมด้วยตนเอง	ความเอาใจใส่อย่างสม่ำเสมอของทีมในการมีประสิทธิผลในสถานการณ์ที่เปลี่ยนแปลงไป

วิธีการแบบ Agile

ระเบียบวิธีการพัฒนาระบบไดนามิก (DSDM)

เป็นกรอบการทำงานที่คล่องตัวสำหรับโครงการซอฟต์แวร์ มันถูกใช้เพื่อปรับแนวทางแบบดั้งเดิม DSDM เวอร์ชันล่าสุดเรียกว่า DSDM Atern ชื่อ Atern ย่อมาจาก Arctic Tern - นกทะเลที่สามารถเดินทางในระยะทางไกล ๆ ซึ่งแสดงถึงคุณสมบัติหลายประการของวิธีการซึ่งเป็นวิธีการทำงานตามธรรมชาติเช่นการจัดลำดับความสำคัญและการทำงานร่วมกัน

การต่อสู้

เป็นเฟรมเวิร์กแบบ Agile ที่ได้รับความนิยมมากที่สุดซึ่งมุ่งเน้นโดยเฉพาะอย่างยิ่งในการจัดการงานภายในสภาพแวดล้อมการพัฒนาแบบทีม Scrum ใช้รูปแบบการพัฒนาแบบวนซ้ำและแบบเพิ่มหน่วยโดยมีระยะเวลาการทำซ้ำสั้นลง การต่อสู้นั้นค่อนข้างง่ายในการนำไปใช้และมุ่งเน้นไปที่การส่งมอบที่รวดเร็วและบ่อยครั้ง

การเขียนโปรแกรมขั้นสูง (XP)

เป็นการพัฒนาซอฟต์แวร์ประเภทหนึ่งที่มีความคล่องตัว สนับสนุนการเผยแพร่บ่อยครั้งในรอบการพัฒนาสั้น ๆ ซึ่งมีวัตถุประสงค์เพื่อปรับปรุงประสิทธิภาพการผลิตและแนะนำจุดตรวจที่สามารถนำข้อกำหนดของลูกค้าใหม่มาใช้ได้ วิธีการนี้ใช้ชื่อจากแนวคิดที่ว่าองค์ประกอบที่เป็นประโยชน์ของแนวทางปฏิบัติทางวิศวกรรมซอฟต์แวร์แบบดั้งเดิมนั้นถูกนำไปใช้ในระดับที่รุนแรง (Extreme Programming เป็นระเบียบวินัยในการพัฒนาซอฟต์แวร์ที่จัดระเบียบคนให้ผลิตซอฟต์แวร์ที่มีคุณภาพสูงขึ้นอย่างมีประสิทธิผลมากขึ้น) XP จัดการกับขั้นตอนการวิเคราะห์การพัฒนาและการทดสอบด้วยวิธีการใหม่ ๆ ที่สร้างความแตกต่างอย่างมากให้กับคุณภาพของผลิตภัณฑ์ขั้นสุดท้าย

การพัฒนาที่ขับเคลื่อนด้วยการทดสอบ (TDD)

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

ยัน

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

Kanban

เป็นระบบปรับปรุงและรักษาระดับการผลิตให้สูงขึ้น Kanban เป็นวิธีการหนึ่งที่ Just-In-Time (JIT) ซึ่งเป็นกลยุทธ์ที่องค์กรใช้เพื่อควบคุมค่าใช้จ่ายสินค้าคงคลัง Kanban กลายเป็นเครื่องมือที่มีประสิทธิภาพในการสนับสนุนระบบการผลิตโดยรวมและพิสูจน์แล้วว่าเป็นวิธีที่ยอดเยี่ยมในการส่งเสริมการปรับปรุง

สรุป

ในช่วง 10 ปีที่ผ่านมามีเรื่องราวความสำเร็จจำนวนมากขึ้นเรื่อย ๆ โดย บริษัท ต่างๆได้ปรับปรุงความสำเร็จและประสิทธิภาพของทีมพัฒนาไอทีและโครงการต่างๆด้วยแนวทางปฏิบัติที่คล่องตัว สิ่งนี้ทำให้เกิดความคล่องตัวในการนำไปใช้อย่างกว้างขวางในหลากหลายอุตสาหกรรมรวมถึงสื่อและเทคโนโลยีองค์กรขนาดใหญ่และแม้แต่รัฐบาล

Agile Framework ช่วยให้ทีมได้รับประโยชน์จาก:

เวลาในการส่งมอบ / ตลาดเร็วขึ้น
ลดความไม่แน่นอนและความเสี่ยง
เพิ่มผลตอบแทนจากการลงทุน (ROI) โดยมุ่งเน้นที่มูลค่าของลูกค้า

ท่ามกลางวิธีการที่คล่องตัวที่แตกต่างกันนี้ Scrum ได้พิสูจน์แล้วว่าประสบความสำเร็จอย่างมากทั่วโลกในช่วง 20 ปีที่ผ่านมา

Scrum เป็นกรอบในการพัฒนาและสนับสนุนผลิตภัณฑ์ที่ซับซ้อน Ken Schwaber และ Jeff Sutherland พัฒนา Scrum พวกเขายืนอยู่เบื้องหลังกฎการต่อสู้ร่วมกัน

นิยามการต่อสู้

การต่อสู้เป็นกรอบที่ผู้คนสามารถแก้ไขปัญหาการปรับตัวที่ซับซ้อนได้ในขณะที่นำเสนอผลิตภัณฑ์ที่มีมูลค่าสูงสุดเท่าที่เป็นไปได้อย่างมีประสิทธิผลและสร้างสรรค์

Scrum เป็นกรอบกระบวนการที่ใช้ในการจัดการการพัฒนาผลิตภัณฑ์ที่ซับซ้อนตั้งแต่ต้นทศวรรษ 1990 Scrum ไม่ใช่กระบวนการหรือเทคนิคในการสร้างผลิตภัณฑ์ แต่เป็นกรอบที่คุณสามารถใช้กระบวนการและเทคนิคต่างๆ Scrum ทำให้ชัดเจนถึงประสิทธิภาพสัมพัทธ์ของแนวทางปฏิบัติในการจัดการและพัฒนาผลิตภัณฑ์ของคุณเพื่อให้คุณสามารถปรับปรุงได้

กรอบการทำงานของ Scrum ประกอบด้วยทีม Scrum และบทบาทที่เกี่ยวข้องเหตุการณ์สิ่งประดิษฐ์และกฎต่างๆ แต่ละองค์ประกอบภายในเฟรมเวิร์กมีจุดประสงค์เฉพาะและจำเป็นต่อความสำเร็จและการใช้งานของ Scrum

กฎของการต่อสู้ผูกมัดเหตุการณ์บทบาทและสิ่งประดิษฐ์เข้าด้วยกันควบคุมความสัมพันธ์และปฏิสัมพันธ์ระหว่างพวกเขา กฎของการต่อสู้อธิบายไว้ตลอดบทช่วยสอนนี้

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

กรอบกระบวนการต่อสู้

ใน Scrum เหตุการณ์ที่กำหนดจะถูกใช้เพื่อสร้างความสม่ำเสมอ เหตุการณ์ทั้งหมดเป็นเหตุการณ์ที่กำหนดเวลาดังนั้นทุกเหตุการณ์จะมีระยะเวลาสูงสุด มีการอธิบายเหตุการณ์อย่างละเอียดมากขึ้นในบทต่อ ๆ ไป

วิ่ง

หัวใจสำคัญของ Scrum คือ Sprint ซึ่งเป็นกล่องเวลาสองสัปดาห์หรือหนึ่งเดือนในระหว่างที่มีการสร้างส่วนเพิ่มผลิตภัณฑ์ที่อาจส่งต่อได้ Sprint ใหม่เริ่มต้นทันทีหลังจากสรุป Sprint ก่อนหน้านี้ Sprints ประกอบด้วยการวางแผน Sprint การต่อสู้ประจำวันงานพัฒนาการทบทวน Sprint และการย้อนหลัง Sprint

ในการวางแผน Sprint งานที่จะดำเนินการใน Sprint ได้รับการวางแผนร่วมกันโดยทีม Scrum
การประชุม Daily Scrum เป็นกิจกรรมแบบแบ่งเวลา 15 นาทีสำหรับทีม Scrum เพื่อซิงโครไนซ์กิจกรรมและสร้างแผนสำหรับวันนั้น
Sprint Review จะจัดขึ้นที่ส่วนท้ายของ Sprint เพื่อตรวจสอบส่วนเพิ่มและทำการเปลี่ยนแปลงใน Backlog ของผลิตภัณฑ์หากจำเป็น
Sprint Retrospective เกิดขึ้นหลังจาก Sprint Review และก่อนการวางแผน Sprint ถัดไป ในการประชุมครั้งนี้ทีม Scrum จะต้องตรวจสอบตัวเองและสร้างแผนสำหรับการปรับปรุงเพื่อประกาศใช้ในช่วง Sprint ที่ตามมา

สรุป

การต่อสู้เป็นกรอบกระบวนการที่กำหนดกฎเกณฑ์เหตุการณ์และบทบาทบางอย่างเพื่อทำให้เกิดความสม่ำเสมอ อย่างไรก็ตามสามารถปรับให้เข้ากับองค์กรใดก็ได้ตามความต้องการหากไม่ละเมิดกฎการต่อสู้ขั้นพื้นฐาน

ทีม Scrum ประกอบด้วยสามบทบาท ได้แก่ ScrumMaster เจ้าของผลิตภัณฑ์และทีม

ScrumMaster

ScrumMaster (บางครั้งเขียนว่า Scrum Master แม้ว่าคำอย่างเป็นทางการจะไม่มีช่องว่างหลัง "Scrum") เป็นผู้ดูแลกระบวนการต่อสู้ เขา / เธอเป็นผู้รับผิดชอบ -

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

เจ้าของผลิตภัณฑ์

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

เจ้าของผลิตภัณฑ์เป็นผู้รับผิดชอบในการจัดการ Backlog ของผลิตภัณฑ์ แต่เพียงผู้เดียว การจัดการสินค้าค้างส่งประกอบด้วย -

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

เจ้าของผลิตภัณฑ์อาจทำงานข้างต้นหรือให้ทีมงานดำเนินการ อย่างไรก็ตามเจ้าของผลิตภัณฑ์ยังคงรับผิดชอบงานเหล่านี้

เจ้าของผลิตภัณฑ์คือบุคคลหนึ่งคนไม่ใช่คณะกรรมการ เจ้าของผลิตภัณฑ์อาจแสดงถึงความต้องการของคณะกรรมการใน Backlog ของผลิตภัณฑ์ แต่ผู้ที่ต้องการเปลี่ยนลำดับความสำคัญของสินค้าที่ค้างอยู่ในผลิตภัณฑ์ต้องอยู่ที่เจ้าของผลิตภัณฑ์

เพื่อให้เจ้าของผลิตภัณฑ์ประสบความสำเร็จทั้งองค์กรต้องเคารพการตัดสินใจของตน การตัดสินใจของเจ้าของผลิตภัณฑ์สามารถมองเห็นได้ในเนื้อหาและลำดับของ Backlog ของผลิตภัณฑ์ ไม่มีใครได้รับอนุญาตให้บอกให้ทีมทำงานจากข้อกำหนดที่แตกต่างกันและทีมไม่ได้รับอนุญาตให้ดำเนินการตามที่คนอื่นพูด สิ่งนี้ได้รับการรับรองโดย ScrumMaster

ทีมงาน

ทีมมีการจัดระเบียบตนเองและทำงานข้ามสายงาน นั่นหมายความว่าทีมงานประกอบด้วยนักวิเคราะห์นักออกแบบนักพัฒนาผู้ทดสอบ ฯลฯ ตามความเหมาะสมและเกี่ยวข้องกับโครงการ

คนในวงการบางคนเรียกทีมนี้ว่าทีมพัฒนา อย่างไรก็ตามการอ้างอิงดังกล่าวนำไปสู่การโต้เถียงว่าทีมสามารถมีได้เฉพาะนักพัฒนาและไม่มีบทบาทอื่น ๆ เป็นความเข้าใจที่ชัดเจนว่าเป็นเพียงความเข้าใจผิดเท่านั้น ในการพัฒนาผลิตภัณฑ์ซอฟต์แวร์เราต้องการบทบาททั้งหมดและนั่นคือหัวใจสำคัญของการต่อสู้ - ทีมจะทำงานร่วมกัน ทีมข้ามสายงานมีความสามารถทั้งหมดที่จำเป็นในการทำงานให้สำเร็จโดยไม่ต้องขึ้นอยู่กับคนอื่น ๆ ที่ไม่ใช่ส่วนหนึ่งของทีมดังนั้นจึงสามารถประหยัดเวลาและความพยายามได้ รูปแบบทีมใน Scrum ได้รับการออกแบบมาเพื่อเพิ่มความยืดหยุ่นความคิดสร้างสรรค์และประสิทธิผล

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

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

ScrumMaster เป็นผู้รับผิดชอบที่ได้รับการฝึกอบรมซึ่งให้บริการตามที่อธิบายไว้ด้านล่าง -

บริการ ScrumMaster แก่เจ้าของผลิตภัณฑ์

ScrumMaster ให้บริการเจ้าของผลิตภัณฑ์ในหลาย ๆ ด้าน ได้แก่ -

หาเทคนิคในการจัดการ Product Backlog ที่มีประสิทธิภาพ
ช่วยให้ทีม Scrum เข้าใจถึงความต้องการรายการสินค้าค้างส่งที่ชัดเจนและรัดกุม
การทำความเข้าใจการวางแผนผลิตภัณฑ์ในสภาพแวดล้อมเชิงประจักษ์
ตรวจสอบให้แน่ใจว่าเจ้าของผลิตภัณฑ์รู้วิธีการจัดเรียง Backlog ของผลิตภัณฑ์เพื่อเพิ่มมูลค่าสูงสุด
ทำความเข้าใจและฝึกฝนความคล่องตัว
การอำนวยความสะดวกในการต่อสู้ตามความจำเป็น

บริการ ScrumMaster แก่ทีม Scrum

ScrumMaster ให้บริการทีม Scrum ในหลายวิธี ได้แก่ -

การฝึกสอนทีม Scrum ในองค์กรตนเองและข้ามฟังก์ชันการทำงาน
ช่วยทีม Scrum ในการสร้างผลิตภัณฑ์ที่มีมูลค่าสูง
ขจัดอุปสรรคต่อความคืบหน้าของทีม Scrum
การอำนวยความสะดวกในกิจกรรม Scrum ตามที่ร้องขอหรือจำเป็น
การฝึกสอนทีม Scrum ในสภาพแวดล้อมขององค์กรที่ Scrum ยังไม่ได้รับการยอมรับและเข้าใจอย่างเต็มที่

บริการ ScrumMaster ให้กับองค์กร

ScrumMaster ให้บริการองค์กรในหลายวิธี ได้แก่ -

เป็นผู้นำและฝึกสอนองค์กรในการนำ Scrum มาใช้
การวางแผนการใช้ Scrum ภายในองค์กร
ช่วยให้พนักงานและผู้มีส่วนได้ส่วนเสียเข้าใจและบังคับใช้ Scrum และการพัฒนาผลิตภัณฑ์เชิงประจักษ์
ก่อให้เกิดการเปลี่ยนแปลงที่เพิ่มผลผลิตของ Scrum Team
การทำงานร่วมกับ ScrumMasters อื่น ๆ เพื่อเพิ่มประสิทธิภาพของการประยุกต์ใช้ Scrum ในองค์กร

สรุป

Scrum Process Framework สามารถดูได้โดยใช้ลำดับของเหตุการณ์และสิ่งประดิษฐ์ที่เกี่ยวข้อง เหตุการณ์ Scrum เป็นเหตุการณ์ที่กำหนดเวลาไว้ นั่นหมายความว่าในโปรเจ็กต์เหตุการณ์การต่อสู้ทุกครั้งจะมีระยะเวลาสูงสุดที่กำหนดไว้ล่วงหน้า เหตุการณ์เหล่านี้ทำให้เกิดความโปร่งใสในความคืบหน้าของโครงการสำหรับทุกคนที่มีส่วนร่วมในโครงการ เหตุการณ์สำคัญของการต่อสู้คือ -

Sprint
การวางแผน Sprint
การประชุมการต่อสู้รายวัน
รีวิว Sprint
Sprint Retrospective

Sprint

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

Sprint Goal เป็นเป้าหมายที่กำหนดไว้สำหรับ Sprint ให้คำแนะนำแก่ทีมว่าเหตุใดจึงสร้าง Increment สร้างขึ้นในระหว่างการประชุมการวางแผน Sprint ขอบเขตของการวิ่งจะได้รับการชี้แจงและมีการเจรจาอีกครั้งระหว่างเจ้าของผลิตภัณฑ์และทีมงานเมื่อได้เรียนรู้เพิ่มเติมเกี่ยวกับข้อกำหนดแล้ว ดังนั้นแต่ละ Sprint จึงมีความเกี่ยวข้องกันคำจำกัดความของสิ่งที่จะสร้างการออกแบบและแผนยืดหยุ่นที่จะเป็นแนวทางในการสร้างงานการพัฒนาและการเพิ่มผลิตภัณฑ์ที่เป็นผลลัพธ์

ควรยกเลิก Sprint หาก Sprint Goal ล้าสมัย สิ่งนี้อาจเกิดขึ้นหากองค์กรเปลี่ยนทิศทางหรือหากเงื่อนไขของตลาดหรือเทคโนโลยีเปลี่ยนไป เจ้าของผลิตภัณฑ์สามารถยกเลิกการวิ่งได้เท่านั้นแม้ว่าคนอื่น ๆ จะมีอิทธิพลต่อสิ่งเดียวกัน

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

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

การวางแผน Sprint

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

Sprint Planning มุ่งเน้นไปที่สองคำถามต่อไปนี้ -

สิ่งที่ต้องมีและสามารถส่งมอบได้ใน Sprint Increment?
งานที่จำเป็นสำหรับการเรียกใช้ Sprint จะบรรลุผลได้อย่างไร?

ข้อมูลสำหรับการประชุมนี้คือ -

สินค้าค้างส่ง
ผลิตภัณฑ์ใหม่ล่าสุดที่เพิ่มขึ้น
ความสามารถที่คาดการณ์ไว้ของทีมในช่วง Sprint
ผลงานที่ผ่านมาของทีม

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

จากนั้นทีม Scrum จะมาพร้อมกับ Sprint Goal Sprint Goal เป็นวัตถุประสงค์ที่ให้คำแนะนำแก่ทีมว่าเหตุใดจึงสร้าง Product Increment จากนั้นทีมจะตัดสินใจว่าจะสร้างฟังก์ชันการทำงานที่เลือกไว้ในผลิตภัณฑ์ที่ใช้งานได้อย่างไรในระหว่าง Sprint รายการ Backlog ของผลิตภัณฑ์ที่เลือกสำหรับ Sprint นี้รวมทั้งแผนการส่งมอบเรียกว่า Sprint Backlog

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

ทีมอาจเชิญผู้อื่น (ไม่ใช่ส่วนหนึ่งของ Scrum Team) เข้าร่วมการประชุม Sprint Planning เพื่อรับคำแนะนำด้านเทคนิคหรือโดเมนหรือความช่วยเหลือในการประมาณค่า

การประชุมการต่อสู้รายวัน

การประชุม Daily Scrum คือการประชุม 15 นาทีสำหรับทีมซึ่งจัดทำทุกวันเพื่อทำความเข้าใจงานอย่างรวดเร็วตั้งแต่การประชุม Daily Scrum ครั้งสุดท้ายและสร้างแผนสำหรับ 24 ชั่วโมงถัดไป การประชุมนี้เรียกอีกอย่างว่าการประชุมประจำวัน

การประชุม Daily Scrum จัดขึ้นในเวลาเดียวกันและสถานที่เดียวกันทุกวันเพื่อลดความซับซ้อน

ในระหว่างการประชุมสมาชิกในทีมแต่ละคนจะอธิบาย -

เมื่อวานนี้เขาทำอะไรเพื่อช่วยให้ทีมบรรลุเป้าหมาย Sprint
เขาจะทำอะไรในวันนี้เพื่อช่วยให้ทีมบรรลุเป้าหมาย Sprint
เขาเห็นอุปสรรคใด ๆ ที่ทำให้เขาหรือทีมไม่สามารถบรรลุเป้าหมาย Sprint ได้หรือไม่?

Daily Scrum ถูกเข้าใจผิดว่าเป็นเหตุการณ์การติดตามสถานะแม้ว่าในความเป็นจริงมันเป็นเหตุการณ์การวางแผน

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

แม้ว่า Scrum Master จะประสานงานการประชุม Daily Scrum และทำให้มั่นใจว่าบรรลุวัตถุประสงค์ของการประชุม แต่การประชุมถือเป็นความรับผิดชอบของทีม

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

ต่อไปนี้เป็นประโยชน์ของ Daily Scrum Meetings -

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

รีวิว Sprint

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

โดยปกติการทบทวน Sprint จะจัดขึ้นเป็นเวลาสองชั่วโมงสำหรับการวิ่งสองสัปดาห์และสี่ชั่วโมงสำหรับการวิ่งหนึ่งเดือน

Scrum Master ช่วยให้มั่นใจได้ว่า -

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

Sprint Review ประกอบด้วยประเด็นต่อไปนี้ -

ผู้เข้าร่วมประกอบด้วยทีม Scrum และผู้มีส่วนได้ส่วนเสียหลักตามที่เจ้าของผลิตภัณฑ์เชิญ
เจ้าของผลิตภัณฑ์อธิบายว่ารายการค้างของผลิตภัณฑ์ใดที่เสร็จสมบูรณ์ในระหว่างการวิ่งและสิ่งที่ยังไม่เสร็จสมบูรณ์
ทีมงานจะพูดถึงสิ่งที่ทำได้ดีในระหว่าง Sprint ปัญหาที่พบและวิธีแก้ไขปัญหาเหล่านั้น
ทีมงานแสดงให้เห็นถึงการทำงานที่เสร็จสมบูรณ์และตอบคำถามเกี่ยวกับส่วนเพิ่ม (ถ้ามี)
จากนั้นทั้งกลุ่มจะคุยกันว่าจะทำอย่างไรต่อไป ดังนั้น Sprint Review จึงให้ข้อมูลที่มีค่าสำหรับ Sprint Planning ของ Sprint ที่ตามมา
จากนั้นทีม Scrum จะตรวจสอบไทม์ไลน์งบประมาณความสามารถที่เป็นไปได้และตลาดสำหรับการเพิ่มผลิตภัณฑ์ที่คาดว่าจะเปิดตัวครั้งต่อไป
ผลลัพธ์ของ Sprint Review คือ Product Backlog ที่อัปเดตซึ่งกำหนดรายการ Backlog ของผลิตภัณฑ์ที่เป็นไปได้สำหรับ Sprint ถัดไป

Sprint Retrospective

Sprint Retrospective เกิดขึ้นหลังจาก Sprint Review และก่อนการวางแผน Sprint ถัดไป โดยปกติจะเป็นการประชุมหนึ่งชั่วโมงสำหรับการวิ่งระยะเวลาสองสัปดาห์และการประชุมสามชั่วโมงสำหรับ Sprints ระยะเวลาหนึ่งเดือน

วัตถุประสงค์ของ Sprint Retrospective คือ -

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

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

Reference

Scrum Artifacts ให้ข้อมูลสำคัญที่ทีม Scrum และผู้มีส่วนได้ส่วนเสียต้องรับทราบเพื่อทำความเข้าใจเกี่ยวกับผลิตภัณฑ์ที่อยู่ระหว่างการพัฒนากิจกรรมที่ทำและกิจกรรมที่วางแผนไว้ในโครงการ สิ่งประดิษฐ์ต่อไปนี้กำหนดไว้ใน Scrum Process Framework -

สินค้าค้างส่ง
Sprint Backlog
แผนภูมิเบิร์นดาวน์
Increment

สิ่งเหล่านี้เป็นสิ่งประดิษฐ์ขั้นต่ำที่จำเป็นในโครงการต่อสู้และสิ่งประดิษฐ์ของโครงการไม่ได้ถูก จำกัด ด้วยสิ่งเหล่านี้

สินค้าค้างส่ง

Backlog ของผลิตภัณฑ์คือรายการคุณลักษณะตามลำดับที่จำเป็นเป็นส่วนหนึ่งของผลิตภัณฑ์ขั้นสุดท้ายและเป็นแหล่งเดียวของข้อกำหนดสำหรับการเปลี่ยนแปลงใด ๆ กับผลิตภัณฑ์

Backlog ของผลิตภัณฑ์จะแสดงคุณสมบัติฟังก์ชันข้อกำหนดการปรับปรุงและการแก้ไขทั้งหมดที่เป็นการเปลี่ยนแปลงที่จะทำกับผลิตภัณฑ์ในรุ่นต่อ ๆ ไป รายการสินค้าค้างส่งมีคุณลักษณะของคำอธิบายคำสั่งซื้อการประมาณและมูลค่า โดยปกติรายการเหล่านี้เรียกว่าเรื่องราวของผู้ใช้ เจ้าของผลิตภัณฑ์ต้องรับผิดชอบต่อ Backlog ของผลิตภัณฑ์รวมถึงเนื้อหาความพร้อมใช้งานและการสั่งซื้อ

Backlog ของผลิตภัณฑ์คือสิ่งประดิษฐ์ที่มีการพัฒนา เวอร์ชันแรกสุดอาจมีเฉพาะข้อกำหนดที่ทราบและเข้าใจดีที่สุดในตอนแรกเท่านั้น Backlog ของผลิตภัณฑ์ได้รับการพัฒนาเป็นผลิตภัณฑ์และสภาพแวดล้อมที่จะใช้ความคืบหน้า Backlog ของผลิตภัณฑ์มีการเปลี่ยนแปลงตลอดเวลาเพื่อรวมสิ่งที่จำเป็นเพื่อให้มีประสิทธิภาพ ตราบเท่าที่มีผลิตภัณฑ์อยู่สินค้า Backlog ของผลิตภัณฑ์ก็มีอยู่เช่นกัน

เนื่องจากผลิตภัณฑ์ที่สร้างขึ้นถูกใช้และได้รับมูลค่า Backlog ของผลิตภัณฑ์จะกลายเป็นรายการที่ใหญ่ขึ้นและครบถ้วนมากขึ้น การเปลี่ยนแปลงข้อกำหนดทางธุรกิจเงื่อนไขทางการตลาดหรือเทคโนโลยีทำให้เกิดการเปลี่ยนแปลงใน Backlog ของผลิตภัณฑ์ทำให้เป็นสิ่งประดิษฐ์ที่ใช้งานได้จริง

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

รายการสินค้าค้างส่งสามารถอัปเดตได้ตลอดเวลาโดยเจ้าของผลิตภัณฑ์หรือตามดุลยพินิจของเจ้าของผลิตภัณฑ์

รายการสินค้าค้างส่งที่สั่งซื้อสูงมักจะชัดเจนและมีรายละเอียดมากกว่ารายการที่สั่งซื้อต่ำกว่า การประมาณการที่แม่นยำยิ่งขึ้นจะขึ้นอยู่กับความชัดเจนและรายละเอียดที่เพิ่มขึ้น ยิ่งลำดับต่ำรายละเอียดก็จะยิ่งน้อยลง

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

Sprint Backlog

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

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

Sprint Backlog เป็นแผนที่มีรายละเอียดเพียงพอที่สามารถเข้าใจได้ แต่ทีมจะติดตามใน Daily Scrum ทีมแก้ไข Sprint Backlog ตลอดทั้ง Sprint และ Sprint Backlog จะปรากฏขึ้นในระหว่าง Sprint การเกิดขึ้นนี้เกิดขึ้นเมื่อทีมทำงานตามแผนและเรียนรู้เพิ่มเติมเกี่ยวกับงานที่จำเป็นในการบรรลุเป้าหมาย Sprint

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

เพิ่มขึ้น

Increment คือผลรวมของรายการ Backlog ของผลิตภัณฑ์ที่เสร็จสมบูรณ์ในระหว่าง Sprint รวมกับการเพิ่มของ Sprint ก่อนหน้าทั้งหมด ในตอนท้ายของ Sprint ส่วนเพิ่มใหม่จะต้องเป็นผลิตภัณฑ์ที่ใช้งานได้ซึ่งหมายความว่าจะต้องอยู่ในสภาพที่ใช้งานได้ ผลิตภัณฑ์จะต้องอยู่ในสภาพใช้งานได้ไม่ว่าเจ้าของผลิตภัณฑ์จะตัดสินใจปล่อยผลิตภัณฑ์จริงหรือไม่

ทีม Scrum จำเป็นต้องมีฉันทามติเกี่ยวกับสิ่งที่ถือว่าเป็นส่วนเพิ่ม สิ่งนี้จะแตกต่างกันอย่างมีนัยสำคัญในแต่ละทีม Scrum แต่สมาชิกในทีมต้องมีความเข้าใจร่วมกันว่าการทำงานให้เสร็จสมบูรณ์หมายความว่าอย่างไร ใช้เพื่อประเมินเมื่องานเสร็จสมบูรณ์ในส่วนเพิ่มผลิตภัณฑ์

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

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

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

เมื่อ Scrum Teams เติบโตเต็มที่คาดว่าคำจำกัดความของ Increments จะขยายออกไปเพื่อรวมเกณฑ์ที่เข้มงวดมากขึ้นเพื่อคุณภาพที่สูงขึ้น ผลิตภัณฑ์ใดผลิตภัณฑ์หนึ่งควรมีคำจำกัดความของ Increment ซึ่งเป็นมาตรฐานสำหรับงานใด ๆ ที่ทำ

แผนภูมิเบิร์นดาวน์ Sprint

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

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

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

สรุป

บทบาทเหตุการณ์สิ่งประดิษฐ์และกฎของ Scrum เป็นสิ่งที่หลีกเลี่ยงไม่ได้ หากใช้เพียงบางส่วนของ Scrum ผลลัพธ์จะไม่ใช่ Scrum การต่อสู้จะต้องดำเนินการอย่างครบถ้วนและทำงานได้ดีหากสอดคล้องกับเทคนิควิธีการและแนวทางปฏิบัติอื่น ๆ

Reference

ตามที่คุณเข้าใจแล้ว User Stories มักใช้เพื่ออธิบายคุณสมบัติของผลิตภัณฑ์และจะเป็นส่วนหนึ่งของ Scrum Artifacts - Product Backlog และ Sprint Backlog.

เรื่องราวของผู้ใช้

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

ในปี 2542 Kent Beck มีคำว่า User Stories สำหรับคุณลักษณะของผลิตภัณฑ์ เขาอธิบายว่าเรื่องราวของผู้ใช้ถูกบรรยายจากมุมมองของผู้ใช้เกี่ยวกับสิ่งที่เขาหรือเธอต้องการแทนที่จะเป็นสิ่งที่ระบบสามารถทำเพื่อเขาได้ ดังนั้นมุมมองจึงเปลี่ยนจากผลิตภัณฑ์เป็นผู้ใช้โดยสิ้นเชิงและเรื่องราวของผู้ใช้กลายเป็นมาตรฐานสำหรับข้อกำหนดในกรอบ Agile ทั้งหมดโดยพฤตินัย

ในโปรเจ็กต์ Scrum Product Backlog คือรายการเรื่องราวของผู้ใช้ เรื่องราวของผู้ใช้เหล่านี้ได้รับการจัดลำดับความสำคัญและนำไปไว้ใน Sprint Backlog ในการประชุมวางแผน Sprint

การประมาณยังขึ้นอยู่กับเรื่องราวของผู้ใช้และขนาดของผลิตภัณฑ์จะถูกประมาณใน User Story Points

โครงสร้างเรื่องราวของผู้ใช้

โครงสร้าง User Story มีดังนี้ -

ในฐานะที่เป็น<ประเภทของผู้ใช้> ,

ฉันต้องการ<การดำเนินการบางงาน> ,

เพื่อให้<I สามารถบรรลุเป้าหมายบาง / ประโยชน์ / ค่า>

ให้เรามาดูว่าเรื่องราวของผู้ใช้ถูกจัดทำขึ้นอย่างไรสำหรับสถานการณ์ที่ลูกค้าธนาคารถอนเงินสดจากตู้ ATM

เรื่องราวของผู้ใช้: การถอนเงินสดของลูกค้า

ในฐานะที่เป็น Customer,

ฉันต้องการ withdraw cash from an ATM,

ดังนั้น I don't have to wait in line at the Bank

เกณฑ์การยอมรับเรื่องราวของผู้ใช้

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

ต่อไปนี้เป็นเกณฑ์การยอมรับตัวอย่างสำหรับตัวอย่าง User Story การถอนเงินสดของลูกค้า

Acceptance Criterion 1:

Given ว่าบัญชีนั้นมีความน่าเชื่อถือ

และบัตรถูกต้อง
และตู้มีเงินสด

When ลูกค้าขอเงินสด

Then ตรวจสอบให้แน่ใจว่าบัญชีถูกหัก

และตรวจสอบให้แน่ใจว่ามีการจ่ายเงินสด
และตรวจสอบให้แน่ใจว่ามีการคืนบัตร

Acceptance Criterion 2:

Given บัญชีถูกถอนออกไป

และบัตรถูกต้อง

When ลูกค้าขอเงินสด

Then ตรวจสอบให้แน่ใจว่าข้อความปฏิเสธปรากฏขึ้น

และตรวจสอบให้แน่ใจว่าไม่มีการจ่ายเงินสด
และตรวจสอบให้แน่ใจว่ามีการคืนบัตร

การเขียนเรื่องราวของผู้ใช้

เจ้าของผลิตภัณฑ์ต้องรับผิดชอบต่อ Backlog ของผลิตภัณฑ์และทำให้เกิดเรื่องราวของผู้ใช้ อย่างไรก็ตามไม่ได้หมายความว่าเจ้าของผลิตภัณฑ์เท่านั้นที่เขียนเรื่องราวของผู้ใช้ ทุกคนในทีม Scrum สามารถเขียนเรื่องราวของผู้ใช้ได้และสามารถกระจายกิจกรรมไปทั่วทั้งโครงการได้เมื่อความต้องการได้รับการปรับปรุงและเพิ่มฟังก์ชันการทำงานใหม่ ๆ

ข้อกำหนดที่ไม่ใช้งานได้ในเรื่องราวของผู้ใช้

เป็นไปได้ที่จะรวมข้อกำหนดที่ใช้งานไม่ได้ไว้ในเรื่องราวของผู้ใช้ด้วย ในตัวอย่าง ATM ที่ระบุตู้ ATM ที่จะพร้อมใช้งานสำหรับผู้ใช้ 24X7, 365 วันเป็นข้อกำหนดที่ไม่สามารถใช้งานได้ซึ่งสามารถอธิบายได้ด้วยกรณีการใช้งาน

การจัดการเรื่องราวของผู้ใช้

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

ประโยชน์จากเรื่องราวของผู้ใช้

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

สรุป

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

โดยปกติแล้วการติดตามการวิ่งจะทำได้โดยใช้แผนภูมิเบิร์นดาวน์ แผนภูมิเบิร์นดาวน์แสดงความพยายามที่เหลืออยู่ในจำนวนชั่วโมงที่ชาญฉลาดในแต่ละวัน ตัวอย่างเช่นให้เราพิจารณาการวิ่ง 2 สัปดาห์ -

Sprint Duration: 2 สัปดาห์

No. of Days per Week: 5

No. of Hrs. per Day: 6

No. of Resources: 6

ดังนั้นความพยายามทั้งหมดที่เหลือในช่วงเริ่มต้นของการวิ่งคือ 2 * 5 * 6 * 6 = 360 ชม.

ดังนั้นในสถานการณ์ที่ดีงาน 36 ชั่วโมงจะลดลงในงานที่เหลือและแผนภูมิเบิร์นดาวน์มีลักษณะดังนี้ -

ถ้างานวิ่งเสร็จตามแผนที่วางไว้ทุกวันความคืบหน้าในการต่อสู้ก็เกือบจะสอดคล้องกับแถบที่เหมาะ

หากงานวิ่งล่าช้าและไม่เป็นไปตามความมุ่งมั่นของเวลาแผนภูมิเบิร์นดาวน์จะมีลักษณะดังนี้ -

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

ดังนั้นเมื่อใดก็ตามใน Sprint งานทั้งหมดที่เหลืออยู่ใน Sprint สามารถมองเห็นได้และความเป็นไปได้ในการประชุมเส้นเวลาการวิ่งสามารถปรับปรุงได้

สรุป

แผนภูมิเบิร์นดาวน์ช่วยทีม Scrum ในการติดตามความคืบหน้าและสิ่งที่ต้องทำเพื่อให้บรรลุเป้าหมายการวิ่ง

ในโครงการ Scrum การประเมินจะกระทำโดยทั้งทีมในระหว่างการประชุมวางแผน Sprint วัตถุประสงค์ของการประมาณการคือการพิจารณาเรื่องราวของผู้ใช้สำหรับ Sprint ตามลำดับความสำคัญและตามความสามารถของทีมที่จะส่งมอบในช่วง Time Box ของ Sprint

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

เนื่องจากทีม Scrum เป็นผู้รับผิดชอบในการส่งมอบผลิตภัณฑ์ที่เพิ่มขึ้นทั้งหมดจึงควรใช้ความระมัดระวังในการเลือกเรื่องราวของผู้ใช้สำหรับ Sprint โดยพิจารณาจากขนาดของ Product Increment และความพยายามที่จำเป็นสำหรับสิ่งเดียวกัน

ขนาดของการเพิ่มผลิตภัณฑ์ถูกประมาณในแง่ของ User Story Points เมื่อกำหนดขนาดได้แล้วความพยายามจะประมาณโดยใช้ข้อมูลในอดีตกล่าวคือความพยายามต่อ User Story Point เรียกว่า Productivity

เทคนิคการประมาณค่าการแย่งชิง

การประมาณค่าการแย่งชิงเรื่องราวของผู้ใช้นั้นอยู่ในแง่ของระดับความยากสำหรับเรื่องราวของผู้ใช้แต่ละคน ในการประเมินระดับความยากจะใช้มาตราส่วนเฉพาะ

มีเครื่องชั่งหลายประเภทที่ใช้ใน Scrum Estimation ต่อไปนี้เป็นตัวอย่างบางส่วน -

การปรับขนาดตัวเลข (1 ถึง 10)
ขนาดเสื้อยืด (XS, S, M, L, XL XXL, XXXL)
ลำดับฟีโบนักชี (1, 2, 3, 5, 8, 13, 21, 34 ฯลฯ )
สายพันธุ์สุนัข (ชิวาวา………เกรทเดน)

โดยปกติเทคนิคการประมาณจะถูกเลือกในลักษณะที่ทีมต่อสู้ทั้งหมดคุ้นเคยและคุ้นเคยกับค่าของมาตราส่วน เทคนิคที่ใช้กันมากที่สุดและเป็นที่นิยมมากที่สุดคือ Planning Poker ซึ่งเป็นไปตามลำดับ Fibonacci

เทคนิคการวางแผนโป๊กเกอร์

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

Planning Poker เล่นด้วยสำรับไพ่ เมื่อใช้ลำดับฟีโบนักชีการ์ดจะมีตัวเลข - 1, 2, 3, 5, 8, 13, 21, 34 เป็นต้นตัวเลขเหล่านี้แสดงถึงคะแนนเรื่องราว ตัวประมาณแต่ละคนมีสำรับไพ่ ตัวเลขบนการ์ดควรมีขนาดใหญ่พอที่สมาชิกในทีมทุกคนจะมองเห็นได้เมื่อสมาชิกในทีมคนใดคนหนึ่งถือไพ่

สมาชิกในทีมคนใดคนหนึ่งถูกเลือกให้เป็นผู้ดูแล โมเดอเรเตอร์อ่านคำอธิบายของเรื่องราวของผู้ใช้ที่มีการประมาณค่า หากผู้ประมาณมีคำถามใด ๆ เจ้าของผลิตภัณฑ์จะตอบคำถามเหล่านี้

ตัวประมาณแต่ละคนจะเลือกการ์ดที่แสดงค่าประมาณของตนโดยส่วนตัว การ์ดจะไม่แสดงจนกว่าตัวประมาณทั้งหมดจะทำการเลือก ในเวลานั้นการ์ดทั้งหมดจะถูกพลิกและถือขึ้นพร้อมกันเพื่อให้สมาชิกในทีมทุกคนสามารถดูการประมาณแต่ละครั้งได้

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

ทีมสามารถพูดคุยเกี่ยวกับเรื่องราวและประมาณการของพวกเขาได้อีกไม่กี่นาที

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

ทำซ้ำขั้นตอนจนกว่าค่าประมาณจะรวมเป็นค่าประมาณเดียวที่สามารถใช้สำหรับเรื่องราวได้ จำนวนรอบของการประมาณค่าอาจแตกต่างกันไปในแต่ละเรื่องราวของผู้ใช้

ประโยชน์ของการวางแผนการประมาณโป๊กเกอร์

การวางแผนโป๊กเกอร์รวมวิธีการประมาณสามวิธี -

Expert Opinion: ในแนวทางการประเมินตามความคิดเห็นของผู้เชี่ยวชาญผู้เชี่ยวชาญจะถูกถามว่าจะใช้เวลานานแค่ไหนหรือจะใหญ่แค่ไหน ผู้เชี่ยวชาญให้การประมาณโดยอาศัยประสบการณ์หรือสัญชาตญาณหรือความรู้สึกทางเดินอาหารของเขาหรือเธอ

การประมาณความคิดเห็นของผู้เชี่ยวชาญมักใช้เวลาไม่มากและแม่นยำกว่าเมื่อเทียบกับวิธีการวิเคราะห์บางวิธี

Analogy: Analogy Estimation ใช้การเปรียบเทียบเรื่องราวของผู้ใช้ เรื่องราวของผู้ใช้ภายใต้การประมาณจะเปรียบเทียบกับเรื่องราวของผู้ใช้ที่คล้ายกันซึ่งดำเนินการก่อนหน้านี้ ผลลัพธ์นี้ได้ผลลัพธ์ที่ถูกต้องเนื่องจากการประมาณขึ้นอยู่กับข้อมูลที่พิสูจน์แล้ว

Disaggregation: Disaggregation Estimation ทำได้โดยการแบ่งเรื่องราวของผู้ใช้ออกเป็นเรื่องราวของผู้ใช้ที่เล็กลงและง่ายต่อการประเมิน เรื่องราวของผู้ใช้ที่จะรวมอยู่ใน Sprint โดยปกติจะอยู่ในช่วงสองถึงห้าวันในการพัฒนา ดังนั้นเรื่องราวของผู้ใช้ที่อาจใช้เวลานานกว่านั้นจำเป็นต้องแบ่งออกเป็น Use Case ขนาดเล็ก วิธีนี้ยังช่วยให้มั่นใจได้ว่าจะมีเรื่องราวมากมายที่เทียบเคียงได้

สรุป

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

Scrum Tools ช่วยอำนวยความสะดวกในการวางแผนและติดตามโครงการ Scrum พวกเขาเป็นที่เดียวสำหรับการจัดการสินค้าค้างส่งงานในมือของ Sprint การวางแผนและการติดตาม Sprints การแสดงแผนภูมิ Burndown การประชุม Scrum ประจำวันและการดำเนินการ Scrum Retrospectives

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

เครื่องมือ Scrum ที่มีอยู่

ต่อไปนี้เป็นรายการเครื่องมือ Scrum ที่มีจำหน่ายในตลาด ณ วันนั้น เครื่องมือโอเพนซอร์สมีเครื่องหมายดอกจัน

Axosoft	Airgile	ห้องนักบิน Agile	จิระ (GreenHopper)	มั่วสุม
Scrumwise	Agilo สำหรับการต่อสู้	กล้วยหอม	คุนางิ	OnTime Now
เวอร์ชันหนึ่ง	AgileWrap	การต่อสู้รายวัน	ช่วงเวลา	Pango Scrum
Acunote	เครื่องมือติดตาม Agile *	Digaboard *	iMeta Agility	Pivotal Tracker
วาระที่คล่องตัว	งาน Agile	EasyBacklog	การต่อสู้น้ำแข็ง *	pmScrum
ม้านั่งแบบ Agile	ซุปเปรียว	อธิบาย PMT	Hansoft	Prj Planner
Agile Buddy	ผู้จัดการเปรียว	Agile Express *	GravityDev	การ์ดโครงการ
แฟนเปรียว *	บันทึก Agile	ไฟไหม้ *	ศูนย์กลาง*	ควอนตัมกระซิบ
การต่อสู้อย่างรวดเร็ว	Retrospectiva *	Scrum'd	โรงงาน Scrum *	Scrumpy
Rally Dev	รอยขีดข่วน *	แดชบอร์ดการต่อสู้ *	Scrum Edge	Scrum Pad
Redmine Backlogs	Scrum 2 Go	โต๊ะต่อสู้	Scrum Do	ทวีต Scrum
Scrumrf	เวลาต่อสู้ *	Scrumwise	เลือก Solution Factory	ต่อสู้ *
เต่าในเมือง	ScrumTool	Scrum Works	Timebox	Tangy Orange Scrum

สรุป

โดยทั่วไป Agile การต่อสู้เฉพาะไม่ได้หมายความว่าไม่มีงานเอกสาร มีการกำหนด Scrum Artifacts การวางแผนและการติดตามการต่อสู้ได้รับการยอมรับอย่างดี

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

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

ประโยชน์ต่อลูกค้า

Sprints มีระยะเวลาสั้นกว่าและมีการจัดลำดับความสำคัญเรื่องราวของผู้ใช้ในทุกการวางแผนการวิ่ง ช่วยให้มั่นใจได้ว่าในการส่งมอบทุกครั้งจะมีการรวมคุณลักษณะตามที่ลูกค้าต้องการไว้ในทันที นอกจากนี้หากลูกค้าแจ้งขอเปลี่ยนแปลงใด ๆ ก็จะถูกดูดซับในการวิ่งปัจจุบันหรือรวมอยู่ในการวิ่งครั้งต่อไป ดังนั้นทีมพัฒนาจึงตอบสนองความต้องการของลูกค้าได้อย่างรวดเร็ว

ประโยชน์ต่อองค์กร

องค์กรสามารถมุ่งเน้นไปที่ความพยายามที่จำเป็นสำหรับการพัฒนาเรื่องราวของผู้ใช้ที่จัดลำดับความสำคัญและลดค่าใช้จ่ายและการทำงานซ้ำ เนื่องจากผลประโยชน์เฉพาะของการต่อสู้กับลูกค้าประสิทธิภาพที่เพิ่มขึ้นของทีมพัฒนาความพึงพอใจของลูกค้าและด้วยเหตุนี้การรักษาลูกค้าและการอ้างอิงลูกค้าจึงเป็นไปได้ เป็นการเพิ่มศักยภาพทางการตลาดขององค์กร

ประโยชน์ต่อผู้จัดการผลิตภัณฑ์

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

ประโยชน์ต่อผู้จัดการโครงการ

ผู้จัดการโครงการมีบทบาทเป็น Scrum Master ในโครงการ ลักษณะการทำงานร่วมกันของ Scrum ช่วยให้สามารถวางแผนและติดตามได้ง่ายและเป็นรูปธรรม การใช้ Burndown Charts เพื่อทำความเข้าใจงานที่เหลือและการประชุม Daily Scrum ทำให้ผู้จัดการโครงการรับรู้เกี่ยวกับสถานะของโครงการตลอดเวลา การรับรู้นี้มีความสำคัญต่อการตรวจสอบโครงการและเพื่อการจับและแก้ไขปัญหาอย่างรวดเร็ว

ประโยชน์ต่อทีมพัฒนา

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

การรับรองการต่อสู้มีให้โดย Scrum Alliance กำลังเสนอใบรับรองต่อไปนี้ -

ScrumMaster ที่ผ่านการรับรอง (CSM)
เจ้าของผลิตภัณฑ์ Scrum ที่ผ่านการรับรอง (CSPO)
Certified Scrum Practitioner (CSP)
โค้ช Scrum ที่ผ่านการรับรอง (CSC)
Certified Scrum Trainer (CST)

ScrumMaster ที่ผ่านการรับรอง (CSM)

Certified Scrum Master คือการรับรองขั้นพื้นฐานในการเป็นสมาชิกของ Scrum Alliance เล่น Scrum Master Role และมีสิทธิ์ได้รับการรับรองอื่น ๆ การรับรองต้องเข้าร่วมหลักสูตร CSM หลังจากนั้นผู้สมัครจะได้รับอีเมลระบุรายละเอียดการเป็นสมาชิก Scrum และการตรวจสอบ CSM ออนไลน์ หลังจากการสอบผู้สมัครจะได้รับการรับรอง Certified ScrumMaster (CSM)

เจ้าของผลิตภัณฑ์ Scrum ที่ผ่านการรับรอง (CSPO)

Certified Scrum Product Owner คือการรับรองขั้นพื้นฐานในการเป็นสมาชิกของ Scrum Alliance เล่นบทบาทของ Product Owner และมีสิทธิ์ได้รับการรับรองอื่น ๆ

Certified Scrum Practitioner (CSP)

Certified Scrum Practitioner คือการรับรองสำหรับ ScrumMasters ที่มีประสบการณ์และเจ้าของผลิตภัณฑ์ ผู้สมัครควรเป็น ScrumMaster หรือเจ้าของผลิตภัณฑ์เป็นเวลาอย่างน้อยหนึ่งปี ผู้สมัครจะต้องส่งใบสมัครที่มีคำอธิบายโดยละเอียดเกี่ยวกับสิ่งที่เขาหรือเธอทำในบทบาทที่ระบุ

เป็นไปได้ที่ผู้สมัครจะได้รับการรับรอง CSP ทันทีหลังจากที่ได้รับการรับรอง CSM หรือการรับรอง CSPO หากผู้สมัครกำลังฝึกฝนบทบาทของ ScrumMaster หรือบทบาทของเจ้าของผลิตภัณฑ์ในระยะเวลาที่กำหนด

โค้ช Scrum ที่ผ่านการรับรอง (CSC)

Certified Scrum Coach คือการรับรองสำหรับผู้ที่มุ่งเน้นไปที่การฝึกสอน การรับรองกำหนดให้ผู้สมัครต้องฝึกสอนทีม Scrum ผ่านการนำไปใช้และความเชี่ยวชาญในการต่อสู้เป็นเวลาอย่างน้อย 1,500 ชั่วโมงในช่วง 5 ปีที่ผ่านมา

Certified Scrum Trainer (CST)

Certified Scrum Trainer คือการรับรองสำหรับผู้ที่ต้องการสอน CSM หรือ CSPO ผู้สมัครจะต้องมี CSM หรือ CSPO และควรเป็น CSP อย่างน้อยหนึ่งปีก่อนที่จะสมัคร

ต่อไปนี้เป็นคำถามที่พบบ่อยเกี่ยวกับ Scrum -

Question: What is the difference between Scrum and Agile Development?

Answer : Agile Development เป็นวิธีการของซอฟต์แวร์ในขณะที่ Scrum เป็นหนึ่งในกรอบกระบวนการที่เป็นไปตาม Agile

Question: Are Sprints and Iterations the same?

Answer: ทั้ง Sprints of Scrum และการทำซ้ำของ Iterative Incremental model ช่วยเพิ่มการทำงานของผลิตภัณฑ์ อย่างไรก็ตามสิ่งเหล่านี้แตกต่างกันตรงที่:

วงจรชีวิตของ Sprint และการวนซ้ำแตกต่างกัน
Sprints เป็นไทม์บ็อกซ์ในขณะที่การทำซ้ำไม่ใช่
ระยะเวลาของ Sprints น้อยกว่ามากเมื่อเทียบกับระยะเวลาของการทำซ้ำ

Question: Is Scrum Master a job title or a role that someone with an existing job title fills?

Answer: Scrum Master เป็นบทบาทที่ผู้ที่มีตำแหน่งงานกรอก การปฏิบัติตามปกติคือบุคคลที่มีบทบาทเป็นผู้จัดการโครงการจะมีบทบาทของ ScrumMaster ด้วยเช่นกัน

Question: Can Product Owner and ScrumMaster’s roles be played by the same person?

Answer: ไม่เนื่องจากความเป็นเจ้าของแตกต่างกัน Product Owner ดูแล Product Backlog การจัดลำดับความสำคัญของเรื่องราวของผู้ใช้และการตรวจสอบความถูกต้องของการเพิ่มขึ้นของผลิตภัณฑ์ที่ใช้งานได้กับเรื่องราวของผู้ใช้ที่จัดสรรให้กับ Sprint

Question: Is it that Scrum Projects need not have any Documentation?

Answer : ไม่โครงการ Scrum เช่นเดียวกับโครงการอื่น ๆ จำเป็นต้องมีเอกสารประกอบเช่นเรื่องราวของผู้ใช้การออกแบบกรณีทดสอบเป็นต้น

สรุป

Agile และ Scrum ไม่เหมือนกัน Scrum เป็นหนึ่งในกรอบกระบวนการที่ปรับ Agile แนะนำให้ใช้ Scrum กับทีมที่มีสมาชิกในทีมที่มีประสบการณ์เนื่องจาก Framework ต้องการการทำงานร่วมกันที่ดีเยี่ยมและการจัดองค์กรด้วยตนเองเช่นกัน หากไม่ปฏิบัติตามกฎ Scrum อย่างเคร่งครัดโครงการอาจนำไปสู่ความล้มเหลว ดังนั้นจึงจำเป็นต้องมีความเข้าใจอย่างถูกต้องเกี่ยวกับแนวคิดการต่อสู้ระหว่างทีมทั้งหมด เนื่องจาก Sprints มีระยะเวลาสั้นและเป็นไทม์บ็อกซ์จึงไม่มีเวลาเรียนรู้ข้อมูลเฉพาะของ Scrum ในงานแม้ว่า Scrum Master จะตรวจสอบโครงการอย่างต่อเนื่อง