Blog

Jednym z kluczowych konceptów w Scrumie jest Definition of Done, czyli po polsku Definicja Ukończenia lub Kryterium Ukończenia. W założeniu koncept trywialny, a jednak bardzo często źle rozumiany i mylony z kryteriami akceptacyjnymi wymagań.

Po ludzku: co to jest Definition of Done?

Jeśli wytwarzamy samochody, to Definition of Done będzie określało warunki jakie spełnić ma produkt, który można nazwać samochodem. Ma on przede wszystkim jeździć, zatem musi mieć koła, napęd, możliwość kierowania nim i hamowania. Ma spełniać wymogi prawne, normy bezpieczeństwa i środowiskowe etc. A przede wszystkim musi być poskładany w całość.

Definition of Done nie mówi, czy samochód ma być kabrioletem, kombi czy roadsterem, nie mówi jaki ma mieć bagażnik, kolor nadwozia czy tapicerkę – to już cechy pojazdu wynikające z potrzeb biznesowych, które opisane będą poszczególnymi wymaganiami.

Inny przykład: drukujemy książki. Definition of Done określi, że książką jest połączony w całość zbiór kartek w jednym ze standardowych formatów, zadrukowany wedle unormowanych zasad; że kartki wpięte są w poprawnej kolejności i nie wypadają, że druk się nie rozmywa, a farba i klej nie są toksyczne; że książka ma okładkę…

Definition of Done nie powie nam ile ma być rozdziałów, jakiego kroju czcionki użyć, jakiej gramatury papieru, czy okładka ma być twarda, czy obrazki mają być czarno-białe – to wymagania biznesowe.

Jeszcze jeden przykład: robimy oprogramowanie (a jakże!). Definition of Done wymagać będzie, aby napisany kod dało się uruchomić jako jedno zintegrowane rozwiązanie, w którym działają zarówno poprzednio istniejące funkcjonalności, jak i rzeczy dołożone w bieżącym sprincie. To oprogramowanie musi spełniać standardy technologiczne, mieć oczekiwaną wydajność i stabilność itd., a jeśli to potrzebne, wytworzyć trzeba również aktualną dokumentację techniczną.

Definition of Done dla oprogramowania nie determinuje wszakże jak wyglądać ma graficzny interfejs użytkownika, jakim algorytmem mają być przeliczane dane księgowe, jakie operacje wymagają nadania użytkownikowi specyficznych uprawnień, ani tego, czy w środku nocy będzie robiona „przerwa konserwacyjna”, podczas której produkt jest niedostępny. To wszystko wymagania biznesowe, opisujące sposób działania oprogramowania, a nie sposób, w jaki należy go wytworzyć.

Parę słów o kolejności

Z faktu, że Definition of Done opisuje warunki, jakie muszą zostać spełnione, aby „coś” wytworzone przez developerów można było w ogóle uznać za działający produkt, pojawia się oczywisty wniosek: dopiero po spełnieniu Definition of Done ma sens sprawdzenie, że zaspokojone zostały wymagania biznesowe.

Bo, wracając do przykładów: jaki sens jest dywagować na temat skuteczności działania układu ABS w samochodzie, który nie jeździ i został tylko częściowo poskładany w całość? Jaki sens ma sprawdzanie czy skład graficzny pozwala na komfortowe czytanie powieści, jeśli książka nie została w ogóle zszyta i zamocowana w okładce? W końcu jaki sens ma sprawdzanie czy walidacja w formularzu wpisywania danych działa poprawnie, jeśli nie są dostępne inne funkcje niezbędne do tego, aby użytkownik w ogóle mógł dojść do wyświetlenia tegoż formularza?

Widać tu przy okazji, jak nielogiczny jest wpis, który często widzimy w Definition of Done różnych zespołów: „wszystkie wymagania realizowane w sprincie są spełnione”. Tego warunku nie sposób przecież spełnić. Czemu?

Aby móc zaspokoić takie Definition of Done, trzeba dokonać sprawdzenia, że rozwiązanie odpowiada na potrzeby biznesowe. By to zrobić, trzeba dysponować działającym produktem, który poddamy stosownym testom akceptacyjnym. Tyle, że produkt ten, aby uznać go za nadający się do testów, musi wcześniej spełnić warunki zapisane w Definition of Done… i koło się zamyka.

Dlatego rozdzielić należy Definition of Done i kryteria akceptacyjne, po czym spełnić to pierwsze, zanim w ogóle przejdziemy do sprawdzenia tego drugiego.

Cena za niezrozumienie konceptu

Wiele zespołów łudzi się, że osiągnie większą efektywność pracy, rozpoczynając równolegle realizację wielu (a czasem wszystkich) wymagań zaakceptowanych do sprintu. Maleje szansa na prawdziwie zespołowe działanie, ale w kontekście tego artykułu pojawia się coś jeszcze: presja na to, by sprawdzać per-wymaganie, czy biznesowe potrzeby zostały spełnione. Brak wtedy dbania o to, by powstał jeden zintegrowany, w pełni działający produkt, spełniający wymogi Definition of Done.

Skutkiem jest, kuriozalna w kontekście Scruma, sytuacja, w której zespół w czasie przeglądu sprintu informuje, że „Definition of Done jest spełnione dla ukończonych wymagań”, a dla reszty „Definition of Done nie udało się spełnić”. Cóż to, u licha znaczy? Czy aby na pewno istnieje jeden produkt nadający się do użycia? Czy da się taki produkt wydać? Warto dopytać…

Czemu Definition of Done jest takie ważne?

Scrum powstał jako odpowiedź na niezdolność tradycyjnych metod do radzenia sobie ze złożonością i nieprzewidywalnością, które nierozerwalnie towarzyszą wytwarzaniu oprogramowania i wielu innym przedsięwzięciom. Często, mimo wykonania całego planu, na końcu powstawał produkt mało przydatny albo nie powstawało w ogóle nic zdatnego do użycia. Scrum, jak wszystkie metody zwinne, odchodzi od oparcia decyzji na założeniach i tworzenia planów na początku, na rzecz podejścia empirycznego.

Dzięki budowaniu produktów iteracyjnie i przyrostowo, miarą postępu przestały być stwierdzenia w rodzaju „mamy zrealizowane już 74% wymagań”, a stał się nią działający produkt. Domniemania, że coś ma wartość i że będzie nadawało się do użycia, zastąpiła jasna informacja: takie funkcje i cechy produkt już posiada i można ich użyć, a takich w nim w ogóle nie ma.

Inaczej mówiąc Scrum spowodował, że zamiast zajmować się realizowaniem planów, zajmujemy się (w końcu!) budowaniem działających produktów.

I tu pojawia się podstawowa funkcja Definition of Done: zapewnia przejrzystość odnośnie tego co zostało ukończone, a jednocześnie czyni klarownym warunki jakie muszą być spełnione, by produkt do użytku się nadawał. Właśnie dzięki Definition of Done można odpowiedzieć na pytanie co w produkcie już jest, a czego tam nie ma. Odpowiada ono też na pytanie co jest produktem, a co jako produkt nie może być traktowane.

Na bazie takiej informacji da się podjąć decyzję, co robić dalej: dodawać nowe rzeczy, zmieniać te już istniejące, a może je usunąć, bo okazały się zbędne? Bez działającego produktu, w świecie opisywanym poprzez „% zrealizowanego planu” to niewykonalne, ponieważ do spekulacji odnośnie owych procentów dodajemy spekulacje odnośnie tego co warto robić dalej.

Definition of Done dotyczy produktu!

Wykrzyknik w tytule tej sekcji celowy. Załóżmy, że zespół nie wpadł w pułapkę utożsamiania Definition of Done z kryteriami akceptacyjnymi. Czy mamy gwarancję, że działamy empirycznie i mamy przejrzystość? Oczywiście nie.

Zdarza się bowiem, że Definition of Done jest przylepiane nie do produktu, ale do jednego z komponentów (elementów składowych produktu), które nigdy nie są używane w oderwaniu od większej całości. Cóż z tego, że taki komponent jest w pełni ukończony, skoro nijak nie gwarantuje to, że produkt działa? A musi działać, by dało się sprawdzić, na ile owo działanie odpowiada wymaganiom biznesowym…

Innym problemem, jaki spotykamy, to Definition of Done związane z zespołami. Wyobraźmy sobie, że jest kilka teamów rozwijających jeden produkt, ale każdy z tych teamów inaczej definiuje co to znaczy ukończona praca. W ostatecznym rozrachunku nie wiadomo, w jakim stanie jest produkt po kolejnych sprintach. Jedynym dopuszczalnym rozwiązaniem jest wspólne uzgodnienie jednego Definition of Done przez te zespoły.

Sytuacje skrajne

No dobrze, powie ktoś, a co jeśli Definition of Done, opisujące produkt nadający się do użycia, wymaga umiejętności i praktyk niedostępnych dla zespołu developerskiego? Czy mogą oni pracować w Scrumie, a jeśli tak, w jaki sposób? Temu tematowi poświęcimy jeden z kolejnych artykułów.