Historyjka użytkownika jest najmniejszą jednostką pracy w obrębie ram postępowania Agile. To nie pojedyncza funkcja, ale cel końcowy wyrażony z perspektywy użytkownika oprogramowania.

Historyjka użytkownika to nieformalne, ogólne objaśnienie funkcji oprogramowania napisane z perspektywy użytkownika końcowego lub klienta. 

Celem historyjki użytkownika jest podkreślenie, w jaki sposób dany fragment prac przełoży się na konkretną korzyść dla klienta. Trzeba podkreślić, że „klientami” nie muszą być zewnętrzni użytkownicy końcowi w tradycyjnym tego słowa znaczeniu. Mogą to być również użytkownicy wewnętrzni lub współpracownicy w organizacji, którzy polegają na pracy Twojego zespołu.

Historyjki użytkowników składają się z kilku zdań napisanych prostym językiem, które nakreślają pożądany rezultat. Nie zawierają szczegółów. Wymagania dodaje się później, gdy zespół już wszystko uzgodni.

Historyjki wpisują się doskonale w ramy postępowania Agile, takie jak Scrum czy Kanban. W Scrum historyjki użytkowników są dodawane do sprintów i „spalane” w trakcie ich realizacji. Z kolei zespoły Kanban wciągają historyjki użytkowników do backlogu i przetwarzają je w ramach przepływu pracy. To właśnie praca nad historyjkami użytkowników pozwala zespołom Scrum doskonalić kompetencje w zakresie szacowania oraz planowania sprintów, co przekłada się na większą dokładność prognozowania oraz zwinność. Dzięki historyjkom zespoły Kanban uczą się zarządzania pracą w toku (WIP) i mogą dalej doskonalić swoje przepływy pracy.

Historyjki użytkowników są również blokami konstrukcyjnymi większych ram postępowania Agile, takich jak epiki czy inicjatywy. Epiki to duże jednostki pracy podzielone na zbiór historyjek. Z kolei wiele epików składa się na inicjatywę. Dzięki tym większym strukturom codzienna praca zespołów programistycznych (nad historyjkami) przyczynia się do realizacji celów organizacyjnych uwzględnionych w epikach i inicjatywach.

Dowiedz się więcej o epikach i inicjatywach

Dla zespołów programistycznych dopiero wkraczających w świat metodyki Agile historyjki użytkowników wydają się czasem dodatkowym krokiem. Czemu nie podzielić po prostu dużego projektu (epiku) na szereg kroków i nie zacząć działać? Jednak to właśnie historyjki dostarczają zespołowi ważnego kontekstu i umożliwiają powiązanie zadań z konkretnymi korzyściami, jakie one zapewniają.

Historyjki użytkowników służą wielu ważnym celom:

• Historyjki kładą nacisk na użytkownika. Lista do wykonania sprawia, że zespół koncentruje się na zadaniach, które trzeba odhaczyć, natomiast zbiór historyjek skupia uwagę zespołu na rozwiązywaniu problemów prawdziwych użytkowników. 

• Historyjki sprzyjają współpracy. Po zdefiniowaniu ostatecznego celu zespół może pracować razem, aby ustalić, w jaki sposób najlepiej zapewnić użytkownikowi korzyści i osiągnąć cel. 

• Historyjki stymulują poszukiwanie twórczych rozwiązań. Historyjki zachęcają zespół do krytycznego i kreatywnego myślenia o najlepszych sposobach osiągnięcia ostatecznego celu. 

• Historyjki nadają impet. Każda kolejna historyjka pozwala cieszyć się zespołowi programistycznemu ze sprostania niewielkiemu wyzwaniu i odniesieniu małego zwycięstwa, co napędza jego dynamikę.  

Zobacz, jak historyjki użytkowników działają w Jira Software

Po napisaniu historyjki trzeba ją zintegrować z przepływem pracy. Zasadniczo historyjkę pisze product owner, menedżer produktu lub menedżer programu, a następnie przekazuje ją do przeglądu.

W trakcie spotkania związanego z planowaniem sprintów lub iteracji zespół decyduje, którymi historyjkami zajmie się w trakcie sprintu. Na tym etapie zespoły omawiają wymagania oraz funkcje wymagane w poszczególnych historyjkach użytkowników. Jest to okazja dla zespołu do omówienia wdrożenia historyjki od strony technicznej oraz kreatywnej. Po uzgodnieniu takie wymagania dodaje się do historyjki.

Innym powszechnym działaniem w trakcie tego spotkania jest ocena historyjek w oparciu o stopień ich złożoności lub czas potrzebny do ukończenia. Zespoły dokonują odpowiednich szacunków, wykorzystując techniki, takie jak rozmiary t-shirtów, ciągi Fibonacciego lub Planning Poker. Historyjka powinna obejmować wycinek prac możliwy do zrealizowania w trakcie jednego sprintu, dlatego przy opracowywaniu przez zespół specyfikacji każdej historyjki trzeba podzielić historyjki, które nie mieszczą się w tych ramach czasowych.

Podczas pisania historyjek użytkowników warto wziąć pod uwagę następujące kwestie:

• Definicja stanu „gotowe” — zasadniczo historyjkę uznaje się za „gotową”, gdy użytkownik jest w stanie wykonać nakreślone zadanie. Trzeba jednak pamiętać o zdefiniowaniu, jakie konkretnie jest to zadanie. 

• Zarys zadań głównych i podrzędnych — zdecyduj, jakie kroki trzeba wykonać i kto odpowiada za realizację każdego z nich. 

• Persony użytkowników — dla kogo? Jeśli użytkowników końcowych jest wielu, warto rozważyć napisanie wielu historyjek. 

• Uporządkowane kroki — napisz historyjkę dla każdego kroku składającego się na większy proces. 

• Wysłuchanie opinii — porozmawiaj ze swoimi użytkownikami i postaraj się ująć problem lub potrzebę ich własnymi słowami. Nie musisz wymyślać historyjek, jeśli możesz uzyskać je od swoich klientów. 

• Czas — czas jest drażliwym tematem. Wiele zespołów programistycznych w ogóle unika dyskusji o czasie, opierając się raczej na technikach szacowania. Historyjki powinny być możliwe do ukończenia w trakcie jednego sprintu, dlatego te, które mogą zająć wiele tygodni, a nawet miesięcy, należy podzielić na mniejsze historyjki lub potraktować jako odrębny epik. 

Gdy historyjki użytkowników zostaną wyraźnie zdefiniowane, upewnij się, że są one widoczne dla całego zespołu.

Historyjki użytkowników często wyraża się w formie prostego zdania o następującej strukturze:

„Jako [persona] [chcę], [aby]”.

Przyjrzyjmy się poszczególnym członom: 

• „Jako [persona]”: dla kogo tworzymy nasz produkt? Nie chodzi nam wyłącznie o stanowisko zajmowane przez daną osobę, ale reprezentację typowej osoby. Dla Marka. Członkowie naszego zespołu powinni mieć jednakowe pojęcie na temat tego, kim jest Marek. Dobrze, jeśli udało nam się porozmawiać z wieloma Markami. Rozumiemy, jak ta osoba pracuje, jak myśli i co czuje. Potrafimy wczuć się w sytuację Marka.

• „Chcę”: tutaj opisujemy jego zamiary, a nie funkcje, z których korzysta. Co próbuje tak naprawdę osiągnąć? Ta informacja nie powinna zawierać żadnych wskazówek dotyczących implementacji. Jeśli opisujesz jakąkolwiek część interfejsu użytkownika, a nie wyłącznie cel, jaki użytkownik stara się osiągnąć, idziesz w złym kierunku.

• „Aby”: w jaki sposób jego bezpośrednia chęć zrobienia czegoś wpisuje się w szerszą perspektywę? Jakie ogólne korzyści próbuje osiągnąć? Jaki wygląda problem wymagający rozwiązania?

Przykładowe historyjki użytkowników mogą wyglądać następująco:

• Jako Marek chcę zaprosić moich znajomych, aby wspólnie korzystać z tej usługi.

• Jako Marta chcę uporządkować swoją pracę, aby zyskać nad nią lepszą kontrolę. 

• Jako kierownik chcę mieć możliwość monitorowania postępów moich współpracowników, aby lepiej informować o naszych sukcesach i porażkach. 

Taka struktura nie jest wymagana, ale ułatwia zdefiniowanie momentu zakończenia prac. Gdy dana persona jest w stanie uzyskać pożądane korzyści, historyjka jest gotowa. Zachęcamy zespoły do zdefiniowania własnej struktury, a następnie do jej stosowania.

Historyjki użytkowników opisują cele i zadania leżące u podstaw codziennej pracy członków zespołu programistycznego i często mają formę persona + potrzeba + cel. Aby proces przebiegał płynnie, konieczne jest uświadomienie sobie ich roli jako źródła rzetelnych informacji na temat tego, co dostarcza Twój zespół i dlaczego to robi.

Zacznij od oceny kolejnego lub najpilniejszego dużego projektu (np. epiku). Podziel go na mniejsze historyjki użytkowników i doprecyzuj je pracując razem z zespołem programistycznym. Gdy historyjki zostaną opublikowane w miejscu, w którym cały zespół będzie mógł się z nimi zapoznać, można przystąpić do pracy.