Beheer van gezamenlijke ontwikkeling
Een effectief governancekader voor gezamenlijke ontwikkeling opstellen, is een belangrijk aspect van het garanderen van consistentie en herhaalbaarheid in door de maker gedefinieerde projecten en fusieteams. In dit artikel wordt een aanpak beschreven voor het definiëren van een governance-stroomdiagram.
Het proces van begin tot eind definiëren
U kunt het volgende proces als voorbeeld gebruiken en het aanpassen aan de best practices van uw organisatie. Het is niet nodig om elke stap te voltooien, zolang u maar het gewenste resultaat bereikt.
Functies toevoegen aan backlog
Met backlogs kunt u uw project plannen door functies toe te voegen die de algehele ervaring stimuleren. De backlog biedt ook de algemene routekaart die het team van plan is te leveren.
Bij het toevoegen van een nieuwe functie aan de backlog is het doel om de algemene reikwijdte te beschrijven. Elke functie definieert vervolgens de bedrijfswaarde, conceptverhaaltitels, reikwijdte en gegevensmodelwijzigingen die de code-ontwikkelingsinspanningen stimuleren.
Bovendien wordt u aangeraden om bij het toevoegen van een bedrijfskritieke functie kritieke scenario's te identificeren om uw testen te automatiseren. Nadat u uw functies heeft toegevoegd, kunt u uw bijeenkomst voor bereikafstemming plannen.
Bereikafstemmingsbijeenkomst
De focus van deze bijeenkomst moet worden beperkt tot het beoordelen van elke voorgestelde nieuwe functie en vervolgens controleren op bestaande apps, scenario's of gegevensmodellen die deze functionaliteit al bieden om dubbel werk te voorkomen. Deze bijeenkomst biedt ook de mogelijkheid om de gevolgen voor andere apps te bespreken. Ten slotte moet u controleren of deze functie een Ervaringsbeoordeling vereist.
Verhalen en storyboard toevoegen aan backlog
Na de bereikafstemmingsbijeenkomst kunnen eventuele concepttitels van gebruikersverhalen onder de functie worden toegevoegd. Op dit moment zijn details niet vereist en is de status van het gebruikersverhaal "Nieuw". U kunt verhalen bekijken in de backlog- of bordweergave.
De volgende afbeelding toont een voorbeeld van een gebruikersverhaal dat is toegevoegd aan een backlog.
Op dit moment is het van vitaal belang om de kwaliteit te handhaven door werk te organiseren per workstream en toepassing. Deze aanpak helpt om gerelateerde werkitems bij elkaar te houden en stelt experts in elke workstream in staat om diepgaand inzicht te krijgen in de functionaliteit en het gegevensgebruik binnen elke app.
Ervaringsbeoordeling
Ervaringsbeoordelingen moeten zich richten op de eindgebruikerservaring en ervoor zorgen dat uw team de best practices van de organisatie volgt. Deze consistentie zorgt ervoor dat al uw apps een betrouwbare en herhaalbare ervaring bieden voor eindgebruikers en ondersteuningsteams.
Verhaaldetails toevoegen
Het toevoegen van een typisch gebruikersverhaal kan de volgende informatie bevatten:
- Titel: als <persona> kan ik <do something>, zodat <impact/priority/value>
- Beschrijving: de beschrijving bevat (hoewel dit niet beperkt is tot) bepaalde belangrijke details, zoals:
- Korte beschrijving van het scenario dat het gewenste resultaat samenvat
- Verhaal - beschrijft de acties die gebruikers zullen ondernemen om te navigeren en het scenario te volbrengen
- Alternatief verhaal - beschrijft andere manieren waarop gebruikers hetzelfde resultaat kunnen bereiken
- Ontwerpnotities - registreert de entiteit, velden, weergaven, mockup-schermen en bedrijfsregels die zijn gekoppeld aan het gebruikersverhaal
- Betrokken beveiligingsrollen - geeft een overzicht van alle beveiligingsrollen die zijn betrokken of die relevant zijn voor het gebruikersverhaal.
Nadat u al deze details hebt toegevoegd, wijzigt u de status van het gebruikersverhaal in "Gereed voor beoordeling". In de meeste gevallen beoordelen het functiesteam en het zakelijke team (indien van toepassing) de gebruikersverhalen.
Verhaalbeoordeling
Verhaalbeoordelingen vinden meestal plaats binnen het fusieteam om ervoor te zorgen dat alle details in het verhaal worden genoemd en dat er geen vaagheden zijn. Na voltooiing van alle beoordelingen, is de aanbeveling om het gebruikersverhaal toe te wijzen aan een teamlid. Ervoor zorgen dat uw team tijdens het ontwikkelingsproces op één lijn blijft, is van vitaal belang voor het bereiken van uw algemene doelen.
Taken en testcases toevoegen
Na het bekijken van de verhalen, maken teamleden taken in Azure DevOps. Het algemene proces voor het toevoegen van taken en testcases is als volgt:
- Open een sprint-backlog. U kunt ook een nieuwe sprint maken.
- Voeg bestaande werkitems toe aan de sprint. Als u al werkitems hebt toegevoegd die niet in de sprint verschijnen, moet u hun gebied en iteratiepaden controleren. Vergeet niet om alle taken zonder bovenliggend element toe te wijzen aan de relevante werkitems.
- Voeg taken toe aan backlog-items. Als u geen backlog-items hebt toegewezen aan uw sprint, doe dat dan nu. Stel ook de start- en einddatum van de sprint in.
- Vul het taakformulier in. Als vuistregel geldt dat taken in niet meer dan een dag uitgevoerd moeten kunnen worden. Taken die langer duren dan deze tijdsspanne, moeten worden opgesplitst.
- Volg of integreer alle taken zonder bovenliggend element. U kunt taken zonder bovenliggend element volgen, net als andere taken, of u kunt ze naar een bestaand backlog-item slepen om ze te 'koppelen'.
Nadat u taken en testcases hebt toegevoegd, kunt u de sprintcapaciteit instellen.
Zie voor meer informatie over het toevoegen van taken Taken toevoegen aan backlog-items om sprintplanning te ondersteunen.
Oplossingen voorbereiden
Een belangrijk aspect voor succesvolle co-ontwikkeling is een gestructureerd releasemanagementproces. Oplossingen zijn het mechanisme voor de implementatie levenscyclusbeheer van applicatie (ALM), u gebruikt oplossingen om onderdelen te distribueren naar omgevingen door middel van export- en importactiviteiten. Een onderdeel is een artefact dat in uw toepassing wordt gebruikt en iets dat u kunt mogelijk aanpassen. Alles wat in een oplossing kan worden opgenomen is een onderdeel, zoals tabellen, kolommen, canvas-apps en modelgestuurde apps, Power Automate-stromen, chatbots, grafieken en plug-ins.
Belangrijk
Bepaal tijdens de releaseplanning de strategie voor het beheer oplossingen in uw project. Gebruik oplossingen om uw project te beheren en eenvoudig onderdelen te vinden die u hebt gemaakt om vervolgens naar andere omgevingen te distribueren.
Installaties
Het kan meerdere sprints duren voordat onderdelen voltooid zijn, afhankelijk van de complexiteit en teamsnelheid. Componenten moeten worden toegevoegd aan een oplossing in een ontwikkelomgeving wanneer taken worden voltooid. Oplossingen worden vervolgens geïmporteerd in een productieomgeving nadat ze zijn getest. We raden u aan ook één testomgeving te onderhouden om end-to-end-tests uit te voeren en implementatie van oplossingen uit te proberen voordat u naar de productieomgeving gaat.
Power Platform-omgevingen
Een omgeving is een ruimte waar de zakelijke gegevens, apps en bedrijfsprocessen van uw organisatie kunnen worden opgeslagen, beheerd en gedeeld. Een omgeving dient ook als een container om apps te scheiden die verschillende rollen, beveiligingsvereisten of doelgroepen hebben.
Als uw organisatie een fusie-opstelling met meerdere teams heeft waarbij elk team zijn eigen oplossingen ontwikkelt, is het belangrijk om de duur van sprints en releases te coördineren. Sprints hoeven niet van een consistente lengte te zijn volgens een projecttijdlijn en kunnen variëren in duur tussen teams, afhankelijk van de voorkeuren van elke groep. De releasecadans kan echter niet korter zijn dan de kortste sprintduur voor alle teams.
Bronbeheer
Overweeg een broncodecontrolesysteem in gebruik te nemen, zoals Azure DevOps. Azure DevOps biedt ontwikkelaarsservices voor ondersteuningsteams bij het plannen van werk, samenwerken aan codeontwikkeling en het bouwen en implementeren van toepassingen.
Exporteer een oplossing vanuit uw ontwikkelomgeving met uw apps en aanpassingen, pak uw oplossing uit en sla de onderdelen op in uw bronbeheersysteem.
Geavanceerd onderwerp: reviews van pull-aanvragen (PR)
U moet alleen PR's maken voor verhalen die actief zijn en waarvan de functies zijn beoordeeld en goedgekeurd. U moet ervoor zorgen dat versiebeheer van oplossingen nauwkeurig is, volgens de sprint- en ontwikkelaarrichtlijnen die zijn uiteengezet in Scrum-praktijken voor uw team in Azure Boards implementeren. Testresultaten van de PR kunnen schermopnamen of video's zijn die de functionaliteit weergeven die wordt gebouwd.
Het automatiseren van het PR-governanceproces helpt de kwaliteit van de code te waarborgen zonder dat een handmatige beoordeling van basiscontroles zoals oplossingsversies nodig is.
Notitie
Gebruik de hulpmiddel voor PR-controle om het controleproces voor pull-aanvragen te automatiseren.
Sjablonen en standaardisatie
Sjablonen en standaardisatie zorgen voor efficiëntie door de consistentie binnen het team te bevorderen. Alle aspecten van de activiteiten van het team— of het nu gaat om introductietaken, presentaties over verhaalrecensies of sjablonen voor werkitems die helpen tijd te besparen en begeleiding te bieden aan teams bij het definiëren van gebruikersverhalen, functies, bugs of taken— profiteer van standaardisatie en vereenvoudiging.
Een effectief ondersteuningsmodel implementeren
Een effectief ondersteuningsmodel is essentieel voor het succes van een toepassing op lange termijn na de implementatie, zoals aangegeven in de eerdere sectie over het genereren van een ondersteuningsmatrix. Bugs en storingen zijn onvermijdelijk, dus het is van vitaal belang dat het team een gestructureerde aanpak heeft om met deze voorvallen om te gaan, en de ondersteuningsmatrix biedt het noodzakelijke kader.
De serviceovereenkomst (Service Level Agreement, SLA) maken
Een belangrijke factor in elk ondersteuningsmodel is de definitie van de serviceovereenkomst ofwel SLA. De SLA moet een formeel document zijn dat het team opstelt en dat secties bevat die de volgende items behandelen:
- Storingen – welk niveau van serviceonderbreking acceptabel is, wie te informeren, welke acties te ondernemen, bevestiging van hervatting van de service en acties om herhaling te voorkomen. Alle geautomatiseerde testprocedures die het team gebruikt, moeten in overeenstemming zijn met de verwachte storingstolerantie en de toepasselijke SLA.
- Bugs – wie kan melden, toewijzing van ernstniveaus, classificatie, acties bij detectie, wie verantwoordelijk is voor het oplossen en afmelden.
- Escalaties – escalatieniveaus, toewijzing van personeel aan niveaus, verantwoordelijkheden per niveau, distributielijsten per niveau, enzovoort.
De SLA moet worden opgeslagen in de documentatieportal van het team en zo nodig worden bijgewerkt.
Toepassingsondersteuning leveren
De beste aanpak voor het leveren van de toepassingsondersteuning die is gespecificeerd in de SLA, is dat het team dat de oplossing heeft gemaakt ook verantwoordelijk is voor de ondersteuning ervan. De voordelen van dit systeem zijn:
- Het stimuleert ontwikkeling van betere kwaliteit, omdat degenen die de app hebben gemaakt weten dat ze deze zullen moeten ondersteunen.
- De makers kunnen bugs sneller vinden en oplossen dan een extern team, simpelweg omdat ze de app beter kennen.
- Het delegeren van het repareren van potentieel bedrijfskritieke software aan een andere groep kan demoraliserend en tijdrovend zijn voor die groep. Net als bij andere fasen van het maken, ontwikkelen en implementeren van toepassingen, moet het fusieteam samenwerken met IT voor assistentie wanneer dat nodig is.
Toezicht op tevredenheid met en bruikbaarheid van toepassingen
Het laatste deel van de ondersteuningsinspanning is het monitoren en beoordelen van de tevredenheid en bruikbaarheid van de geïmplementeerde app. Metrische gegevens zijn hier nuttig, samen met meer traditionele methoden, zoals navragen en vragenlijsten. Zie Beheeranalyse voor Power Apps voor meer informatie over het monitoren van app-gebruik.
Als klanten een gepubliceerde app niet gebruiken, voldoet die app niet aan zijn doel. Regelmatige beoordelingsbijeenkomsten kunnen deze tevredenheids- en bruikbaarheidsstatistieken controleren om een positieve feedbacklus te creëren die verhalen kan wijzigen of toevoegen aan de backlog om een bijgewerkte versie van de app te genereren en vervolgens te implementeren.
Overzicht
De ontwikkeling van no-code- en low-codetools zoals Power Apps heeft uitgebreide opties voor zakelijke technologen of makers om apps te maken, ontwikkelen en implementeren. Deze ontwikkeling werkt het beste binnen een fusieteamomgeving, bestaande uit een producteigenaar, een domeinexpert, een professionele ontwikkelaar en een beheerder, waarbij dit team indien nodig andere resources inbrengt.
Het integreren van agile- en scrum-ontwikkelingsbenaderingen binnen fusieteams resulteert in snellere app-ontwikkeling en een grotere kans op succesvolle implementatie met een functieset die een aanzienlijk verschil maakt voor het bedrijf. Door deze best practices, richtlijnen en aanbevelingen toe te passen, kan uw fusieteam gebruik maken van Power Apps om de digitale transformatie-uitdagingen van uw organisatie aan te pakken.