Definition of Done a kilka Zespołów Scrum

Kiedy zaczynałem pisać ten artykuł, miałem pomysł na prosty wpis poruszający temat Definition of Done w odniesieniu do kilku zespołów. O ile wydaje się, że ogólne zrozumienie czym jest Defintion of Done, to pojawiają się bardziej konkretne pytania. “Mam kilka zespołów, które pracują nad tym samym Produktem. Co powinno być w ich Definition of Done?” “Czy każdy może mieć różną Definition of Done“
Jednak w miarę pisania doszedłem do wniosku, że podstawy mogą wcale nie być takie oczywiste. Zatem zacznijmy od podstaw.

Definition of Done

Definition of Done to standard/checklista określająca stan wykonanej pracy. Kiedy Deweloperzy mówią, że coś jest zrobione/ukończone, czyli Done, to powinniśmy jasno wiedzieć co przez to rozumieją. Każdy ukończony element Backlogu Produktu (PBI) staje się elementem Przyrostu Produktu. Zatem Definition of Done tak naprawdę dotyczy stanu Przyrostu Produktu. Zgodnie z zasadą potencjalnie dostarczalnego Przyrostu na koniec każdego Sprintu, Definition of Done powinno określać taki właśnie stan.

Jeżeli z ważnych przyczyn nie jesteśmy zdolni do dostarczenia takiego poziomu jakości, to nie ma sensu tworzyć idealnej Definition of Done, a w rzeczywistości dostarczać poniżej tego standardu. To by było zwykłe oszukiwanie i tworzenie długu technicznego nie wprost. Product Owner jest przekonana, że idzie bardzo dobrze, a w rzeczywistości mamy nieokreśloną ilość niewykonanej pracy. Taka sytuacja prędzej czy później przyniesie negatywne konsekwencje. Zatem Definition of Done powinna przedstawiać to, co jesteśmy w stanie osiągnąć. Można ją z czasem wzmacniać. Definiton of Done jest jasno ustalana pomiędzy Product Ownerem a Developerami.

Natomiast zwykle nie rodzi się z próżni i nie jest po prostu wymyślana ad hoc. Podstawą do zbudowania Definition of Done są istniejące już w organizacji standardy. Organizacja lub dział IT zazwyczaj posiadają już pewne standardy, które są przestrzegane. Na przykład standardy kodowania i używane narzędzia lub polityka testów są już ustalone, więc budowanie Definition of Done należy zacząć od uwzglednienia ich.

Przykład Definiton of Done

• Unit Test na poziomie 95% minimum.
• Co najmniej jeden test Selenium dla każdego P.B.I.
• Kod przeszedł przeglad lub był napisany w Pair Programming
• Build na Jenkinsie jest zielony
• Kod sformatowyna i zgodny ze s
• Ukończone P.B.I. dostępne na środowisku Test
• Zespół (Developerski) wykonał testy funkcjonalne
• Testy Akceptacyjne biznesowe zakończone pozytywnie
• Wszystkie warunki satysfakcji P.B.I. spełnione
• Wszystkie zadania w JIRA “Done”
• Brak otwartych defektów
• Funkcjonalność działa poprawnie i nie psuje innych (integracja i regresja)
• Dokumentacja w postaci podręcznika użytkownika w wersji PL i EN
• Interfejs uzytkownika w językach EN i PL

Kilka zespołów i ta sama technologia — co z Definition of Done?

Wydaje się, że sytuacja jest bardziej skomplikowana, kiedy mamy więcej niż jeden Zespół pracujący nad Produktem. Nic bardziej mylnego. Zasady pozostają niezmienne. Nadal jest jeden Product Owner i jeden Przyrost, więc jedna i ta sama Definition of Done. Gdyby tak nie było, to jakość i stan Przyrostu byłyby takie same jak tych PBI zespołu o najniższej Definition of Done. Łańcuch będzie tak słaby jak najsłabsze ogniwo. Zatem, podsumowując nawet przy większej ilości zespołów definicja Definition of Done jest jedna i obowiązuje wszystkich.

Kilka zespołów, ale w kilku technologiach — co z Definition of Done?

W sytuacji, kiedy mamy dwa i więcej Zespoły pracujące nad jednym produktem może pojawić się taki problem, że są różnice w używanych technologiach. Na przykład jeden zespół specjalizuje się w SAP, drugi pracuje w Java, a trzeci tworzy aplikację mobilną. No i co zrobić z Definition of Done? Nie mogą mieć identycznej bo nie spełnią jej. Ale z drugiej strony Definition of Done powinna być jedna, żeby wiedzieć w jakim stanie jest Produkt.
Jest na to proste rozwiązanie. Wszystkie zespoły ustalają wspólną Definition of Done, którą są w stanie spełnić. Powinny tam trafić takie rzeczy jak sposób wykonywania pracy, sposób testowania, przebieg procesu, narzędzia wspólne dla wszystkich, standardy narzucone przez organizację, standardy dokumentacji itp. W tej definicji jest też zawarty warunek, że praca wszystkich zespołów powinna być zintegrowana przed Review. Elementy unikalne dla poszczególnych zespołów albo unikalny sposób ich realizacji trafia do Definition of Done specyficznej dla konkretnego zespołu. Można zatem powiedzieć, że każdy Zespół ma Definition of Done, która składa się z części wspólnej i części unikalnej. Najważniejsze, żeby zintegrowany Przyrost Produktu był tej samej, stabilnej jakości w każdym obszarze.