Ponowna ocena historii przez Scrum

Każdego dnia, po stand-up , mój zespół i ja aktualizować nasze szacunki dla każdej historii. Mam wrażenie, że jest coś nie tak ze sposobem, w jaki to robimy, więc potrzebuję twojej pomocy.

To jest jak to robimy:

Szacunkowa historia A: 24 godziny (8 godzin dziennie - jako miarę używamy „idealnych dni”)

• Dzień N: programista rozpoczyna pracę nad Historią A rano (8 godzin pracy ukończonej do końca dnia)
• Dzień N + 1: Ponowne oszacowanie Story A = 16 godzin (jeden dzień roboczy wyjęty z Story A, od dnia N)
• Dzień N + 2: Ponowne oszacowanie opowieści A = 8 godzin (jeden dzień roboczy wyjęty z opowieści A, od dnia N + 1)
• Dzień N + 3: Historia A powinna już być skończona. Ale nie jest. Deweloper uważa, że ​​ukończenie zajmie kolejne 3 godziny. Aktualizujemy historię na tablicy i wypalamy odpowiednio.
• Dzień N + 4: Historia A zajęło cały dzień, a nie tylko 3 godziny! Teraz jest gotowe. Różnica, 5 godzin, jest całkowicie nieuwzględniona w naszym planowaniu.

Jak powinniśmy codziennie oceniać nasze historie?

Różnica 5 godzin jest całkowicie nieuwzględniona w naszym planowaniu.

Tak, rozlicza się to domyślnie, ponieważ następujące zadania są opóźnione. Gdyby istniał wykres wypalenia tylko dla tego dewelopera, można zauważyć, że krzywa pozostała „płaska” przez jeden dzień, a spadłaby, gdyby deweloper ukończył ją wystarczająco wcześnie, aby podjąć inne zadanie.

Nie ma nic złego w sposobie dokonywania ponownej oceny podczas codziennego spotkania. Ponowna ocena polega raczej na ustaleniu, czy damy radę na koniec sprintu, niż na śledzeniu dokładnego opóźnienia każdego zadania. Wszystko, czego potrzebujesz w Scrumie, aby móc codziennie dostosowywać swój plan, to coś, co wskazuje na postęp Sprinta i jak daleko jesteś od osiągnięcia celu Sprint (zazwyczaj wykres wypalenia).

Pytanie, które powinieneś zadać, brzmi: czy powinniśmy ponownie oceniać nasze historie?

Argumentowałbym, że powinieneś pozwolić zwinnej „magii” zrównoważyć swoje niedoszacowanie i przeszacowanie podczas iteracji podczas obliczania prędkości dla następnego (co jest jedynym powodem, aby skorygować wartość). Zobacz zwinne oszacowanie i planowanie Mike'a Cohna, aby uzyskać więcej informacji.

Jest jednak przypadek, w którym powinieneś ponownie oszacować: gdzie coś, czego dowiedziałeś się o kategorii pracy, koryguje wszystkie szacunki na przyszłość.

na przykład. Jeśli szacuje się, że dodanie kolumny do bazy danych zajmuje idealną godzinę, ale okazuje się, że zajmuje to 3 godziny z powodu jakiegoś czynnika, którego nikt nie wziął pod uwagę i wygląda na to, że ten czynnik będzie obowiązywał za każdym razem, gdy dodasz pole do bazy danych wtedy wszystkie szacunki dotyczące pracy tego rodzaju powinny zostać dostosowane, w tym te, nad którymi pracujesz.

Najbardziej skuteczne okazało się:

• Sortuj historie według punktów (lub rozmiarów koszulek).
• Ponownie oszacuj dowolną historię w rejestrze produktów w dowolnym momencie (ale szczególnie tuż przed planowaniem sprintu).
• Nie oceniaj ponownie historii zaplanowanych na ten sprint - nie wahaj się przywoływać obaw podczas pojedynku, ale nie zmieniaj szacunków.
• Użyj wczorajszej pogody, aby zaplanować sprinty

Jeśli opowieści wkraczają do sprintu z fałszywymi szacunkami, ponowne oszacowania planowania przed sprintem pozwolą Ci je naprawić, zanim staną się problemem. Jeśli opowieści trwają dłużej, niż się spodziewano, ponieważ zespół jest zbyt optymistyczny, wczorajsza pogoda będzie Cię śledzić.

Codzienne przeszacowania tego, co pozostało, są całkowicie fałszywe, jak opisano w pytaniu. Praca zakończona / pozostała to fałszywa liczba zaprojektowana tak, aby wyglądała, jakbyś pracował „wystarczająco ciężko”. Zdecydowanie lepiej jest zapytać: „Kiedy myślisz, że skończysz” i wyjaśnić, że jeśli wystąpi jakiś problem z historią, zespół podejmie pomoc.

Myślę, że to nie jest problem. Może to być raczej brak doświadczenia. Im więcej śledzisz scrum, tym więcej programistów przyzwyczaja się do dostarczania dokładniejszych oszacowań. Takie jest nasze doświadczenie we wdrażaniu scrum po 5 miesiącach.

Podczas planowania sesji pokerowych nasi programiści sugerowali bardzo zróżnicowane oszacowania dla każdego PBI i każdego zadania podczas pierwszego sprintu. Jednak teraz jesteśmy prawie równi pod względem czasu i szacunków. Jak długo używasz Scruma? Jeśli nie tyle, daj mu trochę czasu. Ale jeśli to długo, to jak sugerował @pdr, rozważ dodanie dodatkowego marginesu dla zadań o wyższym ryzyku . Na przykład za każdym razem, gdy nasz zespół chce stworzyć interfejs użytkownika w przeglądarce, przekazujemy nasze szacunki. Dlatego zawsze mnożymy oszacowanie zadań w różnych przeglądarkach przez czynnik, aby mieć pewność, że możemy je uwzględnić.

Ponowne oszacowanie historii użytkowników zaangażowanych podczas sprintu nie ma sensu. To tylko marnuje twój czas. Podjęłeś już zobowiązanie i nie ma znaczenia, czy dokonasz ponownej oceny, czy nie.

Inna sytuacja dotyczy historii użytkowników, którzy nie są zaangażowani w bieżący sprint. Od czasu do czasu warto dokonać ponownej oceny (nie więcej niż raz na sprint przed planowaniem). Sytuacje, dla których uzasadnione może być ponowne oszacowanie, mogą być:

• Właściciel produktu zmienił dowolną historię użytkownika
• Właściciel produktu podzielił lub scalił dowolną historię użytkownika
• Właściciel produktu dodał historię użytkownika
• Masz dodatkową wiedzę, która nie była dostępna podczas ostatniej historii użytkownika
• Odkryłeś, że niektóre historie użytkowników są powiązane i już zrobiłeś część innej, która nie została jeszcze popełniona
• itp.

Nie musisz ponownie oceniać każdej historii użytkownika, ale możesz. Do pełnego przeszacowania zwykle potrzebujesz szybkiej metody. Planowanie pokera może być cholernie powolne, nieefektywne, nudne, a czasem również niedokładne, jeśli oszacujesz więcej niż 10-20 historii. Alternatywą może być oszacowanie magii .