Kanban vs Scrum

Kanban คือวิธีการ (Method) แบบ Lean สำหรับการจัดการและปรับปรุงการไหลของงานในกระบวนการการผลิต การพัฒนา และการบริการ โดยมุ่งเน้นที่การส่งมอบคุณค่าอย่างต่อเนื่องโดยไม่ทำให้ทีมงานมีภาระงานมากเกินไป และใช้ระบบภาพในการติดตามความคืบหน้าของงาน คำว่า "Kanban" (看板) มาจากภาษาญี่ปุ่น แปลว่า "สัญญาณภาพ" หรือ "บัตร"

Kanban เป็นหนึ่งในสองวิธีการ Agile ที่ได้รับความนิยมมากที่สุดในโลก ควบคู่กับ Scrum จากรายงาน State of Agile ปี 2024 พบว่าประมาณ 13% ของทีมใช้ Kanban เป็นวิธีการหลัก และอีกหลายทีมผสมผสานกับ Scrum ("Scrumban")

Kanban ถูกพัฒนาครั้งแรกในช่วงทศวรรษ 1940 โดยไทอิจิ โอโนะ (Taiichi Ohno) ที่บริษัทโตโยต้า (Toyota) เป็นส่วนหนึ่งของระบบการผลิตแบบโตโยต้า (Toyota Production System) จุดมุ่งหมายเพื่อเพิ่มประสิทธิภาพของกระบวนการผลิตโดยการมองเห็นงาน ลดของเสีย (Muda) และปรับการผลิตให้สอดคล้องกับความต้องการจริง

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

Kanban ขยายจากการผลิตไปสู่การพัฒนาซอฟต์แวร์ในช่วงทศวรรษ 2000 ส่วนใหญ่เป็นผลจากผลงานของ David J. Anderson หนังสือของเขา "Kanban: Successful Evolutionary Change for Your Technology Business" (2010) กลายเป็นหมุดหมายสำคัญในสาขานี้

Anderson กำหนดแนวปฏิบัติหลัก 6 ประการของ Kanban:

1. ทำให้งานมองเห็นได้ (Visualize) — ทำให้งานเป็นที่มองเห็น
2. จำกัดงานระหว่างทำ (Limit WIP) — ป้องกันการโอเวอร์โหลด
3. จัดการการไหล (Manage Flow) — ติดตามและเพิ่มประสิทธิภาพการไหล
4. ทำให้นโยบายชัดเจน (Make Policies Explicit) — กฎที่ชัดเจนสำหรับทุกคน
5. ใช้วงจรข้อเสนอแนะ (Implement Feedback Loops) — การตรวจสอบและทบทวนเป็นประจำ
6. ปรับปรุงร่วมกัน พัฒนาแบบทดลอง (Improve Collaboratively) — การพัฒนาทีละขั้น

ทีมงานใช้บอร์ด Kanban (Kanban Board) ในการมองเห็นการทำงานและติดตามความคืบหน้า บอร์ด Kanban ทั่วไปประกอบด้วยคอลัมน์ต่างๆ เช่น:

• To Do — งานที่รอเริ่ม
• In Progress — งานที่กำลังดำเนินการ
• Review — งานที่รอการตรวจสอบ
• Done — งานที่เสร็จสมบูรณ์

แต่ละรายการงานแทนด้วยการ์ด (Card) ที่เคลื่อนจากซ้ายไปขวาผ่านคอลัมน์ต่างๆ บอร์ดให้ภาพรวมทันทีของสถานะงานทั้งหมดในทีม

งานวิจัยแสดงให้เห็นว่าบอร์ด Kanban แบบภาพสามารถลดเวลาการสื่อสารในทีมได้ 30% และปรับปรุงการมองเห็นคอขวดได้ 50%

Kanban ส่งเสริมการปรับปรุงอย่างต่อเนื่อง (Kaizen) — การค้นหาและแก้ไขปัญหาในกระบวนการทำงานอย่างสม่ำเสมอ ต่างจากวิธีการที่ต้องการการเปลี่ยนแปลงแบบปฏิวัติ Kanban ส่งเสริมการเปลี่ยนแปลงแบบวิวัฒนาการ — การปรับปรุงเล็กๆ น้อยๆ ที่สะสมเป็นการเปลี่ยนแปลงที่สำคัญในระยะยาว

แนวทางของ Kanban คือ "เริ่มจากจุดที่คุณอยู่" — ไม่จำเป็นต้องเปลี่ยนบทบาท กระบวนการ หรือตำแหน่งที่มีอยู่ แต่ให้ค่อยๆ ปรับปรุงขณะทำงานไป

หนึ่งในแนวปฏิบัติหลักของ Kanban คือการจำกัด WIP (Work In Progress) — การกำหนดจำนวนสูงสุดของงานที่สามารถอยู่ในแต่ละขั้นตอนพร้อมกัน

ทำไม WIP Limits จึงสำคัญ?

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

งานวิจัยปี 2023 พบว่าทีมที่นำ WIP Limits ไปใช้มี Cycle Time ลดลง 40% และ Bug ลดลง 25%

ตัวอย่างเชิงตัวเลข

ถ้าทีม 5 คนจำกัดคอลัมน์ "In Progress" ไว้ที่ 5 งาน นักพัฒนาแต่ละคนจะมุ่งเน้นที่งานเดียวในเวลาใดก็ตาม ถ้านักพัฒนาคนใดติดขัด พวกเขาจะขอความช่วยเหลือแทนที่จะเริ่มงานใหม่

ระบบดึง (Pull System) ใน Kanban ส่งเสริมให้ทำงานให้เสร็จก่อนที่จะเริ่มงานใหม่ โดยเน้นที่ความสามารถและความต้องการจริงของทีม แนวทางนี้แตกต่างอย่างสิ้นเชิงจาก "ระบบผลัก" (Push System) ที่งานถูกผลักเข้าสู่ทีมโดยไม่คำนึงถึงความสามารถ

หลักการของระบบดึง:

• "หยุดเริ่ม เริ่มเสร็จ" (Stop Starting, Start Finishing) — ให้ความสำคัญกับการเสร็จมากกว่าการเริ่ม
• ทำงานตามความต้องการ — งานใหม่เข้ามาเมื่อมีที่ว่างเท่านั้น
• ลดของเสีย — งานที่ไม่จำเป็นน้อยลงและ Context Switching น้อยลง
• การไหลที่ราบรื่น — งานไหลอย่างต่อเนื่องผ่านระบบ

Kanban อาศัยตัวชี้วัดเชิงปริมาณเพื่อปรับปรุงกระบวนการ:

Lead Time

เวลาทั้งหมดตั้งแต่คำขอเข้าสู่ระบบจนกว่าจะเสร็จสิ้น Lead Time รวมเวลารอด้วย

Cycle Time

เวลาที่ใช้ในการทำงานตั้งแต่เริ่มจนถึงเสร็จ Cycle Time เป็นตัวชี้วัดสำคัญของประสิทธิภาพทีม

Throughput

จำนวนรายการงานที่ทีมทำเสร็จต่อหน่วยเวลา (สัปดาห์/เดือน)

Cumulative Flow Diagram (CFD)

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

เครื่องมือดิจิทัลยอดนิยมสำหรับการใช้ Kanban:

• Jira — เครื่องมือมืออาชีพที่ได้รับความนิยมมากที่สุด มีการสนับสนุน Kanban ขั้นสูง
• Trello — เรียบง่ายและใช้งานง่าย เหมาะสำหรับทีมขนาดเล็ก
• Asana — ผสมผสานการจัดการงานกับบอร์ด Kanban
• Azure DevOps — เหมาะสำหรับทีม DevOps
• Notion — ยืดหยุ่น เหมาะกับงานหลายประเภท

Kanban ต้องการการฝึกอบรมพิเศษหรือไม่?

ไม่ หนึ่งในข้อดีที่สำคัญของ Kanban คือสามารถเริ่มต้นจากกระบวนการที่มีอยู่และค่อยๆ เพิ่มแนวปฏิบัติ อย่างไรก็ตาม มีใบรับรอง เช่น KMP (Kanban Management Professional) ให้เลือก

Kanban เหมาะกับทีมขนาดใหญ่หรือไม่?

ใช่ Kanban เหมาะกับทีมทุกขนาดและองค์กรทั้งหมด "Kanban at Scale" ช่วยให้สามารถนำวิธีการไปใช้ในระดับองค์กร

Kanban Board กับ Scrum Board ต่างกันอย่างไร?

Kanban Board เป็นแบบต่อเนื่อง — งานไหลโดยไม่มีกำหนดเวลา Scrum Board รีเซ็ตในทุก Sprint นอกจากนี้ Kanban Board มี WIP Limits ที่ชัดเจน

จะกำหนด WIP Limits อย่างไร?

จุดเริ่มต้นที่นิยม: จำนวนสมาชิกทีม x 1.5 เช่น ทีม 4 คน เริ่มที่ WIP Limit 6 แล้วปรับตามประสบการณ์

สามารถใช้ Kanban โดยไม่มีเครื่องมือดิจิทัลได้หรือไม่?

ได้แน่นอน! บอร์ดจริงที่ใช้กระดาษโน้ตติดเป็นวิธีที่ยอดเยี่ยมในการเริ่มต้น บอร์ดจริงให้การมองเห็นทันทีและส่งเสริมปฏิสัมพันธ์แบบเห็นหน้า

• Scrum — กรอบงาน Agile ชั้นนำ
• Lean — ปรัชญาที่เป็นรากฐานของ Kanban
• Kaizen — การปรับปรุงอย่างต่อเนื่อง
• Cycle Time — เวลาในการทำงาน
• Lead Time — เวลาทั้งหมดจากคำขอถึงการส่งมอบ
• DevOps — การรวมการพัฒนาและการดำเนินงาน
• Jira — เครื่องมือจัดการโครงการ

Scrum คือ กรอบงาน Agile (Agile Framework) ที่ออกแบบมาเพื่อพัฒนาวิธีการแก้ปัญหาที่ปรับตัวได้สำหรับปัญหาที่ซับซ้อน โดยมุ่งเน้นการสร้างคุณค่าผ่านความคืบหน้าแบบทีละขั้น (Incremental) และการวนซ้ำ (Iterative) การทำงานร่วมกันในทีม และความสามารถในการปรับตัวตามความต้องการที่เปลี่ยนแปลง Scrum ถูกสร้างขึ้นในช่วงต้นทศวรรษ 1990 โดย Jeff Sutherland และ Ken Schwaber และกลายเป็นกรอบงาน Agile ที่ได้รับความนิยมมากที่สุดในโลก

จากรายงาน State of Agile ปี 2024 พบว่าประมาณ 87% ของทีม Agile ใช้ Scrum หรือรูปแบบใดรูปแบบหนึ่งของ Scrum นอกจากการพัฒนาซอฟต์แวร์แล้ว Scrum ยังถูกนำไปใช้ในการตลาด การศึกษา การก่อสร้าง และการวิจัยทางวิทยาศาสตร์อีกด้วย

Scrum ถูกออกแบบมาเพื่อช่วยให้ทีมสามารถจัดระเบียบตัวเอง (Self-Organization) และตัดสินใจได้อย่างรวดเร็วเพื่อตอบสนองความต้องการที่ซับซ้อนและเปลี่ยนแปลง กรอบงานนี้ตั้งอยู่บนหลักการที่ว่าทีมที่อยู่ใกล้งานมากที่สุดคือผู้ที่รู้ดีที่สุดว่าจะทำงานอย่างไร

การทำงานร่วมกันใน Scrum แสดงออกในหลายรูปแบบ:

• ความโปร่งใสอย่างเต็มที่ — สมาชิกทุกคนสามารถเห็นความคืบหน้าได้ตลอดเวลา
• การสื่อสารรายวัน — ผ่าน Daily Scrum (Daily Standup)
• การทำงานร่วมกัน — ทีมวางแผน ดำเนินการ และตรวจสอบด้วยกัน
• การมีส่วนร่วมของผู้มีส่วนได้ส่วนเสีย — ผ่าน Sprint Review

งานวิจัยจาก Harvard Business Review พบว่าทีมที่นำ Scrum ไปใช้รายงานว่ามีผลผลิตเพิ่มขึ้น 25% และความพึงพอใจของลูกค้าดีขึ้น 35%

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

1. ข้อเสนอแนะที่รวดเร็ว — ลูกค้าสามารถเห็นผลลัพธ์และให้ข้อเสนอแนะแบบเรียลไทม์ในทุก Sprint
2. ลดความเสี่ยง — ค้นพบปัญหาตั้งแต่เนิ่นๆ และแก้ไขก่อนที่จะขยายตัว
3. ความยืดหยุ่น — สามารถเปลี่ยนทิศทางระหว่าง Sprint ตามความต้องการใหม่
4. คุณค่าตั้งแต่เนิ่นๆ — ฟีเจอร์ที่สำคัญที่สุดได้รับการพัฒนาก่อน

Sprint แต่ละรอบเริ่มต้นด้วย Sprint Planning และจบลงด้วย Sprint Review และ Sprint Retrospective วงจรนี้จะเกิดขึ้นซ้ำจนกว่าผลิตภัณฑ์จะถึงระดับที่ต้องการหรือโปรเจกต์สิ้นสุด

Scrum จะให้ความสำคัญกับการส่งมอบคุณสมบัติที่มีคุณค่าสูงสุดให้กับลูกค้าโดยเร็วและสม่ำเสมอ ตามลำดับที่ Product Owner กำหนดใน Product Backlog แนวทางนี้เรียกว่า "Value-Driven Delivery" ซึ่งช่วยให้มั่นใจว่าทรัพยากรถูกใช้อย่างเหมาะสมที่สุด

Product Owner มีหน้าที่รับผิดชอบ:

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

Scrum กำหนดบทบาทหลักสามบทบาท (Accountabilities):

Scrum Master

Scrum Master คือผู้นำแบบรับใช้ (Servant Leader) ที่มีหน้าที่:

• ดูแลให้ทีมปฏิบัติตามแนวปฏิบัติและกฎเกณฑ์ของ Scrum
• ขจัดอุปสรรค (Impediments) ที่ขัดขวางทีม
• โค้ชทีมและองค์กรในการใช้ Scrum
• อำนวยความสะดวกในเหตุการณ์ Scrum ต่างๆ

Product Owner

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

Developers

นักพัฒนา (Developers) คือผู้เชี่ยวชาญที่รับผิดชอบในการสร้างโซลูชัน พวกเขาเป็นทีมข้ามสายงาน (Cross-functional) จำนวน 3-9 คน ที่จัดระเบียบตัวเองเพื่อบรรลุเป้าหมาย Sprint

สิ่งประดิษฐ์ (Artifacts) ใน Scrum ให้ความโปร่งใสและข้อมูลที่สำคัญ:

Product Backlog

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

ข้อผูกมัด: Product Goal — เป้าหมายระยะยาวของผลิตภัณฑ์

Sprint Backlog

ชุดของรายการที่เลือกจาก Product Backlog สำหรับ Sprint ปัจจุบัน พร้อมแผนการดำเนินงาน Sprint Backlog เป็นของทีมนักพัฒนา

ข้อผูกมัด: Sprint Goal — เป้าหมายที่กำหนดไว้ของ Sprint

Increment (ส่วนเพิ่ม)

ชุดของรายการที่เสร็จสมบูรณ์และเป็นไปตาม Definition of Done (DoD) แต่ละ Increment เป็นการเพิ่มเติมจาก Increment ก่อนหน้าทั้งหมดและพร้อมที่จะเผยแพร่

ข้อผูกมัด: Definition of Done — เกณฑ์ที่รายการต้องผ่านจึงจะถือว่า "เสร็จสมบูรณ์"

Scrum กำหนดเหตุการณ์อย่างเป็นทางการ 5 เหตุการณ์ ที่สร้างความสม่ำเสมอและลดความจำเป็นในการประชุมที่ไม่ได้วางแผนไว้:

Sprint

รอบการทำงานที่กำหนดเวลา (Time-box) ไม่เกินหนึ่งเดือน Sprint คือตัวบรรจุของเหตุการณ์อื่นทั้งหมด

Sprint Planning

การประชุมวางแผนในช่วงเริ่มต้นของแต่ละ Sprint (สูงสุด 8 ชั่วโมงสำหรับ Sprint หนึ่งเดือน) ทีมตัดสินใจเกี่ยวกับ:

• ทำอะไร — เลือกรายการใดจาก Product Backlog
• ทำไม — Sprint Goal คืออะไร
• ทำอย่างไร — งานจะดำเนินการอย่างไร

Daily Scrum

การประชุมรายวัน 15 นาทีสำหรับทีมนักพัฒนา เพื่อประสานงานและวางแผนงานสำหรับวันถัดไป นี่ไม่ใช่การรายงานสถานะ แต่เป็นเครื่องมือสำหรับการระบุปัญหาและประสานงานอย่างรวดเร็ว

Sprint Review

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

Sprint Retrospective

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

Scrum ยึดมั่นในค่านิยมหลัก 5 ประการ:

1. ความมุ่งมั่น (Commitment) — ทีมมุ่งมั่นที่จะบรรลุเป้าหมาย Sprint และสนับสนุนซึ่งกันและกัน
2. ความกล้าหาญ (Courage) — สมาชิกในทีมกล้าเผชิญกับปัญหาที่ยาก
3. ความมุ่งเน้น (Focus) — ทีมมุ่งเน้นที่งาน Sprint และเป้าหมายที่ตั้งไว้
4. ความเปิดเผย (Openness) — ความโปร่งใสเกี่ยวกับงานและความท้าทายที่ทีมเผชิญ
5. ความเคารพ (Respect) — สมาชิกในทีมเคารพซึ่งกันและกันในฐานะมืออาชีพที่มีความสามารถ

ค่านิยมเหล่านี้สร้างสภาพแวดล้อมของความไว้วางใจและการทำงานร่วมกัน ซึ่งเป็นรากฐานของความสำเร็จของ Scrum

Scrum ตั้งอยู่บนเสาหลักเชิงประจักษ์ (Empirical Pillars) สามประการ:

ความโปร่งใส (Transparency)

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

การตรวจสอบ (Inspection)

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

การปรับตัว (Adaptation)

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

Scrum กับ Agile ต่างกันอย่างไร?

Agile คือปรัชญาที่กว้าง ในขณะที่ Scrum คือกรอบงาน (Framework) เฉพาะสำหรับการนำหลักการ Agile ไปใช้ Scrum เป็นหนึ่งในกรอบงาน Agile ที่ได้รับความนิยมมากที่สุด แต่ไม่ใช่กรอบงานเดียว

Sprint ใช้เวลานานเท่าไหร่?

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

Scrum เหมาะกับการพัฒนาซอฟต์แวร์เท่านั้นหรือไม่?

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

จะเกิดอะไรขึ้นเมื่อ Sprint Goal ไม่บรรลุ?

หาก Sprint Goal ไม่สำเร็จ ทีมจะหารือกันใน Sprint Retrospective และระบุสิ่งที่สามารถปรับปรุงได้ Sprint จะไม่ถูกขยายเวลา — รายการที่ยังไม่เสร็จจะกลับไปที่ Product Backlog

สามารถใช้ Scrum ร่วมกับ Kanban ได้หรือไม่?

ได้! "Scrumban" เป็นการผสมผสานที่ได้รับความนิยม โดยใช้โครงสร้างของ Scrum ร่วมกับแนวปฏิบัติของ Kanban เช่น การจำกัด WIP และการมุ่งเน้นที่การไหลของงาน

คู่มือ Scrum (Scrum Guide) ให้ความเข้าใจที่จำเป็นและใช้งานได้จริงเกี่ยวกับกรอบงาน Agile เวอร์ชันล่าสุด (2020) ทำให้ Scrum เรียบง่ายขึ้นและมีข้อกำหนดน้อยลง พร้อมเพิ่มแนวคิดใหม่เช่น Product Goal และ Sprint Goal ดาวน์โหลดคู่มือได้ฟรีที่ Scrum Guide

• Sprint — รอบการทำงานพื้นฐานใน Scrum
• Product Owner — บทบาทที่กำหนดคุณค่าของผลิตภัณฑ์
• Scrum Master — ผู้นำแบบรับใช้ที่ส่งเสริม Scrum
• Backlog — รายการความต้องการที่จัดลำดับ
• Kanban — วิธีการทางเลือกสำหรับจัดการการไหลของงาน
• DevOps — การรวมการพัฒนาและการดำเนินงาน
• CI/CD — การรวมและส่งมอบอย่างต่อเนื่อง