User Story, czy chodzi o szablon?

utworzone przez | Sty 6, 2019 | Scrum | 0 komentarzy

User Story, Story, Historyjki stały się naturalnym elementem krajobrazu Agile. Scrum wymaga User Story. Jak się to pisze? “As a user …” Ile w tym prawdy i czy przypadkiem pisanie User Story na oślep nie zapędziło nas w ślepą uliczkę na drodze ku Agile?

Pamiętam jak dostałem zadanie opowiedzenia, o co chodzi w tym całym Agile pewnemu starszemu już developerowi w mBanku. Więc zaczynam w prostych słowach. Biznes i IT pracują razem jako jeden zespół. Biznes przychodzi bezpośrednio do zespołu i mówi czego potrzebuje. Zespół zadaje dodatkowe pytania na temat potrzeb, mówi co jest możliwe i na kiedy to będzie. Później kiedy już mamy zaimplementowaną funkcjonalność, pokazujemy i pytamy o feedback. Jeśli wszystko jest ok, to możemy wdrażać na produkcję. Jeśli są uwagi, to umawiamy się na poprawki. Developer mówi na to “Ja to znam, kiedyś też tak robiliśmy. BRE Bank tak stawialiśmy. Mówisz, że to się nazywa Agile?”
A później pojawiły się ciężkie metodyki, silosy kompetencyjne i tak dalej. Czyżby historia zatoczyła koło?

Prawdziwym celem korzystania ze story jest wspólne zrozumienie [ Jeff Patton, Story Mapping]

Dlaczego User Story?

Głównym celem zaproponowania User Story jako sposobu pracy z zakresem pracy była potrzeba zmiany podejścia do ustalania zakresu projektu. Wcześniej IT było odpowiedzialne (wiem, że w niektórych firmach nadal tak jest) za spisanie potrzeb biznesu poprzez zadanie wszystkich możliwych pytań i spisanie szczegółowych odpowiedzi. Formą zapisu takich rozmów zazwyczaj było wymaganie w postaci IEE 840, Przypadek Użycia (ang. Use Case), Scenariusz Użycia (ang.Use Scenario). Spisane w ten sposób wymagania najczęściej były wyrażone w języku technicznym, z którego biznes nie chciał korzystać. Po spisaniu wymagań, a tym samym określeniu zakresu biznes przestawał brać odpowiedzialność i czekał na moment kiedy będzie mógł zgłosić uwagi do produktu końcowego. Jakie są szanse, że dobrze się zrozumieliśmy? Jakie są szanse, że klient wiedział czego potrzebuje i potrafił to opisać? A może wiemy więcej o tym jak system ma wyglądać, niż co chcemy osiągnąć i jaki problem rozwiązać? Jeżeli ktoś uczestniczył w takich odbiorach produktu, późnych testach UAT, wie jak takie podejście się kończy.

Software development has been steered wrong by the word “requirement”, defined in the dictionary as “something mandatory or obligatory”. The word carries connotation of absolutism and permanence, inhibitors to embacing change. And the word “requirements” is just plain wrong. [Kent Back]

Zauważmy też, że w takim procesie tworzymy wymagania, czyli coś co jest wymagane, obowiązkowe i nienegocjowalne. Zmiany w wymaganiach będą niszczyły wszelkie założenia i plany. Trzeba stworzyć procesy, a czasem nawet pełne metodyki zarządzania wymaganiami i zarządzania zmianą. Zarządzenie wymaganiami staje się celem samym w sobie. Porażka w dostarczeniu odpowiedniego produktu jest zawsze widziana jako niewystarczające zarządzanie tym co ustaliliśmy na początku.

A może by tak pozwolić klientowi podejmować decyzje wraz z postępem w budowie produktu? Dajmy mu możliwość zmiany zdania, dodawania i usuwania zakresu kiedy uzna? Klient powinien współpracować blisko z zespołem i w sposób ciągły omawiać kolejne funkcjonalności, które potrzebuje.

User Story nie posiadają wszystkich szczegółów, więc łatwo je zmienić. Szybko dodaje się kolejne User Story, bo to tylko kilka zdań. Forma jest na tyle przyjazna, że zarówno klient jak i developer mogą z nimi pracować. Dopiero kiedy jest blisko implementacji, klient i developer uzgadniają szczegóły oraz testy akceptacyjne sprawdzające prawidłowe wykonanie funkcjonalności. Kształt produktu powstaje stopniowo i zmienia się w trakcie implementacji. Dlatego korzystne jest opóźnienie momentu podjęcia decyzji na temat szczegółów kolejnego user story. Duża analiza zrobiona wcześniej będzie nadawała się do wyrzucenia do kosza.

Chociaż w Scrum Guide nie znajdziemy wzmianki o User Story, to taki sposób zapisu Product Backlog Items doskonale spełnia wymagania przejrzystości Product Backlog i stopniowego wyłaniania się kształtu Produktu.

Historia User Story

Technika User Story powstała przy okazji tworzenia Programowania Ekstremalnego ( ang. eXtreme Programming, XP). XP jako metoda pracy jest bardzo podobne do Scrum, ale skupia się bardzo mocno na konkretnych praktykach, z których zespół powinien korzystać w swojej pracy.

W 1993 kształtowały się podstawy metody XP w ramach prac grupy roboczej Hillside Group poszukującej wzorców występujących przy budowaniu oprogramowania. Ward Cunningham zauważył wzorzec Implied Requirement. Kent Beck poszedł dalej rozwijając tę koncepcję i nadał nowemu wzorcowi nazwę Story umieszczając go w ramach Programowania Ekstremalnego.

Wymagania stawiane wtedy dla prawidłowo napisanej Story były następujące:

  • można przetestować automatycznie
  • na tyle małe, że można zmieścić kilka w iteracji,
  • można szybko i łatwo zapisać,
  • można oszacować z jakąś pewnością

Nie było mowy o szablonie pisania Story.

Określenie User Story pierwszy raz zostało użyte później, na projekcie XP, Chrysler C3 w 1996. Wcześniej Kent nie chciał określenia “user”, ponieważ uważał, że historia należy do całego zespołu. Prawdopodobnie na projekcie C3 zaczęto używać określenia User Story, żeby odróżnić historie użytkownika od technicznych (ang. technical stories). Jak już obecnie wiadomo, historie techniczne to antywzorzec Agile i lepiej ich nie stosować.

Czym naprawdę jest User Story?

User Story to po prostu historia użytkownika na temat tego co powinien robić produkt. User Story powinno być opowiadane developerowi przez klienta bez zbędnych pośredników. Klient oczywiście opowiada czego potrzebuje swoimi słowami. Opis User Story powinien być krótki, zaledwie kilkuzdaniowy. Dobrze jest opatrzyć User Story zwięzłym nagłówkiem, żeby łatwiej się do niej odnosić i wiedzieć czego ona dotyczy bez czytania zawartości. User story powinno zmieścić się na fiszce (ang. index card). Korzystanie z takiego rozmiaru kartki skutecznie studzi zapędy do pisania długich, skomplikowanych wywodów. Właściwie tyle w tym temacie. Nie ma tutaj mowy o specjalistach piszących User Story, nie ma też nic o jedynym słusznym szablonie.

To co zapisujesz podczas rozmowy działa jak zdjęcie z wakacji … kiedy na nie patrzysz, pozwala Ci przypomnieć sobie szczegóły, których nie ma na zdjęciu [ Jeff Patton, Story Mapping]

Dobrej User Story nie można napisać samodzielnie. Skryba nigdy nie zada sobie pytań, które zadadzą inne osoby kiedy usłyszą historię. Dlatego niezwykle ważne jest przedstawienie User Story zespołowi, który będzie ją implementował i przeprowadzenie rozmowy na ten temat. Wtedy możemy dojść do zrozumienia u obu stron rozmowy i zapisać ostateczne ustalenia. Właściwie nie powinno być skryby, tylko od razu przychodzi osoba, która ma prawdziwą potrzebę i jest to wspólnie spisywane razem z zespołem. Nierzadko kiedy wrócimy do zapisów i zejdziemy na poziom szczegółów, będziemy musieli zupełnie przerobić User Story, napisać nową albo podzielić na kilka mniejszych. W Scrum nazywamy taką czynność Product Backlog refinement, czy też po polsku pielęgnacja. Warto zapisywać ustalenia w taki sposób, żeby można było je łatwo przetestować i sprawdzić poprawną implementację. Ten cały process pracy z User Story został określony przez Rona Jeffriesa jako Card, Conversation, Confirmation, w skrócie 3C.

User Story powinna być opowiadana przez interesariusza (ang. stakeholder), który ma pewną potrzebę związaną z produktem. Czy zatem Product Owner w Scrum powinien pisać User Story? Niekoniecznie, jedynie wtedy, kiedy interesariuszem jest PO. Product Owner jest odpowiedzialny za wskazywanie wartości i zarządzenie Product Backlog przez określenie kolejności (w tym priorytetu) realizacji potrzeby.

Szablon User Story

Mike Cohn swoją książką User Stories Applied spopularyzował szablon As a , I want , so that, ale to nie on go stworzył. W ramach pracy zespołu Connextra w 2001 do pisania User Story został zaproponowany szablon role‐feature‐reason jako prosty sposób wyjaśnienia nowym osobom jak to robić dobrze i jak w ogóle zacząć. Z założenia ten szablon miał służyć głownie w celu treningowym, edukacyjnym. Głównym autorem tego pomysłu jest Rachel Davies.

Zastosowanie szablonu pozwala na uchwycenie trzech ważnych aspektów. Dla kogo, co i po co budujemy. Prawdziwy powód, który stoi za potrzebą posiadania funkcjonalności pomaga zrozumieć intencję użytkownika. Kiedy rozumiemy intencję możemy zaproponować inny, często lepszy sposób zaspokojenia potrzeby lub rozwiązania problemu. Konkretny użytkownik, persona, rola pomaga zrozumieć kontekst, w którym ten użytkownik korzysta z systemu. W zależności od tego kontekstu rozwiązanie może wyglądać zupełnie inaczej. Pierwotnie, rola w tym zapisie była również ważna ze względu na to, że budowany system był oparty na zarządzaniu uprawnieniami w oparciu o role we frameworku J2EE.

Niestety dosyć szybko szablon “As a user” metoda stała się jedynym słusznym sposobem pisania User Story propagowanym na kolejnych szkoleniach i konferencjach.

Poza samym zapisem User Story w formie historii użytkownika powinniśmy określić jak będziemy testowali czy User Story została zaimplementowana poprawnie. ta cześć formatu określana jest jako Kryteria Sukcesu, Kryteria Akceptacji albo warunki Akceptacji (ang. Acceptance Criteria). Zwykle to tak naprawdę ta część określa nam zakres i złożoność pracy potrzebnej do implementacji. To właśnie ta cześć najbardziej wpływa na oszacowanie rozmiaru.

Dobra User Story jest INVEST

Skąd wiemy czy User Story po napisaniu albo pielęgnacji (ang. refinement) jest dobra?Wyżej piszałem już jakie kryteria podawał Kent Beck, Bill Wake poszedł nieco dalej i zaproponował akronim INVEST, który wygląda następująco:

  • Independent (pol. Niezależna) — można ją zaimplementować niezależnie od innych User Story
  • Negotiable (pol. Negocjowalna) — szczegóły i zakres można doprecyzować, sposób implementacji można zmienić
  • Valuable (pol. Wartościowa) — zaimplementowanie User Story daje wartość dla użytkownika, interesariusza
  • Estimable (pol. Szacowalna) — User Story można oszacować
  • Small (pol. Mała) — User Story powinna być odpowiedniego rozmiaru do zaplanowania, oszacowania na odpowiednim poziomie
  • Testable (po. Testowalna) — User Story można przetestować i sprawdzić czy została poprawnie zaimplementowana

Jak napisać złą User Story?

Najczęstsze anty‐wzorce pisania User Story, które widzę na co dzień to:

  • user/użytkownik zamiast roli, persony, interesariusza
  • tradycyjne wymaganie przekonwertowane na składnię Connextra User Story (Jako użytkownik chcę, żeby system akceptował dane w formacie xml, żebym mógł z niego korzystać)
  • zbyt szczegółowe i tym samym zbyt długie
    z załącznikami lub linkami do innych dokumentów
  • szczegóły implementacji zamiast potrzeby (chcę pole tekstowe o długości 255 znaków, żeby…)
  • Więcej pomysłów w poście Najczęstsze błędy popełniane przy pisaniu User Story

Podsumowanie

User Story jest przede wszystkim głosem interesariusza i zaproszeniem do rozmowy. Można korzystać z szablonu Connextra na początku pracy z tą techniką, ale z czasem można od niego odejść. Jeśli czegoś należy trzymać się rygorystycznie, to tego, żebyśmy zawsze mieli jasne testy akceptacyjne. Chodzi o to, żeby zarówno interesariusz jak i Zespół Developerski rozumieli na co się umawiają. User Story jest ostateczna i zamknięta, kiedy jest zaimplementowana. Do tego czasu może ciągle się zmieniać.