Story mapping – nieco szersze spojrzenie

User Story to bardzo popularna technika opisywania wymagań, a zarazem jedna z moich ulubionych. Poświęciłem jej już wiele artykułów. Pisałem o tym, jakie cechy powinno mieć poprawne User Story, o tym jak je podzielić, gdy jest zbyt duże oraz o tym, że technika ta często bywa nadużywana.

Istotną wadą User Story jest to, że nie dostarcza zbyt szerokiego kontekstu. Skupia się na wybranym wymaganiu. Opisuje oczekiwania określonych interesariuszy i wartość z nimi związaną. Niestety jest to zwykle zbyt mało informacji, by zespoły deweloperskie mogły efektywnie pracować, a na pewno za mało, aby móc w pełni zrozumieć ogólny cel projektu i potrzebę, która za nim stoi. Z tego właśnie powodu opisywanie wymagań w formie User Stories warto wesprzeć innymi technikami i formami dokumentacji. Jedną z takich technik jest Story Mapping.

Story Mapping – co to takiego?

W wielkim skrócie jest to mapowanie User Stories (lub opcjonalnie wymagań w innej formie) na kroki procesu. Musimy zatem określić proces, jego poszczególne kroki i przypisać im określone Historyjki Użytkownika. Mamy też możliwość określania priorytetów poszczególnych User Stories oraz możemy w wygodny sposób wyznaczać zakres poszczególnych wersji produktu.

Wygląda to tak

Na powyższym schemacie widzimy dwie osie: poziomą i pionową. Oś pozioma wyznacza przebieg procesu. Nad nią pojawiają się poszczególne kroki procesu, od lewej do prawej, układające się w spójną całość. Oś pionowa wskazuje priorytet. Im niżej dana Historyjka Użytkownika jest umieszczona, tym niższy jest jej priorytet. Czerwone linie wyznaczają zakres poszczególnych wersji produktu. MVP (ang. Minimal Viable Product), to minimalny, biznesowo uzasadniony zakres, dostarczający użytkownikom wartości. Kolejna linia, wyznacza zakres, który będzie dodany w następnej wersji.

Story Mapping – konkretny przykład

Rozważmy konkretny przykład zastosowania Story Mappingu dla procesu zamawiania produktów w sklepie internetowym. Przykład jest banalny, co pozwala skupić się na prezentacji techniki, a nie zawiłościach danego procesu. Oczywiście tworząc Mapę Historyjek, warto jest używać tytułów User Story, a nie pełnego Statement of Value.

Przykładowy proces zamawiania produktu w sklepie internetowym składa się z kilku, następujących po sobie, kroków. Widzimy je nad poziomą osią wyznaczającą kierunek procesu. Każdemu z kroków procesu zostało przyporządkowanych kilka User Story. Zostały one ułożone według priorytetów. Te ważniejsze znajdują się wyżej, a mniej ważne niżej. Widzimy również linię wyznaczającą MVP a zatem zakres funkcjonalności (wymagań), który będzie ujęty w pierwszej, podstawowej wersji. Oczywiście potencjalnie moglibyśmy zaplanować kolejne wersje i zawrzeć w nich pozostałe wymagania.

Story Mapping w formie warsztatu

Główną zaletą Story Mappingu jest to, że pozwala przekazać i omówić szerszy kontekst. Nie skupiamy się na perspektywie pojedynczego User Story, ale widzimy całość procesu lub nawet całość rozwiązania, które tworzymy. W ramach tej całości, możemy umiejscowić poszczególne User Story. Dzięki temu, możliwe jest zastosowanie podejścia „od ogółu do szczegółu”. Podejście takie wydaje się być najwłaściwsze, ponieważ jedynie mając szeroką perspektywę i zrozumienie celu oraz potrzeby biznesowej, zespoły deweloperskie są w stanie opracować optymalne rozwiązanie.

Mapa Historyjek (ang. Story Map) może być oczywiście formą dokumentacji. Mamy na niej opisane ogólne kroki procesu, odpowiadające im User Stories i ich priorytety. Jest to więc opcja, którą możemy rozważyć jako dokumentację naszego rozwiązania. Moim zdaniem nie jest to jednak optymalne zastosowanie techniki Story Mappingu. Największą zaletą i optymalnym zastosowaniem tej techniki jest możliwość osiągniecia wspólnego zrozumienia pomiędzy interesariuszami. Zrozumienie to może dotyczyć potrzeby biznesowej, odpowiadającego jej rozwiązania oraz jego zakresu.

Organizując warsztat, którego celem jest Story Mapping i zapraszając odpowiednich interesariuszy (zarówno „biznesowych” jak i „technicznych” zyskujemy świetną okazję do wymiany informacji, dyskusji i osiągania bardzo pożądanego zjawiska, jakim jest wspomniane wspólne zrozumienie. Jest to niezwykle ważne w kontekście precyzyjnej estymacji rozwiązania i efektywnej współpracy nad jego tworzeniem. Tworzenie Mapy Historyjek to również dobra okazja do dyskutowania priorytetów i podziału na wersje.

Wady Story Mappingu

Wiemy już, jakie są zalety tworzenia Map Historyjek. Oczywiście jak każda inna, technika ta również posiada pewne wady i ograniczenia. Przede wszystkim ma zastosowanie głównie tam gdzie występują procesy. Polega w końcu na mapowaniu wymagań na poszczególne ich kroki. W przypadku systemów, w których niemożliwe jest zdefiniowanie jasnych procesów, wciąż możemy starać się używać Story Mappingu, grupując wymagania według pewnych cech, czy funkcjonalności. Jest to jednak mniej wygodne i technika staje się mniej przydatna. W przypadku braku procesu, pozioma oś mapy traci swój sens.

Kolejne ograniczenie omawianej techniki jest również związane z procesami. W przypadku bardzo skomplikowanych i rozgałęzionych procesów, określenie Story Map bywa trudne. Należy wtedy, w ramach techniki Story Mappingu, zastosować uproszczoną wersję procesu, a szczegółową i dokładną przedstawić w innej formie (np. odpowiedniego diagramu).

Ostatnim ograniczeniem jakie warto wspomnieć jest brak informacji o wzajemnych powiązaniach pomiędzy wymaganiami. Niektóre wymagania muszą być zrealizowane przed innymi z przyczyn technicznych lub biznesowych. Czasami też implementacja jednego wymagania może znacząco wpłynąć na koszt implementacji innego. Tego rodzaju zależności nie są uwzględniane na Mapach Historyjek i muszą być analizowane i dokumentowane w innej formie.

Moje rekomendacje

• Stosuj Story Mapping w celu uzyskania wspólnego zrozumienia pomiędzy różnymi grupami interesariuszy
• Organizuj warsztaty Story Mappingu (najlepiej stacjonarne) i wykorzystaj do tego tablice, flipcharty i przyklejane karteczki
• Wykorzystaj Story Mapping jako okazję do dyskusji samego rozwiązania, jego zakresu oraz priorytetów
• Pamiętaj nie tylko o zaletach, ale również o wadach i ograniczeniach Story Mappingu i ich konsekwencjach

Źródła

Agile Extension to the BABOK® Guide. Version 2. 2017.