Dzielenie Epiców

Trener Scruma zapytał mnie niedawno o kilka dobrych przykładów, w których duże User Stories (Epiki) zostały podzielone na mniejsze Stories. Chciałbym podzielić się tymi przykładami.

Epik 1: Znalezienie odpowiedniej kampanii marketingowej

Pierwszy przykład dotyczy firmy, która sprzedaje oprogramowanie dużym detalistom (WalMart itp.). Szef działu marketingu musiał zdecydować, jak wydać budżet reklamowy. Dlatego User Story (Epik) została napisana z jego perspektywy. Jego pierwszym dużym celem było:

Jako szef działu marketingu chcę móc przeglądać poprzednie kampanie reklamowe, abym mógł identyfikować i powtarzać dochodowe kampanie.

Członkowie zespołu powiedzieli, że to wyraźnie Epik. Więc poprosiłem ich, żeby zrobili z tego kilka mniejszych Stories:
1a: Jako szef działu marketingu chcę móc wybrać zakres czasowy kampanii reklamowych do przeglądu, aby…
2a: Jako szef działu marketingu chcę móc wybrać, które kampanie (reklamy pocztowe, TV, e-mail, radio itp.) mają zostać uwzględnione w przeglądzie, aby…

(Zwróćcie uwagę, że ponumerowałem Stories tak, aby widać było, z której oryginalnej Story pochodzą. W prawdziwym projekcie niekoniecznie bym to robił – chyba że miałbym narzędzie, które robi to automatycznie.)

Nie wiedziałem dokładnie, jak duże są te dwie Stories i czy należałoby je jeszcze raz podzielić. Zapytałem więc zespół: „Gdybyście musieli oszacować te Stories, jaka jednostka przyszłaby wam jako pierwsza do głowy? Godziny, dni, tygodnie, miesiące czy lata?" W przypadku 1a były to dni, więc Story pozostała bez zmian. W przypadku 1b były to tygodnie i dlatego podzieliliśmy Story ponownie:

• 1b1: Jako szef działu marketingu chcę móc przeglądać informacje o reklamach pocztowych z poprzednich kampanii, aby…

• 1b2: Jako szef działu marketingu chcę móc przeglądać informacje o reklamach TV z poprzednich kampanii, aby…

• 1b3: Jako szef działu marketingu chcę móc przeglądać informacje o reklamach e-mailowych z poprzednich kampanii, aby…

• itd.

Każda z tych Stories miała odpowiedni rozmiar („szacowalibyśmy tę Story w dniach"). Jednak potrzebowały jeszcze pewnych informacji – tzw. "Conditions of Satisfaction", które są w istocie wysokopoziomowymi testami akceptacyjnymi. Dla 1b2 członkowie zespołu napisali na odwrocie karty:

• Ilu widzów z jakiej grupy wiekowej?

• Ilu widzów z jakiej grupy dochodowej?

Przykład 2: Maksymalizacja przychodów hotelu

Ten przykład dotyczy hotelu, w którym celem była maksymalizacja przychodów, czyli właściciel chciał znaleźć najwyższą możliwą cenę za pokoje hotelowe. Ceny były obliczane na podstawie kilku czynników. Były to na przykład ceny pokoi w porównywalnych hotelach, pora roku, duże wydarzenia w pobliżu (gdy Super Bowl lub mistrzostwa świata odbywają się w mieście, ceny tam rosną) itp.

To była oryginalna User Story (Epik):

1: Jako hoteliarz chcę znaleźć optymalną cenę dla moich pokoi hotelowych.
Dla uproszczenia przyjmijmy, że hotel dysponuje tylko jedną kategorią pokoi. Jak wspomniano, wiele czynników może wpływać na cenę pokoju hotelowego. Podstawowy wzór do obliczenia ceny pokoju wygląda następująco:

Cena pokoju = f (a,b,c…)

Ta funkcja podlega różnym czynnikom. Dla każdego z nich istnieje Story:
1a: Jako hoteliarz chcę ustalić optymalną cenę dla moich pokoi hotelowych na podstawie cen z ubiegłego roku.
1b: Jako hoteliarz chcę ustalić optymalną cenę dla moich pokoi hotelowych na podstawie cen porównywalnych hoteli.

Story 1a mówi jedynie, że ceny z poprzedniego roku są uwzględniane w funkcji. Story 1b mówi, że ceny, które inne hotele pobierają, również są wliczane do kalkulacji.

Każda ze Stories była stosunkowo duża (Epik) i oczywiście było ich więcej niż tylko te dwa wymienione powyżej. Dlatego niemożliwe byłoby umieszczenie ich wszystkich w jednym Sprincie. Stories były realizowane stopniowo, więc wspomniany wzór dawał błędną cenę, ponieważ był budowany w następujący sposób:

Cena pokoju = f (a)

potem

Cena pokoju = f (a,b)

potem

Cena pokoju = f (a,b,c)

itd.

Po pierwszym Sprincie obliczenie byłoby Cena pokoju = f (a) i otrzymywano by błędną cenę (której nie można przekazać klientowi). Sam algorytm jest jednak zasadniczo poprawny. Może wartości dla (b) i (c) są zakodowane na stałe lub po prostu ignorowane. Ale w ten sposób można przyrostowo budować takie złożone algorytmy.

Ponieważ Story 1b była nadal zbyt duża, została ponownie podzielona:

• 1b1: Jako hoteliarz mogę określić pewną liczbę porównywalnych hoteli. (W tej firmie używano terminu "Comparable Set".)
• 1b2: Jako hoteliarz mogę dodawać hotele do Comparable Set.
• 1b3: Jako hoteliarz mogę usuwać hotele z Comparable Set.
• 1b4: Jako hoteliarz mogę usunąć cały Comparable Set, którego już nie potrzebuję.
• 1b5: Jako hoteliarz kieruję się cenami pokoi w hotelach z określonego Comparable Set, aby ustalić moje ceny pokoi.

To są dwie dodatkowe Stories:

• 1c: Jako hoteliarz chcę dostosować optymalną cenę moich pokoi hotelowych do przewidywanego obłożenia.
• 1d: Jako hoteliarz mogę ustawiać parametry wpływające na optymalną cenę, takie jak pożądane obłożenie pokoi, minimalne obłożenie i maksymalne obłożenie (może przekraczać 100%).

Podsumowanie dotyczące dzielenia Epików

Prawie wszystkie zespoły na początku mają problem z właściwym dzieleniem User Stories. Z doświadczenia wynika, że w pewnym momencie w ciągu pierwszego roku następuje „klik" i wtedy członkowie zespołu wiedzą, jak dzielić Stories specyficznie dla swojej dziedziny i projektów. Jeśli więc dopiero zaczynasz z Agile lub User Stories, wytrwaj – z czasem staje się to łatwiejsze!