Co to jest User Story i kryteria akceptacji (przykłady)

doskonały przewodnik po kryteriach akceptacji User Story z rzeczywistymi scenariuszami:

w branży tworzenia Oprogramowania SŁOWO „Wymaganie” określa nasz cel, czego dokładnie potrzebują klienci i co sprawi, że nasza firma zwiększy swoją działalność.

niezależnie od tego, czy jest to firma produkująca oprogramowanie, czy firma usługowa oferująca usługi w różnych dziedzinach oprogramowania, podstawową bazą dla wszystkich z nich jest wymóg, a sukces jest definiowany przez to, jak dobrze wymagania są spełnione.,

termin „wymaganie” ma różne nazwy w różnych metodologiach projektów.

w Waterfall jest określany jako „dokument wymagań/specyfikacji”, w Agile lub SCRUM jest określany jako „Epic”, „User Story”.

w modelu Waterfall dokumenty wymagań są ogromne dokumenty 200 lub więcej stron, ponieważ cały produkt jest realizowany w jednej fazie. Ale tak nie jest w przypadku Agile/SCRUM, ponieważ w tych metodologiach wymagania są podane dla małych funkcjonalności lub cech, ponieważ produkt jest przygotowywany krok po kroku.,

w tym artykule starałem się jak najlepiej podzielić moim 4-letnim doświadczeniem w pracy z historiami użytkowników i powiązanymi z nimi kryteriami akceptacji oraz łatwymi i prostymi scenariuszami życia rzeczywistego dla lepszego zrozumienia.

najpierw odwiedźmy podstawy.

Co to jest User Story?

User story jest wymogiem dla każdej funkcjonalności lub funkcji, która jest zapisana w jednej lub dwóch linijkach i maksymalnie do 5 linijek. Historia użytkownika jest zwykle najprostszym możliwym wymogiem i dotyczy jednej i TYLKO JEDNEJ funkcjonalności (lub jednej funkcji).,

najczęściej używany standardowy format tworzenia historii użytkownika jest podany poniżej:

jako <rola użytkownika/klienta, chcę < cel do osiągnięcia> tak, że mogę <powód celu>.

przykład:

jako użytkownik WhatsApp chcę mieć ikonę aparatu w polu zapisu czatu, aby przechwytywać i wysyłać zdjęcia, dzięki czemu mogę klikać i udostępniać moje zdjęcia jednocześnie wszystkim znajomym.

Co to jest kryterium akceptacji?,

kryterium akceptacji to zbiór przyjętych warunków lub reguł biznesowych, które funkcjonalność lub cecha powinna spełniać i spełniać, aby została zaakceptowana przez Właściciela Produktu/interesariuszy.

jest to bardzo ważna część user story completion i powinna być dokładnie zbadana przez Product Ownera i analityka biznesowego, ponieważ brak jednego kryterium może wiele kosztować. Jest to prosta lista numerowana lub punktowana.

jego format jest następujący:

„biorąc pod uwagę pewien warunek wstępny, gdy wykonuję jakąś akcję, oczekuję wyniku”.

przykład (w.r.,t do powyższej historii użytkownika):

• rozważmy, że rozmawiam z przyjacielem i powinienem być w stanie uchwycić zdjęcie.
• Po kliknięciu na zdjęcie, przed wysłaniem powinno być możliwe dodanie podpisu do zdjęcia.
• Jeśli Jest jakiś problem z uruchomieniem aparatu w telefonie, komunikat o błędzie, taki jak „nie można uruchomić aparatu”. itd., powinny być odpowiednio wykazane.

dlatego Historia użytkownika definiuje wymóg dla dowolnej funkcjonalności lub funkcji, podczas gdy kryteria akceptacji definiują „definicję wykonanej” dla historii użytkownika lub wymogu.,

jako QA bardzo ważne jest dogłębne zrozumienie historii użytkownika i jego kryteriów akceptacji, bez żadnej wątpliwości pozostającej na „początku testowania”. Idąc dalej, zrozummy, dlaczego niezwykle ważne jest, aby zagłębić się w historie użytkowników i kryteria akceptacji.

kopanie głęboko w User stories

na początek, pozwól nam najpierw zrozumieć znaczenie „dogłębne” badania podstawowej i fundamentalnej rzeczy, tj. User Stories.

poniższe przypadki są moimi prawdziwymi doświadczeniami.,

Przypadek #1:

przed 3 laty pracowałem nad projektem aplikacji mobilnej, a produkt był aplikacją przeznaczoną dla osób dostarczających.

widziałbyś dostawcę, który przychodzi do ciebie po dostawę. I mają telefon komórkowy, na którym proszą cię o złożenie podpisu po dostarczeniu. Ten podpis odzwierciedla się na portalu dostawców usług kurierskich, takich jak DTDC, FedEx itp.

wyobraźmy sobie, że aplikacja mobilna dopiero się Uruchamia, a ich portale już istnieją i działają.,

Problem: w przypadku Sprintu Właściciel Produktu ma historię użytkownika dla tej aplikacji mobilnej ,że „jako administrator portalu powinienem być w stanie wyświetlić podpis pobrany przez dostawcę w momencie dostawy”. Tutaj portal (aplikacja internetowa) jest odpowiednio zmieniany i aktualizowany w celu odzwierciedlenia podpisu.

jako QA musisz zweryfikować, czy podpis przechwycony w aplikacji mobilnej odzwierciedla się zgodnie z oczekiwaniami w portalu.,

Jeśli spojrzysz na tę historię użytkownika, wygląda to prosto, ale jest tu ukryty wymóg, że ” dla historycznych dostaw nie było funkcji odbicia podpisu, więc co powinno się stać, jeśli faceci z portalu oglądają historyczne dostawy?”Czy dane historyczne powinny zostać wymazane? Czy powinniśmy zezwolić na awarie lub błędy takich danych?

oczywiście, że nie, to powinno być traktowane łaskawie.,

rozwiązanie: gdy odpowiednie tabele DB są aktualizowane, aby dodać nową kolumnę dla lokalizacji podpisu, stare dane powinny mieć wartość NULL lub 0, która powinna być sprawdzona i powinien być wyświetlony komunikat „no signature exists”.

można to nazwać pominięciem Product Ownera lub analityka biznesowego, ale trzeba to zrobić. Wdrożenie jednej funkcji z powodzeniem, ale łamanie czegoś wraz z nią nie jest pożądane przez klientów. Należy to zrobić wraz z tą samą historią użytkownika i w tym samym sprincie.,

Przypadek #2

6 lat temu pracowałem nad aplikacją do planowania emerytalnego (bez BA), która była globalną aplikacją, w której ludzie finansowi, tacy jak CA, Doradcy Finansowi, mogli używać jej dla różnych walut do projektowania planów inwestycyjnych, oszczędności itp., w dużym okresie do swoich klientów.

Problem: Właściciel Produktu podaje historię użytkownika, że „jako doradca chcę przeglądać raport mojego klienta na podstawie podanych danych finansowych”.,

tutaj były 2 ukryte wymagania i nazwałbym to niekompletną historią, ponieważ:

a] raporty powinny uwzględniać dzienny kurs wymiany waluty, a nie Historyczny, jak w ostatnim oglądanym raporcie i

b] Jeśli waluta zostanie zmieniona po podaniu danych finansowych klienta, raporty powinny pokazywać się w zmienionej walucie.

rozwiązanie: zwróciłem się z tym problemem bezpośrednio do naszego Product Ownera i uświadomiłem mu, że oba muszą zostać wykonane jak najszybciej. Zgodził się ze mną i stworzył 2 różne historie na nadchodzące sprinty z priorytetem.,

Take Away: te zostały złapane, ponieważ wszyscy byliśmy bardzo dobrze świadomi produktów, ich projektu, struktury itp. Taką wiedzę można osiągnąć tylko poprzez całkowite zrozumienie produktu, zrozumienie współdziałania modułów i dokładne przestudiowanie historii użytkownika, nawet jeśli jest to Wkładka 2.

Rób notatki, aby ułatwić sprawy i dyskutuj z BA i deweloperami o ich myśleniu.,

szczegółowe spojrzenie na kryteria akceptacji

zrozumienie kryteriów akceptacji i wszystkich innych warunków& Zasady wyczerpująco jest jeszcze ważniejsze niż zaniżenie historii użytkownika. Ponieważ jeśli wymóg jest niekompletny lub niejasny, można go podjąć w następnym sprincie, ale jeśli kryterium akceptacji zostanie pominięte, to sama historia użytkownika nie może zostać wydana.

chyba wszyscy kiedyś skorzystalibyśmy z bankowości internetowej.większość z nas korzysta z niej na co dzień, a ja często ściągam swoje wypowiedzi historyczne., Jeśli obserwujesz go uważnie, istnieją pewne konkretne opcje dostępne do ich pobrania.

istnieje opcja wyboru typu pliku do pobrania wyciągu. Istnieje możliwość wyboru, czy chcesz pobrać tylko kredyty / Debet /oba.

teraz wyobraź sobie, że Product Owner daje Ci tę historię użytkownika „jako klient Chcę pobrać wyciąg z konta, aby móc przeglądać wszystkie moje transakcje wykonane przez określony okres”.,

z następującymi kryteriami akceptacji:

• biorąc pod uwagę, że jestem na stronie pobierania Oświadczenia Historycznego, powinienem wybrać okres, dla którego chcę pobrać oświadczenie.
• biorąc pod uwagę, że jestem na stronie pobierania Oświadczenia Historycznego, powinienem wybrać konto, dla którego chcę pobrać oświadczenie.
• biorąc pod uwagę, że jestem na stronie pobierania Oświadczenia Historycznego, nie powinienem mieć prawa do pobierania oświadczenia na przyszłość „do” daty.,
• biorąc pod uwagę, że pobieram moje oświadczenie, powinienem być w stanie wyświetlić pobrany plik.
• biorąc pod uwagę, że jestem na stronie Pobierz oświadczenie historyczne, powinienem być w stanie pobrać moje oświadczenie w formatach doc, excel i pdf.

Jeśli przejdziesz przez tę akceptację, brakuje tu 3 rzeczy:

• nazwa i format nazwy pliku, który zostanie pobrany.,
• jakie informacje (nazwy kolumn) mają być wyświetlane w pliku.
• lista opcji, aby wybrać, jakiego rodzaju transakcję klient chce, tj. tylko obciążenia lub tylko kredyty lub oba.

takie przypadki mogą się zdarzyć raz na jakiś czas, Jednak nadal dobrze Studiuj każde kryterium akceptacji i staraj się je wizualizować w odniesieniu do historii użytkownika. Im więcej dokładnie studiujesz na temat warunków i zasad biznesowych, tym więcej będziesz mieć wiedzy na temat tej funkcji.

błędy znalezione w początkowej fazie nic nie kosztują w porównaniu do tego, ile mogą kosztować na etapie 'testowania'.,

Znaczenie znajdowania rozbieżności w historii użytkowników/kryteriach akceptacji

zawsze ważne jest, aby dogłębnie przeanalizować historie użytkowników i kryteria akceptacji na wczesnym etapie, nawet przed rozpoczęciem opracowywania lub testowania.

ponieważ wiąże się to z:

#1) strata czasu:

Jeśli rozbieżności lub błędy w historii użytkownika/kryteria akceptacji zostaną znalezione podczas opracowywania lub testowania, to może być konieczne wiele przeróbek w pozostałym czasie sprintu.,

nie zdarza się, że nawet jeśli Product Owner pominął kilka rzeczy, przeniesie historię użytkownika do nadchodzącego sprintu. 95% szans jest, że poproszą zespół o wykonanie niezbędnej implementacji i wydanie go w tym samym sprincie.

dlatego staje się koszmarem dla zespołu, ponieważ muszą spędzać dodatkowy czas, przychodzić w weekendy lub pracować do późna w nocy. Można tego uniknąć, studiując i omawiając historię użytkownika / kryteria akceptacji na najwcześniejszym możliwym etapie.

#2) marnotrawstwo wysiłków:

Programiści i QA muszą ponownie przejrzeć zaimplementowany kod i ponownie przetestować przypadki., Aktualizacja, dodawanie i usuwanie jako wymaganie nie jest łatwym zadaniem. Staje się zbyt bolesne, ponieważ istnieje już presja, aby dostarczyć na czas.

w takiej sytuacji są szanse na błędy na etapie rozwoju lub testowania. Jeśli natkniesz się na taką sytuację, wybierz „DevQA Pairing”. Jako wisienka na torcie, możesz nie dostać odszkodowania za dodatkową pracę.

wnioski

głębokie zrozumienie historii użytkownika i kryteriów akceptacji można osiągnąć tylko przez poświęcenie ogromnego czasu na jej studiowanie.,

na rynku nie ma konkretnego narzędzia lub kursu, który by to zrobił, ponieważ chodzi o logiczne myślenie, doświadczenie i wiedzę na temat produktu.

aktywny udział w spotkaniu Pre-plan, rozmowa z BA, nauka na własną rękę może tylko pomóc ci to osiągnąć. Im więcej wysiłku włożysz, tym więcej się uczysz i rozwijasz.

niezależnie od tego, czy chodzi o QA, czy deweloperów, każdy musi być na tej samej stronie o historiach użytkowników i ich kryteriach akceptacji, tylko wtedy oczekiwania klienta mogą być skutecznie osiągnięte.,

masz coś nowego do podzielenia się z nami swoimi doświadczeniami w pracy z User Stories? Proszę wyrazić swoje myśli poniżej!!