Jeśli znasz technikę User Story Mapping (USM), zachęcam do czytania dalej. Jeśli nie, zachęcam do przeczytania tego artykułu, który jest po trosze wprowadzeniem do tematyki, jaką będę się zajmował w tym artykule.

W firmach zajmujących się rozwojem jednego lub kilku produktów informatycznych (powiedzmy aplikacją mobilną) model analityczny często jest pomijany. Tzn. występują jakieś specyfikacje, ale nawet jeśli wśród artefaktów wytwarzanych oprócz kodu znajdą się diagramy uzupełniające informację o historii, diagram ten przemija wraz z wdrożeniem produktu. Nie ma czasu ani finansów na to, aby gromadzić taką wiedzę. A klient oczekuje przecież softu. W dużych organizacjach, np. usługowych, finansowych bądź technologicznych, zwykle mających na swoim pokładzie IT rozwijające ich wewnętrzny biznes, ważne jest zachowanie know-how dotyczącego procesów, systemów, złożonej infrastruktury itd, oraz zachowanie spójności często skomplikowanej architektury. Tutaj modele zwykle występują. W oparciu o nie prowadzi się analizę biznesowo-systemową, która toczy się w zespołach wytwórczych.

Jak wiązać elementy User Story Mapping z modelem analitycznym? Które elementy którym odpowiadają i które na siebie wpływają. Zależy nam przecież na spójności informacji w obu miejscach. Jak jako analityk biznesowo-systemowy mogę identyfikować wpływ na mój model podejmowanych przez zespół tematów?

Założenia

W poniższym porównaniu omijam całkowicie kolejność prowadzenia analizy biznesowo systemowej i sens, jaki wprowadza jej zachowanie. Skupię się jedynie na podobieństwie elementów z obu światów. Zakładam również, że historie użytkownika (User Stories) budują wizję produktu a nie są wymaganiami funkcjonalnymi i samodzielnie nie wystarczą zespołowi do poprawnej kompletnej realizacji oprogramowania. Mogą wyprzedzać dogłębną analizę. Mogą również być jej wynikiem. Będą jednak uszczegółowione odpowiednim kontekstem pochodzącym z modelu (diagramem, mockupem itp.).

User Story Mapping, ponieważ agreguje wiele informacji w jednym miejscu, może stanowić referencję do modelu analitycznego, który jest aktualizowany w ramach prac wytwórczych. Wyróżniłem kilka miejsc, w których jako analitycy możemy poszukiwać powiązań z modelem analitycznym pracując z User Story Mappingiem.

User Story Map z naszego wcześniejszego przykładu wygląda następująco:

Załóżmy też, że główne poziomy modelu analitycznego przebiegają przez następującą ścieżkę śladowania: proces biznesowy –> zmapowane z jego elementami wymagania funkcjonalne uszczegóławiające w danym kroku oczekiwania względem rozwiązania informatycznego niezbędnego do zrealizowania tego kroku –> przypadki użycia realizujące wymaganie oraz -> elementy przypadku użycia będące bezpośrednią implementacją wymagania.

Na diagramie bardziej szczegółowym będzie wyglądać to tak:

1. USM a produkt

Po pierwsze całą mapę rozpatrywać należałoby w odniesieniu do jednego produktu informatycznego, z którego korzystają użytkownicy wymienieni w historiach (JAKO…). Backlog pisany jest z perspektywy nie uczestnika procesu biznesowego (ani innego „produktu”), a użytkownika aplikacji – aktora. Można go pisać z perspektywy usługi (koncepcji określonej funkcjonalności do zrealizowania na dowolnej platformie informatycznej), ale procesu biznesowego już niekoniecznie.

Próbując jedną mapą opisać cały proces biznesowy, a tym samym wiele produktów (aplikacji/ rozwiązań z których korzysta użytkownik) biorących w nim udział, od razu powstanie zamieszanie. Pojawi się duży obszar poza aplikacyjny (wykonywany ręcznie, który ostatecznie zostanie pominięty bo nie pojawią się pod nim żadne historie). Pojawią się liczne alternatywy i wyjątki, których płaska lista akcji nie obejmie. Zniknie zarządzalność produktem, czyli cecha jaką chcielibyśmy określić nasz product backlog. Koncentrując się na jednym produkcie (aplikacji), panujemy nad zbiorem wymagań, postępem prac, ważnością, krokami realizacji usługi itd. Z perspektywy architektonicznej opisywany będzie więc nasz system bądź komponent.

2. Przypadki użycia

Ponieważ nie ma twardych reguł identyfikacji aktywności (jak próba odnoszenia się do pojęć biznesowych przy identyfikacji kroków w procesie), w przypadku każdej mapy może być inaczej. Raz aktywności mogą opisywać obszary funkcjonalne (czyli luźne grupy przypadków użycia, np. związane z obsługą klienta, rejestracją zamówienia itp.). Wówczas przypadkami użycia będą historie (duże, może nawet za duże na realizację w pojedynczym sprincie).

Przykład:
„Aktualizacja danych osobowych” (historia: JAKO użytkownik sklepu internetowego CHCĘ zaktualizować moje dane osobowe ABY faktura była wystawiana z właściwymi danymi) może być przypadkiem użycia w naszym modelu mimo, że została zakwalifikowana jako element „Edycji profilu”. Jest cel i zakres właściwy dla przypadku użycia.

Innym razem aktywności odnosić się będą do samych przypadków użycia bądź jego elementów. User Story Mapping będzie pokazywać za ich pomocą grube etapy (kroki) realizowanego przypadku użycia.

Przykład:
Akcje podpięte do aktywności „Składanie zamówienia” zostały podzielone na kroki (etapy) UC: Przegląd oferty, Wybór produktu, Obsługa koszyka, Realizacja płatności. Nie są rozpatrywane osobno jako osobne UC, razem dają ciąg czynności implementowany w jednym przypadku użycia.

3. Przebieg przypadku użycia

Przebiegu przypadku użycia możemy poszukiwać w obrębie historii podpiętych pod akcje reprezentujące przypadek użycia bądź jego kroki. Historia użytkownika może reprezentować przebieg podstawowy (bądź jego część) jak i alternatywę.

Przykład:
Wyświetlenie listy produktów stanowi fragment przebiegu przypadku użycia obejmujący pobranie danych ze źródła (np. baza danych) oraz wyświetlenie ich na ekranie. W ten sposób historia użytkownika odwzorowana zostanie na modelu jako fragment przebiegu przypadku użycia.

Każda kolejna historia może modyfikować bądź dodawać nową ścieżkę przebiegu (jako alternatywa, element realizowany asynchronicznie).

Przykład:
Historia: Dodanie produktu do koszyka („JAKO użytkownik sklepu internetowego CHCĘ dodać produkt do koszyka ABY skompletować zamówienie) wprowadzi nam kolejny etap bądź alternatywę w obrębie przebiegu przypadku użycia. Zarówno realizowaną synchronicznie (poprzedza i następuje po kolejnym ekranie) albo asynchronicznie (realizowana jest w obrębie jednego ekranu).

4. Wymagania i sposób ich realizacji

Patrząc na naturę opisu uszczegóławiającego historie użytkownika, kryteria akceptacyjne przejawiają cechy wymagań funkcjonalnych i niefunkcjonalnych. Wymaganiami mogą być też historie, tylko same historie z natury rzeczy będą bardziej mgliste (niedookreślone) wyrażają bowiem oczekiwanie użytkownika czyli wizję produktu, nie jego cechy,

W dalszym kroku wymagania i powiązane z nimi kryteria akceptacyjne będą realizowane w modelu jako aktywności w obrębie przebiegu przypadku użycia.

Przykład:
Kryterium w ramach historii „Dodanie produktu do koszyka” mówiące, że: „Ilość produktów wprowadzonych do koszyka nie może być większa, niż ilość dostępna na magazynie” wymusza wprowadzenie weryfikacji (bądź ograniczenia ilości wprowadzanych do koszyka produktów), odwzorowanej przez odpowiednią aktywność w basenie „system”.

Alternatywy i walidacje.

Przykład:
Kryterium „W przypadku dodania do koszyka ilości wynoszącej zero, system informuje o braku możliwości dodania produktu do koszyka” przełoży się na odpowiednią alternatywę i dodanie komunikatu.

Albo elementy ekranowe.

Przykład:
Kryterium „Dodając produkt użytkownik widzi jaka ilość produktów została wprowadzona do koszyka” przełoży się na powstanie odpowiedniej formatki na ekranie z ilością produktów w koszyku.

5. Aktorzy

Historie (User Stories) opisują oczekiwane działanie aplikacji z perspektywy jego użytkowników, czyli aktorów w naszym modelu. Dlatego też użytkownik zidentyfikowany dla całej mapy (albo jej części) oraz wymieniany w treści historii będzie aktorem w modelu.

Przykład:
JAKO użytkownik sklepu internetowego CHCĘ… stanowi wyznacznik do zidentyfikowana aktora, przynajmniej pierwszej jego wersji. Problem pojawia się bowiem, gdy aktorzy w wyniku dalszej analizy na modelu zmieniają swoje nazwy (ulegają np. specjalizacji) – wówczas należałoby zaktualizować ich w każdej z opisanych historii, co stanowi problem sam w sobie. Jakkolwiek można znaleźć podobieństwo przy mapowaniu wizji (historii) na model (aktora).

6. Priorytet oraz Plateau

Priorytet wymagań, czy priorytet nadawany dla przypadków użycia można przyrównać do poziomych linii odcinających historie wg release. Plateau opisujący przyrost architektoniczny można próbować wiązać z elementami powiązanymi z historiami dedykowanymi poszczególnym wydaniom.

Jakich informacji nie wyczytasz z User Story Map?

Brak kontekstu całego procesu biznesowego

USM mylnie kojarzone jest z pełnym procesem biznesowym. Ze swojej natury USM nie obejmuje przepływu całego procesu biznesowego i służy przede wszystkim organizacji historii użytkownika czyli wizji użytkownika względem rozwiązania informatycznego; do opisu procesu bliższa jest technika Blue Print Map, jednak też nie do końca odzwierciedla każdy wymagany aspekt, m.in. kolaborację uczestników procesu. Proces biznesowy i jego plan/usprawnienie powinno obejmować wiele USM dla wielu produktów informatycznych wspierających realizację procesu (przy założeniu że produktem jest rozwiązanie informatyczne).

Referencji do celów biznesowych inicjatywy i celów organizacyjnych

Historie identyfikowane w ramach określonych aktywności i priorytetyzowane wg poziomu ich istotności względem potrzeb użytkownika (jest to stawianie hipotezy). Nie uzyskamy za pomocą tego narzędzia mapowania na cele organizacyjne. „Aby” w treści historii będzie wyznaczać lokalną potrzebę argumentującą sensowność istnienia historii, niezwiązaną bezpośrednio z korzyścią biznesową. Nie zapewnimy też walidacji tego, czy komplet wymagań spełnia nam cele biznesowe postawione dla inicjatywy.

Architektury rozwiązania

Kontekst mapy historii użytkownika jest jednoproduktowy i to wg powyższej argumentacji ograniczony do rozwiązania informatycznego, jakie obserwuje użytkownik. Nie pokazuje złożoności rozwiązania IT „pod spodem”, która musi zostać wykazana na innym artefakcie (np. diagramie architektury).