Sử dụng Planning Poker để Estimate các dự án trong Agile

Planning Poker là gì ?

Planning Poker được sử dụng trong agile dựa trên sự đồng thuận trong việc ước tính. Để bắt đầu một lần ước tính, Product Owner hoặc khách hàng đọc một User Story hoặc mô tả một tính năng của sản phẩm với những người tham gia ước tính, thường là tất cả các thành viên của một Nhóm. Mỗi người tham gia ước tính cầm một bộ bài (Poker) gồm các giá trị như 0, 1, 2, 3, 5, 8, 13, 20, 40, và 100 (dãy Fibonacci).

Các giá trị đó thể hiện số điểm (story point), lý tưởng là theo số ngày, hoặc bất cứ đơn vị nào mà nhóm dự tính. Các thành viên của nhóm cùng thảo luận về tính năng đó, đặt các câu hỏi với Product Owner nếu cần thiết. Khi tính năng này đã được thảo luận kỹ lưỡng, mỗi thành viên sẽ tự chọn một lá bài để đưa ra ước tính của mình. Tất cả các là bài sẽ được lật lên cùng nhau. Nếu tất cả các lá bài đó có giá trị như nhau thì giá trị đó được chấp nhận là ước tính của tính năng vừa thảo luận. Nếu không, các thành viên của nhóm cùng thảo luận về các ước tính mà mình đưa ra. Đặc biệt, những thành viên có ước tính cao và thấp cần đưa ra những cơ sở cho ước tính của mình. Sau một hồi thảo luận, mỗi thành viên chọn một lá bài để ước tính lại và các lá bài của họ lại đồng thời được lật lên. Quy trình này sẽ lặp đi lặp lại cho tới khi đạt được sự đồng thuận của các thành viên hoặc họ quyết định rằng ước tính về tính năng này cần hoãn lại cho tới khi có thêm các thông tin bổ sung.

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

Khi nào chúng ta sử dụng ?

Hầu hết các nhóm sẽ tiến hành phiên Planning Poker ngay sau khi Product Backlog đầu tiên được xây dựng xong. Phiên làm việc này (có thể được chia thành nhiều ngày) được sử dụng để tạo ra những ước tính ban đầu hữu ích cho việc xác định phạm vi và kích cỡ của dự án. Bởi vì các hạng mục trong Product Backlog (thường sử dụng các User Story để thể hiện) sẽ tiếp tục được thêm vào trong suốt dự án, hầu hết các nhóm sẽ thấy được lợi ích của nó để tiến hành các phiên ước tính trong quy trình lặp tiếp theo. Thông thường, việc này được tiến hành một vài ngày trước khi kết thúc một quy trình lặp và ngay sau buổi Họp Hằng ngày khi mà toàn bộ các thành viên của nhóm cùng có mặt ở đó.

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ụ   A đưa ra estimation là 5   B đưa ra estimation là 12   C đưa ra estimation là 8   D đư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 A và D.

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.

Liệu Planning Poker có được việc không ?

Điều này là chắc chắn. Các nhóm triển khai ước tính với Planning Poker đều đưa ra các báo cáo rằng họ ước tính chính xác hơn so với bất cứ kỹ thuật nào mà họ sử dụng trước đó. Một nguyên nhân giúp Planning Poker đứng đầu trong việc ước tính so với các kỹ thuật khác là bởi vì nó tập hợp được các ý kiến đa dạng của nhiều chuyên gia. Do các chuyên gia từ nhiều lĩnh vực tập hợp thành nhóm liên chức năng trong một dự án phần mềm, họ sẽ đưa ra được những ước tính tốt hơn bất cứ một cá nhân nào. Sau khi hoàn thành việc xem xét các tài liệu về ước tính phần mềm, Tiến sĩ Magne Jørgensen làm việc tại Simula Research Lab kết luận rằng “con người hiệu quả nhất khi giải quyết các công việc nếu nó được ước tính.” Thứ hai, một cuộc thảo luận sôi động nảy sinh trong suốt phiên Planning Poker và các thành viên tham gia ước tính được yêu cầu phải biện minh với các đồng đội về ước tính của mình. Các nhà nghiên cứu đã nhận thấy rằng điều này làm tăng tính chính xác trong ước tính, đặc biệt trên các hạng mục có nhiều thông tin chưa rõ ràng mà chúng ta thường thấy trong hầu hết các dự án phần mềm. Hơn nữa, việc biện minh cho những ước tính đã đưa tới kết quả ước tính tốt hơn do các thông tin thiếu sót được bù đắp. Đây là một điều quan trọng trong một dự án agile bởi vì các User Story được ước tính thường chứa đựng các thông tin mơ hồ. Ngoài ra, các nghiên cứu cho thấy rằng trung bình ước tính cá nhân đem lại kết quả tốt hơn khi ước tính được tiến hành với việc thảo luận nhóm.

Nguồn tài liệu tham khảo:

• http://www.mountaingoatsoftware.com/topics/planning-poker
• Benjamin Day (Scrum Coach, Trainer, Developer)
• https://play.planningpoker.com/