User Story Mapping – wywiad z Tomaszem Piętką
Już za kilka dni w Warszawie odbędzie się Konferencja Inżynierii Wymagań i Analizy Biznesowej. Będzie to już 4-ta edycja wydarzenia organizowanego przez Stowarzyszenie Inżynierii Wymagań. Jednym z prelegentów konferencji jest Tomasz Piętka, którego zaprosiłem do rozmowy, by opowiedział nieco więcej na temat swojego warsztatu, urozmaiconego prezentacją z tajemniczymi rysunkami rodem z Archiwum X…
QA – rysunek z prezentacji Tomasza PIętki przygotowany przez Agatę Magdalenę Nowak
Nowy: Cześć Tomku. Wiem, że od wielu lat zajmujesz się analizą biznesową. Czy mógłbyś powiedzieć, jak zaczynałeś, gdzie teraz jesteś i jakie masz plany na kolejne lata?
Tomasz Piętka: Cześć. Moja przygoda z analizą biznesową zaczęła się ponad dekadę temu, na studiach. Studiowałem ekonomię i równocześnie pracowałem w dużej firmie IT na helpdesku. Odkryłem wtedy, że lubię pomagać ludziom rozwiązywać problemy, szczególnie te bardziej skomplikowane, które mają w styku z nowoczesnymi technologiami. Pomysł na siebie jako analityka biznesowego traktowałem jako połączenie wykształcenia ekonomicznego i zamiłowania do technologii. Obecnie jestem starszym analitykiem w jednym z największych polskich software house’ów jednak niedługo zmieniam rolę i będę zajmował się zarządzaniem produktem.
N: Podczas Konferencji Inżynierii Wymagań i Analizy Biznesowej będziesz prowadzić warsztat. Czego chcesz nauczyć uczestników?
TP: W trakcie mojego warsztatu uczę się przede wszystkim dekompozycji funkcjonalności rozwiązań software, tak aby można było później dostarczyć oprogramowanie w sposób jak najbardziej zwinny. Uczę jak budować backlog oraz nim zarządzać używając narzędzia User Story Mapping stworzonego przez Jeffa Pattona ale także staram się zwrócić uwagę na wiele innych aspektów pracy analityka biznesowego w zwinnym środowisku software development.
User Story Map – rysunek z prezentacji Tomasza Piętki przygotowany przez Agatę Magdalenę Nowak
N: Czy mógłbyś powiedzieć coś więcej na temat User Story Mapping?
TP: Jest to sposób opisywania systemu oparty na mapowaniu poszczególnych akcji użytkownika tego systemu oraz rezultatów i konsekwencji, jakie poszczególne akcje za sobą niosą. Jest to narzędzie, którym analityk biznesowy posługuje się podczas moderacji warsztatów z klientami, ale także używa go podczas codziennej pracy.
N: Jakie są mocne strony tej metody?
TP: Budowanie mapy pozwala na opis wytwarzanego oprogramowania w sposób holistyczny, jednak zdekomponowany na poszczególne elementy. W pracy zwinnego zespołu w skomplikowanych projektach, gdy jedynym narzędziem służącym do opisu budowanego systemu jest Product Backlog – czyli uporządkowania, jednopoziomowa lista pracy, która pozostaje do zrobione bardzo często gubiony jest wysokopoziomowy cel projektu. User Story Mapping pozwala na zbudowanie wspólnego zrozumienia całości. Jest też metodą bardzo intuicyjną i łatwą do zastosowania.
N: Jakie dostrzegasz jej słabe strony i kiedy nie warto robić USM?
TP: Metoda służy do uszczegółowienia koncepcji, która już powinna istnieć. W samym User Story Mappingu nie znajdziemy sposobów na walidację naszych koncepcji, ta praca musi zostać wykonana wcześniej. Stąd samą technikę można traktować jako element inżynierii wymagań, a nie samej analizy biznesowej. USM sprawdza się w dużych projektach, w których występują skomplikowane zależności, integracje, wiele aktorów, więc w mniejszych, mniej skomplikowanych przedsięwzięciach nie zobaczymy pełnego potencjału techniki.
N: Jako tłumacz jednego z artykułów Toma Gilba i uczestnik niedawno przeprowadzonego przez niego Masterclassu, zapewne znasz jego krytyczne spojrzenie dotyczące User Stories. Czy zgadzasz się z jego stanowiskiem i czy może dostrzegasz przestrzeń, w której można by połączyć podejście Gilba z USM?
TP: Ja z tą krytyką się w 100% zgadzam, nigdy nie traktuję samego User Story jako kompletnego sposobu komunikacji tego, co ma być zrobione. Zauważ, że już sam User Story Mapping uzupełnia koncepcję o wizualną reprezentację w postaci mapy. W kontekście tworzenia backlogu User Story to dla mnie po prostu jeden z wielu formatów opisu, wstęp do konwersacji i pracy, którą analityk biznesowy czy inżynier wymagań powinien wykonać wraz zespołem w trakcie prowadzenia projektu. Same User Stories – nawet w postaci mapy o której tutaj mowa – w skomplikowanych systemach nie będą nigdy wystarczające – ja polecam uzupełnianie je choćby o kryteria akceptacji, przypadki użycia, diagramy BPMN czy UML – wszystko, co tak naprawdę w danym momencie uważamy za stosowne. Jeśli chodzi o połączenie metod Toma Gilba z USM to nie widzę żadnych przeciwwskazań. Tłumacząc na świat Gilba – USM służy do tworzenia konkretnego designu, a nie samego opisywania wymagań i wartości. Jest to zupełnie inny aspekt prowadzenia projektu i ja obie te metody stosuje obok siebie z sukcesem.
3C – rysunek z prezentacji Tomasza Piętki przygotowany przez Agatę Magdalenę Nowak