Jeżeli miałabym opisać Scruma jednym zdaniem, to byłoby to: empiryczne podejście do tworzenia Produktu, w którym przynajmniej raz w Sprincie uzyskujemy Przyrost gotowy do wdrożenia, czyli spełniający Definicję Ukończenia.
Dzięki określeniu czym jest ukończony Przyrost i generowaniu ich co Sprint, możemy sprawniej dostarczać rozwiązania użytkownikom. Szybciej wykonujemy inspekcję i adaptację kierunku rozwoju, zmniejszając tym samym ryzyko i koszty dostarczania niewłaściwych rozwiązań. I choć Definicja Ukończenia nie wydaje się być centralną częścią Scruma, to w istocie jest niezwykle ważnym jego elementem.
Czym jest i co nam daje Definicja Ukończenia?
Definicja Ukończenia (ang. Definition of Done, DoD) jest zobowiązaniem wobec Przyrostu. Jest to formalny opis jego stanu, w którym spełnia on kryteria jakościowe wymagane dla produktu [1]. Jak sama nazwa wskazuje, jest to zbiór koniecznych do spełnienia warunków, by uznać Przyrost za ukończony, a zatem gotowy do wdrożenia.
Definicja Ukończenia wspiera empiryzm poprzez tworzenie przejrzystości – dla Zespołu, organizacji i Interesariuszy. Mówi o tym jaką jakość mają nasze rozwiązania. Dzięki DoD każdy będący częścią procesu wytwórczego tak samo rozumie, jaka praca została wykonana w trakcie tworzenia Inkrementu.
Definicja Ukończenia ma znaczenie w kontekście każdego wydarzenia Scrumowego [3]. W Sprincie dążymy do wygenerowania ukończonego Przyrostu. Na Planowaniu Definicja Ukończenia pomaga Zespołowi zrozumieć cały zakres prac, umożliwiając lepsze dostosowanie ilości zadań w Sprincie oraz przygotowanie planu działania. Podczas Daily DoD pomaga każdego dnia budować odpowiedzialność zespołową za Produkt. Na Sprint Review ukazujemy Przyrosty spełniające Definicję Ukończenia, uzyskując dzięki temu lepszą przejrzystość. Retrospektywa jest natomiast momentem inspekcji i adaptacji DoD.
kto odpowiada za Definicję Ukończenia?
Za stworzenie i stałe usprawnianie Definicji Ukończenia odpowiedzialny jest cały Zespół, czyli Developerzy, Product Owner i Scrum Master razem. Dobra Definicja Ukończenia jest wypracowana w ramach współpracy osób wchodzących w skład Zespołu. Perspektywy różnych ról będą sprawiać, że warunki jakościowe dla Produktu będą obszerniej obejmowały różne jego aspekty (kod, testy, biznes etc.).
Jako Product Owner określ wymaganą przez rynek jakość Produktu (uwzględniając wiedzę o konkurencji) oraz formalności, które musi spełniać każdy Przyrost. Bierz udział w Retrospektywach, by aktywnie szukać sposobów na zwiększanie jakości Produktu.
Dobrym pomysłem jest również rozmowa z Managementem oraz Interesariuszami, o tym czym jest dla nich ukończony Przyrost. I choć za DoD wciąż odpowiada Zespół Scrumowy, to taka rozmowa może wnieść przydatną perspektywę do tworzenia użytecznej Definicji Ukończenia.
Dlaczego Product Owner powinien interesować się Definicją Ukończenia?
Tylko dzięki wdrażaniu gotowych rozwiązań dla użytkowników dostarczamy wartość, za której maksymalizację odpowiada Product Owner. Zatem w każdym Sprincie dążenie do wysokiej jakości ukończonych Przyrostów, które można regularnie wdrażać, powinno być kluczowe dla każdego Product Ownera [4].
4 kroki do zbudowania dobrej Definicji ukończenia
#1 Zapoznajcie się z sensem Definicji Ukończenia
Na początku warto zadbać o to by każda osoba w Zespole wiedziała czym jest Definicja Ukończenia i jaki jest jej cel.
Dobra Definicja Ukończenia jest pragmatyczna. Zespół musi być w stanie każdego Sprintu realizować jej warunki. Nie powinna być to zatem lista życzeń, dotycząca jakości, do której dążymy. Jeżeli DoD stawia nierealne do spełnienia warunki, to członkowie Zespołu mogą mieć poczucie, że jest ona niepotrzebna.
Przykładowo: nie ma sensu ustalać, że będziemy tworzyć testy automatyczne do wszystkich realizowanych PBI, jeżeli Produkt technicznie jest jest przygotowany na automatyzację testów.
#2 Zacznijcie od Definicji Ukończenia organizacji
Niech punktem wyjścia do ustaleń zespołowych będzie Definicja Ukończenia wymagana przez organizację, o ile taka istnieje. DoD obowiązujące w danym Zespole powinno ją zawierać, oraz być rozszerzone o kontekst danego Produktu i Zespołu.
Przykładowo: organizacja może wymagać, by pewien poziom dokumentacji lub innych formalności był spełniony, by Przyrosty mogły być zgodne z obowiązującymi procedurami. Może to być szczególnie istotne dla Produktów z rynków regulowanych (medyczny, bezpieczeństwo, finanse itp.).
#3 Rozbudujcie Definicję Ukończenia o perspektywę Zespołu
„Done” oznacza, że Przyrost można wdrożyć bez żadnej dodatkowej pracy. Dla różnych Produktów i Zespołów może mieć to inne znaczenie.
Zastanówcie się jak wygląda wasz proces tworzenia Produktu. Dla każdego z etapów określcie warunki dla Przyrostu, by uzyskać jego maksymalną, lecz realną do spełnienia jakość. Ustalcie jakie formalności powinien spełniać, by bez zwłoki udostępnić go użytkownikom, gdy zapadnie taka decyzja.
Ustalenia zapiszcie w formie checklisty w miejscu dostępnym dla Zespołu oraz innych zainteresowanych. Oto Wasza Definicja Ukończenia.
* Jeżeli kilka Zespołów pracuje nad jednym Produktem generując wspólny Przyrost, to powinni mieć jedną Definicję Ukończenia. Inna jakość poszczególnych kawałków składających się na ukończony Przyrost może prowadzić do chaosu i trudności w integracji [2].
#4 Regularnie sprawdzajcie i usprawniajcie Definicję Ukończenia
Definicja Ukończenia nie jest statyczna [5]. Jej tworzenie to proces.
Definicja Ukończenia powinna ewoluować. Początkowo tworzona jest jej wersja, która jest możliwie najlepsza na danym etapie pracy nad Produktem. Z biegiem czasu dokonujemy jej inspekcji i adaptacji.
Podczas Retrospektyw powinniśmy rozmawiać o jakości Produktu. Jeżeli znajdujemy deficyty w procesie, spróbujmy go usprawnić i rozszerzyć Definicję Ukończenia o ustalone wnioski, by stale zwiększać jakość dostarczanych Przyrostów.
Wracając do omawianego wcześniej przykładu: jeżeli Produkt technicznie nie jest przygotowany na automatyzację testów, a jest to jakość, którą chcecie zapewnić, to zaplanujcie pracę nad tym aspektem. Jeżeli dojdziecie do punktu, w którym pisanie testów automatycznych jest realne, to dodajcie ten warunek do Definicji Ukończenia.
Przykładowe warunki W Definicji Ukończenia
wykorzystanie Definicji Ukończenia w praktyce
Załóżmy, że mamy już dobrze wypracowaną Definicję Ukończenia. Developerzy muszą zachować zgodność z jej warunkami za każdym razem, gdy tworzą Przyrost. Czyli co Sprint.
Jak to zrobić? Jak przy obszernej liście punktów nie zapomnieć o jej poszczególnych elementach?
Pewne warunki muszą być spełniane na bieżąco i każdego dnia przez Developerów, bowiem są powiązane z dobrymi praktykami lub obowiązującymi procedurami (np. ustalone standardy kodu czy code review). Powtarzane codziennie czynności łatwo wchodzą w nawyk.
Natomiast część z warunków wymaga dodatkowych czynności wykonanych na koniec Sprintu. By o niczym nie zapomnieć, w moim Zespole do obiektu Celu Sprintu w Sprint Backlogu przypisane są zadania (ang. task) obrazujące każdy z punktów Definicji Ukończenia. Gdy zbliżamy się do końca Sprintu, zadania te wypływają na początek listy omawianej podczas Daily.
Zespół dzieli się zadaniami, realizuje je i śledzi postęp prac. Robimy to, by uzyskać pewność, że Przyrost spełnia wszystkie warunki wypracowanej Definicji Ukończenia.
Przykładowe warunki Definicji Ukończenia w postaci zadań w programie do śledzenia zadań
PODSUMOWANIE
Definicja Ukończenia jest ważnym elementem dla tworzenia Przyrostów na koniec każdego Sprintu. Jest strażnikiem jakości, który wskazuje czym są ukończone rozwiązania i kiedy są gotowe do wdrożenia. Definicja Ukończenia wspiera empiryzm, dzięki budowaniu przejrzystości. By spełniała jednak swoje zadanie musi być dostosowana do kontekstu Produktu i Zespołu, który go tworzy, oraz regularnie poddawana inspekcji i adaptacji.
BIBLIOGRAFIA
[1] Przewodnik po Scrumie; https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf
[2] Definition of 'Done’: Dysfunctions & Tips; https://www.scrum.org/resources/blog/definition-done-dysfunctions-tips
[3] Definition of 'Done’: What It Is and How It Supports Scrum Events; https://www.scrum.org/resources/blog/definition-done-what-it-and-how-it-supports-scrum-events
[4] The importance of Done for your Product Owner (75), https://www.scrum.org/resources/blog/importance-done-your-product-owner-75
[5] Definition of Done Theses; https://www.scrum.org/resources/blog/definition-done-theses
[6] Why getting to Done matters in Scrum; https://www.scrum.org/resources/blog/why-getting-done-matters-scruma