Październik miesiącem… dobrze wiecie czego. User Stories goszczą na naszym blogu nie pierwszy i nie ostatni raz. Dzisiaj tajemniczo brzmiący temat – zwinna analiza. Co to za zwierz?
„Co ja mam z tym zrobić?”
Tekstów o User Story nigdy dość. Dlatego w tym tygodniu publikujemy kolejny, który wprost do US-ów referuje. Próbując pogłębić temat i rozłożyć go na czynniki pierwsze, postanowiłem sięgnąć do źródeł. Po tekście opisującym źródłach wymagań i User Story tym razem zastanawiam się nad tym, co oznacza „zwinna analiza”. Kto i co powinien robić ze zgłoszonymi tematami?
Może się wydawać, że takie pytanie powinna zadać osoba odpowiedzialna za wymagania. Product Owner, kiedy trafia do niego temat zastanowi się w pierwszej kolejności co z nim zrobić. Nie ma problemu, kiedy temat jest jemu znany, a zgłoszone wymagania jest komplementarne i rozwija wytwarzany Produkt. Jest to wówczas naturalna kontynuacja budowanej wartości biznesowej, taki nowy Feature. Ba, pewnie nawet wiemy kto konkretnie się tym zajmie.
Inaczej sytuacja ma się, kiedy dostajemy coś nowego, świeżego. Tutaj zaczynają się schody. W pierwszej kolejności utworzony zostanie prawdopodobnie Epic, który zostanie prawidłowo opisany. Następnie musimy zastanowić się, co właściwie mamy do zrobienia. W najlepszym razie rozpoczniemy żmudny proces analizy. W końcu „jestem Product Ownerem, coś powiedzieć Zespołowi Deweloperskiemu muszę”.
„Analizuję, ale jak głęboko?”
Naturalnie pojawia się w tej sytuacji wątpliwość, jak głęboko zejść z analizą nowego zagadnienia.
„Z jednej strony powinienem umieć odpowiedzieć na pytania Zespołu, wyznaczyć kierunek rozwoju. Z drugiej strony pragmatyczne podejście do tematu, ilość pracy którą mam jako Product Owner wprost mówią mi o tym, że na dokładne rozpatrzenie tematu nie mam za dużo czasu. Co zrobić?”
Z takimi dylematami, mam wrażenie, mierzy się coraz więcej Product Ownerów. Inspiracja do napisania tego testu przyszła jak zwykle pod wpływem chwili. Coraz więcej z PO ma problem z określeniem swojej roli. Z jednej strony Product Owner jest tym umocowanym, a z drugiej wymaga się od niego coraz większego zaangażowania w analizę wymagań. Bo przecież Zespół zapyta! Co ma zrobić, jak nie będzie znał odpowiedzi?
Kluczowa, w sytuacji opisanej powyżej jest odpowiedź na pytanie o strukturę Zespołu. Jeśli brakuje w nim osób z właściwymi kompetencjami, Product Owner staje się właśnie osobą analizującą wymagania. Czy znajdzie on jednak czas na wykonywania swoich „standardowych” obowiązków?
Odpowiedzialny za analizę jest…
Zespół Deweloperski! Można by napisać, że w ramach Zespołu posiadamy przecież kompetencje pozwalające na realizację wszystkich elementów Backlogu. Mamy w nim pewnie też analityka. Ale nie tylko ta rola może dokonywać analizy zagadnienia, choć oczywiście ona jest do tego naturalnie predysponowana. Gdzie jednak znajduje się rozgraniczenie, umiejętność odpowiedzenia na pytanie Zespołu vs. umiejętność powiedzenia, co musi zostać dostarczone? Wydaje mi się, że odpowiedź jest mi dobrze znana.
Product Owner wyznacza kierunek. Oznacza to, że posiadając wiedzę, pozyskaną od interesariuszy, umie powiedzieć „co ma być zrobione”. Czy musi znać szczegóły? Nie, szczegóły ma znać grupa ludzi, która będzie wymaganie realizowała. Co więcej, ta właśnie grupa ma pełen zasób technik, która może PO wesprzeć w jego pracy.
Jeśli naprawdę nic nie jesteśmy w stanie zrobić z naszym wymaganiem, jeśli nie jesteśmy w stanie ugryźć go z żadnej strony zostaje nam ostatnia deska ratunku. Tworzymy spike’a. Po jego zrealizowaniu powinniśmy mieć wiedzę w zakresie ogólnego sensu wymagania. To wystarczy, aby rozpocząć realizację i głębszą analizę tematu w Sprincie.
Zwinna analiza
Zwinna analiza jest częścią procesu zwinnego wytwarzania produktu. Jej efektem jest materiał, najczęściej w postaci User Story, który pozwoli Zespołowi Deweloperskiemu zrealizować wymaganie. Materiał ten ma być użyteczny dla tego właśnie Zespołu, a co za tym idzie powinien zostać przygotować w sposób, który będzie pozwalał na bezproblemową implementację elementów wymagania zgodnie z założeniami i kryteriami akceptacji. Kto dokona tego najstaranniej?
Mówiliśmy na naszym kanale na Youtube o skin-in-the-game. To Zespół ma w tym przypadku skin-in-the-game. Zwinna analiza jest jego domeną. Nie ma znaczenia kto jej dokona, ważny jest efekt w postaci przeanalizowanego, przygotowanego do realizacji wymagania a następnie zrealizowanego dewelopmentu. Nie byłbym sobą, gdybym w takiej okazji nie wspomniał o Product Backlog Refinement. Mam nadzieję, że podobnie jak ja uważacie, że to właśnie to miejsce jest odpowiednie do przygotowania wymagania do realizacji. W procesie tym biorą udział wszyscy członkowie Zespołu, swój pomysł na realizację wymagania może zgłosić zarówno tester jak i programista. A Product Owner siedzi z boku i przysłuchuje się jak przebiega zwinna analiza korygując ją tam, gdzie istnieje taka potrzeba.
