Tại sao chuỗi Fibonacci được sử dụng trong poker lập kế hoạch nhanh? [đóng cửa]

Khi ước tính kích thước tương đối của câu chuyện người dùng trong phát triển phần mềm nhanh, các thành viên của nhóm phải ước tính kích thước của câu chuyện người dùng là 1, 2, 3, 5, 8, 13, .... Vì vậy, các giá trị ước tính phải giống với chuỗi Fibonacci. Nhưng tôi tự hỏi, tại sao?

Mô tả của http://en.wikipedia.org/wiki/Planning_poker trên Wikipedia giữ một câu bí ẩn:

Lý do sử dụng dãy Fibonacci là để phản ánh sự không chắc chắn cố hữu trong việc ước tính các mục lớn hơn.

Nhưng tại sao lại có sự không chắc chắn cố hữu trong các mặt hàng lớn hơn? Không phải độ không chắc chắn sẽ cao hơn, nếu chúng ta thực hiện ít phép đo hơn, nghĩa là nếu ít người ước tính câu chuyện tương tự hơn? Và ngay cả khi độ không chắc chắn cao hơn trong các câu chuyện lớn hơn, tại sao điều đó lại ngụ ý việc sử dụng dãy Fibonacci? Có một lý do toán học hoặc thống kê cho nó? Nếu không, việc sử dụng chuỗi Fibonacci để ước tính giống như khoa học CargoCult đối với tôi.

Chuỗi Fibonacci chỉ là một ví dụ về quy mô ước lượng hàm mũ. Lý do thang đo hàm mũ được sử dụng đến từ Lý thuyết thông tin.

Thông tin mà chúng tôi thu được từ ước tính phát triển chậm hơn nhiều so với độ chính xác của ước tính. Trong thực tế, nó phát triển như một hàm logarit. Đây là lý do cho độ không chắc chắn cao hơn đối với các mặt hàng lớn hơn.

Trong thực tế, việc xác định cơ số tối ưu nhất của thang số mũ (chuẩn hóa) là khó khăn. Cơ sở tương ứng với thang Fibonacci có thể tối ưu hoặc không.

Dưới đây là giải thích chi tiết hơn về phép biện minh toán học: http://www.yakyma.com/2012/05/why-progressive-estimation-scale-is-so.html

Trong số sáu số đầu tiên của dãy Fibonacci, bốn số là số nguyên tố. Điều này hạn chế khả năng chia nhỏ một nhiệm vụ thành các nhiệm vụ nhỏ hơn để có nhiều người cùng làm việc đó. Làm như vậy có thể dẫn đến quan niệm sai lầm rằng tốc độ của một nhiệm vụ có thể tăng tỷ lệ thuận với số lượng người làm việc đó. Loạt 2 ^ n dễ bị vấn đề như vậy nhất. Trên thực tế, dãy Fibonacci buộc người ta phải ước tính lại từng nhiệm vụ nhỏ hơn.

Theo blog nhanh nhẹn này

"bởi vì chúng phát triển với cùng tốc độ mà con người chúng ta có thể nhận thấy những thay đổi có ý nghĩa về độ lớn."

Đúng vậy. Tôi nghĩ rằng đó là bởi vì họ thêm không khí hợp pháp (Fibonacci! Toán học!) Về bản chất là một bài tập xác định kích thước giai đoạn đầu, rất cao (không xác định phạm vi) (không có giá trị).

Nhưng bạn có thể nhận được kết quả tương tự khi sử dụng định cỡ áo thun ...

Bạn chắc chắn muốn một cái gì đó theo cấp số nhân, để bạn có thể biểu thị bất kỳ lượng thời gian nào với sai số tương đối không đổi. Độ chính xác của ước tính của bạn cũng rất có thể tỷ lệ thuận với ước tính của bạn.

Vì vậy, bạn muốn một cái gì đó: a) với số nguyên b) cấp số nhân c) dễ dàng

Bây giờ tại sao Fibonacci thay vì, 1 2 4 8? Tôi đoán là do fibonacci phát triển chậm hơn. Nó tính bằng goldratio ^ n và goldratio = 1,61 ...

Chuỗi Fibonacci chỉ là một trong số những chuỗi được sử dụng trong poker lập kế hoạch dự án.

Rất khó để ước tính chính xác các đơn vị công việc lớn và rất dễ bị sa lầy trong các cuộc thảo luận hàng giờ so với ngày nếu con số của bạn quá “thực tế”.

Tôi thích lời giải thích tại http://www.agilelearninglabs.com/2009/06/story-sizing-a-better-start-than-planning-poker/ , cụ thể là chuỗi Fibonacci đại diện cho một tập hợp các số mà chúng ta có thể phân biệt bằng trực giác giữa chúng như độ lớn khác nhau.

Tôi sử dụng Fibonacci vì một số lý do:

• Khi nhiệm vụ lớn hơn, các chi tiết trở nên khó nắm bắt hơn
• Ước tính nhiệm vụ là số giờ để mọi người trong nhóm hoàn thành nhiệm vụ
• Không phải tất cả mọi người trong nhóm sẽ có cùng một lượng kinh nghiệm cho một nhiệm vụ cụ thể, do đó, điều này cũng làm tăng thêm sự không chắc chắn
• Con người cảm thấy mệt mỏi vì nhiệm vụ lớn hơn và có khả năng phức tạp hơn. Trong khi một nhiệm vụ phức tạp gấp đôi được giải quyết trong thời gian gấp đôi cho một máy tính thì có thể nhà phát triển sẽ mất nhiều thời gian hơn một chút.

Khi chúng tôi cộng lại tất cả những điều không chắc chắn, chúng tôi không chắc chắn về giờ thực sự nên là bao nhiêu. Nó kết thúc dễ dàng hơn nếu chúng ta có thể đánh giá xem nhiệm vụ này lớn hơn / nhỏ hơn nhiệm vụ khác mà chúng tôi đã đưa ra ước tính. Khi chúng ta tăng quy mô / độ phức tạp của nhiệm vụ, ảnh hưởng của sự không chắc chắn cũng được khuếch đại. Tôi sẽ rất vui khi ước tính 13 giờ cho một nhiệm vụ có vẻ lớn gấp đôi so với công việc mà tôi đã ước tính trước đây là 5 giờ.