Historia użytkownika

Historia użytkownika to krótki opis wymagania wyrażony z perspektywy osoby, która będzie z niego korzystać, konwencjonalnie zapisany w formie roli, pożądanej umiejętności i powodu, dla którego jest ona potrzebna. Wyrosła z ekstremalnej praktyki programistycznej i stała się dominującym formatem wyrażania pracy w iteracyjnym rozwoju.

Jej cel jest często źle rozumiany. Historia nie jest specyfikacją, lecz przypomnieniem o konieczności rozmowy. Pierwotna formuła opisywała historie jako miejsca na dyskusję między osobami, które chcą danej umiejętności, a tymi, które ją opracują, a tekst pisany ma na celu zapewnienie, że dyskusja się odbędzie, a nie jej zastąpienie. Zespoły, które traktują kartę jako całkowite wymaganie, przyjęły ten format i porzuciły ten mechanizm.

Zdanie uzasadniające jest elementem, który niesie ze sobą największą wartość i jest najczęściej pisane niedbale. Stwierdzenie, dlaczego dana zdolność jest potrzebna, pozwala zespołowi zaproponować inne, często lepsze rozwiązanie tej samej potrzeby, a także pozwala na uczciwe obniżenie priorytetu pracy, gdy podstawowy powód okazuje się słaby. Historie, w których zdanie uzasadniające jedynie powtarza zdolność, na przykład chęć naciśnięcia przycisku, nie przekazują niczego i uniemożliwiają taką rozmowę.

Rozmiar ma znaczenie, ponieważ historia ma być możliwa do ukończenia w ramach iteracji i dostarczać użytkownikowi coś, czego może on faktycznie doświadczyć. Zbyt rozbudowane historie nie mogą zostać ukończone ani ocenione, a historie rozłożone na warstwy techniczne, takie jak oddzielne budowanie tabeli bazy danych lub komponentu interfejsu, nie dostarczają niczego, co dałoby się zaobserwować indywidualnie. Pionowe cięcie, w którym każda historia przechodzi przez każdą warstwę, tworząc drobną, ale kompletną funkcjonalność, pozwala zachować możliwość demonstracji i uczenia się.

Format jest raczej konwencją niż wymogiem, a sztywne trzymanie się go prowadzi do absurdów. Prace techniczne bez bezpośredniego użytkownika, takie jak aktualizacja zależności lub poprawa obserwowalności, nie pasują do szablonu, a ich forsowanie tworzy sztucznego użytkownika, który chce zaktualizować bibliotekę. Otwarte rejestrowanie takich prac, z podaniem ich uzasadnienia, jest bardziej uczciwe i użyteczne niż zniekształcanie ich w celu spełnienia wymogów formatu.

Kryteria akceptacji to czynniki, które sprawiają, że historia jest testowalna i stanowią jej integralną część, a nie oddzielny artefakt. Określają one warunki, na jakich historia zostanie uznana za kompletną, w tym przypadki skrajne i ścieżki błędów pomijane w formie narracji. Bez nich ukończenie staje się kwestią opinii, a rozbieżności zazwyczaj pojawiają się podczas recenzji, kiedy rozwiązanie jest najbardziej kosztowne.

Historie kumulują się w zaległości, które stają się niemożliwe do opanowania, jeśli nigdy ich nie usuniemy. Artykuły napisane wiele miesięcy temu opisują produkt i rynek, które od tego czasu uległy zmianie, a zaległości składające się z kilkuset historii to dokument, którego nikt nie czyta, a nie plan. Okresowe usuwanie historii, które w realistycznych warunkach nie zostaną zbudowane, jest niewygodne i znacznie bardziej przydatne niż ich przechowywanie w nieskończoność.

Ponieważ wartość zależy od rozmowy, a nie od artefaktu, skuteczność zależy od tego, czy uczestniczą w niej odpowiednie osoby. W praktyce format ten jest stosowany w rozwój produktów z podstawową potrzebą, która jest udowodniona poprzez badania użytkowników raczej niż zakładane, a organizacje budujące tę zdolność wewnętrznie zwykle ustalają praktykę pisania i udoskonalania w ramach dział produktów tak aby historie wywodziły się z potwierdzonych problemów.