11

Pisanie historyjek użytkownika wbrew pozorom nie jest aż tak trudne. Dużo większym wyzwaniem jest ich dzielenie na mniejsze części. A dzielić trzeba, bo duże historyjki źle się szacuje. Poza tym, im większa historyjka, tym większe ryzyko, że nie uda nam się jej zrealizować w sprincie.

W dzisiejszym wpisie pokażę wam 9 moich ulubionych wzorców, które na pewno ułatwią wam to karkołomne zadanie. Żaden z nich nie jest lepszy, ani gorszy. Zachęcam do eksperymentowania 😉

Wzorzec #1: Kroki w procesie

Historyjki, które zawierają w sobie jakiś proces, można podzielić, rozbijając je na poszczególne kroki.

Załóżmy, że pracujecie nad stworzeniem sklepu internetowego i jedna z historyjek wygląda następująco:

Jako klient muszę mieć możliwość zapłacenia za zakupy, żeby moje produkty zostały dostarczone do domu.

Ta historyjka, na pierwszy rzut oka wygląda dość niepozornie. Ale jak tylko zaczniecie ją rozkładać na czynniki pierwsze, to od razu widać, że można podzielić ją na następujące mniejsze części:

(…) muszę mieć możliwość zalogowania się do swojego konta, żeby wyeliminować konieczność ponownego wprowadzania danych osobowych za każdym razem podczas dokonywanych zakupów.
(…) muszę mieć możliwość sprawdzenia i potwierdzenia mojego zamówienia, żeby poprawić ewentualne błędy przed dokonaniem płatności.
(…) muszę mieć możliwość zapłacenia przelewem, żeby potwierdzić złożone zamówienie.
(…) muszę mieć możliwość zapłacenia kartą kredytową, żeby potwierdzić złożone zamówienie.
(…) muszę mieć możliwość otrzymania mailem potwierdzenia złożonego zamówienia, żeby mieć dowód zakupu.

Taka dekompozycja nie tylko wpływa na lepsze zrozumienie rozwijanej funkcjonalności w zespole scrumowym, ale także ułatwia szacowanie i porządkowanie backlogu.

Bo, jak się bliżej przyjrzycie, nie wszystkie historyjki są tak samo ważne na naszej liście. Część z nich możemy zrobić w kolejnych sprintach. Na przykład mail z potwierdzenie zamówienia dla klienta. Na początku można go wysyłać ręcznie. System płatności też nie musi być od razu wypasiony. Wystarczy jak na początku będzie obsługiwał tylko karty kredytowe. Resztę zrobicie w kolejnych sprintach.

Wzorzec #2: Role użytkowników

Ten wzorzec, w niektórych przypadkach, jest mocno powiązany z poprzednim.

Weźmy na przykład taką historyjkę:

Jako content manager muszę mieć możliwość publikowania wpisów na firmowym blogu, żeby zwiększyć zaangażowanie klientów.

To jest historyjka, do której z powodzeniem możecie zastosować dekompozycję z pierwszego wzorca – według kroków w procesie.

Bo, jak się okazuje, opublikowanie wpisu na firmowym blogu, nie polega tylko na napisaniu samego artykułu i wciśnięciu przycisku „opublikuj”. Może być tak, że najpierw trzeba go wysłać do działu marketingu, żeby ktoś zrobił korektę tekstu i wybrał odpowiednie grafiki. Potem, możliwe, że nasz artykuł trafi do zaopiniowania przez dział prawny.

Jak widzicie, kroków w procesie może być całkiem sporo. Podobnie jak i ról użytkowników, którzy są w niego zaangażowani. I tutaj właśnie, pojawia się drugi wzorzec, który chciałem wam polecić.

Gdybyśmy mieli podzielić naszą historyjkę, biorąc pod uwagę role zaangażowane w kroki procesu, moglibyśmy otrzymać coś takiego:

Jako klient muszę mieć możliwość czytania nowych artykułów na firmowym blogu, żeby być na bieżąco z najważniejszymi informacjami i wydarzeniami firmy.
Jako content manager muszę mieć możliwość publikowania artykułów na firmowym blogu, żeby mieli do nich dostęp nasi klienci.
Jako korektor muszę mieć możliwość korekty artykułów przed publikacją na firmowym blogu, żeby unikać błędów i literówek.
Jako administrator muszę mieć możliwość usuwania wpisów ze strony, żeby eliminować niepożądane treści.

Jak widzicie, taka dekompozycja może prowadzić do zupełnie innego zestawu historyjek, niż stosując zasady z pierwszego wzorca. Co więcej, może się okazać, że potrzebujecie zupełnie nowych funkcjonalności, o których wcześniej w ogóle nie myśleliście.

Podobnie jak przy pierwszym wzorcu, także tutaj, taka dekompozycja zwiększa poziom zrozumienia zespołu tego, co robimy, ułatwia szacowanie i porządkowanie backlogu.

Tutaj na kolejność elementów Backlogu Produktu mają wpływ poszczególne role, które wymieniliście. Może się na przykład okazać, że korekta tekstu nie jest aż tak bardzo priorytetowa i historyjki, które jej dotyczą można zrobić później.

Wzorzec #3: Reguły biznesowe

W niektórych przypadkach możecie dekomponować historyjki użytkownika w oparciu o reguły biznesowe, które się za nimi kryją.

Mamy taką historyjkę:

Jako użytkownik, chcę mieć możliwość wyszukiwania połączeń lotniczych z elastyczną datą, żeby wybrać lot, który najbardziej spełnia moje oczekiwania.

Hasło „elastyczna data” jest tutaj kluczowe i kryje za sobą przynajmniej kilka reguł biznesowych.

Jako użytkownik, muszę mieć możliwość wyszukiwania połączeń lotniczych z datą +/- n dni od planowanej daty wylotu i powrotu…
Jako użytkownik, muszę mieć możliwość wyszukiwania połączeń lotniczych tylko w weekendy danego miesiąca…
Jako użytkownik, muszę mieć możliwość wyszukiwania połączeń lotniczych w najbliższym roku od planowanej daty podróży…
Jako użytkownik, muszę mieć możliwość wyszukiwania połączeń lotniczych w najbliższym miesiącu od planowanej daty podróży…

Reguły biznesowe bardzo często są „zaszyte” w historyjce i czasem przydają się zdolności analityczne, żeby je poprawnie rozpracować. Czasem też, bardzo pomaga rozbicie historyjki na przypadki testowe.

Wzorzec #4: Oczekiwany/ nieoczekiwany scenariusz

Każda funkcjonalność domyślnie zakłada określoną, podstawową ścieżkę działania (tzw. happy path), która opisuje jak zachowuje się funkcjonalność, kiedy wszystko idzie zgodnie z planem.

Oprócz ścieżki podstawowej, powinniśmy także wziąć pod uwagę
różnego rodzaju odchylenia od normy.

Ten drugi scenariusz (tzw. unhappy path), najczęściej jest ich kilka, opisuje jak zachowuje się funkcjonalność w sytuacjach wyjątkowych, kiedy nie wszystko idzie po naszej myśli.

Poniżej historyjka, która dotyczy opcji bezpiecznego logowania się do strony webowej.

Jako klient chcę mieć możliwość zalogowania się do strony za pomocą mojego konta, żeby mieć do niej bezpieczny dostęp.

Biorąc pod uwagę podstawową procedurę logowania, bardzo łatwo możemy wyróżnić jeden, oczekiwany scenariusz logowania i co najmniej kilka scenariuszy nieoczekiwanych:

Jako użytkownik chcę mieć możliwość zalogowania się do strony za pomocą mojego konta, żeby mieć do niej bezpieczny dostęp (oczekiwany)
Jako użytkownik muszę mieć możliwość skasowania hasła po nieudanej próbie logowania, żebym mógł zalogować się ponownie (nieoczekiwany).
Jako użytkownik muszę mieć możliwość założenia nowego konta, jeśli nie znam loginu, żeby mieć bezpieczny dostęp do strony (nieoczekiwany).
Jako właściciel strony muszę mieć możliwość zablokowania użytkowników, po 3 nieudanych próbach zalogowania, żeby chronić stronę przed hackerami (nieoczekiwany).

Wzorzec #5: Pracochłonność

Czasami historyjkę możemy podzielić na kilka mniejszych części, z których tylko w pierwszej jest poważna robota do zrobienia. A implementacja pozostałych jest już relatywnie prosta.

Weźmy taki przykład:

Jako gość hotelu, muszę mieć możliwość płatności za pobyt kartą kartą kredytową typu: VISA, MasterCard i American Express.

Tę historyjkę możemy rozbić na trzy mniejsze.

Jako gość hotelu, muszę mieć możliwości płatności za pobyt kartą typu VISA…
Jako gość hotelu, muszę mieć możliwości płatności za pobyt kartą typu MasterCard…
Jako gość hotelu, muszę mieć możliwości płatności za pobyt kartą typu American Express…

Bez względu na to, od której historyjki zaczniecie prace, zawsze implementacja tej pierwszej będzie najbardziej pracochłonna. Bo musi najpierw powstać fasada – odpowiednia infrastruktura, wspierająca płatności elektroniczne, żeby móc później rozróżniać płatności za pomocą różnych typów kart.

Dzielenie historyjek w ten sposób nie jest do końca udane. I jeżeli jest to tylko możliwe, powinniśmy unikać podziału, który generuje zależności między historyjkami. Bo to znaczenie utrudnia szacowania i planowanie pracy.

Oczywiście możemy oszacować pierwszą historyjkę, która pojawi się na naszej liście jako 3 razy większą od pozostałych. Ale wystarczy, że Product Owner zmieni jej kolejność w backlogu i pozamiatane.

Dlatego dużo lepiej jest podzielić historyjki w taki sposób, żeby nie miało znaczenia, którą z nich będziemy wykonywać jako pierwszą. Wtedy nasz podział może wyglądać na przykład tak:

(…) muszę mieć możliwość płatności za pobyt jednym typem karty (VISA, MasterCard, American Express).
(…) muszę mieć możliwość płatności za pobyt dwoma pozostałymi rodzajami kart (VISA, MasterCard, American Express), zakładając, że jeden typ karty jest już zaimplementowany.

Te dwie historyjki w dalszym ciągu są od siebie zależne, ale jest je dużo łatwiej oszacować i zaplanować, niż w poprzednim przypadku.

Wzorzec #6: Operacje (CRUD)

Historyjki użytkownika bardzo często dają się rozłożyć na kilka standardowych operacji, które użytkownik może wykonać. Te operacje najczęściej sprowadzają się do następujących działań: dodawania, wyświetlania, aktualizowania lub usuwania określonych informacji.

Te cztery typy działań obiegowo nazywa się CRUD-em. Jest to skrót od czterech angielskich słów: create, read, update i remove.

Z operacjami typu CRUD możecie się spotkać, kiedy dana funkcjonalność dotyczy zarządzania produktami, użytkownikami lub zamówieniami.

Wróćmy na chwilę do przykładu ze sklepem internetowym:

Jako właściciel sklepu internetowego muszę mieć możliwość zarządzania wystawionymi produktami, żeby aktualizować ceny oraz informacje o produktach wtedy, kiedy się zmienią.

Kiedy bliżej przyjrzycie się tej historyjce i skupicie się właśnie na działaniach, które właściciel sklepu może wykonać, da się ją rozbić na następujące części:

Jako właściciel sklepu internetowego muszę mieć możliwość dodawania nowych produktów, żeby klienci mogli je kupić.
Jako właściciel sklepu internetowego muszę mieć możliwość aktualizacji informacji o wystawionych produktach, żeby dostosować zmiany w cenie oraz informacje o produkcie.
Jako właściciel sklepu internetowego muszę mieć możliwość usuwania wystawionych produktów, żeby usunąć produkty, których nie ma w magazynie.
Jako właściciel sklepu internetowego muszę mieć możliwość ukrycia wystawionych produktów, żeby na jakiś czas wstrzymać ich sprzedaż.

Wzorzec #7: Wydajność

Są takie historyjki, w których największym wyzwaniem jest wydajność. Sama implementacja nie stanowi aż tak wielkiego problemu.

Dlatego staramy się tak podzielić historyjkę, żeby najpierw powstało coś co działa, a potem dopiero skupiamy się na tym, żeby zaczęło działać szybko 🙂

Jako użytkownik muszę mieć możliwość wyszukiwania połączeń lotniczych dla dwóch destynacji, żeby zaplanować swoją podróż.

Biorąc pod uwagę kryterium wydajności, taką historyjkę możecie rozbić na dwie części:

… (wyszukiwanie działa wolno, pojawia prosta animacja wyszukiwania)
… (wyszukiwanie działa szybko, wyniki są dostarczane w czasie krótszym niż 5s)

Wzorzec #8: Wygląd

Ten wzorzec jest bardzo podobny do poprzedniego, tylko dotyczy interfejsu użytkownika. Czasami trudność wcale nie polega na implementacji określonej funkcjonalności, ale na jej odpowiednim wyglądzie.

W takiej sytuacji, znowu, skupiamy się na tym, żeby najpierw dostarczyć coś, co działa, a dopiero potem zacząć przejmować się tym, żeby było ładne 🙂

Jako przykład, weźmy tę samą historyjkę, której użyliśmy w poprzednim wzorcu:

Jako użytkownik muszę mieć możliwość wyszukiwania połączeń lotniczych dla dwóch destynacji, żeby zaplanować swoją podróż.

Stosując kryterium wyglądu, możemy rozbić ją na dwie mniejsze historyjki:

… (proste GUI)
… (wypasiony kalendarz)

Niestety, tak zapisane historyjki są od siebie mocno zależne, ale i tak, w niektórych przypadkach warto ten wzorzec rozważyć.

Wzorzec #9: SPIKE

Czasem do właściwego podziału historyjki brakuje nam odpowiedniej wiedzy technologicznej, bo nie znamy wystarczająco jakiegoś tematu.

W takiej sytuacji, najlepszym rozwiązaniem jest oddelegowanie jednego lub dwóch programistów w sprincie i zbadanie tematu, na którym jeszcze się nie znamy.

Takie podejście najczęściej określamy jako spike. Sam pomysł i nazwa przyszły z Programowania Ekstremalnego.

Załóżmy, że do waszego backlogu trafia taka historyjka:

Jako gość hotelu, muszę mieć możliwość płatności za pobyt kartą kredytową.

Ponieważ historyjka jest dość duża, chcielibyście ją podzielić na kilka mniejszych części. Niestety nie macie bladego pojęcia, jak to robić, bo nikt z was wcześniej nie miał do czynienia z tym tematem.

Jak więc się za to zabrać?

Rozbijamy naszą historyjkę na dwie części:

Zbadać mechanizm płatności elektronicznych z użyciem kart kredytowych.
Zaimplementować płatności elektroniczne z użyciem kart kredytowych.

Pierwsza historyjka trafia do najbliższego sprintu, gdzie podczas planowania ustalacie ile czasu możecie poświęcić na spike’owanie. Przyjmujemy więc pewien bufor. Załóżmy, że jest to 30 godzin. Tyle czasu chcecie poświęcić na research płatności elektronicznych.

Na podstawie wyników historyjki „badawczej”, w kolejnym sprincie będziecie mieć potrzebną wiedzę, która ułatwi wam proces dekompozycji i planowanie dalszych kroków implementacji.