Scrumban.

Scrumban คืออะไรกันแน่

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

สิ่งที่ข้ามไป ได้แก่ daily standup, การประชุม grooming ก่อน sprint, พิธีการให้ story point และ retrospective ที่ทำไปตามธรรมเนียม สิ่งเหล่านี้ใช้ได้กับวิศวกรสิบคนในองค์กรที่ปรับจูนมาดีแล้ว แต่ใช้ไม่ได้กับ founder คนเดียวที่พยายามส่งงานให้ทันในวันเสาร์

ทำไม Weft จึงเลือก Scrumban

Weft เกิดขึ้นเพราะเครื่องมือจัดการงานส่วนใหญ่ถูกออกแบบมาสำหรับหนึ่งในสองขั้วสุดโต่ง คือ แอป todo สำหรับคนเดียว (รายการยาวไม่สิ้นสุด ไม่มีจังหวะ) หรือชุดเครื่องมือ Agile สำหรับห้าสิบคน (ภาระด้านกระบวนการที่หนักเกินไปสำหรับ founder คนเดียว) Scrumban อยู่ตรงกลางพอดี มีโครงสร้างมากพอที่จะบังคับให้ส่งงานทุกสัปดาห์หรือทุกสองสัปดาห์ แต่ไม่มากจนต้องใช้วันส่งงานไปกับการจัดการมัน

Weft นำไปใช้อย่างไร

• มี คอลัมน์ เริ่มต้นสี่คอลัมน์: Backlog, Todo, Doing, Done งานที่กำลังทำอยู่ถูกจำกัดด้วยสิ่งที่รอคุณอยู่ ไม่ใช่ด้วยตัวเลขประจำแต่ละคอลัมน์ Kanban Guide ถือว่านโยบายที่ระบุชัดเจนในการจำกัดงานที่กำลังทำอยู่เป็นส่วนหนึ่งของการนิยามเวิร์กโฟลว์ เพื่อให้ดึงงานใหม่เข้ามาก็ต่อเมื่อมีกำลังว่างพอเท่านั้น
• มี sprint ที่ทำงานอยู่ได้ครั้งละหนึ่งอัน sprint เป็นตัวเลือก ข้ามไปได้หากใช้ Kanban ล้วน ๆ แล้วลงตัวกว่า Scrum Guide นิยาม Sprint ว่าเป็นช่วงเวลาที่มีความยาวคงที่ไม่เกินหนึ่งเดือน และ Sprint ใหม่จะเริ่มทันทีหลังจาก Sprint ก่อนหน้าสิ้นสุดลง
• งานมีลำดับความสำคัญ ค่าประมาณการ วันครบกำหนด และผูกกับ sprint ได้ (ไม่บังคับ) ไม่มี epic ไม่มีเวิร์กโฟลว์ ไม่มีฟิลด์กำหนดเอง
• Cycle time เริ่มนับเมื่องานถูกย้ายเข้าคอลัมน์ที่มี semantic="doing" และสิ้นสุดที่ "done" ตัวเลขเหล่านี้มาจาก การใช้งานจริง ไม่ใช่จากการคำนวณ story point

เมื่อไรที่ Scrumban ไม่ใช่วิธีที่เหมาะ

• คุณดูแลหลายทีม Scrum ที่ทำงานพร้อมกัน Scrum Guide ระบุว่าโดยทั่วไป Scrum Team มีไม่เกิน 10 คน และผลิตภัณฑ์ที่ใหญ่กว่านั้นควร จัดเป็นหลาย Scrum Team ที่ใช้ Product Goal และ Product Backlog ร่วมกันอย่างละหนึ่งเดียว รายงานระดับโปรแกรม velocity ร่วม และ dependency ข้ามทีม เป็นจุดที่ Scrum เต็มรูปแบบบน Jira คุ้มค่ากับต้นทุนของมัน Nexus Guide เขียนขึ้นมาเพื่อสถานการณ์นี้โดยเฉพาะ คือหลาย Scrum Team ที่ทำงานจาก Product Backlog เดียวกัน พร้อมแนวปฏิบัติเพิ่มเติมสำหรับการเปิดเผยและแก้ไข dependency ข้ามทีม
• งานของคุณเป็นงานซัพพอร์ต / ops ต่อเนื่องล้วน ๆ ไม่จำเป็นต้องมีจังหวะ sprint ใช้ Kanban ล้วน ๆ หรือระบบ ticket จะเหมาะกว่า
• คุณต้องการ Gantt chart และไทม์ไลน์ Scrumban เน้นที่ sprint ไม่ได้ เน้นที่กราฟ dependency