Rekommendationer för formalisering av programutveckling och hantering

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

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å en strukturerad samarbetsmetod för utvecklingsplanering. Produktägare och chefer måste kunna förstå och formulera det arbete som utvecklare utför när som helst under en utvecklingscykel för intressenterna. Omvänt måste utvecklare 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 intressenter. Mer information om utvecklingsmetoder finns i guiden för kontinuerlig integrering.

Upprätta samarbets- och kommunikationsstandarder

• Samarbete: Processen för att definiera föreslagna ändringar av arbetsbelastningen bör vara ett samarbete. De flesta ändringar i arbetsbelastningen påverkar flera funktioner och/eller komponenter, så om du involverar så många medlemmar i arbetsbelastningsteamet som möjligt kan du se till att viktiga överväganden inte missas och att alla är medvetna om hur deras specifika domän påverkas. Samarbete hjälper också till att tydligt definiera omfånget för en ändring och hur du delar upp de uppgifter som krä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.

• Kommunikation: Definiera standardprotokollen för produktägare och projektledare för att främja 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.

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

• Rapporter: Standardisera rapporter för intressenter som ger 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.

Välj branschstandardverktyg

Använd etablerade, branschbeprövade verktyg och processer, till exempel Agile-, Scrum- och Kanban-tavlor. Att utveckla egna verktyg och processer är ett betydande åtagande, vilket 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 införandet 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 kommer att ha 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.

Anta en standard för att avbilda slutanvändarscenarier

• 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ändarhistoria 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 arbetsbelastningsteamets 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 från slutanvändarens perspektiv samlar du in de ändringar som de är intresserade av att se och som ger mervärde till deras upplevelse. Genom att hålla fokus 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 förtroende. 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älpa till att hålla arbetsobjekten uppnåeliga.

  • Användarberättelser bör vara testbara. Utan att kunna testa att en funktion har levererats kan slutanvändaren inte ha förtroende för 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 acceptanskriterier specifikt relaterar till användarberättelsen och kan bevisas otvetydigt med hjälp av ett eller flera godkännandetester.

Standardisera distributionsmetoder

• 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 från 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.

• 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, acceptanskriterier, användarberättelser och funktioner. Detaljerad spårning kan också vara ett regelkrav i vissa fall, till exempel hälso- och sjukvård.

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 i hela utvecklingsprocessen. Det passar bra för agilbaserade utvecklingsmetoder.

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

Relaterade länkar

• Metodtips för agil projekthantering
• Azure Boards

Communitylänkar

• GitHub Projects

Checklista för driftskvalitet

Se den fullständiga uppsättningen rekommendationer.