User Story – choć przydatne, nie zawsze optymalne

User Story to pojęcie jednoznacznie związane ze zwinnymi metodykami wytwarzania oprogramowania. Gdy myślimy Scrum, zwykle na myśl przychodzą nam User Story i na odwrót.

Czym zatem jest User Story? Na pewno jest popularną i szeroko stosowaną techniką opisywania wymagań. Opisuje w krótkiej i zwięzłej formie to, co dany typ użytkownika (aktor) chce zrobić i po co. Skupia się zatem na dostarczanej wartości.

W języku polskim spotkać można również tłumaczenie nazwy tej techniki jako „Historyjka użytkownika”. Brzmi ono jednak na dość nienaturalnie, a oryginalna nazwa w języku angielskim jest na tyle szeroko używana, że pozostanę przy niej w dalszej części wpisu.

Bywa, że jako User Story, rozumiemy jedynie jego zasadniczą część, czyli tzw. „Statement of Value”. Jest to zdanie opisujące jaka wartość jest dostarczana, gdy konkretne story jest implementowane. Zajmijmy się najpierw tą własnie częścią.

Statement of Value

Zwykle „Statement of Value” opiera się na jednym z kilku szablonów. Chyba najpopularniejszy z nich to:

„As a <who?> I need to <what?>, so that <why?>.”

Po polsku brzmi to mniej więcej:

„Jako <kto?> chcę <co?>, po to aby <po co?>”

Mamy zatem konstrukcję składającą się z 3 elementów:

• Aktor <kto?> – Jest to wskazanie konkretnego typu użytkownika (konkretnego aktora wchodzącego w interakcje z systemem, np. Administrator, Klient, Dostawca etc.). Zwykle wyróżnić można różne grupy użytkowników korzystających z systemu w odrębnych celach, posiadających zazwyczaj odrębne uprawnienia.

• Czynność <co?> – Opis tego co dany aktor zamierza zrobić w systemie. Opis wykonywanej przez niego czynności.

• Wartość <po co?> – Ta część określa właściwie sens implementacji, gdyż mówi o dostarczanej wartości. Niestety często ten właśnie element nie jest prawidłowo opisywany lub jest pomijany. Według mnie stanowi to poważny problem gdyż tracimy z oczu wartość biznesową, jaka jest dostarczana, a to przecież ona jest najważniejsza.

Pozostałe elementy User Story

Inne elementy to:

• Tytuł – Traktowany jest jako opcjonalny. Zwykle krótko, w formie jednego zdania, wyraża cel danego User Story.

• Konwersacja – User Story należy traktować jedynie jako wstęp do dalszej dyskusji z zespołem projektowym i innymi interesariuszami oraz dalszych rozważań i związanego z nimi modelowania. Tego elementu nie należy traktować jako widoczny, zapisany fragment tekstu. To raczej podkreślenie faktu, że każde story wymaga odpowiedniego przedyskutowania.

• Kryteria akceptacji – Pomagają uszczegółowić User Story oraz pomóc wyznaczyć jego granicę. Stanowią listę warunków jakie muszą być spełnione, aby można było uznać, że zakładana wartość została dostarczona.

Czy User Story nadaje się do wszystkiego?

User Story jako narzędzie daje nam możliwość krótkiego i zwięzłego opisania potrzeby konkretnego użytkownika, którą możemy dodatkowo doprecyzować stosując kryteria akceptacji, a następnie poddać dalszej dyskusji i rozważaniom w celu stworzenia odpowiedniego rozwiązania. Brzmi dobrze, na tyle dobrze, że stosowanie tej techniki bywa często nadużywane.

Spotkałem się kiedyś z opinią, że Scrum nie uznaje dokumentacji, a jeśli już to jedyną dopuszczalną jej formą są właśnie User Story. Oczywiście jest to opinia absolutnie błędna. Gdy system, który tworzył mój zespół miał się integrować z systemem rozwijanym przez Jego zespół, poprosiłem go o przekazanie mi dokumentacji systemu, w celu zapoznania się z jego funkcjonalnością, udostępnianym interfejsem etc. W odpowiedzi otrzymałem listę 153 User Story dotyczących rozwijanego systemu… Oczywiście powstały one na przestrzeni kilku lat i te które powstały później modyfikowały funkcjonalność opisaną we wcześniejszych. Zatem stworzenie spójnej wizji systemu na podstawie przejrzenia przesłanej listy wydawało się zadaniem wybitnie niełatwym. Jest to dobitny przykład ukazujący na to, iż User Story, choć przydatne, nie nadają się do wszystkiego.

Do czego User Story się nadają?

Mówiąc krótko, do krótkoterminowego przechowywania wymagań ze zwróceniem szczególnej uwagi na dostarczaną wartość. Ponadto służą jako wstęp do dalszej dyskusji mającej na celu wypracowanie wspólnego zrozumienia zagadnienia i dalsze prace nad modelowaniem rozwiązania.

Co więcej, ze względu na swoją naturę pozwalającą na podział pracy na małe i zwięzłe funkcjonalności lub wymagania jakościowe, mogą być wykorzystywane do:

• Dyskutowania priorytetów
• Szacowania pracochłonności
• Planowania rozwoju produktu i jego wersji
• Mapowania wysokopoziomowych wymagań
• Projektowania testów akceptacyjnych
• Śledzenia i raportowania postępów pracy

Tylko tyle i aż tyle.

Do czego User Story się nie nadają?

Przede wszystkim nie nadają się do długoterminowego przechowywania wymagań. Nie nadają się do tworzenia przy ich pomocy dokumentacji służącej do rozwoju i utrzymania systemu lub produktu. Głównie ze względu na to, że ciężko tylko na ich podstawie, bez odpowiedniej dokumentacji wspomagającej, stworzyć obraz aktualnego stanu systemu.

Należy również pamiętać, że samo User Story, bez towarzyszącego mu kontekstu to zwykle dla zespołu deweloperskiego zbyt mało do tego, by mógł efektywnie pracować. Dla dobrego zrozumienia wprowadzanych zmian, ich celu i wpływu na poszczególne komponenty systemu, zespół powinien mieć szerszy kontekst. Można go zapewnić stosując dodatkowo inne techniki i formy dokumentacji.

Moje rekomendacje

• Używaj User Story zgodnie z przeznaczeniem, do krótkoterminowego dokumentowania wymagań.
• Traktuj je jako wstęp do dalszej dyskusji, a nie zdefiniowane i niepodlegające żadnym negocjacjom wymagania.
• Nie staraj się „upchnąć” wszystkiego w ramach User Story. Wspieraj je dokumentacją w innej, dopasowanej do potrzeb, formie, np. diagramami, makietami interfejsu, opisami przypadków użycia etc.
• Do długoterminowego utrzymywania wymagań używaj innych, bardziej odpowiednich technik.
• Zawsze pamiętaj o prawidłowym opisaniu dostarczanej wartości (ostatnie element Statement of Value).

Źródła

A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide). Version 3. 2015.