User Story – jak zapisywać wymagania użytkownika
Historyjki Użytkownika (ang. User Stories), to koncepcja wprowadzona przez twórców zwinnej metody XP (Extreme Programming). Kent Beck i Martin Fowler zaproponowali ją w swojej książce „Planning Extreme Programming”:
Historyjka jest jednostką funkcjonalności w projektach XP. Pokazujemy postęp prac, dostarczając przetestowany i zintegrowany kod, który składa się na implementację danej historyjki. Historyjka powinna być zrozumiała i wartościowa dla klientów, testowalna przez programistów i na tyle mała, żeby programiści mogli zaimplementować sześć historyjek w trakcie jednej iteracji.
K. Beck, M. Fowler
Tradycyjnie historyjki użytkownika przypominają trochę fiszki w katalogu bibliotecznym. Przyjmują formę kartonika lub kartki papieru, na których zapisany zwięzły opis funkcjonalności, użytecznej dla określonego użytkownika systemu.
JAKO… CHCĘ… ABY…
Jednym z najpopularniejszych wzorców zapisu historyjek jest: JAKO…CHCĘ…ABY…
Jako <rodzaj użytkownika> chcę <wykonać zadanie>, aby <osiągnąć cel>.
Tak zdefiniowana historyjka odpowiada na kilka pytań:
– Kto jest użytkownikiem? (Komu potrzebne jest to rozwiązanie? Kogo dotyczy ma problem? Kim jest nasz użytkownik?)
– Co trzeba zrobić? (Co chcemy dostarczyć? W jaki sposób rozwiążemy problem? Jak zweryfikujemy naszą hipotezę?)
– Dlaczego jest mu to potrzebne. (Dlaczego to robimy? Jaki problem chcemy rozwiązać? Jaką mamy hipotezę? Jaką możliwość próbujemy wykorzystać?)
CCC
Agile wprowadza koncepcję historyjki użytkownika aby zapewnić łatwy i szybki sposób zapisu wymagań użytkownika. Rozwiązanie to przypomina również o konieczności konwersacji – rozmowie na temat potrzeb użytkownika, aby je zrozumiał cały zespół. Historie użytkownika są dość dobrze wyjaśnione poprzez 3K (ang. 3C):
– Karta (ang. Card) – zapisane na niewielkiej kartce (7,5 x 12,5 cm) przy pomocy flamastra. Zawoeta lakoniczny opis funkcjonalności. Mała kartka nie zmieści pełnej specyfikacji wymagań. Dlatego zachęca do – Konwersacji.
– Konwersacja (ang. Conversation) – ponieważ historyjki są niejednoznaczne – zmuszają do konwersacji. Zespoły często wskazują, że obszar, który wymaga najwięcej poprawek – to obszar komunikacji. Właścicel Produktu często spotyka sięz zespołem aby porozmawiać o najdrobniejszych nawet szczegółach związanych z realizacją konkretnej funkcjonalności. Szczegóły realizacji mieszczą się w trzecim K.
– Konfirmacja (ang. Confirmation) – zamiast bez końca powtarzać kolejne konwersacje, zespoły zwinne ustalają szczegóły historyjek użytkownika, zapisując je jako kryteria akceptacyjne. Stanowią one warunek aby uznać historyjkę za zaakceptowaną. Właściciel Produktu reprezentujący interesariuszy uważa je za niezbędne minimum. Dlatego dobrą praktyką jest ograniczenie kryteriów akceptacyjnych do odwrotnej strony kartki z historyjką. Jeżeli jest na niej zbyt mało miejsca – warto rozważyć podzielenie historyjki na kilka mniejszych.
INVEST
Bill Wake w swojej książce Extreme Programming Explored podał dla User Stories przydatny mnemonik: „INVEST”:
– Independent (niezależna)
Łatwiej pracuje się z historyjkami, które są niezależne, nie nakładają się pod względem pomysłu i gdy chcemy zaplanować ich wykonanie, nie musimy przejmować się ich kolejnością.
– Negotiable (negocjowalna)
Dobrze dobrana historyjka jest negocjowalna. Nie jest zamkniętym tworem, ale może być uzgadniana z klientem na bieżąco podczas realizacji. Dobra historyjka skupia się na istocie a nie szczegółach i może być uzupełniana o notatki, pomysły testów (ale nie jest to niezbędne na etapie ustalania priorytetu i szacowania złożoności).
– Valuable (wartościowa)
Historyjka powinna nieść wartość – wartość nie dla byle kogo, a dla klienta/użytkownika. Deweloperzy mogą podnosić niektóre kwestie, ale należy je tak formułować, aby były istotne dla końcowego użytkownika.
– Estimable (oszacowana)
Prawidłowo zapisaną historyjkę użytkownika powinno dać się oszacować. Ale ostateczne szacowanie nie jest niezbędne. Za to powinno być na tyle szczegółowe, by pomóc klientowi ustalić kolejność i harmonogram implementacji. W związku z tym, że szacowalność jest zależna od negocjowalności, przed oszacowaniem należy zrozumieć, co jest do zrobienia. Większe historyjki trudno jest oszacować i wówczas zwykle warto je podzielić na mniejsze. Umiejętność szacowania będzie wzrastać wraz z rosnącym doświadczeniem zespołu.
– Small (mała)
Dobre historyjki zazwyczaj są małe, powinny dać się zrealizować podczas pojedynczego sprintu. Mniejsze historyjki daje się bardziej precyzyjnie oszacować.
– Testable (testowalna)
Dobra historyjka jest testowalna. Powinna być na tyle zrozumiała, aby móc napisać dla niej test. Takie podejście wspiera test driven development.
DEEP
Innym akronimem dla historyjek użytkownika jest DEEP (wprowadzony przez Romana Pichlera i stosowany przez Mike’a Cohna:
– Detailed Enough – z wystarczająco określonymi szczegółowymi kryteriami akceptacyjnymi aby zacząć.
– Emergent – backlog produktu nigdy nie jest kompletny, ale rozrasta się w miarę jego doskonalenia z upływem czasu.
– Estimated Relatively – względne oszacowanie pozwala określić rozmiary pod względem wysiłku realizacyjnego.
– Prioritized Ordered – uporządkowane priorytetowo według wartości, ryzyka, kosztu, zależności itp.
Literatura:
K. Beck, M. Fowler, „Planning Extreme Programming”, Addison-Wesley, Boston 2000, s. 42
Ł. Bręk, https://bialko.eu/agile/zrodla-wymagan/
M. Cohn https://www.mountaingoatsoftware.com/blog/make-the-product-backlog-deep
M. Chrapko,”Scrum. O zwinnym zarządzaniu projektami”, Helion, Gliwice 2015, s. 150-168
J. Szczepanik, J.Wieczorek, https://porzadnyagile.pl/047-definition-of-ready/
W. C. Wake, „Extreme Programming Explored”, Boston, Addison-Wesley, 2002
T. Wykowski, https://procognita.pl/post/user-stories-czyli-historie-uzytkownika-84
T. Wykowski, https://procognita.pl/post/3-sposoby-zeby-zrozumiec-twoich-uzytkownikow-442
T.Wykowski, „Biznes odczarowany”, ProCognita, Kraków 2019, s 126-127
D. McGreal, R. Jocham, „Profesjonalny Właściciel Produktu. Jak Scrum zwiększa przewagę konkurencyjną”, APN Promise, Warszawa 2019, s. 197-212