Làm gì với ước tính của câu chuyện không đầy đủ?

Tôi là thành viên của một nhóm phát triển còn khá mới Scrum, giả sử rằng vào cuối cuộc đua nước rút, một vài câu chuyện lớn là in progresshoặc không phải acceptedbởi PO.

Thứ nhất, những gì xảy ra với những câu chuyện người dùng? Bạn chỉ cần mang chúng vào nước rút tiếp theo?

Nếu vậy, họ có nên được ước tính lại? Theo quan điểm của tôi, công việc còn lại trên những câu chuyện người dùng này có thể là tối thiểu hay nhiều? Nếu không, tai sao không?

EDIT: Trong trường hợp cụ thể của tôi, các câu chuyện đã không được hoàn thành vì một trở ngại kéo dài vài ngày, không phải vì đánh giá thấp câu chuyện của người dùng. Đối với những người mà bạn có thể giúp đỡ, chúng tôi đang sử dụngVersionOne

agile scrum

— ediblecode
nguồn

Tôi làm việc với một quy trình XP và đã tự hỏi đâu là cách tốt nhất để giải quyết tình huống này

— chrisbunney

Việc không xác định trở ngại là rủi ro có thể xảy ra và xác định mức rủi ro RE (tác động * xác suất) cho thấy có vấn đề với ước tính. Một câu chuyện người dùng có RE cao cần phải có một bộ đệm lớn hơn về chi phí và thời gian liên quan đến nó để giải quyết những rủi ro đó, nếu chúng phát triển thành vấn đề.

— Thomas Owens

nhân đôi nó và thêm 32, giống như C => F

— Paul

Câu trả lời:

Thứ nhất, những gì xảy ra với những câu chuyện người dùng? Bạn chỉ cần mang chúng vào nước rút tiếp theo?

Nó phụ thuộc. Nếu không có câu chuyện nào khác có mức độ ưu tiên cao hơn, thì, vâng, chúng được chuyển sang giai đoạn nước rút tiếp theo. Nếu các câu chuyện khác có mức độ ưu tiên cao hơn, thì chúng có thể được chuyển trở lại vào hồ sơ tồn đọng của sản phẩm nếu không có đủ chỗ trong giai đoạn nước rút để chứa chúng. Tất cả điều này xảy ra trong kế hoạch chạy nước rút, dựa trên các ưu tiên được chỉ định cho mỗi câu chuyện của Chủ sở hữu sản phẩm của bạn. Vì một trong những mục đích của các phương thức nhanh như Scrum là tối đa hóa giá trị được phân phối trong khi giảm thời gian, tất cả đều phụ thuộc vào giá trị được thêm vào bằng cách hoàn thành những câu chuyện đó.

Bất kể điều gì xảy ra, bạn vẫn cần phấn đấu cho một sản phẩm có khả năng chuyển đổi vào cuối giai đoạn nước rút. Điều này có thể có nghĩa là quay trở lại để đảm bảo rằng sản phẩm cuối nước rút vượt qua tất cả các thử nghiệm và các tính năng đã hoàn thành hoàn toàn có thể sử dụng được bởi người dùng mà không có bất kỳ vấn đề đáng kể nào.

Nếu vậy, họ có nên được ước tính lại? Theo quan điểm của tôi, công việc còn lại trên những câu chuyện người dùng này có thể là tối thiểu hay nhiều? Nếu không, tai sao không?

Tôi sẽ không đánh giá lại bởi vì, trong Scrum, bạn ước tính một câu chuyện khi bạn chấp nhận nó, bắt đầu công việc và không có khái niệm hoàn thành một phần . Một câu chuyện hoàn thành 100%, đã được thử nghiệm và được chấp nhận (hoàn thành) hoặc nó chưa được thực hiện. Nếu không có khái niệm hoàn thành một phần, bạn sẽ không có cách nào để xác định bao nhiêu công việc còn lại trên câu chuyện. Dường như tôi cũng không đơn độc trong suy nghĩ này . Bạn đã ước tính công việc mà bạn nghĩ bạn có thể làm, vì vậy hãy để điểm dữ liệu này vào và biến nó thành một điểm để thảo luận về lý do tại sao ước tính bị tắt trong hậu họa nước rút của bạn và cố gắng tránh mắc lỗi cho lần chạy nước rút trong tương lai.

— Thomas Owens
nguồn

Chúng tôi chỉ mới trải nghiệm điều này một lần và điều đó không xảy ra với ước tính là sai, chúng tôi đã gặp trở ngại về các loại dẫn đến công việc được thực hiện, nhưng không được kiểm tra.

— ediblecode

@ user1016253 Điều đó có nghĩa là ước tính của bạn có vấn đề. Các ước tính nên bao gồm phơi nhiễm rủi ro (tác động * xác suất = phơi nhiễm, trong đó phơi nhiễm có tác động đến chi phí, thời gian và chất lượng). Bởi vì có một trở ngại đã xảy ra, nhưng ước tính không tính đến nó (hoặc không đủ cho nó), một cái gì đó đã bị bỏ qua hoặc đánh giá sai (tác động hoặc xác suất quá thấp, có nghĩa là mức độ phơi nhiễm là quá thấp, có nghĩa là không có đủ tài nguyên được phân bổ để xác định và khắc phục sự cố khi nó xảy ra).

— Thomas Owens

@ user1016253 Và nếu bạn gặp khó khăn trong việc ước tính và nhìn thấy rủi ro và các rào cản tiềm ẩn, có lẽ một ý tưởng hay là phân tách câu chuyện, thành nhiều câu chuyện mà mỗi câu chuyện đi vào tồn đọng hoặc câu chuyện phụ chỉ được nhóm phát triển sử dụng để hiểu công việc cần phải làm Việc ước tính và thực hiện phân tích rủi ro trên một đơn vị công việc nhỏ hơn thường dễ dàng hơn.

— Thomas Owens

@Thomas Owens: Đó dường như không phải là một cách hữu ích để quản lý rủi ro đối với tôi. Cụ thể, một sự kiện có xác suất thấp không phải là thảm họa là mức độ phơi nhiễm thấp, và do đó, ngay cả một dự án được quản lý tốt cũng có thể bị vứt bỏ theo lịch trình. Nếu bạn không bao giờ chấp nhận rủi ro, bạn sẽ hoàn thành rất ít. Tất nhiên, việc theo dõi ước tính không cần phải chấp nhận những lời bào chữa đó, hoặc bạn tiếp tục đưa ra những ước tính chỉ có giá trị như các khoản đầu tư dẫn đến vụ sụp đổ thế chấp gần đây và vì những lý do tương tự

— David Thornley

@DavidThornley Đây không phải là một cách để quản lý rủi ro, mà là điểm khởi đầu cho một kế hoạch quản lý rủi ro cũng bao gồm các chiến lược phát hiện và giảm thiểu. Đó là một kỹ thuật được sử dụng để đảm bảo rằng bạn có đủ tiền và thời gian trong kế hoạch của mình nếu rủi ro phát triển thành vấn đề. Nó được Steve McConnell ủng hộ trong Dự toán phần mềm và Karl Wiegers trong bài viết này . Điều quan trọng là phải nhận ra rằng đó không phải là bộ đệm cho mỗi tác vụ, mà là bộ đệm dự án (hoặc lặp) sẽ có nhiều rủi ro xảy ra.

— Thomas Owens

Thông thường, tùy thuộc vào chủ Scrum được bầu để quyết định những gì sẽ trở thành nhiệm vụ đã vượt qua giai đoạn nước rút, rõ ràng sau khi tham khảo ý kiến của các thành viên còn lại và chủ tài trợ / chủ sở hữu dự án. Vào cuối cuộc đua nước rút, đã đến lúc xem lại những ưu tiên là gì. Có thể câu chuyện đang được đề cập là có mức độ ưu tiên thấp hơn câu chuyện mới / hiện có và nó sẽ được đưa trở lại trên trình theo dõi là 'đang diễn ra' hoặc bất kỳ nhãn nào mà trình theo dõi của bạn sử dụng, cho thấy câu chuyện này sẽ được theo dõi ở một điểm khác đúng giờ. Ngoài ra, câu chuyện có thể được bỏ qua hoàn toàn. Bạn chưa đề cập đến trình theo dõi nào bạn đang sử dụng, nhưng hầu hết những người tôi đã xem cho phép bạn đặt một câu chuyện thành 'bỏ qua' nếu nó không còn là một phần của dự án.

Thứ hai, vì nhóm của bạn chưa quen với Scrum, đây là một phần của quá trình học tập. Bây giờ bạn đã nhận ra rằng một số câu chuyện quá lớn, vì vậy nhóm của bạn sẽ mất nhiều thời gian hơn để phá vỡ các câu chuyện. Đó thường là trách nhiệm của chủ scrum để đảm bảo điều này xảy ra. Bậc thầy Scrum cũng sẽ cần tham khảo ý kiến của chủ tài trợ / chủ sở hữu dự án với những câu chuyện chưa hoàn chỉnh để thử và phân tích chúng thêm hoặc có tiếng nói cuối cùng về việc bỏ qua chúng hoàn toàn.

Trong nhóm của tôi, một chủ nhân Scrum mới được bầu mỗi 2 tuần (chạy nước rút), vì vậy mọi người đều có cơ hội quản lý các nhiệm vụ, tổ chức các cuộc họp Scrum và đảm bảo mọi người gửi báo cáo tiến độ. Tôi hy vọng đó là trường hợp trong đội của bạn, đó chắc chắn là một trải nghiệm tốt.

— Hành tinh hoang vắng
nguồn

Nitpick: Quyết định phải làm gì với câu chuyện chưa hoàn thành là một câu hỏi ưu tiên. Vì vậy, tôi tin rằng chủ sở hữu sản phẩm nên quyết định điều này, không phải là chủ Scrum.

— sleske

@sleske - Đồng ý. Tôi nên đã làm điều đó rõ ràng hơn trong câu trả lời của tôi. Ban đầu tôi nói chủ scrum sẽ tham khảo ý kiến của nhóm, nhưng tôi nên bao gồm nhà tài trợ / chủ sở hữu dự án, điều mà tôi đã sửa. Cảm ơn cho đầu lên mặc dù.

— Hành tinh hoang vắng

Nếu những câu chuyện chưa hoàn thành vẫn chưa hoàn thành ở giai đoạn nước rút, bạn thực sự không thể phá vỡ chúng vào thời điểm đó bởi vì điều đó có khả năng phá hủy hoàn toàn Định nghĩa Hoàn thành - "Vậy bạn có nói rằng một phần của câu chuyện đã xong chưa? Nhưng nó chưa được xem xét mã! " Đây là lý do tại sao những câu chuyện sử thi đơn lẻ là khủng khiếp và không bao giờ được phép vào nước rút.

— Robin Green

@RobinGreen Tôi đồng ý với việc bạn tham gia sử thi và tôi không phải là người hâm mộ của họ. Một trong những điều quan trọng (một điều mà nhiều người tôi đã làm việc bỏ qua) là giá trị của hồi tưởng. Gần đây chúng tôi đã bắt đầu sử dụng bảng Agile của JIRA và tôi thường xuyên cho đội xem biểu đồ ghi điểm về hiệu suất của các đội. Những câu chuyện không đầy đủ được thảo luận nếu và khi chúng xảy ra và ngay lập tức được đưa vào tồn đọng. Nhìn lại, chúng tôi xem xét tại sao câu chuyện không đầy đủ. Thiếu nguồn lực? Thiếu hiểu biết? hoặc có lẽ là sự kết hợp lỏng lẻo của cả hai.

— Hành tinh hoang vắng