Styring af fælles udvikling
Etablering af en effektiv ramme for styring af fælles udvikling er afgørende for at sikre ensartethed og gentagelser i udviklerdefinerede projekter og fusionsteams. I denne artikel beskrives en fremgangsmåde til definition af et rutediagram til styringsformål.
Definition af hele processen
Du kan bruge følgende proces som et eksempel og tilpasse den til din organisations bedste praksis. Det er ikke nødvendigt at fuldføre hvert enkelt trin, så længe du opnår det påkrævede resultat.
Føje funktioner til efterslæb
Efterslæb giver dig mulighed for at planlægge projektet ved at tilføje funktioner, der skaber den samlede oplevelse. Efterslæbet indeholder også den overordnede plan, som teamet skal leve op til.
Når du føjer en ny funktion til efterslæbet, er målet at beskrive det generelle omfang. De enkelte funktioner definerer derefter forretningsværdien, kladdefortællingstitler, omfang og ændringer af datamodeller, der driver kodeudviklingsindsatsen.
Når du tilføjer en forretningskritisk funktion, anbefales det desuden, at du identificerer eventuelle vigtige scenarier for at automatisere testen. Når du har tilføjet en eller flere funktioner, kan du planlægge et møde om justering af omfang.
Møde om justering af omfang
Fokus for dette møde bør være begrænset til at gennemgå alle forslag til nye funktioner og derefter kontrollere, om der er eksisterende apps, scenarier eller datamodeller, der allerede har denne funktion, for at undgå dobbeltindsats. På dette møde kan du også diskutere, hvordan det påvirker andre apps. Til sidst skal du kontrollere, om denne funktion kræver en erfaringsgennemgang.
Tilføje fortællinger og handlingsplan i efterslæb
Efter mødet om justering af omfang kan alle kladdetitler til brugerfortællinger tilføjes under funktionen. På dette tidspunkt er der ikke brug for detaljer, og status for brugerhistorien er "Ny". Du kan se historier i enten efterslæbs- eller i handlingsplanvisningen.
I følgende figur vises et eksempel på en brugerfortælling, der er føjet til et efterslæb.
På dette tidspunkt er det vigtigt at bevare kvaliteten ved at organisere arbejdet efter arbejdsstrøm og program. Denne fremgangsmåde hjælper med at holde relaterede arbejdselementer sammen og gør det muligt for eksperter i de enkelte arbejdsstrømme at udvikle og bevare en dyb forståelse af funktionaliteten og dataforbruget i de enkelte apps.
Erfaringsgennemgang
Erfaringsgennemgange skal fokusere på slutbrugerens oplevelse og sikre, at dit team følger de bedste fremgangsmåder i organisationen. Denne ensartethed sikrer, at alle dine apps giver en pålidelig og gentagelig oplevelse for slutbrugere og supportteams.
Tilføje fortællingsdetaljer
Hvis du tilføjer en typisk brugerfortælling, kan følgende oplysninger være indarbejdet:
- Titel: Som <persona> kan jeg <do something>, så <impact/priority/value>
- Beskrivelse: Beskrivelsen indeholder (selvom den ikke er begrænset til) visse nøgledetaljer, f.eks.:
- Kort beskrivelse af det scenario, der opsummerer det ønskede resultat
- Narrativ – beskriver de handlinger, brugerne skal udføre for at navigere i og opnå scenariet
- Alternativ narrativ – beskriver andre måder, brugere kan opnå det samme resultat på
- Designnoter – registrerer objekter, felter, visninger, skitser og forretningsregler, der er knyttet til brugerfortællingen
- Influerede sikkerhedsroller– viser alle de sikkerhedsroller, der er påvirket, eller som er relevante for brugerfortællingen.
Når du har tilføjet alle disse detaljer, skal du ændre status for brugerfortællingen til "Klar til gennemsyn". I de fleste tilfælde gennemgår funktionsteamet og forretningsteamet (hvis det er relevant) brugerfortællingerne.
Fortællingsgennemgang
Fortællingsgennemgange foregår typisk i fusionsteamet for at sikre, at alle detaljer bliver nævnt i fortællingen, og at der ikke er tvivl om noget. Når alle gennemgange er foretaget, anbefales det, at brugerfortællingen tildeles til et teammedlem. At sikre, at dit team forbliver koordineret under udviklingsprocessen, er afgørende for at opnå det overordnede mål.
Tilføje opgaver og testsager
Efter gennemgang af fortællingerne kan teammedlemmerne oprette opgaver i Azure DevOps. Den overordnede proces til tilføjelse af opgaver og testsager er følgende:
- Åbn et sprintefterslæb. Du kan også oprette et nyt sprint.
- Føj eksisterende arbejdselementer til sprintet. Hvis du allerede har tilføjet arbejdselementer, der ikke vises i sprintet, skal du kontrollere deres område og gentagelsesstier. Husk at tildele ikke-placerede opgaver til de relevante arbejdselementer.
- Føj opgaver til efterslæbselementer. Hvis du ikke har tildelt efterslæbselementer til sprintet, skal du gøre det nu. Angiv også start- og slutdatoer for sprintet.
- Udfyld opgaveformularen. Som regel bør det ikke tage længere tid at udføre opgaver end en dag. Opgaver, der er større end denne tidsramme, skal opdeles.
- Spor eller integrer ikke-placerede opgaver. Du kan spore ikke-placerede opgaver på samme måde som andre opgaver eller trække dem til et eksisterende efterslæbselement for at placere dem hos et overordnet.
Når du har tilføjet opgaver og testsager, kan du gå videre til at angive sprintkapacitet.
Du kan finde flere oplysninger om tilføjelse af opgaver under Føj opgaver til efterslæbselementer for at understøtte planlægning af sprint.
Klargøre løsninger
Et vigtigt element for en vellykket medudvikling er en struktureret udgivelsesstyringsproces. Løsninger er den mekanisme, der bruges til implementering af Administration af programlivscyklus (ALM), og du bruger løsninger til at distribuere komponenter på tværs af miljøer ved hjælp af eksport og import. En komponent repræsenterer en artefakt i dit program og noget, som du kan tilpasse. Alt, hvad der kan inkluderes i en løsning, er en komponent, f.eks. tabeller, kolonner, lærred- og modelbaserede apps, Power Automate-flows, chatrobotter, diagrammer og plug-ins.
Vigtigt
Under planlægningen af udgivelsen skal du fastlægge strategien for administration af løsninger i projektet. Du kan bruge løsninger til at administrere projektet og nemt finde komponenter, du har oprettet, og derefter distribuere til andre miljøer.
Installationer
Komponenterne kan have flere sprints, afhængigt af kompleksiteten og teamhastighed. Komponenter skal føjes til en løsning i et udviklingsmiljø, efterhånden som opgaver fuldføres. Løsninger importeres derefter til et produktionsmiljø, når de er testet. Det anbefales, at du også vedligeholder ét testmiljø, så du kan udføre en total test og afprøve løsningsinstallationen, inden du går i produktion.
Power Platform-miljøer
Miljøer er et område til at gemme, administrere og dele din organisations forretningsdata, apps og forretningsprocesser. De fungerer også som objektbeholdere, der kan adskille apps, der kan have forskellige roller, sikkerhedskrav eller målgrupper.
Hvis din organisation har mange teams, hvor de enkelte teams udvikler deres egne løsninger, er det vigtigt at koordinere varigheden af sprints og udgivelser. Sprints behøver ikke at have en ensartet længde på en projekttidslinje og kan variere i varighed mellem teams efter de enkelte gruppers præferencer. Udgivelsestakten må dog ikke være mindre end den korteste sprintvarighed på tværs af alle teams.
Kildekontrol
Overvej at implementere et kildekodekontrolsystem som f.eks Azure DevOps. Azure DevOps tilbyder udviklingstjenester til supportteams, så de kan planlægge arbejde, samarbejde om kodeudvikling samt opbygge og installere applikationer.
Eksportér en løsning fra dit udviklingsmiljø, der indeholder dine apps og tilpasninger, Pak din løsning ud, og gem komponenterne i kildekontrolsystemet.
Avanceret emne: Gennemgange af pull-anmodning
Du skal kun oprette pull-anmodning for aktive historier, der har fået gennemgået og godkendt funktioner. Du skal sikre, at løsningsversioner er nøjagtige og følger de retningslinjer for sprint og udvikling, der er angivet i Implementere Scrum-praksis for dit team i Azure Boards. Testresultater fra pull-anmodning kan være skærmbilleder eller videoer, der afspejler den funktionalitet, der bygges.
Automatisering af styringsprocessen for pull-anmodninger er med til at sikre kodekvaliteten uden at kræve en manuel gennemgang af grundlæggende kontroller, f.eks. løsningsversioner.
Bemærk
Brug kontrolværktøjet for pull-anmodninger til at automatisere processen til kontrol af pull-anmodninger.
Skabeloner og standardisering
Skabeloner og standarder sikrer effektivitet ved at gøre teamet mere koordineret. Alle aspekter af teamets drift—, uanset om det er onboarding-opgaver, præsentationer af historiegennemgang eller workflowopgaveskabeloner , der hjælper med at spare tid og giver vejledning til teams, når de definerer brugerhistorier, funktioner, fejl eller opgaver—, drager fordel af standardisering og forenkling.
Implementering af en effektiv supportmodel
En effektiv supportmodel er vigtig for at opnå succes på den lange bane for et program efter dets udrulning, som det blev fremhævet i det tidligere afsnit om oprettelse af en supportmatrix. Der er både problemer og udfald, så det er vigtigt, at teamet har en struktureret fremgangsmåde, så de kan håndtere disse forekomster, og supportmatrixen giver de nødvendige rammer.
Oprettelse af serviceaftaler
En væsentlig faktor i enhver supportmodel er definitionen af serviceaftaler (SLA - Service Level Agreement). SLA skal være et formelt dokument, som teamet udarbejder og indeholder sektioner, der dækker følgende punkter:
- Udfald – hvilket niveau af serviceudfald kan accepteres, hvem skal informeres, hvilke handlinger skal udføres, bekræftelse af genoptagelse af driften og handlinger for at forhindre en gentagelse. Alle automatiserede testprocedurer, som teamet bruger, skal indrettes efter den forventede udfaldstolerance og den gældende SLA.
- Fejl – hvem kan give besked, tildeling af alvorlighedsniveauer, klassificering, handlinger ved påvisning, hvem er ansvarlig for løsning og signering.
- Eskaleringer – eskaleringsniveauer, tildeling af medarbejdere til niveauer, ansvarsområder på de enkelte niveauer, distributionslister for de enkelte niveauer osv.
SLA'en skal gemmes på teamets dokumentationsportal og opdateres efter behov.
Levering af programsupport
Den bedste fremgangsmåde til at levere den programsupport, der er angivet i SLA'en, er, at det team, der har oprettet løsningen, også er ansvarligt for at understøtte den. Fordelene ved dette system er:
- Det opfordrer til udvikling af bedre kvalitet, da de, der har oprettet appen, ved, at de skal understøtte den.
- Skaberne kan finde og reparere fejl hurtigere end et tredjepartsteam, blot fordi de kender appen bedre.
- Delegering af reparationen af potentielt forretningskritisk software til en anden gruppe kan være demoraliserende og tidskrævende for den pågældende gruppe. På samme måde som med andre faser i oprettelse, udvikling og installation af programmet skal fusionsteamet samarbejde med it-afdelingen for at få hjælp, når det er nødvendigt.
Overvågning af programtilfredshed og anvendelighed
Det sidste led i supportindsatsen er at overvåge og vurdere tilfredsheden og anvendeligheden af den installerede app. Metrikværdier er nyttige her sammen med mere traditionelle metoder, f.eks. polling og spørgeskemaer. Du kan finde flere oplysninger om overvågning af appforbrug i Administrationsanalyser til Power Apps.
Hvis kunderne ikke bruger en udgivet app, indfrier appen i sidste ende ikke formålet. Jævnlige statusmøder kan kontrollere metrikværdier for tilfredshed og anvendelighed, så der oprettes en positiv feedbackløkke, som kan ændre eller føje fortællinger til efterslæbet for at oprette og derefter udrulle en opdateret version af appen.
Opsamling
Udviklingen af Power Apps-værktøjer uden kode eller med lidt kode har givet udvidede muligheder for forretningsteknologer og udviklere til at oprette, udvikle og installere apps. Denne udvikling fungerer bedst i et fusionsteammiljø, hvor en produktejer, en domæneekspert, en professionel udvikler og en administrator kan bruge andre ressourcer efter behov.
Integration af fleksible Scrum-udviklingsmetoder i fusionsteams resulterer i hurtigere appudvikling og en større sandsynlighed for en vellykket installation med et funktionssæt, der gør en stor forskel for virksomheden. Når du anvender disse bedste praksisser, retningslinjer og anbefalinger, kan dit fusionsteam bruge Power Apps til at håndtere udfordringer i forbindelse med din organisations digitale transformation.