“Ale to nie jest tak Done jak myślisz” — powiedział zespół do Product Ownera. Legenda głosi, że od tego nieporozumienia zaczął się pomysł dodania Definition of Done (pl Definicja Ukończenia) do frameworku Scrum. Dzisiaj nadal w ramach pracy jako Agile Coach spotykam zespoły, które nie mają określonej Definition of Done. Ciągle pojawia się niezrozumienie kiedy tworzyć taką definicję i jak zacząć. Czy do każdego elementu Backlogu Produktu trzeba stworzyć osobne DoD? Czy DoD ustalamy dla Sprintu na planowaniu? Czy tylko User Story mają taką definicję? Czym się różni Definiton of Done od Acceptance Criteria? A co zrobić wiedząc, że nie możemy spełnić DoD? Rozwiejmy te wątpliwości.

Definition of Done zapewnia przejrzystość

Jaką rolę spełnia Definition of Done i czy trzeba się jej trzymać? Scrum można zredukować do jednego zdania: dostarczanie ukończonych Przyrostów produktu w Sprintach.

Definition of Done czyli Definicja Ukończenia przede wszystkim określa co znaczy, że coś jest done, czyli ukończone. Każdy powinien rozumieć co oznacza, kiedy Zespół Developerski mówi, że skończył pracę nad elementem, który wziął do Sprintu. Każdy powinien też zrozumieć jaka praca została wykonana i czy to wystarczy, żeby wdrożyć Przyrost produktu na produkcję.

Definition of Done to spisany standard, lista kontrolna, z którą sprawdzamy ukończenie każdego Elementu Backlogu Produktu.

Jeśli korzystasz z techniki User Story, każda User Story będzie miała różne Kryteria Akceptacji, ale wszystkie muszą spełnić kryteria jednej Definition of Done. Naprawa defektu też musi spełnić Definition of Done.

Definiton of Done daje przejrzystość stanu każdego elementu backlogu produktu i zapewnia przejrzysty stan Przyrostu produktu. Przejrzystość jest jednym z filarów Scruma, ponieważ kiedy rozumiemy jaki jest stan obecny, to możemy podejmować odpowiednie decyzje — stosować empiryzm. Definition of Done daje także przejrzystość jaką jeszcze pracę trzeba wykonać, żeby Przyrost został wydany na środowisko produkcyjne.

Celem Zespołu Scrumowego w kontekście pracy z DoD powinno być doprowadzenie to tego, że zakres tej definicji oznacza “potencjalnie gotowe do wydania”. Co można prostymi słowami wytłumaczyć jako, przynajmniej raz na koniec Sprintu mamy Przyrost, który można wdrożyć na produkcję bez wykonywania dodatkowej pracy. Podnoszenie jakości Przyrostu, czyli podnoszenie Definition of Done jest jednym z zagadnień jakie powinniśmy poruszać na Retrospekcji Sprintu. Oczywiście Product Owner decyduje czy w tym przyroście jest wystarczająca spójność i wartość biznesowa, żeby go wydać.

Żeby zapewnić Przejrzystość musimy zapewnić, że Definition of Done jest zawsze aktualna i zawiera prawdziwe, realne kryteria.

Jeśli element Backlogu Produktu spełnia Definition of Done, to jest on ukończony, czyli done. Jeśli nie spełnia chociażby jednego punktu definicji, to jest nieukończony, czyli undone. Ukończone elementy są zintegrowane z wcześniej ukończonymi elementami i tworzą Przyrost produktu. Elementy nie ukończone wracają do Product Backlog i od nowa ustalany jest ich porządek na tej liście. Jeżeli korzystamy z szacowania elementów Backlogu Produktu w jednostce Story Point, to za każdy ukończony element zaliczamy punkty do Velocity, za każdy nie ukończony liczymy 0 punktów.

Niektórzy mogą tutaj się oburzyć, po przecież jeśli jakaś praca była wykonana dla tego elementu, to jest on częściowo zrobiony, a nawet prawie ukończony (almost Done), więc jakieś Story Points można by zaliczyć do Velocity. Tylko jak i po co? Bardzo trudno jest dobrze oszacować ile pracy jeszcze pozostało. Często ukończenie elementu w 90% Done zajmie tyle co dotychczasowa praca. Dlaczego? Ponieważ tworzymy produkty złożone i mamy wiele zmiennych oraz zależności, które wpływają na pracę. Może też być tak, że Product Owner ma w kolejnym Sprincie dużo bardziej wartościowe rzeczy do robienia niż kończenie tego elementu.

Nieukończony element w produkcie to duże ryzyko. Nie dość, że prawdopodobnie posiada błędy, to dalszy rozwój z tym elementem w produkcie spowoduje kolejne zależności i problem z jego ukończeniem później. Nie chcemy też sytuacji, gdzie mamy wiele elementów w Product Backlog pozaczynanych i nie wiemy w jakim są stanie. Wtedy nie możemy mówić, że mamy przejrzysty Product Backlog i nie możemy dobrze planować. Nie chodzi, o to żeby pokazywać postęp pracy i że coś się dzieje, tylko o to, żeby wiedzieć w jakim stanie jest Przyrost produktu i Product Backlog. Dlatego dużo bardziej rozsądnym podejściem do liczenia Velocity jest podejście zero-jedynkowe. Jak coś jest Done, to zaliczamy punkty, jest nie jest to 0 punktów. Kiedy ten element zostanie ukończony to zaliczymy pełną wartość punktów. Takie podejście uczy też Zespół Developerski, żeby planować pracę tak, żeby kończyć pracę w Sprincie, a nie tylko zaczynać.

Definition of Done pomaga planować

Kiedy rozumiemy, jaka praca i na jakim poziomie jakości musi zostać wykonana dla każdego elementu, wtedy jesteśmy w stanie zaplanować ile elementów Backlogu Produktu zmieści się w Sprincie. Często z Definition of Done wynikają konkretne zadania do wykonania dla każdego elementu. Jeżeli Zespół Scrumowy w ramach Retrospekcji Sprintu postanowił podnieść Definition of Done, powinien tą zmianę uwzględnić w kolejnym planowaniu.

Po kilku Sprintach wiemy z dużą pewnością ile elementów Zespół Developerski jest w stanie wykonać w Sprincie — znamy Velocity zespołu. Kiedy znamy Velocity jesteśmy w stanie planować w horyzoncie kilku Sprintów i planować wydania.

Co jeśli nie mamy Definition of Done albo jej nie przestrzegamy?

Nie posiadanie czy nie przestrzeganie Definition of Done daje właściwie taki sam efekt — brak przejrzystości. Pierwsza konsekwencja jest taka, że nikt nie wie jaki jest rzeczywisty postęp pracy nad produktem. Czasem pojawia się nawet wątpliwość czy zamykać elementy i oznaczać jako ukończone, czy może je zostawić “na razie” otwarte. Kiedy nie wiadomo co można zamknąć, nie można określić ile rzeczy zostało ukończonych, a ile pozostało do ukończenia. Nie wiadomo co jeszcze trzeba zrobić dla każdego elementu, a z czasem coraz trudniej jest odnaleźć informację co zostało zrobione. Powstaje wrażenie, że jesteśmy zajęci i końca nie widać.

Kiedy interesariusze pytają co będzie w następnym wydaniu produktu, czy na kiedy coś będzie nie możemy im udzielić odpowiedzi opartej o konkretne dane. Taka sytuacja nie buduje zaufania pomiędzy Zespołem Scrum a interesariuszami.

Nie wiadomo też jakiej jakości jest przyrost produktu i czy jest w stanie “potencjalnie gotowy do wdrożenia”. Ciężko zatem podjąć decyzję czy produkt wydawać, czy lepiej nie. Jeżeli nie wiemy jaka jest jakość produktu, to najbezpieczniej jest założyć, że jest niska. Będzie awaria na produkcji czy nie? Ile czasu potrzebujemy na porządne testy i stabilizację produktu? Nie wiemy, trzeba zacząć usuwać problemy i zobaczymy ile nam to zajmie. Product Owner może zacząć stresować się i unikać interesariuszy. A przecież wprowadzenie Scrum miało spowodować, że będzie bardziej przejrzyście, wyższa jakość, wyższa przewidywalność.

Jest bardzo duże prawdopodobieństwo, że bez Definition of Done tworzymy dług techniczny, którego nie kontrolujemy i z upływem czasu wysiłek potrzebny na doprowadzenie produktu do stabilnego stanu rośnie geometrycznie. Jak łatwo się domyśleć produkt, który został doprowadzony do stabilnego stanu przez kolejne naprawy nie jest takiej samej jakości jak produkt budowany od początku dobrze. Kiedy długo nie spłacamy długu technicznego, produkt jest coraz ciężej rozwijać. W końcu dojdziemy do momentu, że tak trudno dodawać nowe funkcjonalności i utrzymywać produkt, że lepiej go przepisać na nowo.

Jak zbudować dobre Definition of Done?

Zespół Developerski musi określić Definition of Done, którą są w stanie spełniać co Sprint. Definition of Done dotyczy stanu Przyrostu produktu, więc jeśli jest więcej niż jeden Zespół Developerski, zespoły powinny ustalić wspólną Definition of Done. Jednak jeśli różne zespoły pracują w różnych technologiach i korzystają z innych narzędzi, będą różnice w Definition of Done poszczególnych Zespołów Developerskich.

Zacznij od polityk i standardów firmy. Zacznij od zadania sobie pytania:
Co potrzebujemy w tej organizacji zrobić i spełnić, żeby wydać oprogramowanie na produkcję? Prawdopodobnie trafisz na dokumenty lub w mniej sformalizowanej organizacji konkretne osoby, które decydują o wdrożeniach.

Przechodzimy przez punkty, które znaleźliśmy i zastanawiamy się jak je możemy spełnić:

• Co musimy zrobić, żeby ten punkt był spełniony?
• Kto to może zrobić, nasz zespół, inny zespół, ktoś spoza organizacji? Jeśli inny zespół lub ktoś spoza organizacji, to nie trafia to do DoD.
• Czy jesteśmy w stanie spełnić ten punkt w każdym Sprincie? Jeśli nie jesteśmy w stanie, to nie trafia to do DoD.

Co z punktami, które musimy spełnić przed wydaniem, ale nie chcemy lub nie możemy spełniać ich w każdym Sprincie? Dla nich tworzymy odpowiednie elementy w Backlogu Produktu i planujemy ich wykonanie, kiedy Product Owner zdecyduje, żeby wydać Przyrost na produkcję. Dlaczego to ważne? Jest to praca do wykonania dla produktu, która nie jest wykonywana co Sprint — Undone Work. Taka praca musi być widoczna i zaplanowana. Patrząc na Backlog Produktu czy wykresy spalania, każdy widzi co jeszcze trzeba wykonać i ile pracy w sumie pozostało.

Sprawdźmy jeszcze jak chce pracować zespół.

• Czy zespół chce jeszcze coś dodać? Na przykład: refactoring, Continuous Integration, Behaviour Driven Development, Test Driven Development, Domain Driven Design?

Jeśli wiele zespołów pracuje nad jednym produktem, to powinny ustalić między sobą wspólną Definition of Done, żeby zapewnić spójność jakości produktu. W przeciwnym przypadku jakość produktu będzie taka jak najniższa DoD jednego z zespołów. Poszczególne zespoły mogą mieć swoje unikalne zapisy jeśli nie obniżają wspólnego standardu.

Czy i kiedy można zmieniać Definition of Done?

Definition of Done można zmieniać w ramach Retrospekcji Sprintu. Naturalne jest, że w kiedy zespół uczy się nowych umiejętności, zdobywa nowe narzędzia czy środowiska, może rozszerzać Definition of Done. W takim wypadku na kolejnym Planowaniu Sprintu obowiązuje nowa Definition of Done. Trzeba też pamiętać, że kiedy podnieśliśmy DoD, świadomie stworzyliśmy dług techniczny dotyczący pracy wykonanej w poprzednich Sprintach, kiedy obowiązywała niższa DoD. Może się też tak zdarzyć, że Zespół Developerski weźmie mniej pracy do Sprintu.

Podsumowanie

Definition of Done jest krytyczna dla przejrzystości informacji na temat Przyrostu i postępu. Definition of Done powinna być realnym standardem. Definition of Done powinna odzwierciedlać potencjalnie gotowe do wydania. Jeśli tak nie jest, praca potrzebna do doprowadzenia Przyrostu do takiego stanu powinna być widoczna na Backlogu Produktu. Kiedy zmieniamy Definition of Done, musimy pamiętać o konsekwencjach.

W kolejnym poście napiszemy co zazwyczaj znajduje się w Definition of Done i pokażemy przykłady DoD.