Jarek ŁojkoSkoro czytasz artykuł o tym jak dzielić User Story to zapewne wiesz już lub przynajmniej domyślasz się, że warto to robić. Chociażby dlatego, aby częściej dostarczać użyteczne kawałki Produktu i szybciej weryfikować nasze hipotezy o ich wartości dla użytkownika. Co zrobić gdy twój zespół na pomysł podzielenia danej historyjki reaguje trzema, mrożącymi krew żyłach słowami – „nie da się…”? Albo co gorsza, po chwilach negocjacji wpada na pomysł, że w takim razie w jednym Sprincie zrobi backend, a w drugim frontend? Zacznijmy od początku.
Jak nie dzielić User Story…?
Zanim odpowiemy sobie na pytanie jak dzielić historyjki użytkownika, powiemy sobie jak… tego nie robić. 😉 Wyobraź sobie teraz nieco abstrakcyjny przykład, że twój zespół ma za zadanie dostarczyć historię użytkownika związaną z upieczeniem tortu weselnego. Tort ma mieć przykładowo dwa poziomy i musi być złożony z trzech kolorowych, kontrastujących ze sobą warstw. Zdaniem zespołu nie jest to możliwe do osiągnięcia w typowej dla nich, jednej iteracji. Po chwilowym buncie w trakcie backlog refinementu, że przecież nie da się podzielić takiej historii na mniejsze, bo tort to tort, musi być dostarczony cały na raz, pada pewna propozycja. A zatem może podzielimy nasze prace następująco, skoro już musimy…
- W pierwszej iteracji zrobimy tylko dolną warstwę z biszkoptu (nie można tego jeszcze nazwać tortem).
- W drugiej dorobimy kolorową, owocową warstwę (wciąż nie jest to tort w całości)
- W trzeciej przygotujemy warstwę czekoladową i dopiero wszystko poskładamy w całość (w końcu mamy tort!).
Czy taki, horyzontalny sposób podzielenia, w czymś nam pomógł? Tort, żeby był tortem musi się składać ze wszystkich warstw, bo przecież kroimy go wertykalnie i dopiero jemy rozkoszując się przenikaniem przez siebie wszystkich smaków i warstw jednocześnie. Nie możemy zaserwować gościom samego spodu, który był dostarczony po pierwszej iteracji i uargumentować takiego stanu rzeczy, że zabrakło nam Sprintów na pozostałe warstwy 😉 Przypomina to nieco bardzo wymowny obrazek Jeffa Pattona z malowaniem Mona Lisy.
Czy kojarzysz taki sposób dzielenia z autopsji? Analogicznie, w rozwoju oprogramowania, zespoły mają tendencję do pomysłów dzielenia historyjek użytkownika na warstwy poziome, takie jak przykładowo: bazy danych, backend, middleware, frontend itp. Efekt jest niestety podobny jak przy wspominanym torcie i jego „przydatności do spożycia”. Użyteczny produkt, funkcjonalność osiągamy dopiero po kilku iteracjach, bo wartość każdej z warstw traktowana osobno jest znikoma.
W podejściu agile każda iteracja musi kończyć się dostarczeniem czegoś użytecznego co pozwoli zebrać informację zwrotną od użytkownika, zanim podejmiemy decyzję co robić w następnej kolejności. Dzięki temu znacząco ograniczamy ryzyko tego, że dostarczymy coś, co nie do końca spełniającego oczekiwania użytkownika końcowego czy interesariusza.
Podsumowując, historie użytkownika dzielimy (kroimy) wertykalnie, przez wszystkie warstwy, a nie horyzontalnie, tak aby w każdej iteracji móc zjeść przynajmniej cienki, ale kompletny kawałek :).
Dzielenie metodą SPIDR
Jest to chyba najczęściej wykorzystywana przeze mnie metoda przy wspieraniu zespołów i Product Ownerów w dzieleniu historyjek. Jej autorem jest Mike Cohn, zachęcam do zapoznania się z jego oficjalnymi materiałami, link znajdziecie na końcu artykułu. SPIDR to oczywiście akronim ułatwiający zapamiętanie kilku formułek, wskazówek, które pozwalają naprowadzić zespół na właściwe tory w dzieleniu historyjek.
Spike
Jest to praktyka zaczerpnięta z Extreme Programming (XP), obecnie stosowana też bardzo często przez zespoły Scrumowe. Spike to z angielskiego szpikulec, igła. Jeżeli kompletnie nie wiem jak zabrać się za podzielenie danej story to wyjmujemy przysłowiową igłę, robimy nakłucie i patrzymy co wypłynie na powierzchnię. Innymi słowy zamiast starać się wykonać daną historyjkę, rezerwujemy sobie konkretną ilość czasu na uzupełnienie wiedzy, przygotowanie dodatkowej analizy, zapoznanie się z technologią, poszukanie podobnych przypadków gdzieś indziej, czyli po prostu, tłumacząc z polskiego na nasze, robimy dobry research ;).
Efektem takiego Spike’a, dzięki zdobytej wiedzy, powinno być przybliżenie nas do odpowiedzi na pytanie jak podzielić daną user story.
Uwaga, pomimo tego, że Spike w akronimie Mike’a Cohna występuje jako pierwszy to korzystamy z niego na końcu i traktujemy jako ostatnią deskę ratunku jeżeli nie pomogę inne sposoby.
Paths
Zastanów się czy twoja historia użytkownika nie opisuje kilku różnych sposobów, ścieżek użytkownika na osiągnięcie tego samego celu. Każda z tych ścieżek to dobra kandydatka na osobną user story. Przykładowo realizacja płatności w sklepie internetowym może odbywać się za pośrednictwem karty, przelewu czy kodu BLIK. Każda z tych opcji dąży do zrealizowania tego samego celu i może być osobną historią użytkownika.
Interfaces
Jeżeli powodem dużego rozmiaru danej story i co za tym idzie konieczności jej podzielenia, jest dostosowanie pod różne rodzaje interface’ów czy urządzeń to może być to kolejna wskazówka na jej pokrojenie. Przychodzi mi tu na myśl przykładowo optymalizacja pod różne rodzaje przeglądarek. Skoro wiemy, że przykładowo 80% naszych użytkowników korzysta z Chrome’a to podzielmy historyjkę według tego właśnie kryterium. Na początku zajmiemy się przeglądarką od Google’a, a potem całą resztą.
Można też oczywiście rozpatrywać inne warianty takie jak systemy operacyjne, czy urządzenia mobilne vs. stacjonarne. Warto też skupić się na prostocie interface’u, a pracochłonne upiększenia graficzne (tzw. wodotryski) zostawić na koniec.
Data
Odpowiedz sobie na pytanie czy możliwe jest dostarczenie wartości skupiając się tylko na pewnym, określonym typie danych. Dobrym przykładem są tu wszelkiego rodzaju filtry czy wyszukiwarki. Czy na pewno potrzebujesz od razu mechanizmu sortowania i wyszukiwania produktów po nazwie, dacie, cenie, opiniach, autorze, ilości komentarzy, wydawnictwie, autorze…? Czy może wystarczy na sam początek nazwa i cena? Sprawdź czy twoja nadmiernie spuchnięta historia użytkownika nie próbuje przemycić w sobie wielu różnych danych, z czego jedne są bardziej, inne mniej priorytetowe.
Rules
Czasami user story jest bardzo duże z powodu zbyt wygórowanych standardów, zasad czy reguł. Zastanów się czy nie możesz dorabiać ich stopniowo, a w swojej pierwszej historyjce nieco poluzować. Nie mówię tu oczywiście o rezygnowaniu z wysokiej jakości, ale o odłożeniu na później czegoś, co nie jest niezbędne w danej chwili. Przykładowo może być to czas odpowiedzi, wydajność jakiegoś systemu. Zdecydowanie lepiej jest jeżeli funkcjonalność jest ukończona w danej iteracji, ale działa nieco za wolno niż jeżeli nie działa w ogóle. Sposobów na podniesienie wydajności może być wiele. Pojawia się natomiast pytanie czy priorytet ich realizacji jest wyższy niż inne historyjki użytkownika, które możemy dostarczyć do użytkownika w tym samym czasie i pozyskać na ich temat cenną informację zwrotną.
Metoda CRUD
Czy twoja historyjka zawiera sformułowania takie jak „zarządzanie” czy „konfigurowanie”? Mają one to do siebie, że składają się zazwyczaj z kilku różnych operacji, które z powodzeniem można wydzielić jako osobne historyjki użytkownika. Przykładowo jeżeli twoja historyjka mówi o zarządzaniu kontem czy profilem użytkownika, to może się na nią złożyć:
- utworzenie takiego konta (Create),
- wyświetlenie go (Read),
- aktualizacja czy edycja jakiś danych np. adresu e-mail (Update)
- czy ostatecznie chęć usunięcia konta (Delete).
Wszystkie te operacje tworzą nam kolejny przyjemny akronim CRUD. Zastanów się czy nie możesz zrealizować ich osobno w tej właśnie kolejności. Z pewnością początkowo najistotniejsze jest samo założenie konta użytkownika systemy, a nie od razu zaawansowana jego edycja.
Dzielenie według kroków procesu
Jeżeli dany proces biznesowy zapisany w historyjce składa się z kilku większych kroków to prawdopodobnie każdy z nich da się również zapisać jako oddzielną story. Najprostszy możliwy przykład to realizacja zamówienia w sklepie internetowym. Składa się on po pierwsze z przeglądania produktów w sklepie, po drugie z dodania ich do koszyka, a po trzecie z płatności. Gdzieś po drodze jest też zapewne decyzja czy zakupu dokonujemy jako gość czy logujemy się do swojego konta. Każdy krok tego procesu realizuje pewną wartość biznesową i z powodzeniem może być realizowany osobną user story.
Dzielenie User Stories według kryteriów akceptacji
Zdarzają się też historyjki użytkownika z bardzo długą listą kryteriów akceptacji, które przemycają tak na dobra sprawę kolejne funkcjonalności. Zamiast rozszerzać i dodawać kolejne kryteria, wydzielmy je do osobnej story. Dla lepszego zobrazowania posłużę się przykładem.
Jako osoba przebywająca na kwarantannie, chcę zamówić zakup spożywcze online z dostawą do domu, ponieważ nie mogę wychodzić i chcę ugotować obiad.
Kryteria akceptacji:
- Istnieje wybór spośród supermarketów Biedronka, Lidl, Carrefour, Tesco, Żabka
- Istnieje możliwość dowolnego dodawania i usuwania produktów zanim potwierdzę zamówienie
- Istnieje możliwość zaplanowania dostawy na konkretną datę godzinę
- Istniej możliwość dodatkowego zamówienia toreb termicznych na produkty z lodówki
- Istnieje możliwość płatności online lub przy odbiorze
- Dostępna jest informacja o promocjach w danym sklepie
- Dostępna jest informacja o godzinach otwarcia danego sklepu
Całkiem sporo prawda? Można by w tym miejscu wypisać oddzielne story przykładowo na różne metody płatności (początkowo tylko online), obsługę sklepów dodawaną stopniowo (na start tylko Biedronka), informacje o promocjach i rabatach czy chociażby planowanie na konkretną godzinę i datę (początkowo tylko „opcja, najszybciej jak to możliwe”).
A Wy której metody dzielenia historyjek użytkownika używacie najczęściej? A może macie własną :)? Zachęcam do pozostawienia komentarza poniżej.
Dodaj komentarz