Có thể thay đổi ước tính ở giữa một lần lặp không?


14

Chúng tôi đã bắt đầu sử dụng Agile / Scrum trong một nhóm gồm 4 nhà phát triển. Chúng tôi đã ước tính câu chuyện của mình và đặt hàng những câu chuyện Những câu chuyện được tiên đoán trong hồ sơ tồn đọng của sản phẩm.

Chúng tôi bắt đầu với ước tính dựa trên điểm về độ phức tạp từ 1 đến 5, thay vì 1,2,3,5,8,13 thông thường .... v.v.

Sau khi thực hiện một vài câu chuyện, chúng tôi cảm thấy rằng một số câu chuyện được ước tính 4 điểm chỉ nên là 2 trong khi những câu chuyện khác được ước tính là 2 thì phức tạp hơn rất nhiều và nên được ước tính là 5. Tôi muốn biết rôi:

  • Có ổn không khi thay đổi ước tính câu chuyện của chúng tôi ở giữa vòng lặp?
  • Có ổn không khi sử dụng các điểm ước tính hiện tại từ 1 đến 5, thay vì 1,2,3,5,8,13 thông thường .... v.v.

Mặc dù cá nhân tôi cảm thấy rằng nó không nên cho cả hai trường hợp nhưng tôi cần sao lưu bản thân vì sự hiểu biết của tôi không rõ ràng lắm (Mặc dù vậy, bất kỳ tài liệu tham khảo tốt nào cũng sẽ tốt!)


4
Hãy tự hỏi: lợi ích của việc dành thời gian ước tính lại giữa giai đoạn nước rút là gì? Lợi ích của việc dành nhiều thời gian hơn để 'tranh luận' về mức độ chi tiết 3 so với 4 so với 5 so với mức 3 so với 5 thô là gì?
Hugo

Câu trả lời:


13

Có ổn không khi thay đổi ước tính câu chuyện của chúng tôi ở giữa vòng lặp?

Tuyệt đối không. Chúng tôi hy vọng điều đó sẽ xảy ra. Và chúng tôi hy vọng các lỗi sẽ tự cân bằng theo thời gian. Chúng tôi chỉ thực sự điều chỉnh các ước tính khi rõ ràng rằng một danh mục nhất định (ví dụ: các trang web mới) sẽ luôn phức tạp hơn chúng tôi nghĩ khi chúng tôi ước tính tất cả.

Khi một câu chuyện sử thi được chia thành các câu chuyện nhỏ hơn (sẽ xảy ra rất lâu trước khi chạy nước rút), chúng ta có thể xuất hiện để điều chỉnh ước tính ban đầu, nhưng tôi sẽ gọi nó là tinh chỉnh hơn là đánh giá lại. Đó là bởi vì chúng tôi có một cái nhìn rõ ràng hơn tại thời điểm đó.

Lập kế hoạch và lập kế hoạch nhanh nhẹn của Mike Cohn là một cuốn sách hay về chủ đề này. Tôi sẽ cảnh báo không sử dụng nó (hoặc bất kỳ cuốn sách "Agile" nào) làm kinh thánh, nhưng đó là điểm khởi đầu tốt để tinh chỉnh quy trình của bạn.

Anh ấy nói về cách các ước tính sai lầm cân bằng thành "ma thuật", nhưng nhấn mạnh rằng anh ấy đã thấy nó hoạt động nhiều lần.

Có ổn không khi sử dụng các điểm ước tính hiện tại từ 1 đến 5, thay vì 1,2,3,5,8,13 thông thường .... v.v.

Việc sử dụng chuỗi ước tính điểm Fibonacci là một sự chấp nhận rằng câu chuyện càng lớn thì ước tính của chúng tôi càng kém chính xác (xem nhận xét trước đó của tôi về Epics).

Nhưng, nếu nó không hiệu quả với bạn, đặc biệt nếu bạn giữ tất cả các công việc của mình nhỏ, thì đừng sử dụng nó. Đó là một hướng dẫn, không phải là một quy tắc.

Kích cỡ áo phông (SML XL XXL) cũng phổ biến và về cơ bản không khác gì (1 2 3 4 5).


+1: Thảo luận về điều này trong quá trình hồi tưởng của bạn. Ước tính lại khi bạn ưu tiên lại vào đầu mùa xuân tới. Đó là lý do tại sao bạn có nước rút. Không có chi phí quản lý trong quá trình chạy nước rút - chỉ cần tạo mã.
S.Lott

Về việc sử dụng chuỗi fabonacci, Giả sử bạn biết rằng một câu chuyện sẽ mất gần 3 ngày và không. nhiệm vụ để làm câu chuyện là A, B, C. Bạn cũng cảm thấy rằng nó không phức tạp lắm nhưng mỗi nhiệm vụ này sẽ mất 1 ngày mỗi lần. Bạn ước tính gì cho câu chuyện?
tintin

@tintin: Lý do sử dụng điểm là để tránh nói những câu như "bạn biết rằng một câu chuyện sẽ mất gần 3 ngày." Điểm tương đối tùy ý, mỗi công việc dựa trên độ phức tạp so với các công việc khác (rõ ràng bạn nên tránh sử dụng các công việc bị đánh giá sai làm đường cơ sở). Nhưng, bạn tránh những con số bị thiếu, để tính đến sự không chắc chắn. Vì vậy, nếu công việc B phức tạp gấp đôi công việc A và công việc A được đánh dấu là 2 điểm, bạn đánh dấu công việc B là 5 điểm.
pdr

+1 cho: câu chuyện càng lớn, ước tính của chúng tôi càng kém chính xác
kevchadder

1

Có ổn không khi thay đổi ước tính câu chuyện của chúng tôi ở giữa vòng lặp?

Hoàn toàn có - nếu nó sẽ ảnh hưởng đến kế hoạch mùa xuân hiện tại hoặc tương lai. Điểm nhanh nhẹn là dựa trên hành động của bạn dựa trên thông tin hiện tại và chính xác nhất có thể.

Nếu một ước tính hóa ra sai đến mức nước rút hiện tại không thể kết thúc trong bảng thời gian của nó, bạn cần phải hành động theo ước tính đã sửa đổi, vì vậy bạn có thể muốn thay đổi nó. Nếu bạn dựa trên những ước tính mới về những cái cũ (và thực sự nhìn vào những cái đó thay vì dựa vào bộ nhớ / kinh nghiệm), bạn cần chúng phải chính xác.

Mặt khác, không có thực sự bất kỳ giá trị cho mỗi gia nhập trong một ước tính là chính xác. Đừng lãng phí thời gian vào việc làm đẹp lên một số thống kê vô nghĩa.


Trong trường hợp của chúng tôi, ước tính ban đầu là một ước tính lớn, và công việc đó hóa ra ít hơn nhiều. Vì vậy, nó không phải là chạy nước rút hiện tại của chúng tôi không hoàn thành trong thời gian nhưng chúng tôi có thêm thời gian. Vì vậy, người quản lý đang đề nghị hạ thấp ước tính.
tintin

@Michael, câu trả lời này có thể đúng với một số quy trình nhanh nhưng câu hỏi liên quan đến Scrum. Trong Scrum, không nên thay đổi điểm câu chuyện sau khi lập kế hoạch chạy nước rút vì số liệu Vận tốc nhóm có thể bị tổn hại.
GuyR

Ước tính thất bại mang một lợi ích ở chỗ bạn có thể sử dụng chúng để điều chỉnh bất kỳ ước tính nào trong tương lai. Nếu bạn ước tính quá lâu, thì đó là một thất bại nhiều như ước tính quá ngắn, vì kết quả là tài nguyên không được sử dụng đúng mức. Giá trị trong các ước tính chính xác là bạn biết rằng bạn có khả năng đạt được các mục tiêu phát hành của mình và nhóm của bạn được sử dụng đầy đủ. Do đó, bạn luôn dựa trên các ước tính trong tương lai dựa trên kinh nghiệm trong quá khứ, điều chỉnh theo những gì bạn tìm hiểu về ước tính của mình trên đường đi.
S.Robins
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.