Temat dzielenia wymagań jest jednym z naszych ulubionych. Pierwszy raz na poważnie zajęliśmy się nim blisko 10 lat temu, gdzie na pewnym projekcie na którym borykaliśmy się z dość typowym problemem: słyszeliśmy, że „nie da się” podzielić niektórych wymagań.
Specyfika naszej pracy…
Temat dzielenia wymagań jest tak stary, jak stare jest iteracyjne podejście do wytworzenia oprogramowania. Skoro mamy pracować w krótkich okresach, to w ramach tych okresów musimy coś kończyć. I to tak „na dobre”. W Scrumie na przykład każdy element, który chcemy uznać za zakończony musi spełniać Definition of Done. W wariancie minimum zarówno DoD, jak i „skończenie na dobre” musi oznaczać, że zrobiliśmy to tak, że nie będziemy do tego wracać. I tu pojawia się problem.
Często spotykamy się ze stwierdzeniem, że „specyfika pracy nie pozwala na posiadanie wymagań które da się zmieścić w jednej iteracji”, czyli na przykład dwutygodniowym Sprincie. Podstawowy argument to „rzeczy, którymi się zajmujemy są zbyt duże i zbyt skomplikowane; przecież przez dwa tygodnie to można co najwyżej zrobić jakąś pierdołę”.
Takie stwierdzenia to zupełnie niezrozumienie podejścia do pracy w krótkich iteracjach. Osoby, które mówią takie rzeczy bardzo często też myślą o zadaniach, a nie o wymaganiach. Bo o ile zadania faktycznie zajmują tyle, ile zajmują i zwykle nie są negocjowane, to wymagania można spełniać na różne sposoby. Co więcej, wymagania można dzielić w taki sposób, żeby z jednej strony miało to sens, a z drugiej strony nie było wykonywaniem skomplikowanej czynności krok po kroku. Mówiąc inaczej: wymagania można dzielić na elementy, które na raz są i małe, i wartościowe.
Po co dzielimy wymagania?
Wymagania dzielimy z trzech głównych powodów: chcemy widzieć postęp prac, chcemy weryfikować nasze rozwiązania szybciej niż dopiero po skończeniu całości oraz chcemy budować rozwiązania, które są po prostu lepsze.
Jeżeli chodzi o postęp prac, to chyba nie potrzeba tutaj dalszych wyjaśnień. Jeśli robimy jedną dużą rzecz, która zajmuje nam trzy miesiące, to cały czas jesteśmy „w trakcie pracy” (a.k.a. In Progress). Ale jeżeli podzielimy tą rzecz na siedemnaście wymagań i zrobimy z nich pięć, to mniej więcej widzimy, w jakim jesteśmy stadium zaawansowania. Tu oczywiście trzeba dodać, że w podejściu zwinnym te siedemnaście wymagań w trakcie pracy może nam spuchnąć do dwudziestu jeden. Tylko, że nawet w takim układzie wiemy więcej o postępie naszych prac, niż jeżeli „robimy i będziemy robić” jedno duże wymaganie całymi miesiącami.
Weryfikacja naszych rozwiązań też jest oczywista. Z jednej strony mamy np. Sprint Review, gdzie możemy zebrać informacje zwrotne. Z drugiej strony pracując zwinnie chcemy jak najszybciej weryfikować nasze pomysły wśród odbiorców. Ale zamykając mniejsze wymagania jesteśmy też w stanie wypuszczać nowe wersje – na przykład do ograniczonej grupy odbiorców albo wdrażać je kawałkami.
Tu warto podkreślić, że dla obu powyższych punktów ekstremalnie ważnym jest to, że jak już coś zrobimy to jest to zrobione i nie będziemy do tego wracać.
Lepsze rozwiązania
Trzecim powodem dla którego dzielimy wymagania, to chęć zwiększenia wartości naszego produktu. Innymi słowami, chcemy po prostu robić rzeczy lepsze.
Tutaj z wielką pomocą przychodzi nam chociażby format User Story, dzięki któremu nie tylko pokazujemy po co chcemy zrobić niektóre elementy, ale też jakie konkretnie mają one kryteria akceptacji. Te z kolei jawnie wspierają zasadniczy cel istnienia wymagania. Trochę inaczej zbudujemy wyszukiwarkę produktów, dzięki której klienci sprawdzają ceny i dostępność określonych wariantów, a inaczej taką, która służy po prostu do dodania kolejnego produktu do koszyka.
Ktoś może powiedzieć, że te dwa aspekty wyszukiwania niewiele się od siebie różnią. Pamiętajmy jednak, że mogą być wykorzystane w różnych częściach różnych procesów i mogą być reużywalne. W takim przypadku będą też zrealizowane nieco inaczej. Wymaganie „szukam, żeby kupić” to jednak nieco inne wymaganie niż „szukam, żeby sprawdzić dostępność konkretnego wariantu”.
Jak by nasze wymaganie nie było małe, warto zastanowić się po co ktoś ma je wykorzystywać i dopasować szczegóły do tego, aby spełnić dokładnie te potrzeby. I wtedy zrobimy je lepiej, niż „wyszukiwarkę” będącą jednym z pięćdziesięciu kryteriów akceptacji w dużym Epiku.
W poszukiwaniu wartości biznesowej
I tu wracamy do naszego dzielenia wymagań. Jeśli rozważamy cały proces zakupowy, to samo wyszukanie produktu ma znikomą wartość. Ktoś może nawet powiedzieć „po co mamy to wyróżniać jako osobne wymaganie, jak zrobimy całość to dopiero to pokażemy”. Ale już wiemy, że w ten sposób nie będziemy widzieć postępów prac, ani nie będziemy mogli zebrać informacji zwrotnej o tym konkretnym elemencie.
Jednak jeszcze większą stratą jest traktowanie tej nieszczęsnej wyszukiwarki jako „bezwartościowego” elementu. Nawet jeśli zamkniemy sieęna proces zakupowy, to przecież uzasadnienie biznesowego tego wymagania jest wartościowe – „szukam, żeby dodać do koszyka ten konkretny interesujący mnie produkt, a nie przebijać się przez dziesiątki stron katalogu bądź wyników wyszukiwania”. Jeżeli to nie jest (mała) wartość, to ja nie wiem co nią jest.
Idąc jeszcze dalej, możemy potraktować różne aspekty wyszukiwania jako osobne wymagania i zrobić to po prostu… lepiej. Ale to temat bardziej na nasze praktyczne szkolenia. Jeśli nie możecie się doczekać kolejnego warsztatu, to proponuję zapisać się na listę mailingową. Tam już w najbliższy czwartek opowiem o tym, jak faktycznie znaleźć wartość biznesową tam, gdzie jej rzekomo nie ma.
Wszystkie znane nam sposoby na dzielenie wymagań i nie tylko możecie poznać na szkoleniach z cyklu Wymagania i User Stories (w tym w wersji Weekend z User Stories).
