Kryteria akceptacji User Story mogą się wydawać dość łatwe do określenia. Jednak w procesie tworzenia produktów cyfrowych znaczną część problemów obejmują kwestie komunikacji.
W szczególności, gdy mamy na myśli spełnianie wymogów, rozstrzyganie, czy dany fragment pracy, dana funkcjonalność jest już ukończona.
Chęć uniknięcia chaosu, nieporozumień, konfliktów w praktyce oznacza po prostu konieczność przekazywania informacji, idei, wartości, pomysłów, planów w sposób możliwie komunikatywny.
Wyrażenie oczekiwań, formułowanych względem aplikacji mobilnych, aplikacji webowych, dowolnego oprogramowania to jeden problem.
Kolejnym są klarowne kryteria akceptacji, które znacząco pomagają trafnie i wyczerpująco określić oczekiwania klienta, użytkowników wobec produktu cyfrowego.
W metodykach zwinnych kryteria akceptacji User Story pełnią ważną rolę i koniecznie należy im poświęcić odpowiednią ilość czasu, dzięki czemu płynność, wydajność, bezbłędność pracy jest o wiele większa.
Warto pamiętać, że kryteria ogólne, zbyt abstrakcyjne są po prostu bezużyteczne. Stąd też User Story - historyjki użytkownika - oraz kryteria akceptacji User Story pozwalają nadać ogólnym oczekiwaniom - np. chcemy, by produkt był niesamowity - bardziej wymierne, konkretne formy.
Czym jest User Story? W jaki sposób napisać User Story? Jaką rolę w metodykach zwinnych pełni User Story?
W jaki sposób określać kryteria akceptacji? Czym jest definicja ukończenia?
Jeśli chcecie poznać, jak unikać, a właściwie pozbywać się z projektu niepewności, szkodliwych dwuznaczności oraz jak jasno formułować konkretne kryteria akceptacji dla historyjek użytkownika koniecznie przeczytajcie poniższy artykuł.
Serdecznie zapraszamy do lektury!
Co to jest User Story?
Bardzo dobrą definicję User Story, User Stories, opowieści użytkownika, historii, historyjek użytkownika znajdziemy w artykule pt. “Historyjki użytkowników z przykładami i szablonem”, z którym można się zapoznać na blogu Atlassian.
Max Rehkopf, który jest jego autorem, definiuje User Stories jako: “nieformalne, ogólne objaśnienie funkcji oprogramowania napisane z perspektywy użytkownika końcowego”.
Jego zdaniem User Story służy przede wszystkim do “określenia, w jaki sposób dana funkcja oprogramowania przyniesie klientowi korzyści”.
Dobrym uzupełnieniem powyższej definicji są uwagi poczynione w artykule pt. “What is User Story?”, który opublikowano na blogu Visual Paradigm.
Autorzy związani z Visual Paradigm zauważają, że w tworzeniu oprogramowania i zarządzaniu produktem historyjka użytkownika jest narzędziem, które pozwala uchwycić sens, istotę, clue danej funkcji z perspektywy użytkownika końcowego.
User Story pozwala określić, opowiedzieć:
- czego chce użytkownik
- dlaczego tego chce użytkownik.
Ponadto, stanowią uproszczony opis wymagań, jakie ma użytkownik.
Patrząc na historyjki użytkownika z jeszcze innej strony trzeba podkreślić, że User Stories nie można mylić z przypadkami użycia (Use Case).
Wprawdzie w Use Case i User Story chodzi o zdefiniowanie, określenie, wydobycie, przekazanie wymagań użytkowników, przede wszystkim tego, co użytkownicy będą mogli zrobić za pomocą systemu, ale nie są to narzędzia tożsame.
Historyjki użytkownika są pochodną przypadków użycia. Więcej i podobieństwach i różnicach między tymi narzędziami znajdziecie w artykule pt. “User Story vs Use Case”.
Nie wchodząc w szczegóły powiedzmy tylko, że User Story są bardziej szczegółowo określonymi wymaganiami, jakie względem systemu - np. aplikacji webowej - formułuje użytkownik.
Przykładowo, jeśli przypadek użycia brzmi następująco:
“Sklep internetowy - dodaj produkt do ulubionych”.
To User Story stworzone na podstawie takiego przypadku użycia brzmieć będzie następująco:
“Jako klient sklepu internetowego chcę mieć możliwość dodawania produktów do list produktów ulubionych, dzięki czemu będę miał łatwy do nich dostęp i będę szybciej mógł dokonać zakupu produktu w przyszłości”.
Ogólna matryca pozwalająca zdefiniować historyjki użytkownika przybiera postać:
“Jako (dany typ użytkownika) chcę (wykonać pewne działanie), aby (osiągnąć jakiś cel / uzyskać jakiś wynik / urzeczywistnić wartość)”.
User Story. będąc bardziej szczegółowym wariantem Use Case. nie tylko wskazuje cel, ale także określa motywację, powód, korzyść, plany, możliwości, jakie korzystanie z danej funkcjonalności daje użytkownikowi.
User Stories w praktyce są pisane przez różnych interesariuszy, takich jak klienci lub członkowie zespołów projektowych, programistycznych.
W metodykach zwinnych User Story pozwala:
- odkryć potrzeby użytkownika końcowego
- zdefiniować wymagania w Backlogu Produktu
- zrozumieć intencje użytkownika końcowego
- zaoferować adekwatną, pożądaną funkcjonalność, która jest użyteczna z punktu widzenia użytkownika końcowego.
Głównym celem, jaki chce się osiągnąć za pomocą User Story jest zdefiniowanie i wyjaśnienie ról, jakie użytkownicy pełnią w danym systemie.
User Stories pozwalają także określić, jakie działania - z punktu widzenia użytkownika końcowego - są pożądane.
Historyjki użytkownika pozwalają także sprecyzować cele - określić, co użytkownicy końcowi chcą osiągnąć oraz przede wszystkim dookreślić, co powoduje, że dane działanie jest uznawane za fortunne, pomyślne, satysfakcjonujące.
Mówiąc bardziej ogólnym językiem w metodykach zwinnych historyjki użytkownika stanowią podstawową metodę identyfikacji realnych - nie postulowanych, czy wyobrażonych - potrzeb użytkowników.
Jak pisać dobre User Story?
Pisząc User Story warto korzystać z różnych szablonów oraz technik.
Takich, jak najbardziej popularna metoda, w której historyjka użytkownika stanowi odpowiedź na trzy najbardziej podstawowe pytania:
- Who? - kto wchodzi w interakcję z systemem, w jakiej roli
- What? - czego użytkownik oczekuje od systemu
- Why? - dlaczego użytkownik wchodzi w interakcję, jakich spodziewa się korzyści, efektów.
Pierwsze pytanie o podmiot służy także do określenia roli, jaką pełni użytkownik w systemie.
Drugie pytanie odnosi się do zachowania się systemu, sposobu działania, akcji użytkownika i reakcji systemu.
Trzecie pytanie pozwala określić realne korzyści, wyniki, które są niefunkcjonalne lub zewnętrzne w stosunku do systemu.
Pisząc User Stories należy także:
- konkretnie zdefiniować kiedy historyjka jest gotowa, kiedy konkretne zadanie się kończy, po spełnieniu jakich kryteriów
- uporządkować zadania według kryterium ich ważności, dzieląc je na zadania główne oraz podrzędne
- wykorzystywać Persony użytkowników - User Stories powinny brać pod uwagę różnice, jakie wynikają z różnych grup użytkowników, z różnych Person
- pisać historyjki biorąc pod uwagę, w jakim stadium procesu jest użytkownik, jakiemu etapowi procesu odpowiada historyjka
- myśleć o ich złożoności, możliwości ich ukończenia w ramach jednego Sprintu.
Warto również mieć na uwadze, że istnieje cykl życia User Stories. Historyjki użytkownika przechodzą przez sześć stanów, stadiów w ramach procesu tworzenia produktu cyfrowego.
Cykl życia historii użytkownika obejmuje stan:
- Oczekujące (Pending)
- Do Zrobienia (To-do)
- Dyskutowane (Discussing)
- Rozwijane (Developing)
- Potwierdzane (Confirming)
- Zakończone (Finished).
W każdym z tych stanów, stadiów User Story przyjmuje nieco inną formę, cechuje się różnym poziomem konkretności, szczegółowości. Jest wynikiem także zróżnicowanej świadomości zespołu.
Historyjki użytkownika Oczekujące zawierają jedynie krótki, niekonkretny opis potrzeb użytkownika. Historyjka wymaga dyskusji oraz uznania jej ważności, która będzie możliwa, gdy zostaną choćby wstępnie określone wymagania wobec systemu, jego podstawowa logika.
Historyjki użytkownika Do Zrobienia to historyjki, które przeszły wstępną weryfikację i w wyniku równie wstępnej dyskusji zostały stworzone listy historyjek potencjalnie ważnych.
Historyjki użytkownika Dyskutowane to historyjki, w których określa się wymagania w sposób o wiele bardziej szczegółowy.
Historyjki użytkownika Rozwijane to historyjki, w których wdrożono większość oczekiwań użytkowników.
Historyjki użytkownika Potwierdzane to historyjki zaimplementowane w środowisku testowym w celu potwierdzenia funkcji.
Historyjki użytkownika Skończone to historyjki, które uważa się za ukończone.
Skuteczność pisania User Story zależna jest także od tego, czy zespół piszący je:
- konsekwentnie przyjmuje perspektywę użytkownika końcowego - co do zasady, jeśli osoby piszące User Story nie wiedzą kim są użytkownicy, dlaczego mieliby korzystać z produktu cyfrowego, nie powinny pisać historyjek, bowiem efekt będzie raczej przypuszczeniem, hipotezą, wyobrażeniem, a nie realnym oddaniem potrzeb, celów oraz motywacji
- korzysta z Person, by lepiej zrozumieć potrzeby i oczekiwania różnych użytkowników końcowych
- konsekwentnie będzie pisał proste i zwięzłe User Stories, które są łatwe do zrozumienia i nie stawiają wielkich wymagań w kwestii ich zrozumiałości
- będzie konsekwentnie stratyfikował User Stories - tworzył historie ogólne (Epic Stories) i na ich podstawie coraz bardziej szczegółowe, które łatwiej przełożyć na konkretne zadania, określone w czasie
- uwzględni czytelny, konkretny zestaw kryteriów akceptacji User Story w procesie podziału Epic Stories na User Stories
- zapewni ich odpowiednią widoczność, dostępność oraz komunikatywność, tak, by każdy członek zespołu miał do nich łatwy, niemal bezpośredni dostęp oraz by uzyskać szerszą perspektywę (Big Picture).
Co to są kryteria akceptacji User Story?
Historyjki użytkowników stanowią ważny element metodyk zwinnych i wyznaczają ramy dla codziennej pracy zespołów developerskich.
By prace przebiegały w sposób możliwie najbardziej płynny, wydajny konieczne jest jednoznaczne określenie, kiedy, po spełnieniu jakich warunków można daną historyjkę uznać za zakończoną. Do tego celu służą właśnie kryteria akceptacji User Story.
Pozwalają one uzgodnić, zsynchronizować wyobrażenia o danej funkcjonalności, o danym User Story interesariuszy oraz zespołu programistów.
Dzięki kryteriom akceptacji User Story developerzy wiedzą, jak zachować się powinien system, dana funkcja, by można jej działanie uznać za prawidłowe z punktu widzenia oczekiwań.
Kryteria akceptacji - definicje ukończenia - User Story to zestaw wymagań, jakie muszą być spełnione, aby można było uznać daną historyjkę za ukończoną.
Wymagania odnoszą się do zakresu, kontekstu oraz warunków, jakie musi spełnić oprogramowanie - najczęściej jego fragment - by mogło zostać zaakceptowane przez użytkownika i/lub interesariusza.
Użyteczność kryteriów akceptacji User Story wyraża się przede wszystkim w ich:
- testowalności, która powinna pozwalać rozstrzygać jednoznacznie, czy uzyskany wynik oznacza / nie oznacza akceptacji
- jasności, niemal oczywistości
- zwięzłości
- prostocie
- zrozumiałości
- sfokusowaniu na użytkowniku, jego perspektywie, jego potrzebach, jego celach
- realizmie - powinny wyrażać autentyczne doświadczenie użytkownika.
Kryteria akceptacji User Story, które posiadają powyższe cechy w sposób wymierny pomagają zespołom programistycznym rozumieć, jakie produkt mają tworzyć.
Ich zaletą jest przede wszystkim redukcja niepewności, niejasności, błędów, nieporozumień, nieadekwatności.
Kryteria akceptacji User Story pozwalają:
- osiągnąć większą jednoznaczność w kwestii oczekiwań
- zminimalizować ryzyko rozumienia oczekiwań w zróżnicowany sposób
- wydobyć, dookreślić wizję klienta, użytkownika
- zapanować nad interpretacjami, rozbieżnościami
- określić granice
- rozstrzygać, kiedy aplikacja działa zgodnie z oczekiwaniami
- uwspólniać perspektywę klienta oraz zespołu developerskiego - obie strony znają warunki, oczekiwania, wiedzą, jak tworzyć i oceniać działanie danej funkcjonalności aplikacji
- testować działanie systemu
- planować zadania
- przeciwdziałać zjawisku pełzania zakresów, a więc sytuacji, w której brak zdefiniowanych zakresów, kryteriów powoduje, że historyjka jest podatna na zmiany, co wpływa na harmonogram prac, budżet, płynność, wydajność pracy oraz atmosferę panującą w zespole
- unikać błędów, niepowodzeń, błędnych wyobrażeń
- usprawnić komunikację – zespół i interesariusze mogą poświęcić znacznie mniej czasu na wzajemne zrozumienie się.
Kryteria akceptacji User Story występują najczęściej w dwóch podstawowych wariantach, formatach:
- kryteria zorientowane na reguły (szablon listy kontrolnej)
- kryteria zorientowane na scenariusze (szablon Given / When / Then - Dane / Kiedy / Wtedy)
Format kryteriów akceptacji User Story w formacie zorientowanym na scenariusz przyjmuje postać sekwencji:
- Biorąc pod uwagę pewne warunki wstępne
- Kiedy wykonuję jakąś akcję
- Wtedy oczekuję jakiegoś rezultatu.
Ten rodzaj scenariusza - ze względu na swój przyczynowo-skutkowy charakter - pozwala w zbierać wymagania, przewidywać różnego rodzaju przypadki użycia oraz wykonywać automatyczne testy akceptacyjne.
Walorem tego scenariusza jest także skrócenie czasu koniecznego na pisanie przypadków testowych.
Z kolei szablon listy kontrolnej najczęściej przyjmuje formułę, która funkcjonuje pod akronimem INVEST.
INVEST to lista kontrolna (lista, zbiór kryteriów) służąca do oceny jakości historyjki użytkownika.
W tej formule dobra historyjka użytkownika powinna być:
- I – Independent - niezależna od innych User Story
- N – Negotiable - negocjowalna, powinna otwierać rozmowę nie ją zamykać, dopóki stanowi ona część Backlogu, dopóty może być modyfikowana, ukonkretniana
- V – Valuable - wartościowa z perspektywy użytkownika, powinna oferować użytkownikowi jakąś wartość
- E – Estimable - możliwa do oszacowania, tylko w takiej formule można ją podzielić na zadania, a więc zaplanować w czasie
- S – Small - mała - jej realizacja powinna być możliwa do wykonania w możliwie najkrótszym czasie
- T – Testable - testowalna, a więc powinna skutkować jednoznacznym rozstrzygnięciem - Skończona / Nie skończona.
Tworząc kryteria akceptacji User Stories należy posługiwać się kryteriami:
- zrozumiałymi, realistycznymi oraz osiąganymi
- podzielanymi przez wszystkich (developerów oraz interesariuszy) - a więc wynikającymi z konsensusu
- mierzalnymi - pozwalającymi szacować czas.
Podsumowując: pisanie kryteriów akceptacji User Story ma na celu dostarczenie zespołowi konkretnego zakresu prac przed ich rozpoczęciem. Zespół powinien wiedzieć, co ma zbudować.
Ponadto, pozwala wypracować wspólną platformę rozumienia potrzeb, celów, problemów. Równie istotnym celem jest możliwość weryfikacji historii za pomocą automatycznych testów.
Kto pisze kryteria akceptacji User Story?
Najlepsze efekty w przypadku tworzenia kryteriów akceptacji User Story przynosi wspólna praca - klienta / interesariuszy oraz zespołu developerskiego.
Proces tworzenia kryteriów akceptacji powinien być pracą zespołową. Z biznesowego punktu widzenia oraz czysto projektowego.
Kryteria opisują potrzeby użytkowników, dlatego przygotowane kryteria akceptacji projektu powinny bazować na Personach i powinny powstać przed rozpoczęciem prac programistycznych.
Z pewnością takie podejście pozwala o wiele szybciej:
- osiągnąć cel
- konfrontować warunki możliwości (np. czy nie istnieją ograniczenia technologiczne)
- uzyskiwać konsensus np. między perspektywą, jaką reprezentuje Product Owner i pozostali interesariusze
- uzgadniać perspektywy
- planować pracę
- tworzyć dokumentację projektową.
Po stronie wykonawcy najczęściej do pisania kryteriów akceptacji User Story oddelegowani są analityk wymagań i/lub kierownik projektu.
Ale warto pamiętać, że nie ma żadnych przeciwwskazań, by w prace tego rodzaju angażowali się pozostali członkowie zespołu - cały zespół programistyczny.
Tym bardziej, że rekomendowanym wzorcem osiągania pożądanego efektu jest praca zespołowa, praca grupowa.
Głównie oparta na dialogu, który pozwala lepiej sondować potrzeby, wyłapywać niuanse, doprecyzowywać oczekiwania.
Co to jest definicja ukończenia (Definition of Done - DoD)?
Rozstrzygnięcie, czy dana funkcjonalność jest gotowa / zrobiona jest być może jedną z trudniejszych kwestii, jakie napotykają zespoły tworzące produkty cyfrowe w zwinnych metodykach.
Od definicji ukończenia zależy:
- jakość produktu cyfrowego
- doskonałość produktu cyfrowego
- jego konkurencyjność
- użyteczność
- bezbłędność działania
- doświadczenie użytkownika - User Experience.
Definicję ukończenia definiuje się najczęściej jako sytuację, w której zostały spełnione wszystkie warunki lub kryteria akceptacji User Stories, które produkt cyfrowy powinien spełnić.
Dana funkcjonalność jest ukończone, jeśli spełnia kryteria akceptacji i jest gotowa do weryfikacji, akceptacji przez użytkowników, interesariuszy.
Zgodnie z inną definicją, która stanowi uzupełnienie powyższej, definicja ukończenia to lista wymagań, które musi spełnić historyjka użytkownika, aby zespół deweloperski, zespół programistów, interesarusze uznali ją za ukończoną.
Różnica między zestawem kryteriów akceptacji User Story a definicją ukończenia jest taka oto, że kryteria akceptacji historyjek użytkownika odnoszą się do każdej historyjki z osobna, a definicja ukończenia jest wspólna dla wszystkich historyjek użytkownika.
Aby ukończyć daną historyjkę użytkownika, muszą zostać spełnione zarówno kryteria określone w definicji ukończenia, jak również kryteria akceptacji User Story.
A mówiąc bardziej szczegółowo, by User Story można uznać jako ukończoną w metodyce Agile konieczne jest m.in.:
- spełnienie wszystkich kryteriów akceptacji
- zaakceptowanie historyjki przez Product Ownera
- wdrożenie historyjki użytkownika w środowisku produkcyjnym
- pomyślne przetestowanie historyjki
- pomyślne przejście testów funkcjonalnych
- pomyślne spełnianie wymogów niefunkcjonalnych.
Do opracowania definicji ukończenia pomocne jest sformułowanie odpowiedzi na poniższe pytania:
- Czy kod został ukończony?
- Czy kod został sprawdzony?
- Czy testy jednostkowe zostały zaliczone?
- Czy testy funkcjonalne zostały zdane?
- Czy testy akceptacyjne zostały zakończone?
User Story. Kryteria akceptacji Scrum. Podsumowanie
- Kryteria akceptacji procesu, kryteria akceptacji projektu, kryteria akceptacji User Story tylko pozornie wydają się proste do określenia.
- User Stories to nieformalne, ogólne objaśnienie funkcji oprogramowania napisane z perspektywy użytkownika końcowego.
- User Story służy przede wszystkim do określenia, w jaki sposób dana funkcja oprogramowania przyniesie klientowi korzyści.
- Ogólna matryca pozwalająca zdefiniować historyjki użytkownika przybiera postać: Jako (dany typ użytkownika) chcę (wykonać pewne działanie), aby (osiągnąć jakiś cel / uzyskać jakiś wynik / urzeczywistnić wartość).
- User Story. będąc bardziej szczegółowym wariantem Use Case. nie tylko wskazuje cel, ale także określa motywację, korzyść, możliwości, jakie korzystanie z danej funkcjonalności daje użytkownikowi.
- W metodykach zwinnych historyjki użytkownika stanowią podstawową metodę identyfikacji realnych potrzeb użytkowników.
- Szczegółowe kryteria powinny powodować zrozumienie celu, powinny sprawiać, że developerzy od samego początku wiedzą, jak zachować się powinien system, dana funkcja, by można jej działanie uznać za prawidłowe z punktu widzenia oczekiwań.
- W Scrum, w projektach IT kryteria akceptacji User Story, kryteria akceptacji testów to zestaw wymagań, jakie muszą być spełnione, aby można było uznać daną historyjkę za ukończoną.
- Dzięki czemu można uniknąć nieporozumień już na etapie tworzenia, dzięki czemu po implementacji historyjki nie będzie ona wymagała niezbędnych poprawek, a produkt końcowy pozwoli osiągnąć użytkownikowi jego główne cele.
- Szczegółowe kryteria akceptacji User Story najlepiej, jeśli powstają jako wspólna praca - klienta / interesariuszy oraz zespołu developerskiego
- Aby ukończyć daną historyjkę użytkownika, muszą zostać spełnione zarówno kryteria określone w definicji ukończenia, jak również kryteria akceptacji User Story.
