Michal v 16. 7. 2018, 13:37

2018-07-16T13:37:44Z

Michal: /* Akceptační kritéria */

2018-07-11T11:33:10Z

‎Akceptační kritéria

Michal v 11. 7. 2018, 11:32

2018-07-11T11:32:02Z

Michal: /* Akceptační kritéria */

2018-07-11T11:28:28Z

‎Akceptační kritéria

Michal: 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…“

2018-07-11T11:27:39Z

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…“

Nová stránka

= 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 />

← Starší verze		Verze z 16. 7. 2018, 13:37
Řádek 1:		Řádek 1:
		+	[[Agilní přístup\|Část sekce Agilní přístup]]
		+
	= Vytváření uživatelských příběhů =		= Vytváření uživatelských příběhů =

@@ Řádek 82: / Řádek 82: @@
 Příklady:
-*: 'Je to hotovo, když uživatel ví, jak se registrovat online'
+* '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í, kam poslat vyplněný formulář'
-*: 'Je to hotovo, když uživatel ví, když uživatel zná výsledek žádosti'
+* 'Je to hotovo, když uživatel ví, když uživatel zná výsledek žádosti'
 ====Rozsáhlé uživatelské příběhy ====

@@ Řádek 82: / Řádek 82: @@
 Příklady:
-: * 'Je to hotovo, když uživatel ví, jak se registrovat online'
+*: '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í, kam poslat vyplněný formulář'
-: * 'Je to hotovo, když uživatel ví, když uživatel zná výsledek žádosti'
+*: 'Je to hotovo, když uživatel ví, když uživatel zná výsledek žádosti'
 ====Rozsáhlé uživatelské příběhy ====

Uživatelské příběhy - Historie editací

Michal v 16. 7. 2018, 13:37

Michal: /* Akceptační kritéria */

Michal v 11. 7. 2018, 11:32

Michal: /* Akceptační kritéria */

Michal: 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…“