Oto dziesięć pytań o Definition of Done, które chodzą po Twojej głowie, ale nie miałaś/nie miałeś kogo o nie zapytać. Jako wytrawni Scrum Masterzy właśnie po to jesteśmy, aby zebrać najczęściej pojawiające się pytania i na nie odpowiedzieć.
To nie jest tekst o Definition of Done
Dziś nie będzie standardowego wpisu. Choć Definition of Done nie jest niczym nowym, postanowiłem odpowiedzieć na 10 najczęściej pojawiąjących się pytań w tym zakresie. Definition of Done to ważny element podejścia zwinnego, który często jest pomijany podczas wdrażania Scruma. Przydać się może też w innych zwinnych podejściach aby uniknąć słynnego „Almost Done„. Nie jest to też wpis o podstawach zagadnienia, te znajdziecie na naszym blogu w podlinkowanych w tym akapicie wpisach o Definition of Done, zwanej czasami pieszczotliwie DoDą.
Jeśli w Twojej ocenie nie wyczerpaliśmy tematu, jeśli jest pytanie, na które nie odpowiedzieliśmy – daj nam znać w komentarzu. Odpowiemy w kolejnym wpisie lub na naszym #białkowym kanale na YouTube.
Po co nam Definition of Done?
Odpowiedzi na to pytanie zamykam zazwyczaj w 3 kluczowych słowach: transparetność, jakość, ryzyko. Słowa te znajdują się w Scrum Guide, choć dla niektórych mogą one pozostać niezauważone. Odpowiadając na pytanie „po co?” powiedzmy więc wprost – chcemy transparentnej informacji o tym, co oznacza „Done” po to, aby zwiększyć jakość dostarczanego Produktu. Dzięki niemu obniżając ryzyko udostępnienia bubla klientowi końcowemu, ale równocześnie ograniczamy ryzyko złego zaplanowania się, bo wszyscy rozumiemy co znaczy „Skończone” i ile tak naprawdę pracy musimy wykonać.
Czy duża liczba kryteriów w DoD przeszkadza?
Duża liczba kryteriów w DoD powoduje, że z biegiem czasu Zespół przestanie zwracać uwagę na wszystkie kryteria Definitoin of Done, a zacznie je spełniać wybiórczo. „Przecież jest ich tyle, że i tak nigdy nie udaje nam się ich spełnić.” A stąd dzięki Broken Window Theory już prosta droga do niedziałającego Scruma.
Lista kryteriów powinna obejmować te kryteria, które są niezbędne celem zapewniania jakości, transparentności i obniżenia ryzyka, a nie wszystkie elementy, których „ktoś” oczekuje.
Co, jeśli DoD w naszej organizacji nie istnieje?
Jeśli pracujemy w organizacji, w której nikt nigdy nie słyszał i nie widział Definition of Done czas to zmienić. Zgodnie z teorią DoD, powinien istnieć jakiś standard dla całej organizacji. Jeżeli jej nie ma, to pamiętajmy, że to nie my będziemy ją tworzyć dla wszystkich. Nie musimy przecież mieć wiedzy, że w innym miejscu Polski czy świata istnieje zespół, który zajmuje się czymś zupełnie innym, np. sztuczną inteligencją. Dla nich przyjęte przez nas kryteria jakościowe mogą nie mieć zastosowania.
Jeśli jednak znajdujemy się w ten dziwnej sytuacji, że DoD nie ma, to czas zacząć działać od siebie. Stwórzmy pierwszą wersję kryteriów DoD dla naszego zespołu. Zadbajmy jednak, aby te kryteria były maksymalnie uniwersalne. Po utworzeniu wersji inicjalnej, zweryfikowaniu jej w boju, wyciągnięciu wniosków na temat akuratności kryteriów zacznijmy „kolędować” w naszej organizacji za ich rozpowszechnieniem. Na pewno wywoła to wiele dyskusji, ale czy nie o to nam właśnie chodzi? Jedną z istotnych cech DoD jest przecież transparentność!
Jak ma się DoD do Zobowiązań z nowej wersji Scrum Guide?
Nowa wersja Scrum Guide zaopiekowała się tematem Definition of Done, Do tej pory temat był on potraktowany dość po macoszemu. DoD było jakby „doklejone” do frameworku i miało się „zadziać samo”. W nowej wersji Scrum Guide, tej datowanej na listopad 2020, Definition of Done stało się jednym z trzech Zobowiązań.
Deweloperzy, a więc osoby aktywnie pracujące nad produktem w Sprincie zobowiązują się poprzez Definition of Done, że ukończony Przyrost spełnia kryteria jakościowe wymagane dla produktu.
Czego dotyczy DoD – wymagania, Przyrostu czy produktu?
Pytanie z nagłówka jest jednym z najczęściej zadawanych. „Czego właściwie dotyczą kryteria Definition of Done?” Odpowiedź jest prosta – to Przyrost jest podstawową jednostką, do której odnoszą się kryteria Definition of Done.
Weryfikacja jakościowa Przyrostu polega więc nie tylko na analizie kryteriów akceptacji każdego z wymagań na niego się składających, ale też weryfikacji Definition of Done dla wszystkich części składowych i… całego Przyrostu!
Przyrost jest konkretnym krokiem w kierunku osiągnięcia Celu Produktu. Można więc powiedzieć, że Definition of Done działa na wszystkich z wymienionych poziomów – od pojedynczego, partykularnego wymagania, aż do Produktu, który będzie złożony ze zrealizowanych zgodnie z kryteriami DoD wymagań.
Kto weryfikuje kryteriów DoD?
Odpowiedzialność za weryfikację kryteriów Definition of Done spoczywa na całym Scrum Team. Oczywiście, odpowiedzialność za wykonanie pracy, która wypełnia kryteria DoD spoczywa na tych, którzy pracują nad wytworzeniem nowego Przyrostu (patrz: Deweloperzy). Gdyby ktoś pytał na jakimś egzaminie Scrum o to, kto wykonuje pracę, żeby elementy Backlogu Produktu spełniały DoD, to pamiętajcie, że to Deweloperzy. 🙂
Natomiast przyczyna, dla której to cały Scrum Team jest odpowiedzialny za określenie „done” lub „not done” jest prosta – wszyscy jako zespół pracujemy zarówno nad samym Definition of Done, jak i nad nowym Przyrostem.
Czy bez spełnienia kryteriów DoD można „odebrać” przyrost?
Pracując w Sprincie staramy się dołożyć wszelkich starań, aby wytworzyć nowy przyrost przybliżający nas do osiągnięcia Celu Produktu. Przyrost składa się z jednego lub wielu wymagań, których spełnienie oznacza wykonanie ważnego kroku w kierunku realizacji wizji PO. Wymaganie lub wymagania nie spełniające kryteriów DoD nie mogą być uznane za zakończone. W konsekwencji nie mogą wejść w zakres Przyrostu po Sprincie.
Jeśli wymaganie niespełniające DoD to podstawowy komponent przygotowywanego przez nas rozwiązania oznacza to, że nie mamy żadnego biznesowo używalnego Przyrostu, którym jesteśmy w stanie się pochwalić. Taka sytuacja jest jedną z najbardziej istotnych kwestii w temacie odpowiedniego dzielenia wymagań i dostarczania wartości biznesowej. Bez prawidłowego procesu dekompozycji, sytuacja w której nie będziemy mieli czym się pochwalić, będzie nagminna.
Czy można częściowo spełnić kryteria DoD?
Tak zwane „warunkowe” kryteria Definition od Done to prawdziwa plaga. „Jeśli wymaganie dotyczy dokumentacji, to…”, „Jeśli wynikiem wymagania jest raport to…, a jeśli wydruk to…”.
Powyższe podejście jest najkrótszą drogą do sytuacji niewykorzystywania Definition of Done w ogóle. W przypadku weryfikacji Przyrostu należy przyjąć zasadę „wszystko albo nic”. Dopiero gdy spełniamy wszystkie kryteria, naszą pracę można uznać za „done”. Jeśli któreś z kryteriów nie zostało spełnione, pracy nie możemy uznać za zakończonej. Nieukończone wymaganie oczywiście trafia z powrotem do Backlogu Produktu.
Jakie kryteria mogą stanowić przykład DoD?
Pomyśl o rzeczach, bez których udostępnimy produktu naszym klientom. Jeśli mamy notoryczny problem z wydajnością naszego produktu, dodamy kryterium wydajnościowe do listy DoD. W przypadku, gdy naszą bolączką jest duża ilość błędów, będziemy chcieli skupić się na pragmatycznej weryfikacji przygotowanego rozwiązania. Jeśli działamy na mocno regulowanym rynku, każdy nasz Produkt musi zostać odpowiednio udokumentowany. Potrzebę stworzenia czy modyfikacji dokumentacji dodamy jako kryterium DoD. Jeżeli zdarzyło się, że po oddania naszego rozwiązania klientowi coś eksplodowało, to odpowiednie sprawdzenie powinno wylądować w DoD.
Potencjalna lista kryteriów jest oczywiście o wiele szersza, zależy one jednak bardzo mocno od charakteru produktu, nad którym pracujemy. Tak samo mamy nadzieję, że lista pytań o Definition of Done również nie jest kompletna i w komentarzach zadacie kolejne. Czekamy!
Poproszę o trzy, pełne i konkretne listy DoD z trzech różnych projektów – najlepiej popularnych 🙂 Takie KONKRETNE przykłady podniosą użyteczność Waszego bloga.