Share via

Doporučení pro formalizaci vývoje a správy softwaru

  • Článek

Platí pro toto doporučení kontrolního seznamu efektivity provozu azure Well-Architected Framework:

OE:03 Formalizace procesů ideových a plánovacích procesů softwaru Čerpáte ze zavedených oborových a organizačních standardů. Použijte společný backlog s prioritou a dostatečně podrobnou specifikaci. Na základě výsledků můžete v procesu plánování neustále vylepšovat.

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 přístupu ke 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é strany práci, kterou vývojáři dělají v jakémkoli vývojovém cyklu. 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 nejasností ohledně cílů a očekávání.

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í.

Standardy pro plánování vývoje

  • Spolupráce: Proces definování navrhovaných změn v úloze by měl být společný. Většina změn úlohy bude mít vliv na více funkcí nebo komponent, takže zapojení co nejvíce členů týmu úloh pomůže zajistit, aby nedošlo k vynechání důležitých aspektů a aby všichni věděli o dopadu na svoji konkrétní doménu. Spolupráce také pomáhá jasně definovat rozsah změny a způsob rozdělení úkolů potřebných k provedení změny do jasně definovaných pracovních položek, protože větší skupina s odbornými znalostmi z různých oblastí bude schopna poskytnout zkušenosti s odhady požadovaného úsilí.

  • Nástroje: Používejte zavedené, prověřené nástroje a procesy, jako jsou agilní, scrumové a kanbanové desky. Vývoj vlastních nástrojů a procesů je významný úkol, který trvá čas a vývojové cykly, které by jinak mohly být vynaloženy na vaše úlohy. Většina zkušených techniků DevOps a vlastníků produktů tyto typy nástrojů a procesů zná, takže křivka osvojení těchto nástrojů a procesů by měla být minimální. Stejně tak proces připojování nových zaměstnanců bude těžit také z používání standardních nástrojů a procesů, protože je pravděpodobné, že již budou mít určitou míru vystavení stejným nástrojům a procesům.

Kompromis: Agilní metodologie může být příliš striktní, pokud je příliš normativní. Snažte se o rovnováhu mezi jasně definovanými standardy a inovacemi.

  • Nasazení: Naplánujte použití častých malých iterativních nasazení místo velkých, zřídka používaných nasazení. Tento přístup pomůže zajistit, aby uživatelské scénáře a pracovní položky bylo možné spravovat z hlediska řízení projektů a snížit riziko rozsáhlých problémů v případě selhání nasazení.

  • Termíny: 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í pro usnadnění přístupu.

  • Komunikace: Definujte standardní protokoly pro vlastníky produktů a projektové manažery za účelem interní i externí propagace nadcházejících verzí. 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 se má komunikace odeslat dva týdny před vydáním verze a 24 hodin před vydáním by se mělo odeslat připomenutí.

  • 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 záměnám s překrývající se prací 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 scénářích, což pomáhá při plánování a stanovení priorit.

    • Každý uživatelský scénář je obchodovatelný. Perspektivy koncových uživatelů a členů pracovního týmu jsou nezbytné pro zachycení reálných uživatelských scénářů, které lze provést během krátké doby.

    • 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é ho zajímají a které přidají hodnotu jeho zkušenostem. Když se zaměříte na to, jak je uživatelský scénář rozdělený na pracovní položky, pomůžete tím zajistit, aby každé nasazení poskytovalo lepší prostředí.

    • Úsilí vyžadované pro scénář uživatele je odhadnutelné s vysokou mírou spolehlivosti. Bez toho, aby bylo možné přesně aproximovat hodiny potřebné pro daný uživatelský scénář, bude plánování obtížné a potenciál chybějících termínů se zvýší, což může mít kaskádový dopad na další plánovanou práci.

    • Dobře napsané uživatelské scénáře jsou malé, takže je můžete dokončit během několika týdnů. Menší scénáře s vymezeným oborem pomáhají zajistit, aby je bylo možné odhadnout a spravovat, a zajistit, aby pracovní položky byly dosažitelné.

    • Uživatelské scénáře by měly být testovatelné. Bez otestování, že byla funkce dodána, nemůže mít koncový uživatel jistotu, že cíl byl splněn. I v případě, že test ještě nebyl napsán pro daný uživatelský scénář, měli byste jasně porozumět tomu, jak lze test vyvinout, aby se prokázalo doručení funkce.

  • Kritéria přijetí: Standardizujte šablonu pro kritéria přijetí. Zajistěte, aby kritéria přijetí souvisela konkrétně s uživatelským scénářem a bylo možné je jednoznačně prokázat jedním nebo více akceptačními testy.

  • Trasování: Zajistěte, aby bylo možné sledovat vývojový proces. Měli byste jasně vysledovat stav produkční úlohy a přidruženého kódu zpět k testování kontroly 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 ve zdravotnictví.

  • Kontrola: Pravidelně provádějte interní audity vašich postupů vývoje prostřednictvím retrospektiv a následných posmrtných vývojových cyklů. Reflexe procesu by měla být bez obviňování a měla by se zaměřit na učení, které lze použít jako vylepšení. Zajistěte, aby tým reflektoval efektivitu uživatelského scénáře a úkolů při definování potřebných úkolů a na přesnosti odhadů času.

  • Sestavy: Standardizujte sestavy pro zúčastněné strany, které poskytují užitečné metriky zaměřené na změny. Zaměření na změnu umožňuje sledovat akceleraci a zpomalení produktu. Užitečné metriky můžou zahrnovat změny v:

    • Měsíční míra růstu přijetí.

    • Výkon.

    • Doba trénování.

    • Četnost 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 technika.

Usnadnění Azure

Azure Boards je webová služba, která týmům umožňuje plánovat, sledovat a diskutovat o práci v celém procesu vývoje. Je vhodný pro agilní vývojové postupy.

GitHub Projects je přizpůsobitelný nástroj pro řízení projektů, který dokáže uspořádat projekty a integrovat je pomocí problémů a žádostí o přijetí změn v GitHubu.

Kontrolní seznam efektivity provozu

Projděte si kompletní sadu doporučení.

Kontrolní seznam efektivity provozu