Blog

Czy zastanawialiście się kiedykolwiek nad tym, co to właściwie znaczy, że „sprint zakończył się sukcesem”? Każdy Scrum Master wcześniej czy później musi zmierzyć się z tym pytaniem. Wydawać by się mogło, że w metodzie korzystającej z prostych reguł łączących precyzyjne zdefiniowane role, zdarzenia i artefakty, nie będzie wątpliwości, co jest miarą sukcesu. A jednak, wątpliwości te się pojawiają.

Ale może powinienem napisać to nieco inaczej: pojawiają się tak krańcowo różne interpretacje tego, czym jest „udany sprint”, że rodzi to wątpliwości, czy wszyscy korzystający z metody Scrum rozumieją jej podstawowe zasady.

Najprościej: sukces = cel sprintu został osiągnięty

Cóż, to najprostsza i zarazem najczęściej stosowana definicja sukcesu w Scrum. Nie jest zła, przy założeniu – nie zawsze spełnionym – że ten cel sprintu jest rzeczywiście czymś wartym osiągania. Gdy jednak uświadomimy sobie co jest odwrotnością sukcesu, nieosiągnięcie celu sprintu byłoby automatycznie porażką. Moim zdaniem niesłusznie, bo niepowodzenie daje możliwość, by się czegoś nauczyć, zaś zdobywanie wiedzy ciężko uznać za porażkę.

Formalnie: sukces = Product Owner zaaprobował produkt

Ten sposób dokonywania oceny, czy sprint się „udał” czy nie, świadczy o głębokim niezrozumieniu metody. Od strony formalnej nie ma w definicji Scruma mowy o żadnej formie akceptowania prac przez Product Ownera, nie ma on do tego ani żadnego narzędzia, ani de facto umocowania. Dlaczego?

Jeśli coś jest zrobione (czyli „done”), to musi spełniać Definition of Done. Co to oznacza? Ano tylko tyle, i aż tyle, że wytworzony produkt jest technologicznie w stanie pozwalającym na jego wydanie i użycie. Jeśli Product Owner zdecyduje się na wydanie produktu, który jest „done”, poza pracami wynikającymi stricte z samego procesu wydawania oprogramowania, żaden dalszy development nie jest konieczny.

Z drugiej strony każde z wymagań, które realizowane są w sprincie przez zespół developerski, opisywać powinno określoną potrzebę lub cel biznesowy, jaki za pomocą oprogramowania można będzie osiągnąć. Zakres prac jest pochodną ustaleń poczynionych przez developerów z Product Ownerem zarówno w czasie pielęgnacji backlogu, jak i podczas planowania sprintu. Nieobowiązkowe, ale bardzo przydatne są tutaj kryteria akceptacyjne, które precyzyjnie określają jaka funkcjonalność jest wymagana, aby od strony biznesowej oprogramowanie spełniało potrzeby opisane wymaganiem.

A zatem jeśli spełnione jest zarówno Definition of Done, jak i zaspokojone jest samo wymaganie od strony biznesowej, nie ma potrzeby „aprobowania” produktu. Product Owner otrzymuje bowiem oprogramowanie w stanie pozwalającym na użycie go, z takimi funkcjonalnościami, jakie opisane były zrealizowanymi wymaganiami. Jeśli ze względu na feedback od interesariuszy lub własną ocenę Product Owner nie zdecyduje się na wydanie produktu, dalsze jego zmiany stanowią już nowe wymagania.

Ambitnie: sukces = Product Owner zdecydował o wydaniu produktu

Takie definiowanie sukcesu jest echem pokutującego tu i ówdzie przekonania, że w Scrum wydania można robić tylko na przełomie sprintów. Nie jest to prawda: można je robić w dowolnym momencie. Jeśli w połowie sprintu Product Owner otrzymuje od zespołu developerskiego działający produkt spełniający Definition of Done i uznaje, że rozwiązanie jest na tyle użyteczne biznesowo, że należy go wydać – może, a nawet powinien to zrobić. Ba, można to nawet robić w modelu Continuous Delivery, jeśli tylko organizacja jest w stanie podołać tak częstym wydaniom.

Dużo częściej jest jednak tak, że wydanie odbywa się co kilka sprintów, ponieważ niezależnie od tego, czy wymagania udało się zrealizować, i niezależnie od spełnienia najbardziej nawet rygorystycznego Definition of Done, to wciąż Product Owner podejmuje decyzję o wydaniu. I jeśli uzna, że produkt nie zawiera w sobie dość funkcjonalności, że czegoś w nim brak i trzeba to dopiero wytworzyć – wydania na koniec sprintu nie będzie.

Każdy sprint to eksperyment

Scrum korzysta z empirycznej kontroli procesu, a istotą działania w nim jest eksperymentowanie. Może to przerazić, bo czyż nie można oczekiwać, że doświadczeni developerzy doskonale wiedzą, jak coś zrobić, a biznes na potrzeby którego pracują, wie dokąd zmierza? Cóż, niestety nie można tego oczekiwać, i trzeba się z tym pogodzić. Właśnie dlatego niezbędne jest eksperymentowanie.

Przed zbudowaniem oprogramowania i próbą jego użycia możemy jedynie zakładać, że odpowie ono na nasze potrzeby. A przed wytworzeniem produktu możemy jedynie przewidywać, jaką metodą uda się to zrobić najefektywniej i czy jest to w ogóle możliwe. Inaczej mówiąc stawiamy hipotezy, które staramy się potwierdzić. Takie działanie oznacza, że eksperymentujemy.

Istotą metody Scrum jest zredukowanie złożoności, która nierozerwalnie wiąże się z domeną wytwarzania oprogramowania, właśnie poprzez wykorzystanie empiryzmu. Zamiast próbować przewidzieć z góry wszystko, dzielimy ogromny i złożony problem na serię mniejszych, dających się dużo łatwiej przeprowadzić iteracji (eksperymentów, zwanych w Scrumie sprintami). Po każdej z nich dokonujemy oceny tego, co udało się zrealizować lub dowiedzieć (a więc dokonujemy oceny rezultatów eksperymentu), po czym planujemy kolejną iterację, w której już więcej wiemy, bo znamy rezultaty iteracji poprzednich.

Rozwój produktu w Scrum (ale też innych metodach Agile) jest iteracyjny i inkrementalny: sprint po sprincie dodajemy lub zmieniamy w produkcie funkcjonalności, a gdy stanie się on na tyle użyteczny, że warto go wydać – czynimy to. I zbieramy feedback od rzeczywistych użytkowników, aby w oparciu o to dokonać dalszych zmian w produkcie.

Nie ma „nieudanych” sprintów

Celem sprintu jest wytworzenie produktu, ale nie wolno zapominać, że nie może się to dziać za wszelką cenę. Oprogramowanie musi być wytworzone tak, by spełniało Definition of Done, konieczne jest też dostarczenie rozwiązania dla problemów biznesowych opisanych wymaganiami (i spełnienie kryteriów akceptacyjnych dla tychże wymagań, o ile zostały zdefiniowane).

Sprint, w którym nie udało się zrealizować żadnego wymagania, bo z różnych względów – technicznych lub organizacyjnych – nie udało się spełnić wszystkich zapisów Definition of Done, również może być sukcesem. Pamiętajmy, że eksperyment, którego rezultat odbiega od postawionej na początku hipotezy, jest udany – możemy być co najwyżej nieusatysfakcjonowani tym rezultatem. Rozpoczynamy sprint w przekonaniu, że uda się w nim zrealizować ściśle określony zbiór wymagań, a jeśli się to nie uda, zyskujemy wiedzę niezbędną do decydowania o dalszych krokach. Możemy zmienić sposób działania (proces, narzędzia) i spróbować ponownie; możemy odłożyć realizację na później (jeśli konieczne jest usunięcie przeszkody utrudniającej realizację wymagania); możemy zmienić samo wymaganie lub… zrezygnować z dalszych prac nad nim (jeśli to nie jest już opłacalne).

Z kolei sprint, w którym wszystko udało się zrealizować, ale po którym Product Owner decyduje o dalszych pracach nad produktem lub zmianach w dopiero co ukończonych funkcjonalnościach, również jest sukcesem. Brak wydania nie jest porażką, ale świadomą decyzją opartą na ocenie tego, co udało się wytworzyć. Nie musimy posługiwać się projektami i makietami produktu, ani spekulować jak coś „będzie działać”, bo sprint-eksperyment dostarczył nam działające rozwiązanie. Dzięki temu odkrywamy, że niekoniecznie dobrze rozumieliśmy, jak zbudować wartościowy produkt. Teraz – dzięki zakończonemu sprintowi – wiemy więcej. Dokonujemy adaptacji, czyli pojawiają się nowe wymagania i cykl się powtarza.

Zwinnie: sukces = sprint umożliwił udoskonalenie produktu lub sposobu jego wytwarzania

W Agile miarą sukcesu jest umiejętność wykorzystania podejścia empirycznego do poszukiwania najlepszych rozwiązań. Jeśli czegoś się nie uda wytworzyć, usuńmy to, co stoi nam na drodze – zmieniając podejście. Jeśli pierwszy pomysł staje się zbyt kosztowny – zróbmy coś alternatywnego. Jeśli proces okazał się nieefektywny, nie umiemy korzystać z narzędzi, brak nam praktyk wspierających pracę developerów – poprawmy proces, poznajmy narzędzia, nauczmy się nowych praktyk. Jeśli nie umiemy się dogadać – usprawnijmy komunikację.

Dowiedzenie się o tym, co można zrobić lepiej, a następnie dokonanie usprawnień jest sukcesem. Porażką byłoby zignorowanie wiedzy, którą udało się pozyskać w ciągu sprintu i bezrefleksyjne kontynuowanie pierwotnych zamierzeń niezależnie od rzeczywistych skutków działań, jakie już podjęliśmy. Sprint należałoby uznać za porażkę również wtedy, gdyby uczestnicy procesu za jedyną miarę sukcesu uznali osiągnięcie celu sprintu (lub wydanie produktu) i dążyli do osiągnięcia tak definiowanego sukcesu za wszelką cenę.

Wracając do początku tego wpisu: czy można sprint uznać za udany, jeśli nie osiągniemy celu sprintu ustalonego w czasie planowania? Jeżeli postępując profesjonalnie i etycznie zrobimy wszystko co racjonalne i możliwe, by ów cel osiągnąć, ale nam się to nie uda, sprint należy uznać za udany. Oczywiście pod warunkiem, że potraktujemy ten sprint jako lekcję, wyciągniemy z niej wnioski i posłużymy się nimi do planowania kolejnej iteracji.