Jak duża powinna być każda historia dla osoby w 3-tygodniowym sprincie?

TL; DR

Zasadniczo cały zestaw założeń planowania nie jest zwinny. Musisz ponownie przeanalizować, w jaki sposób planujesz swoje iteracje i jak planuje Twój zespół oszacować pracę, która jego zdaniem może zostać wykonana w bieżącej iteracji. Następnie następuje bardziej szczegółowa analiza.

Szczegółowa analiza

Wiemy, że planowanie długoterminowe (planowanie wydania) powinno być tematem fabularnym. [sic]

Nie. Planowanie wydania Agile odbywa się w iteracjach . Dlatego plan projektu Scrum oszacuje przybliżony zakres iteracji potrzebnych do osiągnięcia minimalnego możliwego do zrealizowania produktu lub ukończenia początkowego Backlogu Produktu. To jest tylko oszacowanie, ponieważ zawartość zaległości będzie się zmieniać w czasie, a długość i dokładność szacunków będzie się zmieniać wraz ze stożkiem niepewności .

Ale planowanie sprintu powinno być oparte na zaangażowaniu.

Ponownie, nie. Planowanie sprintu jest na podstawie pojemności . Jedyny punkt śledzenia (lub tworzenie wstępnych oszacowań) średniej szybkości zespołu polega na znalezieniu trwałej zdolności zespołu do pracy w czasie. Podczas gdy zespół musi mieć pewność, że nigdy nie będzie nadmiernie angażować się w pracę w Sprincie tylko dlatego, że zakres prędkości lub średnia mówi, że powinna być dostępna pojemność, to zespół jest odpowiedzialny za planowanie bieżącej iteracji, biorąc skład zespołu, dostępność i inne czynniki , które wpływają na obecny Sprint .

Mówienie, że Sprinty są „oparte na zaangażowaniu”, może być użyte jako emocjonalna pałka, aby zmusić zespoły do zaangażowania się więcej pracy niż powinni, ponieważ członkowie zespołu kursu powinni być „zaangażowani”. Jednak jest to nadużycie; W prawdziwym świecie pojemność zespołu powinna być generalnie zmniejszona, ale rzadko zawyżana podczas planowania. Jeśli zespół nie zaangażował się, w razie potrzeby można oddzielić dodatkową pracę od Backlogu Produktu, ale ograniczanie zakresu jest prawie zawsze obciążone politycznie i często zagraża Celowi Sprintu. Więc nie rób tego.

Pojemność może być względnie obiektywną miarą. Z drugiej strony, zaangażowania (podobnie jak patriotyzmu) nie można mierzyć, chyba że ty prosząc ludzi o „ostateczne poświęcenie”, co jest w pewnym sensie sprzeczne z całą przesłanką zwinnego zrównoważonego rozwoju. Nigdy nie angażuj się w marsz śmierci .

W przypadku trzytygodniowego sprintu, jak duża powinna być każda historia dla osoby?

To zasługuje na całą książkę wypełnioną „nie”. Historie nigdy nie są dopasowane do konkretnej osoby ani nie są przez nią akceptowane. Wszystkie historie są szacowane na podstawie pełnych, skoordynowanych zasobów wielofunkcyjnego zespołu pracującego razem , aby ukończyć każdą historię. Historie są akceptowane lub odrzucane na podstawie tego, czy:

1. Są one niezbędne do osiągnięcia bieżącego celu sprintu.
2. Będą pasować do szacowanej pojemności dostępne dla bieżącego Sprintu.

Pojedynczy element Backlogu Produktu może być dowolny ponownie od 0 punktów fabularnych do maksymalnej dostępnej dla całego Sprintu. Jednak dobra historia, która spełnia kryteria INVEST , składa się na ogół z zadań Sprint Backlog trwających od około 0,5 do 2,0 dni. Pamiętaj, że im mniejsze zadanie lub historia, tym zwykle dokładniejsze jest oszacowanie, więc tuzin 5-punktowych historii (jeśli dokładnie oszacowano) jest generalnie bardziej wiarygodnych niż pojedyncza 60-punktowa historia. Jednak dojrzałość zespołu i dokładność szacunków mogą z pewnością się różnić.

Historie użytkowników nie są dostępne dla każdego członka zespołu

Wielu członków zespołu powinno pracować z tym samym użytkownikiem historię w tym samym czasie. To nie jest wymóg, ale zalecenie. Istota terminologii rugby, scrum , w której zespół podchodzi do linii bramkowej jako jednostka. Pojęcie to nazywa się rojem . Każdy w danym momencie skupia się na jednym (lub mniej) zadaniu, kończy je i zajmuje się kolejną pracą (powtórz). Korzyści:

• Utrzymuje_w postępie_ elementów mniej.
• Umożliwia ukończenie elementów rejestru sprintu rozłożonych w trakcie sprintu, zamiast wykonywania wszystkiego blisko końca sprintu.
• Utrzymuje równomierne rozłożenie obciążenia qa / testowania w czasie trwania sprintu.
• Cały zespół zapoznaje się z kodem i może przekazywać sugestie techniczne.

Zespół powinien wybierz historię i podziel ją na zadania techniczne. Tylko jedna osoba powinna pracować nad jednym zadaniem technicznym, ponieważ odpowiedzialność jest w tym przypadku jasna, co pomaga podczas codziennych spotkań scrumowych. Idealnie byłoby, gdyby jedno zadanie techniczne było wystarczająco małe, aby zostało ukończone w ciągu dnia.

Rozmiar historii użytkowników

Scrum nie definiuje żadnych zalecany rozmiar historyjki użytkownika. Jednak historia powinna być tak dobrana, aby można ją było ukończyć podczas jednego sprintu. „Zakończenie” oznacza, że obejmuje Twoją „Definicję ukończenia”.

Historia powinna być jasno zrozumiana i mieć wyraźne kryteria akceptacji , które są weryfikowane podczas tego samego sprintu. Zwykle trudniej jest uporządkować dużą historię i przeliterować wszystkie kryteria akceptacji, więc opowieść powinna być krótka, jeśli można ją wystarczająco dobrze oszacować i przetestować.

Historia powinna być również wystarczająco duża, aby zapewnia interesariuszom konkretną wartość biznesową.

Tak więc odpowiedź brzmi ani za mała, ani za duża . Dzięki praktyce i doświadczeniu możesz lepiej pisać i dzielić historie użytkowników. To bardziej sztuka niż nauka.

Planowanie sprintu również powinno być tematem fabularnym. Proces jest taki sam, jak w przypadku planowania długoterminowego. Sprawdzasz swoją prędkość i pojemność (ilu członków zespołu będzie tam z powodu wakacji itp.) i podchodzisz liczbą.

Jeśli planujesz sprint 2, sprawdzasz swoją prędkość w sprincie 1 – na przykład 10 punktów – i umieszczasz historie użytkowników warte 10 punktów w swoim rejestrze iteracji.

Jeśli planujesz sprint 3, sprawdzasz trend prędkości ze sprintu 1 do 2 i znajdujesz kwotę, na którą możesz się poświęcić.

Jeśli planujesz sprint 1, dodajesz aż uważasz za stosowne.

Staraj się nie widzieć, ile punktów osoba może zrobić , ponieważ scrum jest o zespołach, a nie o osobach. Na przykład junior może zrobić mniej niż starszy, ale jeśli ludzie pomagają sobie nawzajem, nie będą w stanie dostarczyć tak dużo, jak „na papierze”. Pracuj i kalkuluj z zespołami , ponieważ ma to większy sens (i jest łatwiejsze).

Komentarze

• Tak, Zgadzam się, wszystkie historie z poprzednich sprintów do odniesienia i jak powiedziałeś / CodeGnome, pojemność również powinna być brana pod uwagę. Właściwie nie wiem, jak krótkie powinno być ” każdą historię „, aby można ją było przetestować równolegle, ponieważ nie ma oddzielnej fazy testowej.
• Ponadto wspomniałem wcześniej: mountaingoatsoftware.com/blog/…
• @Roop, jak powiedzieli inni, ” każda ” historia nie musi być wystarczająco krótka. Będzie pracować nad nią wielu członków zespołu, ale zadania w niej zawarte powinny być przechowywane od 0,5 do 2 dni