Magia „User Story” – czyli krótka historyjka użytkownika.

Nie ma projektu bez wymagań.  Każdy realizowany projekt bez względu czy podejdziemy do jego wykonania  tradycyjnymi metodami (np. Prince2..) czy  Agilowo (DSDM, Scrum..) Stawia przed zespołem projektowym wymagania, które są do zrealizowania. Wymaganiem może być np.: usługa, funkcja lub cecha, której potrzebuje użytkownik końcowy. By projekt znalazł się bliżej sukcesu, każde rozwiązanie powinno być połączeniem dwóch aspektów:

  1. Wymagań funkcjonalnych (FRs  specification of functional requirements)
  2. Wymagań nie funkcjonalnych (NFRs  non-functional requirements).
customers users color wheel
Photo by Kaboompics .com on Pexels.com

 

Określenie wymagań funkcjonalnych odpowie nam na pytanie, co dane rozwiązanie robi. Opisze przykład jego funkcjonalności lub  cechy. Ważne by wymagania funkcjonalne opisywać jako  „co ma być zrobione” a nie „jak ma być zrobione”.

Wymagania nie funkcjonalne opisują natomiast atrybuty danego rozwiązania np. dostępność lub bezpieczeństwo – czyli takie, przy zachowaniu których projekt powinien realizować swoje funkcje.

Agilowym narzędziem, które ułatwia określenie wymagań jest tzw. Historyjka Użytkownika (User Story).

Jest to wymaganie wyrażone z perspektywy celu użytkownika końcowego.

No dobrze – dość teorii! Na chwilę  🙂

Od czego zaczniemy?

Każda Historyjka składa się z 3 elementów tzw.: trzech „C”.

Karty (z ang. Card)

Rozmowy (z ang. Conversation)

Potwierdzenia (z ang. Confirmation)

 

Przykład : Historyjki Użytkownika – awers karty.

1. (unikalny identyfikator) X1

2. (Tytuł Historyjki) Reklamacja Klienta

3. (Rola)  jako: Klient

4. (Wymaganie)  potrzebuję:  złożyć reklamacje

5. (Dostarczona wartość biznesowa)    bym: mógł to zrobić z domu

 

Rewers karty Historyjki Użytkownika (Potwierdzenie)

X1

Kryteria Akceptacji

Czy mogę swoją reklamację zapisać i wrócić do niej później?

Czy mogę na bieżąco widzieć aktualny status reklamacji?

Wymagania Niefunkcjonalne – Dostępność 

Czy mogę mieć dostęp do systemu 24 h / 7

Czy mogę złożyć reklamacje 365 dni w roku ?

 

Kryteria Akceptacji stanowią  podstawę do stworzenia odpowiednich scenariuszy dla testów i proponowanych rozwiązań.  Bardzo ważne przy używaniu „Historyjek”  jest to, by nie stały w sprzeczności z innymi „Historyjkami”.

Stosowanie tego narzędzia umożliwia w Agile koncentrowanie się na użytkowniku końcowym. Pozwala określić ogólne wymagania w początkowej fazie projektu. Definiuje wymagania w sposób przystępny dla odbiorcy końcowego, a przede wszystkim pozwala wyjaśnić prawdziwe znaczenie wymagania.

Dobrze skonstruowana „Historyjka Użytkownika” powinna posiadać cechy INVEST opisane przez Billa Wake’a:

Independent – niezależne: czyli takie, które można zastosować bez uwzględniania innych user story.

Negotiable – negocjowanle: szczegóły i zakres itp. można doprecyzować

Valuable – wartościowe: czyli takie, które dodają konkretną wartość do projektu.

Estimable – możliwe do oszacowania.

Small enough – wystarczająco małe: czyli takie, które dają możliwość jego realizacji i oszacowania prac.

Testable – możliwe do przetestowania.

O „User Stories” napisano wiele.  Uważam jednak, że najlepiej zrozumieć ich uniwersalność  poprzez ich praktyczne wykorzystanie. Narzędzie to nie jest skomplikowane, jednak poprawne spisywanie historyjek wymaga dużo pracy.

A więc do dzieła! Każdy przecież piszę jakąś historię. 🙂

 

2 myśli na temat “Magia „User Story” – czyli krótka historyjka użytkownika.

  1. A jakiś przykład, np konkretnie z życia jak wyglada taki dialog.
    Bo to cały czas teoria.
    User – PM, czy i jak to wygląda? Kto negocjuje? Kto ocenia koszty.

    Polubienie

    1. W praktyce historyjka zbierana jest na spotkaniu, może to być forma wywiadu rozmowy, warsztatu.
      Ważne by robić je zgodnie z określonym formatem.
      Osobą udzielającą odpowiedzi jest zazwyczaj odbiorca końcowy danego rozwiązania. User story służy do zbierania wymagań na podstawie których wyłoni się cel projektu. W zależności od fazy projektu
      używa się ich do określenia zakresu projektu następnie stanowią podstawę do stworzenie planu ich dostarczenia.
      W środowisku Agile zakładamy że szczegóły danego rozwiązania wyłonią się raczej później niż wcześniej. Dlatego też ostateczna wersja rozwiązania będzie ewaluować.
      Koszty określane są przez zespół projektowy na podstawie zebranych wymagań we wstępnej fazie.

      Polubienie

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Wyloguj /  Zmień )

Zdjęcie na Google

Komentujesz korzystając z konta Google. Wyloguj /  Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Wyloguj /  Zmień )

Zdjęcie na Facebooku

Komentujesz korzystając z konta Facebook. Wyloguj /  Zmień )

Połączenie z %s