Blog

Jeden z poprzednich artykułów poświęcony był konceptowi Definicji Ukończenia, który w Scrumie służy zapewnieniu przejrzystości odnośnie tego co to znaczy, że prace nad produktem zostały zakończone, a sam 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 faktycznie 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 poziomu 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ę 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 do uzyskania transparentności co do stanu produktu na koniec sprintu. Nie może być więc rozziewu między tym, co nazywamy ukończonym produktem, i 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ś spełnimy, tylko ma odzwierciedlać to, co rzeczywiście robimy. Jeśli nie mamy problemów, które wymagają pilnych usprawnień, Definicja taka opisywać będzie używalny produkt. W innych przypadkach… 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 i praktyk użytych w ściśle określonej kolejności. Zespół, który będzie rozwijał ten produkt, powinien potrafić wszystkie te działania zrealizować w sprincie. Co zrobić, jeśli jest w stanie wykonać tylko część, na przykład siedem z nich?

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ć, przyzwyczaić do nowej sytuacji.

Alternatywnym rozwiązaniem jest zapewnienie zespołowi wsparcia ekspertów lub innego teamu, który nie tyle ma wykonać niezbędne prace, co 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 Definition of Done, problem będzie rozwiązany.

Zmiana zespołu

Nieco gorzej jeśli nie ma możliwości takiego dodania kompetencji. Cóż, wniosek jest jasny: produktu z takim Definition of Done ten zespół budować nie może, i rzeczywistości tej nie zatupiemy ani nie zakrzyczymy w żaden sposób. Najbrutalniejszym, ale najlepszym rozwiązaniem jest… poszukać innego zespołu, który posiada niezbędne kompetencje. Tylko to nie zawsze możliwe. Co wtedy?

Wstrzymanie prac nad produktem

Rozsądnym wydaje się odłożenie rozwoju produktu do czasu, aż poprzez udział w innym przedsięwzięciu (niewykluczone, że powołanym gównie dla tego celu) zespół uzyska kompetencje pozwalające na rozwój produktu nadającego się do użytku. Wszystko zależy od tego, na co może pozwolić sobie organizacja i Product Owner.

Zmiana Definicji Ukończenia

Jeśli jednak oczekiwanie nie wchodzi w grę… cóż, trzeba zredukować Definition of Done do tego, co jest możliwe do spełnienia przez team. To oznacza, że „ukończony” produkt nie nada się do użycia bez wykonania prac, których zespół na razie zrealizować nie potrafi. Ta praca powinna zostać umieszczona w backlogu produktu i wykonana w momencie, gdy team osiągnie takie możliwości.

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 tak zdefiniowane spełnia swoją podstawową funkcję, jaką jest ujawnienie stanu produktu (lichego, to fakt) na koniec każdego sprintu. Wszyscy wiedzą, co jest zrobione, a co nie oraz co trzeba zrobić, by produktu użyć. Co więcej, zespół ma klarowną listę kompetencji, jakie musi zbudować w ramach usprawniania się, by szybko uzupełnić Definition of Done o to, co uczyni produkt używalnym („wydawalnym”) co sprint.

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, na ile czasochłonność poszczególnych czynności zależy od developerów.

Jeśli sprint jest za krótki, bo z obiektywnych i trudnych do zmienienia powodów pewne działania (takie jak testy, przetwarzanie danych, integracja produktu i jego instalacja) trwają kilka 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ą poddane one będą przeglądowi. Im dłuższy sprint, tym oczywiście mniejsza zdolność organizacji do reagowania na zmianę.

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 sprintu się 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 Definition of Done zespołu nie wymagała zbudowania 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 dwie organizacje współpracujące ze sobą, albo ma integrować się z czymś od organizacji niezależnym i nie poddają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 jeśli nie da się doprowadzić do zmiany modelu, w którym rozwijany jest produkt (tak, by uzyskać wpływ na te zależności), Definition of Done opisywać musi produkt 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 staje się, co oczywiste, upewnienie się, że wszyscy (a więc nie tylko zespół, ale również biznes) 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, w jaki takie zależności można zredukować i wyeliminować. A wtedy natychmiast Definition of Done powinno być adekwatnie rozszerzone.

Procesy i czynności poza kontrolą zespołu

A co jeśli użyć można tylko 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: sami jej nie wydamy, poddawana jest zewnętrznemu przeglądowi, więc w praktyce żaden zespół budujący takie aplikacje nie potrafi zbudować „wydawalnego” produktu…

Definition of Done w takim przypadku powinno opisywać produkt, który jest gotowy do zewnętrznej akceptacji lub certyfikacji oraz 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 developerskiego 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 w przejściu owego zewnętrznego procesu (i 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ść takiego 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.