Kiedy zaczynasz zanurzać się w zwinności, pierwszą rzeczą, którą zauważysz, jest to, jak skoncentrowane jest to podejście na użytkowniku. Przesuwa nacisk z samego kodowania i projektowania na dostarczanie rzeczywistej wartości użytkownikom końcowym, interesariuszom i ogólnie firmie.
zwinne historie użytkowników są istotnym elementem tej ideologii, która pozwala określić, jakie korzyści przyniesie produkt docelowym odbiorcom (i ostatecznie, jak zwiększy wskaźniki KPI i inne wskaźniki).,
w Stormotion love Stories. Jako elastyczny zespół aktywnie z nich korzystamy, aby lepiej zrozumieć, jakie korzyści płyną z produktów naszych klientów dla ich użytkowników końcowych. Napędzają również współpracę i kreatywność, popychając nas do nietrywialnych rozwiązań programistycznych.,
więc dzisiaj podzielimy się naszą wiedzą i doświadczeniem w tej sprawie, aby pomóc Ci poprawić swoje umiejętności pisania historii. Smacznego!
🤔 Co to jest User Story?
User Stories są jednym z podstawowych elementów metodyki zwinnej. Jednak często są one pomieszane z wymaganiami oprogramowania, co nie jest prawdą. Czym jest User Story?
User Story jest małym (właściwie najmniejszym) dziełem, które reprezentuje pewną wartość dla użytkownika końcowego i może być dostarczone podczas sprintu.,
głównym celem tego elementu jest umieszczenie użytkowników końcowych w centrum rozmowy i uchwycenie funkcjonalności produktu z ich perspektywy. Dzięki temu deweloperzy lepiej rozumieją, co, dla kogo i dlaczego budują.,
świetne historie użytkowników zawsze pasują do zestawu kryteriów INVEST według Bill Wake:
- niezależne – mogą być rozwijane w dowolnej kolejności, a zmiany w jednym wątku użytkownika nie wpływają na pozostałe.
- negocjowalne – to do zespołu należy decyzja, jak je wdrożyć; nie ma sztywno ustalonego workflow.
- Valuable-każda historia użytkownika dostarcza użytkownikowi końcowemu oddzielną jednostkę wartości.,
- szacowany-dość łatwo odgadnąć, ile czasu zajmie opracowanie historii użytkownika.
- mały-powinien przejść cały cykl (projektowanie, kodowanie, testowanie) podczas jednego sprintu.
- Testable-powinny istnieć jasne kryteria akceptacji, aby sprawdzić, czy historia użytkownika jest odpowiednio zaimplementowana.
format User Story (który jest również używany przez zespół Stormotion) jest dość prosty i krótki:
wygląda jak nic trudnego, co?, Oto kilka przykładów User Stories, które pasują do jakiegoś Zmyślonego projektu aplikacji taksówkowej:
- jako kierowca chcę blokować źle zachowujących się pasażerów, aby nigdy więcej nie pokazywali mi ich.
- jako pasażer chcę połączyć kartę kredytową z moim profilem, aby móc zapłacić za przejazd szybciej, łatwiej i bez gotówki.
- jako kierowca chcę dodawać zdjęcia mojego samochodu w profilu, aby przyciągnąć więcej użytkowników.
- jako pasażer chcę, aby Wyświetlono kilka dostępnych kierowców, aby móc wybrać najbardziej odpowiednią dla mnie opcję.,
brzmi dość łatwo, ale tworzenie historii użytkownika nie jest często takie proste. Jednak później podzielimy się naszymi sprawdzonymi wskazówkami, które pomogą Ci zrobić tylko dobre zdjęcia.
czy jest coś jeszcze?
pomimo, że właśnie odkryliśmy, że zwinne historie użytkowników są niezależne i powinny być rozumiane jako całkowicie oddzielne jednostki pracy, czasami są pogrupowane razem., Więc pracując z nimi, prawdopodobnie spotkasz się i użyjesz koncepcji epickiej. O co chodzi?
epopeja to dzieło na wysokim poziomie, które łączy się z grupą powiązanych ze sobą historii.
w Stormotion używamy Epic do opisywania bardziej złożonych zadań i tworzenia przejrzystej hierarchii, która pozwala łatwiej zarządzać rozwojem i dostarczać nową wartość użytkownikom, pracując nad większym celem. Jednak sam format User Story pozostaje taki sam.,rement, który powinien być dostarczony podczas 1 sprintu
wyobraź sobie, że budujesz aplikację randkową., niesamowite jestem
tak więc, epiki zapewniają nam Widok na wysokim poziomie naszych celów i jak zmierzamy do nich., Pomaga nam to również w procesie ustalania priorytetów, ponieważ możemy sprawdzić, które epiki wymagają naszej uwagi najbardziej, a zatem, które historie należy wdrożyć jako pierwsze.
Oh, jeszcze jedno!
nie zapomnij dodać kryteriów akceptacji.
kryteria akceptacji to zestaw warunków, które są używane do potwierdzenia zakończenia wątku.,
ponadto warunki te zapewniają nam głębsze i lepsze zrozumienie, ponieważ zawierają kluczowe informacje o tym, jak działają historie. Wykorzystajmy ponownie jeden z przykładów User Story z początku artykułu:
Jakie kryteria akceptacji można zastosować do tej historii?
- aplikacja pokazuje kierowców, którzy byli online w ciągu ostatnich 20 minut i nie mają ciągłej jazdy.
- aplikacja pokazuje tylko 5 sterowników, które są najbliżej użytkownika.
- użytkownik może przeglądać profile tych sterowników, w tym ich zdjęcia i stawki.
jak widać, teraz nie tylko znamy wartość tej historii dla użytkowników, ale także rozumiemy niektóre kluczowe cechy, które wymagają szczególnej uwagi podczas implementacji.,
możesz jednak wybrać, jak szczegółowe będą kryteria akceptacji. Może wahać się od „po prostu pozwól mu działać w dowolny wygodny sposób” do jeszcze bardziej szczegółowych zestawów warunków niż w powyższym przykładzie.
to w dużej mierze zależy od zespołu programistów, więc nie ma „poprawnej odpowiedzi”. Jeśli twój zespół potrzebuje wskazówek i jasnych, bez miejsca na interpretację zadań, lepiej trzymaj się szczegółowych instrukcji, jak powinny wyglądać historie. W przeciwnym razie, podejście „just get it done” może również działać.,
Wow, dużo mówi się o historiach użytkowników. Ale dlaczego są tak ważne dla zespołów zwinnych?
👍 jakie są korzyści z tworzenia User Stories?
Jeśli kiedykolwiek byłeś zaangażowany w pracę ze zwinnymi frameworkami, już wiesz, że zarówno zespoły Scrum, jak i Kanban w znacznym stopniu korzystają z pisania historii użytkowników.,
w Kanban zespoły gromadzą historie w Backlogu, a następnie uruchamiają je jeden po drugim, aby wspieraj przepływ prac w toku. Pomaga to na bieżąco śledzić i poprawiać wskaźniki KPI dla zespołów programistycznych.
zespoły Scrum (które zwykle preferujemy w Stormotion) również uwielbiają historie użytkowników. Aktywnie wykorzystujemy je do szacowania, ustalania priorytetów i planowania sprintów, co pomaga nam być elastycznym i elastycznym na wszelkie zmiany., Jest to szczególnie korzystne, gdy pracujemy ze startupami, które są na etapie MVP i mają ograniczone zasoby, zanim oddamy swój projekt do inwestorów anielskich.
oprócz wyżej wymienionych, istnieją pewne żywe korzyści, które są wspólne dla wszystkich zwinnych zespoły:
- koncentrują się na wartości biznesowej., Pomaga to uczynić Twoją aplikację nie tylko dobrze zbudowaną z technicznego punktu widzenia, ale także użyteczną dla użytkowników końcowych.
- Włącz kreatywność. Ponieważ zawiera minimalną ilość informacji, twój zespół może swobodnie kierować kreatywnymi pomysłami, aby znaleźć najlepsze rozwiązanie do wdrożenia historii.
- Twój projekt staje się łatwiejszy do zarządzania. W Stormotion wiemy, że łatwiej jest pracować z małymi i przewidywalnymi zwinnymi historiami użytkowników niż z dużymi złożonymi zadaniami.
- inspirują zespół! Każdy deweloper uwielbia to słodkie uczucie małej wygranej, które motywuje go do jeszcze cięższej pracy.,
teraz zagłębimy się w proces tworzenia User Story!
How jak pisać User Stories: Our Workflow
przechodzimy do najbardziej ekscytującej części naszego artykułu. Zanim jednak podzielimy się naszymi instrukcjami krok po kroku, aby napisać historię użytkownika, ważne jest, aby dowiedzieć się 2 zasadnicze pytania: kto i kiedy je tworzy.
kto jest odpowiedzialny za tworzenie User Story?,
z reguły historie są pisane głównie przez właścicieli produktów, ponieważ ich obowiązkiem jest utrzymanie zaległości wypełnionych zadaniami. Nie zapominaj jednak, że Agile opiera się na komunikacji i wymianie opinii między ekspertami. Więc…
niekoniecznie oznacza to, że powinny być pisane tylko przez Właściciela Produktu. Im więcej osób dołącza do rozmowy, tym lepiej.
w Stormotion historie są pisane przez wszystkich członków zespołu związanych z biznesową stroną projektu (menedżerów sprzedaży, marketerów, właściciela produktu itp.,), ponieważ pozwala nam spojrzeć na przyszłą aplikację z perspektywy każdego potencjalnego użytkownika. Odpowiedzialność Product Ownera w tym przypadku polega na potwierdzeniu, że spełniają one kryteria inwestowania.
kiedy tworzone są historie użytkowników?
Spotkanie pisarskie w naszej siedzibie odbywa się zwykle tuż przed rozpoczęciem projektu., Wolimy się przygotować, aby upewnić się, że projekt pójdzie dobrze od pierwszego do ostatniego dnia.
później możemy użyć naszej listy Scrum User Story, aby przygotować bardziej szczegółowe szacunki (na przykład do końca etapu odkrywania), ustalić priorytety rozwoju funkcji sprintów i tak dalej.
uzupełniamy również oryginalną listę, gdy pracujemy nad projektem o nowe historie, aby być na bieżąco z wymaganiami naszych klientów.,
jakie są kroki, aby napisać świetne zwinne historie użytkowników?
Po pierwsze, przypomnijmy Ci wspólny szablon User Stories:
jako , chcę, aby
wydaje się krótki i łatwy do napisania. Przy okazji, możesz stworzyć własny szablon User Story. Jednak w Stormotion mamy specyficzny przepływ pracy, który pomaga nam dostarczać najlepsze historie:
- stwórz listę użytkowników końcowych. Określ, czym jest ich ” ból ” lub „potrzeba”, którą próbujesz rozwiązać.
- określ, jakie działania chcą podjąć.,
- dowiedz się, jaką wartość przyniesie to użytkownikom, a ostatecznie Twojemu produktowi. Zadaj sobie również pytanie – czy jakaś strona nam za to zapłaci?
- omów kryteria akceptacji i optymalną strategię wdrożenia.
przejrzyjmy je teraz!
Krok 1: pomyśl o „kto”
jest to pierwszy i, być może, najbardziej fundamentalny krok. Przed napisaniem historii użytkownika powinieneś wiedzieć, kim są użytkownicy końcowi Twojego produktu. A co ważniejsze – jakie mają potrzeby, które starasz się pokryć.,
podczas warsztatów opowiadania staramy się pomijać rolę „użytkownika”. Może być stosowany do każdej osoby – od klientów po administratorów-i dlatego nie odzwierciedla osobowości poszczególnych grup docelowych, sposobu, w jaki wchodzą one w interakcję z aplikacją.
Jeśli chcesz osiągnąć naprawdę świetne wyniki, możesz chcieć jeszcze bardziej zanurzyć się w swoich odbiorcach., Zamiast po prostu nazywać użytkowników po ich roli (na przykład „kierowca”) spróbuj stworzyć coś w rodzaju osoby kupującej.
Oto kilka wskazówek z własnego doświadczenia:
- wszystko zależy od użytkownika. Nie o deweloperach. A nawet nie o Product Ownerze. Każda historia powinna być cenna dla jakiejś grupy użytkowników końcowych.
- nie myśl o użytkownikach tylko jako o klientach zewnętrznych. To prawda, że Twoje historie będą głównie o nich. Ale prawdą jest również, że musisz wziąć pod uwagę użytkowników wewnętrznych, takich jak Administratorzy, redaktorzy itp.
- Poczuj empatię. Nadaj nazwę „użytkownikowi”., Pomyśl o jego mobilnych zwyczajach, jaki problem Twoja aplikacja zostanie dla niego rozwiązany i jak zamierzasz uczynić tę ścieżkę łatwiejszą i szybszą. Pamiętaj o ludziach, których znasz z prawdziwego życia i którzy pasują do tego portretu; poczuj, jak odnosisz się do tej grupy docelowej.
Krok 2: pomyśl o „co”
teraz mamy kilka grup użytkowników końcowych. Kolejnym krokiem jest zdefiniowanie, jakiej funkcjonalności oczekuje każdy użytkownik, w jaki sposób będzie współdziałał z aplikacją.,
są to główne zasady, które należy pamiętać podczas pisania akcji dla Kanban lub Scrum user story:
- jedna akcja na historię. Jeśli chcesz napisać coś w stylu „jako klient chcę przeglądać przedmioty i dodawać je do koszyka”, lepiej Podziel to na 2 osobne historie.
- opisz intencję, a nie cechę., Na przykład zamiast „chcę zarządzać swoim profilem” utwórz kilka historii, takich jak „chcę się zarejestrować”, „chcę przesłać swoje zdjęcie profilowe”, „chcę połączyć moją kartę kredytową z moim profilem” – każda historia będzie miała inną wartość.
- krótko. Użytkownicy nie dbają o to, jakiej biblioteki użyjesz, aby pozwolić im przeglądać listę przedmiotów, więc zostaw wszystkie szczegóły techniczne na bok.
- unikaj opisywania interfejsu użytkownika. Zdefiniowaliśmy historie jako negocjowalne, pamiętasz? Dlatego wszystkie dobre przykłady User Story nie zawierają żadnych szczegółów interfejsu użytkownika., Więc nie próbuj komponować żadnego specjalnego sposobu na ich wdrożenie (zrobimy to później).
Krok 3: pomyśl o „Dlaczego”
wreszcie, ostatni fragment naszego szablonu User Stories jest poświęcony wartości, którą użytkownicy otrzymują po wykonaniu akcji. Może się wydawać, że to nic wielkiego, ale często jest to najtrudniejsza część rozwoju historii użytkownika.,
jednak twoja sekcja powinna zawsze odpowiadać Twoim metrykom i KPI. Powinno to albo poprawić UX, zwiększyć wskaźniki retencji, skrócić podróż użytkowników do rozwiązania problemu lub cokolwiek innego. Każda historia powinna przyczynić się do ogólnego celu produktu.,
Jeśli nie możesz odpowiedzieć, jaką wartość ta funkcja przynosi użytkownikom końcowym i Twojemu produktowi, robisz coś złego.
na przykład istnieje kilka przykładów Historii użytkowników z dobrze napisaną wartością dla naszego projektu aplikacji do zamawiania żywności:
- jako klient chcę otrzymywać powiadomienia, gdy pojawią się nowe gorące oferty, aby nigdy nie przegapić najlepszych ofert. .
- jako kierownik restauracji chcę uzupełnić opis dania w menu o zdjęcie, aby wyglądało atrakcyjniej dla klientów. .,
Krok 4: omówienie historii
wreszcie, zawsze omawiamy historie użytkowników po ich utworzeniu. Nawet jeśli wydaje się, że nie ma o czym rozmawiać.
podczas tego Q&sesji, prosimy autora opowiadania o podanie więcej szczegółów lub wyjaśnienie czegoś w razie potrzeby. Pomaga nam zrozumieć, jak powinien działać i uzgodnić kryteria akceptacji., W ten sposób przeglądamy wszystkie przykłady historii użytkowników aplikacji mobilnych jeden po drugim.
następnie przeprowadzamy burzę mózgów z całym zespołem pracującym nad projektem. Pozwala nam to znaleźć najlepsze sposoby implementacji User Stories z perspektywy technologii.
czyli jak pisać historie użytkowników w skrócie. Nasz oddział Stormotion używa również następujących wskazówek podczas pracy nad tym zadaniem:
- zacznij od Epic., Zwykle łatwiej jest przejść od bardziej złożonych zadań do bardziej szczegółowych, więc spróbuj pisać epiki, a następnie podzielić je na historie.
- posłuchaj opinii. Czasami nie musisz odgadywać historii – poproś prawdziwych użytkowników o opinię i wykorzystaj ich pomysły jako źródło inspiracji.
- nie wprowadzaj szczegółów zbyt wcześnie. Lepiej jest przeprowadzić burzę mózgów przed każdym sprintem, aby omówić, jak wdrożyć planowane historie.
Conclusion wnioski
User Stories są istotnym elementem zwinnego podejścia, które może przynieść wiele korzyści dla Twojego projektu., Ważne jest jednak, aby napisać je poprawnie, co wymaga trochę czasu i umiejętności.,Kryteria T, co oznacza, że są:
- niezależny
- Negocjowalny
- wartościowy
- szacowany
- Mały
- Testowalny
wspólny szablon User Stories zawiera użytkownika , akcję i wartość (lub korzyść) i zazwyczaj wygląda tak:
user stories pomogły ci stale podnosić wartość Twojego produktu, szacować wysiłki rozwojowe w odpowiedni sposób i ustalać priorytety rozwoju funkcji na etapach MVP i post-MVP.,
