Tại sao chúng ta sử dụng điểm câu chuyện thay vì ngày con người khi ước tính câu chuyện của người dùng?


132

Trong các phương pháp nhanh (ví dụ SCRUM), độ phức tạp / nỗ lực cần thiết cho các câu chuyện của người dùng được đo bằng các điểm Câu chuyện. Điểm câu chuyện được sử dụng để tính toán số lượng câu chuyện người dùng mà một nhóm có thể thực hiện trong một lần lặp.

Lợi thế của việc giới thiệu một khái niệm trừu tượng (điểm câu chuyện) là gì, nơi chúng ta chỉ có thể sử dụng một phép đo cụ thể, như ước tính ngày của con người? Chúng ta cũng có thể tính toán vận tốc, ước tính phạm vi của một lần lặp, v.v ... bằng cách sử dụng số ngày ước tính.

Ngược lại, các điểm câu chuyện khó sử dụng hơn (vì khái niệm này là trừu tượng), và cũng khó giải thích hơn cho các bên liên quan. Nó mang lại lợi thế gì?


16
Tại sao bạn lại cho rằng ngày của con người cụ thể hơn câu chuyện, không phải vậy.
Ryathal

4
Có phải dễ dàng hơn để giải thích rằng ước tính của bạn về 5 ngày làm việc có nghĩa là sẽ mất 1 tháng để hoàn thành vì vận tốc của bạn là 0,25 ngày-ngày / lịch?
Patrick

3
@Izkata điều đó chỉ đúng nếu vận tốc của bạn luôn chính xác là 1
Patrick

4
@Patrick Khi sử dụng man-days (xem man-hours trên Wikipedia), không có khái niệm về vận tốc. Đó là một điều nhanh nhẹn / scrum.
Izkata

3
Điều thú vị là ngay khi vận tốc ổn định, các điểm câu chuyện có xu hướng được xác định với một số giờ hoặc ngày nhất định. Ví dụ: 1 điểm câu chuyện = 1 ngày. Nếu tôi nghĩ sẽ mất 2 ngày, tôi sẽ ước tính 2 điểm câu chuyện.
Giorgio

Câu trả lời:


126

Tôi nghĩ một trong những lợi thế chính là con người và các nhà phát triển thực sự khá tệ trong việc ước tính thời gian. Hãy nghĩ về bản chất của sự phát triển - đó không phải là một sự tiến triển tuyến tính từ đầu đến cuối. Nó thường "viết 90% mã trong 10 phút và sau đó xé tóc ra gỡ lỗi trong 17 giờ." Điều đó khá khó để ước tính theo nghĩa thời gian của đồng hồ.

Nhưng việc sử dụng một sự trừu tượng sẽ lấy đi sự tập trung của thời gian thực tế tính bằng giờ hoặc ngày và thay vào đó tập trung vào việc mô tả chi phí tương đối và độ phức tạp của một nhiệm vụ so với các nhiệm vụ khác. Con người / nhà phát triển tốt hơn ở đó. Và sau đó, khi bạn trở nên ồn ào với những ước tính điểm đó và một số tiến bộ thực tế, bạn có thể bắt đầu xem xét thời gian theo kinh nghiệm hơn.

Tôi nghi ngờ rằng cũng có một hiệu ứng quan sát xảy ra với ước tính thời gian sẽ không xảy ra với ước tính điểm. Chẳng hạn, việc khuyến khích túi cát ước tính và đưa ra cách "vượt tiến độ" sẽ bị tắt tiếng với sự gián tiếp trong một hệ thống dựa trên điểm.


28
+1 cho sự tập trung vào sự phức tạp , không phải thời gian. Dịch sang giờ thô sẽ dễ dàng một khi bạn có đủ nước rút trong vành đai của mình. Tôi thấy rằng sự thay đổi giữa các câu chuyện bị cuốn trôi theo thời gian.
Kristo

14
Vì vậy, thực sự, điểm phức tạp có thể là một thuật ngữ rõ ràng hơn so với điểm câu chuyện, và bất kỳ công việc với quá nhiều điểm phức tạp là quá phức tạp và có lẽ liên quan đến quá nhiều rủi ro và chưa biết để đối phó với tất cả trong một đi. Sự phức tạp có chi phí theo cấp số nhân, và người nghèo khổ bị mắc kẹt với nhiệm vụ đó sẽ đào một cái hố sâu đến nỗi anh ta sẽ không gặp lại trong nhiều tuần hoặc nhiều tháng. Tốt hơn là thực hiện một nhiệm vụ đơn giản hơn là hiểu nhiệm vụ phức tạp trước, và chia nó thành các nhiệm vụ nhỏ hơn với độ phức tạp ít rủi ro hơn và hiểu rõ hơn.
Supr

4
Thời gian và chi phí là hiệu ứng, sự phức tạp là nguyên nhân và bạn không thể hiểu thời gian mà không hiểu sự phức tạp.
Supr

8
Điểm câu chuyện = Điểm phức tạp - 2 âm tiết. :-D
Kristo

5
Có ai từng xem điểm gọi câu chuyện "đúc chi phí?" => mọt
Aaron Gibralter

59

Nếu bạn đang sử dụng các số Fibonacci (hoặc một cái gì đó tương tự), nó sẽ giới hạn số lượng tùy chọn khi ước tính một câu chuyện. Tôi đã làm việc với một nhóm chỉ sử dụng các số thấp: 1, 2, 3, 5, 8 và 13. Chúng tôi có một câu chuyện tham khảo là 5. Điều này cho phép chúng tôi dễ dàng đưa ra quyết định về sự phức tạp của câu chuyện khi thực hiện Kế hoạch Poker . Tác dụng phụ khác là mọi thứ được xếp hạng 13 có thể không có đủ thông tin và cần được chia nhỏ hơn nữa. Tôi thực sự nghi ngờ rằng nó sẽ dễ dàng và đơn giản như vậy nếu chúng ta sử dụng giờ thô.

Chủ sở hữu sản phẩm của bạn nói ngôn ngữ của các bên liên quan và có thể dịch giữa các điểm câu chuyện và giờ làm việc (hoặc các đơn vị khác) khi cần. Trong thời gian làm PO, tôi đã có một số dữ liệu cứng rằng 1 điểm câu chuyện = 4 giờ, nhưng rõ ràng mỗi đội đều khác nhau.

Biên tập:

Với kiến ​​thức là 1 điểm = 4 giờ, về mặt lý thuyết, bạn có thể thay đổi sàn Kế hoạch Poker thành 4, 8, 12, 20, 32 và 52. Nhưng những con số đó cảm thấy khó đối phó hơn. Tôi nghĩ rằng tôi sẽ trừu tượng hóa các giá trị trở lại một cái gì đó đơn giản, ví dụ: "ít hơn một ngày", "hơn một tuần", v.v. Và nếu tôi sẽ làm điều đó, tôi cũng có thể gắn bó với đơn vị trừu tượng điểm vô tận.


Chúng tôi sử dụng phương pháp tương tự và tầng kế hoạch của chúng tôi có số lượng cao hơn nhưng chúng tôi đã xác định 20 vì có nghĩa là nó cần được chia nhỏ hoặc xác định tốt hơn. Đối với chúng tôi, số 13 là nhiệm vụ lớn nhất của chúng tôi và thường đây là những nhiệm vụ cuối cùng chỉ mất một tuần để hoàn thành.
Bill Leeper

"Tác dụng phụ khác là mọi thứ được xếp hạng 13 có thể không có đủ thông tin và cần được chia nhỏ hơn nữa." Và tôi cho rằng nếu nó bị phá vỡ hơn nữa, nó sẽ bị chia thành các phần Fibonacci tương đương?
Joe Z.

@JoeZeng, yeah, những người thường trở thành 8 + 5 hoặc 5 + 5 + 3. Tuy nhiên, đây chỉ là một phép đo trừu tượng, vì vậy nếu những câu chuyện mới đủ gần, thì tôi đã không lo lắng quá nhiều. Nhóm thường có thể hấp thụ 13 trở thành hai 8 hoặc ba 5, nhưng ba 8 có nghĩa là tôi cần có một cuộc nói chuyện rõ ràng với các bên liên quan. Lý tưởng nhất, chúng tôi đã ước tính đủ xa để nó sẽ không ảnh hưởng đến nước rút hiện tại.
Kristo

1
Không cần thiết. Chúng tôi đã có những giả định về câu chuyện được 5 điểm, và tổng chi tiết hơn, chi tiết hơn nằm trong phạm vi 15 điểm. Nó xảy ra.
tro999

24

Đó là để cho phép ước tính trở nên tốt hơn theo thời gian, mà không cần tất cả những người ước tính phải điều chỉnh ước tính của họ.

Thay vì mọi người tham gia vào ước tính phải suy nghĩ như "OK .. trông giống như 2 ngày của đàn ông .. nhưng lần chạy nước rút cuối cùng chúng tôi đã đánh giá thấp mọi thứ, vì vậy có lẽ đó thực sự là 2,5 ngày. Hoặc 3?", Họ vẫn tiếp tục như vậy. "5 điểm câu chuyện!"

Sau đó, bạn điều chỉnh ước tính của mình về số điểm câu chuyện mà nhóm có thể vượt qua trong một lần chạy nước rút, dựa trên thành tích đo được thực tế trong các lần chạy nước rút trước đó. "Chúng tôi đã thực hiện 90-110 điểm câu chuyện mỗi lần chạy nước rút trước đây!"

Tôi muốn nói rằng lý thuyết đằng sau điều này là các nhà phát triển tốt hơn trong việc ước tính độ phức tạp tương đối của các nhiệm vụ dev khác nhau so với việc họ ước tính tuyệt đối . Đặc biệt là nếu nhiều người đang ước tính một nhiệm vụ có thể được thực hiện bởi bất kỳ ai trong số họ (và không phải ai cũng làm việc với tốc độ như mọi người khác).

Thay thế hoài nghi: Tôi đã thấy nó nói rằng các nhà phát triển không bao giờ tham gia theo ước tính thời gian. Nếu một cái gì đó mất nhiều thời gian hơn ước tính, bạn đã đi qua. Nhưng nếu một cái gì đó mất ít thời gian hơn so với ước tính, các nhà phát triển có thể mân mê nó, đĩa vàng hoặc chỉ cần làm chậm và làm cho nó dễ dàng vì họ đã được giao một nhiệm vụ cushy. Lấy các đơn vị thời gian thực ra khỏi một ước tính có thể hạn chế các xu hướng này. Kết thúc thay thế hoài nghi.


13
Điều đó thậm chí không phải là hoài nghi. Đó là nguyên tắc "nhanh hay rẻ hay tốt". Tôi có thể cung cấp cho bạn phiên bản FizzBuzz hoạt động ổn định, chủ yếu hoạt động, sẽ cung cấp cho bạn những gì bạn thường muốn trong vài phút, nhưng nếu bạn muốn tương tác với người dùng, sẽ mất nhiều thời gian hơn và nếu bạn muốn thử nghiệm hồi quy, sẽ mất thời gian lâu hơn và nếu bạn muốn nó không bị lỗi khi bạn nhấn MAX_INT, điều đó sẽ mất nhiều thời gian hơn. Nói với tôi để ưu tiên tốc độ, và tôi sẽ bắt đầu bán phá giá. Nói với tôi để ưu tiên mọi thứ khác, và tôi sẽ sử dụng tất cả thời gian tôi đưa ra.
deworde

17

Man ngày hay giờ đàn ông là như bạn nói cụ thể. Vì vậy, khi một nhiệm vụ được ước tính là 5 giờ và mất 6 giờ thì bây giờ là một nhiệm vụ muộn.

Khi bạn có một câu chuyện là 3 điểm và mất 6 giờ, mất 6 giờ, không muộn, chỉ mất sáu giờ. Việc đo vận tốc hơn là một yếu tố của số lượng điểm bạn thực hiện trong một lần chạy nước rút và con số đó có thể dao động, bởi vì nó không cụ thể. Bạn cũng không đo từng nhiệm vụ, nhưng tổng cộng tất cả các nhiệm vụ. Khi bạn có nhiều giờ cho mỗi nhiệm vụ, sự cám dỗ là ở đó để đo từng nhiệm vụ. Khi điều đó xảy ra, bạn không có lợi ích gì cho việc chạy nước rút để hoàn thành theo thời gian và đó là hậu quả của việc hoàn thành theo thời gian của bất kỳ nhiệm vụ nào.

Nó có thể là một sự chuyển đổi để suy nghĩ về các điểm. Một nơi tôi đã làm việc trước khi chúng tôi thậm chí giới thiệu các kích cỡ áo phông được sử dụng nhanh nhẹn chỉ để có được một ý tưởng về mức độ nỗ lực. Điểm chỉ là một phần mở rộng của điều đó.

Điều đó không có nghĩa là không có tranh cãi, hoặc một số sự phân công tùy tiện cho các điểm. Chúng tôi có các thành viên trong nhóm của chúng tôi hầu như luôn bỏ phiếu số thấp nhất và phàn nàn khi họ nghĩ rằng một nhiệm vụ là 1 và chúng tôi nghĩ rằng đó là số 3 mà chúng tôi đang bị lạm phát điểm.


13

Sự trừu tượng là loại điểm. Sử dụng 'ngày của con người' làm phép đo có một số cạm bẫy, bao gồm:

  1. Nếu nhóm không quen thuộc với công nghệ mà họ sẽ sử dụng, thì có thể rất khó để đưa ra ước tính thời gian thực về thời gian thực hiện một nhiệm vụ. Họ có nhiều khả năng có thể đưa ra các ước tính tương đối tốt - ví dụ: "nhiệm vụ A có thể sẽ mất gấp đôi thời gian so với nhiệm vụ B".
  2. Những người khác nhau làm việc ở mức giá khác nhau! Nếu bạn sử dụng 'man day', bạn sẽ phải thay đổi ước tính thời gian khi một nhiệm vụ được chuyển từ nhà phát triển này sang nhà phát triển khác. Ai định nghĩa bao nhiêu công việc cấu thành một "ngày đàn ông" nào?

Nếu bạn muốn ước tính ngày làm việc thì đó là một phép tính đơn giản:

user points in story / average user points per developer per day = estimated man days

Về điểm 2: làm thế nào để câu chuyện giải quyết điều này? Bạn ước tính một câu chuyện là 4 điểm câu chuyện. Bạn đưa nó cho một lập trình viên nhanh hơn và phải mất 4 ngày. Bạn đưa nó cho một lập trình viên chậm và phải mất 8 ngày. Dường như với tôi rằng vấn đề không được giải quyết mà chỉ di chuyển xung quanh.
Giorgio

Về điểm 1. Ý tưởng là nếu nhóm làm quen với các công nghệ cần thiết cho dự án, vận tốc của họ sẽ tăng lên và kích thước tương đối của câu chuyện, được đo bằng điểm câu chuyện sẽ giữ nguyên. Nhưng nếu hai câu chuyện người dùng đòi hỏi kiến ​​thức khác nhau thì sao? Ví dụ: bạn có một câu chuyện người dùng phía trước được thực hiện trong Javascript / HTML và một câu chuyện người dùng phía sau sẽ được thực hiện bằng Java. Khi nhóm tìm hiểu thêm về Javascript, HTML và Java, họ phát hiện ra rằng phần đầu dễ dàng hơn nhiều so với phần phía sau và các ước tính tương đối của các câu chuyện lại bị sai.
Giorgio

@Giorgio Re. điểm 2: Lập trình viên nhanh hơn của bạn có tốc độ làm việc là 1 điểm / ngày và lập trình viên chậm hơn của bạn có tốc độ làm việc là 0,5 điểm / ngày. Nếu bạn làm điều đó trong vài giờ, hoặc lập trình viên nhanh hơn của bạn sẽ tự làm việc đến chết, hoặc lập trình viên chậm hơn của bạn cần sa thải. Câu trả lời của Bill Leeper làm cho điểm này rất tốt.
vaughandroid

1
Re. điểm 1: Vì tiền của tôi, nếu bạn nói về 2 bộ công nghệ khác nhau và 2 lĩnh vực khác nhau của sản phẩm, bạn đã có hai nhóm.
vaughandroid

Hơn nữa điểm 2: Câu chuyện của người dùng được phát triển bởi nhóm , không phải các nhà phát triển riêng lẻ. Đó là tỷ lệ làm việc của nhóm là phần quan trọng. Hãy nhớ rằng khi thực hiện các câu chuyện của người dùng, bạn nên chia chúng thành các nhiệm vụ trước. Cung cấp cho các nhà phát triển nhanh hơn nhiều nhiệm vụ!
vaughandroid

6

Như đã đề cập, điểm câu chuyện là một thước đo tương đối của sự phức tạp. Người ta có thể sử dụng sức mạnh của 2 chuỗi (1,2,4,8,16 ...) hoặc thang đo Fibonacci (1,2,3,5,8,13,20 ...) để ước tính. Vì các nhà phát triển đặc biệt khá giỏi trong việc nói điều gì đó như thế này:

Tính năng A khó gấp đôi tính năng B

Nhưng thực sự rất khó để nói 'tính năng này sẽ mất bao lâu để thực hiện. Bạn để điều đó được cân bằng bởi vận tốc. Vì vậy, nếu một cái gì đó được ước tính là 5 nhưng hóa ra là 13, tốc độ chậm hơn sẽ bình thường hóa cho phép lặp (hoặc bạn có thể ước tính lại).

Bây giờ, có một cách khác, đó là "ngày lý tưởng" (một số ngày tương tự như ngày của con người nhưng tôi không chắc đó có phải ý bạn không) và tôi biết khá nhiều đội thích điều đó. Ngày lý tưởng sẽ được hiểu là:

Nếu đó là tất cả những gì tôi làm sau khi đến văn phòng và chỉ nghỉ giải lao cần thiết, không bị gián đoạn và sẽ có mọi thứ tôi cần để 'thực hiện câu chuyện', tức là không có hoạt động ngoại vi như họp, trả lời thư, v.v.

Mike Cohn, một trong nhiều nhà truyền giáo nhanh nhẹn nổi tiếng cung cấp sự so sánh sau đây giữa các điểm câu chuyện và ngày lý tưởng

Điểm câu chuyện

  • Giúp thúc đẩy hành vi đa chức năng, tức là các nhóm ước tính mức độ phức tạp khi thực hiện toàn bộ từ UI đến DB và ngược lại.
  • Ước tính SP không bị phân rã, tức là vài tháng nữa, câu chuyện 5 điểm vẫn có thể là 5 điểm, nhưng ước tính ngày lý tưởng có thể thay đổi tùy thuộc vào kỹ năng / tốc độ phát triển có được của lập trình viên cụ thể đó
  • SP là một thước đo thuần túy của kích thước tức là chúng chỉ và chỉ phản ánh độ phức tạp của kích thước. Giai đoạn = Stage. Không có thời gian, vv, ném nó. Đó là công việc của vận tốc. Nhưng không phải vậy với những ngày lý tưởng. Trong thực tế với những ngày lý tưởng có xu hướng trộn lẫn nó với ngày dương lịch. Giữ cho nó trừu tượng khi SP chiến đấu với sự cám dỗ để so sánh với thực tế. Chỉ là thước đo kích thước. Không vô nghĩa.
  • Thường nhanh hơn ngày lý tưởng. Nó có thể là khó khăn cho một vài câu chuyện đầu tiên, nhưng một khi bạn hiểu rõ về nó, nó sẽ nhanh hơn.
  • Các nhà phát triển khác nhau có thể có một ước tính khác nhau trong ước tính ngày lý tưởng của họ để hoàn thành một câu chuyện. Tôi có thể làm tương tự trong 3 và bạn có thể làm trong 5. SP ít nhiều đồng đều trên bảng. Họ san bằng sân chơi để nói chuyện.

Ngày lý tưởng

  • Dễ dàng hơn để giải thích bên ngoài nhóm; vì lý do rõ ràng :)
  • Dễ dàng hơn để ước tính lúc đầu như đã đề cập ở trên. Nhưng một khi bạn nhận được SP, nó sẽ tự nhiên xuất hiện

Bây giờ, cái nào để chọn là tùy thuộc vào đội. Tuy nhiên, như hầu hết các câu trả lời ở đây và kinh nghiệm cá nhân của tôi, tôi thích điểm câu chuyện hơn. Những ngày lý tưởng không thực sự mang lại nhiều lợi ích cho SP (và Mike Cohn cũng ủng hộ SP cùng với nhiều nhà truyền giáo nhanh nhẹn khác).


Số Fibonacci tiếp theo là 21, không phải 20.
Joe Z.

4
21 hoặc 20 không quan trọng khi ước tính. SP làm tròn số lượt tiếp theo để loại bỏ cảm giác sai chính xác. Số tiếp theo trong chuỗi không phải là 34 mà là 40 (gấp đôi 20) và sau đó là 100. Các số đại diện cho 'sự không chắc chắn' về độ phức tạp và không chính xác. Nó chỉ là một xấp xỉ.
Tiến sĩ

1
Đó là sự thật, tôi chỉ chọn nits (và đùa).
Joe Z.

1
@PhD: "Ước tính SP không phân rã, tức là vài tháng nữa, câu chuyện 5 điểm vẫn có thể là 5 điểm, nhưng ước tính ngày lý tưởng có thể thay đổi tùy thuộc vào kỹ năng / tốc độ phát triển có được của lập trình viên cụ thể đó": Điều này ngầm giả định rằng nhóm sẽ cải thiện kỹ năng của mình một cách thống nhất trong tất cả các lĩnh vực của dự án. Tôi không hiểu tại sao điều này luôn luôn như vậy: một số phần của dự án (và các công nghệ cần thiết cho chúng) có thể khó hơn các phần khác, làm cho ước tính ban đầu về độ phức tạp tương đối trong các điểm câu chuyện không hợp lệ.
Giorgio

3

Điểm câu chuyện cũng giúp bạn đo lường sự cải thiện hiệu suất của nhóm theo thời gian. Ngoài ra, bạn không cần phải ước tính lại mọi thứ khi hiệu suất được cải thiện.

Lấy ví dụ này sử dụng ngày con người:

Nhóm ước tính các nhiệm vụ khác nhau với số ngày. Nó hoạt động được một lúc, nhưng sau một thời gian bạn thấy rằng nhóm được thực hiện nhanh hơn với nhiều nhiệm vụ hơn so với suy nghĩ ban đầu. Vì vậy, nhóm ước tính lại các nhiệm vụ. Nó hoạt động được một lúc và sau một thời gian bạn lại thấy điều tương tự: Nhóm được hoàn thành nhanh hơn với nhiều nhiệm vụ một lần nữa. Vì vậy, bạn ước tính lại một lần nữa, và câu chuyện này lặp đi lặp lại, và một lần nữa ...

Tại sao? Bởi vì hiệu suất của nhóm của bạn tăng lên. Nhưng bạn không biết về nó.

Ví dụ tương tự với các điểm câu chuyện:

Nhóm ước tính kích thước của câu chuyện người dùng. Sau một số lần chạy nước rút, bạn thấy rằng nhóm có thể thực hiện khoảng 60 điểm câu chuyện trên mỗi lần chạy nước rút. Sau đó, bạn thấy rằng nhóm đã đạt được hơn 60 điểm câu chuyện, có thể là 70. Và nhóm tiếp tục như vậy và kéo thêm câu chuyện của người dùng cho lần chạy nước rút tiếp theo và cung cấp chúng.

Tại sao? Bởi vì hiệu suất đã tăng lên. Và bạn có thể đo nó. Và bạn không cần phải ước tính lại mọi thứ sau khi hiệu suất của nhóm của bạn tăng lên.


3
"Tại sao? Bởi vì hiệu suất của nhóm của bạn tăng lên.": Một cách giải thích khác là sau một thời gian, nhóm bắt đầu đưa ra ước tính thời gian chính xác / thực tế hơn (vì họ đã trễ với một số nhiệm vụ trong lần chạy nước rút trước đó, họ bắt đầu giao thêm thời gian khi ước tính câu chuyện cho lần chạy nước rút sau này).
Giorgio

2

Đầu tiên, mọi người tốt hơn ở ước tính tương đối hơn so với ước tính tuyệt đối. Bản đồ babylonian và đánh giá độ sáng tương đối của các ngôi sao là một ví dụ tuyệt vời. Họ đã không có được số liệu tuyệt đối đúng, nhưng thứ tự chủ yếu được phát hiện ngay cả đối với cường độ rất giống nhau.

Ưu điểm thứ hai là một lý do chính để thực hiện bài tập này là để thúc đẩy cuộc trò chuyện .. Nếu bạn bắt đầu thảo luận trong những ngày chính xác, cuộc trò chuyện có thể nhanh chóng bị trật bánh.

Như Napoleon đã nói: kế hoạch là vô giá trị, kế hoạch là vô giá.

Thứ ba, người quản lý dự án không phải chỉnh sửa tất cả các ước tính, chỉ vì hóa ra các ước tính bị tắt bởi một yếu tố, ví dụ: 130%.


0

Điểm câu chuyện phản ánh sự phức tạp của vấn đề, và do đó, phản ánh sự tự tin (hoặc rủi ro) về mức độ chính xác của ước tính.

Câu chuyện có điểm câu chuyện cao cho tôi biết rằng có rất nhiều điều xảy ra với câu chuyện người dùng không cụ thể.

Ý tưởng là để xem những gì một sự cân bằng tốt của các điểm câu chuyện khác nhau. Nếu tôi đang được hiển thị một kế hoạch lặp với các câu chuyện với tất cả các điểm câu chuyện cao, điều này cho tôi ít tin tưởng rằng việc lặp lại sẽ được thực hiện như mong đợi và chúng ta cần xem xét các câu chuyện khác để lặp lại hoặc bắt đầu phá vỡ các câu chuyện.

Khi liên lạc với người quản lý hoặc Chủ sở hữu sản phẩm, điểm câu chuyện cao có nghĩa là sẽ cực kỳ mơ hồ khi họ sẽ nhận được một tính năng cụ thể. Một trong những giải pháp cho vấn đề này là chia nhỏ câu chuyện và hy vọng bạn sẽ có sự kết hợp giữa các điểm câu chuyện thấp và cao để bạn có thể lặp lại trình bày tiến trình cho Chủ sở hữu sản phẩm.


0

Ngày người đàn ông ước tính thời gian cần thiết để làm một cái gì đó. Chúng được sử dụng tốt nhất khi các mục bạn đang ước tính rất chính xác và có thể đo lường được. Các nhiệm vụ cụ thể, nổi tiếng, có thể lặp lại được ước tính trong ngày của con người.

Ví dụ: trung bình nếu một nhân viên bán hàng có thể thực hiện 20 cuộc gọi của khách hàng mỗi ngày, chúng tôi có thể tính toán mỗi cuộc gọi mất bao nhiêu thời gian và từ đó chúng tôi có thể ước tính sẽ mất bao nhiêu ngày để thực hiện 1000 cuộc gọi.

Trong ví dụ này, người ta có thể suy nghĩ cụ thể về các thuật ngữ thống kê về độ dài trung bình của một cuộc gọi bởi vì tất cả các cuộc gọi có thể được coi là có hiệu quả giống nhau.

Điểm câu chuyện xác định sự kết hợp của câu chuyện có thể được thực hiện trong một lần lặp. Chúng được sử dụng để kết hợp các mục tiêu không đồng nhất với các ranh giới mờ và để đo xem có thể thực hiện bao nhiêu mục tiêu trong một khung thời gian cố định. Họ ước tính độ phức tạp của khối công việc so với nhau để có thể thêm chúng lại với nhau.

Ví dụ: nhóm của bạn đã phát triển 5 câu chuyện với tổng số 23 điểm trong lần lặp 1 và 8 câu chuyện cho 20 điểm trong lần lặp 2. Từ đó, bạn có thể ước tính rằng trong lần lặp lại, hai nhóm của bạn sẽ thực hiện một vài câu chuyện với tổng số điểm là khoảng 20 điểm trong lần lặp 3.

Lưu ý rằng chúng ta không cần xác định kích thước của một điểm và đặc biệt không có giả định rằng mỗi câu chuyện có cùng kích thước sẽ mất cùng thời gian để được phát triển! Chúng tôi chỉ làm việc trên tổng và điểm trên mỗi lần lặp. Tôi thậm chí không đề cập đến việc lặp đi lặp lại là bao lâu.


0

Nếu bạn đi bộ đến một người trên đường phố và hỏi "T-rex lớn cỡ nào?" các câu trả lời sẽ dao động ngay cả khi phần lớn con người biết T-rex là gì, nó lớn đến mức nào, nhưng không ai thực sự biết chắc chắn - bởi vì chúng ta KHÔNG có quy mô tương đối so với đường cơ sở.

Đó là hành vi nhận thức mà bạn đang cố gắng tìm ra với dự báo và nhiều phương pháp xoay vòng với " Tôi đã hiểu rồi! Tôi có bí mật để dự báo chính xác! " Khi bạn thực sự dự báo bạn thực sự đang nói to " Tôi sẽ cho phép x ngày / giờ / điểm để hoàn thành " - theo nghĩa là tạo ra một "thời gian" cho sự kiện đó được thực hiện trong đó.

Đối với tôi, Points chỉ thay đổi ranh giới, vào cuối ngày trừ khi bạn ở trong một đội rất vui khi nói " * Chà, chúng tôi có 3 tuần cho mỗi lần chạy nước rút, và mút ngón tay cái ... tôi nghĩ chúng ta nên bắn 30 điểm để hoàn thành trong chu trình đó! Ai ở bên tôi! * "Và đó là điều sâu sắc như bạn đi trong mô hình dự báo - tốt thôi! .. thực tế là bạn chỉ cần thiết lập một ngân sách độc lập và đó là nó. Sau đó, bạn cũng đang nhìn lại công việc đã hoàn thành với ý nghĩa "tào lao thần thánh, chúng tôi đã thực hiện 33p nước rút, điều đó khá tuyệt" và không thể làm được gì nhiều về điều đó. Bạn có thể sử dụng vận tốc để xác định giữa giai đoạn nước rút mà bạn đang kiếm được cho ngân sách của mình bằng cách hỏi to " Chúng ta đã đạt 15 điểm chưa? Chúng ta sẽ""Nhưng điều nguy hiểm ở đây là bây giờ bạn đang sử dụng Vận tốc để đo năng suất chứ không phải năng lực mà từ những gì tôi hiểu là sẽ quản lý Phát hành Phản ứng (điểm câu chuyện) trong đầu ..

Hệ thống điểm gần như quá thông minh để không nhận thấy rằng bạn vẫn gắn thời gian tương đối vào phương trình, mọi thứ từ "chu kỳ chạy nước rút" đã thỏa thuận của bạn với các tiêu chuẩn hàng ngày mà bạn ban hành một số quy tắc ẩn xung quanh thời lượng + độ phức tạp = " Max sẽ mất nhiều thời gian Với nhiệm vụ đó "ruột bẩm sinh cảm giác mã thời điểm đỏ?

Bộ não con người không thể dự báo được vì nó liên quan đến rất nhiều bộ nhớ làm việc xen lẫn với việc nhớ lại dài hạn / ngắn hạn, vì vậy nó giống như yêu cầu một sinh viên toán mới làm quen với phân số không phải trên giấy .. Đó là lý do tại sao các ngành khác không bao giờ đồng ý về dự báo và liên tục xác nhận dự báo trong thời gian tương đối (ví dụ nhà địa chất không bao giờ ngừng mô hình dự báo cho đến khi mét khối đó được đào lên khỏi mặt đất và sau đó "thực hiện").

Tôi muốn nói hệ thống Point hoạt động nếu bạn không dự báo . Bạn đồng ý với một khối công việc dựa trên thuật toán phân đoạn phụ nhưng đó thực sự là cách tiếp cận gần nhất để dự báo của bạn. Trên thực tế, quản lý phát hành của bạn sẽ tìm kiếm các ngắt tự nhiên trong hàng đợi "tồn đọng" phù hợp với (các) chủ đề (ví dụ như trong Silverlight, các nhà quản lý sản phẩm sẽ đợi cho đến khi họ hoàn thành hồ sơ tồn đọng và ghép các chủ đề chúng tôi đặt ra ban đầu. không bao giờ biết nhóm kỹ sư đang làm gì cụ thể, chúng tôi chỉ có một phác thảo cơ bản. Sau đó, chúng tôi sẽ thực hiện công việc đó và xây dựng sự kiện tiếp thị của chúng tôi xung quanh nó (Microsoft Mix))

Khi bạn bắt đầu khóa kỳ vọng vận tốc trong các chu kỳ nước rút dựa vào vận tốc + thời gian, bạn sẽ quay lại dự đoán một lần nữa, lần này bạn sẽ tệ hơn vì bạn đang chơi "trò chơi phụ thuộc" ... Quan trọng hơn là bạn Cũng đang giết chết tiềm năng phát triển đội ngũ / ​​sự nghiệp.

Thuế bạn phải trả cho Điểm so với Thời gian là với các điểm bạn cần tìm kiếm các công thức đo lường thay thế để theo dõi hành vi phát triển / cố vấn hoặc phát triển kỹ năng onjob.

Vì bạn vẫn sẽ cần xem "nhà phát triển trung bình" là người lý tưởng để gắn kết kỹ năng / nỗ lực của mình, sau đó bạn có thể căn cứ vào các nhà phát triển khác với người đó để xác định cách họ công bằng trong sự phát triển liên tục của họ trong nhóm của bạn. Nó cũng nhấn mạnh các tình huống mà các nhà phát triển "nhanh" đang mang hầu hết nước nhưng đang chán hoặc tệ hơn là họ làm việc nhiều giờ hơn và không được công nhận / khen thưởng vì thời hạn cạnh tranh, v.v. ở đó để phát hiện mùi hôi trong đội mỗi lần nói, như trong "người đó đang vật lộn, hãy giúp đỡ"

Tiếp theo cũng là những câu chuyện "tiếp tục", những câu chuyện không bị cuốn vào chu kỳ nước rút đó nhưng sau đó lại tràn sang chu kỳ nước rút tiếp theo. Điều đó sau đó có thể dễ dàng tạo ra hiệu ứng kích thích nếu bạn bao thanh toán kịp thời, nhưng thời điểm bạn làm yếu tố thời gian tương đối..chỉ, bạn chỉ cần quay lại "dự báo / dự báo dựa trên thời gian" và một lần nữa hệ thống điểm chỉ là làm vẩn đục nước.

Nếu bạn đi điểm bạn hoàn toàn bỏ qua thời gian và ý tôi là hoàn toàn như thời điểm bạn để thời gian trôi qua trong khi bạn chơi game ý tưởng / phương pháp.

Đã đi khắp thế giới với tư cách là một nhà truyền giáo, tôi thấy rất nhiều đội chửi thề bất cứ điều gì họ yêu quý rằng họ đã bẻ khóa mã Dự báo Agile ... nhưng tôi luôn tặc lưỡi, mỉm cười và bỏ đi với ý nghĩ " ừ ... bạn gần như đã làm, nhưng người tình mà chúng ta gọi là 'thời gian' ... cô ấy thật tàn nhẫn ... "


-1

Cuốn sách "Lập kế hoạch và lập kế hoạch nhanh" của Mike Cohn mô tả những lợi thế và bất lợi của việc ước tính với "ngày lý tưởng" hoặc điểm câu chuyện, vì vậy câu trả lời nhanh cho câu hỏi của bạn là bạn không phải ước tính bằng điểm câu chuyện. Nếu ước tính tự nhiên hơn trong những ngày lý tưởng, hãy tiếp tục.


1
Điều này không nhất thiết phải trả lời câu hỏi; nó chỉ cung cấp một tài liệu tham khảo thay thế. Bạn có thể củng cố câu trả lời của mình bằng cách cung cấp một bản tóm tắt về những lợi thế và bất lợi.

-1

Tôi nghĩ rằng phương pháp Story Point có ít nhất hai lợi thế quan trọng so với phương pháp Man-day: Thứ nhất, việc ước tính trong SP dễ dàng hơn. SP là tương đối và con người như chúng ta tốt hơn so với ước tính tuyệt đối như phương pháp ngày con người.

Thứ hai, khi bạn ước tính trong SP, bạn sẽ nhận được "Nhóm SP" chứ không phải "Manday cá nhân". Khi bạn hỏi "Nhiệm vụ này sẽ kéo dài bao lâu?", Nhà phát triển cấp cao có thể cung cấp cho bạn 1 ngày nhưng 5 ngày cho một Junior. Đó là Man-day tùy thuộc vào người sẽ thực hiện nhiệm vụ đó. Nếu chủ sở hữu buộc phải thay đổi (và nó sẽ!), Bạn phải lên lịch lại mọi thứ. Với SP, nó vẫn giống như bất cứ ai nhận nhiệm vụ.


-1

Tôi ngạc nhiên không ai nhắc đến Luật Parkinson .

Công việc mở rộng để lấp đầy thời gian có sẵn để hoàn thành.

Về cơ bản nếu bạn đang ước tính trong bất kỳ loại đơn vị thời gian nào cho các nhiệm vụ lớn, nhà phát triển sẽ có xu hướng dành thời gian họ ước tính để hoàn thành nó hoặc đi qua. Khi bạn ước tính trong một thời gian mơ hồ như Story Points hoặc Kích cỡ áo, bạn sẽ tránh được cạm bẫy này.


1
"Khi bạn ước tính trong một thời gian mơ hồ như Điểm câu chuyện hoặc Kích cỡ áo, bạn sẽ tránh được cạm bẫy này.": Không thực sự: nếu trong một lần chạy nước rút 2 tuần, tôi đã được chỉ định hai câu chuyện của người dùng cho tổng số 10 điểm câu chuyện, tôi có thể lấy toàn bộ hai tuần và thiết lập vận tốc đến 5 điểm câu chuyện mỗi tuần. Tôi nghĩ rằng tăng năng suất có liên quan nhiều đến động lực của nhóm và điều kiện làm việc hơn là với đơn vị được sử dụng để đo lường sự phức tạp của các nhiệm vụ.
Giorgio

Tôi đã không đề cập đến việc tăng năng suất, hơn nữa thực tế là nếu ước tính cho một câu chuyện được đưa ra đến 3 ngày. Một nhà phát triển có nhiều khả năng mất 3 ngày hoặc nhiều hơn để hoàn thành nó, hơn là đi vào theo ước tính.
Vadim

Có bằng chứng tốt cho luật Parkinson? Trang Wikipedia dường như không đề cập đến bất kỳ.
bdsl

-2

Ước tính điểm câu chuyện sau loạt sê-ri 1,2,3,5,8,13,21 ...

Một bộ não con người có thể dễ dàng lập bản đồ mọi thứ dựa trên kích thước. Ví dụ: Chúng tôi có một bài đăng thẻ và gán cho nó một điểm câu chuyện 2 và ba bài đăng kích thước của thẻ đó có nghĩa là 2 * 3 = 6 điểm câu chuyện.

Story Point 6 rơi vào giữa sê-ri số 5 và 8 với 5 là số gần hơn và do đó, cốt truyện sẽ là 5.


1
Chúng tôi không ánh xạ mọi thứ dựa trên kích thước, chúng tôi thực sự sử dụng bộ nhớ làm việc để coi chúng là "lược đồ" để làm việc. Giống như bộ não của chúng ta có một lượng RAM ngắn mà khi chúng ta cung cấp các mẫu nhỏ có thể nhận thấy thành (cỡ Fibre, A000079, áo phông, v.v.), chúng có thể thu hút các năng lực nhận thức nội tại của chúng ta để giúp dự án trong trường hợp này - một câu trả lời. mà thực sự là một mô hình "dự báo tương đối".
Scott Barnes
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.