254
editací
Změny
Založena nová stránka s textem „Část sekce Agilní přístup =Jak funguje fáze alfa provozu služby= Fáze alfa je vývojová fáze, která přichází po fázi…“
[[Agilní přístup|Část sekce Agilní přístup]]
=Jak funguje fáze alfa provozu služby=
Fáze alfa je vývojová fáze, která přichází po fázi objevování/zjišťování.
Ve fázi alfa potřebujete:
* vybudovat prototypy služby
* otestovat prototypy služby s uživateli
* prokázat, že vytvořit plánovanou službu je technicky možné
Ve fázi alfa byste měli využít zkušenosti s budováním prototypů, abyste:
* odhalili problémy v návrhu vaší služby a rozhodli, jak je budete řešit
* udělali odhad, kolik bude služba stát peněz
* co možná nejdříve určili největší rizika pro další fázi beta
Na konci fáze alfa byste měli vědět:
* zda je možno se přesunout do fáze beta
* co potřebujete vytvořit ve fázi, pokud se přesouváte do fáze beta.
== Tým ve fázi alfa ==
Zjištěte jak [[Sestavení teamu pro fáze projektu|postavit projektový tým pro jednotlivé fáze]]
== Jak by tým měl pracovat ==
Váš tým by měl [[Agilní přístup|pracovat agilním způsobem]], rychle iterovat, abyste se mohli rychle učit.
== Etapy úspěšné fáze alfa ==
Každá fáze alfa bude jiná, protože rizika a cíle pro každou službu jsou rozdílné.
Většinou fáze alfa trvá 8 týdnů a dělí se na tyto tři etapy:
# Začátek: postavení týmu k vytyčení cílů
# Iterace: vytvoření prototypů služby, otestování, poučení, změny a nové testování
# Závěr: přesun do fáze beta nebo k ukončení projektu
== Začátek ==
V úvodní etapě potřebujete udělat následující kroky, což bude trvat pár dní:
# Dát dohromady tým
# Stanovit cíle vašeho projektu
# Identifikovat největší rizika
=== Dát dohromady tým ===
Během úvodní etapy můžete plánovat setkání, abyste zajistili, že tým
* se navzájem pozná a stmelí
* vytváří týmové chápání projektu
Můžete týmu představit [[Standard digitální služby|18 standardů digitální služby]], pokud je neznají a agilní způsob práce.
=== Stanovit cíle ===
Musíte s týmem zjistit, jaké jsou vaše cíle ve fázi alfa.
Mohou to být například následující cíle:
* vytvořit novou digitální službu
* vytvořit službu, která bude vyhovovat potřebám uživatelů
* prokázat, že můžete uspokojit potřeby uživatelů, které v současné době naplňuje služba soukromého sektoru, kvůli selhání služby veřejného sektoru.
=== Identifikovat největší rizika ===
Důvodem pro spuštění fáze alfa je, co nejdříve identifikovat všechna rizika projektu.
Během počátku byste se měli pokusit identifikovat největší rizika a lépe jim porozumět.
=== Druhy rizik ===
U většiny projektů veřejné správy spadají rizika do tří kategorií:
* design
* obchodní proces
* technická rizika
=== Rizika spojená s designem ===
Designová rizika jsou veškeré problémy spojené s designem zaměřeným na uživatele identifikovaná v rámci modelu iterace (opakované testování).
Často je zapotřebí více pokusů, než se zjistí, jaký rozsah je pro vaše uživatele správný.
Musíte zvážit
* jak jednoduché je použití služby
* zda uživatel zvládne projít napoprvé
* jak vypadají chyby
* jak budete analyzovat v rámci uživatelského průzkumu
* jak rychle postavíte prototypy služby
=== Rizika spojená s obchodním procesem ===
Tato rizika zahrnují:
* jak bude váš odbor integrovat vaši novou službu
* zda váš odbor provádí kontrolu podvodů
* zda váš odbor disponuje telefonickou podporou
* jak provozovat službu a kdo je zodpovědný, pokud služba “spadne” a podpora je mimo provoz
=== Technická rizika ===
Technická rizika se obvykle týkají integrace do stávajících systémů, například:
* druh probíhajícího spojení, které je nezbytné pro propojení vaší služby s existujícími systémy
* jakékoliv speciální hostování, například hosting s vysokou úrovní zabezpečení
=== Co musíte udělat na konci počáteční etapy ===
Každá služba je jiná, ale na konci počáteční fáze by váš tým měl mít následující:
* znalosti o službě, co má splňovat a pro koho je určena
* písemný popis lidí, kteří budou službu využívat, tzv. “user personas”
* dobrou znalost toho, co pro uživatele již existuje
* dobré pochopení toho, jak splnit [[požadavky na přístupnost]].
* jasné nastavení cílů a rizik
* představu o vizi vašeho projektu a jak bude vypadat, až bude hotov
* jasné pochopení toho, jak bude služba integrována nebo napojena do starších systémů
* prioritizovaný seznam prací pro vaši první iteraci
=== Předvedení (ukázka) a retrospektiva (ohlédnutí) ===
Měli byste projektovému týmu a zúčastněným stranám předvést, co jste se naučili (projektové radě nebo týmu seniorních manažerů) .
Také byste měli uspořádat [[Nástroje a techniky agilního řízení#Retrospektivn.C3.AD_setk.C3.A1n.C3.AD|retrospektivní setkání]] na konci počáteční etapy.
== Iterace ==
Ve fázi alfa nebudete schopni vybrat jednu cestu pro uživatele nebo jeden design. Budete muset postavit a otestovat více prototypů.
To vám umožní rychle zjistit, který design nabízí nejlepší možnosti pro uživatele. Váš první návrh může mít problémy – pokračujte v revizi návrhů, průzkumu a testování postupů a vylepšujte.
[[uživatelský průzkum ve fázi alfa|Více informací o uživatelském průzkumu ve fázi alfa]].
=== Příklad časového rozvrhu u iterace ===
Den 1:
* retrospektivní setkání (1 hodina)
* plánování iterace (2 hodiny)
* start iterace
Den 2:
* uživatelský průzkum na prototypech předchozích iterací
* analýzy výsledků testování
Day 5:
* demo
Od tohoto rozvrhu se můžete odchýlit, ale měli byste uskutečnit uživatelský průzkum co nejdříve v etapě iterace, abyste měli dostatek času do další iterace. To vám umožní rychlý obrat uživatelských příběhů / scénářů.
Práce tímto tempem bude mít za následek:
* uživatelský průzkum v iteraci 1
* dokončení příběhu/scénáře v iteraci 2
* další průzkum na aktuálních prototypech v iteraci 3
Chcete-li pracovat tímto způsobem, potřebujete velmi dobře vyvinuté prototypy. Ty mohou mít back-end systémy, které vymodelují integraci služby, ale obsahují skutečnou logiku práce.
Pokud potřebujete iterovat rychleji, můžete začít s mnohem menší přesností / výstižností prototypů (jak papír).
To vám umožní testovat různé toky a rychleji opakovat průzkum a vývoj prototypu.
Opakujte (provádějte iterace) dokud:
* neprokážete, že prototyp splňuje požadavky uživatelů a není možno se posunout dál
* neprokážete, že nerozumíte problémům prototypu, kvůli kterým zrušíte projekt a vrátíte se do fáze předchozí objevování.
=== Na konci každé iterace ===
Na konci každé iterace musíte předvést kroky služby tak, abyste ukázali, co se tým při iteracích naučil a co plánuje dělat dál.
Měli byste se vyvarovat nastavení iterací ve dnech od pondělí do pátku, protože v těchto dnech chybí více lidí.
== Závěr ==
=== Rozhodnutí o tom, že fáze alfa skončila ===
Na konci fáze alfa byste měli mít:
* příběhy uživatelů /uživatelské scénáře, které souvisejí s celou cestou uživatele spíše než podle jednotlivých funkcionalit
* plán prací pro fázi beta a méně podrobně i plán pro ostrou fázi
* nastavit [[Využití dat k zlepšování služby|měření úspěšnosti služby]]
* základní pracovní systém s omezenou funkčností, který se dá předvést uživatelům
* znalost starších systémů, které je třeba vyměnit nebo integrovat
* rozhodnutí o tom, zda pokročit do fáze beta
* znalost toho, jak navrhnout přístupnou službu
* analýzy průzkumu potřeb uživatelů, který jste udělali
* nápady, jak navrhnete model asistované digitální podpory pro vaši službu
== Jak by měl vypadat prototyp služby ==
Prototyp z fáze alfa má umožnit kompletní end-to-end transakci.
Měli byste na to myslet jako na prokázání konceptu a použít toho ke kontrole, že:
* máte správné řešení, které naplní potřeby uživatelů
* váš přístup je životaschopný a ekonomicky efektivní
* technologie k implementaci vašeho plánu existují
* jsou věci, které se nedají snadno změnit, a přesto budete pokračovat
* znáte potřeby vašich uživatelů natolik, abyste je mohli změnit.
Pokud ne, zjišťujte dále a udělejte nový prototyp služby.
=== Přechod do fáze beta ===
Váš tým musí být přesvědčen, že nenavrhujete projekt, který nebude fungovat ve fázi beta. Ujistěte se, že vaše časové lhůty, rozsah a vaše vize jsou správné v souladu s penězi a lidmi, které máte na další fázi.
Poté, co se přesvědčíte, že se chcete přesunout do fáze beta, manažer poskytování služby a vlastník služby by měl začít pracovat na obchodním návrh pro fázi beta ještě včas ve fázi alfa.
Začnete-li včas pracovat na návrhu programu beta fáze, váš tým bude pokračovat dynamicky a poskytne vám čas na další schválení kontroly výdajů.
Měli byste mít finální demo z fáze alfa a ujistit se, že vedení projektu se může předvedení alfa demo (prototypu) zúčastnit.
Použijte demo ukázku k předvedení toho, co jste dosáhli ve fázi alfa a vysvětlení dalších vizí pro fázi beta.
Měli byste mít finální retrospektivu a vytvořit zásobu (backlog) uživatelských scénářů pro fázi beta.
[[Uživatelské příběhy |Zjistěte více o psaní příběhů / uživatelských scénářů]].
=== Rozhodnutí nepokračovat do fáze beta ===
Můžete také fázi alfa využít k rozhodnutí ukončit projekt raději než pokračovat s fází beta.
Můžete zjistit například:
* potřeby uživatelů již naplňuje jiná služba veřejné správy nebo soukromý sektor
* náklady na vybudování služby jsou příliš vysoké v závislosti na tom, kolik uživatelů ji využije
* nedigitální řešení je lepší
* přizpůsobení nebo vývoj jiné služby je lepší řešení.
Jedná se pořád o úspěšnou fázi alfa, i když se rozhodnete, že pokračování ve fázi beta by znamenalo plýtvání časem i penězi.
=== Rozhodnutí o nové fázi alfa ===
Na konci fáze alfa se můžete také rozhodnout, že začnete znovu s fází alfa nebo “objevování”, protože se třeba chcete zaměřit na jiné věci.
Například, můžete identifikovat potřebu uživatelů ve fázi objevování a alfa a potom objevíte prostřednictvím dalšího průzkumu jinou potřebu uživatelů.
== Související příručky: ==
Může se vám hodit:
* [[Objevovací fáze služby | Jak funguje objevovací fáze službyeditovat]]
* [[Fáze beta provozu služby|Jak funguje fáze beta]]
* [[Fáze spuštění služby|Jak funguje ostrá verze]]
* [[Fáze ukončení služby|Dosloužení služby]]
====Zdroje====
https://www.gov.uk/service-manual/agile-delivery/how-the-alpha-phase-works
=Jak funguje fáze alfa provozu služby=
Fáze alfa je vývojová fáze, která přichází po fázi objevování/zjišťování.
Ve fázi alfa potřebujete:
* vybudovat prototypy služby
* otestovat prototypy služby s uživateli
* prokázat, že vytvořit plánovanou službu je technicky možné
Ve fázi alfa byste měli využít zkušenosti s budováním prototypů, abyste:
* odhalili problémy v návrhu vaší služby a rozhodli, jak je budete řešit
* udělali odhad, kolik bude služba stát peněz
* co možná nejdříve určili největší rizika pro další fázi beta
Na konci fáze alfa byste měli vědět:
* zda je možno se přesunout do fáze beta
* co potřebujete vytvořit ve fázi, pokud se přesouváte do fáze beta.
== Tým ve fázi alfa ==
Zjištěte jak [[Sestavení teamu pro fáze projektu|postavit projektový tým pro jednotlivé fáze]]
== Jak by tým měl pracovat ==
Váš tým by měl [[Agilní přístup|pracovat agilním způsobem]], rychle iterovat, abyste se mohli rychle učit.
== Etapy úspěšné fáze alfa ==
Každá fáze alfa bude jiná, protože rizika a cíle pro každou službu jsou rozdílné.
Většinou fáze alfa trvá 8 týdnů a dělí se na tyto tři etapy:
# Začátek: postavení týmu k vytyčení cílů
# Iterace: vytvoření prototypů služby, otestování, poučení, změny a nové testování
# Závěr: přesun do fáze beta nebo k ukončení projektu
== Začátek ==
V úvodní etapě potřebujete udělat následující kroky, což bude trvat pár dní:
# Dát dohromady tým
# Stanovit cíle vašeho projektu
# Identifikovat největší rizika
=== Dát dohromady tým ===
Během úvodní etapy můžete plánovat setkání, abyste zajistili, že tým
* se navzájem pozná a stmelí
* vytváří týmové chápání projektu
Můžete týmu představit [[Standard digitální služby|18 standardů digitální služby]], pokud je neznají a agilní způsob práce.
=== Stanovit cíle ===
Musíte s týmem zjistit, jaké jsou vaše cíle ve fázi alfa.
Mohou to být například následující cíle:
* vytvořit novou digitální službu
* vytvořit službu, která bude vyhovovat potřebám uživatelů
* prokázat, že můžete uspokojit potřeby uživatelů, které v současné době naplňuje služba soukromého sektoru, kvůli selhání služby veřejného sektoru.
=== Identifikovat největší rizika ===
Důvodem pro spuštění fáze alfa je, co nejdříve identifikovat všechna rizika projektu.
Během počátku byste se měli pokusit identifikovat největší rizika a lépe jim porozumět.
=== Druhy rizik ===
U většiny projektů veřejné správy spadají rizika do tří kategorií:
* design
* obchodní proces
* technická rizika
=== Rizika spojená s designem ===
Designová rizika jsou veškeré problémy spojené s designem zaměřeným na uživatele identifikovaná v rámci modelu iterace (opakované testování).
Často je zapotřebí více pokusů, než se zjistí, jaký rozsah je pro vaše uživatele správný.
Musíte zvážit
* jak jednoduché je použití služby
* zda uživatel zvládne projít napoprvé
* jak vypadají chyby
* jak budete analyzovat v rámci uživatelského průzkumu
* jak rychle postavíte prototypy služby
=== Rizika spojená s obchodním procesem ===
Tato rizika zahrnují:
* jak bude váš odbor integrovat vaši novou službu
* zda váš odbor provádí kontrolu podvodů
* zda váš odbor disponuje telefonickou podporou
* jak provozovat službu a kdo je zodpovědný, pokud služba “spadne” a podpora je mimo provoz
=== Technická rizika ===
Technická rizika se obvykle týkají integrace do stávajících systémů, například:
* druh probíhajícího spojení, které je nezbytné pro propojení vaší služby s existujícími systémy
* jakékoliv speciální hostování, například hosting s vysokou úrovní zabezpečení
=== Co musíte udělat na konci počáteční etapy ===
Každá služba je jiná, ale na konci počáteční fáze by váš tým měl mít následující:
* znalosti o službě, co má splňovat a pro koho je určena
* písemný popis lidí, kteří budou službu využívat, tzv. “user personas”
* dobrou znalost toho, co pro uživatele již existuje
* dobré pochopení toho, jak splnit [[požadavky na přístupnost]].
* jasné nastavení cílů a rizik
* představu o vizi vašeho projektu a jak bude vypadat, až bude hotov
* jasné pochopení toho, jak bude služba integrována nebo napojena do starších systémů
* prioritizovaný seznam prací pro vaši první iteraci
=== Předvedení (ukázka) a retrospektiva (ohlédnutí) ===
Měli byste projektovému týmu a zúčastněným stranám předvést, co jste se naučili (projektové radě nebo týmu seniorních manažerů) .
Také byste měli uspořádat [[Nástroje a techniky agilního řízení#Retrospektivn.C3.AD_setk.C3.A1n.C3.AD|retrospektivní setkání]] na konci počáteční etapy.
== Iterace ==
Ve fázi alfa nebudete schopni vybrat jednu cestu pro uživatele nebo jeden design. Budete muset postavit a otestovat více prototypů.
To vám umožní rychle zjistit, který design nabízí nejlepší možnosti pro uživatele. Váš první návrh může mít problémy – pokračujte v revizi návrhů, průzkumu a testování postupů a vylepšujte.
[[uživatelský průzkum ve fázi alfa|Více informací o uživatelském průzkumu ve fázi alfa]].
=== Příklad časového rozvrhu u iterace ===
Den 1:
* retrospektivní setkání (1 hodina)
* plánování iterace (2 hodiny)
* start iterace
Den 2:
* uživatelský průzkum na prototypech předchozích iterací
* analýzy výsledků testování
Day 5:
* demo
Od tohoto rozvrhu se můžete odchýlit, ale měli byste uskutečnit uživatelský průzkum co nejdříve v etapě iterace, abyste měli dostatek času do další iterace. To vám umožní rychlý obrat uživatelských příběhů / scénářů.
Práce tímto tempem bude mít za následek:
* uživatelský průzkum v iteraci 1
* dokončení příběhu/scénáře v iteraci 2
* další průzkum na aktuálních prototypech v iteraci 3
Chcete-li pracovat tímto způsobem, potřebujete velmi dobře vyvinuté prototypy. Ty mohou mít back-end systémy, které vymodelují integraci služby, ale obsahují skutečnou logiku práce.
Pokud potřebujete iterovat rychleji, můžete začít s mnohem menší přesností / výstižností prototypů (jak papír).
To vám umožní testovat různé toky a rychleji opakovat průzkum a vývoj prototypu.
Opakujte (provádějte iterace) dokud:
* neprokážete, že prototyp splňuje požadavky uživatelů a není možno se posunout dál
* neprokážete, že nerozumíte problémům prototypu, kvůli kterým zrušíte projekt a vrátíte se do fáze předchozí objevování.
=== Na konci každé iterace ===
Na konci každé iterace musíte předvést kroky služby tak, abyste ukázali, co se tým při iteracích naučil a co plánuje dělat dál.
Měli byste se vyvarovat nastavení iterací ve dnech od pondělí do pátku, protože v těchto dnech chybí více lidí.
== Závěr ==
=== Rozhodnutí o tom, že fáze alfa skončila ===
Na konci fáze alfa byste měli mít:
* příběhy uživatelů /uživatelské scénáře, které souvisejí s celou cestou uživatele spíše než podle jednotlivých funkcionalit
* plán prací pro fázi beta a méně podrobně i plán pro ostrou fázi
* nastavit [[Využití dat k zlepšování služby|měření úspěšnosti služby]]
* základní pracovní systém s omezenou funkčností, který se dá předvést uživatelům
* znalost starších systémů, které je třeba vyměnit nebo integrovat
* rozhodnutí o tom, zda pokročit do fáze beta
* znalost toho, jak navrhnout přístupnou službu
* analýzy průzkumu potřeb uživatelů, který jste udělali
* nápady, jak navrhnete model asistované digitální podpory pro vaši službu
== Jak by měl vypadat prototyp služby ==
Prototyp z fáze alfa má umožnit kompletní end-to-end transakci.
Měli byste na to myslet jako na prokázání konceptu a použít toho ke kontrole, že:
* máte správné řešení, které naplní potřeby uživatelů
* váš přístup je životaschopný a ekonomicky efektivní
* technologie k implementaci vašeho plánu existují
* jsou věci, které se nedají snadno změnit, a přesto budete pokračovat
* znáte potřeby vašich uživatelů natolik, abyste je mohli změnit.
Pokud ne, zjišťujte dále a udělejte nový prototyp služby.
=== Přechod do fáze beta ===
Váš tým musí být přesvědčen, že nenavrhujete projekt, který nebude fungovat ve fázi beta. Ujistěte se, že vaše časové lhůty, rozsah a vaše vize jsou správné v souladu s penězi a lidmi, které máte na další fázi.
Poté, co se přesvědčíte, že se chcete přesunout do fáze beta, manažer poskytování služby a vlastník služby by měl začít pracovat na obchodním návrh pro fázi beta ještě včas ve fázi alfa.
Začnete-li včas pracovat na návrhu programu beta fáze, váš tým bude pokračovat dynamicky a poskytne vám čas na další schválení kontroly výdajů.
Měli byste mít finální demo z fáze alfa a ujistit se, že vedení projektu se může předvedení alfa demo (prototypu) zúčastnit.
Použijte demo ukázku k předvedení toho, co jste dosáhli ve fázi alfa a vysvětlení dalších vizí pro fázi beta.
Měli byste mít finální retrospektivu a vytvořit zásobu (backlog) uživatelských scénářů pro fázi beta.
[[Uživatelské příběhy |Zjistěte více o psaní příběhů / uživatelských scénářů]].
=== Rozhodnutí nepokračovat do fáze beta ===
Můžete také fázi alfa využít k rozhodnutí ukončit projekt raději než pokračovat s fází beta.
Můžete zjistit například:
* potřeby uživatelů již naplňuje jiná služba veřejné správy nebo soukromý sektor
* náklady na vybudování služby jsou příliš vysoké v závislosti na tom, kolik uživatelů ji využije
* nedigitální řešení je lepší
* přizpůsobení nebo vývoj jiné služby je lepší řešení.
Jedná se pořád o úspěšnou fázi alfa, i když se rozhodnete, že pokračování ve fázi beta by znamenalo plýtvání časem i penězi.
=== Rozhodnutí o nové fázi alfa ===
Na konci fáze alfa se můžete také rozhodnout, že začnete znovu s fází alfa nebo “objevování”, protože se třeba chcete zaměřit na jiné věci.
Například, můžete identifikovat potřebu uživatelů ve fázi objevování a alfa a potom objevíte prostřednictvím dalšího průzkumu jinou potřebu uživatelů.
== Související příručky: ==
Může se vám hodit:
* [[Objevovací fáze služby | Jak funguje objevovací fáze službyeditovat]]
* [[Fáze beta provozu služby|Jak funguje fáze beta]]
* [[Fáze spuštění služby|Jak funguje ostrá verze]]
* [[Fáze ukončení služby|Dosloužení služby]]
====Zdroje====
https://www.gov.uk/service-manual/agile-delivery/how-the-alpha-phase-works