Oto dziesięć pytań o Definition of Done, które wylosowała nasza maszyna losująca. Pochodzą one ze zbioru najpopularniejszych pytań, które trafiają do nas przez social media, a także bezpośrednio na naszych szkoleniach i warsztatach.
To nie jest tekst o Definition of Done
Definition of Done to zbiór kryteriów, które produkt lub jego część (pojedyncze wymaganie) muszą spełnić, aby zostać uznane za ukończone i gotowe do dostarczenia klientowi. Najczęściej stosujemy Definition of Done do Elementów Backlogu Produktu działając w procesie scrumowym, ale koncepcja ta znalazła także szersze zastosowanie. Jeżeli szukasz więcej informacji o DoD, polecamy naszego bloga.
Wprowadzając Definition of Done dajemy jasne wytyczne, które pomagają zrozumieć, kiedy praca jest ukończona i jakiej powinna być jakości. DoD pomaga uniknąć niejasności i zapewnia odpowiedni standard produktu końcowego. Jest to ważne narzędzie w zarządzaniu jakością, które pozwala zespołowi utrzymywać wysoki standard pracy i zachować transparentność.
1. Po co nam Definition of Done?
Definition of Done jest niezbędne w metodykach Agile z kilku powodów: jakość, transparentność, ryzyko. Dobrze stosowane DoD gwarantuje, że produkt lub jego części spełniają wymagane standardy. Pomaga to utrzymać spójny poziom jakości w każdym jego elemencie. Ponadto, zapewnia klarowne i wspólne kryteria określające, kiedy praca jest uważana za zakończoną. Ta jasność redukuje nieporozumienia w zespole oraz między interesariuszami.
DoD pomaga także identyfikować i łagodzić ryzyka we wczesnym (a tak naprawdę – na każdym) etapie procesu rozwoju. Jeśli mamy problemy ze spełnieniem DoD, to jest to sygnał, że mogą istnieć problemy, które trzeba rozwiązać przed przejściem dalej. Dzięki temu zespoły mogą wykorzystać te sygnały do poprawy swoich procesów.
2. Czy duża liczba kryteriów w DoD przeszkadza?
Im więcej kryteriów DoD tym w teorii mamy wyższą (bardziej precyzyjnie określoną) jakość, a także mniej niejasności dotyczące tego, kiedy praca jest ukończona. Z drugiej strony im więcej kryteriów, tym więcej problemów. Zbyt szczegółowa DoD może doprowadzić do zbytniej złożoności procesu, co utrudnia realizację zadań i może prowadzić do opóźnień.
Z kolei wyśrubowane Definition of Done może ograniczać elastyczność zespołu w dostosowywaniu się do zmieniających się warunków i priorytetów i wymagać większych nakładów pracy. Może też być trudniejsza do utrzymania, ponieważ zespoły muszą stale dbać o jej przestrzeganie i aktualizację.
O DoD powinniśmy pamiętać i stosować je odruchowo. Dziesiątki czy setki kryteriów sprawiają, że zamiast intuicyjnego działania potrzebna jest nam „checklista”.
3. Co, jeśli DoD w naszej organizacji nie istnieje?
Jeżeli nie mamy Defintion of Done w organizacji, to powinniśmy wprowadzić jakąś listę kryteriów według naszego widzimisię. Przy czym to nigdy nie jest tak, że bierzemy je „z sufitu” – każdy z nas w jakiś sposób rozumie, co to znaczy „skończone” i jakiej to coś powinno być jakości. Kryteria te różnią się między poszczególnymi osobami, tak więc powinniśmy zsumować wszystkie głosy i zapewnić jedno spójne rozumienie DoD.
Brak Definition of Done na poziomie całej organizacji prawie na pewno oznacza różne standardy jakości, brak klarowności i idące za tym nieporozumienia. Każdy porządny Scrum Master na pewno odruchowo zajmie się tym problemem.
4. Jak ma się DoD do Zobowiązań z nowej wersji Scrum Guide?
Nowa wersja Scrum Guide w końcu określiła miejsce Definition of Done we frameworku. Od 2020 roku Definition of Done jest jednym z trzech Zobowiązań (razem z Celem Produktu i Celem Sprintu). Tak więc osoby aktywnie wykonujące pracę nad Przyrostem (czytaj: Deweloperzy) zobowiązują się, za pośrednictwem DoD, że ukończona praca spełnia odpowiednie kryteria jakościowe.
5. Czego dotyczy DoD – wymagania, Przyrostu czy produktu?
Definition of Done odnosi się głównie do Przyrostu (Incrementu) oraz… poszczególnych elementów wykonywanej pracy (Product Backlog Item)! Ponieważ to cały Przyrost musi spełniać te kryteria, a my pracujemy iteracyjnie i przyrostowo, to kryteria DoD przykładamy zwykle do wszystkich części składowych, czyli poszczególnych wymagań. Sprawdzamy więc, że praca nad każdym elementem jest uważana za zakończoną i gotową do dostarczenia.
Jednakże, odnosząc się do całego produktu, często upewniamy się też, że wszystkie Przyrosty dostarczone w trakcie Sprintu spełniają kryteria DoD. Definition of Done jest więc stosowane do pracy nad poszczególnymi zadaniem, ale ma wpływ na cały produkt w miarę dodawania kolejnych Przyrostów.
6. Kto weryfikuje kryteria DoD?
Sprawdzenie, czy element pracy spełnia kryteria Definition of Done, jest odpowiedzialnością całego Zespołu Scrum. Oznacza to, że wszyscy członkowie zespołu, włączając w to Deweloperów, Scrum Mastera i Produkt Ownera, mają obowiązek wspólnie ocenić, czy dany element spełnia kryteria DoD. Natomiast pamiętajmy, że tylko Deweloperzy wykonują faktyczną pracę, która ma na celu spełnienie tych kryteriów! To tak gdybyście dostali takie pytanie na jakimś egzaminie…
7. Czy bez spełnienia kryteriów DoD można „odebrać” przyrost?
W teorii, Increment (Przyrost) nie powinien być wydany, jeśli nie spełnia kryteriów Definition of Done. Są one bowiem ustanawiane, aby zapewnić, że każdy Przyrost jest kompletny i gotowy do dostarczenia klientowi lub użytkownikowi końcowemu.
Sytuacja w której „omijamy” DoD nie powinna być standardem i niezależnie od okoliczności, zespół powinien podjąć środki w celu doprowadzenia Przyrostu (i wszystkich jego elementów składowych) do pełnej zgodności z kryteriami DoD. W praktyce, stosowanie kryteriów DoD jest kluczowe dla utrzymania jakości produktu i zapewnienia zadowolenia klienta.
Pamiętajmy też, że wymagania (Elementy Backlogu Produktu), które nie spełniają kryteriów Definition of Done nie są uznawane za ukończone i nie są też pokazywane na Sprint Review!
8. Czy można częściowo spełnić kryteria DoD?
DoD jest zazwyczaj opracowywana w sposób, który nie dopuszcza jej częściowego spełnienia. Wszystkie kryteria muszą być spełnione w całości, aby przyrost produktu był uważany za ukończony i gotowe do dostarczenia.
Jeżeli „spełniliśmy wszystkie kryteria poza jednym”, to znaczy, że nie spełniliśmy DoD i tyle. Zespół musi podjąć działania w celu spełnienia pozostałych kryteriów DoD przed uznaniem danego kawałka pracy za ukończony. Ewentualne zmiany do Definition of Done możemy wprowadzić na koniec Sprintu – na Sprint Retrospective.
9. Jakie kryteria mogą stanowić przykład DoD?
W naszym Definition of Done możemy zawrzeć różnorodne rodzaje kryteriów, które określają, kiedy praca jest uważana za ukończoną, gotową do dostarczenia i będącą odpowiedniej jakości.
I to właśnie kryteria jakościowe trafiają tam jako pierwsze (różnego rodzaju testy, brak błędów, kwestie związane z wydajnością, bezpieczeństwem, itd.). Równie istotne są kryteria procesowe (spełnienie określonych wymagań, dokumentacji, stosowanie procedur i procesów). Trzecią grupą, która często trafia do DoD to wymagania niefunkcjonalne (wygląd, styl, estetyka, kolorystyka, itd.). Często też dodajemy do tego kwestie związane z wdrożeniami (przygotowanie paczek, wdrożeń, procedur, itd.).
Każdy ma w głowie jakieś rzeczy, bez których „wstyd pokazać efekty naszej pracy” czy też „wdrożenie może być niebezpieczne”. Przelewając te kryteria na papier zyskamy pierwszą wersję naszej Definition of Done, którą potem będziemy mogli rozwijać.
10. Jaka jest różnica pomiędzy Definition of Ready i Definition of Done?
„Definition of Done” to termin, który wprost pochodzi ze Scrum Guide’a. Próżno jednak szukać tam informacji o Definition of Ready. O ile z samego niniejszego tekstu doskonale wiemy, czym jest DoD, to DoR może być zagadką.
Definition of Ready określa, kiedy dane zadanie lub element pracy jest gotowe do przyjęcia i rozpoczęcia nad nim prac. Inaczej mówiąc, jest to lista kryteriów i wymagań, które muszą zostać spełnione, zanim element pracy zostanie „wzięty na Sprint”. Niektórzy idą o krok dalej i mówią wprost, że na Planowaniu Sprintu nie dotkną żadnego elementu, który nie spełnia DoR. Często dzieje się tak dlatego, że zespół ma dość niedoprecyzowanych zadań lub niedostatecznego zrozumienia wymagań.
DoR może być pomocnym elementem, a może być antywzorcem, który pokazuje, że brakuje nam zaufania i wspólnego zrozumienia. Po więcej szczegółów na ten temat zapraszamy do tekstu o Definition of Ready.
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.