w Mobindustry działamy w sposób zwinny. Oznacza to, że używamy zwinnych komponentów, takich jak historie użytkowników i kryteria akceptacji. Wysokowydajne zespoły i organizacje mają te komponenty w swoich listach produktów i wiedzą, jak je tworzyć i efektywnie z nich korzystać.
Jeśli w Twoim portfolio produktów brakuje historii użytkowników i kryteriów akceptacji — lub jeśli nie są one jasno określone — ryzykujesz, że Twoje oczekiwania nie będą zbieżne z rzeczywistością., Historie użytkowników i kryteria akceptacji są odpowiedzialne za przedstawienie, w jaki sposób użytkownik końcowy będzie korzystać z aplikacji i jak Twój zespół programistów powinien wykonać każde zadanie programistyczne. Kiedy rozpoczynamy pracę nad nowym produktem, nasz zespół współpracuje z klientem, aby zdefiniować historie użytkowników.
user story to krótki, prosty opis funkcji produktu z perspektywy osoby, która chce z niej korzystać. Historie użytkowników są używane do definiowania zaległości produktu w zwinnym przepływie pracy programistycznej.,
product backlog jest zasadniczo zbiorem historii użytkownika, który informuje o specyfikacji funkcjonalnej i rozwoju funkcji dla konkretnego produktu lub usługi. Historie użytkownika składają się z trzech części: osoby użytkownika, dla której historia jest pisana, opisu funkcji, której użytkownik wymaga, i wyjaśnienia potrzeby, którą funkcja spełnia.
oto jak napisać historię użytkownika:
jako (użytkownik) chcę (funkcja), aby móc (zaspokoić potrzebę).
przyjrzyjmy się, jak może wyglądać Historia użytkownika., Weźmiemy Airbnb jako przykład. Wyobraźmy sobie, jak może wyglądać typowa historia użytkownika dla produktu takiego jak Airbnb.
„jako użytkownik chcę wyszukać miejsce docelowe, aby móc zarezerwować nocleg w obcym mieście.”
definicja kryteriów akceptacji
teraz musimy upewnić się, że historie użytkowników są poprawnie wypełnione i spełniają wymagania klienta.
kryteria akceptacji to warunki, które musi spełniać oprogramowanie, aby zostało zaakceptowane przez Użytkownika, Klienta lub, w przypadku funkcjonalności na poziomie systemu, przez zużywający się system.,
kryteria akceptacji są zestawem instrukcji, z których każda ma wyraźny wynik pass/fail, które można zmierzyć i określić zarówno wymagania funkcjonalne, jak i niefunkcjonalne.
pisanie kryteriów akceptacji jest ważne nie tylko dla ustalenia, czego klient oczekuje od produktu, ale dla procesu rozwoju. Oczywiście, różni ludzie widzą ten sam problem z różnych stron. Dobrze zdefiniowane kryteria akceptacji zapewniają jednolity widok funkcjonalności, którą planujesz wdrożyć.,
każdy powinien być w stanie podejść do tablicy Scrum, pobrać element zaległości produktu, przeczytać kryteria akceptacji i wyraźnie zobaczyć wszystko, co musi zostać wypełnione, aby dany element został przeniesiony do kolumny gotowe. Kryteria akceptacji mówią, co należy zrobić, aby dana część produktu została ukończona.
rozwój aplikacji mobilnych i internetowych
planujesz rozszerzyć swoją działalność w Internecie? Przełożymy Twoje pomysły na inteligentne i wydajne rozwiązania.
Dlaczego potrzebujemy kryteriów akceptacji?,
- Definiowanie granic. Kryteria akceptacji pomagają zespołowi programistów określić granice historii użytkownika. Służą one jako forma potwierdzenia, że aplikacja działa zgodnie z oczekiwaniami, co oznacza, że historia użytkownika jest kompletna.
- osiąganie konsensusu. Kryteria akceptacji pozwalają Zespołowi Deweloperskiemu być na tej samej stronie co klient. Informują one zespół programistów o tym, jakie dokładnie warunki muszą być spełnione i zapewniają, że klient wie, czego można oczekiwać od aplikacji.
- , Kryteria akceptacji są podstawą testów akceptacji user story. Każde kryterium akceptacji powinno być testowane niezależnie i mieć jasne scenariusze sukcesu lub porażki.
- planowanie i szacowanie. Kryteria akceptacji pozwalają na dystrybucję historii użytkowników między zadaniami, dzięki czemu są one odpowiednio oceniane i zaplanowane.
- opisujące negatywne scenariusze. Kryteria akceptacji mogą wymagać, aby system zidentyfikował słabe hasło i uniemożliwił użytkownikowi kontynuowanie, na przykład., Wprowadzenie nieprawidłowego formatu hasła jest przykładem negatywnego scenariusza, w którym użytkownik wprowadza nieprawidłowe dane lub nieoczekiwanie zachowuje się. Kryteria akceptacji określają te scenariusze i wyjaśniają, w jaki sposób system powinien na nie reagować.
chcesz napisać niefunkcjonalne i funkcjonalne wymagania dla Twojego projektu oprogramowania? W tym artykule przedstawiamy przykładowe i najlepsze praktyki wymagań funkcjonalnych i niefunkcjonalnych
kto pisze kryteria akceptacji?,
pisanie kryteriów akceptacji pomaga ustalić wspólne zrozumienie między product ownerem a zespołem programistów w odniesieniu do rozwiązania problemu klienta lub tworzenia możliwości produktu. Ponieważ kryteria akceptacji odnoszą się do klienta i zespołu, powinny być napisane przez Klienta lub członka zespołu.
w Mobindustry nasi analitycy biznesowi piszą wszystkie kryteria akceptacji dla historii użytkowników. Analitycy biznesowi rozumieją potrzeby klienta i to, co deweloperzy muszą wiedzieć, aby spełnić wymagania projektu.,
kryteria akceptacji są dokumentowane i potwierdzane przed rozpoczęciem projektu, ponieważ zespół i klient muszą uzgodnić, jakie wyniki będą spełniać wymagania klienta.
rozwój aplikacji mobilnych i internetowych
planujesz rozszerzyć swoją działalność w Internecie? Przełożymy Twoje pomysły na inteligentne i wydajne rozwiązania.
przykłady historii użytkowników z kryteriami akceptacji
teraz, gdy masz jasne zrozumienie, czym są historie użytkowników i kryteria akceptacji, rzućmy okiem na kilka przykładów.,
przykład 1
User story: jako użytkownik chcę mieć możliwość rejestracji w serwisie, aby móc rozpocząć zakupy online.
kryteria akceptacji:
- użytkownicy mogą przesłać formularz tylko poprzez wypełnienie wszystkich wymaganych pól.
- e-mail podany przez użytkownika nie może być dostarczany przez bezpłatną usługę poczty e-mail.
- zgłoszenia z tego samego IP można składać tylko trzy razy w ciągu 30 minut.
- użytkownicy otrzymują powiadomienia e-mail po pomyślnej rejestracji.,
przykład 2
User story: jako użytkownik mogę uzyskać dostęp do powiadomienia na moim urządzeniu natychmiast po jego otrzymaniu.
kryteria akceptacji:
- przesuwanie / stukanie powiadomienia przenosi użytkownika bezpośrednio do wiadomości.
- widok pokazuje rozmowę-jeśli nowa wiadomość była odpowiedzią, to jest wyświetlana nad oryginałem.
- liczba wiadomości jest aktualizowana.
- wiadomość jest oznaczona jako przeczytana po wyświetleniu.
7 wskazówek dotyczących pisania dobrych kryteriów akceptacji
kryteria akceptacji NIE są łatwe do napisania., Pomimo prostego formatu, pisanie tekstu jest wyzwaniem. Oto siedem wskazówek, które pomogą Ci uniknąć typowych błędów podczas pisania kryteriów akceptacji lub sprawdzenia kryteriów napisanych przez członka Twojego zespołu.
- dokumentuj kryteria przed rozpoczęciem procesu tworzenia. W ten sposób zespół jest bardziej prawdopodobne, aby złapać wszystkie potrzeby klienta z wyprzedzeniem. Początkowo wystarczy ustawić kryteria dla niewielkiej liczby historii użytkowników, aby zakończyć zaległości dla dwóch sprintów. Udokumentowane kryteria akceptacji są następnie wykorzystywane przez programistów do planowania procesu technicznego.,
- nie zawężaj kryteriów akceptacji. Kryteria akceptacji, które są zbyt szczegółowe, pozostawiają deweloperom mało miejsca do manewrowania. Aby tego uniknąć, pamiętaj, że kryteria akceptacji powinny być wyrazem intencji, a nie ostateczną decyzją. Ponadto wąskie kryteria akceptacji mogą nie uwzględniać wszystkich działań użytkownika.
- Zachowaj swoje kryteria. Skuteczne kryteria akceptacji określają rozsądną minimalną liczbę funkcji, które możesz zapewnić. Ale jeśli nadal będziesz opisywać wszystkie szczegóły, istnieje ryzyko, że twój zespół utknie w setkach małych zadań.,
- unikaj zbyt szerokich kryteriów akceptacji. 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ć swoje wysiłki.
- unikaj szczegółów technicznych. Kryteria akceptacji powinny być napisane prostym językiem. Twoi interesariusze i menedżerowie mogą nie mieć zaplecza technicznego, więc użycie prostego języka sprawi, że kryteria będą zrozumiałe dla wszystkich.
- Osiągnij konsensus., Ten sam problem może być rozwiązany na różne sposoby przez członków zespołu i interesariuszy w zależności od ich punktu widzenia. Upewnij się, że przekazujesz swoje kryteria akceptacji interesariuszom i członkom zespołu i osiągniesz wzajemne porozumienie.
- napisz testowalne kryteria akceptacji. Da to testerom możliwość upewnienia się, że wszystkie wymagania są spełnione i pozwoli programistom dowiedzieć się, czy historia użytkownika jest kompletna.,
Dowiedz się, jak sprawdzić, czy twój zleceniodawca jest wiarygodny
jak napisać kryteria akceptacji
Oto pięć ogólnych zasad, które pomogą Ci rozwiązać problemy z sformułowaniem kryteriów akceptacji. Zasady te pozwolą Ci zaoszczędzić cenny czas i ustalić porozumienie między product ownerem a zespołem programistów.
reguła #1: unikaj „nie”
„nie” oznacza „w żadnym wypadku”, a zatem żadna ilość czasu nie będzie wystarczająca, aby zweryfikować zgodność z takim warunkiem., Jeśli przepisasz wymóg bez użycia „nie”, będzie to jaśniejsze i, co najważniejsze, możliwe do zweryfikowania.
przykład:
Historia użytkownika
nie: jako użytkownik nie chcę wprowadzać hasła za każdym razem, gdy uzyskuję dostęp do konta.
Do: jako użytkownik chcę, aby moje hasło zostało zapamiętane i automatycznie wypełnione, aby uzyskać dostęp do konta bez ponownego wprowadzania hasła.
kryteria akceptacji
nie: system nie może zawieść.
Do: dostępność systemu powinna wynosić nie mniej niż 90%.,
wyjątek
Możesz użyć „Nie” w kryteriach akceptacji, aby wprowadzić logiczny sprzeciw, taki jak „formularz logowania nie powinien być czerwony.”W większości przypadków będzie to miało zastosowanie do wymogów niefunkcjonalnych. W tym przykładzie sformułujemy ograniczenie, które można łatwo zweryfikować, jeśli zakres odcieni czerwieni jest jasno określony (na przykład określony w formacie RGB).,
Dowiedz się, jak zoptymalizowaliśmy wrażenia klienta za pomocą aplikacji mobilnej
reguła #2: Użyj aktywnego głosu
aktywny głos jest wtedy, gdy podmiot w zdaniu jest wykonawcą akcji. Jeśli podmiot odpowiedzialny za wykonanie czynności nie zostanie wyraźnie wskazany, nie będzie jasne, kto lub co powinien wykonać czynność i trudniej będzie zweryfikować, czy wymóg został spełniony.,
przykład:
User story
nie: jako kupujący online chcę, aby filtry były stosowane, aby móc znaleźć to, czego chcę.
Do: jako użytkownik chcę zastosować filtry wyszukiwania, aby móc znaleźć pozycje.
kryteria akceptacji
nie: należy potwierdzić tożsamość klienta. (Nie jest jasne, kto lub co jest odpowiedzialne za potwierdzenie tożsamości klienta.)
Do: Accounting_System powinien potwierdzić Customer_Indentity. (Należy pamiętać, że definicje terminów „Accounting_System” i „Customer_Indentity” powinny zostać dodane do glosariusza.,)
rozwój aplikacji mobilnych i internetowych
planujesz rozwinąć swoją działalność w Internecie? Przełożymy Twoje pomysły na inteligentne i wydajne rozwiązania.
reguła #3: Unikaj używania zaimków (zwłaszcza niezdefiniowanych)
używaj rzeczowników zamiast zaimków, gdy odwołujesz się do elementów wymienionych w innych wymaganiach. Należy unikać zaimków, ponieważ mogą one wprowadzać niejednoznaczność.,
jest to szczególnie ważne, gdy kryteria akceptacji są przechowywane w narzędziach zarządzania wymaganiami (takich jak Jira) jako oddzielne instrukcje, które niekoniecznie są zorganizowane. Zawsze używaj rzeczowników zamiast zaimków, a unikniesz tego problemu.
przykład:
user story
Don ' t: jako członek witryny chcę dzielić się informacjami o sobie, aby inni mogli je zobaczyć.
Do: jako członek serwisu chcę dodać opis profilu, aby inni mogli się o mnie dowiedzieć.
kryteria akceptacji
nie: Kontroler powinien wysłać kierowcy plan podróży na dany dzień., Powinien być dostarczony co najmniej 8 godzin przed zmianą.
Do: sterownik powinien wysłać Driver_Itinerary dla danego dnia do kierowcy co najmniej 8 godzin przed Driver_Shift.
jak zarządzać zdalnymi zespołami, najlepsze praktyki. Mobindustry dzieli się swoim doświadczeniem jako firma outsourcingowa
reguła #4: unikaj spójników
spójniki to słowa i wyrażenia, takie jak „i”, „lub”, „ale” i „jak również”, które łączą proste zdania w złożone., Ich użycie w wymaganiach jest zwykle znakiem, że wymóg można podzielić na kilka oddzielnych wymagań.
przykład:
User story
nie: jako projektant interfejsu użytkownika chcę utworzyć i wyświetlić problem, aby wiedzieć, co przetestować.
Do: jako projektant UI chcę stworzyć problem, aby wiedzieć, co przetestować. / Jako projektant UI chcę zobaczyć problem, żebym wiedział, co przetestować.
kryteria akceptacji
nie: użytkownikowi należy ufać lub nie.
Do: Security_System powinien kategoryzować każdego użytkownika jako zaufanego lub nie zaufanego.,
wyjątek
„And,” „or,” and „not” może być użyty do opisania warunków logicznych i dodania kwalifikatorów.
rozwój aplikacji mobilnych i internetowych
planujesz rozszerzyć swoją działalność w Internecie? Przełożymy Twoje pomysły na inteligentne i wydajne rozwiązania.
reguła #5: unikaj nieosiągalnych absolutów
Absolut (taki jak 100% dostępności) jest nieosiągalny. Zastanów się, jak sprawdzić wskaźnik: czy będzie można udowodnić, że poziom dostępności systemu wynosi dokładnie 100%?, A nawet jeśli taki system mógłby zostać stworzony, czy stać Cię na to?
unikaj słów „wszystko”, „zawsze” i „nigdy”, ponieważ sprawdzenie takich bezwzględnych wymagań będzie wymagało nieskończonej liczby testów.
przykład:
User story
Don ' t: jako podróżnik chcę znać dokładną lokalizację, aktualizowaną w czasie rzeczywistym, aby się nie zgubić. („Czas rzeczywisty” można interpretować na różne sposoby. Na przykład może być postrzegana jako absolutna (brak jakiegokolwiek opóźnienia), której nie można osiągnąć i która nie jest weryfikowalna.,)
Do: jako podróżnik chcę znać swoją dokładną lokalizację, aktualizowaną co sekundę, aby się nie zgubić.
kryteria akceptacji
nie: system powinien mieć 100% dostępności. (100% jest absolutem, którego nie można osiągnąć i którego nie można zweryfikować.)
Do: dostępność systemu powinna wynosić co najmniej 98%.
Szybkie podsumowanie kryteriów akceptacji
mamy nadzieję, że ten artykuł rzuca światło na świat kryteriów akceptacji i historii użytkowników., Oto najważniejsze wnioski:
- kryteria akceptacji to warunki, które musi spełniać oprogramowanie, aby zostało zaakceptowane przez Użytkownika, Klienta lub, w przypadku funkcjonalności na poziomie systemu, przez zużywający się system.
- kryteria akceptacji powinny być udokumentowane i wypełnione przed rozpoczęciem projektu, ponieważ zespół i klient muszą uzgodnić, jakie wyniki będą spełniać wymagania klienta.
- pamiętaj, że kryteria akceptacji powinny być wyrazem intencji, a nie ostateczną decyzją.
- skuteczne kryteria akceptacji określają rozsądną minimalną ilość funkcjonalności.,
- dobre kryteria akceptacji muszą nakreślić zakres prac, aby deweloperzy mogli prawidłowo zaplanować i oszacować swoje wysiłki.
- kryteria akceptacji powinny być napisane prostym językiem.
- upewnij się, że przekazujesz swoje kryteria akceptacji interesariuszom i członkom zespołu i osiągniesz wzajemne porozumienie.
- pisząc kryteria akceptacji, unikaj używania” nie”, spójników i nieosiągalnych absolutów. Formułuj zdania za pomocą aktywnego głosu.,
Jeśli chcesz stworzyć kryteria akceptacji i historie użytkowników dla swojej aplikacji mobilnej lub jeśli masz jakiekolwiek pytania dotyczące tego tematu, skontaktuj się z Mobindustry, aby uzyskać bezpłatną konsultację.
rozwój aplikacji mobilnych i internetowych
planujesz rozszerzyć swoją działalność w Internecie? Przełożymy Twoje pomysły na inteligentne i wydajne rozwiązania.