1. NGUỒN GỐC KANBAN: TỪ TOYOTA ĐẾN NGÀNH PHẦN MỀM
1.1. Bối cảnh ra đời tại Nhật Bản
Sau Thế chiến thứ hai (1945), nền kinh tế Nhật Bản rơi vào tình trạng kiệt quệ với nguồn vốn hạn chế, tài nguyên thiên nhiên khan hiếm và cơ sở hạ tầng bị phá hủy. Ngành công nghiệp ô tô Nhật Bản thời bấy giờ phải đối mặt với bài toán sinh tồn: làm thế nào để đáp ứng nhu cầu thị trường đa dạng nhưng số lượng nhỏ, mà vẫn có thể cạnh tranh với các tập đoàn ô tô khổng lồ của Mỹ (vốn đang áp dụng mô hình sản xuất hàng loạt – Mass Production)?
Mô hình sản xuất truyền thống của Mỹ tập trung tối ưu hóa chi phí trên từng đơn vị sản phẩm bằng cách sản xuất khối lượng lớn. Hạn chế của mô hình này là tạo ra lượng lớn hàng tồn kho (Inventory), gây lãng phí vốn, không gian lưu trữ và tiềm ẩn rủi ro hỏng hóc hoặc lỗi thời. Toyota nhận thấy rằng: Sản xuất nhiều không đồng nghĩa với việc tạo ra nhiều giá trị.
1.2. Taiichi Ohno và Toyota Production System (TPS)
Kỹ sư Taiichi Ohno là người đặt nền móng cho Hệ thống Sản xuất Toyota (Toyota Production System – TPS). TPS được xây dựng nhằm mục tiêu loại bỏ triệt để lãng phí (Muda) và cải thiện hiệu suất vận hành toàn hệ thống.
Hai trụ cột chính của TPS bao gồm:
-
Just-in-Time (JIT): Chỉ sản xuất đúng sản phẩm, đúng số lượng, và đúng thời điểm cần thiết.
-
Jidoka (Tự động hóa có yếu tố con người): Xây dựng cơ chế tự động phát hiện bất thường và dừng quy trình ngay khi xuất hiện lỗi, ngăn chặn lỗi lan truyền sang công đoạn sau.
1.3. Khái niệm Kanban và cơ chế Pull System
Trong tiếng Nhật, Kanban (看板) có nghĩa là “bảng hiệu”, “biển báo” hoặc “thẻ tín hiệu”. Trong nhà máy Toyota, Kanban ban đầu là các thẻ tín hiệu bằng giấy hoặc kim loại dùng để truyền thông tin giữa các công đoạn sản xuất.
Khác với mô hình Push System (đẩy hàng từ công đoạn trước sang công đoạn sau bất chấp khả năng tiếp nhận), Toyota áp dụng Pull System (hệ thống kéo):
-
Công đoạn phía sau tiêu thụ vật tư.
-
Khi cần bổ sung, công đoạn phía sau phát ra một tín hiệu Kanban gửi về công đoạn phía trước.
-
Công đoạn phía trước nhận tín hiệu và tiến hành sản xuất đúng số lượng được yêu cầu.
-
Vật tư mới được chuyển tới nơi tiêu thụ.
1.4. Dịch chuyển sang phát triển phần mềm
Năm 2004, David J. Anderson bắt đầu nghiên cứu và áp dụng tư duy Kanban vào mảng phát triển phần mềm và CNTT tại Microsoft. Đến năm 2010, ông xuất bản cuốn sách kinh điển “Kanban: Successful Evolutionary Change for Your Technology Business”, chính thức đặt nền móng cho Phương pháp Kanban trong công việc trí óc (Knowledge Work).
Khác biệt cốt lõi: Trong sản xuất, đối tượng quản lý là linh kiện vật lý (ốc vít, động cơ). Trong phần mềm, đối tượng chuyển dịch là các hạng mục công việc phi vật thể (tính năng, API, giao diện, lỗi bảo mật, yêu cầu thay đổi). Kanban giúp quản lý dòng chảy tri thức trong một môi trường có biến động cao và khó dự đoán.
2. BẢN CHẤT VÀ TRIẾT LÝ CỦA KANBAN
2.1. Định nghĩa
Kanban là một phương pháp quản lý nhằm tối ưu hóa dòng chảy công việc (Work Flow) thông qua 4 trụ cột chính:
-
Trực quan hóa công việc.
-
Giới hạn công việc đang thực hiện (Work in Progress – WIP).
-
Quản lý và đo lường luồng công việc.
-
Liên tục cải tiến hệ thống.
Kanban không áp đặt cấu trúc tổ chức, không bắt buộc các vai trò cố định (như Scrum Master, Product Owner) và không chia cố định theo các khung thời gian (Sprint).
2.2. So sánh Push System và Pull System
-
Push System (Hệ thống Đẩy): Công việc được giao hoặc đẩy liên tục vào hệ thống dựa trên kế hoạch theoretical, mặc cho khả năng xử lý thực tế của nhân sự. Hậu quả là tồn đọng công việc, nghẽn dòng chảy và tăng chi phí chuyển đổi ngữ cảnh (Context Switching).
-
Pull System (Hệ thống Kéo): Thành viên chỉ chủ động “kéo” hạng mục công việc mới vào xử lý khi công đoạn đó còn năng lực (Capacity) và đáp ứng các tiêu chuẩn ưu tiên.
2.3. Just-in-Time (JIT) trong phần mềm
JIT trong CNTT định hướng việc trì hoãn cam kết phát triển (Commitment Point) cho đến thời điểm muộn nhất có thể (Last Responsible Moment), nhằm tránh việc lãng phí nguồn lực cho các tính năng chưa thực sự cần thiết hoặc yêu cầu chưa rõ ràng.
2.4. Dòng chảy liên tục (Continuous Flow)
Thay vì tích lũy công việc để bàn giao theo lô lớn (Batch processing) vào cuối Sprint hay cuối kỳ dự án, Kanban khuyến khích việc phát hành các tính năng ngay khi chúng sẵn sàng và đáp ứng đủ tiêu chuẩn chất lượng.
2.5. Mối quan hệ giữa Kanban và Agile
-
Agile là một tập hợp các giá trị và nguyên tắc tư duy (trình bày trong Agile Manifesto).
-
Kanban là một phương pháp luận quản lý cụ thể giúp thực thi và bổ trợ cho tư duy Agile. Kanban không thuộc framework chuẩn hóa của Agile Manifesto nhưng hoàn toàn tương thích với môi trường Agile.
3. CƠ CHẾ VẬN HÀNH CỦA KANBAN
3.1. Bảng Kanban (Kanban Board)
Bảng Kanban là công cụ trực quan hóa toàn bộ quy trình làm việc. Bảng chia thành các cột đại diện cho trạng thái của công việc.
Ví dụ về cấu trúc bảng đơn giản:
$$\text{Backlog} \longrightarrow \text{Ready} \longrightarrow \text{In Progress} \longrightarrow \text{Code Review} \longrightarrow \text{Testing} \longrightarrow \text{Done}$$
3.2. Thẻ Kanban (Kanban Card)
Mỗi hạng mục công việc được biểu diễn bằng một thẻ chứa thông tin cơ bản:
-
Mã định danh (ID), Tên hạng mục, Mô tả ngắn.
-
Người phụ trách (Assignee), Mức độ ưu tiên (Priority).
-
Tiêu chí nghiệm thu (Acceptance Criteria).
-
Lý do bị tắc nghẽn (Blocked Reason – nếu có).
3.3. Giới hạn công việc đang thực hiện (WIP Limit)
WIP Limit là số lượng hạng mục tối đa được phép tồn tại ở một hoặc một nhóm trạng thái tại một thời điểm.
| Trạng thái | WIP Limit |
| Backlog / Ready | Không giới hạn |
| In Progress | 3 |
| Code Review | 2 |
| Testing | 2 |
| Done | Không giới hạn |
Nguyên lý WIP: Giảm WIP giúp hoàn thành công việc nhanh hơn. Khi đặt WIP Limit, đội ngũ bị buộc phải tập trung giải quyết triệt để các hạng mục dang dở trước khi bắt tay vào việc mới, qua đó giảm thời gian chờ (Queue Time) và giảm chi phí chuyển đổi bối cảnh.
3.4. Điểm nghẽn (Bottleneck)
Bottleneck là công đoạn có năng lực xử lý thấp hơn lưu lượng công việc đi qua nó, khiến công việc bị tích tụ phía trước và gây “đói việc” ở các công đoạn sau. Việc phát hiện điểm nghẽn cho phép đội ngũ tập trung nguồn lực tháo gỡ thay vì tiếp tục đẩy việc vào hệ thống.
3.5. Các chỉ số đo lường cốt lõi
[Thời điểm tiếp nhận yêu cầu] -------- (Lead Time) --------> [Hoàn thành]
[Bắt đầu xử lý] --(Cycle Time)--> [Hoàn thành]
-
Lead Time: Khoảng thời gian từ lúc yêu cầu được ghi nhận/cam kết đến khi hoàn thành toàn bộ.
-
Cycle Time: Khoảng thời gian thực tế từ khi bắt tay vào thực hiện hạng mục đến khi hoàn thành.
-
Throughput (Thông lượng): Số lượng hạng mục hoàn thành trong một đơn vị thời gian (ví dụ: 10 tasks/tuần).
3.6. Biểu đồ dòng chảy tích lũy (Cumulative Flow Diagram – CFD)
CFD là biểu đồ khu vực xếp chồng (Stacked Area Chart) thể hiện số lượng hạng mục công việc ở từng trạng thái theo thời gian. CFD giúp phân tích:
-
Tốc độ tích tụ công việc.
-
Sự ổn định của Cycle Time (khoảng cách giữa các đường).
-
Biến động của tổng WIP (khoảng cách đứng giữa đường đầu và đường cuối).
4. NGUYÊN TẮC VÀ THỰC HÀNH CỐT LÕI
Phương pháp Kanban (theo David J. Anderson) bao gồm 4 nguyên tắc nền tảng và 6 thực hành cốt lõi:
4.1. Bốn nguyên tắc nền tảng
-
Bắt đầu với những gì bạn đang làm: Không yêu cầu tái cấu trúc tổ chức ngay lập tức; áp dụng trực tiếp lên quy trình hiện tại.
-
Đồng ý theo đuổi thay đổi tiến hóa: Cải tiến từng bước nhỏ, có đo lường và đánh giá thay vì thay đổi toàn diện gây xáo trộn.
-
Khuyến khích hành động lãnh đạo ở mọi cấp độ: Mọi cá nhân đều có quyền đề xuất cải tiến dòng công việc.
-
Tôn trọng các vai trò, trách nhiệm và chức danh hiện tại: Giữ nguyên cơ cấu nhân sự ban đầu để giảm thiểu tâm lý chống đối thay đổi.
4.2. Sáu thực hành cốt lõi
-
Visualize (Trực quan hóa): Hiển thị rõ công việc và quy trình trên Bảng Kanban.
-
Limit WIP (Giới hạn công việc đang thực hiện): Đặt ngưỡng tối đa cho các công đoạn.
-
Manage Flow (Quản lý dòng chảy): Theo dõi, tối ưu hóa sự di chuyển của công việc, giảm thiểu điểm nghẽn.
-
Make Policies Explicit (Công khai chính sách): Quy định rõ ràng điều kiện để một task được chuyển trạng thái (Process Policies).
-
Implement Feedback Loops (Thiết lập các nhịp phản hồi): Duy trì các cuộc họp kiểm tra, đánh giá dòng chảy định kỳ (như Daily Kanban, Replenishment, Service Delivery Review).
-
Improve Collaboratively, Evolve Experimentally (Cải tiến cộng tác, phát triển qua thử nghiệm): Sử dụng dữ liệu định lượng và phương pháp khoa học để cải tiến quy trình.
5. ÁP DỤNG KANBAN TRONG THỰC TẾ THỰC HIỆN DỰ ÁN
5.1. Định nghĩa chuẩn Hoàn thành (Definition of Done – DoD)
DoD là tập hợp các tiêu chuẩn kỹ thuật và vận hành bắt buộc để một hạng mục được coi là hoàn tất hoàn toàn.
-
Phân biệt: Acceptance Criteria áp dụng cho từng yêu cầu cụ thể của một tính năng; Definition of Done áp dụng chung cho tất cả các hạng mục công việc đi qua quy trình.
5.2. Vận hành Daily Kanban Meeting
Khác với Daily Scrum (tập trung vào báo cáo cá nhân với 3 câu hỏi), Daily Kanban tập trung vào sự di chuyển của các thẻ trên bảng:
-
Rà soát từ phải qua trái (ưu tiên các task gần cột Done nhất).
-
Xử lý các hạng mục bị Blocked hoặc vượt quá WIP Limit.
-
Thảo luận giải pháp giải phóng dòng chảy.
5.3. Quản lý công việc sự cố và khẩn cấp (Classes of Service)
Kanban phân loại công việc theo mức độ rủi ro và chi phí do sự chậm trễ (Cost of Delay):
-
Expedite (Khẩn cấp): Chi phí chậm trễ cực kỳ cao (ví dụ: sập hệ thống thanh toán). Được phép vượt WIP Limit nhưng giới hạn nghiêm ngặt chỉ 1 task tại một thời điểm trên toàn hệ thống.
-
Fixed Date (Ngày cố định): Có hạn chót cố định về mặt pháp lý hoặc sự kiện kinh doanh.
-
Standard (Tiêu chuẩn): Công việc thông thường quy chuẩn.
-
Intangible (Phi vật thể/Dài hạn): Cải thiện nợ kỹ thuật (Technical Debt), tối ưu hạ tầng; chi phí chậm trễ thấp ở hiện tại nhưng cao trong tương lai.
6. SO SÁNH KANBAN, SCRUM VÀ SCRUMBAN
| Tiêu chí | Kanban | Scrum |
| Bản chất | Phương pháp quản lý dòng chảy continuous | Framework phát triển phần mềm theo chu kỳ |
| Nhịp làm việc | Dòng chảy liên tục (Continuous Flow) | Khung thời gian cố định (Sprint 1-4 tuần) |
| Cam kết phạm vi | Theo khả năng tiếp nhận (Capacity-based) | Cam kết theo Sprint Goal |
| Thay đổi ưu tiên | Bất kỳ lúc nào (tại cột Ready/Backlog) | Hạn chế thay đổi mục tiêu trong Sprint |
| Vai trò bắt buộc | Không quy định | Product Owner, Scrum Master, Developers |
| Chỉ số đo lường | Lead Time, Cycle Time, Throughput | Velocity, Sprint Burndown |
Scrumban là gì?
Scrumban là mô hình lai (Hybrid), kết hợp tính cấu trúc của Scrum (sử dụng Sprint Planning, Retrospective) với khả năng linh hoạt và quản lý WIP của Kanban (sử dụng Kanban Board, WIP Limit, đo lường Cycle Time).
7. KANBAN NÂNG CAO: TỐI ƯU HÓA HỆ THỐNG DÒNG CHẢY
7.1. Định luật Little (Little’s Law)
Ứng dụng từ lý thuyết hàng đợi vào quản lý dòng chảy:
$$WIP = Throughput \times Lead\ Time \quad \implies \quad Lead\ Time = \frac{WIP}{Throughput}$$
Ý nghĩa: Trong một hệ thống ổn định, nếu giữ nguyên Throughput, phương thức duy nhất để giảm thời gian hoàn thành (Lead Time) là giảm lượng công việc dở dang (WIP).
7.2. Kỳ vọng Cấp độ Dịch vụ (Service Level Expectation – SLE)
SLE là mảng dự báo xác suất dựa trên dữ liệu lịch sử Cycle Time.
Ví dụ: “85% các hạng mục công việc được hoàn thành trong vòng 5 ngày làm việc hoặc ít hơn.” Đây là cơ sở để đưa ra cam kết với khách hàng dựa trên dữ liệu thống kê định lượng thay vì ước tính cảm tính.
7.3. Hiệu suất Dòng chảy (Flow Efficiency)
Flow Efficiency đo lường tỷ lệ thời gian công việc thực sự được xử lý (Active Time) so với tổng thời gian hạng mục đó nằm trong hệ thống (Lead Time):
$$\text{Flow Efficiency} = \frac{\text{Active Time}}{\text{Lead Time}} \times 100\%$$
Trong hầu hết các tổ chức phần mềm chưa tối ưu, Flow Efficiency thường rơi vào mức khá thấp (10% – 20%), nghĩa là 80% – 90% thời gian còn lại công việc nằm ở trạng thái chờ (Idle Time/Queue Time).
7.4. Mô hình Trưởng thành Kanban (Kanban Maturity Model – KMM)
KMM phân định 6 cấp độ trưởng thành của tổ chức trong việc áp dụng Kanban:
-
Level 0 (Oblivious): Chưa nhận thức được dòng chảy công việc.
-
Level 1 (Emerging): Bắt đầu trực quan hóa ở mức độ cá nhân/nhóm nhỏ.
-
Level 2 (Defined): Quy trình và chính sách làm việc được định nghĩa rõ ràng.
-
Level 3 (Managed): Quản lý định hướng dịch vụ, định lượng được hiệu suất dòng chảy.
-
Level 4 (Quantitatively Managed): Sử dụng mô hình thống kê để dự báo và kiểm soát chất lượng.
-
Level 5 (Optimizing): Cải tiến liên tục trên quy mô toàn tập đoàn.
8. TỔNG KẾT VÀ BÀI HỌC CỐT LÕI
-
Kanban không chỉ đơn thuần là bảng điều khiển công việc (Task Board), mà là hệ thống tư duy tối ưu hóa dòng chảy giá trị.
-
Bản chất của việc giới hạn WIP là ngừng bắt đầu công việc mới để tập trung hoàn thành các công việc cũ (“Stop Starting, Start Finishing”).
-
Lựa chọn mô hình (Kanban, Scrum, hay Scrumban) phụ thuộc hoàn toàn vào mức độ biến động của công việc, tính chất sản phẩm và mức độ trưởng thành của đội ngũ.
-
Mục tiêu cuối cùng của quản lý dự án không phải là duy trì trạng thái bận rộn 100% của nhân sự, mà là tối ưu tốc độ và chất lượng chuyển giao giá trị đến tay người dùng cuối.
Bài viết khác
SCRUM
Framework phát triển sản phẩm dựa trên Agile 3.1. Scrum ra đời để giải quyết vấn đề gì? Sau khi hiểu Agile, sẽ xuất hiện một câu hỏi: Agile nói rằng team cần phản hồi nhanh, thích nghi và liên tục cải tiến. Nhưng làm thế nào để tổ chức công việc thực tế? Đó […]
AGILE
2.1. Agile bắt đầu xuất hiện như thế nào? Trước năm 2001, nhiều phương pháp phát triển phần mềm đã được hình thành nhằm giải quyết những khó khăn của các dự án phần mềm truyền thống. Một số phương pháp tiêu biểu: Extreme Programming (XP) // lập trình cực hạn, tập trung vào phản […]
Waterfall: Tưởng đâu làm tuần tự là chill… ai ngờ kill
WATERFALL Mô hình phát triển phần mềm tuần tự 1.1. Trước Agile: thế giới phần mềm làm việc như thế nào? Trước khi các phương pháp Agile phổ biến, một tư duy phát triển thường gặp là: Muốn xây dựng một hệ thống lớn thì trước tiên phải lập kế hoạch thật kỹ, sau đó […]
TỔNG HỢP KIẾN THỨC GIT CƠ BẢN
TỔNG HỢP KIẾN THỨC GIT CƠ BẢN 1. Git là gì? Git là một hệ thống quản lý phiên bản phân tán (Distributed Version Control System – DVCS), được sử dụng để lưu trữ, quản lý và theo dõi những thay đổi trong mã nguồn, dữ liệu và các tệp tin của một dự án. […]
Làm việc hiệu quả : đẩy tiến độ công việc trong vùng xám và hoàn thành
Là một người chịu trách nhiệm 1 đôi nhóm xây dựng 1 tính năng, 1 công việc, hoặc là 1 thành viên của đội nhóm, bất kì ai cũng muốn mọi thứ rõ ràng. Thiết kế rõ ràng, quy trình rõ ràng, tính năng rõ ràng, mục đích đạt được rõ ràng v.v Trên thực […]
Khoá học lập trình game con rắn cho trẻ em 
