Blog

Tym razem chciałem napisać o czymś, czego nie ma, a więc o tytułowych „odbiorach” w Scrumie. Zanim jednak przejdę do 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 owe „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 nieprzewidywalnej zmienności

Okazało się, że klienci często nie byli zadowoleni z produktu, gdy już przychodzili 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 tego 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 owe rozwiązania 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: 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”. Produkt budowany jest w krótkich cyklach (iteracjach). Klient po każdym zakończonym cyklu ocenia, na ile to, co powstało, spełnia jego potrzeby, po czym wspólnie z dostawcą (aby uwzględnić również potrzeby wynikające z procesu wytwórczego) 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 niemożliwym stało się sporządzenie specyfikacji, która określałaby 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. 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 rozwoju produktu, po każdym cyklu (w Scrumie te iteracje nazywamy sprintami) musi być wiadomo, jaki jest rzeczywisty stan produktu. Inaczej mówiąc musi dać się odpowiedzieć na dwa pytania:

1. Czy produkt posiada 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.

Drugie pytanie jest związane z jakością strukturalną: jak 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ć, na ile jego cechy i działanie odpowiada 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 istnieje koncept Definicji Ukończenia (ang. Definition of Done, w skrócie DoD), które 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ż DoD jest zmieniane, to w sposób transparentny dla wszystkich zainteresowanych (w tym klienta), a zmiany służą doprecyzowaniu lub rozszerzeniu Definicji. Celem ich jest podniesienie jakości produktu, jeśli okaże się to możliwe i uzasadnione.

Jaki poziom jakości technologicznej jest wymagany 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 DoD jest gwarantem stałej jakości rozwiązania, na które się z klientem umówił dostawca.

Poszczególne potrzeby klienta mają rzecz jasna 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 te 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 DoD w Scrumie. Jest ono jednym z gwarantów, że możliwe będzie empiryczne działanie. Nie może być domniemywania odnośnie tego, co zostało wykonane w produkcie. Musimy wiedzieć, co w nim jest zrobione w sposób pozwalający na użycie (zgodnie z DoD), a czego w nim nie ma. Musimy też wiedzieć, czy w ogóle udało się zbudować nową wersję produktu spełniającą DoD, 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, ale o tym, co wiadomo na pewno. Skoro wiadomo, co w produkcie działa, możliwa jest ocena czy działanie to jest zgodne z bieżącymi potrzebami. Jeśli tak, taka wersja produktu zostanie zapewne użyta. Jeśli nie, produkt musi zostać przerobiony z uwzględnieniem bieżących potrzeb. 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 prawdopodobnie przepychanka odnośnie 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, jak 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 (DoD) 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. O tym, czy produkt nadaje się do użycia od strony technicznej, rozstrzyga DoD, a za sprawdzenie, czy tak jest, odpowiada dostawca.

Oczywiście jeśli budowane są złożone rozwiązania, nie zawsze od razu pierwsza wersja produktu i pierwsze drobne zmiany będą użyteczne i wystarczające. To klient decyduje, kiedy i jakiej wersji produktu użyje. Może o tym swobodnie decydować, ponieważ każda, którą dostawca określa jako ukończoną, do użycia się nadaje (spełnia wymogi DoD). Niewiadomą pozostaje jedynie, czy użycie to jest zasadne (czy cechy i funkcjonalności są właściwe i wystarczająco dopracowane); o tym dostawca w Scrumie zdecydować nie może.

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. Jest wręcz odwrotnie: zbudowanie czegoś, co można poddać doświadczalnemu sprawdzeniu często ujawnia, że fajny pomysł nie jest wcale taki fajny. A bez możliwości takiego empirycznego sprawdzenia opierać można by się jedynie na domniemaniach.

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? Sytuacja taka jest niekomfortowa, ale przynajmniej wiadomo, jaki jest stan spraw i możliwa staje się racjonalna i oparta na faktach dyskusja, co dalej. Kontynuujemy? Zmieniamy kierunek działań? Zupełnie to odpuszczamy? A może kontynuujemy prace, ale zmieniamy sposób rozwiązania problemu? Tym, co pozostaje niezmienne jest pełna klarowność klienta odnośnie co do tego czym dysponuje (co jest naprawdę „done”) a czego w produkcie nie ma.

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, okazało się być niepotrzebne lub niewłaściwe 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 poprzednim rozdziale 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.

A zatem sukcesem procesu empirycznego jest uzyskanie wiedzy wystarczającej do podjęcia kolejnych decyzji w oparciu o fakty. Co jest jego 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. Inaczej mówiąc jako porażkę można traktować każdy sprint, z którego nie wynika żadna nowa wiedza. Porażką jest też sytuacja, w której mimo zakończenia sprintu konieczne jest kontynuowanie działań w oparciu o poczynione wcześniej założenia 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 w oparciu o znane klientowi kryteria (DoD). Jeśli klient nie akceptuje „done” wynikającego ze spełniania tego DoD, nie powinien w ogóle zatrudniać tego dostawcy do budowania produktu. A jeśli go zatrudnił i dostawca trzyma się ustalonego DoD, co klient miałby w tym aspekcie jeszcze aprobować lub „odbierać”?

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 deklarowane DoD… To osobny temat, bo Scrum – podobnie jak wszystkie inne metody i praktyki – nie jest odpowiedzą na brak profesjonalizmu lub nieuczciwość uczestników procesu.

Może zatem „odbierać” produkt od strony funkcjonalnej? 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. 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 subiektywne), że rozwiązanie nie może być użyte bez dalszych prac nad nim. Nie ma „odbioru” tylko informacja zwrotna (ang. feedback), a więc dokładnie to, do czego służy przegląd sprintu w Scrum.

„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 trudność w jednoznacznym określeniu kryteriów tej walidacji. Niemal na pewno zdarzy się, że produkt, który ich nie spełnił, okaże się lepszy, niż ktokolwiek się spodziewał. Albo że rozwiązanie zgodne z oczekiwaniami i potrzebami klienta nie może być użyte, bo powoduje nieprzewidziane negatywne skutki. Uniknięcie nieporozumień jest niemożliwe, a zredukowanie ich ilości kosztowne (i dodatkowo może przywrócić ciężką fazę analizy problemu znaną z klasycznych metod nie-zwinnych).

Trzeci powód związany jest z czasem niezbędnym na potwierdzenie wartości niektórych zmian w produkcie. Brak decyzji klienta 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żenia co do ostatecznej decyzji klienta. Efektem jest nieuchronny spadek przejrzystości procesu i artefaktów (produktu i backlogu), 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 właściwe.

Klient czy Product Owner?

Nie zawsze jest tak, że developerzy pracują na rzecz zewnętrznego klienta – często bywa to ktoś odpowiedzialny za wydzielony obszar biznesowy w tej samej firmie.

Posługiwałem się też uparcie określeniami „klient” i „dostawca”, ale równie dobrze mógłbym posługiwać się nazwą ról: Zespół Developerski i Product Owner. To, czy role obsadzone są przez pracowników różnych firm czy jednej organizacji nie ma istotnego znaczenia dla mechaniki Scruma.

Nie będę ukrywał, że moim celem było zaszczepienie w umysłach czytelników myśli, że w modelu klient-dostawca również 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).

Klient lub Product Owner nie może w sposób znany z tradycyjnych metod „odbierać” zrealizowanych wymagań na koniec sprintu, bo są one odzwierciedleniem jego lub jej decyzji produktowych. Ostatecznym sprawdzianem tego, czy rozwiązanie jest dobre, nie będzie nawet przegląd sprintu i feedback od interesariuszy, ale reakcja użytkowników produktu, jeśli zapadnie decyzja o jego wydaniu. 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 roli Product Ownera: jeśli dopiero na przeglądzie 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 dla nas zrobili” i rozliczyć ich z wykonanej pracy. A przecież powinien być gospodarzem, który interesariuszom prezentuje co zbudował dla nich zespół w oparciu o jego wybory i decyzje produktowe.