User stories przyjęły się w zwinnych metodach zarządzania projektami i produktami na dobre. Często słyszy się nawet, że to element np. Scruma, co oczywiście jest nieprawdą. Gdyby się nad tym chwilę zastanowić, można by rzec, że user stories weszły po prostu tak mocno w kanon dobrych praktyk, że ciężko zastąpić je czymś równie skutecznym. Ich popularność ma też „ciemną stronę”. Poza błędnym przypisywaniem ich do Scruma istnieje wiele mylnych definicji czy praktyk. W poniższym tekście wracam do podstaw i wyjaśniam czym users stories są, jak je definiować i dlaczego właściwe zrozumienie ich celu jest kluczowe. Zapraszam do lektury!
User stories – definicja
Mike Cohn, jeden z moich ulubionych praktyków agile, w swoim poście napisał o user story tak:
User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.
W tekście od firmy Atlassian znalazłam zaś taką definicję:
A user story is an informal, general explanation of a software feature written from the perspective of the end user or customer.
Podobnych wyjaśnień w sieci jest bardzo dużo. Wszystkie w końcowym efekcie definiują historyjki w jednakowy sposób. Zbierzmy zatem to co wiemy w jedno:
User story to krótki, nieformalny i prosty opis funkcjonalności, napisany z perspektywy osoby, która potrzebuje nowych możliwości w produkcie. Najczęściej aktorem staje się użytkownik lub system.
Choć Atlassian wskazuje, że funkcjonalności pisane w omawianej formie dotyczą oprogramowania, nie jest to według mnie prawdą. Będąc w zgodzie z definicją można zapisać praktycznie każdą zmianę. Dlaczego? Wyjaśniam to w kolejnym akapicie!
W czym pomagają user stories?
Wiedząc czy user stories są, skupmy się na tym, w czym mogą nam pomóc. W mojej opinii największą wartość niesie możliwość zbudowania pomostu między stroną biznesową i tzw. „techniczną”. Pod tym ostatnim hasłem ukrywa się cała rzesza osób zaangażowanych we wdrożenie nowej funkcjonalności czy zmiany.
Właściciel produktu przekazuje swoją wizję na nowość np. w aplikacji i ma dwie główne opcje – albo zostanie zrozumiany albo nie. Może zdarzyć się, że odbiorcy pomysłu, osoby które będą go realizować, nie są do niego przekonani lub nie rozumieją czym dokładnie ma być. Innym razem, wszystko jest jasne i każdy ma zapał do działania w kierunku wydania nowości użytkownikom, lecz na końcu funkcjonalność mija się z wyobrażeniem pomysłodawcy. Gros takich nieporozumień to właśnie brak odpowiedniego przekazania obrazu pomysłu. I wtedy z pomocą przychodzą user stories.
Ich schematyczny układ pozwala zapisać pomysł i jego funkcjonalność w zrozumiały i szczegółowy sposób. User story napisane zgodnie z definicją, czyli z perspektywy użytkownika czy klienta, daje biznesowe spojrzenie na wdrażaną zmianę czy zupełnie nową opcję w produkcie. Wszyscy zaangażowani patrzą na to co tworzą oczami odbiorcy. Dla mnie to ogromny plus tej formy – inaczej widzimy to co tworzymy, gdy przed oczami mamy cały czas efekt końcowy i potrzebę jaką spełnia.
Żeby to, co opisałam wyżej miało miejsce, musi zaistnieć komunikacja między dwiema stronami – biznesową i „techniczną”. Dlaczego? Czy nie wystarczy gdy właściciel pomysłu opisze go dobrze? W pewnych przypadkach pewnie tak, ale zwykle tekst pisany jest inaczej interpretowany przez różnych czytelników, zatem nawet przy dobrym opisie należy omówić go „na żywo”. Paradoksalnie, również i w tym user stories są pomocą – dzięki swojej strukturze ułatwiają przekazanie wizji w sposób klarowny.
Struktura zapisu user stories
Choć istnieje wiele zdań na temat tego jak zapisywać poprawne user stories, uważam, że dopóki spełniają one swoje założenia, są pisane właściwie. Oficjalnie przyjęta struktura wygląda jak poniżej:
Jako <użytkownik, klient, system itd.> chcę <cel, funkcjonalność> aby <powód>.
Czyli musimy mieć zaadresowane 3 elementy:
- Odbiorca funkcjonalności: użytkownik, administrator, klient, system i pozostałe role jakie pojawiają się w naszym produkcie.
- Definicja tego co chcemy móc widzieć, robić itd.
- Powód, dla którego to czego chcemy powinno być dodane.
Spójrzmy na przykłady spełniające powyższe kryteria:
- Jako administrator chcę akceptować nowych użytkowników systemu, aby uniknąć zakładania fałszywych kont.
- Jako użytkownik chcę móc usunąć niechciane zdjęcie z mojego konta, aby nikt nie mógł go oglądać.
- Jako klient detaliczny chcę mieć możliwość pobrania cennika, aby znać ceny wszystkich towarów.
Jak widać, zapis jest krótki i przejrzysty. Powyższe przykłady można napisać w wielu innych kombinacjach, z innymi powodami etc., ale nie to jest najważniejsze. Właściwe przyjęcie struktury pomaga odpowiedzieć na pytania, które zwykle padną – dzieje się to o czym pisałam wyżej, usprawniana jest komunikacja.
Struktura, którą lubię najbardziej wygląda nieco inaczej niż ta oficjalna. Różni się niewiele, ale mi osobiście zwyczajnie bardziej pasuje i jest bardziej naturalna w zapisie czy mowie.
<użytkownik, klient, system itd.> <robi coś> <z powodu>
W tym wypadku przykłady wyglądałyby tak:
- Administrator akceptuje nowych użytkowników by zapobiec powstawaniu nieprawidłowych kont.
- Użytkownik usuwa zdjęcie z konta w celu ukrycia go przed innymi użytkownikami.
- Klient detaliczny pobiera cennik by poznać ceny wszystkich towarów.
Cel w obu formach jest spełniony, zatem wybór jednej z nich jest już sprawą drugorzędną. Poza samym tytułem, ogromną rolę odgrywa opis samej historyjki w formie kryteriów akceptacji, czynników sukcesu czy satysfakcji. Są one rozszerzeniem, czy też warunkami koniecznymi do spełnienia oczekiwań względem funkcjonalności. Najczęściej tworzy się je podczas rozmowy obu zaangażowanych stron, jednocześnie wyjaśniając wątpliwości czy precyzując detale efektu końcowego.
Podsumowanie
User stories to bardzo pomocna forma opisu wymagań. Jest jedynie (i aż!) dobrą praktyką, stosowaną w zespołach zwinnych. Korzystamy z niej by zwiększyć przejrzystość i zrozumienie zakresu pracy, jaka jest do wykonania. Kiedyś przeczytałam w jednej z książek, że praca z user story jest prosta, jednocześnie napisanie dobrej historyjki jest trudne i wymaga praktyki. W pełni się z tym zgadzam. Źle napisana formułka nie przyniesie poprawy w zrozumieniu zagadnienia, a tylko wprowadzi zamieszanie. Mimo tego, że początki mogą być trudne warto spróbować! User story to najlepsza znana mi forma opisu tego co biznes chce.
Sprawdź nasze ostatnie wpisy:
