Oszacowanie w procesie tworzenia oprogramowania często jest źródłem napięć między właścicielami produktu a zespołami inżynieryjnymi. Gdy historia jest niejasna, programiści nie mogą podać dokładnych oszacowań nakładu pracy. To prowadzi do niepewnego planowania sprintów, przekroczeń terminów i frustracji zespołu. Przyczyną rzadko jest brak umiejętności technicznych; najczęściej jest to brak jasności w wymaganiach.
Aby wypełnić tę przerwę, historie użytkownika muszą być pisane z precyzją. Powinny zapewniać wystarczający kontekst, aby programista zrozumiał co, dlaczego, oraz granice pracy. Ten przewodnik bada, jak tworzyć historie użytkownika, które ułatwiają dokładne oszacowanie w ramach frameworku Scrum, bez użycia zewnętrznych narzędzi czy szumu.
🤔 Dlaczego oszacowanie zawodzi
Programiści nie oszacowują czasu; oszacowują nakład pracy, złożoność i ryzyko. Gdy historia użytkownika jest niejasna, nieznane zmienne powiększają ryzyko, co z kolei powiększa oszacowanie. Oto najczęstsze przyczyny, dla których historie są trudne do oszacowania:
- Brak kryteriów akceptacji: Bez jasnych granic programiści zakładają najgorszy przypadek.
- Zależności techniczne: Historie, które opierają się na nieukończonych pracach innych zespołów, powodują niepewność.
- Nieprecyzyjne czasowniki: Słowa takie jak „optymalizuj”, „doskonal”, czy „popraw” nie mają mierzalnych wyników.
- Zakładane wiedza: Opieranie się na wiedzy tribały, a nie na zapisanym kontekście.
- Zbyt wiele historii: Duże, monolityczne historie, które obejmują zbyt dużo rzeczy naraz.
Kiedy programista pyta: „Ale jak dokładnie to działa?”, historia nie jest gotowa do oszacowania. Celem jest zmniejszenie potrzeby zadawania pytań wyjaśniających podczas fazy planowania sprintu.
📐 Model INVEST dla oszacowalnych historii
Model INVEST to akronim używany do definiowania dobrych historii użytkownika. Choć często cytowany, wiele zespołów pomija aspekty Małe oraz Sprawdzalne które są kluczowe dla oszacowania.
1. Niezależne
Historie powinny być idealnie niezależne. Jeśli historia zależy od innej, która musi zostać najpierw ukończona, zespół nie może jej oszacować samodzielnie. Zależności powodują blokadę. Jeśli historia naprawdę zależy, powinna zostać podzielona, aż do usunięcia zależności lub aż do momentu, gdy będzie wystarczająco mała, by można ją było przetestować.
2. Ustalalne
Historie nie są kontraktami; są miejscami na rozmowę. Jednak rozmowa musi się odbyć przed szacowanie. Jeśli historia jest zapisana jako stała specyfikacja bez możliwości dyskusji technicznej, ogranicza zdolność programisty do zaproponowania lepszego rozwiązania, które może wpłynąć na szacowanie.
3. Wartościowa
Każda historia musi przynosić wartość końcowemu użytkownikowi. Jeśli historia dotyczy wyłącznie infrastruktury technicznej bez wartości widocznej dla użytkownika, jest zadaniem technicznym, a nie historią użytkownika. Zadania techniczne wymagają innej metody szacowania i powinny być traktowane ostrożnie, aby uniknąć nadmiernego rozrostu sprintu.
4. Szacowalna
To podstawowe wymaganie dla tego przewodnika. Historia jest szacowalna, jeśli zespół ma wystarczająco dużo informacji, aby określić wysiłek. Oznacza to:
- Przepływ użytkownika jest jasny.
- Wymagania dotyczące danych są zdefiniowane.
- Zagadnienia krawędziowe są rozważone.
- Wymagania dotyczące wydajności są określone (np. czasy ładowania).
5. Mała
Dokładność szacowania spada wraz ze wzrostem rozmiaru. Historia, która zajmuje dwa tygodnie, jest zbyt duża. Powinna zostać podzielona na historie trwające od jednego do trzech dni. Małe historie zmniejszają ryzyko i poprawiają szczegółowość szacowania.
6. Testowalna
Jeśli nie możesz napisać testu dla historii, nie możesz zdefiniować kryteriów akceptacji. Jeśli nie możesz zdefiniować kryteriów akceptacji, programista nie wie, kiedy historia jest zakończona. To bezpośrednio wpływa na szacowanie, ponieważ „zrobione” to metyka.
🛠 Anatomia wysokiej jakości historii użytkownika
Historia użytkownika to więcej niż tylko tytuł. To zestaw informacji. Aby zapewnić, że programiści mogą skutecznie szacować, każda historia powinna zawierać następujące elementy.
1. Tytuł
Tytuł powinien być opisowy, ale krótki. Powinien podsumować podstawową funkcjonalność.
- Zły: Napraw logowanie
- Dobry: Pozwól użytkownikom zresetować hasło za pomocą linku e-mail
2. Stwierdzenie użytkownika
Standardowy format to: „Jako [rola], chcę [funkcjonalność], ponieważ [korzyść].” Zapewnia to, że zespół rozumie kontekst.
3. Kontekst i tło
Programiści muszą znać kontekst biznesowy. Dlaczego ta funkcjonalność jest budowana teraz? Czy istnieje wymóg regulacyjny? Czy jest to naprawa krytycznego błędu? Kontekst pomaga programistom priorytetyzować decyzje techniczne.
4. Kryteria akceptacji
To najważniejszy element dla szacowania. Kryteria akceptacji definiują granice pracy. Powinny być sformułowane w sposób umożliwiający testowanie automatyczne.
- Użyj Given-When-Then: Ta struktura zmniejsza niepewność.
- Zdefiniuj przypadki brzegowe: Co się stanie, jeśli internet przestanie działać? A co, jeśli dane wejściowe będą puste?
- Określ dane: Czy pobieramy dane z istniejącej bazy danych? Czy tworzymy nowe rekordy?
📋 Porównanie: Niejasne a jasne historie użytkownika
Zrozumienie różnicy między historią, która powoduje błędy szacowania, a tą, która ułatwia jasność, jest kluczowe. Poniższa tabela pokazuje tę różnicę.
| Funkcja | Niejasna historia (trudna do oszacowania) | Jasna historia (łatwa do oszacowania) |
|---|---|---|
| Cel | Ulepsz wydajność pulpitu. | Zmniejsz czas ładowania pulpitu do mniej niż 2 sekund dla 1000 rekordów. |
| Zakres | Optymalizuj backend. | Zindeksuj kolumnę ‘user_id’ w tabeli wyszukiwania i buforuj 50 najlepszych wyników. |
| Kryteria akceptacji | Muszą być szybsze. | 1. Czas ładowania < 2s. 2. Brak błędów przy 1000 rekordach. 3. Wersja mobilna działa. |
| Zależności | Nie wspomniano o żadnych. | Wymaga dostępu do interfejsu API Analiz, który obecnie jest w wersji beta. |
🧩 Obsługa zależności i ryzyk
Zależności są wrogiem szacowania. Jeśli historia zależy od interfejsu API innej drużyny, szacowanie jest tylko zgadką. Aby to ograniczyć:
- Identyfikuj wcześnie: Dyskutuj zależności podczas wyrównywania backlogu, a nie podczas planowania.
- Twórz historie spike: Jeśli zależność jest nieznana, stwórz historię do jej zbadania. Spike to zadanie badawcze z ustalonym czasem. Nie generuje kodu, ale generuje wiedzę, która zmniejsza ryzyko.
- Dane testowe: Jeśli usługa zewnętrzna jest niedostępna, zgodź się na strukturę odpowiedzi testowej. Pozwala to kontynuować rozwój bez blokowania.
- Zależności zewnętrzne: Jeśli historia opiera się na usłudze trzeciej strony, zaznacz w opisie koszty i skutki opóźnień.
🗣 Rola rozmowy
Pisanie historii to tylko połowa pracy. Drugą połowę stanowi rozmowa. Napisana historia to przypomnienie rozmowy, a nie sama rozmowa.
Poprawa przed planowaniem
Zanim zacznie się planowanie sprintu, zespół powinien przejrzeć listę zadań. To czas na zadawanie pytań. Jeśli programista zauważy lukę w historii, powinien natychmiast ją zaznaczyć. Historia zaznaczona podczas poprawy to historia gotowa do oszacowania.
Pytania wyjaśniające
Podczas poprawy powinny zostać odpowiedziane konkretne pytania. Na przykład:
- Czy ta funkcja musi być dostępna?
- Czy wymagane są konkretne protokoły bezpieczeństwa?
- Jaka jest maksymalna liczba oczekiwanych użytkowników?
- Czy musimy wspierać starsze przeglądarki?
Jeśli te odpowiedzi są zapisane w historii, oszacowanie staje się bardziej wiarygodne.
📊 Zrozumienie technik oszacowania
Gdy historia jest jasna, zespół potrzebuje metody do oszacowania. Ważniejsze jest porozumienie, które metoda tworzy, niż sama metoda.
Punkty historii
Punkty historii mierzą względną pracę, złożoność i ryzyko. Nie są to godziny. Używanie punktów historii pozwala zespołom skupić się na rozmiarze pracy, a nie na szybkości poszczególnych osób.
- Złożoność: Jak trudny jest logika?
- Ryzyko: Jak duże jest prawdopodobieństwo, że coś pójdzie nie tak?
- Praca: Ile pracy jest wymagane?
Poker planowania
Jest to technika oparta na porozumieniu. Każdy programista podnosi kartę z liczbą. Jeśli liczby się różnią, oszacowujący z najwyższą i najniższą wartością wyjaśniają swoją argumentację. To ujawnia ukryte założenia. Na przykład jeden programista mógł zapomnieć o wymogu integracji, a drugi założył, że została już zrealizowana.
🚫 Najczęstsze pułapki do uniknięcia
Nawet z dobrymi intencjami zespoły często wpadają w pułapki, które psują dokładność oszacowań.
1. Tylko „ścieżka szczęścia”
Pisanie historii, które opisują tylko idealny scenariusz, jest niebezpieczne. Programiści oszacują tylko ścieżkę szczęścia, ale praca rzeczywista obejmuje obsługę błędów. Zawsze uwzględniaj stany błędów w kryteriach akceptacji.
2. Ignorowanie wymagań niiefunkcjonalnych
Wydajność, bezpieczeństwo i skalowalność często są pomijane. Historia mówiąca „Utwórz użytkownika” może mieć 1 punkt. Ale historia mówiąca „Utwórz użytkownika obsługującego 10 000 jednoczesnych logowań” ma 10 punktów. Jasno określ wymagania niiefunkcjonalne.
3. Nadmierna złożoność opisu
Nie pisz specyfikacji technicznej w historii użytkownika. Deweloper musi wiedzieć, coma budować, a nie jakma budować. Jeśli określisz schemat bazy danych w historii, ograniczasz zdolność dewelopera do wyboru najlepszego rozwiązania.
4. Pomijanie Definicji Gotowości
Definicja Gotowości (DoD) dotyczy każdej historii. Obejmuje testowanie, przegląd kodu i dokumentację. Jeśli DoD nie jest jasna, szacowanie będzie niepoprawne. Upewnij się, że zespół zgadza się, co oznacza „gotowe”, zanim przystąpisz do szacowania.
🔄 Przepływ pracy weryfikacji
Aby utrzymać stały przepływ historii, które można oszacować, postępuj zgodnie z tym przepływem.
- Pierwotny szkic:Właściciel produktu pisze historię z podstawowymi szczegółami.
- Recenzja techniczna:Deweloperzy sprawdzają realizowalność i ukrytą złożoność.
- Rozszerzenie kryteriów akceptacji:Dodaj przypadki brzegowe i ograniczenia.
- Sprawdzenie zależności:Upewnij się, że nie ma blokujących czynników.
- Ostateczne szacowanie:Zespół przypisuje punkty historii podczas weryfikacji lub planowania.
- Weryfikacja:Upewnij się, że historia spełnia kryteria INVEST.
📈 Mierzenie dokładności szacowania
W czasie zespół powinien śledzić dokładność swoich szacowań. Nie chodzi o karanie osób, tylko o poprawę procesu.
- Śledzenie prędkości:Śledź prędkość zespołu przez kilka sprintów. Jeśli prędkość drastycznie się zmienia, historie prawdopodobnie są niezgodne.
- Stopień ukończenia:Czy zespół ukończył wszystkie oszacowane historie? Jeśli nie, czy były zablokowane, czy zostały niedoszacowane?
- Częstotliwość ponownego szacowania:Jeśli historie są często ponownie szacowane w trakcie sprintu, pierwotne szacowanie było błędne.
🛡 Bezpieczeństwo i zgodność
Dla regulowanych branż bezpieczeństwo i zgodność są częścią szacunku. Historia obsługująca dane użytkownika wymaga innego wysiłku niż historia wyświetlająca informacje publiczne. Włącz sprawdzenia zgodności do kryteriów akceptacji.
- Prywatność danych: Czy historia dotyczy danych osobowych (PII)?
- Ślady audytu: Czy system musi rejestrować, kto dokonał zmian?
- Szyfrowanie: Czy dane są szyfrowane w spoczynku lub w trakcie przesyłania?
Jeśli te wymagania nie są wymienione, programista może stworzyć rozwiązanie, które później wymaga znacznej refaktoryzacji, co zmarnuje początkowy szacunek.
🧪 Wartość spike’ów
Czasem historia jest zbyt ryzykowna, by ją oszacować. W takich przypadkach należy użyć spike’a. Spike to zdefiniowane czasowo badanie. Nie jest to funkcja do dostarczenia. Jest to zadanie naukowe.
Przykład:
- Historia: Zbadaj możliwość zintegrowania się z dziedzicznym bramką płatności.
- Cel: Ustal, czy bramka obsługuje naszą wymaganą wersję interfejsu API.
- Wynik: Dokument z wynikami badań i rekomendacją.
Po zakończeniu spike’a, rzeczywista historia funkcji może zostać oszacowana na podstawie wyników. To znacznie zmniejsza ryzyko.
🤝 Współpraca z QA
Zapewnienie jakości (QA) powinno być zaangażowane w proces dopasowania. Programiści mogą pominąć przypadki krawędziowe, które wyłapują testery. QA może pomóc w napisaniu kryteriów akceptacji z perspektywy testowania. Zapewnia to, że historia jest naprawdę testowalna, co jest kluczowym elementem szacowania.
📉 Zarządzanie rozrostem zakresu
Rozrost zakresu występuje, gdy wymagania ulegają zmianie po szacowaniu. Aby temu zapobiec:
- Zamrożenie kryteriów: Po oszacowaniu kryteria akceptacji nie powinny ulegać zmianie bez ponownego szacowania.
- Prośby o zmianę: Jeśli potrzebna jest zmiana, musi zostać zarejestrowana i dodana do backlogu, a nie naruszona w bieżącej iteracji.
- Przejrzystość: Jeśli zmiana jest nieunikniona, natychmiast poinformuj o jej wpływie na cel iteracji.
🧠 Udzielanie wiedzy
Szacowanie to gra drużynowa. Młodsi programiści mogą szacować inaczej niż starsi. Aby wyrównać zespół:
- Sesje kalibracji: Regularnie przeglądarki poprzednie historie, aby skaliować, jak wygląda „5” w porównaniu do „13”.
- Programowanie parach: Używaj programowania parach dla skomplikowanych historii, aby dzielić się wiedzą i zmniejszać zmienność szacowań.
- Dokumentacja: Utrzymuj bibliotekę poprzednich historii, aby służyły jako punkty odniesienia do przyszłych szacowań.
🌟 Ostateczne rozważania dotyczące jasności
Pisanie historii użytkownika, które programiści mogą łatwo szacować, to ćwiczenie empatii. Wymaga to od właściciela produktu włożenia się w skórzę inżyniera i przewidzenie jego pytań. Wymaga to od inżyniera, by mówił, gdy brakuje informacji. Gdy obie strony współpracują, aby usunąć niejasności, szacowanie staje się wiarygodnym narzędziem do planowania.
Wynikiem nie są tylko dokładne liczby. To zaufanie. Gdy zespół zobowiązuje się do zestawu historii opartych na jasnych kryteriach, może je realizować z pewnością. Skupienie przesuwa się od zgadywania do budowania.
🔑 Kluczowe wnioski
- Jasność jest królową:Jasna historia to historia, którą można szacować.
- Kryteria akceptacji: Wyraźnie zdefiniuj granice i przypadki brzegowe.
- Zależności: Zidentyfikuj i ogranicz ryzyka przed planowaniem.
- Rozmowa: Używaj dopracowania, aby omówić szczegóły przed szacowaniem.
- Małe historie: Rozbijaj duże zadania, aby poprawić dokładność.
- Nieustanna poprawa: Śledź prędkość i dostosowuj proces z biegiem czasu.
Przestrzegając tych zasad, zespoły mogą przekształcić planowanie sprintów z gry w zgadywanie w strukturalny, przewidywalny proces. Wkład w pisanie dobrych historii przynosi zyski w każdym kolejnym sprintie.