W trzeciej części artykułu opisuję, jak stworzyć Definicję Ukończenia, która uwzględnia to, czym jest produkt, jakie standardy ma spełniać i jakie potrzeby Developerów trzeba zaspokoić, by byli w stanie skutecznie budować produkt. Wyjaśniam kto i kiedy Definicję powinien stworzyć i kiedy można ją zmienić. Pora napisać o stosowaniu Definicji w Sprintach.

Jak często Definicja Ukończenia powinna być spełniona?

Za każdym razem, gdy Zespół twierdzi, że ukończył pracę nad produktem, zwykle nie rzadziej niż raz na Sprint (oczywiście przed jego zakończeniem).

Marne Zespoły uzyskują w Sprincie Przyrost tylko raz, tuż przed Przeglądem Sprintu, albo wręcz im się to nie udaje – czyli udaje im się spełnić Definicję raz w Sprincie, albo i wcale. Dobre Zespoły potrafią spełnić Definicję Ukończenia (i uzyskać nowy Przyrost) wiele razy w Sprincie, nierzadko codziennie, a są i takie, co robią to dosłownie co chwilę.

Jeśli Zespół ma Definicję Ukończenia i planuje jej spełnienie dopiero po kilku Sprintach, w których będzie nad czymś intensywnie pracował – to nie ma nic wspólnego ze Scrumem. Dlaczego? Bo w takim modelu pracy niemożliwy jest empiryzm. Na koniec tych „Sprintów” (celowo w cudzysłowie), w których Zespół nie ma intencji realnie nic ukończyć, nie ma Przyrostu, nie ma więc co poddać sprawdzeniu.

Jedyne, co wiadomo na pewno, to że jeszcze nic nie zostało ukończone. Każda inna ocena postępu prac będzie jedynie spekulacją, a to nie ma nic wspólnego z empiryzmem. To oznacza, że przez kilka „Sprintów” decyzje o kontynuacji prac podjęte będą na bazie prognoz i założeń, nie faktów.

Czy niewłaściwy produkt może spełniać Definicję 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 jedynie 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 powstanie.

Może okazać się, że powstanie książka, która jest totalną szmirą, 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 oczywiście możliwy odwrotny scenariusz: że powstanie produkt, mimo iż Definicja Ukończenia nie jest spełniona. Przyjmując, że w naszym przykładzie Definicja Ukończenia określała, jak ma być wytwarzana książka: jeśli produkt powstanie niezgodnie z nią i będzie stanowił ryzę luźnych kartek, poukładanych nie po kolei, z rozmazującym się drukiem, nieprzygotowanych do druku masowego – nie będzie można nazwać go 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, Definicja Ukończenia ma zapewnić, że powstanie mebel, na którym da się usiąść, ale nie zapewni, że ma on wygląd, kolory i materiały takie, jakich oczekuje użytkownik. Jeśli Definicja taka będzie spełniona, na krześle będzie się dało siedzieć, nawet jeśli będzie ono odległe od oczekiwań. Z drugiej strony coś, co wygląda idealnie, ale jest jedynie makietą i nie da się na tym czymś usiąść, nie jest krzesłem.

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 wymagań, jakie były zrealizowane w Sprincie (np. poprzez zaspokojenie zdefiniowanych w tych wymaganiach kryteriów akceptacji). Czemu to błąd?

Aby w ogóle sprawdzać, czy wymagania zostały spełnione, czyli czy powstał właściwy produkt, trzeba najpierw spowodować, by produkt powstał w ogóle. O tym, czy powstał, rozstrzyga Definicja Ukończenia. Tyle że aby ona była spełniona, musimy potwierdzić, że powstał właściwy produkt, czego nie możemy sprawdzić, zanim produkt nie powstanie, czyli zanim Definicja nie będzie spełniona… ot, logiczny problem „jajka i kury”.

Odkładając logikę na bok: taki zapis jest nienajlepszy z dwóch innych powodów. Po pierwsze, może doprowadzić do naprawdę dziwnych sytuacji. Wróćmy do przykładu z krzesłem: jeśli w kryterium akceptacji jakiegoś wymagania związanego z tym krzesłem jest napisane, że obicie siedziska ma być zielone, a Developerzy dostarczą krzesło z obiciem niebieskim, w myśl Definicji Ukończenia wymagającej, by wszystko, co zapisane w wymaganiach, było spełnione, Developerzy muszą powiedzieć „nie powstało krzesło”. Serio!? Czym więc jest mebel, jaki wytworzyli, jeśli nie krzesłem?

Efektem tej absurdalnej sytuacji będzie uznanie, że krzesło jednak powstało, natomiast jeden z zapisów Definicji (ten wymagający, by wymagania były co do joty spełnione) stanie się „opcjonalny”. Bardzo szybko i inne mogą zostać potraktowane w ten sam sposób. Pożegnamy się z „binarnością” Definicji, czyli de facto Zespół przestanie mieć Definicję Ukończenia.

Po drugie, i chyba o wiele ważniejsze: wymóg spełnienia kryteriów akceptacji w Definicji Ukończenia wywiera presję na Developerów, by za wszelką cenę spełnić je wszystkie. Bez tego nie powstanie formalnie żaden Przyrost. To może spowodować, że zamiast mieć jakiś poprawnie zrobiony 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.

A przecież Scruma używa się po to, by 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 nie okaże się, iż produkt jest naprawdę dobry w oczach interesariuszy? Skąd pewność, że spełnienie wszystkich kryteriów okaże się faktycznie potrzebne? 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. Nie, Zespół powinien mieć intencję ich spełnienia, ale nie jako coś wymuszonego Definicją Ukończenia, tylko jako 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 można spełnić Definicję Ukończenia nie trzymając się jej zapisów?

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 (jego jakości i tego, co zostało zrobione, by powstał), będące zobowiązaniem Zespołu, że będzie w określony sposób ten produkt wytwarzał i zapewni jego odpowiednią jakość.

Skoro tak, każdy zapis jest wyrazem intencji Zespołu, by zapewnić jakość, wynikającym z potrzeby osiągnięcia konkretnego celu związanego z jakością. 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ół świadomie zdecyduje się wykonać inne działanie, niż wynikałoby to z ustaleń zawartych w Definicji Ukończenia. I będzie to zgodne z zasadami Scruma, bo:

  • 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 duchem 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.
  • 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 jej 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ć, został dochowany w opinii Zespołu.

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 zapis: 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 warunku 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 tej jakości zapewniania 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, że stanie się zwyczajnie 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łem, 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ło wciąż musi być krzesłem. Gdyby w wyniku wymiany obicia mebel przestał 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 jakich aspektó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ół).

Już wkrótce

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.