Del via

Anbefalinger til formalisering af fremgangsmåder for administration af softwareudvikling

  • Artikel

Gælder for denne Power Platform anbefaling af Well-Architected Operational Excellence-tjekliste:

OE:03 Formaliser softwareudvikling og planlægningsprocessen, hvor der trækkes på etablerede branchestandarder og organisatoriske standarder. Brug en almindelig, prioriteret efterslæb og tilpas detaljerede specifikationer. Baseret på resultater kan du skabe konstante forbedringer i planlægningsprocessen.

I denne vejledning beskrives anbefalingerne til administration af fremgangsmåder til udvikling af arbejdsbelastninger i overensstemmelse med etablerede standarder. Dit teams evne til at producere software af høj kvalitet er afhængig af en struktureret, samarbejdsbaseret tilgang til udviklingsplanlægning. Arbejdsbelastningsteams bør forstå og klart kommunikere til interessenter det arbejde, der udføres. Mere præcist bør arbejdsbelastningsteams have et klart overblik over det arbejde, der skal udføres i en udviklingscyklus, og sikre, at alle interessenter er på linje med "hvorfor" det pågældende arbejde. I etablerede standarder defineres, hvordan udviklingspraksis skal udføres, og hvordan arbejdsbelastningsteamet kan samarbejde effektivt, hvilket reducerer risikoen for forvirring om mål og forventninger.

Vigtigste designstrategier

Formaliser dine fremgangsmåder til udvikling af arbejdsbelastninger for at sikre en fælles forståelse af målene og forventningerne.

Behandl ikke low-code-arbejdsbelastninger som lav kompleksitet. Du drager stadig fordel af at formalisere udviklingen og administrationen af low-code-arbejdsbelastninger. Lær af andre softwareudviklingsteams. Hav en beslutningsmatrix på plads, der dikterer det formaliseringsniveau, der kræves baseret på kompleksiteten og vigtigheden af arbejdsbelastningen.

Standarder for planlægning af udvikling

Følgende standarder kan hjælpe dig med at designe en omfattende strategi for planlægning af udvikling.

  • Prioritering: Planlægning af arbejdets rækkefølge og omfang indebærer forståelse af den sande indvirkning og værdi af arbejdsbelastningsfunktioner på virksomheden. Den omfatter også evaluering af disse påvirkninger i forhold til andre arbejdsanmodninger og den overordnede procedure for dit produkt eller program. En måde at prioritere arbejdsbelastninger på er ved at vurdere forretningsværdien af hele arbejdsbelastningen. Du kan også finde det nyttigt at evaluere individuelle funktioner til arbejdsbelastning for forretningsværdien.

  • Kategorisering: Etabler processer, der sikrer, at kritiske applikationer har de nødvendige rækværk til at understøtte dem. Sørg samtidig for, at produktivitetsscenarier ikke bremses eller kvæles af for mange strenge processer.

  • Samarbejde: Processen med at definere foreslåede ændringer i arbejdsbyrden bør være en samarbejdsindsats. De fleste ændringer i arbejdsbelastningen påvirker flere funktioner og komponenter, så involvering af så mange arbejdsbelastningsteammedlemmer som muligt hjælper med at sikre, at vigtige overvejelser ikke overses, og at alle er opmærksomme på effekten på deres specifikke domæne. Samarbejde hjælper også med klart at definere omfanget af en ændring, og hvordan man opdeler de nødvendige opgaver i veldefinerede arbejdselementer. En større gruppe med ekspertise på tværs af domæner er i stand til at levere erfaringsbaserede estimater for den nødvendige indsats.

  • Værktøjer: Brug etablerede, brancheafprøvede værktøjer og processer, såsom Agile , Scrum og Kanban-tavler.

Afvejning: Agil metode kan blive for streng, hvis den er alt for præskriptiv. Stræb efter en balance mellem veldefinerede standarder og innovation.

  • Udrulning: Planlæg at bruge hyppige små, iterative udrulninger i stedet for store, sjældne udrulninger.

  • Vilkår: Standardiser din definition af afsluttede udviklingscyklusser for at sikre, at understøttende funktioner, herunder test, dokumentation og tilgængelighedsfunktioner, fuldføres.

  • Kommunikation: Definer standardprotokollerne for produktejere og projektledere for at hæve kommende udgivelser.

  • Brugerhistorier: Standardiser en skabelon til brugerhistorier. Velskrevne brugerhistorier skal følge INVEST-fremgangsmåden:

    • I–Independent: Hver brugers historie skal være uafhængig af andre, så teamet kan levere i små trinvise trin.
    • N–Negotiable: Brugerhistorier skal være til diskussion og være åbne for ændringer.
    • V-Værdifuld: Brugerhistorier skal give værdi til kunden.
    • E-Estimerbar: Brugerhistorier skal kunne estimeres og have en klar definition af udført.
    • S-Small: Brugerhistorier skal være små og fokusere på en enkelt funktion.
    • T–Testbar: Brugerhistorier skal kunne testes og have klare acceptkriterier.

  • Acceptkriterier: Standardiser en skabelon til acceptkriterier. Sørg for, at acceptkriterierne specifikt vedrører brugerhistorien, og at de kan dokumenteres entydigt ved hjælp af en eller flere accepttests.

  • Sporing: Sørg for, at udviklingsprocessen er sporbar. Du skal tydeligt spore status for produktionsbelastningen og den tilknyttede kode tilbage til kvalitetstest, acceptkriterier, brugerhistorier og funktioner. Detaljeret sporing kan også være et lovkrav i nogle tilfælde, f.eks. sundhedspleje.

  • Gennemgang: Udfør regelmæssigt interne revisioner af din udviklingspraksis gennem udviklingscyklusretrospektiver og obduktioner. Procesreflektion skal være pletfri og bør fokusere på læring, der kan anvendes som forbedringer. Sørg for, at teamet tænker over, hvor effektiv brugerfortællingen og opgaverne var i forbindelse med definition af de nødvendige opgaver og præcisionen af tidsestimater.

  • Rapporter: Standardiser rapporter til interessenter, der giver nyttige målinger med fokus på forandring. Med fokus på ændringer kan du spore produktacceleration og -deceleration. Nyttige målepunkter kan inkludere ændringer i:

    • Månedlig vækstrate for indføring
    • Ydeevnen
    • Oplæringstidspunkt
    • Frekvens af hændelser

    Rapportering bør ikke bruges som et værktøj til evaluering af enkeltpersoners arbejde, så du skal undgå metrikværdier som fortællepunkter eller kodelinjer for de enkelte teknikere.

Power Platform-processtyring

Selvom der ikke er nogen Power Platform produkter, der direkte letter denne anbefaling, kan du bruge andre værktøjer i stakken Microsoft . Azure Boards er en webbaseret tjeneste, der gør det muligt for teams at planlægge, spore og diskutere arbejde på tværs af hele udviklingsprocessen.

GitHub Projects er et projektstyringsværktøj, der kan tilpasses, til at organisere projekter og integreres med dine problemer og pull-anmodninger i GitHub.

Næste trin

Tjekliste for operationel ekspertise