
Historyjka użytkownika – oręże analityka
Jak pisać user story? Zacznę może… tak całkiem od początku.
Jak ważne jest precyzyjne dokumentowanie, czyli w zasadzie ubieranie ważnych myśli w słowa? Najlepiej wie to pewnie ustawodawca, który formułuje prawa spisane słowem, a potem ten, kto znajduje w nich lukę.

W tworzeniu software’u jest podobnie.
Tu też dokumentacja ubierze w słowa pewne myśli, ustalenia i skondensuje je do konkretów. Te rzeczy muszą się wydarzyć, żeby mogła się rozpocząć faza software development’u. Zespół raczej nie będzie chciał korzystać z wymagań jako przewlekłych wywodów pełnych nieścisłości, dwuznaczności, kwiecistego języka i nadmiaru tekstu.
Nie chcemy też, żeby złe udokumentowanie wymagań wygenerowało podobne „luki prawne”, które klient mógłby wykorzystać przeciwko nam. Albo kiedy nasze zrozumienie okaże inne od tego, co miał na myśli klient, a jeszcze inaczej zinterpretował to programista.
Kto ma korzystać z historyjki użytkownika?
Programista? Tester? Analityk/Product Owner?
Moja odpowiedź jest prosta – każdy zainteresowany. A im bardziej „dojrzały” opis, tym więcej osób będzie zainteresowanych i większą wyniesie z nich wartość. Do tego, dobrze udokumentowana historyjka zapewni sobie „nieśmiertelność”. Co to oznacza? To za chwilę. Po przerwie na reklamę…
Nieśmiertelność historyjki użytkownika
Co mam na myśli przez nieśmiertelność? Chodzi o takie udokumentowanie, żeby Twoja historyjka użytkownika nie straciła mocy w czasie. Ma być tak samo wartościowa zarówno teraz – kiedy zespół o niej rozmawia i wszyscy wiedzą, o co chodzi – jak i za pół roku i rok, kiedy otworzy ją przypadkowa osoba. Historyjka zachowa nieśmiertelność, kiedy po przejściu kilku linijek tekstu nikt nie będzie mieć wątpliwości, co zostało zrobione. Będzie jasne w jaki sposób i jaka wartość biznesową z sobą wniosło; kto tego potrzebował i kto i w jaki sposób z tego skorzysta.

Teraz horror dostępny w strrrasznie promocyjnej cenie.
Zobacz również:
Kto definiuje User Stories?
W teorii będzie to ta sama osoba, która zajmuje się przygotowaniem pracy dla zespołu. Może to być analityk, Product Owner, Product Manger, czyli ktoś, kto zna potrzeby klienta i posiada warsztat potrzebny do definiowania ich w postaci wymagań.
Praktyka pokazuje natomiast, że bywa różnie. Wynika to choćby z tego, że Backlog może zawierać pracę zarówno produktową jak i stricte techniczną (zamiana technologii, framework’ów, aktualizacja bibliotek etc.). A tam, gdzie praca jest techniczna, często właśnie ludzie techniczni tworzą historyjki. To właśnie bywa najczęstszym scenariuszem, kiedy historyjka użytkownika chętnie wyłamuje się z standardów i konwencji na rzecz „one-liner’ów”.
Jak pisać User Story dobrze?
Oczywiście stosując znane narzędzia i techniki. Jak np.:
- „As a user…, I wan to…, so that…” (Jako użytkownik…, chciałbym…, w celu…)
- Acceptance Criteria (kryteria akceptacji)
- Given-when-then (Zakładając, że-jeśli-wówczas)
Przy czym, nie jest to takie banalne, jakby się mogło wydawać. Widzę to na co dzień w praktyce. Ludzie zazwyczaj używają tych narzędzi na „odczepne”, żeby sprawić wrażenie, że robią to zgodnie ze standardami. Efekt końcowy jest jednak taki, że robią to źle. Bagatelizują wartość tych technik i ostatecznie zastosowanie ich nie wnosi właściwie zbyt dużo wartości, jeśli w ogóle.
Jak pisać User Story źle?
Temat jest dość obszerny więc postanowiłem omówić go w oddzielnym artykule. Tam pokazuję szczegółowo, jak robić to dobrze i jak robić to źle.

„Jesteśmy organami rozrodczymi świata maszyn” – Marshall McLuhan
„Jesteśmy jedynie środkiem do czegoś dalece bardziej doskonałego” – Ryszard Blak
Jak to jest w praktyce?
Osobiście spotkałem się ze skrajnymi postawami. Z jednej strony, ludzie przyzwyczajeni do dobrych standardów i praktyk nie wyobrażali sobie pracy inaczej. Z drugiej, zespoły wychowane na one-linerach i zdawkowej treści nie widziały potrzeby na poprawę… bo nikt nie wiedział, że może być inaczej – lepiej.
To tak trochę jak narzekać na mechanizację rolnictwa, bo przecież sierpy i kosy robią robotę. Ale jak się pojawił pierwszy kombajn, to najwięksi sceptycy nie chcieli wracać do tradycyjnych narzędzi.
Tak też reakcja na porządną dokumentację, zgodną ze sztuką, ale nie nadmiarową, bywa dla nich odkryciem i bardzo miłym zaskoczeniem, że można robić to lepiej i daje to dużo wymiernych korzyści.
Zawsze będą protesty.
Zwolennicy one-liner’ów oczywiście będą protestować, że przecież i tak wiemy, co zrobić. Po co sobie nadkładać dodatkowej roboty? No ciężko się nie zgodzić – robota pewnie zostanie zrobiona. Problem zacznie się, kiedy ktoś z zewnątrz na to spojrzy. Choćby inny albo mniej doświadczony członek zespołu, a już nie daj Boże po jakimś czasie. Mało kto będzie pamiętać kto, gdzie i dlaczego wprowadził zmiany, czy jakie miały być z tego korzyści.
Minimalizm w dokumentacji może być tak samo problematyczny jak i jej nadmiar. Dobrze jest więc mieć świadomość, po co to robimy i utrzymać w tym zdrowy rozsądek, by zachować ducha manifestu Agile.

Chcesz wejść do IT?
Jeśli jesteś zainteresowany pracą w IT, zachęcam do eksplorowania bloga. Dużo bardziej szczegółowo omawiam software development w książce Almanach Informatyczny – Lite.
Jej założeniem jest wprowadzenie każdego do świata IT w 100 słowach i turbo kompaktowych definicjach. Wszystko, czego potrzebujesz, żeby świadomie wybrać rolę dla siebie i czuć się komfortowo, kiedy już zaczniesz.
Powiązane wpisy:
- Jak dobrze napisać historyjkę użytkownika, a jak robić to źle
- Co to jest API
- Co to jest REST API
- Co to jest CRUD
- Jak dostać awans
- Czym zajmuje się Scrum Master
- Czym zajmuje się Product Owner
- Cechy dobrego Product Ownera
- 8 cech dobrego Scrum Mastera
- Co to jest Scrum w IT?
- Co to jest Agile w IT?
- Co to jest Product Backlog w IT?
Zobacz także:
- Jak znaleźć pracę w korporacji
- Praca w IT bez doświadczenia
- Praca w IT bez programowania
- Czy angielski jest konieczny w IT
- Humanista w informatyce
- Rekrutacja w IT
- (Nie)techniczna skala wejścia do IT
- Jak się pracuje w IT – czy to wszystko mit?
- Estymowanie w Scrumie
- Jak pisać User Story
- Jak dobrze napisać historyjkę użytkownika, a jak robić to źle?
- Zmysły sztucznej inteligencji.
- Czy to wszystko mit? – czyli jak na prawdę pracuje się w IT?
- Humanista pośród informatyków
- Czym zajmuje się Scrum Master?
- Informatyk w informatyce.
- Umysł ścisły w informatyce
- AI w IT. Koniec dominacji ludzkiego intelektu?
- Geograficzna eksploracja IT
Dodaj komentarz