Historyjki użytkownika (ang. User Stories) są niezwykle popularne wśród zespołów zajmujących się wytwarzaniem oprogramowania, a już szczególnie w metodykach zwinnych. Czy są używane również w Twoim zespole do definiowania wymagań?
Jeśli odpowiedziałeś/aś twierdząco to zdecydowanie warto abyś sięgnął/sięgnęła po książkę Jeffa Patton'a: Mapowanie historyjek użytkownika.
Wiesz, dlaczego?
Dlatego, że historyjki wcale nie służą do definiowania wymagań. Tak, pytanie było trochę podchwytliwe - przepraszam.
Jeśli powyższe stwierdzenie Cię nie zaintrygowało to możesz spokojnie zakończyć czytanie tego wpisu, bo nic poniżej też Cię nie przekona do lektury wspomnianej książki i zgłębienia tematu.
Jeśli jednak jesteś ciekawy/a co Jeff Patton ma na myśli, to poniżej podzielę się kilkoma spostrzeżeniami, które wyniosłem z lektury i które, mam nadzieję, wyjaśnią powyższą tezę.
Forma nie ma znaczenia
Wszyscy przyzwyczailiśmy się do zapisu historyjek w formie: As <user>, I can <capability>, So that <receive benefit>. I oczywiście nie ma nic złego w takiej formie, tyle tylko, że to nie o formę zapisu chodzi.
Zapisana historyjka jest jak zdjęcie z wakacji. Gdy pokazujemy nasze zdjęcie z wakacji znajomemu, osoba ta widzi rodziców z dzieckiem stojących na plaży i głupio się uśmiechających. Koniec. Jeśli jednak my sami spojrzymy na to zdjęcie, od razu przypomnimy sobie, że w dniu, w którym zdjęcie zostało wykonane, wybraliśmy się na rejs statkiem, były duże fale, a kapitan statku nie wydawał się do końca trzeźwy.
Podobnie jest z historyjkami. Stanowią wartość tylko dla ludzi, którzy uczestniczyli w ich opracowaniu. Dyskutowali nad nimi, omawiali wartość, którą za ich pomocą dostarczą końcowemu użytkownikowi i kłócili się szczegóły. Dla każdej innej, postronnej osoby, będzie to tylko i wyłącznie pewna forma dokumentacji (i to wcale nie najlepsza).
Przyznacie, że patrząc w taki sposób na historyjki de facto nie ma większego znaczenia jak je zapiszemy. Wszak zdjęcie może być niewyraźne, liczą się wspomnienia.
Wymaganie to złe słowo
Powinniśmy zadać sobie jedno bardzo ważne pytanie: Czy chcemy dostarczyć klientowi to co zamówił, czy to co naprawdę potrzebuje?
W pierwszym przypadku wystarczy zebrać i przenieść wymagania klienta do naszego rejestru. Choćby w formie historyjek. A następnie zacząć development. W tym scenariuszu najczęściej kończymy jednak z gotowym produktem, który nikomu nie jest potrzebny, lub którego nikt za bardzo nie chce używać.
Jeśli jednak zależy nam na faktycznym odkryciu czego potrzebują końcowi użytkownicy, powinniśmy eksperymentować w sposób kontrolowany. Autor dość wyczerpująco, z przykładami, zachęca do stosowania takich technik jak MVP wywodzącego się z Lean Startup (więcej o MVP znajdziesz tutaj) czy Design Thinking. Są to koncepcje, w których słowo "wymaganie" jest traktowane na równi z herezją. Techniki te bazują na empatii, definiowaniu problemów, generowaniu pomysłów na ich rozwiązanie, przeprowadzaniu eksperymentów i uczeniu się na nich. Wszystko to powtarzając do momentu uzyskania pożądanych wyników, czyli pewności co do słuszności i użyteczności danego rozwiązania.
Mapowanie historyjek jest tylko narzędziem w takim procesie. Może być użyte na różnych jego etapach. Począwszy od zobrazowania stanu aktualnego, czyli jak ludzie żyją bez naszego wspaniałego produktu, po odzwierciedlenie pomysłu, czyli jak ludzie będą żyli używając go. Mapowanie historyjek stanowi więc jedynie efekt uboczny rozmów prowadzonych podczas zdobywania wiedzy, dyskutowania nad pomysłami i budowaniem prototypów.
Historyjka niejedną ma wielkość
Powszechnie przyjął się podział wielkości pracy, narzucony przez najbardziej popularne na rynku narzędzia, w którym najczęściej wyróżniamy elementy typu Epos (ang. Epic), Funkcjonalność (ang. Feature) czy wreszcie Historyjka Użytkownika (ang. User Story). W kolejności od największej do najmniejszej, gdzie epos to duży element produktu, którego implementacja może zająć np. kilka miesięcy. Taki element może składać się z pojedynczych funkcjonalności, na które z kolei składają się historyjki użytkownika.
Według Jeffa Pattona każdy z tych elementów jest tak naprawdę historyjką. Należy to rozumieć w sposób taki, że przy każdym z nich powinniśmy tak naprawdę opowiadać historię, budować narrację i prowadzić dyskusje. Przy czym każdy z tych elementów ma zastosowanie przy różnych okazjach. W momencie, gdy rozmawiamy z kluczowymi interesariuszami operujemy raczej na poziomie eposów. Gdy dyskutujemy z końcowymi użytkownikami mówimy najczęściej o funkcjonalnościach. Gdy natomiast uczestniczymy w zespołowej sesji doskonalenia rejestru produktu, rozbijamy pojedyncze funkcjonalności i dyskutujemy na poziomie historyjek użytkownika, które chcemy zrealizować w najbliższym czasie.
Sprowadzenie każdego typu elementu do historii jest zasadniczo esencją mapowania historyjek użytkownika. Budowanie mapy zaczynamy wszak od najbardziej ogólnych czynności, które mają zaprowadzić użytkownika do celu. Następnie rozbijamy je na etapy, a te z kolei dzielimy na zadania, które mogą być sekwencyjne (oś lewo-prawo) lub niezależne od siebie (oś góra-dół).
W celu zobrazowania, weźmy za przykład kupno laptopa przez Janka, w sklepie internetowym. Oto jak mogłaby wyglądać najprostsza mapa historyjek:
Subiektywnie
Poniżej parę subiektywnych spostrzeżeń co do samej książki.
Autor obrazuje przykłady, na podstawie rzeczywistych zdjęć z warsztatów, nanosząc na nie grafikę czy inne dopiski. Doceniam sam pomysł, ale generalnie nie jest to najbardziej czytelne podejście. Pewnie jest to efekt zamierzony, w końcu fotografie pochodzą z prawdziwych firm i mogą być na nich informacje wrażliwe. Natomiast w niektórych miejscach książki fajnie by było zobaczyć zapisy przykładowych historyjek. "Uroku" dodaje również fakt, że czasami autor odnosi się do kolorów na tych fotografiach, a ilustracje są czarno-białe (przynajmniej w polskim wydaniu Helion'a).
Inny aspekt, który zwrócił moją uwagę, to trochę nazbyt optymistyczne czasy wypracowania rozwiązań, podawane przez autora. Pojawiają się stwierdzenia, że w parę godzin, dana grupa ludzi jest w stanie wypełnić całą ścianę przedyskutowanymi historyjkami, lub że przez dwa dni warsztatów wypełnili kilkadziesiąt metrów ściany w biurze. Nie mówię, że nie jest to możliwe. Powiedziałbym jednak, że potrzebna jest zgrana grupa ludzi, która konkretnie wie jaki jest cel i co ma robić. Najlepiej mająca doświadczenie w podobnych warsztatach w przeszłości i która potrafi pracować przynajmniej częściowo równolegle. Najczęściej jednak mamy ludzi z różnych obszarów czy działów w organizacji, którzy są na tego rodzaju warsztatach pierwszy raz. Zrównoleglenie pracy w takiej grupie, szczególnie na początku nie jest możliwe (o ile w ogóle chcemy pracować równolegle), a wypracowanie zadowalających rezultatów przychodzi najczęściej po kilku sesjach. Jestem ciekawy jakie jest Wasze doświadczenie? Podzielcie się w komentarzu.
Podsumowując
Jeff Patton podchodzi do tematu szeroko. W książce można znaleźć tak naprawdę rozległy opis sztuki tworzenia wartościowych produktów. Autor wyczerpująco, z przykładami, opisuje takie pojęcia jak Product Discovery, MVP, Design Thinking, Business Model Canvans czy Proto Persony. Mapowanie historyjek użytkownika stanowi tylko tło dla tych koncepcji. Dowiadujemy się, w których miejscach, na drodze do stworzenia udanego produktu, możemy skorzystać z tej techniki.
To co osobiście wynoszę z tej książki, jeśli chodzi o tworzenie map historyjek to, że po pierwsze chodzi o rozmowę, po drugie chodzi o opowiadanie, a po trzecie o dyskusje:-) Jak również to, że nie ma jednego domyślnego schematu czy formatu tworzenia map historyjek. Wszystko zależy od tego co chcemy przez daną mapę osiągnąć.