Concept หลัก: Sprint#

Sprint = รอบเวลาตายตัว (timebox) ปกติ 2 อาทิตย์

ทุก sprint:

1. Sprint Planning (ต้น sprint) — เลือก backlog item ที่จะทำใน sprint นี้
2. Daily Standup (ทุกวัน, 15 นาที) — เมื่อวานทำอะไร, วันนี้จะทำอะไร, ติดอะไร
3. Sprint Review (ปลาย sprint) — show ผลให้ stakeholder ดู
4. Sprint Retrospective (หลัง review) — ทบทวน — อะไรดี อะไรควรปรับ

กฎเหล็กของ Sprint:

• Scope ไม่เปลี่ยนกลาง sprint — ถ้ามีเรื่องด่วน ใส่ sprint ถัดไป
• ส่งมอบ “potentially shippable” ทุก sprint — ไม่ใช่ work-in-progress

Roles (จาก EP.04)#

• Product Owner — เจ้าของ backlog
• Scrum Master — facilitator + coach
• Developers — ทีมที่ build (3-9 คน)

Artifacts#

• Product Backlog — รายการงานทั้งหมด (เรียงลำดับ)
• Sprint Backlog — งานที่ commit ใน sprint นี้
• Increment — ผลลัพธ์ที่ส่งมอบหลัง sprint

Scrum เหมาะเมื่อ#

• ✅ Team co-located หรือ async + sync ได้
• ✅ Backlog prioritize ได้ (มี PO ที่ตัดสินใจเร็ว)
• ✅ ส่งมอบ increment ทุก 2 อาทิตย์ได้
• ✅ Team committed กับขนาดงาน sprint

Scrum ไม่เหมาะเมื่อ#

• ❌ ทีมเล็กกว่า 3 คน (overhead เกิน)
• ❌ งาน continuous flow (support, ops) — ไม่ commit เป็น sprint ได้
• ❌ Hard deadline + fixed scope ใหญ่ (ยังคง challenge แม้ scrum)
• ❌ PO ตัดสินใจไม่ได้ — ทีม block ตลอดเวลา

Anti-pattern: “ScrumBut”#

ทีมที่ใช้ Scrum แต่ ไม่ทำตาม guide:

• “ScrumBut เราไม่ retrospective”
• “ScrumBut PO เราตัดสินใจเองไม่ได้”
• “ScrumBut Sprint เรา 4 อาทิตย์เพราะ deploy ไม่บ่อย”

ScrumBut บ่อยๆ = Scrum ล้ม — เพราะค่านิยม core ถูก strip ออก

Concept หลัก: Visualize + Limit WIP#

Kanban Board หน้าตา:

1
| Backlog | To Do | In Progress | Review | Done |
2
|         |       |  (limit: 3) |        |      |

กฎเหล็ก:

1. Visualize — งานทุกอย่างต้องอยู่บน board
2. Limit WIP (Work In Progress) — จำนวน item ใน “In Progress” ห้ามเกิน X
3. Manage flow — measure time จาก “To Do” → “Done”
4. Make policies explicit — เขียนกติกาชัด
5. Implement feedback loops — review เป็นระยะ
6. Improve collaboratively — kaizen

ทำไม WIP limit สำคัญ?#

ลองนึกร้านอาหาร — ถ้าเชฟทำ 10 เมนูพร้อมกัน vs 2 เมนูพร้อมกัน

• 10 พร้อมกัน: เริ่มทุกเมนู, ไม่มีเมนูไหนเสร็จ, ลูกค้ารอนาน
• 2 พร้อมกัน: เสร็จเมนูที่ 1 แล้วเริ่มเมนูใหม่, ลูกค้าได้กินเร็ว, queue หมุนเร็วกว่า

นี่คือ flow — Kanban เน้น throughput ไม่ใช่ utilization

Kanban เหมาะเมื่อ#

• ✅ Continuous flow ของงาน (support, ops, content marketing)
• ✅ Priority เปลี่ยนบ่อย (sprint commitment ผิด)
• ✅ ไม่มี natural cadence (releases ตามต้องการ)
• ✅ ทีมที่ Scrum ไม่เหมาะ

Kanban ไม่เหมาะเมื่อ#

• ❌ ต้องการ hard delivery commitment by date X
• ❌ ทีมยังไม่มีวินัย — Kanban ต้องการ self-discipline สูงกว่า Scrum

Core idea: ขจัด waste (มุดะ — 無駄)#

7 wastes ใน Lean:

1. Overproduction — สร้างเกินจำเป็น
2. Waiting — งานรอ approval, รอ resource
3. Transport — โอนงานข้ามทีมไม่จำเป็น
4. Over-processing — ทำเกินที่ลูกค้าต้องการ
5. Inventory — มี backlog เก่า ไม่ได้ทำ
6. Motion — task switching, meeting ไม่จำเป็น
7. Defects — bug ที่ต้องกลับมาแก้

หลักการสำคัญของ Lean#

1. Eliminate waste
2. Amplify learning
3. Decide as late as possible (สูงสุดของข้อมูล)
4. Deliver as fast as possible
5. Empower team
6. Build integrity in (quality ใน process)
7. See the whole

Lean เหมาะเมื่อ#

• ✅ Repetitive value-stream (manufacturing, ops)
• ✅ บริษัทมี culture kaizen
• ✅ Long-term commitment

Lean ไม่เหมาะเมื่อ#

• ❌ One-off creative R&D (waste = experiment ที่จำเป็น)
• ❌ บริษัทที่ KPI สั้น

Practices หลัก#

1. Pair Programming 2 คน 1 keyboard — driver (พิมพ์) + navigator (review real-time)

• ✅ Code quality ดี
• ❌ คนยอมรับยาก (“ไม่ productive”)

2. Test-Driven Development (TDD)

• เขียน test ก่อน → run (fail) → เขียน code → run (pass) → refactor
• เป็น discipline ที่ requires practice

3. Continuous Integration

• Merge code เข้า main branch หลายๆ ครั้งต่อวัน
• Run automated test ทุก merge

4. Small Releases

• Deploy production บ่อย (รายวัน, รายอาทิตย์)

5. Refactoring

• Improve code structure ตลอด — ไม่ใช่ “refactor week” ปีละครั้ง

6. On-site Customer

• ลูกค้าจริงนั่งกับทีม → ตอบคำถามได้ทันที

XP เหมาะเมื่อ#

• ✅ Software team ที่ co-located
• ✅ Code quality สำคัญสูง
• ✅ ลูกค้ายอม dedicate คน

XP ไม่เหมาะเมื่อ#

• ❌ Distributed team (pair programming ยาก)
• ❌ ลูกค้าไม่ยอม pair / on-site
• ❌ Non-software work

XP + Scrum รวมกันได้ไหม?#

ได้ — ปกติเรียก “Scrum + XP” หรือ “Scrum-XP Hybrid”:

• Scrum = process framework
• XP = engineering practice

หลายทีมทำแบบนี้ — ใช้ Scrum โครง + XP สำหรับ code