Rekommendationer för formalisering av programutveckling och hantering

  • Artikel

Gäller för denna checklista för Azure Well-Architected Framework Operational Excellence:

OE:03 Formalisera programvaruidéer och planeringsprocesser. Hämta från etablerade bransch- och organisationsstandarder. Använd en gemensam, prioriterad kvarvarande uppgifter och tillräckligt detaljerade specifikationer. Baserat på resultat ger kontinuerliga förbättringar i planeringsprocessen.

Den här guiden beskriver rekommendationerna för att hantera metoder för programvaruutveckling i enlighet med etablerade standarder. Teamets förmåga att producera programvara av hög kvalitet bygger på ett strukturerat, samarbetsinriktat tillvägagångssätt för utvecklingsplanering. Produktägare och chefer måste tydligt kunna förstå och formulera för intressenterna det arbete som utvecklare utför när som helst i en utvecklingscykel. Utvecklarna måste däremot förstå målen för utvecklingscykeln via välskrivna funktioner, användarberättelser och acceptanskriterier. 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 kring mål och förväntningar.

Viktiga designstrategier

Formalisera dina metoder för programvaruutveckling för att säkerställa att produktägare, projektledare och utvecklare förstår målen för varje sprint och levererar konsekvent kvalitet till intressenterna. Mer information om utvecklingsmetoder finns i guiden för kontinuerlig integrering.

Standarder för utvecklingsplanering

  • Samarbete: Processen för att definiera föreslagna ändringar i arbetsbelastningen bör vara ett samarbete. De flesta ändringar av arbetsbelastningen påverkar flera funktioner och/eller komponenter, så att så många medlemmar i arbetsbelastningsteamet som möjligt kan hjälpa till att säkerställa att viktiga överväganden inte missas och att alla är medvetna om hur deras domän påverkas. Samarbete hjälper också till att tydligt definiera omfattningen av en ändring och hur du delar upp nödvändiga uppgifter som behövs för att utföra ändringen i väldefinierade arbetsobjekt, eftersom en större grupp med expertis över domäner kommer att kunna tillhandahålla erfarenhetsbaserade uppskattningar för den nödvändiga ansträngningen.

  • Verktyg: Använd etablerade, branschbeprövade verktyg och processer, som Agile, Scrum och Kanban boards. Att utveckla egna verktyg och processer är ett viktigt åtagande och tar tid och utvecklingscykler som annars skulle kunna spenderas på din arbetsbelastning. De flesta erfarna DevOps-tekniker och produktägare är bekanta med dessa typer av verktyg och processer, så inlärningskurvan vid implementering av dem bör vara minimal. På samma sätt kommer registreringsprocessen för nyanställda också att dra nytta av att använda standardverktyg och processer eftersom de sannolikt redan har en viss exponering för samma verktyg och processer.

Kompromiss: Agil metodik kan bli för strikt om den är alltför normativ. 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 sällan förekommande distributioner. Med den här metoden kan du hålla användarberättelser och arbetsobjekt hanterbara ur projekthanteringssynpunkt och minska risken för storskaliga problem när distributioner misslyckas.

  • Termer: Standardisera din definition av färdiga utvecklingscykler för att säkerställa att stödfunktioner, inklusive testning, dokumentation och hjälpmedelsfunktioner, har slutförts.

  • Kommunikation: Definiera standardprotokollen för produktägare och projektledare för att marknadsföra kommande versioner internt och externt. Du kan till exempel upprätta en standard för kommunikation till externa parter om kommande versioner. Standarden kan kräva att kommunikationen skickas två veckor före lanseringen och att en påminnelse ska skickas 24 timmar före lanseringen.

  • Användarberättelser: Standardisera en mall för användarberättelser. Se till att varje användarberättelse är en diskret arbetsenhet som skrivits ur slutanvändarens perspektiv. Välskrivna användarberättelser bör ha följande egenskaper:

    • Varje användarberättelse bör vara helt oberoende av varandra. Att hålla användarberättelser oberoende av varandra undviker all förvirring med överlappande arbete och hjälper teamet att förstå om arbetet med en viss användarberättelse förlitar sig på arbetet på andra, vilket hjälper till med schemaläggning och prioritering.

    • Varje användarberättelse är förhandlingsbar. Både slutanvändarens och arbetsbelastningsgruppens medlemmars perspektiv är viktiga för att samla in realistiska användarberättelser som kan utföras under en kort tid.

    • Användarberättelser är värdefulla för slutanvändaren. När du skriver användarberättelser ur slutanvändarens perspektiv samlar du in de ändringar som de är intresserade av att se och som ger mervärde till deras upplevelse. Om du behåller det här fokuset när användarberättelsen är uppdelad i arbetsobjekt kan du se till att varje distribution ger en bättre upplevelse.

    • Det arbete som krävs för en användarberättelse kan uppskattas med hög grad av tillförsikt. Utan att kunna ha en nära uppskattning av de timmar som krävs för en viss användarberättelse blir planeringen svår och risken för saknade tidsgränser ökar, vilket kan orsaka sammanhängande effekter på annat planerat arbete.

    • Välskrivna användarberättelser är små, så att de kan slutföras inom några veckor. Mindre omfångsberättelser hjälper till att hålla dem estimable och hanterbara och hjälper till att hålla arbetsobjekten åstadkomliga.

    • Användarberättelser bör vara testbara. Utan att kunna testa att en funktion har levererats kan slutanvändaren inte vara säker på att målet har uppnåtts. Även om ett test inte redan har skrivits för en viss användarberättelse bör det finnas en tydlig förståelse för hur ett test kan utvecklas för att bevisa leveransen av funktionen.

  • Godkännandekriterier: Standardisera en mall för godkännandekriterier. Se till att godkännandekriterierna är specifikt relaterade till användarberättelsen och kan entydigt bevisas med hjälp av ett eller flera godkännandetester.

  • Spårning: Se till att utvecklingsprocessen kan spåras. Du bör tydligt spåra tillståndet för din produktionsarbetsbelastning och den associerade koden tillbaka till kvalitetssäkringstestning, godkännandekriterier, användarberättelser och funktioner. Detaljerad spårning kan också vara ett regelkrav i vissa fall, till exempel hälso- och sjukvård.

  • Granska: Utför regelbundet interna granskningar av dina utvecklingsmetoder via utvecklingscykelns retrospektiv och postmortems. Processreflektion bör vara skuldfri och bör fokusera på lärande som kan tillämpas som förbättringar. Se till att teamet reflekterar över hur effektivt användarberättelsen och uppgifterna var när det gäller att definiera nödvändiga uppgifter och om noggrannheten i tidsuppskattningar.

  • Rapporter: Standardisera rapporter för intressenter som tillhandahåller användbara mått som fokuserar på förändring. Med fokus på förändring kan du spåra produktacceleration och inbromsning. Användbara mått kan innehålla ändringar i:

    • Den månatliga tillväxttakten för införandet.

    • Prestanda.

    • Träningstid.

    • Frekvensen för incidenter.

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

Azure-underlättande

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. Den passar bra för agilbaserade utvecklingsmetoder.

GitHub Projects är ett anpassningsbart projekthanteringsverktyg som kan organisera projekt och integrera med hjälp av problem och pull-begäranden i GitHub.

Checklista för utmärkt drift

Se den fullständiga uppsättningen rekommendationer.

Checklista för utmärkt drift