Zásady správného řízení společného vývoje
Ustavení efektivní architektury zásad řízení společného vývoje je důležitou součástí procesu zajišťujícího konzistenci a opakovatelnost v projektech definovaných tvůrcem a smíšených týmech. Tento článek popisuje přístup k definování vývojového diagramu řízení.
Definování kompletního procesu
Následující proces můžete použít jako příklad a přizpůsobit jej osvědčeným postupům vaší organizace. Není nutné dokončit každý jednotlivý krok, pokud dosáhnete požadovaného výsledku.
Přidání funkcí do backlogu
Backlogy vám umožňují plánovat váš projekt přidáním funkcí, které řídí celkové prostředí. Backlog také poskytuje celkový plán, který tým hodlá dodat.
Při přidávání nové funkce do backlogu je cílem popsat obecný rozsah. Každá funkce pak definuje obchodní hodnotu, názvy konceptů, rozsah a změny datového modelu, které řídí vývoj kódu.
Kromě toho se při přidávání zásadní funkce doporučuje identifikovat všechny kritické scénáře pro automatizaci testování. Po přidání funkcí můžete naplánovat schůzku pro zarovnání rozsahu.
Schůzka pro zarovnání rozsahu
Zaměření této schůzky by mělo být omezeno na přezkoumání každé navrhované nové funkce a poté na kontrolu všech existujících aplikací, scénářů nebo datových modelů, které již tuto funkci poskytují, aby se předešlo zdvojování úsilí. Toto setkání také poskytuje příležitost prodiskutovat dopad na jiné aplikace. Na závěr byste měli zkontrolovat, zda tato funkce vyžaduje kontrolu prostředí.
Přidejte příběhy a scénář do backlogu
Po schůzce zarovnání rozsahu lze do funkce přidat libovolné názvy příběhů uživatelů. V tomto okamžiku nejsou podrobnosti vyžadovány a stav uživatelského příběhu je „Nový“. Příběhy si můžete prohlížet buď v backlogu nebo v zobrazení řídicího panelu.
Následující obrázek ukazuje ukázkový uživatelský příběh přidaný do backlogu.
V tomto okamžiku je životně důležité udržovat kvalitu organizováním práce podle pracovního toku a aplikace. Tento přístup pomáhá udržet související pracovní položky pohromadě a umožňuje odborníkům v každém pracovním proudu rozvíjet a udržovat hluboké porozumění funkcím a využití dat v každé aplikaci.
Kontrola prostředí
Kontrola zkušeností by se měla zaměřit na prostředí koncového uživatele a zajistit, aby se váš tým řídil osvědčenými postupy organizace. Tato konzistence zajišťuje, že všechny vaše aplikace poskytují koncovým uživatelům a týmům podpory spolehlivé a opakovatelné prostředí.
Přidání podrobností historie
Přidání typického uživatelského příběhu může obsahovat následující informace:
- Nadpis : Jako <persona> mohu <do something>, aby <impact/priority/value>
- Popis: Popis obsahuje (ačkoli není omezen na) určité klíčové detaily, jako například:
- Stručný popis scénáře, který shrnuje požadovaný výsledek
- Příběh – popisuje akce, které uživatelé podniknou, aby prošli scénářem a provedli jej
- Alternativní příběh – popisuje jiné způsoby, jak mohou uživatelé dosáhnout stejného výsledku
- Poznámky k návrhu – zaznamenává entitu, pole, pohledy, obrazovky maket a obchodní pravidla související s příběhem uživatele
- Ovlivněné role zabezpečení – uvádí všechny role zabezpečení, kterých se to týká nebo které jsou relevantní pro příběh uživatele.
Po přidání všech těchto podrobností změníte stav příběhu uživatele na „Připraveno ke kontrole“. Ve většině případů hodnotí příběhy uživatelů tým funkcí a obchodní tým (pokud existuje).
Kontrola příběhu
Kontrola příběhu se obvykle odehrávají v rámci smíšeného týmu, aby se zajistilo, že všechny podrobnosti jsou uvedeny v příběhu a že neexistují žádné nejednoznačnosti. Po dokončení všech kontrol se doporučuje přiřadit příběh uživatele členovi týmu. Pro dosažení vašich celkových cílů je zásadní zajistit, aby váš tým zůstal během procesu vývoje jednotný.
Přidání úkolů a testovacích případů
Po prostudování příběhů vytvoří členové týmu úkoly v Azure DevOps. Celkový proces přidávání úkolů a testovacích případů je následující:
- Otevřete backlog sprintu. Případně vytvořte nový sprint.
- Přidejte existující pracovní položky do sprintu. Pokud jste již přidali pracovní položky, které se ve sprintu nezobrazují, měli byste zkontrolovat jejich oblast a cesty iterací. Nezapomeňte přiřadit všechny úkoly bez nadřazených položek příslušným pracovním položkám.
- Přidejte úkoly do nevyřízených položek. Pokud ke svému sprintu nemáte přiřazené položky backlogu, udělejte to nyní. Nastavte také datum začátku a konce sprintu.
- Vyplňte formulář úkolu. Obecně platí, že dokončení úkolů by nemělo trvat déle než jeden den. Úkoly, které jsou delší než tento časový rámec, by měly být rozděleny.
- Sledujte nebo integrujte všechny úkoly bez nadřazených položek. Úkoly bez nadřazených položek můžete sledovat stejně jako jiné úkoly nebo je přetáhnout do existující položky nevyřízené položky, abyste jim přiřadili nadřazenou položku.
Po přidání úloh a testovacích případů můžete přejít k nastavení kapacity sprintu.
Další informace o přidávání úkolů najdete v tématu Přidání úkolů do položek backlogu pro podporu plánování sprintů.
Příprava řešení
Důležitým aspektem úspěšného společného vývoje je strukturovaný proces správy vydání. Řešení jsou mechanismem pro implementaci správy životního cyklu (ALM); použijete je k distribuci komponent napříč prostředími prostřednictvím aktivit exportu a importu. Součást představuje artefakt použitý v aplikaci a něco, co lze potenciálně přizpůsobit. Cokoli, co lze zahrnout do řešení, je součást; například tabulky, sloupce, aplikace plátna a modelem řízené aplikace, Power Automate, chatboty, grafy a moduly plug-in.
Důležité
Během plánování vydání určete strategii správy řešení ve vašem projektu. Používejte řešení ke správě svého projektu a snadno vyhledejte součásti, které jste vytvořili, a poté je distribuujte do jiných prostředí.
Nasazení
Součásti mohou v závislosti na složitosti a rychlosti rozhodování týmu zabrat několik sprintů. Součásti by měly být přidány k řešení ve vývojovém prostředí po dokončení úkolů. Řešení jsou poté po otestování importována do produkčního prostředí. Doporučujeme také udržovat jedno testovací prostředí sloužící k provádění komplexního testování a vyzkoušení nasazení řešení před přechodem do produkce.
Prostředí Power Platform
Prostředí jsou místa k ukládání, správě a sdílení obchodních dat, aplikací a obchodních procesů vaší organizace. Slouží také jako kontejnery k oddělení aplikací, které mohou mít různé role, požadavky na zabezpečení nebo cílové publikum.
Pokud má vaše organizace vícetýmové hybridní nastavení, kde každý tým vyvíjí svá vlastní řešení, je důležité koordinovat trvání sprintů a vydání. Sprinty nemusí mít konzistentní délku na časové ose projektu a jejich délka se u jednotlivých týmů může lišit, a to podle preferencí každé skupiny. Interval vydání však nemůže být menší než nejkratší doba trvání sprintu za všechny týmy.
Zdrojový ovládací prvek
Zvažte zavedení systému správy zdrojového kódu, například Azure DevOps. Azure DevOps poskytuje vývojářské služby týmům podpory, určené k plánování práce, spolupráci při vývoji kódu a vytváření a nasazování aplikací.
Exportujte řešení z vývojového prostředí obsahující vaše aplikace a přizpůsobení, rozbalte řešení a uložte komponenty do systému řízení zdrojového kódu.
Pokročilé téma: kontroly požadavků na sloučení změn
Požadavky na sloučení změn byste měli vytvářet pouze pro příběhy, které jsou aktivní a jejichž funkce byly zkontrolovány a schváleny. Měli byste se ujistit, že verzování řešení je přesné podle pokynů pro sprint a vývoj uvedených v tématu Implementace postupů Scrum pro váš tým v Azure Boards. Výsledky testů z PR mohou být snímky obrazovky nebo videa, která zobrazují vytvářenou funkcionalitu.
Automatizace procesu řízení změn PR pomáhá zajistit kvalitu kódu bez nutnosti ruční kontroly základních kontrol, jako jsou verze řešení.
Poznámka
Nástroj pro kontrolu PR použijte k automatizaci procesu kontroly požadavku na přijetí změn.
Šablony a standardizace
Šablony a standardizace přinášejí efektivitu, protože pomáhají podporovat konzistenci v týmu. Všechny aspekty operací týmu— ať už se jedná o zavádění úkolů, prezentace recenzí příběhů nebo šablony pracovních položek , které pomáhají šetřit čas a poskytují týmům rady při definování uživatelských příběhů, funkcí, chyb nebo úkolů— využívejte standardizaci a zjednodušení.
Implementace efektivního modelu podpory
Efektivní model podpory je nezbytný pro dlouhodobý úspěch aplikace po jejím nasazení, jak bylo zdůrazněno v předchozí části o generování matice podpory. Chyby a výpadky jsou nevyhnutelné, takže je důležité, aby tým měl strukturovaný přístup k řešení těchto událostí a matice podpory poskytovala nezbytnou architekturu.
Vytvoření smlouvy o rozsahu služeb
Klíčovým faktorem v každém modelu podpory je definice smlouvy o úrovni služeb (SLA). SLA by měl být formální dokument, který tým vypracuje a který obsahuje části, které pokrývají následující záležitosti:
- Výpadky – jaká úroveň výpadku služby je přijatelná, koho informovat, jaké kroky podniknout, potvrzení obnovení služby a opatření k zabránění opakování. Veškeré automatizované testovací postupy, které tým používá, musí být v souladu s očekávanou tolerancí výpadku a příslušnou SLA.
- Chyby – kdo je může oznamovat, přiřazení úrovní závažnosti, klasifikace, akce při zjištění výskytu, kdo je odpovědný za řešení a odhlášení.
- Eskalace – úrovně eskalace, přiřazení zaměstnanců k úrovním, odpovědnosti na každé úrovni, distribuční seznamy pro každou úroveň atd.
SLA by měla být uložena na dokumentačním portálu týmu a podle potřeby aktualizována.
Poskytování aplikační podpory
Poskytování aplikační podpory specifikované ve smlouvě SLA se nejlépe zajistí, když tým, který řešení vytvořil, je také odpovědný za jeho podporu. Výhody tohoto systému jsou:
- Podporuje vývoj s vyšší kvalitou, protože ti, kdo aplikaci vytvořili, vědí, že ji budou muset podporovat.
- Tvůrci budou schopni najít a opravit chyby rychleji než tým třetí strany, jednoduše proto, že aplikaci znají lépe.
- Delegování opravy potenciálně kritického softwaru na jinou skupinu může být pro tuto skupinu demoralizující a časově náročné. Stejně jako u jiných fází tvorby, vývoje a nasazení aplikací by měl smíšený tým spolupracovat s IT, aby vám v případě potřeby pomohl.
Monitorování spokojenosti a použitelnosti aplikací
Poslední částí podpory je monitorování a hodnocení spokojenosti a použitelnosti nasazené aplikace. Zde jsou užitečné metriky spolu s tradičnějšími metodami, jako je dotazování a dotazníky. Další informace o sledování používání aplikací naleznete v tématu Analýza správce pro Power Apps.
Nakonec, pokud zákazníci nepoužívají publikovanou aplikaci, pak tato aplikace neplní svůj účel. Pravidelné kontrolní schůzky mohou přezkoumat tyto metriky spokojenosti a použitelnosti a vytvořit smyčku pozitivní zpětné vazby, která může měnit nebo přidávat příběhy do backlogu a generovat a poté nasadit aktualizovanou verzi aplikace.
Shrnutí
Vývoj nástrojů s nulovým nebo omezeným psaním kódu – jako např Power Apps – má rozšířené možnosti vytváření, vývoje a nasazování aplikací pro podnikové technology nebo tvůrce. Tento vývoj funguje nejlépe v prostředí smíšeného týmu, který zahrnuje vlastníka produktu, experta na doménu, profesionálního vývojáře a správce, přičemž tento tým podle potřeby přináší další zdroje.
Integrace agilních přístupů a scrumu v rámci smíšených týmů má za následek rychlejší vývoj aplikací a vyšší pravděpodobnost úspěšného nasazení se sadou funkcí, která představuje významný rozdíl pro podnikání. Uplatněním těchto osvědčených postupů, pokynů a doporučení umožníte vašemu smíšenému týmu používat Power Apps k řešení problémů digitální transformace vaší organizace.