Nhầm lẫn về việc sửa đổi tồn đọng nước rút trong một lần chạy nước rút

Gần đây tôi đã đọc rất nhiều về scrum và tôi đã tìm thấy những gì dường như là thông tin mâu thuẫn với tôi về việc có nên thay đổi nước rút tồn đọng trong giai đoạn nước rút hay không. Các bài viết trên Wikipedia về scrum nói nó không phải là ok, và nhiều bài báo khác nói điều này là tốt. Giáo sư Phát triển phần mềm của tôi cũng dạy điều tương tự trong phần tổng quan về scrum.

Tuy nhiên, tôi đã đọc Scrum và XP từ Rãnh và điều đó mô tả một phần dành cho các mục không có kế hoạch trên bảng tác vụ. Vì vậy, sau đó tôi đã tra cứu Hướng dẫn Scrum và nó nói rằng trong giai đoạn nước rút "Không có thay đổi nào ảnh hưởng đến Mục tiêu Sprint" và trong cuộc thảo luận về Mục tiêu Sprint "Nếu công việc hóa ra khác với Nhóm phát triển dự kiến, sau đó họ hợp tác với Chủ sở hữu sản phẩm để đàm phán phạm vi của Sprint Backlog trong Sprint. " Nó tiếp tục nói trong cuộc thảo luận về Sprint Backlog:

Sprint Backlog là một kế hoạch có đủ chi tiết để thay đổi tiến trình có thể được hiểu trong Scrum hàng ngày. Nhóm phát triển sửa đổi Sprint Backlog trong suốt Sprint và Sprint Backlog xuất hiện trong suốt Sprint. Sự xuất hiện này xảy ra khi Nhóm phát triển làm việc thông qua kế hoạch và tìm hiểu thêm về công việc cần thiết để đạt được Mục tiêu Sprint.

Khi công việc mới được yêu cầu, Nhóm phát triển sẽ thêm nó vào Sprint Backlog. Khi công việc được thực hiện hoặc hoàn thành, công việc còn lại ước tính được cập nhật. Khi các yếu tố của kế hoạch được coi là không cần thiết, chúng sẽ bị xóa. Chỉ Nhóm Phát triển mới có thể thay đổi Sprint Backlog trong Sprint. Sprint Backlog là một bức tranh thời gian thực rõ ràng về công việc mà Nhóm phát triển dự định hoàn thành trong Sprint và nó chỉ thuộc về Nhóm phát triển.

Vì vậy, tại thời điểm này tôi hoàn toàn bối rối. Nghĩ về nó, nó có ý nghĩa hơn đối với tôi để thực hiện cách tiếp cận thứ hai. Các mục cụ thể, riêng lẻ trong backlog dường như không phải là điều quan trọng nhất, mà là mục tiêu chạy nước rút, vì vậy không thay đổi mục tiêu chạy nước rút mà có thể thay đổi backlog có ý nghĩa. Ví dụ, nếu cả chủ sở hữu sản phẩm và nhóm nghĩ rằng họ đang ở cùng một trang về một câu chuyện, nhưng khi nước rút tiến triển, họ nhận ra rằng có một sự hiểu lầm, có vẻ như việc thay đổi các nhiệm vụ tạo nên câu chuyện đó phù hợp . Hoặc nếu có một câu chuyện hoặc nhiệm vụ nào đó bị lãng quên, nhưng được yêu cầu để đạt được mục tiêu nước rút, tôi nghĩ sẽ tốt nhất là thêm câu chuyện hoặc nhiệm vụ vào hồ sơ tồn đọng trong giai đoạn nước rút.

Tuy nhiên, có rất nhiều người có vẻ khá kiên quyết rằng bất kỳ thay đổi nào đối với việc tồn đọng nước rút là không ổn. Tôi có hiểu nhầm vị trí đó không? Là những người định nghĩa nước rút tồn đọng khác nhau bằng cách nào đó? Sự hiểu biết của tôi về tồn đọng nước rút là nó bao gồm cả câu chuyện và nhiệm vụ mà chúng được chia thành.

Dù sao, tôi thực sự sẽ đánh giá cao đầu vào về vấn đề này. Tôi đang cố gắng tìm ra cả cách tiếp cận scrum lý tưởng là thay đổi tồn đọng nước rút trong giai đoạn nước rút và liệu những người sử dụng scrum thành công để phát triển có cho phép thay đổi tồn đọng nước rút trong giai đoạn nước rút hay không.

Đầu tiên tôi sẽ không có quy tắc cứng về nó; toàn bộ quan điểm của scrum là cho phép bạn thích nghi với hoàn cảnh. Vì vậy, bạn sẽ có thể sửa đổi tồn đọng nước rút trong khi chạy nước rút nếu bạn hoàn toàn phải (như bạn quên một cái gì đó quan trọng).

Nhưng nói rằng sửa đổi này để tồn đọng nước rút trong nước rút nên được chống lại. Toàn bộ điểm của lần chạy nước rút là công việc mới có thể được thêm vào lần chạy nước rút tiếp theo (sau khi nó được ưu tiên chính xác) mà không ảnh hưởng đến dòng thời gian dự án tổng thể (nhiều lần chạy nước rút).

Nhưng nếu công việc là quan trọng đối với một trong những nhiệm vụ trong lần chạy nước rút này, bạn có hai lựa chọn.

1. Thêm mục mới vào nước rút.
   NHƯNG loại bỏ một mục có kích thước tương đương từ nước rút.
2. Bỏ mục đã được lên kế hoạch xấu từ lần chạy nước rút này (để bạn có thể lập kế hoạch đúng cho lần chạy nước rút tiếp theo).
   • Thêm vào một thay thế (có kích thước phù hợp) từ đầu của sản phẩm tồn đọng (cần có thứ tự ưu tiên từ cuộc họp lập kế hoạch nước rút của bạn).
   • Hoặc khi tất cả các mục chạy nước rút kết thúc, hãy cho phép các nhà phát triển thu thập thông tin từ hồ sơ tồn đọng của sản phẩm.

Vì vậy, tôi đang ở trong trại mà có lẽ bạn không nên sửa đổi tồn đọng nước rút. Nhưng bạn phải tính đến tình huống có thể có trường hợp đặc biệt. Trong hầu hết các trường hợp, tôi sẽ sử dụng các tùy chọn 2 và để các nhà phát triển nhận lấy sự chậm chạp với các nhiệm vụ từ hồ sơ tồn đọng.

Sau đó, trong cuộc họp lập kế hoạch tiếp theo, nhiệm vụ mới sẽ được phân tích và bổ sung một cách thích hợp vào giai đoạn nước rút (khi thích hợp).

Hãy nhớ nước rút là ngắn và chỉ là dấu hiệu của lần giảm tiếp theo chứ không phải là kết thúc chu kỳ phát triển. Chủ sở hữu sản phẩm sẽ phải rất tuyệt vọng cho một tính năng mà họ không thể chờ đến cuối cuộc đua nước rút tiếp theo.

Sự nhầm lẫn là do ngôn ngữ mơ hồ.

Sprint Backlog có hai cấp độ chi tiết. Đầu tiên, đó là danh sách các Mục (Câu chuyện của người dùng) mà Nhóm đã cam kết phân phối. Thứ hai, đó là tất cả NHIỆM VỤ mà nhóm dự định sẽ làm để đưa ra từng câu chuyện.

Vì vậy, khi mọi người nói về Sprint Backlog, họ nên thực sự rõ ràng về ý nghĩa của chúng. Khi bạn đọc Hướng dẫn Scrum, bạn sẽ thấy rằng: Sprint Backlog là tập hợp các mục Product Backlog được chọn cho Sprint, cộng với kế hoạch phân phối Sản phẩm Tăng dần và hiện thực hóa Mục tiêu Sprint.

Vì vậy, đó là CẢ HAI danh sách các mặt hàng tồn đọng sản phẩm và kế hoạch (Nhiệm vụ) để phân phối chúng.

Bây giờ, nhiều nhóm muốn thêm tất cả các nhiệm vụ (kế hoạch) được đề xuất vào đầu Sprint để họ có thể theo dõi biểu đồ phát sinh dựa trên số giờ còn lại phải làm. Các đội khác để các nhiệm vụ xuất hiện theo yêu cầu. ĐÂY là khi bạn có thể thêm vào 'Sprint Backlog', vì nhóm phải làm điều đó để kiểm tra và điều chỉnh nhằm phân phối Vật phẩm và đáp ứng Mục tiêu của Sprint.

Trong một số trường hợp nhất định, một nhóm có thể đi trước tiến độ và (đã loại bỏ tất cả các nhiệm vụ hữu ích khác có thể cải thiện khả năng của Nhóm) có thể quyết định làm việc với Chủ sở hữu sản phẩm để chọn một câu chuyện khác (nên được ưu tiên và có kích thước) từ Product Backlog ... nhưng chỉ khi họ có niềm tin rằng nó sẽ được hoàn thành trong Sprint đó và nó phù hợp với Mục tiêu của Sprint.

Vì vậy, chúng tôi đã có nó; CÓ ... các đội KHÔNG thêm Nhiệm vụ vào kế hoạch Sprint Backlog theo yêu cầu. KHÔNG, họ thường không thêm vào danh sách các Mục tồn đọng xác định Phạm vi của Sprint.

Tôi hy vọng điều này làm rõ tình hình.

Nó phụ thuộc vào tình huống của bạn. Nếu một số thông tin bị bỏ lỡ trong quá trình lập kế hoạch, và sau đó bạn nhận ra rằng bạn cần sửa đổi hoặc thêm một số điểm vào một vài câu chuyện, thì tôi nghĩ rằng nó ổn. Nhưng, vâng, nếu phạm vi của một tính năng thay đổi hoàn toàn, thì đó là một tình huống cực đoan và cần phải được xử lý khác nhau.

Nhưng tất nhiên, trong quá trình lập kế hoạch, người ta cho rằng mọi người đều biết rõ và thảo luận về từng tính năng mà họ sẽ làm việc. Nếu các cuộc thảo luận và lập kế hoạch là tốt, thì trong hầu hết các trường hợp bạn không thực sự cần bất kỳ sửa đổi nào.

Tôi đồng ý với câu trả lời, tôi chỉ ra rằng nếu câu chuyện đã bắt đầu phát triển thì nó không thể dừng lại cho đến khi hoàn thành.

Đào gót chân của bạn vào đầu. Những người yêu cầu thay đổi sẽ phải học một cách khó khăn, nếu không, bạn sẽ kết thúc với kế hoạch trở nên vô giá trị nếu mọi người học bạn có thể làm những gì bạn thích bằng mọi cách.

Trích dẫn rằng chất lượng đến từ sự tập trung và lỗi đến từ việc thả một dòng suy nghĩ. Trích dẫn chi phí chuyển đổi bối cảnh. Theo dõi nợ và quản lý bằng văn bản và thảo luận và chơi - trong một câu chuyện để giải quyết công việc nửa vời là tốn kém. Đừng bắt đầu xuống tuyến đường này.

Ý tưởng: cung cấp cho ban quản lý 3 tín dụng chuyển đổi để chi tiêu mỗi quý như một sự thỏa hiệp.