Làm thế nào để đánh giá ước tính và điểm câu chuyện trong Scrum?

Question

Cho phép lấy ví dụ giả sử chúng tôi có 5 câu chuyện A, B và C, D, E.

Importance Name Estimate 
90   B 
70   A 
50   C 
35   E 
10   D 

Câu chuyện được sắp xếp dựa trên mức độ quan trọng (mức độ ưu tiên). Làm thế nào để bạn ước tính họ? Có được ước tính dựa trên kích thước của đối tượng địa lý không? Ví dụ: tôi đã cung cấp cho họ các giá trị ước tính:

Importance Name Estimate 
90   B  10 
70   A  12 
50   C  9 
35   E  20 
10   D  11 

Giả sử đó là chạy nước rút trong 2 tuần. Đây là kích thước thời gian 14 ngày = 5,14x5 = 70 ngày-người. Bây giờ giá trị 10 có nghĩa là gì? Điều đó có nghĩa là số lượng thời gian (giờ hoặc ngày) mà một nhóm nên chi tiêu? Và điểm câu chuyện là gì? Giả sử đây là lần chạy nước rút đầu tiên; làm thế nào bạn sẽ ước tính số lần chạy nước rút khi bạn không có vận tốc chạy nước rút cuối cùng?

Answer 1

Argh! Phục vụ tôi đúng cho việc viết từ bộ nhớ.

Điểm câu chuyện có liên quan đến ước tính của khóa học và khi bạn cố gắng tìm ra số tiền bạn có thể làm cho chạy nước rút, điểm câu chuyện là một đơn vị "công việc" cần thiết để thực hiện một phần hoặc toàn bộ tính năng . Một câu chuyện có thể là một ngày, hoặc một giờ, hoặc một cái gì đó ở giữa. Tôi đã nhầm lẫn "ước tính" và "điểm câu chuyện" bên dưới, không biết tôi đang nghĩ gì.

Điều tôi viết ban đầu là "ước tính" và "điểm câu chuyện". Những gì tôi có nghĩa là để viết (và chỉnh sửa dưới đây) là "câu chuyện điểm" và "vận tốc".

---

Điểm câu chuyện và vận tốc đi cùng nhau để giúp bạn cảm nhận "chúng ta có thể hoàn thành trong một khoảng thời gian nhất định".

Hãy lấy một ví dụ.

Giả sử bạn muốn ước tính tính năng theo giờ, do đó, tính năng có ước tính 4 sẽ mất 4 giờ để hoàn thành, bởi một người, do đó bạn chỉ định ước tính đó cho tất cả các tính năng. Do đó, bạn xem xét tính năng đó, hoặc "câu chuyện" của nó, đáng giá 4 điểm khi nói đến cạnh tranh cho các nguồn lực.

Bây giờ chúng ta hãy nói rằng bạn có 4 người trong dự án của bạn, mỗi người làm việc trong một tuần 40 giờ bình thường, nhưng do những thứ khác xảy ra xung quanh họ, như hỗ trợ, nói chuyện với tiếp thị, cuộc họp, v.v. chỉ có thể làm việc 75% trên các tính năng thực tế, 25% còn lại sẽ được sử dụng cho các nhiệm vụ khác đó.

Vì vậy, mỗi người có 30 giờ có sẵn mỗi tuần, cung cấp cho bạn 30 * 4 = 120 giờ tổng cộng cho tuần đó khi bạn đếm tất cả 4 người.

Bây giờ, chúng ta cũng nên nói rằng bạn đang cố gắng tạo ra một chạy nước rút trong 3 tuần, có nghĩa là bạn có 3 * 120 giờ giá trị công việc bạn có thể hoàn thành. Đây là vận tốc của bạn, bạn di chuyển nhanh đến mức nào, bạn có thể hoàn thành bao nhiêu "điểm câu chuyện".

Đơn vị vận tốc của bạn phải tương thích với đơn vị cho điểm câu chuyện của bạn. Bạn không thể đo lường câu chuyện trong "số lượng các nhà phát triển sẽ tiêu thụ trong khi thực hiện điều này" với "chúng tôi có sẵn bao nhiêu giờ".

Sau đó, bạn cố gắng tìm một tập hợp các đối tượng địa lý gần nhau, nhưng không quá 120 điểm, được xếp hạng theo mức độ ưu tiên của chúng. Điều này chỉ đơn giản là để tổng tích lũy từ trên xuống dưới cho đến khi bạn đạt được một nhiệm vụ mà lời tổng hợp, hoặc bằng, những 120 điểm. Nếu nó tipped nó hơn, không bao gồm các nhiệm vụ.

Bạn có thể dễ dàng ước tính trong ngày hoặc tách cà phê do nhà phát triển tiêu thụ, giống như số đại diện cho loại công việc bạn đang làm và có thể liên quan đến công việc thực tế bạn sẽ thực hiện (nghĩa là bạn có bao nhiêu thời gian).

Bạn cũng nên đánh giá khối lượng công việc của mình sau mỗi lần chạy nước rút để tìm hiểu xem số 75% đó có chính xác hay không. Ví dụ: nếu bạn chỉ quản lý một nửa số tiền bạn đã đặt ra để làm, hãy tìm hiểu xem ước tính tính năng của bạn có sai hay nếu ước tính tải công việc của bạn sai. Sau đó, hãy xem những gì bạn đã học được khi tính toán và lập kế hoạch cho các lần chạy nước rút sau.

Cũng lưu ý rằng các tính năng nên được chia nhỏ nếu chúng trở nên quá lớn. Lý do chính cho điều này là các ước tính lớn hơn có nhiều sự không chắc chắn hơn được xây dựng trong chúng, và bạn có thể giảm thiểu điều đó bằng cách chia nhỏ nó thành các tính năng phụ và ước lượng chúng. Tính năng tổng thể lớn sau đó trở thành tổng của tất cả các tính năng phụ. Nó cũng có thể cung cấp cho bạn khả năng phân chia các tính năng trên nhiều người, bằng cách gán các tính năng phụ khác nhau cho những người khác nhau.

Một nguyên tắc nhỏ là tính năng mà có một ước tính hơn 1 ngày có lẽ nên được chia. *

Answer 2

Với một nhóm hoặc dự án mới, chúng tôi luôn bắt đầu bằng cách giả định điểm câu chuyện là một "ngày lý tưởng" duy nhất và chúng tôi tính mỗi nhà phát triển nhận được khoảng 3,5 ngày lý tưởng mỗi tuần, đó là cách chúng tôi tính toán vận tốc ban đầu.

Khi bạn đã trải qua giai đoạn "lên kế hoạch chơi bài" và cân bằng/so sánh tất cả các câu chuyện của mình, thời gian thực tế của một câu chuyện thực sự không rõ - tất cả những gì bạn thực sự có là ý tưởng khá hay về Thời gian và sử dụng phán đoán tốt nhất của bạn để tìm ra vận tốc có khả năng.

Ít nhất, đó là cách tôi làm điều đó!

Nếu bạn đang hướng các điểm câu chuyện của mình gần bằng một ngày lý tưởng, thì tôi khuyên bạn nên chia nhỏ câu chuyện thành những câu chuyện nhỏ hơn, nếu không bạn sẽ không có thời gian tốt trong việc lên kế hoạch và theo dõi lặp lại .

Answer 3

Hãy nhớ rằng điểm chỉ là ROM (để thô của cường độ) thiết lập thông qua việc sử dụng "Planning Poker" như một thực tế phổ biến. Vài lần chạy nước rút đầu tiên là khi bạn bắt đầu xác định những điểm có ý nghĩa đối với đội bóng và bạn càng đi đúng đội càng chính xác.

Thêm giao diện để sử dụng các điểm được cách nhau hơn một chút. Một thực tế tôi đã nhìn thấy và sử dụng là sử dụng trình tự fibonacci, nó đảm bảo rằng bạn không có quá nhiều điểm khác biệt 1 điểm.

Cũng đừng quên người kiểm tra, khi chỉ ra một câu chuyện mà bất kỳ ai thực hiện kiểm tra cũng cần phải cân nhắc như đôi khi một nhiệm vụ phát triển đơn giản có thể gây ra một nỗ lực thử nghiệm lớn và nếu đúng là Sprint thì ý tưởng là mọi thứ đã hoàn thành được vận chuyển (được xây dựng, kiểm tra và ghi lại). Vì vậy, ước tính của một câu chuyện được xác định bởi nhóm không phải bởi một cá nhân.

Answer 4

Câu trả lời hay ở mọi nơi.

Một điểm tôi muốn thêm là nó không thực sự quan trọng những gì bạn chọn làm cơ sở cho giá trị điểm của bạn (giờ, ngày lý tưởng, bất kỳ điều gì khác). Điều quan trọng là giữ cho nó nhất quán.

Nếu bạn giữ nó phù hợp, nó sẽ cho phép bạn khám phá "vận tốc thực sự" của nhóm của bạn. Ví dụ cho phép nói rằng bạn đã có vài lần lặp:

iteration 1 = 120 points 
iteration 2 = 95 points 
iteration 3 = 115 points 

Và bây giờ bạn đang bắt đầu lặp lại 4 và bạn đã sau trong việc tồn đọng (được sắp xếp vào ưu tiên):

item 1 = 50 points 
item 2 = 30 points 
item 3 = 30 points 
item 4 = 40 points 

Bây giờ giả sử điểm ước tính của bạn nhất quán, bạn có thể chắc chắn rằng nhóm sẽ hoàn thành các mục 1,2 và có thể là 3 nhưng chắc chắn không phải là 4.

Bạn có thể áp dụng tương tự để phát hành nhật ký để cải thiện dự đoán ngày phát hành. Đây là những gì cho phép các nhóm Scrum cải thiện ước tính của họ khi họ đi cùng.

Answer 5

Giá trị 10 chỉ là giá trị tương đối so với các ước tính khác, ví dụ: nó là một nửa như khó khăn như là một 20 hoặc hơi khó khăn hơn một 9. Không có một bản dịch cụ thể của 1 điểm = x giờ nỗ lực là một cái gì đó để chỉ ra.

Nơi tôi làm việc, chúng tôi có những gì chúng tôi gọi là "điểm sử thi", điều này khó khăn như thế nào là một số câu chuyện cấp cao, ví dụ: tích hợp Tìm kiếm vào một trang web mới, sẽ bao gồm nhiều câu chuyện để hoàn thành và sau đó chúng tôi ước tính số giờ trên mỗi câu chuyện được tạo từ việc chia nhỏ từng sử thi, ví dụ: chỉ cần đặt Tìm kiếm trong tài liệu hỗ trợ trên trang web. "Các điểm sử thi" được phân phối trong một biến thể của các số Fibonacci (1,2,3,5,8,13,21,28,35) để các sử thi rộng hơn, mơ hồ hơn chỉ nhận được một giá trị lớn, ví dụ: bất cứ điều gì lớn hơn 8, là một chỉ báo rằng nó có thể được chia thành những câu chuyện dễ đoán hơn. Nó cũng đáng chú ý ở đây là nơi tôi làm việc, chúng tôi chỉ làm việc 5 ngày một tuần và trong mỗi lần chạy nước rút một ngày bị mất cho các cuộc họp như bản demo, cuộc họp lập kế hoạch lặp lại, hồi tưởng và đánh giá để chỉ có 9 ngày để chạy nước rút. Thêm lập trình ghép đôi cho một số thứ, thời gian để sửa lỗi và các tác vụ phi dự án khác như vé hỗ trợ và sẽ trở nên khá khó khăn để nói số lượng nhà phát triển sẽ dành bao nhiêu giờ trong lần chạy nước rút.

Một vài lần chạy nước rút đầu tiên là nơi giá trị bắt đầu trở nên cụ thể hơn dựa trên trải nghiệm thu được, ước tính có thể trở nên rõ ràng hơn về cách đoán giá trị.

Answer 6

JB King có câu trả lời đúng nhất, nhưng không có phiếu bầu nào có nghĩa là thông tin không chính xác đang được phổ biến và đóng góp vào việc giải thích thông thường của người nghèo. Xin vui lòng xem các câu trả lời thực tế từ một trong những người thiết kế Scrum ở đây:

http://blog.mountaingoatsoftware.com/seeing-how-well-a-teams-story-points-align-from-one-to-eight

Hãy nhớ rằng, đó là về nỗ lực, không phức tạp.

Bây giờ đọc về và xem video ở đây: Thông tin

http://www.agilebok.org/index.php?title=Relative_Sizing_and_Story_Points