Pisząc o Scrum nie można zapomnieć o historyjkach użytkownika.
Co prawda Scrum nie określa sposobu opisywania elementów rejestru produktu i pozwala na dodanie tam różnych artefaktów to historyjka użytkownika stałą się jednym z symboli metodyki Scrum.
„User story, czyli historia użytkownika, opowiada o kliencie lub użytkowniku korzystającym z produktu. Zawiera imię, krótki opis oraz kryteria akceptacji czy warunki, które muszą być spełnione, by historia była kompletna. User story może być ogólne lub szczegółowe; ogólne historie zwane są epikami„[2].
Charakterystyczne dla historyjek użytkownika jest opisanie tego faktu w postaci:
„Jako <rola użytkownika> chcę…” – przykładowo: Jako Sprzedawca chcę dodawać do zamówienia klienta opcjonalne ubezpieczenie.
Rubin w swojej książce [1] definiuje kilka typów historyjek. Oto one:
- historyjka użytkownika (ang. user story) — wygodny format służący do wyrażania pożądanej wartości biznesowej w różnorodnych elementach rejestru produktu. Historyjki użytkownika są konstruowane w taki sposób, aby mogły być zrozumiane w łatwy sposób zarówno przez ludzi ze strony biznesowej, jak i przez inżynierów. Mają prostą strukturę i zazwyczaj wyrażone są w formie zdania takiego jak „Jako <rola użytkownika> chcę osiągnąć <cel>, abym mógł otrzymać <korzyść>”. Są doskonałym miejscem do prowadzenia konwersacji. Mogą być pisane z różnym poziomem uszczegółowienia, a następnie stopniowo wzbogacane o detale.
- historyjka zdolna do implementacji (ang. implementable story) — historyjka użytkownika o rozmiarze wystarczająco małym, aby zmieścić się swobodnie w sprincie. Równoznaczne z historyjką nadającą się do sprintu (ang. sprintable story).
- historyjki techniczne (ang. technical stories) — historyjki „użytkownika” (należące do rejestru produktu), które nie dostarczają widocznej wartości dla użytkownika, ale w sposób istotny rozbudowują architekturę lub infrastrukturę potrzebną do dostarczenia takiej wartości w przyszłości.
- historyjka z rejestru produktu (ang. product backlog item — PBI) — cecha produktu, błąd lub (sporadycznie) zadanie inżynieryjne mające wartość z punktu widzenia właściciela produktu. PBI to także element w rejestrze produktu.
Scrum pozwala, a raczej reaguje na konieczność dzielenie elementów w rejestrze produktu ze względu na ich stopień szczegółowości. W taki oto sposób powstały epiki, zwane w literaturze także eposami.
„Historyjki, które są duże, nazywa epikami (ang. epics). Nie ma jakiegoś konkretnego algorytmu, który w sposób jednoznaczny pozwoliłby nam stwierdzić, czy dana historyjka jest już epikiem, czy nie. Zespoły często pytają, ile punktów powinna mieć historyjka, żeby można było powiedzieć, że nie jest epikiem. Zazwyczaj stosuję zasadę, że rozmiar historyjki nie powinien przekraczać połowy wartości prędkości zespołu, który będzie ją rozwijał. Jeżeli np. średnia prędkość zespołu wynosi 30 punktów, wielkość historyjki powinna oscylować wokół 15 punktów. Wszystko, co będzie większe, może być potraktowane jako epik„[4].
Inny sposób definiowania epik ma Rubin, który pisze [1]: „Epos to duża historia użytkownika o rozmiarze sięgającym nawet kilku miesięcy, która może wypełnić całą wersję dystrybucyjną lub nawet kilka z nich. Eposy są dobrym sposobem przechowywania wymagań o dużych rozmiarach. W odpowiednim czasie eposy są stopniowo przekształcane na zbiory małych historyjek użytkownika.„
Dodatkowo Scrum pozwala na grupowanie historyjek. Taka agregacja historyjek nosi nazwę tematów (ang. themes). Temat to zbór historyjek powiązanych ze sobą wspólnym czynnikiem. Ważne jest to, że każdy Zespół Scrumowy może zupełnie inaczej może określić wielkość epik i historyjek. Dla mnie zazwyczaj epika to proces biznesowy. Każdą aktywność procesu biznesowego opisuje od jednej do kilku historyjek użytkownika.
A jak Ty raisz sobie ze złożonością epik i historyjek?
Pisząc ten wpis korzystałem oraz umieściłem cytaty z następujących pozycji:
[1] „Scrum. Praktyczny przewodnik po najpopularniejszej metodyce agile” – Kenneth S. Rubin
[2] „Zarządzanie projektami ze SCRUM. Twórz produkty, które pokochają klienci” – Roman Pichler
[3] „Zwinne projekty w klasycznej organizacji” – Henning Wolf
[4] „Scrum. O zwinnym zarządzaniu projektami. Wydanie II rozszerzone” – Mariusz Chrapko
Szczególnie polecam pozycje 1 i 4, które to moim zdaniem są bardzo dobrą literaturą. Podane linki są linkami afiliacyjnymi.
Reklama
