Kanban board (KB) không quá xa lạ với chúng ta. Chúng ta dễ dàng bắt gặp KB ở bất kỳ đâu trong công ty phần mềm. Một bảng vật lý với giấy note sticker dán đầy, một màn hình với 3 cột đơn giản: To do | Work in progress | Done. Đó là hình thức của một ứng dụng / một phương thức quản lý công việc không thể tiện hơn. Thế nhưng, bạn có chắc là bạn đang sử dụng nó hiệu quả không ? Bản thân mình trước đây cũng chỉ nghĩ đơn giản" KB như bảng quản lý danh sách công việc (tasks list) nhằm để minh bạch công việc (transparency). Cho đến khi được đọc và học sâu hơn về kiến thức PM, bản thân một dự án / team có thể sử dụng KB tốt hơn nếu hiểu và tuân thủ theo những nguyên tắc của KB. Hãy cùng khám phá bên dưới nhé

A/ Kanban board

Kanban board sơ khai là bảng quản lý công việc bắt nguồn công ty nhật Toyota. Vâng, đúng là vậy, công ty sản xuất linh kiện xe hơi, mục tiêu chính của KB ra đời là để giảm lãng phí, tạo ra nhiều giá trị hơn bằng cách minh bạch quy trình thực hiện công việc qua 3 trạng thái: To do | Doing | Done (nhiều nơi sau này áp dụng là Work In Progress - WIP). Việc quản lý trực quan, xác định nhanh độ ưu tiên công việc giúp KB trở nên nổi tiếng và áp dụng được nhiều vào các lãnh vực khác.

B/ Nguyên tắc của Kanban

Theo lý thuyết dự án, KB mang trong mình vài nguyên tắc cơ bản

1. Visualize workflow: Điểm mạnh nhất của KB là minh bạch quy trình. Nếu bản thân công việc của bạn cảm thấy không thể vẽ được quy trình một cách rõ ràng thì xem chừng bạn khó thể áp dụng được KB đấy
2. Limit WIP: Đây là quy tắc quan trọng nhất của KB và cũng là ... quy tắc hay bị vi phạm nhất trong KB. Limit WIP dịch ra là hạn chế tối đa các công việc đang thực hiện, giúp team phát hiện những điểm thắt nút cổ chai trong công việc (Bottleneck). Việc hạn chế WIP giúp công việc được xử lý nhanh hơn, đúng theo tinh thần Agile đã đề ra
3. Manage flow: Việc minh bạch quy trình, giúp team đo được tốc độ, thời gian xử lý của công việc trong quy trình định sẵn. Giúp cấp quản lý tối ưu hơn, tăng năng suất cho dự án / team
4. Process policies explicit: Việc chuyển công việc giữa các cột phải được định nghĩa rõ ràng. Các khái niệm như DOR (Definition of Ready) / DOD (Definition of Done) đều cần được xác định rõ khi team thực hiện, chuyển trạng thái giữa các cột
5. Improve collaboratively: Áp dụng pull-based (phương thức kéo việc về thực hiện), chủ động minh bạch công việc trong team, phối hợp thực hiện công việc theo tinh thần Agile đề ra

C/ Bạn có biết sử dụng Kanban sao cho đúng

C.1/ Kanban chính là ... Agile Framework

Vâng, đó là Agile, bạn sử dụng KB là đang áp dụng Agile. Có nhiều bạn có lẽ vẫn mơ hồ về Agile, KB được cho là Agile Framework vì KB được tạo ra để ủng hộ 4 phát biểu tuyên ngôn của Agile và tuân theo các nguyên tắc của Agile

Mình không có ý định nhắc lại tuyên ngôn hoặc nguyên lý. Các bạn có thể tìm hiểu nó tại đây: https://agilemanifesto.org/

Chung quy, thứ mình muốn nhấn mạnh: vì KB là theo tinh thần Agile nên sử dụng bản thân người PM (Project Manager) / Leader vẫn phải luôn ghi nhớ các giá trị mà Agile đề xuất về quy trình, con người để làm sao phát huy hiệu quả tính nhất của công cụ. Thêm nữa, vì là Agile Framework nên KB sẽ mang theo trong mình một số tính chấ như transparency, Adaptation, Inspection, ... tương tự như Scrum hay Xp.

C.2/ Có chắc bạn biết Limit WIP

Theo bạn limit WIP là gì? Dấu hiệu cơ bản của những KB mình thường thấy là ... có rất nhiều task nằm ở cột WIP và nhiều bạn làm rất nhiều task WIP. Điều này là rất không ổn trong một dự án / team làm Agile. Theo quan điểm của quản lý công việc, bạn không thể làm song song nhiều việc cùng 1 lúc, nên khó có thể tồn tại những công việc WIP trong 1 ngày hoặc ít nhất là trong 2 ngày gần nhất. Hãy đảm bảo rằng bạn,một PM / Leader kiểm soát được công việc của team khi các member pull quá nhiều task WIP nhé

Best practices cho việc limit WIP theo cách của mình hay áp dụng

• Hãy quy định về rule limit WIP: Không task / feature nào được WIP quá lâu trong 1 hoặc 2 ngày (thường là 1.5 ngày). Nếu tồn tại thì có thể task cần refinement (định nghĩa làm rõ lại), hoặc workflow của bạn thiết kế đang có vấn đề (cần tách bạch workflow như nếu task cần được test rồi mới review trước khi done thì nên thêm 2 cột TEST và REVIEW) hoặc các member kéo task có vấn đề (không cập nhật task)
• DSM (daily standup meeting) để reflect các task trên KB: Vâng, chính xác là nên họp để cập nhật task, các câu hỏi hôm qua, hôm nay làm gì chính là xác định WIP trên KB. Hãy đảm bảo các thành viên tập trung vào 1 task cụ thể, và dành effort để kéo task sang trạng thái khác. Sức mạnh của WIP nằm phần focus (tập trung), collaborate (phối hợp) để giải quyết task, và đừng quên cập nhật các vấn đề (blockers, issues) vào KB, đó cũng là công việc cần thảo luận & xử lý trong team
• Đừng quên Definition of Ready / Definition of Done: Nghe có vẻ xa lạ với KB, nhưng khái niệm Agile này sẽ giúp team bạn hoạt động hiệu quả hơn. Hãy coach cho member trả lời câu hỏi: Bạn có chắc mình bắt đầu làm task này chưa ? Bạn có chắc task này done chưa ? Kỹ thuật này giúp team focus vào giá trị của từng task, ví dụ định nghĩa mini DOD cho việc test xong ở khi kéo task từ TEST sang REVIEW, mini DOD cho việc kéo từ REVIEW sang DONE. Nó sẽ giúp hạn chế nợ kỹ thuật (Technical Debt) khi task flow đến cuối quy trình đấy

C.3/ Kanban tối ưu cho Linear Workflow - Luồng việc tuyến tính

Mô hình thông thường của KB sẽ là To do > WIP > Done. Tất nhiên nó thường đúng với mọi quy trình công việc, nhưng thường mình thấy nó chưa đủ. Lời khuyên là hãy thiết kế KB của bạn để làm sao áp dụng được quy tắc Limit WIP và có được DOD trong mỗi bước (stage) của quy trình

Ví dụ quy trình tính năng mình hay áp dụng cho công ty phát triển sản phẩm phần mềm

NEW > TO DO > WILL DO > DEVELOPMENT > TESTING > REVIEW > DONE > RELEASE

Khá dài đúng không, nhưng đảm bảo được các task / feature được kiểm soát theo từng chặn mini DOD và các thành viên nắm được thông tin minh bạch của task / feature. Các task / feature bị trả về cũng được audit / log nhằm mục đích xác định root cause và tăng hiệu suất cho team nữa. Nên hãy chọn và thống nhất trong team mình quy trình làm việc hiệu quả nhất nhé

C.4/ Task / Feature Refinement

Khái niệm refinement / grooming được nghe rất nhiều trong Scrum, chắc ít ai nghe là thực hiện nó trong KB. Việc refinement là áp dụng theo tinh thần của Agile - Adaptation. Bạn không thể để 1 task / feature quá lớn trong quy trình của mình, đó là vi phạm Limit WIP, đây là lúc cần refinement. Vài nguyên tắc của refinement của mình hay khuyến khích áp dụng trong team

• Task / feature không được quá lớn. Thường những task được estimate trên 1 ngày rưỡi đều nên được chia lại cho nhỏ hơn
• Các task / feature tồn tại ở 1 stage trên 1 ngày hơn thì nên được thảo luận ở DSM (Daily Standup Meeting) để brainstorm tìm giải pháp. Có thể nghiên cứu áp dụng các phương thức swarming / mobbing trong agile để xử lý teamwork cùng nhau xử lý
• Đảm bảo các task / feature đều phải thỏa mãn được DOD (ví dụ unit test được, nghiệm thu được, ...). Consider nếu là phát triển tính năng sản phẩm thì có thể sử dụng concept của user story (thuộc tính I.N.V.E.S.T) để kiểm định độ lớn, giá trị của task / feature

C.5/ Đừng quên nghi thức của Agile

Việc áp dụng KB không đồng nghĩa với việc không phải tuân thủ theo nghi thức của Agile như Review, Retrospective, ... Hãy nhớ rằng KB chỉ là phương thức, kỹ thuật quản lý công việc đội nhóm. Team vẫn có thể tổ chức các buổi meeting nếu thật sự cần thiết. Ví dụ team có thể vẫn giữ các nghi thức meeting như sau

• DSM - Daily Standup meeting: Buổi daily bên cạnh KB để cập nhật WIP và vấn đề vào board
• Review : Team mình vẫn giữ nghi thức review mỗi bi-weekly, việc kéo card DONE sang RELEASE thì vẫn giữ buổi demo và commit giữa members, review các card đã đủ DOD (mini DOD for release stage) và lên rollout lên production
• Retrospective: Keep ít nhất 2 tuần 1 lần để cùng team improve cách làm việc (ways of working) nha các bạn

D/ In practice - Thực tế thì sao

Mỗi dự án, team sẽ có quy định riêng. Tùy thuộc theo tính chất dự án / sản phẩm mà quy trình trên kanban sẽ khác nhau. Công ty hiện tại mình đang làm việc với nhiều dự án, có dự án chạy SCRUM, có dự án mình đang chuyển đổi sang chạy KB vài lý do sau

• Dự án / sản phẩm không nhất thiết cần planning định kỳ theo iteration
• Do tính phức tạp cần theo dõi stage của dự án / sản phẩm nên mình thấy áp dụng KB sẽ minh bạch thông tin hơn. Ví dụ sản phẩm bên mình sẽ cần release & rollout theo greyscale (% user) để đảm bảo tính ổn định cho user
• Các tính chất phức tạp do nhiều sub-app nhỏ trên app lớn nên việc chia theo feature và quản lý release mình áp dụng trên KB khá hiệu quả

Về tools, mình thường sử dụng JIRA (policy công ty sử dụng JIRA On-prem), nhưng các bạn có thể sử dụng các ứng dụng KB khác đơn giản khác như Trello, Asana, ... Hãy nhớ KB tools sử dụng hiệu quả hay không là do các định hướng từ PM / Leader đối với team, team cần đồng thuận sử dụng để phát huy tối đa hiệu quả nhé. Nếu có thắc mắc gì thêm, đừng ngại liên hệ mình qua email hoặc comment trong bài viết nhé

Link trello Kanban: https://trello.com/b/XKQmmlh3/pmstarter

E/ Kết luận

Kanban thực sự hữu ích, việc minh bạch công việc, dán note cùng team, thảo luận xung quanh bảng công việc là một cách tuyệt vời để tăng tính gắn kết và phối hợp trong team. Hãy luôn nhớ rằng, chung quy Kanban vẫn là công cụ, sẽ vẫn rất cần kỹ năng của một PM / Leader thật sự hiểu được cách sử dụng công cụ đó để phát triển cùng team. Đừng ngại học hỏi, áp dụng, trải nghiệm và đúc kết bài học. Đó là cách nhanh nhất để mình và team cải thiện, ngày một tốt hơn nhé.