Czy zdarzają się w Twoich zespołach dialogi podobne do tego z obrazka? Kiedy zdezorientowany product owner pyta:
– Hej, ludzie, czy ta historyjka – tutaj wskazuje konkretną karteczkę na tablicy albo w Jirze – jest już zakończona?
Z ust kolejnych osób z zespołu słyszy:
– Nie wiem, nie mam pojęcia o co tam chodziło i co trzeba było zrobić.
– Tak, skończyliśmy kodowanko.
– No… tego… jeszcze testuję, ale już mam prawie „done”.
– Skończona, skończona, tylko trzeba pamiętać, żeby kiedyś dokumentację dorobić.
– A ja to bym jeszcze dołożył tam walidację na tych polach w formularzu.
– Tak, doróbmy tę walidację. Pewnie nie zdążymy w sprincie, ale doróbmy. I jeszcze opcja wydruku by się przydała!
I bądź tu człowieku na miejscu tego biednego ownera. Czy dostał odpowiedź na swoje proste pytanie? Jak na mój gust – średnio.
Ta krótka scenka sugeruje, że zespół nie dorobił się jeszcze swojej definicji ukończenia – DOD, kryteriów akceptacji – AC, ani definicji gotowości – DOR.
Dlaczego w tekście zaroiło się od kolorów? Bo oznaczyłem nimi wypowiedzi wskazujące na brak konkretnego artefaktu:
zielonym – definicji gotowości (ang. Definition of Ready) – DOR,
czerwonym – definicji ukończenia (ang. Definition of Done) – DOD,
niebieskim – kryteriów akceptacji (ang. Acceptance Criteria) – AC.
Zetknąłem się kilka razy w swoim życiu z podobnymi sytuacjami, a mimo to zespół zgodnie twierdził, że przecież oni mają te wszystkie DORy, DODy i inne takie. Mają je nawet na kartkach na ścianie powyklejane przez scrum mastera, a niekiedy to i do Confluence’a czy innego Sharepointa wprowadzone. A co?
No i tutaj trochę kultem cargo zawsze mi zalatywało. Samo „mieć / posiadać” bez „rozumieć / stosować / rozwijać” jest bezcelowe.
Jeśli chcesz wprowadzić artefakty, o których mowa w moim wpisie, zadbaj o to, aby zespół rozumiał „po co”. Wprowadzanie na siłę – bo trzeba – nie ma kompletnie sensu, gdyż prawdopodobnie wyrobisz w ludziach tak silny odruch obronny, że dostaną na nie dożywotniej alergii. Postaraj się wykorzystać każdą okazję, aby najpierw zrozumieli, o co w tym wszystkim chodzi. Zadbaj o „żyzny grunt”, a jak już będzie – wtedy zasiej ziarenko i podlewaj, podlewaj, podlewaj. Jest szansa, że coś wykiełkuje. Przykładowo doskonałą okazją „do zaczepienia się” jest przytoczony na początku wpisu dialog.
Definition of Ready / DOR / definicja gotowości
Jest to definicja gotowości podjęcia danej historyjki do sprintu. Jeśli decydujemy się stosować DOR to do sprintu nie możemy wziąć historyjek, które go nie spełniają. W procesie pielęgnacji backloga musimy „dopieszczać” elementy z jego góry tak, aby były gotowe do podjęcia w najbliższej przyszłości.
Przykładowe DOR:
– historyjka jest oszacowana,
– zespół zna wartość biznesową historyjki,
– do historyjki dołączona jest makieta ekranu,
– zespół ma pomysł, jak przetestować historyjkę.
Używanie tego artefaktu pozwoli uniknąć sytuacji, gdy do sprintu wpadają zadania nierozpoznane. Minimalizuje ryzyko „uwalenia sprintu”. Może wymuszać na product ownerze odrobinę wysiłku, aby uzasadnić zespołowi, po co każda historyjka musi być zrobiona, jaka jest jej wartość dla klienta. Stosowanie DOR sprzyja dobrym sesjom porządkowania backloga (refinement). Pozytywnym efektem ubocznym jest wzrost przewidywalności zespołu – gdyż na warsztat brane jest to, o czym wcześniej rozmawiano i „kminiono”.
Definition of Done / DOD / definicja ukończenia
Jako jedyna z tytułowej trójki znalazła się w Scrum Guide, gdzie bardzo precyzyjnie określono, po co ją stosujemy. Po szczegóły odsyłam tutaj: https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Polish.pdf, na stronę 16.
Po tym, co napisali Schwaber i Sutherland, trudno cokolwiek dodać. Chłopaki „w punkt” opisują DOD, dzięki któremu zapewniamy w organizacji JAKOŚĆ wytwarzanego oprogramowania. DOD jako jedyny z naszej trójki artefaktów może, a nawet powinien być OBOWIĄZKOWY. Najczęściej duże organizacje konstruują bardzo ogólną definicję, która następnie jest precyzowana w zespołach. Ważne: precyzowana, lecz nie zmieniana. W DOD każdego zespołu MUSI się zawierać DOD całej organizacji.
Przykład DOD na poziomie organizacji:
Element backloga uznajemy za zakończony, gdy:
– jest dostarczony na środowisko integracyjne,
– jest przetestowany,
– jest udokumentowany.
Przykład rozszerzenia DOD na poziomie zespołu w tej organizacji:
Historyjkę uznajemy za zakończoną, gdy:
– jest dostarczona na środowisko INT_MORDOR (nazwa z czapy, ale mi się podoba),
– przechodzą testy integracyjne,
– pokryta jest testami automatycznymi, które przechodzą,
– scenariusze testów manualnych zostały wykonane,
– nie ma do niej otwartych błędów o priorytecie BLOCKER i HIGH,
– błędy o niższym priorytecie są zaadresowane w innych historyjkach w backlogu,
– dług technologiczny w Sonarze nie może zostać powiększony,
– dokumentacja znajduje się w przestrzeni zespołowej na Confluence.
– spełnione są kryteria akceptacji.
Kilkukrotnie spotkałem się z sytuacją, w której zespół nie do końca czuł różnicę między DOD a kryteriami akceptacji. Czasami nawet początkujący scrum masterzy nieco się w tym gubili.
O kryteriach za chwilę, natomiast w przypadku DOD warto pamiętać, że są one wspólne dla całej organizacji i bez wyjątku, każda historyjka musi spełniać to samo wspólne DOD. Nie ma czegoś takiego, jak swobodne definiowanie DOD dla każdej historyjki osobno.
Po to jest jedna, spójna definicja (doprecyzowana w zespole), aby zapewnić jednakową wysoką jakość i standardy wytwarzanego oprogramowania.
Upraszczając, warto zapamiętać, że definicja ukończenia jest po to, aby zapewnić przestrzeganie standardów oraz wysoką jakość tworzonych produktów.
Acceptance Criteria / AC / kryteria akceptacji
Ich stosowanie precyzuje co ma być zrobione, aby historyjkę uznać za zakończoną. Mogą, a nawet muszą być inne dla każdej historyjki. Punktują wymagania funkcjonalne i niefunkcjonalne.
Popracujmy na przykładzie konkretnej historyjki:
„Jako sprzedawca chcę wprowadzić dane nowego klienta do systemu, aby po zakończeniu sprzedaży wystawić mu fakturę.”
Trafia ona do sprintu, a w efekcie w ręce żądnego krwi dewelopera, który przez cały sprint rzeźbi, aby na koniec pokazać piękne okno, w którym możemy wprowadzić imię, nazwisko, pesel, NIP, imię ojca, matki i syna, rozmiar buta, a nawet dołączyć zdjęcie i odcisk palca. Okno jest koloru czarnego, bo taki podoba się twórcy. Trochę mu zeszło z wizualnym dopieszczaniem czerni i układu komponentów, więc sam zapis danych w systemie został potraktowany „po macoszemu”. Trwa 3 minuty, często się wywala a błędy nie są obsłużone.
W konfrontacji z klientem okazuje się, że oczekiwał on okna niebieskiego, dzięki któremu wpisze imię, nazwisko i NIP, który będzie walidowany a operacja zapisu potrwa nie dłużej niż 2 sekundy.
Miało być tak pięknie a wyszło? Średnio…
I tu właśnie w sukurs przychodzą nam kryteria akceptacji.
Gdybyśmy wobec powszechnego oporu zespołu, że to strata czasu, że biurokracja, że przecież „i tak wiadomo” dopięli swego i doprecyzowali je w tej historyjce, np. tak:
„Jako sprzedawca chcę wprowadzić dane nowego klienta do systemu, aby po zakończeniu sprzedaży wystawić mu fakturę.”
Kryteria akceptacji:
– mogę wprowadzić imię, nazwisko, oraz NIP klienta,
– pola tekstowe „imię” oraz „nazwisko” podświetlone są niebieskim kolorem,
– walidator na polu „NIP” nie pozwala wprowadzić nieprawidłowego numeru,
– zapis danych trwa krócej niż 2 sekundy,
– w przypadku niepowodzenia zapisu wyświetlany jest komunikat o błędzie,
– po zapisaniu danych system wraca do ekranu startowego.
to istnieje duża szansa, że nasz klient otrzymałby to, czego oczekiwał, a żądny krwi deweloper, wiedziałby, co ma robić. Kasa by się zgadzała.
Dzięki stosowaniu AC unikamy niedopowiedzeń. Precyzujemy komunikację między PO, zespołem i klientem. Ułatwiamy product ownerowi odbiór zadań w trakcie sprintu. Unikamy sytuacji, w których historyjki „puchną”, bo np. w ostatnim dniu sprintu ownera „olśniło” i zażądał, aby w ramach jednej historyjki przemycać jakieś inne. Jeśli umówimy się z klientem, że produkt ma być koloru niebieskiego i zapiszemy to w kryteriach akceptacji, to podczas odbioru mamy „jasną” sytuację, dlaczego jest niebieski, a nie zielony. Jeśli dzisiaj preferuje ten kolor, to stwórzmy na to nową historyjkę w backlogu.
Kryteria akceptacji pozwalają skupić się podczas pracy na tym, co istotne. Zmniejszają ryzyko, że jakiś szalony deweloper zaimplementuje funkcjonalność za którą nikt nie zapłaci.
Podsumowując moje wywody o DORach, DODach i ACkach mam dla Ciebie „piękny” rysuneczek (mojego autorstwa), który obrazuje, gdzie w procesie scrumowym znajdują się opisywane dzisiaj artefakty.
DOR – uchroni zespół przed braniem do sprintu nieznanego,
AC – pozwoli precyzyjnie wykonać to, na co się wcześniej umówiono,
DOD – sprawi, że dostarczane produkty będą spełniały standardy na których wszystkim zależy.