Del via

Anbefalinger for formalisering av praksis for administrasjon av programvareutvikling

  • Artikkel

Gjelder denne Power Platform anbefalingen for Well-Architected Operational Excellence-sjekklisten:

OE:03 Formaliser programvareforslaget og planleggingsprosessen, som henter fra etablerte bransjestandarder og organisasjonsstandarder. Bruk en felles, prioritert restanse og tilstrekkelig detaljerte spesifikasjoner. Frem kontinuerlige forbedringer i planleggingsprosessen basert på resultater.

Denne veiledningen beskriver anbefalingene for behandling av arbeidsbelastningsutviklingspraksis i henhold til etablerte standarder. Teamets evne til å produsere programvare av høy kvalitet er avhengig av en strukturert, samarbeidende tilnærming til utviklingsplanlegging. Arbeidsbelastningsteam bør forstå og tydelig kommunisere til interessenter arbeidet som gjøres. Mer presist bør arbeidsbelastningsteam ha en klar oversikt over arbeidet som skal gjøres i en utviklingssyklus og sikre at alle interessenter er på linje med "hvorfor" det arbeidet. Etablerte standarder definerer hvordan utviklingspraksis bør utføres og gjør det mulig for arbeidsbelastningsteamet å samarbeide effektivt og redusere risikoen for forvirring i mål og forventninger.

Viktige utformingsstrategier

Formaliser praksisen for utvikling av arbeidsbelastninger for å sikre en felles forståelse av målene og forventingene.

Ikke behandle lavkodebaserte arbeidsbelastninger som lavkompleksitet. Du drar fortsatt nytte av å formalisere utviklingen og administrasjonen av lavkodebaserte arbeidsbelastninger. Lær fra andre programvareutviklingsteam. Ha en beslutningsmatrise på plass som dikterer formaliseringsnivået som kreves basert på kompleksiteten og kritikaliteten til arbeidsmengden.

Standarder for utviklingsplanlegging

Standardene nedenfor kan hjelpe deg med å utforme en omfattende planleggingsstrategi for utvikling.

  • Prioritering: Planlegging av rekkefølgen og omfanget av arbeidet innebærer å forstå den sanne effekten og verdien av arbeidsbelastningsfunksjoner på virksomheten. Den omfatter også evaluering av disse virkningene mot andre arbeidsforespørsler og det samlede veikartet for produktet eller programmet. En måte å prioritere arbeidsbelastninger på er å evaluere forretningsverdiene for hele arbeidsbelastningen. Det kan også være nyttig å evaluere individuelle arbeidsbelastningsfunksjoner for forretningsverdien.

  • Kategorisering: Etabler prosesser som sikrer at kritiske applikasjoner har de nødvendige rekkverkene for å støtte dem. Sørg samtidig for at produktivitetsscenarier ikke bremses eller kveles av for mange strenge prosesser.

  • Samarbeid: Prosessen med å definere foreslåtte endringer i arbeidsmengden bør være en samarbeidsinnsats. De fleste endringer i arbeidsbelastningen påvirker flere funksjoner og komponenter, så å involvere så mange arbeidsbelastningsteammedlemmer som mulig bidrar til å sikre at viktige hensyn ikke går glipp av og at alle er klar over effekten på deres bestemte domene. Samarbeid bidrar også til å tydelig definere omfanget av en endring og hvordan du kan dele de nødvendige oppgavene inn i veldefinerte arbeidselementer. En større gruppe med ekspertise på tvers av domener er i stand til å gi erfaringsstøttede estimater for den nødvendige innsatsen.

  • Verktøy: Bruk etablerte, bransjeutprøvde verktøy og prosesser, som Agile-, Scrum- og Kanban-tavler.

Avveining: Smidig metodikk kan bli for streng hvis den er for foreskrivende. Strebe etter en balanse mellom veldefinerte standarder og nyskapning.

  • Distribusjon: Planlegg å bruke hyppige små, iterative distribusjoner i stedet for store, sjeldne distribusjoner.

  • Vilkår: Standardiser definisjonen av ferdige utviklingssykluser for å sikre at støttefunksjoner, inkludert testing, dokumentasjon og tilgjengelighetsfunksjoner, fullføres.

  • Kommunikasjon: Definer standardprotokollene for produkteiere og prosjektledere for å heve nivå av kommende utgivelser.

  • Brukerhistorier: Standardiser en mal for brukerhistorier. Velskrevne brukerhistorier bør følge INVEST-metoden:

    • I–Independent: Hver brukerhistorie bør være uavhengig av andre, noe som gjør at teamet kan levere i små trinnvise trinn.
    • N–Negotiable: Brukerhistorier bør forhandle og være åpne for diskusjon og endring.
    • V – Verdifull: Brukerhistorier skal gi verdi til kunden.
    • E–Estimable: Brukerhistorier bør kunne forstås og ha en klar definisjon av hva som er gjort.
    • S–Small: Brukerhistorier bør være korte og fokusert på én enkelt funksjon.
    • T–Testable: Brukerhistorier bør kunne testes og ha klare godkjenningsvilkår.

  • Akseptkriterier: Standardiser en mal for akseptkriterier. Kontroller at godkjenningsvilkårene er spesielt relatert til brukerartikkelen, og at de kan bevises utvetydig ved hjelp av en eller flere aksepttester.

  • Sporing: Sørg for at utviklingsprosessen er sporbar. Du bør tydelig spore tilstanden til produksjonsarbeidsbelastningen og den tilknyttede koden tilbake til kvalitetssikringstesting, godkjenningsvilkår, brukerstatus og funksjoner. Detaljert sporing kan også være et forskriftskrav i noen tilfeller, for eksempel helsetjenester.

  • Gjennomgang: Utfør regelmessig interne revisjoner av utviklingspraksisen din gjennom utviklingssyklusretrospektiver og obduksjoner. Prosessrefleksjon bør være uanstrengt og bør fokusere på læring som kan brukes som forbedringer. Sørg for at teamet reflekterer over hvor effektiv brukerhistorien og oppgavene var med å definere nødvendige oppgaver og nøyaktigheten av tidsestimater.

  • Rapporter: Standardiser rapporter for interessenter som gir nyttige beregninger med fokus på endring. Fokusering på endring gjør det mulig å spore produktakselerasjon og -deselerasjon. Nyttige måleverdier kan omfatte endringer i følgende:

    • Månedlig vekstrate for innføring
    • Ytelse
    • Opplæringstid
    • Frekvens for hendelser

    Rapportering bør ikke brukes som et verktøy til å evaluere arbeidet til enkeltpersoner, så unngå måleverdier som historiepoeng eller kodelinjer for hver tekniker.

Tilrettelegging for Power Platform

Selv om det ikke finnes Power Platform-produkter som direkte legger til rette for denne anbefalingen, kan du bruke andre verktøy i Microsoft-stakken. Azure Boards er en nettbasert tjeneste som gjør det mulig for team å planlegge, spore og diskutere arbeid på tvers av hele utviklingsprosessen.

GitHub Projects er et tilpassbart prosjektstyringsverktøy for å organisere prosjekter og integreres med dine problemer og pull-forespørsler i GitHub.

Neste trinn

Sjekkliste for Operational Excellence