Samutvecklingsstyrning

Att upprätta ett effektivt ramverk för samutvecklingsstyrning är en viktig del för att säkerställa konsekvens och repeterbarhet i tillverkardefinierade projekt och fusion teams. I den här artikeln beskrivs en metod för att definiera ett flödesschema för styrning.

Definiera komplett process

Du kan använda följande process som exempel och anpassa den efter organisationens metodtips. Det är inte nödvändigt att slutföra varje enskilt steg så länge du uppnår det resultat som krävs.

Lägga till funktioner i eftersläpning

Med eftersläpningar kan du planera ditt projekt genom att lägga till funktioner som ökar helheten. Den eftersläpning som teamet har för avsikt att leverera ger också en övergripande information.

När man lägger till en ny funktion till eftersläpningen är målet att beskriva den allmänna omfattningen. Varje funktion definierar sedan affärsvärdet, utkast till berättelsetitlar, omfattning och datamodelländringar som driver kodutvecklingsinsatserna.

Dessutom, när du lägger till en affärskritisk funktion, rekommenderas du att identifiera alla kritiska scenarier för att automatisera din testning. När du har lagt till dina funktioner kan du schemalägga ditt omfattningsanpassningsmöte

Omfattningsanpassningsmöte

Fokus för det här mötet bör begränsas till att granska alla föreslagna nya funktioner och sedan kontrollera om det finns appar, scenarier eller datamodeller som redan innehåller den här funktionen för att undvika dubblering av åtgärder. Det här mötet ger också möjlighet att diskutera påverkan på andra appar. Slutligen bör du kontrollera om den här funktionen kräver en erfarenhetsrecension.

Lägg till berättelser och storyboard till eftersläpning

Efter mötet med omfattningsanpassning kan alla utkast till användarberättelser läggas till under funktionen. Så här mycket behöver du inte ha information och statusen på användarartikeln är "Ny". Du kan visa information antingen i eftersläpande vy eller i schemaläggningsvyn.

I följande figur visas en exempelartikel som har lagts till i en eftersläpning.

I det här läget är det viktigt att upprätthålla kvaliteten genom att organisera arbetet efter arbetsflöden och program. Den här metoden hjälper dig att hålla ihop relaterade arbetsobjekt och gör det möjligt för experter i varje arbete att utveckla och behålla en djupare förståelse av funktionerna och dataanvändningen i varje app.

Erfarenhetsrecension

Erfarenhetsgranskningar bör fokusera på slutanvändaren och se till att ditt team följer organisationens bästa arbetssätt. Konsekvensen säkerställer att alla dina appar ger en pålitlig och repeterbar upplevelse för slutanvändare och supportteam.

Lägg till berättelseinformation

Om du lägger till en typisk användarartikel kan följande information finnas:

1. Titel: Som en <persona>, kan jag <do something> så att <impact/priority/value>
2. Beskrivning: Beskrivningen innehåller (även om den inte är begränsad till) vissa viktiga detaljer, till exempel:
   • Kortfattad beskrivning av scenariot som sammanfattar det önskade resultatet
   • En beskrivning av vilka åtgärder användarna kommer att vidta för att navigera i scenariot
   • Alternativ lösning – beskriver andra sätt för användare att uppnå samma resultat
   • Designanteckningar – registrerar entiteten, fälten, vyer, skärmar och affärsregler som är associerade med användarartikeln
   • Säkerhetsroller som påverkas – listar alla säkerhetsroller som har påverkats eller är relevanta för användarartikeln.

När du har lagt till all information ändrar du tillståndet för användarartikeln till "Klar för granskning". I de flesta fall granskar funktionsteamet och affärsteamet (om tillämpligt) användarprofilen.

Artikelrecension

Berättelserecensioner inträffar oftast i teamet för att se till att all information är med i storyn och att det inte finns någon tvetydighet. När alla granskningar har slutförts rekommenderar vi att du tilldelar en teammedlem en användarartikel. Se till att ditt team fortsätter att vara i linje under utvecklingsprocessen.

Lägga till uppgifter och testfall

När teammedlemmarna har granskat programmet skapar de uppgifter i Azure DevOps. Den övergripande processen för att lägga till uppgifter och testfall är som följer:

1. Öppna en eftersläpning. Du kan också skapa en ny lösning.
2. Lägg till befintliga arbetsobjekt i sprint. Om du redan har lagt till arbetsobjekt som inte visas i arbetsområdet bör du kontrollera deras område och iterationssökvägar. Kom ihåg att tilldela eventuella uppgifter som saknar överordnade till relevanta arbetsobjekt.
3. Lägg till uppgifter i eftersläpade objekt. Om du inte har tilldelats eftersläpade objekt gör du det nu. Ange även start- och slutdatum för sprint.
4. Fyll i det här formuläret. Som tumregel bör det inte ta längre än en dag att utföra uppgifter. Uppgifter som är större än den här tidsskalan ska delas upp.
5. Spåra eller integrera uppgifter som saknar överordnade. Du kan spåra uppgifter som saknar överordnade precis som andra uppgifter eller dra dem till ett befintligt eftersläpande objekt till överordnat objekt.

När du har lagt till uppgifter och testfall kan du sedan ange kapacitet.

Mer information om hur du lägger till uppgifter finns i Lägga till uppgifter i eftersläpning objekt som stöd för planering.

Förbered lösningar

En viktig aspekt av en lyckad utveckling är en strukturerad releasehanteringsprocess. Lösningar är mekanismen för att implementera hantering av programmets livscykel (ALM); du använder dem för att distribuera komponenter mellan miljöer via export och import. En komponent representerar en artefakt som används i din app och något som du eventuellt kan anpassa. Allt som kan ingå i en lösning är en komponent som tabeller, kolumner, flödes- och modellbaserade appar, Power Automate flöden, chattscheman, diagram och plugin-program.

Distributioner

Det kan ta flera komponenter att slutföra beroende på komplexiteten och teamets komplexitet. Komponenter bör läggas till till en lösning i en utvecklingsmiljö när uppgifterna slutförs. Lösningar importeras sedan till en produktionsmiljö efter att de har testats. Vi rekommenderar att du även upprätthåller en testmiljö för att utföra kompletta tester och prova en lösningsdistribution innan du går till produktion.

Power Platform-miljöer

Miljöer är ett utrymme där du lagrar, hanterar och delar din organisations verksamhetsdata, appar och verksamhetsprocesser. De fungerar också som behållare för olika appar som kan ha olika roller, säkerhetskrav eller målgrupper.

Om organisationen har ett installationsprogram med flera team där varje team utvecklar sina egna lösningar är det viktigt att koordinera varaktigheten för produkter och versioner. Sprintar behöver inte vara av en konsekvent längd längs en projekttidslinje och kan variera i längd mellan team, enligt varje grupps preferenser. Utgåvor som släpps kan dock inte vara mindre än den kortaste sprintvaraktigheten för alla team.

Källkontroll

Överväga att implementera ett system för källkodskontroll, exempelvis Azure DevOps. Azure DevOps tillhandahåller utvecklingstjänster för supportteam som planerar arbete, samarbetar med kodutveckling och skapar och distribuerar program.

Exportera en lösning från utvecklingsmiljön som innehåller appar och anpassningar, packa upp din lösning och lagra komponenterna i källkontrollsystemet.

Avancerad ämne: Pull-begäran (PR)

Du bör endast skapa PRs för aktiva funktioner som har funktioner som granskas och godkänns. Du bör se till att lösningsversionen är korrekt, följa sprint- och utvecklingsriktlinjerna som anges i Implementera Scrum-praxis för ditt team i Azure Boards. Testresultat från PR kan vara skärmbilder eller videoklipp som beskriver den funktion som byggs.

Genom att automatisera PR-styrningsprocessen kan du säkerställa kodkvaliteten utan att det krävs en manuell granskning av grundkontroller, till exempel lösningsversioner.

Mallar och standardisering

Mallar och standardisering ger effektivitet genom att hjälpa till att öka enhetligheten i teamet. Alla aspekter av teamets verksamhet, oavsett om det är registreringsuppgifter, presentation av artikelrecension eller arbetsobjektmallar som hjälper till att spara tid och ge vägledning för team när de definierar användarfunktioner, funktioner, korrigeringar eller uppgifter har nytta av standardisering och arbete.

Implementera en effektiv supportmodell

En effektiv supportmodell är mycket viktig för ett programs framgång på lång sikt efter distributionen. Det finns också ett tidigare avsnitt om att skapa en supportmatris. Det är därför som teamet har en strukturerad metod för att hantera de här händelserna, och supportmatrisen tillhandahåller det ramverk som krävs.

Skapa servicenivåavtalet

En viktig faktor i alla supportmodeller är definitionen av SLA (serviceavtal). Serviceavtalet bör vara ett formellt dokument som teamet upprättar med avsnitt som omfattar följande:

• Driftavbrott – vilken servicenivå som kan accepteras, vem som ska informera, vilka åtgärder som ska vidtas, bekräfta att tjänsten återupptas och åtgärder för att förhindra en upprepande åtgärd. Alla automatiserade testprocedurer som teamet använder måste anpassas efter det förväntade avbrottet och det tillämpliga standardserviceavtalet.
• Buggar – vem som kan meddela, tilldelning av säkerhetsnivåer, klassificering, åtgärder för identifiering, vem som är ansvarig för att lösa och stänga.
• Eskaleringar – eskalera nivåer, tilldelning av personal till nivåer, ansvar på varje nivå, distributionslistor för varje nivå och så vidare.

Serviceavtalet bör lagras i teamets dokumentationsportal och uppdateras vid behov.

Leverera programstöd

Den bästa metoden för att leverera programstöd som anges i licensavtalet är att det team som skapade lösningen också ansvarar för att stödja den. Fördelarna med detta system är:

1. Det uppmuntrar till bättre utveckling, eftersom de som har skapat appen vet att de kommer att behöva stöd för den.
2. Skaparna kan hitta och åtgärda problem snabbare än ett team från tredje part, bara för att de känner till appen bättre.
3. Att delegera korrigering av potentiellt verksamhetskritisk programvara till en annan grupp kan ge upphov till missmod och vara tidskrävande för den gruppen. Precis som med andra faser av programgenerering, utveckling och distribution bör teamet samarbetar med IT för hjälp när det behövs.

Övervaka programtillfredsställelse och användbarhet

Den sista delen av supporten är att övervaka och kontrollera hur nöjd och användbarhet den distribuerade appen är. Mått är användbara här tillsammans med mer traditionella metoder, som avsökning och enkäter. Mer information om hur du övervakar appanvändning finns i Administratörsanalys för Power Apps.

Om kunderna inte använder en publicerad app uppfyller den inte syftet. Med regelbundna granskningsmöten kan du kontrollera dessa mått för tillfredsställelse och användbarhet och skapa en positiv feedbackloop som kan ändra eller lägga till information i eftersläpningar för att skapa och sedan distribuera en uppdaterad version av appen.

Sammanfattning

Utvecklingen av verktyg utan kod och med lite kod som t.ex. Power Apps har utökade möjligheter för affärsteknologer eller tillverkare att skapa, utveckla och distribuera appar. Den här utvecklingen fungerar bäst i en teammiljö där teamet får ta hjälp av en produktägare, en domänexpert, ett teamexpert och en administratör. Teamet tar in andra resurser efter behov.

Om de använder smidiga metoder och utvecklingsmetoder inom olika fusion teams går det snabbare att utveckla appar och att det går snabbare att distribuera dem med en funktionsuppsättning som gör skillnad på verksamheten. Genom att tillämpa dessa bästa metoder, riktlinjer och rekommendationer kommer ditt fusion teams att kunna använda Power Apps för att hantera organisationens utmaningar med den digitala omvandlingen.