User Story to po polsku Historyjka Użytkownika. To od niej rozpoczęła się moja historia ze Scrumem i podejściem agile. Na początku utożsamiałem te pojęcie z opisem procesu biznesowego. Bo czym innym niż procesem może być „historyjka” użytkownika opowiedziana w kontekście systemu informatycznego?
User Story opisują wymagania
Na naszym blogu wielokrotnie wspominaliśmy o wymaganiach. Celowo unikaliśmy do tej pory terminu User Story, bo w Scrum Guide ta nazwa nigdy nie pada. Nie ma obowiązku formułowania wymagań w tej postaci. Wymagania to elementy Backlogu Produktu, które muszą być w jakiś sposób zapisane i łatwo dostępne (transparentne). Jak to zrobimy, zależy już tylko od nas.
User Story to tylko jeden ze sposobów zapisu wymagań. Jeśli chcemy, mogą one zostać zapisane w dowolny inny sposób, np. jako wiadomości e-mail od użytkowników albo tabela w arkuszu kalkulacyjnym udostępnionym na dysku sieciowym. Dobre praktyki wskazują jednak, że wymagania zapisane w postaci User Story sprawdzają się lepiej.
Nie da się ukryć, że popularny „US” to najczęściej spotykany sposób zapisu wymagań. Dodatkowo, świetnie wpisuje się on w koncepcję „wymagania, a nie zadania„. Często piszemy o tym, że nasz odbiorca nie powinien nam dyktować sposobu rozwiązania problemu. I tak właśnie skonstruowane są US-y.
Co to jest Historyjka Użytkownika?
Zapisanie wszystkich wymagań w taki sam sposób daje nam możliwość łatwego ich zrozumienia. Oczywiście zakładamy, że opis wymagania spełnia wymogi stawiane przed User Stories. Mamy również możliwość porównania wymagań między sobą, co jest szczególnie ważne w przypadku szacowania elementów backlogu czy w trakcie Planowania Sprintu.
User Story powstało jako nieformalny ale zestandaryzowany szablon wymagań. Każda Historyjka Użytkownika powinna posiadać dwa główne elementy. Jednym z nich jest sama „historia”, najczęściej zapisana w formie:
Jako <konkretny użytkownik systemu>
chcę <zrealizować potrzebę>
aby <rozwiązać problem lub osiągnąć cel>.
Nadrzędnym założeniem jest to, że absolutnie każde sensowne wymaganie da się zapisać w przedstawiony powyżej sposób. Jeśli nie jesteśmy w stanie wskazać konkretnego użytkownika systemu może oznaczać to, że nikt z tej funkcjonalności nie będzie korzystał. Zastanówmy się komu jest ona potrzebna i czy w ogóle ktoś zauważy, jeśli nie zrealizujemy tego wymagania.
Jeśli zaś brakuje uzasadnienia i nasza praca nie rozwiąże problemu, ani nie wesprze realizacji celu, może to oznaczać że wymaganie jest z kategorii „chcę bo chcę”. Powinniśmy się wystrzegać takich pustych historyjek. Nie spowodują one wzrostu zadowolenia klienta z dostarczonego przyrostu oprogramowania, a jedynie dodadzą nam pracy.
Konstrukcja User Story
Krytycy User Story skupiają się na samej historyjce – jednym zdaniu opisującym samo User Story („jako, chcę, aby”). Nie zauważają drugiego, niezwykle istotnego elementu tej techniki.
Do każdego z User Story dodane powinny zostać tzw. warunki satysfakcji zwane również HLAC-ami (ang. High Level Acceptance Criteria). Wyobraźmy sobie te warunki jako checklistę, według której będziemy sprawdzać czy na pewno zaspokoiliśmy potrzeby odbiorcy.
Ta lista nie może być zbyt ogólna, bo mogą umknąć nam ważne wymagania. O wiele groźniejsze są jednak zbyt szczegółowe kryteria akceptacji. Nie tylko zabijają one kreatywność naszego Zespołu Deweloperskiego, ale przede wszystkim zamiast opisywać problem – sugerują jego rozwiązanie.
Zapisanie User Story w powyższy sposób powinno dać nam szybko odpowiedzi na najważniejsze pytania: dla kogo budujemy funkcjonalność, jaka jest potrzeba stojąca za budowaną funkcjonalnością i jaki problem rozwiązujemy lub jaki cel próbujemy osiągnąć (jaka będzie korzyść).
Zapisując w User Story warunki satysfakcji określamy jakie kryteria musi spełniać przygotowywana przez nas funkcjonalność. Posiadając komplet informacji zdefiniowany w powyższy sposób, bardzo łatwo jest nadać każdemu wymaganiu wartość (bo wiemy dla jest beneficjentem funkcjonalności, którą wykonujemy i co najważniejsze, po co ją robimy) oraz je wyszacować (bo opisuje ono na tyle mały i jasny problem, że nie mamy problemu z wyobrażeniem sobie pracochłonności).
ZaINVESTuj w dobre historyjki
Dobre User Stories powinny spełniać kryteria INVEST. Ten mnemonik został wymyślony przez Billa Wake’a i opisuje 6 niezwykle istotnych cech każdego wymagania:
Niezależna – nieposiadająca zależności z innymi User Story. Zdarzają się wymagania techniczne albo sekwencyjne, które po prostu są od siebie zależne. Trudno nam będzie robić kolejne (niezależne) raporty, zanim utworzymy mechanizm raportowania. Pomijając jednak oczywistą kolejność prac, starajmy się, żeby wymagania nie były zależne.
Negocjowalna – sposób realizacji wymagania nie może być narzucony i musi zostawić miejsce do negocjacji. To Zespół Deweloperski ma decydujący głos, w jaki sposób zrealizuje wymaganie i nikt, nawet Product Owner, nie powinien w to ingerować.
Wartościowa – przynosząca korzyść odbiorcy i mająca dla niego realną wartość biznesową. Celem czy problemem do rozwiązania, który stoi za realizacją wymagania, nie może być „chcę bo chcę”. User Story musi posiadać wartość dla naszego klienta.
Szacowalna – możliwa do oszacowania przez Zespół Deweloperski. Zespół Deweloperski musi mieć tyle wiedzy na temat danego wymagania, aby bez problemu był w stanie oszacować jego pracochłonność. Ta sztuka nie uda się, jeżeli nie wiemy co jest przedmiotem historyjki.
Mała – możliwa do zaplanowania i realizacji w Sprincie. Wymaganie powinno być na tyle małe, aby możliwe było jego zrealizowanie w czasie trwania jednego Sprintu. Jednak podzielenie go zbyt drobno spowoduje tylko wysokie koszty przełączania i konieczność powtarzania części pracy.
Testowalna – istnieje możliwość stworzenia scenariusza testowego i przeprowadzenia testów rozwiązania. Jeśli nie jesteśmy w stanie sprawdzić, czy dobrze wykonaliśmy pracę, to znaczy, że nic się nie zmienia!
Najważniejsze cechy User Story
Nie można powiedzieć, że jakaś cecha User Story jest najważniejsza. Musi ono zawierać zarówno jasny i klarowny opis, kryteria akceptacji, a całość powinna spełniać wszystkie kryteria INVEST.
Metodyki agile, w których bardzo używa się Historyjek Użytkownika, opierają się o podejście empiryczne. To znaczy, że powinniśmy w praktyce sprawdzić, czy nasze wymagania są zapisane w odpowiedni sposób. Powiedzą nam o tym rezultaty naszej pracy, a gdy będzie naprawdę źle – odezwą się również ludzie.
Jeśli jednak dopiero zaczynamy albo przeprowadzamy transformację agile, to z dużą dozą prawdopodobieństwa możemy powiedzieć, że wzorując się na kryteriach INVEST stworzymy wymagania wysokiej jakości. A jest to pierwszy krok do świadomego szacowania, planowania i realizacji backlogu.
Czy User Story to dobry wybór dla mojego Backlogu?
Wydaje się, że pracując w projekcie utrzymaniowym, zapisywanie wymagań w postaci User Stories nie ma sensu – mamy przecież błędy zgłoszone w Jira czy QC. Czasami zdarzą się też zespoły, które nie chcą zapisywać wymagań w postaci User Story, w obawie przed narzutem na dodatkową pracę. Zdefiniowanie Historyjki Użytkownika w prawidłowy sposób zajmuje przecież dużo czasu.
Czy powyższe twierdzenia są prawdziwe? Nie! Prawidłowo zdefiniowane User Story, zawierające wszystkie niezbędne elementy oraz spełniające kryteria INVEST jest skarbem dla Zespołu Deweloperskiego. Dodatkowy czas poświęcony na transformację wymagania do postaci User Story, nawet jeśli początkowo jest on zauważalny, przyniesie nam korzyść w postaci lepszej jakości backlogu. A ten jest na wagę złota.
Miejmy na uwadze, iż każde jedno User Story (lub zbiór kilku User Stories) jest realizacją Minimum Viable Product. Dostarczanie wartości jest sensem istnienia naszego projektu i naszej pracy. Lepsza jakość User Story przełoży się na lepszą jakość potencjalnie wdrażalnego inkrementu. Lepsza jakoś tego ostatniego przełoży się na zadowolenie osób, dla których pracujemy. A do tego przecież powinniśmy dążyć.
Tematyką User Story zajmujemy się dogłębnie na naszym szkoleniu „Wymagania w projektach agile„. Sprawdź nas!
Powinieneś dawać przykłady. Teoria teorią a przydałyby się 2 – 3 przykłady.
Cały dzień przykładów, pracy z backlogiem, tworzenia User Stories itd. można znaleźć tutaj: https://bialko.eu/wymagania-projekty-agile/, zapraszamy także na szkolenia otwarte! 🙂
Hi,
Tak ujawnia się paradoksalność metodyk:
„Negocjowalna – sposób realizacji wymagania nie może być narzucony i musi zostawić miejsce do negocjacji. To Zespół Deweloperski ma decydujący głos, w jaki sposób zrealizuje wymaganie i nikt, nawet Product Owner, nie powinien w to ingerować.”
Jeśli się nie odezwę jako PO, to Dev zrobi wg swojej wiedzy, a nie wg potrzeby rynku/interesariuszy.
Szczęście jeśli Dev jest klientem produktu i też zna potrzeby.. może zrobi „optymalnie”.
Odezwać to za mało, negocjować idzie w sprzeczności w interwencję.
Wydaje się, że założenia „knoweledge flow” są sprzeczne.
Podobne konflikty wynikają pomiędzy PO vs PDM vs PJM kiedy PO wie lepiej.
No skutki są wtedy dziwne.. produkt jest, ale rynek nie tego chce a PDM, PJM pokazuje features list for shareholders ( IR-part, investor relations part).
Najlepsze akcje są wtedy kiedy DevTeam/SofwareHouse jest wykonawcą jakiejś dużej firmy.. wtedy im absurdy nie przeszkadzają, ważne że jest 250zł/h * coders.
Podobnie jest z UStories.. i zostawianie wielu spraw dla DevTeam – to rozwadnianie roli PDM/PO tak, gdzie czas który mógłby poświęcić na rozpiskę, to traci na spotkania gdzie information flow jest 100% Dev -> PO, zamiast np.30%
Założenia UStories mają bardziej sens przy game development, a najbardziej gdy PO jest oderwany od reszty i ma być decydującym. No ale to słaby efekt gdy PO nie jest ekspertem i raczej fazy wczesno start-up’owe, gdzie szuka się „true” PO.
Co pozwoliła np. w Polsce scena Agile, Scrum itp.. ano możliwość sterowania poważnymi procesami osobom bez kompetencji decyzyjnych (a tak jest bez dziedzinowej wiedzy u siebie), rozwijając struktury na SME, itp. Wszystkiego wiedzieć nie można, ale to jest właśnie problem budowania struktur, często tak gdzie fachowcy są, ale bierze się certyfikaty..
Podobnie jest z SM vs PJM. Zanim te wszystkie metodyki narosły do formy religii i doktryn, to ciężar spoczywał na PJM. Nie da się wszystkiego negować co wymyślono. Rzecz w tym całym consultingu, który rozmija się z istotą biznesu. Dobrze jeśli inwestora stać na takie koszty „kultury” i „zabawy” (niejako demokratyczne, z iluzjami utożsamiającymi rzekomo team). Fakty są jednak takie, że np. Polski rynek różni się od tego zagranicznego i ciekawie wygląda to przycinanie. Chodzi o to, że interesariusz w całym agile/scrum team jest fikcyjny w większości. Nie ma udziału (w sensie korzyści kapitałowej na przyszłość), a udział w budowaniu to wyzysk. Taka to prawda jest, a cały coaching urabia tak i cementuje system. Można by to szerzej skomentować.. nurtują jednak te paradoksy w Polskiej przestrzeni i nie wiem… czy to z tłumaczenia tych dzieł się bierze, braku refleksji na tym jak to działa w praktyce w innych miejscach, czy w czym rzecz..
Jakkolwiek właśnie takie doktryny/ideologie pozwalają uśpić rozum, świadomość i analizę otoczenia. Niemniej nierzadko w korpo odgrywa się rolę, ulega coachingom, a myśli swoje, bo na chlebek trzeba : )
Ten komentarz jest baaardzo chaotyczny i trudno tu się odnieść do tego miksu myśli oraz losowo wrzucanych angielskich słów i określeń.
Największą uwagą, z tego co rozumiem, jest „Jeśli się nie odezwę jako PO, to Dev zrobi wg swojej wiedzy, a nie wg potrzeby rynku/interesariuszy.” I tu leży pies pogrzebany, bo właśnie rolą PO jest zapewnienie, żeby Dev Team rozumiał potrzeby rynku i interesariuszy. Zamiast za stać nad zespołem i przy każdym wymaganiu mówić mu, że „dla klienta istotne jest utrzymanie odpowiedniej kolorystyki rozwiązania” wystarczy raz opowiedzieć o kliencie i o tym, jak ważna jest dla niego identyfikacja wizualna i dlaczego tak jest.
Po drugie, w sformułowaniu „sposób rozwiązania” najbardziej istotne są „technikalia”. Z punktu widzenia PO i klienta najważniejsze są funkcjonalności i elementy niefunkcjonalne, aczkolwiek widoczne. Cała reszta pozostaje pod kontrolą Development Teamu. No bo co PO czy klienta obchodzi, jaka biblioteka zostanie użyta? I znów – jeśli z jakiegoś powodu obchodzi (bo np. nie chcemy używać biblioteki naszego największego rywala „bo tak”), to rolą PO jest zawarcie tego wymagania w elemencie Backlogu Produktu oraz – suprise, suprise – wytłumaczenie zespołom dlaczego to jest istotne. Dzięki temu pozwalamy sobie na uniknięcie takich problemów w przyszłości.
Tak jak pisałem w tekście https://bialko.eu/agile/wymagania-sposob-realizacji/ – „Dobry Product Owner doskonale wie, na jakim poziomie szczegółowości wymagania powinny trafiać do Backlogu Produktu. Zawrze on w nim minimum, które zapewni właściwy tok rozumowania. Jednocześnie unikał będzie stwierdzeń, które zasugerują coś Zespołowi Deweloperskiemu.”
1. Sorki, to było tak przytykiem do logiki. Patrzę z perspektywy big korpo. Może ktoś coś wyciągnie dla siebie.
” I tu leży pies pogrzebany, bo właśnie rolą PO jest zapewnienie, żeby Dev Team rozumiał potrzeby rynku i interesariuszy. ”
a) Nie ma szans na to w wielu przypadkach. Ja mam wrażenie, że zbyt często i zbyt lekko mówi się o produktach prostych typu jakiś serwis www, może rozbudowany, aplikacja funkcjonalna (GUI, itp. – może to wynika z młotka masłowa? Szybkie awanse serwisowców, albo designerów). Zarządzanie się przydaje, bo jest dużo ludzi i obieg szerokiej informacji.
b) Ale gdy do gry wchodzi coś zaawansowanego, specyficznego, unikalnego, to Dev Team zgubi się już podczas wyboru formatu pliku, rozszerzenia. Wyobraziłem sobie kilka przypadków próby zastosowania takiej myśli „nie wtrąca” itp. Uznałem, że warto zwrócić uwagę na ten problem oraz sprawę UStories. Przy takiej filozofii INVEST i US kończy się rola dla ew. widoków rozbudowanych formularzy. Problem się rozwija gdy taki PO z takim doświadczeniem próbuje replikować praktykę formularzy (widoków) gdzieś indziej by upraszczać pracę albo raczej robić, to co umie/robił (znowu młotek masłowa).
2. „No bo co PO czy klienta obchodzi, jaka biblioteka zostanie użyta? ”
a) No powinno obchodzić PO.. np. żeby móc zrealizować w przyszłości wizję, której cały DevT nie pozna (DevT nie jest w danej dziedzinie wyspecjalizowane i wszystkiego nie pozna – problem entropii) i nie wpaść w kanał niemożliwości technologicznej a obecnie często ma to miejsce (np. użycie Node.js albo html5, JS, technologii uniwersalnej/cross VM – .net java, wstawka w innej technologii np. python, itp.). To można powiedzieć są inne decyzje (w początkach), ale jednak.. w zróżnicowanych technologiach (co obserwuje się w topowych apkach komercyjnych stale – Adobe, MS, inne) jako moduły i komponenty panuje chaos (..a bo wykorzystaliśmy DevTeamNode, albo DevTeamPython).
W miarę przyrostu funkcji itp. te technologie sobie nie radzą, rośnie ew. wymaganie sprzętowe i obcina się dostęp do klientów. To jest przypadek, który obserwuję nonstop. Dev Team ma w nosie.. działa.. działa.. dostarczone? Dostarczone.. A w miarę złożeń, powstają komplikacje technologiczne (update, niekompatybilności, itd.)
Kwestia performance jest może skrajna. Ale przykłady z rozszerzeniami często się powtarzają. Często się mówi, że tak firmy tworzą własne standardy, itp. wyjaśnienia.. Wiele razy byłem zaskoczony informacją zwrotną, że po prostu tak coś wymyślono by zrobić krok dalej..
b) Dyskutujemy o konflikcie:
1) PO narzuca dla DEV
2) PO negocjuje z DEV
3) PO się nie wtrąca do DEV
Tylko balansowanie w absurdzie jest takie, że jeśli na takim etapie idziemy jak w pkt.3) to PO stwarza odrębne wymaganie i wychodzi na to samo. Czyli wchodzi się wtedy w precyzowanie (HLAC). Gra logik, ale istotna. Choć fakt z innego posta na blogu można by to wywnioskować. Ale kończy się w takich warunkach często przestrzeń techniczna i czasowa na kreatywność, autonomię, itp. a PO musi obchodzić „technologia”, „technikalia” itp. A nawyki są takie by się spotykać, dyskutować, a nie ma o czym.. a godziny są nabijane.
c) Czasem brakuje etyki w SoftwareHouse, a także u konsultantów. Ale te procesy .itd. potrafią usprawiedliwiać długi czas dostarczania produktów. Obserwowałem kilka dużych aplikacji i systemów, które powinny powstać w max 1-1.5 roku, a trwają 3-4. Tak.. przetargi, ale też zwykłe zlecenie do innej firmy wykonanie projektu lub rozwój produktu (rozwój powinien przypaść na 2 rok, a planuje się na 5).
d) Czemu to ciekawe? Bo jest przesadny nacisk na iteracje z metodyki, a nie w zakresie etapu wersji oprogramowania. Tuż obok stoi problem „przewidzieć wszystko”. Wg mnie i z obserwacji tam gdzie są user stories, tam są problemy, bo zwykle nie ma głębszych dyrektyw : )
3. Wracając do wątku 1.b), gdyby ktoś napotkał na taki problem, to uwaga – wg mnie trzeba odchodzić od INVEST i US na dyrektywy lub PS – problem/solution. A czy to już Agile, itd.?
Nie jestem wierny tym wszystkim manifestom. Zespoły są coraz większe, a klasyka zawodzi a ew. działa w początkach lub przy małych rzeczach, gdzie realnie nie potrzeba takich metodyk.
No krytyka musi być : )
Widziałem dobrych PO i dobre User Stories na projektach mocno technicznych, a nawet w zespołach scrumowych tworzących fizyczne urządzenia.
US to tylko narzędzie, które dobrze wykorzystywane – pomaga, źle wykorzystywane – przeszkadza.
Product Owner z kolei ma za zadanie przekazywać wizję o której mówisz, że „Dev Team nie pozna”. No skoro PO nie przekaże, to DevTeam nie będzie miał o niej bladego pojęcia. Jeżeli jedna osoba (PO) jest w stanie ogarnąć całość, to tę całość można też sprzedać zespołom tak, aby pracowały spójnie.
Jeśli DevTeam „ma w nosie”, to nie jest zmotywowany, nie rozumie na czym opierają się zwinne zespoły i tu następuje wymowne spojrzenie i na Scrum Mastera, i pośrednio na PO.
To nie jest tak, że na projektach zwinnych nie ma architekta, nie ma planowania długoterminowego i nie ma pracy w oparciu o wersje (release/wydania). Tu się nie biegnie ze Sprintu na Sprint dowożąc wymagania, które kupy się nie trzymają.
To nie jest tak, że na projektach zwinnych „nawyki są takie by się spotykać, dyskutować, a nie ma o czym.. a godziny są nabijane”. Zarówno timebox jak i „law of two feet” mówią właśnie, że nie marnujemy czasu bez sensu na spotkaniach.
To o czym piszesz, wygląda jak jakiś horror, gdzie ktoś znalazł trzy kartki wyrwane ze Scrum Guide oraz połowę Agile Manifesto i postanowił wdrożyć to w życie.
Z całym szacunkiem, ale moje doświadczenia z „polskim agilem” są zupełnie inne. I chociaż daleko jest do ideału, to nie wygląda to tak źle, jak opisujesz. Problemy są, ale w zupełnie innych miejscach. Same rezultaty i np. czas trwania projektów również są raczej po tej pozytywnej stronie. Cóż, chyba trafialiśmy po prostu na zupełnie inne firmy.
„No skoro PO nie przekaże, to DevTeam nie będzie miał o niej bladego pojęcia. Jeżeli jedna osoba (PO) jest w stanie ogarnąć całość, to tę całość można też sprzedać zespołom tak, aby pracowały spójnie.”
Nie da rady wg mnie.. są tematy gdzie PO mógł siedzieć 10,20,30 lat. To jest też tak, że SME może dużo za niego robić, ale.. to już inna sytuacja.
„Jeśli DevTeam “ma w nosie”, to nie jest zmotywowany..” no jest.. na kase : )
To jest stary problem wg mnie.. brać 100-200/h i zrobić w miesiąc, czy dogadać się z decydentami i robić 6 lub 12 mcy. Po 10 większych trudniejszych projektach wcale nie chce się więcej pracować, zwłaszcza jak są podobne („stary.. to tam część się skopiuje z tego co było”, .itp. argumenty na ścięcie kosztów).
„To o czym piszesz, wygląda jak jakiś horror, gdzie ktoś znalazł trzy kartki wyrwane ze Scrum Guide oraz połowę Agile Manifesto i postanowił wdrożyć to w życie.”
Hmm.. na serio.. osoby w przestrzeni z silnym PR w tematach, w top Polskich markach ; )
„Cóż, chyba trafialiśmy po prostu na zupełnie inne firmy.”
No może.. są i takie gdzie wszystko jest na zdrowo, ale rozglądnijmy się.. jaki jest rezultat powstaniach różnych produktów IT.
Jest problem.. taki, że na pewnym etapie przychodów jest machnięcie ręką na wszystko. Ale ciągle jest ten 2 medal rynku w PL w porównaniu np. do USA.. nieadekwatna motywacja, brak odpowiedniego modelu.
„Oglądam” i analizuję często outsorcingi oraz co leży/powstało w bazach. Akurat nie bardzo fizyczne urządzenia, bo to inna specyfika raczej.. pewnie warto by popytach Chińczyków od smartfonów i laptopów jak to robią : )
Od jakiegoś czasu obserwuję nowy trend polegający na zastępowaniu US poprzez Job Story (When…I want… so I can…). Czy jest jakiś polski odpowiednik nazwy Job Story? Co sądzicie o takim podejściu do zapisywania wymagań? Może jakiś wpis na blogu? 🙂
To jest zasadniczo to samo, zapisane w innej kolejności. Ale dzięki za inspirację do tekstu o różnych formatach US. 😉