Jak pisać user stories retrospektywnie – poradnik analityka biznesowego

Do Craftware trafiłam z branży nie związanej z IT. Dostałam się na staż do Akademii Craftware i tu stawiałam pierwsze kroki w analizie biznesowo-systemowej. W krótkim czasie zdobyłam ogrom wiedzy i poznałam narzędzia pracy analityka biznesowego. Uczyłam się pod okiem mentorów, którzy wspierali akademistów w realizacji projektu stażowego. Był on zbliżony do tych, które w Craftware wdrażamy dla klientów, dzięki temu oswoiłam się z realiami codziennej pracy.

Mimo że zdobyłam solidne, praktyczne podstawy, pierwszy “prawdziwy” projekt, do którego zostałam przydzielona po ukończeniu akademii, okazał się wyzwaniem. Na szczęście szybko się potwierdziło, że na pomoc doświadczonych kolegów możemy liczyć nie tylko podczas akademii, ale również na co dzień – nasi team leaderzy zawsze chętnie dzielą się z nami wiedzą.

Projekt już trwał, gdy do niego dołączyłam. Moim głównym zadaniem miało być stworzenie user stories, czyli historyjek użytkownika. Jest to powszechna technika używana w analizie biznesowej, zwłaszcza w projektach prowadzonych w metodologii zwinnej. Polega ona na zbieraniu wymagań użytkownika w tak zwanych sprintach i dostarczaniu ich w postaci historyjek użytkownika, wraz z kryteriami akceptacji kolejnych elementów aplikacji tworzonej dla klienta. W ten sposób pomagamy programistom w budowie rozwiązania, a testerom w weryfikacji jego poprawności. Historyjki wprowadzają też nowych członków zespołu w założenia realizowanego projektu.

User stories – jak pisać poprawnie, choć wbrew schematom?

Niestety, analityk biznesowy nie zawsze może przygotować historyjki według takiego schematu.

Tak też stało się w “moim” projekcie. Wymagania zostały zebrane przez zespół, zanim do niego dołączyłam, a potem wystąpiły problemy z weryfikacją postępu pokrywania wymagań (czyli – mówiąc prościej – tego, czy elementy projektu dostarczane przez developerów są zgodne z oczekiwaniami użytkowników). Dodatkowo, zakres projektu niespodziewanie się rozszerzył, co groziło nieporozumieniami i wydłużeniem realizacji. W takich podbramkowych sytuacjach do trwającego już projektu angażuje się analityka biznesowego – w ten sposób do projektu trafiłam ja.

W tym artykule nie skupiam się na tym, jak zbudować poprawną historyjkę użytkownika – w internecie jest wiele poradników i tutoriali na ten temat. Zamiast tego, opiszę, jak zebrać informacje i przygotować analizę biznesową na podstawie dotychczasowych rezultatów  projektu i pozyskanych wymagań. Dzięki temu, że znalazłam się w takiej sytuacji kilkukrotnie, w oparciu o własne doświadczenia oraz merytoryczne wskazówki team leadera mogłam opracować moją koncepcję postępowania. Teraz już wiem, jak zapewnić najlepszą jakość analizy i tej formy dokumentacji, jaką są historyjki użytkownika. Oto mój sposób na analizę retrospektywną, krok po kroku.

Najważniejsze jest przygotowanie do spotkań: to czas na uporządkowanie zgromadzonego materiału oraz usystematyzowanie tego, co zostało spisane wcześniej. Trzeba ułożyć listę pytań, przygotować plansze do współpracy online i sprawdzić, czy da się je udostępnić.
Podczas rozmów z biznesem powinno się sprecyzować główny cel dla fazy produkcyjnej projektu oraz taki jego zakres, na który wszyscy się zgadzają i który przyniesie wartość biznesową finalnym odbiorcom. W trakcie spotkań warto również stworzyć wysokopoziomowy szkic przepływu procesów i decyzji dla rozwiązania.

Z kolei podczas wywiadów z członkami zespołu należy potwierdzić, co zrobiono do tej pory oraz jaki jest zakres pozostałych zadań. Ważne jest również ustalenie, gdzie przechowuje się ich listę (backlog) oraz na podstawie jakich kryteriów ocenia się, czy opracowane funkcjonalności spełniają wymagania biznesu.

Wywiady powinny odbywać się cyklicznie – jedno spotkanie to za mało. Polecam poprosić członków zespołu, aby włączali Cię w każde spotkanie biznesowe. Nawet jeśli Twoja rola ograniczy się do obecności i słuchania – Twoje obserwacje mogą pomóc Ci w dostarczeniu lepszych wyników analizy.

Grupowanie wymagań

Teraz można przystąpić do tworzenia historyjek użytkownika. Dobrym pomysłem jest rozpoczęcie od posegregowania wymagań i rozwijanych funkcji w grupy, na przykład: interfejs użytkownika, przepływ danych, uprawnienia, bezpieczeństwo itp. Pomoże to w budowaniu epików i przypisaniu do nich historyjek użytkownika.

Inny pomysł to przypisanie każdego wymagania do zadań w narysowanym procesie. Można dopasować kilka wymagań do jednego zadania, na przykład:

ZADANIE:

• Logowanie użytkownika do systemu

WYMAGANIA:

• logowanie odbywa się za pomocą maila firmowego,
• powiadomienie o nieprawidłowym haśle bądź loginie,
• możliwość logowania przez SSO.

Historie użytkowników

Świetnie! Teraz można skupić się na tworzeniu historyjek użytkownika z kryteriami akceptacji. Należy pamiętać, że nawet jeśli niektóre wymagania są już pokryte przez dostarczone elementy aplikacji, to i tak trzeba je umieścić w historyjkach użytkownika. Jest to forma dokumentacji dla całego projektu – nie tylko dla tej jego części, od której analityk dołączył do zespołu projektowego.

Potwierdzenie historyjek użytkownika z członkami zespołu i biznesem

Historyjki użytkownika zostały zebrane. Teraz należy potwierdzić, czy są kompletne i czy posiadają kryteria akceptacji, niezbędne do ustalenia, że dane wymaganie zostało spełnione. To kluczowa część, nie tylko dla programistów, ale również dla testerów, którzy będą pisać testy dla rozwiązania.

Tak wysokopoziomowo wygląda mój sposób pracy, gdy dołączam do trwających już projektów. W tym artykule przedstawiłam mój punkt widzenia na retrospektywne zbieranie wymagań. Dzięki świeżemu spojrzeniu na analizę wypracowałam własne podejście, które się sprawdza, a potwierdzeniem jest angażowanie mnie jako analityka – juniora do kolejnych projektów. Do każdego z nich dostosowuję swoją metodę, a dzięki doświadczeniom zbieranym z projektu na projekt efekty mojej pracy są coraz bardziej perfekcyjne.