Jeden z poprzednich artykułów poświęcony był Definicji Ukończenia, która w Scrumie służy zapewnieniu przejrzystości tego, co to znaczy, że prace nad produktem zostały zakończone i czy produkt nadaje się do użycia.

Zazwyczaj Zespół, kierując się standardami obowiązującymi w organizacji oraz własną wiedzą i umiejętnościami, ustanawia Definition of Done takie, które rzeczywiście zapewnia, że produkt określony jako ukończony może zostać użyty.

A jeśli to niemożliwe, czy Scrum może być dalej stosowany?

Istnieje wiele sytuacji, które mogą doprowadzić do konieczności wyboru między obniżeniem wymogów Definicji Ukończenia (jej osłabieniem) a możliwością ukończenia czegokolwiek w Sprintach. Wbrew obiegowej opinii nie uniemożliwia to stosowania Scruma, o ile będziemy trzymać się przy tym obowiązujących w nim zasad, w tym nadrzędnej: zapewnienia przejrzystości.

Warto tu od razu przypomnieć, że Definicja Ukończenia jest przede wszystkim narzędziem zapewnienia empirycznej wiedzy o stanie produktu na koniec Sprintu. Nie może być więc rozziewu między tym, co traktujemy jako ukończony produkt i zaczynamy użytkować, a tym, co określone jest jako ukończone w Definition of Done. Inaczej mówiąc, Definicja nie może funkcjonować jako lista pobożnych życzeń, które kiedyś być może spełnimy. Ma ona odzwierciedlać to, co rzeczywiście dziś już robimy.

Jeśli nie mamy problemów, które wymagają pilnych usprawnień, Definicja taka opisywać będzie używalny produkt. W innych przypadkach… cóż, to zależy od sytuacji.

Wyobraźmy sobie produkt, który do tego, by nadawał się do użytku, wymaga wykonania piętnastu różnych czynności w ściśle określonej kolejności z zastosowaniem konkretnych praktyk. Zespół, który będzie rozwijał ten produkt, powinien potrafić wszystkie te działania zrealizować w Sprincie. Niestety, nie potrafi. Co wtedy zrobić?

Dodanie kompetencji

Pierwsza i najprostsza odpowiedź to uzupełnienie kompetencji, na przykład poprzez zmianę składu Zespołu (dodanie nowych osób lub ich częściową wymianę). Oczywiście ceną za to będzie zdestabilizowanie relacji, bo ludzie muszą się poznać i przyzwyczaić do nowej sytuacji.

Alternatywnym rozwiązaniem jest zapewnienie Zespołowi wsparcia ekspertów lub innego Zespołu, który nie tyle ma wykonać niezbędne prace, ile przekazać wiedzę i nauczyć jak budować działający produkt.

Jeśli da się jedno ze wspomnianych rozwiązań zastosować i uzyskać w ciągu Sprintu lub dwóch możliwość spełnienia wymogów Definition of Done, problem zostanie rozwiązany.

Zmiana Zespołu

Czasami nie ma możliwości dodania kompetencji do Zespołu. Co wtedy? Najbrutalniejszym, ale i najlepszym rozwiązaniem jest poszukanie innego Zespołu, który już ma niezbędne kompetencje. Rozwiązanie to jest skuteczne, o ile taki Zespół istnieje i jest realnie dostępny – bo być może zajmuje się właśnie rozwojem innego produktu, a nie wchodzi w grę praca nad dwoma różnymi produktami w jednym Sprincie.

Powiedzmy, że skorzystanie z tej opcji nie jest możliwe – innego Zespołu brak. Co wtedy?

Wstrzymanie prac nad produktem

Rozsądnym wyjściem może być odłożenie rozwoju produktu do czasu, aż poprzez udział w innym przedsięwzięciu (niewykluczone, że powołanym gównie dla tego jednego celu) Zespół uzyska kompetencje pozwalające na rozwój produktu nadającego się do użytku. W ten sposób będzie absolutnie jasne dla wszystkich – również dla interesariuszy – że na razie produkt nie powstaje.

Możliwość sięgnięcia po to rozwiązanie zależy od tego, na co może pozwolić sobie organizacja i czy interesariusze będą dość cierpliwi, by na rozpoczęcie prac nad produktem poczekać.

Zmiana Definicji Ukończenia i jej stopniowe udoskonalanie

Jeśli oczekiwanie nie wchodzi w grę… cóż, trzeba zredukować Definition of Done do takiego poziomu jakości produktu, jaki Developerzy będą mogli faktycznie osiągnąć. To oznacza, że ukończony produkt w myśl obowiązującej Definicji nie nada się do użycia bez wykonania prac, których Zespół na razie zrealizować nie potrafi.

Taka początkowa wersja Definicji Ukończenia oczywiście byłaby skrajnie odległa od pożądanej, dlatego Zespół powinien najszybciej, jak to możliwe, zdobywać brakujące kompetencje. W kolejnych Sprintach Definicja będzie uzupełniana o kolejne wymogi (te wcześniej usunięte ze względu na brak możliwości ich spełnienia przez Developerów) i w końcu osiągnięty zostanie stan, w którym ukończony produkt będzie mógł zostać bez problemów użyty.

Wiem, że czytając o obniżeniu wymogów, „puryści scrumowi” podniosą krzyk, że to już nie Agile, bo nic nie jest kończone. Bądźmy wszak realistami: Definition of Done spełnia w zaistniałej sytuacji swą podstawową funkcję, jaką jest ujawnianie stanu produktu (lichego, to fakt) na koniec każdego Sprintu. Wszyscy wiedzą, co jest zrobione, a co pozostaje wciąż do zrobienia, by produktu użyć. Co więcej, Zespół ma klarowną listę kompetencji, jakie musi szybko pozyskać.

Czy w opisanym modelu postępowania produkt mimo wszystko może zostać użyty? Tak, ale pod warunkiem wykonania niezbędnej do tego pracy (tej, która na razie przekracza możliwości Developerów). Może to być inny Zespół albo np. zatrudniony w tym celu ekspert. Bez tego produkt nie nadaje się przecież do użycia i korzystanie z niego w takim stanie byłoby karkołomnym pomysłem.

Jeśli natomiast nie ma presji na użycie produktu już teraz, stać się to może dopiero wtedy, gdy Developerzy rozszerzą Definicję Ukończenia do wymaganego poziomu, a następnie spełnią zawarte w niej warunki. Być może dojście do tego punktu zajmie Sprint lub dwa, a może tych Sprintów będzie kilka. Jeśli potrzeba na to wielu miesięcy, być może skład Zespołu mimo wszystko należy zmienić, bo ewidentnie został źle dobrany w stosunku do realnych wymogów, jakie stawia przed nim rozwój tego konkretnego produktu.

Przy okazji warto odpowiedzieć na pytanie, co dzieje się z elementami Backlogu Produktu, które zostały zrealizowane w momencie obowiązywania tej pierwszej Definicji Ukończenia. Jedni uznają, że powinny być realizowane raz jeszcze za każdym razem, gdy Definicja zostanie rozszerzona. Inni powiedzą, że w momencie ich ukończenia do Backlogu Produktu powinny być dodane elementy opisujące, co trzeba zrobić w przyszłości, gdy Definicja już zostanie rozszerzona. Obie te opcje są dość marne.

Pierwsza nie ma sensu o tyle, że wymogi Definicji Ukończenia ma spełniać cały produkt, a nie tylko rozwiązania pojedynczych wymagań. Nie trzeba więc realizować ich ponownie, jeśli Definicja się zmieni. Wystarczy sprawdzić, czy produkt spełnia zawarte w Definicji warunki, a jeśli nie, zadbać o to, wykonując niezbędną pracę. Będzie ona stanowić część bieżącego developmentu, a nie jakąś ponowną realizację wymagań z przeszłości.

Druga opcja jest kuriozalna, bo Backlog Produktu to plan rozwoju produktu, a nie opis niezbędnych działań developerskich. Albo więc wymagania uznać należy po prostu za niezrealizowane (i wtedy po Sprincie wrócą one do Backlogu, w którym przedefiniowane zostaną tak, by opisywać, co pozostało do zrobienia), albo są zrealizowane i do Backlogu Produktu powracać w żadnej formie nie powinny. Praca, którą trzeba będzie wykonać w przyszłości (po rozszerzeniu Definicji Ukończenia), stanowić będzie przecież część nie Backlogu Produktu, ale Backlogu Sprintu, w którym Developerzy będą zabiegać o spełnienie wymogów udoskonalonej Definicji.

Za mało czasu!

Bywa i tak, że Zespół ma kompetencje i potrafiłby zbudować działający produkt, ale Sprinty są zbyt krótkie, by to osiągnąć. Wtedy trzeba zadać sobie pytanie, w jakim stopniu czasochłonność poszczególnych czynności zależy od kompetencji i sposobu pracy Developerów.

Jeśli z obiektywnych i trudnych do usunięcia przyczyn pewne działania (takie jak testy, przetwarzanie danych, integracja produktu i jego instalacja) trwają wiele dni, rozsądnym rozwiązaniem będzie wydłużenie Sprintów. W ten sposób w każdym z nich uda się dostarczyć więcej wartościowych rozwiązań za cenę zmniejszenia częstotliwości, z którą sprawdzać się będzie ich wartość z interesariuszami. Pamiętać też trzeba, że im dłuższy Sprint, tym oczywiście mniejsza zdolność Zespołu do reagowania na zmianę potrzeb użytkowników produktu.

Natomiast jeśli czasu w Sprincie jest za mało, bo Zespół stosuje nieefektywne praktyki lub nie potrafi dobrze zorganizować swej pracy, absolutnie nie powinno się Sprintu wydłużać. Zamiast tego warto zracjonalizować ilość wymagań podejmowanych do realizacji w każdym z nich. Ba, bywa i tak, że decyzja o… skróceniu Sprintu (zamiast wydłużenia) zmusza Developerów do znalezienia efektywniejszych sposobów działania.

W żadnym z opisanych tu przypadków nie ma powodu, by usuwać cokolwiek z Definition of Done Zespołu. Ma ono wymagać zbudowanie działającego, nadającego się do użycia produktu.

Tu dwie drobne uwagi. Pierwsza: odpowiedzialnością Scrum Mastera jest zadbanie, by zbyt łatwo to, na co Zespół może wpłynąć, nie zostało uznane za „obiektywny czynnik”, uzasadniający wydłużenie (bez potrzeby) Sprintów. I druga uwaga: po wydłużeniu Sprintów należy ciągle poszukiwać sposobu ich ponownego skrócenia, bo taka możliwość w końcu się może otworzyć…

Niespełnione zależności

Jeśli produkt budowany jest przez różne Zespoły albo organizacje współpracujące ze sobą, albo ma integrować się z czymś od organizacji niezależnym i niepoddającym się kontroli z jej strony, niemal zawsze pojawia się problem z niezaspokojonymi zależnościami. Zmusza to do czynienia założeń, że coś zadziała w określony sposób, gdy już będzie dostępne. A przecież czynienie założeń w istocie jest sprzeczne z podejściem zwinnym.

Nie wiem, co „puryści scrumowi” doradzają w takiej sytuacji, ale trzeba czasami pogodzić się z tym, że Definition of Done opisywać będzie produkt zaledwie gotowy do integracji, mający duże prawdopodobieństwo na połączenie się z innymi komponentami bez problemów i dodatkowego developmentu. Istnieje mnóstwo praktyk developerskich pozwalających zredukować ryzyko nieudanej integracji i Zespół powinien wybrać te, które w jego kontekście sprawdzą się najlepiej.

Odpowiedzialnością Scrum Mastera jest upewnienie się, że wszyscy (a więc nie tylko Zespół, ale również interesariusze) mają świadomość, że to, co nazywane jest ukończonym produktem na koniec każdego Sprintu, wciąż nie jest zintegrowane i istnieje ryzyko, że próba takiej integracji zakończy się niepowodzeniem.

Oczywiście nic i nikt nie zwalnia Zespołu z obowiązku poszukiwania sposobu wyeliminowania zależności lub zredukowania ich liczby. A wtedy natychmiast Definition of Done powinno być adekwatnie rozszerzone tak, aby przybliżyć się do budowania produktu nadającego się do użycia.

Procesy i czynności odbywające się poza kontrolą Zespołu

A co jeśli użyć można tylko takiego produktu, który przejdzie przez niezależny audyt, uzyska niezależny certyfikat (którego nie sposób pozyskać w czasie Sprintu)? Klasyczny przykład to aplikacja na telefon, której Zespół nie może samodzielnie opublikować. Zrobi to operator sklepu z aplikacjami, najczęściej poprzedzając to przeglądem rozwiązania pod kątem zgodności ze standardami, jakie oprogramowanie musi spełniać.

Definition of Done w takim przypadku powinno opisywać produkt, który jest gotowy do zewnętrznej akceptacji lub certyfikacji – wskazując czynności niezbędne do zapewnienia, że ma szansę ją przejść pozytywnie. Z reguły nic nie stoi na przeszkodzie, by po stronie Zespołu replikować wszystkie czynności (testy), jakim poddany zostanie produkt w czasie audytu – a wtedy Definicja Ukończenia powinna wprost tego wymagać. W ten sposób niepowodzenie publikacji nowej wersji (odrzucenie produktu) staje się czymś rzadkim i niespodziewanym.

Nie udawajmy

Jak widać, w Scrumie można poradzić sobie niemal z każdym problemem bez łamania obowiązujących w nim zasad. Czasami produkt, jaki w ten sposób budujemy, nie jest tak dobry, jakbyśmy tego chcieli, ale przynajmniej jest zagwarantowana przejrzystość stanu spraw. Nie pojawia się też ukryta praca, o której nikt nie mówi (dług techniczny) – wiadomo, co zostało zrobione, a co nie (i wciąż musi zostać wykonane).

Najgorszym bowiem, co można zrobić, to udawać, że buduje się wartościowy, działający produkt i pozwolić w to uwierzyć wszystkim dookoła.