Example mapping – historia prawdziwa

Całkiem niedawno dołączyłem jako analityk do nowego zespołu projektowego. Myślę, super, poznam kolejną wersję scruma! Obecnie mam już za sobą ekscytujący grooming, pasjonujący planning, udział w porannych daily. Zaczynam rozumieć i widzieć coraz więcej niż tylko Big Picture z niedawnej sesji Event Storming, która była częścią onbordingu do projektu.

Tak przygotowany mogłem przystąpić do pierwszego zadania! Choć domena była dla mnie nowa, to z ciekawością podjąłem wyzwanie. Wybierałem zadanie z backlogu i poczułem, że nareszcie działam w nowym projekcie! Udało mi się okiełznać User story. Moje zadowolenie rośnie, zwłaszcza kiedy po rozmowach z właścicielami biznesowymi oraz product ownerem, wydawało mi się, że uzyskałem świetne kryteria akceptacji podparte przykładami. Stwierdziłem, że jestem gotów z moim story na review! Potem planning, sprawny development i radość z udanego demo…

Wróćmy do momentu review, bo to właśnie tu rozpoczyna się prawdziwa przygoda!

Example Mapping – o co chodzi?

Cofnijmy się do sesji review z udziałem developerów, kolegi analityka oraz testera – a więc naszych rycerzy trzech /3 Amigos. Razem damy radę ze wszystkim dzięki swoim kompetencjom i spojrzeniu z różnych perspektyw. Rozesłałem wcześniej materiał, niemniej mam wrażenie, że nikt nie miał czasu się z nim zapoznać. Bywa. Brak czasu, natłok obowiązków. Rozumiem to. Podejmuję wyzwanie i zaczynam opowiadać moje story. Myślę: jest ok, uff, wspaniale…!

Czyżby? Dlaczego nie wszystkie z zaproszonych osób angażowały się w dyskusje? Dlaczego nie opuszcza mnie wrażenie że coś poszło nie tak, że nie ma chemii między nami 3 Amigos… Spisałem uwagi i rozeszliśmy się. Niestety, niepokój pozostał.

Nie zignorowałem go, ponieważ po wielu latach w projektach, wiem że ten wewnętrzny głos zwany intuicją, to naturalny machine learning, że coś musi być na rzeczy… Przeprocesowałem uwagi, znalazłem kilka gapów, skrótów myślowych w kryteriach akceptacji i odkryłem, że dwa przykłady w ogóle się nie kleją. Miałem to! Poleciałem na kawę i podjąłem decyzję że zrobię sesję Example Mapping i to w dodatku zdalną! Chciałem skorzystać z komfortu jaki daje zbroja w postaci monitora i odwagi jaką ma człowiek zwracający się do własnego komputera. Poza tym zespół był częściowo rozproszony geograficznie, więc tak było szybciej, niż czekać na obecność wszystkich lub ograniczać się do wąskiego grona osób dostępnych na miejscu, aby wspólnie naklejać karteczki na ścianie lub stole.

Example Mapping jest metodą z bardzo niskim progiem wejścia, niezaawansowaną technicznie. Jej celem jest upewnienie się, że User story jest kompletne i tak samo rozumiane przez każdego uczestnika procesu wytwórczego. Sesja Example Mapping pomaga nam wykryć to, czego jeszcze nie wiemy. Powinna odbyć się przed podjęciem User story do developmentu oraz deklaracją czasochłonności jej realizacji (tj. implementacji lub nawet jej opisu).

Example Mapping w praktyce

Juhuuuu! Zdzwoniliśmy się i zaczęliśmy! Natychmiast udostępniłem ekran, na którym pokazałem współdzielony dokument. Jednocześnie rozesłałem link do dokumentu. Dokument miał prostą strukturę i oznaczenia zgodnie z zaleceniami techniki. Znalazły się w nim:

1. U szczytu strony na żółto zapisałem User story.
2. Pod User story wypisałem na niebiesko – kryteria akceptacji – jedną obok drugiej (a nie jedną pod drugą).
3. Pod kryteriami akceptacji wypisałem przykłady – oznaczyłem je na zielono.
4. Na zachętę i przełamanie lodów wypisałem moje pytania do przykładów i kryteriów akceptacji (na które sam natrafiłem lub nie potrafiłem odpowiedzieć) – oznaczyłem je na czerwono.

Zrobiłem wprowadzenie. Opowiedziałem User story, przedstawiłem kryteria akceptacji, zadałem spisane pytania zgodnie z zaleceniami techniki w formie „Co jeśli…?”. Obawiałem się banalnego dialogu… Tymczasem, zaskoczyła mnie dyskusja i zaangażowanie uczestników! Pojawiły się pytania, a przedstawiane przykłady stawały się coraz lepsze. Wszystko notowaliśmy zrozumiałym dla wszystkich, nieformalnym językiem. Zgodnie z zaleceniami techniki zapisywaliśmy przykłady używając języka nieformalnego, zrozumiałego dla nas wszystkich. Dodatkowo nazwaliśmy je tak, by zapadły nam wszystkim w pamięć. Zaczęliśmy wszystko rozumieć tak samo i na bieżąco potwierdzaliśmy sobie ten fakt! Jako osoba odpowiedzialna za te User Story, poczułem że pełnię równocześnie rolę facilitatora/moderatora na tym spotkaniu.

Co jest wynikiem sesji Example Mapping?

Na część pytań udało się nam wspólnie znaleźć odpowiedzi. Na pozostałe nie – te zostały po prostu zapisane.

W trakcie spotkania okazało się, że jedno z kryteriów akceptacji było zbyt obszerne. Podzieliliśmy je na dwa mniejsze. Każdy w trakcie sesji edytował dokument. Pracując i działając razem, nagle doszliśmy do tego, że w story zaszyte jest kolejne story i inna potrzeba biznesowa. Dodatkowo wszyscy zrozumieliśmy to story tak samo! No more drama, no more skróty myślowe i niedopowiedzenia! To naprawdę dużo! W naturalny sposób udało nam się osiągnąć jedno story w przewidywanym czasie około 25 minut (procesując zgodnie z zaleceniami techniki)!

Wynikami sesji były:

1. 1. Potwierdzenie zakresu User story, decyzje o gotowości do realizacji tego z czym zgadzał się cały zespół.
   2. Założenia realizacyjne.
   3. Otwarte kwestie – pytania, na które nie znaleźliśmy odpowiedzi w czasie spotkania. Zobaczyliśmy to, czego jeszcze nie wiemy.
   4. Krytyczny i podstawowy zakres User story.
   5. Wspólne nazewnictwo (dla zespołu realizacyjnego i właściciela produktu).
   6. Dodatkowo:
      1. Rozbiliśmy User story na mniejsze.
      2. Wykryliśmy nowe User story.

Nie zawsze w czasie jednej sesji udaje się zakończyć pracę nad User story. Wspólne zatwierdzenie User story może zająć nawet 3 sesje.

Jak interpretować i wykorzystać mapę powstałą podczas sesji Example Mapping?

Tak, napracowaliśmy się. Stworzyliśmy mapę (współdzielony dokument), na której, dzięki użytym kolorowym oznaczeniom, od razu widać status naszego story:

1. Mapa zawierająca wiele pytań („czerwone karteczki”) świadczy o tym, że:
   1. User story nie jest gotowe do rozpoczęcia implementacji. Trzeba je dopracować.
2. Mapa zawierająca wiele kryteriów akceptacji („niebieskie karteczki”) świadczy o tym, że:
   1. User story nie jest gotowe do rozpoczęcia implementacji, ponieważ jest zbyt duże. Powinno przejść tzw. slicing, czyli być podzielone aby zmniejszyć zakres i złożoność.
3. Mapa zawierająca wiele przykładów („zielone karteczki”) świadczy o tym, że:
   1. Kryteria akceptacji są zbyt ogólne lub skomplikowane. User story nie jest gotowe do rozpoczęcia implementacji. Kryteria akceptacji powinny zostać poprawione.

Patrząc z perspektywy różnych ról, mapa pozwala nam również dowiedzieć się:

1. Czy jako business person uważam, że mapa zawiera wszystkie informacje, które chciałem przekazać zespołowi?
2. Czy jako programista uważam, że mam wszystkie informacje niezbędne do rozpoczęcia pracy i oszacowania pracochłonności?
3. Czy jako tester mam wystarczająco dużo informacji do przetestowania funkcjonalności i zweryfikowania czy zadziała zgodnie z oczekiwaniami – tj. zgodnie z tym User story?

Jeśli pomimo zidentyfikowania wielu otwartych pytań i uwag, grupa uzna, że User story jest wystarczającej jakości i nadaje się do realizacji/wyceny – to znaczy, że wykryte zastrzeżenia nie są krytyczne. Wspólnie wypracowana mapa powinna zostać zapisana (lub sfotografowana) celem zachowania wydobytej wiedzy. Taka forma notatki pozwoli dalej pracować nad daną User story po zakończonej sesji, kiedy trzeba odpowiedzieć na otwarte pytania i niewiadome oraz w czasie jej implementacji.

Co daje nam Example Mapping?

Niski próg wejścia oraz prostota techniki Example Mapping sprawia, że ta metoda jest dostępna dla wszystkich. Zainwestowanie około 30 minut na tak dokładny przegląd/kontrolę User story dokonany przez co najmniej 3 Amigos raczej nie doprowadzi do negatywnego zaskoczenia na planningu lub w czasie developmentu.

Korzyści przemawiające za Example Mapping:

1. 1. Krótkie, wysoce produktywne spotkanie.
   2. Natychmiastowy feedback o zakresie i jakości User story, w tym wiedza:
      1. które kryteria akceptacji są zrozumiałe, a które powinny zawierać więcej przykładów, które wymagają jeszcze dopracowania (wiem nad czym jeszcze muszę popracować).
      2. które kryteria akceptacji są intuicyjne/jasne i tak samo rozumiane przez wszystkich – wtedy nie wymagają przykładów (oszczędność czasu).
      3. czy zakres User story może zostać uznany za zbyt duży.
      4. czy są jakieś luki, otwarte kwestie, niejasności.
   3. Zaangażowanie wszystkich ról w zespole, wymiana wiedzy i wspólne potwierdzenie zrozumienia tego co ma być zrealizowane.
   4. Skupienie uwagi na kryteriach akceptacji User story oraz powiązań między nimi.
   5. Wydzielenie niezależnych kryteriów akceptacji.
   6. Wykrycie „rdzenia/podstawy” User story. Resztę zakresu (jako mniej krytyczną) można odłożyć na później (np. nowe „User story”).
   7. Wykrycie nowych kryteriów akceptacji.
   8. Osiągnięcie wspólnego zrozumienia tego co jest potrzebne do realizacji User story. – w tym także zidentyfikowanie wymaganych zadań technicznych (o koszcie i istnieniu których niestety czasem zapominamy).
   9. Dodatkowe przykłady – wspólnie wypracowane przez zespół w trakcie sesji – spisane językiem nieformalnym, zrozumiałym dla wszystkich. Takie przykłady staję się świetną bazą do testów oraz walidacji rozwiązania.
   10. Jasny przegląd zakresu pierwszej iteracji wymagania.
   11. Uspójnione nazewnictwo i takie samo zrozumienie tematu przez wszystkie role w zespole.
   12. Example Mapping promuje wymagania zapisane jako zachowanie użytkownika.
   13. Kryteria akceptacji określają podstawowe zachowanie aplikacji.
   14. Duże lub niejasne User story nie są brane do realizacji.
   15. Wspólne przygotowanie bazy pod testy akceptacyjne.
   16. Wspólne odkrycie tego czego nie wiemy!

Autor: Piotr Dobrowolski, Starszy Analityk ASC