Wyobraź sobie, że jesteś na Sprint Planningu z całym Scrum Teamem i ustalacie zakres następnego Sprintu. Skupiacie się na każdym elemencie Product Backlogu (PBI) indywidualnie, deklarując wykonanie każdego z nich wraz z końcem Sprintu? Czy może myślicie tylko o PBIs, które są związane z Celem Sprintu i dyskusje toczą się głównie wokół nich? Pierwsze podejście jest bardzo popularnym antywzorcem, kiedy to skupiamy się na ukończeniu poszczególnych zadań, a nie na wartości jaką mają one przynieść. No i tu właśnie pojawia się pojęcie “ukończenia”. Na jakiej podstawie określacie, czy zdefiniowany zakres prac został zrealizowany? Jak wygląda Wasza Definicja Ukończenia (Definition of Done, DoD)? I czy w ogóle ją posiadacie?!
Czym jest Definicja Ukończenia?
Parafrazując fragment Przewodnika po Scrumie uzyskujemy poniższą definicję: Definicja Ukończenia jest zobowiązaniem, które ma zapewnić dostęp do informacji poprawiających przejrzystość i skupienie w odniesieniu do których można mierzyć postęp Icrementu. Po raz pierwszy w historii Scrum Guide’a pojawia się słowo “zobowiązanie” w stosunku do DoD. Dzięki tej modyfikacji wiemy, że realizując Increment zobowiązujemy się do tego by był on zgodny z naszymi postanowieniami zapisanymi w postaci Definicji Ukończenia. Jest to “formalny opis stanu Incrementu, w którym spełnia on kryteria jakościowe wymagane dla produktu.”
Jak ustalać DoD?
Definicja Ukończenia powinna być z nami od początku naszych prac nad produktem. Warto więc ustalić ją na starcie. Można tego dokonać np. na kick-offie projektu, kiedy to często poznajemy się wzajemnie i zaznajamiamy się z wizją i Celem Produktu. Jednak zwykle w organizacjach, które pracują zgodnie z duchem Agile i wykorzystują ramy Scruma do wytwarzania produktów, taka definicja jest pewnego rodzaju standardem. Wtedy też nie tworzymy definicji od początku. A jedynie ją weryfikujemy tę utworzoną przez organizację, traktując jako minimum i dopasowujemy do specyfiki naszego produktu. Można zająć się tym na wspomnianym kick-offie. Albo zorganizować dedykowane spotkanie, którego celem będzie wspólne zrozumienie “co dla nas znaczy, że ukończyliśmy pracę?”.
Często spotykaną praktyką jest ustalanie DoD na pierwszym Sprint Retrospective, osobiście jednak nie jestem zwolenniczką takiego podejścia. Dlaczego? Jak Scrum Team określi po pierwszym Sprincie co zostało ukończone? Można by powiedzieć “na czuja”, albo “każdy wie co znaczy “done”. W praktyce jednak okazuje się, że każdy z nas może mieć trochę inną definicję, co może powodować pewne nieporozumienia. Aby tego uniknąć sugeruje zorganizowanie osobnego spotkania, a pierwsze, czy kolejne, Sprint Retrospective potraktować jako czas na skonfrontowanie naszych wstępnych ustaleń z rzeczywistością.
Co powinna zawierać Definicja Ukończenia?
To bardzo trudne pytanie. Scrum Guide nie definiuje jasno co powinna zawierać wspomniana Definicja Ukończenia. Znam zespoły, które tworzą reguły zrozumienia “done” na poszczególne etapy przepływu pracy (workflow). Inne z kolei skupiają się tylko na efekcie końcowym. To w jaki sposób Ty i Twój zespół do tego podejdziecie jest nierozerwalnie związane z inspekcją i adaptacją całego procesu. Nie ma jasnej recepty, czy gotowej definicji DoD. Warto więc wyjść od “jakiejś” Definicji Ukończenia, a następnie zweryfikować ustanowione punkty i dostosować ją do naszych realiów.
Jedno jest pewne, Definicja Ukończenia powinna pomóc nam odpowiedzieć na pytanie “czy nasza praca, w postaci PBI (oczywiście jako zespołu) została ukończona i jest częścią Incrementu?”. Nie powinna być ona zbyt obszerna, napisana zawiłym językiem, a być prosta w weryfikacji i stosowaniu. Stanowczo odradzam punkty typu “każdy pull request powinien zawierać przynajmniej jeden test jednostkowy, zostać sprawdzony przez dwie osoby (code review), posiadać scenariusze testowe, które będą znajdowały się w bazie wszystkich przypadków testowych … “. Gdy stworzymy taki zapis sami możemy się w tym pogubić. Dobrym przykładem punktu, które może zawierać nasze DoD jest “wszystkie kryteria akceptacji zostały zaimplementowane i zweryfikowane na środowisku QA” albo “przetestowane i poprawnie działające PBI zostaną wrzucone na środowisko UAT”. Im prostsze będą punkty tym łatwiej i chętniej będziemy ich przestrzegać i podążać w zobowiązaniu realizacji Incrementu.
Jak dbać o DoD?
Po pierwsze tak często jak to konieczne. Czyli jak często? Oczywiście “to zależy” m.in. od tego jak dojrzały jest zespół. Jak ustalone na początku współpracy punkty rezonują z naszą codzienną pracą, itd. Nadgorliwością może być sprawdzanie stosowności i zakresu DoD na każdym Sprint Retrospective. Jednak, nie zaszkodzi, jeżeli raz na jakiś czas całym zespołem pochylimy się nad Definicją Ukończenia i sprawdzimy, czy wymaga ona jakiś zmian. Sprint Retrospective może być świetną okazją do dokonania inspekcji i adaptacji, jednak nie jedyną. Możemy zorganizować osobą sesję, a Sprint Retrospective przeznaczyć na bardziej bieżące ustalenia. Powyższe stwierdzenia dotyczą dedykowanej pielęgnacji. Bieżąca dbałość o DoD dzieje się przy każdym stwierdzeniu “ten PBI jest done”. Oraz na koniec każdego Sprintu, kiedy to oddajemy Increment potencjalnie gotowy do wydania.
Podsumowanie
Definicja Ukończenia wspiera przejrzystość wytwarzanego produktu i prac nad nim prowadzonych. Jest zobowiązaniem pozwalającym nam mierzyć postęp realizacji Incrementu. Stanowi przy tym nieodłączny element pracy w Scrumie. Mówiąc krótko, gdy zespół nie posiada DoD nie pracujemy we wspomnianym frameworku, a jedynie wykorzystujemy jego elementy. Brak ustalonego i przestrzeganego Definition of Done jest częstym powodem niezadowolenia i niepowodzenia w stosowaniu Scruma. (Więcej na ten temat możesz przeczytać tutaj: Houston, mamy problem, Scrum nie działa! (cz. 1)). To jakie punkty zawiera nasza definicja jest kwestią indywidualną każdego zespołu i organizacji. Ważne, żeby nie było one zbyt skomplikowane, a proste i łatwe w stosowaniu i weryfikowaniu. Definicja Ukończenia ma nam pomagać w realizacji Product Backlog Itemów będących częścią Sprint Backlogu, a nie utrudniać życie. Pamiętajmy także, że jak każdy element pracy w Scrumie, również i DoD powinno podlegać procesowi inspekcji i adaptacji.
Sprawdź nasze ostatnie wpisy:
