W środowisku rozwoju agilnego jasność jest walutą sukcesu. Gdy zespół zaczyna pracować nad nową funkcjonalnością, podstawą jest historia użytkownika. Jednak historia użytkownika to tylko miejsce na rozmowę. Aby przekształcić tę rozmowę w działający produkt, potrzebne są dwa kluczowe elementy: kryteria akceptacji i definicja gotowości. Te pojęcia działają jak bariery, które zapewniają jakość, zgodność i przewidywalność.
Wiele zespołów ma trudności z rozróżnieniem tych dwóch pojęć. Czasem traktuje się je jako to samo, co prowadzi do zamieszania podczas testowania lub wdrażania. W innych przypadkach są całkowicie pomijane, co skutkuje rozrostem zakresu lub wypuszczeniem niekompletnych funkcjonalności do produkcji. Ten przewodnik bada mechanizmy, cele i implementację kryteriów akceptacji oraz definicji gotowości, aby pomóc Twojemu zespołowi spójnie dostarczać wartość.
Czym jest historia użytkownika? 📝
Zanim przeanalizujemy składniki historii, ważne jest przypomnieć sobie, czym naprawdę jest historia użytkownika. W ramach frameworków agilnych historia użytkownika to krótkie, proste opisanie funkcjonalności przedstawione z perspektywy osoby, która chce nowej możliwości. Zazwyczaj podlega ona następującemu formatowi:
- Jako [rodzaj użytkownika],
- Chcę [któreś cel],
- Aby [któraś korzyść].
Ten format skupia się na wartościzostałej użytkownika, a nie na implementacji technicznej. Jednak ten format sam w sobie nie wystarcza do kierowania rozwojem. Nie określa granic pracy ani standardów wymaganych do jej zakończenia. To właśnie tutaj wchodzą kryteria akceptacji i definicja gotowości.
Kryteria akceptacji (KA): Warunki zakończenia ✅
Kryteria akceptacji to zestaw warunków, które historia użytkownika musi spełnić, aby być uznana za zakończoną z perspektywy właściciela produktu. Definiują one granice historii i zapewniają jasne zrozumienie, jak powinien wyglądać ostateczny produkt.
Cel kryteriów akceptacji
Kryteria akceptacji pełnią wiele funkcji w cyklu rozwoju:
- Ujednolicenie: Usuwają niepewność. Jeśli programista zapyta: „Czy przycisk ma zmienić kolor na zielony czy niebieski przy najechaniu?”, kryteria akceptacji powinny odpowiedzieć na to pytanie.
- Testowanie: Są testami. Inżynierowie jakości wykorzystują te warunki do weryfikacji funkcjonalności.
- Porozumienie: Zapewniają, że właściciel produktu i zespół programistów zgadzają się, co oznacza „zakończone” dla konkretnej historii.
Cechy dobrych kryteriów akceptacji
Skuteczne kryteria akceptacji są konkretne, mierzalne i jednoznaczne. Unikaj nieprecyzyjnych słów takich jak „przyjazny dla użytkownika” lub „szybki” bez określenia metryk. Zamiast tego określ dokładnie zachowania.
- Atomowe: Każde kryterium powinno dotyczyć jednego wymagania.
- Testowalne: Musi być możliwe zweryfikowanie kryterium z wynikiem „przeszło” lub „nieprzeszło”.
- Niezależne:Kryteria nie powinny opierać się na zewnętrznych historiach użytkownika w celu weryfikacji.
- Dotyczące:Skup się na wartości dla użytkownika, a nie na wewnętrznej strukturze kodu.
Przykłady kryteriów akceptacji
Zastanów się nad historią dotyczącą dodania funkcji „Zapomniałem hasło”. Oto jak mogą wyglądać kryteria akceptacji:
- Dane, że użytkownik znajduje się na stronie logowania,
Gdy klikną w link „Zapomniałem hasło”,
To zostaną przekierowani na stronę odzyskiwania hasła. - Dane, że użytkownik wprowadził poprawny adres e-mail,
Gdy prześlą formularz,
To zostanie wyświetlone powiadomienie potwierdzające. - Dane, że użytkownik wprowadził niepoprawny adres e-mail,
Gdy prześlą formularz,
To zostanie wyświetlone komunikat o błędzie wskazujący, że format adresu e-mail jest niepoprawny.
Te przykłady wykorzystują strukturęDane/Gdy/To (często kojarzona z składnią Gherkin), która promuje jasność i jest zgodna z frameworkami testów automatycznych.
Definicja gotowości (DoD): Brama jakości 🚧
Podczas gdy kryteria akceptacji dotyczą pojedynczej historii użytkownika, Definicja Gotowości to globalny standard stosowany dowszystkichpracy w ramach sprintu lub wydania. Reprezentuje listę kontrolną wymagań, które muszą zostać spełnione, aby każdy fragment pracy mógł być uznany za potencjalnie gotowy do wypuszczenia.
Cel Definicji Gotowości
DoD działa jak brama jakości. Zapewnia, że dług techniczny nie gromadzi się, a produkt zawsze pozostaje w stanie gotowym do wypuszczenia. Jeśli historia spełnia swoje kryteria akceptacji, ale nie spełnia Definicji Gotowości, nie może być oznaczona jako zakończona.
Typowe elementy zawarte w Definicji Gotowości to:
- Przegląd kodu:Wszystki kod musi zostać przeszedł przez przegląd co najmniej jednego kolegi.
- Testy jednostkowe:Testy automatyczne muszą przejść z 100% pokryciem dla nowej logiki.
- Dokumentacja: Dokumentacja interfejsu API lub przewodniki użytkownika są aktualizowane.
- Wydajność: Funkcja spełnia wymagania minimalnego czasu ładowania.
- Dostępność: Funkcja przestrzega wytycznych WCAG.
- Bezpieczeństwo: Nie wprowadzono znanych luk bezpieczeństwa.
Dlaczego DoD ma znaczenie
Bez Definicji Gotowości zespoły często wpadają w pułapkę „technicznie zakończone, ale niegotowe do użytku”. Funkcja może działać zgodnie z kryteriami akceptacji, ale może uszkodzić inny element systemu, brakować odpowiedniej dokumentacji lub wprowadzać ryzyko bezpieczeństwa. DoD zapobiega temu, wymuszając podstawowy poziom jakości na całym zestawie zadań.
Kryteria akceptacji w porównaniu do Definicji Gotowości: Kluczowe różnice 🆚
Pomyłki często powstają, ponieważ oba pojęcia dotyczą „kompletności”. Jednak ich zakres i odpowiedzialność znacznie się różnią. Zrozumienie tej różnicy zapobiega nieporozumieniom między programistami, testerami i właścicielami produktu.
| Funkcja | Kryteria akceptacji | Definicja Gotowości |
|---|---|---|
| Zakres | Specyficzne dla pojedynczego User Story | Globalne dla całego zespołu lub projektu |
| Odpowiedzialność | Właściciel produktu i zespół programistów | Cały zespół programistów |
| Elastyczność | Zmiany na podstawie wymagań dla każdej historii | Stabilna, choć może być aktualizowana w czasie |
| Cel | Określa wymagania funkcjonalne | Określa standardy jakości i niiefunkcjonalne |
| Weryfikacja | Testy funkcjonalne wobec potrzeb użytkownika | Weryfikacja techniczna i procesowa |
Wyobraź sobie, że Kryteria Akceptacji to cel konkretnego przejazdu, a Definicja Gotowości to lista kontrolna bezpieczeństwa wymagana dla każdego pojazdu na drodze.
Jak pisać skuteczne kryteria akceptacji 📝
Pisanie kryteriów akceptacji to współdziałanie. Nie powinno być wykonywane samodzielnie przez właściciela produktu. Najlepszą praktyką jest koncepcja „Trzech Przyjaciół”, w której właściciel produktu, programista i tester współpracują na wczesnym etapie procesu dopasowania.
Krok 1: Zidentyfikuj cel użytkownika
Zacznij od ponownego sformułowania wartości produktu. Jakie problemy rozwiązuje użytkownik? To zapewnia, że kryteria skupiają się na doświadczeniu użytkownika, a nie na szczegółach technicznych.
Krok 2: Zdefiniuj scenariusze pozytywne i negatywne
Nie rób tylko ścieżki szczęśliwego użytkownika. Rozważ, co się dzieje, gdy rzeczy poszły nie tak.
- Ścieżka szczęśliwego użytkownika: Użytkownik wykonuje działanie dokładnie tak, jak się spodziewano.
- Przypadki graniczne: Co się dzieje z znakami specjalnymi, brakującymi danymi lub wolnymi połączeniami?
- Ścieżka negatywna: Jak system obsluży nieprawidłowe dane w sposób przyjazny dla użytkownika?
Krok 3: Używaj jasnego języka
Unikaj żargonu tam, gdzie to możliwe. Jeśli są potrzebne terminy techniczne, upewnij się, że są zdefiniowane. Używaj czasu orzecznika. Na przykład: „System ma zweryfikować…” jest mniej jasne niż „Użytkownik otrzymuje komunikat o błędzie…”.
Krok 4: Priorytetyzuj
Jeśli historia jest duża, podziel ją. Kryteria akceptacji powinny być osiągalne w ramach sprintu. Jeśli kryteria sugerują pracę, której nie da się zakończyć w ramach sprintu, historia musi zostać podzielona.
Jak stworzyć solidną definicję gotowości 🛠️
Definicja gotowości nie jest dokumentem statycznym. Rozwija się wraz z dojrzewaniem zespołu i zmianami technologii. Powinna być widoczna dla wszystkich, często wyświetlana na tablicy fizycznej lub cyfrowej.
Krok 1: Skonsultuj się z zespołem
Definicja gotowości należy do zespołu, który wykonuje pracę. Programiści, testerzy i projektanci powinni przyczyniać się do listy. Jeśli programista dodaje wymóg, jest bardziej skłonny go przestrzegać.
Krok 2: Kategoryzuj wymagania
Grupuj elementy definicji gotowości według logicznych kategorii, aby lista kontrolna była łatwa w obsłudze.
- Jakość kodu: Sprawdzenie kodu zakończone sukcesem, brak ostrzeżeń, przegląd przez kolegę zakończony.
- Testowanie: Testy jednostkowe napisane, testy integracyjne zakończone sukcesem, testy ręczne zweryfikowane.
- Wdrożenie: Wdrożone na środowisku testowym, testy smoka zakończone sukcesem.
- Dokumentacja: Readme zaktualizowane, dokumentacja API zsynchronizowana.
Krok 3: Zrób to zatrzymanie na twardo
Jeśli historia nie spełnia Kryteriów Zakończenia, nie może zostać zamknięta. Wymaga to dyscypliny. Jest pokusą powiedzieć: „Zrobimy poprawki w dokumentacji później”, ale to tworzy dług techniczny. Historia pozostaje w stanie „W trakcie” aż do spełnienia Kryteriów Zakończenia.
Krok 4: Przegląd i doskonalenie
W trakcie retrospekcji zapytaj zespół: „Czy nasze Kryteria Zakończenia wykryły jakieś problemy?” lub „Czy jest wymóg, którego ciągle brakuje?” Uaktualnij Kryteria Zakończenia na podstawie tych spostrzeżeń.
Powszechne błędy do uniknięcia ⚠️
Nawet doświadczone zespoły popełniają błędy podczas wdrażania tych praktyk. Znajomość typowych pułapek może zaoszczędzić znaczną ilość czasu i frustracji.
1. Nieprecyzyjne kryteria akceptacji
Pisanie kryteriów takich jak „System powinien być bezpieczny” jest bezużyteczne. Nie jest to testowalne. Zamiast tego określ: „System musi wymagać uwierzytelniania wieloskładnikowego dla kont administratorów.”
2. Kryteria Zakończenia jako formalność
Jeśli zespół zaznacza pole Kryteriów Zakończenia, nie wykonując faktycznej pracy (np. pomijając przegląd kodu), Kryteria Zakończenia tracą sens. Kryteria Zakończenia muszą być szanowane, a nie tylko przeczytane.
3. Nadmierna skomplikowanie Kryteriów Zakończenia
Kryteria Zakończenia z 50 pozycjami stają się przytłaczające. Skup się na kluczowych barierach jakościowych. Jeśli wymóg rzadko jest naruszany, może to być zasada, a nie obowiązkowa pozycja Kryteriów Zakończenia.
4. Ignorowanie wymagań niiefunkcjonalnych
Zespoły często skupiają się mocno na Kryteriach Akceptacji (funkcjonalnych) i ignorują Kryteria Zakończenia (niiefunkcjonalne). Wydajność, bezpieczeństwo i dostępność są częścią Kryteriów Zakończenia, a nie Kryteriów Akceptacji. Ignorowanie ich prowadzi do funkcjonalności, która działa, ale jest wolna lub niebezpieczna.
5. Tworzenie Kryteriów Zakończenia bez zaangażowania zespołu
Jeśli Product Owner ustala Kryteria Zakończenia bez udziału programistów, zespół może się temu opierać. Kryteria Zakończenia muszą być wspólnym porozumieniem.
Integracja z przepływem pracy 🔄
Kryteria Akceptacji i Kryteria Zakończenia powinny być zintegrowane z każdym etapem cyklu rozwojowego, a nie tylko na końcu.
Faza dopasowania
W trakcie dopasowania backlogu Product Owner opracowuje Kryteria Akceptacji. Zespół je przegląda, aby upewnić się, że są testowalne i realizowalne. Pytania są zadawane i odpowiadane tutaj, a nie podczas sprintu.
Planowanie sprintu
Podczas zobowiązywania się do historii zespół sprawdza, czy Kryteria Akceptacji są jasne. Jeśli nie są, historia nie jest gotowa do sprintu.
Faza rozwoju
Programiści piszą kod, aby spełnić Kryteria Akceptacji. Jednocześnie zapewniają, że przestrzegają Kryteriów Zakończenia (np. piszą testy, żądają przeglądów).
Faza testowania
Inżynierowie QA sprawdzają Kryteria Akceptacji w stosunku do zbudowanej funkcjonalności. Sprawdzają również Kryteria Zakończenia (np. sprawdzają raporty pokrycia kodu, skany dostępności).
Przegląd i zamknięcie
Zanim historia zostanie przeniesiona do stanu „Zakończone”, zespół potwierdza, że spełnione są zarówno Kryteria Akceptacji, jak i Kryteria Zakończenia. Jeśli nie, historia wraca do kolejki.
Mierzenie sukcesu 📊
Jak możesz wiedzieć, czy Twoje Kryteria Akceptacji i Kryteria Zakończenia działają? Śledź metryki w czasie.
- Wskaźnik wad:Czy liczba błędów znalezionych w środowisku produkcyjnym maleje? Silny DoD powinien wyłapywać problemy przed wydaniem.
- Wskaźnik odrzuceń:Czy historie użytkownika są często odrzucane przez Product Ownera? Oznacza to słabe zdefiniowanie kryteriów akceptacji.
- Stabilność prędkości:Czy prędkość zespołu pozostaje stała? Jeśli historie są często zwracane z powodu brakujących elementów DoD, prędkość będzie się zmieniać.
- Częstotliwość wdrażania:Czy jasny DoD pozwala na płynniejsze i częstsze wdrażania?
Często zadawane pytania ❓
Oto najczęściej zadawane pytania przez zespoły podczas wdrażania tych standardów.
Q: Czy kryteria akceptacji mogą się zmieniać w trakcie sprintu?
A: Idealnie, nie. Jeśli kryteria akceptacji znacznie się zmieniają, może to wskazywać na to, że historia nie została dobrze zrozumiana podczas dopasowania. Małe wyjaśnienia są dopuszczalne, ale istotne zmiany zakresu powinny skutkować nową historią lub dostosowaniem zakresu sprintu.
Q: Czy każda historia potrzebuje unikalnej definicji gotowości?
A: Nie. DoD jest globalne. Jednak konkretne historie techniczne mogą mieć dodatkowe wymagania dodane do listy kontrolnej dla tego konkretnego elementu, ale podstawowa definicja gotowości dotyczy wszystkich.
Q: Co jeśli zespół nie zgadza się co do DoD?
A: Zorganizuj dyskusję. Celem jest zgodność. Jeśli deweloper naciska na wymóg, którego tester nie zgadza się, omów ryzyko. Jeśli ryzyko jest niskie, zrezygnuj z niego. Jeśli wysokie, zostaw.
Q: Jak szczegółowe powinny być kryteria akceptacji?
A: Wystarczająco szczegółowe, aby można je było przetestować. Jeśli inżynier QA może bezpośrednio napisać przypadek testowy na podstawie kryteriów akceptacji, są one wystarczająco szczegółowe. Jeśli musi zadawać pytania, potrzebują więcej szczegółów.
Q: Czy testy automatyczne mogą zastąpić testy ręczne w DoD?
A: Zależy. Dla krytycznej logiki – tak. Dla doświadczenia użytkownika lub elementów wizualnych może być wciąż wymagana weryfikacja ręczna. DoD powinien odzwierciedlać najlepsze praktyki zapewnienia jakości.
Ostateczne rozważania dotyczące jakości i zgodności 🌟
Wprowadzanie kryteriów akceptacji i definicji gotowości nie dotyczy biurokracji; dotyczy szacunku. To szacunek dla użytkownika, który oczekuje działającej funkcjonalności, szacunek dla dewelopera, który chce jasnych wymagań, oraz szacunek dla właściciela produktu, który potrzebuje pewności co do dostarczenia.
Kiedy te dwa pojęcia są używane poprawnie, tworzą wspólny język dla zespołu. Zmniejszają potrzebę ciągłych spotkań wyjaśniających. Zapobiegają akumulacji długu technicznego. A najważniejsze – zapewniają, że każda zakończona historia przynosi rzeczywistą wartość dla produktu.
Zacznij od małego. Zdefiniuj podstawowy DoD. Napisz jasne kryteria akceptacji dla następnej historii. Przejrzyj je na kolejnym retrospektywie. Z czasem te praktyki staną się naturalne, wciąż się w kulturze Twojego zespołu. Wynikiem jest stały strumień wysokiej jakości oprogramowania spełniającego potrzeby osób, które go używają.