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:
- Wymagań funkcjonalnych (FRs specification of functional requirements)
- Wymagań nie funkcjonalnych (NFRs non-functional requirements).
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ę. 🙂
Agile Lives 
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.
PolubieniePolubienie
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.
PolubieniePolubienie