User Story cz. 2

Kiedy dzisiaj mówimy o User Stories, myślimy o krótkich, prostych zapisach potrzeb użytkowników, które stanowią podstawę backlogu produktowego w Agile. Ale skąd tak naprawdę się wzięły? Jak powstały? Czy zawsze wyglądały tak samo?

W tym artykule prześledzimy ich historię – od początków w Extreme Programming (XP), przez ich popularyzację w Scrum, aż po współczesne techniki rozwijające ich zastosowanie.

Historia User Stories zaczyna się pod koniec lat 90., kiedy Kent Beck opracowywał metodykę Extreme Programming (XP). Pracując nad projektem Chrysler C3 w Detroit,
zauważył, że tradycyjne specyfikacje wymagań są zbyt sztywne, skomplikowane i często
nieaktualne już w momencie ich napisania.
Beck chciał stworzyć coś prostszego i bardziej elastycznego. Zamiast obszernej
dokumentacji, zespoły miały zacząć od krótkich zapisów, które prowadziłyby do rozmowy o potrzebach użytkowników.
Beck zauważył też, że opowiadanie historii o tym, jak oprogramowanie ma działać, generuje entuzjazm i wizję w umysłach słuchaczy. To doprowadziło go do pytania:

„Skoro możemy opowiadać historie o tym, co oprogramowanie robi, i wzbudzać tym energię oraz zainteresowanie, to dlaczego nie opowiadać takich historii, zanim
oprogramowanie to zrobi?”

Tak narodził się pomysł, aby zamiast sztywnych wymagań tworzyć krótkie historyjki opisujące potrzeby użytkowników – nie jako specyfikację, ale jako punkt startowy do rozmowy.

W 1998 roku Alistair Cockburn odwiedził projekt Chrysler C3 i ukuł frazę:
„User story to obietnica rozmowy”.

Podkreślił tym samym, że historyjki użytkownika nie mają być gotową specyfikacją, ale
mają inicjować dialog między interesariuszami a zespołem deweloperskim.
To był kluczowy moment. User Stories przestały być traktowane jako dokumentacja, a
zaczęły być postrzegane jako narzędzie komunikacji.

W 2001 roku Ron Jeffries, jeden z pionierów Extreme Programming, sformalizował sposóbpracy z User Stories, tworząc zasadę 3C:

1. Card (Karta) – kluczowe jest, aby zanim przyjdziesz do zespołu, zapisać User Story na
karcie.
– Ten etap służy do przemyślenia kontekstu i weryfikacji, czy historia ma sens jeszcze
przed rozmową z zespołem.
– Często już na tym etapie okazuje się, że coś wymaga doprecyzowania lub zmiany.
– Spisanie User Story zmusza do zastanowienia się nad tym, **dlaczego to jest ważne i kto z tego skorzysta.
– Moje doświadczenie pokazuje, że kiedy pierwszy raz faktycznie siadam do poprawnego zapisania User Story, muszę się zastanowić, dlaczego to zadanie jest istotne i jaka wartość za tym stoi.
– Zadając sobie pytanie „dlaczego?”; możemy przejść przez metodę „3x Why”  –
dlaczego to jest bólem użytkownika, dlaczego to dla niego ważne i dlaczego właśnie takiego rozwiązania potrzebuje.

– Jeśli dobrze wykonamy ten etap, kolejne kroki będą **dużo prostsze**, ponieważ już
mamy dobrze przemyślany kontekst i potrzeby użytkownika.
– Największe wyzwanie? Zatrzymać się na chwilę i faktycznie o tym pomyśleć –
naturalnie mamy tendencję, by od razu biec do rozwiązań, zamiast zastanowić się, po co i dla kogo to robimy.

2. Conversation (Rozmowa) – User Story to nie dokument, lecz narzędzie do
rozmowy.
– Ten etap polega na dyskutowaniu z zespołem i wspólnym odkrywaniu najlepszych
rozwiązań.
– To tutaj opowiadamy historię użytkownika, wyjaśniamy jego potrzeby i wyzwania.
– W trakcie rozmowy zespół może zadawać pytania, doprecyzowywać szczegóły i
proponować inne rozwiązania.

3. Confirmation (Potwierdzenie) – kluczowy moment, w którym zespół upewnia się, że
wszyscy rozumieją problem.
– Można użyć parafrazy, aby sprawdzić, czy wszyscy dobrze zrozumieli kontekst User
Story.
– Wspólnie zapisane kryteria akceptacji pomagają doprecyzować, kiedy historia
zostanie uznana za ukończoną.
– W niektórych zespołach confirmation odbywa się przez testy napisane przez zespół,
które określają warunki spełnienia danej funkcji.

Dzięki takiemu podejściu **User Stories nie są tylko tekstem zapisanym w backlogu, ale aktywnym narzędziem do zrozumienia problemu i znalezienia najlepszego rozwiązania.

User Stories przeszły długą drogę, od luźnych zapisów w Extreme Programming do jednego z kluczowych narzędzi w Agile.

Najważniejsze momenty w historii User Stories:
– 1997 – Kent Beck opracowuje Extreme Programming i wprowadza User Stories.
– 1998 – Alistair Cockburn podkreśla, że „User Story to obietnica rozmowy”.
– 2001 – Ron Jeffries formułuje zasadę 3C (Card, Conversation, Confirmation).
– 2004 – Mike Cohn standaryzuje User Stories w książce „User Stories Applied”
– 2014 – Jeff Patton rozwija **User Story Mapping.

Masz temat, który szczególnie Cię interesuje? Daj mi znać!