Definicja gotowości: 5 kryteriów wejściowych, które zapobiegają nieudanym sprintom

Większość zespołów ma definicję Ukończenia. Znacznie mniej osób ma definicję gotowości. Rezultat: historie rozpoczynają się w sprintach w bardzo różnych stanach gotowości, planowanie sprintu staje się selekcją, a niespodzianki w połowie sprintu pożerają cel.

Definicja Gotowości (DoR) jest starszym bratem Definicji Ukończenia. DoD mówi, kiedy praca może opuścić sprint. DoR mówi, kiedy praca może do niego wejść. To najtańszy element elastycznej infrastruktury, który większość zespołów pomija.

To jest praktyczna wersja. Co właściwie robi DoR. Pięć kryteriów wejścia, które wychwytują najwięcej niespodzianek, którym można zapobiec. Pułapka przeprojektowanego DoR. I jak to wprowadzić, nie zamieniając wyrafinowania w ceremonię otwarcia.

Do czego służy DoR

Definicja gotowości odpowiada na jedno pytanie: czy można bezpiecznie wykorzystać tę historię podczas planowania sprintu?

Kiedy historie rozpoczynają sprint w połowie, dzieją się trzy rzeczy:

1. Szacunki są błędne. Inżynierowie dostrzegają w trakcie sprintu ukrytą złożoność, której nie mogli dostrzec podczas planowania. Punkty dotyczyły innej historii.
2. Cele ulegają rozmyciu. Odkrycia w połowie sprintu odciągają wysiłek od pracy zorientowanej na cel. Rozciągnięcie staje się „zrobiłem część tego”.
3. Udoskonalanie następuje podczas sprintu. Inżynierowie ustalają kryteria akceptacji, szukają projektów, pingują interesariuszy w poszukiwaniu brakujących decyzji; praca, która powinna była się wydarzyć wcześniej zaangażowanie.

DoR to poprawka strukturalna. Historie, które nie spełniają tego warunku, nie wchodzą do sprintu. Okres.

Pięć kryteriów wejścia, które zaskakują najwięcej

Większość działań niepożądanych ogranicza się do 12-elementowej listy kontrolnej, której nikt tak naprawdę nie sprawdza. Oto uproszczona wersja, która uwzględnia istotne problemy:

1. Historia ma jasne „dlaczego”

Albo wartość dla użytkownika jest oczywista z tytułu, albo historia to wyjaśnia. „Dodaj warstwę buforowania” bez kontekstu nie przechodzi tego testu. „Zmniejsz opóźnienie API na desce rozdzielczej p95 z 800 ms do 200 ms”.

Test: czy osoba niebędąca autorem opowiadania potrafi w jednym zdaniu wyjaśnić, dlaczego jest to istotne?

2. Istnieją kryteria akceptacji i można je testować

Przynajmniej minimalny realny zestaw; trzy kule; i każdy z nich można uzgodnić jako spełniony lub niespełniony. (Patrz formaty kryteriów akceptacji dla pełnego przewodnika.)

Test: przeczytaj kryteria. Czy są to stwierdzenia, które każdy mógłby sprawdź, czy też są to aspiracje?

3. Historia jest na tyle krótka, że można ją oszacować

Jeśli zespół nie może dojść do porozumienia w sprawie punktów w ciągu kilku rund planowania pokera, historia nie jest jeszcze gotowa. Jest albo za duży (podziel go, patrz rozdzielacz historii) lub zbyt niejasne (więcej doprecyzowania lub konwersja na igłę).

Test: czy zespół może przedstawić wiarygodne oszacowanie, a nie „wzruszyć ramionami, może 8”?

4. Identyfikacja i odblokowanie zależności zewnętrznych

Jeśli praca zależy od projektu innego zespołu, klucza API, źródła danych lub decyzji interesariusza; należy je rozwiązać (lub wyraźnie zaakceptować jako ryzyko) przed podjęciem zobowiązań.

Test: wypisz zależności. Czy w przypadku każdego z nich odpowiedź brzmi „mamy to” czy „decydujemy się podjąć ryzyko”?

5. Ktoś jest jego właścicielem

Albo inżynier, albo wyraźna grupa inżynierów może poprowadzić tę historię od początku do końca. „Zaczniemy zastanawiać się, kto” nie przechodzi; to jest proces odkrywania, który przenika do sprintu.

Test: kto pierwszego dnia w stand-upie powiedziałby „Pracuję nad tym”?

To wszystko. Pięć testów. Większość historii, które je przechodzą, nie zaskakuje zespołu w połowie sprintu. Większość historii, które je zawodzą, to te, które wybuchają.

Co to jest DoR nie

DoR jest najbardziej przepracowanym i zwinnym artefaktem. Powszechne wzdęcia do odmowy:

• „Cały projekt techniczny musi być kompletny.” Nie. Projektowanie większości historii odbywa się w trakcie pracy. Jeśli historia wymaga wstępnego zaprojektowania, jest to impuls, a skok jest poprzednikiem.
• „Wszystkie makiety UX zostały zatwierdzone przez wszystkich interesariuszy.” Nie. UX wymaga wystarczającej definicji, aby rozpocząć, a nie pełnego podpisu. Wylogowanie blokuje wysyłkę; Umożliwia to „wystarczająco dużo, aby zacząć”.
• „Oszacowane przez cały zespół podczas planowania sesji pokerowej.” Nie. Niektóre zespoły tak robią; niektóre zespoły mają mniejsze szacunki dotyczące załogi, które należy udoskonalić, a następnie zatwierdzają je na etapie planowania. Nie piecz proces do swojego DoR.
• „Powiązane z eposem JIRA z mapowaniem rodzic-dziecko.” Nie. To preferencje dotyczące narzędzi. W DoR chodzi o to, czy historia jest gotowa, a nie o to, czy zadanie wypełnił 14 pól.
• „Ma całkowicie rozłożoną listę zadań”. Nie. Zespół powinien mieć możliwość odkrywania zadań w trakcie ich pracy. Nakazujący rozkład zachęca do fałszywego rozkładu (inżynierowie piszą zadania, które będą ignorować).

Wzór: DoR powinien przetestować wyniki (czy można to bezpiecznie zaangażować?), nie wyjścia (czy ten artefakt został wyprodukowany?). Każdy przedmiot wymagający artefaktu jest podatkiem. Każdy przedmiot, który zadaje prawdziwe pytanie, jest sygnałem.

Miejsce DoR w przepływie pracy

Przepływ:

1. Historia wchodzi do zaległości (luźna, niedokończona, to w porządku).
2. Wyrafinowanie przenosi go w stronę gotowości. Udoskonalenie to spotkanie, w którym spełnione są kryteria DoR.
3. Historia jest oznaczona jako Gotowa.
4. Planowanie sprintu wybrane z Gotowych historii. Historie, które nie są jeszcze gotowe, nie kwalifikują się.
5. Biegi sprinterskie. DoD dotyczy wyjazdu.

Zasada strukturalna: udoskonalenie czyni wszystko gotowym. Planowanie wybiera z gotowych rzeczy. Jeśli Twój zespół planuje od „rzeczy, które wyglądają interesująco”, DoR nie ma się do czego przyczepić.

(W parze z Element Runbook udoskonalania zaległości dla formatu spotkania.)

Jak wprowadzić DoR bez konieczności udoskonalania ceremonii otwarcia

Dwa tryby niepowodzenia, gdy zespoły przyjmują DoR:

Tryb awarii 1: DoR staje się czystym obciążeniem. Każda historia jest omawiana przez 20 minut. Premier czuje się urażony. Inżynierowie sprawdzają elementy mechanicznie, bez zastanowienia. Udoskonalanie staje się dłuższe; nic innego się nie poprawia.

Tryb awarii 2: DoR jest ignorowany. Zespół zgadza się na DoR. Historie wchodzą w sprinty, nie spełniając tego warunku. Nikt nie wymusza. DoR ma charakter dekoracyjny.

Poprawka dla obu: zespół może świadomie obejść DoR, ale obejście jest rejestrowane.

Konkretnie:

• Można zaangażować się w historię, która nie spełnia wymagań DoR jeśli zespół wyraźnie zaakceptuje ryzyko i zapisuje, czego brakuje.
• W przypadku retro zespół sprawdza nadpisania: czy brakujący element ugryzł? Jeśli tak, co DoR powinien złapać następnym razem? Jeżeli nie, czy kryterium było konieczne?

Dzięki temu DoR staje się bramą w instrument edukacyjny. Zespół staje się pragmatyczny; zespół nie może też udawać, że te same niespodzianki zdarzają się przez przypadek.

Kiedy DoR powinien być ciaśniejszy lub luźniejszy

Standardowy 5-elementowy DoR pasuje do większości zespołów. Odchylenia:

Bardziej rygorystyczne DoR (dodaj kryteria), gdy:

• Wskaźnik incydentów w zespole jest wysoki; niespodzianki mocno gryzą
• Rozproszone/asynchroniczne; mniejsze szanse na naprawę w połowie sprintu
• Dziedzina o dużym stopniu zgodności (opieka zdrowotna, finanse, regulacje): zmiany są kosztowne
• Wiele specjalizacji (backend + frontend + ML): koszt koordynacji jest realny

Dodaj takie elementy, jak: „załączony przegląd projektu”, „udokumentowana umowa API”, „obecny plan testów”.

Looser DoR (kryteria odrzucenia), gdy:

• Bardzo mały zespół, bardzo szybka iteracja; Narzut DoR przewyższa korzyści
• Wymagająca praca odkrywcza (produkt na wczesnym etapie, prace badawczo-rozwojowe): udawanie, że historie są gotowe, jest fikcją
• Zespoły o silnej własności indywidualnej; inżynierowie uzupełniają luki na bieżąco

Upuść takie rzeczy jak: jawny właściciel, pełne kryteria, sprawdzenie zależności. Zachowaj minimum: jasne „dlaczego” i przybliżone poczucie rozmiaru.

DoR dla różnych typów sprintów

Nie każdy sprint wymaga tego samego rodzaju pracy. Regulować:

Sprint rozwoju funkcji: pełny 5-elementowy DoR. Cały sens polega na zaangażowaniu się w prace fabularne o jasno określonym zakresie.

Sprint z naprawą błędów: luźniejszy. Wiele błędów ma charakter eksploracyjny. DoR w przypadku błędu = „reprodukuje konsekwentnie LUB ma wyraźny etap reprodukcji, który najpierw sprawdzimy”.

Sprint odkrywczy: dużo luźniej. Większość historii to kolce. DoR = „ograniczony czasowo i ma jasne pytanie, na które należy odpowiedzieć”.

Sprint za długiem technologicznym: bardziej rygorystyczne w zakresie wyników, mniej istotne w kwestii „dlaczego” użytkownika. DoR = „stan końcowy jest obserwowalny” + „zespół zgadza się, że warto to zrobić teraz”.

Nie stosuj tej samej listy kontrolnej do wszystkich typów sprintów. Chodzi o to, aby wyniki sprintu odpowiadały zaangażowaniu, a pytania chroniące różniły się w zależności od typu sprintu.

Co pójdzie nie tak bez DoR

Trzy wzorce, na które należy zwrócić uwagę, wszystkie objawy braku DoR:

„Odkryliśmy to dopiero, gdy zaczęliśmy”

Historia nie miała określonego „dlaczego” ani kryteriów akceptacji. W połowie sprintu zespół zdaje sobie sprawę, że praca jest większa lub inna. Do tego czasu cel sprintu spada.

Poprawka: kryterium 1 i 2 DoR.

„Czekaliśmy na zespół ds. marketingu/projektowania/prawa/innego zespołu”

Zależność nie została zidentyfikowana lub nie została rozwiązana przed zaangażowaniem. Teraz inżynier jest zablokowany, w sprincie zabrakło mu przydatnej pracy, punkty zostają przetasowane.

Poprawka: kryterium 4 DoR.

„To stało się epickie”

Historia zawsze była zbyt obszerna; zespół oszacował go na 5, uśredniając domysły. W połowie sprintu staje się oczywiste, że jest to 13+. Albo nie zostanie wysłany, albo porzucono inne prace, aby go wysłać.

Poprawka: kryterium 3 DoR (z podziałem historii, gdy jest zbyt duży).

Jeśli zobaczysz dwa z nich w jednym retro, Twojemu zespołowi brakuje DoR. Poprawka ma charakter strukturalny, a nie motywacyjny.

DoR dla zespołów rozproszonych/asynchronicznych

DoR ma większe znaczenie, gdy zespół jest asynchroniczny. Powody:

• Mniej szans na wyjaśnienie w połowie sprintu bez spalenia dnia w oczekiwaniu na nałożenie się stref czasowych
• Ukrytego kontekstu nie można naprawić, stukając kogoś w ramię
• „Zaraz się zastanowimy” zamienia się w „straciliśmy dwa dni, bo nie mogliśmy się zsynchronizować”

W przypadku zespołów asynchronicznych/rozproszonych dodaj co najmniej: „historia ma zapisany cały kontekst; do jej zrozumienia nie jest wymagana żadna tradycja ustna”. Wpada to w pułapkę, w której osoba żądająca ma kontekst w głowie, ale nigdy go nie zapisuje.

Konkluzja

Definicja Ukończenia mówi, kiedy praca może opuścić sprint. Definicja gotowości mówi, kiedy można przystąpić do pracy. Większość zespołów ma pierwszą; większość zespołów potrzebuje drugiego.

Pięć kryteriów; jasne dlaczego, testowalne kryteria akceptacji, szacunkowa wielkość, zidentyfikowane zależności, możliwość przypisania właściciela; łap niespodzianki, które niszczą większość sprintów. Nie zawyżaj listy. Nie udawaj, że to trudna brama. Używaj zamienników świadomie i przeglądaj je w stylu retro.

Zespoły, które poważnie traktują DoR, zwykle stwierdzają, że w ciągu dwóch cykli ograniczyły chaos sprintu o jedną trzecią, a kosztem było nieco zaostrzone spotkanie w sprawie udoskonalenia.

Na tym polega handel. Weź to.