Giải thích tốt nhất về Story Points là gì?

Chúng tôi đang bắt đầu sử dụng Story Points ở đây để phát triển Agile nhưng tôi thấy khó giải thích và cũng không thể tìm thấy bất kỳ câu trả lời dứt khoát nào cho những gì họ đang có. Điều tốt nhất tôi có thể làm là chỉ đến các trang web khác (như http://blog.mountaingoatsoftware.com/tag/story-point ) và đưa ra một số khái quát mơ hồ về những gì chúng là. Tôi đang tìm kiếm một lời giải thích tốt với một số ví dụ về việc sử dụng sẽ hữu ích cho những người khác sử dụng. Có bất kỳ nguồn lực tốt để giải thích điểm câu chuyện?

Điều này có thể giúp như một người bắt đầu: Mike Cohn về điểm câu chuyện . Nhưng điều này tốt hơn nhiều: Các nhóm phát triển Agile: Phạm vi và quy mô với Mike Cohn

Giải pháp của Mike cho các số liệu ước tính phần mềm rất đơn giản và hiệu quả. Sự thật sinh học:

• Bộ não con người chỉ không thể ước tính chính xác thời gian. Đặc biệt là nếu hơn vài giờ.
• Điều này được khuếch đại rất nhiều bởi số lượng không chắc chắn trong nhà phát triển phần mềm, áp lực tâm lý từ quản lý (khi bạn ước tính, bạn cam kết ...) và sự khác biệt về kỹ năng trong nhóm.
• Tuy nhiên, chúng tôi khá giỏi trong việc so sánh các công cụ. Chúng tôi khá chính xác ở đó.

Ý tưởng là lấy một câu chuyện người dùng tham khảo , sau đó cung cấp cho nó một số điểm (câu chuyện) tùy ý , sau đó các câu chuyện khác sẽ nhận được điểm liên quan đến tham chiếu đó.

Nếu câu chuyện tham khảo của bạn là 100 điểm, và một câu chuyện khác lớn hơn ba lần, thì nó sẽ là 300 điểm.

Để chuyển đổi điểm câu chuyện thành thời gian cho kế hoạch của bạn, bạn phải biết vận tốc của mình .

Để có được vận tốc chính xác, bạn phải thực hiện vài lần lặp và tính toán số điểm mà nhóm của bạn đã hoàn thành trong một khoảng thời gian nhất định.

Nó hoạt động .

Tôi đồng ý với mọi thứ @Pierre 303: đã nói ở trên: (ngoài 100 điểm tham chiếu).

Điều duy nhất tôi muốn thêm (nhấn mạnh) là chúng tôi không giỏi trong việc ước tính các nhiệm vụ. Chúng ta có thể ước tính các nhiệm vụ liên quan đến các nhiệm vụ khác miễn là chúng có cùng kích thước. Sự khác biệt giữa các nhiệm vụ càng lớn chúng ta càng nhận được.

Vì vậy, tôi không đồng ý với việc sử dụng điểm bắt đầu là 100.

Nó không phải như thể bạn sẽ ước tính nhiệm vụ tiếp theo là 42% của nhiệm vụ tham chiếu. Đó là một nửa công việc gấp đôi công việc gấp ba lần công việc, v.v.

Nhóm của chúng tôi sử dụng Planing Poker : Trong phần này, chúng tôi có nhiệm vụ tham khảo gồm 2 điểm câu chuyện. Sau đó, chúng tôi sử dụng chuỗi Fibonacci để ước tính các nhiệm vụ: 1,2,3,5,8,13,21, Lớn ,? Liên quan đến nhiệm vụ tham chiếu (Thay vì Fibonacci tôi đã thấy các nhóm khác sử dụng quyền hạn là 2. 1,2,4,8,16,32, Huge ,?) Tôi đã thấy các nhóm khác sử dụng (nhỏ (1), trung bình ( 2), lớn (3), XLUND (4) khi họ tính toán vận tốc nó vẫn hoạt động.).

Vấn đề là khi kích thước của nhiệm vụ tăng lên so với nhiệm vụ tham chiếu, chúng ta trở nên ít có khả năng ước tính chính xác chi phí của nó. Vì vậy, không có điểm trong cố gắng. Điều này được phản ánh bởi độ dốc lớn hơn ở cuối đường ước tính.

Vì vậy, nếu nhiệm vụ tham khảo của bạn là 2SP. Sau đó, ước tính 1/2/3/5 là tương đối dễ dàng vì nhiệm vụ có kích thước tương tự. Khi bạn vượt quá 3 lần so với nhiệm vụ tham chiếu (5SP), việc ước tính sẽ trở nên khó khăn hơn (Có phải là 9 tháng 9 / 10SP không) Tất cả những gì bạn có thể nói là lớn hơn 5SP và nhỏ hơn 13SP thì 8SP phù hợp với hóa đơn.

Bất cứ điều gì có giá trị SP là 13/21 / Huge là quá lớn cho việc tồn đọng nước rút. Đây là những ước tính cho những thứ bạn chưa sẵn sàng để thực sự làm việc (và do đó chưa được chia thành các nhiệm vụ nhỏ hơn (đừng chia nhỏ chúng cho đến khi bạn cũng cần)). Nhưng họ cung cấp cho bạn một ước tính cho kích thước của một nhiệm vụ trong sản phẩm tồn đọng (cho phép một số kế hoạch trong tương lai). Vào thời điểm bạn sẽ làm việc với chúng, bạn nên có đủ kiến ​​thức để chia chúng - thành các nhiệm vụ nhỏ hơn cho việc tồn đọng nước rút và ước tính lại chúng một cách riêng lẻ (Lưu ý: Đó là một quan niệm sai lầm phổ biến rằng tổng của các phần bằng bản gốc).

• Bất cứ điều gì bạn ước tính là rất lớn cần được chia thành các nhiệm vụ nhỏ hơn.
• Bất cứ điều gì được ước tính là? có nghĩa là nó không đủ xác định để ước tính
  Bạn cần thêm một nhiệm vụ cụ thể để đi và xác định nhiệm vụ
  (nghĩa là viết một số tài liệu hoặc bản trình bày).

Điểm câu chuyện là một phép đo tương đối về mức độ khó của một nhiệm vụ. Điều này là do con người thực sự tốt hơn ở các ước tính tương đối so với các phép đo chính xác.

Cách bạn sử dụng điểm câu chuyện là bạn thực hiện khoảng hai nhiệm vụ trong dự án và gán cho chúng hai giá trị điểm câu chuyện khác nhau. Sau đó, bạn ước tính các nhiệm vụ khác bằng cách sử dụng hai xấp xỉ điểm câu chuyện đó làm cơ sở cho ước tính của mình. Nhiệm vụ C không khó hơn nhiệm vụ A nhưng dễ dàng hơn nhiệm vụ B rất nhiều, vì vậy chỉ có khoảng 2 điểm công việc nhiều hơn nhiệm vụ A.

Khi bạn hoàn thành ước tính tất cả các yêu cầu bạn có cho đến nay, sau đó bạn ước tính số lượng bạn có thể thực hiện trong một lần chạy nước rút. Trong vài lần chạy nước rút tiếp theo, bạn ước tính số lượng bạn đã hoàn thành. Điểm câu chuyện của một yêu cầu chỉ được tính là hoàn thành nếu yêu cầu được đáp ứng. Không có "80% hoàn thành" trong Scrum. Điều này là do con người thực sự xấu trong việc ước tính tính đầy đủ. Sau một vài lần chạy nước rút, bạn sẽ có một ý tưởng về số điểm câu chuyện bạn có thể làm cho mỗi lần chạy nước rút.

Bạn ước tính như thế nào? Bạn có thể sử dụng lập kế hoạch poker để xác định bao nhiêu công việc mà các nhà phát triển của bạn cảm thấy một yêu cầu sẽ liên quan đến các yêu cầu cơ bản của bạn.

Tôi cũng khuyên bạn nên đọc The Agile Samurai . Theo tôi, đây là một công việc tốt để giải thích những điều này và các khái niệm Agile khác.

Đây là một liên kết với nhiều hơn về các điểm câu chuyện.

Đây là một liên kết khác.

Họ là một sự lãng phí thời gian.

http://www.amazon.com/Lean-Trenches-Managing-Large-Scale-Projects/dp/1934356859/

Điều thú vị là ý kiến ​​này bây giờ đến từ anh chàng đã viết Scrum và XP từ Trenches và có tên công ty ( Crisp ) có thể được tìm thấy trên rất nhiều bộ bài lập kế hoạch chơi bài được sử dụng bởi rất nhiều đội trên thế giới.

Câu cuối cùng của OP: "Có tài nguyên tốt nào để giải thích điểm câu chuyện không?" Vâng, cuốn sách này là một tài nguyên tốt. Thức ăn cho ý nghĩ.

Giải thích đơn giản nhất tôi có thể đưa ra là sử dụng một đối tượng hữu hình và có thể cung cấp một ví dụ cụ thể.

Mang một ngôi nhà di động. Nếu tôi kinh doanh nhà di động, tôi sẽ biết rằng việc xây dựng một chiều rộng thông thường chỉ mất 5 (điểm, ếch, vật dụng ... hình thức đo lường là tùy ý) và do đó, việc xây dựng một chiều rộng gấp đôi sẽ tốn gấp đôi hoặc 10 (điểm , ếch, vật dụng).

Vào thời điểm này, các nhà lập trình sẽ suy nghĩ và nói về một cách tiếp cận hợp lý; nó không mất gấp đôi thời gian do cơ sở hạ tầng tiêu tốn phần lớn thời gian và các ví dụ tương tự khác. Điều này là không thể tránh khỏi. Harp về thực tế rằng đây là một ước tính trong (điểm, ếch, vật dụng) vì chúng ta KHÔNG BAO GIỜ có thể ước tính chính xác về thời gian và do đó ước tính trong (điểm, ếch, vật dụng) loại bỏ niềm tin mà chúng ta có thể.

Để biết một cái gì đó sẽ mất bao lâu để xây dựng, chúng tôi sẽ sử dụng các xu hướng của chúng tôi theo thời gian; do đó theo thời gian ngày càng chính xác hơn trong ước tính của chúng tôi.

Đừng quên lập kế hoạch chơi bài khi đội đã sẵn sàng.

Như những người khác đã đề cập các điểm câu chuyện là một phép đo tương đối về độ phức tạp cho một câu chuyện của người dùng. Lợi ích thực sự của điểm câu chuyện được nhận ra khi

1. Các điểm được đo bởi đơn vị chịu trách nhiệm thực hiện (một cá nhân hoặc nhóm).
2. Các số liệu được giữ cho bao nhiêu điểm tổng hợp được hoàn thành bởi cùng một đơn vị trong một khoảng thời gian không đổi (vận tốc).

Sau một vài lần đo lường trong các điểm câu chuyện và vận tốc theo dõi, bạn sẽ có thể ước tính chính xác có bao nhiêu điểm câu chuyện có thể phù hợp trong một khung thời gian nhất định (lặp lại hoặc chạy nước rút nếu sử dụng scrum). Lưu ý rằng áp dụng kỹ thuật này cho một nhóm và cố gắng sử dụng các số liệu đó cho một nhóm khác sẽ không hoạt động tốt. Đó là nếu đội a có thể hoàn thành 120 điểm câu chuyện trong một lần chạy nước rút hai tuần, hy vọng đội b có kết quả tương tự là không thực tế.

Như một người khác đã đề cập, lập kế hoạch chơi bài xì phé là một trợ giúp tuyệt vời khi sử dụng phương pháp này bởi vì nó sẽ giúp xác định những câu chuyện cần sàng lọc thêm (nếu có sự khác biệt giữa các phiếu, điều đó có nghĩa là không chắc chắn trong các yêu cầu).