Story w Scrum

Question

Rozpoczęliśmy projekt, który będzie zarządzany Scrum/XP. Napisaliśmy cały backlog produktu z góry w celach ewaluacyjnych. Robimy, że wszystkie historie są zorientowane na klienta i jesteśmy oceniając je

• wartości biznesowej piętrowego: Moskwa technika - Musi, należy może, to/nie będą mieć ten realizowany
• historia próba/złożoności (= punkty historia): 1, 2, 3, 5, 8, 13, 21, 100 - podobne do historii złożoności/wysiłku niż idealnych dni trwania

100 punktów historia może mieć jakieś historie z "Nie chcę" ponieważ w rzeczywistości są one bardziej skomplikowanymi historiami, które zostaną później podzielone, jeśli zajdzie taka potrzeba.

Obliczana ważność historia opiera się na wartości & wysiłku przez nie nakładających się opowieści MoSCoW.

Ale bez 100-punktowych opowieści nasze dotychczasowe historie (również w podziale) mają złożoność od 2 do 8, co uważamy za odpowiednią wielkość opowieści, aby uniknąć mikrozarządzania. Ale niektóre historie stały się powiązane lub zależne od siebie nawzajem. Mamy historie, które mogą zająć więcej, jeśli zostaną zrobione w pierwszej kolejności, i mniej, jeśli przed nimi zostanie zrobiona jakaś inna historia.

Pytania
Czy to możliwe, aby dostosować punkty fabuły później w trakcie rozwoju, jak możemy zrobić z zadań fabularnych, gdzie możemy ich ponownej oceny, dodać nowe, usuwać istniejące lub czy nie jest to przypadek z historii? Ponieważ zmieniając ich złożoność, zmienią także szacunki daty końcowej na podstawie planowanej prędkości. Jaka jest najlepsza praktyka w tym przypadku?

Answer 1

Absolutnie możesz oszacować swoje historie ponownie i powinieneś. Punkty są zablokowane tylko wtedy, gdy drużyna zobowiązuje się do nich na sesji planowania sprintu bezpośrednio przed rozpoczęciem sprintu.

Jedna z praktyk, których używałem podczas wykonywania indywidualnego planowania sprintu, powinna ponownie ocenić każdą historię. Zespół uczy się z biegiem czasu i stanie się dokładniejszy dzięki szacunkom i identyfikacji zależności. Pamiętaj, że to, co wchodzi w skład Sprintu, zależy od zespołu, a właściciel produktu definiuje ogólne zaległości. Jeśli projekt jest powiązany czasowo, nie próbuj dopasowywać prognoz do daty końcowej, jeśli robisz to, ustawiasz się na porażkę.

Pamiętaj, że dzięki Velocity możesz zacząć od odgadnięcia, co możesz osiągnąć. Zwykle dopiero trzecia lub czwarta sprint, jaki trafisz, identyfikuje realistyczną prędkość, którą może zarządzać zespół. Tak, oznacza to, że możesz założyć, że zespół może dostarczyć 20 punktów na sprint i faktycznie może zrobić tylko 15 punktów. Tak, oznacza to, że czas dostawy wygasa lub historie spadają poniżej linii cięcia.

Co do historii zależnych, powinieneś współpracować z właścicielem produktu. Jeśli zespół do nich mówi, zazwyczaj możesz zmienić kolejność opowieści. Większość ludzi jest otwarta na kogoś, kto mówi im: "Jeśli zrobimy A teraz, to zajmie to cały Sprint, ale jeśli zrobimy A później zajmie 15% Sprintu", co czyni go całkiem przekonującym.

Przydatną praktyką do wypróbowania jest planowanie historii w Sprintu. Podczas sesji planowania, gdy wszystkie historie zostaną zatwierdzone i omówione, zespół opracowuje kalendarz i omawia, kiedy chce coś zrobić. Dzięki umieszczeniu dat docelowych w kalendarzu pomaga zidentyfikować nakładanie się i zależności między opowieściami. Może to zidentyfikować rzeczy, które mają charakter seryjny i mogą spowodować niepowodzenie Sprintu.

Mam nadzieję, że te informacje są pomocne.

Answer 2

Mogę tylko opisać moje doświadczenie.

Kiedy planowaliśmy pierwszy sprint, zdecydowaliśmy, że możemy osiągnąć 18 punktów. Zrobiliśmy kilka historii, a całkowita ocena wyniosła 15 punktów. Jak wspomniałem powyżej, stawialiśmy pierwsze kroki w scrumie i dlatego zdecydowaliśmy, że 3 niewykorzystane punkty i współczynnik kształtu 0,6 gwarantują nasz sukces.

Ale nasze szacunki każdej historii były tylko przybliżone. Mieliśmy też kilka zależnych historii. I nie planowaliśmy wdrożenia każdej z historii, ponieważ uważaliśmy, że jest nieprzypadkowa z elastyczną metodologią.

W rezultacie zakończyliśmy nasz pierwszy sprint tylko 8 punktami.

Przed naszym drugim sprintem postanowiłem, że powinniśmy wziąć coś ze starej dobrej prostej kaskady i iteracyjnych metodologii (a ja byłem mistrzem scrum). Tak więc, podczas naszej przyszłej wiosennej planowania, aby dokonać poprawnych szacunków, zaplanowaliśmy każdą historię (około 20 minut na historię), z prostymi diagramami, wszystkimi zależnościami, szczegółami implementacji i tak dalej. Planowanie było trudne i wymagało dwóch spotkań.

Ale drugi sprint był znacznie lepszy i zrobiliśmy prawie wszystko (właściwie zrobiliśmy wszystko z kilkoma błędami). Myślę, że w trzecim sprincie zajmiemy mniejszy współczynnik formy i odniesiemy sukces.

Answer 3

Z twojego wyjaśnienia wykonujesz już świetną robotę. Oczywiście zawsze będą historie z zależnością. Niektóre z nich mogą nie mieć nawet widocznej wartości dla klienta; tj. początkowe próby utworzenia architektury i niektórych frameworków).Ale jeśli je odrzucisz, stworzysz dużo technicznego długu. Jeśli możesz, sugeruję, abyś spróbował ukończyć równanie i jakoś pokazać relację między zadaniami.

Na przykład: - zadanie 3 to 8 punktów, jeśli wykonane po zadaniu 2, ale 12 punktów, jeśli zrobione niezależnie.

W ten sposób właściciel produktu odczuje ból polegający na ignorowaniu zależności, ale może najpierw dokonać wyboru, aby wykonać najcenniejsze historie. Jeśli właściciel produktu jest pewien, że wszystkie historie sprawiają, że w następnych sprinty, możesz sterować, aby je wdrożyć w najbardziej efektywnej kolejności. Na przykład, blokując elementy, dla których nie zostały spełnione zależności (tzn. Możesz mieć tylko funkcję "zmień moje logo na stronie internetowej" po zakończeniu "wersji internetowej").

Powodzenia!

Answer 4

Istnieje kilka wzorców, które pomogłyby Ci w dzieleniu historii użytkowników w taki sposób, że pozostaną INVEST, co oznacza, że ​​spróbujesz w szczególności zapisać zależności, rozmiar, testowalność i wartość. Możesz przeczytać więcej na ten temat tutaj: http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/ Richard aktywnie stosuje i poprawia je, a on nie jest sam ;-)

Pamiętaj tylko, że dzielenie i utrzymywanie zależności (co jest jak tworzenie krytycznej ścieżki na wykresie Gantta) ma przeważyć zdolność zespołu do kreatywności i negocjować te historie, a także może ukryć "nie-wartościową propozycję".

HTH
ANdreaT