Historyjki użytkowników z przykładami i szablonem

Historyjki użytkowników są zadaniami programistycznymi, które często mają formę „persona + potrzeba + cel”. 

Max Rehkopf Max Rehkopf
Przeglądaj tematy

Streszczenie: historyjka użytkownika to nieformalne, ogólne objaśnienie funkcji oprogramowania napisane z perspektywy użytkownika końcowego. Służy wykazaniu, w jaki sposób dana funkcja oprogramowania przyniesie klientowi korzyści.

Chciałoby się powiedzieć, że historyjki użytkownika są, po prostu, wymaganiami systemowymi oprogramowania. Ale nie są.

Kluczowym elementem tworzenia oprogramowania w nurcie Agile jest stawianie ludzi na pierwszym miejscu, a historyjka użytkownika pozwala umieścić użytkowników końcowych w samym sercu rozmowy. W takich historyjkach używa się języka nietechnicznego, aby dostarczyć zespołowi programistów kontekst do pracy. Po zapoznaniu się z historyjką użytkownika zespół wie, dlaczego tworzy, co tak właściwie tworzy i jakie korzyści zapewni wynik ich pracy.

Historyjki użytkowników są jednym z podstawowych elementów programu Agile. Pozwalają one tworzyć zorientowane na użytkownika ramy postępowania w codziennej pracy, które sprzyjają współpracy, twórczemu myśleniu, a w konsekwencji powstawaniu lepszych produktów.

Czym są historyjki użytkowników w metodyce Agile?

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

Epiki, historyjki i tematy w Agile | Atlassian Agile Coach

Dlaczego warto tworzyć historyjki użytkowników?

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. Gdy ostateczny cel zostanie zdefiniowany, zespół może pracować razem, aby ustalić, w jaki sposób najlepiej zapewnić użytkownikowi korzyści i zrealizować 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ę.

Praca z historyjkami użytkowników

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.

Jak pisać historyjki użytkowników

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 ukończyć 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ę uchwycić 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.

Szablon i przykłady historyjek użytkowników

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.

Rozpoczęcie pracy z historyjkami użytkowników w metodyce Agile

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.

Następny
Estimation