W trzeciej części cyklu opisuję, jak stworzyć Definicję Ukończenia, która uwzględnia, czym jest produkt, jakie standardy ma spełniać i jakie potrzeby Developerów trzeba zaspokoić, by byli w stanie skutecznie ten produkt budować. Wyjaśniam kto i w jakim momencie Definicję powinien stworzyć i kiedy można ją zmienić. Pora napisać o stosowaniu Definicji w Sprintach.
Jak często wymogi Definicji Ukończenia powinny być spełnione?
Odpowiedź: za każdym razem, gdy Zespół twierdzi, że ukończył pracę nad zmianą w produkcie, zwykle nie rzadziej niż raz na Sprint (oczywiście przed jego zakończeniem).
Marne Zespoły wytwarzają w Sprincie jeden Przyrost tuż przed Przeglądem Sprintu albo wręcz im się to nie udaje – czyli są w stanie spełnić warunki zawarte w Definicji Ukończenia raz w Sprincie, albo i wcale. Dobre Zespoły potrafią to zrobić (i uzyskać nowy Przyrost) wiele razy w Sprincie, nierzadko codziennie, a są i takie, które robią to dosłownie co chwilę.
Jeśli Zespół ma Definicję Ukończenia, ale planuje spełnienie jej wymogów dopiero po kilku Sprintach ciągłego developmentu, nie ma to nic wspólnego ze Scrumem. Dlaczego? Na koniec każdego ze „Sprintów” (celowo w cudzysłowie), w których Zespół nie wytwarza Przyrostów, nie ma czego poddać sprawdzeniu, dlatego dalsze działania planowane są na podstawie przewidywań i założeń zamiast faktów. Jedyne, co wiadomo na pewno, to że jeszcze nic nie zostało ukończone.
Im dłuższy jest okres, w którym Zespół nie wytwarza niczego nadającego się do użycia, tym trudniej empirycznie kontrolować proces rozwoju produktu. Od pewnego momentu samo ustalenie, jaki jest jego aktualny stan, zaczyna być problematyczne, a w końcu staje się niemożliwe. Tym samym rośnie ryzyko, że rozwój podąży w zupełnie niewłaściwą stronę – nie da się sprawdzić, jak działa produkt, dopóki trwa development, a wszelkie przewidywania odnośnie do efektów, jakie przyniesie zakończenie prac, mogą okazać się chybione.
Czy niewłaściwy produkt może spełniać warunki zawarte w Definicji Ukończenia?
Oczywiście, że tak. Definicja Ukończenia określa, jak powinien być budowany produkt, ale nie mówi, jaki produkt powinien powstać. O tym w Scrumie decyduje Product Owner, zarządzając jednym z artefaktów, jakim jest Backlog Produktu.
Posłużmy się przykładem, żeby wyklarować tę kwestię. Przyjmijmy, że produktem jest książka – nie jej pojedynczy egzemplarz, ale wszystko, co potrzebne, by trafiła ona do druku po tym, jak autor przygotował manuskrypt, Definicja Ukończenia odpowiadać będzie za to, by faktycznie doszło do pojawienia się papierowych egzemplarzy książek na półkach w księgarniach. Będzie więc określać, jak powinien być robiony skład, jak przygotować matryce do druku itd. Nie będzie za to nijak wpływać na merytoryczną zawartość książki, nie uczyni jej ani trochę lepszą czy gorszą, zapewniając jedynie, że książka jako taka zostanie wydana.
A wtedy może okazać się, że jest to szmira, której nikt nie chce kupić ani czytać choćby za darmo. Wciąż jednak będzie to książka. Definicja Ukończenia produktu, jaki ona stanowi, będzie więc spełniona.
Nie jest natomiast możliwy odwrotny scenariusz, czyli powstanie nadającego się do użycia produktu mimo zignorowania zapisów Definicji Ukończenia. Ta Definicja opisuje minimum jakościowe, które spełniać musi produkt, zanim ktokolwiek zacznie z niego korzystać. Jeśli proces wydawniczy z wcześniejszego przykładu doprowadziłby do powstania ryzy luźnych kartek, poukładanych nie po kolei, z rozmazującym się drukiem, nieprzygotowanych do druku masowego, nie będzie można nazwać jej książką. Choćby treść zawarta na kartkach zasługiwała na Nobla, wartość takiego „produktu” będzie dokładnie zerowa.
Inny przykład, którym często się posługuję: jeśli produktem byłyby krzesła (a dokładniej cały proces ich wytwarzania), Definicja Ukończenia ma zapewnić, że powstaną meble, na których da się bezpiecznie siedzieć. Nie spowoduje natomiast, że stylistyka, kolory i materiały będą takie, jakich chcą klienci. Jeśli zapisy Definicji Ukończenia są spełnione, to nawet jeśli wygląd krzeseł jest zupełnie niewłaściwy, da się ich używać. Natomiast jeśli zamiast prawdziwych mebli powstaną delikatne i kruche makiety, pełna zgodność ich wyglądu z oczekiwaniami klientów nie spowoduje, że będzie można na tych makietach usiąść.
Kryteria akceptacji a Definicja Ukończenia
Warto przy okazji wspomnieć, że wiele Zespołów Scrum popełnia swego rodzaju błąd, zawierając w Definicji Ukończenia twardy wymóg spełnienia wszystkich kryteriów akceptacji, jakie zostały zdefiniowane dla wymagań zrealizowanych w Sprincie. Czemu to błąd?
Aby sprawdzić, czy kryteria akceptacji zostały spełnione, czyli czy powstał właściwy produkt, trzeba najpierw upewnić się, że produkt w ogóle powstał. O tym, czy tak się stało, rozstrzyga Definicja Ukończenia, a dokładniej zaspokojenie zawartych w niej warunków. Jeśli jednym z nich będzie spełnienie wszystkich kryteriów akceptacji, wymagać to będzie sprawdzenia, że funkcjonalności produktu działają zgodnie z oczekiwaniami, zanim ten produkt powstanie. Z drugiej strony, walidowanie rozwiązań, których development wciąż trwa, nie ma żadnego sensu, bo ich stan i sposób działania może ulec zmianie niekoniecznie wprowadzonej celowo.
Inaczej mówiąc, w myśl zasad logiki formalnej, nie da się nigdy doprowadzić do jednoczesnego spełnienia wszystkich zapisów tak skonstruowanej Definicji Ukończenia.
Odkładając logikę na bok: taki zapis może doprowadzić do naprawdę dziwnych sytuacji i ponurych długoterminowych konsekwencji. Wróćmy do przykładu z krzesłami i przyjmijmy, że w kryterium akceptacji jakiegoś wymagania zawarto wymóg obicia siedziska zielonym materiałem. Jeśli Developerzy dostarczą krzesła z obiciem niebieskim, to po sprawdzeniu warunków zawartych w Definicji Ukończenia – w tym tego związanego z kryteriami akceptacyjnymi – należy uznać, że żadne krzesła nie powstały.
Oczywiście nikt nie będzie utrzymywał, że krzesła nie są krzesłami, a zapis wymagający, by kryteria akceptacji były spełnione, zostanie najzwyczajniej zignorowany. Jestem pewien, że odbędzie się dyskusja, w której padną słowa o wyjątkowości sytuacji (tak, jakby była ona trudna do przewidzenia…), a także podkreślona zostanie konieczność pragmatycznego działania. Prawie na pewno nikt nie wpadnie na to, by wywalić z Definicji Ukończenia mało rozsądny warunek, bo przecież to ważne, by trzymać się kryteriów akceptacji!
Niestety, takie zdarzenia, a tym bardziej ich powtarzanie się od czasu do czasu, spowoduje erozję znaczenia Definicji Ukończenia. Skoro jakąś jej część można będzie „z dobrych powodów” traktować jako coś opcjonalnego, wcześniej czy później znajdą się powody, by zrobić to samo z innymi zapisami. Nie mówiąc już o tym, że w umysłach wielu osób zakiełkuje myśl, że „ta cała Definicja nie jest zbyt przydatna, skoro powoduje takie problemy”. A gdy te dwa zjawiska i negatywne trendy nałożą się na siebie, Definicja Ukończenia de facto przestanie działać i traktowana będzie jako zbiór zaleceń, które można w różnych sytuacjach ignorować.
Jest jeszcze drugi problem: wymóg spełnienia kryteriów akceptacji zawarty w Definicji Ukończenia wywiera presję na Developerów, by za wszelką cenę spełnić je wszystkie, bo bez tego nie powstanie formalnie żaden Przyrost. To może spowodować, że zamiast zbudować działający produkt, w którym niektóre kryteria akceptacji z dobrych powodów nie zostały spełnione, do ostatniej chwili trwać będzie walka, by zaspokoić je wszystkie – co niekoniecznie się uda.
Innym skutkiem będzie trzymanie się ustaleń zapisanych w kryteriach akceptacji również wtedy, gdy prowadzić to będzie do powstania produktu gorszego lub wręcz marnego. Developerzy często przecież odkrywają dopiero w trakcie developmentu nowe możliwości, których wykorzystanie przyniesie wymierne korzyści interesariuszom. Zdarza się też, że kryteria akceptacji kierują Developerów na manowce. Powiązanie Definicji Ukończenia z kryteriami akceptacji będzie w każdej z takich sytuacji wymagać przedefiniowania tych ostatnich w trakcie Sprintu, co zabiera czas i niekoniecznie się uda (wszystko zależy od tego, kto kryteria te sporządził i czy jest skłonny do ich zmiany). Mając do wyboru zbudowanie czegoś, co działa, choć nie jest najlepsze, albo niedostarczenie niczego, co wybiorą Developerzy?
A przecież Scruma używa się po to, by lepiej radzić sobie z nieprzewidywalnością i niestabilną złożonością. Skąd więc przekonanie, że mimo niespełnienia kilku z kryteriów akceptacyjnych produkt nie okaże się naprawdę dobry w oczach interesariuszy? Skąd pewność, że spełnienie wszystkich kryteriów jest faktycznie potrzebne i korzystne? Skąd wiara, że kryteria akceptacji są właściwe i jest sens je wszystkie spełniać?
Nie stawiam tezy, by celowo ignorować wymagania czy kryteria akceptacyjne. Niemniej Zespół powinien mieć intencję ich spełnienia, a nie być do tego zmuszany zapisami z Definicji Ukończenia. Wymagania wraz z ich kryteriami akceptacji to coś osobnego, równoległego, równie ważnego. Definicja będzie pomagać Zespołowi w decyzjach odnośnie do tego, jak budować produkt, a wymagania (i kryteria akceptacji, jeśli są zdefiniowane), w decyzjach o tym, jaki produkt ma powstać. Przy czym to drugie ma żadne znaczenie, jeśli zapomnimy o tym pierwszym, bo żaden produkt wtedy nie powstanie.
Czy Przyrost może powstać w sposób niezgodny z Definicją Ukończenia?
Nie jest to zapewne oczywiste, ale tak, to możliwe, choć jest to sytuacja wyjątkowa. W praktyce spotkałem się z nią tylko raz, a i wtedy mieliśmy wątpliwości, czy słusznie czynimy. Mimo to dla kompletności mojej opowieści o Definicji napiszę i o takiej możliwości.
Na początek przypomnę, czym jest Definicja Ukończenia. To narzędzie zapewnienia przejrzystości stanu produktu będące zobowiązaniem Zespołu do wytwarzania produktu w sposób, który pozwoli osiągnąć przynajmniej minimalny wymagany poziom jakości.
Każdy zapis w Definicji jest deklaracją intencji Zespołu, który zamierza posłużyć się określonym procesem, praktykami i narzędziami po to, by zaspokoić potrzeby interesariuszy. Nie chodzi o bezmyślne trzymanie się jakiejś listy warunków, ale o rzeczywistą intencję uzyskania odpowiedniej jakości poprzez postępowanie wedle ustalonych zasad.
Może okazać się, że Zespół odkryje, iż nie da się zbudować produktu w sposób, na jaki się umówił (czyli zgodnie z Definicją Ukończenia), ale jest to możliwe w nieco inny sposób, dający taki sam lub wyższy poziom jakości. W tej sytuacji Zespół ma prawo świadomie zdecydować o wykonaniu działań innych, niż wynikałoby to z ustaleń zawartych w Definicji Ukończenia. I będzie to zgodne z zasadami Scruma, ponieważ:
- Definicja Ukończenia stoi na straży jakości i przejrzystości stanu produktu, a postępowanie Zespołu nie powoduje spadku ani jednego, ani drugiego.
- Celem Scruma jest wykreowanie wartości dla interesariuszy, a nie wymuszenie arbitralnego procesu, więc działania, które nie stoją w jawnej sprzeczności z zasadami Scruma, a sprzyjają uzyskaniu wartości, nie mogą być w Scrumie niedozwolone.
Zanim jednak ktokolwiek ochoczo rzuci się do stosowania tego schematu w swoim Zespole, warto wymienić warunki, które muszą być jednocześnie spełnione, by uznać takie postępowanie za zgodne z regułami Scruma:
- Decyzję podejmuje cały Zespół Scrum (nie sami Developerzy, a już zdecydowanie nie może to być samodzielna decyzja pojedynczego Developera).
- Nie istnieje realnie inny sposób zbudowania produktu, który nada się do użycia (nie chodzi więc o kupienie sobie czasu, czyli zrobienie czegoś szybciej niż zwykle, tylko o niemożność wykonania – z przyczyn obiektywnych – działania takiego, jakiego wymaga Definicja Ukończenia).
- Działanie Zespołu pozwoli na realne uzyskanie wartości (korzyści dla interesariuszy) bez wygenerowania dodatkowego ryzyka np. wynikającego z czynienia optymistycznych założeń lub zaciągania długu technicznego.
- Zespół, decydując się na niestandardowe postępowanie, ma pewność, że produkt będzie miał taką jakość, jaką opisują zasady Definicja Ukończenia, lub że jakość ta będzie jeszcze wyższa.
- Odstępstwo nie dotyczy całej Definicji, ale jej niewielkiej części, a najlepiej wyłącznie jednego zapisu.
- Jest to sytuacja wyjątkowa, a nie rutynowe postępowanie Zespołu.
- Interesariusze poinformowani zostaną o tym, w jaki sposób uzyskany został Przyrost.
- Zespół zamierza na koniec Sprintu rozszerzyć Definicję Ukończenia tak, by w specyficznych, jasno określonych warunkach od kolejnego Sprintu dopuszczalne było takie działanie, jakie zamierza teraz wyjątkowo podjąć.
Ostatni punkt jest kluczowy, bo wskazuje, że Zespół nie ignoruje Definicji Ukończenia, tylko dąży do zapewnienia wymaganej przez nią jakości, choć już wie, że Definicja jest niekompletna i wymaga zmiany. Jednocześnie jest to zmiana krytyczna dla możliwości zbudowania działającego rozwiązania bez utraty jego jakości.
Teoretycznie Zespół mógłby dokonać zmiany Definicji od razu, ale tak jak pisałem wcześniej, lepiej odłożyć to do Retrospekcji Sprintu, żeby nie ulec pokusie dostosowywania wymaganego poziomu jakości po to, by dowieźć wszystko przed końcem Sprintu.
Przykład, z jakim się zetknąłem osobiście: Definicja Ukończenia wymagała, by tworzone były testy jednostkowe do każdego kawałka kodu, jaki został zmieniony w ramach prac developerskich. Stosowane narzędzia nie pozwalały tego zrobić w specyficznym, starym komponencie, nierozwijanym od lat. Żeby to umożliwić, niezbędne byłoby jego znaczące przebudowanie, co nie miało sensu ekonomicznego.
Dlatego Zespół nie stworzył testów jednostkowych, tylko zapewnił rozszerzony przegląd kodu (ang. code review) przez dwóch ekspertów, znających ten komponent i jego technologię. Choć formalnie Definicja nie została spełniona, to jednak poziom jakości, jaki miała zapewnić, w opinii Zespołu został dochowany.
Definicja Ukończenia została na koniec Sprintu zmodyfikowana. Przy czym dzięki temu, że dyskusja odbywała się na spokojnie w trakcie Retrospekcji, zamiast pozornie oczywistego zapisu, wyłączającego z obowiązku pisania testów jednostkowych cały ów stary komponent, pojawił się bardziej pragmatyczny warunek: Zespół każdorazowo zdecyduje wspólnie, czy w przypadku trudności ze stworzeniem testów jednostkowych można zastąpić je rozszerzonym przeglądem kodu.
Zwracam uwagę, że takie sformułowanie w Definicji Ukończenia pozwoliło na pominięcie pisania testów jednostkowych w każdym komponencie (nie tylko tym archaicznym), a jednocześnie wciąż wymagało tworzenia ich dla każdej zmiany (również w tym problematycznym komponencie), o ile tylko da się to zrobić.
Czy nastąpiło rozluźnienie wymogów jakościowych? Nie. Stały się one bardziej elastyczne, ale poziom jakości wymagany był wciąż taki sam, jedynie sposoby zapewniania tej jakości nieco się zmieniły. Z drugiej strony decyzję podejmować miał cały Zespół, co ograniczyło ryzyko, że dla wygody albo z pośpiechu jakiś Developer nie zrobi testów jednostkowych tam, gdzie można je bez trudu napisać.
Wspominam o tej sytuacji, by pokazać pragmatyzm Scruma i elastyczność jego elementów, w tym Definicji Ukończenia. Zdecydowanie nie należy tego traktować jako podpowiedź, jak można omijać Definicję Ukończenia. Tu nie została ona ominięta dla wygody Developerów, bo w praktyce zapewnienie tego samego poziomu jakości okazało się dużo trudniejsze (znalezienie ekspertów, którzy szybko zrobią dobry przegląd kodu, było wyzwaniem). Z drugiej strony Zespół kierował się potrzebą zracjonalizowania działań – próba dostosowania bardzo trudnego starego kodu do standardów obecnie obowiązujących w tym przypadku byłaby nieuzasadniona ekonomicznie.
To przy okazji pokazuje też, że Definicja Ukończenia może zawierać zapisy, których stosowanie jest uzależnione od jakichś jasno określonych warunków. Oczywiście to czyni ją mniej czytelną i łatwo może doprowadzić, że przestanie być jednoznaczna, albo wręcz stanie się nieskuteczna. Dlatego takie działanie powinno być czymś ostatecznym, a nie pierwszym wyborem Zespołu, gdy tworzy on swoją Definicję Ukończenia.
Definicja poskładana z kawałków
A skoro już mowa o komponentach, z jakich może składać się produkt: czy Definicja Ukończenia dotyczyć tylko kilku z nich, niekoniecznie wszystkich? Nie, nie może.
Definicja Ukończenia obejmuje produkt jako całość, czyli zarówno to, co w produkcie zmieniło się w wyniku działań Zespołu w bieżącym Sprincie, jak i wszystko inne, co w produkcie znajdowało się do tej pory. Inaczej mówiąc, dokonując zmian w produkcie, Zespół Scrum musi zapewnić ciągłość działania tego produktu jako całości. Jeśli na produkt składa się wiele komponentów, Definicja obejmuje je wszystkie.
Wracając do przykładu z krzesłami, jakim posługiwałem się wcześniej: jeśli zmiana polega na zastąpieniu obicia skórzanego materiałowym (czyli dotyczy tylko jednego komponentu), krzesła wciąż muszą być krzesłami. Gdyby w wyniku wymiany obicia meble przestały nadawać się do siedzenia, ciężko mówić o powstaniu Przyrostu wartości, prawda?
Natomiast bywa tak, że produkt składa się z komponentów, które tworzone były historycznie z różnymi standardami jakości i dziś ich jakość nie jest spójna. Jeśli nie ma możliwości jej wyrównania w górę (w dół nie miałoby to w oczywisty sposób sensu), ciężko będzie objąć jednym zbiorem zapisów cały produkt w Definicji Ukończenia. Co wtedy?
Można posłużyć się wspomnianym już wcześniej mechanizmem warunków, które określą, jakie zapisy obowiązują dla poszczególnych obszarów produktu (w tym przypadku: jakie zapisy dotyczą każdego z komponentów). Istnieje niezerowe ryzyko, że Definicja Ukończenia rozpadnie się na szereg „Definicji Ukończenia” komponentów, co byłoby sprzeczne z ideą Definicji w Scrumie. Dlatego wprowadzając ową wariantowość zapisów, trzeba wciąż traktować Definicję jako spójną całość. Będzie długa, mało czytelna i trudna w stosowaniu, ale przynajmniej jedna.
Lepszym pomysłem jest ustalenie, że do każdej zmiany, jaką Zespół wprowadza do produktu, obowiązują najwyższe ze wszystkich standardów, a jednocześnie nie może dojść do pogorszenia stanu któregokolwiek z komponentów, czyli zejścia poniżej poziomu jakości, jaki miał do tej pory. Inaczej mówiąc, Definicja nie wymaga dociągnięcia wszystkich komponentów na najwyższy poziom jakości od razu w całości, ale wymaga robienia tego na raty w każdym kawałku, jaki jest na bieżąco modyfikowany przez Developerów. Z czasem jakość wszystkich komponentów ogólnie się podniesie, a niewykluczone, że zupełnie się wyrówna (oczywiście w górę, nie w dół).
Przykłady Definicji
Do tematyki Definicji Ukończenia wrócę już niedługo i omówię kilka przykładowych zapisów z różnych Definicji, rozważając ich słabości i podpowiadając, jak można je wyeliminować. Dla osób, które nie zetknęły się z Definicją w praktyce i są ciekawe, jak może ona wyglądać, może stanowić to inspirację i zapewne pozwoli lepiej zrozumieć sam Scrum.