Pamiętacie hasło „wrzesień miesiącem Kanbana”? Idziemy za ciosem. Rozmawiałem ostatnio z Tomkiem i decyzja zapadła, październik będzie miesiącem User Stories i ogólnie wymagań. Nie rozpoczynamy od podstaw, bo je już mamy. Dziś interesuje nas źródło User Stories.
Wymagania
Pisząc „źródło” wcale nie mam na myśli „skąd się wziął pomysł na US-y”. Podstawy już mamy, definicję User Story opisaliśmy prawie dwa lata temu. Skoro wiemy czym są, zastanówmy się skąd się biorą. Sprawa może wyglądać trywialnie i możemy w ciemno odpowiedzieć, że od… interesariuszy. To prawda, ale nie jest to jedyne źródło wymagań, które mogą pojawić się w naszym Backlogu.
Tekst ten dedykuje szczególnie Product Ownerom i Proxy Product Ownerom, którzy na pewno dużo na nim skorzystają. Umiejętność identyfikowania źródła zmian jest przecież jednym z bardziej istotnych aspektów Waszej pracy. Nie zamykając się jedynie na tę grupę, informacje zawarte w dzisiejszym wpisie będą atrakcyjne dla całych Scrum Teamów i wszystkich uczestniczących w procesie wytwarzania produktu.
Źródła wymagań
Przechodząc do meritum, źródłami wymagań są wszyscy ludzi i wszystkie wydarzenia, które będą miały wpływ na nasz Produkt.
Powyższe jest oczywistą oczywistością, zejdźmy więc niżej. Starając się określić źródła US-ów moglibyśmy podzielić je na dwie grupy: wewnętrzne i zewnętrzne. Wewnętrzne to źródła, które dotyczą Zespołu i procesu wytwarzania Produktu. Zewnętrzne dotyczą z kolei wszystkich źródeł, które generują wymagania, lecz są niezależne od działań związanych z rozwojem rozwiązania.
Jako doskonały przykład źródła wewnętrznego służyć może sam Zespół. Jak zbiór ludzi odpowiedzialnych za rozwój Produktu, zespół ma w swojej kompetencji proponowanie najlepszych rozwiązań prowadzących do zaoferowania wartości. Tak, Zespół sam w sobie może być również generatorem wymagań. Osobną sprawą jest fakt, że Product Owner powinien znaleźć dla takiego wymagania priorytet (często wspólnie z Klientem) i finansowanie. To jest jednak temat na zupełnie inną dyskusję.
Z Organizacji…
Przyjrzyjmy się zatem pozostałym źródłom. Rozpoczynając od tych wewnętrznych, prócz Zespołu wyróżnić możemy: spriorytetyzowany Product Backlog, kryteria Definition of Done, wymagania biznesowe i w końcu – interesariuszy. O ile dość oczywistym jako źródło wymagań wydaje się być Product Backlog (to z niego pochodzą historyjki) i wymagania biznesowe, o tyle Definition of Done takie oczywiste już nie jest.
Nie od dziś mówimy, że poszczególne elementy kryteriów akceptacji mogą – kolokwialnie mówiąc – nieźle zamieszać. Może okazać się, że realizacja wymagania, właśnie przez kryteria Definition of Done będzie bardziej skomplikowana, niż nam się pierwotnie wydawało.
Aby zobrazować powyższe weźmy na przykład wymyślone na poczekaniu kryterium o nazwie „system ma być zgodny z Dyrektywą (UE) 2016/680„. Sama funkcjonalność naszego systemu jest do zrobienia w czasie X, konieczność spełnienia dodatkowego wymagania może wiązać się z kolejnymi pracami, które musimy wziąć pod uwagę. Proste równanie X + Y = realizacja wymagania. Samo X nie wystarczy!
I z jej otoczenia…
Przejdźmy zatem do źródeł zewnętrznych. Do tych zaliczyć możemy użytkowników, odbiorców, klientów rozwiązania oraz prawo i regulacje. W tym przypadku niewiadomych będzie mniej.
Klienci rozwiązania to osoby, dla których je budujemy, ich zadowolenie i konieczność dostarczenia odpowiednio wysokiej wartości biznesowej powinno być dla nas dobrem nadrzędnym. Prawo i regulacje z kolei to kategoria, która jest aż nader oczywista. To między innymi ta grupa źródeł jest wymieniana jednym tchem, kiedy zapytamy o źródła wymagań nowych adeptów zwinności. „Prawo i Prezes„, to ta najczęściej występująca odpowiedź.
Jak ma się zewnętrzne źródło wymagań do wspominanych przez nas person? Nie wchodząc za bardzo w detale, persony wyznaczają nam grupy użytkowników, dla których rozwiązanie ma zostać przygotowane. Prawie zawsze, a przynajmniej powinniśmy tak robić, realizujemy funkcjonalność dla głównej persony rozwiązania. Po jej dostarczeniu uzupełniamy rozwiązanie o kolejne zidentyfikowane grupy użytkowników, dostosowując funkcjonalność do ich specyfiki.
Źródła User Stories
Patrząc na całokształt nie trudno odnieść wrażenie, że często pierwotnie przez nas identyfikowane źródła „prawo i Prezes” to tylko wierzchołek góry lodowej. Faktyczne źródła wymagań w naszym projekcie obejmują szereg różnych miejsc, w których takowe powstają i, co najważniejsze, wpływają na nasze rozwiązanie. Nie każdy zdaje sobie jednak z tego sprawę.
Podchodząc do rozumienia źródła wymagań w sposób przytoczony powyżej mamy pewność, że wzięliśmy pod uwagę wszystkie elementy, które będą miały wpływ na przygotowywane rozwiązanie. Nie da się przygotować dobrego Produktu patrząc wyłącznie na chciejstwa klienta bądź Prezesa naszej firmy. Tak samo nie da się przygotować dobrego rozwiązania patrząc wyłącznie na jego zgodność z regulacjami czy prawem. Potrzebujemy czegoś więcej.
Tym czymś więcej są pozostałe strumienie, które z jednej strony wpływają na kompletność wymagania, z drugiej zaś powodują, że rozwijając je podążamy w kierunku zgodnym z oczekiwaniami czy to interesariuszy czy klientów rozwiązania. Dopiero po złożenia wszystkiego w jedną całość trafimy do świata wymagania „prawie idealnego”. A na pewno bliższego temu, co chcemy osiągnąć pracując nad Produktem.
