User Story Mapping – opowiedz nam swoją historię
Zanim deweloperzy zaczną tworzyć oprogramowanie, cały zespół projektowy Intellect spotyka się z klientem. Zależy nam, aby podczas tego spotkania opowiedział nam o swoich oczekiwaniach oraz dostarczył informacji na temat zachowań przyszłych użytkowników oprogramowania. Wspólnie systematyzujemy tę wiedzę korzystając z metody zwanej User Story Mapping.
Co to jest User Story Mapping?
User Story Mapping w dosłownym tłumaczeniu oznacza Mapowanie Historyjek Użytkownika. To technika pozwalająca spojrzeć na oprogramowanie jego oczami poprzez dokładne rozpisanie, w jaki sposób i w jakim celu korzysta on z oprogramowania. Użytkownik i jego cele są tutaj najważniejsze. W praktyce, zamiast rozbudowanej dokumentacji zawierającej specyfikację i wymagania systemu, spisanej i przekazanej do zespołu deweloperskiego, stawiamy na wspólne omówienie i wyznaczenie najważniejszych funkcji oprogramowania. Spotykamy się na warsztatach i wspólnie, krok po kroku, zapisujemy w jaki konkretnie sposób użytkownik korzysta z poszczególnych opcji oprogramowania, jakie ma potrzeby i cele. Dzięki temu mamy pewność, że cały zespół wie, co chcemy osiągnąć. Tak zbudowana mapa zachowań użytkownika jest podstawą do planowania i realizacji prac programistycznych.
Jakie jest miejsce historyjek użytkownika w procesie zwinnego tworzenia oprogramowania?
W Software House Intellect pracujemy zgodnie z tzw. zwinnym modelem programowania. Dzięki temu zespół deweloperski co kilka tygodni dostarcza kolejne fragmenty sprawnego, działającego oprogramowania. To niewątpliwie jedna z ważniejszych korzyści dla klienta, który od razu może oprogramowanie udostępnić użytkownikom. Jednak przy takim dynamicznych modelu pracy, w którym na bieżąco wprowadza się wiele zmian w odpowiedzi na informacje zwrotne od klienta, zespołowi deweloperskiemu bardzo trudno jest nie stracić z oczu wizji całości. Dzięki mapie historyjek użytkownika grupa projektowa w codziennej pracy pamięta o wizji, głównych celach projektu i potrzebach użytkownika. Wraz z testowaniem oprogramowania wśród użytkowników, elementy naszej mapy mogą się zmieniać. Jej struktura i podział na wiele małych elementów, pozwala w łatwy sposób wprowadzać modyfikacje i nimi zarządzać.
Skąd wziął się pomysł takiego przedstawiania oprogramowania? Krótka historia:
Ideę historyjek użytkownika przypisuje się Kentowi Beckowi – (jeden z twórców słynnego Manifestu zwinnego wytwarzania oprogramowania), który wprowadził je niejako w opozycji do szczegółowej dokumentacji. Jego postulatem było: “Nie przesyłaj mi dokumentów, po prostu opowiedz mi swoją historię”. Ten pomysł rozbudował później Jeff Patton. W 2005 roku opublikował serwisie StickyMinds.com artykuł “It’s all in how you slice it” (“Wszystko zależy od tego, jak to pokroisz”), w którym opisał alternatywne podejście do przedstawiania funkcji oprogramowania w taki sposób, aby reprezentowały perspektywę użytkownika (tj. opisywały jak konkretnie w danym systemie działa użytkownik). Głównym założeniem jest dzielenie funkcji systemu na mniejsze części w taki sposób, aby – jedna po drugiej – możliwa była ich publikacja i oddanie do testów. Pomysł “krojenia” funkcji stał się bazą bardziej wyrafinowanej koncepcji, którą Jeff Patton opisał w swojej głośnej książce “User Story Mapping”.
W Intellect spotykamy się z klientem, żeby wspólnie zmapować historyjki użytkownika – po co to robimy?
Budowanie wspólnego rozumienia produktu to jeden z najważniejszych celów opracowania historyjek użytkowników. Klient ma wizję swojego produktu i to on najlepiej wie, jaką ma potrzebę biznesową oraz jakie korzyści chce osiągnąć. Dla nas ważne jest to, żeby uwspólnić tę wiedzę i zyskać pewność, że cały zespół dokładnie tak samo rozumie, kto konkretnie będzie użytkownikiem oprogramowania, którzy użytkownicy są najważniejsi, które funkcje są kluczowe, a które opcjonalne. Pozwala to też klientowi realnie ocenić zakres projektu, jaki jest w stanie zrealizować w ramach określonego budżetu.
Warsztaty z User Story Mappingu – czym to się je?
W Intellect warsztaty User Story Mappingu stanowią fundament wszelkich dalszych działań podejmowanych w ramach projektu. To właśnie dlatego spotykamy się całym zespołem jeszcze przed rozpoczęciem jakichkolwiek prac programistycznych i wspólnie mapujemy historyjki użytkowników. Stawiając na pierwszym miejscu maksymalny komfort pracy zespołów, warsztaty z User Story Mappingu przeprowadzamy obecnie przede wszystkim w formie zdalnej. Wykorzystujemy w tym celu aplikację Zoom, a samą Story Mapę stanowiącą rozłożone na części pierwsze cele i potrzeby użytkownika końcowego produktu przygotowujemy w programach Microsoft Excel lub Miro.
Skoro logistyczne technikalia mamy już za sobą, możemy przejść do samego sedna warsztatów z User Story Mappingu.
Do udziału w warsztatach angażujemy cały zespół deweloperski wraz z UX designerami oraz project managerem, a po stronie klienta – wszystkie te osoby, które docelowo mają korzystać z systemu. Utworzony w ten sposób ‘dream team’ pracuje nad stworzeniem wspólnego, spójnego rozumienia produktu w dwóch fazach. Na pierwszą z nich składa się szczegółowe omówienie potrzeb docelowego użytkownika, czyli zmapowanie jego historyjek, które pozwolą określić pożądane funkcje systemu. To właśnie w tej fazie tworzona jest mapa stanowiąca szkielet aplikacji, który odzwierciedla opowieść o tym, w jaki sposób użytkownicy będą z niej korzystać. Szkielet ten uzupełniają zdekomponowane historie, które funkcjonują na niższym poziomie szczegółowości lub odzwierciedlają alternatywne scenariusze korzystania z produktu. Etap drugi to priorytetyzacja wypracowanych w ten sposób funkcji oprogramowania końcowego. Dzięki tak rozplanowanej strukturze warsztatów zespół programistyczny zyskuje jasny obraz zadań, a klient – lepsze rozumienie swoich oczekiwań względem produktu.
Praktyczne do bólu, czyli złote zasady mapowania historyjek
Jeden z guru User Story Mappingu, wspomniany wcześniej Jeff Patton, wypracował złote zasady stosowania techniki mapowania historyjek użytkownika, stanowiącebazę dla organizacji pracy podczas warsztatów. Przede wszystkim należy skupiać się na budowaniu „wspólnego obrazu całości” – im lepsze rozumienie projektu przez zespół, tym lepszy produkt końcowy. Po drugie, użytkownik jest na pierwszym miejscu i to właśnie o jego potrzeby należy opierać funkcje produktu. Z kolei myśląc o efekcie końcowym powinniśmy „bake stories like a cake” („tworzyć opowieści jak tort”), czyli wyznaczać cele i funkcje, biorąc pod uwagę możliwości budżetowe oraz czasowe projektu. Dzięki temu klient otrzymuje najlepszy możliwy efekt przy optymalnej inwestycji czasu i środków oraz produkt odpowiadający specyfice jego odbiorców.
Źródła:
Jeff Patton. „Mapowanie historyjek użytkownika. Przepis na produkt idealny”.
Proces tworzenia story mapy – wg Jeffa Pattona
http://www.jpattonassociates.com/wp-content/uploads/2015/03/story_mapping.pdf
https://www.jpattonassociates.com/wp-content/uploads/2015/03/story_essentials_quickref.pdf
https://www.youtube.com/watch?v=AorAgSrHjKM
http://agile247.pl/story-mapping-w-praktyce/
