Przyrost produktuPrzyrost produktu

Na zakończenie każdego sprintu zespół dostarcza nową wersję rozwijanego produktu, czasem zwaną „przyrostem” albo „inkrementem” (od potentially shippable product increment). Produkt ów musi być tak dobry (takiej jakości), by mógł być zastosowany produkcyjnie – by użytkownicy mogli z niego korzystać. Innymi słowy produkt nie może wymagać wykonywania nad nim żadnej dodatkowej pracy poza ewentualną instalacją.

Definition of done

Definition of Done określa jakie cechy musi spełnić produkt, aby był technicznie używalny, czyli aby dało się go wydać. To oznacza, że jeśli DoD jest spełnione i Product Owner zechce wydać produkt, zespół developerski nie może sobie „przypomnieć” nagle, że jeszcze coś zostało do zrobienia, i że produktu nie da się wydać. Skoro technicznie jest gotowy, to życzenie Product Ownera bez trudu można spełnić.

Druga istotna kwestia dotycząca DoD: ma ono gwarantować, że w produkcie nie pojawia się dług techniczny, czyli że nie podejmowane są decyzje, które w przyszłości spowodują konieczność dodatkowej pracy, a więc spłacenia tego długu. Oczywiście czasami świadomie ten dług jest zaciągany, im „lepsze” DoD mamy, tym większa jego siła w blokowaniu takich zapędów. A zatem w DoD zakodować powinniśmy reguły, które wymuszą taki sposób pracy, aby produkt zachował (lub poprawiał) swoją jakość strukturalną (technologiczną).

Trzecia istotna kwestia to fakt, że DoD tworzone jest przez developerów. Product Owner uczestniczy w tym procesie jedynie jako doradca i dąży do zapewnienia, że Definition of Done rzeczywiście obejmuje listę czynności jakie trzeba wykonać, żeby produkt był zdatny do użycia. To zaś oznacza, że w DoD umieścić można tylko te rzeczy, które dla zespołu są realnie osiągalne w sposób powtarzalny. Jeśli umieszczone tam wpisy będą „na wyrost” i zespół nie będzie w stanie ich zaspokoić, wartość DoD będzie nikła, bo ignorując jeden element rychło przestaniemy zwracać uwagę na pozostałe.

 

Jeśli zdarzy się, że nie da się pogodzić tych trzech kwestii – a nie jest to rzadka sytuacja – czyli aby uzyskać produkt gotowy do wydania musielibyśmy stosować praktyki, jakich zespół użyć nie potrafi, wtedy DoD będzie niekompletne. Zespół musi wtedy dążyć do jak najszybszego wyeliminowania tej luki, ucząc się nowych praktyk, zmieniając proces jakim się posługuje, korzystając z nowych narzędzi.