Kanban
Cách quản lý công việc bằng bảng trực quan và giới hạn số việc đang làm dở, kéo việc mới vào khi có chỗ trống thay vì đẩy theo lô. Không có sprint, không có vai trò bắt buộc.
Định nghĩa
Kanban xuất phát từ dây chuyền sản xuất của Toyota, sau đó David J. Anderson đưa vào phần mềm khoảng năm 2010. Ý tưởng đơn giản tới mức dễ bị coi thường: dán hết việc lên một cái bảng, giới hạn số việc được phép làm dở cùng lúc, và chỉ kéo việc mới vào khi có chỗ trống.
Bảng đầy cột "In Progress" mà cuối tuần chẳng có gì Done thì vấn đề nằm ở chỗ khởi động quá nhiều việc, chứ không phải team lười.
Sáu thực hành, và cái thứ hai là cái khó
- Trực quan hoá luồng việc. Mỗi cột phải là một trạng thái thật trong quy trình của bạn, không phải cột mặc định Jira dựng sẵn.
- Giới hạn WIP. Cột "Đang code" tối đa 3 thẻ cho team 5 người, đại loại vậy. Chạm trần thì cấm bốc việc mới — phải đi đẩy giúp việc đang kẹt. Đây là thực hành bị bỏ đầu tiên ở mọi team, và bỏ nó thì năm cái còn lại thành trang trí.
- Quản lý luồng. Đo bằng thời gian chứ đừng đo bằng số thẻ: lead time, cycle time, throughput.
- Công khai chính sách quy trình. Điều kiện để một thẻ được kéo sang cột kế tiếp phải viết ra dán cạnh bảng, đừng để trong đầu mỗi người một kiểu.
- Dựng vòng phản hồi. Có nhịp nhìn lại bảng và nhìn lại chỉ số, không thì chẳng ai biết WIP limit đang đặt đúng hay sai.
- Cải tiến cùng nhau bằng thực nghiệm. Đổi một thứ, đo, rồi mới quyết giữ hay bỏ.
Ngoài sáu thực hành này, Kanban còn bốn nguyên tắc nền, quan trọng nhất là nguyên tắc bắt đầu từ đúng quy trình hiện tại của bạn, kể cả khi nó xấu. Kanban không quy định vai trò, không quy định lịch họp, không bắt estimate. Đó là điểm mạnh, và cũng là cái bẫy: team thiếu kỷ luật rất dễ biến bảng Kanban thành danh sách việc dài vô tận.
So sánh Scrum và Kanban
| Tiêu chí | Scrum | Kanban |
|---|---|---|
| Nhịp làm việc | Sprint cố định, tối đa 1 tháng | Dòng chảy liên tục, release bất cứ lúc nào |
| Vai trò | PO, Scrum Master, Developers | Không bắt buộc vai trò nào |
| Cam kết | Sprint Goal cho cả sprint | Cam kết theo từng thẻ |
| Giới hạn công việc | Gián tiếp, qua sức chứa của sprint | Trực tiếp, qua WIP limit mỗi cột |
| Chỉ số quen dùng | Velocity, burndown | Cycle time, throughput, biểu đồ CFD |
| Đổi ưu tiên giữa chừng | Hạn chế, Sprint Goal cần được bảo vệ | Thoải mái, chỉ cần đổi thứ tự hàng đợi |
| Hợp với | Phát triển tính năng mới theo mục tiêu | Bảo trì, vận hành, việc đến bất chợt |
Ví dụ thực tế
Đội bảo trì các hệ thống phụ trợ của một ngân hàng: năm người, mỗi tuần lãnh chừng 27 ticket từ ba hướng — lỗi production, yêu cầu trích số liệu, chỉnh cấu hình sản phẩm tiền gửi. Không ticket nào biết trước từ đầu sprint, nên Scrum gần như vô nghĩa với họ.
Bảng của team có 5 cột: Hàng đợi, Phân tích, Đang làm, Chờ kiểm thử, Xong. WIP limit đặt lần lượt là vô hạn, 2, 3, 2. Sau sáu tuần, dữ liệu cho thấy cycle time trung bình 4,5 ngày nhưng cột "Chờ kiểm thử" chiếm gần 2 ngày trong số đó — chỉ vì cả team có một QC duy nhất. Team quyết định hai dev học làm regression test cơ bản. Cycle time xuống còn 3 ngày trong tháng kế tiếp.
Cái hay là con số đó tự lộ ra từ bảng, chẳng cần ai họp kiểm điểm.
Scrumban và chuyện trộn hai thứ
Nhiều team Việt Nam chạy kiểu lai: vẫn giữ sprint 2 tuần, vẫn có retro và Sprint Review, nhưng thêm WIP limit lên bảng và đo cycle time. Cách gọi thị trường là Scrumban. Nó không có chuẩn chính thức nào cả, nên đừng tranh cãi tên gọi, cứ nhìn xem team có ít việc dở dang hơn và giao hàng đều hơn không.
Lỗi hay gặp
- Đặt WIP limit rồi ai cũng vượt, không ai nhắc. Bỏ luôn phần "limit" thì Kanban chỉ còn là cái bảng dán giấy.
- Cột "Chờ" mọc lên khắp nơi mà không ai đo thời gian nằm chờ.
- Dùng Kanban để né việc lập kế hoạch. Không sprint không có nghĩa là không cần biết quý này định làm gì.
- Đo throughput theo số thẻ mà thẻ thì cái to cái nhỏ chênh nhau mười lần. Muốn số có nghĩa thì phải chẻ thẻ về kích cỡ tương đối đều.
Bắt đầu thì đơn giản thôi: vẽ đúng quy trình hiện tại lên bảng, đếm xem hiện đang có bao nhiêu việc dở dang. Con số đó thường làm cả team giật mình.
