Jarek ŁojkoChyba najczęściej padającą, niepoprawną próbą odpowiedzi na pytanie czym jest User Story to, o zgrozo: “szablon zapisywania wymagań w Scrumie”. W tym jednym zdaniu składającym się z czterech wyrazów są aż trzy błędy! Dlatego nie pozostaje mi nic innego jak rozprawić się z nimi po kolei i wyjaśnić jak poprawnie korzystać z tej praktyki oraz jakie były jej pierwotne założenia.
User Story się opowiada
Zacznijmy od samego określenia “story” i jego tłumaczenia na język polski. Story to historia, opowiadanie. Logiczne wydawałoby się zatem, że należało by je… opowiadać, a nie tylko zapisywać. Dlaczego? Przychodzi mi tu do głowy świetna analogia użyta przez Jeffa Pattona w książce “User Story Mapping“, który pisze, że “Dobre dokumenty są jak zdjęcia wakacji”.
Wyobraź sobie, że wróciłeś/aś właśnie z bardzo dalekiej, egzotycznej podróży i zorganizowałeś/aś mały pokaz zdjęć dla swoich przyjaciół i rodziny. Samo obejrzenie fotografii, przykładowo jak stoicie ze swoją partnerką czy partnerem pod palmą na plaży i pijecie drinki, nie było by raczej szalenie ciekawym i angażującym przeżyciem dla twoich gości. Co najwyżej ktoś rzuciłby komentarz “piękna plaża!”, no bo cóż więcej można powiedzieć na temat takiego zdjęcia?
Co innego, gdy opatrzycie je konkretnym opowiadaniem, historią. Przykładowo, że to jest właśnie miejsce gdzie się zaręczyliście, a chwilę po zrobieniu fotki zostaliście obrabowani przez grasujące w okolicy dzikie małpy, co skończyło się stresującą wizytą w ambasadzie i wyrabianiem tymczasowych paszportów. Oczywiście nie sposób dowiedzieć się tego wszystkiego z samego zdjęcia, a dopiero z historii za nim stojącej, którą trzeba… no właśnie, podkreślę jeszcze raz, opowiedzieć!
Analogicznie jest z historyjkami użytkownika. Jeżeli ich, nawet bardzo szczegółowo spisana, forma zostanie po prostu przekazana drugiej osobie (na przykład developerowi), która nie brała udziału w jej tworzeniu, to może ona nie dostrzec w nich tego co autorzy mieli w głowie. Nawet jeżeli ktoś twierdzi, że wszystko rozumie, bo przeczytał dokładnie opis, to opowiedz jej daną historię, aby wszyscy dokładnie wiedzieli, co się za nią kryje.
Gdy po prostu rozpiszesz szczegółowo jakieś wymaganie w Jirze, nawet przy użyciu specjalnego szablonu user story, to pozostanie ono spisanym wymaganiem, specyfikacją, a nie historią użytkownika. Zobacz poniższy komentarz na Twitterze autorstwa jednego z popularyzatorów tej praktyki Rona Jeffriesa, który mówi sam za siebie :).
User Story to nie sam szablon
Apropos szablonu. Skoro rozprawiliśmy się już z jednym mitem, że User Story powinno być przede wszystkim opowiadane, a nie tylko zapisywane i przekazywane dalej, przejdźmy do kolejnego czyli szablonu.
Formułka:
Jako… (użytkownik, kto?)
Chcę/potrzebuję…. (co?)
Po to, aby/ponieważ…. (dlaczego?)
jest tak szeroko rozpowszechniona, że dla wielu to nierozerwalna i wręcz fundamentalna częścią praktyki User Story. Szablon ten rozpowszechnił za sprawą swojej książki “User Stories Applied” Mike Cohn i nie ma oczywiście nic złego w jego używaniu. Należy jednak pamiętać, że samo zastosowanie wzorca nie tworzy nam jeszcze Historii Użytkownika. Aby tak się zadziało musimy spełnić przede wszystkim trzy podstawowe kryteria (tak zwane 3C), które opisuje jeden z twórców metody Programowania Ekstremalnego (Extreme Programming, XP), wspomniany wcześniej – Ron Jeffries. Są to:
Karta (Card)
User Story zapisujemy w zwięzły sposób na niewielkiej karcie. Nie zawierają one wszystkich szczegółów dotyczących danego wymagania, a jedynie hasła wystarczające do łatwego zidentyfikowania danej historii i rozpoczęciu konwersacji na jej temat.
Konwersacja (Conversation)
Tak jak wspominałem wcześniej, dla pełnego zrozumienia danego wymagania, kluczowe jest opowiedzenie historii, wymiana myśli, komentarzy i opinii pomiędzy członkami zespołu. Takie rozmowy toczą się przykładowo w trakcie planowania iteracji czy procesu backlog refinementu.
Jeśli nie spotykacie się, żeby prowadzić rozbudowane dyskusje o historyjkach, to tak naprawdę nie używacie historyjek.
Jeff Patton, “Mapowanie Historyjek Użytkownika”
Konfirmacja (Confirmation)
Bez względu na to ile wspomnianych wyżej konwersacji na temat danej historii odbędzie zespół i ile przygotuje dodatkowej dokumentacji, nigdy nie może być w 100% pewny czy wytwarzane rozwiązanie, funkcjonalność będzie dokładnie tym czego oczekuje od nas użytkownik, klient.
Aby tak się stało niezbędne jest potwierdzenie, konfirmacja poprawnego działania danej historii na przykład przy pomocy testów akceptacyjnych. Dzięki nim jasno określimy kiedy faktycznie dana historia użytkownika może zostać uznana za ukończoną i spełniającą oczekiwania użytkownika.
Na koniec warto dodać i podkreślić, że początkowo Historyjki Użytkownika nie zawierały żadnego szablonu, ani formułki poza 3C nadal pozostając Historyjkami :).
Nie tylko Scrum
Wiemy już, że User Story to nie tylko oklepana formuła “Jako… chcę… aby….” ale także, a w zasadzie przede wszystkim wspomniane 3C i odpowiednia komunikacja. Ostatnim błędem we wspomnianej na wstępie “definicji” było używanie tej praktyki jako elementu Scruma. Faktycznie wiele zespołów Scrumowych korzysta z tego sposobu przygotowywania elementów Backlogu Produktu, ale warto podkreślić, że nie jest to coś, co framework Scrum wymaga. Technika ta została zapoczątkowana w innej zwinnej metodzie, Programowaniu Ekstremalnym (XP) i to właśnie stamtąd zapożyczyli ją sobie adepci Scruma.
Szablon User Story
Mam nadzieję, że rozumiesz już, dlaczego samo użycie wzorca to jeszcze nie Historia Użytkownika. Nie sposób jednak nie omówić szerzej popularnego wzorca (tak zwanej Connextra Template) i teraz przyszła na to kolei. 🙂 A zatem wygląda ona następująco:
Jako… (kto?)
W tym miejscu wpisujemy konkretnego użytkownika, końcowego odbiorcę, dla którego będzie dostarczana dana wartość czy funkcjonalność Produktu. Często do tego celu tworzy się też tak zwane Persony.
Chcę… (co konkretnie?)
Czego konkretnie oczekuję, jaką mam potrzebę, co ma zostać dostarczone, jaka funkcjonalność?
Po to, aby… (dlaczego?)
Co stoi za taką potrzebą? Jak jest motywacja i jej uargumentowanie? Dlaczego tego potrzebuję?
Zauważ, że taki szablon tworzenia i rozmawiania o User Story pozwala wejść nam w buty konkretnego użytkownika, lepiej zrozumieć jego potrzeby, perspektywę i w prosty sposób rozmawiać o złożonych wymaganiach.
Inną zaletą tej metody jest niewątpliwie natychmiastowa próba uargumentowania dlaczego czegoś potrzebujemy. Dlaczego naszym zdaniem jest to w danym momencie wartościowe, godne podjęcia wysiłku i zrealizowania? Wymyślanie kolejnych, nowych funkcjonalności do rozwijanego Produktu raczej nie stanowi większego problemu. Nieco trudniej jest trafić z nimi w konkretne potrzeby użytkownika i to właśnie z rozwinięciem ostatniego punktu tej formułki najczęściej mają problem Product Ownerzy.
Nierzadko coś co wydawałoby się nam genialnym i innowacyjnym rozwiązaniem bardzo szybko umiera, bo po prostu nikt z tego nie korzysta. Pamiętacie chociażby sławetny i szalenie irytujący spinasz w Wordzie? Jego najczęściej używaną funkcjonalnością była chyba opcja całkowitego wyłączenia 😉
INVEST User Story
Poza samą zasadą 3C i bardzo popularnym szablonem wspomnianym wyżej istnieje jeszcze kolejna praktyka, która podpowie nam jak napisać dobrą User Story. Co to znaczy dobrą? W myśli tej metody, rozwijając akronim INVEST będzie to taka historyjka która jest:
- Independent (Niezależna) – Historyjki powinny być możliwe do zrealizowania niezależnie od innych występujących w Product Backlogu czyli powinny samodzielnie reprezentować jakąś wartość, funkcjonalność. Nie zawsze jest to możliwe do osiągnięcia i nierzadko występujące zależności narzucają nam kolejność realizacji. Nie mniej jednak powinniśmy dążyć do tego, żeby takie przypadki stanowiły raczej wyjątek niż regułę.
- Negotiable/Negotiated (Negocjowalne, Przenegocjowane) – Tak jak wspominałem na samym początku tego wpisu, historie się opowiada, przedyskutowuje, negocjuje. Ich zakres powinien być zatem ustalany wspólnie z całym zespołem i jego stroną biznesową oraz możliwy do zmiany i doprecyzowania, a nie po prostu przekazany do realizacji do developerów bez słowa komentarza.
- Valuable (Wartościowe) – Jak mierzyć i oceniać wartość biznesową to obszerny temat na cały osobny artykuł (dajcie znać w komentarzach czy chcielibyście takie opracowanie na blogu). Na potrzeby tego wpisu wyjaśnijmy tę cechę historyjki, że po prostu w oczach jej końcowego odbiorcy, użytkownika czy też interesariusza powinna dostarczać realną wartość, umożliwiać coś nowego, coś ułatwiać, przyspieszać czy też eliminować jakiś występujący do tej pory problem.
- Estimable/Estimated – (Możliwe do oszacowania, oszacowane) – Powinniśmy być w stanie wstępnie oszacować pracochłonność danej historyjki. Przykładowo jeżeli będzie zbyt ogólna, a jej zakres niejasny ciężko będzie podać jakąś sensowną estymatę skoro nie do końca czujemy co jest do zrobienia.
- Scalable, small sized (Skalowalne , niewielkiego rozmiaru) – Ich wielkość i złożoność powinna być na tyle mała, aby możliwe było ich zrealizowanie w jednej iteracji. Przykładowo w Scrumie taka iteracja określana mianem Sprintu może trwać maksymalnie miesiąc kalendarzowy. Co jeżeli jest za duża? Tę kwestię poruszam w artykule Jak dzielić user story?
- Testable (Testowalne) – Opis historyjki wraz z jej kryteriami akceptacji (czy też wspomnianymi przy zasadzie 3C scenariuszami testowymi) powinien być na tyle klarowny, aby możliwe było przeprowadzenie jej testów i sprawdzenie, czy dzięki niej osiągamy pożądany rezultat.
A zatem drogi Product Ownerze, INVEST-uj w dobre User Story 🙂
Kryteria akceptacji
Zwane też czasami warunkami satysfakcji. Najprościej rzecz ujmując, jest to uszczegółowienie danej historyjki użytkownika o konkretne potrzeby biznesowe. Muszą być one spełnione aby móc uznać, że zakładana wartość historyjki została dostarczona i jej zakres zrealizowany zgodnie z założeniami. Można pokusić się o stwierdzenie, że to coś w rodzaju wysokopoziomowych scenariuszy testów akceptacyjnych.
Przykładowo, jeżeli historyjka dotyczy rejestrowania konta użytkownika w jakimś systemie to kryteria akceptacji mogą określać jakie dane musimy podać (imię, nazwisko, adres email, telefon), jaka jest przewidziana walidacja pól formularza oraz potencjalne komunikaty błędów.
User Stories w pigułce
Przykłady User Stories
Zapisz się do Newslettera korzystając z formularza poniżej, a w podziękowaniu otrzymasz ode mnie przykłady realnych historyjek użytkownika, które powstały przy tworzeniu platformy e-learningowej Agile Adept.
Dodaj komentarz