Jak radzić sobie z planowaniem sprintu trwającym zbyt długo?


14

Spędziłem ponad 5 godzin w planowaniu sprintu na tygodniowy sprint. To wydaje się za dużo.

Omawiamy szczegółowo kwestie związane z planowaniem sprintu, ponieważ większość członków zespołu nie jest starsza. Jeśli tego nie zrobimy, doprowadzi to do błędów podczas wdrażania i przeprojektowania podczas sprintu.

Jak sobie z tym poradzić?

Ile szczegółów powinienem omówić podczas planowania, aby dopasować go do zaledwie 2 godzin tygodniowego sprintu?


2
Co dokładnie robisz w planowaniu sprintu? Czy dzielisz historie, dopracowujesz wymagania, projektujesz, oceniasz?
Liath,

1
Dzięki, zapomniałem powiedzieć. Większość czasu spędzamy na projektowaniu.
b.ben

1
Czy robisz pielęgnację zaległości na osobnym spotkaniu? Zazwyczaj dbanie o zaległości timeboxu do 1 godziny na sprint i planowanie sprintu do 1 godziny na sprint. Działa to dobrze na nasze 2-tygodniowe sprinty.
Berin Loritsch,

4
@ b.ben, ale „projektowanie” nie jest częścią planowania sprintu.
Thomas Junk

2
eee czekaj, dlaczego mówisz o implementacji podczas planowania sprintu? Planowanie sprintu polega na tym, co nie jak .
candied_orange

Odpowiedzi:


20

Masz rację - 5 godzin w Planowaniu Sprintu na 1 tydzień Sprint wydaje się długi. Scrum Guide wyznacza przedziały czasowe Planowania Sprintu do 8 godzin przez 1 miesiąc Sprintu i mówi, że „w przypadku krótszych Sprintu wydarzenie jest zwykle krótsze”. Jeśli weźmiesz pod uwagę stosunek, dobrym celem może być 2 godziny planowania sprintu na 1-tygodniowy sprint, ale nie ma ustalonego timeboxu.

Jak więc poradzić sobie z długim planowaniem sprintu?

Jako Scrum Master podjąłbym następujące kroki:

Po pierwsze, chciałbym współpracować z właścicielem produktu, aby upewnić się, że rejestr produktu jest odpowiednio zamówiony. Skuteczne udoskonalanie backlogu i planowanie sprintu jest niezbędne, aby upewnić się, że najważniejsze prace i ich zależności znajdują się na szczycie backlogu produktu, dzięki czemu zespół Scrumowy może skoncentrować się na określeniu, udoskonaleniu i przygotowaniu właściwej pracy.

Po drugie, upewnię się, że zespół spędza wystarczająco dużo czasu na ulepszaniu zaległości. Przewodnik Scrumowy wskazuje, że działania udoskonalające zwykle zajmują nie więcej niż 10% zdolności zespołu programistów. Na przykład 4-osobowy zespół programistów pracujący w standardowym 40-godzinnym tygodniu powinien zaplanować około 16 godzin wyrównywania zaległości. Można to zrobić indywidualnie, w małych grupach lub jako zespół. Przekonałem się, że zaplanowanie sesji doskonalenia zaległości dla zespołu, a następnie wybranie się na badania, dochodzenie lub planowanie zwykle działa najlepiej.

Po trzecie, upewnij się, że zespół zdaje sobie sprawę z tego, że nie musi dokładnie dopracowywać wszystkich szczegółów w planowaniu sprintu. Celem planowania sprintu jest opracowanie planu realizacji celów sprintu. Nie próbuj robić dużego projektu z góry podczas sesji planowania sprintu. Dowiedz się, w jaki sposób dopasowuje się praca, zależności i cele, i wykorzystaj czas poza sesjami planowania sprintu z odpowiednimi osobami do wykonania projektu, wdrożenia i testowania wymaganego do wykonania pracy.

Więcej kroków może z nich wyniknąć, ale byłby to dobry punkt wyjścia.


3
Zasadniczo zespół nadal spędza tę samą liczbę godzin na spotkaniach. Po prostu nazywamy je różnymi spotkaniami. :) Potrzeba wszystkiego, aby załamać wszystko na tyle, aby zespół mógł swobodnie oceniać pracę i być niezależnym, gdy przychodzi czas na wykonanie pracy.
Greg Burghardt,

5
@GregBurghardt: OP pisze, że spędzają większość czasu na projektowaniu. Cały zespół pracuje więc nad projektem każdej historii. Jeśli podzielisz to, aby tylko część zespołu pracowała nad każdą odpowiednią historią, skrócisz całkowity czas spędzony na spotkaniach.
Michael Borgwardt,

Re: „Upewnij się, że zespół zdaje sobie sprawę, że nie musi poprawnie wyszczególniać każdego szczegółu w planowaniu sprintu”: A, co ważniejsze, upewnij się, że to prawda , że nie musi on odpowiednio dostosowywać każdego szczegółu podczas panoramowania sprintu .
ruakh

@GregBurghardt Być może. Istnieje jednak różnica między całym zespołem przebywającym w pokoju przez 5 godzin a różnymi kombinacjami osób niepracujących przez 3 godziny po 2-godzinnej sesji planowania.
Thomas Owens

5

Słyszę cię. To za długo, aby wydać! Mamy nadzieję, że Twój zespół omawia to w twoich retrospektywach. Próbowaliśmy kilku eksperymentów z mieszanymi wynikami:

  1. Każdy tworzy projekt wysokiego poziomu na jednym bilecie i przekazuje go w lewo lub w prawo wokół stołu w celu rewizji, a następnie grupowy przegląd planu dla każdego biletu. Nie wszystkim to się podobało, ale zmusiło to naszych juniorów do spróbowania. Niektóre osoby w zespołach są całkiem zadowolone, że pozwalają innym myśleć i postępują zgodnie z instrukcjami. Z drugiej strony nasz eksperyment zmusił wszystkich do skonfrontowania się z brakami wiedzy, co stanowiło wyzwanie dla młodszych. Z drugiej strony, nie wszyscy lubią być na miejscu i niekoniecznie skracają czas na spotkaniu. Kolejny!

  2. Próbowano sparować projekty. Grupy dwu- lub trzyosobowe rozkładałyby bilet na zadania. Cały zespół przejrzy powstałe plany. Poszło znacznie szybciej, ale niektóre mini-strąki miały ten sam problem z jedną osobą jadącą razem, podczas gdy druga pracowała nad projektem.

  3. Pomiń podział zadań. Uznaliśmy, że nasze punkty historii są uśrednione, więc marnowaliśmy czas, próbując zaangażować cały zespół we wszystko. W rezultacie mieliśmy znacznie krótsze spotkania planistyczne, ale prace projektowe były czymś, co nasze pary musiały zrobić dla siebie, kiedy zaczęły kupować bilet. Jeśli juniorzy pracują nad biletem, spodziewaj się, że będą potrzebować pomocy, aby przejść ten krok. Jeśli spróbujesz tego, zaakceptuj mniej historii w sprincie, dopóki nie poczujesz się komfortowo. Upewnij się również, że „bezpiecznie” dla kolegów z zespołu jest prośba o pomoc, gdy czegoś nie wiedzą.

Ostatecznie sprowadza się to do dojrzałości zespołu. Ludzie muszą rozumieć nawzajem swoje umiejętności i preferencje oraz mieć pewność, że członkowie drużyny będą prosić o wkład, gdy będą go potrzebować. Napraw je najpierw, jeśli ich nie masz. Wtedy rozwiązanie problemu nieefektywnych spotkań staje się łatwiejsze.


4
Opcja nr 3 obejmuje zespoły, które polegają na jednej osobie lub małej grupie ludzi. Jeśli tej osoby lub osób nie ma w pobliżu, prędkość zespołu spada bezpośrednio do toalety. Robiłem to z naszym zespołem i za każdym razem, gdy ta osoba wyjeżdżała na wakacje, pojawiał się chaos. Nic się nie stało. Następnie kierownik zespołu spędził 3 tygodnie próbując uspokoić zarządzanie projektami. Jeśli pracujesz w zespole z młodszymi lub nie ekspertami, zdecydowanie nie polecam nr 3. Jeśli masz wszystkich ekspertów (a tak naprawdę są ekspertami) # 3 może być oszczędnością czasu.
Greg Burghardt,

Jeśli ta osoba po prostu wykonuje zadanie projektowania dla wszystkich, jasne, zgadzam się. Ale co, gdyby ta osoba pomagała ludziom w lepszym wykonywaniu tego samodzielnie?
Jason Zinschlag,

2
Z mojego doświadczenia wynika, że ​​nie poprawia się, gdy ktoś prowadzi ich przez różne rzeczy. Okazuje się, że doświadczeni ludzie robią to dla mniej doświadczonych, ponieważ mniej doświadczeni zajęli rzędy wielkości dłużej. Mieliśmy więcej szczęścia, siedząc w pokoju i wykonując zadania programistyczne. Nawet przechodzenie przez kod - ale nie podczas planowania sprintu. Nazywamy to „pisaniem zadań programistycznych”, ponieważ tego potrzebował nasz zespół. Potem zaczęli stawać się niezależni i stawali się coraz lepsi w pisaniu zadań deweloperskich.
Greg Burghardt,

Cieszę się, że Twój zespół znalazł sposób. Czy uważasz, że twoi doświadczeni koledzy z drużyny wybierali łatwe wyjście? Wiem, że uczenie ludzi to ból głowy. Ale opłaca się duże dywidendy. Większość ludzi nie ma na to cierpliwości i widzę dokładnie to, co opisujesz - doświadczeni ludzie mogą łatwo stracić cierpliwość w procesie i „zrobić to sami”. Ponadto juniorzy muszą być dobrymi uczniami.
Jason Zinschlag,

@GregBurghardt Ciężko zrobiliśmy coś takiego jak „pisanie zadań deweloperskich” podczas planowania sprintu. I nie jestem pewien, czy to w porządku?
b.ben

3

Podoba mi się odpowiedź otrzymana od @ Thomas-Owens, ale dodam jeszcze jeden przedmiot. Czy zastanawiałeś się nad robieniem programowania par w ramach implementacji Agile?

Programowanie w parach pomogłoby w (1) nauczeniu niektórych młodszych programistów, jak pisać lepszy kod i (2) w programowaniu parami, nie zawsze musisz mieć wszystkie funkcje projektowe określone dla ciebie w planowaniu sprintu. Gdy para działa razem, niektóre z tych decyzji projektowych mogą być podejmowane „spontanicznie” z dodatkowymi korzyściami programowania par.

Jeśli możesz pomóc młodszym programistom uczyć się szybciej i wiesz, że o elementach projektu, które nie zostały uwzględnione w Planowaniu Sprintu, zadecydują dwie osoby, nie ma powodu, dla którego nie byłbyś w stanie skrócić czasu, który spędzasz w przyszłe planowanie sprintu


Tak, właśnie tego chciałem. Ale nasz zespół nie ma wystarczającej liczby osób starszych, aby to zrobić. Wpadłem na pomysł, który pozwoli wszystkim członkom zespołów pisać własne abstrakty i interfejsy, zanim zacznę wdrażanie, umów się na spotkanie wszystkich programistów. Co myślisz?
b.ben

1
@ b.ben Ale twój zespół nigdy nie będzie miał wystarczającej liczby seniorów, dopóki tego nie zrobisz. To część siły programowania par. Musisz się do tego zobowiązać.
Nieznany Coder,

1

Nie jestem miłośnikiem Scruma i mam tylko rok praktycznego doświadczenia. Tak więc należy czytać z ziarnem soli.

Widzę kilka czerwonych flag w tym, co piszesz:

5 godzin planowania sprintu

To zdecydowanie za długo na tygodniowy sprint.

Celem planowania sprintu jest AFAIR

  • umożliwić zespołowi poznanie bieżących priorytetów i
  • opracować plan bitwy na nadchodzący sprint.

Aby to zrobić skutecznie, każda ze stron musi zrozumieć Product Backlog items.

Aby zrozumieć Product Backlog itemszaległości, zaległości muszą być w dobrej formie.

W fazie planowania konkretnego Product Backlog itemssą przekształcane w Sprint Backlog items.

Jedną z możliwych przyczyn jest to, że te elementy nie są wystarczająco wyjaśnione / dopracowane.

Inną możliwą przyczyną jest to, że przedmioty są zbyt złożone i pozostawiają miejsce na zbyt wiele interpretacji.

Omów bardzo szczegółowo planowanie sprintu

Jak wspomniano powyżej, faza dyskusji będzie krótsza, gdy elementy będą bardziej konkretne.

Z drugiej strony: planowanie sprintu oczekuje profesjonalnego zachowania od każdego uczestnika. Obejmuje to unikanie dyskusji o rowerach .

Być może wszystko jest jasne, ale ktoś zaczyna dyskusję na temat jazdy rowerem .

Więcej: Unikaj dyskusji na temat szczegółów implementacji . Chociaż każdy pomysł kończy się w kodzie w pewnym momencie, nie ma sensu dyskutować o planowaniu sprintu, czy prosta tablica zrobi lewę, czy lepiej będzie użyć połączonej listy.

Ponieważ większość członków zespołu nie jest starszych

W scrumie nie ma różnicy między seniorami a juniorami . Obaj są tylko programistami. Jest to dobry punkt wyjścia, który pomaga skoncentrować dyskusję na realnym rozwiązaniu popartym lepszymi argumentami, a nie wypłatą.

Błędy implementacji i przeprojektowania podczas sprintu

Wydaje się, że podstawowym problemem jest gromadzenie wymagań, a następnie bardzo niejasne zaległości produktowe.

Jak powiedziałem powyżej: tak długo, jak długo Product Backlogjest w dobrej formie, trudno nie zauważyć sedna sprawy.

Nie wyobrażam sobie takiej sytuacji jak:

»Jako użytkownik chcę zobaczyć garstkę klientów!«

»Och, nie miałeś na myśli każdego z naszych 2 milionów klientów?«

OTOH: Co w tym kontekście oznacza przeprojektowanie ? Jeśli programista wybrał algorytm o niskiej wydajności, to jest kolejny cel jasny: wybierz lepszy. Ale to nie jest „przeprojektowanie”, to jest optymalizacja.


Do twoich głównych pytań:

Jak sobie z tym poradzić?

Wspomnienie jest trywialne, ale i tak to robię: nie zapominaj, że masz do czynienia z ludźmi .

Bardzo trudno jest mieć grupę różnych umysłów, które są w stanie dzielić wspólne koncepcje (jak w Rashomon ). Aby skutecznie sobie z tym poradzić, używaj jak największej nadmiarowości w swojej komunikacji: np. Wyjaśniaj obszerny kontekst przedmiotu, nawet jeśli wszyscy „powinni wiedzieć”, co robić. Zadawaj pytania, czy wszyscy rozumieją temat danego przedmiotu.

Jeśli planujesz grać w pokera, dobrym wskaźnikiem, czy zrozumienie jest wystarczające, jest to, że zadania są oceniane jako niskie. Niska oznacza niską złożoność oznacza łatwą do zrozumienia i trudną do przeoczenia.

Jednym z efektów ubocznych iteracji jest wzrost liczby określonych zadań (ponieważ zespół rozumie swoje możliwości i ukryte zawiłości). Następnie istnieje szansa na podzielenie przedmiotu na kilka mniej złożonych przedmiotów o mniejszej złożoności.

Ile szczegółów powinienem omówić podczas planowania, aby zmieścić 2 godziny tygodniowo w sprincie?

Odpowiedź Salomonowa: jak najmniej i tyle, ile potrzeba, ale nie więcej.

tl; dr

  • Wybierz łatwy język (jeśli to pomaga, użyj prostego angielskiego lub ELI5), aby uniknąć nieporozumień

  • Popraw zbieranie wymagań

  • Popraw zaległości

  • Zwiększenie zaufania członków zespołu do ich indywidualnych możliwości, a także ich możliwości jako zespołu

  • Unikaj jazdy rowerem

  • Popraw dyscyplinę osobistą

  • Być może używaj stałych timeboxów do każdego przedmiotu do dyskusji

  • scrum masterSkutecznie wzmocnij pozycję moderatora.


-2

Udało nam się znacznie skrócić czas planowania spotkania, przygotowując łącznie trzy godziny w ciągu 2 tygodni sprintu. Pielęgnację dzielimy na cztery sesje. my robimy 30 min pielęgnacji w poniedziałek i 1 godzinę pielęgnacji w środę co tydzień. Nasze sprinty zaczynają się w poniedziałek i kończą w piątek. W rezultacie mamy dobre informacje ze spotkań dotyczących pielęgnacji, które przyczyniają się jako wkład w planowanie, co czyni go krótszym. Naszym najlepszym rekordem było spotkanie planistyczne o długości 30 minut w jednym z naszych sprintów. W większości przypadków nie zajmuje to więcej niż godzinę do godziny i 30 minut. Mimo to wciąż jest ograniczony czas, ale planowanie zostało wykonane bardzo wcześnie.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.