Co składa się na dobrą historię użytkownika (zastosowano INVEST, z przykładami obok siebie)

Historie użytkowników są jednocześnie najczęściej pisanym i najczęściej pomijanym artefaktem w Agile. Większość zespołów pisze je, ponieważ wymaga tego szablon. Większość zespołów je ignoruje stójka ponieważ tak naprawdę nie kształtują dzieła.

Oto praktyczna wersja. Lista kontrolna INVEST zawiera najbardziej elastyczne odniesienia do szkoleń, ale rzadko uczy w konkretny sposób. Jak dobre i złe historie wyglądają obok siebie. Debata na temat wzorca roli. I zasada, która za pomocą jednego nawyku rozwiązuje 80% problemów z jakością zadań.

Szablon „jak… chcę… żeby…”; kiedy pomaga, a kiedy kłamie

Klasyczny format:

Jako [rola] chcę [funkcji], aby [korzyść].

Ten szablon jest przydatne w dwóch przypadkach:

1. Zespół nie jest pewien, dla kogo jest przeznaczona ta praca. Narzucanie roli powoduje, że stajesz przed pytaniem.
2. Zespół nie jest pewien, dlaczego praca ma znaczenie. Narzucanie „aby tak” stawiało Cię przed pytaniem.

Szablon jest bezużyteczny w trzech przypadkach:

1. Rola i korzyści są oczywiste. „Jako zalogowany użytkownik chcę się wylogować, aby móc przestać być zalogowanym”; tak, w porządku, wszyscy wiedzieliśmy. Szablon dodaje szum bez dodawania sygnału.
2. Rola i korzyść są fałszywe. Inżynierowie piszący historie często wymyślają wiarygodnie brzmiącą rolę/korzyść, aby spełnić format, a następnie ignorują oba. „Jako administrator systemu chcę łączyć połączenia z bazą danych, aby poprawić wydajność”. Nikt nie sprawdza, czy administrator systemu tego chciał. To zadanie wewnętrzne.
3. Opowieść jest obowiązkiem, a nie cechą. „Uaktualnij Railsy do wersji 7.1.” Nie ma żadnych korzyści dla użytkownika; korzyść jest wewnętrzna. Wymuszanie formatu historii użytkownika powoduje, że autor kłamie.

Poprawka: napisz wszystko, co wyraźnie przekazuje pracę. Użyj szablonu, gdy wyostrza myślenie, porzuć go, gdy dodaje ceremonii.

INWESTUJ, zastosowano

INVEST to najczęściej cytowany akronim jakości historii: Independent, Negotiable, Valuable, Estimable, Small, Testable. Większość szkoleń przedstawia to abstrakcyjnie. Oto praktyczna wersja każdego z nich wraz z pytaniem, które należy zadać.

ja; Niezależny

Czy można pracować nad tą historią w dowolnej kolejności, bez opierania się na osobnej, jeszcze nie ukończonej historii?

Test: „Gdybyśmy wybrali samą tę historię, bez niczego innego z zaległościCzy moglibyśmy to dokończyć?”

Jeśli nie, zależność musi być wyraźna (połączone zadania) lub historię należy połączyć z jej zależnością. Ukryte zależności to sposób, w jaki odkrycia w połowie sprintu zabijają spójność celów.

Częsta awaria: „Dodaj warstwę buforowania” zależy od „Przeprowadź migrację do nowej instancji Postgres”, ale tak nie jest. W połowie sprintu inżynier zdaje sobie sprawę, że kolejność ma znaczenie. Sprintowe bramki.

N; Do negocjacji

Czy wynik naprawiono, ale wdrożenie otwarte? A może historia jest receptą krok po kroku?

Test: „Czy dwóch różnych inżynierów mogłoby przedstawić tę historię na dwa różne sposoby i obaj osiągnęliby swój cel?”

Jeśli nie, historia jest listą zadań zamaskowaną jako opowieść. Czasami jest to w porządku (prace związane z zapewnieniem zgodności, testy regresyjne), ale to nie jest bajka; to przepis. Nie udawaj, że jest otwarte, gdy tak nie jest.

Częsta porażka: historie z 14 kryteria akceptacji to brzmi jak plan wdrożenia. Zespół nie ma miejsca na znalezienie lepszego rozwiązania.

V; Cenne

Czy historia tworzy coś, co interesariusz może nazwać wartością?

Test: „Gdybyśmy w tym sprincie przesłali tylko tę historię, czy potrafilibyśmy wskazać korzyść i beneficjenta?”

Jeśli nie, historia jest prawdopodobnie zadaniem podrzędnym czegoś innego. Albo połącz to z historią nadrzędną, albo bądź szczery, że umożliwia to pracę, a nie pracę, którą można dostarczyć, i zaakceptuj, że nie powinno to być nagłówkiem sprintu.

Częsta awaria: „Kontroler sprawdzania refaktoryzacji”; sam w sobie żaden użytkownik nie widzi różnicy. To umożliwia. Cenną historią jest „zmniejszenie współczynnika błędów przy kasie do 0,5%”, a refaktor jest jedną z możliwych ścieżek do tego.

mi; Szacunkowy

Czy zespół może uzgodnić przybliżony rozmiar?

Test: "Trzej inżynierowie patrzą na to i mówią mały/średni/duży. Czy zgadzają się w ramach jednego segmentu?"

Jeśli nie, w historii jest zbyt wiele niepewności. Zespół nie ma wystarczającej wiedzy, aby się zaangażować. Albo zainwestuj wyrafinowanie (badania, prototyp, awaria) lub nie umieszczaj tego w sprincie.

Częsta awaria: „Dodaj powiadomienia w czasie rzeczywistym”; bez określenia, gdzie, jak, co je wyzwala, jaki jest tryb awarii. Szacunki wahają się od „1 dnia” do „3 sprintów”.

S; Mały

Czy historię można zmieścić w jednym sprincie? Idealnie w ciągu 2-5 dni?

Test: „Czy pojedynczy inżynier (lub para) może ukończyć to w trakcie sprintu, nawet przy normalnych przerwach?”

Jeśli nie, podziel to. Historie dłuższe niż połowa sprintu to najczęstszy powód, dla którego zespoły nie zdobywają bramek; nie można ich wstrzymać, zrównoleglić ani zmniejszyć ryzyka.

Częsta porażka: historie oceniane na „13 punktów” lub „20 punktów” w 30-punktowym sprincie. Pochłaniają drużynę przez dwa tygodnie; jeśli coś pójdzie nie tak, sprint się skończy.

T.; Testowalne

Czy istnieje wyraźna i możliwa do zaobserwowania kontrola, która pozwala określić, czy historia została ukończona?

Test: „Czy inżynier może zademonstrować wykonalność bez wyjaśnienia?”

Jeśli nie, kryteria akceptacji wymagają dopracowania. „Powinno wydawać się żwawe” nie podlega testowaniu. „Strona ładuje się poniżej 800 ms p95” jest. Zobacz formaty kryteriów akceptacji dla pięciu formatów pasujących do różnych rodzajów pracy.

Typowa awaria: zgłoszenia, w przypadku których „ukończone” oznacza to, co inżynier uważa za prawidłowe. Przegląd PR staje się jedyną kontrolą, a recenzenci nie mają czasu na walidację zachowań funkcjonalnych.

Obok siebie: zła historia → dobra historia

Przykład 1; funkcja

Złe:

Dodaj obsługę zdjęć profilowych użytkownika.

Dobrze:

Jako aktywny użytkownik chcę przesłać zdjęcie profilowe, aby moje komentarze były rozpoznawalne w zajętych wątkach.

Akceptacja:

• Prześlij plik PNG/JPG o rozmiarze do 2 MB ze strony ustawień profilu
• Zdjęcie pojawi się obok mojej nazwy wyświetlanej w komentarzach w ciągu 30 sekund od przesłania
• Zastąpiono stare zdjęcie (brak magazynu dla sierot)
• Domyślny awatar wyświetlany w przypadku braku przesłania

Cele inne niż cele: przycinanie interfejsu użytkownika, wiele obrazów, animowane obrazy.

Dobra wersja jest testowalna, mała (1-2 dni), wartościowa, ma jasny zakres. Linia „bez celów” oszczędza godzinę debaty.

Przykład 2; infrastruktura/platforma

Złe:

Popraw wydajność API.

Dobrze:

Włącz opcję Zmniejsz opóźnienie P95 GET /api/v1/issues od 850 ms do poniżej 300 ms.

Akceptacja:

• 24-godzinne walcowanie P95 w czasie produkcji poniżej 300 ms
• Brak degradacji P99 (obecnie 1,4 s, musi pozostać ≤ 1,6 s)
• Brak regresji na równorzędnych punktach końcowych /api/v1/issues/*

Wskazówki dotyczące implementacji: prawdopodobnie wstępne ładowanie N+1 dla cesjonariusza, ale inżynier ma swobodę wyboru.

Dobra wersja ma konkretny wynik, wymierną akceptację i negocjowalność; inżynier wybiera wdrożenie.

Przykład 3; błąd

Złe:

Czasami logowanie jest zepsute.

Dobrze:

Limit czasu logowania u 4–6% użytkowników w godzinach szczytu (14:00–16:00 w Wielkiej Brytanii), szczególnie w przypadku użytkowników mających na koncie > 500 sprintów.

Akceptacja:

• Zaloguj się w mniej niż 2 sekundy na 95. percentylu, łącznie z godzinami szczytu
• Powtarzalne w fazie inscenizacji z danymi zaszczepionymi; popełniono skrypt reprodukcji
• Zidentyfikowano pierwotną przyczynę i wymieniono ją w opisie PR

Dane testowe: zobacz konto tymczasowe loadtest-1.

Dobra wersja jest powtarzalna, ma wyraźną mierzalność, zawiera nieoczywisty szczegół (segment + pora dnia), który uniemożliwia inżynierowi dotarcie do niewłaściwej przyczyny.

Zasada 30 sekund, która naprawia 80% jakości zadania

Zanim zaakceptujesz historię do sprintu, każdy w zespole powinien być w stanie przeczytać ją w czasie krótszym niż 30 sekund i odpowiedzieć:

1. Jaki jest wynik?
2. Skąd będziemy wiedzieć, że to już zrobione?
3. Co nie w zakresie?

Jeśli znalezienie jakiejkolwiek odpowiedzi na zgłoszeniu zajmie więcej niż 5 sekund, oznacza to, że zgłoszenie nie jest gotowe. Przepisz go teraz (15 minut) lub wytnij ze sprintu. Zaoszczędzisz 4 razy ten czas podczas sprintu.

Trzy konsekwencje, gdy zespoły to przyjmą:

• Udoskonalanie staje się sesjami 30-minutowymi, a nie 90-minutowymi, ponieważ większość historii pojawia się już ustrukturyzowana.
• Planowanie sprintu zajmuje o połowę mniej czasu, ponieważ zespół nie wypisuje zadań podczas planowania.
• W połowie sprintu „czekaj, co to znaczy?” rozmowy spadają o ~70%.

Anty-wzorce, które można zabić od razu

Kilka wzorców historii, które zawsze wskazują na złe dane wejściowe do sprintu:

Historia akapitu zrzutu. 400 słów kontekstu, brak kryteriów akceptacji, brak jasnego zakresu. Zwykle interesariusz wkleił wiadomość na Slacku, a ktoś zrobił z niej zadanie.

Historia 17 kryteriów akceptacji. Albo historia jest zbyt obszerna (podziel ją), albo kryteria udają specyfikację (umieść je w połączonym dokumencie projektowym i odwołuj się do niego).

Historia „do ustalenia”.. „Kryteria akceptacji: do ustalenia.” Historia nie jest gotowa. Nie zaczynaj od sprintu z zadaniami do ustalenia.

Historia naprawiania błędów w łańcuchu. „Napraw X, Y, Z, A, B, C.” Każdy jest osobnym biletem. Historia z pięcioma objawami w tytule to pięć historii.

Historia „rozwiążemy to”.. Inżynier mówi: „Zajmę się tym na bieżąco”. Czasami dotyczy skoków (nazwij to skokiem, określ ramę czasową). Prawie zawsze nie nadaje się do pracy z funkcjami.

Jak przeprowadzić 5-minutową kontrolę jakości historii podczas planowania

Jeśli historie Twojego zespołu są niespójne, dodaj to do planowania sprintu:

Dla każdej historii kandydata:

1. Przeczytaj tytuł na głos. Jeśli ktoś powie „czekaj, co?”, oznacz to.
2. Jedna osoba czyta kryteria akceptacji. Jeśli nie będą w stanie ich przeczytać w ciągu 30 sekund, oznacz to.
3. Zapytaj „co jest nie w zakresie?” Jeśli odpowiedź brzmi „nic nie zostało określone”, oznacz ją.

Oznaczone historie nie wchodzą do sprintu, dopóki nie zostaną napisane od nowa. To brzmi agresywnie. Oszczędza to więcej czasu niż kosztuje w pierwszym tygodniu.

Podsumowanie

• Używaj szablonu roli, gdy wyostrza to myślenie; upuść go, gdy dodaje hałasu.
• INVEST ma decydujące znaczenie przy konkretnym zastosowaniu; Niezależny, zbywalny, wartościowy, szacowany, mały, testowalny.
• 30-sekundowy test (wynik, wykonany test, poza zakresem) wychwytuje 80% złych zadań.
• Pięć antywzorców do odrzucenia: akapit zrzutu, 17 kryteriów, do ustalenia, błędy łańcuchowe. „Rozwiążemy to”.

Historie nie są artefaktem dokumentacyjnym; są narzędziem do wyrównywania. Jeśli nie zorganizują zespołu, zawiodą jedyne zadanie, jakie mają.

Śledzenie rozmiarów historii w stosunku do prędkości? SprintFlint automatycznie oblicza prędkość toczenia, zdobyte punkty i współczynnik trafień; brak dryftu arkusza kalkulacyjnego. Wypróbuj za darmo: 50 bezpłatnych zadań miesięcznie, bez konieczności posiadania karty.