Bạn có muốn hoàn thành dự án một cách hiệu quả và đúng thời hạn? Bạn đang mắc kẹt trong một dự án phức tạp? Quanh quẩn trong một môi trường luôn thay đổi nhanh? Có ai đó nói với bạn về một phương pháp agile để giải quyết tất cả những trục trặc này? Khi nói đến một phương pháp agile, những người khác nhau sẽ có những quan điểm khác nhau. Một số nói, Kanban; một số nói, Scrum. Và có một sự nhầm lẫn ở đây 

Và bài viết này chính là để làm sáng tỏ vấn đề đó. Chúng ta sẽ nói về Kanban và Scrum trong chủ đề này. Chúng ta sẽ hiểu Kanban là gì, Scrum là gì và cả hai khác biệt như thế nào.

Kanban là gì?

• Kanban có nghĩa là 'Visual Signal' trong tiếng Nhật. Phương pháp Kanban là hình dung tất cả những gì bạn sẽ làm cho ngày hôm nay.
• Bảng Kanban không chỉ đóng một vai trò quan trọng trong việc hiển thị quy trình công việc mà còn giúp tối ưu hóa luồng công việc giữa các đội khác nhau.
• Ngày nay, một số công ty vẫn sử dụng bảng công việc cố định tại một nơi, tuy vậy việc sử dụng bảng công việc ảo (virtual) có ích lợi về tính khả dụng và khả năng truy cập ở bất cứ địa điểm nào.
• Bảng Kanban cơ bản có ba phân đoạn: To do, In progress và Done
• Tuy nhiên, tùy thuộc vào dự án, quy mô đội, quy trình công việc bảng Kanban có thể được thiết lập cho phù hợp. Bảng có thể được phân đoạn như: To do, In Progress, Code review, In Testing, Deliverable...
• Mỗi một mục công việc trên bảng là một thẻ Kanban. Mục đích duy nhất của việc sử dụng Thẻ [Physical/Virtual] giúp cho đội có khả năng theo dõi công việc trực quan.
• Thẻ cung cấp thông tin cụ thể như người chịu trách nhiệm, thời gian ước tính hoàn thành, và tình trạng hiện tại của mục công việc...
• Điều này cho phép đội dự đoán được những thách thức, nắm bắt nhanh các Blockers, tăng khả năng truy tìm nguồn gốc, giảm sự phụ thuộc.
• Trong quá trình này, đội chỉ được tham gia vào công việc đang được tiến hành (In progress). Chỉ khi mục công việc đó được chuyển sang trạng thái hoàn thành (Done), họ mới được chọn mục công việc kế tiếp từ danh sách Backlog / To do.
• Các hạng mục công việc quan trọng nhất được giữ ở đầu danh sách việc cần làm "To do" bởi product owner. Có thể được điều chỉnh lại cho phù hợp với nhu cầu.
• Không có vòng lặp lại trong thời gian cố định ở bảng Kanban. Tất cả đều dựa vào cycle times. Cycle time là thời gian để di chuyển một mục công việc từ trạng thái To Do đi đến trạng thái Done.
• Kanban cũng cho thấy tầm quan trọng của nguồn nhân lực đa năng. Khi một người có nhiều kỹ năng, cô / anh ta không chỉ làm việc với chỉ một kỹ năng. Họ có thể đóng góp vào các mục công việc khác trong nhiều khía cạnh. Ví dụ: một developer không chỉ dán chặt vào công việc develop code. Trong trường hợp được yêu cầu, developer có thể chuyển sang Kiểm tra (Testing) do đó làm giảm sự phụ thuộc và cycle time.

Scrum là gì?

• Giống như Kanban, Scrum là một khuôn khổ để triển khai Agile. Scrum có các tính năng như xác định thời gian vòng lặp, theo dõi / tiếp cận theo vai trò, v.v.
• Scrum phát triển sản phẩm bằng cách thiết lập một vòng lặp trong một thời gian cố định. Mỗi vòng lặp này được gọi là Sprint. Thông thường, mỗi lần chạy sprint cố định trong khoảng 2 tuần đến 1 tháng.
• Bắt đầu với một cuộc họp Sprint Planning để lên kế hoạch cho các mục công việc trong lần chạy sprint đó. Việc ước tính thời gian chạy Sprint cũng được xác định trong giai đoạn này.
• Chọn Product Backlog cho Sprint cụ thể được thực hiện trong giai đoạn này.
• Truyền đạt với tất cả những người liên quan về phạm vi và các mục tiêu hoàn thành.
• Các mục backlog cũng có thể được chia ra khi cần thiết.
• Quyền ưu tiên công việc có thể được sửa đổi trong các mục backlog trong giai đoạn này
• Mỗi Sprint đều có các cuộc họp Stand-Up hàng ngày / Các cuộc họp Scrum hàng ngày
• Tất cả thành viên trong đội đều tham gia
• Thời gian không quá 15 phút.
• Những gì đã được thực hiện kể từ cuộc họp cuối cùng, Điều gì sẽ được thực hiện trước cuộc họp Scrum tiếp theo cũng sẽ được thảo luận.
• Đưa ra các Blockers, Bottlenecks, sự phụ thuộc trong các cuộc họp.
• Mỗi Sprint được kết thúc bằng cuộc họp Retrospective meeting
• Các hạng mục công việc đã hoàn thành được giới thiệu / Demo trong thời gian họp
• Phân tích: những điều thành công (đạt được) từ Sprint và những việc cần khắc phục cho kỳ sprint tiếp theo.
• Khi Sprint kết thúc, lặp lại các bước tương tự ở trên cho các mục còn lại của Backlog.
• Scrum về cơ bản được vận hành dựa trên các vai trò: Product Owner, Scrum master, và đội Development
• Product Owner: là người chịu trách nhiệm chính cho phát triển sản phẩm. Tối ưu hóa giá trị của sản phẩm thông qua quản lý các danh sách backlog và đảm bảo các sản phẩm phân phối phù hợp nhất để đáp ứng nhu cầu kinh doanh.
• Scrum Master: Họ là những chịu trách nhiệm trên quy trình công việc, lập kế hoạch sprint, đánh giá, cuộc họp hàng ngày ..
• Đội Development: Đội phát triển và vận hành sản phẩm vào cuối mỗi kỳ Sprint. Thực hiện các công việc như phân tích, thiết kế, phát triển, thử nghiệm, tài liệu...

Bây giờ thì chúng ta đã nắm rõ về định nghĩa Scrum và Kanban, sau đây sẽ là phần so sánh giữa 2 bảng:

Kanban và Scrum

Như chúng ta đã thấy trong các mô tả bên trên, về mặt tính chất của hai bảng đều như nhau. Nhưng cách làm việc trong cả hai quá trình này là khác nhau.

Một số công ty lựa chọn Scrum, số khác chọn Kanban. Đôi khi, chúng ta có thể kết hợp cả 2 với nhau với tên gọi là Scrumban.

Ví dụ chỉnh sửa chu kỳ cố định của Sprint và các vai trò từ Scrum với mục tiêu tập trung vào việc giới hạn công việc đang được tiến hành và cycle time từ Kanban. Và như đã phân tích, cả hai đều hữu ích theo cách riêng, đương nhiên là cũng có thể kết hợp khi cần thiết, điều đó tùy thuộc vào nhu cầu của từng công ty.

Kết luận

Có sự khác biệt đáng kể giữa phương pháp agile Scrum và Kanban. Hy vọng các bạn đã nắm bắt cũng như cách vận hành cho từng loại phương pháp. Thông tin về tác giả: Subhasis có hơn 8 năm kinh nghiệm làm việc cho các công ty CNTT thuộc tạp chí Fortune 500 trong lĩnh vực Quản lý Chất lượng Phần mềm, Phát triển Phần mềm và có kinh nghiệm về Testing . Ông hiện là trưởng nhóm QA của một công ty CNTT hàng đầu và rất thích viết về những trải nghiệm của ông về Software Testing Tricks.