Share on Facebook Tweet it

Jak ugryźć user story

Nawiązując do wpisu o story points postanowiłem napisać kilka słów o samych user stories czyli „historiach użytkownika”.

Wg Mike’a Cohna user story powinno mieć następującą formę:

Jako <rodzaj użytkownika> , chcę< jakiś cel>, tak aby <uzasadnienie>

Przykładowe pojedyncze user story może brzmieć:

„Jako użytkownik premium kupując towary powyżej 1000zł chcę dostać rabat 10% do końca miesiąca tak aby zachęcić mnie do kolejnych zakupów.”

Taki zapis user story ma wiele zalet. Pozwala określić:

  1. kto będzie używał danej funkcjonalności,
  2. czego ten użytkownik będzie wymagał od systemu,
  3. kontekst dla wymagania.

Powyższy zapis ma też jedną wadę. Jest dość długi, a lista wymagań przedstawionych w tej formie jest nieprzejrzysta.

Ron Jeffries proponuje podejście „Karty, konwersacji  i potwierdzenia”

Chodzi o to, że karta jest tylko nośnikiem. Na karcie zapisany jest tylko tytuł problemu. Brakuje tam natomiast szczegółów. Z tego względu sama karta nie jest dostatecznym medium do przeniesienia pełnej informacji od  klienta do dewelopera. Temu służy konwersacja czyli komunikacja obustronna. Deweloperzy zadają pytania starając się dobrze zrozumieć wymaganie. Klient również pyta deweloperów, żeby mieć pewność, że jego wymaganie zostało dobrze zrozumiane. Konwersacja może przyczynić się do lepszego zrozumienia wymagania przez obie strony i w konsekwencji doprowadzić do jego rozwinięcia, zmiany a nawet porzucenia. Potwierdzenie potrzebne jest deweloperom, aby wiedzieli kiedy wykonali user story. Może wiązać się to z podaniem konkretnych przykładów użycia, które następnie zostaną przekształcone na zautomatyzowane testy akceptacyjne.

Nie przesadzałbym też z próbami przekształcenia każdego wymagania w user story. Niektóre wymagania (szczególnie te pozafunkcjonalne) trudno wtłoczyć w ramy user story. Warto natomiast zadać sobie pytanie: jeżeli czegoś nie da się opisać jako user story, to czy na pewno warto się tym zajmować?

 

Tags: ,

Profile photo of liber

About liber

Jestem zdeklarowanym zwolennikiem zwinnych praktyk. Większość mojego doświadczenia z agile stanowi praca z zespołami scrumowymi zarówno jako Scrum Master jak i jako Scrum Coach. Nie stronie jednak od innych podejść. Ostatnio, na przykład, miałem przyjemność bycia członkiem zespołu kanbanowego. Po klikuletniej pracy w londyńskim City obecnie związany jestem z firmą Espeo Software.

Comments are closed.