Mini-waterfall to popularna nazwa na błędne rozumienie sposobu zwinnej pracy. W miejsce kompleksowej analizy na początku projektu robimy to samo, ale w fazach, produktach czy innym okresach. Czy ma to sens? Odpowiedź na to pytanie jest jasna i powszechnie znana. Ale czy Refinement nie robi nam ze zwinności waterfalla?
Mini wodospad
„Zróbmy analizę przed sprintem, będziemy przygotowani.” Pewnie słyszeliście to nie raz. Osoby odpowiedzialne za sporządzenie specyfikacji wymagań przygotowują ją według swojej najlepszej wiedzy i rozbijają je na „zrabialne” elementy. Jesteśmy przygotowani – a tak się nam przynajmniej wydaje. Pełni wiary w przygotowane specyfikacje siadamy do planowania i nagle okazuje się, że rzeczywistość jest zupełnie inna.
Czy zastanawialiście się, jak wiele takich analiz nie ma ciągu dalszego? Co się z nimi dzieje, kiedy okazuje się, że część przygotowanego rozwiązania nie jest już nieaktualna? Co zrobić, a czasem również gdzie zaraportować czas pracy poświęcony na przygotowanie specyfikacji, która nie będzie wykorzystana w realizacji? To tylko niektóre z pytań, które cisną się na usta.
Mini-waterfall to nic nowego. Niektórzy z nas wyciągają analizę do poprzedniego Sprintu (udając, że jest to Product Backlog Refinement), a inni – robią mini-waterfalle w ramach jednej iteracji. Większość z nas nie wyobraża sobie pracy w inny sposób. Chcemy być przygotowani na realizację wymagania, nie chcemy tracić czasu na gaszenie pożarów, kiedy już się pali.
Ale czy faktycznie nie ma innej drogi rozwiązania tej sytuacji?
Refinement to też waterfall!
Wiele razy mówiliśmy, że Product Backlog Refinement to najważniejszy element Scruma. Bez niego nic przecież nie będzie. Żadne planowanie się nie uda.
Ale skoro analiza wykonywana przed rozpoczęciem Sprintu jest stygmatyzowana waterfallem, to Product Backlog Refinement, który ma miejsce również przed rozpoczęciem prac – również powinien nim być. A nie jest! Gdzie tu logika?
Wszystko rozbija się o charakter tego procesu. Z uwagi na jego czas trwania i potencjalnie duży zakres wymagań, które podlegają przeglądowi, zwyczajnie nie ma czasu na to, aby dokonywać gruntownej analizy wymagań. Zresztą czasem na analizę w ogóle nie ma miejsca, bo zajmujemy się omawianiem bieżących potrzeb naszego interesariusza, a więc przeglądamy priorytety wymagań zapisanych np. w formacie User Stories.
W żaden sposób nie można więc powiedzieć, że PBR to preanaliza. Nawet, jeśli mamy to szczęście i możemy dowiedzieć się, co jest do zrobienia w danym wymaganiu, to powinno to odbywać się na zasadzie muśnięcia piórkiem, delikatnego zagłębienia się w wymaganie i wyciągnięcie jego sensu. Co bardziej uważni czytelnicy naszego bloga doskonale wiedzą, o czym mówię.
Pracujmy jak najzwinniej
Nasza praca powinna być tak zwinna, jak to jest tylko możliwe, ale nie bardziej. Brzmi to jak populistyczne hasło, ale idzie też za tym konkretny przepis.
Przecież z jakiegoś powodu wykorzystujmy zwinne podejście. Skorzystajmy więc z niego w jak najszerszym zakresie. Realizujemy trudne projekty, pracujemy w szybko zmieniającym się świecie (patrz ostatnie zdarzenia), pracujmy więc tak, aby maksymalizować ilość niewydanych pieniędzy i niespalonych godzin.
Mówi się, że wszelkie podejmowane przez nas działania powinniśmy podejmować tak późno, jak to jest tylko możliwe. Nie ma tutaj znaczenia, czy mówimy o analizie, dewelopmencie czy testach. Każda z tych czynności, zgodnie z ideą pragmatyzmu powinna być podejmowana just-in-time. I ja się z tym całkowicie zgadzam.
Postępowania w sposób przedstawiony powyżej daje nam poczucie, że nie stracimy czasu i pieniędzy naszej organizacji na przygotowywanie rozwiązania, którego realizacja może nie nastąpić. Dodatkowo, decyzje podjęte wspólnie z innymi członkami Zespołu Deweloperskiego spowodują ograniczenie czasu, w jakim wypracujemy rozwiązanie. Jeśli wszyscy w jednej chwili skupimy się na analizie jednego zagadnienia, to unikniemy kosztów przełączenia i wielowątkowości (multitaskingu).
A co jak nie idzie?
Jeżeli coś nam nie idzie, to tu z pomocą przyjdzie nam to samo zwinne podejście. Mówiliśmy o DoR (Definition of Ready), które będzie idealnym narzędziem w tym przypadku. Nie będzie to szczegółowa analiza, ale doprowadzenie wymagań do stanu „planowalności”. Z drugiej strony spowoduje, że będziemy wiedzieć z czym konkretnie mamy do czynienia.
Nie zapominajmy też o Sprint Retrospective. Jeśli mamy problem z przygotowaną, a nie kontynuowaną pracą (np. analizą) lub „wybuchającymi” wymaganiami, zastanówmy się, co możemy z tym zrobić. Jako zespół mamy wiele możliwości, a będąc zaangażowanymi w realizację prac na pewno zastosujemy najlepsze.
Nie pracujmy w mini-waterfallach, podejście to ma więcej wad niż zalet. Zastanówcie się na najbliższej Retrospektywie, jak często musicie zmieniać wcześniej przygotowanego elementy naszej pracy i dlaczego tak się dzieje. Opóźnijcie każdą pracę do absolutnie ostatniej chwili. Ale nie po to, aby na koniec Sprintu bić się o jego realizację.
Jeżeli za wykonanie zadania weźmiemy się odpowiednio późno (ale nie później), to damy sobie szanse na wypracowanie innego rozwiązania, niż by nam się wydawało wcześniej. Prawdopodobnie będzie ono lepiej dostosowane do aktualnych potrzeb i warunków. A wyjdzie nam to zdecydowanie lepiej, jeżeli zaangażujemy w tę pracę wszystkich ludzi.
