.st0{fill:#FFFFFF;}

Definition of Done, czyli DoD 

 30 lipca, 2018

Tomasz Dzierżek

Definition of Done, czyli DoD, to jeden z tych elementów Scruma, które są bardzo proste, jeżeli już załapiemy o co chodzi. Mogę jednak nastręczać wielu problemów, jeżeli próbujemy nauczyć się o nim ze Scrum Guide’a.

 

Definicja Definition of Done

Definition of Done to specjalny zestaw kryteriów akceptacji, który mówi nam o tym, że nasza praca nad danym Elementem Backlogu Produktu została skończona i jest odpowiedniej jakości. Ten kryteria dotyczą każdego jednego wymagania czy też kawałka pracy, o którym chcielibyśmy powiedzieć że go skończyliśmy.

Definition of Done jest wspólne dla wszystkich wymagań w backlogu i zwykle pochodzi z organizacji. Zwykle chcemy mieć jedno wspólne zrozumienie tego, co to znaczy, że robota jest skończona. Ponadto, chcemy też zadbać o to, żeby skończone prace miały jakąś określoną jakość. Jeżeli zespół nie dostanie takich kryteriów od organizacji, tworzy je sam. Ważne jednak, żeby DoD dotyczyło wszystkich wymagań którymi się zajmujemy.

Jeżeli jednym wymaganiem jest wprowadzenie płatności BLIKIEM, a drugie to zmiana szaty graficznej naszej strony na świąteczną, to każde z tych wymagań ma jakieś swoje określone kryteria akceptacji („co trzeba zrobić”). Ale, żeby powiedzieć, że dowolne z nich jest skończone, do tych kryteriów akceptacji doklejamy zawsze jeden i ten sam zestaw kryteriów pochodzących z Definition of Done. Chcąc powiedzieć, że „zrobiliśmy płatność BLIKIEM”, musimy sprawdzić czy faktycznie można nim płacić, ale do tego czy spełniliśmy wszystkie kryteria Definition of Done.

 

Kryteria Definition of Done

Co do zasady, w Definition of Done znajdują się trzy rodzaje kryteriów akceptacji. Te najbardziej popularne, to kryteria związane z procesem. Jeżeli musimy stworzyć dokumentację albo musimy przetestować nasze rozwiązanie na odpowiednim środowisku, to dokładnie takie zapisy znajdziemy w DoD.

Drugi równie popularny zestaw kryteriów Definition of Done to kryteria jakościowe i wymagania niefunkcjonalne. Jeżeli dowolna akcja w systemie nie może trwać więcej niż 2 sekundy albo w żadnym miejscu systemu mają nie być widoczne dane osobowe to zamiast powtarzać takie kryterium w każdym jednym Elemencie Backlogu Produktu, po prostu zapisujemy je raz – w Definition of Done. Najczęściej są to właśnie wymagania wydajnościowe, stylistyczne, bezpieczeństwa, itd.

Wszystkie te wymagania, których nie chce nam się w kółko wpisywać w każdy jeden element backlogu, też możemy umieścić w DoD. Tu jednak warto pamiętać o tym, że Definition of Done dotyczy każdego jednego wymagania którym będziemy się zajmować. To z kolei znaczy, że nie mogą się tam pojawić kryteria specyficzne dla konkretnej działki, technologii czy rodzaju pracy. Inaczej ryzykujemy tworzenie martwych kryteriów DoD, co z kolei powoduje, że stają się one ignorowane (patrz: Broken Window Theory).

 

Jak pisać DoD?

Wiele zespołów boryka się z problemem stworzenia „właściwej” listy Definition of Done. Tymczasem w każdym jednym miejscu w którym byliśmy, taka definicja już istnieje. Tylko najczęściej jest ona po prostu schowana w głowach uczestników procesu.

Wystarczy zebrać wszystkich aktywnych uczestników procesu wytwórczego naszego produktu i zapytać ich wprost: „Co to znaczy, że wasza praca jest skończona?” Weźmy pierwsze z brzegu wymaganie i zapytajmy, „Kiedy możemy powiedzieć, że to jest zrobione i – co najważniejsze – nigdy już do tego nie będziemy wracać?”

Jeżeli spotka nas milczenie i konsternacja, to zapytajmy, czy wystarczy tylko napisać kod, żeby powiedzieć że to jest zrobione. Tu pewnie od razu słyszymy, że sam kod nie wystarczy, bo przecież trzeba jeszcze to przetestować, zintegrować, zrobić code review, itd. Ktoś może dodać, że gotowe jest dopiero, jak mamy przygotowaną paczkę wdrożeniową albo napisaną instrukcję instalacji. Może musimy zadbać o jakieś konkretne kryteria wydajnościowe bądź bezpieczeństwa? Spiszmy wszystkie te kryteria, a dzięki nim zyskamy nasze pierwsze prawdziwe Definition of Done.

Idealny moment na takie działanie to Sprint Retrospective. Według Scrum Guide’a, jest to jedyny moment, kiedy faktycznie możemy zmieniać Definition of Done.

Kryteria akceptacji DoD w swojej konstrukcji nie różnią się niczym od kryteriów akceptacji User Story. Sugerujemy, żeby to były zdania oznajmujące w trybie dokonanym, które jasno mówią co się zadziało i w jaki sposób. Jeżeli wypowiadając takie kryterium nie mamy poczucia, że mówimy kłamstwo to znaczy, że prawdopodobnie jest ono spełnione.

 

Kto weryfikuje Definition of Done?

Bardzo częstym nieporozumieniem w temacie zarówno kryteriów akceptacji wymagań, jak i kryteriów Definition of Done, jest osoba odpowiedzialna za ich weryfikację. Ci którzy mieli przyjemność być na naszych warsztatach i szkoleniach wiedzą, że właściwą odpowiedzią jest słowo „zespół„. I nie jest to jedna osoba. Odpowiedzialność leży na całej grupie zwanej Scrum Teamem.

Owszem Product Owner jest częścią Scrum Teamu, ale nie jest jedyną osobą, która weryfikuje kryteria Definition of Done. W dobrze działającym zespole w sytuacja wygląda tak, że gdy – jako deweloperzy – skończymy jakieś wymagania, oznaczamy je jako skończone. Potem będziemy omawiać je i prezentować na Sprint Review. Ponieważ pracujemy profesjonalnie i sobie ufamy, to nikt nie podejrzewa nikogo o to, że coś mogłoby być nie zrobione.

I wcale nie mówię tu o tym, że taki Product Owner nie zobaczy tego rozwiązania. Ba! Często ktoś z zespołu krzyknie „Hej, Product Ownerze, podejdź tu i zobacz jak to zrobiliśmy!” Ale formalnie PO nie ma żadnej „władzy” odnośnie pozytywnego bądź negatywnego opiniowania kryteriów akceptacji. Tyczy się to też kryteriów Definition of Done.

Nie znaczy to, że nikt tego nie sprawdza albo że nikogo to nie obchodzi. Wręcz przeciwnie, każdemu powinno zależeć na tym żeby tworzyć dobre jakościowo rozwiązania i nie najeść się wstydu na Sprint Review. Sytuację, w której PO musi oficjalnie „namaścić” wymagania jako ukończone, odbieram jako brak zaufania PO do zespołu. Ale to temat na zupełnie inny tekst.

Tomasz Dzierżek


21+ lat doświadczenia w IT, 13+ lat doświadczenia w Scrum i agile, PSM I-III, konsultant zwinnych procesów i zespołów, Agile Coach, trener

Your email address will not be published. Required fields are marked

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.

  1. Czy DoD powinien weryfikować wymagania, czy jednak Przyrost? „Definition of Done to zestaw kryteriów, które spełnić musi wymaganie, aby można było je uznać za skończone” vs. „efekt pracy w bieżącym sprincie, czyli inkrement spełnia wymagania, które sami zdefiniowaliśmy”. W końcu na Przyrost składają się zaimplementowane wymagania, ale wymaganiem może też być stworzenie dokumentacji czy technical task.

    1. Stworzenie dokumentacji czy technical task to zdecydowanie elementy składowe służące do realizacji wymagania. To „Story”, rozumiane jako wymaganie, ma spełniać Definition of Done. Niektóre zespoły dodają osobną bramkę/Definition of Done w kontekście przyrostu, ale opisane w artykule DoD zdecydowanie dotyczy poszczególnych wymagań.

  2. Kryterium akceptacji wymagania,
    ale jakiego? Biznesowego czy Systemowego? A może w zależności od kontekstu?

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}