Wrzutki, czyli nowa, niezaplanowana praca w Sprincie. Jest to coś, czego nie da się uniknąć, bo świat jest nieprzewidywalny i ciągle się zmienia. Jest więc to coś, z czym musimy umieć sobie poradzić. Ale czy na pewno wrzutki są zawsze negatywnym zjawiskiem?
Nowa praca kontra zaplanowany zakres
Istnienie wrzutek nie powinno nikogo szokować. W ciągle zmieniającym się świecie nie możemy założyć, że istnieje cokolwiek stałego. Pisząc o zmianach nie mówię jedynie o dużych, znaczących wydarzeniach mogących zmienić w jednej chwili sens naszego życia czy projektu (patrz: Black Swan). Zmianą mającą wpływ na nasz projekt będą również np. błędy krytyczne wykryte na środowisku produkcyjnym i wypuszczenie nowego produktu przez konkurencję.
Skoro wiemy, że zmiany wystąpią na pewno, to czy powinniśmy harmonogramować nasze życie lub projekt zakładając, że znane są nam jego poszczególne etapy? Oczywiście że nie! Zresztą, już 12 zasad zwinnego tworzenia oprogramowania sugeruje, że pojawiające się zmiany powinniśmy wykorzystywać do uzyskania przewagi.
Wrzutki w agile
Wrzutki nie powinny być normą. Każde nowe wymaganie, które trafia do naszego projektu powinno znaleźć się w pierwszej kolejności w Backlogu Produktu. Nie ma tu znaczenia, jakiej kategorii jest nowe wymaganie „niezbędne do zrealizowania”, ponieważ backlog zawiera spis wszystkich wymagań, życzeń, ulepszeń, błędów i planów. Zarówno tych krytycznych, jak i tych znikomej wagi.
„Backlog Produktu to uporządkowana lista wszystkiego, co w danym momencie wiadomo odnośnie rozwoju produktu. Stanowi jedyne źródło wymaganych zmian, które mają być w produkcie wprowadzone.” – Scrum Guide
Właśnie z tego powodu, nowe wymaganie powinno trafić w pierwszej kolejności do Backlogu Produktu gdzie powinno zostać właściwie opisane, oszacowane, a także powinna mu zostać przypisana wartość biznesowa. Co najważniejsze, powinno zostać spriorytetyzowane przez Product Ownera lub za jego wiedzą. Oczywiście, jeżeli nadal chcemy pracować w metodyce zwinnej.
Kiedy realizować?
Nowe wymaganie (wrzutka) nie powinno trafić od razu do Backlogu Sprintu. Właścicielem Backlogu Sprintu jest Zespół Deweloperski, który podczas spotkania Sprint Planning (Planowanie Sprintu) na podstawie dokonanych przez siebie prognoz w pełni świadomie określił, co będzie w stanie dostarczyć w czasie kolejnej iteracji.
Czy „dorzucenie” niewielkiego wymagania nie zaburzy tej prognozy? Oczywiście, że tak. Zakładając, że nie mamy (i nie powinniśmy mieć!) buforów na niezaplanowane w sprincie prace stawiamy Zespół Deweloperski w bardzo trudnej sytuacji. Z jednej strony zaplanował on swój Sprint według swojej najlepszej wiedzy i na podstawie posiadanych informacji, a z drugiej może się okazać, że dostaje „propozycję nie do odrzucenia”. Zgodnie jednak ze Scrum Guide:
„Podczas Sprintu, nie są wprowadzane zmiany stanowiące zagrożenie dla realizacji Celu Sprintu.” – Scrum Guide
Nie bez znaczenia jest też fakt, że ciągłe przepełnianie naszego Sprint Backlogu powoduje nie tylko pracę w nadgodzinach, ale też degradację jakości wytwarzanego oprogramowania i ciągły wzrost długu technologicznego. Na pewno nie jest to coś, o co nam chodziło, gdy decydowaliśmy się na Scrum bądź inną metodykę zwinną.
Jak reagować na nowe wymaganie?
Jest taka rola, jest taka osoba… mowa oczywiście o Scrum Masterze. To on w pierwszej kolejności, zgodnie z jednym z podstawowych zadań powinien zareagować na pojawiające się zagrożenie w postaci próby „wrzucenia” nowego wymagania. Zawsze w pierwszej kolejności powinno ono trafić do Backlogu Produktu, bo może okazać się, że na tle innych znajdujących się tam rzeczy wcale nie jest takie krytyczne.
Zdarzyć się może też sytuacja, w której nowe wymaganie faktycznie będzie miało wyższy priorytet niż cały backlog, a nawet rzeczy aktualnie realizowane w Sprincie. Wtedy powinniśmy spróbować odpowiedzieć sobie na pytanie: czy możemy wstrzymać się z realizacją tego wymagania do kolejnej iteracji? Jeśli tak, dajemy sobie szansę na zaznajomienie się z wymaganiem, przeprowadzenie Product Backlog Refinementu i spokojne zaplanowanie jego realizacji.
Co więcej, odkładając wymaganie na kilka dni (bo tyle może zostać do kolejnego Sprintu), mamy możliwość dokończenia rzeczy, które zostały już rozpoczęte, a których być może nie udałoby się dokończyć gdybyśmy zdecydowali się na multitasking. Z drugiej strony, możemy mieć do czynienia z sytuacją „wszystkie ręce na pokład”, gdzie poświęcenie niedokończonej pracy jest korzystne, bo spowoduje uniknięcie wielkich strat lub zapewni ogromne zyski.
Jeśli koniecznie musimy tą wrzutką zająć się w przysłowiowym ASAP, to nie mamy wyjścia – negocjujemy zakres Sprintu z Product Ownerem. Odpowiedzmy sobie wówczas na pytanie, które z wymagań pierwotnie zaplanowanych do realizacji w bieżącym sprincie powinno zostać zwrócone do Backlogu Produktu, jednocześnie tworząc nam miejsce do realizacji wrzutki. Powyższe podejście pozostawia komfort pracy Zespołowi Deweloperskiemu powodując jednocześnie pełną transparentność działań na projekcie i w Backlogu Produktu.
Konotacja słowa wrzutka
Czy powinniśmy traktować wrzutkę jako negatywny aspekt naszego działania, jako coś złego? Nie! Decydując się na realizację nowego wymagania (nie ma znaczenia, czy jest to poprawa błędu, nowa funkcjonalność czy wymaganie niefunkcjonalne) dajemy sobie szansę na zwiększenie zadowolenia naszego klienta.
Zdecydowaliśmy się na pracę w podejściu iteracyjnym właśnie po to, aby być gotowym na zmianę zakresu naszego projektu po każdym Sprincie. Powinniśmy więc, paradoksalnie, oczekiwać niespodziewanych wydarzeń. Wykorzystajmy tę szansę aby osiągnąć coś więcej niż tylko korzyść finansową. Pamiętajmy, że większość wrzutek przeważnie może poczekać do następnego Sprintu, a do pokazania tego wystarczy bardzo zgrubna ich analiza.
Zmiana myślenia z „nie zrobimy tego” albo „zrobimy to w nadgodzinach” na „możemy to zrobić, ale zamiast tego nie zrobimy następujących rzeczy…” ma kolosalny wpływ na priorytet, z jakimi przychodzą do nas wrzutki.
Oczywiście każdy kij ma dwa końce, nie inaczej jest w tym przypadku. Jeśli wrzutki są nagminne a ich realizacja zawsze jest krytyczna i nie może czekać, to mamy problem. Może być on spowodowany przez niską jakość testów funkcjonalnych naszego wymagania (błędy, zgłoszenia z produkcji) bądź przez niedogadanie zakresu funkcjonalności z interesariuszami (ciągłe zmiany zakresu wymagania). Porozmawiamy o powyższym na Retrospektywie i znajdźmy najlepsze rozwiązanie.
