Niespełna 2 lata temu, na potrzeby firmy, w której wówczas byłam zatrudniona, pracowałam nad stworzeniem “kryterium gotowości” (ang. Definition of Ready, w skrócie DoR) oraz kryterium ukończenia (ang. Definition of Done, w skrócie DoD) zadań.
Celem tego przedsięwzięcia było określenie, kiedy zadanie programistyczne można uznać za gotowe do przyjęcia do realizacji (DoR) oraz za wykonane (DoD). Z uwagi na to, że pracowaliśmy w waterfall’u, próbując adaptować pewne, wygodne dla nas elementy Agile’a, zadanie to nie miało szans powodzenia. Dlaczego?
Kryteria Definition of Ready oraz Definition of Done pochodzą z metodyk zwinnych i są jednym z podstawowych założeń Agile’a. Próba dostosowania tych pojęć do waterfall’a osłabia ich użyteczność głównie z uwagi na to, że zadania realizowane w Scrumie są planowane tak, aby były testowalne i wdrażalne, w waterfallu tak się nie dzieje (często pojedyncze zadanie nie niesie ze sobą konkretnej funkcji do przetestowania czy weryfikacji klienta).
Niemniej jednak powołałam wówczas zespół roboczy składający się z deweloperów, team leadera i project managera, aby wspólnie, w ramach burzy mózgów opracować rozwiązanie.
Sam charakter współpracy pokazał nam bardzo wiele o nas samych; ukazał nasze rozumienie “ready” i “done”, naszą agile’ową mentalność, a raczej jej brak, pokazał też miejsce, w którym projektowo jesteśmy – waterfall coraz mniej nam wychodził, a do podjęcia decyzji o wdrożeniu Scruma była długa droga.
Jak zawsze praca w zespole, wymiana doświadczeń, obserwacja różnic są bardzo owocne, stąd po kilku spotkaniach udało nam się stworzyć coś na kształt tego, co mieliśmy wdrożyć do ówczesnych projektów jako uniwersalne zastosowanie. Kolejny błąd, ponieważ ani Definition of Ready, ani Definition of Done nie są czymś na poziomie organizacji, a raczej na poziomie zespołu i projektu, i są czymś unikalnym bardziej niż uniwersalnym, ale to takie “lesson learned” już po fakcie.
Dobra praktyka
Abstrahując od metodyk i terminów, gotowość do podjęcia zadania jest kluczowa do tego, aby móc wziąć za nie odpowiedzialność. Nie można egzekwować zasad, kiedy nie są znane, podobnie jak ciężko egzekwować należytą realizację zadania, kiedy założenia są mgliste.
Kiedy myślimy o tym, czy jesteśmy gotowi, aby przyjąć zadanie do wykonania, musimy wiedzieć czy znamy oczekiwany wynik końcowy, czy znane są nam kryteria akceptacji, czy posiadamy wszystkie niezbędne do realizacji zadania zasoby.
Ostatnio podczas jednego ze szkoleń “The Agile Experience” jako kilkuosobowa grupa mieliśmy wykonać w ramach Sprintu 10 kapeluszy z papieru. Każdy chwycił arkusze A4 i zaczął je składać, tworząc kapelusz. Po wykonaniu zadania nasz Product Owner (trener) odrzucił produkt końcowy. Okazało się, że wszystkie kapelusze miały być identyczne i miały mieć zagięte rogi, a także kolorowy kwiatek narysowany na środku z jednej strony. Nie mieliśmy pisaków. Nie mieliśmy pojęcia o pozaginanych rogach. Każdy zrobił kapelusz według swojego uznania. Nie byliśmy “ready”, zadanie nie było “ready”, mimo to podjęliśmy się wykonania go. W tym ćwiczeniu zmarnowaliśmy tylko kilka kartek, w realnym projekcie zmarnowalibyśmy budżet, nie dostarczając oczekiwanej wartości biznesowej.
Are you ready or are you done?
DoR – Definition of Ready – określa jakie cechy ma posiadać zadanie, aby mogło być przyjęte do realizacji, “odsiewa” zadania źle lub niejasno zdefiniowane, jest stałe, zależy od zespołu.
DoD – Defintion od Done – określa kiedy realizowane zadanie można uznać za wykonane, “odsiewa” nieukończone zadania, zmienia się w czasie, zależy od uwarunkowań projektu.
O ile DoR mówi o tym, kiedy zadanie może wejść do Sprintu, DoD mówi o tym, kiedy zadanie może wyjść poza Sprint.
Dzisiaj chciałabym się skupić na kryterium gotowości, jako, że Definition of Ready jest pierwszym i ostatnim kryterium wejściowym zadania do realizacji.
Definicja podkreśla, że jest to kryterium odnoszące się do zadania – pytamy czy zadanie jest gotowe do przyjęcia do realizacji, a ja nieco przewrotnie pytam czy Ty jesteś gotowy, aby się go podjąć. Równie ważna bowiem jak gotowość zadania, jest gotowość wykonawcy.
Na jakie pytania musisz znać odpowiedź, aby uznać, że jesteś „ready”?
- Why?– jaki cel firma chce osiągnąć? Dlaczego decyduje się na realizację zadania?
- What? – co ma być końcowym rezultatem zadania? Jaka jest wartość biznesowa dla klienta? Jakie są kryteria akceptacji?
- How? – jak zadanie zrealizować? Czy zadanie jest wykonalne? Jaki jest sposób implementacji? Czy zadanie konsoliduje się z całym systemem? Czy zadanie posiada jakieś zależności? Jakie są potrzebne do wykonania zadania zasoby?
„Gotowy” znaczy GOTOWY!
Oczywiście powyższe pytania są mocno umowne i powinny zostać opracowane przez zespół na jego poziomie – to zespół decyduje o tym, kiedy uznaje zadania za “gotowe”. Jednak nawet, jeśli zadanie spełnia te kryteria, nie znaczy to, że Ty jesteś na nie gotowy. Musisz wziąć pod uwagę nie tylko wiedzę o zadaniu, ale także:
- swoje doświadczenie i możliwości (umiejętności),
- chęci i motywację,
- warunki zewnętrzne potrzebne do wykonania zadania.
Kiedy uznasz, że jesteś gotowy, przejmujesz odpowiedzialność. Dajesz jasny sygnał, że znasz i rozumiesz zakres końcowy, nie wydaje Ci się, ale wiesz jak mają wyglądać kapelusze.
Koszt naprawy błędów rośnie wykładniczo w miarę upływu czasu. Pisałam o tym we wpisie “Błędy oprogramowania – znajdź je zanim zaczną Cię kosztować”. Im później zorientujesz się, że nie o to w zadaniu chodziło, tym więcej projekt zapłaci za zmianę.
O błędzie mówimy nie tylko wtedy, kiedy coś nie działa, ale również wtedy kiedy nie działa zgodnie z oczekiwaniami. W waterfall’u odpowiedzialnością można obarczyć analityka, projektanta, a nawet PM’a, tam kryterium gotowości również jest kaskadowe – powinno nastąpić na każdym poziomie, jednocześnie narażone jest na utratę danych, na głuchy telefon, na błędne rozumienie poszczególnych ogniw całego łańcucha. Jeśli pracujesz w Scrumie, odpowiadasz za swoje własne „ready”. Odpowiedzialność jest tu kluczowa. Pytanie czy jesteś na nią gotowy?
Trochę bym się kłócił o “Jak” na drugim miejscu ponieważ
właśnie ono pozwala podjąć decyzje o kosztach.
Wtedy jest łatwiej wiedzieć co zostanie wykonane aby spełnić oczekiwanie klienta. Np. dostając wymagania od klienta , który chce aby wprowadzić możliwość rejestracji dodatkowego zbioru danych w istniejącej aplikacji oraz (w skrócie )tak żeby nie musiał za wiele zapłać będziemy szukali rozwiązania w parametryzacji oraz zrobienia drobnej modyfikacji.
A poza tym pozdrawiam.
Wygląda na to, że rozbiliśmy się o założenia :) Ja przyjęłam pracę w time & material. Przyjęłam, że, aby powiedzieć “jak”, musimy najpierw wiedzieć “co”. Dopiero po odpowiedzi na 2 powyższe, możemy wycenić zadanie kosztowo. Jak rozumiem, Ty przyjąłęś fixed price. Wówczas rzeczywiście najpierw musimy ocenić “jak” – musimy dostosować rozwiązanie do możliwości. Super, że zwróciłeś uwagę na aspekt kosztowy, który ja w artykule pominęłam :) Dziękuję i również pozdrawiam :)
Tak. Tylko nie wiem jak zakwalifikować projekty typu usprawnienia lub rozszerzenia istniejących funkcjonalności. Cena nie jest do końca ustalona.
Podczas szacowania uwzględniamy dane historyczne z poprzednich projektów. Fakt – występują samoograniczenia ale raczej na zasadzie dobrej współpracy z klientem. Klient raczej się nie obrazi ale nie zdecyduję się na realizację gdy cena nie będzie mu odpowiadać.
Pozdrawiam
Przeczytałem artykuł i wydaje mi się ,że kolejność zadawanych pytań powinna być troszkę inna.
1. Dlaczego , po co, zadanie ma zostać wykonane, jaka istnieje potrzeba ?
2. Jak wykonać zadanie ?
3. Co ma zostać wykonane ?
Kiedy zaczynamy od pytania “co” wtedy istnieje duże ryzyko, że zakres zadania może nie pokryć całkowicie potrzeby biznesowej.
Gdyby tak się stało wtedy będziemy musieli liczyć się z koniecznością wydłużenia czasu realizacji i tracimy na efektywności.
Jak najbardziej zgadzam się z tym, że należy zacząć od “Dlaczego”. W swoim wpisie rzeczywiście nie skupiłam się na kolejności, jednak “Jak” nadal zostawiłabym jako ostatnie – możliwe do określenia dopiero wówczas, gdy odpowiedź na powyższe pytania, w tym również “co” jest znana. Pozwoliłam sobie już nawet wprowadzić aktualizację do wpisu :) Cieszę się, że zwróciłeś na to uwagę! Dzięki!