Jak pisać historie użytkowników: kompletny przewodnik

Historie użytkowników są istotną częścią prawidłowego zwinnego tworzenia oprogramowania: przyjrzyjmy się ich roli i nauczmy się pisać historie użytkowników.

Zwinne ramy są popularnym, skutecznym sposobem strukturyzacji tworzenia oprogramowania i delegowania zadań. Pisanie historii użytkowników (nie mylić z tym, jak napisać referencje) jest narzędziem w zwinnym programowaniu, które pozwala programistom zrozumieć, co należy zrobić i jak spełnić wymagania. To czyni je bardzo ważnym miejscem startowym – ale oznacza to również, że muszą być starannie skonstruowane. Oto, co powinieneś wiedzieć.

Co to jest historia użytkownika?

Jest to termin używany w tworzeniu oprogramowania w zwinnych ramach. Historia użytkownika jest zwykle uważana za najmniejszą jednostkę w zwinnym projekcie lub pierwszy krok w spełnieniu wymagania. Powstają, gdy projekt jest w pełni zaplanowany.

Więc, co to dokładnie oznacza? Każda funkcja oprogramowania ma (lub powinna mieć) określony cel, gdy jest dodawana do projektu. Ten cel powinien wpłynąć na cały jego rozwój i sposób włączenia go do ogólnych ram. Deweloperzy mogą odwoływać się do tego celu w razie potrzeby, aby podejmować decyzje, zwłaszcza dotyczące podziału celów i ustalania priorytetów. „Historia użytkownika” to po prostu sposób na opisanie celu funkcji.

Historie użytkowników są pisane z perspektywy użytkownika, zwykle w jednym lub dwóch zdaniach. Przechwytują punkt widzenia użytkownika i to, co ten użytkownik chce zrobić. Po ukończeniu dobre historie użytkowników są łatwym sposobem na rozmowę o celach strategicznych, o tym, jakie funkcje można bezpiecznie odrzucić lub które należy dodać, i wiele więcej.

Jak napisać historię użytkownika

Krok 1. Uzyskaj dane wejściowe

Uzyskaj informacje od właścicieli, potencjalnych użytkowników i kierowników projektów. Silna historyjka użytkownika wymaga wielu danych wejściowych, aby była dokładna. Uzyskaj jasne wyjaśnienia od tych grup, co chcą zrobić. Pamiętaj, że nie powinno to przekładać się bezpośrednio na historię użytkownika, ale dostarczy niezbędnych informacji. Właściciel może powiedzieć: „Potrzebuję ludzi, którzy będą mogli płacić PayPalem w mojej aplikacji”, co jest bardzo przydatne, ale nie sama historia użytkownika.

Krok 2. Zdecyduj, w jaki sposób tworzone są historie użytkowników

To zależy od twojego przepływu pracy. Na wczesnych etapach historie użytkowników są rejestrowane na kartach indeksowych lub karteczkach samoprzylepnych podczas planowania ogólnych ram. Później są one włączane do oprogramowania do zarządzania projektami. Niektórzy członkowie zespołu pomijają etap karteczek samoprzylepnych, podczas gdy inni na nim polegają – w zależności od tego, co Ci odpowiada.

Krok 3. Zdefiniuj, zdefiniuj, zdefiniuj

Zdefiniuj użytkownika: Za pomocą danych wejściowych możesz teraz zdefiniować użytkownika. Pamiętaj, że nie zawsze jest to użytkownik końcowy funkcji produktu; może się różnić w zależności od typu użytkownika. W razie potrzeby utwórz persony użytkowników. Zdefiniuj akcję, którą podejmuje użytkownik, i zdefiniuj cel użytkownika w podejmowaniu tej akcji. Uwzględnij te kluczowe informacje podczas tworzenia historii użytkownika, aby przemawiać do docelowych odbiorców.

Krok 4. Napisz historię

Zacznij pisać swoją historyjkę użytkownika, powinna składać się tylko z jednego lub dwóch zdań, aby przykuć uwagę czytelnika. Kuszące jest bycie precyzyjnym i technicznym, ale ogólny język, taki jak deklaracja misji, może być pomocny. Wyjaśnij historię i upewnij się, że można ją rozwiązać lub ukończyć, abyś mógł spojrzeć wstecz i potwierdzić: „Tak, użytkownicy mogą teraz to zrobić!”.

Krok 5. Podziel na dalsze kroki

Historie użytkowników mogą wymagać wielu kroków, aby osiągnąć cel końcowy, co może wymagać odrobiny restrukturyzacji w zależności od używanej zwinnej struktury. Pamiętaj, że historyjka użytkownika jest zawsze najmniejszą jednostką w frameworku. Na tym szczegółowym poziomie wdrożenie historii użytkowników powinno zająć kilka dni.

Jeśli wygląda na to, że zajmą one znacznie więcej czasu, jest to znak, aby ponownie odwiedzić i sprawdzić, czy doświadczenie użytkownika wymaga dalszego podziału i restrukturyzacji. Jeśli zostaną dodane nowe wymagania, będą one również musiały zostać podzielone na historie użytkowników. Chociaż te kilka zdań stanowi rdzeń skutecznych historii użytkowników, można je również rozszerzać w miarę postępu prac. Przyjrzyjmy się temu bliżej.

Jakie są 3 C w User Stories?

Karta : Faza karty odnosi się do pisania historyjek użytkownika dla zespołu programistów w zdaniu lub dwóch. Nazywa się to kartą, ponieważ historie użytkowników były pierwotnie zapisywane na kartach indeksowych, a wiele zespołów nadal woli robić to w ten sposób. Karta jest rdzeniem specyficznych wymagań programowych i punktem wyjścia dla wszystkich dyskusji. Łatwo też sprawdzić, czy historia użytkownika nie jest za długa – jeśli nie mieści się na fiszce, którą każdy może przeczytać, należy ją skrócić.

Rozmowa : Po utworzeniu zdań z kart nadszedł czas na dopracowanie szczegółów. Zwykle zaczyna się od serii pytań między programistami, na przykład: „Ile czasu zajmie wdrożenie tego rozwiązania?” lub „Jak możemy włączyć to działanie?” lub „Czy ta historia użytkownika jest tutaj niezbędna?” I tak dalej.

Ta dokładna analiza historii użytkownika prawdopodobnie zaowocuje dodatkowymi pytaniami, które należy zadać kierownikom projektów i właścicielom produktów, których w razie potrzeby należy włączyć do rozmowy. W miarę trwania konwersacji historie użytkowników mogą być zmieniane, udoskonalane, łączone lub usuwane, dopóki wszyscy nie znajdą się na tej samej stronie. Po sfinalizowaniu historii użytkowników są one przenoszone do implementacji, co jest znakiem, że rozmowa jest zasadniczo zakończona.

Potwierdzenie : Potwierdzenie polega na testach akceptacyjnych, czyli kryteriach akceptacji. Gdy zmiana została wdrożona, a programiści zgłoszą, że jest gotowa – że historia użytkownika została usatysfakcjonowana – czas ją przetestować.

Testy akceptacyjne powinny być tworzone przy udziale właściciela produktu i bezpośrednio powiązane z historyjką użytkownika. W najlepszym przypadku użytkownik po prostu próbuje zrobić to, co wskazuje historia użytkownika i sprawdza, czy może. Ale testy akceptacyjne mogą się różnić i nie zawsze są tworzone z myślą o historiach użytkowników, tak jak powinny. Jeśli stwarza to problem, czas wrócić do kroku Konwersacja, aż testy akceptacyjne i historie użytkowników zostaną odpowiednio dopasowane. Jeśli wszystkie testy akceptacyjne zostaną zakończone, historia użytkownika jest zachwycona. Teraz nadszedł czas, aby przejść do następnego kroku w rozwoju produktu lub udostępnić tę funkcję.

Czwarte C? : Co ciekawe, niektórzy twierdzą, że istnieje istotny kontekst 4. C. W tym przypadku historia użytkownika jest wyświetlana razem z innymi historiami użytkownika w szerszych ramach projektu. Tutaj programiści pytają, czy historia użytkownika płynnie uzupełnia inne historie użytkownika lub czy istnieją luki – rzeczy, które użytkownik musi zrobić lub zrozumieć, a które zostały pominięte między historiami użytkownika.

Idealnie jest to zauważane podczas fazy Konwersacji, ale nie zawsze tak się dzieje. Niektóre zespoły programistyczne mogą chcieć ostatecznego przeglądu tego, w jaki sposób ukończona historia użytkownika pasuje do większej całości i czy należy wykonać dalsze prace.

Jaki jest dobry format historii użytkownika?

Przyjrzyjmy się dwóm technikom formatowania, które są bardzo pomocne przy tworzeniu zdań historyjek użytkownika. Pierwsza jest bardzo prosta: „Kto, co i dlaczego?” W szablonie zdania można to opisać w następujący sposób:

Jako [Kim jest użytkownik], chcę [Czego chce użytkownik] (aby [Dlaczego użytkownik tego chce]).

Ten szablon może być również sformułowany w następujący sposób: „Jako [rola] chcę [działać], (aby [korzystać])” dla uproszczenia terminologii. Przestrzeganie tego podstawowego formatu wystarczy do stworzenia większości historii użytkowników. Zwykle to wszystko, czego potrzebujesz i może pomóc zaoszczędzić dużo czasu, gdy jest używane do każdej historii użytkownika.

Czasami jednak historie użytkowników są trudniejsze do zdefiniowania w bardziej złożonych projektach. W takim przypadku przydatna może być technika drugiego szablonu historyjek użytkownika. Nazywa się INVEST, akronim, który oznacza:

• Niezależne : Historie powinny być całkowicie niezależne od siebie, a w rezultacie historie powinny umożliwiać pracę poza kolejnością.
• Negocjowalne : Historie powinny być zaprojektowane tak, aby można je było zmieniać podczas części konwersacyjnej procesu.
• Wartościowe : Historia użytkownika powinna wykazywać wyraźną wartość dla projektu. Jeśli nie, może to oznaczać marnowanie zasobów.
• Szacunkowa : historia użytkownika musi być mierzona pod względem wartości i priorytetów, aby pomóc zdecydować, nad czym pracować w kolejności ważności.
• Mały : Historie użytkowników muszą być najmniejszą jednostką funkcjonalności i w przeciwnym razie powinny być dalej dzielone.
• Testowalna : Historyjka użytkownika musi zostać przedstawiona w sposób dający się przetestować podczas procesu potwierdzenia.

Często zadawane pytania dotyczące pisania historii użytkowników

Być może zainteresuje Cię również nasz poradnik, jak napisać recenzję gry.