Definition of Done, czym jest i jak stworzyć?

Posługując się określeniem z najnowszej wersji Scrum Guide’a z 2020 roku, Sprinty to puls Scruma (ang. heartbeat). Idąc krok dalej z powyższą analogią, Definition of Done będzie jego sercem. Bez regularnie dostarczanych Przyrostów, spełniających kryteria Definicji Ukończenia, nie możemy mówić o działającym Scrumie.

Czym jest Definition of Done?

Fundament frameworku Scrum stanowi pięć wartości – skupienie, otwartość, szacunek, odwaga i zaangażowanie. Ta ostatnia, wraz z aktualizacją Przewodnika po Scrumie w 2020 roku, została znacząco uwypuklona i dodana do wszystkich Scrumowych Artefaktów. Miało to na celu podkreślenie ich kluczowych cech w przejrzysty i ustrukturyzowany sposób. Są to odpowiednio:

• Product Backlog – zobowiązanie: Cel Produktu
• Sprint Backlog – zobowiązanie: Cel Sprintu
• Przyrost (Increment) – zobowiązanie: Definition of Done

Definition of Done to formalny opis stanu Incrementu, w którym spełnione są wszystkie kryteria jakościowe wymagane przez rozwijany Produkt.
„Done” oznacza, że zgodnie z posiadaną definicją, w danym zadaniu czy Historyjce Użytkownika, nie pozostała już żadna praca do wykonania. Innymi słowy, wspomniany, wartościowy Przyrost rodzi się w momencie gdy element Backlogu Produktu spełni założoną Definicję Ukończenia.

Korzyści z posiadania Definition of Done

Gdyby ktoś zapytał mnie jaki jest najważniejszy element czy też rezultat poprawnie stosowanego Scruma odpowiedziałbym bez wahania, że jest to właśnie regularne dostarczanie Przyrostów zgodnych z Definition of Done. Jest to też istota agile’a. Mówi o tym wręcz wprost trzecia zasada Manifestu Agile – dostarczajcie często działające oprogramowanie – w odstępach kilkutygodniowych lub kilkumiesięcznych, im częściej tym lepiej.

Dlaczego to takie ważne? Za sprawą częstego dostarczania skończonych, wartościowych kawałków naszego Produktu mamy szansę budować przewagę konkurencyjną. Dzięki efektywnemu procesowi zamieniania elementów Backlogu Produktu w użyteczną wartość biznesową możemy szybko zaadaptować się do często zmieniających się warunków rynkowych. Przykładowo wykorzystamy nadarzające się okazje, dostosujemy do aktualnych trendów czy ograniczymy ryzyko poprzez możliwość szybkiego zwrotu kierunku w przypadku błędnej decyzji lub… globalnej pandemii.
Ciekawą analogią do tej właściwości agile’owego podejścia jest cytat Karola Darwina
o przetrwaniu gatunków (w naszym przypadku oczywiście firm i produktów), które najlepiej potrafiły zaadaptować się do zmiany.

Dokładnie do tego samego efektu powinno dążyć wdrażanie Scruma czy wszelkich innych metod i frameworków spod parasola Agile.

Kolejną, niewątpliwą zaletą z posiadania Definition of Done jest podniesienie poziomu transparencji na wielu płaszczyznach.
Po pierwsze oczywiście na poziomie samego Przyrostu. Gotowe oznacza gotowe, bez żadnych „ale”. Wszyscy członkowie zespołu i interesariusze dokładnie rozumieją ten stan, a dodatkowe komentarze i wyjaśnienia są zbędne.

Po drugie na poziomie procesów funkcjonujących w zespole. Jeżeli w trakcie Sprintu nie udało się spełnić Definicji Ukończenia dla danego elementu to widzimy to od razu gołym okiem. Być może brakuje nam wiedzy, kompetencji, jakiegoś narzędzia, a może po prostu popełniliśmy błąd na planowaniu Sprintu. Transparencja umożliwia szybką inspekcję takiego stanu i możliwość adaptacji czyli podjęcia próby wyeliminowania problemu w przyszłości.

Po trzecie transparencja gdzie jesteśmy i dokąd zmierzamy. Pomaga lepiej prognozować i planować ile faktycznie ukończonych elementów Backlogu Produktu zespół jest w stanie dostarczyć w nadchodzącym Sprincie. Takie dane pomogą też z pewnością w budowaniu i urealnianiu wysokopoziomowych roadmap Produktu czyli na odpowiadaniu na pytanie: „a na kiedy to będzie?”

Jak stworzyć pierwsze Definition of Done?

Kluczowym aspektem Definicji Ukończenia jest to aby była wymagająca, ale jednocześnie realna do osiągnięcia. Gdy poprzeczka twojej pierwszej Definition of Done będzie zawieszona zbyt wysoko, spełnienie jej co Sprint może być po prostu nierealne. Zamiast wysokiej jakości i wartości spowoduje wówczas podniesiony poziom frustracji developerów.
Z kolei gdy będzie ona zbyt prosta, nie przyczyni się do rozwoju kompetencji członków zespołu, którzy staną w miejscu, tak jak jakość i wartość twojego Produktu.

Na samym wstępie dobrze jest zatem postąpić zgodnie z jedną zasad Kanbana – zacznij od tego co masz, a następnie stopniowo usprawniaj. Zrób pierwszy krok i z czasem podnoś poprzeczkę. Warsztat na stworzenie pierwszej Definition of Done może wyglądać następująco:

• Zapisz na tablicy lub flipcharcie hasło w stylu: „Co oznacza DONE?” a następnie rozpocznij sesję burzy mózgów, pamiętając o jej zasadach:
  nie ma czegoś takiego jak głupi pomysł, unikamy ich oceniania, im więcej tym lepiej, zachęcamy uczestników do rozwijania już zgłoszonych pomysłów, jeden pomysł na raz, wszystko zapisujemy (najlepiej na karteczkach i przyklejamy do tablicy).
  
  Przy dłuższych momentach ciszy możesz wesprzeć zespół zadając dodatkowe pytania, przykładowo:
  • W jaki sposób unikniemy błędów?
  • Jak podejdziemy do testowania kodu?
  • Co możemy automatyzować?
  • Jak zminimalizujemy dług technologiczny?
  • W jaki sposób osiągniemy kryteria wydajnościowe?
  • Jakie standardy i praktyki inżynieryjne pomogą w osiągnięciu technicznej doskonałości?
  • Jak zapewnimy spójność z zasadami architektury?
  • Jakiej będziemy potrzebować dokumentacji?
  • Co zrobimy dla zapewnienia spójność z zasadami bezpieczeństwa?
  • Jakie działania przełożą się na większość wartość Produktu?
    
• Następnie na osobnym flipcharcie lub tablicy narysuj trzy podzbiory/ramki: NOW, NEXT, FUTURE. Zadaniem zespołu będzie rozmieszczenie wszystkich pomysłów z burzy mózgów według następujących kategorii:
  
  NOW – rzeczy, które jesteśmy w stanie zrobić teraz, od kolejnego Sprintu.
  NEXT – tematy na najbliższą przyszłość, które spowodują „podniesienie poprzeczki”, trudne, ale realne.
  FUTURE – zagadnienia do rozważenia w odleglejszej przyszłości, nierealne w tym momencie, co nie oznacza że w ogóle.

• Ostatnim krokiem będzie przejrzenie wszystkich pomysłów pod kątem tego, czy zostały wyrażone w sposób obiektywny i możliwy do zweryfikowania w przyszłości.
  Możesz też na koniec poprosić członków zespołu, aby symbolicznie podpisali się pod właśnie utworzoną Definition of Done i wyrazili tym samym swoje zobowiązanie do jej przestrzegania.

Pamiętaj, że dopiero wcielenie w życie nowo powstałej Definicji Ukończenia pozwoli ją zweryfikować pod kątem odpowiedniego na dany moment wyważenia. Warsztat na jej stworzenie to dopiero pierwszy krok.

Jak często aktualizować Definition of Done?

Raz utworzona Definicja Ukończenia nie oznacza końca pracy nad nią. Powinna w regularnych odstępach czasu podlegać inspekcji i adaptacji celem wspomnianego wcześniej podnoszenia poprzeczki. Dobrym miejscem do dyskusji na jej temat może być przykładowo Retrospekcja Sprintu.

Jeżeli twój zespół ma bardzo duże problemy z dostarczeniem czegokolwiek zgodnego z DoD i stan ten utrzymuje się przez kilka Sprintów, to być może poprzeczka jest jeszcze za wysoko. Analogicznie, jeżeli jej spełnienie nie stanowi już żadnego wyzwania to może trzeba się zastanowić jakie podjąć wyzwanie, aby wejść na wyższy poziom.

A zatem, wraz ze wzrostem dojrzałości i kompetencji zespołu warto podnosić kryteria jakościowe realizowanych elementów Backlogu Produktu. W moich zespołach najczęściej wracaliśmy do dyskusji na temat Definition of Done mniej więcej raz na kwartał. Pamiętaj jednak, że w twoim przypadku odpowiednia częstotliwość może być zupełnie inna. Podstawą jak zwykle jest tutaj empiryzm, a nie jedyna słuszna, najlepsza praktyka, gdyż coś takiego po prostu nie istnieje.

Definition of Done vs. „u mnie działa”

Przy okazji opowiadania o Definicji Ukończenia zawsze kojarzy mi się historia kiedy to pewnego razu żona poprosiła mnie o zrobienie prania. Zadanie wydawało się proste i bez „haczyków”. Jednak przy próbie zweryfikowania jego wykonania nasz dialog wyglądał następująco:

– Czy zrobiłeś pranie jak mnie nie było?
– Oczywiście!
– Czyli wyjąłeś też wszystko z pralki i przełożyłeś do suszarki…
– … suszarki…?
– … i wysuszone z suszarki włożyłeś do szafy?
– … nie… ale mówiłaś tylko „zrobić pranie”!
– …

Jak się okazało, mieliśmy zupełnie inne postrzeganie Definition of Done dla „zrobienia prania” 😉 Jaki z tego wniosek? Każdy członek zespołu i interesariusz musi mieć takie samo zrozumienie co to znaczy „ukończona praca”. Pełna transparencja i jednakowe zrozumienie Definicji Ukończenia pozwali uniknąć podobnych nieporozumień na większą skalę.

Niestety z jakiegoś powodu koncepcja DoD w wielu zespołach, które aspirują do bycia Scrumowymi często odkładana jest na później lub po prostu nie respektowana. Tak zwane „wdrażanie Scruma” zaczyna się w nich od spotykania w ramach Daily Scrumów, przeprowadzania Retrospekcji czy zapełniania Product Backlogu mnóstwem wątpliwej jakości Historyjek Użytkownika. W swoim życiu spotkałem zdecydowanie za dużo zespołów, które twierdziły, że są Agile, bo mają Daily, założony projekt i tablicę Scrum w Jirze i kogoś kto zastanawia się jak zostać Scrum Masterem…

Jednak gdy faktycznie muszą dostarczyć coś gotowego i użytecznego na koniec Sprintu to pojawiają się problemy. Tutaj nie przetestowane, tam czegoś brakuje, gdzie indziej jest „gotowe, ale” czy też sławetne „u mnie działa”.

Jeżeli deklarujemy, że coś jest zakończone to wszyscy członkowie zespołu muszę mieć takie same zrozumienie tego stanu. Natomiast najlepsza Definition of Done to taka, która zawiera całą pracę jaka musi zostać wykonana, aby dostarczyć produkt w ręce użytkownika końcowego .

Prawie DONE na Sprint Review

Wielokrotnie byłem pytany przez zespoły i Product Ownerów czy mogą pokazać pewną funkcjonalność w ramach demo na Sprint Review, która prawie spełnia Definition of Done. Przecież zespół tak się napracował w Sprincie! Zostało niewiele do końca, to może zaprezentujemy już to co jest? Co jeżeli pojawią się ważni interesariusze, a my nie będziemy mieli nic na demo? Musimy pokazać, że byliśmy bardzo zajęci i nie graliśmy za dużo w FIFĘ na firmowej konsoli.

W tej materii nie uznajemy półśrodków w stylu, że coś jest „prawie gotowe albo „prawie działa”. Jak utarło się mówić, prawie robi różnicę. Wielką różnicę. Pokazywanie prawie gotowych rzeczy może zakłamywać rzeczywistość, zaburzać transparencję i nadszarpywać zaufanie interesariuszy wobec zespołu. Mogą przecież pojawić się pytania o to czy można już używać danej funkcjonalności i czy może ona już zacząć dostarczać oczekiwaną wartość biznesową. Przecież pokazane było, że działa…

Z pewnością odpowiedź w stylu „jeszcze nie można, pokazujemy tylko, że się napracowaliśmy, ale w zasadzie to nie działa, musimy zrobić testy w kolejnym Sprincie i wdrożenie jeszcze w kolejny” nie będzie satysfakcjonująca. Pamiętaj, liczy się efekt pracy, a nie sam czas na nią poświęcony. Jedno zadanie DONE jest zawsze więcej warte niż sto „IN PROGRESS”. A zatem, jak to mówi, inne agile’owe porzekadło, trzeba wreszcie przestać zaczynać, a zacząć kończyć 😉

Im lepsza transparencja stanu w jakim jest nasz Przyrost, bez żadnych ukrytych „prawie” i „ale”, tym lepsza jego inspekcja. Z kolei lepsza inspekcja oznacza trafniejszą adaptację i właściwe decyzje biznesowe jakie są podejmowane na jej podstawie.

Definition of Done a Kryteria Akceptacji

Bardzo często myli się te dwa pojęcia i błędnie stosuje zamiennie. Wyjaśnijmy sobie zatem raz, a dobrze czym różni się Definition of Done od Kryteriów Akceptacji. Najprościej rzecz ujmując ta pierwsza dotyczy każdego elementu Backlogu Produktu. Przykładowo chcemy, aby każdy z nich był przetestowany i pozbawiony błędów czy wdrożony na odpowiednie środowisko. Kryteria Akceptacji z kolei dotyczą poszczególnych, unikalnych cech konkretnego elementu Backlogu.

Przykładowo jeżeli nasza historyjka użytkownika dotyczy finalizacji płatności w sklepie internetowym to musi być, tak jak wszystkie inne w Backlogu, pozbawiona błędów i wdrożona. Takie zapisy znajdą się w Definition of Done.
Natomiast w Kryteriach Akceptacji, przykładowo mogłoby się znaleźć: możliwość płatności BLIKiem, możliwość płatności kartą lub przelew online.

Kryteria Akceptacji często stanowią też punkt wyjścia przy tworzeniu scenariuszy testowych czy pomagają w dzieleniu historyjki użytkownika ma mniejsze.

Ukończone czy wartościowe?

Na koniec chciałbym jeszcze podkreślić, że Definicja Ukończenia powinna opisywać coś więcej niż pracę niezbędną do wytworzenia gotowego Przyrostu. Prawidłowa Definition of Done prowadzi do dostarczenia nie tylko gotowych ale i wartościowych biznesowo Przyrostów.

Wiele Zespołów Scrumowych wpada na pomysł dopisania do swojej DoD różnych praktyk programistycznych jak przykładowo pair progamming, TDD czy automatyzacja testów. Nie mają one jednak bezpośrednio powiązania z wartością rozwijanego Produktu. Mogą faktycznie wpływać na ograniczenie liczby błędów, transparencję czy komunikację, ale wciąż jest to wyłącznie metoda pracy.

Analogicznie, zastanów się czy przykładowo w fabryce samochodów Toyoty jakość nowego produktu wyraża się zastosowaniem konkretnych maszyn, linii produkcyjnych czy narzędzi? W ten sposób tworzy się jakość, a nie ją definiuje. Jakościowa historyjka to taka, która pozbawiona jest krytycznych błędów, a nie taka, która ma zautomatyzowane testy i została napisana przy użyciu Test Driven Development. A zatem postaraj się w swojej Definition of Done zawrzeć nie nazwy różnych narzędzi i praktyk, ale też pożądany efekt ich zastosowania i idącą za tym wartość.

Przy okazji rozprawiliśmy się z pewnym mitem. Głosi on, że w podejściu Agile nie dba się o jakość. Wszystko jest przecież robione na szybko w Sprintach, byle jak i w małych kawałkach. Krótkie iteracje i małe kawałki nie stoją jak widać w opozycji z wysoką jakością, której bardzo mocno strzeże stosowana w Scrumie Definition of Done.

A co znajduje się w Definicji Ukończenia twojego zespołu? Zachęcam do pozostawienia komentarza poniżej 🙂