Kto z nas nie uwielbia opowieści? Można je spotkać wszędzie: przy ognisku, w kawiarni, w kinie, w książce. Słuchamy ich, czytamy je, oglądamy i wreszcie uczestniczymy w nich rozgrywając sesje RPG. Jest w nich humor, przygoda, emocje i bohaterowie z krwi i kości, ze swoimi potrzebami, problemami i celami. Wszystko to, co nas pociąga w opowieściach jest tym, czego z pewnością nie znajdziemy w … Książce Wymagań do Oprogramowania (Software Requirements Document, czy jakkolwiek jest nazywany w Twojej firmie). Te dokumenty są długie i kompletnie nudne, wywołujące narkolepsję po pierwszych paru stronach. „Bo do czegoś innego służą” słyszę na ich obronę. Czy aby na pewno?
Gdzie tkwi problem z tradycyjnym podejściem do wymagań?
„Wymagania trzeba spisać, tak na wszelki wypadek, żebyśmy czegoś nie zapomnieli.” To z pozoru niewinne zdanie niesie ze sobą sporo konsekwencji. Po pierwsze najczęściej zbieraniem wymagań zajmuje się inna osoba niż ta, która będzie się odpowiedzialna za implementację. Dopiero po spisaniu wszystkich wymagań są one przekazywane do developmentu. Tym samym wybrane rozwiązanie nie koniecznie będzie optymalne zarówno z punktu widzenia klienta (np. duże koszty) jak i developerów (np. złożoność). Czyli zamiast kalkulatora, przygotujemy arkusz kalkulacyjny z obsługą makr.
Dodatkowo, brak kontekstu powoduje, że wymagania mogą zostać błędnie zinterpretowane. Na przykład, co znaczy, że nazwa użytkownika ma mieć 8 znaków. Tylko? Minimum? Jakie znaki są dopuszczalne? Tutaj można się bronić przez bardzo szczegółową specyfikację i ograniczenie używanego słownictwa, ale powoduje to natychmiast gwałtowny przyrost masy dokumentu i stosowanie monotonnych mantr („system ma, system musi, system może…”). W najlepszym przypadku klient dostanie to co zostało zapisane. Bardzo rzadko będzie to tym, czego potrzebował.
Pokazuje to bardzo dosadnie wynik badań zaprezentowanych przez Standish Group w 2002 roku. Okazuje się, że 64% fukcji jest używana bardzo rzadko albo wcale.
Po drugie, klient najczęściej ma tylko jedną próbę – jedną szansę na zdefiniowanie wymagań dla jedynego wydania (release), które nastąpi za długi okres czasu. Wszystkie późniejsze, nawet drobne zmiany będą trudne i kosztowne i będą wymagały przejścia przez formalny proces zarządzania zmianami. W tej sytuacji nie pozostaje nic innego, jak spisać wszystkie pomysły jakie tylko przychodzą do głowy i wszystkie funkcjonalności jakie być może będą potrzebne za rok, kiedy to produkt będzie już gotowy. Oczywiście, ponieważ jest jedno wydanie i nie można zmienić zdania to nie ma nawet sensu ustalać, które wymagania są najważniejsze. Po prostu implementujemy wszystko jak leci. Nie powinien więc dziwić raport Standish Group z 2002 roku, gdzie Jim Johnson pokazał, że 45% funkcjonalności nigdy nie jest używana, a 19% rzadko.
Może porozmawiać?
Jaka jest zatem alternatywa? Przede wszystkim już samo wprowadzenie podejścia iteracyjnego daje nam możliwość zmiany wymagań (co iterację), a tym samym ich priorytetyzację. Przestają zatem być „wymagane”, a stają się „oczekiwane”. Dzięki temu, klient nie musi się martwić, że czegoś zapomniał na początku, albo że zmiana na rynku spowoduje zmianę potrzeb w stosunku do produktu. Co więcej, nie musi już spisywać wszystkiego na raz, ale może definiować potrzebne zmiany w niewielkich paczkach, takich w sam raz na jedną iterację. A wszystko to dzieje się w tym samym czasie kiedy powstaje produkt.
Czemu więc nie pójść więc o krok dalej i zamiast kazać klientowi spisywać wymagania na najbliższy Sprint, po prostu usiąść i porozmawiać, aby zrozumieć potrzeby i priorytety użytkownika i poznać jego historię.
Historyjka Użytkownika (User Story)
Historie użytkownika, to coś co opowiadamy, nie spisujemy.
I tak dochodzimy do opowiadania historii z życia użytkownika, czyli popularniej praktyki Agile – Historyjki Użytkownika (User Story) . Fabuła, czyli kontekst pozwala zrozumieć sytuację głównego bohatera (to jest użytkownika) i jego cele oraz potrzeby (a więc i priorytety). Znając jego problemy i bolączki zespół może się z nim identyfikować i dzięki temu zaangażować w poszukiwanie skutecznego rozwiązania. Inaczej mówiąc, dobra Historyjka powinna nam powiedzieć:
- Co robimy?
- Dla kogo to robimy?
- Dlaczego to robimy?
Przy czym ważność pytań jest odwrotna do ich kolejności. Inaczej mówiąc trzeba najpierw zrozumieć dlaczego i dla kogo, żeby móc odpowiedzieć na pytanie jak rozwiązać dany problem.
Te pytania prowadzą nas do szablonu Historyjek Użytkownika zaproponowanego przez Mike Cohna:
Jako <rola użytkownika>
Chciałbym <akcja/funkcjonalność>
Aby <cel>
Na przykład dla śledzenia statusu zamówienia w sklepie internetowym Historyjka może wyglądać tak:
„Jako kupujący
chcę mieć możliwość śledzenia statusu zamówienia,
abym wiedział kiedy paczka do mnie dotrze”
A oto kilka przykładów z Gwiezdnych Wojen:
Jako Hans Solo,
chciałbym, aby Sokół Milenium był wyposażony w tarcze,
aby chroniły nas przed laserami krążowników Imperium.Jako rycerz Jedi,
chciałbym aby miecz laserowy mógł ciąć metal,
żebym mógł otworzyć zamkniętą śluzę na mostek kapitański.Jako senator Palpatine
chcę mieć możliwość uzyskania zdalnego połączenia kiepskiej jakości,
tak abym nie został rozpoznany.
Na wszelki wypadek powtórzę jeszcze raz – akcja/funkcjonalność ma wynikać z celu i roli użytkownika. Unikaj Historyjek bez dobrze zdefiniowanego celu, bo:
„jak nie ma tam treści, to po prostu można tam sobie podkładać różne treści i może nawet takie, które by nam tu nie odpowiadały.” /rejs/.
Zalety Historyjek Użytkownika
Historyjki są krótkie, bo mają prowadzić do rozmowy, nie ją zastępować. Ich celem jest zrozumienie przez zespół potrzeb Klienta, ale również w drugą stronę – wytłumaczenie klientowi możliwości i ograniczeń technologicznych.
Historyjki stanowią naturalny pomost pomiędzy IT i biznesem. Zapewniają, że żadna ze stron nie zdominuje rozmowy o potrzebach, możliwościach i ograniczeniach, narzucając swoje rozwiązania. Pomagają rozmawiać o najważniejszej osobie – użytkowniku.
Historyjki pozwalają skupić się na wartości dla użytkownika. Znając wielkość Historyjek, ryzyka z nimi związane, zależności i ich priorytet Product Owner będzie mógł je poszeregować tworząc Rejestr Produktu (Product Backlog).
Historyjki również świetnie nadają się do podejścia iteracyjnego, bo łatwo je dzielić na mniejsze kawałki, tak aby zmieściły się do iteracji. Co więcej, nowo powstałe Historyjki nie muszą mieć tego samego priorytetu. Jeżeli zajdzie taka potrzeba, część z nich możemy dostarczyć w następnych wydaniach.
Historyjki to nie wszystko
Oczywiście Historyjki nie istnieją w próżni. Wraz z nimi stosuje się inne techniki, pozwalające lepiej zrozumieć oczekiwania użytkownika, takie jak Kryteria Akceptacyjne, Persony, Scenariusze i Komiksy (Storyboard), Schematy Blokowe czy też Papierowe Prototypy. Ale to już kandydaci na zupełnie nowe artykuły.
