Blog

Wprowadzenie

Praca zwinna jest iteracyjna i inkrementalna.

Praca w iteracjach (obojętnie czy to Scrumowe sprinty, Kanbanowe kadencje czy jeszcze coś innego) zakłada, że będziemy pracować w regularnym rytmie (w okresie nie dłuższym niż miesiąc).

Praca inkrementalna dodatkowo wymaga, że przynajmniej na koniec tego ustalonego okresu oddamy nową, używalną wersję naszego produktu (jego inkrement – w największym skrócie: zmiany, ulepszenia, nowe funkcje, przebudowanie nieadekwatnych rozwiązań itd.).

Jeśli przyjąć, że większość zespołów deklarujących się jako zwinne pracuje zgodnie z regułami , to powinny mieć one Backlog Produktu, zarządzany przez Product Ownera. Nie wnikając za bardzo w to, czym jest Backlog Produktu bo tutaj jest to dokładnie opisane, należy bliżej się przyjrzeć jego strukturze. W Backlogu Produktu znajdują się jego Elementy (ang. Product Backlog Items), czyli zapisana w zrozumiały sposób, wartościowa, wyszacowana praca do wykonania w produkcie, którą Product Owner nieustannie układa w najbardziej odpowiedniej kolejności. Im coś ma większą wartość, tym wyższe miejsce listy okupuje, ale też powinno być odpowiednio małe, żeby zespół mógł ukończyć nad nim pracę w jednym sprincie. Jeśli coś nie jest tak małe, musi być więc zdekomponowane.

Co to znaczy? W większości znanych nam firm sprinty trwają krócej niż miesiąc, w konsekwencji pojedynczy Element Backlogu Produktu powinien być dostarczany najrzadziej co dwa tygodnie lub częściej. Skoro chcemy mieć możliwość oddawania raz na miesiąc lub częściej nowej wersji produktu, oznacza to, że najpierw musimy zrozumieć co planujemy zbudować. Dzięki temu zrozumieniu będzie można lepiej (zdekomponować) zakres pracy, by móc ją sensownie zamknąć w iteracji – ale nadal dostarczyć wartościowy produkt.

Właściwa dekompozycja

Przykładowo – chcemy zbudować stronę internetową ze sklepem naszej firmy. W klasycznym podejściu budowalibyśmy najpierw makiety całej strony, potem je zmieniali zgodnie z nowymi wymaganiami różnych decydentów, potem podpinali bazę klientów, płatności, wybór opcji wysyłki itd., jednak ponieważ chcemy zrobić to zwinnie, decydujemy, że najpierw oddamy podstawową wersję sklepu (ale od samego początku będzie można w nim kupować, nawet jeśli będzie wyglądać prosto), a w kolejnych iteracjach będziemy dokładać bardziej rozbudowane funkcje (np. nowe sposoby płatności albo bardziej dopracowane grafiki).

Decydujemy się na prosty mechanizm: można na przykład założyć konto w sklepie tylko z użyciem już istniejących kont na portalach społecznościowych od Facebooka i Google’a. Następnie można zapłacić wyłącznie kartą Visa. Nie ma wyboru dostawcy – wszystko obsłuży jedna firma kurierska za stałą stawkę. Ponieważ na razie nie spodziewamy się tysięcy zamówień na raz, obsługa będzie ręczna – zrobią to pracownicy w naszym biurze. Taki sposób dekompozycji wymagań jest właściwy dla podejścia zwinnego. W każdej iteracji chcemy przecież dostarczyć wartościowy i używalny produkt. Oznacza to, że nie możemy opierać go o kaskadowe dzielenie wymagań (najpierw analiza i planowanie wszystkiego z góry, potem długotrwały development, testowanie i dopiero oddanie klientowi). Bardzo późno w procesie otrzymalibyśmy cokolwiek zdatnego do użycia! Wartość pracy zwinnej wynika z tego, że wcześnie można używać i dostosowywać nasze rozwiązanie, dzięki czemu po pierwsze jest ono lepiej dopasowane do potrzeb klienta (często klient rozumie czego tak naprawdę chciał dopiero, gdy to zobaczy), a po drugi zabezpiecza przed pracą niepotrzebną („na zaś”, bo może się przyda itd.), która dla klienta nie przynosi wartości i jest de factostratą. Od pierwszej iteracji nasi klienci mogą kupować produkty ze sklepu, a kiedy okaże się, że musimy dostosować sklep do zgłaszanych potrzeb – będziemy mogli to zrobić.

Najprostsze podejście do dekompozycji

Zespoły zwinne muszą się nauczyć takiego dzielenia dużych wymagań, żeby to, co budują w iteracji, było pewną sensowną całością, ale i mogło być od razu po iteracji użyte (np. wydane klientowi). Dekomponowanie jest więc procesem ciągłym. Zakłada, że zespół ze sobą nieustannie rozmawia o wymaganiach i aktualizuje je wraz z postępem zdobywanej wiedzy (empiryczna nauka plus informacja zwrotna od użytkowników). Dla zespołów korzystających ze Scrum doskonałą okazją dla dekomponowania wymagań są Planowanie Sprintu i Pielęgnacja Backlogu Produktu (ang. Product Backlog Refinement, czasami nazywana też groomingiem).

Jak najłatwiej zdekomponować duże wymaganie? Będziemy potrzebować Product Ownera, Zespołu Developerskiego (najlepiej w całości) i moderatora (najpewniej Scrum Mastera lub Agile Coacha). Przydadzą się fizyczne pomoce, jak np. karteczki z zapisanymi wymaganiami lub wydrukowane Elementy Backlogu Produkty z narzędzia, w którym rejestrujemy jego elementy (np.: JIRA). Przyda nam się też odpowiednio dużo pustych karteczek (świetnie się sprawdzają tzw. Index Cards, karteczki kartotekowe w formacie A6). Doskonałym pomysłem na przygotowanie przestrzeni jest szeroki stół, przy którym wszyscy mogą stać lub siedzieć w ten sposób, by manipulować kartkami rozłożonymi na blacie. Dodatkowo potrzeba czegoś do pisania oraz pięciu pudełek, talerzy, lub dowolnej innej formy do „szufladkowania” karteczek (tabelka z naklejonej taśmy, kolorowe kartki z papieru technicznego, cokolwiek co pozwoli nam przygotować 5 rozdzielnych obszarów na karteczki).

Opatrzmy teraz te pięć „pudełek” czy „szufladek” etykietami:

1. To, co potrzebne najbardziej i teraz.
2. To, co mniej potrzebne, ale wciąż wartościowe.
3. To, co warto mieć za chwilę (najczęściej za 1–2 sprinty).
4. To, co warto mieć w przewidywalnej przyszłości (czyli jeszcze później, za 3–5 sprintów).
5. To, czego nie rozumiemy lub już teraz widać, że w ogóle jest zbędne.

Do tych pięciu pól będziemy odkładać pocięte, mniejsze wymagania, zabrane z tego pierwotnego. Przykładowo wymaganie pt. “Jako klient sklepu chcę zapłacić by dostać zamówiony towar” można zdekomponować w następujący sposób:

1. To, co potrzebne najbardziej i teraz.

Płatność przelewem na konto i przesłanie potwierdzenia mailem w formacie PDF. Towar wyślemy po zaksięgowaniu.

1. To, co mniej potrzebne, ale wciąż wartościowe.

Chcemy umożliwić klientom płacenie bardzo popularnym BLIKiem, więc musimy mieć zaimplementowaną opcję wpisywania tych kodów.

1. To, co warto mieć za chwilę (najczęściej za 1–2 sprinty).

Płatność z użyciem bramki jak PayPal czy PayU; klienci zakładają tam profil, dodają swoje karty lub rachunki, a my dostaniemy szybką płatność przez bramkę i lepsze ewidencjonowanie rozliczeń.

1. To, co warto mieć w przewidywalnej przyszłości (czyli jeszcze później, za 3–5 sprintów).

Możliwość płacenia z użyciem Apple Pay, bo już jest w Polsce i wzrasta liczba tych transakcji.

1. To, czego nie rozumiemy lub już teraz widać, że w ogóle jest zbędne.

Płatność gotówką przy odbiorze nie będzie możliwa, a co do płatności AMEX musimy się mocno zastanowić, bo nigdy tego nie robiliśmy.

Przykładowy scenariusz warsztatu dekompozycji

1. Ustalcie kto weźmie udział (najlepiej cały Zespół Scrumowy)
2. Ustalcie timebox (spróbujcie na początek 60 minut).
3. Jeśli Wasz backlog jest w formie papierowej, zanotujcie pierwotną kolejność jego elementów lub zróbcie mu zdjęcie (przyda się na koniec).
4. Weźcie pierwsze wymaganie ze szczytu Backlogu Produktu.
5. Zdecydujcie, do której z szufladek go włożyć:

1. Jeśli wymaganie w całości mieści się szufladce 1., połóżcie je tam i na razie nic z nim nie róbcie.
2. Jeśli w wymaganiu można wyodrębnić jakieś biznesowo sensowne części, wypiszcie je na osobnych karteczkach. Rozłóżcie nowe karteczki po szufladkach, pierwotne wymaganie odłóżcie na bok (żeby nie mieszało się z nowymi).
3. Elementy zbędne z szufladki 5. usuńcie na bok, o elementy niezrozumiałe zapytajcie swojego Product Ownera, obecnych w zespole ekspertów lub zapiszcie kilka pytań, na które musicie znaleźć odpowiedź by coś dalej z nimi zrobić.

1. Gdy całe pierwotne wymaganie zostało omówione i rozpisane do odpowiednich szufladek, poproście Product Ownera o ułożenie tych nowych w adekwatnej kolejności na Backlogu Produktu (w narzędziu klasy Jira lub na fizycznej tablicy, przyda się mieć zdjęcie). Oznacza to, że stare, grube wymagania albo zmieniły swoją pozycję, albo w ogóle zniknęły – a w ich miejsce pojawiają się bardziej detaliczne (i nie zawsze na tej samej pozycji).
2. Teraz weźcie drugi w kolejności element Backlogu Produktu i powtórzcie cały cykl.
3. Sensowny kształt Backlogu Produktu to: im wyżej, tym mniejsze i bardziej detaliczne elementy. Jeśli jakiś element leży nisko na backlogu i widzimy, że jeśli nie zmieni się kolejności w trakcie, to zajmiemy się nim dopiero za kilka sprintów – wtedy nie ma sensu poświęcać mu teraz dużo uwagi.

Jeśli chcesz poznać inne strategie na dzielenie wymagań, zapraszamy do obejrzenia grafu autorstwa Richarda Lawrence’a, a przetłumaczonego przez Ewę Koprowską i Łukasza Szóstka, dostępnego tutaj.