Doporučení pro formalizaci vývoje a správy softwaru
Platí pro toto doporučení kontrolního seznamu provozní efektivity architektury Azure Well-Architected Framework:
| OE:03 | Formalizace procesů ideace a plánování softwaru Vycházet ze zavedených oborových a organizačních standardů. Použijte společný backlog s určením priority a dostatečně podrobné specifikace. Na základě výsledků můžete průběžně zlepšovat proces plánování. |
|---|
Tato příručka popisuje doporučení pro správu postupů vývoje softwaru v souladu se zavedenými standardy. Schopnost vašeho týmu vytvářet vysoce kvalitní software závisí na strukturovaném a spolupráci při plánování vývoje. Vlastníci a manažeři produktů musí být schopni jasně pochopit a vyjádřit zúčastněným stranám práci, kterou vývojáři v každém okamžiku dělají v cyklu vývoje. Vývojáři naopak musí porozumět cílům vývojového cyklu prostřednictvím dobře napsaných funkcí, uživatelských scénářů a kritérií přijetí. Zavedené standardy definují, jak by se měly provádět vývojové postupy, a umožňují týmu úloh efektivně spolupracovat, což snižuje riziko nejasnosti na cílech a očekáváních.
Klíčové strategie návrhu
Formalizujte postupy vývoje softwaru, abyste zajistili, že vlastníci produktů, projektoví manažeři a vývojáři pochopí cíle každého sprintu a zajistí konzistentní kvalitu zúčastněným stranám. Pokyny k postupům vývoje najdete v průvodci kontinuální integrací.
Vytvoření standardů pro spolupráci a komunikaci
Spolupráce: Proces definování navrhovaných změn úlohy by měl být úsilím na spolupráci. Většina změn úlohy bude mít vliv na více funkcí a/nebo součástí, takže zapojení co nejvíce členů týmu úloh pomůže zajistit, aby důležité aspekty nebyly zmeškané a že všichni vědí o dopadu na svoji konkrétní doménu. Spolupráce také jasně definuje rozsah změny a způsob rozdělení nezbytných úkolů potřebných k provedení změny na dobře definované pracovní položky, protože větší skupina s odbornými znalostmi napříč doménami bude schopna poskytnout odhady založené na zkušenostech pro požadované úsilí.
Komunikace: Definujte standardní protokoly pro vlastníky produktů a projektové manažery, aby podporovaly nadcházející verze interně i externě. Můžete například vytvořit standard pro komunikaci s externími stranami o nadcházejících verzích. Standard může diktovat, že komunikace by měla být odeslána dva týdny před vydáním a připomenutí by mělo být odesláno 24 hodin před vydáním.
Kontrola: Pravidelně provádět interní audity vašich postupů vývoje prostřednictvím retrospektivních a postmortemálních cyklů vývoje. Reflexe procesu by měla být bezobvižná a měla by se zaměřit na učení, které je možné použít jako vylepšení. Ujistěte se, že tým odráží, jak efektivní byl scénář uživatele a úkoly při definování potřebných úkolů a na přesnosti časových odhadů.
Sestavy: Standardizujte sestavy pro zúčastněné strany, které poskytují užitečné metriky zaměřené na změnu. Když se zaměříte na změnu, můžete sledovat akceleraci a zpomalení produktu. Mezi užitečné metriky můžou patřit změny:
Měsíční míra růstu přijetí.
Výkon.
Čas trénování.
Frekvence incidentů.
Vytváření sestav by se nemělo používat jako nástroj k vyhodnocení práce jednotlivců, takže se vyhněte metrikám, jako jsou body scénáře nebo řádky kódu pro každého inženýra.
Volba standardních nástrojů
Používejte zavedené, prověřené nástroje a procesy, jako jsou Agilní, Scrum a Kanbanové desky. Vývoj vlastních nástrojů a procesů je významný podnik, který trvá čas a vývojové cykly, které by jinak mohly být vynaloženy na vaši úlohu. Většina zkušených techniků DevOps a vlastníků produktů jsou obeznámeni s těmito typy nástrojů a procesů, takže křivka učení při jejich přijetí by měla být minimální. Stejně tak bude proces onboardingu pro nové zaměstnance těžit také z používání standardních nástrojů a procesů, protože budou pravděpodobně mít určitou míru expozice stejným nástrojům a procesům.
Kompromis: Agilní metodologie se může stát příliš striktní, pokud je příliš preskriptivní. Snažte se o rovnováhu mezi dobře definovanými standardy a inovacemi.
Přijetí standardního standardu pro zachycení scénářů koncových uživatelů
Uživatelské scénáře: Standardizujte šablonu pro uživatelské scénáře. Zajistěte, aby každý uživatelský scénář byl samostatnou jednotkou práce napsanou z pohledu koncového uživatele. Dobře napsané uživatelské scénáře by měly mít následující charakteristiky:
Každý uživatelský scénář by měl být zcela nezávislý na sobě. Udržování uživatelských scénářů nezávisle na sobě zabraňuje nejasnostem při překrývající se práci a pomáhá týmu pochopit, jestli práce na daném uživatelském scénáři závisí na práci na jiných uživatelích, což pomáhá s plánováním a stanovením priorit.
Každý uživatelský příběh je možné vyjednat. Perspektivy koncových uživatelů a členů týmu úloh jsou nezbytné k zachycení realistických uživatelských scénářů, které je možné provést za krátkou dobu.
Uživatelské scénáře jsou pro koncového uživatele cenné. Když píšete uživatelské scénáře z pohledu koncového uživatele, zachytíte změny, které mají zájem vidět a které budou mít přidanou hodnotu do svého prostředí. Toto zaměření je rozdělené na pracovní položky, které zajistí, aby každé nasazení poskytovalo lepší prostředí.
Úsilí potřebné pro uživatelský příběh je odhadnutelné s vysokou mírou spolehlivosti. Aniž by bylo možné mít úzkou aproximaci hodin potřebných pro daný uživatelský příběh, plánování bude obtížné a potenciál chybějících termínů se zvýší, což může způsobit kaskádové účinky na jinou plánovanou práci.
Dobře napsané uživatelské scénáře jsou malé, takže je možné je dokončit během několika týdnů. Menší oborové scénáře pomáhají udržovat je v odhadnutelném a spravovatelném prostředí a pomáhají udržet pracovní položky dosažitelné.
Uživatelské scénáře by měly být testovatelné. Bez toho, aby bylo možné otestovat, že funkce byla doručena, nemůže mít koncový uživatel jistotu, že byl cíl splněn. I když test ještě nebyl napsán pro daný uživatelský příběh, měli byste jasně pochopit, jak lze test vyvinout, aby bylo možné prokázat doručení funkce.
Kritéria přijetí: Standardizujte šablonu pro kritéria přijetí. Ujistěte se, že kritéria přijetí souvisí konkrétně s uživatelským scénářem a je možné je jednoznačně ověřit pomocí jednoho nebo více akceptačních testů.
Standardizace postupů nasazení
Nasazení: Naplánujte použití častých malých iterativních nasazení místo velkých zřídka používaných nasazení. Použití tohoto přístupu pomůže udržet uživatelské scénáře a pracovní položky spravovatelné z hlediska řízení projektů a snížit riziko rozsáhlých problémů v případě selhání nasazení.
Podmínky: Standardizujte definici dokončených vývojových cyklů, abyste zajistili úspěšné dokončení podpůrných funkcí, včetně testování, dokumentace a funkcí přístupnosti.
Trasování: Ujistěte se, že je proces vývoje trasovatelný. Měli byste jasně sledovat stav produkční úlohy a přidružený kód zpět k testování kvality, kritériím přijetí, uživatelským scénářům a funkcím. Podrobné trasování může být v některých případech také zákonným požadavkem, například zdravotní péče.
Usnadnění azure
Azure Boards je webová služba, která týmům umožňuje plánovat, sledovat a diskutovat o práci napříč celým procesem vývoje. Je vhodný pro agilní vývojové postupy.
GitHub Projects je přizpůsobitelný nástroj pro správu projektů, který umožňuje organizovat projekty a integrovat je pomocí problémů a žádostí o přijetí změn na GitHubu.
Související odkazy
Komunitní odkazy
Kontrolní seznam pro efektivitu provozu
Projděte si kompletní sadu doporučení.