User Stories – przydatne narzędzie w zwinnym developmencie

Zwinne wytwarzanie oprogramowania praktykowane jest przez większość software house’ów na rynku. Głównie dlatego, że podejście to jest elastyczne, produktywne i efektywne. Każdy etap projektu typu Agile rządzi się własnymi zasadami. W tym artykule omówimy jedno z typowych zwinnych narzędzi – historie użytkownika, czyli user stories.

Spis treści

1. Czym jest User Story?
2. Struktura User Stories
3. Dlaczego tworzenie User Stories jest tak ważne?
4. Jak tworzyć User Stories?
5. Przykłady User Stories 
6. User Stories – podsumowanie

Czym jest User Story?

Zespół developerski może korzystać z zaawansowanej terminologii, aby opisywać tworzone przez siebie funkcjonalności, ale najważniejsza jest perspektywa użytkownika. User story, czyli historyjka użytkownika to uproszczony sposób na to, aby przedstawić, kto będzie korzystał z naszego produktu, co chcą w ten sposób osiągnąć i dlaczego powinni go wybrać. User stories definiują każdy wymóg w projekcie.

Co ważne, user stories powinny być tak proste, jak się da. Zazwyczaj mają długość jednego zdania. W zwinnym developmencie są one umieszczane na karteczkach samoprzylepnych lub fiszkach, a następnie przyklejane na ścianie lub tablicy podczas omawiania pomysłu na aplikację mobilną lub webową. To jest właśnie główny cel user stories – wzniecić dyskusję na temat konceptu oprogramowania. Jak powinien działać, co powinien oferować i kto go będzie używał. User stories pomagają wypracować kolejność developmentu funkcjonalności oraz ramy czasowe dla całego procesu wytwarzania produktu.

Struktura User Stories

Jak już wspomnieliśmy, user stories muszą odpowiadać na trzy proste pytania: kto, co i dlaczego. Wtedy możemy stworzyć następująco brzmiące zdanie:

Jako <użytkownik> chcę <cel>, aby <dlaczego>.

Wytłumaczmy zatem znaczenie każdego z tych elementów.

Kto?

Znany także jako persona – zazwyczaj to charakterystyka użytkownika końcowego, który będzie korzystał z naszego produktu, ale nie zawsze. Nie muszą to zawsze być Twoi klienci, ale też wewnętrzni partnerzy czy członkowie zespołu, którzy będą mieli do czynienia z ostatecznym systemem jako administratorzy, menedżerowie lub pracownicy obsługi klienta.

Co?

To cel, który chce osiągnąć użytkownik, korzystając z produktu.

Dlaczego

Tutaj mamy powód, dla którego użytkownik chce skorzystać z tej konkretnej funkcjonalności.

Dlaczego tworzenie User Stories jest tak ważne?

Istnieje wiele zalet rozpisywania user stories, o których warto pamiętać. Po pierwsze, każde zadanie otrzymuje kontekst, w którym powinna być uwzględniona wartość – nad nią będzie pracował zespół. Uwaga jest przeniesiona na użytkownika, co pomaga każdemu pracownikowi skupić się na tym, co naprawdę ważne. Zamiast odhaczać kolejne zadania do zrobienia, można przecież rozwiązywać prawdziwe problemy. 

Dzięki user stories zespół ma możliwość pobudzenia swojej kreatywności i krytycznego myślenia. Mogą oprzeć swoją pracę na wspólnych celach, dążąc do efektów pożądanych przez użytkownika. Każda historyjka użytkownika to pretekst do pchnięcia projektu naprzód poprzez zwiększenie motywacji i morale zespołu. To także doskonałe narzędzie do priorytetyzowania zadań. User stories pozwalają uniknąć ograniczeń występujących wtedy, gdy funkcjonalności są określone z góry bez wstępnej analizy możliwości ich implementacji w produkcie. Na koniec warto dodać, że są niezwykle pomocne w wykorzystywaniu feedbacku zebranego wcześniej od użytkowników.

Jak tworzyć User Stories?

Jest kilka zasad, które warto wziąć pod uwagę podczas pisania user stories. Po pierwsze, musisz się zastanowić: jaki typ użytkownika bierzesz pod uwagę. Zazwyczaj istnieje wiele person, które zespół i właściciel produktu powinni wziąć pod uwagę – bo dla każdego oprogramowania może być więcej użytkowników końcowych. W takim wypadku należy napisać wiele historii dla każdego z nich i wszystkich celów, które będą chcieli osiągnąć. 

Potem definiujemy moment, w którym konkretna aktywność prowadzi do zrealizowania celu. Nie chcemy, żeby nasze user stories zatrzymywały go w środku akcji, a raczej, żeby mógł ją wykonać i otrzymać przewidziane rezultaty. Jeżeli proces jest złożony z mniejszych kroków, każdy z nich powinien otrzymać swoją user story.

Możesz także dodać szczegóły do każdej historyjki poprzez ustalenie “warunków satysfakcji”. Są to kryteria akceptacji, które w user stories typu agile determinują, czego tak naprawdę chce użytkownik. Prościej mówiąc to zasady opisujące warunki, które muszą być spełnione, aby osiągnąć zamierzony cel.

Jeśli chodzi o zwinny zespół programistyczny, powinny oni także ustalić kilka rzeczy. Każda user story musi odnosić się do zadań i podzadań, które muszą zostać ukończone przez konkretnego członka zespołu i powinna być przypisana do odpowiedniej osoby już w trakcie tworzenia historii. Warto także po raz kolejny przedyskutować ramy czasowe podczas pracy nad każdą stories – wstępne założenia mogą nie być na tyle szczegółowe. Umieszczenie user story na tablicy pozwala zdać sobie sprawę, jak wiele czasu będzie trzeba poświęcić na stworzenie każdej funkcjonalności.

Na koniec zbierz i przeanalizuj informacje zwrotne od Twoich potencjalnych klientów i innych użytkowników końcowych. Na ich podstawie stwórz historie. To dużo bardziej produktywna metoda niż zgadywanie, co każdy typ użytkownika chciałby dostać.

Kto pisze User Stories i dlaczego?

Pisanie user stories powinno się odbywać w zespole. W dobrze prowadzonych projektach agile zazwyczaj każdy bierze udział w procesie. Właściciel produktu jest osobą kluczową, ponieważ jest odpowiedzialny za prowadzenie backlogu user stories dla całego zespołu. Warto jednak pamiętać, że same user stories nie są tak kluczowe jak dyskusja, którą wywołują i wnioski, jakie można dzięki nim wyciągnąć.

Trzy C w User Stories

Zwinne zespoły powinny znać komponenty user stories zwane Trzy C, zanim zaczną je tworzyć. W ten sposób będą mogli je pisać w prawidłowy sposób. Sprawdźmy, co każde C oznacza i dlaczego są one tak istotne.

Karta (Card)

Pierwsze C jest raczej oczywiste. To karta, na której umieszcza się user story. Są one częścią backlogu. Warto pamiętać, że nie trzeba wcale w nim umieszczać idealnie dopracowanych elementów – ważna jest dyskusja nad nimi. Po to właśnie są karty – aby prowokować dyskusję pomiędzy członkami zespołów typu agile.

Konwersacja (Conversation)

Kluczowa część i najważniejszy cel tworzenia user stories. Właściciel produktu oraz zespół programistyczny powinien porozmawiać o każdej historii. Co ważne, zwykle jest to konwersacja werbalna, można ją jednak wesprzeć dokumentacją, testami i innymi przydatnymi danymi. Nie można jednak zapominać o rozmowie jako celu user stories. Powinny one wywoływać żywą dyskusję na temat ich realizacji.

Potwierdzenie (Confirmation)

Każda historyjka ma swoje “kryteria akceptacji” będące wskazówkami odnośnie momentu wykonania konkretnej akcji. Kryteria te muszą być uzgodnione przez cały zwinny zespół.

INVEST

Kolejna zasada determinująca, czy napisana historia jest zrozumiała dla całego zespołu i czy może on przystąpić do pracy. INVEST można stosować także do wszystkich innych zadań zgromadzonych w backlogu, nie tylko do user stories.

I – Independent (Niezależne)

Wszystkie user stories muszą być od siebie odseparowane. Oznacza to, że funkcjonalności nie powinny być technicznie zależne od siebie – oczywiście w miarę możliwości. Wymaga to wdrożenia kreatywnego myślenia, rozwiązywania problemów oraz zwinnych technik wytwarzania oprogramowania w pracy zespołu.

N – Negotiable (Możliwe do negocjacji)

Należy pamiętać, że user stories to nie to samo, co wymagania projektu. Muszą być nieco plastyczne. Każda historia powinna zostać przedyskutowana. Zanim zacznie się faza produkcji, zespół powinien mieć możliwość wprowadzania zmian.

V – Valuable (Wartościowe)

User story powinna mieć wpisane cele biznesowe między wierszami. Kryteria akceptacji efektu końcowego powinny być skoncentrowane na osiągnięciu danego celu. Nie każdy rezultat w ramach user stories będzie przynosił bezpośrednie korzyści. Trzeba znaleźć równowagę – dać użytkownikom to, czego szukają i spełniać potrzeby biznesowe.

E – Estimable (Możliwe do oszacowania)

User story powinna pozwalać programistom i reszcie zespołu estymować czas potrzebny do przekształcenia jej w funkcjonalność.

S – Small (Małe)

User story powinna być tak mała, żeby można ją było przekształcić w funkcjonalność w trakcie trwania jednego sprintu. Nieumieszczanie w backlogu pozycji, które są większe to dobra praktyka.

T – Testable (Testowalne)

Weryfikacja każdej user story jest istotna – należy sprawdzić, czy pozwala ona osiągnąć założony cel. Testowanie kryteriów akceptacji, aby ustalić, czy zdefiniowana aktywność końcowa jest taka, jak powinna być, powinno być stałym elementem tworzenia user stories.

Przykłady User Stories 

Wiesz już jak pisać user stories oraz jakie są kluczowe elementy, które trzeba wziąć pod uwagę w trakcie procesu ich tworzenia. Oto kilka przykładów, które pokażą Ci, jak takie historyjki mogą wyglądać:

Jako użytkownik chcę dodawać zdjęcia, aby moi znajomi mogli zobaczyć, jakie mam osiągnięcia.

Jako menedżer chcę mieć wgląd w statystyki pracy, aby móc analizować postępy pracowników.

Jako Kasia chcę móc organizować swoje notatki, aby zyskać kontrolę nad moją pracą.

Jako Wojciech chcę mieć dostęp do panelu administratora, aby spełniać swoje obowiązki admina systemu.

Jak widzisz, nie wszyscy ludzie w powyższych przykładach są klientami. W dwóch ostatnich user stories mamy także imiona – ponieważ tworzenie person z danymi personalnymi takimi jak imiona, wiek lub szczegóły aparycji to częsta praktyka.  Pozwala to lepiej sobie wyobrazić cele i potrzeby tych osób.

User Stories – podsumowanie

Jeśli Twoim marzeniem jest stworzyć niestandardowe oprogramowanie – na przykład aplikację webową lub mobilną, stronę internetową czy inny użyteczny produkt – z pewnością będziesz pracować z doświadczonym software housem, który zatrudnia utalentowanych designerów. Wszystkie tego typu firmy korzystają z metodologii Agile i Scrum w swoich projektach. W związku z tym piszą także user stories.

Lepsze zrozumienie potrzeb Twoich klientów i użytkowników, osiąganie celów biznesowych poprzez dostarczanie wartości oraz świadome budowanie każdej funkcjonalności to ogromne zalety user stories. Bądź częścią procesu, a zobaczysz, że Agile to framework, w którym bardzo dobrze się pracuje.

Jeśli potrzebujesz partnera biznesowego, który wie jak pisać user stories, czyli historyjki użytkowników i potrafi ich używać w projektach software’owych – skontaktuj się z nami. Porozmawiajmy o szczegółach Twojego produktu. Stworzymy takie historie wspólnie, a potem je ożywimy w formie aplikacji lub innego oprogramowania.