User Story w metodyce Agile to krótki, sformułowany w naturalnym języku opis funkcji oprogramowania z perspektywy końcowego odbiorcy, który określa, kto potrzebuje danej zmiany, na czym ona polega i jaki problem biznesowy rozwiązuje. Poprawne pisanie historyjek opiera się na prostym schemacie „Jako [typ użytkownika], chcę [wykonać akcję], żeby [osiągnąć cel]” oraz bezwzględnym zdefiniowaniu twardych kryteriów akceptacji przed rozpoczęciem prac programistycznych. To podstawowe narzędzie komunikacji między biznesem a zespołem technicznym.
W zeszłym miesiącu siedzieliśmy nad backlogiem dla dużego klienta z branży logistycznej. Zespół deweloperski patrzył na specyfikację i nikt nie wiedział, od czego zacząć kodowanie. Dokument liczył kilkadziesiąt stron. Zmieniliśmy te zasady na robocie. Wyrzuciliśmy ten plik do kosza i zaczęliśmy pisać wymagania biznesowe od nowa, korzystając z karteczek samoprzylepnych. To pokazało nam od razu, gdzie brakuje logiki.
Czym dokładnie jest historyjka użytkownika w codziennej pracy zespołu IT?
W codziennym życiu projektowym historyjka użytkownika to po prostu obietnica rozmowy. Nie traktujemy jej jako zamkniętego kontraktu. Zdecydowana większość początkujących analityków myśli, że musi zapisać w niej każdy detal techniczny. To błąd. Bilet w systemie takim jak Jira ma sprowokować dyskusję podczas planowania sprintu. Zespół czyta opis i zaczyna zadawać trudne pytania.
Główna fraza, czyli odpowiedź na pytanie co to jest User Story w metodyce Agile i jak je poprawnie pisać, sprowadza się do zrozumienia intencji. Kodujemy rozwiązanie dla konkretnego człowieka. Jeśli deweloper nie wie, kim jest ten człowiek, napisze zły kod. Prawda jest zresztą absolutnie taka, że połowa błędów na produkcji wynika z niezrozumienia, kto w ogóle klika ten przycisk w aplikacji.
Skąd wziął się format Jako, chcę, żeby?
Ten szablon powstał w środowisku Extreme Programming pod koniec lat dziewięćdziesiątych. Programiści mieli dość czytania suchych wymagań systemowych. Zaczęli narzucać formę narracyjną. Zbudowali strukturę opartą na trzech prostych zmiennych. A to przyniosło efekty.
- Jako (Who): Określamy konkretną personę. Piszemy „Jako niezalogowany klient sklepu”, a nie ogólnie „Jako system”. System niczego nie chce.
- Chcę (What): Definiujemy akcję. Bardzo krótko i wprost. Na przykład „chcę odzyskać hasło za pomocą numeru telefonu”.
- Żeby (Why): Wskazujemy korzyść. Piszemy „żeby szybko wrócić do przerwanych zakupów bez sprawdzania skrzynki mailowej”. Czasami zespoły pomijają ten punkt. To najgorsza opcja z wszystkich. Zawsze musimy znać cel biznesowy.
- Kontekst brzegowy: Dodajemy drobne notatki ułatwiające wycenę podczas sesji Planning Poker.
Jakie są główne różnice między User Story a tradycyjną specyfikacją wymagań?
Tradycyjna specyfikacja kaskadowa (Waterfall) zakłada, że wiemy wszystko przed napisaniem pierwszej linijki kodu. Tworzymy opasłe tomy dokumentacji. Agile podchodzi do tego inaczej. Akceptujemy niewiedzę. Historyjki użytkownika ewoluują w czasie. Zmieniamy ich zakres w miarę odkrywania nowych faktów o systemie.
Michał, nasz główny Product Owner, stwierdził we wtorek na stand-upie: „Jeśli deweloper musi dopytywać o sens biznesowy po przeczytaniu pierwszego zdania, to wywalamy ten bilet do kosza”. Zgadzam się z nim. Tradycyjny dokument systemowy skupia się na tym, jak baza danych ma przetwarzać tabele. Zwinne wymaganie mówi o tym, dlaczego księgowa w ogóle potrzebuje tego raportu do zamknięcia miesiąca.
Jak poprawnie pisać User Story krok po kroku?
Proces tworzenia wymagań wymaga dyscypliny. Najpierw definiujesz personę. Zapomnij o ogólnikach. Dobrym pomysłem jest nadanie użytkownikom imion lub konkretnych ról zawodowych. Potem określasz akcję. Używaj czasowników dokonanych. Unikaj form biernych. Zamiast pisać „Raport jest generowany”, napisz „Pobieram raport w formacie PDF”.
Następnie skupiasz się na wartości biznesowej. Ten element weryfikuje, czy zadanie w ogóle powinno trafić do Product Backlogu. Jeśli nie potrafisz wymyślić sensownego „żeby”, prawdopodobnie próbujesz przepchnąć zadanie techniczne pod przykrywką wartości dla klienta. My w zespole po prostu odrzucamy takie zgłoszenia na spotkaniach Refinement.
Dlaczego kryteria akceptacji decydują o sukcesie wdrożenia?
Kryteria akceptacji (Acceptance Criteria) to zbiór warunków, które aplikacja musi spełnić, by uznać historyjkę za ukończoną. To nasza definicja sukcesu. Bez nich programista i tester mają zupełnie inne wyobrażenie o tym, jak ma działać funkcja. Zapisujemy je najczęściej w formie listy kontrolnej lub w formacie BDD (Given-When-Then).
| Złe kryteria akceptacji | Dobre kryteria akceptacji (Gherkin/BDD) |
| Wyszukiwarka działa szybko. | Zakładając, że jestem na stronie głównej. Kiedy wpiszę „laptop” i wcisnę Enter. Wtedy system wyświetla wyniki w czasie poniżej 1 sekundy. |
| Użytkownik widzi błąd przy złym haśle. | Zakładając, że podaję błędne hasło. Kiedy klikam Zaloguj. Wtedy pole podświetla się na czerwono i wyświetla komunikat „Błędne dane logowania”. |
Zawsze dołączaj negatywne ścieżki (Negative paths). Zdecydowana większość historyjek opisuje tylko to, co dzieje się, gdy wszystko idzie dobrze. My skupiamy się na tym, co system robi, gdy serwer zewnętrzny zwraca błąd 500 albo gdy klient wpisze w pole tekstowe skrypt SQL.
Co oznacza skrót INVEST i jak weryfikuje jakość historyjek?
Zasada INVEST ma sześć liter określających cechy idealnego wymagania. My na produkcji patrzymy głównie na cztery z nich. Historyjka musi być niezależna (Independent). Jeśli bilet A blokuje bilet B, a ten blokuje C, to mamy problem z planowaniem. Wymagania powinny dać się wdrażać w dowolnej kolejności.
Musi też być negocjowalna (Negotiable). Oznacza to, że zespół programistów ma prawo zmienić sposób implementacji, jeśli cel biznesowy zostaje zachowany. Pamiętam sytuację, gdy klient upierał się przy skomplikowanym algorytmie uczenia maszynowego do sortowania produktów. Zrobiliśmy to prostym zapytaniem do bazy w jedno popołudnie. Klient dostał to, czego chciał, a my zaoszczędziliśmy dwa tygodnie pracy.
Kolejne cechy to wartościowa (Valuable) i mierzalna (Estimable). Zespół musi umieć oszacować rozmiar zadania.
Na koniec mała (Small) i testowalna (Testable). Jeśli historyjka zajmuje więcej niż połowę sprintu, jest za duża. Musisz ją pociąć.
Jak dzielić duże Epiki na mniejsze zadania do sprintu?
Epik to po prostu ogromna historyjka. To wymaganie tak duże, że nie mieści się w jednym sprincie. Może to być na przykład „Moduł płatności internetowych”. Zespół musi rozbić ten głaz na mniejsze kamienie.
(Prawda jest zresztą absolutnie taka, że nienawidzę patrzeć, jak początkujący analitycy tną epiki na siłę według warstw architektury. Siedzimy potem na review, gość pokazuje mi sam zrobiony backend, na froncie nic nie klika, a on uśmiechnięty twierdzi, że dowiózł wartość. To mnie doprowadza do szału. Musisz ciąć to pionowo, przez wszystkie warstwy, inaczej całe to zwinne planowanie można wyrzucić przez okno przed poniedziałkiem.)
Dzielimy epiki według ścieżek biznesowych. Najpierw robimy płatność kartą. W kolejnym sprincie dodajemy płatność przelewem. Potem dorzucamy obsługę błędów operatora. Każdy mały przyrost daje działający kawałek oprogramowania, który możemy pokazać użytkownikom.
Kto fizycznie odpowiada za tworzenie Product Backlogu?
To rola Product Ownera. Koniec kropka. On ma wizję. To on decyduje, co robimy teraz, co robimy później, a czego nie zrobimy nigdy. Scrum Master dba o to, by zespół rozumiał teorię, ale nie pisze wymagań za biznes.
Jednak w dojrzałych zespołach programiści aktywnie pomagają w pisaniu. Zgłaszają własne propozycje, dzielą zadania i doprecyzowują kryteria akceptacji. Backlog to żywy organizm. Jeśli tylko jedna osoba ma do niego prawo zapisu, tworzy się wąskie gardło spowalniające cały proces deweloperski.
Jakie błędy najczęściej niszczą planowanie w metodyce Agile?
Wielokrotnie widziałem, jak źle napisane wymagania kładły cały sprint w pierwszych trzech dniach. Ludzie popełniają wciąż te same błędy.
- Pisanie dla deweloperów, a nie dla użytkowników. Konstrukcje typu „Jako baza danych, chcę indeksować tabele” łamią całą koncepcję. Zespół nie wie, po co to robi.
- Brak twardych kryteriów akceptacji. Prowadzi to do syndromu „u mnie działa”, gdy tester zgłasza błąd w funkcjonowaniu interfejsu.
Innym błędem jest traktowanie backlogu jak zamrażarki na pomysły. Ludzie wrzucają tam setki biletów, których nikt nigdy nie zrealizuje. My trzymamy w backlogu zadania na maksymalnie trzy miesiące w przód. Resztę po prostu usuwamy. Jeśli coś jest naprawdę ważne, klient i tak do nas z tym wróci.
Czy techniczne zadania deweloperskie to też User Stories?
Dług techniczny, aktualizacje bibliotek czy refaktoryzacja kodu to zadania, które nie mają bezpośredniego użytkownika końcowego. Niektórzy na siłę próbują wcisnąć je w format historyjki. Wychodzą z tego potworki językowe.
Zmieniliśmy te zasady na robocie. Zadanie techniczne to po prostu zadanie techniczne. Nazywamy je Enablerami lub Technical Tasks. Zapisujemy je prostym językiem technicznym: „Podnieść wersję bazy PostgreSQL do 15.0”. Nie udajemy, że system operacyjny ma ludzkie potrzeby. Ważne jest tylko to, by wytłumaczyć Product Ownerowi, dlaczego musimy poświęcić na to czas w sprincie zamiast dostarczać nowe funkcje.
Jak wyceniać wymagania i po co nam Story Points?
Wycena w Agile nie opiera się na godzinach. Używamy Story Points, czyli abstrakcyjnych punktów historii. Oceniamy złożoność zadania, ryzyko i ilość pracy do wykonania w odniesieniu do innego, znanego już zadania. Najczęściej korzystamy z ciągu Fibonacciego (1, 2, 3, 5, 8, 13).
Wyceniamy w zespole za pomocą Planning Pokera. Każdy deweloper rzuca kartę z wyceną. Jeśli są rozbieżności, dyskutujemy. Wycena w punktach chroni nas przed różnicami w doświadczeniu. Senior napisze kod w dwie godziny, junior w dwa dni. Ale dla obu to zadanie ma dokładnie taką samą złożoność biznesową i wynosi na przykład 5 Story Points.
Zrozumienie, co to jest User Story w metodyce Agile i jak je poprawnie pisać, to proces nauki na błędach. Przestańcie pisać te gigantyczne dokumentacje pod przykrywką zwinności. Otwórz swój backlog jutro rano. Przeczytaj pierwszą historyjkę z góry. Jeśli nie potrafisz w pięciu słowach powiedzieć, po co w ogóle to robicie, po prostu ją wyrzuć. Szkoda waszego czasu na kodowanie rzeczy, których nikt nie potrzebuje.
Najczęściej zadawane pytania (FAQ)
- Kto w zespole Agile pisze User Stories?
Za zarządzanie Product Backlogiem i tworzenie historyjek odpowiada Product Owner. W praktyce jednak często współpracuje on ściśle z zespołem deweloperskim i analitykami biznesowymi, aby doprecyzować szczegóły techniczne i wycenić zadania. - Jak długie powinno być idealne User Story?
Opis główny powinien składać się z jednego, prostego zdania w formacie 'Jako, chcę, żeby’. Resztę treści stanowią precyzyjne kryteria akceptacji. Samo zadanie powinno być na tyle małe, aby zespół mógł je wdrożyć w ciągu kilku dni trwania jednego sprintu. - Czy każde zadanie w systemie Jira to User Story?
Nie. W systemach typu Jira funkcjonują różne typy zgłoszeń (Issue Types). Oprócz historyjek mamy tam błędy (Bugs), zadania techniczne (Tasks/Technical Tasks) oraz ogromne inicjatywy biznesowe zwane Epikami. - Czym są kryteria akceptacji w historyjce?
To warunki graniczne i szczegółowe wytyczne, które muszą zostać spełnione, by Product Owner i zespół uznali zadanie za całkowicie skończone. Często zapisuje się je w formie testów zachowawczych BDD (Given-When-Then). - Co zrobić, gdy wymaganie jest za duże na jeden sprint?
Takie wymaganie nazywamy Epikiem. Należy je rozbić na mniejsze, niezależne User Stories. Najlepszą praktyką jest podział pionowy, w którym każda nowa historyjka dostarcza małą, ale działającą wartość dla użytkownika końcowego od frontu do bazy danych. - Co to jest metoda INVEST?
To akronim określający cechy dobrej historyjki. Oznacza, że powinna ona być: Niezależna (Independent), Negocjowalna (Negotiable), Wartościowa (Valuable), Mierzalna (Estimable), Mała (Small) oraz Testowalna (Testable).
Bibliografia
1. Scrum.org – https://www.scrum.org
2. Agile Alliance – https://www.agilealliance.org
3. Atlassian – https://www.atlassian.com
4. Project Management Institute – https://www.pmi.org
5. Mountain Goat Software – https://www.mountaingoatsoftware.com
