Scrum Guide | 33. กระดาน Scruban และ Kanban ใน Scrum

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

กระดาน Scruban และ Kanban ใน Scrum – สารบัญ:

1. บทนำ
2. Kanban vs Scrum
3. บอร์ด Kanban ใน Scrum
4. สครัมบัน
5. สรุป

บทนำ

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

Kanban vs Scrum

วิธีการทำงานโดยรวมใน Kanban นั้นแตกต่างจาก Scrum เป็นหลักโดย นำวิธีการที่เป็นทางการน้อยกว่ามาใช้ ใน Kanban ไม่มีแนวทางโดยละเอียดเช่น การทำงานใน Sprints บทบาทของ Product Owner, Scrum Master และทีมพัฒนา สิ่งนี้เป็นไปได้เนื่องจาก Kanban มุ่งเน้นไปที่ความต่อเนื่องของงาน เช่น การให้บริการเฉพาะประเภท ซึ่งสามารถทำซ้ำได้มากกว่า และไม่ต้องการการวางแผนที่ซับซ้อนเช่นนี้

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

1. งานควรราบรื่นและไม่มีการหยุดทำงาน - ใน Scrum สิ่งนี้ทำได้โดยการสืบทอดอย่างต่อเนื่องของ Sprints ในขณะที่ใน Kanban งานจะดำเนินต่อไปเนื่องจากการไหลของงานอย่างราบรื่น พวกเขาสร้างคิวซึ่งนักพัฒนาเลือก (ดึง) งานสองสามอย่างให้เสร็จ
2. ทีมควรมุ่งเน้นเฉพาะงานที่เลือก - โดยใช้คำศัพท์ Kanban ทีมควร "ลดงานระหว่างทำ" ใน Scrum เทียบเท่ากับ User Stories ที่เลือกจาก Product Backlog เพื่อใส่ลงใน Sprint Backlog
3. ทุกคนที่เกี่ยวข้องควรมองเห็นความคืบหน้าของงานได้ - ใน Kanban จะแสดงเป็นภาพโดยกระดาน ซึ่งมักแสดงอยู่ใน Scrum Teams ด้วย

บอร์ด Kanban ใน Scrum

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

• ทำ
• กำลังดำเนินการ
• เสร็จสิ้น – ไปยังคอลัมน์สุดท้าย ไปที่งานที่ตรงตาม คำจำกัดความของความสมบูรณ์ ซึ่งเราเขียนไว้ที่นี่

ด้านล่างนี้ คุณจะพบตัวอย่าง บอร์ดคัมบังจากระบบการจัดการโครงการแบบ ครบวงจร – Firmbee.com

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

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

สครัมบัน

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

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

เมื่อทำงานใน Scruban งานจะไม่แบ่งออกเป็น Sprints การประชุม Scrum จะจัดขึ้นทุก 3, 6 หรือ 12 เดือน

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

เมื่อย้ายงานจากคอลัมน์แรกไปยังคอลัมน์ที่สอง กฎ "ดึง" จะมีผล หมายความว่างานไม่ได้ถูกมอบหมายให้กับผู้พัฒนารายใดรายหนึ่ง แต่ละคนเลือกงานจากคิวและดำเนินการอย่างอิสระ

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

สรุป

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

หากคุณชอบเนื้อหาของเรา เข้าร่วมชุมชนผึ้งที่วุ่นวายบน Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest

ผู้เขียน: แคโรไลน์ เบ็คเกอร์

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

ดูกระทู้ทั้งหมด

คู่มือการต่อสู้:

1. อภิธานศัพท์ของคำศัพท์พื้นฐาน บทบาท และแนวคิด
2. Scrum คืออะไร?
3. ค่าการต่อสู้
4. วิธีใช้งาน Scrum ในบริษัทของคุณ
5. Scrum Team - มันคืออะไรและทำงานอย่างไร?
6. เจ้าของผลิตภัณฑ์คือใคร?
7. ข้อผิดพลาดที่พบบ่อยที่สุดของ Product Owner
8. Scrum Master คือใคร?
9. ลักษณะของ Scrum Master ที่ดี
10. ข้อผิดพลาดที่พบบ่อยที่สุดของ Scrum Master
11. สถิติและตัวชี้วัดใดที่ Scrum Master ควรติดตาม
12. ความร่วมมือระหว่าง Product Owner และ Scrum Master
13. ทีมพัฒนาใน Scrum
14. ข้อผิดพลาดที่พบบ่อยที่สุดของ Developers
15. สิ่งประดิษฐ์การต่อสู้
16. สเกลการต่อสู้
17. Sprint Backlog
18. Backlog สินค้าคืออะไร?
19. เรื่องราวของผู้ใช้คืออะไร?
20. สร้าง User Story ที่ดีที่สุดกับ INVEST
21. ข้อผิดพลาด User Story ที่พบบ่อยที่สุด
22. เกณฑ์การยอมรับเรื่องราวของผู้ใช้
23. การประมาณค่าและจุดเรื่องราวใน Scrum
24. การวางแผนโป๊กเกอร์
25. เกมประเมินทีม
26. กำหนดส่วนเพิ่ม
27. เหตุการณ์การต่อสู้
28. Sprint ใน Scrum คืออะไร?
29. ความมุ่งมั่นของทีม Scrum - เป้าหมายผลิตภัณฑ์ เป้าหมาย Sprint และคำจำกัดความของความสำเร็จ
30. แผนภูมิ Burndown คืออะไร?
31. จะสร้างและตีความแผนภูมิเบิร์นดาวน์ได้อย่างไร?
32. ข้อดีและข้อเสียของแผนภูมิการเบิร์นดาวน์
33. กระดาน Kanban ใน Scrum และ Scruban
34. Velocity in Scrum - ความเร็วของทีมพัฒนา
35. การต่อสู้รายวัน
36. การวางแผนการวิ่ง
37. Sprint Review
38. Sprint Retrospective คืออะไร?
39. ข้อผิดพลาดทั่วไประหว่าง Sprint Retrospective
40. บำรุง Backlog สินค้า