Historie użytkownika to narzędzie, które wywodzi się z Extreme Programming i stało się de facto sposobem, w jaki zespoły Agile dokumentują i zbierają swoje wymagania. Na temat historyjek użytkownika napisano już wiele (link, link, link), więc powiem tylko o tym, co uważam za ważne w pisaniu dobrych historyjek, ponieważ widzę wiele naprawdę złych historyjek w dzisiejszych czasach.
Dla tych, którzy nie wiedzą, historyjki są lekkim artefaktem, który pozwala nam zarówno uchwycić potrzeby biznesu ORAZ zaplanować pracę. Zazwyczaj są one zapisywane na kartach indeksowych (tak… małych karteczkach 3×5 lub 4×6) w języku biznesu lub klienta. W przypadku historyjek użytkownika, piszemy tylko tyle, aby uchwycić potrzeby użytkownika i nie więcej. Mamy tendencję do postrzegania historyjek nie jako kompletnych specyfikacji wymagań, ale jako placeholdery do późniejszych rozmów pomiędzy programistami a biznesem.
Właściwie użyty brak szczegółowości historyjki użytkownika zapewnia nam dużą użyteczność – możemy użyć tego samego dokumentu, aby porozmawiać o wymaganiu z wysokiego poziomu, przybliżyć szczegóły implementacji i wyskoczyć z powrotem, wszystko w ciągu kilku zdań. Następnie, gdy skończymy rozmawiać o wymaganiach, możemy rozważyć ryzyko, zidentyfikować zależności i stworzyć plan projektu bez konieczności odkładania kartki z indeksem. Wow !!! Nie znam żadnego innego artefaktu wymagań, który pozwalałby nam na taką użyteczność.
Przez lata ludzie, którzy odnieśli prawdziwy sukces z historyjkami, ustalili pewne wspólne cechy, które można znaleźć we wszystkich historyjkach:
- Rola: kto, lub co, będzie korzystało z tej funkcjonalności?
- Cecha (lub zdolność): co zespół dostarczy lub doda po zakończeniu swojej pracy?
- Wartość: dlaczego biznes w ogóle chce tej funkcjonalności? Jaki wpływ na biznes będzie miała ta funkcjonalność?
- Kryteria akceptacji: skąd będziemy wiedzieć, czy ta funkcjonalność została wykonana?
- Szacunek: ile według zespołu będzie kosztować ta funkcjonalność?
IMO, aby historia mogła być uznana za kompletną, musi mieć WSZYSTKIE cechy opisane powyżej. Zauważyłem, że kiedy ludzie mają problem z określeniem wszystkich cech, historie nie są tym, co nazywam dojrzałymi, tzn. nie zostały przemyślane wystarczająco dobrze, aby mogły być użyte przez zespół. Poza tymi cechami, historyjki powinny również spełniać kryteria INVEST (ten świetny artykuł J.B. Rainsbergera również mówi o INVEST).
Mike Cohn napisał świetną książkę na temat historyjek użytkownika. Niestety, przy całej dobroci tej książki, wydaje się, że ludzie skupili się na jednym kawałku śmieci w książce – szablonie historii użytkownika. W swojej książce Mike oferuje szablon, który niektóre zespoły uznały za pomocny przy pisaniu historyjek i który stał się źródłem tak wielu złych historyjek, że nie zamierzam już więcej poświęcać mu więcej atramentu (ani bitów). To, co budzi mój sprzeciw w tym szablonie, to fakt, że powoduje on, że ludzie przestają myśleć, ponieważ mechanicznie wypełniają role, cechy i wartości, a pomijają kryteria akceptacji i szacunki (przypuszczalnie dlatego, że brakuje ich w szablonie). Kiedy widzę, że ludzie zmagają się z historyjkami, dzieje się tak dlatego, że próbują wcisnąć swój biznes w jakiś szablon, który pomógł jakiemuś nienazwanemu zespołowi (który prawdopodobnie już nawet nie używa tego szablonu) pięć lub sześć lat temu i – niespodzianka – nie pasuje do miejsca, w którym są teraz.
Istnieje proces myślowy, który musi nastąpić przed napisaniem pojedynczej historyjki. Kroki, które zazwyczaj widzimy u ludzi, którzy odnoszą sukcesy w pisaniu opowiadań, są wymienione poniżej. Proszę pamiętać, podczas gdy te kroki są liniowe w moim poście, można przeskoczyć do tyłu, do przodu i pominąć, jak to ma sens. Celem jest uzyskanie odpowiedzi na te pytania do czasu zakończenia eksploracji historii użytkownika.
- Jakie są role (lub użytkownicy), którzy będą korzystać z twojego systemu?
- Jakie są ich potrzeby? W jaki sposób produkt pomoże im to osiągnąć?
- Jakie funkcje (lub możliwości) chcesz zapewnić tym rolom?
- Dlaczego te funkcje są wartościowe dla biznesu? Jakiego rodzaju efektów biznesowych możemy się spodziewać po tych funkcjach?
- Jakie są priorytety tych funkcji? Czy złożyliśmy już obietnicę dostarczenia niektórych z nich?
- Skąd będziesz wiedział, czy te funkcje zostały już wykonane?
Na koniec, ludzie mają tendencję do pisania wielu szczegółów na przedniej stronie karty historii. Mam dwie sugestie dla tych ludzi. Po pierwsze, używaj mniejszych kart – naprawdę. Historyjki użytkownika NIE są specyfikacjami ani dokumentami wymagań. Są to po prostu karty indeksowe przechwytujące potrzeby użytkownika i przypominające, że musimy uchwycić te szczegóły implementacji później. Jeśli próbujesz upchnąć coraz więcej na kartce indeksowej, może to być znak, że oprócz historyjek użytkownika potrzebujesz specyfikacji lub jakiegoś rodzaju dokumentacji projektowej. Po drugie, rodzaje szczegółów, które ludzie próbują zapisywać są w rzeczywistości kryteriami akceptacji. Przesuwając te szczegóły do przypadków testowych, utrzymujemy historię w języku biznesowym i skupiamy się na funkcji i wartości, którą dostarcza nasz zespół.