Blog

Tym razem chciałem napisać o czymś, czego nie ma, a więc o tytułowych odbiorach w Scrumie. Zanim jednak przejdę do wyjaśnienia tej tezy, być może kontrowersyjnej (o tym, że wywołuje ona kontrowersje, wiem z reakcji uczestników moich szkoleń), wyjaśnijmy sobie, co przez odbiory rozumiem.

W świecie tradycyjnych metod był sobie klient z walizką pieniędzy i problemami, za których rozwiązanie gotów był wyłożyć część zawartości walizki, rzecz jasna jak najmniejszą. Przychodził do dostawcy, który obiecywał, że rozwiąże te problemy, rzecz jasna za kwotę możliwie najwyższą. Gdy już cena została ustalona i plan działań ułożony, klient przed odejściem umawiał się dostawcą na odbiór produktu. Czasami działo się to raz, na koniec przedsięwzięcia, a czasami etapami, jeśli tak przewidywał plan.

Odbiór stanowił istotną część procesu, w którym klient aprobował (lub nie) rozwiązanie przedstawione przez dostawcę. Przy czym warunki odbioru również były z góry ustalane – wszak była to podstawa do określenia tak ceny, jak i zakresu prac. Proces odbierania produktu miał uzasadnienie: klient nie brał udziału w wytwarzaniu produktu, więc zanim go otrzymał i za niego zapłacił, musiał rozwiązanie zaakceptować. Mógł też wykazać dostawcy, że ten zbudował nie to, co zostało zamówione, i płatności odmówić.

Problem niestabilnej złożoności

Okazało się, że klienci często nie byli zadowoleni z produktu, gdy już mieli go odebrać od dostawcy. Nie wynikało to ani z nieogarnięcia dostawcy, ani z braku precyzji zamówienia, ani nawet ze złego zrozumienia istoty zamówienia. Przyczyną był sam produkt, który w ogóle, albo co najwyżej w miernym stopniu, odpowiadał na bieżące potrzeby klientów. I to nawet wtedy, gdy spełniał co do joty specyfikację zawartą w zamówieniu.

Duże rozwiązania buduje się dostatecznie długo, by zmieniły się warunki, w których mają funkcjonować. Zmianie mogą ulec również potrzeby klientów. Produkt pożądany w momencie składania zamówienia, w chwili ukończenia prac często okazywał się zupełnie niewłaściwy. I tak na przykład w grudniu klient dostawał rozwiązanie problemów, z jakimi borykał się w kwietniu roku poprzedniego. A że produkt wytworzony został zgodnie ze specyfikacją zawartą w zamówieniu, dostawca musiał otrzymać zapłatę za wywiązanie się z umowy. To dodatkowo wzmagało niezadowolenie klienta.

Często jeszcze przed zakończeniem projektu pojawiała się presja ze strony klienta, żeby oryginalne zamówienie dostosować tak, by pasowało do zmieniających się potrzeb. Jednakże to, co było w interesie klienta, niekoniecznie pasowało dostawcy – ten w oczywisty sposób dążył do minimalizowania zmian, które destabilizowały plany i generowały koszty. Kompromis klienta i dostawcy najczęściej owocował kiepskiej jakości rozwiązaniem, marnie odpowiadającym na potrzeby klienta.

Zwinne podejście do budowania produktów

Jasne stało się, że nie da się tworzyć złożonych produktów w oderwaniu od klienta, jeśli jego potrzeby ulegają choćby powolnym zmianom. Dlatego kilkadziesiąt lat temu (jak to zabawnie brzmi…) narodziła się koncepcja budowania rozwiązań w inny sposób, do której po pewnym czasie przylgnęła całkiem zgrabna nazwa: Agile.

W podejściu zwinnym nie planuje się wszystkiego z góry ani nie umawia na odbiory rozwiązań. Produkt budowany jest w krótkich cyklach (iteracjach). Klient po każdym zakończonym cyklu ocenia, w jakim stopniu to, co powstało, spełnia jego potrzeby, po czym wspólnie z dostawcą (aby uwzględnić również jego potrzeby związane z procesem wytwórczym) podejmowana jest decyzja, co robione będzie w kolejnej iteracji. Taki przyrostowy sposób budowania rozwiązań pozwala zmierzać w stronę określonej wizji bez konieczności precyzyjnego zaprojektowania całości na początku. Co więcej, to podejście pozwala na bieżąco (w każdej krótkiej iteracji) dopasowywać produkt do aktualnych potrzeb.

Jeden wielki odbiór na koniec (lub odbiory po zakończonych etapach) zastąpiła seria dużo prostszych decyzji podejmowanych po każdym zakończonym cyklu. Zakres prac realizowanych w kolejnych iteracjach nie jest już z góry zdefiniowany i płynnie się zmienia. Tym samym zbędne (a nawet niemożliwe) stało się sporządzanie specyfikacji i detalicznych planów, które określałyby na początku przedsięwzięcia co, kto, kiedy i jak wykona.

Warto zauważyć, że bez szczegółowych projektów, analiz, planów, specyfikacji etc., nie da się przeprowadzić klasycznych odbiorów po zakończeniu prac (bo brak punktu odniesienia, jakim były zapisy zawarte w umowach na początku). Nie stanowi to jednak żadnego problemu, bo po każdej iteracji klient i dostawca doskonale wiedzą, czym w danym momencie dysponują. Jeśli zdecydują, że produkt nie wymaga dalszych prac (i nie będzie kolejnego cyklu), cóż jeszcze miałoby być odbierane?

Co to znaczy zrobione w Scrumie?

Aby dało się empirycznie podejmować decyzje odnośnie do rozwoju produktu, po każdym cyklu (w Scrumie te iteracje nazywamy Sprintami) musi być znany rzeczywisty stan produktu. Inaczej mówiąc, musi dać się odpowiedzieć na dwa pytania:

1. Czy produkt ma niezbędne cechy użytkowe i funkcjonalności?
2. Czy produkt nadaje się do użycia?

Pierwsze pytanie związane jest z tak zwaną jakością funkcjonalną (lub szerzej: wartością) i jedynie klient jest w stanie ostatecznie udzielić odpowiedzi na nie. W podejściu zwinnym produkt budowany jest w serii małych kroków, z udziałem klienta. Dzięki temu dostawca ma dużą szansę na dobre poznanie i zrozumienie potrzeb tego klienta, a więc również na ich skuteczne rozwiązanie. Co za tym idzie, szybko (po każdej iteracji) może z klientem zweryfikować, czy to, co powstało, jest rzeczywiście dobrym rozwiązaniem. Jeśli rozwój produktu z jakiegoś powodu pójdzie w niewłaściwą stronę, klient zwróci na to uwagę najpóźniej na koniec bieżącej iteracji.

Drugie pytanie jest związane z jakością strukturalną: w jaki sposób to, co zostało wytworzone, jest zrobione. Inaczej mówiąc, czy produkt może zostać rzeczywiście użyty – w szczególności do tego, by sprawdzić, w jakim stopniu jego działanie i cechy odpowiadają potrzebom klienta. Za sprawdzenie tego i zapewnienie, że produkt nadaje się do użycia od strony technologicznej, odpowiada – rzecz jasna – dostawca. Bo to on, a nie klient, wytwarza rozwiązanie. Klient nie musi nawet rozumieć technologii użytych do zbudowania produktu.

W Scrumie korzysta się z Definicji Ukończenia (ang. Definition of Done), która opisuje warunki, jakie spełnić musi produkt technologicznie gotowy do użycia. Ta Definicja jest co do zasady stała – nie może zmieniać się dowolnie ze Sprintu na Sprint (cyklu na cykl), bo budujemy cały czas ten sam produkt. Jeśli już Definicja jest zmieniana, to w sposób transparentny dla wszystkich zainteresowanych (w tym klienta), a zmiany służą doprecyzowaniu lub rozszerzeniu zapisów tak, by powstawał produkt o pożądanej jakości technologicznej.

Poziom tej jakości wynika z tego, czym jest produkt (jak będzie używany), ale też z kosztów, jakie klient jest w stanie ponosić w związku z samym procesem wytwórczym. Inaczej mówiąc, Definicja Ukończenia jest narzędziem zapewnienia stałej jakości rozwiązania, na które się z klientem umówił dostawca.

Z poszczególnymi potrzebami klienta często wiążą się kryteria pozwalające zdeterminować, czy zostały one zaspokojone, czy nie. Ponieważ każda potrzeba jest inna, te kryteria są różne dla każdego wymagania. O ile kryteria takie określa przede wszystkim klient, nie odbywa się to w zupełnym oderwaniu od dostawcy – jeśli coś ma się stać częścią produktu, to musi być możliwe do zbudowania za racjonalną cenę w akceptowalnym czasie bez rezygnacji z ustalonego poziomu jakości.

Done jest niezbędne dla działania empiryzmu

Zanim wrócimy do odbiorów, konieczne jest podkreślenie wagi Definicji Ukończenia w Scrumie. Jest ono jednym z gwarantów, że możliwe będzie empiryczne działanie. Nie może być domniemywania odnośnie do tego, co zostało wykonane w produkcie. Musimy wiedzieć, co w nim jest zrobione w sposób pozwalający na użycie (zgodnie z Definicją), a czego w nim nie ma. Musimy też wiedzieć, czy w ogóle udało się zbudować nową wersję produktu spełniającą wymogi Definicji, a więc nadającą się do użycia.

Dopiero to umożliwia podejmowanie empirycznych decyzji na koniec każdej iteracji. Empirycznych, czyli opartych nie na założeniach, że coś udało się zrobić, ale o tym, co wiadomo na pewno, że zrobione zostało. Dopiero wtedy jest możliwa ocena, czy aktualnie istniejący produkt ma pożądane cechy i działa zgodnie z bieżącymi potrzebami. Jeśli tak, taka wersja produktu zostanie zapewne użyta. Jeśli nie, produkt musi zostać dostosowany do potrzeb (przerobiony). Takie podejście pozwala również na szybką rezygnację z planowanych zmian w produkcie, gdy okażą się one zbyt kosztowne, czasochłonne, trudne lub po prostu niewykonalne.

Co ciekawe, otwiera się w ten sposób przestrzeń do powstania rozwiązań, które zostały zrobione zgodnie z oczekiwaniami i mogłyby zostać użyte, ale na razie nie zostaną, bo klient woli dokonać w nich kolejnych zmian. W klasycznym świecie odbiorów nastąpiłaby w tej sytuacji przepychanka odnośnie do tego, czyja to wina i czy za taką pracę należy się płatność. W metodach Agile jest to naturalna konsekwencja działania empirycznego. Zamiast dywagować, czy coś będzie, czy nie będzie dobre, sprawdziliśmy, jakie jest i już wiemy, czy dalsza zmiana jest konieczna.

Zakończenie Sprintu w Scrumie

Poskładajmy kawałki układanki w jeden obraz. Zanim produkt przedstawiony zostanie klientowi, musi zostać ukończony na dwóch płaszczyznach:

1. Technicznej: dostawca musi zbudować produkt, który spełnia kryteria jakościowe (zawarte w Definicji Ukończenia) tak, by w ogóle mówić, że powstał produkt w nowej wersji.
2. Funkcjonalnej: dostawca musi dysponować takim rozwiązaniem problemu, którym zajmował się w bieżącym Sprincie, co do którego jest przekonany, że jest właściwe (spełnia określone przez klienta kryteria i fakt ten potwierdziły przeprowadzone testy).

Klient wraz z dostawcą dokonuje przeglądu stanu produktu i może zdecydować o użyciu tego, co zostało wytworzone. Dyskusja może skupić się na ocenie wartości produktu (stopnia jego dopasowania do potrzeb), ponieważ wiadomo, że od strony technicznej produkt nadaje się do użycia zgodnie z zapisami Definicji Ukończenia.

Oczywiście, jeśli budowane są złożone produkty, to nawet gdy są one w pełni ukończone i potencjalnie mogłyby zostać użyte, nie zawsze pierwsze wersje są wystarczająco bogate w funkcjonalności i cechy, by zacząć z nich korzystać. To klient decyduje, kiedy i której wersji produktu użyje. Może o tym swobodnie decydować, ponieważ każde rozwiązanie, które dostawca określa jako ukończone, do użycia się nadaje (spełnia wymogi Definicji Ukończenia).

A jeśli klient nie jest zadowolony z rozwiązania, jakie otrzymał i chce jego przerobienia lub wręcz przywrócenia produktu do wcześniejszego stanu? Brak decyzji o użyciu produktu lub konieczność wycofania zmian nie oznacza, że dostawca nie wywiązał się ze swych obowiązków i naraził klienta na straty. Wszak klient dostał to, czego wcześniej chciał i dzięki doświadczalnemu sprawdzeniu otrzymanego rozwiązania odkrył, że z pozoru fajny pierwotny pomysł nie jest wcale taki fajny. Nie wszystko da się z góry przewidzieć, dlatego takie sytuacje będą się zdarzać, a uzyskanie empirycznej wiedzy o tym, co będzie dobrym rozwiązaniem, też stanowi wartość.

No dobrze, a jeśli nie uda się czegoś skończyć? Bo pojawił się problem techniczny, bo potrzeba klienta okazała się zbyt skomplikowana, bo brakło kompetencji po stronie dostawcy, bo wydarzyło się coś nieprzewidzianego?

Gdy z jakiegoś powodu warunków zawartych w Definicji dostawca nie spełnił, wtedy sytuacja również jest całkowicie klarowna: produkt do użycia się nie nadaje i dyskusja o jego wykorzystaniu w tym stanie lub wartości jest bezcelowa. Można i trzeba natomiast ustalić, co stanie się dalej. Przykładowo, prace mogą być kontynuowane, może nastąpić zmiana kierunku działania albo rozwój produktu zostanie całkowicie wstrzymany.

Zwinna definicja sukcesu

W klasycznym podejściu projektowym jako sukces definiować zwykło się dostarczenie produktu do klienta na czas, w zakresie i po kosztach, na jakie się na początku umówiono. W taki „sukces” nie było wbudowane zadowolenie klienta, tylko spełnienie formalnych ustaleń zawartych w kontrakcie. Wiele produktów, które zostały wytworzone, i za które zapłacono, było w istocie niepotrzebnych, albo okazały się nieadekwatne w stosunku do rzeczywistych potrzeb, na jakie miały odpowiadać. Inne zostały dostarczone z ogromnym garbem długu technicznego, bo tylko obniżając jakość, udało się utrzymać w ryzach koszty ich wytworzenia i dotrzymać terminów…

Jeśli w poprzednich akapitach udało mi się zbudować wrażenie, że w Scrumie prawie każdy sposób zakończenia Sprintu jest traktowany jako sukces, to nie będę zaprzeczał, że o to mi chodziło. Co nie znaczy, że w tej metodzie porażka jest niemożliwa – po prostu ma ona inny wymiar.

Sukcesem procesu empirycznego jest uzyskanie dowodu na prawdziwość jakiejś tezy lub uzyskanie wiedzy, że teza była fałszywa. Każdy Sprint to w pewnym sensie eksperyment, w którym stawiamy hipotezę, że coś jest możliwe, a zrealizowanie tego da klientowi określoną wartość (niekoniecznie finansową). Może się jednak okazać, że czegoś się nie da zrobić albo że zrobione w formie, jaka została uzgodniona, nie ma oczekiwanej wartości. Czyż taka wiedza nie jest cenna? Jest, ponieważ pozwala świadomie (empirycznie, ha!) podejmować decyzje o dalszych krokach.

Inaczej mówiąc, sukcesem w empiryzmie jest pozyskanie faktycznej wiedzy, która pozwala podjąć decyzje o dalszym rozwoju produktu (lub jego zaprzestaniu). Co więc jest w nim porażką?

Porażką procesu empirycznego jest spadek przejrzystości do stopnia, w którym niemożliwe jest określenie, czy to, co zostało wytworzone, nadaje się do użycia i czy opłacalne jest kontynuowanie prac. W Scrumie jako porażkę można traktować każdy Sprint, z którego nie wynika nowa wiedza. Porażką jest też sytuacja, w której mimo zakończenia Sprintu konieczne jest kontynuowanie działań na podstawie poczynionych wcześniej założeń do momentu, aż będzie możliwe sprawdzenie efektów w sposób empiryczny.

Dlaczego nie ma odbiorów w Scrumie?

Wróćmy do głównego tematu i nałóżmy na model działania w Scrumie ideę klasycznych odbiorów.

Jeśliby odbiór miał odbyć się na koniec (projektu lub jakiegoś etapu tego projektu), konieczne byłoby zdefiniowanie na początku, co dokładnie ma powstać. To zaś, jak wiadomo, jest mało realne lub niemożliwe dla problemów złożonych. Jak więc określić z góry warunki odbioru? Nie da się. Lista kryteriów musiałaby powstawać iteracyjnie i inkrementalnie w Sprintach, podobnie jak produkt, do którego się odnosi. I byłaby niczym więcej jak sformalizowaniem czegoś, co już wiadomo: co zostało zrobione, a co nie. Sztuka dla sztuki, nieprawdaż?

No, to może odbiory powinny odbywać się po każdej iteracji? Wydaje się to dość racjonalne, bo klient płaci za każdą iterację. Scrum Guide nic o takim formalizmie nie wspomina, ale też go nie zabrania. Rozbierzmy więc na czynniki pierwsze ten odbiór i zastanówmy się, jak mógłby być robiony.

O tym, czy produkt technologicznie nadaje się do użytku, decyduje dostawca na podstawie znanych klientowi kryteriów (Definicji Ukończenia). Jeśli klient nie akceptuje done wynikającego ze spełniania tej Definicji, nie powinien w ogóle zatrudniać tego dostawcy do budowania produktu. A jeśli go zatrudnił i dostawca trzyma się ustalonego poziomu jakości (czyli Definicji Ukończenia), co klient miałby w tym aspekcie jeszcze aprobować lub odbierać? Wszak dostaje produkt o takiej jakości technicznej, na jaką umówił się z dostawcą.

Jedyny powód, by robić odbiory związane z technologią, to brak zaufania do dostawcy i konieczność sprawdzenia przez klienta, że rzeczywiście produkt spełnia deklarowaną Definicję Ukończenia… To oczywiście może być uzasadnione, ale stanowi zupełnie osobny temat. Scrum – podobnie jak wszystkie inne metody i praktyki – nie jest odpowiedzią na brak profesjonalizmu lub nieuczciwość uczestników procesu.

Może zatem dałoby się odbierać produkt od strony funkcjonalnej i użytkowej? Ponieważ klient jest zaangażowany w proces i definiowanie wymagań, w znacznej mierze musiałby akceptować lub odrzucać skutki własnych decyzji. To, co jest budowane w poszczególnych Sprintach, ustalane jest między dostawcą i klientem, przy czym to ten ostatni decyduje o kryteriach, jakie muszą spełniać poszczególne funkcjonalności (a ogólniej: zmiany w produkcie). Kryteria te nie są tajne – znają je obie strony, bo się na nie umawiają – a przyjmując, że są jednoznaczne, wiadomo, czy są spełnione. Cóż więc tu odbierać?

Klient nie powie raczej „dostałem, co chciałem, ale tego nie akceptuję” tylko „dostałem, co chciałem, ale widzę teraz, że musimy to zmienić”. Nie ma w tym braku akceptacji, jest za to stwierdzenie (zapewne wynikające z subiektywnej oceny), że rozwiązanie nie może być użyte bez dalszych prac nad nim. Nie ma odbioru lub jego braku, jest tylko informacja zwrotna (ang. feedback), a więc dokładnie to, do czego służy Przegląd Sprintu w Scrumie.

Odbiory, czyli walidacja?

Tylko klient jest w stanie określić, czy produkt opracowany przez dostawcę rozwiązał problem lub zaspokoił potrzebę w stopniu wystarczającym. Mówimy czasami o walidacji rozwiązania – potwierdzeniu jego wartości. Dlaczego nie spiąć z tym odbiorów?

Pierwszy powód: w Scrumie dostawca i klient współpracują po to, by uzyskać maksymalną wartość z inwestycji, a takie traktowanie walidacji jest zaproszeniem do konfliktu. Dużo sensowniejszym podejściem jest dążenie do szybkiego potwierdzenia wartości nie po to, by udowodnić dostawcy, że źle zbudował produkt, ale by zlecić mu (w kolejnych iteracjach) niezbędne zmiany, gdyby produkt ich wymagał.

Drugim powodem jest brak możliwości zagwarantowania, że kryteria walidacji będą zawsze jednoznaczne i dobrze oddają potrzeby klienta. Niemal na pewno zdarzy się, że produkt, który ich nie spełnił, okaże się lepszy, niż ktokolwiek się spodziewał i klient go zaakceptuje. Albo, że klient nie zaakceptuje rozwiązania, które co prawda idealnie odpowiada zapisanym w wymaganiach kryteriom walidacji, ale generuje nieoczekiwane negatywne skutki i nie może być użyte.

Trzeci powód związany jest z czasem niezbędnym na potwierdzenie wartości niektórych zmian w produkcie. Brak decyzji klienta o odbiorze od razu na koniec Sprintu generuje niejasny stan rozwiązania, które co prawda jest done i spełnia wymagania, ale wciąż oczekuje na akceptację. W tej sytuacji kolejne Planowanie Sprintu bardziej niż na faktach opiera się o założenie, jaka może być ostateczna decyzja klienta. Efektem jest nieuchronny spadek przejrzystości procesu i artefaktów (Przyrostu i Backlogu Produktu), a ta niezbędna jest do działania empiryzmu.

Ostatnim powodem jest formalizm, jakim szybko obrosnąć może proces, zwłaszcza jeśli od akceptacji przez klienta zależeć będą płatności za kolejne Sprinty. Poza wspomnianym już konfliktem interesów nastąpi  przekierowanie części wysiłków (często znacznej) z poszukiwania najlepszych rozwiązań na udowadnianie, że to, co zostało zrobione, jest dokładnie tym, czego klient oczekiwał.

Odbiory przez Product Ownera

Nie będę ukrywał, że moim celem było zaszczepienie w umysłach czytelników myśli, że w modelu klient-dostawca jest możliwe działanie w Scrumie i zachowanie dobrych relacji oraz przejrzystości nawet w przypadku problemów (a może zwłaszcza wtedy).

Posługiwałem się uparcie określeniami klient i dostawca, ale równie dobrze mógłbym pisać o interesariuszach oraz Zespole Scrum pracującym na ich rzecz. To, czy interesariusze i Zespół pochodzą z tej samej, czy też z różnych organizacji, nie ma istotnego znaczenia dla mechaniki Scruma. Ba, nie ma to znaczenia również i wtedy, gdy Product Owner jest przedstawicielem klienta, a Developerzy i Scrum Master to pracownicy dostawcy.

Product Owner nie może odbierać zrealizowanych wymagań na koniec Sprintu, bo są one odzwierciedleniem jego lub jej decyzji produktowych, a on sam stanowi część Zespołu, który produkt buduje. Poza tym ostatecznym sprawdzianem tego, czy rozwiązanie jest dobre, nie będzie ani Przegląd Sprintu, ani uzyskany na nim feedback od interesariuszy, ale reakcja użytkowników produktu, jeśli zapadnie decyzja o jego przekazaniu do użycia. Dlatego, zamiast jałowo spierać się o odbiory, należy dążyć, by jak najszybciej dostarczyć rozwiązanie tym, którzy z niego będą korzystać.

Co zaś do Product Ownera: jeśli dopiero w trakcie Przeglądu Sprintu widzi, co zostało wytworzone i przychodzi tam, aby zanurzoną w czerwonym atramencie pieczęcią przybijać na poszczególnych wymaganiach „zatwierdzam” lub „odrzucam”, to niewiele ma wspólnego ze Scrumem. Równie dobrze mógłby przyjść wraz z interesariuszami jako jeden z nich, aby zobaczyć, co Developerzy zrobili. A przecież powinien być gospodarzem, który interesariuszom prezentuje, co zbudował dla nich Zespół.

Jeśli więc z jakiegokolwiek (zapewne złego) powodu muszą w Sprincie odbywać się jakieś odbiory przez Product Ownera, to nastąpić powinno to przed rozpoczęciem Przeglądu Sprintu. Tak, by na spotkanie z interesariuszami cały Zespół wybierał się ze wspólną wiedzą odnośnie do tego, z czym tam idzie. Przy czym Scrum Master, widząc takie odbiory, powinien zidentyfikować przyczynę, dla której wydają się Developerom lub Product Ownerowi potrzebne. Gdyby bowiem Product Owner naprawdę współpracował z Developerami w trakcie Sprintu na rzecz uzyskania maksymalnej wartości dla interesariuszy, żadne odbiory nie miałyby miejsca.