RyszardBlak.com

IT dla humanistów i nie tylko

Jak pisać User Story

|

Jak pisać User Story
Dobra dokumentacja to inwestycja.

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ę.

Kodeł historyjka użytkownika
Kodeł – porady eksperta. Więcej w kolejnych artykułach.

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.

Po drugiej stronie Tenczy
Dlaczego ród Toporczyków wygasł tak nagle? Czy legendy Zamku Tenczyn w Rudnie kryją w sobie odpowiedź?
Teraz horror dostępny w strrrasznie promocyjnej cenie.

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.

OKEANOS 115 - NA RATUNEK BOGU
Co się dzieje, kiedy życie wykracza poza świat materialny? Sprawdź dostępne pozycje w sklepie.
„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.

IT dla humanistów

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:

Zobacz także:

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *