Kanban, Agile และ Scrum: มีความแตกต่างหรือไม่

Kanban, Agile และ Scrum: มีความแตกต่างหรือไม่

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



Kanban และ Agile

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

การจัดการโครงการแบบ Agile มุ่งเน้นไปที่เวิร์กโฟลว์แบบขนานและปรับเปลี่ยนได้ และอยู่ในวิธีการจัดการที่หลากหลาย รวมถึง Scrum และ Kanban

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

Kanban ใช้หลักการ Agile และนำไปใช้ในลักษณะเฉพาะ ดังนั้น Kanban จึงเป็นเฟรมเวิร์กที่อยู่ภายใต้ระเบียบวิธีแบบ Agile

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

แต่แตกต่างจาก Scrum หรือ Agile ตรงที่ Kanban นั้นเกี่ยวกับสถานะการทำงานที่มุ่งเน้นไปที่การวิ่งและการวนซ้ำ Kanban มุ่งเน้นที่การแบ่งงานออกเป็นงานเล็กๆ การแสดงภาพ และรับหลายรายการในสถานะงานที่กำหนด บนกระดาน Kanban งานจะย้ายจากซ้ายไปขวาเสมอ

versatility of kanban lies in its simplicity

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

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

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

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

Kanban และการต่อสู้

มันคุ้มค่าที่จะเปรียบเทียบ Kanban กับ Scrum หนึ่งในเฟรมเวิร์กเปรียวยอดนิยม

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

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

Scrum มีระบบของบทบาท เหตุการณ์ กฎ และสิ่งประดิษฐ์ ในโมเดลนี้ ทีมมีหน้าที่รับผิดชอบในการสร้างและปรับแต่งเวิร์กโฟลว์

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

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

kanban used in production environment for inventory management

Kanban ถูกนำมาใช้ในสภาพแวดล้อมการผลิตเพื่อจัดการสินค้าคงคลังตลอดห่วงโซ่อุปทานโดยใช้แนวทางปฏิบัติที่เรียกว่าการผลิตแบบทันเวลาพอดี (JIT) ในการจัดการโครงการ วิธีการ Kanban ใช้แนวคิดเดียวกัน เพื่อให้มั่นใจว่าปริมาณงานที่ต้องการตรงกับความสามารถในการทำงานของทีม

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

Scrum และ Kanban ถือเป็นรากฐานที่สำคัญของวิธีการดำเนินการแบบ Agile ตามรายงาน "Pulse of Profession 2019" ของ PMI องค์กรกว่า 57% ใช้วิธีการแบบ Agile ที่หลากหลาย โดยส่วนใหญ่มุ่งมั่นที่จะใช้ Scrum และ Kanban

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

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

วิธีแก้ปัญหาที่จะใช้ขึ้นอยู่กับลักษณะของกระบวนการ อย่างไรก็ตาม อาจกล่าวได้ว่า Kanban นำเสนอวิธีการที่เป็นส่วนตัวมากกว่า ในขณะที่ Scrum อาศัยกฎที่กำหนดไว้ล่วงหน้า

ความแตกต่างที่สำคัญอีกประการหนึ่งระหว่างสองสิ่งนี้คือกรอบความคิดและระบบความเชื่อของ Scrum และ Kanban

เพื่อให้เข้าใจสิ่งนี้ โปรดดูตารางด้านล่าง

Kanban

Scrum

ธรรมชาติ

Kanban - วิธีการปรับตัว

Scrum - กรอบที่กำหนด

หลักการ

1. เริ่มจากสิ่งที่คุณทำอยู่ตอนนี้

2. ยอมรับการเปลี่ยนแปลงเชิงวิวัฒนาการ

3. ส่งเสริมการเป็นผู้นำในทุกระดับ

4. มุ่งเน้นไปที่ความต้องการของลูกค้า

5. จัดการงาน

6. ตรวจสอบเครือข่ายบริการของคุณเป็นประจำ

1. ประสบการณ์นิยม

2. ความโปร่งใส

3. การตรวจสอบ

4. การปรับตัว

Cadences - จังหวะระดับคำสั่ง

- จังหวะที่มุ่งเน้นบริการ

- ระยะเวลาการวิ่งคงที่

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

- การต่อสู้รายวัน

- รีวิววิ่ง

- วิ่งย้อนหลัง

บทบาท

- ไม่จำเป็นต้องมีบทบาทที่กำหนดไว้ล่วงหน้า

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

- ปรมาจารย์การต่อสู้

- ทีมพัฒนา

ตัวบ่งชี้ 

- รอบเวลา

- แบนด์วิธ

- งานระหว่างทำ

- ความเร็ว

- กำลังการผลิตตามแผน

ดังนั้น Scrum จึงหมุนรอบ "sprint" ที่มีความยาวคงที่ และงานเสร็จเป็นชุดเล็กๆ Kanban มุ่งเน้นไปที่กระบวนการปรับปรุงอย่างต่อเนื่อง และงานจะดำเนินการอย่างเป็นระเบียบ

Kanban สามารถเปลี่ยนได้อย่างง่ายดายทุกเมื่อเนื่องจากเป็นงานที่อิงตามงาน ในขณะที่ Scrum ต้องการแผน sprint หนึ่งแผนให้เสร็จสิ้นก่อนที่จะทำการเปลี่ยนแปลงใดๆ

สิ่งนี้ทำให้ Kanban เป็นตัวเลือกที่เหมาะสมสำหรับโครงการอเนกประสงค์ ในขณะที่ Scrum เหมาะสมกว่าสำหรับโครงการที่ต้องทำงานเป็นชุด Kanban ยังไม่มีบทบาทที่กำหนด Scrum มีบทบาทที่กำหนดไว้ล่วงหน้า - Scrum Master, Product Owner และสมาชิกในทีม

scrum master product owner and team member

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

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

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

kanban for programmers

แต่ถ้ามีคนมองว่า Kanban รวมกับ Scrum เขาก็ไม่ผิด ทีมพัฒนาไอทีหลายทีมผสมรูปแบบการทำงานที่เรียกว่า "Scrumban" อย่างไรก็ตามผู้สนับสนุน Kanban "บริสุทธิ์" โต้แย้งว่า แนวปฏิบัติของ Scrum บางอย่างต้องถูกยกเลิกเพราะเสียเวลาโดยไม่ได้เพิ่มคุณค่าโดยตรงให้กับลูกค้า ตัวอย่างเช่น Sprints ที่มีความยาวคงที่ การประเมินเรื่องราวของผู้ใช้ การประชุมวางแผน Sprint และ Release และการจัดลำดับความสำคัญของ User Story ที่เข้มงวดใน Product Backlog

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

เมื่อพิจารณาจากกฎการจัดตารางเวลาที่คล่องตัวแล้ว เรื่องราวเกี่ยวกับ Product Backlog จะมีความสำคัญ และแต่ละทีมจะต้อง:

  • กำหนดความเร็วที่คุณคาดไว้

  • ให้คะแนนเรื่องราวของผู้ใช้โดยใช้ค่าที่กำหนดไว้ล่วงหน้า (0, 1, 2, 3, 5, 8, 13 และ 20)

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

kanban work in progress

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

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

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

ข้อดีของคัมบังคือสามารถนำไปใช้กับกระบวนการหรือวิธีการใดก็ได้ ไม่ว่าจะใช้วิธีการแบบ Agile (Scrum, XP และอื่นๆ) หรือวิธีการแบบดั้งเดิมอื่นๆ (waterfall, iterative เป็นต้น) มีโอกาสเสมอที่จะใช้ Kanban เพื่อปรับปรุงกระบวนการทีละน้อย ลดรอบเวลา และปรับปรุงโฟลว์

คำถามที่พบบ่อย

คันบันช่วยลดระยะเวลานำได้อย่างไร?

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

ข้อผิดพลาดทั่วไปที่ควรหลีกเลี่ยงในการนำคันบันไปใช้มีอะไรบ้าง?

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

สามารถใช้คันบันในโครงการที่ไม่ใช่การพัฒนาซอฟต์แวร์ได้หรือไม่?

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

คันบันช่วยส่งเสริมการทำงานร่วมกันและความโปร่งใสได้อย่างไร?

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

มาตรวัดใดที่มักใช้ในการวัดความสำเร็จในคันบัน?

มาตรวัดที่มักใช้ในการวัดความสำเร็จในแคนบัน ได้แก่: cycle time (เวลาที่ใช้ในการเคลื่อนย้ายรายการงานผ่านกระบวนการทั้งหมด), throughput (จำนวนรายการงานที่เสร็จสมบูรณ์ในช่วงเวลาที่กำหนด) และ cumulative flow (การแสดงภาพของจำนวนรายการงานในแต่ละขั้นตอนของกระบวนการตลอดช่วงเวลา)

ทีมคันบันควรทบทวนและปรับกระบวนการบ่อยแค่ไหน?

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

สามารถใช้คันบันร่วมกับวิธีการ Agile อื่นๆ ได้หรือไม่?

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


Yandex pixel