Scrum i spotkanie planujące. Rób to dobrze!

1 586

W tym artykule chciałbym podzielić się z Wami moimi doświadczeniami ze spotkania planującego obecnego w Scrumie. Możliwe, że uznacie, że informacje tu przekazane są wartościowe na tyle, byście sami spróbowali tych praktyk. Wszystkie z nich są bezpieczne do wykorzystania. Użycie ich nic nie kosztuje, tylko odrobiny wytrwałości. Zapraszam do lektury i dzielenia się innymi praktykami w komentarzach.

W Scrumie, każdy sprint (iteracja) rozpoczyna się spotkaniem planującym. To spotkanie ma jeden podstawowy cel – stworzenie listy user stories (historyjek), które będą dostarczone w najbliższym sprincie. Oczywiście, wymagania mogą być także przedstawione jako funkcjonalności, scenariusze, elementy Backlogu Produktu, etc. Ja ze swojej strony preferuję historyjki, jednak każda z poniższych praktyk/zasad może być użyta także z innym typem wymagań.

Z mojego doświadczenia wynika, że jest to jedno z najtrudniejszych spotkań do poprowadzenia w całym cyklu Scrumowym. Product Owner (właściciel produktu) oraz zespół deweloperski muszą pracować razem by stworzyć Backlog Sprintu.

Backlog Sprintu jest swego rodzaju umową między Product Ownerem, a zespołem deweloperskim. Deweloperzy zobowiązują się* do osiągnięcia celu w ograniczonym czasowo sprincie. Właśnie dlatego ważne jest, aby wszyscy byli skupieni na spotkaniu. Źle przeprowadzone spotkanie planujące będzie miało wpływ na cały Zespół Scrumowy.

Bądź przygotowany. Miej swój cel.

Product Owner przygotowuje się do spotkania planującego już nawet kilka dni wcześniej. Musi zebrać wszystkie wymagania od interesariuszy. Nieprzygotowany Product Owner bez spriorytetyzowanego Backlogu produktu to bardzo poważny problem. Marnowanie czasu deweloperów to nie przelewki, więc Product Owner musi wiedzieć dokładnie, które funkcjonalności są najważniejsze dla interesariuszy, biznesu, zespołu, etc., a odpowiedź na to pytanie będzie się różnić zależnie od projektu. Zdarza się, że priorytet jest wymuszony przez Zespół Scrumowy, gdyż określone user story pochodzić będzie z Retrospektywy. Istnieją także sytuacje odwrotne i Product Owner musi uwzględnić potrzeby interesariuszy, którzy np. już zdążyli obiecać daną funkcjonalność swoim klientom. Odpowiednie wyważenie obu tych światów jest bardzo trudnym zadaniem, które spoczywa na barkach Product Ownera.

Product Owner musi mieć określony cel na najbliższy sprint. Dobrą praktyką jest, by każda osoba zaangażowana w projekt była go świadoma. Dobrze na czas planowania nawet napisać cel w zasięgu wzroku uczestników. Powinien on być jasny, a dzięki temu każdy może się w niego zaangażować. Wszystkie wymagania powinny pochodzić od wspólnego celu, który pomoże skupić się na nich. Nawet jeśli priorytety nie są dla wszystkich jasne lub „wszystko ma wysoki priorytet” (skąd ja to znam?), wspólny cel scala spotkanie planujące.

Miej swój cel! (źródło: https://www.flickr.com/photos/hikingartist/)
Miej swój cel! (źródło: https://www.flickr.com/photos/hikingartist/)

Ogranicz spotkanie czasowo

W Scrumie wszystkie spotkania mają określone ramy czasowe i spotkanie planujące nie jest wyjątkiem. Nie powinno ono trwać dłużej, niż jeden dzień pracujący dla iteracji trwającej miesiąc (i relatywnie mniej dla krótszych). Z mojego doświadczenia wynika, że zespoły Scrumowe bardzo często o tym zapominają (mi także się to zdarzyło!) – omawiają bardzo małe szczegóły, a samo spotkanie zaczyna błądzić. Dodaj do tego niejasny cel i efekt końcowy będzie bardzo sławy. Rolą Scrum Mastera jest by trzymać rękę na pulsie i pilnować czasu. To Scrum Master powinien przypominać Zespołowi Scrumowemu o ich ograniczonym czasie.

Kilka słów o estymacjach

Estymacje są bardzo ważne (jeśli nie najważniejsze) w Scrumie. Zespół Scrumowy używa estymacji podczas całego projektu do zaplanowania pracy, jednak nie tylko w jednej iteracji. Estymacje mogą zostać użyte jako punkt odniesienia w przyszłych sprintach.

We wpisie skupiłem się na estymacjach punktowych jako najbardziej popularnym sposobie przedstawiania estymat wymagań w projektach prowadzonych zwinnie.

Estymacje w punktach muszą spełniać dwa wymagania:
– punkty muszą być jasne dla wszystkich;
– estymacje muszą być przedstawione w jednostkach idealnych i abstrakcyjnych.

Szeroko rozumiany biznes chętnie przyjmuje estymacje czasowe lub kosztowe. Jednak praca na bardziej abstrakcyjnych wartościach pozwala przełączyć rozmowę na zupełnie nowy poziom – bitwę na godziny zastępuje się rozmową o rozwiązaniu. Używanie abstrakcyjnych estymacji jest korzystne także z dwóch innych powodów, a mianowicie możliwe jest uwzględnienie w takich estymacjach także złożoności oraz niepewności. Takie podejście pozwala estymować bardziej efektywnie, niż pozostawanie na poziomie estymacji godzinowych.

Golden triangle of estimation
Złoty trójkąt estymacji

Najbardziej podstawowym typem estymacji jest ciąg Fibonacciego. Najprostsze user story będą miały 1 punkt, te najtrudniejsze, bardziej zaawansowane lub te z najwyższą niepewnością – uzyskują najwyższą wartość. To, co jest ważne i to, o czym powinno się pamiętać podczas estymacji jest relacją między punktami.

Niestety, często znajdą się ludzie, którzy będą ingerować w punkty i będą nawet próbować porównywać dwa zespoły Scrumowe bazując tylko na ich estymacjach. Można ich zignorować lub… można zmienić podejście do estymacji! Można zacząć estymować w rozmiarach koszulek. Dzięki temu uzyskasz skalę S, M oraz L. Jeśli to zbyt mało, można także dodać XS oraz XL, czy nawet XXL. Jeśli rozmiary koszulek nie są wystarczająco abstrakcyjne, można estymować w zwierzętach. Spróbuj skończyć jednego słonia, kozę oraz trzy wiewiórki w jednym sprincie… a potem porównaj je z 20 punktami, które uzyskał inny zespół. Myślę, że jest to wystarczająco jaskrawy przykład. Takie porównanie jest niemal niemożliwe, a spotkanie planujące może stać się dzięki użyciu takiej skali bardzo interesujące.

Animal estimation
Estymacja w zwierzętach? Czemu nie!

Spraw by planowanie było bardziej atrakcyjne

Teraz, kiedy posiadasz już własną skalę, możesz rozpocząć estymacje. W tej chwili pojawia się kolejny problem, który warto rozwiązać. Zazwyczaj deweloperzy estymują jeden po drugim, co na początku może być świetnym podejściem. Estymacje różnią się od siebie i jest spore miejsce do dyskusji. Po kilku rundach estymacje się stabilizują, ale czy na pewno? Może ludzie stają się zbyt zmęczeni i po prostu powtarzają estymację jeden po drugim, by mieć to już za sobą? Trudno zgadnąć…

Jednak jest na to rozwiązanie. Możesz użyć Planning Pokera. Dzięki temu rozwiązaniu każdy wybiera jedną kartę reprezentującą jego estymację. Następnie wszystkie karty odsłaniane są równocześnie. Różnią się? Pozwól deweloperom wyjaśnić najniższą i najwyższą wartość. Dzięki takiemu podejściu będziesz pewny, że wszyscy rozumieją user story identycznie. Następnie pozwól przeprowadzić kolejną rundę. Po takiej operacji możesz mieć niemal 100% pewność, że estymacje są poprawne i, co ważniejsze, cały zespół identyfikuje się z nimi. To najprostsza droga by wszyscy byli zaangażowani w proces. Możesz użyć zwykłych kart do gry lub dedykowanych do planning pokera. Możesz dodać także kilka dodatkowych kart do swojego zestawu – z symbolem kawy lub czasu. Dzięki temu, jeśli ktoś czuje się przemęczony, może zgłosić przerwę, a spotkanie wznowione zostanie po kilku minutach, gdy wszyscy będą ponownie gotowi.

Przykład kart do Planning Pokera (źródło: www.it-zynergy.com)
Przykład kart do Planning Pokera (źródło: www.it-zynergy.com)

Dziel i zwyciężaj

Pamiętasz swój ostatni stand up? Ktoś powiedział, że pracuje nad historyjką X? Jest to trzeci raz z rzędu! Kiedy skończy?…

Powyższa sytuacja wygląda znajomo? Na pewno tak! Historyjki są często zbyt duże by skończyć je jednego dnia. Co zrobić, gdy masz kilka epiców, a każdy z nich zajmuje cały sprint by go skończyć? W takiej sytuacji jeden deweloper może pracować przez cały sprint nad tym samym zadaniem (może być więcej powodów, dlaczego deweloper przy chodzi na Stand Upy cały czas z taką samą informacją, jednak tutaj nie skupiam się na nich). Może to być irytujące i nieznośne, ale to nie jego wina. Oczywiście – może być bardziej specyficzny co do swojej pracy na stand upach, ale ten problem można naprawić już na spotkaniu planującym!

Wszystko dlatego, że nie przeprowadziłeś swojej sesji planującej poprawnie. Każde spotkanie planujące powinno składać się z dwóch części:
– Co zespół będzie robił?
– Jak zespół to wykona?

Odpowiedź na oba te pytania jest bardzo ważna. Dotychczas pisałem tylko o pierwszej części. Do tego momentu zespół powinien mieć wybrane i wyestymowane historyjki do sprintu, czyli powinien być zdefiniowany Sprint Backlog. Wygląda na to, że skończyliśmy nasze zadanie.

Nic bardziej mylnego! Druga część spotkania jest o wiele ważniejsza dla deweloperów i o wiele bardziej angażująca. To teraz następuje moment dyskusji, jak zespół deweloperski ma zamiar spełnić wymagania klienta – co musi zostać zrobione, by dostarczyć funkcjonalności. Zespół deweloperski powinien wyszczególnić wszystkie zadania, które kryją się za danym wymaganiem klienta. Oczywiście wyodrębnienie zdań dla bardzo małej historyjki może być uznane za bezcelowe, jednak nie jest to do końca prawdą. Jest to jeden z procesów translacji wymagań biznesowych, na zadania techniczne.

Breakdown user stories
Rozbicie User Stories na taski

Podsumuj swoje spotkanie

Pamiętaj, że każde spotkanie musi zostać podsumowane. Dla spotkania planującego, dobrym podsumowaniem jest Sprint Backlog. Powinien to być efekt ciężkiej pracy głównie zespołu deweloperskiego, ale także Product Ownera i Scrum Mastera. Jeśli Sprint Backlog zawiera także podział na wszystkie zadanie, jakie w ramach poszczególnych wymagań należy wykonać – jeszcze lepiej! Jednak Sprint Backlog nie jest jedynym rezultatem tego spotkania.

Ze swojej strony na zakończenie spotkania planującego zawsze prezentuję zespołowi tzw. Point Board. Wygląda podobnie do Sprint Backlogu, jednak została dodana do niego jedna dodatkowa rzecz. Wymagania zostały posortowane wg ich wag by pokazać zachodzące między nimi relacje. Wymagania z identyczną/podobną estymacją powinny na takiej tablicy znajdować się niedaleko siebie – może to być ich trudność, wysiłek potrzebny do ich skończenia, czy niepewność. Dzięki takiej tablicy, zespół bardzo szybko może przejrzeć swoje estymacje i zweryfikować, czy jakieś user story jest „większe” od innego i w efekcie należy poprawić ową estymację (w takiej sytuacji dodatkowa dyskusja jest zazwyczaj potrzebna). Oczywiście na tej tablicy zachodzą także dodatkowe relacje – między sąsiadami w wagach. Wszystko pokazane jest na poniższym obrazie.

Przez pokazanie Point Boarda zespołowi, pozwalam zespołowi uzyskać pełną informację na temat zakresu sprintu i potwierdzić, że jest o poprawny, a wszystkie estymacje są słuszne.

Relacje na Point Boardzie
Relacje na Point Boardzie

Oczywiście. Zaprezentowane powyżej pomysły nie są jedynymi. Starałem się pokazać te, które nie są specjalnie absorbujące, a dają dobre efekty. Jeśli macie więcej podobnych przykładów, nie bójcie podzielić się nimi w komentarzach. Jeśli coś jest niejasne – także zapraszam poniżej.

Komentarze
This site is using the Seo Wizard plugin created by http://seo.uk.net/