Story / Impact Mapping – Kontekst, Zasady i Przegląd

Podejście Small-Batch w wytwarzaniu oprogramowania jest dobre
Istnieje wiele zalet stosowania podejścia Small-Batch (wiele małych, pojedynczych kroków) przy wytwarzaniu oprogramowania:

• Szybsza informacja zwrotna
• Problemy są lokalizowane
• Zmniejszone ryzyko
• Większa presja i rutyna w celu redukcji nakładu pracy

Naiwne podejście Small-Batch w wytwarzaniu oprogramowania nie jest już tak dobre

Jednakże podejście do wytwarzania oprogramowania w sposób naiwny ma też istotną wadę: brak odniesienia do ogólnego celu.

Jeff Patton opisał to zjawisko na przykładzie drzewa i worka pełnego liści:

„Wyobrażam sobie drzewo, którego pień składa się z celów i pożądanych korzyści napędzających system. Grube gałęzie to użytkownicy, cieńsze gałęzie i pędy to capabilities, których potrzebują. Liście reprezentują User Stories, które są wystarczająco małe, by rozwijać je w iteracjach.
Po całej tej pracy, po tym jak zbudowaliśmy tak wiele wspólnego rozumienia, mam wrażenie, że zdejmujemy wszystkie liście z drzewa, wkładamy je do dużego worka – a potem ścinamy drzewo."

„Worek pełen liści" odnosi się do pozbawionej kontekstu, spriorytetyzowanej listy zadań w Backlogu i odzwierciedla naiwne rozumienie „Backlogów", które moim zdaniem jest szczególnie typowe dla początkujących w Agile. Mimo że teoretycznie brzmi to jak podejście Small-Batch, „worek pełen liści" zrywa połączenie z leżącymi u podstaw zasadami i celami, podważając tym samym autonomię.

5 atrybutów efektywnego podejścia Small-Batch w wytwarzaniu oprogramowania

Bardziej efektywne podejście wykracza jednak poza zwykłe dzielenie na mniejsze jednostki. Bardziej efektywne podejście:

• podkreśla rzeczywistą intencję za pomocą celów.
• podkreśla logiczny związek między celami a wymaganymi zadaniami.
• w sposób widoczny przedstawia cele, zadania i powiązania, aby ujawnić ewentualne rozbieżności i nieporozumienia.
• jest zorientowane na pracę zespołową.
• jest iteracyjne, tzn. na początku nie wymagana jest kompletność.
• Story/Impact Mapping a wytwarzanie oprogramowania metodą Small-Batch
  Zarówno „User Story Mapping" Jeffa Pattona, jak i „Impact Mapping" Gojko Adzica są (w dużej mierze równoważnymi) odpowiedziami na naiwne podejścia do określania mniejszych pojedynczych kroków w wytwarzaniu oprogramowania metodą Small-Batch (czyli do tworzenia Backlogów). Opisałbym to następująco:

Uwaga: Ten proces Impact Mapping powinien być iteracyjny. Jest tu przedstawiony sekwencyjnie jedynie dla lepszego zrozumienia. Nie jest konieczne ani zalecane wykonywanie każdego kroku w tej kolejności. Zamiast tego możesz zacząć od miejsca, w którym się aktualnie znajdujesz, i wymieniać kroki według potrzeb.

1) Identyfikuj cele
Co chcesz osiągnąć?

Powinno to być coś, co można obserwować, a zatem i mierzyć. Dlatego lubię termin „wpływ", bo oznacza, że coś jest mierzalne. Jednak „cel" jest bardziej powszechny i poza tym nie lubię wprowadzać nowych pojęć, gdy nie jest to absolutnie konieczne.

Może istnieć wiele celów.

2) Identyfikuj role i aktywności
Kto musi uczestniczyć w aktywności, aby osiągnąć cele? Albo jakie aktywności muszą być wykonywane przez kogoś, aby osiągnąć cele?

Generalnie najchętniej zaczynam od aktywności. W praktyce jest to jednak raczej dość iteracyjny proces.

Proszę pamiętać, że „rola" nie oznacza „osoba". „Osoba" może odnosić się do innych ról, które nie mają nic wspólnego z Twoimi celami, a zamiast tego dotyczą własnych celów tej osoby. Zazwyczaj oznacza to konieczność dodania dodatkowych celów, które muszą być wspierane.

3) Identyfikuj Capabilities
Jaki jest warunek wstępny, aby rola mogła wykonać aktywność?
Capabilities niekoniecznie muszą być czymś wbudowanym w oprogramowanie.

4) Identyfikuj Features i Stories
Co trzeba zrobić, aby stworzyć lub umożliwić Capabilities?
Stories powinny składać się z mniejszych prac. W przypadku Features chodzi raczej o umożliwienie dyskusji na bardziej szczegółowym poziomie.

Niniejszy tekst pochodzi z bloga Jasona Yipa i został przez nas przetłumaczony na język polski.