Wczesne podzadanie na początku każdego sprintu

Dołączyłem do nowego zespołu, który używa Agile / Scrum, a ich proces rozwoju jest następujący:

1) programiści sprawdzają każdą historię przed każdym sprintem, aby upewnić się, że nie przeoczy niczego krytycznego. Jest taki stan formalny w przepływie pracy.

2) podczas rozpoczęcia Sprint cała drużyna dokonuje oszacowania (planowania pokera), ile punktów opowieści kosztowałaby każda historia.

3) wreszcie, natychmiast po rozpoczęciu każdego sprintu, każdy programista musi z chęcią rozbić wszystkie przypisane historie na podzadania z oszacowaniami czasu (w przeciwieństwie do podzadania przed rozpoczęciem każdej historii).

Głównym argumentem za ostatnim krokiem jest to, że pomaga odkryć, czy wdrożenie opowieści potrwa dłużej, niż się spodziewano, i ostrzec mistrza scrum przed potencjalnym ryzykiem niedotrzymania terminów sprintu.

Uważam jednak, że przynosi to efekt przeciwny do zamierzonego, głównie z następujących powodów:

• jeśli celem jest oszacowanie przybliżone, punkty fabularne (krok # 2) są tym, co działa. W przeciwnym razie po co w ogóle zawracać sobie głowę punktami historii? - po prostu zrób podzadanie wcześnie.
• jeśli celem jest dostarczenie dokładnych danych szacunkowych, jest to wyraźny przykład tego, co opisano w przełącznikach zadań ludzkich uznanych za szkodliwe . Myślę, że dotyczy to zwłaszcza nowych programistów, którzy dołączają do istniejących zespołów w dużych projektach, w których zrozumienie, co należy zrobić, może zająć do 50% czasu. Musisz zapoznać się ze szczegółami opowieści nr 1, następnie opowieści nr 2, nr 3 itd. Itd., Które dostarczają wiele informacji.

Powiedziano mi również, że taka praktyka jest „z książki” i nawet nie mam zamiaru o tym dyskutować. Czy ktoś może podać odniesienie do takiej praktyki - czy jest to jasno określone w Biblii Scruma i / lub może zapewnić dodatkowy wgląd?

Nie różni się to od sposobu, w jaki przeprowadzamy niektóre procesy scrum. My

1. Oszacuj historie u góry zaległości w „punktach historii”
2. Wybierz / wyjaśnij historie na podstawie punktów, które naszym zdaniem „nadrobią” sprint
3. Podziel historie na bardziej szczegółowe zadania techniczne
4. Oszacuj zadania techniczne i porównaj je z pierwotnym oszacowaniem punktów fabuły (wiemy w przybliżeniu, ile czasu rozwoju zwykle odpowiada punktowi opowieści)

Ale chcesz wiedzieć, dlaczego oceniamy dwa razy!

• Dokonujemy przybliżonej oceny (na podstawie historii), ponieważ lubimy być w stanie przewidywać, co może się wydarzyć w następnym sprincie, a może nawet później. Ostatecznie kierownictwo musi być w stanie komunikować się z klientem o prawdopodobnych skalach czasowych, więc jeśli nie będziemy mieli takiej przybliżonej skali, długoterminowe planowanie jest praktycznie niemożliwe.
• Oczywiście oznacza to, że dokonujemy przybliżonych szacunków dla więcej niż tylko bieżącego sprintu. Ponieważ nie ma gwarancji, że kolejność zaległości nie zmieni się na następny sprint, nie chcemy poświęcać czasu na dokonywanie podziałów zadań i dokładnych oszacowań, dopóki nie będą one konieczne.
• Rozbijamy zadanie, aby upewnić się, że wszystkie zadania zostały wyliczone i że historie można łatwiej opracowywać równolegle.
• Dokonujemy drobnych oszacowań (w zależności od zadania), ponieważ daje to nam znacznie płynniejszy wykres wypalenia (szczególnie tam, gdzie nie ma łatwego sposobu na podzielenie dużej historii na realne „funkcje”).
• Ponieważ robimy obie rzeczy, działają one wzajemnie jako kontrole poczytalności - dzika rozbieżność wskazuje, że potrzebujemy błędu w miejscu, które musimy zidentyfikować. Jest to przydatny produkt uboczny, ale nie sam w sobie powód, dla którego oceniamy „dwa razy”.

Ponownie czytając twoje pytanie i komentarz, widzę, że istnieją pewne różnice między naszym przepływem pracy a twoim.

• Robimy awarie jako zespół , chociaż okazuje się, że koszty ogólne są większe, dyskusja techniczna, którą otrzymujemy, jest często bardzo cenna i może wykryć niedociągnięcia w naszej historii. Gdy mamy rozbieżności w doświadczeniu, wiedzy lub umiejętnościach, dyskusja dotyczy również osób z większą liczbą osób, które mogą pomóc tym, którzy mają mniej (bardzo przydatne w przypadku nowych pracowników).
• Szacujemy na poziomie zadania jako zespół , jednym z powodów, dla których działa „planowanie pokera”, jest zjawisko „mądrości tłumów” - jak wspominam w komentarzach, szacowanie zadania w tym miejscu powinno zająć mniej niż 30 sekund , więc koszty ogólne są znikome.

To brzmi jak powód, dla którego twój zespół dokonuje podziałów zadań, a szacunki zadań mają na celu sprawne wypalenie - co jest w porządku, to wszystko polega na monitorowaniu postępu sprintu i umożliwieniu scrum-masterowi wczesnego wykrywania i rozwiązywania problemów. Jeśli chcesz uzyskać te informacje, musisz dokonać podziału i oszacowań, a najpierw musisz to zrobić.

Moim zdaniem przełączanie zadań raczej nie będzie dla ciebie problemem, nie sądzę, że podział różnych zadań jest tak naprawdę przełączaniem zadań w tym samym sensie, że przełączanie z jednej funkcji na drugą jest przełączaniem zadań . Myślę, że zrozumienie ogólnej „architektury” sprintu jest prawdopodobnie dość przydatną rzeczą.

Myślę jednak, że mogą istnieć inne problemy, które możesz rozważyć. Jak zawsze w przypadku agile, powinieneś zidentyfikować problem i zaproponować rozwiązanie , a następnie zdecydować, czy Twoje rozwiązanie działało z mocą wsteczną . Jest to sedno budowy zwinnego rozwiązania, które działa dla Twojej firmy i zespołu. Tak, pewne problemy ty może mieć:

• Robisz awarie indywidualnie - jak więc twoi młodsi / niedoświadczeni członkowie zespołu uczą się od starszych członków zespołu? Pewnie, prawdopodobnie prawdopodobnie nauczą się wszystkiego sami - ale nauczą się szybciej, jeśli otrzymają mentoring. Czy młodsi członkowie zespołu długo się psują? Czy w dłuższej perspektywie popełniają błędy lub brakuje rzeczy, które kosztują czas zespołu? Załamanie się jako zespół może tutaj pomóc.
• Szacunki przeprowadzasz indywidualnie - to samo dotyczy pierwszego punktu, ale czy te szacunki są mniej dokładne niż mogłyby być?
• Wygląda na to, że zadania są przydzielane na początku sprintu, ale jeśli tak, to ile kosztujesz je, gdy musisz zmienić przypisanie? Jeśli ktoś pozostaje w tyle lub choruje, jak łatwo jest komuś odebrać swoje zadania? Czy muszą przejść przez podziały zadań i starać się je zrozumieć bez przerywania pierwotnemu cesjonariuszowi? Jeśli załamiesz się i ocenisz jako zespół, wszyscy powinni mieć możliwość pracy nad wszystkim!
• Czy twoje historie są zbyt duże? Jeśli podział zajmuje 50% czasu, historie brzmią, jakby były bardzo zaangażowane - być może można je zmniejszyć? Nasze historie przechowujemy w ciągu 1-osobowego tygodnia pracy.
• Czy twoje zadania są za małe? Jeśli spędzasz dużo czasu na tworzeniu list zadań, może wpadasz w zbyt wiele szczegółów? Zazwyczaj wykonujemy zadania o wartości od 1 do 8 roboczogodzin, aby w ciągu dnia wszyscy robili postępy w raportowaniu podczas następnego codziennego zajęcia.

Jeśli w taki sposób Twoja firma chce prowadzić rozwój i zakończy dyskusję, masz ograniczone możliwości wyboru lub przynajmniej ryzykujesz zdenerwowanie ludzi.

Biorąc pod uwagę, że ostatecznym celem agile jest działające oprogramowanie wartościowe, możesz spróbować zaoferować pomoc, mierząc zdolność swojego zespołu do dostarczania (punkty dostarczone / oszacowane, błędy w sprincie, liczba testów, pokrycie kodu, czas działania, wygenerowana sprzedaż - cokolwiek). Przygotuj się na wszystkie wyniki - być może taki sposób pracy działa na nie, nawet jeśli nie ma dla ciebie sensu. Jeśli masz rację, marnotrawstwo stanie się oczywiste.

Uważaj na następujący proces ze względu na proces - to marnuje czas i nadal dostarcza słabe produkty. Dobry, zwinny zespół eksperymentuje, mierzy i uczy się. Najlepszym sposobem zmiany zachowania bez popadania w opinię są decyzje oparte na dowodach.

To też moja opinia. Proponuję spróbować samemu i zmierzyć wynik - zobacz, co tam zrobiłem :)

Zakładam, że twój start sprintu oznacza spotkanie planowania sprintu. Myślę, że twój Scrum Master źle zinterpretował, jak powinno przebiegać to spotkanie. Nie tylko decydujesz, które historie opracować, ale również testujesz je w swoim zespole pod kątem jego definicji gotowości, aby upewnić się, że niczego nie umknie (zwykle za pomocą INVEST ), a także podzielisz te historie na zadania. Cytując Mike'a Cohna (jednego z założycieli Scrum Alliance);

Backlog sprintu to kolejna informacja wyjściowa z planowania sprintu. Rejestr zaległości sprintu to lista elementów zaległości produktu, które zespół zobowiązuje się dostarczyć, oraz lista zadań niezbędnych do dostarczenia elementów zaległości produktu. Każde zadanie w zaległościach sprintu jest również zwykle szacowane.

Tak więc dzielenie się historiami i ich szacowanie jest częścią sesji planowania sprintu; nie po zakończeniu sesji planowania, a nie indywidualnie.

Aby uzyskać więcej informacji, nasz przepływ pracy podczas spotkania planowania sprintu jest następujący:

1. bierzemy historię z góry zaległości produktu i dzielimy ją na zadania. Zasadniczo jedno zadanie powinno być zazwyczaj mniejsze niż jeden dzień.

2. Oceniamy historię na podstawie zadań, które odjęliśmy. Jeśli historia okaże się duża, staramy się podzielić ją na mniejsze historie.

3. Płucz i powtarzaj, aż osiągniemy sumę szacowanych punktów

W przeciwieństwie do tego, co mówi Cohn, stwierdziłam, że nie ma potrzeby rzeczywistej oceny każdego z zadań osobno, ponieważ zadania mają być mniejsze niż jeden dzień. Biorąc pod uwagę, że zadania są mniejsze niż jeden dzień pracy, możesz łatwo zauważyć podczas Daily Standup, gdy zadanie trwa dłużej niż oczekiwano, ponieważ osoba pracująca nad danym zadaniem powie, że nadal nad nim pracuje.

Podczas sprintu zespół przegląda historie, a na koniec powinien zastanowić się, ile naprawdę zostało zrobione. Po to jest retrospektywne spotkanie Scrum. Jeśli na stole są wciąż historie, możesz wywnioskować, że twoje oszacowanie było zbyt optymistyczne i zastosować się do nich na następny sprint. Ewentualnie mogły wystąpić pewne incydenty, które miały wpływ na to, ile wykonałeś, itp. Przekonasz się, że szacunki stają się lepsze w miarę upływu czasu.

„przy książce” - to twój problem. Topisz się w procesie większym niż w przypadku wodospadów.

Nie ma „książki” dla Agile, jest tylko zwinny manifest, który mówi „załatw rzeczy bez narzutów”. Tak więc, jeśli szacujesz rozmiary, a następnie dzielisz historie na zadania, aby je ponownie oszacować, to jest to bezcelowy narzut procesu, który należy usprawnić - na tym polega zwinność. Scrum i wszystkie inne są naprawdę wskazówkami, jak zacząć zwinnie. Robiąc to, powinieneś zidentyfikować te punkty, które nie mają sensu lub nie pomagają Twojemu zespołowi pracować bardziej efektywnie, i powinieneś je zmienić.

Jednak niektórzy ludzie uważają, że zakazane metody pracy muszą być napisane w kamieniu i nigdy nie odstępować, bez względu na to, jak głupie się stają. Spróbowałbym podzielić historie na zadania przed spotkaniem scrum - mówisz, że programiści są zobowiązani do przejrzenia każdej historii, cóż, oto szansa na podzielenie historii w tym samym czasie w ramach recenzji. Następnie możesz zadeklarować zadania składające się na historię na spotkaniu scrumowym (nie przydzielaj im czasu!) I pozwól, aby ludzie zdecydowali, jak duży jest pakiet roboczy, na podstawie zawartych w nim dodatkowych informacji (co nigdy nie jest złe, świadome podejmowanie decyzji jest znacznie lepsze niż zgadywanie, a można tego dokonać tylko wtedy, gdy masz informacje potrzebne do podjęcia decyzji).

Po spotkaniu nadal możesz przypisywać czasy do zadań (chociaż nie rozumiem sensu, sprinty nie są oparte na czasie, są oparte na „ile rzeczy oczekujesz”, mierzonych w punktach opowieści , a nie czas. Jest to powszechny problem z scrumem, punkty nie oznaczają czasu, ale musisz ukończyć, powiedzmy, 20 punktów na dwa tygodnie, a zatem 2 punkty = 1 dzień pracy. To powinno być szybkie zgadnięcie, ile zadań postawić w sprincie, abyś nie był ani przeciążony, ani przepracowany, nie tyle, ile faktycznie zostanie zrobionych. Najlepsze sprinty to te, które mają jeszcze kilka zadań, co pokazuje, że oszacowałeś doskonale. Wykonanie każdego zadania pokazuje, że ludzie albo rzucili się na ostatnie opóźnione ukończenie ich na końcu - żadne nie jest produktywne).

Krótko mówiąc - wydrukuj kopię Manifestu Zwinnego i wersję przeciw zwinną . Założę się, że robisz więcej anty-zwinności. Scrum zwykle taki jest. Jedynym sposobem, aby to naprawić, jest zaangażowanie się w zespół i uzyskanie wpisowego na zmianę. Nie pozwól, aby kierownictwo powiedziało ci, jak ma działać Twój zespół, to też nie jest zwinne, a to zostanie zapisane w Księdze.

W którymś momencie każdego sprintu powinieneś odbyć spotkanie w celu dopracowania rejestru produktów . Na tym spotkaniu upewniasz się, że górna część Backlogu Produktu jest wystarczająco podzielona, ​​aby elementy z tej części mogły zostać dodane do następnego Backlogu Sprintu.

Jeśli zarządzanie zaległościami produktu jest dobrze zarządzane, spotkanie planowania Sprintu może być bardziej wydajne. W idealnym przypadku pozwoliłoby to programistom na „chętne dzielenie się” historiami po uruchomieniu Sprint.

Jeśli elementy rejestru produktu zostaną dodane do rejestru sprintu przed wystarczającym podziałem na realistyczne oszacowanie, utrudni to podejmowanie dobrych decyzji dotyczących tego, co dodać do sprintu.