User stories są prostymi, ale niezwykle potężnymi konstrukcjami: opisują elementy funkcjonalności z punktu widzenia użytkownika, wyrażone w solidny, kompaktowy sposób. Odzwierciedlają one potrzeby danej klasy użytkowników i wartość, którą należy uzyskać. Format jest bardzo prosty i łatwy w użyciu. Istnieje kilka odmian, w tym:
dlaczego historie użytkowników?
User stories to doskonały sposób na przejrzyste zdefiniowanie Twojego produktu., Zestaw dobrze zdefiniowanych, priorytetowych historii użytkownika może pomóc wyrazić funkcjonalność produktu za pomocą „prostego języka” – bez szczegółów technicznych i szczegółów implementacji.
podejście „user story” umożliwia sensowne Dyskusje o produktach, zarówno w zespole ds. rozwoju produktu, jak i z zewnętrznymi interesariuszami.
odpowiednio napisane historie użytkowników stanowią solidną podstawę do komunikacji i współpracy — Koncentrując się na tym, co najważniejsze dla użytkownika., W porównaniu do innych sposobów przechwytywania i dokumentowania wymagań użytkowników i specyfikacji produktu, mają one co najmniej następujące zalety:
- historie użytkowników pomagają osiągnąć jasność między zespołami na temat tego, co budować, dla kogo, dlaczego i kiedy. Ponieważ są łatwe do zdefiniowania, zrozumienia i zmiany, mogą stać się standardowym sposobem komunikowania się i podsumowania funkcjonalności produktu zarówno przez członków technicznych, jak i nietechnicznych. Są one niezwykle przydatne w dyskusjach dotyczących zakresu produktu lub jako punkty wejścia do głębokich nurkowań technicznych. Są to kluczowe elementy zwinnej inżynierii.,
- historie użytkowników zachęcają do udziału członków nietechnicznych. Nowoczesne projekty oprogramowania są zazwyczaj złożone, obejmujące szeroką gamę technologii, skrótów i opcji implementacji. W wielu przypadkach terminologia lub język techniczny nie są powszechnie rozumiane – nawet w ramach jednego zespołu-co wprowadza „hałas” i zagrożenia dla projektu. Historie użytkowników usuń ten wymiar techniczny, aby każdy członek zespołu mógł wnieść swój wkład, po prostu myśląc „jako użytkownik”., Zespół może używać nietechnicznego języka i skutecznie współpracować w definiowaniu, kwestionowaniu lub nadawaniu priorytetów historiom użytkowników. Wpływ na współpracę i dynamikę zespołu może być znaczący.
- pomagają w definiowaniu całego produktu — jako zestawu solidnych, mądrze ustalanych priorytetów. Zespół ds. rozwoju produktu może myśleć wielce, zdefiniować super-zestaw historii użytkowników, a następnie przypisać priorytety (które odzwierciedlają wartość oczekiwaną dla użytkownika, złożoność, zależności i inne priorytety biznesowe). Nie musisz podejmować trudnych decyzji i oznaczać przedmiotów jako „poza zakresem”., Zamiast tego możesz przypisać niższy priorytet tym „szalonym” pomysłom, jednocześnie przesuwając historie użytkowników odzwierciedlające podstawową funkcjonalność produktu. Zdefiniowanie „linii cięcia”, które określają zakres dla każdej iteracji, fazy lub wersji, jest wtedy kwestią dostępnych zasobów i szybkości zespołu.
pisanie wspaniałych opowiadań użytkownika
format jest prosty, a pisanie opowiadań jest łatwe. Ale pisanie wspaniałych może być trochę trudne. Oto kilka wskazówek do rozważenia:
User stories ≠ zadania
user stories nie są zadaniami., W rzeczywistości pojedyncza historia może wymagać setek pojedynczych zadań do pomyślnego wykonania. Zadania są o implementacji; user stories są o definicji.
kompilując swoje historie, skup się na zapewnieniu jasności o funkcjach produktu — co, nie jak.
pozostań na wysokim poziomie
musisz być na wysokim poziomie, ale także dokładny i rzeczowy. Historie muszą być proste i solidne. Pomoże to członkom zespołu i interesariuszom dogłębnie zrozumieć potrzeby użytkowników i uniknąć marnowania czasu na wyjaśnienie słów kluczowych, terminologii i akronimów. Wystarczy użyć prostego i dokładnego języka.,
zrozum użytkowników
musisz odkryć i zbadać prawdziwych użytkowników Twojego produktu — uchwycić ich profile, punkty widzenia, oczekiwania i związane z nimi ” punkty bólu.”Badania użytkowników i inne techniki mogą generować spostrzeżenia, które pomogą Ci lepiej zrozumieć użytkowników i ich potrzeby.
bez względu na techniki, zanim zaczniesz kompilować historie użytkowników, potrzebujesz zestawu kluczowych użytkowników — najlepiej w postaci person.,
myśl jako użytkownik
<jako szczególna Klasa użytkownika /persona/roli> część historii użytkownika określa kąt, perspektywę — sposób, w jaki dany użytkownik postrzega funkcjonalność podsumowaną w historii.
ma to kluczowe znaczenie — product owner i cały zespół muszą myśleć z punktu widzenia użytkownika i zrozumieć podstawowe potrzeby i wartość oczekiwaną.,
Think big
opisując produkt jako zaległości w historii użytkowników, nie ma dobrego powodu, aby ograniczać swoje myślenie przez budżet, czas, wykonalność lub koszty.
dobrą praktyką jest duże myślenie i pozwalanie „zwariowanym” historiom użytkowników wchodzić w zaległości. Koszty administracyjne związane z utrzymaniem rozszerzonych zaległości produktowych są niewielkie; wartość z nich wynikająca — pod względem przejrzystości produktów, wizji i możliwości — jest ogromna.,
użyj epiki
epiki mogą przybierać formę opowieści wyższego poziomu, które opisują duże elementy funkcjonalności-zazwyczaj wymagają znacznej ilości pracy, w wielu sprintach. Innym sposobem myślenia o epikach jest grupowanie / kontenery powiązanych, mniejszych historii, wszystkie służące wspólnemu celowi. Epiki są dobre do organizowania swoich historii i zapewnienie szerszego obrazu.,
nie odrzucaj — zamiast tego ustalaj priorytety
biorąc pod uwagę efektywny proces ustalania priorytetów, dobrą praktyką jest wzbogacanie zaległości produktów o nowe historie użytkowników, opisywanie nowych scenariuszy interakcji z użytkownikami, „przypadkowych pomysłów” lub wyników działań w zakresie innowacji produktów.
aby zarządzać potencjalnym szumem, musisz odpowiednio pogrupować i nadać priorytet nowym wpisom. W każdym razie nie odfiltrowuj / nie wyrzucaj przedmiotów z zaległości: przedmioty o zerowym zasięgu są zwykle zapomniane, a przedmioty o nadanym priorytecie pozostają wykrywalne i mogą stać się istotne w odpowiednich warunkach.,
w zależności od kontekstu nadawanie priorytetów historiom użytkowników może być trudnym procesem. Musisz oszacować wartość każdej historii, dla użytkownika i dla firmy. Musisz rozmiar złożoności, oszacować wykonalność i koszt / wysiłek wymagany do zbudowania i Wydania funkcji. Musisz zidentyfikować współzależności w swoim Backlogu-wymuszanie określonej kolejności między pewnymi wpisami.
Konfiguracja sukcesu — nie tylko akceptacji
zespoły często definiują testy akceptacji użytkowników i powiązane kryteria akceptacji. Akceptacja jednak nie wystarczy — musisz się przygotować do sukcesu., Jako menedżer produktu Potrzebujesz więcej niż potwierdzenia ,że „działa tak, jak powinien” lub ” zgodnie ze specyfikacją.”
potrzebujesz metryk, które są również powiązane z bezpośrednimi opiniami użytkowników, aby uchwycić, jak szczęśliwi i zaangażowani są twoi prawdziwi użytkownicy. Podczas gdy akceptacja jest dobra do kontrolowania cyklu życia rozwoju funkcji, sukces dotyczy średnio – / długoterminowego wpływu i wartości stworzonej dla prawdziwych użytkowników produktu. Musisz zdefiniować oba — na poziomie produktu i / lub epickim i / lub fabularnym.
tag stories, dodaj metadane
złożone produkty wymagają setek historii użytkownika., Aby ułatwić nawigację i administrację, musisz skutecznie nazywać, kategoryzować i oznaczać swoje historie. Po kilku pierwszych zmianach historii należy unikać zmiany nazwy lub drastycznej zmiany jej opisu, ponieważ może to wprowadzić zamieszanie i luki w zespole.
właściwe zarządzanie metadanymi swoich historii—status, postęp, linki, priorytety, zasoby, itp. – pomaga odkrywać, monitorować i rozumieć zaległości.
nie przyklejaj się do karteczek!,
tak, ściana pełna kolorowych karteczek wygląda fantazyjnie i pomaga Twojemu zespołowi wyglądać na zajętego i produktywnego 🙂 ale potrzebujesz poważnego systemu i specjalnych narzędzi, które pomogą Ci prawidłowo zarządzać, wzbogacać, ustalać priorytety i dzielić się historiami.,
w szczególnych przypadkach, takich jak burza mózgów lub sesja pomysłów, można przechwycić pierwszy zestaw historii użytkownika za pomocą notatek samoprzylepnych—pod warunkiem, że następnie udokumentujesz je wszystkie w odpowiednim systemie zarządzania produktem. Jeśli tego nie zrobisz, a będziesz trzymać swoje historie na karteczkach samoprzylepnych, prawdopodobnie stracisz możliwości w zakresie przejrzystości, innowacji, wydajności i współpracy.,
nadal potrzebujesz specyfikacji
posiadanie priorytetyzowanego zestawu dobrze zdefiniowanych historii użytkownika jest świetne, ale to dopiero początek. Zespół musi przeanalizować historie-z technicznego punktu widzenia — i stworzyć niezbędne artefakty techniczne.
idealnie, historie są mapowane do konkretnej dokumentacji, która zawiera wszystkie szczegóły techniczne potrzebne z punktu widzenia inżynierii oprogramowania. Zapewniają one punkty wejścia dla szczegółowych dokumentów specyfikacji technicznych i innych szczegółowych artefaktów.,
Wizualizacja pomaga
zawsze włączona (cyfrowa) wizualizacja najważniejszych historii użytkowników według kategorii, motywu lub programu epic może być niezwykle przydatna do współpracy i dostosowania między zespołami i interesariuszami. Wraz ze statystykami, problemami, blokerami i wskaźnikami postępu, Mapa fabuły może być wyświetlana za pomocą interaktywnych ekranów w przestrzeni współpracy.
User stories to świetny sposób na szybkie i dokładne opisanie funkcjonalności oprogramowania lub systemu., Są również bardzo skuteczne w przechwytywaniu wyników sesji burzy mózgów, sprintów projektowych, hackathonów i innych procesów opartych na innowacjach-gdzie strumień pomysłów musi być przechwytywany w zwarty, ustrukturyzowany sposób.