Ako písať svižné príbehy používateľov: 7 pokynov

Agilné príbehy používateľov sú v zásade krátke, jednoduché nástroje na dokumentovanie jednej akcie alebo zámeru, ktorý si cieľový užívateľ želá dosiahnuť cieľ. Najjednoduchšie príbehy používateľov majú formát: „Ako typ alebo rola používateľa, Chcem čin alebo zámertak že dôvod alebo výhoda”, Ktorá odpovedá na najmenej tri jednoduché otázky o tom, kto, čo a prečo je príbeh vo fronte nevybavených položiek.

Keď tímy dozrejú a organizácie budú agilné vo viacerých tímoch a iniciatívach, agilné príbehy používateľov často nadobúdajú oveľa viac definícií a štruktúr, aby sa zabezpečilo spoločné porozumenie zámeru a základných požiadaviek.

Začíname s písaním svižných používateľských príbehov

Existuje veľa zdrojov, ktoré vlastníkom nových produktov, obchodným analytikom, majstrom scrumov a technickým zákazníkom pomôžu porozumieť základom písania príbehov používateľov. Niektoré miesta, ktoré treba začať, zahŕňajú články z Atlassian, FreeCodeCamp, Agile Modeling a týchto 200 príkladov príbehov používateľov. Jeden z úplnejších zápisov je v najlepšom svižnom príbehu používateľa Alexandra Cowana. Existujú knihy o písaní príbehov, vrátane Mapovanie užívateľských príbehovpredkladajú Jeff Paton a Peter Economy a Aplikované užívateľské príbehyMike Cohn. Môžete tiež absolvovať kurzy písania príbehov od Udemy, Learning Tree, VersionOne a Lynda.

Jedným zo základných princípov, ktoré ako prvý zdieľa Bill Wake, je investujte do dobrých príbehov. Investznamená „nezávislý, obchodovateľný, hodnotný, odhadovateľný, malý a testovateľný“, čo predstavuje dobrý kontrolný zoznam pre agilných autorov príbehov. „Sprievodca agilným vodcom pri písaní používateľských príbehov“ je jeden článok, ktorý vysvetľuje, ako sa prihlásiť investovaťprincípy.

Základné informácie sú pomerne ľahké, napriek tomu často počujem a som svedkom rozporov medzi zainteresovanými stranami, vlastníkmi produktov, vývojármi a testermi, pokiaľ ide o kvalitu požiadaviek alebo to, či je príbeh skutočne hotový. Niekedy existujú protichodné stanoviská týkajúce sa úrovne požadovaných podrobností, miesta, kde je potrebné zapadnúť do technických požiadaviek, a toho, aké artefakty by sa mali vytvoriť s príbehmi používateľov.

S ohľadom na tieto otázky je tu sedem základných pokynov pre písanie svižných používateľských príbehov.

1. Píšte príbehy pre publikum, ktoré ich použije

Pred písaním príbehov nezabudnite, že príbehy majú ľudia, ktorí sa podieľajú na procese vývoja s rôznymi potrebami a zodpovednosťou, prečítať a porozumieť im. Autori a prispievatelia príbehov by mali mať na pamäti publikum a pripravovať príbehy, aby vyhoveli spoločným potrebám:

• Príbehy príbehov nemusia písať vlastníci produktu, najmä ak vaša organizácia deleguje túto funkciu na obchodných analytikov alebo ak sa na písaní príbehov podieľa viac ľudí. Vlastníci produktov sa chcú ubezpečiť, že príbeh úplne vystihuje potreby a úmysly používateľov. Mali by si prečítať podrobné akceptačné kritériá, ale nemusia si byť istí, že sú uviaznutí v detailoch technickej implementácie. Vlastníci produktov by tiež mali pochopiť, ako je príbeh zosúladený s väčším obrazom, takže sa musia aktívne zaujímať o to, ako sú definované eposy a vlastnosti a ako sú im príbehy priradené.
• Zainteresované strany nebudú čítať podrobnosti príbehu, ale budú skúmať eposy a prečítať si súhrn príbehu. Ak máte veľa zainteresovaných strán, zvážte použitie popisného formátu pre súhrny a presunutie položky „Ako typ alebo rola používateľa”Popis na začiatok popisu užívateľského príbehu.
• Technickí vedúci sú často prvou osobou v tíme, ktorá posudzuje príbehy, a preštudujú požiadavky, aby zistili, či je príbeh príliš veľký a mal by byť rozdelený do viacerých príbehov, alebo či si príbeh vyžaduje predbežnú technickú prácu na určenie toho najlepšieho. Riešenie.
• Postupník je osoba zodpovedná za kontrolu podrobností a správu o pokroku na každodenných samostatných stretnutiach. Postupníci by mali kontrolovať príbehy o závislostiach, ktoré sa môžu počas šprintu stať blokmi.
• Členovia tímu často kontrolujú všetky príbehy, aby pochopili svoje priradené príbehy v kontexte iných príbehov priradených k šprintu.
• Testéri určia, či existujú medzery alebo riziká, ktoré nie sú identifikované v kritériách prijatia, a potom zvážia, ako najlepšie ich implementovať v rámci automatizovaného testovania.
• Analytik tímu, ktorý môže byť programovým manažérom alebo členom kancelárie projektového riadenia, chce, aby boli príbehy úplne označené a kategorizované, aby bolo možné z nevybavených prípadov vyťažiť zmysluplné metriky.

2. Začnite s prihliadnutím na používateľa

Aj keď agilné príbehy používateľov môžu vyžadovať veľa podrobností, je veľmi dôležité mať na pamäti používateľa. Príbeh by mal byť určujúci čočinnosť alebo zámer, ktoré chce používateľ dosiahnuť, a prečoto rieši potrebu, základnú hodnotu alebo cieľ odvodený zo skúsenosti.

Pre zložitejšie aplikácie je definovanie rôznych personálnych skupín používateľov, ktoré ilustrujú potreby, hodnoty a vzorce používania rôznych typov používateľov, dôležitou disciplínou a môže vylepšiť písanie príbehov. V „10 tipoch na písanie dobrých používateľských príbehov“ navrhuje Roman Pichler, že „ciele osobnosti vám pomôžu nájsť tie správne príbehy. Položte si otázku, aké funkcie by mal produkt poskytovať, aby splnil ciele týchto osôb. “ Používanie osobností na posilnenie cieľov používateľov poskytuje bohatší význam pojmu prečopríbeh je dôležitý a pomáha uprednostniť nevybavené položky.

3. Odpovedzte, prečo je príbeh dôležitý

Pochopenie, zdokumentovanie a diskusia o potrebách používateľov alebo cieľoch persona používateľov je iba jednou dimenziou prečoproduktový vlastník uprednostňuje príbehy. Príbeh by mal poskytnúť aj obchodnú hodnotu, čo je ťažké kvantifikovať, ale môže byť kvalifikovateľnýna úrovni príbehu, funkcie, epiky alebo vydania.

Odpovedať prečomôžu byť dôležité pre vývojárov, keď majú oprávnenie navrhovať rôzne možnosti implementácie. Napríklad funkcia, ktorá zlepšuje prihlasovacie prostredie pre používateľov, môže byť pre podnik tiež prospešná, ak nová skúsenosť generuje aj lepšie údaje o zákazníkoch. Vývojár môže premýšľať o tejto pridanej obchodnej hodnote a optimalizovať implementáciu pre tento cieľ, aj keď kritériá prijatia príbehu nie sú o tejto požiadavke konkrétne.

4. Definujte kritériá prijatia bez predpisovania riešenia

Najdôležitejšou disciplínou, na ktorú sa treba sústrediť pri písaní príbehov, je príprava kritérií prijatia. Často ide o zoznamy krátkych výpisov typu pass-and-fail, ktoré dokumentujú požiadavky, obmedzenia, metriky a očakávania. Tieto kritériá prijatia sa často používajú niekoľkými spôsobmi:

• Technickí vedúci a tímy ich používajú na odhadovanie bodov príbehu na základe zložitosti a úsilia.
• Vývojári zúžia možnosti implementácie na také, ktoré vyhovujú kritériám prijatia.
• Vlastníci produktov môžu znížiť rozsah alebo zložitosť kritérií prijatia a dosiahnuť tak implementácie s nižšími odhadmi.
• Počas standupov postupník komunikuje s blokmi alebo problémami, ktoré spĺňajú náročné kritériá.
• Inžinieri zabezpečovania kvality používajú kritériá prijatia na vývoj automatizovaných testov.
• Produktový vlastník počas agilnej ukážky skontroluje kľúčové kritériá, aby sa ubezpečil, že príbeh je skutočný hotový.

Písanie kritérií prijatia nie je triviálne. Kritériá prijatia kritérií prijatia zdôrazňujú niektoré z problémov, ako je poskytnutie príliš veľa kritérií, definovanie príliš vágnych kritérií alebo dokumentácia zložitých kritérií, ktoré sa nedajú ľahko overiť. Niektorí autori používajú šablóny kritérií prijatia, ktoré definujú štruktúru pre krátke, atómové a testovateľné kritériá.

5. Pomocou príbehov definujte, čo a prečo; definovať úlohy, ako sa majú implementovať

Jednou z kritických chýb, ktorú tímy pri písaní príbehov vidia, je, že sú pri implementácii podrobné a konkrétne. Tieto zle napísané príbehy investujú veľa úsilia do opisu akoimplementovať často na úkor popisu čopoužívateľ potrebuje, prečozameriava sa na ich ciele a kdezvyšuje obchodnú hodnotu.

Môže sa to stať z niekoľkých dôvodov.

Neskúsení vlastníci produktov môžu pomocou príbehov vykresliť svoje implementačné vízie. Inými slovami, môžu namiesto zdieľania skúseností a výhod cieľového používateľa príliš špecifikovať používateľský dizajn a funkčné implementácie. Niektorí vlastníci produktov si mýlia svoju koncepciu toho, ako čo možnoprácu (proces, ktorým pochopia požiadavky) s tým, ako na to by malneúmyselne premenil interný príklad implementácie na externú špecifikáciu implementácie.

Ostatní vlastníci produktov môžu prekročiť svoje hranice tým, že požiadajú tím, „aby mi to postavili“. To je jedno z mojich 20 zlých správaní vlastníkov produktov, pre ktoré mám pre vlastníkov produktov odporúčanie týkajúce sa spolupráce s tímom riešení.

Ďalším dôvodom, prečo môžu byť príbehy preplnené detailmi implementácie, je to, že niektoré tímy a technickí vedúci pracovníci požadujú túto úroveň podrobností. Novo vytvorené technické tímy pracujúce na zdokonalení existujúcich aplikácií môžu vyžadovať túto úroveň detailov, kým lepšie pochopia, ako aplikácia funguje, a plne porozumieť potrebám používateľov. Niektoré distribuované tímy pracujúce s offshore vývojármi alebo nezávislými pracovníkmi môžu tiež chcieť zdokumentovať podrobnosti implementácie, aby zabezpečili, že títo členovia pochopia svoje zodpovednosti.

Najlepšie pre tieto tímy je vytvoriť prepojenie na implementačné diagramy a zdokumentovať, kto čo a ako robí, ako úlohy spojené s príbehom. Väčšina nástrojov na agilnú správu umožňuje úlohy alebo čiastkové úlohy a táto úroveň podrobností je zvyčajne oddelená od podstaty príbehu. Schéma v tomto príspevku odvádza dobrú prácu, ktorá ilustruje tento dôležitý princíp využívania svižných príbehov na členenie používateľských skúseností a obchodných procesov a pridávanie úloh na definovanie implementácie jednotlivých častí práce.

6. Označte svoje príbehy a podporte vylepšenia analytiky a praxe

Po napísaní, spracovaní a dokončení príbehov sa veľa tímov snaží zachytiť metriky a vykonať analýzy, ktoré môžu viesť k zlepšeniu procesov alebo sa používajú na vytváranie obchodných prípadov pre ďalšie investície.

Tu je niekoľko príkladov:

• Označte príbehy ako technický dlh, aby ste vyčíslili veľkosť dlhu, percento rýchlosti tímu použité na jeho riešenie a celkový dlh dokončený pri každom vydaní.
• Definujte funkčné a technické špičkové príbehy na podporu experimentovania a inovácie, potom podajte správu o tom, kde to má dopad na podnikanie.
• Ak váš tím odhaduje svižné používateľské príbehy, požiadajte tím, aby na konci šprintu označil príbehy, ktoré signalizujú, či sa nadhodnotili alebo podhodnotili, aby sa zlepšila presnosť odhadov.
• Použite štítky, komponenty a vlastné polia na uľahčenie vyhľadávania nevybavených položiek v prípade historických porozumení alebo metrík. Napríklad znalosť toho, aké príbehy ovplyvnili API alebo aké požiadavky viedli k posledným funkčným vylepšeniam v konkrétnej oblasti aplikácie, je možné urobiť, keď sú príbehy označené funkčnými a technickými komponentmi.
• Označením príbehov zhromažďujúcich alebo spracúvajúcich citlivé informácie, ako sú napríklad osobné identifikačné údaje (PII), transakcie elektronického obchodu alebo priemyselne regulované údaje, ako sú údaje HIPAA, umožníte kontrolu bezpečnosti a dodržiavania predpisov.
• Poskytnite spätnú väzbu vlastníkovi produktu a tímu. Okrem značenia príbehu hotový, produktový vlastník by mohol tiež poskytnúť tímu spätnú väzbu, napríklad potvrdiť a dobrá práca. Tím môže podobne poskytnúť spätnú väzbu vlastníkovi produktu o celkovej kvalite a interpretovateľnosti užívateľského príbehu.

7. Definujte svižné šablóny príbehov a sprievodcov štýlmi

Väčšie organizácie pracujúce s viacerými agilnými tímami a vlastníkmi produktov môžu chcieť pripraviť štandardy a príručky štýlov pre písanie príbehov. Konzistencia pomáha novým majiteľom produktov rýchlejšie sa učiť zručnosti písania a tiež zvyšuje efektivitu členov tímu pri konzumácii informácií.

Ďalším dôvodom na návrh šablón príbehov je, že rôzne typy produktov a aplikácií sa dajú použiť na rôzne výrazy a artefakty používateľských príbehov. Niekoľko príkladov:

• Príbehy obchodných procesov môžu vyžadovať odkazy na diagramy pracovných tokov a tiež uvádzať roly a oprávnenia.
• Príbehy aplikácií orientovaných na zákazníka by mali mať odkazy na drôtové rámce a mali by obsahovať výkonnostné kritériá.
• Príbehy API by mali dokumentovať očakávané vzorce používania a metriky.
• Príbehy business intelligence a vizualizácie údajov by mali poskytovať pokyny týkajúce sa oblastí a informácií potrebných pre požadovanú analýzu.

Šablóny pomáhajú preklenúť komunikáciu medzi tímami a vlastníkmi produktov, na čo sa treba zamerať pri písaní svižných príbehov.

A nie je to bodom svižných príbehov? Agilné postupy, pokyny a princípy písania príbehov sú tu preto, aby pomohli tímom vedieť, čo je dôležité pre používateľov a pre podnikanie skôr, ako zvážia, ako ich implementovať.