Medutviklingsstyring
Det er viktig å etablere et effektivt rammeverk for koutviklingsstyring for å sikre ensartethet og repeterbarhet i beslutningsdefinerte prosjekter og fusjonsteam. Denne artikkelen beskriver en metode for å definere et flytskjema for styring.
Definere ende-til-ende-prosessen
Du kan bruke følgende prosess som eksempel og tilpasse den etter organisasjonens gode fremgangsmåter. Det er ikke nødvendig å fullføre hvert enkelt trinn så lenge du oppnår det nødvendige resultatet.
Legge til funksjoner i restanse
Med restanser kan du planlegge prosjektet ved å legge til funksjoner som driver den totale opplevelsen. Restansen inneholder også det generelle veikartet teamet har tenkt å levere.
Når du legger til en ny funksjon i restansen, er målet å beskrive det generelle omfanget. Hver funksjon definerer deretter forretningsverdien, titler for foreløpige utkast, omfang og endringer i datamodellen som driver frem kodeutviklingsarbeidet.
Når du legger til en forretningskritisk funksjon, anbefales det i tillegg å identifisere eventuelle kritiske scenarioer for å automatisere testingen. Når du har lagt til funksjonen(e), kan du planlegge omfangsjusteringsmøtet.
Omfangsjusteringsmøte
Fokuset for dette møtet bør begrenses til å gå gjennom alle foreslåtte nye funksjoner, og deretter se etter eksisterende apper, scenarier eller datamodeller som allerede gir denne funksjonaliteten, for å unngå duplisering av arbeidet. Dette møtet gir også mulighet til å diskutere hva som skjer med andre apper. Til slutt bør du kontrollere om denne funksjonen krever en opplevelsesgjennomgang.
Legg til historier og fortellingstavle i restansen
Etter omfangsjusteringsmøtet kan eventuelle utkast til titler på brukerhistorier legges til under funksjonen. På dette punktet er det ikke nødvendig med detaljer, og statusen til brukerhistorien er "Ny". Du kan vise historier enten i restansen eller i tavlevisning.
Følgende figur viser et eksempel på en brukerhistorie som er lagt til i en restanse.
På dette punktet er det avgjørende å opprettholde kvalitet ved å organisere arbeid etter arbeidsflyt og bruksområde. Denne tilnærmingen hjelper deg med å holde relaterte arbeidselementer samlet, og gjør det mulig for eksperter i hver arbeidsflyt å utvikle og opprettholde en grundig forståelse av funksjonaliteten og databruken i hver app.
Gjennomgang av opplevelse
Gjennomganger av opplevelse bør fokusere på sluttbrukeropplevelsen og sørge for at teamet følger de beste fremgangsmåtene i organisasjonen. Denne konsekventheten sikrer at alle appene gir en pålitelig og repeterbar opplevelse for sluttbrukere og kundestøtteteam.
Legg til historiedetaljer
Ved å legge til en typisk brukerhistorie kan følgende informasjon innlemmes:
- Tittel: Som <persona> kan jeg <do something>, slik at <impact/priority/value>
- Beskrivelse: Beskrivelsen inkluderer (selv om den ikke er begrenset til) bestemte nøkkeldetaljer, for eksempel:
- Kort beskrivelse av scenarioet som oppsummerer ønsket resultat
- Fortelling – beskriver handlingene brukerne skal utføre for å navigere i og gjennomføre scenarioet
- Alternativ fortelling – beskriver andre måter brukere kan oppnå samme resultat på
- Utformingsnotater – registrerer enheten, feltene, visningene, skjermbildene og forretningsreglene som er tilknyttet brukerhistorien
- Berørte sikkerhetsroller – viser alle sikkerhetsrollene som påvirkes, eller som er relevante for brukerloggen.
Når du har lagt til alle disse detaljene, kan du endre tilstanden til brukerhistorien til "Klar for gjennomgang". I de fleste tilfeller ser funksjonsteamet og forretningsteamet (hvis aktuelt) gjennom brukerhistoriene.
Gjennomgang av historie
Gjennomganger av historier forekommer vanligvis i fusjonsteamet for å sikre at alle detaljene er fremhevet i historien, og at det ikke er tvetydighet. Når alle gjennomgangene er fullført, anbefales det at du tilordner brukerhistorien til et teammedlem. Det er svært viktig å sikre at teamet holder seg på linje under utviklingsprosessen for å nå de samlede målene.
Legg til oppgaver og testtilfeller
Etter å ha gått gjennom historiene, oppretter teammedlemmene oppgaver i Azure DevOps. Den generelle prosessen for å legge til oppgaver og testtilfeller er som følger:
- Åpne en sprintrestanse. Du kan også opprette en ny sprint.
- Legg til eksisterende arbeidselementer i sprinten. Hvis du allerede har lagt til arbeidselementer som ikke vises i sprinten, bør du kontrollere området og iterasjonsbanene deres. Husk å tilordne eventuelle oppgaver som ikke har overordnede oppgaver, til de relevante arbeidselementene.
- Legg til oppgaver i restanseelementer. Hvis du ikke har restanseelementer tilordnet til sprinten, gjør du det nå. Angi også start- og sluttdatoene for sprinten.
- Fyll ut oppgaveskjemaet. En tommelfingerregel er at det ikke skal ta mer enn en dag å fullføre oppgaver. Oppgaver som er større enn denne tidsrammen, må brytes ned.
- Spor eller integrer oppgaver som ikke har overordnede oppgaver. Du kan spore oppgaver som ikke har overordnede oppgaver, akkurat som andre oppgaver, eller dra dem til et eksisterende restanseelement til et overordnet element.
Når du har lagt til oppgaver og testsaker, kan du angi sprintkapasitet.
Hvis du vil ha mer informasjon om hvordan du legger til oppgaver , kan du se Legge til oppgaver i restanseelementer for å støtte sprintplanlegging.
Forberede løsninger
En viktig side ved vellykket samarbeidsutvikling er en strukturert prosess for utgivelsesadministrasjon. Løsninger er mekanismen for implementering av administrasjon av programlivssyklus (ALM). Du bruker løsninger til å distribuere komponenter i miljøer ved å eksportere og importere aktiviteter. En komponent representerer en artefakt som brukes i appen, og noe som du potensielt kan tilpasse. Alt som kan tas med i en løsning, er en komponent, for eksempel tabeller, kolonner, lerreter og modelldrevne apper, Power Automate-flyter, chatroboter, diagrammer og plugin-moduler.
Viktig
Under lanseringsplanlegging kan du fastsette strategien for å administrere løsninger i prosjektet. Bruk løsninger til å administrere prosjektet og enkelt finne komponenter du har opprettet, for deretter å distribuere til andre miljøer.
Distribusjoner
Komponenter kan gjennomføre flere sprinter avhengig av kompleksiteten og hastigheten til teamet. Komponenter bør legges til i en løsning i et utviklingsmiljø etter hvert som oppgavene fullføres. Løsninger importeres deretter til et produksjonsmiljø etter at de er testet. Vi anbefaler at du også vedlikeholder ett testmiljø for å utføre ende-til-ende-testing og prøve ut løsningsdistribusjon før du går til produksjon.
Power Platform-miljøer
Miljøer er et sted der du kan lagre, behandle og dele organisasjonens forretningsdata, apper og forretningsprosesser. De fungerer også som beholdere for å skille apper som kan ha ulike roller, sikkerhetskrav eller målgrupper.
Hvis organisasjonen har et oppsett med flere team der hvert team utvikler sine egne løsninger, er det viktig å koordinere varigheten av sprinter og utgivelser. Sprinter trenger ikke å ha en konsekvent lengde langs en prosjekttidslinje, og kan variere i varighet mellom teamene i henhold til hver gruppes preferanser. Utgivelseshyppigheten kan imidlertid ikke være mindre enn den korteste sprintvarigheten for alle team.
Kildekontroll
Vurder å bruke et system for kildekodekontroll som Azure DevOps. Azure DevOps inneholder utviklingstjenester for støtteteam for å planlegge arbeid, samarbeide på kodeutvikling og utvikle og distribuere apper.
Eksporter en løsning fra utviklingsmiljøet som inneholder apper og tilpassinger, pakk ut løsningen din, og lagre komponentene i kildekontrollsystemet.
Avansert emne: Pull request (PR)-omtaler
Du bør bare opprette PR-er for omtaler som er aktive, og som har fått funksjoner gjennomgått og godkjent. Du må sørge for at versjonskontroll av løsninger er nøyaktig ved å følge retningslinjene for sprint og utviling som er fremsatt i Implementer klyngepraksiser for teamet ditt på Azure-tavlene. Testresultater fra HF kan være skjermbilder eller videoer som viser funksjonaliteten som bygges.
Automatisering av HF-administrasjonsprosessen bidrar til å sikre kodekvalitet uten at du trenger manuell gjennomgang av grunnleggende kontroller, for eksempel løsningsversjoner.
Obs!
Bruk HF-kontrollverktøyet til å automatisere kontrollprosessen for henteforespørsler.
Maler og standardisering
Maler og standardisering leverer effektivitet ved å bidra til å fremme ensartethet i teamet. Alle aspekter av teamets operasjoner—, enten det er onboarding-oppgaver, historiegjennomgangspresentasjoner eller arbeidselementmaler som bidrar til å spare tid og gi veiledning til team når de definerer brukerhistorier, funksjoner, feil eller oppgaver—, drar nytte av standardisering og forenkling.
Implementering av en effektiv støttemodell
En effektiv støttemodell er svært viktig for at en app skal lykkes på lang sikt etter distribusjonen, slik det er fremhevet i den tidligere delen om generering av en støttematrise. Feil og avbrudd er uunngåelig, så det er viktig at teamet har en strukturert tilnærming til håndteringen av disse hendelsene, og støttematrisen gir det nødvendige rammeverket.
Oppretting av serviceavtalen
En viktig faktor i enhver støttemodell er definisjonen av serviceavtalen. Serviceavtalen skal være et formelt dokument som teamet utarbeider som inneholder deler som dekker følgende elementer:
- Avbrudd – hvilket serviceavbruddsnivå som kan godtas, hvem som skal informere, hvilke handlinger som skal utføres, bekreftelse av gjenopptakelse av tjenesten og handlinger for å hindre gjentakelse. Alle automatiserte testprosedyrer som teamet bruker, må tilpasses den forventede strømbruddsforløpet og gjeldende serviceavtale for serviceavtalen.
- Feil – hvem som kan varsle, tilordning av nedverdigende nivåer, klassifisering, handlinger på registrering, hvem som er ansvarlig for å løse og logge av.
- Eskaleringer – eskaleringsnivåer, tilordning av ansatte til nivåer, ansvar på hvert nivå, distribusjonslister for hvert nivå og så videre.
Serviceavtalen må lagres i teamets dokumentasjonsportal og oppdateres etter behov.
Levering av appstøtte
Den beste metoden for å levere appstøtten angitt i serviceavtalen er at teamet som opprettet løsningen, også skal ha ansvar for å støtte den. Fordelene med dette systemet er følgende:
- Det oppmuntrer til bedre kvalitetsutvikling fordi de som opprettet appen, vet at de må støtte den.
- Skaperne kan finne og rette feil raskere enn et tredjepartsteam fordi de kjenner appen bedre.
- Delegering av potensielt forretningskritisk programvare til en annen gruppe kan være demoraliserende og tidkrevende for gruppen. Som med andre faser av appoppretting, utvikling og distribusjon bør teamene samarbeide med IT-teamet for å få hjelp når det er nødvendig.
Overvåking av apptilfredshet og brukervennlighet
Den siste delen av støttearbeidet er å overvåke og vurdere tilfredsstillelsen og nytten av den distribuerte appen. Målinger er nyttige her, sammen med mer tradisjonelle metoder, for eksempel avspørring og spørreskjemaer. Hvis du vil ha mer informasjon om overvåkning av appbruk, kan du se Administratoranalyse for Power Apps.
Til syvende og sist, hvis kundene ikke bruker en publisert app, oppfyller ikke denne appen sitt formål. Regelmessige gjennomgangsmøter kan se på disse måleverdiene for tilfredsstillelse og brukervennlighet for å opprette en positiv tilbakemeldingsløkke som kan endre eller legge til historier i restansen for å generere og deretter distribuere en oppdatert versjon av appen.
Sammendrag
Utviklingen av verktøy uten kode og med lav kode, for eksempel Power Apps, har utvidet alternativene for forretningsteknikere eller -beslutningstakere til å opprette, utvikle og distribuere apper. Denne utviklingen fungerer best i et miljø med et team som består av en produkteier, en domeneekspert, en utviklingsavdeling og en administrator, og dette teamet henter inn andre ressurser etter behov.
Integrering av smidige tilnærminger og utvikling av klynger inne i teamene fører til raskere apputvikling og høyere sannsynlighet for vellykket distribusjon med et funksjonssett som utgjør en betydelig forskjell for virksomheten. Ved å bruke disse gode fremgangsmåtene, retningslinjene og anbefalingene kan fusjonsteamet ditt bruke Power Apps til å løse organisasjonens utfordringer for digital transformasjon.