W przypadku zwinnego zespołu istnieje kilka różnych ustaleń, które warto zrobić. Bardzo ważnym jest Definition of Done, jednak oprócz tego często spisuje się także ogólne zasady zespołowe oraz Definition of Ready. W przypadku tego ostatniego istnieje jednak duże ryzyko problemów.
Czym jest Definition of Ready
Definition of Ready, czyli Definicja Gotowości, określa warunki, jakie musi spełnić element backlogu produktu produktu (PBI, ang. product backlog item, czyli User Story, bug lub cokolwiek innego), aby zespół mógł nad nim pracować w kolejnej iteracji. Dzięki temu zespół ma uniknąć potencjalnych problemów. Bardzo często dla Definition of Ready stosuje się skróconą nazwę, czyli DoR.
Należy pamiętać, że w przeciwieństwie do Definicji Ukończenia (ang. Definition of Done, czyli DoD), Definicja Gotowości nie jest zdefiniowana w Scrum Guide. Stanowi jednak często stosowana praktykę i obok DoD jest jedną z podstawowych zasad funkcjonowania zespołu.
Kto tworzy Definition of Ready
W procesie tworzenia powinny brać udział wszystkie osoby zaangażowane w wytwarzanie produktu. W przypadku Scruma jest to więc cały zespół scrumowy, czyli zarówno Deweloperzy, Product Owner jak i Scrum Master. Podobnie jak Definition of Done, Definicja Gotowości powinna być co jakiś czas sprawdzana i uaktualniana.
Co może się znaleźć w Definicji Gotowości
To oczywiście zależy od zespołu, jednak wiele z Definition of Ready jakie widziałem zawiera pewne charakterystyczne elementy. Przykładowo mogą to być:
- PBI spełnia kryteria INVEST
- Zespół rozumie, na czym polega dany PBI
- Kryteria akceptacji zostały zdefiniowane
- PBI jest wyestymowany i nie większy niż X
- Zewnętrze zależności zostały rozwiązane
Do czego przyda się Definition of Ready
Dzięki Definicji Gotowości zespół może zwiększyć jakość i sprawność dostarczania kolejnych PBI. Przygotuje je wcześniej, zgodnie z własnymi wymaganiami, więc nie będzie tracić czasu podczas iteracji na niepotrzebne sprawy.
Definition of Ready może być swego rodzaju przypominajką lub listą kontrolną sprawdzającą, czy zespół o niczym nie zapomniał przed rozpoczęciem pracy.
Może także pomagać w rozwiązywaniu napotkanych wcześniej problemów. jak na przykład przytoczony wcześniej punkt o maksymalnej wielkości danego PBI. Jest to więc sygnał, że należy podzielić dany element backlogu na mniejsze części.
Narzędzie to na pierwszy rzut oka wydaje się więc bardzo pomocne. Niestety, zdarza się, że stwarza ono ryzyko wielu problemów, o których trzeba pamiętać, aby nie stało się antywzorcem.
Kiedy sprawdzać zgodność z Definition of Ready
Jeśli w twoim zespole stworzyliście Definicję Gotowości, to kiedy najczęściej na nią patrzycie? Czy w przypadku Scruma jest to Sprint Planning? Może to być pierwszy problem związany z DoR.
W przypadku, gdy zespół dopiero na Planowaniu Sprintu zastanawia się, czy dany PBI jest gotowy do iteracji, realizacja może się opóźnić. Zespół przeglądając poszczególne elementy backlogu produktu odrzuca je z powodu braków, zwiększając tylko frustrację Product Ownera.
Jeśli chcesz korzystać z DoR, najlepszym momentem na sprawdzanie zwartych w niej warunków jest Backlog Refinement. W tym czasie można dany PBI doprecyzować, uwspólnić wiedzę, wyestymować. Gdy spełnia warunki, może dostać pieczątkę “DoR spełnione” i na jednym z kolejnych Planowań Sprintu trafić do iteracji.
Jest to mała zmiana, ale powoduje większe zaangażowanie zespołu i polepszenie jakości backlogu produktu.
DoR jako broń na Product Ownera
To właśnie jeden z często występujących antywzorców w przypadku Definition of Ready. Deweloperzy zaczynają używać DoR jako długiej listy kontrolnej, dzięki której mogą odrzucać podczas Planowania Sprintu nie do końca przygotowane elementy backlogu produktu. Biorąc pod uwagę podobieństwo skrótu DoR do angielskiego słowa “door”, zaczynają stosować politykę zamkniętych drzwi.
W tym przypadku powinieneś sobie zadać pytanie, czy w zespole działa odpowiednio proces refinementu. A może jest to problem w komunikacji z Właścicielem Produktu, jego zaangażowaniem lub po prostu brakiem doświadczenia? Czy Product Owner brał udział w tworzeniu Definition of Ready, czy są to wymagania Deweloperów, których nie może spełnić lub nawet ich nie zna?
Pamiętaj, że problemów z komunikacją pomiędzy Deweloperami a Product Ownerem nie rozwiąże udostępniona lista wymagań dla PBI. Tu bardziej pomoże szczera rozmowa, na przykład podczas Retrospektywy Sprintu, a nie tworzenie nowych dokumentów. Te mogą się przydać jako podsumowanie wspólnych ustaleń.
Definicja Gotowości jako broń na stakeholderów
Bardzo podobna metoda jak w przypadku Product Ownera, ale tym razem odnosząca się do interesariuszy, czyli osób wpływających na zakres prac zespołu.
Zdarza się czasem, że stakeholder dodaje nowy element do backlogu produktu i chce o tym porozmawiać z Właścicielem Produktu lub prosi o spotkanie z Deweloperami w celu doprecyzowania jakiś szczegółów. W odpowiedzi otrzymuje natomiast link do długiej listy wymagań, jakie muszą być spełnione, aby zespół w ogóle popatrzył na to User Story.
Rozpoczyna się odbijanie piłeczki, związane z niespełnieniem kolejnych paragrafów z listy. To prowadzi do narastającej frustracji po obu stronach.
Oczywiście, dany PBI powinien spełniać jakieś podstawowe założenia. Z drugiej strony jest to wstęp do dyskusji, która powinna mieć miejsce podczas refinementu. Jeśli będzie to pomocne, można na niego zaprosić danego stakeholdera.
Nie musimy eksperymentować ani rozmawiać o wymaganiach
Jednym z założeń podejścia zwinnego jest praca w krótkich iteracjach, eksperymentowanie i sprawdzenie, czy dany kierunek jest dobry. Poprzez zbyt rozbudowane Definition of Ready zespół może jednak wpaść w pułapkę waterfalla, czyli zbyt dużo uwagi poświęcać na wcześniejsze doprecyzowanie i pracowanie w odizolowanych fazach.
Jeśli zespół wymaga wszelkich szczegółów związanych z elementem backlogu produktu zanim zacznie nad nim pracować (mockupy, specyfikacja, wcześniejsze dokładne zbadanie problemu) to gdzie pozostaje miejsce na ewentualne zmiany w trakcie iteracji?
Zespół może przez to uzyskać błędne poczucie bezpieczeństwa. Nie będzie widział potrzeby rozmowy z Product Ownerem lub innymi osobami aby dokonać ewentualnej korekty w podejściu. Przecież dany PBI spełniał wszystkie założenia, nic nie powinno już nas zaskoczyć. Problem ten jest podobny do opisywanej przeze mnie w innym artykule sytuacji, gdy zespół definiuje zbyt szczegółowe kryteria akceptacji.
Powinieneś zachować balans pomiędzy perfekcyjnym doprecyzowaniem danego User Story zgodnie z Definition of Ready, a pozostawieniem sobie miejsca na założenia, które potwierdzisz lub obalisz w podczas iteracji. Tym bardziej, że znając prawa Murphiego, w jej trakcie natrafiasz na coś, o czym zespół nie pomyślał wcześniej.
Sposób na zależności zewnętrzne
To podobne do poprzedniego punktu ryzyko skutkuje zbyt mocnym ograniczeniem zależności. Skoro w Definition of Ready zespół wpisał, że dany PBI musi spełniać kryterium INVEST, to nie zacznie pracować nad żadnym elementem backlogu produktu, który wymaga pracy kogoś innego (pierwsza litera akronimu oznacza niezależność, od angielskiego Independent).
Warto jednak zawsze się zastanowić, czy ta zależność blokuje zespół, czy jest dodatkiem do wspólnie realizowanego zadania. Nie zawsze jest to coś, co nie pozwala na rozpoczęcie pracy lub uniemożliwia jej zakończenie w danej iteracji.
W przeciwnym wypadku wpadamy ponownie w pułapkę waterfalla, a nasz zwinny projekt można rozrysować na pięknym wykresie Gantta. Prace się przedłużają, nie ma potrzeby komunikacji, bo zespół stwierdza “gdy oni skończą swoje story, to my zaczniemy nasze”.
Praca nad zadaniami, które w pewnym stopniu się zazębiają, może przynosić bardzo dobre efekty. Wspólna dyskusja, doprecyzowanie szczegółów i wczesne próby integracji znacznie lepiej odkrywają potencjalne problemy.
Czy warto więc używać Definition of Ready?
W tym poście przytoczyłem wiele możliwych problemów z DoR, a tylko kilka zalet na jego początku. Czy to oznacza, że Definicja Gotowości to antywzorzec, który należy usunąć? Według mnie nie jest aż tak źle.
Rozsądne stosowanie Definition of Ready może być przydatne dla zespołu podczas refinementu backlogu produktu i ostateczne potwierdzenie na planowaniu sprintu. Nie powinno stanowić jednak szczegółowej, długiej listy wymagań dla Product Ownera, stakeholderów lub być obroną przed eksperymentowaniem oraz sztucznym unikaniem zależności.
DoR powinna bardziej stanowić zestaw wspólnych wytycznych, niż twardą listę kontrolną, z której każdy punkt musi być spełniony. Jak to bywa zarówno w pracy i życiu prywatnym, wszystko trzeba stosować z rozwagą i umiarem.
Be First to Comment