Ile razy widziałeś, jak deweloperzy i testerzy spierają się o to, jak powinna działać dana funkcja? A co z zdezorientowanymi minami deweloperów, którzy nie byli pewni, jak zbudować zamówioną przez Ciebie funkcję? Oba problemy są dość powszechne w świecie oprogramowania i na szczęście masz w swoim arsenale potężne narzędzie, które pozwala je rozwiązać — kryteria akceptacji.
W tym przewodniku omówię naturę tego formatu zapisywania wymagań, wyjaśnię ich rolę w zarządzaniu produktem oraz pokażę Ci, jak pisać świetne kryteria akceptacji.
Spis treści
Jaki jest cel pisania kryteriów akceptacji?
Jak powinny wyglądać dobrze napisane kryteria akceptacji?
Popularne formaty kryteriów akceptacji
Czym są kryteria akceptacji
(i jakie jest ich miejsce w Agile/Scrum?)
W metodyce Agile kryterium akceptacji jest najmniejszą jednostką wymagania funkcjonalnego lub projektowego, którą menedżerowie produktu Agile (lub analitycy biznesowi) dodają do swoich historyjek, aby jasno komunikować różne stany i zachowanie funkcji, którą zespół planuje zbudować.
Technicznie rzecz biorąc, możesz używać kryteriów akceptacji wszędzie, gdzie chcesz. Tradycyjnie są one jednak częścią historyjek użytkownika, które stanowią elementy epik Agile.
Aby lepiej zrozumieć kryteria akceptacji, najpierw odświeżmy sobie pamięć, przeanalizujmy elementy tej hierarchii i zobaczmy, do czego służy każdy z nich.
Epiki
Epiki to zadania zawierające wysokopoziomowe wymagania funkcjonalne i niefunkcjonalne dotyczące dużej funkcji lub grupy powiązanych ze sobą funkcji. Zwykle epik obejmuje cały przypadek użycia klientów i zawiera wszystkie funkcje oraz elementy funkcjonalne, które należy zaimplementować, aby obsłużyć dany przypadek użycia.
Wyobraź sobie, że należysz do zespołu produktowego Spotify i chcesz rozszerzyć wykorzystanie aplikacji, dodając nowy przypadek użycia dla osób będących w drodze, które nie mają dostępu do internetu.
Aby obsłużyć ten przypadek użycia, możesz rozważyć dodanie nowej dużej funkcji o nazwie „tryb offline Spotify”, która może stać się epikiem w backlogu produktu, zawierającym wszystkie ogólne wymagania umożliwiające użytkownikom słuchanie muzyki poza zasięgiem sieci, a także kilka historyjek użytkownika z wymaganiami dotyczącymi konkretnych części tej funkcji.
Historyjki użytkownika
Historyjki użytkownika są mniejsze i przedstawiają pojedynczy, odrębny element funkcjonalności w ramach epiku. Są to niewielkie części pracy, które zespół Agile może zobowiązać się dostarczyć w ramach jednej iteracji.
Jedną z kluczowych cech historyjki użytkownika jest to, że reprezentowana przez nią funkcjonalność powinna być kompletna i potencjalnie użyteczna.
Na przykład, jeśli tworzysz aplikację do przechowywania plików online i chcesz umożliwić użytkownikom zmianę nazw przesłanych plików, będziesz musiał wykonać pracę po stronie interfejsu użytkownika (interfejs i doświadczenie użytkownika związane ze zmianą nazwy) oraz po stronie zaplecza (przechowywanie nowej nazwy).
Aby funkcja była kompletna i użyteczna, musisz ukończyć oba zadania oraz połączyć ze sobą części interfejsu użytkownika i zaplecza. Twój zespół wykonałby całość w ramach jednej historyjki użytkownika.
Gdybyś wykonał tylko pracę po stronie zaplecza, zadanie to nie byłoby prawidłową historyjką, ponieważ zawierałoby rezultat, który nie jest kompletny ani użyteczny.
Aby poinformować zespół deweloperski o tym, jak będzie wyglądać funkcja i jak powinna działać, właściciele produktu piszą kryteria akceptacji dla danej historyjki.
Have an account? Log In
Kryteria akceptacji historyjki użytkownika
Na końcu mamy najmniejsze elementy hierarchii wymagań dotyczących produktu programistycznego — kryteria akceptacji. Reprezentują one poszczególne scenariusze użycia danej funkcjonalności lub informacje, które zespół inżynieryjny uzna za ważne podczas implementacji historyjki.
W powyższym przykładzie kryterium akceptacji byłoby otwarcie pola tekstowego z automatycznie wpisaną nazwą pliku, jeśli użytkownik kliknie przycisk ✏️Zmień nazwę przy przesłanym pliku.
Definicja ukończenia (tak, różni się od kryteriów akceptacji!)
Czasami właściciele produktu (zwłaszcza ci, którzy są stosunkowo nowi w tej roli w Scrumie) mylą definicję ukończenia z kryteriami akceptacji.
Szczerze mówiąc, na początku dla mnie również było to dość mylące, ponieważ oba pojęcia oznaczają „kryteria sprawdzania, czy funkcja jest ukończona”.
Jedyna różnica polega na tym, że definicja ukończenia oznacza kompletność w kontekście procesów deweloperskich zespołu.
Natomiast kryteria akceptacji reprezentują wymagania funkcjonalne (czyli to, jak funkcja powinna wyglądać i działać).
Oznacza to, że definicja ukończenia pozostanie taka sama dla wszystkich historyjek implementowanych przez zespół, chyba że podczas retrospektyw zespół zdecyduje się ją zmienić. Z drugiej strony kryteria akceptacji są unikalne dla każdej historyjki, ponieważ wyjaśniają sposób działania danej funkcji.
Uwaga: Niektóre narzędzia do zarządzania produktem pozwalają umieścić w historyjkach zarówno definicję ukończenia, jak i kryteria akceptacji.
Skoro przypomnieliśmy sobie, czym są epiki i historyjki oraz jak odnoszą się do nich kryteria akceptacji, przejdźmy do zrozumienia, dlaczego właściciele produktu w ogóle spisują kryteria akceptacji.
Jaki jest cel spisywania kryteriów akceptacji?
Czy mogę po prostu napisać opis historyjki użytkownika tak, jak chcę, bez uwzględniania w nim żadnych kryteriów akceptacji? Jaka właściwie jest korzyść ze spisywania kryteriów akceptacji?
Oczywiście możesz pisać swoje historyjki tak, jak chcesz. Zalecam jednak używanie kryteriów akceptacji jako sposobu formułowania wymagań, ponieważ ten format ma wiele zalet. Oto kilka z nich, które warto rozważyć.
Sprzyjają myśleniu skoncentrowanemu na zachowaniu
Jeśli wybierzesz format BDD dla kryteriów akceptacji (więcej na ten temat później), kryteria akceptacji będą opisywać ścieżkę klientów podczas korzystania z danej funkcji.
Piękno tego podejścia polega na tym, że odchodzisz od myślenia o suchych wymaganiach technicznych i zaczynasz patrzeć na funkcję z perspektywy użytkownika. W ten sposób możesz zobrazować sobie, czego użytkownik doświadcza i co czuje podczas korzystania z funkcji.
Dość często właściciel produktu zdaje sobie sprawę, że zaplanowana przez niego funkcjonalność nie jest najlepsza, gdy spojrzy na nią z perspektywy użytkowników.
Mi również wielokrotnie się to zdarzało. Na przykład, gdy tworzyłem wymagania dotyczące edytora formuł matematycznych (był on częścią tworzonego przez nas wówczas produktu SaaS do analizy finansowej), chciałem, aby proces edycji wyglądał następująco:
- Przycisk edycji obok formuły.
- Po kliknięciu przycisku edycji pole formuły stawałoby się edytowalne i wyświetlałoby przyciski ✅ Zapisz oraz ❎ Anuluj .
- Po kliknięciu dowolnego z nich tryb edycji byłby zamykany, a w tym miejscu pojawiałaby się nowa, zapisana wersja formuły albo jej stara wersja — zależnie od wyboru użytkownika.
To zachowanie wygląda logicznie, prawda?
Cóż, nie do końca — dopiero gdy zacząłem spisywać scenariusze korzystania z edytora przez analityków, znalazłem poważną wadę użyteczności. Analitycy zazwyczaj eksperymentują z formułą, wprowadzając w niej drobne zmiany i obserwując wynik obliczeń, aż uzyskają pożądaną formułę.
Zaplanowany przeze mnie sposób edycji byłby wyjątkowo uciążliwy dla docelowych użytkowników, ponieważ musieliby 20–30 razy z rzędu wchodzić w tryb edycji i z niego wychodzić. Dlatego gdy tylko zdałem sobie sprawę z tego błędu, szybko zmieniłem kryteria akceptacji i zleciłem stworzenie edytora formuł, w którym można byłoby wprowadzać zmiany w czasie rzeczywistym.
Pomagają stworzyć jedno źródło prawdy
Jako „młody” menedżer produktu największą trudnością było dla mnie przekazywanie wymagań dotyczących produktu osobom wykonującym różne zawody, a nawet pracującym w różnych zespołach. Problem polegał na tym, że każda z tych osób rozumiała wymagania inaczej, a komunikacja między nimi stawała się niejasnym chaosem.
Wtedy doświadczony menedżer produktu zasugerował, abym zastosował koncepcję jednego źródła prawdy poprzez bardzo jasne formułowanie wymagań dotyczących produktu (może w tym pomóc również AI w zbieraniu wymagań), przekazywanie ich wszystkim oraz proszenie wszystkich o opieranie swojej pracy wyłącznie na tym, co zostało tam zapisane.
Był to ogromny sukces, ponieważ wszyscy tak samo rozumieli, jak powinna działać funkcja, a w przypadku nieporozumień wracali do wymagań.
Kryteria akceptacji to świetny sposób na stworzenie jednego źródła prawdy, ponieważ opisują funkcję w jasny i łatwy do odczytania sposób oraz charakteryzują się wysokim poziomem szczegółowości (ponieważ powinny obejmować wszystkie najważniejsze szczegóły funkcji).
Poprawiają jakość testów akceptacyjnych
Dla inżynierów oprogramowania kryteria akceptacji stanowią wymagania dotyczące produktu, których będą przestrzegać podczas tworzenia funkcji. Z kolei dla zespołu ds. jakości kryteria akceptacji mają kilka dodatkowych zastosowań:
Pomagają ustalać priorytety przypadków testowych. Jeśli zespół testów oprogramowania ma wiele przypadków testowych dla danej funkcji, a czasu nie wystarcza na przejrzenie ich wszystkich, najpierw ustali priorytety i uruchomi scenariusze testowe zgodne z kryteriami akceptacji, ponieważ opisują one najważniejsze przepływy użytkownika.
Służą jako lista kontrolna akceptacji. Dotyczy to zarówno zespołów ds. zapewnienia jakości, jak i właścicieli produktu, którzy muszą zaakceptować funkcję. Kryteria akceptacji, zgodnie ze swoją nazwą, służą jako lista kontrolna do określenia, czy funkcja spełnia wymagania. Jeśli jedno lub więcej kryteriów akceptacji nie zostanie spełnionych, zespół ds. zapewnienia jakości ponownie otworzy zadanie i poprosi zespół inżynieryjny o dodanie brakującej funkcjonalności.
Podsumowując, kryteria akceptacji są nieocenionymi narzędziami w rękach właścicieli produktu, umożliwiającymi właściwe przekazywanie wymagań dotyczących produktu. Jak jednak pisać dobre kryteria akceptacji? Za chwilę Ci w tym pomogę.
Jak powinny wyglądać dobrze napisane kryteria akceptacji?
Jakość napisanych przez Ciebie kryteriów akceptacji będzie miała bezpośredni wpływ na jakość funkcji dostarczanych przez Twój zespół. Dzięki jasnemu zrozumieniu tego, co należy zbudować i jak to przetestować, Twój zespół stworzy funkcję zgodnie z Twoją wizją, przy minimalnej liczbie problemów.
Aby doskonalić się w pisaniu kryteriów akceptacji, musisz zwrócić uwagę na następujące kwestie.
Jasność
Grzechem numer jeden, który może popełnić właściciel produktu, jest pisanie niejasnych i ogólnikowych kryteriów akceptacji. Możesz zapomnieć o wspólnym zrozumieniu, jeśli ludzie mogą interpretować to, co napisałeś, na wiele sposobów.
Aby pokazać, jak duże ma to znaczenie, przedstawię Ci przykład.
Co zrozumiałeś z tego zdania? Czy możesz powiedzieć, w jaki sposób bankomat wykorzysta typ karty, aby zdecydować, czy uwierzytelnić użytkownika? Czy bankomat uwierzytelni użytkownika, jeśli wszystkie te kryteria zostaną spełnione jednocześnie, czy wystarczy spełnienie tylko jednego z nich?
Jeśli przekażesz to kryterium akceptacji swoim inżynierom, zasypią Cię pytaniami i poproszą o dokładniejsze określenie wymagań. Teraz je ulepszmy.
Wygląda znacznie lepiej, prawda? Dzięki temu kryterium akceptacji udzieliliśmy również odpowiedzi na wszystkie powyższe pytania. Bankomat musi obsługiwać typ karty włożonej przez użytkownika, a wszystkie trzy kryteria powinny zostać spełnione jednocześnie, aby bankomat przeprowadził uwierzytelnianie.
Wskazówka eksperta: Spraw, aby Twoje kryteria akceptacji były SMART (konkretne, mierzalne, osiągalne, istotne i testowalne). Tak, zmieniłem ostatnią cechę na testowalność, ponieważ jest ona ważną właściwością skutecznych kryteriów akceptacji.
Czytelność
Oprócz unikania niejasności w kryteriach akceptacji powinieneś również zachować prostotę i unikać wyszukanych terminów lub złożonego języka.
Jestem pewien, że masz zespół świetnie wykształconych gwiazd, które z łatwością przeczytają i zrozumieją najbardziej wyszukane i złożone słowa oraz zwroty w języku angielskim, ale przecież nie chcesz marnować ich zdolności poznawczych na rozszyfrowywanie swoich tekstów.
Dlatego zamiast tego.
Powiedz to tak.
Zakładam, że nawet nie zadałeś sobie trudu, aby w pełni przeczytać pierwsze kryterium akceptacji, ponieważ również nie chciałeś marnować swojego czasu i energii umysłowej!
Pokrycie przypadków
Diabeł tkwi w szczegółach. Czasami orientujesz się, że pominąłeś trudny przypadek w swojej funkcji dopiero na bardzo późnym etapie prac i musisz utworzyć dodatkowe zadanie dotyczące jego ulepszenia albo nawet przerobić całość.
Brzmi znajomo, prawda?
Im więcej przypadków uwzględnisz z wyprzedzeniem w kryteriach akceptacji, tym mniejsze prawdopodobieństwo, że spotkasz się z takim scenariuszem w elementach swojego backlogu.
Przyjrzyjmy się teraz poniższym kryteriom akceptacji.
Czy widzisz tu coś dziwnego? Na pierwszy rzut oka wymaganie jest jasne: dodajesz adres e-mail, klikasz przycisk wysyłania i dana osoba uzyskuje dostęp. W rzeczywistości nie uwzględniliśmy tu wielu przypadków:
- Jeśli adres e-mail znajduje się już na liście użytkowników, którzy mają dostęp do dokumentu, być może należy wyświetlić komunikat o błędzie informujący o tym użytkownika.
- Wyślesz użytkownikowi wiadomość e-mail z zaproszeniem, więc być może warto pokazywać na wspólnej liście, czy zaakceptował zaproszenie.
- Jeśli użytkownik nie zaakceptował zaproszenia, być może warto dodać przycisk „wyślij zaproszenie ponownie”.
Istnieją również przypadki negatywne, w których określasz zachowanie funkcji, gdy czegoś brakuje lub wystąpił błąd.
Aktywne korzystanie z pomocy wizualnych
Czy przedstawione przeze mnie powyżej kryteria akceptacji były dla Ciebie całkowicie jasne? Czy gdy wspomniałem o polu „Dodaj osoby i grupy”, dokładnie rozumiałeś, czego ono dotyczy?
Czasami same słowa nie wystarczą, aby zapewnić zespołowi jasność wymagań, dlatego lepiej je pokazać, niż tylko o nich mówić. Teraz pozwól, że nieco ulepszę te kryteria akceptacji.
Czy słusznie zakładam, że z łatwością zrozumiałbyś, o czym mówię w tych kryteriach akceptacji, gdybyś oglądał obraz i moje komentarze obok siebie? Założę się, że tak.
To wyczerpuje temat „kryteriów akceptacji” — omówmy teraz różne typy i formaty, których zespoły produktowe używają do ich tworzenia.
Popularne formaty kryteriów akceptacji
Muszę być z Tobą szczery. Rzadko używam tego samego formatu we wszystkich swoich historyjkach użytkownika. Powodem jest to, że różne formaty kryteriów akceptacji sprawdzają się w różnych przypadkach użycia i nie zawsze dobrym pomysłem jest zmuszanie się do korzystania zawsze z tego samego formatu.
Dlatego wybieram format na podstawie historyjki oraz rodzaju informacji, które chcę zawrzeć w jej kryteriach akceptacji.
Przyjrzyjmy się teraz niektórym popularnym formatom oraz odpowiadającym im przykładom kryteriów akceptacji.
Format BDD
BDD oznacza rozwój sterowany zachowaniem i jest metodyką, która zachęca członków zespołów programistycznych i produktowych do definiowania wymagań na podstawie sposobu, w jaki użytkownicy końcowi będą korzystać z funkcji.
Jako sposób zapisywania wymagań na podstawie zachowania użytkownika kryteria akceptacji BDD opierają się na następującym szablonie:
Zakładając: Warunek wstępny konkretnego scenariusza zachowania użytkownika.
Kiedy: Działanie podejmowane przez użytkownika.
Następnie: Wynik działania.
Jeśli więc chcesz wyjaśnić działanie funkcji wypłaty w bankomacie, Twoje kryteria akceptacji wyglądałyby tak:
Ten typ kryteriów akceptacji, oparty na schemacie zakładając/kiedy/następnie, sprawdza się doskonale, gdy chcesz wzbudzić w zespole empatię wobec potrzeb użytkowników, kładąc nacisk na perspektywę użytkownika.
More Articles
Format listy kontrolnej
W przeciwieństwie do BDD (czyli formatu „zorientowanego na scenariusz”) ten format nie przedstawia punktu widzenia użytkownika końcowego. Zamiast tego koncentruje się na wyjaśnieniu konkretnych zasad, których powinna przestrzegać logika biznesowa funkcji (alternatywna nazwa tego formatu to format „zorientowany na reguły”). Oto jak wygląda.
Ten format najlepiej sprawdzi się, gdy logika, którą chcesz wyjaśnić, jest złożona, ponieważ pomaga rozłożyć ją na wiele małych reguł, które są łatwiejsze do zrozumienia i wdrożenia.
Format przepływu
To prawdopodobnie format, którego używam najczęściej.
Format przepływu jest podobny do formatu BDD, ponieważ również przedstawia punkt widzenia użytkownika. Jednak w przeciwieństwie do BDD nie narzuca ścisłej struktury (Given/When/Then). Możesz więc opisać kroki podejmowane przez użytkownika w dowolny sposób.
Tak wyglądałby proces rejestracji w tym formacie.
Format przepływu będzie najlepszym rozwiązaniem, jeśli chcesz wzbudzić empatię wobec użytkownika (podobnie jak w przypadku BDD), ale nie chcesz stosować ścisłej struktury.
Zadbaj o wspólne rozumienie dzięki kryteriom akceptacji
Kryteria akceptacji to potężne narzędzia w rękach właścicieli produktu, które pozwalają im stworzyć jedno źródło prawdy i zadbać o to, by członkowie zespołu podążali w tym samym kierunku zgodnie z ich wizją danej funkcji.
Aby otrzymywać więcej poradników tego typu i innych wartościowych materiałów dla osób zajmujących się produktami, zapisz się do naszego newslettera!