Nào, chúng ta cùng nói về Kanban

Tôi quyết định viết bài này vì một bài viết rất thú vị khác cũng trên Spiderum mang tên "Tư duy Agile". Rất dễ hiểu, dễ hình dung, kể cả với những người không làm việc trong ngành phần mềm. Các bạn nên đọc bài này trước khi đọc tiếp những phần dưới bài viết của tôi. 

Nói về Agile, thường người ta chỉ nói về Scrum. Thậm chí hiện tại chứng chỉ đáng giá nhất từ Agile để làm việc trong ngành phần mềm cũng là Scrum Master. Tuy nhiên, Agile không chỉ có Scrum, và Scrum cũng không thể hiện được hết toàn bộ các tính chất của Agile. Hơn nữa theo tư duy linh hoạt của Agile, sẽ có những lúc Scrum không hiệu quả, và khi đó người ta cần mô hình khác để bổ sung. Trong Agile còn có DSDM (Dynamic Systems Development Method), XP (Extreme Programming), FDD (Feature-driven Development)... và Kanban - mô hình nổi tiếng không kém cạnh Scrum (mặc dù chúng ta không có Kanban master) và bổ sung rất tốt cho Scrum. Bài viết này sẽ nói rõ hơn (một chút) về Kanban cũng như vì sao Kanban là một trong những mô hình hữu dụng không chỉ trong sản xuất phần mềm. 

- Scrum chia nhân sự thành các nhóm nhỏ, có thể trao đổi chức năng cho nhau, và mỗi nhóm này đều có khả năng tự tổ chức. 

- Scrum chia dự án thành các phần nhỏ (deliverables), và các phần này đều có thể được hoàn thành và giao lại cho khách hàng theo từng gói nhỏ. Các phần này sẽ được sắp xếp theo thứ tự ưu tiên cũng như thời gian cần thiết để hoàn thành

- Scrum chia tổng thời gian hoàn thành dự án thành các bước nhỏ (từ 2-4 tuần) với phần code được hoàn thành sau mỗi bước

- Scrum tối ưu hóa kế hoạch giao tiếp với khách hàng, thu nhập ý kiến từ khách hàng và thay đổi ngay trong từng bước

- Scrum tối ưu hóa quy trình bằng cách có một cuộc họp tổng kết (retro) sau mỗi bước

Khác với mô hình Waterfall (thác nước) truyền thống, khi mà một đội lớn sẽ hoàn thành sản phẩm trong một thời gian dài, Scrum chia nhỏ khối lượng công việc, chia nhỏ nhân sự nhưng thường xuyên trao đổi, kết hợp với nhau để đảm bảo tiến độ, chất lượng của dự án tổng. 

Đối với Scrum, một số vai trò rất quan trọng, và buộc phải có, đó là:

- Product Owner (Người chịu trách nhiệm cho sản phẩm, hoặc trong nhiều trường hợp, chính là quản lý dự án): PO là "cầu nối" giữa đội sản xuất và khách hàng trong trường hợp đơn giản nhất, còn trong trường hợp phức tạp hơn là tất cả các bên liên quan đến dự án. Ngoài là người hiểu các vấn đề kỹ thuật, PO còn phải nắm rõ các khía cạnh về tài chính, nhân lực của dự án để đảm bảo ROI (Return on Investment - Tỷ lệ lợi nhuận ròng) cho dự án (hoặc phần anh ta chịu trách nhiệm trong dự án lớn). 

- Scrum Master (Quản lý Scrum): Nói một cách nôm na thì đây là người hiểu toàn bộ các quy tắc của Scrum và... cầm roi để đảm bảo tất cả mọi người đều làm theo bộ quy tắc của Scrum. Trong mô hình Waterfall thì Quản lý dự án thường là người kiêm luôn việc này, nhưng đối với Scrum thì không.

- Scrum Team (Đội Scrum): Nô lệ cho Scrum Master, đùa thôi, những con người chăm chỉ làm việc ngày đêm để đem đến sản phẩm tốt nhất. Đối với Scrum thì Scrum Master không cần thiết phải  phân chia công việc, đưa ra kế hoạch, bởi Scrum Team sẽ có thể tự phân chia linh hoạt về mặt công việc với nhau.

Scrum là mô hình phù hợp với những dự án có quy mô cố định (fixed scope); tuy nhiên, bởi tính chất của Scrum là phải theo những quy tắc nhất định, nên việc chỉ sử dụng Scrum sẽ khiến đội sản xuất chịu nhiều áp lực hơn khi dự án xảy ra vấn đề. Đó là khi mà dead-line đến rất gần mà ngày nào cũng họp với hành đến phát mợt. 

"Kanban" tiếng Nhật có nghĩa là "Bảng minh họa". Vào cuối những năm 1940, Taiichi Ohno phát minh ra mô hình này để cải thiện hiệu suất lao động trong nhà máy ô tô. Về cơ bản:

- Kanban minh họa quy trình làm việc bằng bảng trắng và thẻ để ghi cụ thể các tác vụ. Người dùng Kanban sẽ sử dụng các cột liền nhau để minh họa các bước trong quy trình làm việc, và mỗi thẻ tác vụ sẽ nằm ở trong một cột. 

- Kanban giới hạn WIP (Work-in-progress - Tác vụ đang tiến hành). Đội sản xuất sẽ quyết định số lượng tác vụ mà bạn có thể hoàn thành. Bằng cách này, đội sản xuất sẽ không gặp phải tình trạng bị quá tải dẫn đến hiệu suất và chất lượng đều giảm

- Kanban tập trung vào cải thiện quy trình. Đội sản xuất sẽ cần phải phân tích, đo lường, và cải thiện quy trình để đảm bảo sẽ luôn luôn có cải tiến trong tương lai.

- Kanban chú trọng vấn đề liên tục cải thiện. Một khi áp dụng Kanban vào quy trình sản xuất, đội sản xuất sẽ cần phải liên tục theo sát quy trình, chất lượng, và đặc biệt là khoảng thời gian sản xuất (lead time). 

Đối với Kanban, vai trò không quan trọng bằng quy trình. Vậy nên chúng ta sẽ không có Kanban Master, Kanban Team, Product Owner như đối với Scrum. Kanban linh hoạt hơn, và giúp cho đội sản xuất có thể thích nghi tốt hơn với tình hình. Tuy nhiên, Kanban không phù hợp với các đội thiếu kinh nghiệm, không có nhiều lập trình viên cứng tay, bởi các đội này thường không có phương thức đánh giá hiệu suất tốt. 

Giải thích rõ hơn về vấn đề giới hạn WIP của Kanban và Scrum:

Ví dụ khi đưa ra bảng Scrum và bảng Kanban

Bảng Scrum                                   

Trong cả 2 trường hợp, chúng ta đều dùng bảng để theo dõi tác vụ được thực hiện qua các bước. Ở đây cả hai bảng đều theo dạng là: 

- To do (Backlog): Những việc cần làm

- On Going: Những việc đang làm

- Done: Những việc đã hoàn thành

Đây chỉ là ví dụ, việc quyết định các bước trong quy trình như thế hoàn toàn phụ thuộc vào đội của bạn.

Điểm khác nhau giữa hai bảng trên nằm ở chỗ phía dưới phần On Going của bảng Kanban có số (2). Đối với bảng Scrum, bạn hoàn toàn có thể để cả C và D vào trong phần On Going bởi: Kiểu gì thì cũng phải hoàn thành hết tất cả các tác vụ này trong thời gian sản xuất của sprint này. Tức là trong trường hợp "xấu" nhất, tất cả bốn tác vụ A, B, C, D đều có thể cùng nằm trong cột On Going. Tuy nhiên, trong thời gian dài, đây không phải là thứ hay ho gì cả, việc dồn tất cả công việc đang hoàn thành vào cùng một chỗ khiến cho đội sản xuất rất dễ dàng rơi vào tình trạng bị quá tải và họ sẽ cần phải giới hạn lại số lượng công việc đang hoàn thành. Và khi đó chúng ta có... Kanban (hoặc Scrumban). 

Giới hạn số lượng tác vụ trong Kanban cũng có thể áp dụng cho tất cả các bước của quy trình, trong trường hợp trên là đối với cả To do lẫn Done (Nhưng chúng ta sẽ chỉ dùng giới hạn WIP trong On Going khi tính lead time trong phần sau). Việc này có lợi ích như sau:

- Đối với Kanban, việc đo lường lead time (trên bảng thì đó sẽ là thời gian một tác vụ đi từ đầu đến cuối quy trình) rất quan trọng. Để đo lường chính xác lead time, thì người sử dụng nên đặt giới hạn về số lượng tác vụ cho tất cả các bước trong quy trình, và có thể thử nghiệm thay đổi để xem hiệu suất của đội mình đến đâu. 

- Khi lead time được đo lường chuẩn xác, đội sản xuất hoàn toàn có thể dự đoán trước thời gian sản xuất (và dự đoán được thời gian của từng bước trong quy trình) nếu như họ nhận được các yêu cầu tương tự, từ đó có thể đưa ra kế hoạch giao hàng phù hợp với thực tế.

Đối với Kanban, chúng ta áp dụng công thức của Little's Law để đưa ra mối quan hệ giữa lead time với WIP

- DR: Delivery Rate - Khoảng thời gian trung bình một tác vụ được hoàn thành

- LT: Lead Time - Khoảng thời gian trung bình một tác vụ đi hết bản Kanban

- WIP: Work in Progress - Số lượng tác vụ trung bình ở trong giai đoạn đang tiến hành

Giả sử chúng ta có một đội 4 người, và đặt giới hạn WIP là 1. Các tác vụ trong dự án này không cần nhiều hơn 1 người để hoàn thành trong trường hợp lý tưởng. 

Điều này có nghĩa là trong On Going luôn luôn chỉ được có 1 tác vụ. Ở trên bảng trên, chỉ khi B được hoàn thành, thì C mới được đưa vào, và chỉ khi nào C được hoàn thành, thì D mới được đưa vào, cứ thế tiếp tục.

Tuy nhiên việc này khiến cho 4 người trong đội không thể cùng làm việc một lúc được, do mỗi tác vụ không cần phải có sự tham gia của người thứ hai. Điều này khiến cho thông thường sẽ luôn có 3 người không có việc, trong thời gian dài thì không tốt. Thêm vào đó, giới hạn WIP bằng 1 sẽ khiến cho nhiều tác vụ bị tắc ở To do, từ đó dẫn đến lead time cao hơn cần thiết. Trong trường hợp này, giả sử như trung bình mỗi tác vụ cần 2 ngày để hoàn thành:

WIP = 1

DR = 0.5 (Do cứ mỗi 2 ngày thì sẽ xong được 1 tác vụ)

=> LT = WIP/DR = 1/0.5 = 2

Nếu như tăng giới hạn WIP lên 2, thì DR = 2, và LT = 1

Và như thế thì giới hạn WIP bằng 1 quá thấp, nếu như chúng ta quyết định tăng lên 8 và mọi người đều luôn có việc thì sao? Đối với đội 4 người thì chúng ta sẽ luôn luôn có 2 tác vụ đang trong quá trình thực hiện bất kể lúc nào. 

Tuy nhiên, nếu như có vấn đề gì đó xảy ra, giả dụ như server có vấn đề và không thể hoàn thiện các tác vụ C, D, E, F. Khi đó chúng ta sẽ vẫn phải để C, D, E, F trong phần On Going và phải "pull" thêm các tác vụ từ To do sang để đảm bảo WIP, và không có thời gian để sửa server.

Nhưng nếu chúng ta không sửa server, thì rất nhanh thôi On Going sẽ đầy, và lúc đó chúng ta buộc phải sửa server. Thời gian để sửa server sẽ khiến cho dòng việc gặp tình trạng "thắt cổ chai" (việc thì vẫn đến nhưng không thể làm gì), dồn ứ vào. Như vậy chúng ta phải giảm giới hạn WIP để vừa có thời gian thực hiện các tác vụ, vừa có thời gian để phản ứng với những việc phát sinh. Sau một thời gian nữa mà số lượng tác vụ trong To Do tăng lên thì chúng ta sẽ lại cần tăng giới hạn WIP.

Thế nên nếu như sử dụng Kanba, đội sản xuất phải luôn trong trạng thái phân tích, đo lường, thay đổi là vì vậy. 

Tính chất linh hoạt của Kanban khiến cho mô hình này có thể áp dụng ở mức độ cá nhân, và trên thực tế, rất phù hợp ở mức độ cá nhân do Kanban khuyến khích thay đổi liên tục. 

Có rất nhiều bài viết về vấn đề xây dựng quản lý thời gian cá nhân ở Spiderum, nhưng tôi chưa thấy một bài nào nói cụ thể về đo lường hiệu quả công việc. Nếu như sử dụng và tuân theo tôn chỉ của Kanban về lead time (các bạn có thể tham khảo ở phần 5 của bài này), các bạn sẽ hiểu rõ hơn về hiệu suất lao động của chính bản thân mình. 

Để xây dựng một bản Kanban cá nhân, bạn cần làm theo 3 bước của Kanban, tôi sẽ nhắc lại ở đây:

- Sử dụng bảng để minh họa quy trình làm việc của cá nhân, thông thường đối với cá nhân thì To do, On Going, và Done là đủ 

- Sử dụng các thẻ (sticky card), viết tác vụ vào trong thẻ, và dán lên bảng tùy theo các bước trong quy trình làm việc cá nhân

- Giới hạn WIP cho On Going (Nếu như bạn muốn sử dụng Kanban cho tổng thể công việc chứ không phải từng dự án, bạn có thể đặt giới hạn tác vụ cho từng bước trong quy trình)

Nếu như quen với các công cụ quản lý như Asana hay Jira, bạn cũng hoàn toàn có thể làm một dashboard trên đó theo bảng Kanban, và đối với cá nhân tôi thì cách này phù hợp hơn, tôi luôn để bảng Kanban cá nhân ở trên một màn hình để theo dõi (vâng, tôi dùng 2 màn hình, lúc nào cũng vậy). 

Nếu như là lần đầu sử dụng Kanban, với mỗi tác vụ, bạn cần phải theo dõi chính xác, thậm chí tuyệt đối chính xác 2 loại thời gian sau:

- WIP - Work In Progress

- DR - Delivery Rate

Và ghi nhớ công thức LT = WIP/DR

Để cải thiện thời gian làm việc, bạn sẽ cần phải tập trung vào việc giảm lead time nhưng vẫn đảm bảo được chất lượng công việc (bạn nên phân loại đánh giá của khách hàng để theo dõi chất lượng) thông qua:

- Tăng giới hạn WIP

- Giảm thời gian hoàn thành một tác vụ

Đây là một trong những dự án dài hơi mà nhóm dịch của tôi đang thực hiện, tôi đã cất bỏ hết xấu hổ để quảng cáo trắng trợn ở đây: