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
SDLC&STLC
1. Tổng quan nền tảng về quy trình phát triển và kiểm thử phần mềm Trong bất kỳ một dự án công nghệ thông tin nào, dù là ứng dụng di động nhỏ hay hệ thống phần mềm doanh nghiệp khổng lồ, việc để sản phẩm đi đến thành công không thể dựa vào sự […]
Kanban vs Scrum, Scrumban và phần nâng cao
Kanban vs Scrum, Scrumban và phần nâng cao So sánh Kanban và Scrum Tiêu chí Kanban Scrum Bản chất Phương pháp quản lý dòng chảy liên tục Framework phát triển theo chu kỳ Nhịp làm việc Dòng chảy liên tục Khung thời gian cố định (Sprint 1-4 tuần) Cam kết phạm vi Theo khả năng […]
Backlog Refinement, ước lượng, công cụ thực tế
Backlog Refinement, ước lượng, công cụ thực tế Backlog Refinement Là hoạt động làm rõ Product Backlog: chia nhỏ, làm rõ, ước lượng, sắp xếp lại các item khi cần. Ví dụ ban đầu backlog có một mục “Product Search” quá to. Sau khi refine thì tách thành: Search UI, Search API, Search by name, […]
Scrum cơ bản, vai trò và các sự kiện
Scrum cơ bản, vai trò và các sự kiện Scrum sinh ra để làm gì? Hiểu Agile xong thì sẽ nảy ra câu hỏi: Agile bảo phản hồi nhanh, thích nghi, cải tiến liên tục, nhưng làm thật thì tổ chức công việc kiểu gì? Scrum ra đời để trả lời câu đó. Theo Scrum […]
12 nguyên tắc, feedback loop và mấy khái niệm liên quan
12 nguyên tắc, feedback loop và mấy khái niệm liên quan 12 nguyên tắc Agile Nếu 4 giá trị là tư tưởng thì 12 nguyên tắc là cách biến tư tưởng đó thành hướng đi thực tế. Giao hàng sớm và liên tục (Early and continuous delivery) Đưa phần mềm có giá trị đến tay […]
Agile là gì, và 4 giá trị cốt lõi
Agile là gì, và 4 giá trị cốt lõi Agile thực sự là gì? Agile nghĩa là linh hoạt, thích nghi. Nó là một bộ giá trị và nguyên tắc để định hướng cách làm phần mềm, chứ không phải một framework cố định, cũng không phải quy trình bắt mọi team phải làm y […]
Khoá học lập trình game con rắn cho trẻ em 
