Blog

Czym jest Definition of Done?

Wyobraźmy sobie, że na moment odłożyliśmy dotychczasową pracę i zajęliśmy się wytwarzaniem mebli. Zacznijmy od najprostszego, drewnianego krzesła. Co czyni to krzesło krzesłem?

Po pierwsze, to musi być poskładany mebel. Nie interesuje nas jedynie stos zafoliowanych części wyjętych ze sklepowego kartonu.

Po drugie, na tym meblu można bezpiecznie usiąść. Śruby wkręciliśmy mocno, a chropowate powierzchnie zawczasu wygładziliśmy. Istnieje nikłe niebezpieczeństwo wbicia sobie drzazgi.

Po trzecie, mebel jest stabilny. Nie nazwiemy krzesłem przedmiotu o dwóch nogach, a najpewniej będziemy chcieli siadać na takim z czterema nogami. Więc jeśli przez błąd pakowacza zabrakło nam jednej fabrycznej nogi, zwracamy zakup do sklepu lub żądamy dosłania elementu – bez tego to niekompletny produkt, którego nie da się postawić w jadalni, i nie da się normalnie używać.

Takie kryteria definiują, czy coś jest używalnym krzesłem, czy tylko bezużyteczną zbieraniną drewnianych i metalowych części. Nazywamy to Definition of Done (Definicją Ukończenia).

Wyobraźmy sobie taką checklistę do przejścia za każdym razem, gdy chcemy zdecydować czy mamy do czynienia z krzesłem. Skręciliśmy je? Ma cztery nogi? Stoi stabilnie? Spiłowaliśmy drzazgi? Można na nim bezpiecznie usiąść? Jeśli na każde z pytań odpowiemy “tak”, mamy do czynienia z produktem jakim jest krzesło. Proszę siadać!

Ze spełnienia Definition of Done nie wiemy jednak nic o tym, czy krzesło jest drogie czy tanie, czy pasuje do wystroju salonu, czy ma regulowane części, czy jeszcze jakiś element powinien być dodany do produktu dla wygody użytkownika itp. Wiemy tylko, że mamy używalne krzesło.

Jak użyć Definition of Done?

Odłóżmy meblarstwo, a wróćmy do dziedziny wytwarzania oprogramowania. W Scrumie Definition of Done jest na sztywno przytwierdzone do Przyrostu Produktu (Increment). Bez Definition of Done nie możemy bowiem stwierdzić, czy istnieje Przyrost Produktu, czy tylko niepowiązane ze sobą wyniki jakiejś pracy nad wymaganiami (z których nie wiadomo do końca, które są używalne, a które wymagają dalszej pracy). W ten sposób Definition of Done jest podstawowym narzędziem zapewniania przejrzystości: zerojedynkowo określa co zostało zrobione i można tego używać, a czego jeszcze użyć nie sposób (bo nie zostało ukończone).

Napisaliśmy kod i trzymamy go sobie lokalnie. Czy można go użyć? Nie! Wymaga jeszcze różnego rodzaju testów. Zaktualizowania dokumentacji. Odłożenia w repozytorium. Pewnie jeszcze wielu innych punktów kontrolnych z naszej checklisty. Dopiero gdy odznaczymyje wszystkie, będziemy mieli jasność: to, co stworzyliśmy, spełnia Definition of Done, może się więc nazywać Przyrostem Produktu. Najprościej: możemy tego użyć i zobaczyć, czy spełnia biznesowe potrzeby zamawiającego.

To, co jedynie rozgrzebaliśmy, czego nie skończyliśmy, co napisaliśmy ale nie przetestowaliśmy itd. – nie przechodzi przez checklistę. Dopóki nie spełni więc Definicji Ukończenia, nie będzie częścią Przyrostu.

A co z produktami spoza świata oprogramowania, np. dokumentami jak książka? One też mogą mieć swoje Definition of Done. Wystarczy ustalić, co jest niezbędne by taki dokument móc wydać końcowemu odbiorcy. Samo napisanie tekstu? Jeszcze nie. Złożenie w odpowiednim formacie? Jeszcze nie. Poprawna numeracja stron? Też jeszcze nie. Sprawdzenie literówek? Poprawa błędów gramatycznych i składniowych? Eksport do PDF w przypadku ebooka? Wydruk i oprawa? Pewnie dopiero w tym punkcie odbiorca może użyć dokumentu zgodnie ze swoim życzeniem (np. siadając z książką na skręconym wcześniej krześle).

Żaden z tych elementów checklisty nie mówi rzecz jasna nic o atrakcyjności tekstu, jego objętości, kwiecistości stylu itp. Nie wiemy, czy między okładkami znajduje się jakaś szczegółowa instrukcja, przepisy kuchenne czy porywająca literatura przygodowa. Wiemy natomiast z całą pewnością co jest gotową książką, a co stanowi wyłącznie luźne notatki “na brudno”, nienadające się do użycia (czyli w tym przypadku wygodnego czytania).

Jak stworzyć Definition of Done?

Jeśli w naszej organizacji już istnieją jakieś standardy produkcyjne, warto ich użyć jako punktu wyjścia. Jeśli jednak nie mamy ich, lub z jakichś powodów nie chcemy ich użyć do nowego produktu, warto posłużyć się poniższymi poradami.

1. Sprawdźmy, co to znaczy, że produktu da się użyć; na jakie środowisko musi być wydany, jakie testy ma przejść nim to się stanie, jaką dokumentację musi posiadać.
2. Ustalmy dokładne warunki: jakie konkretnie testy wykonujemy, jakiego typu i na jakim poziomie, jaki ich efekt nas satysfakcjonuje?
3. Zdefiniujmy co oznacza, że praca członków zespołu została zintegrowanaw jeden produkt. W jaki sposób to sprawdzimy? Gdzie?
4. Trzymajmy się wspólnego nazewnictwa, zarówno w kwestii pisania kodu, jak i dokumentowania.
5. Jeśli uznajemy coś za skończone, musimy liczyć się z tym, że może to zostać od razu wydane. Wprawdzie decyzja o wydaniu jest biznesowa (podejmuje ją w Scrumie Product Owner), ale przygotowany Przyrost Produktu jest potencjalnie wydawalny. Czyli można go użyć produkcyjnie, jeśli zechcemy (a jak radzić sobie, gdy to nieosiągalne i jak używać wtedy Scruma – napiszemy w następnym artykule). Choć oczywiście samo wydanie produktu może wymagać wykonania jakiejś dodatkowej pracy, ważne by nie była to praca związana z wytwarzaniem produktu.
6. Jeśli możemy cokolwiek z tej listy sensownym kosztem zautomatyzować – zróbmy to.
7. Definition of Done rośnie wraz z produktem. Będą do niego dodawane nowe kryteria (rzadziej może się też zdarzyć, że odejmowane), a te już istniejące będą bardziej wyśrubowane. Dlatego jego kształt podlega regularnej inspekcji i adaptacji, jak wszystkie elementy Scrum; dobrym momentem do zmieniania DoD jest Retrospektywa Sprintu – wówczas nowa Definicja Ukończenia obowiązuje od początku nowego Sprintu.