Sprint review: A step-by-step guide

Przegląd sprintu to spotkanie mające fundamentalne znaczenie w procesie programowania w sposób zgodny z metodyką Agile, w szczególności w ramach Scrum. Stanowi ono zakończenie sprintu — zazwyczaj trwającego od dwóch do czterech tygodni. W jego trakcie zespół programistów przedstawia potencjalnie gotowy do udostępnienia przyrost funkcjonalności produktu.

Podczas przeglądu sprintu zespół programistów i interesariusze zbierają się, aby przejrzeć i przedstawić pracę wykonaną podczas sprintu. Daje to możliwość zaprezentowania opracowanych funkcji, zebrania informacji zwrotnych oraz zapewnienia zgodności z wizją produktu i wymaganiami.

Głównym celem przeglądu sprintu jest zebranie informacji zwrotnych i zapewnienie przejrzystości na kolejnych etapach procesu rozwoju. Ma on kilka kluczowych celów:

Demonstracja ukończonych prac: zespół programistów przedstawia kluczowym interesariuszom, w tym product ownerowi, klientom i innym istotnym stronom, funkcje ukończone podczas sprintu.

Gromadzenie informacji zwrotnych: interesariusze przekazują informacje zwrotne na temat zademonstrowanych funkcji, umożliwiając zespołowi skuteczne dostosowanie i ustalenie priorytetów pracy w trakcie kolejnych sprintów.

Zgodność z wizją produktu: przegląd sprintu zapewnia zgodność wykonanej pracy z ogólną wizją i celami produktu. Pomaga on zweryfikować, czy prace dotyczące rozwoju produktu i cele sprintu zmierzają we właściwym kierunku.

Świętowanie osiągnięć: stanowi okazję do świętowania dokonań zespołu programistów oraz docenienia jego ciężkiej pracy i poświęcenia.

Identyfikacja usprawnień: poprzez dyskusje i obserwacje podczas przeglądu sprintu można określić obszary procesu rozwoju wymagające poprawy i zająć się nimi w przyszłych iteracjach.

Krótko mówiąc, przegląd sprintu promuje współpracę, przejrzystość i ciągłe doskonalenie w programistycznych ramach postępowania Agile. Wspiera kulturę otwartej komunikacji, wspólnych sesji roboczych i współodpowiedzialności za sukces produktu.

Przeglądy sprintów nie są retrospektywami, więc co to jest przegląd sprintu? Podczas przeglądu sprintu następuje prezentacja ciężkiej pracy całego zespołu Scrum: projektantów, programistów i product ownera. W Atlassian lubimy przeprowadzać przeglądy sprintów w swobodnej atmosferze.

Członkowie zespołu zbierają się wokół stołu, gdzie przeprowadzają nieformalne demonstracje i opisują prace zrealizowane w ramach danej iteracji. Jest to czas na zadawanie pytań, wypróbowywanie nowych funkcji oraz dzielenie się opiniami. Celebrowanie wspólnego udziału w sukcesie jest ważną częścią budowania zespołu Agile.

Omówmy, dlaczego „definicja ukończenia”, którą stosuje zespół, jest tak ważna dla tego wydarzenia Agile.

Dla typowego użytkownika systemu Jira nie ma nic bardziej satysfakcjonującego niż przeniesienie zadania z kolumny „Przegląd kodu” do kolumny „Gotowe”. Ta zmiana statusu jest równoznaczna z ukończeniem pracy, którą jako zespół zobowiązaliśmy się wykonać. Po prostu gotowe!

Dotarcie do mety i doprowadzenie pracy do końca wymaga dobrego planowania, precyzyjnej definicji ukończenia oraz koncentracji na wykonaniu zadania. Większość tych czynności wykonuje się na etapie planowania sprintu, jednak sam plan to za mało, aby przegląd sprintu i sprint zakończyły się sukcesem. Zespoły muszą wypracować jasno określoną kulturę dostarczania pracy oraz definicję ukończenia.

Skuteczne zespoły przenoszą jasne procesy i kulturę programistyczną na każdy projekt i każdą jednostkę pracy. Wykorzystaj następujące pytania do oceny swojego procesu i sprawdzenia, czy działa on optymalnie:

• Czy przed wdrożeniem historyjki zostały właściwie zdefiniowane przez product ownera, projektanta oraz zespół techniczny?

• Czy wszyscy rozumieją wartości inżynierskie i kulturę inżynierską zespołu?

• Czy istnieją precyzyjne definicje oraz wymagania dotyczące przeglądu kodu, automatycznych testów oraz ciągłej integracji, które wspierają zrównoważone programowanie Agile?

• Czy po zrealizowaniu historyjki przez zespół uwidaczniają się błędy? Innymi słowy, czy status ukończenia faktycznie oznacza, że coś jest ukończone?

Kultura zespołu w zakresie jakości oraz realizacji powinna wykraczać ponad poziom poszczególnych historyjek użytkowników, jednostek prac technicznych oraz błędów. Kultura ta jest odzwierciedleniem podejścia zespołu do samego oprogramowania oraz jego dostarczania.

Precyzyjna definicja ukończenia pomaga zespołom skoncentrować się na ostatecznym celu każdej jednostki pracy. Kluczowym elementem procesu dodawania przez product ownera pracy do backlogu zespołu jest zdefiniowanie kryteriów akceptacji. Co to oznacza, że historyjka użytkownika jest ukończona?

W Atlassian zespół Jira śledzi kryteria akceptacji i uwagi z testowania razem z resztą historyjki użytkownika w systemie Jira. Dzięki temu cały zespół ma wyraźny obraz pomyślnej realizacji każdego zgłoszenia. Czym są kryteria akceptacji i uwagi z testowania?

• Kryteria akceptacji: wskaźniki wykorzystywane przez product ownera do potwierdzenia, że historyjka została wdrożona w zadowalający sposób.

• Uwagi z testowania: krótkie, precyzyjne wytyczne od zespołu QA, na podstawie których programista może poprawić jakość pisanego kodu funkcji i ulepszyć automatyczne testy.

Dobrze zdefiniowane zgłoszenia w trakcie wdrożenia pozwalają każdemu z powodzeniem zakończyć prace. W systemie Jira dodawanie odpowiednich pól jest łatwe. Wystarczy zalogować się jako administrator i kliknąć przycisk Administrator w zgłoszeniu.

Jedna z podstawowych wartości wyznawanych w Atlassian brzmi: „Gramy w jednej drużynie”. Przeglądy sprintów są doskonałą okazją do świętowania dokonań zespołu oraz poszczególnych jego członków w trakcie iteracji. Zazwyczaj organizujemy je w piątkowe popołudnia, gdy prace w biurze zwalniają przed weekendem.

Przeglądy sprintów nie są tożsame z retrospektywami, dlatego trzeba pamiętać o organizowaniu ich po zakończeniu iteracji, ale przed przystąpieniem do retrospektywy. Uczestnictwo osób z zewnątrz zawsze jest mile widziane, jednak w spotkaniu zazwyczaj biorą udział product owner, wszyscy członkowie zespołu programistycznego oraz Scrum Master. Dobrą praktyką jest poświęcenie każdej iteracji w trakcie spotkania od 30 minut do godziny.

Jesteśmy zwolennikami przeglądów sprintów, ponieważ są one elementem dbania o dobrą atmosferę w zespole i jego morale. W przeglądach sprintów chodzi głównie o budowanie zespołu. W trakcie przeglądu nie trzeba nic udowadniać, to nie egzamin — to wydarzenie oparte na współpracy zespołowej, w trakcie którego ludzie prezentują swoją pracę, zadają pytania i otrzymuje informacje zwrotne.

„Podczas przeglądu sprintu warto zachęcać zespół do przejmowania własności poprzez demonstrowanie funkcjonalności przez różnych jego członków” — sugeruje Mark Cruth, trener ds. nowoczesnej pracy w Atlassian. „Jeśli masz w zespole feature leadów, jest to dla nich świetny sposób na zademonstrowanie swojej ciężkiej pracy”.

Jeśli przegląd sprintu nie jest odbierany przez członków zespołu pozytywnie, może to oznaczać, że:

• Zespół podejmuje się wykonania zbyt wielu prac i nie jest w stanie ich ukończyć w trakcie iteracji.
  
  „Przeglądy sprintów to świetny sposób na zachęcenie zespołów do podzielenia pracy na małe, istotne elementy” — dodaje Cruth. „Unikaj przeglądu niedokończonych prac — jak ujęto to w Manifeście Agile, celem jest działające oprogramowanie!”.
  

• Zespół zmaga się z powstałym długiem technicznym.

• tworzenie funkcji nie odbywa się w sposób zrównoważony, tak aby błędy nie trafiały do bazy kodu;

• praktyki programistyczne zespołu związane nie są dopracowane tak, jak mogłyby być;

• Product owner zmienia priorytety w trakcie iteracji, a zespół programistyczny jest odsuwany na bok w efekcie niekontrolowanego rozrastania się zakresu.

Uwaga: czasami każdemu zespołowi trafia się trudna iteracja. W trakcie retrospektywy zespołu zastanówcie się, dlaczego iteracja ulega zmianie, i utwórzcie plan uporania się z przyszłymi problemami.

Firmy z zespołami rozproszonymi borykają się ze szczególnymi trudnościami związanymi ze skalowaniem wydarzeń Agile na różne obszary geograficzne. Przeglądy sprintów nie stanowią wyjątku.

Na przykład członkowie zespołu Jira pracują w lokalizacjach na całym świecie: od Sydney przez Gdańsk po San Francisco. Mimo że jesteśmy rozproszeni, przeglądy sprintów stanowią ważną część kultury naszego zespołu. Członkowie zespołu nagrywają nieformalne filmy i udostępniają je na stronie Confluence, gdzie może je obejrzeć cały zespół.

„Korzystajcie z narzędzi takich jak Loom, aby nagrywać swoje przeglądy i gromadzić opinie od innych osób z całego świata” — podpowiada Cruth. „Pracujemy w środowisku asynchronicznym, więc należy podchodzić do przeglądów sprintów przez pryzmat współpracy asynchronicznej”.

Dzięki tym filmom informacyjnym każdy może na bieżąco śledzić postępy projektów programistycznych pomimo różnic czasowych. Zobaczenie prezentacji funkcji na własne oczy przez programistę jest korzystne dla zespołu na dwa sposoby:

• Pozwala zrozumieć produkt: cały zespół może zapoznać się z celem, uzasadnieniem i wdrożeniem funkcji, dzięki czemu wszyscy lepiej rozumieją działanie produktu.

• Buduje relacje w zespole: filmy sprzyjają zacieśnianiu osobistych relacji między członkami zespołu. Widzimy, kto odpowiada za poszczególne aspekty produktu. Ta praktyka wzmacnia nasze relacje, dzięki czemu pomimo różnic geograficznych jesteśmy bardziej zżytą i lepiej zgraną grupą.

Jedną z istotnych korzyści płynących z włączenia przeglądów sprintów do procesu programistycznego Agile jest większa zdolność adaptacji i elastyczność produktu. Dzięki regularnemu przeglądowi ukończonej pracy zespoły zyskują cenny wgląd w zmieniające się potrzeby i preferencje interesariuszy.

Przeglądy sprintów ustanawiają iteracyjną pętlę informacji zwrotnych między zespołem programistów a interesariuszami. Ten iteracyjny charakter pozwala na szybkie dostosowywanie i udoskonalanie produktu w oparciu o informacje zwrotne w czasie rzeczywistym oraz zapewnienie jego zgodności z ewoluującymi potrzebami rynkowymi i wymaganiami użytkowników.

Prezentując prace w toku podczas przeglądów sprintów, zespoły mogą zidentyfikować potencjalne problemy lub nieporozumienia na wczesnym etapie cyklu programistycznego. Umożliwia to szybkie rozwiązywanie problemów, a tym samym zapobiega ich późniejszej eskalacji.

Przeglądy sprintów stanowią platformę umożliwiającą iteracyjne udoskonalanie produktu. Gromadzenie informacji zwrotnych od interesariuszy umożliwia zespołom ustalanie priorytetów funkcji, dokonywanie korekt obranego kursu i w razie potrzeby zmienianie kierunku produktu w celu zapewnienia adekwatności i konkurencyjności na rynku.

W dzisiejszym dynamicznym środowisku biznesowym priorytety i warunki rynkowe mogą się szybko zmieniać. Przeglądy sprintów umożliwiają zespołom dostosowanie się do tych zmian, pozwalając na zmianę priorytetów pracy i modyfikację celów projektu w oparciu o pojawiające się możliwości lub wyzwania.

Przeglądy sprintów wzmacniają pozycję interesariuszy, dając im głos w procesie tworzenia oprogramowania. Dzięki aktywnemu uczestnictwu w przeglądach i przekazywaniu informacji zwrotnych interesariusze czują się zaangażowani w sukces produktu, co prowadzi do lepszej współpracy.

Ogólnie rzecz biorąc, większa zdolność adaptacji i elastyczność zapewniana przez przeglądy sprintów umożliwia zespołom szybkie reagowanie na zmieniające się warunki rynkowe, preferencje klientów i potrzeby biznesowe. Dzięki tej elastyczności firmy mogą utrzymać przewagę konkurencyjną i dostarczać produkty zgodne ze zmieniającymi się oczekiwaniami interesariuszy.

W zespołach, które dopiero zaczynają praktykować przeglądy sprintów, pojawia się pokusa przemycenia ich do retrospektywy. Przegląd sprintu jest jednak wydarzeniem niezależnym od retrospektywy sprintu.

Poświęćcie czas, aby nacieszyć się owocami swojej pracy. Świętujcie dokonania z radością. Skuteczne przeglądy sprintów podnoszą morale i motywację zespołu. Ta idea świętowania jest dla nas w zespole Jira tak ważna, że w deklaracji naszej wizji uwzględniliśmy stwierdzenie „śmiało, świętuj”.

Zacznij korzystać bezpłatnie z szablonu Scrum w Jira