Wizualizacja na Planowaniu Sprintu

Wizualizacja to jest to! Pisałem już o tym kilkukrotnie – np. w poście o planowaniu kwartałów oraz w poście o historyjkach użytkownika. Można ją wykorzystać także w trakcie planowania Sprintu! Taki zabieg pomaga przygotować sobie grunt pod udany przebieg :) 

Nikt nie lubi przydługawych wstępów i owijania w bawełnę, więc… od razu opiszę jak można zwizualizować sobie plan na Sprint ^_^

Jak zwizualizować plan na Sprint?

Przygotuj tablicę. Kolumny będą to dni Sprintu, wiersze – imiona deweloperów. Stałe wydarzenia (np. Refinement Backlogu) zaznacz przy danym dniu.

Wyświetl listę historyjek i zadań, które zamierzaliście zrealizować w Sprincie. Będziecie potrzebowali mieć tę listę pod ręką, przez całą sesję. 

Rozdaj wszystkim deweloperom karteczki i markery (chyba, że korzystasz z tablic online, których przykłady możesz sprawdzić w tym poście).

Sesja krok po kroku

Urlopy, wydarzenia – na początku zaznaczcie, w które dni dzieje się coś ważnego, sporego, urlopy, konferencje, deadliney itp. 

W kolejnym kroku, każdy deweloper nanosi na tablicę swoje zadania, które będzie realizował. Jak to zrobić dokładnie?

1. Na posticie Deweloper zapisuje tytuł danego zadania.
2. Rysuje poziomą kreskę, która zaczyna się w dniu, w którym Deweloper szacuje, że rozpocznie pracę nad daną historyjką. Kreska ciągnie się do dnia, w którym praca nad historyjką dla tego dewelopera już w zasadniczej części się kończy (np. jest oddawana do testów, przeglądu przez Product Ownera lub nawet wdrażana na produkcję – to trzeba ustalić wcześniej, więcej w “uwagi dodatkowe”  oraz punkcie 6 poniżej). 
3. W komórce z  tym dniem dodaje karteczkę (z tytułem historyjki). 
4. Jeśli dwóch deweloperów pracuje nad danym zadaniem, oznaczają to prowadząc drugą strzałkę w wierszu z imieniem drugiego dewelopera – strzałki dochodzą do tego samego postita. 
5. Jeśli między zadaniami są jakieś zależności, zaznaczacie je linią z odpowiednim symbolem i możecie dopisać “blocked”,  “zależne” itp. 
6. Co z testami? W niektórych zespołach jest to osobny etap, który wykonuje osoba specjalizująca się w testach. Jej wysiłek także trzeba uwzględnić – wystarczy dodać w jej wierszu skopiowane postity programistów. Z tą różnicą, że wówczas jej postit pokaże datę wdrożenia produkcyjnego (lub np. oddania do akceptacji Product Ownera – innymi słowy, kolejny etap po testach w niektórych firmach). Jeśli testera nie ma w zespole, programiści robią testy w ramach np. code review, to po prostu ich postity są przypisywane do dni, w których następuje wdrożenie produkcyjne lub historyjka jest gotowa do wdrożenia (i np. czeka na Product Ownera, aby ją zaakceptował/a).

Tak może to wyglądać na koniec. 

Jeszcze jednak jest kilka fajnych szczegółów, które warto uwzględnić. 

Uwagi dodatkowe:

• Początek jest bardzo ważny, ustawia mocno to co się będzie działo potem. Jednak faktem jest, że ten plan dość szybko i tak się zdezaktualizuje. Jego wartość nie jest w tym, aby idealnie się zrealizował, ale żeby pobudził do myślenia, dyskusji i był swoistym „sprawdzeniem” czy to co myślicie, że uda Wam się zrealizować jest rzeczywiście możliwe. Jeśli masz Sprinty dłuższe niż 1-tygodniowe, to może warto zaplanować tylko ten pierwszy tydzień, a nie dwa?
• A tak w ogóle, to poczytaj czemu warto robić krótkie Sprinty – o tutaj :P
• Taka wizualizacja może pokazać, że testerowi zaczyna się zbierać spora górka do testowania w danym dniu. Co z tym zrobić? Niech programiści też testują! Przecież najlepsze zespoły to interdyscyplinarne zespoły, prawda? :) 
• Ustalcie, przed sesją, co symbolizuje umieszczenie danej karteczki w danym dniu – może być to Definition Of Done, oddanie do testów albo wdrożenie produkcyjnie (np. „w środę wdrażamy historyjkę XYZ” albo „w czwartek PO będzie mógł obejrzeć zmiany na stronie”). Najważniejsze, aby każdy rozumiał te postity tak samo. Jeśli w zespole macie różne role (np. Tester, Product Owner), to wizualizacja ich pracy, to jest najczęściej inny etap tych samych historyjek. Musicie to jakoś pogodzić po prostu. Nic trudnego, po prostu wystarczy to ustalić. 
• Ten plan, z każdym kolejnym dniem, będzie się dezaktualizował. Jednak pamiętaj, że Eisenhower miał dużo racji, gdy mówił o tym, że plany są bezwartościowe, ale planowanie jest wszystkim. Nie chodzi o to, aby trzymać się sztywno tabeli. Ona ma Ci pomóc zorganizować początek pracy. Tym samym, w zależności od tego jak szybko ten plan się zdezaktualizuje możesz go pokazywać na Daily albo wyświetlić przez pierwsze dni na jakiejś tablicy. 
• Pamiętaj, aby narzędzia dopasowywać do swojego świata. Może masz pomysł na skromniejszą wersję, prostszą albo dużo bardziej rozbudowaną? :)

Podsumowanie

To by było na tyle, w kwestii wizualizacji planu na Sprint. Nie jest to skomplikowane działanie, z reguły zajmie około 20 minut, w zależności od wprawy zespołu i liczby elementów do zaplanowania. Dostarcza natomiast całkiem dużo wartości, bo uruchamia wiele dobrych dyskusji o tym co i jak można zrobić, co jest osiągalne, a czego się nie uda zrealizować. Stosowałem to narzędzie z kilkoma zespołami i z reguły sprawdzało się świetnie, chociaż były i takie które to porzuciły :) Może Ty też masz doświadczenia z tym narzędziem? Podziel się opinią w komentarzu!

---

Ilustracja posta dzięki uprzejmości You X Ventures