Tại sao tôi từ bỏ Scrum và chọn Kanban

Phân tích về Scrum

Với Scrum, chúng ta cần có daily standup meeting (cuộc họp hàng ngày), sprint planning meeting (cuộc họp lên kế hoạch cho 1 sprint), sprint review meeting (cuộc họp review sản phẩm), và retrospective meeting (họp rút kinh nghiệm mỗi sprint). Tất cả các cuộc họp đều hữu ích và đem lại những lợi ích nhất định. Tuy nhiên, có 2 vấn đề nổi trội về Scrum.

Đầu tiên, Scrum project sẽ xoay quanh story point (Là một đơn vị được dùng để đánh giá công sức phải bỏ ra để thực hiện một user story. Story point càng nhiều thì user story đó càng lớn và tốn nhiều thời gian thực hiện) và sprint planning (Sprint Planning là một sự kiện trong Scrum, cuộc họp này bao gồm Scrum Team. Trong cuộc họp, Scrum team xem xét, dự đoán sẽ làm gì trong Sprint tiếp theo và làm như thế nào để hoàn thành và phát hành sản phẩm thoả với Definition of Done)

Story point sẽ trở nên không có ý nghĩa nếu đội nhóm đó đã trở nên quen thuộc và biết rõ khả năng của bản thân và những yêu cầu của dự án. Nếu mọi người chỉ ngồi và đưa ra những con số đánh giá, mà không đi sâu vào chi tiết, sẽ xảy ra các vấn đề liên quan tới Sprint concept.

Sprint trong Scrum là khoảng thời gian mà Nhóm Scrum tiến hành tất cả các hoạt động cần thiết để sản xuất được một phần tăng trưởng có khả năng chuyển giao được.

Ví dụ, chúng ta có sprint là 2 tuần, và theo kế hoạch, phần triển khai tiến hành sử dụng phần mềm hoàn thiện sẽ vào cuối mỗi sprint. Thử tưởng tượng khi bắt đầu 1 sprint mới, Product Owner biết được có 1 task cần hoàn thiện gấp. Nội dung của task là về thị trường hiện tại, và cần tung ra tính năng này ngay lập tức. Vậy, anh ấy cần phải làm gì? Dựa theo nguyên tắc của Scrum, anh ấy sẽ phải chờ tới khi chu kì của sprint mới,hoàn thành tính năng, và tiến hành triển khai sử dụng thử sản phẩm vào cuối của sprint đó. Nhìn chung, quá trình này tốn khoảng 4 tuần. Quãng thời gian này là quá lâu, và không hợp lý đối với người sử dụng sản phẩm. Chính vì vậy, giải pháp duy nhất của anh ấy là phải thêm đầu việc giải quyết task đó vào giữa chu trình của sprint hiện tại. Tất nhiên, việc này sẽ làm cho các kĩ sư phát triển phần mềm không hài lòng.  

Khi thực hiện sprint planning, chúng ta cần đầy đủ các thành viên của nhóm dự án tham gia. Nếu không làm được điều đó, Product Owner và các kĩ sư (Senior trở lên) sẽ là người bàn luận chính và phổ biến về cho mọi người. Việc này khá là phổ biến trong 1 số doanh nghiệp, tuy nhiên, việc truyền đạt thông tin đôi khi sẽ bị không chính xác hoặc thiếu sót. Bên cạnh đó, một vấn đề nổi trội khác chính là chất lượng của sản phẩm. Hầu hết các sản phẩm đều được hoàn thành khi sprint chuẩn bị kết thúc. Chính vì vậy, đội ngũ QA không đủ thời gian để kiểm tra lại chất lượng sản phẩm một cách chính xác nhất. Sẽ có vài trường hợp khi công việc chưa được hoàn thiện, các kĩ sư sẽ dùng “dirty way” để hoàn thành công việc sớm. Việc làm này sẽ khiến đội ngũ QA trở nên mệt mỏi. Họ sẽ phải bỏ nhiều công sức, thời gian, cũng như tài nguyên để kiểm tra lại sản phẩm đó.

Chính vì lý do đó, tôi nghĩ mình nên từ bỏ phương pháp Scrum, và chuyển sang Kanban
 

Tại sao lại là Kanban?

Kanban giới hạn WIP (Work in Progress – Tác vụ đang tiến hành). Với phương pháp này, đội sản xuất sẽ tiến hành 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 nhóm sẽ không bị quá tải khi giải quyết công việc, và đảm bảo chất lượng của công việc cũng như sản phẩm. Hãy tưởng tượng là bạn đang ở 1 nhà hàng sushi. Nhà hàng này có 2 đầu bếp phục vụ. Đơn order của bạn sẽ là task được dán ở bảng Kanban, và 2 đầu bếp sẽ là lập trình viên. Họ có thể làm 2 đến 4 miếng sushi trong một khoảng thời gian nhất định, và đó là giới hạn WIP.

1 bảng Kanban mẫu đơn giản, các thẻ màu xanh là các task đang được tiến hành.

Khi lắp ghép mọi thứ lại với nhau, chúng ta sẽ có một bảng Kanban đơn giản. Đừng quên các thẻ trong cột Backlog (những việc cần làm) nên được xếp theo thứ tự ưu tiên. Việc này sẽ giúp các lập trình viên dễ dàng nắm được họ nên làm gì tiếp theo.

Một đội nhóm theo phương pháp Kanban sẽ tập trung vào đầu công việc đang triển khai. Khi 1 công việc được hoàn thành, họ sẽ tiếp tục lấy 1 thẻ công việc mới ở cột backlog. Trong trường hợp này, Product owner là người chịu trách nhiệm sắp xếp lại thứ tự ưu tiên cho các công việc ở cột đang tiến hành xử lý. Thực chất, tất cả các đầu việc ngoài cột Đang tiến hành (WIP) đều không ảnh hưởng tới đội nhóm.

Nếu như đầu bếp làm sushi chỉ cần biết nấu ăn, thì so với các lập trình viên, họ sẽ gặp nhiều khó khăn hơn thế. Thực chất, trong lĩnh vực phát triển phần mềm, khi làm một task, họ sẽ cần tự học, nghiên cứu, hoặc triển khai thử nghiệm (POC - Proof of Concept).

Trong Scrum, chúng ta sẽ có sprint planning meeting, nơi mà tất cả các thành viên trong nhóm có cơ hội hiểu và nắm được các đầu việc của nhau. Thì ở Kanban, sẽ không có bất kì cuộc họp nào. Chính vì vậy, để thay đổi nó, tôi đã thêm vào một bước, gọi là Phân tích – Analyse.

Cấu trúc của 1 bảng Kanban

Chúng tôi đã thay đổi và nâng cấp bảng Kanban lên 1 chút. Ở cột To-do, chúng tôi chia làm 2 cột nhỏ Phân tích (Analyse) và Hoàn thành (Done). Bất cứ khi nào sẵn sàng, thành viên trong team có thể chọn 1 task trong cột Done để bắt đầu phát triển, hoặc chọn 1 task trong cột Backlog để Analyse.

Vậy Analyse cái gì? Đây là một bước khá quan trọng. Khi thẻ nằm ở trong cột Analyse, người chịu trách nhiệm sẽ phải tìm đầy đủ, chi tiết các yêu cầu, việc cần làm cho task này. Việc này cần được triển khai cùng sự giúp đỡ của Product Owner, hoặc QA và các thành viên khác

Chúng tôi không ngại việc dành nhiều thời gian ở bước này, mục tiêu của chúng tôi là đội nhóm cần phải nắm rõ được cần phải làm gì và làm như thế nào. Thẻ trong cột Analyse cũng sẽ được tính như WIP.

Một việc không kém phần quan trọng trong bước này chính là bẻ nhỏ các công việc nếu việc đó quá lớn. Chúng ta cần đảm bảo mỗi thẻ chỉ cần được hoàn thiện trong 1 hoặc 2 ngày. Việc này giúp ích cho việc kiểm tra lại của QA, cũng như đội nhóm dễ dàng kiểm tra tiến độ.

Product Owner vẫn sẽ là người sắp xếp thứ tự ưu tiên của các thẻ trong các cột, từ Backlog, To-Do tới Done. So sánh với Scrum, việc này tương đối linh hoạt hơn.

Thực tế, chúng tôi vẫn giữ lại những văn hóa hoặc cuộc họp theo phương pháp của Scrum. Chúng tôi cố gắng duy trì sự tự chủ trong việc làm việc đội nhóm của mình. Chúng tôi tiếp tục review, và có retrospective meetings (họp rút kinh nghiệm), tuy nhiên việc này không diễn ra thường xuyên. Chúng tôi chỉ thực hiện khi cuộc họp đó là cần thiết.
 

Khi sản phẩm được hoàn thiện, chúng ta sẽ làm gì?

Thực tế, không có định nghĩa “deliver a product” trong Agile. Thực tế, chúng ta cần bẻ nhỏ từng tính năng và nâng cấp, deploy chúng thường xuyên. Nó còn phụ thuộc vào công nghệ mà bạn đang sử dụng. Nếu bạn sử dụng PHP, sẽ an toàn hơn nếu có một lịch cụ thể để deploy. Tuy nhiên, nếu bạn sử dụng Go, sẽ là cần thiết nếu bạn deploy thường xuyên, thậm chí vài lần 1 ngày. Trong trường hợp này, công cụ CI/ CD cũng cần được sử dụng

Tôi không nói tới việc là chúng ta sẽ không thông báo tới các bên liên quan về thời gian dự kiến sản phẩm được hoàn thành. Việc này sẽ được thực hiện sau quá trình phân tích kĩ lưỡng. Đội nhóm sẽ ước lượng được thời gian bằng số lượng của các thẻ làm việc.

Chúng tôi đã và đang áp dụng phương pháp này được gần 1 năm, và chúng tôi không nghĩ rằng đây là quyết định sai lầm. Tất nhiên là nó trải qua rất nhiều khó khăn, thất bại, sàng lọc để có được một phương pháp như ngày hôm nay. Nhưng nó thực sự có ích và thú vị. Mong rằng câu chuyện của tôi sẽ giúp ích cho các bạn trong việc vận hành đội nhóm của mình.

Tác giả: Aaron Fan
Dịch: VNPMI

• So sánh Agile và Waterfall (Phần 1)
• VNPMI tổ chức khóa học PMP miễn phí 02 days
• Xác nhận phạm vi (Validate Scope) trong quản lý dự án
• Đường cơ sở dự án (project baseline) trong quản lý dự án là gì?
• Cơ cấu tổ chức dự án 
• Đề án kinh doanh (Business Case) trong dự án là gì?