Jak możemy zagwarantować, że historia użytkownika zostanie poprawnie zrealizowana i spełni wymagania klienta? Oto gdziekryteria akceptacjiwchodzą w grę. Kryteria akceptacji to formalny list wymagań, które zapewniają, że wszystkie historie użytkownika zostaną zrealizowane i rozważone wszystkie scenariusze. Krótko mówiąc, kryteria akceptacji definiują warunki, przy których historia użytkownika jest uznawana za zakończoną. Jasne, zapisane kryteria pomagają zespołom programistycznym uniknąć niejasności co do potrzeb klienta i zapobiegają nieporozumieniom.
Dlatego podczas tworzenia historii użytkownika kryteria akceptacji są niezwykle ważne. Pomagają Twojemu zespołowi zrozumieć, co jest obowiązkowe podczas rozwoju funkcji, i na czym powinien skupić się.
Zajmijmy się kryteriami akceptacji.
Co to są kryteria akceptacji?
Kryteria akceptacji pozwalają określić, kiedy historia użytkownika jest zakończona i kiedy ma wszystkie funkcje potrzebne do spełnienia potrzeb użytkownika.
Są to zestaw warunków, które historia użytkownika musi spełnić, aby być uznana za zakończoną. Podają szczegółowy zakres historii użytkownika i co jest wymagane, dzięki czemu Twój zespół rozumie problem, z którym się spotyka. W ten sposób za każdym razem, gdy wypuszczasz nową funkcję, możesz zagwarantować, że spełnia standard, którego użytkownik zasługuje.
Ale zanim z entuzjazmem wyliczysz zestaw kryteriów funkcyjnych, które powinna spełniać Twoja historia użytkownika, rozważ, jak inne zmienne mogą wpływać na jakość Twojej funkcji, i uwzględnij je w kryteriach akceptacji.
Kryteria akceptacji mogą obejmować szczegóły takie jak
- Doświadczenie użytkownika
- Wpływ obecnej historii użytkownika na istniejące funkcje
- Kluczowe parametry wydajności, takie jak prędkość
- Co historia użytkownika ma na celu
Dlatego w zależności od funkcjonalności, którą budujesz, oraz jej złożoności, posiedź z zespołem i określ minimalny zestaw funkcjonalności, które powinna wykonywać, oraz jak powinna się zachowywać.
Jeśli jest skomplikowana lub kluczową funkcją Twojego produktu, powinieneś rozważyć napisanie jak najwięcej i szczegółowych kryteriów akceptacji, aby pomóc zespołowi uniknąć nieporozumień.
Jak pisać kryteria akceptacji dla historii użytkownika
1. Kryteria akceptacji powinny być pisane z perspektywy użytkownika
Kryteria akceptacji to sposób patrzenia na problem z perspektywy klienta. Powinny być pisane w kontekście rzeczywistego doświadczenia użytkownika. Po wszystkim, budujesz produkt dla użytkowników, prawda?
2. Kryteria powinny być jasne i zwięzłe
Kryteria akceptacji nie powinny być mylone z przypadkami testowymi ani dokumentacją. Ważne jest, aby Twoje kryteria były jak najprostsze i jasne.
3. Każdy musi rozumieć Twoje kryteria akceptacji
Jeśli Twoi programiści ich nie rozumieją, Twoje kryteria są bezużyteczne. Jeśli nie jesteś pewien jasności, poświęć czas na zadawanie pytań i dopasuj, aż wszystko stanie się jasne.
4. Kryteria akceptacji nie dotyczą sposobu (jak?), ale o tym, co (dlaczego?)
Tak jak historie użytkownika, kryteria akceptacji nie są zadaniami. Są sposobem komunikowania historii użytkownika.
5. Kryteria akceptacji są konkretne, ale nie są kolejnym poziomem szczegółowości
Rozważ oprogramowanie do deklaracji podatkowej. Najważniejszym wymaganiem jest poprawne obliczenie podatku do zapłaty na podstawie dochodów i wydatków. Jasne, prawda? I wiesz, że nie możesz przetestować każdej możliwej kombinacji — ponieważ możliwości są niemal nieskończone.
Dlatego kryteria akceptacji dla historii użytkownika będą określać konkretne warunki lub wymagania, które muszą zostać spełnione. Oznacza to być bardziej konkretnym, a nie dodawać kolejnego poziomu szczegółowości. Pomaga to zespołowi zrozumieć, co jest wymagane, i przyspiesza dostarczanie. Oczywiście, gdy porównasz aktualny wykres spadku z poprzednimi, możesz zauważyć pewne poprawy.
6. Kryteria akceptacji mogą być przekazaniem historii użytkownika z perspektywy użytkownika
To dotyczy tylko wtedy, gdy historia użytkownika nie jest nadmiernie skomplikowana. Oto przykład, o którym mówię.
Dla historii użytkownika takiej jak „Jako urzędnik finansowy, chcę akceptować faktury, aby móc śledzić wszystkie raporty finansowe”
Kryteria akceptacji mogą brzmieć „Gdy wykonam działanie akceptacji, faktura zostaje zaakceptowana (potwierdzone przez sprawdzenie rekordu faktury)”
Dane/When/Then – szablon kryteriów akceptacji
Aby ułatwić życie, oto prosty szablon, który możesz użyć do tworzenia kryteriów akceptacji:
Dane [kontekst] gdy [wykonana zostanie określona czynność] then [powinny zajść pewne skutki]
Przykłady kryteriów akceptacji
Dla przykładu historii użytkownika:
“Jako pisarz, chcę otrzymywać powiadomienia, gdy inni dodają komentarze, aby móc być na bieżąco.”
Oto trzy przykłady kryteriów akceptacji dla powyższej historii użytkownika:
- Dane moje urządzenie jest zablokowane gdy aplikacja nie jest otwarta, to powinienem otrzymać powiadomienie w postaci paska.
- Dane piszę dokument gdy aplikacja jest otwarta, to ikona dzwonka powinna zostać zaktualizowana, aby pokazywać nieprzeczytane powiadomienia z licznikiem.
Przykład – Wysyłanie opinii o stronie
Określamy historię użytkownika i kryteria akceptacji dla funkcji komentarza do bloga. Użytkownicy zalogowani mogą dodawać komentarze. Historia użytkownika dla funkcji „Dodaj komentarz” brzmi:
Jak zalogowany użytkownik,
Chcę móc zostawić komentarz do posta na blogu,
aby mógł otrzymać feedback na temat tematu.
Kryteria akceptacji tej funkcji to:
Scenariusz: Zalogowany użytkownik zostawia komentarz do posta na blogu
Zakładając, że jestem zalogowanym użytkownikiem,
Kiedy otworzę stronę zawierającą konkretny post na blogu,
To system wyświetla sekcję „Komentarze” poniżej posta na blogu, pokazując listę komentarzy dodanych przez innych użytkowników.
System wyświetla pole „Dodaj komentarz” na początku sekcji „Komentarze”.
Kiedy wypełnię pole „Dodaj komentarz” swoim komentarzem i kliknę przycisk „Wyślij”,
To system zapisuje mój komentarz.
System wyświetla mój komentarz na początku sekcji „Komentarze”.
System wyświetla moje imię użytkownika i awatar po lewej stronie mojego komentarza.
System wyświetla ikony „Usuń” i „Edytuj” po przeciwnej stronie mojego komentarza.
Jak widać, tworzenie kryteriów akceptacji to prawdziwy sukces dla obu stron – zarówno klientów, jak i zespołów deweloperskich: nie tylko pomaga zespołowi jasno zrozumieć, co musi zrobić, ale także pozwala klientom zrozumieć proces rozwoju i zweryfikować, czy otrzymane oprogramowanie spełnia rzeczywiste potrzeby biznesowe.
- Skuteczne historie użytkownika – przewodnik 3C i INVEST
- Rozwój agilny – iteracyjny i inkrementalny
- Co to jest Product Backlog w Scrumie? Kto za niego odpowiada?
- Jak dopracować Product Backlog?
- Co to jest Sprint Backlog w Scrumie?
- Jak priorytetyzować Product Backlog przy użyciu metody MoSCoW
- Jak priorytetyzować Product Backlog przy użyciu metody 100 punktów?
- Co to jest cel sprintu w Scrumie?
- Co to jest wykres spalania w Scrumie?
- Co to jest szablon Rola-Funkcja-Przyczyna?
- Sprint Increment vs Potencjalnie gotowy produkt vs MVP vs MMP
- Twórz cele SMART i kryteria INVEST dla historii użytkownika