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ć, to zazwyczaj taki, którego nie można 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 liczbą i nakładem pracy; ma natomiast problem z nadmierną liczbą niewiadomych. Podział zadań pozwala ograniczyć liczbę niewiadomych do momentu, gdy zadanie nabierze 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ó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ół głosuje na wartości 13 i 20, a następnie przeprowadza kolejne głosowania, aby osiągnąć zbieżność, a nie rozbieżność.
• 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ę.
• Status „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ędzi cały sprint na próbach realizacji zadania, a to, co pozostało, zostanie przeniesione do kolejnego sprintu (co jest niekorzystne, ponieważ przeniesione zostaną właśnie te elementy, które okazały się najtrudniejsze) albo ukończy podzbiór gotowy do wydania i uzna zadanie za zakończone, podczas gdy reszta pozostanie w stanie niekompletnym. 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ą informacyjną jest szeroki rozrzut wyników. Rozrzut kart od 3 do 13 nie oznacza rozbieżności w ocenie liczbowej. To dwie różne perspektywy 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 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ś z obecnych 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, lub 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 wdrożyć samodzielnie. Podejście „najpierw backend, frontend w następnym sprincie” dzieli zadanie tak, jak nóż dzieli ciasto: otrzymuje się dwie połowy niczego. Pionowy fragment 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łne omówienie tej zasady można znaleźć w sekcji „Podział poziomy a pionowy”.

Skuteczne schematy podziału

Model SPIDR (spike, path, interface, data, rules) obejmuje większość sytuacji związanych z podziałem i należy go rozważyć w pierwszej kolejności. Kilka innych wzorców powtarza się na tyle często, że warto je wymienić.

Etapy procesu

Opis, który obejmuje 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 najprzejrzystsza technika w całym zestawie narzędzi: każdy opis dostarcza rozpoznawalny, widoczny dla użytkownika element, każdy można zaprezentować, a zakres każdego z nich można określić osobno.

Test składa się z jednego pytania, które należy zadać na każdym etapie: czy użytkownik odniósłby z tego korzyść, gdybyśmy wprowadzili tę funkcję, a 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: 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 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 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 jednak 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 za każdy „etap” odpowiada dokładnie jeden specjalista. Prawdziwe etapy przepływu pracy obejmują cały stos technologiczny, ponieważ tak właśnie wygląda w przypadku etapów, z którymi ma do czynienia użytkownik.

Różnice w zasadach 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ę jej wariantami. 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 w pierwszej kolejności wdrożyć scenariusz prawidłowego działania; 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 awarii, o ile w międzyczasie zaakceptuje się gorsze zachowanie w przypadku awarii i faktycznie powróci się do tej kwestii.

Jakość odroczona

Wprowadźcie tę część bez dopracowania (bez podpowiedzi, bez animacji, bez nadpisywania ustawień przez administratorów), a następnie wprowadźcie dopracowanie jako osobną historię. To rozwiązanie sprawdza się o ile faktycznie wprowadzicie to dopracowanie. Zespoły, które zaniedbują jakość i nigdy do tego 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; jest 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: nieprzetestowany kod stanowi obciążenie, a nie odrębną część. Jeśli dana część pracy ma wartość dopiero po wdrożeniu jej odpowiednika, nie podzielili Państwo zadania. Po prostu je zaplanowali Państwo.

Gdy nie można podzielić artykułu: należy opublikować artykuł 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ę 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 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 zadanie.

Jeśli pojedynczy etap nadal nie wystarczy, oznacza to, że projekt nie jest jeszcze gotowy; to dopiero początek. Proszę potraktować go jako całość, przedstawić harmonogram i przestać udawać, że wystarczy jeden sprint, by go zrealizować.

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 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?

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 najtrudniejszy fragment) 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 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ża rozpiętość wyników nie oznacza sporu co do wartości liczbowych; 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 tego działania jest wiedza (dokument, prototyp, wynik pomiaru), 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 idealny, a następnie scenariusz niepożądany, jakość odroczona oraz kwestie operacyjne, a także pięć etapów SPIDR. Kryterium oceny wszystkich tych elementów jest takie samo: czy użytkownik odniósłby korzyść, gdyby wprowadzono ten element, a pozostałe nie zostały wdrożone?

Materiały powiązane

• „Szacowanie w metodologii agile: kompletny przewodnik” stanowi centralne źródło wszystkich informacji na ten temat.
• W artykule poświęconym metodzie podziału historii SPIDR szczegółowo omówiono pięć sprawdzonych linii podziału.
• Podział poziomy a pionowy to zasada leżąca u podstaw każdego udanego podziału.
• Pojęcie „gotowości” oznacza etap, który musi przejść podział na etapy, zanim ponownie zostanie włączony do sprintu.
• Udokumentowanie listy zadań to spotkanie, podczas którego faktycznie dochodzi do podziału zadań.