W szybko zmieniającym się świecie rozwoju oprogramowania jasność jest walutą. Zespoły, które skutecznie komunikują się, wypuszczają lepsze produkty szybciej. W centrum tej komunikacji znajduje się historia użytkownika. Nie jest to po prostu bilet w kolejce zadań; to obietnica rozmowy, środek przekazywania wartości i narzędzie do wyrównania działań.
Ten przewodnik prowadzi Cię przez mechanizmy tworzenia wysokiej jakości historii użytkownika. Przejdziemy od podstawowych definicji do zaawansowanych technik, takich jak mapowanie i doskonalenie. Na końcu będziesz miał praktyczny szablon do pisania historii, które zrozumieją programiści, testery potrafią zweryfikować, a stakeholderzy mogą priorytetyzować. Zaczynajmy.
Czym dokładnie jest historia użytkownika? 🤔
Historia użytkownika to krótkie, proste opisanie funkcjonalności przedstawione z perspektywy osoby, która chce nowej możliwości, zazwyczaj użytkownika lub klienta systemu. Nie jest to dokument specyfikacji. Jest to miejsce zapasowe dla rozmowy.
W przeciwieństwie do tradycyjnych dokumentów wymagań, które mogą być sztywne i długie, historie użytkownika są zaprojektowane jako lekkie. Skupiają się na kim, co, oraz dlaczego.
Standardowy format
Większość zespołów agilnych wykorzystuje standardowy szablon, aby zapewnić spójność. Ten szablon pomaga skupić się na wartości dla użytkownika, a nie na szczegółach implementacji technicznej.
- Jako:Chcę: Aby:
- Jako: [rola użytkownika]
- Chcę: [działanie lub funkcja]
- Aby: [korzyść lub wartość]
Rozważ sytuację, w której użytkownik musi zresetować hasło. Zły opis wymagań mógłby brzmieć: „System musi umożliwić resetowanie hasła przez e-mail”. Historia użytkownika brzmiałaby:
- Jako zarejestrowany użytkownik
- Chcę zresetować hasło przez e-mail
- Aby mógł odzyskać dostęp do swojego konta bez kontaktowania się z pomocą techniczną
Ten format zmusza zespół do myślenia o ukrytej wartości. Przesuwa rozmowę z „jak zbudować ten przycisk” na „dlaczego użytkownik potrzebuje uzyskać dostęp do tego przycisku”.
Model INVEST: Kryteria jakościowych historii użytkownika 🌟
Nie wszystkie historie użytkownika są równoważne. Niektóre są niejasne, inne zbyt duże, a niektóre technicznie niemożliwe do przetestowania. Aby wyeliminować niskiej jakości elementy, zespoły często używają modelu INVEST. To akronim oznaczający niezależność, negowalność, wartość, oszacowalność, małych rozmiarów i testowalność.
Niezależność
Historia powinna być jak najbardziej niezależna. Jeśli historia zależy od zakończenia innej historii, zanim nawet można ją omówić, powstają węzły zastojowe. Choć zależności istnieją w oprogramowaniu, powinny one być jawnie zarządzane. Idealnie, zespół powinien móc wziąć historię i ją ukończyć, nie potrzebując konkretnego zadań górnych.
Negowalność
Opis historii nie jest kontraktem. Jest przypomnieniem rozmowy. Szczegóły powinny być negocjowane między zespołem programistów a właścicielem produktu. Ta elastyczność pozwala zespołowi zaproponować rozwiązania techniczne, które mogą być lepsze niż pierwotna prośba.
Wartość
Każda historia musi przynosić wartość. Jeśli historia nie przynosi wartości użytkownikowi ani firmie, nie powinna istnieć. Wartość może być funkcjonalna, techniczna (np. zmniejszanie długu) lub związana z zgodnością. Jeśli nie potrafisz wyrazić wartości, historia prawdopodobnie jest zbędna.
Oszacowalność
Zespół musi być w stanie oszacować wysiłek potrzebny do ukończenia historii. Jeśli historia jest zbyt niejasna lub opiera się na nieznanym technologicznie, nie może być oszacowana. W takich przypadkach historia musi zostać rozłożona na mniejsze części lub badana za pomocą spike’a.
Mały rozmiar
Historie powinny być wystarczająco małe, aby zostały ukończone w jednym sprintie. Jeśli historia jest zbyt duża, staje się projektem. Duże historie są trudne do przetestowania, trudne do oszacowania i trudne do priorytetyzacji. Ich rozkładanie na mniejsze fragmenty pozwala na szybsze zwroty.
Testowalność
Historia musi mieć jasne warunki spełnienia. Jeśli nie możesz napisać przypadku testowego dla niej, nie możesz zweryfikować, czy została ukończona. To bezpośrednio wiąże się z definicją gotowości.
| Kryterium | Pytanie do zadania | Przykładowy problem |
|---|---|---|
| Niezależność | Czy możemy zbudować to bez innej historii? | „Logowanie” zależy od „Profilu użytkownika” |
| Negowalność | Czy jesteśmy otwarci na zmianę rozwiązania? | „Użyj API X” zamiast „Użyj funkcji Y” |
| Wartość | Czy to pomaga użytkownikowi? | „Zmień kolor czcionki, aby pasował do marki” |
| Oszacowalność | Czy wiemy, jak długo to trwa? | „Zintegruj z nieznanym dostawcą trzeciej strony” |
| Mały rozmiar | Czy to zmieści się w jednym sprintie? | „Zbuduj cały pulpit” |
| Testowalny | Czy możemy napisać test dla tego? | „Zrób aplikację szybszą” |
Krok po kroku: Pisanie historii użytkownika 🛠️
Pisanie historii użytkownika to proces iteracyjny. Zdarza się to rzadko w jednym podejściu. Oto systematyczny sposób tworzenia historii, która wytrzyma krytykę.
Krok 1: Zidentyfikuj osobę użytkownika
Zanim napiszesz jedno słowo, zidentyfikuj, dla kogo piszesz. Historia dla administratora różni się od historii dla przypadkowego przeglądarka. Użyj kart osobowości lub istniejących profili, aby upewnić się, że rozumiesz ich cele i ograniczenia.
Krok 2: Zdefiniuj działanie
Bądź konkretny co do tego, co użytkownik chce zrobić. Unikaj nieprecyzyjnych czasowników takich jak „zarządzaj” lub „obsługuj”. Używaj czasowników czynnościowych takich jak „kliknij”, „zapisz”, „usuń” lub „eksportuj”. Ta jasność pomaga programistom zrozumieć konkretną interakcję wymaganą.
Krok 3: Wypowiedz wartość
To najważniejsza część. Dlaczego użytkownik się tym interesuje? Jeśli pominiesz część „Aby”, ryzykujesz budowę funkcji, których nikt nie będzie używał. Regularnie wyzwania zespół, by wyjaśnił korzyści.
Krok 4: Dodaj kontekst i ograniczenia
Czasem historia potrzebuje dodatkowego kontekstu. Może to obejmować ograniczenia techniczne, wymagania regulacyjne lub przypadki graniczne. Umieść tę informację w polu opisu lub jako komentarze do historii, a nie w tytule.
Krok 5: Przejrzyj zgodnie z INVEST
Zanim dodasz historię do listy backlogu, przeprowadź ją przez listę kontrolną INVEST. Czy pasuje? Jeśli nie, dopracuj ją. Lepiej poświęcić pięć minut na dopracowanie historii teraz niż pięć godzin na naprawę nieporozumienia podczas rozwoju.
Kryteria akceptacji: Granica gotowości ✅
Kryteria akceptacji definiują granice historii. Są to warunki, które muszą zostać spełnione, aby historia była uznana za zakończoną. Bez nich „gotowe” jest subiektywne.
Rodzaje kryteriów akceptacji
Istnieje kilka sposobów strukturyzowania kryteriów akceptacji. Najefektywniejsza metoda często zależy od przepływu pracy zespołu.
- Oparte na scenariuszach:Użycie składni Given/When/Then pomaga wyjaśnić przebieg logiki.
- Lista kontrolna:Proste punkty listy, które potwierdzają konkretne wyniki.
- Zasady:Zasady matematyczne lub logiczne, które muszą zostać spełnione.
- Przepływ użytkownika:Opis drogi, którą użytkownik przebywa przez funkcję.
Przykłady kryteriów akceptacji
Spójrzmy, jak kryteria różnią się w zależności od typu historii użytkownika.
| Skupienie na historii użytkownika | Przykład kryteriów akceptacji |
|---|---|
| Funkcjonalność | |
| Bezpieczeństwo | |
| Wydajność | |
| Użyteczność |
Pisanie skutecznych kryteriów
Podczas pisania tych kryteriów trzymaj je atomowymi. Nie łączyć wielu warunków w jednym zdaniu. Każde kryterium powinno być jednym testowalnym warunkiem. Ułatwia to testowcom weryfikację pracy oraz programistom dokładne zrozumienie wymagań.
Unikaj słów subiektywnych takich jak „szybki”, „łatwy” lub „nowoczesny”. Zastąp je mierzalnymi pojęciami takimi jak „poniżej 200 ms”, „mniej niż 3 kliknięcia” lub „zgodny z WCAG 2.1”.
Mapowanie historii użytkownika: wizualizacja przebiegu użytkownika 🗺️
Czasem lista historii użytkownika nie wystarcza. Potrzebujesz zobaczyć całość. Mapowanie historii użytkownika to technika służąca do wizualizacji doświadczenia użytkownika i organizacji historii w spójny plan wypuszczenia.
Tworzenie szkieletu
Zacznij od identyfikacji głównych działań, które wykonuje użytkownik. To będą Twoje poziome szkielety. Dla strony e-commerce mogą to być: Przeglądanie, Wyszukiwanie, Dodanie do koszyka, Zakończenie zakupu i Zarządzanie kontem.
Dodawanie kroków
Pod każdym działaniem wymień konkretne kroki wymagane. To będą Twoje historie użytkownika. Ułóż je poziomo w kolejności ich wykonywania. Tworzy to szkielet przebiegu użytkownika.
Priorytetyzacja do wypuszczenia
Po zbudowaniu mapy możesz ją przekroić poziomo. Górny wiersz reprezentuje Minimalną Wersję Produkcyjną (MVP). Następny wiersz dodaje większą wartość. Pomaga to zespołom priorytetyzować, co należy najpierw zbudować, na podstawie wartości dla użytkownika, a nie wygody technicznej.
Zalety mapowania
- Daje kompleksowy obraz produktu.
- Wykrywa luki w przebiegu użytkownika.
- Ułatwia lepsze planowanie i harmonogram wypuszczenia.
- Zachęca do współpracy między projektantami a programistami.
Dostosowanie i szacowanie 📏
Pisanie historii to tylko połowa walki. Zespół musi zrozumieć zakres i wysiłek wymagany. Odbędzie się to podczas sesji dostosowania.
Ujednoznacznianie niejasności
W trakcie dopracowywania zespół zadaje pytania. „Co się stanie, jeśli użytkownik nie ma dostępu do internetu?” „Jak obsługujemy powtarzające się e-maile?” Te pytania ujawniają ukrytą złożoność. Nie czekaj, aż sprint się rozpocznie, by zadawać te pytania.
Określanie rozmiaru historii
Zespoły często używają porównawczego rozmiaru zamiast godzin. Uznaje to, że szacowanie czasu jest trudne i różni się w zależności od osoby. Powszechnymi metodami są:
- Poker planowania: Członkowie zespołu głosują na rozmiar, używając kart.
- Punkty historii: Wartość liczbową reprezentującą złożoność, wysiłek i ryzyko.
- Rozmiary T-shirt: Mały, średni, duży, X-duży do planowania na wysokim poziomie.
Niezależnie od metody, celem jest zgodność. Jeśli zespół znacznie się różni, historia musi zostać rozłożona na mniejsze części lub dokładniej przebadana.
Typowe pułapki do uniknięcia ⚠️
Nawet doświadczone zespoły popełniają błędy przy obsłudze historii użytkownika. Znajomość tych typowych pułapek może zaoszczędzić dużo czasu i frustracji.
1. Pisanie zadań technicznych jako historii użytkownika
Zadania takie jak „Przepisz schemat bazy danych” lub „Zaktualizuj wersję biblioteki” są ważne, ale nie są historiami użytkownika. Są to zadania techniczne. Choć powinny istnieć w backlogu, powinny być przedstawione jako zadłużenie techniczne lub prace infrastrukturalne, a nie jako bezpośrednia wartość dla użytkownika. Jeśli musisz napisać historię, przedstaw ją jako „Jako programista, chcę zaktualizować bibliotekę, aby uniknąć luk bezpieczeństwa.”
2. Ignorowanie „żeby”
Pomijanie klauzuli korzyści prowadzi do rozrostu funkcjonalności. Zespoły budują rzeczy, które wyglądają dobrze, ale nie rozwiązują problemu. Zawsze zmuszaj zespół do uzasadnienia wartości.
3. Przeciążanie opisu
Opis historii nie powinien być powieścią. Jeśli historia wymaga 10 stron dokumentacji, jest zbyt duża. Rozłóż ją na mniejsze części. Opis powinien być podsumowaniem, z linkami do szczegółowych specyfikacji, jeśli to konieczne.
4. Traktowanie historii jako stałych umów
Pamiętaj o aspekcie negocjowalnym. Jeśli zespół znajdzie lepszy sposób rozwiązania problemu, powinien to zaproponować. Sztywne przestrzeganie początkowego żądania może stłumić innowacyjność.
5. Ignorowanie przypadków brzegowych
Historie często skupiają się na drodze szczęśliwego użytkownika. Testery i programiści muszą jawnie wskazać przypadki brzegowe. Co się stanie, jeśli dane wejściowe są null? Co jeśli sieć się zawiesi? To musi być część kryteriów akceptacji.
Współpraca i komunikacja 🗣️
Historia użytkownika to narzędzie współpracy. Połącza właściciela produktu, zespół programistów i testerów. Bez komunikacji historia to tylko tekst na ekranie.
Trzej przyjaciele
Powszechną praktyką jest spotkanie „Trzech Przyjaciół”. Uczestniczy w nim właściciel produktu, programista i tester, którzy omawiają historię przed jej wejściem do sprintu. Razem przeglądują historię, aby zapewnić zrozumienie i kompletność.
- Właściciel produktu: Potwierdza wartość i priorytet.
- Programista: Potwierdza możliwość techniczną i złożoność.
- Testowanie:Potwierdza możliwość testowania i przypadki brzegowe.
Ciągła zwrotna wiadomość
Nie czekaj na przegląd sprintu, aby otrzymać feedback. Udostępniaj wczesne szkice historii użytkownika z zaangażowanymi stronami. Uzyskaj ich opinię na temat sformułowania i wartości produktu. Zmniejsza to ryzyko budowania nieprawidłowego rozwiązania.
Pomoc wizualna
Tekst nie wystarczy. Używaj szkiców, mockupów lub schematów, aby uzupełnić historię. Obraz może szybciej wyjaśnić złożowy przepływ pracy niż akapit tekstu. Przypnij te artefakty bezpośrednio do rekordu historii.
Ostateczne rozważania dotyczące sztuki tworzenia historii użytkownika 🎯
Opanowanie sztuki tworzenia historii użytkownika wymaga praktyki. Wymaga zmiany nastawienia od pisania wymagań do wspierania rozmów. Celem nie jest stworzenie doskonałych dokumentów, ale jasne zrozumienie.
Zacznij od małego. Skup się na modelu INVEST. Upewnij się, że każda historia przynosi wartość. Bądź gotów rozbić rzeczy na mniejsze części, jeśli wydają się zbyt duże. Angażuj zespół w proces pisania.
Gdy jest dobrze wykonane, historia użytkownika staje się fundamentem Twojej realizacji. Wyrównują zespół, precyzują wizję i zapewniają, że każdy wiersz kodu ma cel. Kontynuuj doskonalenie swojego podejścia i pozwól historyjom kierować Twoją pracą.