Przeglądy sprintów w metodyce Agile

Przeglądy sprintów nie są retrospektywami. W przeglądzie sprintu chodzi o zaprezentowanie ciężkiej pracy całego zespołu: projektantów, programistów i product ownera. W Atlassian lubimy przeprowadzać przeglądy sprintów w swobodnym tonie. 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.

Najpierw zastanówmy się, dlaczego definicja ukończenia, którą stosuje zespół, jest tak ważna dla tego wydarzenia Agile.

Dla mnie, jako typowego użytkownika systemu Jira, nie ma nic bardziej satysfakcjonującego niż przeniesienie zadania z kolumny „Przegląd kodu” do kolumny „Gotowe”. To przeciągnięcie karty Agile jest oznaką ukończenia 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 realizacji zadania. Większość tych czynności wykonuje się na etapie planowania sprintu, jednak do skutecznego przeprowadzenia samego sprintu oraz jego przeglądu sam plan nie wystarczy. Zespoły muszą wypracować jasno określoną kulturę dostarczania prac oraz definicję ukończenia.

Skuteczne zespoły przenoszą jasne procesy i kulturę programistyczną na każdą jednostkę pracy. Wykorzystaj następujące pytania do oceny własnego procesu i sprawdzenia, czy służy on Twojemu zespołowi w sposób optymalny:

• 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 oraz kulturę inżynierską zespołu i postępują zgodnie z nimi?

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

• Czy po zrealizowaniu historyjki przez zespół uwidacznia się wiele błędów? 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 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 sposób zadowalający.

• 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.

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;

• 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 tymi problemami w trakcie kolejnego sprintu.

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. Członkowie zespołu Jira pracują w lokalizacjach na całym świecie: w Sydney, Gdańsku, Sajgonie i 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ół.

Dzięki tym filmom informacyjnym każdy może na bieżąco śledzić postępy, 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 temu każdy lepiej rozumie działanie całego produktu.

• Buduje relacje w zespole: Filmy sprzyjają zacieśnianiu osobistych relacji między członkami zespołu. Każdy z nas widzi, 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ą.

W zespołach, które dopiero zaczynają praktykować przeglądy sprintów, pojawia się pokusa przemycenia przeglądu sprintu do retrospektywy. Przegląd sprintu jest 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”.