Zmieszany przy modyfikowaniu zaległości sprintu podczas sprintu

Ostatnio dużo czytałem o scrumie i znalazłem coś, co wydaje mi się sprzeczną informacją o tym, czy można zmienić zaległości sprintu podczas sprintu. Artykuł Wikipedii na temat scrum mówi, że to nie jest w porządku, a różne inne artykuły również to mówią. Również mój profesor ds. Rozwoju oprogramowania nauczał tego samego podczas przeglądu scrum.

Jednak czytam Scruma i XP z Okopów i to opisuje sekcję dotyczącą nieplanowanych elementów na tablicy zadań. Potem przejrzałem Przewodnik Scruma i mówi, że podczas sprintu „Nie wprowadzono żadnych zmian, które wpłynęłyby na Cel Sprintu” oraz w dyskusji na temat Celu Sprintu „Jeśli praca okaże się inna niż oczekiwano od Zespołu programistycznego, następnie współpracują z Właścicielem produktu w celu negocjacji zakresu Backlogu Sprintu w ramach Sprintu. ” W dyskusji na temat Backlogu Sprintu mówi dalej:

Backlog Sprint to plan z wystarczającą ilością szczegółów, aby zmiany w toku były zrozumiałe w Daily Scrum. Zespół programistów modyfikuje dziennik sprintu w całym sprincie, a dziennik sprintu pojawia się podczas sprintu. Pojawia się, gdy zespół programistów pracuje nad planem i dowiaduje się więcej o pracy potrzebnej do osiągnięcia celu sprintu.

Ponieważ wymagana jest nowa praca, zespół programistów dodaje ją do Backlogu Sprintu. W miarę wykonywania lub ukończenia pracy szacowana pozostała praca jest aktualizowana. Gdy elementy planu zostaną uznane za niepotrzebne, zostaną usunięte. Tylko zespół programistów może zmienić swój dziennik sprintu podczas sprintu. Backlog Sprint jest bardzo dobrze widocznym obrazem prac, które Zespół programistyczny planuje wykonać podczas Sprint, w czasie rzeczywistym, i należy on wyłącznie do Zespołu programistycznego.

Więc w tym momencie jestem całkowicie zdezorientowany. Myśląc o tym, bardziej sensowne jest dla mnie drugie podejście. Poszczególne elementy w zaległościach nie wydają mi się najważniejsze, ale raczej cel sprintu, więc nie zmiana celu sprintu, ale możliwość zmiany zaległości ma sens. Na przykład, jeśli zarówno właściciel produktu, jak i zespół myśleli, że są na tej samej stronie na temat historii, ale w miarę postępu sprintu odkryli, że doszło do nieporozumienia, wydaje się, że sensownie jest odpowiednio zmienić zadania składające się na tę historię. . Lub, jeśli zapomniano o jakiejś historii lub zadaniu, ale jest ona wymagana do osiągnięcia celu sprintu, pomyślałbym, że najlepiej byłoby dodać historię lub zadanie do zaległości podczas sprintu.

Jednak jest wiele osób, które wydają się dość nieugięte, że jakakolwiek zmiana w zaległościach sprintu nie jest w porządku. Czy w jakiś sposób nie rozumiem tej pozycji? Czy ci ludzie definiują zaległości sprintu inaczej? Rozumiem, że zaległości w sprincie obejmują zarówno historie, jak i zadania, na które są podzielone.

W każdym razie bardzo doceniłbym wkład w tę kwestię. Próbuję dowiedzieć się, jakie jest idealistyczne podejście Scrum do zmiany zaległości sprintu podczas sprintu oraz czy ludzie, którzy używają Scruma do rozwoju, pozwalają na zmianę zaległości sprintu podczas sprintu.

Po pierwsze, nie miałbym twardych reguł na ten temat; sednem scrum jest umożliwienie ci dostosowania się do sytuacji. Powinieneś być w stanie zmodyfikować zaległości sprintu podczas sprintu, jeśli absolutnie musisz (tak jakbyś zapomniał o czymś krytycznym).

Ale powiedzeniu tej modyfikacji zaległości sprintu podczas sprintu należy się oprzeć. Istotą skrótu sprintu jest to, że można dodawać nowe prace do następnego sprintu (po prawidłowym ustaleniu priorytetów) bez wpływu na ogólną oś czasu projektu (wiele sprintów).

Ale jeśli praca ma kluczowe znaczenie dla jednego z zadań w tym sprincie, masz dwie opcje.

1. Dodaj nowy przedmiot do sprintu.
   ALE usuń przedmiot o podobnej wielkości z sprintu.
2. Upuść przedmiot, który był źle zaplanowany z tego sprintu (abyś mógł go odpowiednio zaplanować w następnym sprincie).
   • Dodanie alternatywy (o odpowiednim rozmiarze) z góry zaległości produktu (która powinna być w kolejności priorytetowej na spotkaniu dotyczącym planowania sprintu).
   • Lub gdy wszystkie elementy sprintu zostaną ukończone, pozwól deweloperom nabrać luzu z rejestru produktów.

Jestem w obozie, więc prawdopodobnie nie powinieneś modyfikować zaległości sprintu. Musisz jednak wziąć pod uwagę sytuację, w której mogą wystąpić wyjątkowe okoliczności. W większości przypadków wybrałbym opcję 2 i pozwoliłem deweloperom wybrać luz z zadaniami z zaległości.

Następnie na następnym spotkaniu planistycznym nowe zadanie zostanie odpowiednio przeanalizowane i dodane do sprintu (odpowiednio).

Pamiętaj, że sprint jest krótki, a jedynie znak następnej kropli, a nie koniec cyklu rozwoju. Właściciel produktu musiałby być bardzo zdesperowany w związku z funkcją, która nie mogła się doczekać końca następnego sprintu.

Zamieszanie wynika z niejednoznacznego języka.

Backlog Sprint ma dwa poziomy szczegółowości. Po pierwsze, jest to lista przedmiotów (historii użytkowników), które zespół zobowiązał się dostarczyć. Po drugie, wszystkie ZADANIA, które zespół zamierza zrobić, aby przekazać każdą z tych historii.

Kiedy więc ludzie mówią o Backlogu Sprintu, powinni naprawdę jasno powiedzieć, co mają na myśli. Po przeczytaniu Przewodnika po Scrumie zobaczysz, że zawiera on następujące informacje: Backlog Sprint to zestaw elementów Backlogu Produktu wybranych dla Sprinta, plus plan dostarczenia Przyrostu produktu i realizacji Celu Sprint.

Tak więc ZARÓWNO lista elementów Backlogu Produktu ORAZ Plan (Zadania), aby je dostarczyć.

Teraz wiele zespołów lubi dodawać wszystkie proponowane zadania (plan) na początku sprintu, aby mogły śledzić wykres wypalenia na podstawie pozostałej liczby godzin do zrobienia. Inne zespoły pozwalają, aby zadania pojawiały się zgodnie z wymaganiami. TO jest wtedy, gdy można dodawać do „Rejestru sprintu”, ponieważ zespół musi to zrobić, aby sprawdzić i dostosować się w celu dostarczenia Przedmiotów i osiągnięcia celu Sprint.

W pewnych okolicznościach zespół może znacznie wyprzedzić harmonogram i (po wyeliminowaniu wszystkich innych przydatnych zadań, które mogłyby poprawić możliwości zespołu) może zdecydować o współpracy z właścicielem produktu, aby wybrać inną historię (powinna mieć już priorytet i rozmiar) Backlog Produktu ... ale tylko wtedy, gdy mają pewność, że zostanie on ukończony w ramach tego Sprintu i że będzie zgodny z celem Sprint.

A więc mamy to; TAK ... zespoły dodają zadania do planu Sprint Backlog zgodnie z wymaganiami. NIE, zwykle nie dodają do listy elementów zaległości, które określają zakres sprintu.

Mam nadzieję, że to wyjaśnia sytuację.

To zależy od twoich sytuacji. Jeśli podczas planowania brakuje niektórych informacji, a później okazuje się, że musisz zmodyfikować lub dodać kilka punktów do kilku opowiadań, to myślę, że jest w porządku. Ale tak, jeśli zakres funkcji zmienia się całkowicie, to jest to sytuacja skrajna i należy z nią postępować inaczej.

Ale oczywiście podczas planowania zakłada się, że wszyscy wyraźnie znają i omawiają każdą z funkcji, nad którymi będą pracować. Jeśli dyskusje i planowanie są dobre, to prawie we wszystkich przypadkach tak naprawdę nie potrzebujesz żadnych modyfikacji.

Zgadzam się z odpowiedziami, zwracam uwagę, że jeśli historia zaczęła się rozwijać, nie można jej zatrzymać, dopóki nie zostanie ukończona.

Wcześnie wykop pięty. Osoby proszące o zmianę będą musiały nauczyć się na własnej skórze, w przeciwnym razie skończy się to planowaniem bycia bezwartościowym, jeśli ludzie nauczą się, że możesz robić to, co lubisz.

Przyznaj, że jakość wynika z koncentracji, a błędy wynikają z porzucenia toku myślenia. Podaj koszt przełączania kontekstu. Śledzenie zadłużenia oraz zarządzanie pisaniem, dyskutowaniem i odgrywaniem historii zajmującej się pracą na wpół upieczoną jest kosztowne. Tylko nie zaczynaj tej trasy.

Pomysł: daj kierownictwu 3 kredyty na zmianę, aby wydawać co kwartał jako kompromis.