Kanban Flow: WIP limit, cycle time, giao hàng liên tục

Phương pháp Kanban có đúng một quy tắc đơn giản, nhưng quy tắc đó thay đổi mọi thứ: giới hạn việc đang làm. Tất cả các phần còn lại - cái bảng, các metric, các ceremony bạn không cần phải làm - đều bắt nguồn từ quy tắc ấy. Chương này giới thiệu setup Kanban tối thiểu để áp cho team phần mềm, các WIP limit giúp bắt được tình trạng quá tải trước khi nó biến thành burnout, và lúc nào nên chọn Kanban thay vì Scrum.

Khi nào Kanban thật sự hợp với một team?

Có ba tín hiệu chính.

Việc đến liên tục. Ticket, sự cố, các yêu cầu từ team khác - việc xuất hiện hàng ngày dưới hình dạng không thể dự đoán. Bạn không thể gom những việc đó vào một sprint 2 tuần mà không tự lừa mình về những gì sắp tới.

Việc trộn nhiều loại. Một team vừa làm tính năng, vừa fix bug, vừa support ops thì khó nhét cả ba vào một sprint chỉ-có-một-goal của Scrum. Kanban xử lý cái mix đó một cách tự nhiên.

Team hay bị ngắt. Các team platform, infra, support thường xuyên bị kéo vào việc khẩn của team khác. Kanban thừa nhận thực tế đó; trong khi Scrum cố gắng chống lại nó.

Nếu công việc do tính năng dẫn dắt với tốc độ đến tương đối dự đoán được, và team có một product owner rõ ràng, thì Scrum thường thắng Kanban.

Cái giá khi chạy Kanban mà không có WIP limit là gì?

Có ba kiểu lỗi thường gặp.

Mọi thứ đều đang làm, nhưng chẳng có gì xong. Mỗi engineer cùng lúc ôm 4-5 card. Việc liên tục chuyển ngữ cảnh giết throughput. Cái bảng trông thì rất bận, nhưng đồ thị phần mềm đã ship vẫn phẳng lỳ.

Việc cũ kẹt ở review. Các PR ngồi chờ review nhiều ngày vì reviewer bị kéo đi bắt việc mới thay vì hoàn thành việc cũ. Cycle time phồng to.

Bottleneck ngầm. Một cột nào đó (thường là QA hoặc review) cứ lặng lẽ tích lại. Không ai nhận ra cái queue đó là vấn đề vì không có WIP limit nào bắt được. Team chỉ biết phàn nàn "mọi thứ chậm" mà không gọi tên được nguyên nhân cụ thể.

Bảng Kanban tối thiểu trông thế nào?

Cho một team 5 engineer:

flowchart LR
    BL[Backlog<br/>không limit] --> Ready[Ready<br/>WIP 5]
    Ready --> Doing[Doing<br/>WIP 3]
    Doing --> Review[Review<br/>WIP 3]
    Review --> Done[Done<br/>tuần này]
    style Doing fill:#fef3c7,stroke:#d97706
    style Review fill:#fef3c7,stroke:#d97706

Năm cột, trong đó hai cột có WIP limit. Backlog là danh sách ưu tiên những việc sắp tới; Ready chứa các item đã được refine đủ để kéo vào làm; Doing và Review bị limit để công việc không bị chất đống; còn Done là đầu ra của tuần này (sẽ được dọn sang archive vào cuối tuần).

WIP limit (3 và 3) chỉ là con số khởi điểm. Hãy điều chỉnh dựa trên metric - xem mục về failure mode bên dưới.

Các metric cụ thể là gì và thu thập ra sao?

Có bốn con số, được tính từ timestamp lúc card đổi cột:

team_kanban_dashboard:
  period: "Tuần 2026-06-01"

  throughput:
    cards_completed_this_week: 9
    average_last_4_weeks: 8.2
    trend: ổn định

  cycle_time_days:
    p50: 2.5
    p95: 7.0
    target_p95: 7.0
    note: "p95 trong target; một outlier do card vendor chặn"

  wip_history:
    monday: 3
    tuesday: 3
    wednesday: 4    # một card kéo trong khi cái khác ở review
    thursday: 3
    friday: 3

  flow_efficiency:
    active_time_percent: 35
    waiting_time_percent: 65
    note: "65% chờ là điển hình; giảm bằng cách hạ WIP thêm"

Có hai chi tiết cần lưu ý. Cycle time được đếm từ lúc card được kéo vào Doing cho tới lúc card chuyển sang Done - thời gian chờ ở Backlog không được tính. Còn throughput chính là sản lượng thật mà team giao ra; đây là con số mà bạn sẽ bảo vệ trong status report.

Kanban scale lên đa team như thế nào?

Có hai pattern phổ biến.

Mỗi team chạy Kanban riêng kèm dashboard chung:

flowchart TB
    Team1[Bảng Team A] --> Dash[Dashboard tổ chức:<br/>cycle time + throughput]
    Team2[Bảng Team B] --> Dash
    Team3[Bảng Team C] --> Dash
    Dash --> Review[Review flow tháng]

Mỗi team chạy một bảng riêng với WIP limit riêng. Cuộc review flow hàng tháng so cycle time giữa các team để làm lộ ra bottleneck (Team C cứ liên tục chậm? có thể họ cần thêm hỗ trợ, hoặc hình dạng công việc của họ đang sai).

Kanban dùng chung cho một chương trình: khi một tính năng phải chảy qua 3 team (mobile, backend, ops), một bảng dùng chung với các cột theo team sẽ trực quan hoá được các điểm handoff. WIP limit ở mỗi cột giúp ngăn không cho team nào bị quá tải bởi upstream đẩy xuống.

Kanban có thể tạo ra những lỗi nào?

• Bỏ qua WIP limit. "Thêm một card thôi mà." Cách phòng: coi WIP limit là quy tắc cứng; nếu một việc thật sự bị chặn, hãy chuyển card đó ra khỏi Doing và đưa về Ready hoặc một swimlane Blocked.
• Backlog kéo dài vô tận. Backlog phình ra hàng nghìn item; không ai còn biết bên trong có gì. Cách phòng: dọn theo quý; bất cứ item nào không được kéo lên trong 3 tháng thì đem archive.
• Stakeholder mất nhịp. Giao hàng liên tục nghĩa là không có một cột mốc tự nhiên kiểu "sprint này ship được cái gì". Cách phòng: gửi digest những thứ đã ship hàng tuần theo định dạng của status report.
• Gaming cycle time. Engineer chia một card lớn thành nhiều card nhỏ để hạ con số cycle time. Cách phòng: theo dõi phân phối kích thước card cùng với cycle time; thưởng cho throughput đều đặn chứ không thưởng cho mánh lới.

Khi nào Kanban là lựa chọn sai?

Có ba trường hợp.

Stakeholder đòi cam kết kiểu sprint. Marketing muốn "5 tính năng này ship trong 2 tuần". Kanban không hứa được điều đó; còn Scrum thì có thể. Hãy chọn Scrum, hoặc chạy hybrid trong đó Kanban xử lý ops và Scrum xử lý tính năng.

Team cần bị ép phải retrospect. Một số team sẽ bỏ hẳn việc cải thiện nếu không có retro bắt buộc của Scrum. Kanban cũng có dạng retro riêng (kaizen event) nhưng trong thực tế là tuỳ chọn; nếu team không tự tổ chức được, thì kỷ luật của Scrum sẽ hữu ích hơn.

Dự án có deadline cứng. Kanban tốt cho việc giao hàng steady-state, nhưng yếu hơn khi yêu cầu là "phải kịp X vào Y". Khi deadline chặt, hãy chuyển sang plan kiểu dự án (chương planning) và dùng Kanban như một cơ chế thực thi bên trong.

Đi tiếp từ đây như thế nào?

Chương tiếp theo: chọn phương pháp - cây quyết định để chọn giữa Scrum, Kanban, hybrid, hay waterfall dựa trên loại công việc trước mặt. Sau đó, các chương về lifecycle sẽ dẫn bạn đi xuyên một dự án từ đầu đến cuối.