Kỹ thuật Estimation trong Agile

Hiện nay, những mô hình quản lý dự án và mục đích chung của các mô hình này đều hướng đến việc tạo ra sản phẩm tốt, bàn giao cho khách hàng đúng deadline. Tuy nhiên, trong quá trình phát triển, cũng có rất nhiều yếu tố ảnh hưởng đến chất lượng công việc. Một trong số đó là việc estimate thời gian? Estimate thời gian hợp lý, đảm bảo tiến độ dự án luôn là bài toán đau đầu với những nhà quản lý.

Hầu hết chúng ta đều đã trải qua những cuộc họp ước lượng mất thời gian như vậy và đều từng cảm nhận được trải nghiệm đau đớn này. Luôn có những cuộc thảo luận bất tận về mức độ phức tạp của ‘X’ và thời gian để thực hiện trong bao nhiêu lâu là đủ. Vấn đề là mỗi người đều có quan điểm riêng tùy thuộc vào mức độ nhận thức của từng cá nhân về công việc của họ cho nên thật khó để thống nhất các ý kiến và số liệu đưa ra cũng chỉ có thể dừng ở mức tương đối.

Ngoài ra, vì phần mềm ngày nay được xây dựng theo mô hình Agile, phân chia thành các vòng lặp và khách hàng luôn muốn thay đổi yêu cầu của họ, mỗi yêu cầu thay đổi hoặc tăng phạm vi sẽ tăng thêm thời gian để phát triển dự án. Và dưới đây các là các kỹ thuật có thể giúp đội dự án có thể ước tính cho dự án thực tế và chính xác hơn.

1. Affinity mapping:

Nó có một phương pháp bắt đầu nhanh, độ trung thực thấp để tổ chức một lượng lớn các điểm thông tin cấp thấp vào các chủ đề chính có thể giúp bạn nhìn thấy chế độ xem hàng trăm feet thay vì chế độ xem một centimet. Kỹ thuật này còn được gọi là "Chia cho tới khi đạt maximum hoặc ít hơn ". Những gì mọi người trong team cần làm đó là họ sẽ phân chia khối lượng công việc theo kích thước của họ - đặc biệt là về mức maximum mà team đã đưa ra. Và những điều được thảo luận là những kích thước phù hợp và những kích thước không phù hợp. Nếu có mục nào lớn hơn mức tối đa thì mọi người trong team sẽ cùng chia chúng thành các mục phụ và bắt đầu thảo luận lại. Phương pháp này có thể mất một thời gian dài để team trao đổi và tìm được kích thước hợp lý cho task của team nhưng khi đã tìm được kích thước phù hợp thì việc đưa vào implement sẽ không phải gặp vấn về về over estimation nữa.

Tất cả các thành viên của nhóm có thể được yêu cầu lấy các vật phẩm nhóm chúng theo danh mục và kể câu chuyện của chúng trong một trong số chúng. Sau đó, những câu chuyện đơn giản về con người được chọn và gửi thành những mục nhỏ. Nhưng những cái khó hơn được đưa lên. Tất cả các thành viên của nhóm sẽ phải phân tích yêu cầu và chia chúng thành các danh mục hay các kích thước theo góc nhìn của họ. Đây là một loại kỹ thuật rất tốt, nơi bạn có thể đối chiếu Product Backlog. Phiên bản này là một bản thô, và trong hệ thống đơn giản, nó chỉ có ba kích cỡ: Lớn, Nhỏ và Không chắc chắn.

2. T-shirt Sizes- Kích cỡ áo phông:

Đây cũng là phương pháp Numeric Sizing - Định cỡ số giống phương pháp ở phần 1. Tất cả các task được phân loại theo size của chiếc áo phông phổ biến như: XS, S, M, L, XL. Và sau đó team sẽ đưa ra đánh giá về size cho các task trong dự án, dựa vào số size team có thể ước tính bằng những con số đơn giản. Ví dụ: Con số estimates sẽ được quy định theo size của chiếc áo phông, dự tính task đó sẽ hoàn thành trong 1 giờ, 2 giờ hay là 1 tuần, sau đó team sẽ thống nhất vừa đánh dấu size cho các task và dựa vào số số size ta sẽ có được con số estimate cho tất cả các task trong dự án: XS = < 4 giờ S = 4~6 giờ M = 1 ~ 2 ngày L = 3~4 ngày XL = 1 tuần hoặc hơn

3. Dot Voting - Chấm điểm

Phương pháp này liên quan đến việc sử dụng các điểm đặc biệt, điểm số của người dùng cho thấy tiếng nói của những người tham gia. Tất cả các user story sẽ được đánh giá trên các thẻ riêng biệt và được đặt trên mặt bàn hoặc là bảng. Để thực hiện đánh giá, môi người tham gia sẽ được nhận cùng một số điểm và sau đó mỗi thành viênc sẽ tự phân phối điểm của mình cho các task mà họ cảm thấy phù họp, những task càng nhiều đểim thì sẽ càng phức tạp và mất nhiều thời gian hơn.

Sau khi mỗi người tham gia đưa ra đánh giá và phân phối tất cả số điểm điểm của mình, thì tổng số điểm được đặt cho mỗi lịch sử người dùng được tính. Do đó, tất cả các task sẽ được xếp hạng theo tổng số điểm được mọi người trong team vote. Về cơ bản, đây là một phương pháp xếp hạng tốt để quyết định thứ tự của Product Backlog từ User Story lớn nhất đến User Story nhỏ nhất theo mức độ ưu tiên của chúng. Và đây là một kỹ thuật rất tốt để phân biệt những User Story có thể sẽ có thay đổi.

4. Planning Poker

Theo một khảo sát thì đây là một trong những kỹ thuật phổ biến nhất. Tất cả những gì bạn cần là một trí tưởng tượng tốt . Và người sáng lập phương pháp này là Mike Cohn.

Mỗi thành viên sẽ nhận được một bàn và bộ thẻ. Sử dụng một loại số đặc biệt, họ sẽ ước tính. Trên một số thẻ, họ sẽ có ký tên. Và phương pháp này sẽ thực hiện như sau:

• User Story (câu chuyện của người dùng) được thông báo cho toàn bộ nhóm, trong đó mỗi thành viên trong nhóm ước tính số điểm Story Points và không tiết lộ lựa chọn của mình cho người khác.
• Tất cả số điểm Story Points sẽ được công bố cùng một lúc
• Tất cả các Estimation sẽ được người đánh giá giải thích và sau đó đưa ta thảo luận
• Sau đó, 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.

5. Ordering rule - Quy tắc đặt hàng

Phương pháp này là một trò chơi step-by-step, mục tiêu của nó là xây dựng tất cả các nhiệm vụ liên quan đến nhau trên một quy mô duy nhất. Tất cả các User Story được viết ra trên thẻ. Các thẻ với các nhiệm vụ được đặt ngẫu nhiên trên một bảng với một kích thước ngẫu nhiên. Mỗi người tham gia, lần lượt, thực hiện đánh giá của mình bằng cách kéo các thẻ User Story.

Và phương pháp này sẽ thực hiện như sau:

• Các User Story sẽ được đặt từ thấp đến cao và được đặt với các điểm số ngẫu nhiên. Mỗi người tham gia được yêu cầu di chuyển bất kỳ một mục nào trên thang đo, cùng một lúc. Có thể là một lên, một xuống hoặc chuyển lần lượt cho một thành viên khác.
• Điều này cũng đưa ra thứ tự ưu tiên của các mục Product Backlog. Nó cung cấp kích thước tương đối chính xác cho các mặt còn tồn đọng của User Story
• Điều này tiếp tục cho đến khi tất cả những người tham gia hài lòng và không muốn di chuyển bất kỳ mục nào.

Phương pháp này khá hiệu quả để Estimation một số lượng task nhỏ (5-15). Những người tham gia được tham gia vào một quy trình chơi trò chơi chung và thay đổi vị trí User Story so với nhau để đạt được độ chính xác cao của đánh giá.

6. The Bucket System

Kỹ thuật này khá giống với Planning Poker. Ước tính được thực hiện bằng cách đặt các mục trong các thùng, mỗi nhóm đại diện cho một mức Estimation, trong một số nhóm nhỏ hơn.

Bucket System là một cách để ước tính số lượng lớn các task với một nhóm người có quy mô vừa và lớn, và thực hiện nhanh chóng. Hệ thống Xô có các phẩm chất sau đây khiến nó đặc biệt phù hợp để sử dụng trong môi trường Agile:

• Nhanh ! Một khố lượng task lớn có thể được Estimate trong ít thời gian như một giờ.
• Sự hợp tác . Mọi người trong một nhóm tham gia gần như bằng nhau.
• Nó cung cấp kết quả tương đối (điểm so với giờ).
• Làm việc với các nhóm để ước tính nỗ lực hoặc với các bên liên quan để ước tính giá trị.

Kết Luận Một việc cần được ghi nhớ trong suốt quy trình estimate này là ước lượng không phải là đã kết thúc công việc. Theo triết học Agile, cần xác định được việc nỗ lực ít nhất có thể mà vẫn hoàn thành được công việc. Các ước tính là cần thiết để ưu tiên cho việc xử lý những vấn đề còn tồn đọng và để đạt được sự phân bổ có ý nghĩa hơn cho mỗi sprint. Bằng cách làm như vậy, user story bắt đầu được thực hiện, không phải chỉ là ước tính và lập kế hoạch.

Cuối cùng, các ước tính tốt nhất là từ các quan điểm tập thể của toàn bộ nhóm. Việc sử dụng ý kiến của người quản lý hoặc chuyên gia sẽ giúp các ước tính lạc quan hơn. Ngược lại, việc sử dụng phần lớn ý kiến của các cá nhân mới vào nhóm có thể dẫn đến ước tính khối lượng thời gian và công việc lớn hơn mức cần thiết. Sau tất cả Agile là bao gồm tất cả mọi người.

Reference: https://www.softwaretestingmaterial.com/agile-estimation-techniques-software-testing-material/