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 problem z nadmierną liczbą niewiadomych. Podział zadań ogranicza liczbę niewiadomych do momentu, gdy zadanie nabiera kształtu pracy, która została już wcześniej wykonana, a szacunki się zbieżają.

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

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

• Zespół głosuje na 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ż jeden zespół.
• 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ę częściowego zestawu gotowego do dostarczenia i uznaje zadanie za zakończone, podczas gdy reszta pozostaje w stanie nieukończonym. Oba te 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

Gdy zespół o różnej liczebności pracuje wspólnie z wykorzystaniem metody planning poker, największą wartością informacyjną jest szeroki rozrzut wyników. Rozrzut kart od 3 do 13 nie oznacza rozbieżności w ocenie liczbowej. To dwie różne historie udające jedną. Osoba, która przyznała ocenę 3, dostrzega jeden zakres; osoba, która przyznała ocenę 13, dostrzega inny zakres. Ponowne głosowanie nie doprowadzi do pogodzenia tych stanowisk; 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 – sytuacje skrajne.
• Jedna osoba zakłada, że projekt już istnieje; inna zakłada, że to ona go opracowuje.
• Jedna osoba zajmuje się oszacowaniem zakresu zapytania, a druga – oszacowaniem zakresu wdrożenia.
• Jedna osoba wie, że ta zależność istnieje; druga – nie.
• Jedna osoba zajmuje się analizą wymagań dla kogoś obecnego w sali; zadanie to należy do innego zespołu.

Większa szczegółowość rzadko rozwiązuje ten problem: skutkuje dłuższym zgłoszeniem, a nie dokładniejszym oszacowaniem. Rozbicie natomiast tak: na szczyt, jeśli niewiadomą jest przyczyna, na pionowe segmenty, jeśli niewiadomą jest zakres. Rozłożenie na dwie karty nie oznacza, że zespół nie jest zgodny. Oznacza to, że zespół głosuje nad różnymi zadaniami. Proszę to odesłać.

Proszę kroić w pionie, a nie w poziomie

Podział musi być pionowy, a nie poziomy: cienki wycinek, który faktycznie można dostarczyć samodzielnie. Podejście typu „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 wdrożenie 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

Funkcja SPIDR (spike, path, interface, data, rules) obejmuje większość sytuacji związanych z podziałem i jest to pierwsze miejsce, w którym należy szukać rozwiązania. 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 sprawdza się, jest to najprzejrzysta 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 składa się z jednego pytania, zadawanego na każdym etapie: czy użytkownik odniósłby z tego korzyść, gdybyśmy wprowadzili tylko tę funkcję i nic więcej? „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: sytuacja użytkownika, którego zgłoszenie nie zostaje przesłane, pogarsza się w porównaniu z poprzednim stanem. Jeśli odpowiedź brzmi „nie”, dany etap jest podzadaniem, a nie opisem funkcji, i przepływ pracy nie ulega w tym miejscu rozgałęzieniu.

Szybsza wersja tego samego testu: czy każdy etap mógłby trafić 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 działającą 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. Są to również poziome wycinki z nałożonym na nie słownictwem związanym z przepływem pracy, a żaden z nich nie dostarcza użytkownikowi żadnej funkcji. Cechą charakterystyczną jest to, że za każdy „etap” odpowiada dokładnie jeden specjalista. Prawdziwe etapy przepływu pracy obejmują cały stos, 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 reguł. W pierwszej kolejności należy wdrożyć najpowszechniejszą regułę; następnie należy wdrożyć jej warianty. Każdy wariant stanowi odrębne zadanie z własną grupą użytkowników.

Scenariusz pozytywny, a następnie scenariusz negatywny

Jest to ściśle powiązane z podejściem Path w ramach SPIDR. Należy wdrożyć ścieżkę powodzenia; 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 nadpisania ustawień przez administratorów), a następnie wprowadźcie dopracowaną wersję jako osobną funkcję. To rozwiązanie sprawdza się o ile faktycznie wprowadzicie tę dopracowaną wersję. Zespoły, które zaniedbują jakość 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; oznacza to jedynie 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 osobny element. Jeśli dana część pracy ma wartość dopiero po wdrożeniu jej „siostrzanej” części, nie podzielił Pan zadania. Zaplanował je Pan jedynie.

Gdy nie da się podzielić artykułu: opublikuj go w całości

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ę test obciążeniowy: badanie o ściśle określonym czasie trwania, którego wynikiem jest wiedza (dokument, prototyp, zalecenie, pomiar), a nie gotowy kod produktu. Po jego zakończeniu jest Pan w stanie rzetelnie oszacować rzeczywisty zakres prac.

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 Pan/Pani niewłaściwego narzędzia: nie udziela się odpowiedzi na żadne konkretne pytanie lub rezultatem jest stwierdzenie „funkcja została zrealizowana”. Pierwszy z nich oznacza, że zespół w rzeczywistości nie ma wątpliwości; drugi oznacza, że jest to historia.

Jeśli pojedynczy fragment nadal się nie mieści, oznacza to, że projekt nie jest jeszcze gotowy; to dopiero początek. Proszę potraktować go jako całość, przedstawić harmonogram i przestać udawać, że uda się go zrealizować 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, ścieżka, interfejs, dane, reguły. Wybierzcie tę, która daje wycinek, który faktycznie mogliby Państwo udostępnić.

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

Proszę celowo podzielić zadanie przed rozpoczęciem sprintu. Zadanie, które nie zmieści się w ramach sprintu, zostanie przeniesione na kolejny sprint w niekorzystny sposób (pozostała część to zazwyczaj to, co było najtrudniejsze) lub dostarczone 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 na mniejsze części zamiast szacować jego nakład?

Gdy zespół nie jest w stanie zmieścić tego w ramach sprintu, gdy wyniki głosowania są bardzo rozbieżne (np. 3 obok 13), gdy na więcej niż kilka pytań doprecyzowujących pada odpowiedź „to zależy” lub gdy historia dotyczy więcej niż jednego zespołu. Duży rozrzut ocen 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 cechy 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 prawidłowy, a następnie scenariusz nieprawidłowy, jakość odroczona oraz kwestie operacyjne, a także pięć etapów analizy SPIDR. Kryterium oceny dla wszystkich tych elementów jest takie samo: czy użytkownik odniósłby korzyść, gdyby wprowadzono właśnie ten etap, a pozostałe nie zostały wdrożone?

Warto przeczytać

• Szacowanie w metodologii agile: kompletny przewodnik stanowi centralne źródło wszystkich informacji na ten temat.
• Podział fabuły w grze SPIDR zawiera szczegółowe omówienie pięciu sprawdzonych punktów podziału fabuły.
• Podział poziomy a pionowy to zasada leżąca u podstaw każdego dobrego podziału.
• Definicja gotowości to etap, który podzielona historia musi przejść, zanim ponownie zostanie włączona do sprintu.
• Udokumentowanie zaległości to etap, podczas którego faktycznie dochodzi do podziału zadań.