11. Một số vấn đề gặp phải khi estimate trong Agile sử dụng kĩ thuật Planing Poker

Một số vấn đề gặp phải khi estimate trong Agile sử dụng kĩ thuật Planing Poker

image source  from : Wiki

Nếu đã từng làm việc với Scrum method trong Agile, chắc hẳn bạn có biết tới kĩ thuật estimation – Planing Poker. Đây là một kĩ thuật  đơn giản và hiệu quả trong việc estimation, giúp cho team thoả mãn tiêu chí transparent cho toàn team, thể hiện tính commitment của từng cá nhân với tập thể.

Tuy nhiên hầu hết các Scrum team luôn có những vấn đề gặp phải dẫn tới hiệu quả cũng như tính chính xác trong estimation không cao

 Planing Poker :
Thời gian:    Thường trong buổi họp estimation sau khi đã có tương đối (chưa cần hoàn thiện) các stories  trong project’s backlog, hoặc buổi họp planing meeting sẽ define chi tiết hơn, chúng ta sẽ sử dụng Planing Poker để estimate. Tôi thường có một buổi general estimation và buổi planning meeting để break down thêm với team và nhận được sự confirm và commitment từ phía các thành viên trong scrum team.

Phương thức: Team sẽ có các lá bái, mỗi là bài tương ứng với 1 con số, 0, 1/2 và  trong dãy Fibonacci : 1, 2, 3, 5,8, 13,… tương ứng với các story point sẽ được gán – estimate cho từng story
Trong quá trình estimation, với mỗi story, scrum master sẽ đóng vai trò dẫn team, team member sẽ đưa lên lá bài mà a ta cho rằng sẽ mất thời gian như vậy để làm xong story đó. Quá trình cứ diễn ra theo từng vòng cho tới khi thống nhất được lá bài tương ứng với story đó. Quá trình đảm bảo ở mỗi vòng mọi thành viên liên quan đều được đưa ra estimation.

Lợi ích: Sử dụng sức mạnh của tập thể, tránh trường hợp một thành viên chưa nhìn thấy hoặc có vấn đề không rõ về story được đồng đội bổ sung và đưa ra estimation thêm chính xác. Sau đó toàn bộ team clear hoàn toàn với các vấn đề có thể gặp phải đối với story này

Sau đây là một số vấn đề mà các Scrum team có thể gặp phải và cách có thể tránh được những vấn đề này.

1.  Estimation của bạn bị phụ thuộc người khác ngay từ vòng estimation đầu tiên.

Giả sử bạn phân tích và đưa ra estimation cho story là 21, tuy nhiên trước khi scrum master đề nghị các bạn bắt đầu vote, một thành viên trong team có năng lực báo rằng:’ok chúng ta bắt đầu vote, tuy nhiên tôi thấy đây là 1 function nhỏ, đơn giản, chắc sẽ không tốn thời gian’. Bạn bỗng trở nên phụ thuộc vào và có khả năng đưa ra nhận định cho story sai lầm, vì bạn sợ trở nên ngớ ngẩn trước mắt mọi thành viên.
Để khắc phục tình trạng này scrum master nên để công bằng với hết mọi người, mọi người sẽ chỉ phát biểu và thảo luận sau vòng estimation thứ  nhất

2. Không phân tích tại sao lại có estimation thấp nhất và cao nhất

Xin đưa ra 1 ví dụ
An đưa ra estimation là 5
Bình đưa ra estimation là 1
Hải đưa ra estimation là 8
Chung đưa ra estimation là 21

Trước khi bắt đầu vòng tiếp theo Scrum master cần phải bàn luận với team tại sao chúng ta đưa ra estimation lại khác biệt như vậy, trường hợp An và Chung.

Sau khi clear thì mới bắt đầu vòng estimation tiếp theo cho tới khi các estimation gần về với nhau nhất

3. Bạn chỉ estimate công việc của bạn:

Trong scrum team luôn có sự mix giữa các vị trí, tuy nhiên trong thực tế ở một thời điểm thì bạn sẽ có 1 vai trò. Khi estimation, bạn chỉ estimation cho phần công việc của mình mà không quan tâm tới ảnh hưởng với toàn team hoặc bạn biết đã làm 1 story tương tự như vậy với một vị trí , nhưng bạn không có nói ra trong buổi họp estimation. Scrum team đòi hỏi sự đoàn kết, cộng tác giữa các thành viên trong team. Điều đó giúp team estimate các story ngày một chính xác hơn
Thực tế sẽ có estimation cho developer, estimation cho QA và tester.

4. Bạn không định nghĩa Done rõ ràng:

Đây là một lỗi rất cơ bản mà các team thường bị miss, ngay cả trong quá trình phát triển các sprint, team cũng cần luôn re define lại định nghĩa này cho phù hợp.
Bàn đến quá trình estimation, team cần đưa ra một định nghĩa Done phù hợp nhất với ban đầu để đưa ra estimation. Với định nghĩa Done như vậy, team sẽ xác định và không nhập nhằng khi đưa ra estimation.

Hi vọng 4 quan điểm được nêu ra sẽ giúp ích được bạn trong quá trình estimation của Agile sử dụng kĩ thuật Planing Poker.

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *