Jak pisać kryteria akceptacji w Jira — praktyczne przykłady

„Klienci mogą zmieniać preferencje powiadomień” brzmi jak jasne zgłoszenie, dopóki nie zacznie się implementacja. Czy zmiana zapisuje się od razu? Co przy błędzie zapisu? Czy preferencja przetrwa do jutra? Których wiadomości dotyczy?

Kryteria akceptacji zamieniają te pytania w uzgodnione, obserwowalne wyniki. Pozwalają zamawiającym, budującym i sprawdzającym zmianę pracować według tych samych oczekiwań.

Opracujemy kryteria fikcyjnej funkcji portalu, poprawimy niejasne wymagania i dodamy listę do Definition of Done & AC w Power Pack. Nie potrzebujesz szczególnego formatu pisania. Wystarczą jasne warunki i wyniki.

Czym są kryteria akceptacji?

Opisują warunki, które konkretna praca musi spełnić, aby została przyjęta. Skupiają się na oczekiwanym wyniku danego elementu. Atlassian odróżnia je od Definition of Done, opisującej szerszy standard jakości ukończonej pracy. Zobacz poradnik Atlassian.

W przykładzie kryterium brzmi: „Zapisany wybór powiadomień pozostaje zaznaczony po ponownym zalogowaniu”. „Implementacja została przejrzana” należy do wspólnej Definition of Done.

Rozróżnienie zachowuje użyteczność obu list. Kryteria mówią, czy funkcja robi to, co ustalono. Definition of Done mówi, czy praca spełnia szerszy standard zakończenia zespołu.

Żadna lista nie musi zawierać wszystkich kroków technicznych. „Utworzyć pole w bazie” może być potrzebnym zadaniem, ale nie mówi klientowi ani sprawdzającemu, czy preferencja działa poprawnie.

Zacznij od jednego wyniku klienta

Fikcyjne zgłoszenie brzmi „Pozwól klientom sterować cotygodniowym podsumowaniem”. Celem jest możliwość wyboru otrzymywania podsumowania przez zalogowanego klienta bez wpływu na niezbędne wiadomości konta.

Przed pisaniem zespół ustala zakres. Ustawienie ma jawny przycisk Save. Klient zmienia wyłącznie własną preferencję. Dotyczy ona podsumowań jeszcze niedodanych do kolejki. Wiadomości już w kolejce są poza regułą wysyłki tego zgłoszenia.

Te szczegóły są wymyślone dla przykładu. Zespół powinien sam ustalić rzeczywiste zachowanie, zamiast kopiować je jako wymagania.

Krótka notatka zakresu pozwala uniknąć przenoszenia całego kontekstu do długiej listy. W opisie Jira zespół zapisuje, że chodzi o jedną preferencję na stronie ustawień konta. Dni wysyłki, adresy e-mail i ustawienia innych klientów to oddzielne prace.

Teraz kryteria mogą skupić się na wynikach potwierdzających działanie tej konkretnej zmiany.

Najpierw opisz typowy przebieg

Zacznij od ścieżki większości klientów. Opisz zwykłym językiem warunek początkowy, czynność i obserwowalny wynik.

Na przykład: „Gdy zalogowany klient wyłączy podsumowania i skutecznie zapisze zmianę, ponowne otwarcie ustawień pokazuje podsumowania wyłączone”. Sprawdzający może utworzyć stan początkowy, wykonać czynność i obejrzeć rezultat.

To przydatniejsze niż „Preferencje zapisują się poprawnie”. Wskazuje zmienianą preferencję, moment działania i metodę sprawdzenia.

Potrzebny jest też kierunek przeciwny. Kontrolka wyłączająca podsumowania, ale niemogąca ich włączyć, jest niekompletna. Napisz osobne kryterium, gdy odwrotne zachowanie wymaga własnej weryfikacji.

Nie łącz niezwiązanych wyników w jednym wpisie. Zapis, klawiatura, wysyłka i błędy mogą być ważne, lecz ogromny warunek utrudnia pokazanie, która część nadal wymaga uwagi.

Dodaj błędy i granice

Typowy przebieg zakłada udany zapis. Zapytaj, co klient zobaczy, gdy to założenie będzie fałszywe.

Zespół wybiera regułę: przy nieudanym żądaniu zapisu strona pokazuje błąd bez potwierdzenia sukcesu. Po ponownym otwarciu pozostaje poprzednio zapisana preferencja. To konkretny przypadek awarii do wykonania w środowisku testowym.

Następnie sprawdź granicę funkcji. Ustawienie podsumowań nie może blokować resetu hasła. Wybór klienta musi też przetrwać nową sesję logowania. To różne kwestie, więc otrzymują osobne kryteria.

Unikaj „Wszystkie przypadki brzegowe obsłużone”. Nazwij ważne przypadki. Pomocne są pytania: co może zawieść, co musi pozostać bez zmian i co wydarzy się później?

Jeśli zespół nie uzgodni oczekiwanego wyniku, zapisz otwartą decyzję, zanim implementacja zajdzie za daleko. Pytanie bez odpowiedzi nie staje się użytecznym kryterium przez umieszczenie na liście.

Przykładowa pełna lista kryteriów

Oto pierwszy kompletny szkic fikcyjnego zgłoszenia. Każdą pozycję można zweryfikować oddzielnie.

• Otwarcie ustawień pokazuje aktualnie zapisaną preferencję podsumowań klienta.
• Po wyłączeniu podsumowań i udanym zapisie ponowne otwarcie ustawień pokazuje preferencję wyłączoną.
• Po włączeniu podsumowań i udanym zapisie ponowne otwarcie ustawień pokazuje preferencję włączoną.
• Po udanym zapisie wylogowanie i ponowne zalogowanie zachowuje preferencję.
• Nieudany zapis pokazuje błąd bez potwierdzenia sukcesu, a ponowne otwarcie pokazuje poprzednią preferencję.
• Klient z wyłączoną preferencją nie otrzymuje podsumowania dodanego do kolejki po udanym zapisie.
• Klient z włączoną preferencją pozostaje objęty następnym podsumowaniem według istniejącego harmonogramu.
• Wyłączenie podsumowań nie blokuje zamówionej wiadomości resetowania hasła.

Wpisy wysyłki zależą od decyzji o wiadomościach w kolejce. Zespół zapisuje kontekst przy zgłoszeniu, aby sprawdzający nie zakładał wycofywania wiadomości już wysyłanych.

Potrzebna jest także wykonalna metoda kontroli. Dla wysyłki zespół ustala, jak uruchomić lub zaobserwować podsumowanie w testach. Jasne kryterium może pozostać trudne do sprawdzenia bez dostępu do konta lub dowodów dostarczenia.

Popraw niejasne kryteria przed dodaniem

Krótka kontrola tekstu często zapobiega długim późniejszym sporom. Sprawdź, czy dwie osoby mogłyby różnie rozumieć sukces każdej pozycji.

Ostatni przykład sam nie dowodzi użyteczności. Zastępuje niejasne zdanie jedną ograniczoną, przydatną kontrolą. Szersze cele użyteczności mogą potrzebować badań lub kilku uzgodnionych obserwacji.

Uważaj również na wymyśloną precyzję. Wymaganie odpowiedzi w dwie sekundy brzmi mierzalnie, ale tworzy zobowiązanie. Przed dodaniem progu wydajności uzgodnij warunki i powód.

Wprowadź kryteria do Power Pack

Otwórz zgłoszenie i kartę Definition of Done & AC. Wybierz Acceptance Criteria. Lista jest oddzielna od Definition of Done, więc sprawdź zakładkę przed wpisywaniem.

Aby dodać kryterium, wpisz tytuł i wybierz Add lub Enter. Tytuł powinien być krótki, ale zachowywać oczekiwany wynik. Obszerny kontekst trzymaj w opisie Jira albo podlinkowanej dokumentacji.

Dla wielu wpisów wybierz Bulk Import i wklej wypunktowanie Markdown. Możesz skopiować powyższe pozycje, dodając myślnik i spację. Obsługiwane są też listy pól wyboru Markdown.

Po imporcie sprawdź wpisy. Akcja dopisuje do bieżącej listy, więc ponowne wklejenie może tworzyć duplikaty. Zaznaczone pola Markdown będą ukończone; zaczynaj od niezaznaczonych, chyba że wyniki bieżącego zgłoszenia rzeczywiście już zweryfikowano.

Jeśli wpis jest błędny, uzgodnij poprawkę z zespołem, dodaj nową wersję i usuń starą po potwierdzeniu. Zachowaj przejrzystą dyskusję, gdy zmiana wpływa na uzgodniony zakres.

Sprawdź wyniki przed oznaczeniem gotowości

Przed implementacją poproś osobę uczestniczącą w weryfikacji o przegląd kryteriów. Może zauważyć brak warunku początkowego lub wynik nieobserwowalny w dostępnym środowisku.

Po implementacji zweryfikuj każdy wynik i zapisz dowody normalnym procesem Jira lub dokumentacji. Wybierz Done po zaliczeniu oczekiwanego wyniku. Ponowne kliknięcie przywraca stan do zrobienia, jeśli późniejsze ustalenia otwierają kontrolę.

Preferencja może przetrwać odświeżenie strony, ale resetować się po nowym logowaniu. Kryterium ponownego otwarcia może przejść, gdy trwałość między sesjami pozostaje nieukończona. Oddzielne wpisy zachowują to przydatne rozróżnienie.

Power Pack śledzi ukończenie listy; nie uruchamia testów i nie ustala automatycznie sprawdzającego. Jeśli potrzebna jest imienna lub datowana weryfikacja, zapisz te informacje wyraźnie w zwykłym procesie.

Używaj obu liczników, nie myląc ich z dowodami

Acceptance Criteria i Definition of Done pokazują własne liczby ukończonych i wszystkich pozycji. Ready for Release wymaga niepustych obu list i ukończenia każdej pozycji. W innym przypadku widać In Verification.

To podsumowanie wpisanego stanu. Nie potwierdza kompletności ważnych zachowań ani wiarygodności dowodów. Nie wymusza też przejść Jira i nie blokuje scaleń.

W przykładzie wszystkie osiem kryteriów może być spełnionych, a instrukcje wsparcia nadal otwarte w Definition of Done. Wyniki funkcji przeszły, lecz szersze porozumienie ukończenia ma brakujący element.

Zacznij od nadchodzącego zgłoszenia. Opisz wynik klienta, uzgodnij warunki i rezultaty, a następnie dodaj kryteria w Power Pack obok wspólnej Definition of Done. Przejrzyj listę z budującymi i testującymi zmianę. Korzyścią jest mniej założeń ukrytych za pozornie oczywistym zdaniem.

• Atlassian — Czym są kryteria akceptacji?