Blog

Jednym z kluczowych pojęć w Scrumie jest Definition of Done, czyli po polsku Definicja Ukończenia lub Kryterium Ukończenia. I tak jakoś się dzieje, że sprawia sporo kłopotów licznym Zespołom, które posługują się Definicjami Ukończenia marnymi, albo nie mają ich wcale. Najbardziej zaskakuje, że mimo jednoznacznego opisu, jaki dostarcza Scrum Guide, Definition of Done bywa często mylone z kryteriami akceptacji wymagań.

Po ludzku: co to jest Definition of Done?

Jeśli wytwarzamy samochody, to Definicja Ukończenia będzie określać warunki, jakie spełnić ma produkt, który można nazwać samochodem. Musi on przede wszystkim jeździć, zatem musi mieć koła, napęd, układ kierowniczy oraz hamulce. A precyzyjniej rzecz ujmując:

• koła muszą faktycznie się obracać i pozwalać jechać wytyczoną przez kierowcę trasą;
• napęd musi faktycznie generować niezbędną moc i moment obrotowy, pozwalające rozpędzić pojazd;
• układ kierowniczy musi faktycznie pozwalać na kontrolowanie toru jazdy samochodu;
• hamulce muszą faktycznie pozwolić na zatrzymanie rozpędzonej masy.

Oznacza to, że aby można było powiedzieć, iż powstał samochód, nie wystarczy dysponować potencjałem jego poskładania z części, ale trzeba wytworzyć jeżdżący egzemplarz, pozwalający na potwierdzenie zgodności wszystkich cech z wymogami prawnymi, normami bezpieczeństwa, środowiskowymi itd.

Definition of Done nie determinuje natomiast zupełnie, czy samochód ma być kabrioletem, kombi czy roadsterem, jaki ma mieć bagażnik, kolor nadwozia czy tapicerkę – to już cechy pojazdu wynikające z potrzeb biznesowych, które opisane będą poszczególnymi wymaganiami. Definicja Ukończenia ma na te wymagania wpływ taki, że wymusi, by zostały zaspokojone w sposób, który nie spowoduje, iż samochód przestanie być samochodem.

Inny przykład: wydajemy książki. Definition of Done określi, co jest książką: połączony w całość zbiór kartek w jednym ze standardowych formatów, zadrukowany wedle unormowanych zasad. Kartki muszą być wpięte w poprawnej kolejności, nie mogą wypadać, druk nie może się rozmywać, farba i klej nie są toksyczne. Książka musi mieć okładkę, w treści nie powinno być błędów ortograficznych, gramatycznych czy rzeczowych. Skład tekstu (jego łamanie) trzyma się standardowych zasad typograficznych… Lista wymogów, które spełnić musi książka, jest całkiem rozbudowana.

Natomiast Definicja Ukończenia nie wskaże, ile ma być rozdziałów, ani czy w ogóle w książce będą jakieś rozdziały. Nie narzuci rozmiaru ani kroju czcionki (choć pewnie narzuci wymóg czytelności tekstu i może ograniczać wybór do takiego zakresu, jaki realnie da się zastosować w druku). O tym, czy okładka będzie twarda, czy miękka, czy w treści będą jakiekolwiek obrazki, a jeśli tak, czy drukowane w kolorze – również nie decyduje Definicja Ukończenia, tylko wymagania biznesowe. Definicja będzie jedynie stać na straży, by okładka była okładką, by obrazki pełniły swoją funkcję, by przygotowane zostały do druku w sposób, jakiego wymagają maszyny drukarskie itd.

Jeszcze jeden przykład: robimy oprogramowanie (a jakże, przykład z branży IT zawsze w cenie, gdy mowa o Scrumie). Definition of Done wymagać będzie, aby napisany kod dało się uruchomić jako jedno zintegrowane rozwiązanie, w którym działają zarówno poprzednio istniejące funkcjonalności, jak i rzeczy dołożone w bieżącym Sprincie. To oprogramowanie musi spełniać standardy technologiczne, mieć oczekiwaną wydajność i stabilność itd., a jeśli to potrzebne, wytworzyć trzeba również aktualną dokumentację techniczną.

Definition of Done dla oprogramowania nie determinuje wszakże, jak wyglądać ma graficzny interfejs użytkownika (i czy w ogóle będzie jakiś interfejs), jakim algorytmem mają być przeliczane dane księgowe, jakie operacje wymagają nadania użytkownikowi specyficznych uprawnień, ani tego, czy w środku nocy będzie robiona „przerwa konserwacyjna”, podczas której produkt jest niedostępny. To wszystko wymagania biznesowe, opisujące sposób działania oprogramowania, a nie sposób, w jaki należy go wytworzyć.

Czym są kryteria akceptacji?

Kryteria akceptacji albo kryteria akceptacyjne to praktyka polegająca na umieszczaniu w wymaganiach (np. w elementach Backlogu Produktu) informacji o tym, jakie są kluczowe warunki, które spełnić musi rozwiązanie, by było ono wartościowe z punktu widzenia użytkowników produktu.

Uwaga: nie chodzi o „warunki formalnego odbioru” ani inny tego rodzaju bełkot, ale o sposób potwierdzenia skuteczności rozwiązania problemu opisanego wymaganiem lub zaspokojenia wskazanej w nim potrzeby.

Tym samym kryteria akceptacji nie mówią, jak zbudowany ma być produkt, ale raczej jaki produkt ma powstać, bo wskazują, jakie cechy ma wartościowy produkt lub w jaki sposób wartościowy produkt działa.

Co oczywiste, kryteria akceptacji dla każdego wymagania będą różne, bo też wymagania dotyczą zupełnie różnych problemów i potrzeb. Z drugiej strony nie mogą się wykluczać wzajemnie, bo zaspokojone zostać muszą w jednym produkcie. Stąd czasami pojawia się konieczność uwzględnienia zależności pomiędzy różnymi wymaganiami, by zapewnić spójność produktu jako całości.

Jest też jedna zasadnicza różnica pomiędzy Definicją Ukończenia i kryteriami akceptacyjnymi w Scrumie. Stworzenie Definicji i praktyczne jej stosowanie jest wymagane, natomiast kryteria akceptacji stanowią opcjonalną praktykę, po którą Zespoły mogą, ale nie muszą sięgnąć.

Różne pytania, różne narzędzia

Rozwój produktu wymaga nieustannego poszukiwania odpowiedzi na kilka różnych pytań.

Pierwszym jest pytanie o to, jakie są potrzeby i problemy interesariuszy, czyli np. klientów i użytkowników korzystających z produktu. Odpowiedzią na to są wymagania, a w Scrumie elementy Backlogu Produktu.

Drugie pytanie dotyczy tego, jak zbudować produkt, który nadaje się do użycia – na co w Scrumie odpowiedzią jest właśnie omawiana wcześniej Definicja Ukończenia i wynikający z niej plan działania Developerów w każdym Sprincie.

Trzecia kwestia to ustalenie, jaki produkt będzie miał największą wartość i tutaj można posłużyć się kryteriami akceptacyjnymi. Nie mogą zastąpić one wymagań (bo stanowią ich uzupełnienie), nie mogą też być zastąpione Definicją Ukończenia, która zajmuje się zupełnie innym aspektem rozwoju produktu.

Można więc powiedzieć, że tak, jak Definicja Ukończenia stanowi określenie wymaganej minimalnej jakości strukturalnej produktu (tego, jak ma on być budowany), tak kryteria akceptacji są określeniem wymaganej minimalnej jakości funkcjonalnej lub użytkowej produktu (tego, jaki produkt powinien powstać).

Parę słów o kolejności

Z faktu, że Definicja Ukończenia opisuje warunki, jakie muszą zostać spełnione, aby rozwiązanie wytworzone przez Developerów można było w ogóle uznać za działający produkt, pojawia się oczywisty wniosek: dopiero po spełnieniu jej wymogów da się sprawdzić, czy zaspokojone zostały wymagania biznesowe. A jeszcze kolejnym krokiem jest walidacja, czyli potwierdzenie wartości z użyciem kryteriów akceptacyjnych.

Wracając do przykładów z początku artykułu: jaki sens jest dywagować na temat skuteczności działania układu ABS w samochodzie, który nie jeździ i został tylko częściowo poskładany w całość? Jaki sens ma sprawdzanie, czy skład graficzny pozwala na komfortowe czytanie powieści, jeśli książka nie została w ogóle zszyta i zamocowana w okładce? I wreszcie: jaki sens ma sprawdzanie, czy walidacja formatu danych wpisywanych do formularza na stronie internetowej działa poprawnie, jeśli nie są dostępne inne funkcje niezbędne do tego, aby użytkownik w ogóle mógł dojść do wyświetlenia tegoż formularza?

Widać tu przy okazji, jak nielogiczny jest zapis, który często widzimy w Definition of Done różnych Zespołów: „kryteria akceptacji dla wszystkich wymagań realizowanych w Sprincie są spełnione”. Ten warunek nigdy nie może zostać zaspokojony. Czemu?

Aby spełnić ten warunek, trzeba dokonać sprawdzenia, że rozwiązanie odpowiada na potrzeby biznesowe i to w sposób właściwy (czyli muszą być spełnione wymagania w myśl zawartych w nich kryteriów akceptacji). Sprawdzenia takiego nie da się zrobić bez dysponowania działającym rozwiązaniem. Czyli takim, które spełnia wymogi Definicji Ukończenia, włącznie z feralnym zapisem o konieczności zaspokojenia kryteriów akceptacji… Kręcić zaczynamy się w kółko, nieprawdaż?

Dlatego rozdzielić należy Definition of Done i kryteria akceptacyjne, po czym zaspokajać wszystkie wymogi po kolei. Najpierw stworzyć rozwiązanie, które w ogóle działa (czyli odpowiadające wymogom Definicji Ukończenia), potem zweryfikować, że działanie to zgodne jest z zapisami wymagań, a na koniec potwierdzić wartość z użyciem kryteriów akceptacji.

Oczywiście w całym tym procesie od samego początku Developerzy mają świadomość zarówno treści wymagań, jak i ewentualnych kryteriów akceptacji, jakie są w nich zawarte i budują produkt taki, który w ich przekonaniu będzie właściwy. Nie mogą jednak twierdzić, że „spełnione zostały wymagania!”, zanim nie sprawdzą (w opisanej powyżej kolejności), że faktycznie udało się to zrobić.

I nie chodzi tu o formalizm ani „niepotrzebne filozofowanie”, lecz o twardy pragmatyzm. Tworzenie produktów „prawie gotowych” to plaga, z którą zmagają się tysiące organizacji i Zespołów, nie mówiąc już o tym, że prawdziwie empiryczne działanie wymaga twardego powiedzenia: albo coś jest naprawdę skończone i nadaje się do użycia, albo wciąż tego nie ma i nie wiadomo, czy kiedykolwiek powstanie. W ten sposób interesariusze nie są wprowadzani w błąd i mamieni promesą tego, jak będzie świetnie, gdy już tylko „dokończymy te drobiazgi”. Nie, nie będzie, bo „drobiazgi” pozostaną wiecznie nieukończone.

Cena za niezrozumienie wagi Definicji Ukończenia

Wiele Zespołów łudzi się, że osiągnie większą skuteczność, jeśli rozpocznie równolegle pracę nad wieloma (a czasem wszystkimi) wymaganiami podjętymi do realizacji w Sprincie. Maleje przez to szansa na prawdziwie zespołowe działanie, ale nawiązując do tematyki niniejszego artykułu, pojawia się coś jeszcze: presja na to, by sprawdzać per wymaganie, czy biznesowe potrzeby zostały spełnione. Brak wtedy dbania o to, by powstał jeden zintegrowany, w pełni działający produkt, spełniający jako całość wymogi zawarte w Definition of Done.

Skutkiem jest kuriozalna sytuacja, w której Zespół w czasie Przeglądu Sprintu informuje, że „Definition of Done jest spełnione dla ukończonych wymagań”, a dla tych, których ukończyć się nie udało, „Definition of Done spełnione nie jest”. Cóż to, u licha znaczy? Czy aby na pewno istnieje jeden działający produkt? Czy da się taki produkt przekazać komukolwiek do użycia? Czy ma on realną wartość, czy jest jedynie promesą jej uzyskania w przyszłości, gdy już (być może) uda się wszystko ukończyć? Warto o to dopytać…

Czemu Definition of Done jest takie ważne?

Scrum powstał jako odpowiedź na niską zdolność tradycyjnych metod do radzenia sobie ze złożonością i nieprzewidywalnością, które nierozerwalnie towarzyszą np. wytwarzaniu oprogramowania i wielu innym przedsięwzięciom. Często, mimo wykonania całego planu, na końcu powstawał produkt mało przydatny albo nie powstawało w ogóle nic zdatnego do użycia. Scrum, jak wszystkie metody zwinne, odchodzi od podejmowania decyzji na podstawie założeń i tworzenia na początku planu realizacji całego przedsięwzięcia. Zamiast tego posługuje się podejściem empirycznym.

Dzięki budowaniu produktów iteracyjnie i przyrostowo miarą postępu przestały być stwierdzenia w rodzaju „mamy zrealizowane już 74% wymagań”, a stał się nią działający produkt. Domniemania, że coś ma wartość i że będzie nadawało się do użycia, zastąpiła jasna informacja: takie funkcje i cechy produkt już posiada i można ich użyć, a takich w nim w ogóle nie ma.

Inaczej mówiąc, Scrum spowodował, że zamiast zajmować się realizowaniem planów, zajmujemy się (w końcu!) budowaniem działających produktów. Oczywiście pod warunkiem, że to, co wytwarzamy, faktycznie nadaje się do użycia.

I tu pojawia się podstawowa funkcja Definition of Done: zapewnia przejrzystość odnośnie do tego, co zostało ukończone, a jednocześnie czyni klarownym warunki, jakie muszą być spełnione, by produkt do użytku się nadawał. Właśnie dzięki Definicji Ukończenia można odpowiedzieć na pytanie, co w produkcie już jest, a czego tam wciąż nie ma. Odpowiada ono też na pytanie, czy produkt w ogóle powstał (bo bubel działający „na 99%” to wciąż nie produkt).

Na bazie takiej informacji da się podjąć decyzję, co robić dalej: dodawać nowe rzeczy, zmieniać te już istniejące, a może je usunąć, bo okazały się zbędne? Bez działającego produktu, w świecie opisywanym poprzez procenty zrealizowanego planu, to niewykonalne, ponieważ do spekulacji odnośnie do owych procentów dodajemy spekulacje odnośnie do tego, co warto robić dalej.

Definition of Done dotyczy produktu!

Wykrzyknik w powyższym zdaniu jest celowy. Definicja Ukończenia dotyczy każdego wymagania (a szerzej: elementu Backlogu Produktu) z osobna oraz produktu jako całości. Nie jest więc tworzona na potrzeby pojedynczych wymagań, ale jest zbiorem stałych wymogów odnośnie do sposobu budowania produktu.

Załóżmy, że Zespół nie wpadł w pułapkę utożsamiania Definicji Ukończenia z kryteriami akceptacyjnymi i nie próbuje też określać go osobno dla każdego wymagania. Czy mamy gwarancję, że działamy empirycznie i mamy przejrzystość? Oczywiście nie.

Zdarza się bowiem, że Definition of Done jest określane nie na poziomie produktu, ale osobno dla jego elementów składowych (różnych komponentów, funkcji, mechanizmów itd.). Cóż z tego, że taki komponent jest w pełni ukończony, skoro nijak nie gwarantuje to, że produkt działa? A musi działać, by dało się sprawdzić, na ile owo działanie odpowiada wymaganiom biznesowym…

Innym problemem, z jakim można się spotkać, to szereg różnych Definicji Ukończenia w Zespołach, które wspólne rozwijają jeden produkt. Każdy z tych Zespołów inaczej definiuje, co dla niego oznacza, że budowanie produktu zostało zakończone. W ostatecznym rozrachunku nie wiadomo, w jakim stanie jest produkt po kolejnych Sprintach. Jedynym dopuszczalnym rozwiązaniem w tej sytuacji jest wspólne uzgodnienie jednego Definition of Done i stosowanie go zarówno w odniesieniu do prac wykonywanych równolegle przez różne Zespoły, jak i całego produktu.

Sytuacje skrajne

No dobrze, powie ktoś, a co jeśli Definition of Done, opisujące produkt nadający się do użycia, wymaga umiejętności i praktyk niedostępnych dla Developerów? Czy mogą oni pracować w Scrumie, a jeśli tak, w jaki sposób? Temu tematowi poświęcony zostanie jeden z kolejnych artykułów.