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?

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.

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.

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

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.

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.