Kanban từ đâu ra và nó thực chất là gì
Chuyện bắt đầu ở Nhật
Sau Thế chiến 2 (1945), kinh tế Nhật tan hoang: thiếu vốn, thiếu tài nguyên, hạ tầng bị phá nát. Ngành ô tô Nhật lúc đó gặp bài toán sống còn: thị trường cần nhiều mẫu mã nhưng mỗi mẫu số lượng ít, mà phải cạnh tranh với mấy ông khổng lồ Mỹ đang chơi sản xuất hàng loạt (Mass Production).
Cách làm của Mỹ là sản xuất thật nhiều để giảm chi phí trên từng sản phẩm. Nhược điểm là hàng tồn kho chất đống, tốn vốn, tốn chỗ chứa, lại còn dễ hỏng hoặc lỗi thời. Toyota nhìn ra một điều: làm nhiều không có nghĩa là tạo ra nhiều giá trị.
Taiichi Ohno và Toyota Production System (TPS)
Kỹ sư Taiichi Ohno là người đặt nền móng cho TPS, mục tiêu là loại bỏ triệt để lãng phí (tiếng Nhật gọi là Muda) và làm cả hệ thống chạy hiệu quả hơn. TPS đứng trên hai trụ:
- Just-in-Time (JIT): chỉ làm đúng thứ cần, đúng số lượng, đúng lúc cần.
- Jidoka: tự động hóa nhưng có yếu tố con người. Hệ thống tự phát hiện bất thường và dừng ngay khi có lỗi, không để lỗi chạy tiếp sang công đoạn sau.
Kanban và cơ chế Pull
Kanban (看板) tiếng Nhật nghĩa là “bảng hiệu”, “biển báo”, hay “thẻ tín hiệu”. Ở nhà máy Toyota, ban đầu nó chỉ là mấy tấm thẻ giấy hoặc kim loại dùng để báo tin giữa các công đoạn.
Điểm hay là Toyota dùng Pull System (hệ thống kéo) thay vì Push System (hệ thống đẩy). Push là công đoạn trước cứ làm rồi đẩy sang công đoạn sau, bất kể bên sau có kịp nhận không. Còn Pull thì chạy kiểu này:
- Công đoạn sau dùng hết vật tư
- Nó gửi một thẻ Kanban về công đoạn trước để báo cần bổ sung
- Công đoạn trước nhận tín hiệu và làm đúng số lượng được yêu cầu
- Vật tư mới được chuyển tới chỗ cần dùng
Tức là có nhu cầu thật thì mới làm, không làm dư.
Kanban chui vào ngành phần mềm
Năm 2004, David J. Anderson bắt đầu áp dụng tư duy Kanban vào phát triển phần mềm và CNTT tại Microsoft. Đến 2010 ông ra cuốn sách kinh điển “Kanban: Successful Evolutionary Change for Your Technology Business”, từ đó Kanban chính thức thành một phương pháp cho công việc trí óc (Knowledge Work).
Khác biệt chính: ở nhà máy thì thứ di chuyển là linh kiện thật (ốc vít, động cơ), còn trong phần mềm thứ di chuyển là mấy hạng mục công việc vô hình như 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 công việc đó trong môi trường hay biến động và khó đoán.
Kanban thực chất là gì?
Kanban là phương pháp quản lý nhằm tối ưu dòng chảy công việc (Work Flow), dựa trên 4 trụ cột:
- Trực quan hóa công việc
- Giới hạn số việc đang làm cùng lúc (WIP, Work in Progress)
- Quản lý và đo lường luồng công việc
- Liên tục cải tiến hệ thống
Push vs Pull trong phần mềm
- Push: việc cứ bị giao dồn vào theo kế hoạch trên giấy, bất kể người làm còn sức hay không. Hậu quả là việc tồn đọng, dòng chảy nghẽn, và mất công chuyển đổi ngữ cảnh liên tục (Context Switching, tức là đang làm cái này phải nhảy qua cái kia).
- Pull: thành viên chỉ chủ động “kéo” việc mới vào làm khi còn năng lực (Capacity) và việc đó đáp ứng tiêu chuẩn ưu tiên.
Just-in-Time trong phần mềm
Ở đây JIT nghĩa là trì hoãn cam kết làm một thứ cho đến thời điểm muộn nhất có thể (gọi là Last Responsible Moment). Lý do là để không phí công sức vào tính năng chưa thật sự cần hoặc yêu cầu còn mơ hồ.
Dòng chảy liên tục
Thay vì dồn việc rồi bàn giao một cục to vào cuối Sprint hay cuối dự án (Batch processing), Kanban khuyến khích phát hành tính năng ngay khi nó sẵn sàng và đạt chuẩn chất lượng.
Kanban với Agile
- Agile là tập giá trị và nguyên tắc tư duy (nằm trong Agile Manifesto).
- Kanban là một phương pháp quản lý cụ thể, giúp thực thi và hỗ trợ tư duy Agile.
- Kanban không thuộc khung chuẩn của Agile Manifesto, nhưng dùng chung với môi trường Agile rất hợp.
Bài viết khác
Test Automation(Kiểm thử tự động)
1.Test Automation (Kiểm thử tự động) là gì? Trong các dự án phát triển phần mềm truyền thống trước đây, toàn bộ quy trình kiểm thử (Testing) đều được thực hiện thủ công (Manual Testing) bởi con người. Các kiểm thử viên trực tiếp thao tác trên giao diện, nhập dữ liệu, kiểm tra kết […]
Logging – Monitoring – CI/CD
Logging, Monitoring và CI/CD là gì? Vai trò trong phát triển Backend 1. Tổng quan Khi xây dựng một ứng dụng Backend, viết code và chạy được chương trình mới chỉ là bước đầu. Khi ứng dụng được đưa vào sử dụng, lập trình viên còn cần biết ứng dụng đang hoạt động như thế […]
Redis & Caching là gì?
Redis & Caching là gì? Hướng dẫn sử dụng Redis trong Go 1. Caching là gì? Vì sao cần cache khi đã có database? Caching (bộ nhớ đệm) là kỹ thuật lưu tạm dữ liệu thường được truy cập để có thể lấy lại nhanh chóng khi cần, thay vì phải thực hiện lại toàn […]
Background Jobs & Queues
1. Background Jobs & Queues là gì? Trong một ứng dụng backend, không phải công việc nào cũng cần hoàn thành ngay trong lúc xử lý HTTP request. Ví dụ, khi người dùng đăng ký tài khoản, hệ thống có thể cần: Lưu thông tin người dùng vào database. Gửi email xác nhận. Gửi thông […]
Saga Pattern
Saga Pattern là gì? Quản lý Transaction trong kiến trúc Microservices 1. Saga Pattern là gì? Saga Pattern là một mẫu thiết kế được sử dụng để quản lý các nghiệp vụ phân tán gồm nhiều bước xử lý, trong đó mỗi bước có thể thực hiện một local transaction tại một service hoặc Database […]
Two-Phase Locking (2PL)
Two-Phase Locking (2PL) là gì? Cơ chế khóa hai pha trong Database 1. Two-Phase Locking (2PL) là gì? Two-Phase Locking (2PL — khóa hai pha) là một giao thức quản lý khóa trong Database, quy định cách một transaction được phép lấy và giải phóng lock trong quá trình thực thi. Khi nhiều transaction cùng […]
Khoá học lập trình game con rắn cho trẻ em 
