KHÁC BIỆT GIỮA SCRUM VÀ KANBAN
Nếu chúng ta muốn so sánh Scrum và Kanban, chúng ta cần xem xét cách cả hai phương pháp tổ chức quy trình công việc và các thực thể, định nghĩa chính mà chúng sử dụng như thế nào.

 


So sánh Scrum và Kanban
 
1 - Vai trò
Sự phân công vai trò là sự khác biệt lớn đầu tiên giữa Scrum và Kanban. Trong Scrum, bạn luôn tìm thấy ba vai trò chính trong một nhóm:

- Product owner (Chủ sở hữu sản phẩm/Người phụ trách sản phẩm). Chủ sở hữu sản phẩm phân tích các yêu cầu của khách hàng về sản phẩm và chuyển chúng thành các nhiệm vụ cho nhóm. Chủ sở hữu sản phẩm cũng ưu tiên các nhiệm vụ và quyết định khi nào một thành phần chức năng cụ thể có thể được phát hành.
- Scrum Master (người phụ trách nhóm). Scrum Masters, trước hết, giới thiệu các nguyên tắc Scrum cho các thành viên trong nhóm của họ và hỗ trợ họ thực hiện. Ngoài ra, Scrum Masters quản lý việc phân phối nguồn nhân lực cần thiết để cung cấp một cuộc chạy nước rút cụ thể.
- Team (Đội ngũ, người phụ trách công việc). Các thành viên trong nhóm sẽ là người hoàn thành công việc. Một nhóm scrum sở hữu nhiều kỹ năng, với một số kỹ năng thường được kết hợp trong một người. Nhóm làm việc theo nguyên tắc tự tổ chức, hỗ trợ lẫn nhau để hoàn thành công việc.

Kanban, đến lượt nó, không có yêu cầu nghiêm ngặt nào về vai trò của đội. Cũng có thể có Chủ sở hữu sản phẩm giám sát các nhiệm vụ trong dự án tồn đọng, nhưng nếu không, nhóm sẽ tự tổ chức.

2 - Quy trình làm việc
Như chúng ta đã đề cập, quá trình phát triển Scrum tiến triển theo các lần lặp, xác định công việc sẽ được thực hiện trong mỗi lần lặp, trong khi Kanban nhằm mục đích giới hạn công việc hiện tại đang tiến hành không có giới hạn thời gian cụ thể. Chúng ta hãy xem hai cách tiếp cận này có ý nghĩa gì trong thực tế dự án.

Scrum Flow
Lập kế hoạch dự án bắt đầu bằng việc xác định công việc tồn đọng, nghĩa là danh sách các câu chuyện (user story) của người dùng nên được thực hiện để tạo ra sản phẩm hoàn thành. Trong ngữ cảnh này, Scrum sử dụng các khái niệm chính sau đây sẽ giúp chúng ta hiểu cách thức công việc được lên kế hoạch và thực hiện:

Dòng chảy công việc theo Scrum
 
Product backlog - đại diện chính cho "To Do" list của cả đội. Việc tồn đọng bao gồm tất cả các tính năng và sửa lỗi cần được thực hiện để dự án được coi là hoàn thành. Backlog được cập nhật liên tục với các yêu cầu mới hoặc các lỗi được phát hiện được lên lịch cho công việc. Product Owner chịu trách nhiệm quản lý công việc tồn đọng, đưa nó đồng bộ với phản hồi và đề xuất của khách hàng và tiến độ công việc của nhóm. Một số mục của danh sách công việc tồn đọng có thể được di chuyển lên hoặc xuống trong xếp hạng ưu tiên, một số mục có thể được thêm vào khi các yêu cầu thay đổi và những mục khác có thể được xóa hoàn toàn.

Sprint backlog - bao gồm các nhiệm vụ phải được thực hiện trong một sprint (vòng lặp) cụ thể. Các mục sprint backlog được chọn để cung cấp một tính năng hoặc thành phần hoàn thành vào cuối sprint . Mặc dù sprint backlog cũng cho phép sự linh hoạt và sửa đổi nhất định, các mục tiêu của sprint nên không thay đổi và các thay đổi nên được giữ ở mức tối thiểu.

Sprint goal, hoặc Increment - là một sản phẩm có thể sử dụng như là kết quả của sprint. Thông thường, một sprint kết thúc bằng một bản demo hiển thị các tính năng hoặc thành phần đã hoàn thành. Về mặt này, một khái niệm quan trọng là định nghĩa hoàn thành để có thể coi từng câu chuyện của người dùng là hoàn thiện. Định nghĩa của các lần thực hiện, có thể khác nhau tùy theo câu chuyện của người dùng: nó có thể bao gồm nhiều nhiệm vụ, chẳng hạn như phát triển, thử nghiệm, thiết kế, tài liệu và trình bày và nó cũng có thể liên quan đến các thành viên khác trong nhóm. Mỗi sprint bắt đầu với giai đoạn lập kế hoạch trong đó các nhiệm vụ cho sprint tiếp theo được chọn. Đối với kế hoạch, nhóm đầy đủ thường có mặt, bao gồm Product Owner và Scrum Master. Nhóm quyết định những gì họ có thể cung cấp vào cuối sprint và chọn những câu chuyện người dùng tương ứng từ hồ sơ product backlog. Bằng cách này, họ cùng nhau xử lý sprint backlog.

Trong suốt 1 sprint, nhóm gặp gỡ hàng ngày cho một "scrum daily" , nơi họ thảo luận về tiến trình của họ và bất kỳ khối nào họ có thể gặp phải. Mục đích của" scrum daily" là phát hiện sớm các vấn đề và tìm ra giải pháp nhanh chóng để không làm gián đoạn sprint.

Sau sprint, các tính năng hoàn thành được xem xét bởi các bên liên quan. Trong quá trình đánh giá sprint, nhóm có cơ hội nhận được phản hồi về công việc của họ và các đề xuất thay đổi, nếu có.

Đồng thời, nhóm gặp gỡ trong các "sprint retrospective", nơi họ phân tích sprin mà họ vừa hoàn thành và tìm thấy những điều có thể được cải thiện. Sau đó, quy trình được đặt lại và sprint mới bắt đầu với giai đoạn lập kế hoạch.

3 - Dòng chảy Kanban
Ở Kanban, không có khoảng thời gian nào trong đó một số lượng công việc nhất định phải được thực hiện. Thay vào đó, Kanban tập trung vào việc cân bằng năng lực của đội với công việc hiện đang được tiến hành.

 

Bảng công việc Kanban với WIP
 
Luồng dự án Kanban bắt đầu với tồn đọng công việc chung bao gồm tất cả các nhiệm vụ nên được thực hiện. Mỗi thành viên trong nhóm chọn một nhiệm vụ cho mình từ hồ sơ tồn đọng và tập trung hoàn thành nó. Khi nhiệm vụ hoàn thành, thành viên sẽ chọn cái tiếp theo, và cứ thế cho đến khi hết hàng tồn đọng. Việc tồn đọng được ưu tiên với các nhiệm vụ khẩn cấp nhất được đặt lên hàng đầu để được nhóm chọn trước.

Ở Kanban, điều quan trọng là số lượng công việc đang tiến hành không vượt quá khả năng của nhóm bất cứ lúc nào trong dự án. Với mục đích đó, có khả năng đặt giới hạn cho bất kỳ loại công việc nào theo khả năng có sẵn.

Product Owner có thể đặt và thay đổi các ưu tiên trong hồ sơ tồn đọng bao nhiêu lần và bao nhiêu lần tùy thích, vì quản lý tồn đọng không ảnh hưởng đến hiệu suất của nhóm. Nhóm chỉ quan tâm đến công việc đang tiến hành, chỉ quay lại tồn đọng sau khi nhiệm vụ hiện tại hoàn thành.

Mỗi nhiệm vụ thực hiện To Do - Làm việc trong tiến trình trực tiếp - Cách thực hiện. Tất nhiên, Kanban cũng hỗ trợ khái niệm về các định nghĩa về việc thực hiện của Wap, đây là tiêu chí cho sự chấp nhận của mỗi nhiệm vụ.

Cuối cùng, các nhiệm vụ đã hoàn thành tạo thành các thành phần mà có thể đo thời gian cần thiết để phân phối chúng. Ở Kanban, nó được gọi là thời gian chu kỳ của người dùng , và phép đo thời gian theo chu kỳ có rất nhiều cơ hội tối ưu hóa. Tất nhiên, tất cả đội đều cố gắng cho thời gian chu kỳ ngắn hơn và tìm cách giải quyết các tắc nghẽn, nếu có.

Trong bối cảnh này, điều quan trọng là phải có các thành viên có nhiều kỹ năng trong nhóm. Nếu một kỹ năng nhất định chỉ được sở hữu bởi một người - ví dụ, nếu bạn chỉ có một người kiểm tra - đó là một nút cổ chai. Tất cả các nhiệm vụ thử nghiệm sẽ xếp hàng để xử lý sự chậm trễ trong phân phối sản phẩm.


Xem tiếp: Lựa chọn quy trình phát triển phần mềm theo phương pháp Agile? (Phần 3)

Nếu bạn có nhu cầu xây dựng hệ thống phần mềm phục vụ bài toán quản lý doanh nghiệp, dịch vụ của mình, hãy liên hệ với chúng tôi để được hỗ trợ tốt nhất!

Tầng 12, Mipec Tower, 229 Tây Sơn, Đống Đa, Hà Nội

Mục này đã được đăng trong: Kiến Thức