Kanban là gì?
Kanban là một từ tiếng Nhật, thường được hiểu là “thẻ tín hiệu” hoặc “biển báo”. Kanban có nguồn gốc từ hệ thống sản xuất của Toyota, trong đó các tín hiệu trực quan được sử dụng để báo nhu cầu bổ sung vật tư hoặc công việc giữa các công đoạn. Cách làm này giúp giảm lãng phí và cải thiện hiệu quả của quy trình.
Trong Kanban, công việc và luồng công việc được trực quan hóa để mọi người có thể dễ dàng theo dõi trạng thái của công việc, đồng thời phát hiện các vấn đề và điểm nghẽn trong quy trình. Từ đó, nhóm có thể đưa ra những thay đổi để cải thiện dòng chảy của công việc.
Kanban là một phương pháp quản lý luồng công việc, thường được sử dụng trong môi trường Agile. Khác với Scrum, Kanban không yêu cầu công việc phải được thực hiện trong các Sprint có thời lượng cố định. Công việc có thể được thực hiện theo một luồng liên tục, khi một công việc hoàn thành thì công việc tiếp theo có thể được đưa vào dựa trên năng lực của quy trình.
Kanban tập trung vào việc trực quan hóa workflow, giới hạn lượng công việc đang thực hiện và liên tục cải thiện dòng chảy của công việc. Vì vậy, Kanban có thể hỗ trợ các giá trị và nguyên tắc của Agile mà không cần sử dụng Sprint hay một chu kỳ phát triển cố định.
Kanban và Agile
Agile là một cách tiếp cận trong phát triển phần mềm, dựa trên các giá trị và nguyên tắc nhằm giúp nhóm thích ứng tốt hơn với những thay đổi trong quá trình phát triển. Agile đề cao việc tạo ra giá trị sớm, nhận phản hồi thường xuyên, phối hợp giữa các bên và liên tục cải thiện cách làm việc.
Kanban là một phương pháp quản lý luồng công việc, tập trung vào việc trực quan hóa workflow, giới hạn công việc đang thực hiện và cải thiện dòng chảy của công việc. Kanban không phải là một framework hay một quy trình cụ thể để triển khai Agile, nhưng có thể được sử dụng trong môi trường Agile và hỗ trợ nhiều giá trị, nguyên tắc của Agile như khả năng thích ứng với thay đổi, minh bạch và cải tiến liên tục.
Một điểm khác biệt đáng chú ý là Agile không quy định một quy trình làm việc cụ thể, trong khi Kanban cung cấp những thực hành cụ thể để quản lý workflow. Tuy nhiên, Kanban không yêu cầu nhóm phải làm việc theo các Sprint có thời lượng cố định như Scrum.
Tại sao cần Kanban?
1. Khó nhìn thấy toàn bộ công việc
Trong một nhóm, nếu công việc nằm rải rác qua tin nhắn, email, ghi chú…, rất khó biết:
- Đang có bao nhiêu việc?
- Việc nào đang làm?
- Việc nào bị trì hoãn?
- Việc nào đang chờ người khác?
→ Kanban trực quan hóa workflow để mọi người có cùng một cái nhìn về công việc.
2. Làm quá nhiều việc cùng lúc
Một vấn đề phổ biến là nhóm bắt đầu quá nhiều công việc cùng lúc, dẫn đến:
- chuyển đổi liên tục giữa các công việc;
- nhiều task cùng dở dang;
- công việc hoàn thành chậm.
→ WIP Limit giúp giới hạn số lượng công việc đang được thực hiện trong workflow, từ đó nhóm tập trung hoàn thành công việc thay vì liên tục bắt đầu việc mới.
3. Công việc bị tắc nghẽn
Development → Code Review → Testing → Done
Nhóm Development có thể hoàn thành nhiều task, nhưng nếu Code Review chỉ xử lý được 2 task thì công việc sẽ dồn lại ở đó.
→ Kanban giúp nhìn thấy bottleneck và cho phép nhóm tập trung xử lý điểm nghẽn thay vì tiếp tục tạo thêm công việc.
4. Yêu cầu và ưu tiên thay đổi liên tục
Không phải mọi công việc đều có thể được xác định cố định từ đầu. Khi có yêu cầu mới hoặc ưu tiên thay đổi, Kanban cho phép nhóm điều chỉnh thứ tự công việc trong backlog mà không yêu cầu phải chờ đến cuối một Sprint.
→ Điều này phù hợp với những workflow có công việc đến liên tục và khó dự đoán.
5. Khó cải thiện quy trình
Nếu chỉ biết “công việc đã hoàn thành hay chưa” thì rất khó biết vì sao quy trình chậm.
Kanban giúp nhóm quan sát workflow và sử dụng các dữ liệu về quy trình, chẳng hạn Cycle Time, để phát hiện những nơi cần cải thiện.
6. Cần giao giá trị liên tục
Kanban không yêu cầu nhóm phải chờ đến cuối một Sprint mới hoàn thành một nhóm công việc. Khi một công việc hoàn thành và workflow có đủ năng lực, công việc tiếp theo có thể được kéo vào.
→ Điều này giúp công việc được xử lý theo dòng chảy liên tục (Continuous Flow) thay vì phải chờ một chu kỳ cố định.
Bảng Kanban
Bảng Kanban là một công cụ trực quan hóa workflow, thường được chia thành các cột đại diện cho các trạng thái hoặc giai đoạn khác nhau của công việc, chẳng hạn như “Việc cần làm”, “Đang tiến hành”, “Đang kiểm thử” và “Đã hoàn thành”.
Mỗi công việc được biểu diễn bằng một thẻ (card) và được di chuyển qua các cột khi trạng thái của công việc thay đổi. Nhờ đó, nhóm có thể dễ dàng theo dõi công việc đang ở đâu, phát hiện những công việc bị tồn đọng và nhận biết các điểm nghẽn trong workflow.
Các cột và trạng thái trên bảng có thể được thiết kế dựa trên workflow thực tế của nhóm. Ngoài việc trực quan hóa công việc, bảng Kanban còn có thể kết hợp với WIP Limit để giới hạn số lượng công việc đang được thực hiện ở một trạng thái, từ đó giúp nhóm kiểm soát và cải thiện dòng chảy của công việc.
Thẻ Kanban
Các thẻ đại diện cho các nhiệm vụ hoặc hạng mục công việc riêng lẻ và được di chuyển qua các giai đoạn khác nhau trên bảng Kanban. Mỗi thẻ chứa những thông tin cần thiết về công việc, chẳng hạn như mô tả, người phụ trách, ngày đến hạn và các chi tiết liên quan.
Các thẻ có thể được mã hóa màu hoặc gắn nhãn để thể hiện loại công việc, mức độ ưu tiên hoặc các danh mục khác nhau. Khi công việc tiến triển, thẻ được di chuyển giữa các cột trên bảng, giúp nhóm dễ dàng theo dõi trạng thái hiện tại của từng công việc.
Bảng Kanban và các thẻ kết hợp với nhau giúp trực quan hóa workflow của nhóm. Nhờ đó, các thành viên có thể dễ dàng nhìn thấy những công việc cần thực hiện, công việc nào đang được xử lý, ai đang phụ trách và những công việc nào đã hoàn thành.
Các nguyên tắc/thực hành cốt lõi
Trực quan hóa workflow
Công việc tri thức thường khó nhìn thấy trực tiếp trạng thái và tiến độ như các công việc vật lý. Vì vậy, Kanban sử dụng các công cụ trực quan như bảng và thẻ để biểu diễn công việc cùng workflow của nhóm.
Việc trực quan hóa giúp các thành viên có thể nhìn thấy công việc đang ở đâu, công việc nào đang được thực hiện, công việc nào bị tồn đọng và những khu vực có khả năng xuất hiện điểm nghẽn.
Giới hạn WIP
WIP (Work in Progress) là lượng công việc đang được thực hiện nhưng chưa hoàn thành. Kanban sử dụng WIP Limit để giới hạn số lượng công việc có thể được thực hiện đồng thời trong một trạng thái hoặc một phần của workflow.
Việc giới hạn WIP giúp nhóm giảm việc làm quá nhiều thứ cùng lúc, dễ nhận biết các vấn đề và tập trung hoàn thành công việc đang tồn đọng thay vì liên tục bắt đầu công việc mới.
WIP Limit cũng hỗ trợ cơ chế Pull. Khi workflow có đủ năng lực để tiếp nhận công việc mới và không vượt quá giới hạn WIP, công việc tiếp theo có thể được kéo vào workflow.
Quản lý flow
Sau khi trực quan hóa workflow và giới hạn WIP, nhóm cần theo dõi cách công việc di chuyển qua workflow.
Thông qua việc quan sát flow, nhóm có thể phát hiện các công việc bị tồn đọng, thời gian xử lý kéo dài hoặc những điểm nghẽn trong workflow. Từ đó, nhóm có thể thực hiện các thay đổi và quan sát kết quả để tìm ra cách cải thiện flow.
Làm rõ các chính sách của workflow
Các quy tắc của workflow cần được xác định rõ để mọi thành viên có cùng cách hiểu về cách công việc được thực hiện.
Ví dụ, nhóm có thể quy định một công việc chỉ được chuyển từ Development sang Code Review khi code đã được hoàn thành và đáp ứng các điều kiện kiểm tra cần thiết.
Việc làm rõ các chính sách giúp giảm sự mơ hồ, tạo ra sự nhất quán trong cách làm việc và giúp nhóm có cơ sở rõ ràng để thảo luận về những thay đổi trong workflow.
Triển khai các feedback loop
Kanban sử dụng các vòng phản hồi để nhóm thường xuyên kiểm tra workflow, kết quả và các vấn đề phát sinh.
Feedback loop có thể được thực hiện thông qua nhiều hình thức khác nhau, chẳng hạn như các cuộc họp xem xét workflow, thảo luận về công việc tồn đọng hoặc đánh giá các chỉ số của quy trình. Kanban không yêu cầu một loại cuộc họp cố định như Scrum, mà nhóm có thể lựa chọn cơ chế phản hồi phù hợp với workflow của mình.
Cải tiến liên tục
Kanban hướng đến việc liên tục cải thiện workflow dựa trên những gì nhóm quan sát được trong quá trình làm việc.
Thay vì thay đổi toàn bộ quy trình cùng một lúc, nhóm có thể thực hiện những thay đổi nhỏ, quan sát kết quả và tiếp tục điều chỉnh khi cần thiết. Qua đó, workflow có thể được cải thiện dần dựa trên dữ liệu và kinh nghiệm thực tế.
WIP là gì?
WIP là viết tắt của Work in Progress hoặc Work in Process, thường được hiểu là công việc đang thực hiện. WIP dùng để chỉ những công việc đã được bắt đầu nhưng chưa hoàn thành.
Trong lĩnh vực sản xuất, WIP là những sản phẩm đã bắt đầu quá trình sản xuất nhưng chưa trở thành thành phẩm. Những sản phẩm này đã tiêu tốn nguyên vật liệu, nhân công và các nguồn lực khác nhưng vẫn chưa thể xuất xưởng.
Trong phát triển phần mềm, WIP có thể là các task, bug, feature hoặc hạng mục công việc đang được xử lý nhưng chưa hoàn thành. Ví dụ, trên một bảng Kanban, các công việc đang nằm ở cột Development, Code Review hoặc Testing có thể được xem là WIP.
Việc theo dõi và giới hạn WIP là một phần quan trọng trong Kanban. Thay vì bắt đầu càng nhiều công việc càng tốt, nhóm cố gắng duy trì một lượng công việc đang thực hiện phù hợp với năng lực của workflow, từ đó giúp giảm tồn đọng và cải thiện flow.
Các bước cơ bản để triển khai Kanban
Bước 1: Xác định và trực quan hóa workflow
Để triển khai Kanban, trước tiên cần xác định quy trình làm việc thực tế của nhóm, từ khi một công việc được bắt đầu cho đến khi hoàn thành.
Sau đó, trực quan hóa workflow này bằng một bảng Kanban. Mỗi cột đại diện cho một trạng thái hoặc giai đoạn của công việc. Ví dụ, một workflow trong phát triển phần mềm có thể gồm Backlog → Development → Code Review → Testing → Done.
Bước 2: Thiết lập WIP Limit
Sau khi xác định workflow, nhóm có thể thiết lập WIP Limit cho một hoặc một số trạng thái trong workflow. WIP Limit xác định số lượng công việc tối đa có thể cùng tồn tại ở một trạng thái hoặc một phần của workflow tại một thời điểm.
Việc giới hạn WIP giúp nhóm tránh bắt đầu quá nhiều công việc cùng lúc, tập trung hoàn thành công việc đang tồn đọng và dễ nhận biết các điểm nghẽn trong workflow.
WIP Limit không nhất thiết phải có cùng một giá trị cho tất cả các cột. Nhóm có thể điều chỉnh giới hạn dựa trên năng lực và đặc điểm của từng bước trong workflow.
Bước 3: Tạo và đưa công việc lên bảng
Mỗi công việc được biểu diễn bằng một thẻ trên bảng Kanban. Thẻ có thể chứa các thông tin như tiêu đề, mô tả, người phụ trách, mức độ ưu tiên, thời hạn và các thông tin liên quan khác.
Nhóm có thể sử dụng màu sắc hoặc nhãn để phân loại công việc, chẳng hạn như loại công việc hoặc mức độ ưu tiên. Đây là những quy ước do nhóm tự thiết lập để bảng phù hợp với workflow thực tế.
Bước 4: Thực hiện công việc theo cơ chế Pull
Khi bắt đầu làm việc, các thành viên thực hiện những công việc phù hợp với trạng thái hiện tại của workflow. Khi một công việc hoàn thành một bước và workflow phía sau có đủ năng lực tiếp nhận, công việc có thể được pull sang bước tiếp theo.
Nhóm cần theo dõi WIP Limit trong quá trình này. Nếu một bước đã đạt giới hạn WIP, thay vì tiếp tục đưa thêm công việc vào bước đó, nhóm nên tập trung xử lý những công việc đang tồn đọng để khơi thông flow.
Nếu xuất hiện vấn đề hoặc điểm nghẽn, nhóm có thể điều chỉnh cách làm việc để cải thiện flow.
Bước 5: Theo dõi và cải tiến Kanban
Kanban không phải là một hệ thống được thiết lập một lần rồi giữ nguyên. Nhóm cần thường xuyên quan sát workflow, thu thập phản hồi và tìm kiếm những vấn đề cần cải thiện.
Các chỉ số như WIP, Cycle Time và Throughput có thể được sử dụng để hiểu rõ hơn về hiệu quả của workflow. Dựa trên những quan sát và dữ liệu này, nhóm có thể điều chỉnh workflow, WIP Limit hoặc các chính sách làm việc khi cần thiết.
Việc cải tiến nên được thực hiện từng bước, sau đó quan sát kết quả và tiếp tục điều chỉnh dựa trên những gì nhóm thực sự nhận thấy trong quá trình làm việc.
Kanban vs Scrum
Sự khác biệt quan trọng giữa Kanban và Scrum là Kanban là một phương pháp quản lý workflow, trong khi Scrum là một framework để phát triển và quản lý sản phẩm trong môi trường phức tạp.
Kanban tập trung vào việc trực quan hóa workflow, giới hạn WIP, quản lý flow và cải tiến liên tục. Kanban không yêu cầu nhóm phải làm việc theo các Sprint có thời lượng cố định. Công việc có thể được thực hiện theo một luồng liên tục và được đưa vào workflow khi có đủ năng lực.
Scrum tổ chức công việc trong các Sprint có thời lượng cố định, với một hệ thống accountabilities, artifacts và events được xác định rõ. Mỗi Sprint hướng đến việc tạo ra một Increment có giá trị và nhóm thường xuyên kiểm tra kết quả để điều chỉnh hướng phát triển.
Một điểm khác biệt đáng chú ý là cách hai phương pháp tổ chức công việc. Kanban tập trung vào tối ưu hóa flow của công việc trong workflow, trong khi Scrum tổ chức công việc theo Sprint và Sprint Goal.
| Kanban | Scrum | |
|---|---|---|
| Bản chất | Phương pháp quản lý workflow | Framework |
| Tổ chức công việc | Theo flow | Theo Sprint |
| Sprint | Không yêu cầu | Có, tối đa 1 tháng |
| WIP Limit | Là một thực hành quan trọng | Không phải yêu cầu của Scrum |
| Vai trò/accountabilities | Không quy định bộ accountabilities như Scrum | Product Owner, Scrum Master, Developers |
| Events | Không quy định bộ event cố định | Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective |
| Trọng tâm | Flow và cải tiến workflow | Tạo Increment và thích ứng thông qua Sprint |
| Phân phối | Có thể theo continuous flow | Có thể phát hành Increment bất cứ khi nào phù hợp |
Việc lựa chọn Kanban hay Scrum phụ thuộc vào đặc điểm của nhóm và công việc. Nếu workflow có công việc đến liên tục, ưu tiên thường xuyên thay đổi và nhóm muốn tập trung vào việc tối ưu flow, Kanban có thể phù hợp. Nếu nhóm cần một framework có cấu trúc rõ ràng với Sprint, Sprint Goal và các sự kiện cụ thể để tổ chức quá trình phát triển, Scrum có thể phù hợp hơn.
Ngoài ra, Kanban và Scrum không nhất thiết phải được xem là hai lựa chọn loại trừ lẫn nhau. Một nhóm có thể áp dụng một số thực hành của Kanban trong Scrum, chẳng hạn như trực quan hóa workflow và sử dụng WIP Limit để cải thiện flow.
Ưu và nhược điểm của Kanban
Kanban có nhiều ưu điểm trong việc trực quan hóa và quản lý workflow, nhưng cũng có một số hạn chế cần lưu ý khi áp dụng.
Ưu điểm
- Minh bạch và dễ theo dõi công việc: Kanban giúp trực quan hóa công việc và workflow, cho phép các thành viên dễ dàng theo dõi trạng thái của từng công việc và nhận biết những công việc đang tồn đọng hoặc gặp vấn đề.
- Quản lý công việc linh hoạt: Kanban không yêu cầu các Sprint có thời lượng cố định. Công việc có thể được đưa vào workflow, thay đổi thứ tự ưu tiên hoặc điều chỉnh khi nhu cầu thay đổi, miễn là vẫn phù hợp với workflow và các chính sách của nhóm.
- Giúp cải thiện hiệu quả workflow: Việc giới hạn WIP giúp nhóm giảm số lượng công việc được thực hiện đồng thời, hạn chế việc chuyển đổi ngữ cảnh và tập trung hoàn thành công việc đang tồn đọng. Qua đó, nhóm có thể cải thiện flow của công việc.
- Dễ phát hiện điểm nghẽn: Khi công việc được trực quan hóa trên bảng, những khu vực bị tồn đọng hoặc quá tải có thể dễ dàng được nhận biết. Điều này giúp nhóm xác định bottleneck và tìm cách cải thiện workflow.
- Linh hoạt và dễ thích nghi: Kanban không yêu cầu nhóm phải thay đổi toàn bộ quy trình hiện tại ngay từ đầu. Nhóm có thể bắt đầu bằng việc trực quan hóa workflow hiện tại, sau đó từng bước áp dụng WIP Limit và các thực hành khác để cải tiến.
Nhược điểm
- Không có timebox cố định: Kanban không tổ chức công việc trong các Sprint có thời lượng cố định như Scrum. Vì vậy, nếu nhóm cần lập kế hoạch theo các mốc thời gian cố định, cần sử dụng thêm dữ liệu của workflow như Cycle Time và Throughput để dự đoán thời gian hoàn thành.
- Cần duy trì tính chính xác của bảng: Kanban phụ thuộc nhiều vào việc workflow được trực quan hóa chính xác. Nếu các thành viên không cập nhật trạng thái công việc, bảng có thể nhanh chóng trở nên lỗi thời và không còn phản ánh đúng tình trạng thực tế.
- Workflow phức tạp có thể khó trực quan hóa: Khi có quá nhiều trạng thái, dependency hoặc nhiều luồng công việc khác nhau, bảng Kanban có thể trở nên phức tạp và khó theo dõi. Khi đó, cần thiết kế lại cách trực quan hóa hoặc chia workflow thành những phần phù hợp hơn.
- Không tự đảm bảo sản phẩm đạt mục tiêu: Kanban tập trung mạnh vào việc quản lý và cải thiện workflow. Nếu nhóm chỉ tập trung vào việc hoàn thành và di chuyển các công việc mà không quan tâm đầy đủ đến mục tiêu và giá trị cần tạo ra, việc tối ưu workflow không đồng nghĩa với việc sản phẩm chắc chắn đạt được kết quả mong muốn.
Kết luận
Kanban là một phương pháp quản lý workflow tập trung vào việc trực quan hóa công việc, giới hạn WIP, quản lý flow và cải tiến liên tục. Thay vì yêu cầu nhóm phải làm việc theo các Sprint có thời lượng cố định, Kanban cho phép công việc được thực hiện theo một luồng liên tục và thích nghi với những thay đổi trong quá trình làm việc.
Bằng cách làm cho workflow trở nên minh bạch, giới hạn lượng công việc đang thực hiện và thường xuyên quan sát, phản hồi và cải tiến, Kanban giúp nhóm dễ dàng nhận biết các điểm nghẽn và tìm cách cải thiện cách làm việc.
Tuy nhiên, Kanban không phải là một giải pháp phù hợp với mọi tình huống. Việc áp dụng Kanban hiệu quả phụ thuộc vào đặc điểm của workflow, loại công việc và mục tiêu của nhóm. Quan trọng nhất không phải là tạo ra một bảng Kanban đẹp hay di chuyển các thẻ công việc, mà là sử dụng bảng và các thực hành của Kanban để hiểu, quản lý và liên tục cải thiện flow của công việc.
Nguồn tham khảo
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 […]
Kanban từ đâu ra và nó thực chất là gì
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 […]
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 […]
Khoá học lập trình game con rắn cho trẻ em 
