W rozwoju Agile dostarczanie wartości stopniowo jest głównym celem. Jednak funkcje często zaczynają się jako ogromne epiki, które są zbyt duże, aby zmieścić się w jednym sprintie. Gdy wymaganie jest zbyt duże, staje się ryzykiem. Zatrzymuje postępy, opóźnia zwrot informacji i powoduje zamieszanie co do tego, co naprawdę zostało ukończone. To właśnie tutaj dzielenie historii użytkownika staje się kluczowe.
Podzielenie dużego wymagania na mniejsze, łatwiejsze do zarządzania fragmenty pozwala zespołowi często dostarczać działające oprogramowanie. Zmniejsza to ryzyko i zapewnia, że każdy etap dostarcza wartość końcowemu użytkownikowi. Ten przewodnik omawia praktyczne strategie dzielenia złożonych funkcji na wykonalne historie użytkownika.
🧩 Dlaczego dzielenie ma znaczenie
Duża historia użytkownika często nie spełnia kryteriów INVESTkryteriów. Może być zbyt duża, aby dokładnie ją oszacować, nie dać się przetestować lub nie mieć wartości samodzielnie. Gdy historia jest zbyt duża, zespół może poświęcić na nią tygodnie, nie pokazując niczego stakeholderom. Dzielenie rozwiązuje te problemy, skupiając się na:
- Szybkość dostarczania:Mniejsze historie oznaczają szybsze zakończenie i wcześniejsze wypuszczenie.
- Pętle zwrotu informacji:Stakeholderzy mogą wcześniej przejrzeć działające oprogramowanie i podać kierunek.
- Zmniejszone ryzyko:Jeśli zostanie znaleziony błąd, łatwiej go izolować w małej historii niż w ogromnej epice.
- Skupienie:Zespoły mogą skupić się na jednym konkretnym celu bez zmiany kontekstu.
📐 Kryteria INVEST
Zanim podzieli się historię, warto zrozumieć, co czyni ją dobrą. Model INVEST zapewnia listę kontrolną:
- INiezależna: historia nie powinna mocno polegać na innych historiach.
- NNegowalna: szczegóły mogą być omawiane i dostosowywane.
- VWartościowa: musi przynosić wartość użytkownikowi.
- EOszacowalna: zespół musi móc oszacować wysiłek.
- SMała: powinna zmieścić się w jednym sprintie.
- TTestowalna: muszą istnieć jasne kryteria akceptacji.
Jeśli historia nie spełnia któregokolwiek z tych kryteriów, wymaga podziału. Celem jest stworzenie sekwencji historii, które mogą być dostarczane niezależnie, ale nadal przyczyniają się do większego celu.
🔨 Najczęstsze techniki dzielenia
Nie ma jednej jedynie metody dzielenia historii. Poprawna metoda zależy od funkcjonalności. Poniżej znajduje się porównanie powszechnych strategii stosowanych w złożonym rozwoju.
| Technika | Skupienie | Najlepiej do |
|---|---|---|
| Pionowe dzielenie | Funkcjonalność od końca do końca | Funkcjonalności wymagające natychmiastowej wartości |
| Poziome dzielenie | Warstwy techniczne | Infrastruktura lub wspólne składniki |
| Oparte na scenariuszach | Przepływy użytkownika | Złożone procesy z wariacjami |
| Oparte na danych | Objętość i typy | Raportowanie lub operacje masowe |
| Sterowane interfejsem | Złożoność interfejsu | Formularze lub pulpity |
1. Pionowe dzielenie
Jest to najpowszechniejsza i zalecana strategia dostarczania funkcjonalności. Pionowe dzielenie oznacza przekrojenie wszystkich warstw technicznych w celu dostarczenia konkretnej funkcjonalności od bazy danych po interfejs użytkownika.
- Jak to działa: Najpierw budujesz małą, kompletną funkcjonalność, a następnie ją rozszerzasz.
- Przykład: Zamiast najpierw budować całą strukturę bazy danych, najpierw budujesz funkcjonalność „Zapisz użytkownika”, a następnie „Zaktualizuj użytkownika”, a następnie „Usuń użytkownika”.
- Zalety: Każda historia kończy się działającą częścią oprogramowania, którą można wdrożyć.
2. Poziome dzielenie
Poziome dzielenie polega na budowaniu pojedynczej warstwy systemu na raz dla wszystkich funkcjonalności. Jest często stosowane w przypadku infrastruktury technicznej.
- Jak to działa: Budujesz warstwę bazy danych, potem warstwę interfejsu API, a następnie warstwę interfejsu użytkownika.
- Przykład: Tworzenie ogólnego mechanizmu rejestrowania przed jego zastosowaniem do konkretnych funkcji.
- Zalety: Zapewnia spójność i możliwość ponownego wykorzystania w całym systemie.
- Ostrzeżenie: Często opóźnia wartość dla użytkownika. Używaj tego tylko wtedy, gdy jest to konieczne dla stabilności technicznej.
3. Podział oparty na scenariuszach
Złożone funkcje często mają różne ścieżki, które może przejść użytkownik. Podział oparty na scenariuszach dzieli funkcję według konkretnego przypadku użycia.
- Jak to działa: Zidentyfikuj główną ścieżkę działania oraz ścieżki wyjątkowe.
- Przykład: Funkcja płatności może zostać podzielona na „Płać kartą kredytową”, „Płać przez PayPal” oraz „Zwróć transakcję”.
- Główna ścieżka działania: Pomyślna płatność.
- Ścieżka wyjątkowa: Płatność odrzucona lub przekroczony limit czasu.
4. Podział oparty na danych
Gdy funkcja wymaga obsługi różnych ilości lub typów danych, dziel ją według objętości danych lub złożoności.
- Jak to działa: Zacznij od prostych danych, a następnie dodawaj złożoność.
- Przykład: Funkcja importu może zacząć od „Importuj CSV”, potem „Importuj Excel”, a następnie „Importuj JSON”. Alternatywnie, podziel według objętości: „Importuj 10 rekordów”, a następnie „Importuj 10 000 rekordów”.
5. Podział oparty na interfejsie użytkownika
Jeśli złożoność dotyczy interfejsu, dziel ją według ekranów lub komponentów.
- Jak to działa: Podziel interfejs na logiczne sekcje.
- Przykład: Pulpit może zostać podzielony na „Nagłówek”, „Pasek boczny” i „Główna strefa wykresu”. Albo: „Tworzenie formularza” w porównaniu do „Wyświetlanie formularza”.
📝 Przykład przewodnika: Kasa e-handlu
Aby ilustrować te strategie, rozważ skomplikowaną funkcję kasowania dla sklepu internetowego. Epos to „Zakończenie procesu zakupu”. Jest on zbyt duży, aby zmieścić się w jednym sprintie.
Krok 1: Zdefiniuj cel
Celem jest umożliwienie klientowi zakupu produktów. Minimalna wartość to otrzymanie płatności i potwierdzenie zamówienia.
Krok 2: Zastosuj pionowe podziały
Zamiast budować logikę dostawy, podatków i płatności osobno, dokonujemy pionowego podziału.
- Historia 1:Jako klient, chcę dodać przedmioty do koszyka, aby móc je kupić później.
- Historia 2:Jako klient, chcę zobaczyć zawartość koszyka, aby potwierdzić zamówienie.
- Historia 3:Jako klient, chcę wpisać swój adres dostawy, aby zamówienie zostało dostarczone.
- Historia 4:Jako klient, chcę wybrać metodę płatności, aby zapłacić bezpiecznie.
- Historia 5:Jako klient, chcę potwierdzić zamówienie, aby otrzymać paragon.
Krok 3: Wyostrz z podziałem opartym na scenariuszach
W ramach historii 4 (Płatność) występują złożoności. Dokonujemy dalszego podziału.
- Podhistoria A:Obsługa płatności kartą kredytową wyłącznie.
- Podhistoria B:Obsługa integracji z PayPal.
- Podhistoria C:Obsługuj błędy odmowy płatności zgodnie z zasadami.
Krok 4: Zdefiniuj kryteria akceptacji
Każda historia wymaga jasnych kryteriów, aby zapewnić jej testowalność. Dla historii 3 (Adres dostawy):
- Zakładając, że użytkownik znajduje się na stronie kasowania
- Gdy użytkownik wprowadzi poprawny adres
- Wtedy system weryfikuje format
- I użytkownik może przejść do płatności
⚠️ Powszechnie spotykane pułapki podczas dzielenia
Nawet doświadczone zespoły popełniają błędy podczas dzielenia funkcji. Bądź na baczności przed tymi powszechnymi problemami.
- Zbyt duże dzielenie:Dzielenie historii na bardzo małe fragmenty, które trwają tylko 2 godziny. Powoduje to zbyt duży nakład administracyjny.
- Zbyt mało szczegółowe dzielenie:Historie, które nadal trwają dwa tygodnie. Narusza to pojemność sprintu.
- Techniczne vs. Funkcjonalne:Dzielenie według „Bazy danych”, „API” i „Frontendu” często ukrywa wartość. Stakeholderzy chcą wiedzieć, co użytkownik może robić, a nie tylko to, co przetwarza serwer.
- Ignorowanie zależności:Tworzenie historii, która nie może zostać dostarczona, ponieważ zależy od innej historii, która jeszcze nie znajduje się na liście zadań.
🤝 Współpraca i dopracowanie
Dzielenie to działalność wspólnotowa. Nie powinno być wykonywane przez jednostkę w izolacji. Product Owner, programiści i testerzy powinni wszystko wspierać.
1. Rola Product Ownera
Product Owner określa co i wartość. Zapewniają, że najmniejszy fragment nadal przynosi wartość. Ustalają priorytety, który fragment jest najważniejszy dla kolejnej wersji.
2. Rola zespołu deweloperów
Programiści dostarczają szacunki i ocenę technicznej realizowalności. Mogą zaproponować inne podejście do dzielenia historii w celu zmniejszenia ryzyka technicznego lub umożliwienia pracy równoległej.
3. Rola zespołu testowania
Testerzy zapewniają, że podzielone historie są testowalne. Zadają pytania takie jak: „Czy możemy zautomatyzować test dla tego konkretnego fragmentu?” lub „Czy to dzielenie pozwala nam bezpiecznie wypuścić do produkcji?”
📊 Zarządzanie zależnościami
Podczas dzielenia często pojawiają się zależności. Musisz je dokładnie zarządzać.
- Zależności wewnętrzne:Historia B wymaga, aby najpierw została wykonana Historia A. Oznacz je na liście zadań.
- Zależności zewnętrzne:Może być potrzebna API zewnętrznej usługi. Jest to czynnik ryzyka.
- Odkładanie:Tam gdzie to możliwe, projektuj system tak, aby historie nie zależały od siebie. Używaj flag funkcji, aby ukryć nieukończone prace.
Tabela: Typy zależności
| Typ | Definicja | Strategia zarządzania |
|---|---|---|
| Twarda zależność | Historia B nie może się rozpocząć bez historii A | |
| Miękka zależność | Historia B jest łatwiejsza, jeśli historia A została wykonana | |
| Opcjonalna zależność | Historia B działa lepiej wraz z historią A |
🔍 Mierzenie sukcesu
Jak możesz wiedzieć, czy strategia podziału działa? Spójrz na te metryki.
- Spójność prędkości:Jeśli historie mają odpowiedni rozmiar, prędkość powinna być stabilna.
- Wskaźnik ukończenia:Czy kończysz historie w każdym sprintie?
- Wskaźnik błędów:Czy znajdujesz mniej błędów w środowisku produkcyjnym? Mniejsze historie są łatwiejsze do testowania.
- Zadowolenie stakeholderów:Czy stakeholderzy są zadowoleni z widzianego postępu?
🔄 Iteracja i poprawa
Podział nie jest jednorazowym zadaniem. Gdy dowiadujesz się więcej o funkcjonalności, możesz odkryć, że początkowe podziały były błędne. Bądź gotów ponownie zgrupować się.
- W trakcie dopasowania:Jeśli historia nadal jest zbyt duża, podziel ją ponownie. Nie zmuszaj jej do sprintu.
- W trakcie sprintu:Jeśli historia jest zbyt mała, połącz ją z inną. Nie pozwól, by praca pozostawała niezakończona.
- Po Sprintie: Przejrzyj dokładność oszacowania. Czy podział odpowiadał wysiłkowi? Dostosuj przyszłe podziały na podstawie tych danych.
🧠 Zaawansowane rozważania
Dla bardzo złożonych systemów stosuje się dodatkowe rozważania.
1. Zgodność z przepisami
Niektóre funkcje muszą zostać podzielone, aby spełnić wymagania prawne. Na przykład prywatność danych może wymagać konkretnego dziennika audytu przed uruchomieniem głównej funkcji. Podziel na podstawie potrzeb zgodności.
2. Progi wydajności
Jeśli funkcja wymaga wysokiej wydajności, podziel jej implementację, aby włączyć testy wydajności na wczesnym etapie. Nie czekaj do końca, aby przetestować prędkość.
3. Dostępność
Upewnij się, że każdy podział spełnia standardy dostępności. Nie buduj historii „Wyświetl stronę” i potem dodawaj dostępność w późniejszej historii „Poprawka dostępu”. Zawrzyj ją w oryginalnym podziale.
📝 Podsumowana lista kontrolna podziału
Zanim przeniesiesz historię do aktywnego backlogu, przejdź przez tę listę kontrolną.
- Czy historia sama w sobie przynosi wartość? ✅
- Czy historię można niezależnie przetestować? ✅
- Czy historia jest wystarczająco mała na sprint? ✅
- Czy istnieją jasne kryteria akceptacji? ✅
- Czy zależności są minimalne lub zarządzane? ✅
- Czy historia odpowiada celowi użytkownika? ✅
Śledząc te strategie, zespoły mogą przekształcić przesadnie złożone funkcje w strumień zarządzalnej pracy. Wynikiem jest przewidywalny przepływ wartości, lepsza jakość oprogramowania oraz zespół, który czuje się zadowolony na końcu każdego sprintu.
Pamiętaj, że celem nie jest tylko podział historii, ale zrozumienie wartości, którą przynoszą. Zachowaj użytkownika w centrum każdej decyzji dotyczącej podziału.