254
editací
Změny
Založena nová stránka s textem „= 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…“
= 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. <ref>[https://soch.cz/blog/management/agile/proc-piseme-user-story/]</ref>
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 [[Digitální standardy služeb]] a splnit potřeby bodu 1 [[Pochopte potřeby občanů]]
Pro splnění potřeb bodu 4 [[Použijte agilní 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 [[Rozvíjejte a vylepšujte službu průběžně]] 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ý Průzkum|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í:<ref>[http://www.knesl.com/navod-na-user-stories]</ref>
* 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ž ...'''"
{{Quotation|Příklad:
* '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:
[https://www.gov.uk/service-manual/agile-delivery/agile-methodologies Agile methods: an introduction]
[https://www.gov.uk/service-manual/agile-delivery/agile-tools-techniques Agile tools and techniques]
<references />
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. <ref>[https://soch.cz/blog/management/agile/proc-piseme-user-story/]</ref>
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 [[Digitální standardy služeb]] a splnit potřeby bodu 1 [[Pochopte potřeby občanů]]
Pro splnění potřeb bodu 4 [[Použijte agilní 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 [[Rozvíjejte a vylepšujte službu průběžně]] 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ý Průzkum|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í:<ref>[http://www.knesl.com/navod-na-user-stories]</ref>
* 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ž ...'''"
{{Quotation|Příklad:
* '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:
[https://www.gov.uk/service-manual/agile-delivery/agile-methodologies Agile methods: an introduction]
[https://www.gov.uk/service-manual/agile-delivery/agile-tools-techniques Agile tools and techniques]
<references />