พิมพ์เขียวการจัดการโครงการ ตอนที่ 1: การเปรียบเทียบที่ครอบคลุมของ Agile, Scrum, Kanban และ Lean

ภาพรวม

ปัจจุบันมีการใช้วิธีการมากมายในการพัฒนาซอฟต์แวร์ คุณอาจเคยได้ยินคำศัพท์ต่างๆ เช่น Waterfall, Agile, Scrum, Kanban, Lean, Extreme Programming เป็นต้น

ในบทความนี้ ผมจะนิยามคำศัพท์เหล่านี้ อภิปรายว่าคำเหล่านี้เกี่ยวข้องกันอย่างไร และมีความแตกต่างกันอย่างไร คำศัพท์ดังกล่าวจำนวนมากมีพื้นฐานมาจากแนวคิดจากการผลิตแบบลีนซึ่งเดิมมีพื้นฐานมาจากระบบการผลิตของโตโยต้า (TPS) ดังนั้นเราจะมาพูดถึงเรื่องนี้กันก่อน

วิธีการแบบลีน

ที่มาของการผลิตแบบลีนและแบบลีน

คำว่า "Lean" มีต้นกำเนิดมาจากการผลิต ซึ่งได้รับการประกาศเกียรติคุณเพื่ออธิบายรูปแบบการผลิตตามระบบการผลิตของโตโยต้า (TPS) ที่พัฒนาโดย Sakichi Toyoda, Kiichiro Toyoda และ Taiichi Ohno ซึ่งเดิมได้รับแรงบันดาลใจจาก Henry Ford TPS มุ่งเน้นไปที่ปรัชญา "การกำจัดของเสียทั้งหมดโดยสิ้นเชิง" และปฏิวัติการผลิตในช่วงทศวรรษ 1950 ถึง 1970 TPS กลายเป็นที่รู้จักในชื่อ "Lean Manufacturing" ในปี 1990 เมื่อ "The Machine That Changed the World" ได้รับการตีพิมพ์

TPS ระบุขยะสามประเภทกว้างๆ ที่ Toyota:

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

  • การประมวลผลส่วนเกิน: จากการใช้เครื่องมือหรือการออกแบบผลิตภัณฑ์ที่ไม่ดี

• Muri: แปลว่า "ภาระหนักเกินไป" มูริมักเป็นผลจากมูระ แต่เป็นผลจากมูดะได้ Muri ปรากฏตัวในความพัง, การขาดงาน, ปัญหาด้านความปลอดภัย ฯลฯ
• Mura: แปลว่า "ความไม่สม่ำเสมอ" สามารถพบได้ในความผันผวนในความต้องการของลูกค้า เวลาดำเนินการต่อผลิตภัณฑ์ หรือการเปลี่ยนแปลงของรอบเวลาสำหรับผู้ปฏิบัติงานที่แตกต่างกัน เมื่อมูระไม่ลดลง เราเพิ่มความเป็นไปได้ของมูริและดังนั้น มูดะ สามารถลด Mura ได้โดยการสร้างการเปิดกว้างในห่วงโซ่อุปทาน การเปลี่ยนแปลงการออกแบบผลิตภัณฑ์ และสร้างงานมาตรฐานสำหรับผู้ปฏิบัติงานทุกคน

TPS ทำงานเพื่อกำจัดของเสียโดยใช้แนวคิดหลักสองประการนี้:

• จิโดกะ: แปลง่ายๆ ว่า "การทำงานอัตโนมัติด้วยการสัมผัสของมนุษย์" กำหนดว่า "คุณภาพต้องสร้างขึ้นในระหว่างกระบวนการผลิต!" ซึ่งหมายความว่าเมื่อเกิดปัญหา อุปกรณ์จะหยุดทันที ป้องกันไม่ให้มีการผลิตสินค้าที่บกพร่อง
• Just-in-Time: สร้างเฉพาะ “สิ่งที่จำเป็น เมื่อจำเป็น และในปริมาณที่ต้องการ”

เมื่อ TPS พัฒนาขึ้น เสาหลักและค่านิยมเหล่านี้สร้างจากแนวคิดของ Jidoka และ JIT และกลายเป็นสิ่งที่ยึดเหนี่ยว:

• พัฒนาอย่างต่อเนื่อง:
  • ท้าทาย: สร้างวิสัยทัศน์ระยะยาวและเผชิญกับความท้าทายด้วยความกล้าหาญและความคิดสร้างสรรค์เพื่อบรรลุความฝัน
  • ไคเซ็น: ปรับปรุงการดำเนินธุรกิจอย่างต่อเนื่อง ขับเคลื่อนนวัตกรรมและวิวัฒนาการอยู่เสมอ ขจัดโคลนออกทีละตัว
  • เก็นจิ เก็นบุตสึ: ฝึกเก็นจิเก็นบุตสึ ไปที่แหล่งที่มาเพื่อค้นหาข้อเท็จจริงเพื่อตัดสินใจอย่างถูกต้อง สร้างฉันทามติ และบรรลุเป้าหมายด้วยความเร็วสูงสุด
• ความเคารพต่อผู้คน:
  • เคารพ: เคารพ ผู้อื่น พยายามเข้าใจซึ่งกันและกัน รับผิดชอบ และทำให้ดีที่สุดเพื่อสร้างความไว้วางใจซึ่งกันและกัน
  • การทำงานเป็นทีม: กระตุ้นการเติบโตส่วนบุคคลและในอาชีพ การแบ่งปันโอกาสในการพัฒนา และการเพิ่มประสิทธิภาพของบุคคลและทีม
• Andon: ตัวบ่งชี้สถานะหรือปัญหาที่มองเห็นได้
• Heijunka: หมายถึงการปรับระดับหรือการปรับระดับการผลิต
• Hansei : หมายถึงการทบทวนตัวเอง เพื่อปรับปรุงประสิทธิภาพ พนักงานควรท้าทายสมมติฐานที่อยู่เบื้องหลังกระบวนการปัจจุบันเพื่อค้นหาสิ่งที่ดีกว่า
• Kanban: ป้ายที่ใช้เป็นเครื่องมือในการควบคุมการผลิต
• Poka-yoke: เรียกอีกอย่างว่าการพิสูจน์ข้อผิดพลาดหรือการพิสูจน์ข้อผิดพลาด
• ระบบดึง: วัสดุถูกดึงเข้าสู่เวิร์กสเตชันตามความจำเป็น
• เซริ : เป็นหลักการที่สะท้อนของเสีย เซริบอกให้เอาของที่ไม่จำเป็นออกไป ซึ่งรวมถึงของเสียดั้งเดิมทั้งเจ็ดของ TPS
• มาตรฐาน: จัดระเบียบงานทั้งหมดเกี่ยวกับการเคลื่อนไหวของมนุษย์และสร้างลำดับการผลิตที่มีประสิทธิภาพโดยไม่ต้องใช้โคลน ซึ่งจะช่วยนำไปสู่คุณภาพ ก้าวที่สม่ำเสมอ และช่วยให้มีการปรับปรุงอย่างต่อเนื่อง

แผนภาพด้านล่างแสดงให้เห็นว่าแนวคิดหลักและค่านิยมหลักมีความสัมพันธ์กันอย่างไร

การจัดการแบบลีน

ระบบผลิตภัณฑ์ของโตโยต้าและการผลิตแบบ Lean Manufacturing พัฒนาขึ้นเมื่อเวลาผ่านไป และถูกนำไปใช้ในหลายด้านรวมถึงการจัดการ

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

1. ระบุมูลค่า: ระบุค่าจากจุดยืนของลูกค้าปลายทางตามตระกูลผลิตภัณฑ์
2. Map Value Stream: ระบุขั้นตอนทั้งหมดในสายธารคุณค่าสำหรับผลิตภัณฑ์แต่ละตระกูล กำจัดขั้นตอนที่ไม่สร้างมูลค่าทุกครั้งที่ทำได้
3. Create Flow: ทำให้ขั้นตอนการสร้างมูลค่าเกิดขึ้นเป็นลำดับ เพื่อให้ผลิตภัณฑ์ไหลไปสู่ลูกค้าได้อย่างราบรื่น
4. สร้างการดึง: เมื่อมีการแนะนำโฟลว์ ให้ลูกค้าดึงคุณค่าจากกิจกรรมต้นน้ำถัดไป
5. แสวงหาความสมบูรณ์แบบ: เมื่อมีการระบุค่า กระแสคุณค่าจะถูกระบุ ขั้นที่สูญเปล่าจะถูกลบออก และแนะนำการไหลและการดึง เริ่มกระบวนการอีกครั้งและดำเนินต่อไปจนกว่าจะถึงสภาวะของความสมบูรณ์แบบซึ่งสร้างมูลค่าที่สมบูรณ์แบบโดยไม่เสียเปล่า

หลักการเหล่านี้และแง่มุมอื่นๆ ของการจัดการแบบลีนถูกทำให้เป็นทางการเมื่อ Womack & Jones ตีพิมพ์ “Lean Thinking” ในปี 1996

การพัฒนาซอฟต์แวร์แบบลีน

ตั้งแต่นั้นมา Lean ก็ถูกนำไปใช้กับการจัดการ การพัฒนาซอฟต์แวร์ และสาขาอื่นๆ

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

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

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

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

ในทศวรรษ 1990 และต้นทศวรรษ 2000 ผู้เขียนหลายคนได้ตีพิมพ์หนังสือเกี่ยวกับการใช้หลักการแบบลีนในการพัฒนาซอฟต์แวร์ Dr. Robert Charette ตีพิมพ์ “Lean Software Development” ในปี 1993 และ “12 Principles of Lean Software Development” ในปี 2003

Tom และ Mary Poppendieck ตีพิมพ์ “Lean Software Development: An Agile Toolkit” ในปี 2546 หนังสือเล่มนี้ให้รายละเอียดเกี่ยวกับหลักการ 7 ประการของการพัฒนาแบบ Lean ซึ่งสัมพันธ์โดยตรงกับขยะ 7 รูปแบบในการผลิตแบบ Lean ความเหมือนและความแตกต่างระหว่างสิ่งพิมพ์แบบ Lean ทั้งสองแบบและแบบ Agile (จะกล่าวถึงในหัวข้อถัดไป) ได้แสดงไว้ในแผนภาพด้านล่าง

ความแตกต่างระหว่าง Lean และ Agile

ตามที่ Dr. Charette กล่าว หนึ่งในความแตกต่างหลักระหว่าง Lean และ Agile ก็คือ Agile จะอยู่จากล่างขึ้นบน ในขณะที่ Lean อยู่จากบนลงล่าง

กรอบงานเปรียว

ที่มาของ Agile และ Agile Manifesto

ในช่วงเวลาเดียวกับที่ Charette และ Poppendiecks ตีพิมพ์หนังสือของพวกเขา Agile Framework ถูกสร้างขึ้นเพื่อช่วยแก้ปัญหาเดียวกัน ในเดือนกุมภาพันธ์ 2544 กลุ่มผู้บุกเบิก Agile ได้พบกันที่การประชุม Snowbird อันโด่งดังใน Snowbird รัฐ Utah เพื่อพยายามหาวิธีแก้ปัญหา

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

แถลงการณ์ Agile อ่านดังนี้:

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

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

นั่นคือถึงแม้สิ่งของทางด้านขวาจะมีมูลค่า แต่เราให้คุณค่ากับสิ่งของทางซ้ายมากกว่า”

สอดคล้องกับค่านิยมในแถลงการณ์คือหลักการ 12 ประการที่อยู่เบื้องหลังแถลงการณ์ Agile:

“เราปฏิบัติตามหลักการเหล่านี้:

1. ความสำคัญสูงสุดของเราคือสร้างความพึงพอใจให้กับลูกค้าด้วยการส่งมอบซอฟต์แวร์ที่มีคุณค่าตั้งแต่เนิ่นๆ และต่อเนื่อง
2. ยินดีต้อนรับความต้องการที่เปลี่ยนแปลง แม้จะอยู่ในช่วงการพัฒนาก็ตาม กระบวนการที่คล่องตัวใช้ประโยชน์จากการเปลี่ยนแปลงเพื่อความได้เปรียบในการแข่งขันของลูกค้า
3. ส่งมอบซอฟต์แวร์ที่ใช้งานได้เป็นประจำ ตั้งแต่สองสามสัปดาห์ถึงสองเดือน โดยชอบใช้ช่วงเวลาที่สั้นกว่า
4. นักธุรกิจและนักพัฒนาต้องทำงานร่วมกันทุกวันตลอดโครงการ
5. สร้างโครงการเกี่ยวกับบุคคลที่มีแรงบันดาลใจ มอบสภาพแวดล้อมและการสนับสนุนที่พวกเขาต้องการ และไว้วางใจให้พวกเขาทำงานให้เสร็จลุล่วง
6. วิธีที่มีประสิทธิภาพและประสิทธิผลมากที่สุดในการถ่ายทอดข้อมูลไปยังและภายในทีมพัฒนาคือการสนทนาแบบเห็นหน้ากัน
7. ซอฟต์แวร์ทำงานเป็นตัวชี้วัดความก้าวหน้าหลัก กระบวนการที่คล่องตัวส่งเสริมการพัฒนาที่ยั่งยืน
8. สปอนเซอร์ นักพัฒนา และผู้ใช้ควรจะสามารถรักษาระดับอย่างต่อเนื่องไม่มีกำหนด
9. การเอาใจใส่ความเป็นเลิศทางเทคนิคอย่างต่อเนื่องและการออกแบบที่ดีช่วยเพิ่มความคล่องตัว
10. ความเรียบง่าย—ศิลปะในการเพิ่มปริมาณงานที่ไม่ได้ทำ—เป็นสิ่งสำคัญ
11. สถาปัตยกรรม ข้อกำหนด และการออกแบบที่ดีที่สุดมาจากทีมที่จัดการกันเอง
12. ในช่วงเวลาปกติ ทีมงานจะไตร่ตรองถึงวิธีการที่จะมีประสิทธิภาพมากขึ้น จากนั้นจึงปรับแต่งและปรับพฤติกรรมตามนั้น”

ค่านิยมและหลักการข้างต้นเป็นการนำหลักการแบบลีนมาใช้ เช่น Jidoka, JIT, Genchi Genbutsu, Kaizen, Hansei, Heijunka และการลดของเสีย

หลักการ Agile ที่ใช้กับการพัฒนาซอฟต์แวร์

Agile คือกรอบงานแบบร่มที่ใช้กับกระบวนการใดๆ ก็ตามที่ใช้ชุดค่านิยมและหลักการของ Agile

ตัวอย่างบางส่วน ได้แก่ :

• Extreme Programming
• Scrum
• คัมบัง

Scrum

ประวัติโดยย่อของขยะ

Scrum เป็นกรอบการทำงานที่ใช้หลักการ Agile ที่คิดค้นโดยคนหลายคนแยกกัน ซึ่งหลายคนลงนามใน Agile Manifesto:

• ฮิโรทากะ ทาเคอุจิ และ อิคุจิโระ โนนากะ ได้แนะนำคำว่า "การต่อสู้" ในบริบทการผลิตในสมุดปกขาวเรื่อง "เกมการพัฒนาผลิตภัณฑ์ใหม่" ตีพิมพ์ในปี 1986 ใน Harvard Business Review
• Jeff Sutherland, John Scumniotales และ Jeff McKenna ใช้งาน Scrum ที่ Easel Corporation ในปี 1993
• Ken Schwaber ใช้สิ่งที่จะกลายเป็น Scrum ในบริษัทของเขา นั่นคือ Advanced Development Methods ในปี 1990

Schwaber และ Sutherland ร่วมมือกันตลอดช่วงทศวรรษ 1990 เพื่อพัฒนาและปรับแต่งกรอบงานในบริบทการพัฒนาซอฟต์แวร์ โดยพูดในการประชุมต่างๆ Schwaber ทำงานร่วมกับ Mike Beedle เพื่ออธิบายวิธีการในหนังสือ "Agile Software Development with Scrum" ในปี 2544

Schwaber ได้สร้างหน่วยงานออกใบรับรอง Scrum หลักทั้งสองแห่งต่อไป:

• Scrum Alliance: สร้างขึ้นในปี 2001 ตั้งค่าชุดการ รับรอง Scrum ที่ผ่านการรับรอง
• Scrum.org: สร้างขึ้นในปี 2009 หลังจาก Schwaber ออกจาก Scrum Alliance ตั้งค่าชุดการรับรอง Professional Scrum แบบคู่ขนาน

เมื่อเวลาผ่านไป เฟรมเวิร์ก/หน่วยรับรองต่างๆ ถูกสร้างขึ้นเพื่อจัดการกับการปรับขนาดของเฟรมเวิร์ก Scrum สำหรับทีมและโครงการที่ใหญ่กว่า เนื่องจาก Scrum ได้รับการออกแบบมาสำหรับทีมขนาดเล็ก (7 บวกหรือลบ 2 สมาชิก):

• ปลอดภัย: Scaled Agile Framework
• น้อยกว่า: Scrum ขนาดใหญ่
• Scrum@scale: Scrum at Scale สร้างสรรค์โดย Jeff Sutherland

ค่าการต่อสู้

ตาม Scrum Alliance:

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

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

ภาพรวมการต่อสู้

งานจะถูกแบ่งออกเป็นการทำซ้ำในช่วงเวลาสั้น ๆ ที่เรียกว่า sprints ซึ่งโดยปกติคือ 1-3 สัปดาห์ ตรงกันข้ามกับการวางแผนเชิงลึกของน้ำตกโดยสิ้นเชิง งานที่วางแผนไว้สำหรับ Sprint ปัจจุบันจะถูกเลือกจากด้านบนของรายการงานค้างที่มีลำดับความสำคัญสูงที่เรียกว่า Product Backlog (ระบบดึง, Heijunka) และจะได้รับการแก้ไขเมื่อเริ่มการวิ่ง เป้าหมายคือการมีซอฟต์แวร์ที่ใช้งานได้เมื่อสิ้นสุดการวิ่งแต่ละครั้ง ซึ่งช่วยให้ตอบสนองได้อย่างรวดเร็ว

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

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

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

แผนผังความคิดด้านล่างแสดงแนวคิดหลักบางประการของ Scum ซึ่งจะกล่าวถึงในหัวข้อต่อไป

บทบาทการต่อสู้

Scrum มีสามบทบาท:

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

Scrum Flow กิจกรรมและพิธีการ

ตามที่กล่าวไว้ข้างต้น Scrum มีโฟลว์ที่กำหนดไว้และชุดของพิธีกรรมและกิจกรรมต่างๆ การไหลของการวิ่งเป็นดังนี้

การวางแผนการวิ่ง:

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

โดยปกติจะทำกับกิจกรรมต่อไปนี้:

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

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

การดำเนินการวิ่ง

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

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

ในแต่ละวัน Scrum Master มุ่งเน้นไปที่:

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

สแตนด์อัพรายวัน

ในช่วงเริ่มต้นของแต่ละวันในการวิ่ง Scrum Master จะอำนวยความสะดวกในการประชุมสั้นๆ 15 นาทีกับทีม scrum และเจ้าของผลิตภัณฑ์เพื่อวางแผนในแต่ละวันและทบทวนความคืบหน้าของการวิ่ง นี่คือการประชุมสั้นๆ ที่ทุกคนยืนอยู่หน้า Scrum Board และแต่ละคนในการประชุมจะตอบคำถามต่อไปนี้ภายใน 2 นาทีหรือน้อยกว่า โดยอ้างอิงถึงรายการเฉพาะบนกระดาน sprint:

• เมื่อวานคุณทำอะไร?
• วันนี้คุณวางแผนจะทำอะไร
• มีสิ่งกีดขวางใด ๆ ที่ขัดขวางไม่ให้คุณทำงานให้เสร็จหรือไม่?

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

วิ่งเสร็จ

Scrum Master อำนวยความสะดวกในพิธีสองรายการในการปิดการวิ่งก่อนที่จะวางแผนการวิ่งครั้งต่อไป

สาธิตการวิ่ง

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

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

Sprint Retrospective

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

มีการสร้างรายการของรายการการดำเนินการปรับปรุงและบางครั้งส่งผลให้มีการเพิ่มรายการลงในรายการในมือ การเปลี่ยนแปลง DoD หรือกฎบัตรของทีม ฯลฯ

การจัดการ Backlog ของผลิตภัณฑ์

การสร้าง Backlog ของผลิตภัณฑ์

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

Backlog กรูมมิ่ง

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

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

การประเมินจุดเรื่องราว

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

มาตราส่วน Fibonacci (1, 2, 3, 5, 8, 13, 21…) เป็นมาตราส่วนที่ใช้บ่อยที่สุด โดยที่การเพิ่มขึ้นแต่ละครั้งจะใหญ่เป็นสองเท่าโดยประมาณก่อนหน้านี้ (กล่าวคือ เรื่องราวห้าจุดมีมากหรือน้อยกว่าสองเท่าของ ใหญ่เท่าเรื่องสามจุด) บางครั้งอาจใช้เกล็ดอื่นๆ เช่น ขนาดเสื้อยืด (XS, S, M, L, XL) หรือแม้แต่ปลา (ปลาซิว ปลาทอง ปลาเทราท์ ปลาทูน่า วาฬ ฯลฯ) มาตราส่วนใดๆ ที่ยอมให้คุณเปรียบเทียบขนาดของบางสิ่งที่สัมพันธ์กับขนาดอื่นจะได้ผล

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

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

การประมาณค่า Story point ทำได้ระหว่างการประชุมและบางครั้งในระหว่างการวางแผนการวิ่งโดยใช้ Planning Poker:

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

ข้อดีของการประมาณจุดเรื่องราวคือ:

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

ปล่อยการประเมินและการติดตาม

การประเมินประเด็นเรื่องยังใช้ในบริบทการวางแผนการเปิดตัวโดยใช้เทคนิคต่อไปนี้:

1. รายชื่อเรื่องราวทั้งหมดที่จะปรับขนาด
2. เรียงจากน้อยไปหามาก
   • ใช้เรื่องราวของผู้ใช้ครั้งแรกและครั้งที่สอง
   • ตัดสินใจว่าอันไหนใหญ่กว่าและใส่อันที่ใหญ่กว่าไว้ด้านล่าง
   • จากนั้นใช้อันต่อไปและตัดสินใจว่าจะพอดีกับอีกสองอันไหน
   • ทำซ้ำขั้นตอนจนกว่าเรื่องราวทั้งหมดจะอยู่ในรายการ (ในลำดับจากน้อยไปมาก)
3. ขนาดเรื่องราว

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

Scrum Artifacts และข้อกำหนด

• Product Backlog: รายการ Backlog ของรายการงานทั้งหมดสำหรับผลิตภัณฑ์ที่กำหนด ซึ่งอาจรวมถึงคุณลักษณะ (เรื่องราว) งานด้านเทคนิค จุดบกพร่อง และข้อบกพร่อง
• การเผาไหม้ของรีลีส: แผนภูมิกราฟิกที่ใช้เพื่อแสดงความคืบหน้าในระดับรีลีสและคาดการณ์เมื่อรีลีสจะเสร็จสิ้นโดยใช้ Sprint Velocity คะแนนเรื่องราวที่เสร็จสมบูรณ์จะแสดงบนแกน Y และการวิ่งแสดงบนแกน X
• Sprint Backlog: รายการงานค้างของรายการงานทั้งหมดที่ต้องทำใน Sprint ที่กำหนด เนื้อหาของงานที่ค้างสำหรับการวิ่งจะได้รับการตกลงในระหว่างการประชุมวางแผนการวิ่ง
• Scrum Board: กระดานรูปแบบตารางที่ติดตามความคืบหน้าของงานที่มอบหมายสำหรับการวิ่ง สถานะจะแสดงที่ด้านบนสุดในคอลัมน์แนวตั้ง และรายการงานจะถูกย้ายไปยังแต่ละสถานะจนกว่าจะเสร็จสิ้น กระดาน Scrum มีการเติมข้อมูลระหว่างการประชุมวางแผนการวิ่งและถูกรีเซ็ตเมื่อสิ้นสุดการวิ่ง
• Sprint Burndown: แผนภูมิกราฟิกที่แสดงจำนวนงานที่เสร็จสมบูรณ์และคงเหลือโดยวัดเป็นคะแนนเรื่องราวตลอดความยาวของการวิ่ง จุดเรื่องราวที่เหลือจะแสดงบนแกน Y และเวลาที่เหลือจะแสดงบนแกน X
• Sprint Velocity: จำนวนแต้มเรื่องราวที่ทีม Scrum ทำสำเร็จในการวิ่ง
• Impediments Backlog: รายการสิ่งกีดขวางที่ Scrum Master ต้องแก้ไขเพื่อให้ทีมสามารถทำงานได้ต่อไป เมื่อสมาชิกในทีมถูกบล็อก พวกเขาจะเพิ่มรายการไปยังอุปสรรคที่ค้างอยู่เพื่อให้ทีมและ Scrum Master มองเห็นได้
• มหากาพย์: มหากาพย์คืองานขนาดใหญ่ที่ประกอบด้วยเรื่องราวของผู้ใช้ที่เกี่ยวข้องหลายเรื่อง
• เรื่องราวของ ผู้ใช้: เรื่องราวของผู้ใช้คือคำอธิบายของคุณลักษณะซอฟต์แวร์จากมุมมองของผู้ใช้ปลายทาง เรื่องราวของผู้ใช้อธิบายประเภทของผู้ใช้ สิ่งที่พวกเขาต้องการ และเหตุผล เรื่องราวของผู้ใช้ช่วยสร้างคำอธิบายที่ง่ายขึ้นของข้อกำหนดและรวมถึงเกณฑ์การยอมรับ เรื่องราวของผู้ใช้สร้างและดูแลโดยเจ้าของผลิตภัณฑ์
• งาน: งานคือชิ้นงานที่ Scrum Master หรือสมาชิกในทีมป้อนซึ่งอาจเกี่ยวข้องโดยตรงหรือโดยอ้อมกับเรื่องราวของผู้ใช้ โดยทั่วไปแล้วจะเป็นลักษณะทางเทคนิคและจะรวมถึงเกณฑ์การยอมรับ
• Spike: Spike เป็นงานประเภทพิเศษที่ใช้เมื่อคุณต้องการวิจัย สร้างต้นแบบ และ/หรือสถาปนิก ก่อนที่คุณจะตัดสินใจได้ว่าจะใช้หรือประเมินเรื่องราวของผู้ใช้อย่างไร
• งานย่อย: งาน ย่อยคืองานที่ป้อนเป็นขั้นตอนการใช้งานเพื่อให้เรื่องราวของผู้ใช้หรืองานเสร็จสมบูรณ์ พวกเขามักจะป้อนโดยทีมในระหว่างการประชุมวางแผนการวิ่ง
• Story Point Estimates: มาตราส่วนการประมาณการขนาดสัมพัทธ์ที่ยึดตามมาตราส่วน Fibonacci (1, 2, 3, 5, 8, 13, 21…)
• เกณฑ์การยอมรับ: รายชื่อของเรื่องที่ทดสอบได้โดยเฉพาะซึ่งรวมอยู่ในทุกเรื่องที่ต้องทำให้เสร็จก่อนที่เจ้าของผลิตภัณฑ์จะยอมรับว่าเรื่องราวนั้นเสร็จสมบูรณ์
• คำจำกัดความของเสร็จสิ้น (DoD): รายการขั้นตอนหรือเกณฑ์ทั่วไปที่ต้องทำให้เสร็จก่อนจึงจะพิจารณาเรื่องราวใดๆ ได้ ทีมงานตกลงในเรื่องนี้และจัดทำเอกสารเพื่อไม่ให้มีรายชื่ออยู่ในทุกเรื่อง

ข้อดีและข้อเสียของ Scrum

ข้อได้เปรียบหลักของ Scrum คือการประยุกต์ใช้ค่านิยมและหลักการแบบ Agile ตลอดจนแนวคิดแบบ Lean เช่น Seiri, Jidoka, Just-in-Time, Kaizen, Genchi Genbutsu, Heijunka, Pull System และ Iterations Applying these principles allow project teams to receive continuous feedback, quickly adapt to changing requirements and uncertainty, reduce waste, increase visibility and transparency, and strive for continuous improvement. By always focusing on the most important items in the product backlog and only working in short iterations that always produce working software, Scrum is more customer focused and allows customers to see what they like (and don't like) and make changes as needed. The overhead cost in terms of process and management is smaller, thus leading to quicker, cheaper results.

Scrum is a great methodology for projects with requirements that are not clearly known and/or expected to change. This applies to most projects. Scrum is also great for experienced, motivated teams as it allows teams to organize the work themselves and it provides visibility, transparency, and accountability for both progress and problems. All of this will result in teams improving and becoming more productive over time.

Scrum does have some disadvantages and is not the best methodology in some situations:

• Transparency: Scrum increases transparency and accountability which is both an advantage and disadvantage as problems and poor performance within and outside the team and are exposed. This can be uncomfortable and can lead to resistance if not handled properly within the Scrum framework of continuous improvement.
• Team Experience and Commitment: Inexperienced and/or uncommitted Scrum teams or Scrum Masters can cause serious problems through misapplying the Scrum methodology. There are no defined roles in the Scrum team as everyone does everything, so it requires committed team members with technical experience to follow the Scrum process and improve over time. It can also be very detrimental if other parts of the organization are resistant to Scrum.
• Scope Creep: There is a risk of scope creep, especially if there isn't a defined end date as stakeholders are allowed to add to the scope. Being able to change scope and priorities is one of the main advantages of Scrum, but it can also be a disadvantage if discipline isn't used.
• Poorly defined work: Poorly defined and understood user stories or tasks can lead to rework, inaccurate estimates, and scope creep. Although Scrum is focused on working software over documentation, the product owner needs to be clear on what they want and be able to clearly communicate that in conversations and in the user stories.
• Scaling: Adopting the Scrum framework in large teams is challenging as Scrum is meant for smaller teams.

Kanban

What Is Kanban?

Kanban is a lighter weight process that applies many of the Lean and Agile values as well as a subset of the Scrum values and principles but there are also some fundamental differences. Kanban focuses on visualization, flow, and limiting work in progress.

Kanban is Japanese for “signboard” or “billboard.” Toyota line-workers used a kanban (ie, an actual board) to signal extra capacity in various steps in their manufacturing process. In software, this is done with a Kanban board, which is very similar to the Scrum board. There is a prioritized backlog of To Do items and vertical columns for each status that a work item can have. Like Scrum, work items are moved from one status to another; however, in Kanban, the amount of work in progress is strictly limited to a maximum number of items in each status based on team capacity. New work cannot be pulled in until existing work is moved to the next step in the process. In Scrum, work in progress in indirectly limited by controlling the amount of work planned for a sprint.

In Kanban, there are no fixed iterations or sprints, just a constant flow where work items are pulled from one stage to the next. This means that the Kanban board is never reset. It also means that many of the Scrum rituals not used. Kanban teams often have daily standup meetings but they are not prescribed. There are no regularly planned sprint planning meetings, sprint demos or sprint retrospectives, so the process is more lightweight. Some of the activities in those rituals may or may not be performed at an informal level. Continuous improvement is accomplished by tracking and analyzing the flow of items from one state to another and making constant incremental improvements based on what issues are uncovered.

Kanban also doesn't prescribe the roles that Scrum does. The only role needed is the team member role, however, there is often a project manager that manages the team and the backlog. Often a single Kanban board can serve multiple function based roles and/or teams that only work on items in a certain status. For example, a development team might pull items from To Do to In Progress and move them to Testing, and the test team might test items in Testing and move them to Done.

Many of the backlog management activities for prioritizing and grooming of work items still need to be done to ensure that a given work item is well understood and ready to be worked on, however, estimating the work items is prescribed as optional.

Kanban vs. Scrum

The following table compares Scrum and Agile:

Summary: The End of Part 1

In this part, we reviewed a few of the most popular methodologies used for Software Development. By now you should have a good understanding of Lean, Agile, Scrum, and Kanban and their historical roots in Lean Manufacturing and TPS. In the next part of the series, we will continue reviewing and comparing other Software Development methodologies such as Waterfall, JTBD, and SAFe (and other scaling frameworks), as well as hybrid methodologies, so you have all of them conveniently explained in one place.