Spis treści
Jak poprawić user stories? Jak pisać user stories żeby były idealne? Te pytania zadawał sobie chyba każdy kto z User Stories pracował. W tym wpisie dostaniesz 13 porad jak je lepiej pisać. Zapraszam do lektury
Na początek zamiast odpowiedzi „Jak poprawić user stories?” jest wstęp teoretyczny. Pomiń akapit jeśli znasz.
User Stories to technika która jest powiązana z pozyskiwaniem wymagań od interesariuszy oraz sposobu prezentacji wymagań. Coraz więcej zespołów wytwarzania oprogramowania pracuje w metodologiach zwinnych. W takich przypadkach ta technika prezentacji wymagań zyskała na popularności.
Przedstawianie wymagań polega na tym aby opisać wymaganie używając kilku niezmiennych słów w zdaniu w którym:
1. Określamy kto
2. Określamy co chce
3. Określamy dlaczego coś chce.
Przykład
Jako sprzedawca(KTO) chciałbym aby system rekomendował odpowiednich dostawców towaru(CO), żeby nie tracić czasu i pieniędzy na zamawianie towaru z niepewnych źródeł.(DLACZEGO)
Pisanie historyjek ma teorii wiele zalet:
- jest szybkie,
- od razu sprawdza czy wymaganie ma sens(tłumaczy kto je chce i dlaczego).
- tłumaczy programistom cel biznesowy wdrażania rozwiązania(z doświadczenia programiści chcą znać ten sens)
- skupia się na rozwiązaniu zapotrzebowania interesariusza
- pozwala podzielić całą aplikację lub moduł na małe, testowalne przy implementacji wymagania
Są też i wady:
- wymagania nie są w 100% precyzyjne i często prowadzi do tego że rozwiązanie nie pokrywa się z tym jak sobie coś wyobrażaliśmy. Często wygrywa tworzenie dokładnej specyfikacji dodatkowo do user stories.
- Trzeba mocno pilnować ogólnego widoku projektu. Rozbijanie czegoś na części często sprawia że potem ciężko jest to złożyć ponownie w wymaganą całość(tak jak z silnikiem samochodowym, rozebrać na części przy odpowiednich kluczach może każdy ale złożyć ponownie bez odpowiedniej instrukcji nie będzie umiał nikt). Tutaj pomaga user story mapping.
Teraz odpowiedź – jak poprawić user stories
Ten paragraf podzieliłem na 13 różnych sposobów z krótkim objaśnieniem. Poniżej spis treści.
#1 Opowiadaj historie
User stories jest często traktowane jak mała dokumentacja wymagań biznesowych od interesariuszy do implementacji. Prowadzi to do tego że piszemy zdanie z user story a następnie dodajemy do tego:
- diagram
- przypadki testowe
- opisy zmian
- kryteria akceptacji
- inne rzeczy które sprawiają że user stories schodzi na dalszy plan
A user stories z założenia ma służyć jako rozpoczęcie rozmowy o zmianie w systemie. Rozmowy między zespołem rozwijającym oprogramowaniem a interesariuszem. W trakcie rozmowy:
-pojawią fajne pomysły i prostsze rozwiązania
-wyjdą wszystkie luki w pomyśle rozwiązania
– interesariusze mogą jasno powiedzieć czego chcą. Dlatego jak tworzysz user story to opowiadaj historię a nie pisz wymagań. Aplikacje do ticketowania traktuj jako przypominajkę do tego że temat trzeba przegadać i opracować rozwiązanie. Nie jako gotową dokumentację.
#2 Opisuj co ma się zmienić w istniejącym systemie
Jak tworzysz user stories do istniejącego systemu(a w większości przypadków tak jest) to zamiast suchego opisu co chcesz jako użytkownik warto jest do formułki KTO, CO, DLACZEGO dodać jeszcze jeden krok o nazwie ZAMIAST lub OBECNIE albo inny który wyjaśni jak jest teraz. W taki sposób tworzenie rozwiązania będzie o wiele szybsze bo pojawia się większa jasność w dyskusji.
Przykładowo
Jako kierownik produkcji chcę aby system pokazywał powiadomienie w momencie gdy stan magazynowy danego elementu jest mniejszy niż 10%. Obecnie jest tak że system nie pokazuje żadnego powiadomienia i zamówienie dodatkowych elementów wykonujemy w momencie gdy elementów zaczyna brakować. Przez to istnieje ryzyko że produkcja się zatrzyma bo ktoś przeoczy że czegoś zaczyna brakować.
#3 Dodawaj termin ważności do user story
Wszyscy lubimy priorytetyzować. Jak przestajemy nad tym panować i tym zarządzać to często jest tak że wszystko jest pilne. Najgorsza sytuacja jest w momencie gdy mamy same pilne elementy w backlogu i nie wiadomo czym zajmować się najpierw.
Dlatego fajnym rozwiązaniem jest dodawanie do user story terminu ważności. Nie deadline tylko termin ważności. Termin ważności oznacza kiedy dane story przestanie być przydatne. Dodatkowo termin przydatności determinuje rozwiązanie(w przypadku gdy trzeba szybko to rozwiązanie będzie prostsze a w przypadku gdy jest czas to rozwiązanie będzie bardziej wyszukane)
Bardzo fajną praktyką jest dodawanie minimalnej wartości terminu ważności do user stories. Przykład. User story w momencie dodawania musi mieć termin ważności na co najmniej 30dni w przód.
#4 Używaj US Mapping
User story mapping nie dotyczy bezpośrednio odpowiedzi na pytanie „Jak poprawić user stories” ale jest na tyle fajnym ćwiczeniem że musiałem to umieścić jako jeden z elementów. A to ćwiczenie polega na zwizualizowaniu podróży klienta z produktem. Pomaga ono zobaczyć obraz całego produktu który ciężko jest zrekonstruować z szeregu atomowych historyjek.
Jest to bardzo dobre ćwiczenie do wykonania na samym początku tworzenia produktu ale też warto je wykonać na istniejącym już produkcie aby wyłapać luki w myśleniu o produkcie ogółem.
#5 Unikaj uszczegóławiania z Jira
User story z założenia ma służyć za przypominajkę o tym że trzeba przeprowadzić rozmowę. Rozmowa to nie jest odpalenie Jiry na rzutniku i pisanie szczegółów live z pozostałymi uczestnikami. W taki sposób przeważnie tworzymy monolog osoby która jest animatorem spotkania.
Oczywiście w przypadku pracy zdalnej prezentowanie często jest jedynym rozwiązaniem żeby wszyscy wiedzieli o czym rozmawiamy. Jednak jak występuje sytuacja gdzie możecie się wszyscy spotkać to zachęcam do wspólnej dyskusji z jak najmniejszą liczbą narzędzi. A w szczególności klepania w klawiaturę bo to zabiera zbyt dużo czasu(nawet jak piszesz bardzo szybko).
#6 Omawiaj z najmniejszą możliwą liczbą ludzi ale pamiętaj o wszystkich
To jest plaga pracy zdalnej gdzie zapraszamy na spotkania szereg ludzi z czego rozmawiają 3 osoby(a czasem nawet dwie). Unikaj omawiania user story w gronie 12 osób. Dąż do tego żeby user story omawiać w gronie niezbędnych z adnotacją żeby nie pomijać żadnego interesariusza(bo to jest jeszcze gorsze niż rozmowy w wielkich gronach).
#7 Zagraj adwokata diabła
Często jest tak że podczas omawiania user story z automatu wykluczane są konkretne rozwiązania. W takiej sytuacji warto jest zagrać adwokata diabła i zacząć bronić tego rozwiązania. Może się okazać że to odrzucone rozwiązanie po kilku drobnych modyfikacjach jest idealne a nigdy byście na nie nie wpadli.
#8 Rozdziel rozmowy techniczne i biznesowe
Jest to pokłosie punktu #6. Często jest tak że rozmowy są zdominowane przez szczegóły biznesowe lub przez szczegóły techniczne. I w takiej sytuacji osoby techniczne albo osoby biznesowe tracą swój czas bo niepotrzebnie siedzą i słuchają. Unikaj takich sytuacji. Najprostszym sposobem jest rozbijanie takich rozmów na osobne spotkania.
#9 Wypisz wszystkie wartości które dodaje dane user story
Aby znacząco poprawić user stories potrzeba sprawić aby spełniały one swój cel najlepiej jak potrafią. Tak jak pisałem wcześniej user stories w idealnym świecie służy jako przypominajka do rozmowy. Jako taki wstępniak do tworzenia wymagań. I aby wymagania były jak najlepiej dostosowane do potrzeby najlepiej jest wypisać wszystkie wartości które dane user story daje.
#10 Jak dzielisz User Story na mniejsze to dziel wynik końcowy
Często jest tak że dane User Story trzeba rozbić na mniejsze historyjki aby rozwiązanie było realizowalne. I żeby dobrze takie user story podzielić to najlepszym sposobem jest dzielenie nie rozwiązania a korzyści. Dzielenie korzyści pozwala na o wiele prostsze planowanie developmentu.
#11 Nie pchaj wszystkiego w UserStories
Jest masa rzeczy do których nie pasuje User Stories. Przykładowo analiza logów, upgrade wersji kodu lub bibliotek albo praca konfiguracyjna. Takie zadania nie są historyjką użytkownika. One pomagają zespołowi developerskiemu pracować szybciej ale nie mają nic wspólnego z historyjką użytkownika. Nie rób takich karkołomnych zadań.
#12 Wyceniaj user stories jako rozmiar nie jako liczba
Nie wyceniaj user stories w story pointach albo w roboczodniach(co jest złą praktyką). User Stories najlepiej wyceniać w postaci rozmiaru. Jakiego rozmiaru? Takiego jak ubrania. XS, S, M, L, XL, XXL. Takie rozmiary dają nam idealną abstrakcję która nie jest uzależniona od czasu.
#13 Nie traktuj user stories jako dokumentacji
Po wdrożeniu najlepiej jest wyrzucić user stories. Tak wiem. Kuszącą propozycją jest user stories traktować jako istniejącą dokumentację. Przecież na ich podstawie utworzyliśmy system!!!
No dobrze tylko wyobraź sobie że wchodzisz do projektu który istnieje od 5 lat i chcesz się dowiedzieć o co w nim chodzi. Masz 1 dzień na pierwsze zapoznanie. Nikt nie ma dla Ciebie czasu i kazał ci przebić się przez 4000 user stories na JIRA. POWODZENIA 🙂
Podsumowanie
Patrząc na ten wpis to podsumować go można w jeden sposób. Im większa popularność tym większe pole do błędnych interpretacji. Czy moja interpretacja(gdzie user story jest punktem zaczepnym do rozmowy o rozwiązaniu a nie dokumentacją samą w sobie) jest ok? W moich oczach, tak. Do dokumentowania wymagań jest wiele innych metod które są skuteczniejsze, zajmują mniej miejsca(nawet ta nieszczęsna forma tekstowa napisana poprawnie – tutaj opisuje najczęściej spotykane błędy)
A czy w oczach innych też tak jest? Chętnie poznam opinię innych w tym temacie 🙂