Nasze spotkania dotyczące planowania sprintu nie tylko są zabawne, ale wręcz przerażające.

Spotkania są nużące, nudne i trwają wiecznie (dzień, ale wydaje się, że jest o wiele dłużej).
Deweloperzy narzekają na to i obawiają się nadchodzących planów.

Nasza rutyna jest dość standardowa (historia użytkownika wstawiana do rejestru sprintu według priorytetu >> historia jest dzielona na zadania >> zadania są szacowane w godzinach >> powtarzanie) i nie mogę zrozumieć, co robimy źle.

Jak sprawić, by spotkania były przyjemniejsze?

...

Kilka dodatkowych informacji w odpowiedzi na prośby o dodatkowe informacje:

Dlaczego elementy zaległości nie są wstawiane i nadawane im priorytety przed rozpoczęciem sprintu?

Historie użytkowników są rzeczywiście traktowane priorytetowo; nie mamy pojęcia, ile potrwa, dopóki nie podzielimy ich na zadania! Z (doskonałych) odpowiedzi tutaj widzę, że może nie powinniśmy w ogóle szacować zadań, tylko historie użytkowników. Powodem, dla którego oceniamy zadania (a nie historie), jest to, że błędnie oceniamy historie - ale sądzę, że jest to temat zupełnie innego pytania.

Dlaczego deweloperzy narzekają?

1. Spotkania są długie.

2. Spotkania są monotonne. Historia po historii, zadanie po zadaniu, walka (tak, walka), aby oszacować, ile czasu to zajmie i na czym to polega.

3. Szacowanie zadań sprawia, że ​​szacowanie historii użytkownika wydaje się bezcelowe.

4. Im dłuższe spotkanie, tym mniej skupienia w pokoju. Im mniej skoncentrowani są koledzy, tym dłużej trwa spotkanie. Powstaje rekurencyjna spirala nienawiści. Rozważaliśmy podzielenie spotkania na dwa dni, aby skupić uwagę ludzi, ale programiści nie chcieli o nim słyszeć. Jeden dzień planowania jest wystarczająco zły; teraz będziemy mieć dwa ?

Częścią naszego problemu jest to, że wchodzimy w bardzo małe szczegóły (w celu uzyskania dokładniejszych szacunków). Ale kiedy z grubsza oceniamy, idziemy daleko od celu!

Podsumowując pytanie:

• Co robimy źle?

• Jakie są dodatkowe sposoby, aby spotkanie było ogólnie przyjemniejsze?

Ułatw oszacowanie

Przerwij planowanie sprintu.

Czy potrzebujesz oszacować poszczególne zadania? Planowałem sprint na dwa sposoby:

1. Opowieści są szacowane w punktach opowieści, a następnie zadania w godzinach
2. Historie są szacowane w punktach fabularnych, a zadania po prostu mieszczą się w tym bez szacunku

Z tych dwóch wolę drugą opcję. Uważam, że brak szacowania zadań daje programistom więcej swobody w radzeniu sobie ze zmianami. Jeśli zadanie nie ma już sensu (ile razy dowiedziałeś się, że zadanie nie ma zastosowania lub zostało już wykonane w poprzednim sprincie), po prostu je wyrzucisz bez kary lub być może będziesz musiał zmienić bieżące zadanie na coś nowego, być może zerwanie. Naprawdę jesteś zbędny, jeśli oszacujesz oba, ponieważ suma zadań powinna reprezentować punkty fabularne i odwrotnie. Jaką wartość tak naprawdę zyskujesz, gdy nie wiesz, ile czasu zajmie wykonanie poszczególnych zadań? Jeśli znajdziesz się w rozmiarach zadań, które naprawdę różnią się na tyle, aby coś zmienić, sugerowałbym podzielenie tych zadań na mniejsze, bardziej jednorodne części.

W ten sposób możesz skrócić czas poświęcony na planowanie sprintu . Historie są szacowane podczas planowania sprintu, a kiedy zaczynasz sprint, możesz odłożyć wszystkie zadania, które możesz wymyślić, które składają się na tę historię. Oczywiście, jeśli są jakieś punkty, które napotykasz przy szacowaniu historii, o których wiesz , że będą musiały zostać rozwiązane w zadaniu, możesz dodać to do informacji o historii i ustawić jako zadanie.

Oszacuj w jednostkach idealnych

Punkty fabularne mają być w idealnych jednostkach, takich jak idealne godziny pracy lub idealne dni pracy. Oznacza to, że biorąc pod uwagę idealny dzień każdego dnia, w którym nie było żadnych przerw, spotkań i wszystko przebiegło zgodnie z planem, zadanie można było wykonać w X dni. Teraz wszyscy wiedzą, że to po prostu nieprawda, ale wspaniałą rzeczą w statystykach jest to, że nie musi tak być.

Rozumiem przez to, że po pewnym czasie oszacowania ich w idealnych dniach zdajesz sobie sprawę, że ukończenie historii może zająć dodatkowe 25% szacowanego czasu. Powiedzmy, że oszacowałeś 4 idealne dni robocze, a zamiast tego zajęło ci to 5. Z biegiem czasu śledzisz to, a następnie masz przybliżone wyobrażenie o konwersji z dni idealnych na rzeczywiste. Twoim pierwszym instynktem byłoby próba zrekompensowania tego poprzez przeszacowanie, a prawdopodobnie pomylisz się. Najważniejsze, aby zachować spójność. W ten sposób Twoja długoterminowa średnia pozostanie taka sama. Pewnie, czasem będzie pod spodem, a czasem się skończy, ale im więcej oszacujesz, tym lepiej. Jeśli okaże się, że nadal nie można uzyskać przyzwoitej oceny, może to oznacza, że ​​nie wiesz wystarczająco dużo o historii, aby ją właściwie oszacować.

Porozmawiaj o historiach

Kiedy oceniasz, wszyscy powinni mieć ogólne pojęcie o tym, co trzeba zrobić od początku do końca, co trzeba zrobić, aby ta historia została ukończona. Nie musisz znać każdego szczegółu, ale na tyle, abyś myślał, że sam możesz podjąć się tej historii. Jeśli nie masz takiego poziomu pewności, prawdopodobnie nie powinieneś go szacować. Jeśli powiesz „Cóż, ta historia jest zbyt duża, abyśmy mogli poznać większość szczegółów”, oznacza to, że historia jest zbyt duża i powinna zostać podzielona. Historie, przynajmniej z mojego doświadczenia, były na tyle małe, że jedna osoba, jeśli zajdzie taka potrzeba, mogłaby nad nimi pracować sama i osiągnąć to w ciągu tygodnia lub dwóch.

Pomoże to również rozwiązać drugi punkt w edycji, który jest zbyt dużym szacunkiem . Zamiast szacować każde zadanie dla każdej historii, po prostu oceniasz historię jako całość, co powinno pomóc w usunięciu dużej części szacunków. Jeśli chodzi o zmniejszenie monotonii spotkań, sugerowałbym planowanie pokera, o którym więcej informacji można znaleźć powyżej.

Spraw, by planowanie było bardziej wciągające

Oszacuj za pomocą Planning Poker

Jeśli chodzi o zwiększanie zadowolenia z wyceny, czy próbowałeś pokera ? W ten sposób zawsze planowałem wszystkie moje sprinty w wielu zespołach i jest to dobry sposób na zaangażowanie wszystkich, ponieważ każda osoba musi przynajmniej wybrać COŚ. Jest też sporo zabawy, gdy wszyscy w drużynie wybierają 3, a ktoś odkłada 20 i musi się wyjaśnić, lub gdy wszyscy w drużynie odkładają 5, ale menedżer odkłada 8 (z kim się kłóci szef, kiedy chce dać ci więcej czasu!).

Aby to zrobić, potrzebujesz jedynie planowania kart pokera , które często wykonujemy na odwrocie kart indeksowych lub przy użyciu normalnych kart do gry z wartościami przypisanymi do kart twarzy. Nic szczególnego, a to skupia wszystkich. Pamiętaj tylko, że próba wykonania dowolnego zadania przez cały dzień (w tym planowanie pokera) ma negatywny wpływ na wydajność. Wiele zestawów kart nie bez powodu jest wyposażonych w kartę do kawy; jeśli ktoś czuje się wypalony, daj drużynie przerwę na doładowanie i podnieś ją, gdy wszyscy będą świezi!

Jako alternatywę dla kart fizycznych możesz także spojrzeć na karty elektroniczne . Prawdziwymi korzyściami są zautomatyzowane śledzenie wyników, śledzenie historii użytkowników do oszacowania i umożliwienie każdemu pokazania swoich kart naraz, aby uniknąć „oszukiwania” (gdy na szacunki jednej osoby mają wpływ inne osoby, ponieważ mogą zobaczyć swoją kartę). Oczywiście wymaga to posiadania komputera i umiejętności skupienia się na zadaniu, więc używaj go według własnego uznania.

1. Dlaczego elementy zaległości nie są wstawiane i nadawane im priorytety przed rozpoczęciem sprintu? Marnowanie czasu programistów nie jest zabawne. Pozwól zespołowi kierowników na kilka dni wcześniej współpracować z właścicielem produktu i kierownikiem projektu, aby nadać priorytet priorytetom. Dotyczy to również planowania, kto jest w każdej drużynie sprintu.

2. Dlaczego dzielenie rzeczy na zadania zajmuje dzień? Jeśli masz zespół o rozsądnej wielkości (2-4 programistów, 0,5-1,5 QA na programistę, 1-2 różne), powinieneś mieć 2-4 historie użytkowników w tym sprincie. Spędź około 30 minut z wyjaśnieniem wymagań właściciela produktu, a następnie około 30 minut, dzieląc go na około 8 godzinne zadania. Nie wprowadzaj zadań podczas spotkania. Po prostu uzgodnij jako zespół, jakie zadania są wystarczające, aby rozsądni ludzie je zrozumieli, kto jest za nie odpowiedzialny, i ile czasu powinni zająć. Zgadzam się, że „jak długo powinny trwać (łącznie z testowaniem)” mieści się wygodnie w sprincie.

3. Jeśli nie chodzi tylko o dzielenie rzeczy na zadania, co jeszcze robisz? Oczywiście retrospektywy mogą potrwać 30–60 minut, ale będą krótsze, gdy zespoły wpadną w groove.

Podsumowując - przestań marnować czas ludzi, a oni będą mniej obawiać się spotkań. Poza tym, zabawa i towarzysze w zespole nie są czymś, na czym można porozmawiać podczas spotkań. Idźcie razem na lunch, żartujcie, mieszajcie ludzi, aby mieć lepsze dopasowanie osobowości, organizujcie konkursy na wąsy ... kiedy morale się poprawi, ludzie naturalnie sprawią, że spotkania planowania sprintu będą bardziej beztroskie.

Planowanie to jeden z obszarów scrum, w którym zespoły mają dużą elastyczność. Wypróbuj coś nowego podczas każdego sprintu, dopóki nie trafisz na coś, co działa dla Twojego zespołu.

Kilka udanych pomysłów, które albo wypróbowałem osobiście, albo słyszałem o nich od innych zespołów:

• Twórz historie użytkowników i ustalaj priorytety bez całego zespołu. Właściciel produktu i / lub Scrum Master mogą poradzić sobie z dużą ilością pracowitej pracy i po prostu pozwolić zespołowi ją poprawić.
• Spraw, aby zaległości były znacznie dłuższe niż pojedynczy sprint. Jego zbudowanie może trochę potrwać, ale jeśli twoje zaległości są wystarczająco długie, planowanie spotkań sprowadza się do wprowadzania drobnych poprawek lub omawiania najnowszych wydarzeń biznesowych.
• Organizuj spotkania szacunkowe oddzielnie od planowania sprintu. Jeśli ludzie uważają, że spotkania są zbyt długie, nie ma powodu, aby ich nie dzielić.
• W szczególności zaplanuj włamania do porządku obrad. Jest to przydatne, jeśli często tracisz czas na czekanie na powrót jednego lub dwóch członków zespołu.
• Przerwij środek spotkania i przydziel każdemu zadanie wykonania jednej lub dwóch historii użytkowników, a następnie spotkaj się ponownie, aby złożyć raport i osiągnąć konsensus.
• Upewnij się, że spotkanie planujące dotyczy tego, co robić, a nie jak to zrobić. Inżynierowie bardzo łatwo wpadają w to drugie. W razie potrzeby zorganizuj osobne spotkania projektowe, na których omawiasz, w jaki sposób.
• Podziel swoje historie na dochodzenie i wdrożenie. Planowanie spotkań często trwa zbyt długo, gdy członkowie zespołu wiedzą zbyt mało o tym, nad czym będą pracować, i starają się to rozgryźć podczas spotkania.
  Na przykład powiedz, że musisz zintegrować się z interfejsem API, z którym Twój zespół nie ma doświadczenia. Zamiast próbować tworzyć prognozy i zadania podczas spotkania planistycznego na temat czegoś, o czym nie masz pojęcia, zrób jedną historię dochodzenia, aby nauczyć się interfejsu API, zrób prostą aplikację „witaj świat” i naucz ją zespołu. Wtedy będziesz przygotowany do zaplanowania rzeczywistej pracy.
• Śledź podczas spotkań konkretne problemy. Nie tylko „planowanie jest nudne”, ale także poziom szczegółowości, „spędzamy dużo czasu na rozmowach o niejasnych wymaganiach i nikt nie wydaje się znać właściwej odpowiedzi”. Następnie omów te konkretne kwestie w swoich retrospektywach i przeprowadzaj burzę mózgów w celu uzyskania konkretnych rozwiązań. Rozwiąż swój problem, dopóki elementy nie będą łatwe do rozwiązania.

Jednocześnie planujemy sprint i retrospektywę i prawie zawsze robimy to w 90 minut, ale jesteśmy jednym z szybszych zespołów. Co 5 sprintów wykonujemy duże długoterminowe planowanie w całej firmie, które zajmuje 4-6 godzin. Oczywiście każdy zespół jest inny, ale jeśli spędzasz cały dzień w każdym sprincie, jest wiele miejsca na ulepszenia.

Twoje sesje planowania są zbyt długie!

Z mojego doświadczenia wynika, że ​​spotkanie w sprawie planowania sprintu nie powinno trwać dłużej niż 2 godziny tygodniowo (np. 2-tygodniowy sprint powinien zająć najwyżej 1/2 dnia), ale udane powinny być krótsze (połowa).

W twoim szczególnym przypadku: dlaczego szacujesz zadania? Podczas planowania należy szacować tylko historie. Zadania mogą być później oszacowane przez konkretnych właścicieli zadań .

Sposób, który zadziałał dla mnie:

• Szybkie wprowadzenie do sprintu przez PO
• Oszacowanie zdolności sprintu
• Historie wyczerpują się i planują grę w pokera (czasowo odtwarzany po 5/10 minut na historię), dopóki nie znajdzie się wystarczająco dużo szacunkowych rzeczy na pokrycie sprintu
• Oficjalne zobowiązanie / prognoza zespołu

Następnie, równolegle / pary / samoorganizacja przy naszych biurkach, zadania i ocena zadań.

W mojej poprzedniej pracy cały pierwszy dzień każdego sprintu (nazywaliśmy je tam iteracjami) obejmował:

• Z mocą wsteczną. Zaczęliśmy robić to po południu ostatniego dnia, ale często szukaliśmy retrospekcji na temat sprintu, a następnie wracaliśmy do pracy, wiążąc ostatnie luźne końce pracy tego sprintu, więc doszliśmy do wniosku, że lepiej jest upewnić się, że praca była już za nami, zanim jeszcze się nad tym zastanowiliśmy. Logiczne wydaje się również konsolidacja całego kosztu spotkania związanego z procesem Scrum, aby pozostałe dni można było zaplanować i spędzić w bardziej idealnych warunkach. Zazwyczaj trwało to 2 godziny.
• Planowanie sprintu. Zaległości zostały oszacowane podczas Milestone Planning Meeting (które może być cały dzień samo w sobie zarówno dla deweloperów, jak i PO), i zostały ustalone priorytetowo przez OP przed rozpoczęciem każdego sprintu. Wyliczyliśmy, ile dni programistów mieliśmy do dyspozycji (uwzględniając wakacje, vaca itp.), Wzięliśmy pracę, którą, jak sądziliśmy, moglibyśmy zrobić na szczycie stosu, i szybko sprawdziliśmy wymagania użytkowników (uprzednio sprawdzone przez nasze licencje), aby uzyskaj pełniejsze zrozumienie tego, co pociąga za sobą praca, niż otrzymaliśmy dzięki prostemu przeglądowi podczas MPM. Zazwyczaj zajmowało to kolejne 2 godziny.
• Planowanie zadań. Znając historie i kryteria akceptacji, podzieliliśmy każdą historię na zadania wielkości kęsa oszacowane w idealnych godzinach (godzina poświęcona wyłącznie na „wykonanie” tego zadania bez rozpraszania uwagi i blokowania dróg). Po skalibrowaniu naszej skali punktowej 5 było sprintem dla programistów, więc 1 mogło być dowolne do dwóch dni dla programistów włącznie. Z tego powodu praktycznie wszystko musiało zostać zepsute, aby członkowie zespołu mogli pokazać postępy na tablicy scrum. To był kolejny 2-godzinny blok, z pewną dawką od tego do następnego elementu.
• Zarys AAT. Nasze PO i BA nie były programistami i nie kodowały. Organizacje producentów ukryły się za umową przewidującą, że spełnią wymagania w formie szablonu Word i będą współpracować z licencjobiorcami w celu dopracowania ich w tej formie. BA zrozumieli kod, ale ich czas był wyłącznie analizą i testami końcowymi (co wymagało istnienia systemu, aby mogli rejestrować swoje makra w Selenium). Aby więc sprawdzić, czy nasz kod spełnia kryteria akceptacji, musieliśmy napisać własne AAT modelujące działania „papierowego” testu akceptacji. Zazwyczaj robiliśmy to w tym samym środowisku NUnit, którego używaliśmy do testów jednostkowych i integracyjnych (wypróbowaliśmy FitNesse i nie mogliśmy zrezygnować wystarczająco szybko). To była reszta naszego pierwszego dnia każdego sprintu i trwała do drugiego.

W mojej obecnej pracy wciąż wdrażamy proces Scrum, nie mieliśmy planu etapowego dla całego zespołu, a większość tego, nad czym pracujemy, nie ma ścisłych kryteriów akceptacji. Zatem nasze planowanie sprintu jest tak samo wyjaśnieniem tego, co pociąga za sobą każda historia i tego, co nazwiemy zrobione, jak zobowiązanie do wykorzystania najlepszych X idealnych godzin pracy poza szczytem. Uciekamy od tego - przynajmniej na razie - ponieważ jesteśmy wewnętrznym zespołem i każdy z nas współpracuje osobiście z użytkownikami końcowymi naszego oprogramowania w celu zebrania wymagań i rozwiązań projektowych. Nawet wtedy planowanie sprintu jest codzienne co drugi poniedziałek, a popołudnie spędza się na usuwaniu osobistych przeszkód, aby móc rozpocząć rozwój we wtorek na poważnie.

Aby faktycznie odpowiedzieć na pytanie PO, zamiast kontrastować z innymi komentarzami / odpowiedziami mówiącymi, że nie powinno to zająć tak długo, istnieją sposoby na zwinne oszacowanie, planowanie sprintu i retrospektywy, które są nieco bardziej interesujące, niż możesz użyć.

W szczególności rozwiązywanie problemów:

• Spotkania są długie - wyznacz im termin. Każde spotkanie, niezależnie od tego, czy jest to retrospekcja, planowanie sprintu, podział zadań itp., Powinno mieć określony cel i temat dyskusji oraz powinno być ograniczone w jak największym stopniu do określonego czasu. Zadaniem Scrum Mastera jest utrzymywanie tych spotkań na dany temat i ciągłe realizowanie celów czasowych.

• Spotkania są monotonne - będzie ich trochę; pracujesz w kawałkach wielkości kęsa, pojedynczo, więc będziesz robić to samo w kółko. Utrzymanie skupienia zespołu i dążenie do osiągnięcia celu spotkania pomoże.

  Coś jeszcze słyszę, że być może twoje spotkania planowania sprintu próbują osiągnąć zbyt wiele. W mojej ostatniej firmie oszacowania historii dokonano na „spotkaniach związanych z planowaniem kamieni milowych”, które odbywały się mniej więcej raz na kwartał i trwały cały dzień. Na tych spotkaniach wszystko, co narosło na zaległościach, których nie oszacowaliśmy, zostało oszacowane w punktach. Jeśli dokonujesz oceny historii w punktach, a następnie oceny zadań w godzinach, nie chcesz robić ich obu w tym samym czasie (być może tego samego dnia).

• Szacowanie historii w punktach, a następnie zadania w godzinach wydają się zbędne - mają dwa różne cele. Celem oszacowania historii jest przybliżone oszacowanie złożoności, którego można użyć do wypełnienia zaległości sprintu na podstawie prędkości w przeszłości i oczekiwanej przepustowości. Celem oszacowania zadania jest podzielenie historii na rzeczy, które wymagają jednego dnia programisty lub krócej (a więc można je przypisać do jednego faceta, od którego oczekuje się, że wszystko to zrobi się na czas) i upewnić się, że nie źle oszacowałeś złożoność jakiejkolwiek opowieści ani nie odgryzłeś więcej niż możesz przeżuć w sprincie.

  Jeśli wszystkie opowiadania zajmą jeden dzień lub krócej, jest to zbędne, ale nie wszystkie skale punktów są skalibrowane jednakowo; w mojej ostatniej pracy 5 to dwa tygodnie deweloperów (ponieważ na początku mieliśmy wiele epickich do oszacowania), które w skali liniowej wskazywały na coś do 2 dni programisty. Biorąc pod uwagę taką skalę, praktycznie wszystko powinno zostać podzielone na zadania. W mojej nowej firmie punkt jest bliższy połowie dnia programisty, więc 1, a nawet 2 to zdecydowanie jej własne zadanie, a 3-8 ma wątpliwości co do zmuszania zespołu do podzielenia go na zadania.

• Istnieje błędne koło, które trwa dłużej, powodując, że ludzie są mniej skoncentrowani, więc zajmuje to więcej czasu. Rób przerwy, tak jak powinieneś być przy kodowaniu. Co 30 minut poświęć 5 minut na rozciągnięcie nóg, przegrupowanie itp. Możesz zrobić to dziesięć minut co godzinę, ale nie pchaj solidnego bloku czasu spotkania zbyt daleko. Twoi faceci mogą być głodni, potrzebować więcej kawy lub przerwy w łazience itp. Nie zaprzeczaj im; jeśli zmusisz ich, by wyssali to, ich myśli wędrują. Poza tym, jak wspomnieliśmy wcześniej, krótkie i słodkie rozmowy na temat również będą pomocne.

Spotkanie planowania Sprint składa się z 2 części:

1. Zdecyduj, co zrobi zespół
2. Zdecyduj, jak zespół to zrobi.

Pierwsza część jest stosunkowo prosta - na podstawie liczby punktów opowieści, które zespół może podjąć, zobowiązanie się do ukończenia tylu opowieści użytkowników w kolejności ich pierwszeństwa. Gotowy.

Druga część jest tym, czym powinni się cieszyć programiści - opracowanie historii i zaprojektowanie rozwiązania. Zadania z tego wypadają. Poproś właściciela produktu lub dowolne dostarczone przez niego MŚP o wyjaśnienie wybranej historii. Następnie poproś dowolnego programistę, aby wziął na siebie prowadzenie dyskusji projektowej. Użyj białej tablicy. Odbijaj pomysły. Baw się dobrze.

To jest naprawdę. Jeśli spotkania projektowe nie są zabawne, oznacza to po prostu coś złego.

Tak, wiem, że to stare pytanie, ale mam nową odpowiedź. : P

Podziel spotkanie.

Nasze spotkanie dotyczące planowania Sprintu podzieliliśmy na 3 osobne mini-spotkania

• Pielęgnacja zaległości
• Wybór historii
• Podział zadań

Robimy każdy w innym dniu, zaraz po naszym codziennym Scrumie - jak tylko dziennik się skończy, przystępujemy do planowania, a następnie jesteśmy wolni od (regularnych) spotkań przez resztę dnia.

Więc tak, zatopiliśmy nasze plany: -O

Omówię bardziej szczegółowo, co jest zaangażowane w każdą sesję za sekundę, ale pozwól mi wyjaśnić, jak do tego doszliśmy.

Podobnie jak Ty mieliśmy problem z naprawdę okropnymi spotkaniami planowania Sprint. Mieliśmy wszystkie właściwe elementy, ale wszystko trwało wiecznie i naprawdę wyczerpało nas psychicznie i emocjonalnie.

Potem wpadłem na ten pomysł po przeczytaniu artykułu Business Insider o 5-minutowym dzienniku Pivotal o dzieleniu naszych spotkań na krótsze sesje i robieniu ich na początku każdego dnia.

Porozmawiałem o tym z zespołem z perspektywy czasu. Niektórym członkom zespołu od razu się spodobało, innym trochę się obawiano, ale potem nasz stażysta wspomniał o badaniu, które przeczytał o technice pomodoro i zaczął o tym dalej, a to naprawdę pomogło zyskać przyczepność.

Postanowiliśmy więc spróbować.
Nasze 2-godzinne spotkanie podzieliliśmy na trzy 25-minutowe sesje. (tak, to rozmyta matematyka, ale wszyscy uważali, że nasze spotkania były zbyt długie i chcieli to zrobić tylko, jeśli zaoszczędziliśmy czas).

I zadziałało! Robimy to od około 6 tygodni przy dwóch osobnych projektach (w sumie 6 dwutygodniowych sprintów), dzięki czemu świat się zmienił.
Jesteśmy bardziej produktywni. Oszczędzamy mnóstwo czasu.
Otrzymujemy lepsze wyniki. I nie boimy się już naszych spotkań planistycznych.

I szczerze mówiąc, nasz 25-minutowy przedział czasowy jest dość luźny - niektóre sesje trwają naprawdę szybko, na przykład 5-10 minut na niektórych sesjach pielęgnacyjnych, a niektóre trwają długo, na przykład, gdy kończy się identyfikowanie nowych historii lub konieczność dzielenia historii i ponownie oszacuj podczas negocjacji. Ogólnie rzecz biorąc, zwykle trwa to średnio nie więcej niż 1,5 godziny dla całego shebang, i myślę, że dlatego działa tak dobrze.

Do szczegółów .....

Pielęgnacja zaległości

Całkiem proste - przeglądamy historie o najwyższym priorytecie, rozmawiamy o ich skutkach i upewniamy się, że nasze prognozy są dobre.

W razie potrzeby dokonamy ponownej oceny historii - powiedzmy, że oszacowaliśmy coś kilka miesięcy temu, a po uświadomieniu sobie, jak podobna historia rzeczywiście miała miejsce, możemy zgodzić się na ponowną ocenę. (Nawiasem mówiąc, wykorzystujemy punkty fabularne bez jednostek i nie oceniamy zadań ).

Ponadto, jeśli OP doda nowe historie, które jego zdaniem mają wysoki priorytet, nadszedł czas, aby je oszacować.

Ponieważ nie dokonujemy wyboru Historii aż do następnego dnia, proces ten daje OP trochę więcej czasu na dokonanie ostatecznej oceny tego, co najważniejsze do zrobienia w następnej iteracji - i to okazało się bardzo pomocne.

To spotkanie zwykle kończy się u niektórych PO i długo u innych. (osobiście uważam, że jest to świetny wskaźnik zapachu tego, jak radzi sobie twoja PO)

Wybór opowieści

Włącz Chrisa Vossa , czas na negocjacje.

Na tym spotkaniu bierzemy historie o najwyższym priorytecie i określamy DoD dla każdego. Negocjujemy, co będzie się wiązać - dzielenie i łączenie historii w razie potrzeby - dopóki wszyscy nie uzgodnimy naszych celów Sprint.

Dużą korzyść czerpiemy ze świeżości umysłów i energii na dzień dobry na to spotkanie - a świadomość, że wykonamy zadania innego dnia, pozwala nam spędzić czas, którego naprawdę potrzebujemy, aby dobrze negocjować i zrozumieć nasze zobowiązania.

Zadania

Okej, więc jako pierwszy powiem, że zadania były moją NAJMNIEJ ulubioną częścią planowania na naszych starych jednodniowych spotkaniach.

Po prostu nigdy tego nie osiągnęliśmy. Próbowaliśmy zapisywać zadania do końca spotkania - ale do tego czasu wszyscy byliśmy wyczerpani i było to naprawdę nieproduktywne. Próbowaliśmy zdefiniować zadania w tym samym czasie, co nasze DoD podczas negocjacji, ale okazało się, że jest to zbyt rozpraszające i zbyt kłopotliwe - wypalilibyśmy się, zanim wybraliśmy wszystkie historie. Poza tym naprawdę ciężko było zmieniać fokus / myślenie między szacowaniem, negocjacjami, wyborem historii i generowaniem zadań. Walczyliśmy, a to było do bani, a nasze spotkania były straszne.

Ale teraz, definiując DoD jednego dnia i nie wykonując zadań do następnego dnia, nie jesteśmy wypaleni, zawsze mamy właściwy stan umysłu i daje nam to cały dzień na marynowanie historii i naprawdę przemyśl i zrozum wszystkie zadania, zanim zaczniemy.

Samo to, IMHO, całkowicie zmienia grę.

Kładąc wszystko razem.

Oto, jak wygląda teraz nasz harmonogram ceremonii sprintu:

• Poniedziałek - Codzienny scrum -> Przegląd sprintu
• Wtorek - Codzienne scrum -> Pielęgnacja zaległości
• Środa - Codzienny scrum -> Wybór opowieści
• Czwartek - Codzienny scrum -> Zadania
• Piątek - Codzienny scrum -> Retrospektywa

To działało dla nas naprawdę dobrze. Jeśli spróbujesz, chciałbym usłyszeć, co myślisz.

Mamy cotygodniowy sprint z godzinnym spotkaniem, podczas którego omawiamy poprzedni sprint, co pozostało do zrobienia, a następnie przechodzimy do planowania nadchodzącego tygodnia. Wszystko w ciągu godziny.

Dzieje się tak, ponieważ dowiedzieliśmy się, że w naszym przypadku zbyt ścisłe przestrzeganie scrumu zmarnowałoby zbyt wiele czasu. Dzieje się tak, ponieważ większość historii jest już omawiana z członkami naszego zespołu, gdy osoba tworząca żądanie tworzy historię użytkownika.

Mówię tylko, że jeśli twój zespół obawia się planowania spotkań, prawdopodobnie powinieneś porzucić niektóre „zasady” scrum.

Odpowiedź na to pytanie jest wyczerpująca, ale tylko jedna rzecz jest potrzebna, aby działała i była przyjemna.

Daj moc zespołowi. - tzn. sprawić, by pracowali nad rzeczami, które ich zdaniem są najważniejsze.