Mở đầu — vì sao bài này quan trọng
Nếu Scrum ở bài trước dạy bạn cách làm việc theo từng "nhịp" cố định (Sprint), thì Kanban đến với một triết lý gần như ngược lại: đừng chia công việc thành từng đợt đóng gói, mà hãy để công việc chảy liên tục như dòng nước trên một dây chuyền. Trong kỳ thi PMP, Kanban xuất hiện dưới nhóm phương pháp "flow-based" (dựa trên luồng), và người ra đề rất thích đặt những câu hỏi kiểu: "Đội của bạn liên tục bị nghẽn ở khâu kiểm thử, quá nhiều việc dở dang cùng lúc — bạn nên làm gì?". Nếu bạn nắm được ba khái niệm cốt lõi của bài này là Flow, WIP limit và Cycle Time, bạn sẽ trả lời được phần lớn các câu hỏi dạng đó.
Nhưng Kanban không chỉ là kiến thức thi. Ở Việt Nam, rất nhiều đội ngũ vận hành, bộ phận IT support, phòng marketing, đội DevOps hay thậm chí phòng nhân sự đều đang dùng bảng Kanban (trên Trello, Jira, hay chỉ là bảng trắng dán giấy note) mà không nhất thiết phải theo Scrum. Lý do là Kanban không đòi hỏi bạn phải đảo lộn cơ cấu tổ chức, không cần vai trò mới, không cần chia Sprint. Nó bắt đầu từ chính quy trình bạn đang có và giúp bạn nhìn thấy việc, giới hạn việc, rồi làm việc mượt hơn. Đây là lý do Kanban đặc biệt hợp với những tổ chức "chưa sẵn sàng cho một cuộc cách mạng Agile" nhưng vẫn muốn cải thiện dần.
Bài này sẽ giúp bạn hiểu bản chất của Kanban, bốn nguyên lý nền tảng, ba thước đo dòng chảy, và biết cách áp dụng vào một dự án thật.
Khái niệm cốt lõi
Kanban là gì?
"Kanban" (看板) là tiếng Nhật, nghĩa là "bảng thông báo trực quan". Nguồn gốc của nó là hệ thống sản xuất Toyota (Toyota Production System) những năm 1950, nơi các thẻ (card) được dùng để báo hiệu khi nào cần bổ sung nguyên liệu — tức là một hệ thống pull (kéo): chỉ sản xuất khi có nhu cầu thực, thay vì đẩy (push) hàng loạt ra rồi tồn kho.
David J. Anderson là người đưa tư duy này vào công việc tri thức (knowledge work) và phần mềm vào khoảng năm 2007. Trong bối cảnh dự án, Kanban là một phương pháp giúp bạn trực quan hóa luồng công việc, giới hạn lượng việc đang làm dở, và tối ưu tốc độ hoàn thành.
Điểm cần nhớ cho PMP: Kanban không phải là một khung quy trình (framework) đầy đủ như Scrum. Nó là một phương pháp cải tiến (evolutionary method) mà bạn "đắp" lên trên quy trình hiện có. Bạn không xóa bỏ cái cũ, bạn làm cái cũ hiện rõ ra và cải thiện dần.
Bốn nguyên lý nền tảng (Foundational Principles)
Đây là phần cốt lõi nhất và cũng là thứ hay bị hỏi trong đề thi. Kanban khởi đầu bằng bốn nguyên lý mang tính "thái độ":
1. Bắt đầu từ chính quy trình hiện tại (Start with what you do now). Bạn không cần phải thay đổi vai trò, không cần đập đi làm lại. Hãy vẽ đúng cách đội bạn đang làm việc lên bảng. Kanban tôn trọng thực tế: nếu hiện tại quy trình của bạn là "Yêu cầu → Phân tích → Code → Test → Deploy", thì bảng của bạn cứ có đúng những cột đó.
2. Đồng thuận theo đuổi thay đổi từ từ, tăng dần (Agree to pursue incremental, evolutionary change). Kanban không chủ trương "big bang" — không cách mạng lật đổ. Thay vào đó là những cải tiến nhỏ, liên tục. Điều này giảm sự kháng cự của con người, vì thay đổi lớn thường khiến người ta sợ và chống lại.
3. Tôn trọng vai trò, trách nhiệm và chức danh hiện tại (Respect current roles, responsibilities and titles). Không có "Kanban Master", không bắt trưởng nhóm đổi thành vai trò mới. Ai đang làm gì cứ tiếp tục — điều này khiến việc áp dụng Kanban ít gây xáo trộn chính trị nội bộ.
4. Khuyến khích tinh thần lãnh đạo ở mọi cấp (Encourage acts of leadership at all levels). Cải tiến không phải việc riêng của sếp. Một bạn dev nhìn thấy cột "Test" luôn tắc và đề xuất giải pháp — đó cũng là lãnh đạo. Kanban khuyến khích mọi người, từ nhân viên đến quản lý, chủ động đề xuất cải tiến.
Bốn nguyên lý này giải thích vì sao Kanban được xem là phương pháp "nhẹ nhàng" nhất để bắt đầu hành trình Agile trong các tổ chức truyền thống.
Sáu thực hành cốt lõi (Core Practices)
Bên cạnh bốn nguyên lý mang tính thái độ, Kanban có sáu thực hành cụ thể. Bạn nên biết chúng để phân biệt với Scrum:
- Visualize (trực quan hóa) — đưa toàn bộ công việc lên bảng để ai cũng thấy.
- Limit WIP (giới hạn việc đang làm) — đặt trần cho số việc trong mỗi cột.
- Manage flow (quản lý dòng chảy) — theo dõi và làm mượt luồng việc.
- Make policies explicit (làm rõ chính sách) — ví dụ định nghĩa rõ khi nào một việc được coi là "xong" cột này để sang cột kia (Definition of Done cho từng cột).
- Implement feedback loops (thiết lập vòng phản hồi) — các cuộc họp review, standup, đánh giá.
- Improve collaboratively (cải tiến cùng nhau, dựa trên dữ liệu và mô hình khoa học).
Ba thước đo dòng chảy: Flow, WIP và Cycle Time
Flow (dòng chảy). Đây là mục tiêu tối thượng của Kanban: công việc di chuyển từ trái sang phải trên bảng một cách đều đặn, ít bị dừng, ít bị dội ngược. Một dòng chảy tốt nghĩa là việc không "ứ đọng" ở bất kỳ cột nào. Kanban dùng hệ thống pull: một cột chỉ kéo việc mới vào khi nó có chỗ trống, thay vì bị đẩy việc vào dồn dập.
WIP — Work In Progress (việc đang làm dở). WIP limit là giới hạn số lượng việc được phép nằm trong một cột (hoặc một giai đoạn) tại cùng một thời điểm. Ví dụ cột "Đang code" đặt WIP = 3 nghĩa là tối đa 3 task được code cùng lúc; muốn kéo task thứ 4 vào thì phải hoàn thành và đẩy bớt một task đi trước. Đây là "trái tim" của Kanban. Giới hạn WIP buộc đội ngừng nhồi việc, tập trung hoàn thành cái đang dở, và làm lộ ra điểm nghẽn (bottleneck) — vì nơi nào việc chất đống chạm trần WIP, nơi đó chính là nút thắt cần xử lý.
Cycle Time (thời gian chu kỳ). Đây là khoảng thời gian tính từ lúc một việc bắt đầu được làm (bước vào cột đang xử lý) đến lúc nó hoàn thành (ra khỏi bảng). Cycle Time càng ngắn và càng ổn định thì đội càng dự đoán được tốt. Đừng nhầm với Lead Time — Lead Time tính từ lúc yêu cầu được đưa vào hàng chờ (kể cả khi chưa ai đụng đến) cho tới lúc giao. Nói dễ hiểu với bối cảnh Việt Nam: Lead Time là tổng thời gian khách chờ từ lúc đặt món phở đến lúc bưng ra bàn; Cycle Time là thời gian bếp thực sự nấu tô phở đó.
Ba chỉ số này liên hệ với nhau qua Định luật Little (Little's Law):
> Cycle Time trung bình = WIP trung bình / Throughput (số việc hoàn thành mỗi đơn vị thời gian)
Ý nghĩa rất trực quan: nếu bạn ôm càng nhiều việc dở (WIP cao) mà tốc độ hoàn thành (throughput) không tăng, thì mỗi việc sẽ mất càng lâu để xong (Cycle Time dài). Đây chính là cơ sở khoa học giải thích vì sao "giảm WIP thì việc lại xong nhanh hơn" — một điều nghe có vẻ nghịch lý nhưng hoàn toàn đúng.
Công cụ đo lường: Cumulative Flow Diagram
Kanban thường dùng Cumulative Flow Diagram (CFD) — biểu đồ luồng tích lũy — để nhìn sức khỏe dòng chảy. Trên CFD, mỗi cột trạng thái là một dải màu. Nếu một dải phình to ra theo thời gian, nghĩa là việc đang ứ ở giai đoạn đó — bottleneck lộ diện ngay bằng mắt. Khoảng cách theo chiều dọc giữa các dải cho biết WIP, khoảng cách theo chiều ngang cho biết Cycle Time.
Tình huống thực tế
Ví dụ 1 — Đội IT Support của một chuỗi bán lẻ tại TP.HCM
Một chuỗi cửa hàng điện máy giả định tên VietMart có đội IT Support 6 người, xử lý sự cố cho 40 cửa hàng. Trước đây họ nhận yêu cầu qua email và Zalo, ai rảnh thì bốc việc. Kết quả: có bạn ôm 12 ticket cùng lúc, nhảy qua nhảy lại giữa các việc, ticket nào cũng dở dang, khách phàn nàn "báo mãi không thấy sửa".
Trưởng nhóm dựng một bảng Kanban trên Trello với các cột: Chờ tiếp nhận → Đang chẩn đoán → Đang xử lý → Chờ khách xác nhận → Xong. Anh áp dụng đúng nguyên lý "bắt đầu từ quy trình hiện tại" — không đổi vai trò ai cả. Sau đó đặt WIP limit cho cột "Đang xử lý" là 2 việc/người.
Kết quả sau một tháng: Cycle Time trung bình của một ticket giảm từ 4,5 ngày xuống còn 1,8 ngày. Lý do không phải vì đội làm nhanh hơn, mà vì họ ngừng làm nhiều việc cùng lúc. Khi bị chạm trần WIP, các bạn buộc phải đóng dứt điểm ticket đang làm trước khi bốc ticket mới.
Bài học: Giới hạn WIP không làm bạn làm ít hơn — nó làm bạn hoàn thành nhiều hơn. Việc nhảy qua lại giữa quá nhiều task (context switching) là kẻ giết chết năng suất thầm lặng.
Ví dụ 2 — Đội marketing của một startup fintech ở Singapore/Việt Nam
Một startup fintech giả định tên PayLane (văn phòng Singapore, đội nội dung ở Hà Nội) có đội marketing 5 người sản xuất nội dung: bài blog, video ngắn, thiết kế banner. Họ dùng bảng Kanban với cột Ý tưởng → Viết → Thiết kế → Duyệt → Đăng.
Vấn đề: cột "Duyệt" luôn ùn tắc vì chỉ có một Giám đốc Marketing được quyền duyệt, mà chị này thường xuyên đi công tác. Nhìn vào Cumulative Flow Diagram, dải màu của cột "Duyệt" phình to dần — bottleneck lộ rõ. Nội dung viết xong, thiết kế xong, nhưng nằm chờ duyệt cả tuần, khiến Cycle Time trung bình lên tới 9 ngày.
Áp dụng nguyên lý "khuyến khích lãnh đạo ở mọi cấp", một bạn content chủ động đề xuất: với các bài blog thường (không phải chiến dịch lớn), giao quyền duyệt cho trưởng nhóm nội dung, chỉ những chiến dịch quan trọng mới cần Giám đốc duyệt. Họ làm rõ chính sách này (make policies explicit) ngay trên bảng. Sau thay đổi, cột "Duyệt" thông thoáng, Cycle Time xuống còn 4 ngày.
Bài học: Bottleneck trong Kanban thường không nằm ở khâu "làm" mà ở khâu "chờ phê duyệt / chờ người khác". CFD giúp bạn nhìn thấy nó bằng dữ liệu, và cải tiến bằng cách thay đổi chính sách chứ không phải bắt mọi người làm việc cật lực hơn.
Ví dụ 3 — Đội DevOps chuyển từ Scrum sang Kanban
Một công ty phần mềm gia công (outsourcing) ở Đà Nẵng có đội DevOps 4 người. Họ từng cố ép mình theo Scrum với Sprint 2 tuần, nhưng thất bại: công việc của DevOps phần lớn là sự cố phát sinh bất ngờ (production down, cần vá gấp), không thể "khóa scope" trong 2 tuần như Scrum yêu cầu. Cứ nửa Sprint là kế hoạch vỡ.
Họ chuyển sang Kanban. Không còn Sprint, không còn planning cứng. Việc mới xuất hiện thì đưa lên cột "Backlog", ưu tiên theo mức độ khẩn, đội kéo việc theo hệ thống pull khi có chỗ trống trong WIP. Họ thêm một loại thẻ đặc biệt "Expedite" (đường ưu tiên nhanh) cho sự cố khẩn cấp, có làn riêng vượt qua WIP thông thường.
Kết quả: đội không còn cảm giác "kế hoạch Sprint lúc nào cũng sai". Họ đo throughput mỗi tuần (trung bình 11 việc hoàn thành/tuần) và dùng con số này để cam kết với khách hàng thay vì hứa theo Sprint.
Bài học: Kanban hợp với công việc có tính "dòng chảy liên tục và khó dự đoán" (vận hành, support, bảo trì) hơn là công việc dự án có phạm vi rõ ràng đóng gói theo đợt. Trong PMP, hãy nhớ tiêu chí này khi đề hỏi nên chọn Scrum hay Kanban.
Hướng dẫn từng bước
Nếu bạn muốn triển khai Kanban cho một đội thật, đây là lộ trình:
- Vẽ bảng theo đúng quy trình hiện tại. Ngồi cùng đội, liệt kê các bước công việc thực sự đi qua, biến chúng thành các cột. Đừng vẽ quy trình "lý tưởng" — vẽ quy trình "thật".
- Đưa hết việc đang có lên bảng. Mỗi việc là một thẻ. Mục tiêu là trực quan hóa: ai cũng nhìn thấy hiện đội đang ôm bao nhiêu việc, việc nào đang ở đâu.
- Xác định điểm bắt đầu và kết thúc rõ ràng. Quyết định "commitment point" (khi nào một việc chính thức được đội nhận làm) và "delivery point" (khi nào coi là giao xong) — đây là hai mốc để đo Cycle Time.
- Đặt WIP limit cho từng cột. Bắt đầu bằng con số hợp lý (ví dụ số người trong cột đó, hoặc số người × 1,5). Đừng cầu toàn — cứ đặt rồi điều chỉnh dần.
- Làm rõ chính sách (explicit policies). Định nghĩa rõ điều kiện để một thẻ được kéo sang cột kế tiếp. Ví dụ: "Việc chỉ rời cột Code khi đã có unit test và pass review."
- Vận hành theo pull. Khi hoàn thành một việc, kéo việc tiếp theo vào — chỉ khi còn chỗ trống dưới trần WIP.
- Đo lường: Cycle Time, Throughput, và vẽ CFD. Theo dõi theo thời gian để phát hiện bottleneck.
- Cải tiến liên tục. Định kỳ họp nhìn dữ liệu, hỏi "cột nào đang tắc?", "WIP nên tăng hay giảm?", và điều chỉnh.
Lỗi thường gặp & mẹo
Lỗi 1 — Đặt WIP limit quá cao (hoặc không đặt). Đây là lỗi phổ biến nhất. Nhiều đội dựng bảng Kanban đẹp nhưng bỏ qua WIP limit, và thế là bảng chỉ còn là "cái danh sách việc màu mè". Không có WIP limit thì không có Kanban thật sự. Mẹo: bắt đầu với WIP hơi thấp một chút để cảm nhận sức ép "phải hoàn thành trước khi bốc mới".
Lỗi 2 — Nhầm Cycle Time với Lead Time. Trong đề thi và cả thực tế, hãy nhớ: Lead Time là góc nhìn của khách hàng (từ lúc yêu cầu tới lúc nhận), Cycle Time là góc nhìn của đội (từ lúc bắt tay làm tới lúc xong).
Lỗi 3 — Coi Kanban là Scrum không có Sprint. Kanban không có vai trò bắt buộc, không có iteration cố định, không có ước lượng story point bắt buộc. Đừng gán ghép luật Scrum vào Kanban.
Lỗi 4 — Bỏ qua bottleneck. Khi một cột liên tục chạm trần WIP, đó là tín hiệu vàng chỉ ra nút thắt. Đừng chỉ tăng WIP để "cho việc chạy qua" — hãy hỏi vì sao nó tắc và giải quyết gốc rễ.
Mẹo cho kỳ thi PMP: Khi đề mô tả tình huống "quá nhiều việc dở dang, đội bị phân tán, việc mãi không xong", đáp án thường liên quan đến giới hạn WIP. Khi đề nói "cần nhìn thấy nghẽn ở đâu", nghĩ đến Cumulative Flow Diagram. Khi đề hỏi về công việc vận hành liên tục, khó chia đợt, hãy nghiêng về Kanban thay vì Scrum.
Bài tập thực hành
- Vẽ bảng của riêng bạn. Lấy một công việc thật của bạn (dự án, việc học, việc phòng ban) và vẽ bảng Kanban với các cột phản ánh đúng quy trình hiện tại. Đưa tất cả việc đang làm lên bảng.
- Đặt và thử WIP limit. Chọn cột "đang xử lý" và đặt một WIP limit. Trong một tuần, ghi lại cảm giác: có lúc nào bạn muốn bốc việc mới nhưng bị chặn vì chạm trần không? Việc đó buộc bạn làm gì?
- Tính Cycle Time. Chọn 5 việc bạn đã hoàn thành gần đây. Ghi lại ngày bắt đầu làm và ngày xong, tính Cycle Time từng việc rồi lấy trung bình. Sau đó thử tính Lead Time (từ ngày việc được đưa vào hàng chờ) và so sánh khoảng chênh lệch — đó chính là thời gian "chờ đợi vô ích".
- Áp dụng Little's Law. Giả sử đội bạn hoàn thành trung bình 10 việc/tuần (throughput) và thường ôm 30 việc dở (WIP). Cycle Time trung bình sẽ là bao nhiêu? (Đáp án: 30/10 = 3 tuần.) Bây giờ nếu giảm WIP xuống 15 mà giữ throughput, Cycle Time còn bao nhiêu?
- Câu hỏi tình huống PMP: Đội của bạn có một cột "Kiểm thử" luôn ứ đọng, các thẻ chất đống ở đó trong khi cột "Code" thì trống. Bạn nên làm gì đầu tiên? Hãy tự viết câu trả lời rồi đối chiếu với nguyên lý quản lý dòng chảy và xử lý bottleneck đã học.
Tóm tắt
- Kanban là phương pháp cải tiến dựa trên luồng, "đắp" lên quy trình hiện có chứ không lật đổ nó. Nó dùng hệ thống pull (kéo việc khi có chỗ) thay vì push.
- Bốn nguyên lý nền tảng: (1) Bắt đầu từ quy trình hiện tại; (2) Đồng thuận thay đổi từ từ, tăng dần; (3) Tôn trọng vai trò và chức danh hiện có; (4) Khuyến khích lãnh đạo ở mọi cấp.
- Sáu thực hành: Trực quan hóa, Giới hạn WIP, Quản lý dòng chảy, Làm rõ chính sách, Vòng phản hồi, Cải tiến cùng nhau.
- Ba thước đo cốt lõi: Flow (dòng chảy mượt), WIP (giới hạn việc dở dang — trái tim của Kanban, làm lộ bottleneck), Cycle Time (thời gian từ lúc làm đến lúc xong; đừng nhầm với Lead Time).
- Little's Law: Cycle Time = WIP / Throughput — cơ sở giải thích vì sao giảm WIP giúp việc xong nhanh hơn.
- Cumulative Flow Diagram giúp nhìn bottleneck bằng mắt.
- Kanban hợp nhất với công việc liên tục, khó dự đoán (vận hành, support, DevOps). Trong đề PMP, tình huống "quá nhiều việc dở" thường trỏ tới giải pháp giới hạn WIP.