Zadanie zostaje oznaczone jako zrobione na tablicy, sprint się kończy, a tydzień później to samo zadanie wraca jako zgłoszenie błędu - bez testów, bez dokumentacji, czasem nawet bez code review. Problem nie leży w jakości pracy konkretnej osoby, a w braku wspólnej Definition of Done, czyli jasnej definicji tego, co właściwie oznacza "zrobione" w danym zespole.
Bez tej definicji każda osoba ma własne kryterium zakończenia zadania. Dla jednej "zrobione" znaczy "kod działa na moim komputerze", dla drugiej - "kod przeszedł testy i jest opisany w dokumentacji". Te różnice są niewidoczne, dopóki nie wyjdą na wierch w najgorszym możliwym momencie.
W tym artykule pokażę, co powinno znaleźć się w Definition of Done, jak ją ustalić dla konkretnego zespołu i dlaczego jej brak prowadzi do narastania długu technicznego i nieprzewidywalne sprinty.
Czym jest Definition of Done
Definition of Done to lista konkretnych warunków, które musi spełnić zadanie, żeby można je było uznać za naprawdę zakończone - nie "prawie gotowe" albo "działa, ale jeszcze coś trzeba dopisać". Lista ta jest ustalana wspólnie przez zespół i obowiązuje dla każdego zadania tego samego typu, niezależnie od tego, kto je wykonuje.
To różni się od kryteriów akceptacji konkretnego zadania, które opisują, co dokładnie ma robić ta jedna funkcja. Definition of Done dotyczy jakości i kompletności pracy ogólnie - obowiązuje dla wszystkich zadań, nie tylko jednego.
Dlaczego brak Definition of Done szkodzi zespołowi
Różne rozumienie słowa "zrobione"
Bez spisanej definicji każda osoba w zespole intuicyjnie ustala własny standard. Lider odkrywa różnice w najgorszym momencie - kiedy klient zgłasza błąd w funkcji, która od tygodni wisiała w kolumnie "Gotowe".
Co gorsza, każda z tych osób jest przekonana, że robi to dobrze - nikt nie celowo skraca pracy, po prostu nikt wcześniej nie ustalił, gdzie leży granica między "zrobione" a "do dokończenia".
Dług techniczny rosnący w cieniu
Zadania zamykane bez testów czy code review wydają się szybciej zakończone, ale w rzeczywistości tylko przenoszą pracę na później - i to pracę droższą, bo trzeba ją wykonać w kodzie, który już działa na produkcji. Więcej o tym mechanizmie przeczytasz w artykule Dług techniczny - czym jest i jak nim zarządzać.
Różnica jest podobna do odkładania remontu w domu - im dłużej drobna usterka czeka, tym więcej szkód wyrządza w międzyczasie i tym więcej kosztuje naprawa, gdy ktoś wreszcie się nią zajmie.
Nieprzewidywalne sprinty
Jeśli "zrobione" zadania w praktyce wymagają jeszcze dodatkowej pracy, estymacje kolejnych sprintów stają się bezwartościowe - zespół planuje na podstawie fałszywych danych o tym, ile pracy faktycznie zostało wykonane. Wpływa to też na trafność metod opisanych w artykule Estymacja zadań w zespole - jak szacować czas realizacji.
Co powinno znaleźć się w Definition of Done
Kod i testy
Standardowym elementem jest wymóg, żeby kod przechodził testy automatyczne i nie wprowadzał regresji w istniejącej funkcjonalności. Dla zespołów bez pełnej automatyzacji testów minimalnym wymogiem może być manualne sprawdzenie kluczowych scenariuszy.
Dokumentacja
Zmiana, która nie jest opisana w dokumentacji projektu, jest niewidoczna dla osób, które dołączą do zespołu później albo po prostu zapomną szczegółów po kilku miesiącach. Sposób prowadzenia takiej dokumentacji opisuje artykuł Dokumentacja projektu - co, gdzie i jak zapisywać.
Code review
Zadanie niezweryfikowane przez drugą osobę częściej zawiera błędy, które łatwo przeoczyć, pisząc kod samodzielnie. Code review jako element Definition of Done eliminuje sytuacje, w których zadania trafiają na produkcję bez żadnej drugiej pary oczu.
Akceptacja kryteriów biznesowych
Nawet technicznie poprawne zadanie nie jest zrobione, jeśli nie realizuje tego, czego potrzebował klient albo product owner. Krótkie potwierdzenie od osoby odpowiedzialnej za wymagania biznesowe zamyka pętlę między tym, co zostało zbudowane, a tym, co było potrzebne.
Jak ustalić Definition of Done dla swojego zespołu
Najlepiej zacząć od krótkiego spotkania, na którym zespół wypisuje, co w przeszłości "wracało" jako problem mimo oznaczenia zadania jako zrobione. Każdy taki przypadek staje się kandydatem na punkt w Definition of Done - to znacznie skuteczniejsze niż kopiowanie listy z innego zespołu albo z internetu, bo odnosi się do realnych problemów, które już się zdarzyły.
Lista nie musi być długa. Cztery lub pięć konkretnych, sprawdzalnych punktów działają lepiej niż piętnaście ogólnych zasad, których nikt nie pamięta podczas codziennej pracy.
Warto też ustalić, czy Definition of Done jest taka sama dla każdego typu zadania, czy różni się na przykład między poprawką błędu i nową funkcją. Najczęściej wystarcza jedna wspólna lista z dopiskiem, które punkty są opcjonalne dla drobnych poprawek.
Definition of Done vs Definition of Ready
Definition of Done określa, kiedy zadanie jest zakończone. Definition of Ready określa coś wcześniejszego - kiedy zadanie jest wystarczająco dobrze opisane, żeby zespół mógł je w ogóle zacząć, na przykład podczas Sprint Planning. Zespoły, które mają tylko jedną z tych dwóch definicji, nadal mają dziurę w procesie - albo zaczynają niejasne zadania, albo kończą je niedokładnie.
Najczęstsze błędy
Lista zbyt ogólna - punkty typu "kod jest dobrej jakości" nie da się zweryfikować i w praktyce nic nie znaczą.
Brak konsekwencji - jeśli czasem zadanie zamyka się bez spełnienia listy "bo się spieszymy", lista przestaje obowiązywać w ogóle.
Definition of Done ustalona przez jedną osobę - bez udziału zespołu lista trafia do szuflady i nikt jej nie stosuje w praktyce.
Nigdy nieaktualizowana lista - zespół, który zmienia sposób pracy, ale zostaje przy starej definicji, traci jej sens.
Przykład z praktyki
Zespół programistyczny zauważył, że co kilka sprintów wraca ten sam typ błędu - funkcja działała poprawnie w typowym przypadku, ale psuła się przy nietypowych danych wejściowych, których nikt nie testował przed zamknięciem zadania. Po analizie zespół dodał do Definition of Done punkt: "sprawdzono zachowanie funkcji przy przynajmniej jednym nietypowym przypadku danych wejściowych".
W kolejnych sprintach liczba zgłoszeń tego konkretnego typu błędu spadła wyraźnie, mimo że zespół nie zmienił niczego innego w swoim procesie - jeden konkretny, sprawdzalny punkt na liście wystarczył, żeby zmienić codzienne przyzwyczajenia.
To dobrze pokazuje, że Definition of Done nie musi być rozbudowana, żeby działać. Jeden trafny punkt, odnoszący się do realnego, powtarzającego się problemu, ma większy wpływ niż długa lista ogólnych zasad.
Jak Taskello pomaga przestrzegać Definition of Done
W Taskello listę warunków Definition of Done można dodać jako checklistę przy każdym zadaniu, dzięki czemu zanim zadanie trafi do kolumny "Gotowe", widać wprost, które punkty zostały zaznaczone, a które nie. To eliminuje sytuacje, w których "zrobione" oznacza coś innego dla każdej osoby w zespole.
Komentarze pod zadaniem pozwalają też zapisać, dlaczego dany punkt checklisty został pominięty w wyjątkowych sytuacjach, więc decyzja jest widoczna dla całego zespołu, nie tylko zapamiętana przez jedną osobę.
Administrator projektu może ustalić jedną checklistę jako standard dla danego typu zadań, więc każda nowa osoba w zespole od pierwszego dnia wie, czego się od niej oczekuje, zamiast uczyć się tego metodą prób i błędów po kilku tygodniach pracy.
Podsumowanie
Definition of Done nie jest formalnością do spisania raz i zapomnienia. To narzędzie, które eliminuje niejasności wokół słowa "zrobione" i zapobiega sytuacjom, w których dług techniczny narasta niezauważony pod warstwą zamkniętych zadań.
Jeśli Twój zespół nie ma jeszcze spisanej Definition of Done, zacznij od krótkiej listy opartej na realnych problemach z przeszłości, a nie na teoretycznym ideale - i wracaj do niej regularnie, na przykład podczas retrospektywy, żeby sprawdzić, czy wciąż odpowiada rzeczywistej pracy zespołu.
Jeśli chcesz dodatkowo ograniczyć liczbę zadań, które wiszą niedokończone w połowie pracy, sprawdź artykuł WIP limits - jak ograniczyć liczbę zadań w toku i zwiększyć przepływ pracy - oba podejścia dobrze się uzupełniają.