Podział opowieści użytkownika, które nie mieszczą się w ramach sprintu

Podział opisu użytkownika polega na rozbiciu jednego, zbyt obszernego opisu na mniejsze opisy, z których każdy nadal dostarcza użytkownikowi coś, z czego może skorzystać. Opis, którego nie da się oszacować, zazwyczaj oznacza, że nie można go jeszcze wdrożyć — a podział jest działaniem, które pozwala ponownie umieścić go na tablicy.

Większość rozmów typu „nie potrafimy tego oszacować” to w rzeczywistości rozmowy dotyczące podziału zadań. Zespół nie boryka się z problemem związanym z liczbami i nakładem pracy; ma natomiast do czynienia z problemem zbyt dużej liczby niewiadomych. Podział zadań pozwala ograniczyć liczbę niewiadomych do momentu, gdy zadanie nabierze kształtu pracy, która została już wcześniej wykonana — a wówczas szacunki się zbieżają.

Kiedy należy zaprzestać szacowania i przejść do podziału

Zadanie, którego nie da się zrealizować w ramach jednego sprintu, nie stanowi problemu związanego z rozmiarem, lecz z kształtem. Proszę zwracać uwagę na następujące sygnały:

• Zespół wybiera wartości 13 i 20, a następnie przeprowadza kolejne głosowania, aby osiągnąć zgodność, a nie doprowadzić do podziału.
• Odpowiedź „To zależy” dotyczy więcej niż kilku pytań doprecyzowujących.
• Akcja tej historii rozgrywa się na terenie obejmującym więcej niż jedną drużynę.
• Oznaczenie „Zakończone” wymaga przeprowadzenia kilku wdrożeń.
• Można to opisać w dwóch zdaniach, ale nie w dwóch kryteriach akceptacji.

Jeśli mimo wszystko zdecydują się Państwo kontynuować, zespół spędza cały sprint na próbach realizacji zadania, a to, co pozostało, przenosi na kolejny sprint — co jest niekorzystne, ponieważ przenoszone są właśnie te elementy, które okazały się najtrudniejsze — albo kończy realizację podzbioru gotowego do wydania i uznaje zadanie za zakończone, podczas gdy reszta pozostaje w połowie zrealizowana. Oba rozwiązania są gorsze niż celowe podzielenie zadania przed rozpoczęciem sprintu.

Dlaczego duża różnica w wynikach głosowania oznacza podział, a nie powtórne głosowanie

Kiedy zespół o różnej liczebności współpracuje przy użyciu metody planning poker, największą wartością jest właśnie szeroki rozrzut wyników. Rozrzut kart od 3 do 13 nie oznacza braku porozumienia co do liczby. To dwie różne koncepcje udające jedną. Osoba, która przyznała 3, dostrzega jeden zakres; osoba, która przyznała 13, dostrzega inny zakres. Ponowne głosowanie nie pozwoli ich pogodzić — zadaniem jest rozmowa na temat tego, który zakres jest rzeczywisty. Oto, co zazwyczaj dzieje się w tle:

• Jedna osoba ocenia scenariusz optymalny, a druga – przypadki skrajne.
• Jedna osoba zakłada, że projekt już istnieje; inna zakłada, że to ona go tworzy.
• Jedna osoba zajmuje się oszacowaniem zapotrzebowania na zapytania, a druga – oszacowaniem zapotrzebowania na wdrożenie.
• Jedna osoba wie, że ta zależność istnieje; druga – nie.
• Jedna osoba zajmuje się analizą wymagań dla kogoś z obecnych w sali; zadanie to należy do innego zespołu.

Większa szczegółowość rzadko rozwiązuje ten problem — skutkuje jedynie dłuższym zgłoszeniem, a nie dokładniejszym oszacowaniem. Pomocne jest natomiast podzielenie: na „spike”, jeśli nieznaną wielkością jest przyczyna, lub na pionowe segmenty, jeśli nieznaną wielkością jest zakres. Rozłożenie na dwie karty nie oznacza, że zespół nie jest zgodny. Oznacza to, że zespół głosuje nad różnymi historiami. Proszę to odesłać.

Proszę kroić w pionie, a nie w poziomie

Podział musi być pionowy — cienki wycinek, który faktycznie można dostarczyć samodzielnie — a nie poziomy. Podejście „najpierw backend, frontend w następnym sprintzie” dzieli zadanie tak, jak nóż dzieli ciasto: otrzymuje się dwie połowy niczego. Pionowy wycinek obejmuje każdą warstwę i pozwala na dostarczenie działającej kolumny — jednego przycisku, który działa od początku do końca, nawet jeśli obsługuje tylko jeden przypadek wprowadzenia danych. Pełny opis tej zasady można znaleźć w artykule podział poziomy a pionowy.

Skuteczne schematy podziału

SPIDR — spike, path, interface, data, rules — obejmuje większość sytuacji wymagających podziału i jest to miejsce, od którego należy zacząć poszukiwania. Kilka innych wzorców powtarza się na tyle często, że warto je wymienić.

Etapy procesu

Historia obejmująca całą ścieżkę użytkownika — rejestracja, ustawienie preferencji, potwierdzenie adresu e-mail, wyświetlenie pulpitu nawigacyjnego — często dzieli się wyraźnie na poszczególne etapy. Gdy ta metoda się sprawdza, jest to najprostsza technika w całym zestawie narzędzi: każda historia dostarcza rozpoznawalny, widoczny dla użytkownika element, każdą z nich można zaprezentować, a zakres każdej z nich można określić osobno.

Test polega na jednym pytaniu, zadawanym na każdym etapie: czy użytkownik odniósłby z tego korzyść, gdybyśmy wprowadzili tę funkcję i nic więcej? Funkcja „Ustaw preferencje” przechodzi test — użytkownik, który ma ustawione preferencje, ale nie otrzymał potwierdzenia e-mailowego, nadal może korzystać z serwisu. „Prześlij formularz” nie przechodzi testu — użytkownik, którego zgłoszenie nie zostaje przesłane, znajduje się w gorszej sytuacji niż przedtem. Jeśli odpowiedź brzmi „nie”, dany etap jest podzadaniem, a nie opisem, i przepływ pracy nie ulega w tym miejscu rozgałęzieniu.

Szybsza wersja tego samego testu: czy każdy etap mógłby zostać wdrożony do środowiska produkcyjnego w ciągu trzech sprintów bez wprowadzania żadnych innych zmian, zapewniając spójne doświadczenie na każdym etapie? Jeśli pominięcie etapu powoduje, że użytkownik widzi nieprawidłowo wyświetlaną stronę, podział ten jest pozorny. To właśnie pułapka, w którą wpadają zespoły inżynierów — etapy odpowiadają podziałowi kodu (usługa uwierzytelniania, API preferencji, komponent pulpitu nawigacyjnego), przez co wydają się szczegółowe. Są one rzeczywiście szczegółowe. Stanowią one również poziome wycinki opatrzone terminologią przepływu pracy, a żaden z nich nie dostarcza użytkownikowi żadnej wartości. Cechą charakterystyczną jest to, że każdy „etap” znajduje się w gestii dokładnie jednego specjalisty. Prawdziwe etapy przepływu pracy obejmują cały stos technologiczny, ponieważ tak właśnie wygląda w przypadku rzeczywistych etapów widocznych dla użytkownika.

Różnice w regułach biznesowych

Zadanie obejmujące wiele reguł lub ról — zwykły użytkownik, administrator, klient API — należy podzielić według poszczególnych reguł. Najpierw należy zrealizować najpowszechniejszą regułę; następnie należy zająć się wariantami. Każdy wariant stanowi odrębne zadanie z własnymi użytkownikami.

Scenariusz pozytywny, a następnie scenariusz negatywny

Jest to ściśle powiązane z podejściem Path w ramach SPIDR. Należy w pierwszej kolejności wdrożyć ścieżkę pomyślną; obsługa błędów, ponowne próby i przypadki skrajne pojawiają się później. Użytkownik może osiągnąć sukces nawet przed pełnym opanowaniem scenariuszy awaryjnych — o ile w międzyczasie zaakceptuje się gorsze zachowanie w przypadku awarii i faktycznie powróci się do tej kwestii.

Jakość odroczona

Wprowadźcie na rynek wersję bez dopracowania — bez podpowiedzi, bez animacji, bez nadpisywania ustawień przez administratorów — a następnie wprowadźcie dopracowaną wersję jako osobną aktualizację. To działa o ile faktycznie wprowadzicie tę dopracowaną wersję. Zespoły, które odkładają kwestię jakości na później i nigdy do niej nie wracają, kończą z trwale niedopracowanymi funkcjami.

Działalność operacyjna

Projekt, który z jednej strony dotyczy funkcji dla użytkowników, a z drugiej – kwestii operacyjnych (rejestrowanie, monitorowanie, powiadamianie), dzieli się właśnie wzdłuż tej linii. Najpierw należy wdrożyć część przeznaczoną dla użytkowników; część operacyjna jest kolejnym etapem, który często przebiega szybciej, ponieważ funkcja jest już w środowisku produkcyjnym, a niedociągnięcia są widoczne.

Co nie stanowi prawdziwego rozłamu

„W tym sprincie frontend, w następnym backend” nie oznacza podziału — to odłożenie terminu dostawy, ponieważ żadna z tych części nie jest dostarczana samodzielnie. „Najpierw to zbudować, a potem napisać testy” ma ten sam charakter: niesprawdzony kod stanowi obciążenie, a nie odrębną część. Jeśli dana część pracy ma wartość dopiero po wdrożeniu jej „siostrzanej” części, nie podzielili Państwo tego zadania. Po prostu je zaplanowali Państwo.

Gdy nie da się podzielić artykułu: należy opublikować skrót

Czasami niewiadomą jest sam zakres zadania — nikt wcześniej tego nie robił, interfejs API dostawcy nie dostarcza odpowiedzi na kluczowe pytanie dotyczące obciążenia, albo realizacja zadania zależy od danych, których nikt jeszcze nie posiada (aktualna wartość p99, aktualna liczba wywołań, aktualna struktura danych). Właśnie wtedy przeprowadza się analizę typu „spike”: ograniczone czasowo badanie, którego wynikiem jest wiedza — dokument, prototyp, zalecenie, pomiar — a nie gotowy kod produktu. Po jego zakończeniu można rzetelnie oszacować rzeczywisty zakres zadania.

Spiki są często niewłaściwie wykorzystywane w stylu: „po prostu zacznijmy i zobaczmy, co z tego wyjdzie”. To nie jest spike — to nieoszacowana historia z dodatkowymi etapami. Dwa sygnały wskazujące, że używa się niewłaściwego narzędzia: nie udziela się odpowiedzi na żadne konkretne pytanie lub oczekiwanym rezultatem jest „zrealizowanie funkcji”. Pierwszy z nich oznacza, że zespół w rzeczywistości nie ma wątpliwości; drugi oznacza, że jest to zadanie.

Jeśli pojedynczy etap nadal się nie mieści, oznacza to, że projekt nie jest jeszcze gotowy — to wciąż projekt. Proszę potraktować go jako całość, ustalić harmonogram i przestać udawać, że zmieści się to w ramach jednego sprintu.

Najczęściej zadawane pytania

W jaki sposób dzieli się opowieść użytkownika?

Podzielcie to w pionie — zgodnie z wynikami dla użytkownika, tak aby każdy wycinek obejmował każdą warstwę i dostarczał coś, z czego użytkownik może skorzystać, nawet jeśli obsługuje to tylko jeden przypadek. Model SPIDR wskazuje pięć wiarygodnych linii podziału: szczyt (spike), ścieżka (path), interfejs (interface), dane (data) oraz reguły (rules). Wybierzcie tę, która pozwala uzyskać wycinek, który faktycznie moglibyście udostępnić.

Co należy zrobić, gdy opowieść użytkownika jest zbyt obszerna, by zmieścić się w jednym sprincie?

Należy celowo podzielić zadanie przed rozpoczęciem sprintu. Zadanie, które nie zmieści się w ramach sprintu, jest przenoszone na kolejny — a to, co pozostaje, to zazwyczaj najtrudniejsza część — albo dostarczane jako niekompletny podzbiór. Oba rozwiązania są gorsze niż celowy podział pionowy na części, z których każda jest dostarczana osobno.

Kiedy należy podzielić zadanie zamiast dokonywać jego oszacowania?

Gdy zespół nie jest w stanie zmieścić tego w ramach sprintu, gdy rozrzut ocen jest duży (np. 3 obok 13), gdy na więcej niż kilka pytań doprecyzowujących pada odpowiedź „to zależy” lub gdy zadanie obejmuje więcej niż jeden zespół. Duży rozrzut nie oznacza sporu co do wartości liczbowej — oznacza to, że mamy do czynienia z dwoma historiami udającymi jedną.

Czym jest „spike” w metodologii agile?

Spike to ograniczone czasowo badanie, przeprowadzane w sytuacji, gdy zespół nie jest w stanie oszacować zakresu zadania bez uzyskania dodatkowych informacji. Efektem jest wiedza — dokument, prototyp, pomiar — a nie gotowy kod produktu. Dwie rzeczy odróżniają spike od pracy o nieokreślonym czasie trwania: limit czasowy oraz konkretny wynik.

Jakie są typowe sposoby podziału opisu użytkownika?

Etapy przepływu pracy, warianty reguł biznesowych, scenariusz idealny, a następnie scenariusz niepożądany, jakość odroczona oraz kwestie operacyjne — a także pięć kryteriów SPIDR. Kryterium oceny wszystkich tych elementów jest takie samo: czy użytkownik odniósłby korzyść, gdyby wprowadzono właśnie ten element, a pozostałe nie zostały wdrożone?

Warto przeczytać

• Szacowanie w metodologii agile: kompletny przewodnik — tutaj znajdą Państwo wszystkie niezbędne informacje.
• Podział fabuły w SPIDR — szczegółowe omówienie pięciu sprawdzonych punktów podziału.
• Podział poziomy a pionowy — zasada leżąca u podstaw każdego dobrego podziału.
• Definicja gotowości — etap, który musi przejść podział historii, zanim ponownie zostanie włączony do sprintu.
• Udokumentowanie zaległości — etap, podczas którego faktycznie dochodzi do podziału zadań.