test změny

Vytváření uživatelských příběhů

Proč v agilních a Scrum týmech píšeme uživatelské příběhy (User Story) a proč nestačí jen tasky s popisem co se má udělat? K čemu je, že se držíme formátu Jako Uživatel, chci Funkcionalitu abych dostal Business Value? Není to zbytečné pořád dokola opakovat slovíčka ‘Jako’, ‘chci’ a ‘abych’? Může se to tak zdát. Pojďme se na to ale podívat od začátku.

Uživatelský příběh vám říká nejen, co chcete dělat, ale i pro koho a hlavně proč. Uživatelský příběh má vytvářet obrázek, popisuje příběh. Lidský mozek vnímá obrázky a příběhy daleko snadněji než technický popis v bodech.

Zkuste si teď porovnat jeden příklad z praxe:

1. UP: „Kontaktní formulář“ (jaký jste si představili?) 2. UP: „Jako administrátor chci kontaktní formulář, abych se včas dozvěděl o chybách systému“.

Jsem si téměř jistá, že když jste to četli, šlo o dvě různé věci. Myslíte si, že je to z kontextu firmy a produktu jasné? Ne vždy. Většinou je to jasné pouze Product Ownerům, ti mají v hlavách obrázky, jak přesně se má systém chovat a jak má vypadat. Ti jsou součástí příběhu zákazníka, ale v uživatelských příbězích jde o to, aby ten obrázek, co mají v hlavě, sdělili ostatním tak, aby ho ani oni nikdy nezapomněli. A aby se i oni stali jeho součástí.

User Story by měla být

jednoznačně popsatelná,

vytvářet obrázek,

nezávislá,

přinášet hodnotu,

malá,

testovatelná.

Je-li uživatelský příběh příliš velký, je většinou těžké říct co je jejím obsahem a co už ne, a je tak pro tým neuchopitelná. A jak se pozná, že je User Story hotová? Od toho jsou tu akceptační kritéria. 1)https://soch.cz/blog/management/agile/proc-piseme-user-story/

Při vytváření a modifikaci služby musíte uživatelské příběhy. Jsou nutným základem pro budování a provozování služeb, které pokrývají potřeby uživatelů.

Ubezpečte se, že každý člen vašeho teamu píše uživatelské příběhy a používá je:

k popsání všeho, co je potřeba ve službě dělat

přemýšlet nad svojí práci z perspektivy uživatele

diskutovat o své práci s kolegy a odbornou veřejností

lépe stanovit své priority

naplnit digitalni_standardy_sluzeb a splnit potřeby bodu 1 pochopte_potreby_obcanu

Pro splnění potřeb bodu 4 pouzijte_agilni_metody musíte ukázat, jak jste adoptovali agilní metody a nástroje, včetně použití uživatelských příběhů.

Pro splnění bodu 5 rozvijejte_a_vylepsujte_sluzbu_prubezne musíte ukázat, jak jednotlivé uživatelské příběhy prioritizujete a jak je rychle a agilně přenášíte z etapy uživatelského průzkumu do produkce.

Jak psát uživatelské příběhy

Uživatelský příběh je takový způsob zadávání práce, kdy na konci vždy zůstane něco, co je pro někoho užitečné. Když budete psát uživatelské příběhy, čeká vás následující:2)http://www.knesl.com/navod-na-user-stories

Práci může (a měl by) schvalovat produkt manager.

Práce se dá nasadit do produkce (jde o konkretní věc).

K práci se nebudete muset vracet, takže vám zpětně nezasahuje do plánování.

Vše, co se dělá, vede k něčemu užitečnému

Proces prioritizace se točí kolem přinesené hodnoty uživateli

Vede k průběžnému refaktoringu

Co mají UP obsahovat

Každý uživatelských příběh by měl obsahovat dostatek informací pro produkt managera pro rozhodnutí, jak důležitý příběh je. Měl by vždy obsahovat:

osobu, která služby používá (účastník)

jaké jsou uživatelské potřeby od služby (příběh)

proč, k čemu je potřeba (cíl)

Obvyklý formát UP

Uživatelské příběhy jsou obvykle psány ve formátu:

Jako (kdo je uživatel?)…

Potřebuji/chci/očekávám (co chce uživatel dělat)…

Aby dosáhl (proč to chce uživatel udělat)

Příklad: (TBD)

Uživatelský příběh pro služby "registrace pro volby v zahraničí" Jako český občan jsem v době prezidenských voleb v zahraničí, proto se chci snadno zaregistrovat, abych mohl volit

Soustředte se na cíl

Nejdůležitější částí UP je cíl. Proto

se ujistěte, že řešíto skutečný problém uživatele

rozhodněte, kdy je příběh hotový a řeší uživatelskou potřebu

Pokud se vám nedaří UP napsat, zvažte, zda vůbec takovou funkcionalitu potřebujete.

Akceptační kritéria

Je vhodné, aby každý uživatelský příběh obsahoval i akceptanční kritéria. Akceptační kritéria tvoří seznam výsledků, který potvrzuje, že vaše služba vykonala svou práci a uspokojuje potřeby uživatele.

Často je psát formou "Je to hotovo, když …"

Příklady:

* 'Je to hotovo, když uživatel ví, jak se registrovat online'* 'Je to hotovo, když uživatel ví, kam poslat vyplněný formulář'* 'Je to hotovo, když uživatel ví, když uživatel zná výsledek žádosti'

Rozsáhlé uživatelské příběhy

Je-li uživatelský příběh příliš velký, je většinou těžké říct co je jejím obsahem a co už ne, a je tak pro tým neuchopitelná. Také se to pozná tak, že jeho vytvoření a otestování trvá několik týdnů. Pokud je to možné (a to skoro vždy je), rozdělte ho na menší části.

Kam uživatelské příběhy psát

Pište uživatelské příběhy na karty, a každou kartu vhodně pojmenujte. Karta může být např. :

skutečná karta nalepená na teamové zdi

digitální, uložená ve sdíleném Google Spreadsheet či agilním SW (Trello apod).

kombinace obou, dle priorit

Plánování

Když máte hodně uživatelských příběhů, můžete je evidovat v digitální formě, a překlápět je na fyzické karty podle priorit.

Pokud v rámci přípravy práce na uživatelkém příběhu probíhá hlubší diskuze mezi členy teamu, je dobré diskutované detaily uvést i v uživatelském příběhu.

Related guides You may also find these guides useful:

Agile methods: an introduction Agile tools and techniques

<references />