Kryteria akceptacji: 5 formatów i strukturalne pułapki, które je psują

Jeśli historie użytkowników są najczęściej pomijanym artefaktem zwinności, kryteria akceptacji są najczęściej pomijane część historii użytkowników. Większość zespołów pisze tytuł i opis, a następnie wysyła produkt bez wyraźnych kryteriów określających, co oznacza „ukończone”. Potem są zaskoczeni, gdy kontrola jakości odmawia lub gdy interesariusz demonstruje coś, czego inżynier nie uważał za potrzebne.

To jest praktyczny przewodnik. Pięć formatów kryteriów akceptacji, jeśli każdy z nich pasuje, oraz przyczyny strukturalne, dla których większość zespołów nie spełnia kryteriów.

Jakie znaczenie mają kryteria akceptacji

Historia użytkownika mówi co i dlaczego. Kryteria akceptacji mówią skąd wiemy, że to już zrobione.

Bez nich „gotowe” będzie negocjowane post hoc; zwykle po pracy, często po sprincie. Z nimi negocjacje toczą się wcześniej ktoś pisze kod.

Sygnał, że Twój zespół nie spełnia kryteriów akceptacji:

• zadania są odrzucane podczas przeglądu ze względu na brakujący zakres, o którym nikt nie wspomniał.
• „Ale nie zdawałem sobie sprawy, że tego potrzebujemy” – mówi retrospekcja.
• Kontrola jakości znajduje „błędy”, które w rzeczywistości są lukami w zakresie.
• Zainteresowane strony pytają: „Czy to już zostało zrobione?” a inżynier nie może odpowiedzieć czysto.

Trzy z tych czterech to problemy związane z przejrzystością zakresu, a nie problemy inżynieryjne.

Format 1: Lista punktowana

Punktory w prostym języku. Najpopularniejszy format, najłatwiejszy do napisania i najłatwiejszy do odczytania.

Historia: Użytkownik może zresetować hasło poprzez e-mail

Kryteria akceptacji:

• Użytkownik wprowadza adres e-mail na stronie resetowania
• System wysyła e-mail resetujący, jeśli adres e-mail pasuje do konta
• System wyświetla tę samą wiadomość („sprawdź pocztę”), niezależnie od tego, czy adres e-mail pasuje, czy nie (bez wyliczenia)
• Link resetujący wygasa po 24 godzinach
• Link resetujący działa dokładnie raz

Użyj go, gdy: kryteria są niezależne, a historia jest krótka. Większość historii tu pasuje.

Pomiń, gdy: zachowanie zależy od kontekstu (wejście X daje wynik Y) lub kryteria oddziałują na siebie.

Pułapka: autorzy wpadają w język specyfikacji „system powinien…”. Nie. Kryteriami akceptacji są wstępna rozmowa, a nie dokument umowy.

Format 2: Dany / Kiedy / Wtedy (Ogórek)

Zapożyczone z frameworków BDD (Cucumber itp.). Wymusza jasne myślenie scenariuszowe.

Scenariusz: adres e-mail pasuje do istniejącego konta
Biorąc pod uwagę, że istnieje użytkownik o adresie e-mail „uż[email protected]”.
Gdy użytkownik zażąda zresetowania hasła dla „uż[email protected]”
Następnie na ten adres zostanie wysłana wiadomość e-mail z resetem
A system pokazuje „Sprawdź swoją pocztę e-mail”

Scenariusz: adres e-mail nie pasuje do żadnego konta
Biorąc pod uwagę, że żaden użytkownik nie ma adresu e-mail „[email protected]”
Gdy ktoś prosi o zresetowanie hasła dla „[email protected]”
Wtedy nie zostanie wysłany żaden e-mail
System pokazuje „Sprawdź pocztę” (ta sama wiadomość)

Scenariusz: łącze resetowania zostało ponownie użyte
Biorąc pod uwagę, że link resetowania został kliknięty raz pomyślnie
Po ponownym kliknięciu tego samego łącza
Następnie użytkownik widzi „Ten link został już użyty”

Użyj go, gdy: zachowanie zależy od danych wejściowych lub stanu. Format sprawia, że ​​rozgałęzienia są wyraźne.

Pomiń to, gdy: historia jest jedną prostą rzeczą (logowanie przy użyciu ważnych danych uwierzytelniających). Korniszon dodaje ceremonii, nie dodając przejrzystości w trywialnych przypadkach.

Pułapka: większość drużyn nadużywa korniszona. Tworzą listę faktów w formacie korniszona, które w rzeczywistości nie są scenariuszami. Trzy dane, bez „kiedy”, bez „potem”; to tylko udawana lista punktowana.

Format 3: Tabela przykładów

Kiedy historia brzmi „oblicz właściwą wartość dla tych N danych wejściowych”, tabela bije prozę.

Historia: Ceny rozliczeń rocznych i miesięcznych

Planuj	Siedzenia	Termin	Oczekiwana suma
Zawodowiec	1	Miesięcznie	£5
Zawodowiec	5	Miesięcznie	£25
Zawodowiec	1	Roczne	50 GBP (60 GBP - 10 GBP rabatu)
Zawodowiec	5	Roczne	250 GBP (300 GBP - 50 GBP rabatu)
Zawodowiec	0	Albo	Odrzuć; nieważne

Użyj go, gdy: praca polega na wyszukiwaniu, obliczeniach lub transformacji z wieloma przypadkami wejściowymi. Ceny, podatki, macierze uprawnień, zasady walidacji.

Pomiń, gdy: zachowania nie można zredukować do awantury.

Pułapka: autorzy wymieniają wiersze szczęśliwej ścieżki i pomijają granice. Interesujące przypadki to puste dane wejściowe, maksimum, liczba ujemna, nieprawidłowa waluta. Jeśli tabela ma 4 szczęśliwe wiersze i wiersze o zerowej krawędzi, kryteria są niekompletne.

Format 4: Lista testów akceptacyjnych

Każde kryterium jest tytułem testu, który będzie istniał po pracy.

Historia: Wydajność sprintu szanuje święta

Testy do zaliczenia:

• capacity_calculator_excludes_holidays
• capacity_calculator_handles_partial_day_holidays
• capacity_calculator_uses_team_timezone_for_holiday_resolution
• capacity_calculator_returns_zero_when_all_days_are_holidays
• capacity_calculator_warns_when_more_than_50_percent_of_sprint_is_holiday

Używaj go, gdy: zespół najpierw pisze testy lub gdy „ukończenie” zostanie w sposób udowodniony zautomatyzowane. Szczególnie przydatne w przypadku historii zaplecza bez powierzchni interfejsu użytkownika.

Pomiń to, gdy: praca ma charakter eksploracyjny, wymaga dużych nakładów projektowych lub nie zawiera jeszcze żadnych testowalnych twierdzeń.

Pułapka: nie każda historia ma znaczący automatyczny test. Narzucanie tego formatu historii w języku polskim to teatr.

Format 5: Definicja ukończenia + delta specyficzna dla historii

Dla dojrzałych zespołów: zamiast powtarzać te same kryteria w każdej historii (przeprowadzono testy, przejrzano kod, zaktualizowano dokumentację), zespół Definicja Ukończenia obejmuje je. Historia opisuje tylko to, czego dotyczy to historia.

Kryteria akceptacji specyficzne dla historii:

• Kalkulator prędkości obsługuje sprinty z prędkością 0 bez dzielenia przez zero
• Prognozujący sprint używa mediany, a nie średniej, gdy prędkość ma dużą zmienność
• Obydwa kalkulatory pokazują podstawowe liczby, a nie tylko wynik

(Obowiązuje standardowy DoD; testy, przeglądanie, wdrażanie, dokumentacja, sprawdzanie dostępności.)

Użyj go, gdy: zespół ma działający DoD. (Patrz definicja gotowej inżynierii i Narzędzie do generowania DoD.)

Pomiń to, gdy: DoD zespołu ma charakter aspiracyjny, a nie faktycznie egzekwowany. Nie odwołuj się do DoD, który nie obejmuje łączenia bramek.

Pułapka: historie z tylko „zobacz DoD” i żadnych kryteriów związanych z fabułą. Oznacza to, że praca nie jest jeszcze zdefiniowana; to po prostu „zrób to”.

Jak wybrać format

Większość historii nie wymaga rozmowy w formacie. Większość historii potrzebuje kul. Wybierz format inny niż pocisk tylko wtedy, gdy pociski nie wytrzymają obciążenia:

• Zachowanie rozgałęziające → Korniszon
• Wyszukiwanie lub obliczanie → Tabela
• Obciążający backend / najpierw test → Lista testów
• Dojrzały zespół ze stabilnym DoD → DoD + delta

Mieszanie formatów w jednej historii jest w porządku. Historia może mieć trzy punkty i małą tabelę przykładów.

Pięć anty-wzorców

Większość błędów w kryteriach nie dotyczy formatu. Mają charakter strukturalny.

1. Zmiana tytułu

Historia: Użytkownik może się zalogować

Kryteria akceptacji:

• Użytkownik może się zalogować

Zero dodanych informacji. Kryterium musi zostać określone co liczy się jako zalogowanie; dane uwierzytelniające zaakceptowane, sesja ustawiona, następuje przekierowanie; albo to hałas.

2. Etapy wdrożenia ukryte w kryteriach

Kryteria akceptacji:

• Dodaj password_resets stół
• Dodaj PasswordResetsController
• Dodaj PasswordResetMailer

To są zadania, a nie kryteria. Kryteria opisują wyniki; zadania opisują pracę. Jeśli jutro zespół wybierze inną implementację (zewnętrzny dostawca uwierzytelniania), kryteria powinny nadal obowiązywać. Zadania wdrożeniowe znajdują się na osobnej liście kontrolnej lub zadaniach inżyniera, a nie w kryteriach akceptacji.

3. Kryteria nietestowalne

• System powinien być szybki
• Interfejs użytkownika powinien wyglądać profesjonalnie
• Kod powinien być czysty

Jeżeli nie można się zgodzić, czy warunek jest spełniony, nie stanowi to kryterium. „Strona ładuje się w czasie krótszym niż 200 ms przy 95. percentylu” można przetestować. „Powinno być szybko” to pobożne życzenie.

4. Ukryte kryteria

Programista dostarcza zmianę, recenzent mówi „ale powinna też obsługiwać X”, a X nigdy nie zostało zapisane. Jeśli X było ważne, było kryterium. Jeśli X nie było na tyle ważne, aby je zapisać, nie może blokować scalenia.

Rozwiązanie: gdy recenzent prosi o X, albo (a) odrzuć prośbę, ponieważ kryteria nie mówią X, albo (b) zaakceptuj X, ale dodaj je do kryteriów, aby następny recenzent następnej historii wiedział, że pasek został przesunięty. Nie pozwól, aby pasek dryfował cicho.

5. Kryteria dodane po rozpoczęciu pracy

Inżynier po dwóch dniach pracy
„Czekaj, czy możemy dodać kryteria akceptacji?”

Jeśli kryteria pojawiają się dopiero po rozpoczęciu pracy, opisują to, co już zbudowano, zamiast określać, co należy zbudować. Albo potwierdzają po fakcie już wykonaną pracę (to w porządku, ale trzeba to przyznać), albo rozszerzają jej zakres w trakcie realizacji (to nie jest w porządku; przenieś je do nowej historyjki).

The structural fix: refuse to start work without criteria. Udoskonalenie to miejsce, w którym są pisane. (Patrz Element Runbook udoskonalania zaległości.)

Zasada pięciu minut

Jeśli zapisanie kryteriów akceptacji dla historyjki typowego rozmiaru zajmuje ponad pięć minut, historyjka jest za duża lub niejasna. Samo pisanie kryteriów pozwala sprawdzić jakość historyjki.

Jeśli nadal potrzebujesz 30 minut:

• Ta historia jest epicka w przebraniu (podziel ją)
• Zespół nie rozumie wymagania — potrzeba więcej doprecyzowania, a mniej pisania.
• Kryteria służą do spierania się o zakres z trudnym interesariuszem — to problem procesu, a nie pisania.

Mała, jasno opisana historyjka powinna szybko prowadzić do jasnych kryteriów. Jeśli tak się nie dzieje, problem leży na wcześniejszym etapie.

Jak kryteria akceptacji współdziałają z resztą systemu

• Ocena historii: punkty powinny odzwierciedlać zapisane kryteria. Jeśli kryteria rozszerzają się w trakcie sprintu, błędne było oszacowanie punktów, a nie praca zespołu. (Zobacz oszacowanie punktu historii.)
• Definicja Gotowe: bramy obejmujące cały zespół, które dotyczą każdej historii. Kryteria dotyczą konkretnej historii. Te dwa elementy nie nakładają się na siebie; stosują.
• Cel sprintu: kryteria definiują, kiedy jedna historia jest ukończona. Cel sprintu określa, kiedy sprint dostarczył coś spójnego. Sprint, w którym kryteria zostały spełnione w 100%, ale nie osiągnięto celów sprintu, oznaczał złe planowanie sprintu, a nie złe kryteria.
• Retrospektywy: jeśli to samo kryterium zostanie pominięte w sprincie za sprintem (dopracowanie UX, dostępność, stany błędów), należy to do DoD zespołu, a nie do każdej historii.

Minimalne realne kryteria akceptacji

Jeśli Twój zespół obecnie nie ma żadnego, zacznij tutaj:

1. Każda historia ma co najmniej jeden punkt, który szczegółowo opisuje, jak wygląda „praca”.
2. Każda historia ma co najmniej jeden punkt dotyczący przypadku granicznego (puste dane wejściowe, stan błędu, przypadek oczywisty, ale pominięty).
3. Każda historia zawiera co najmniej jeden punkt dotyczący tego, skąd użytkownik wie, że się udało.

Trzy kule. Pięć minut. Większość skarg w stylu „Nie wiedziałem, że tego potrzebujemy” wyłapałem podczas pierwszych dwóch sprintów.

Po dwóch miesiącach eskaluj format tylko wtedy, gdy proste kule nie udźwigną obciążenia.

Konkluzja

Kryteria akceptacji to nie zgodność. They’re how the team and the requester agree what “done” means wcześniej praca się rozpoczyna, więc po wysłaniu nie zostaje ona ponownie zdefiniowana.

Nie pisz więcej, niż wymaga tego historia. Nie pisz mniej, niż wymaga tego historia. Zasada pięciu minut i minimum trzech kul dogoni większość drużyn.

Kiedy przejdziesz dalej, sformatuj kryteria wokół miły chodzi o historię, a nie o to, czego nauczał twój kurs szkoleniowy.