Kanban: Không chỉ là Todo, Doing, Done – Phần 2

Trong phần trước, chúng ta đã biết được lịch sử Kanban và các nguyên lý cốt lõi của Kanban: Visualize, Limit WIP, Manage flow.

Trong phần này, chúng ta cùng tìm hiểu nhiều hơn về 2 phần rất quan trọng trong việc quản lý bằng Kanban.

• Visualizing your work
• Limit WIP

Visualizing your work

Kanban sử dụng 3 công cụ chính để trực quan hoá công việc: Board, Queues & Work Items.

Board gồm các column thể hiện trạng thái công việc, mỗi column là đại diện của hàng đợi Queue, trên mỗi hàng đợi là các Work Item

Type of board

Ngoài việc thiết kế bảng Kanban truyền thống như ở trên, Kanban board có thể điều chỉnh để phù hợp với bối cảnh của từng tổ chức, dưới đây là những cách cải tiến

The space saver

Thay vì luồng công việc dịch chuyển từ trái sang phải như thông thường thì để tiết kiệm không gian, các Work Item sẽ được di chuyển theo chiều kim đồng hồ

The HR web

Một bộ phận HR áp dụng Kanban ở Transpire đã có cách thiết kế bảng giống như 1 hình hexagon, các nguồn ứng viên khác nhau sẽ đến từ các cạnh, điểm cuối khi job đc offer sẽ là trung tâm.

Priority pyramid

Luồng công việc sẽ đi từ đáy lên trên đỉnh tháp, mỗi phần của tháp đều áp dụng triểt để Limit WIP

Physical board or Digital board

Đã có rất nhiều tranh luận nên dùng bảng vật lý (Physical board) hay bảng điện tử (JIRA/Trello) nhưng vì không thể có 1 đáp án đúng cho mọi trường hợp (No silver bulltet) nên chúng ta nên nắm được những ưu điểm của từng loại.

Digital board

• Là một nơi lưu trữ thông tin duy nhất, thành viên trong team có thể truy cập bất cứ ở đâu, bất cứ lúc nào
• Không bị mất dữ liêu như bảng vật lý (có thể bị rơi mất stickies hoặc bị xoá)
• Dễ dàng tổng hợp report metric.
• Dễ dàng sửa, xoá, xem chi tiết thông tin về các work items
• Có thể tích hợp với các công cụ khác để quản lý dễ dàng hơn (notification system, documentation system)

Physical board

• Thường to hơn so với bảng điện tử, từ đó các thành viên dễ dàng theo dõi
• Dễ dàng setup, chi phí thấp (chỉ cần 1 bức tường hoặc 1 bảng trắng)
• Dễ dàng thay đổi cấu trúc hoặc thêm các thông tin (vẽ/viết)

Chính team sẽ quyết định lựa chọn loại bảng nào để phù hợp với công việc (hoặc cả 2)

Queues

Mỗi queue thể hiện số lượng công việc trong cùng một trạng thái. Khi nhìn vào board, các thành viên trong nhóm có thể nhận diện rõ ràng công việc đang ở status như thế nào.

• Todo: Những việc cần làm
• Analyze: Những việc đang phân tích
• Development: Những việc đang phát triển
• Test: Những việc đang được kiểm thử
• Done: Những việc đang hoàn thành

Trong mỗi queue có thể có các queue (column) nhỏ hơn để phân biệt trạng thái chi tiết hơn (zoom-in board).

Bên cạnh đó các queue cũng cần có policy cụ thể, ví dụ “Development Done” nghĩa là chức năng đã được đưa lên môi trường DEV, Code coverage trên 85% và phải được review bởi toàn team.

Việc tạo các policy cụ thể, rõ ràng và trực quan là điều rất quan trọng, nó giảm bớt sự hiểu nhầm giữa các thành viên, tăng tốc quá trình chuyển trạng thái của các Work Items.

Work Items

Mỗi Work Item đại diện cho 1 đơn vị công việc, thường được viết trên 1 sticky (physical board) hoặc 1 e-card (digital board).

Card layout

• Nên có các thông tin như tiêu đề, PIC, due date, ID
• Tránh việc đưa quá nhiều hoặc quá ít thông tin lên 1 Work Item card, sẽ gây khó khăn cho việc review tổng thể
• Có thể dùng các màu sắc khác nhau cho từng loại công việc để nhận diện dễ dàng hơn

Có một cách để phát hiện ra các Work item đã quá lâu chưa thể thay đổi trạng thái đó là gán cho 1 chiếc vỏ chuối. Thời gian trôi qua và vỏ chuối sẽ đổi màu, đến khi nó trở thành màu đen thì đó thực sự là smell Work item.

Limit WIP

Chỉ trực quan hoá công việc là chưa đủ, nếu không có sự tập trung và phân bổ nguồn lực hợp lý thì rất dễ đến các công việc luôn bị dở dang, không thể hoàn thành.

Vậy làm thế nào để tìm ra limit WIP. Có một số tiêu chí để cân nhắc

• Lower is better than higher: Có ít việc dở dang luôn tốt hơn có nhiều. Đó là điều kiện để có thể có được “lead time” ngắn hơn (thời gian đưa sản phẩm đến customer) hay feedback loop nhanh hơn, giúp gỡ bỏ các rào cản (impediments) hiệu quả hơn.
• People idle or work idle: Khi có nhiều WIP thì mỗi công việc sẽ có khả năng bị delay nhiều hơn, ngược lại khi có quá ít WIP thì con người lại trở nên nhàn rỗi.
• There is no limits: Đây là lỗi thường mắc phải khi không set bất cứ giới hạn nào, nó sẽ dẫn tới rất nhiều rủi ro cho dự án.

Stop starting, start finishing

Thay vì khởi đầu những công việc mới thì hãy cố gắng hoàn thiện những công việc đang dang dở.

Limit WIP based on columns

Đây là cách đơn giản nhất để thực hiện limit WIP, trên mỗi một column (queue) set số lượng tối đa có thể kéo vào các Work item.

Giống như việc phân luồng giao thông, để có một tuyến đường thông suốt, mỗi chặng đường với độ rộng khác nhau sẽ có 1 lưu lượng phương tiện khác nhau. Nếu một đoạn đường rộng nối với đoạn đường quá hẹp thì bottleneck sẽ dễ xảy ra trên đoạn đường hẹp đó. Chính vì thế việc set giới hạn số lượng phương tiện trên đoạn đường rộng cho phù hợp với đoạn đường kế tiếp đó là cần thiết.

Trong phát triển phần mềm, giả sử nhóm có 4 developer & 1 tester, việc giới hạn ở column Development sẽ giảm tải cho việc ở column Test do chênh lệch về số lượng vị trí, điều đó dẫn tới khả năng delivery sản phẩm tốt hơn. Việc tìm ra trạng thái nào của công việc dễ bị overload cũng là điều quan trọng, từ đó có thể điều chỉnh giới hạn cho phù hợp.

Setting JIRA limit WIP

Limit WIP based on people

Cách tiếp theo là giới hạn công việc trên cá nhân nhưng lựa chọn con số limit cho các thành viên như nào thì hợp lý ?

Giả sử team có 5 người, WIP = 1, điều đó có nghĩa là nếu 1 người bị block, ngay lập tức công việc của các thành viên khác cũng sẽ bị block theo.

Nếu WIP = 2 thì có thể dẫn tới nếu 1 việc bị block, các thành viên sẽ chuyển sang làm việc thứ 2 và việc bị block sẽ vĩnh viễn không được giải quyết.

Con số được khuyên nên là 1.5, từ đó nhân với số lượng thành viên thì bằng WIP của cả nhóm.

Chú ý rằng sẽ không có con số nào là chính xác hoàn toàn, chúng ta phải tìm ra con số phù hợp theo tình hình của team hay của dự án.

Tạm kết

Bài tổng hợp đến đây đã khá dài, cảm ơn đã dành thời gian đọc đến đây. Trong phần cuối chúng ta sẽ tìm hiểu những phần liên quan đến Kanban như việc estimate, planning, retrospective, reporting & Kanban pitfall.

References

• Various Types of Kanban boards
• Kanban in action