Co to jest historia użytkownika?

Co to jest historia użytkownika?

Historia użytkownika to notatka, która uchwyca to, co użytkownikrobi lub musi zrobić jako część swojej pracy. Każda historia użytkownika składa się z krótkiego opisu napisanego z punktu widzenia użytkownika, w naturalnym języku. W przeciwieństwie do tradycyjnego zbierania wymagań, historia użytkownika skupia się na tym, czego potrzebuje użytkownik, a nie na tym, co system powinien dostarczyć. Pozwala to na dalsze dyskusje nad rozwiązaniami i otrzymuje system, który naprawdę pasuje do procesu działania klienta, rozwiązuje jego problemy operacyjne i przede wszystkim dodaje wartości organizacji.

Koncepcja trzech C

Trzy C odnoszą się do trzech kluczowych aspektów dobrych historii użytkownika. Koncepcję zaproponował Ron Jeffries, współwynalizator praktyki historii użytkownika. Obecnie, gdy mówimy o historiach użytkownika, zazwyczaj mówimy o tych historiach, które składają się z tych trzech aspektów.

1. Karta – Historie użytkownika są zapisywane jako karty. Każda karta historii użytkownika zawiera krótkie zdanie z wystarczającą ilością tekstu, by przypomnieć wszystkim, o czym historia dotyczy.
2. Rozmowa – Wymagania są wykrywane i dopasowywane poprzez ciągłe rozmowy między klientami a zespołem rozwojowym przez cały projekt oprogramowania. Ważne pomysły i decyzje są odkrywane i notowane podczas spotkań z zaangażowanymi stronami.
   
3. Potwierdzenie – albo znane również jako kryteria akceptacji historii użytkownika. Podczas dyskusji nad wymaganiami klient informuje analityka nie tylko o tym, czego chce, ale także potwierdza, pod jakimi warunkami i kryteriami oprogramowanie będzie akceptowane lub odrzucane. Określone przypadki są zapisywane jako potwierdzenie. Zauważ, że potwierdzenie skupia się na weryfikacji poprawności pracy odpowiedniej historii użytkownika. Nie jest to test integracyjny.
   

Jak zidentyfikować historię użytkownika?

Historie użytkownika powinny być identyfikowane wspólnie z zaangażowanymi stronami, najlepiej w bezpośredniej rozmowie. Historia użytkownika to proces odkrywania wymagań, a nie proces analizy wymagań na wstępie. W tradycyjnych podejściach do zbierania wymagań analityk systemu stara się zrozumieć potrzeby klientów, a następnie przygotować szczegółową specyfikację wymagań systemu. To nie jest sposób, w jaki działa podejście oparte na historiach użytkownika. Zamiast procesu dokumentacji, identyfikacja historii użytkownika bardziej przypomina proces notowania. Poprzez rozmowy z użytkownikami słuchamy i rozumiemy ich problemy i potrzeby, a następnie zapisujemy te potrzeby jako historie użytkownika w tym samym czasie. Te historie użytkownika staną się źródłem wymagań. Szczegóły mogą być następnie uzupełnione w odpowiednim momencie, zapewniając zespołowi odniesienia do wymagań „wystarczających” przez cały proces rozwoju projektu.

Mapowanie procesu biznesowego z historiami użytkownika

BPMN to jedno z najpotężniejszych narzędzi do analizy i modelowania procesów biznesowych. Możemy nie tylko wykorzystać je do poprawy procesów, ale także identyfikować historie użytkownika z tych procesów, które mają zostać zautomatyzowane, poprzez następujące kroki:

1. Po prostu zamodeluj przepływ pracy użytkownika za pomocą diagramu procesu biznesowego BPMN.
2. Przejdź przez model procesu razem z użytkownikami.
3. I analizuj aktywności biznesowe problemu, a następnie zidentyfikuj historie użytkownika związane z procesem, który ma zostać zautomatyzowany, co znane jest również jako mapowanie procesu biznesowego na historię użytkownika.

Jak napisać historię użytkownika?

Podczas pisania historii użytkownika, staraj się pisać głosem użytkownika według poniższego wzoru (lub przynajmniej upewnij się, że to, co napisałeś, spełnia poniższe stwierdzenie):

Jako <rola>, chcę <cel biznesowy>, aby <wartość biznesowa/przyczyna>.

Na przykład: Jako klient, chcę otrzymać SMS, gdy towar zostanie dostarczony aby móc idź go zabrać.

gdzie:

1. <rola> reprezentuje osobę, system, podsystem lub jakąkolwiek inną jednostkę, która będzie interakcjonować z systemem do wdrożenia w celu osiągnięcia celu. On lub ona uzyska wartości poprzez interakcję z systemem.
2. <cel biznesowy> reprezentuje oczekiwanie użytkownika, które może zostać zrealizowane poprzez interakcję z systemem.
3. <wartość biznesowa> reprezentuje wartość ukrytą za interakcją z systemem.

To nie jest zasada, ale wytyczna pomagająca myśleć o historii użytkownika, biorąc pod uwagę następujące aspekty:

1. Historia użytkownika przyniesie wartość komuś lub określonej grupie (np. klientom).
2. Historia użytkownika spełnia potrzebę użytkownika (np. otrzymać SMS, gdy przedmiot zostanie dostarczony)
3. Istnieje powód, by wspierać wdrożenie tej historii użytkownika (np. klient może odebrać zakupiony przedmiot)

Każda historia użytkownika powinna przynosić wartość komuś. Czasem jednak wartość jest wystarczająco oczywista, tylko po przeczytaniu celu biznesowego. Zapisywanie wartości jako część stwierdzenia jest kłopotliwe. W takim przypadku po prostu ją pominiemy. Oto kilka przykładów:

Jako klient, chcę zapłacić za pomocą karty kredytowejaby móc używać mojej karty kredytowej przy zakupach online.

Jako użytkownik, chcę wyszukiwać, wpisując imię mojego znajomegoaby móc znaleźć mojego znajomego po jego imieniu.

Niezależnie od tego, jak napiszesz historię użytkownika, musisz pamiętać o dwóch rzeczach. Po pierwsze, historia użytkownika musi być napisana z punktu widzenia użytkownika. Po drugie, utrzymaj opis „wystarczająco szczegółowy”. Unikaj dodawania zbyt wielu szczegółów na początku projektu oprogramowania. Później będzie Ci szansa dopracować i rozszerzyć historię użytkownika, aby stała się czymś, co może być wykorzystane przez programistów w projektowaniu i implementacji.

Cykl życia historii użytkownika

W szerszym ujęciu, przez cały cykl projektu oprogramowania istnieje sześć głównych stanów dla każdej historii użytkownika:

1. Oczekujące – Poprzez komunikację między użytkownikiem a zespołem projektowym, odkrywane są historie użytkownika. W tym stanie historie użytkownika mają jedynie krótkie opisy potrzeb użytkownika. Nie ma jeszcze szczegółowej dyskusji wymagań, logiki systemu ani projektu ekranu. W rzeczywistości jedynym celem historii użytkownika na razie jest przypomnienie wszystkim stroną o przyszłej dyskusji dotyczącej prośby użytkownika zawartej w tej historii (karcie). Możliwe, że historia użytkownika zostanie odrzucona w przyszłości.
2. Do zrobienia – Poprzez dyskusję między różnymi stakeholderami, decyduje się, które historie użytkownika będą realizowane w kolejnych kilku tygodniach, i umieszcza się je w czasowym oknie zwanym sprintem. Takie historie użytkownika są nazywane w stanie Do zrobienia. W tym stanie jeszcze nie przeprowadzono szczegółowej dyskusji.
3. Dyskutowane – Gdy historia użytkownika jest w stanie Dyskutowane, użytkownik końcowy komunikuje się z zespołem programistycznym w celu potwierdzenia wymagań oraz zdefiniowania kryteriów akceptacji. Zespół programistyczny zapisuje wymagania lub dowolne decyzje jako notatki z rozmowy. Specjalista UX może tworzyć szkice lub scenariusze, aby użytkownik mógł przewidzieć proponowane funkcje w wizualnych mock-upach i poczuć je. Ten proces nazywa się projektowaniem doświadczenia użytkownika (UX design).
   
4. Rozwój – Po wyjaśnieniu wymagań, zespół programistów zaprojektuje i zaimplementuje funkcje spełniające prośby użytkownika.
5. Potwierdzanie – Po zaimplementowaniu historii użytkownika przez zespół programistów, historia użytkownika zostanie potwierdzona przez użytkownika końcowego. Użytkownik otrzyma dostęp do środowiska testowego lub do częściowo gotowego produktu programowego (czasem nazywanego wersją alfa) w celu potwierdzenia funkcji. Potwierdzenie zostanie przeprowadzone na podstawie elementów potwierdzających, które zostały zapisane podczas szczegółowego opisu historii użytkownika. Dopóki potwierdzenie nie zostanie wykonane, historia użytkownika jest uznawana za znajdującą się w stanie Potwierdzania.
6. Zakończone – Wreszcie, funkcja została potwierdzona jako zakończona, historia użytkownika jest uznawana za zakończoną. Zazwyczaj jest to koniec historii użytkownika. Jeśli użytkownik ma nowe wymagania, czy to nową funkcję, czy ulepszenie zakończonej historii użytkownika, zespół stworzy nową historię użytkownika dla kolejnej iteracji.

Szczegółowe opisanie historii użytkownika – kiedy i dlaczego?

Kluczową cechą, która różni historię użytkownika od tradycyjnych metod zbierania wymagań, jest to, że podejście oparte na historiach użytkownika dzieli identyfikację problemu i rozwiązania na dwa kroki, wykonane w różnych etapach projektu oprogramowania. Podczas gdy problemy i ogólne zrozumienie potrzeb użytkownika są wykrywane na początku projektu oprogramowania, szczegółowe informacje dotyczące wymagań systemu są ustalane jedynie przed rozpoczęciem projektowania i implementacji. Oto niektóre korzyści z takiego podejścia:

1. Możliwość odpowiedzi na najnowsze potrzeby użytkownika, ponieważ wymagania są szczegółowo ustalane tuż przed implementacją, a nie w pełni zakończone na początku.
2. Możliwość łatwiejszego zidentyfikowania odpowiednich wymagań, ponieważ zarówno problemy, jak i rozwiązania będą szczegółowo omawiane. W tradycyjnych podejściach, ponieważ szczegółowe informacje dotyczące wszystkich wymagań muszą zostać znalezione na początku projektu, „wstępne wymagania” mogły ulec zmianie w czasie, co prowadziło do dużych strat w czasie i wysiłku analizy.
3. – Z drugiej strony, historie użytkownika uznane za nieważne można łatwo odrzucić. Nie tracisz dużo czasu na wcześniejsze badania i dokumentację

Jak skutecznie wykorzystywać historie użytkownika?

Podobnie jak wiele innych metodologii rozwoju oprogramowania, jeśli odpowiednio zastosujesz historię użytkownika w swoim projekcie oprogramowania, będziesz mógł stworzyć system o wysokiej jakości oraz zyskać zaufanie i satysfakcję klientów. Oto kilka punktów, które należy mieć na uwadze podczas korzystania z historii użytkownika:

1. Trzymaj opis historii użytkownika krótki.
2. Myśl z punktu widzenia użytkownika końcowego podczas pisania historii użytkownika.
3. Przypadek użycia (UML) reprezentuje cel biznesowy. Możliwość grupowania historii użytkownika pod przypadkami użycia pozwala Ci upewnić się, że historia użytkownika spełnia cel biznesowy, innymi słowy, że dzielą ten sam cel systemowy. Służy on jako miejsce zastępcze, które ułatwia zarządzanie, planowanie i priorytetizację historii użytkownika w bardziej przejrzysty sposób.
4. Elementy potwierdzające muszą zostać zdefiniowane przed rozpoczęciem rozwoju
5. Oszacuj historię użytkownika przed implementacją, aby upewnić się, że obciążenie zespołu pozostaje pod kontrolą.
6. Wymagania są ustalane wspólnie z użytkownikami końcowymi, a nie przez użytkownika końcowego ani tylko przez zespół programistów. Zachowanie dobrej relacji z użytkownikami końcowymi jest korzystne dla obu stron.
7. Komunikacja zawsze ma znaczenie przy rozumieniu, czego użytkownik końcowy chce.

Visual Paradigm oferuje wszystkie narzędzia, które potrzebujesz w rozwój oprogramowania agilnego, które obejmują narzędzie do tworzenia diagramów przypadków użycia UML, (agilne) historia użytkownika, sprint, konspekt i szkice do projektowania UX, narzędzie do zarządzania zadaniami, itd.