Jak być Agile, nie będąc Agile

Czym jest Agile?

Agile można opisać jako iteracyjny cykl tworzenia produktu, który przekłada się na szybsze dostarczanie klientowi wartości. Jest preferowany w sytuacji, kiedy nie jest znany dokładny zakres projektu od początku jego realizacji, a kierunek, w którym będzie podążał, wynika z informacji zwrotnej z rynku. W podejściu zwinnym (agile)stawia się na określone czaso-okresy, w trakcie których realizuje się wyznaczone na początku takiego czaso-okresu zadania.

Twórcy podejścia zwinnego w wytwarzaniu oprogramowania zaproponowali światu swój manifest polegający na przeniesieniu uwagi od procesów i narzędzi do ludzi i interacji, od szczegółowej dokumentacji do działającego oprogramowania, od negocjacji umów do współpracy z klientem oraz od realizacji założonego planu do reagowania na zmiany. Stworzyli oni również 12 zasad zwinnego tworzenia oprogramowania, z którym polecam się zapoznać.

Zwinność jako główny nurt rozwoju produktu została wykorzystana w wielu metodykach (czy też praktykach, ramach postępowania) - kilka najczęściej obecnie spotykach na rynku, to np. Scrum, Kanban, Lean, XP, Nexus, Disciplined Agile. Każda z nich dodała swoje ramy, stworzyła wydarzenia i narzędzia, żeby dostosować do zdefiniowanych przez twórców, ciągle rozwijających się potrzeb. W dalszej części artykułu rozwinę kilka wydarzeń / narzędzi, które zostały zaproponowane w ramach powyższych frameworków.

Źródło: grafiki własne Frontkom

Agile way of thinking

Rzeczywistość projektowa nie jest jednak często tak idealna, jak się twórcom agile marzyło. Klienci mają określony budżet, zakres prac i czas na wdrożenie. Często nie rozumieją, dlaczego warto być bardziej zwinnym, uważają, że generuje to dodatkowe koszty, pracują od dziesiątek lat w starym modelu i nie czują potrzeby zmiany. Można ich edukować, przekonywać, zachęcać, ale można też skorzystać z narzędzi, które proponuję niezależnie od tego, czy prowadzony projekt będzie w oparciu o metody klasyczne, czy zwinne.

Skuteczność poszczególnych narzędzi będzie różna, polecam je wypróbować w swoich zespołach pilotażowo i zdecydować, czy chce się z nimi zostać. Poniższe są tylko przykładami, które sprawdziły się w moim doświadczeniu.

1. Planning projektu

Jeśli projekt ma być zrealizowany z sukcesem, zaplanować go trzeba niezależnie od tego, czy zrobimy to w sposób klasyczny, czy zwinny. W sposób klasyczny, to znaczy etap po etapie, np. najpierw przeprowadzamy analizę biznesową, następnie projektujemy rozwiązanie, programujemy, testujemy i oddajemy klientowi do używania. Przykładem zwinnego podejścia jest następujący schemat: przeprowadzamy analizę biznesową, projektujemy rozwiązanie, przeprowadzamy testy z użytkownikami, programujemy pierwsze funkcjonalności, testujemy je, oddajemy klientowi, programujemy kolejne funkcjonalności itd.

Wbrew pozorom projekt nie powinien skonsumować więcej zasobów dzieląc go na mniejsze części, a dzięki temu z jednej strony klient będzie mógł korzystać z rozwiązania wcześniej, co się może przełożyć na potencjalne zyski, jak również jakość powinna być wyższa z uwagi na większe skupienie nad daną częścią.

Techniką, z której polecam skorzystać przy planowaniu projektu (będzie też wartościowa przy planowaniu zadań, o czym w punkcie 2), jest MoSCoW (wymyślona przez Dai Clegga), czyli określenie ważności poszczególnych zadań dla danego etapu projektu. Dla przykładu - podczas tworzenia MVP (minimum viable product) tylko część funkcjonalności będzie niezbędnych.

Dla kolejnego etapu projektu prawdopodobnie funkcjonalności, które z jakiegoś powodu się nie zmieściły lub nie były tak istotne, żeby znaleźć się w kategorii “must”, powędrują w hierarchii wyżej. Podział zadań w ten sposób, zarówno z perspektywy całego projektu, planowania tygodniowego, ale również w pracy codziennej pozwoli skupić się w pierwszej kolejności na najważniejszych.

Poszczególne litery z MoSCoW oznaczają:

M - must (musi być zrobione)
S - should (powinno być zrobione)
C - could (może być zrobione)
W - won’t (nie będzie zrobione)

Źródło: grafiki własne Frontkom

2. Planning zadań (tygodniowy)

Projekt mamy zaplanowany - przynajmniej jakąś jego część, teraz możemy przejść do podziału naszego zakresu na mniejsze części. W zależności od tego, jak nam wygodnie pracować, jaka jest charakterystyka projektu, nad jaką częścią projektu pracujemy, Scrum Guide mówi o podziale na Sprinty, które modelowo trwają 4 tygodnie.

W życiu projektowym mi się dobrze sprawdzały tygodniowe oraz 2-tygodniowe przedziały, podczas których realizowany był określony pakiet zadań. I ponownie, metodą MoSCoW dzielimy konkretny zakres na te najważniejsze, które muszą zostać wykonane, oraz na te mniej istotne. Ile zadań wejdzie do naszego zakresu, zależeć będzie między innymi od ich złożoności, oraz od ilości członków zespołu (czy też czasu, który będą mieli w trakcie danego okresu na realizowanie zadań). Zadania warto planować na początku tygodnia, żeby ze świeżą głową ruszyć do ich realizacji.

3. Daily

Żeby projekt się nie wydłużył, wartokontrolować jego postęp codziennie. Do tego świetnie się sprawdzają spotkania typu stand up czy daily  (wg wcześniej wspomnianego Scrum Guide - Daily Scrum), podczas których omawiane są zadania realizowane w dniu poprzednim - czy zostały wykonane, jakie były trudności, jakie zadania są do zrealizowania w dniu dzisiejszym oraz czy są jakieś elementy potencjalnie problematyczne, sprawy, które trzeba rozjaśnić / wytłumaczyć, aby nie blokować pracy zespołowi. Spotkania daily powinny być jak najbardziej konkretne i dać możliwość wypowiedzenia się każdej osobie z zespołu.

4. Kanban board

Tablica kanban (ang. kanban board)(pierwotnie stworzona przez Taiichi Ohno)jest narzędziem, które w sposób wizualny obrazuje proces produkcyjny oraz umiejscawia realizowane zadania w odpowiednim miejscu. Jest to wartościowe narzędzie, ponieważ z jednej strony wspiera osoby, które są wzrokowcami i potrzebują widzieć, ile jeszcze pracy zostało, a z drugiej strony pozwala ograniczyć ilość zadań w trakcie (tzw. work in progress), co ma pozytywny wpływ na skupienie i nie przeładowywanie zadaniami danego członka zespołu.

Kto korzysta z tzw. multitaskingu ten wie, że nie wspiera pracy w skupieniu i wcale nie oznacza, że realizując kilka zadań jednocześnie, zrealizujemy je szybciej, niż gdybyście je realizowali jedno po drugim.

Źródło: grafiki własne Frontkom

5. Retro

Ostatnim wydarzeniem w ramach wybranego zbioru jest spotkanie retrospektywne (wg Scrum Guide - Retrospektywa Scrum). Podczas takiego spotkania powinny zostać omówione kwestie, które dotyczyły danego wycinka projektu - co poszło dobrze, co poszło gorzej, oraz bardzo ważne - co możemy ulepszyć na przyszłość (ten element wywodzi się z filozofii kaizen jako ciągłego usprawniania naszej pracy).

Ze swojego doświadczenia polecam organizować takie spotkania raz na tydzień / dwa, w zależności od tego, jaki przedział czasu przyjmiemy za nasz “Sprint”.

Dobrym sposobem jest również realizowanie jednego ulepszenia na raz, czyli jeśli problemem jest estymowanie zadań i zespół docelowo nie realizuje zakresu, który ustalił, bo spędza więcej czasu na poszczególnych zadaniach, to jako element do poprawy weźmy pracę nad estymacjami i skupmy się na poprawieniu tylko tego w najbliższym czasie.

Dla każdego zadania, nad którym będziemy pracować jako zespół, ważny jest wybór osoby odpowiedzialnej za tę poprawę, ponieważ jeśli nie ma osoby odpowiedzialnej za zadanie, to zadanie najprawdopodobniej nie zostanie zrealizowane.

Podsumowanie

Przedstawiona lista to tylko kilka wartościowych technik, które można zastosować w pracy nad projektem i spowodować, że będzie bardziej zwinny, niezależnie, w jaki sposób jest realizowany oficjalnie.