Jednou z největších výzev v oblasti vývoje softwaru, je téměř nemožný úkol shromažďování jasné požadavky, a pak se dostat na tyto požadavky zůstávají beze změny v průběhu kód rozvoj. V vodopádu přístup k vývoji software—navzdory snahám definovat, zdokumentovat a schválit všechny možné nepředvídané události před zahájením vývoje—vyexpedovaný výrobek je zřídka to, co zákazník chce.
agilní alternativa? Tvorba uživatelských příběhů.,
Jednou z největších výhod použití agilní přístup k vývoji softwaru je, že požadavky nejsou nastaveny v kameni, ale místo toho se očekává, že ke změně, s konstantní zpětnou vazbu od zúčastněných stran a podnikání. Agilní metodiky, jako je Scrum a extrémní programování (XP) nahradit tradiční, zdlouhavá požadavky na dokumenty s různou prioritu nevyřízených produktu tvoří stručné uživatelské příběhy, detaily, které se objeví blíže, když příběh je hotová.,
přestože tvorba uživatelských příběhů je více umění než věda, tento tutoriál vám poskytne informace, příklady a kroky, které budete potřebovat k vytvoření vysoce kvalitních uživatelských příběhů.
historie uživatelských příběhů
XP poprvé představila koncept uživatelských příběhů v roce 1998 a porovnala je s případy použití. V Object-Oriented Software Engineering: Use Case Driven Přístup, Ivar Jacobson představil případy použití jako způsob, jak dokumentovat požadavky tím, že definuje interakce mezi role (osoba, která používá systém) a systém sám o sobě k dosažení cíle pomocí Unified Modeling Language (UML).,
Tento přístup byl populární v objektově-orientovaný vývoj a je stále používán jako klíčový proces v oblasti vývoje softwaru rámců, jako je například Unified Process (UP), IBM Rational Unified Process (RUP), a Oracle Unified Method (OUM). Použití případů použití, spíše než uživatelských příběhů, umožňuje iterativní a inkrementální vývoj a je považován za agilní přístup k definici požadavků.,
se zavedením mnohem kratších uživatelských příběhů a popularitou XP a Scrum se produkt nevyřízený z uživatelských příběhů stal běžněji známým přístupem k definici agilních požadavků. Mnoho praktiků si stále myslí, že uživatelské příběhy jsou jediným přijatelným agilním přístupem. Alistair Cockburn, jeden ze signatářů agilního manifestu, však upřednostňuje případy použití před příběhy uživatelů.
ačkoli existuje spousta silných názorů na význam „agilní“, oba případy použití a uživatelské příběhy jsou s tímto přístupem kompatibilní., Někteří říkají, že uživatelské příběhy se nakonec podobají případům použití, jakmile tým souhlasí s podrobnostmi implementace. V raných fázích je příběh uživatele jednoduše krátkou větou, ale není úplný, dokud nejsou definovány podrobnosti a kritéria přijetí.
vytváření uživatelských příběhů
existují různé názory na definici uživatelského příběhu a na to, jak nejlépe vytvořit jeden., Některé pokyny pro dobrý příběh uživatele zahrnují následující:
- měla by být napsána někým, kdo představuje podnikové uživatele (obvykle vlastník produktu)
- původně měla zahrnovat stručné popisy „kdo, co, a proč,“ale ne „jak“
- mělo by To vytvořit vertikální plátek pracovní kód
- mělo by být dostatečně malé, že to může být kódován a testován v jedné iteraci (obvykle jedno-až čtyř-týdenní období)
Různé šablony, techniky a zkratky jsou použity na pomoc majitelé produktů napsat uživatelské příběhy., Tři z nejběžnějších technik jsou šablona role-feature-reason, tři C (karta, konverzace, potvrzení) a investujte (nezávislé, obchodovatelné, cenné, odhadovatelné, malé, testovatelné).
příklady
říkají, že vyvíjíte aplikaci, která by školitelům umožnila Nahrát kurz a přilákat studenty, kteří mají zájem o třídu. Zde je návod, jak byste použili techniky uživatelských příběhů.,
Role-Feature-Reason
jak vysvětluje Mike Cohn z Mountain Goat Software, šablona role-feature-reason nebo RGB (role, cíl, výhoda) vypadá takto:
„jako chci tak, aby .“
ačkoli existují variace, tato struktura krátkých vět udržuje zaměření na koho, co a proč. To brání vlastníkovi produktu v tom, aby vývojovému týmu poskytl příliš mnoho informací o tom, jak by měl implementovat řešení. Zaměřením na who, Co a proč je vývojový tým oprávněn najít nejlepší technické řešení.,
Příklad 1: poskytněte trenérovi možnost přidat kurz
jako trenér, chtěl bych být schopen přidat nový kurz, abych měl potenciál přilákat nové studenty.
příklad 2: Poskytněte studentovi možnost vyhledávat kurz
jako student bych chtěl být schopen vyhledávat nabídky kurzů, abych mohl najít nabídku, která mě nejvíce zajímá.
role (who)
role popisuje, kdo bude mít z této funkce prospěch. Všimněte si, že role není jen “ uživatel.,“Existují různé typy uživatelů, a proto chceme, aby role byla konkrétnější než „uživatel“, ale popište typ uživatele, který bude mít prospěch z příběhu. Majitelé produktů mají často za úkol dostat se do mysli svých uživatelů, aby pochopili, co by pro ně bylo nejcennější.
Příklad 1 Role = trenér
Příklad 2 Role = student,
funkce (co)
Tento krok velmi stručně popisuje, co uživatel chce. To nejvíce představuje požadavek, který popisujete v tradičním vývoji softwaru., Chcete však být opatrní, abyste nebyli příliš konkrétní nebo popsat, jak napsat kód. To bude nakonec určeno, ale ne při prvním vytvoření uživatelského příběhu. Příběh uživatele by měl být napsán z pohledu uživatele, který bude mít z této funkce prospěch, nikoli z pohledu vývojáře, který jej bude kódovat.
Example 1 Feature = add a new course
Example 2 Feature = search the course offerings
důvod (proč)
nakonec chceme uvést, proč uživatel tuto funkci chce. Jakou hodnotu z ní uživatel získá?, To pomáhá majiteli produktu vyhodnotit, jak upřednostnit příběh uživatele na nevyřízených. Pokud hodnotu nebo přínos nelze vyjádřit, může to být něco, co není nutné. Pochopení hodnoty často pomáhá vývojovému týmu najít inovativní způsoby implementace kódu za účelem vyřešení objektivních způsobů, které se mohou lišit od toho, co má na mysli vlastník produktu.,
Příklad 1 Důvod = přilákat nové studenty,
Příklad 2 Důvod = najít nabídku, která nejvíce mě zajímá
Tři C: Karty, Konverzace, Potvrzení
Tři C je vzorec, vyvinutý Ron Jeffries, pomáhá k dosažení dohody mezi obchodním a technickým týmem na význam uživatelský příběh. Tři C je vedou progresivním zpracováním příběhu, od krátkého prohlášení po plně vyvinutý uživatelský příběh.,
Karta
uživatel příběh začíná záměrně krátké, jednoduché prohlášení, které by se vešly na 3×5 index karty, obvykle v návaznosti na role-funkce-výhody formátu, který jsem právě na něž se vztahuje. Například:
jako trenér bych chtěl být schopen přidat nový kurz, abych měl potenciál přilákat nové studenty.
konverzace
přestože příběh uživatele začíná jako jednoduché prohlášení, musí se objevit podrobnosti, než tým začne pracovat na příběhu., Spíše než popisovat to, co je potřeba v dokumentaci, tým bude zahrnovat 1) zastoupení z podnikání (obvykle vlastník produktu), a 2) rozvoj týmu sám, včetně vývojářů, testerů, business analytiků, nebo někdo jiný v týmu.
tato Konverzace umožňuje vývojovému týmu klást otázky, aby zajistil, že bude mít jasné pochopení toho, o co se žádá, a poskytovanou hodnotu. Například:
vývojář: bude trenér muset nahrát kurzový software na web?,
majitel produktu: ne, trenér bude jen přidávat informace o kurzu, který bude nabízen, a tato funkce by měla obsahovat způsob, jak se student dostat na seznam zájmů. Tento příběh dává trenérovi možnost inzerovat kurz.
vývojář: jaká pole by měla být zahrnuta?
majitel produktu: název kurzu, abstrakt, data a časy, umístění.
vývojář: bude to pouze pro reklamní třídy tváří v tvář?
majitel produktu: Ano., Později můžeme přidat možnost virtuální třídy,ale tento příběh se bude týkat pouze přidávání informací o kurzu pro osobní nabídky.
vývojář: jaké informace by měly být shromážděny, když potenciální student požádá o získání seznamu zájmů?
vlastník produktu: jméno, telefonní číslo a e-mailová adresa.
tým aktualizuje příběh uživatele s informacemi, které shromáždil z konverzace, a budou diskutovat o implementaci—nebo „jak“—což často vytváří konkrétní úkoly, které je třeba provést, aby se příběh dokončil., Přestože je příběh uživatele napsán z pohledu uživatele, vývojový tým píše úkoly pro vývojáře a zahrnuje technické detaily implementace.
potvrzení
vývojový tým musí mít jasnou představu o tom, jak bude funkce fungovat v různých situacích, včetně chybových podmínek. Musí získat potvrzení o kritériích přijetí od vlastníka produktu. To jsou kritéria, která musí být splněna, aby byl příběh považován za hotový a přijatý., Zde je příklad přijetí kritéria:
- trenér je schopen přidat nový kurz zadáním název předmětu, abstraktní, data a časy a umístění do formuláře a stiskněte tlačítko „přidat kurz“ tlačítko.
- Pokud některá pole chybí nebo data nebo časy jsou neplatné, zobrazí se chybové zprávy.
- jakmile je kurz správně přidán, bude veřejně zobrazen na webových stránkách kurzu a bude k dispozici tlačítko pro vyjádření zájmu studenta.,
- zájem tlačítko umožní uživateli zadat jméno, e-mailovou adresu a telefonní číslo, a tyto údaje budou uloženy a spojeny s nový kurz.
INVEST: atributy solidního uživatelského příběhu
INVEST je zkratka, která pomáhá vyhodnotit, zda máte kvalitní uživatelský příběh. Zde je návod, jak se atributy v zkratce vztahují na příběh, na kterém jsme pracovali.
i = Independent-může být tento příběh dokončen týmem? Chceme, aby tým byl schopen dokončit celý příběh, spíše než být závislý na jiném týmu, který bude dělat GUI, například.,
N = obchodovatelné-příběh není tak podrobný, aby přesně popsal, jak dlouho by měla být pole, nebo poskytnout specifika o formátech data a podobně. S největší pravděpodobností budou existovat společné rutiny nebo knihovny, které umožní vývojovému týmu implementovat způsobem, který pro ně dává největší smysl.
V = cenné-majitel produktu popisuje, že hledaná hodnota je schopnost trenéra propagovat nadcházející třídy. To je jasné v“ Proč “ původního prohlášení a znovu zdůrazněno v rozhovoru.,
E = odhad-tým položí dostatek otázek a shromáždí podrobnosti, aby se cítil sebevědomě ve své schopnosti odhadnout příběh.
S = Small-tým si musí být jistý, že bude schopen dokončit příběh ve sprintu. Pokud tak neučiní, mohou rozdělit příběh. Například, v našem vzorovém příběhu, mohou se rozhodnout, že schopnost shromažďovat informace o studentovi bude jiným příběhem a jednoduše zobrazí informace o třídě pro tento příběh.
T = testovatelné – s jasnými kritérii pro přijetí lze testovat podmínky šťastné cesty i chyby.,
zarovnání s vizí
jsem se zabýval základy vytváření uživatelského příběhu, ale stále musíte pochopit velký obrázek před vytvořením vlastních uživatelských příběhů. Je tu hodně práce, kterou musíte udělat vpředu, na vyšší úrovni, určit, jaké funkce nejvyšší hodnoty jsou, které by měly být dodány zákazníkům. Ty jsou nakonec rozloženy do uživatelských příběhů.
je důležité, aby tým nejprve pochopil vizi na vysoké úrovni a ujistil se, že funkce a nakonec příběhy uživatelů odpovídají této vizi na vysoké úrovni.,
typicky rozdělíte produkt na seskupení, která jdou podle názvů jako „témata“ nebo „funkce“.“I když označování těchto nevyřízených položek se může lišit v závislosti na agilní metody a nástroje, které používáte k jejich popisu, myšlenka je, aby ujistěte se, že sladit tak, že práce lze vysledovat až do své vize, které zajistí, že jste splnění cílů a hodnot produktu vision.
znovu nezačínejte projekt vytvářením uživatelských příběhů; začněte vytvořením vize., Pro náš příklad jednoduše ukážu ukázkové prohlášení o vizi, které vede k některým ukázkovým funkcím, které lze dále rozložit do uživatelských příběhů.
Vision
poskytují vysoce kvalitní webové stránky, které umožní školitelům inzerovat kurzy a umožnit studentům absolvovat tyto kurzy.
funkce
- poskytují stránku nabízející kurz, která umožní studentům přihlásit se k kurzům.
- Poskytněte domovskou stránku, která uživatelům řekne, o čem jsou naše stránky.
- poskytuje registrační proces umožňující uživatelům přihlásit se, vytvořit profil a sledovat jejich třídy.,
- Poskytněte blog, který pomůže inzerovat naše nabídky a získat publicitu pro naše webové stránky.
uživatelské příběhy
- poskytněte trenérovi možnost přidat kurz na stránce nabídky kurzu.
- poskytují studentům možnost vyhledávat kurz.
ve výše uvedeném příkladu můžete vidět, jak vznikly uživatelské příběhy. Uživatelské příběhy byly součástí funkce „poskytnout stránku nabízející kurz“, která odpovídá vizi na vysoké úrovni.,
impact mapping
i když sladění s vizí vám pomůže naplnit počáteční nevyřízené účty, není to jediný způsob, jak to udělat. Existuje mnoho nástrojů a technik, která produkt manažeři mohou použít k vytvoření příběhy, které jdou v novém nevyřízených a který je v souladu s vizí.
Jeden strategické plánování technika používaná k pomoci pochopit velký obrázek, dopad mapování, byl propagován Gojko Adzic, autor Padesáti Rychlé Nápady, jak Zlepšit Své Uživatelské Příběhy a Dopad Mapování: velký dopad s softwarových produktů a projektů., Impact mapping je mapa mysli, která začíná cílem, který by měl řešit otázku hodnoty a proč jste budování produktu.
na další úrovni jsou uvedeny „herci“ nebo lidé, kteří pomohou dosáhnout cíle. Dále mapa uvádí chování nebo“ dopady“, které herci vykonají, aby pomohli dosáhnout tohoto cíle. Konečná úroveň mapy představuje „výstupy“, které může tým implementovat. Ty umožňují a podporují aktéry k vytvoření požadovaných dopadů. Z těchto výstupů odvodíte softwarové funkce a příběhy.,
- Cíl: Vytvořit široce dostupné kurzy, které studenti budou chtít
- Subjekty: Školitelé, studenti
- Dopady: sportovní Obuv bude poskytovat vysoce kvalitní kurzy, které jsou zajímavé pro studenty; studenti budou poskytovat doporučení a doporučení
- Výstupy: Vysoce kvalitní kurzy, které jsou přístupné pro studenty
- Potenciál příběhy:
- „Jako trenér, já chci inzerovat tříd, tak, že mohu získat studenty.
- “ jako trenér chci získat zpětnou vazbu od studentů, abych se mohl neustále zlepšovat.,“
- “ jako trenér chci zjistit, co studenti chtějí, abych mohl přidat do svých učebních osnov.“
- “ jako student chci najít třídy, které mě nejvíce zajímají.“
- “ jako student chci najít třídy, které jsem schopen vzít online, takže nebudu muset cestovat.“
- “ jako student chci číst recenze od ostatních, abych se mohl rozhodnout, které třídy mi budou nejlépe vyhovovat.“
mapování uživatelských příběhů tímto způsobem umožňuje sledovatelnost do myšlenkového procesu, jak příběhy nakonec vytvářejí hodnotu a jak je používáte k dosažení konečného cíle., Cílem není implementovat vše, ale najít nejkratší cestu přes mapu k dosažení vašeho cíle.
Rozdělení příběhy
Jedním z nejčastějších problémů, agilní týmy spustit do je, když příběhy jsou příliš velké a nelze provést v iteraci. Když tým vytváří úkoly spojené s příběhem, si uvědomí, že existuje příliš mnoho neznámých, nebo že úkoly, které bude trvat více času, než tým má k dispozici v jediné iteraci. Týmy to někdy řeší rozdělením většího příběhu na menší příběhy.,
Nezapomeňte však, že chcete, aby uživatelský příběh dodával pracovní software, který uživateli přidá hodnotu. Spíše než vytvoření uživatelského příběhu, který pouze částečně dokončí funkci, rozdělte příběhy na „vertikální řezy“, které dodají funkčnost typu end-to-end.
Obrátit společenství pro hlubší učení
Podrobné řešení, jak vyřešit nejtěžší problémy, které se týkají požadavků a uživatelské příběhy jsou jedinečné pro každou situaci. Nicméně, jeden společný rys úspěšných agilních praktiků je, že jsou dychtiví pomáhat druhým a sdílet to, co vědí.,
Cohn je userstories webové stránky umožňuje těm, kteří pracují s produkty backlogs a uživatelských příběhů sdílet produkty, zdroje a znalosti. Stránka produkty obsahuje působivý seznam nástrojů, mnoho k dispozici zdarma, s příležitostmi pro uživatelské recenze a vstup. Cohn na webu poznamenává, že doufá, že web rozšíří, aby bylo možné sdílet backlogy produktů.
nikdy nebude odpověď na to, jak psát perfektní uživatelské příběhy., Postupem času se však se zdravou kombinací zkušeností, radami odborníků a experimentováním s navrhovanými nástroji a technikami můžete neustále zlepšovat.