czas czytania: 7 minut
sukces każdego projektu zależy od zdolności zespołu programistycznego do zaspokojenia potrzeb klienta. Komunikacja między Klientem a zespołem programistów odgrywa kluczową rolę w dostarczaniu rozwiązania, które pasuje do wymagań produktu i rynku., Problemy pojawiają się, gdy klienci wyjaśniają swoje potrzeby zbyt niejasno, a zespół nie może zrozumieć jasnych wymagań i ostatecznie problemu biznesowego za nimi. Wyobraź sobie, że poprosisz swój zespół, aby umożliwić użytkownikom wyszukiwanie produktu w Księgarni Internetowej według kategorii. Spodziewasz się, że masz przejrzysty interfejs z linkami do kategorii, aby je kliknąć(np.) Po dwóch tygodniach rozwoju otrzymasz funkcję paska wyszukiwania, w którym użytkownicy muszą wpisać interesującą ich kategorię, zamiast przeglądać wstępnie wymienione kategorie., Chociaż to również działa, Twoim początkowym celem było ujawnienie wszystkich dostępnych kategorii i umożliwienie użytkownikom dalszej eksploracji.
jest to czas, kiedy wysokiej jakości dokumentacja oprogramowania może pomóc uniknąć problemu. Historie użytkowników i kryteria akceptacji (AC) jako główne formaty dokumentowania wymagań. Historia użytkownika to opis funkcji w języku naturalnym. Zazwyczaj towarzyszą mu kryteria akceptacji.
kryteria akceptacji (AC) to warunki, które musi spełniać oprogramowanie, aby zostało zaakceptowane przez Użytkownika, Klienta lub inny system., Są one unikalne dla każdej historii użytkownika i definiują zachowanie funkcji z perspektywy użytkownika końcowego. Dobrze napisane kryteria akceptacji pomagają uniknąć nieoczekiwanych wyników na końcu etapu rozwoju i zapewniają, że wszyscy interesariusze i użytkownicy są zadowoleni z tego, co otrzymują.
kryteria akceptacji są najniższym poziomem wymagań funkcjonalnych
kryteria akceptacji główne cele
wyjaśnienie wymagań interesariuszy jest celem wysokiego poziomu. Aby cele AC były jaśniejsze, Podzielmy je.,
detalizacja zakresu funkcji. AC zdefiniuj granice historii użytkowników. Zapewniają one dokładne szczegóły dotyczące funkcjonalności, które pomagają zespołowi zrozumieć, czy historia została ukończona i działa zgodnie z oczekiwaniami.
opisujące negatywne scenariusze. Yor AC może wymagać od systemu rozpoznania niebezpiecznych wpisów hasła i uniemożliwienia użytkownikowi dalszego postępowania. Nieprawidłowy format hasła jest przykładem tak zwanego scenariusza negatywnego, gdy użytkownik wykonuje nieprawidłowe dane wejściowe lub zachowuje się nieoczekiwanie. AC zdefiniuj te scenariusze i wyjaśnij, jak system musi na nie reagować.
Ustawianie komunikacji., Kryteria akceptacji synchronizują wizje klienta i zespołu deweloperskiego. Zapewniają one, że wszyscy mają wspólne zrozumienie wymagań: Programiści wiedzą dokładnie, jakiego rodzaju zachowanie funkcja musi wykazać, podczas gdy interesariusze i klient rozumieją, czego oczekuje od funkcji.
usprawnienie testów akceptacyjnych. AC są podstawą testów akceptacyjnych user story. Każde kryterium akceptacji musi być niezależnie testowalne, a tym samym mieć wyraźne scenariusze zaliczenia lub niepowodzenia. Można je również wykorzystać do weryfikacji historii za pomocą testów automatycznych.
ocena funkcji., Kryteria akceptacji określają, co dokładnie musi opracować zespół. Gdy zespół ma określone wymagania, może podzielić historie użytkowników na zadania, które można poprawnie oszacować.
kryteria akceptacji typy i struktury
AC mogą być zapisywane w różnych formatach. Istnieją dwa najczęściej spotykane formaty, a trzecią opcją jest opracowanie własnego formatu:
- scenario-oriented (Given/When/Then)
- rule-oriented (checklist)
- formaty niestandardowe
ponieważ pierwszy i drugi format mają bardzo specyficzne struktury, skupimy się głównie na nich., Może się jednak okazać, że inne formaty lepiej pasują do Twojego produktu, więc pokrótce je omówimy.
Scenario-oriented acceptance criteria
Scenario-oriented format zapisu AC jest znany jako typ Given/When / Then (GWT).
- biorąc pod uwagę pewien warunek
- kiedy wykonuję jakąś akcję
- to oczekuję jakiegoś wyniku
to podejście zostało odziedziczone z behavior-driven development (BDD) i zapewnia spójną strukturę, która pomaga testerom określić, kiedy mają rozpocząć i zakończyć testowanie danej funkcji., Zmniejsza to również czas spędzony na pisaniu przypadków testowych, ponieważ zachowanie systemu jest opisane z góry.,
każde kryteria akceptacji zapisane w tym formacie mają następujące instrukcje:
- Scenario – nazwa zachowania, które będzie opisane
- Given – stan początkowy scenariusza
- When – akcja specyficzna dla użytkownika
- Then – wynik akcji w „When”
- i – używany do kontynuowania któregokolwiek z trzech poprzednich poleceń
Po połączeniu te polecenia obejmują wszystkie akcje, które użytkownik trzeba wykonać zadanie i doświadczyć wyniku.
przyjrzyjmy się kilku przykładom.,
przykład 1
Historia użytkownika: jako użytkownik chcę mieć możliwość odzyskania hasła do mojego konta, aby mieć dostęp do mojego konta w przypadku, gdy zapomniałem hasła.,
Kiedy: użytkownik wybrał opcję Nie pamiętam hasła
I: wprowadził prawidłowy e-mail, aby otrzymać link do odzyskania hasła
następnie: system wysłał link do wprowadzonego e-maila
Podane: użytkownik otrzymał link za pośrednictwem e-mail
Kiedy: użytkownik nawigował przez link otrzymany w e-mailu
następnie: system umożliwia użytkownikowi ustawienie nowego hasła
przykład 2
p >
user story: jako użytkownik chcę mieć możliwość żądania gotówki z mojego konta w bankomacie, aby móc otrzymywać pieniądze z mojego konta szybko i w różnych miejscach.,lid
i: kasownik zawiera gotówkę
Gdy: klient żąda gotówki
następnie: upewnij się, że konto jest obciążone
i: upewnij się, że kasa jest wydawana
i: upewnij się, że karta jest wydawana
i: upewnij się, że karta jest zwracana
kryteria akceptacji 2:
Podane: że konto jest przekroczone
i: karta jest ważna
Gdy: klient żąda gotówki
następnie: upewnij się, że komunikat odrzucenia jest wyświetlany
oraz: upewnij się, że nie jest wydawana gotówka
format kryteriów akceptacji zorientowanych na reguły
w niektórych przypadkach trudno jest dopasować kryteria akceptacji do danej struktury/when / then., Na przykład GWT nie byłby przydatny w następujących przypadkach:
- pracujesz z historiami użytkowników, które opisują funkcjonalność na poziomie systemu, która wymaga innych metod zapewniania jakości.
- grupa docelowa dla kryteriów akceptacji nie potrzebuje dokładnych szczegółów scenariuszy testowych.
- scenariusze GWT nie pasują do opisu ograniczeń projektowych i doświadczeń użytkownika danej funkcji. Deweloperzy mogą pominąć wiele krytycznych szczegółów.
możesz rozwiązać te przypadki za pomocą formatu AC zorientowanego na reguły.,
forma zorientowana na reguły oznacza, że istnieje zbiór reguł opisujących zachowanie systemu. Na podstawie tych reguł można narysować określone scenariusze.
zazwyczaj kryteria złożone za pomocą tego formularza wyglądają jak prosta lista punktowa. Spójrzmy na przykład.
przykład
Historia użytkownika: jako użytkownik chcę użyć pola wyszukiwania, aby wpisać Miasto, nazwę lub ulicę, aby znaleźć pasujące opcje hotelu.,
podstawowe kryteria akceptacji interfejsu wyszukiwania
- pole wyszukiwania znajduje się na górnym pasku
- wyszukiwanie rozpoczyna się, gdy użytkownik kliknie „Szukaj”
- pole zawiera symbol zastępczy z szarym tekstem: „dokąd idziesz?”
- Element Zastępczy znika, gdy użytkownik zaczyna wpisywać
- wyszukiwanie jest wykonywane, jeśli użytkownik wpisuje Miasto, nazwę hotelu, ulicę lub wszystkie połączone
- wyszukiwanie jest w języku angielskim, francuskim, niemieckim i ukraińskim
- użytkownik nie może wpisać więcej niż 200 symboli
- wyszukiwanie nie obsługuje specjalnych symboli (znaków)., Jeśli użytkownik wpisał specjalny symbol, wyświetli komunikat ostrzegawczy: „wejście wyszukiwania nie może zawierać specjalnych symboli.”
inne formaty
większość historii użytkownika może być pokryta dwoma wyżej wymienionymi formatami. Możesz jednak wymyślić własne kryteria akceptacji, biorąc pod uwagę, że służą one swoim celom, są napisane wyraźnie w prostym języku angielskim i nie można ich źle zinterpretować. Niektóre zespoły używają nawet zwykłego tekstu.,
czasami Twoje kryteria mogą być określone jako przykład zachowania systemu:
prosty zestaw AC dla silnych haseł autorstwa Marka Levisona dla agilepainpainrelief.com
to podejście zapewnia jasne wytyczne do testowania funkcji haseł.
role odpowiedzialne i sposób tworzenia kryteriów akceptacji
niektóre z kryteriów są definiowane i pisane przez właściciela produktu, gdy tworzy on backlog Produktu. A pozostałe mogą być dalej określone przez zespół podczas dyskusji user stories po planowaniu sprintu., Nie ma ścisłych zaleceń dotyczących wyboru osoby odpowiedzialnej za napisanie kryteriów. Klient może je udokumentować, jeśli posiada wystarczającą wiedzę techniczną i produktową. W takim przypadku Klient negocjuje kryteria z zespołem, aby uniknąć wzajemnych nieporozumień. W przeciwnym razie kryteria są tworzone przez właściciela produktu, analityka biznesowego, analityka wymagań lub kierownika projektu.,
proces rozpoczyna się od ustalenia priorytetów historii użytkownika, a kończy na szczegółach negocjacji z całym zespołem
główne wyzwania i najlepsze praktyki pisania kryteriów akceptacji
kryteria akceptacji wyglądają tak, jakby były bardzo łatwe do napisania. Pomimo ich uproszczonych formatów, pisanie stanowi wyzwanie dla wielu zespołów. Przyjrzyjmy się bliżej najlepszym praktykom, które pomagają uniknąć typowych błędów.
kryteria dokumentu przed opracowaniem. Kryteria akceptacji muszą być udokumentowane przed rozpoczęciem rzeczywistego rozwoju., W ten sposób zespół prawdopodobnie przechwyci wszystkie potrzeby klientów z wyprzedzeniem. Na początku wystarczy ustawić kryteria dla małej liczby historii użytkowników, aby wypełnić zaległości dla dwóch sprintów (jeśli ćwiczysz Scrum lub podobną metodę). Muszą one zostać uzgodnione przez obie strony. Następnie udokumentowane kryteria akceptacji są wykorzystywane przez programistów do planowania procesu technicznego.
nie rób zbyt wąskiego AC. Kryteria akceptacji mogą być zbyt specyficzne dla deweloperów. Aby tego uniknąć, należy pamiętać, że AC musi przekazać zamiar, ale nie ostateczne rozwiązanie., Co więcej, wąskie AC może być pozbawione wielu zachowań użytkowników, które nie są objęte.
Zachowaj swoje kryteria. Punkt ten ściśle przecina się z poprzednim. Skuteczne kryteria akceptacji określają rozsądną minimalną część funkcjonalności, którą jesteś w stanie dostarczyć. Ale jeśli ulegniesz opisaniu wszystkich drobnych szczegółów, istnieje ryzyko, że twój zespół utknie z setkami małych zadań.
trzymaj AC mierzalne i nie zbyt szerokie. Szerokie kryteria akceptacji sprawiają, że historia użytkownika jest niejasna., Skuteczne kryteria akceptacji muszą nakreślić zakres prac, aby deweloperzy mogli prawidłowo zaplanować i oszacować swój wysiłek.
unikaj szczegółów technicznych. Jak już wspomnieliśmy, kryteria akceptacji muszą być napisane w prostym języku angielskim. Dzięki temu będą one jasne i łatwe do zrozumienia dla wszystkich: twoi interesariusze lub menedżerowie mogą nie mieć zaplecza technicznego.
Osiągnij konsensus. Ten sam problem może być rozwiązany w różny sposób przez zespół i interesariuszy, w zależności od ich punktów widzenia. Upewnij się, że przekazałeś swoje AC interesariuszom i osiągnąłeś wzajemne porozumienie., To samo dotyczy członków zespołu. Każdy musi przejrzeć AC i potwierdzić, że rozumie i zgadza się z każdą linią.
napisz testowalny AC. Pozwoli to testerom sprawdzić, czy wszystkie wymagania zostały spełnione. W przeciwnym razie programiści nie zrozumieją, czy historia użytkownika została ukończona.
ostatnie słowo
nie zaniedbuj kryteriów akceptacji, ponieważ – będąc prostym i przystępnym – rozwiązują wiele problemów jednocześnie., Dokumentują oczekiwania Klientów, zapewniają perspektywę użytkownika końcowego, wyjaśniają wymagania i zapobiegają niejednoznaczności, a ostatecznie pomagają w kontroli jakości, czy cele rozwojowe zostały osiągnięte. Niezależnie od tego, czy używasz metod zwinnych, czy nie, wybierz najlepszy format lub eksperymentuj z własnymi. Różne rodzaje user stories i ostatecznie funkcje mogą wymagać różnych Odat i testowanie nowych, które działają dla Ciebie, jest dobrą praktyką.