Dela via


Rekommendationer för formalisering av metoder för hantering av programvaruutveckling

Gäller för den här Power Platform rekommendationen för checklistan Well-Architected Operational Excellence:

OE:03 Formalisera processen för programvaruidéer och planering, med hjälp av etablerade bransch- och organisationsstandarder. Använd en gemensam, prioriterad backlog och tillräckligt detaljerade specifikationer. Förbättra planeringsprocessen kontinuerligt baserat på resultat.

I den här guiden beskrivs rekommendationer om hur du hanterar arbetsbelastningens utvecklingsmetoder enligt fastställda standarder. Ditt teams förmåga att producera programvara av hög kvalitet är beroende av ett strukturerat, samarbetsinriktat tillvägagångssätt för utvecklingsplanering. Arbetsbelastningsteam bör förstå och tydligt kommunicera till intressenter det arbete som utförs. Mer exakt bör arbetsbelastningsteamen ha en tydlig bild av det arbete som ska utföras i en utvecklingscykel och se till att alla intressenter är överens om "varför" arbetet ska utföras. Etablerade standarder definierar hur utvecklingsmetoder ska utföras och gör det möjligt för arbetsbelastningsteamet att samarbeta effektivt, vilket minskar risken för förvirring om mål och förväntningar.

Viktiga designstrategier

Formalisera arbetsbelastningens utvecklingsmetoder så att du får en gemensam förståelse av målen och förväntningarna.

Behandla inte arbetsbelastningar med lågkod som låg komplexitet. Du kan fortfarande dra nytta av att formalisera utvecklingen och hanteringen av arbetsbelastningar med lågkod. Lär dig av andra programvaruutvecklingsteam. Ha en beslutsmatris på plats som dikterar vilken nivå av formalisering som krävs baserat på arbetsbelastningens komplexitet och allvarlighetsgrad.

Standarder för utvecklingsplanering

Följande standarder kan hjälpa dig att utforma en omfattande utvecklingsplaneringsstrategi.

  • Prioritering: Att planera ordningen och omfattningen av arbetet innebär att förstå den verkliga effekten och värdet av arbetsbelastningsfunktioner på verksamheten. Det omfattar också att utvärdera dessa effekter mot andra arbetsförfrågningar och den övergripande utvärderingen av produkten eller programmet. Ett sätt att prioritera arbetsbelastningen är att utvärdera affärsvärdet för hela arbetsbelastningen. Det kan också vara användbart att utvärdera enskilda arbetsbelastningsfunktioner för affärsvärdet.

  • Kategorisering: Upprätta processer som säkerställer att kritiska program har de skyddsräcken som krävs för att stödja dem. Se samtidigt till att produktivitetsscenarier inte saktas ner eller kvävs av för många rigorösa processer.

  • Samarbete: Processen för att definiera föreslagna ändringar av arbetsbelastningen bör vara ett samarbetsarbete. De flesta ändringar av arbetsbelastningen påverkar flera funktioner och komponenter, så om du involverar så många arbetsbelastningsteammedlemmar som möjligt kan du se till att viktiga överväganden inte missas och att alla är medvetna om effekten på deras specifika domän. Samarbete hjälper också till att tydligt definiera omfattningen av en ändring och hur man delar upp de nödvändiga uppgifterna i väldefinierade arbetsobjekt. En större grupp med expertis inom olika områden kan tillhandahålla erfarenhetsstödda uppskattningar för den insats som krävs.

  • Verktyg: Använd etablerade, branschbeprövade verktyg och processer, som Agile-, Scrum- och Kanban-tavlor.

Kompromiss: Agil metodik kan bli för strikt om den är alltför föreskrivande. Sträva efter en balans mellan väldefinierade standarder och innovation.

  • Distribution: Planera att använda frekventa små, iterativa distributioner i stället för stora, ovanliga distributioner.

  • Villkor: Standardisera din definition av färdiga utvecklingscykler för att säkerställa att stödfunktioner, inklusive testning, dokumentation och tillgänglighetsfunktioner, slutförs framgångsrikt.

  • Kommunikation: Definiera standardprotokoll för produktägare och projektledare för att främja kommande versioner.

  • Användarberättelser: Standardisera en mall för användarberättelser. Välskrivna användarupplevelser bör följa INVEST-metoden:

    • I–Independent: Varje användarupplevelse bör vara oberoende av andra så att teamet kan leverera i små inkrementella steg.
    • N–Negotiable: Användarupplevelsen bör vara förhandlingsbar och öppen för diskussion och förändring.
    • V–Värdefullt: Användarberättelser ska ge värde till kunden.
    • E–Estimable: Användarupplevelser bör vara uppskattningsbara och ha en tydlig definition av slutförande.
    • S–Small: Användarupplevelser bör vara små och fokusera på en enskild funktion.
    • T–Testbar: Användarupplevelser bör vara testbara och ha tydliga acceptanskriterier.
  • Godkännandekriterier: Standardisera en mall för godkännandekriterier. Se till att acceptanskriterierna specifikt relaterar till användarupplevelsen och kan otvetydigt bevisas med hjälp av ett eller flera acceptanstester.

  • Spårning: Se till att utvecklingsprocessen är spårbar. Du bör tydligt kunna spåra produktionsarbetsbelastningens status och den tillhörande koden tillbaka till kvalitetssäkringstest, acceptanskriterier, användarupplevelser och funktioner. Detaljerad spårning kan också vara ett lagstadgat krav i vissa fall, till exempel inom hälso- och sjukvården.

  • Granskning: Utför regelbundet interna revisioner av dina utvecklingsmetoder genom retrospektiv och postmortems i utvecklingscykeln. Processreflektionen bör vara klanderfri och fokusera på lärdomar som kan användas som förbättringar. Se till att teamet reflekterar över hur effektivt användarupplevelsen och uppgifterna var när de definierar de nödvändiga uppgifterna och hur korrekta tidsuppskattningarna är.

  • Rapporter: Standardisera rapporter för intressenter som ger användbara mätvärden med fokus på förändring. Genom att fokusera på förändring kan du spåra produktacceleration och deceleration. Användbara mått kan vara ändringar i:

    • Månatlig ökningstakt för införande
    • Resultat
    • Utbildningstid
    • Incidentfrekvens

    Rapportering bör inte användas som ett verktyg för att utvärdera enskilda personers arbete, så undvik mått som story points eller kodrader för varje tekniker.

Underlätta Power Platform

Även om det Dit inte finns några Power Platform produkter som direkt underlättar denna rekommendation kan du använda andra verktyg i stacken Microsoft . Azure Boards är en webbaserad tjänst som gör det möjligt för team att planera, spåra och diskutera arbete under hela utvecklingsprocessen.

GitHub Projects är ett anpassningsbart projektledningsverktyg för att organisera projekt och integreras med dina problem och pull-begäranden i GitHub.

Gå vidare