Uživatelské příběhy jsou jednoduché, ale velmi silné konstrukce: popisují kousky funkčnost z uživatelského pohledu, vyjádřený v pevném, kompaktním způsobem. Odrážejí to, co konkrétní třída uživatelů potřebuje a hodnotu, kterou je třeba získat. Formát je velmi jednoduchý a snadno použitelný. Existuje několik variant, včetně:
proč Uživatelské příběhy?
uživatelské příběhy poskytují vynikající způsob, jak definovat svůj produkt s jasností., Sadu dobře definovaných, priorit uživatelské příběhy mohou pomoci formulovat funkčnost vašeho produktu pomocí ‚zjednodušeně‘ — žádné formality a detaily implementace.
přístup „user story“ umožňuje smysluplné diskuse o produktech, a to jak v rámci týmu pro vývoj produktů, tak s externími zúčastněnými stranami.
správně napsané uživatelské příběhy poskytují pevný základ pro komunikaci a spolupráci — se zaměřením na to, na čem uživateli nejvíce záleží., Ve srovnání s jinými prostředky pro zachycení a dokumentování uživatelské požadavky a specifikace produktu, které mají přinejmenším tyto výhody:
- Uživatelské příběhy pomoci k dosažení cross-tým jasnosti na to, co stavět, pro koho, proč a kdy. Vzhledem k tomu, že je lze snadno definovat, porozumět a revidovat, mohou se stát standardním způsobem komunikace a shrnutí funkčnosti produktu jak technickými, tak netechnickými členy. Jsou velmi užitečné pro diskuse o rozsahu produktů nebo jako vstupní body pro technické hluboké ponory. Jsou klíčovými prvky agilního inženýrství.,
- uživatelské příběhy podporují účast netechnických členů. Moderní softwarové projekty jsou obvykle složité, zahrnující širokou škálu technologií, zkratky, a možnosti implementace. V mnoha případech není terminologie nebo technický jazyk běžně chápán-ani v rámci jednoho týmu-a tak do projektu zavádí „hluk“ a rizika. Uživatelské příběhy odstranit tento technický rozměr, takže každý člen týmu může přispět, jednoduše tím, že myslí „jako uživatel“., Tým může používat netechnický jazyk a efektivně spolupracovat při definování, zpochybňování nebo upřednostňování uživatelských příběhů. Dopad na spolupráci a dynamiku týmu může být významný.
- pomáhají při definování celého produktu – jako souboru pevných, moudře upřednostňovaných příběhů. Tým pro vývoj produktů může myslet na velké, definovat super-sadu uživatelských příběhů a poté přiřadit priority (které odrážejí očekávanou hodnotu pro uživatele, složitost, závislosti a další obchodní priority). Nemusíte dělat tvrdá rozhodnutí a označovat položky jako „mimo rozsah“., Místo toho můžete těmto „bláznivým“ nápadům přiřadit nižší prioritu a zároveň posunout uživatelské příběhy odrážející základní funkčnost vašeho produktu. Definování „řezaných čar“, které určují prostor pro každou iteraci, fázi nebo verzi, je pak otázkou dostupných zdrojů a rychlosti týmu.
psaní skvělých uživatelských příběhů
formát je přímočarý a psaní příběhů je snadné. Ale psaní těch skvělých může být trochu složité. Zde je několik pokynů, které je třeba zvážit:
uživatelské příběhy ≠ úkoly
uživatelské příběhy nejsou úkoly., Ve skutečnosti, jeden příběh může potřebovat stovky jednotlivých úkolů, které mají být úspěšně dodány. Úkoly jsou o implementaci; uživatelské příběhy jsou o definici.
při sestavování příběhů se zaměřte na zajištění jasnosti o vlastnostech produktu-co, ne jak.
zůstaňte na vysoké úrovni
musíte být na vysoké úrovni,ale také přesné a k bodu. Příběhy musí být jednoduché a pevné. To pomůže členům týmu a zúčastněným stranám hluboce porozumět potřebám uživatelů, a vyhnout se trávení času objasněním buzzwords, terminologie, a zkratky. Stačí použít jednoduchý a přesný jazyk.,
pochopte uživatele
musíte objevit a studovat skutečné uživatele vašeho produktu-zachytit jejich profily, pohledy, očekávání a související body bolesti.’Uživatelský výzkum a další techniky mohou vytvářet poznatky, které vám pomohou lépe porozumět uživatelům a jejich potřebám.
bez ohledu na techniky potřebujete sadu klíčových uživatelů-ideálně ve formě personas-než začnete sestavovat uživatelské příběhy.,
Přemýšlet jako uživatel
<jako zvláštní třídu user/ persona /role> část uživatelská příběh, definuje úhel pohledu — jak se konkrétní uživatel vnímá funkčnost shrnuty v příběh.
to má zásadní význam-vlastník produktu a celý tým musí myslet z pohledu uživatele a pochopit základní potřeby a očekávanou hodnotu.,
Think big
při popisu produktu jako nevyřízených uživatelských příběhů není dobrý důvod omezovat vaše myšlení rozpočtem, časem, proveditelností nebo náklady.
dobrou praxí je myslet na velké a nechat „bláznivé“ uživatelské příběhy zadat nevyřízené. Správní režii udržování rozšířený produktový backlog je malý, a hodnoty, které z něj vyplývají — z hlediska produktu jasnost, vize a příležitosti — je masivní.,
použijte eposy
eposy mohou mít podobu příběhů vyšší úrovně, které popisují velké části funkčnosti-obvykle vyžadují značné množství práce, napříč více sprinty. Dalším způsobem, jak myslet na eposy, jsou seskupení / kontejnery příbuzných, menších příběhů, které slouží společnému cíli. Eposy jsou dobré pro organizaci vašich příběhů a poskytování velkého obrazu.,
nechci zahodit — upřednostnit místo
Vzhledem k účinné stanovení priorit procesu, je dobré praxe, aby obohacení vašeho produktového backlogu s nové uživatelské příběhy, popisující nové uživatelské interakce scénáře, ‚náhodné myšlenky, nebo výstup z produktu inovační činnosti.
Chcete-li spravovat potenciální šum, musíte správně seskupit a upřednostnit nové položky. V každém případě, ne odfiltrovat/vyřazení položky z backlogu: de-scoped položky jsou obvykle zapomenuta, zatímco de-prioritní položky zůstanou zjistitelné a může se stát relevantní za správných podmínek.,
v závislosti na kontextu může být upřednostňování uživatelských příběhů složitým procesem. Musíte odhadnout hodnotu každého příběhu, pro uživatele a pro podnikání. Musíte velikost složitost, odhadnout proveditelnost a náklady / úsilí potřebné k vybudování a uvolnění funkce. Musíte identifikovat mezi závislostmi ve vašem nevyřízeném stavu-vynucování konkrétního uspořádání mezi určitými položkami.
nastavení pro úspěch-nejen přijetí
týmy často definují akceptační testy uživatelů a související akceptační kritéria. Přijetí však nestačí-musíte se připravit na úspěch., Jako produktový manažer potřebujete více než potvrzení, že „funguje tak, jak má „nebo“ podle specifikací.“
potřebujete metriky, které jsou také spojeny s přímou zpětnou vazbou uživatelů a zachycují, jak jsou vaši skuteční uživatelé šťastní a angažovaní. Zatímco přijetí je dobré pro kontrolu vývojového životního cyklu funkce, úspěch je asi střední / dlouhodobý dopad a hodnota vytvořená pro skutečné uživatele vašeho produktu. Musíte definovat oba-na produktové a / nebo epické a / nebo příběhové úrovni.
tag stories, přidat metadata
komplexní produkty vyžadují stovky uživatelských příběhů., Pro snadnější navigaci a správu musíte efektivně pojmenovat, kategorizovat a označit své příběhy. Po prvních několika revizích příběhu byste se měli vyhnout přejmenování nebo drastickému změně jeho popisu, protože by to mohlo v týmu způsobit zmatek a mezery.
správná správa metadat vašich příběhů-stav, pokrok, odkazy, priority, zdroje atd. – pomáhá prozkoumat, sledovat a pochopit vaše nevyřízené.
nelepte se na poznámky!,
Ano, zeď plnou barevné sticky notes vypadá nóbl a pomáhá váš tým se objeví rušné a produktivní :), Ale je třeba vážně systém a speciální nástroje, které vám pomohou správně řídit, obohatit, priority a sdílet příběhy.,
Ve zvláštních případech, jako je například brainstorming nebo myšlenky zasedání, to je v pořádku, aby zachytit první sadu uživatelských příběhů pomocí sticky notes—za předpokladu, že si pak dokument všechny z nich do správného produktu systému řízení. Pokud ne, a vy prostě udržet své příběhy na sticky notes, šance jsou, že vám bude chybět příležitosti, pokud jde o jasnost, inovace, efektivitu a spolupráci.,
stále potřebujete SPECIFIKACE
mít upřednostněnou sadu dobře definovaných uživatelských příběhů je skvělé, ale je to jen začátek. Tým musí analyzovat příběhy — z technického hlediska-a vytvořit potřebné technické artefakty.
v ideálním případě jsou příběhy mapovány na konkrétní dokumentaci, která poskytuje všechny technické detaily potřebné z hlediska softwarového inženýrství. Poskytují vstupní body pro podrobné dokumenty technické specifikace a další podrobné artefakty.,
Vizualizace pomáhá
vždy-na (digitální) vizualizace nejvyšší prioritou uživatelské příběhy podle kategorie, téma, nebo epic by mohlo být velmi užitečné pro spolupráci a sbližování mezi týmy a zúčastněnými stranami. Spolu se statistikami, problémy, blokátory a ukazateli pokroku může být mapa příběhu podávána prostřednictvím interaktivních obrazovek v prostoru spolupráce.
Uživatelské příběhy poskytují skvělý způsob, jak rychle a přesně popsat funkčnost softwarového produktu nebo systému., Oni jsou také velmi efektivní v zachytávání výstupů z brainstormingu, design sprinty, hackatony, a jiné inovace-led procesy — kde proud myšlenek musí být zachyceny v kompaktní, strukturovaným způsobem.