Acceptatie mogelijk maken met digitale uitvindingen

De ultieme test van innovatie is de reactie van de klant op uw uitvinding. Is de hypothese waar gebleken? Gebruiken klanten de oplossing? Wordt de schaal aangepast aan de behoeften van het gewenste percentage gebruikers? Het belangrijkste is, blijven ze terugkomen? Geen van deze vragen kan worden gesteld totdat de MVP-oplossing (Minimum Viable Product) is geïmplementeerd.

In dit artikel richten we ons op het mogelijk maken van acceptatie met ci/CD-pijplijnhulpprogramma's (continue integratie en continue implementatie). Continue integratie is het automatiseren van code meerdere keren per dag om één project te kunnen bijwerken. Continue implementatie is de automatische levering van deze functies gedurende de dag.

Ci/CD-wrijving verminderen die van invloed is op de acceptatie

Sommige obstakels voor acceptatie kunnen worden geminimaliseerd door een combinatie van technologie en processen. Voor lezers met kennis van CI/CD- of DevOps-processen zijn de volgende CI/CD-pijplijnprocessen bekend. Dit artikel vormt een uitgangspunt voor cloudimplementatieteams die innovatie en feedbacklussen stimuleren. Dit uitgangspunt kan een robuustere CI/CD- of DevOps-benadering bevorderen naarmate de producten en teams volwassener worden.

Zoals beschreven in Meting voor de impact van de klant, is voor positieve validatie van een hypothese herhaling en bepaling vereist. Dit CI/CD-artikel is bedoeld om technische pieken die innovatie vertragen te minimaliseren en ervoor te zorgen dat u de aanbevolen procedures behoudt. Als u dit doet, helpt het team bij het ontwerpen van toekomstige successen, terwijl het voldoet aan de huidige behoeften van de klant.

Acceptatie en digitale uitvindingen mogelijk maken: het volwassenheidsmodel

Het primaire doel van de innovatiemethodologie is het bouwen van klantpartnerschappen en het versnellen van feedbacklussen, die leiden tot marktinnovaties. In de volgende afbeelding en secties worden de eerste implementaties beschreven die deze methodologie ondersteunen.

• Gedeelde oplossing: Maak een gecentraliseerde opslagplaats voor alle aspecten van de oplossing.
• Feedbacklussen: zorg ervoor dat feedbacklussen consistent kunnen worden beheerd via iteraties.
• Continue integratie: bouw en consolideert regelmatig de oplossing.
• Betrouwbaar testen: valideer de kwaliteit van de oplossing en verwachte wijzigingen om de betrouwbaarheid van uw metrische testgegevens te garanderen.
• Oplossingsimplementatie: Implementeer oplossingen zodat het team snel wijzigingen met klanten kan delen.
• Geïntegreerde meting: voeg metrische leergegevens toe aan de feedbacklus voor een duidelijke analyse door het volledige team.

Als u technische pieken wilt minimaliseren, moet u ervan uitgaan dat de rijpheid in eerste instantie laag is voor deze principes. Plan vooruit door uit te lijnen op hulpprogramma's en processen die kunnen worden geschaald naarmate hypothesen nauwkeuriger worden. In Azure bieden GitHub en Azure DevOps kleine teams de mogelijkheid om met weinig wrijving aan de slag te gaan. Deze teams kunnen groeien tot duizenden ontwikkelaars die samenwerken aan schaaloplossingen en honderden klanthypotheses testen. De rest van dit artikel illustreert de benadering 'plan groot, begin klein' om acceptatie mogelijk te maken binnen deze principes.

Gedeelde oplossing

Zoals beschreven in Meting voor de impact van de klant, is voor positieve validatie van een hypothese herhaling en bepaling vereist. U ondervindt veel meer fouten dan overwinningen tijdens elke innovatiecyclus. Dit is normaal. Wanneer een klant echter behoefte, hypothesen en oplossingen op schaal op elkaar afstemt, verandert de wereld snel.

Wanneer u digitale uitvindingen en innovatie schaalt, is er geen waardevoller hulpprogramma dan een gedeelde codebasis voor de oplossing. Helaas is er geen betrouwbare manier om te voorspellen welke iteratie of welke MVP de winnende combinatie oplevert. Daarom is het nooit te vroeg om een gedeelde codebasis of opslagplaats tot stand te brengen. Dit is de enige technische piek die niet mag worden uitgesteld. Terwijl het team verschillende MVP-oplossingen doorloopt, maakt een gedeelde opslagplaats eenvoudige samenwerking en versnelde ontwikkeling mogelijk. Wanneer metrische leergegevens naar beneden worden gesleept door wijzigingen in de oplossing, kunt u met versiebeheer teruggaan naar een eerdere, effectievere versie van de oplossing.

Het meest gebruikte CI/CD-hulpprogramma voor het beheren van codeopslagplaatsen is GitHub, waarmee u in slechts enkele stappen een gedeelde codeopslagplaats kunt maken. Daarnaast kan de functie Azure-opslagplaatsen van Azure DevOps worden gebruikt om een Git - of TFVC-opslagplaats te maken.

Feedbacklussen

De klant onderdeel maken van de oplossing is de sleutel tot het opbouwen van klantpartnerschappen tijdens innovatiecycli. Dit wordt deels bereikt door de impact van de klant te meten. Hiervoor zijn gesprekken en directe tests met de klant vereist. Beide genereren feedback die effectief moet worden beheerd.

Elk feedbackpunt is een mogelijke oplossing voor de klant. Wat nog belangrijker is, is dat elk beetje directe feedback van klanten een kans biedt om de samenwerking te verbeteren. Als feedback er een MVP-oplossing van maakt, vier dat dan met de klant. Zelfs als bepaalde feedback niet kan worden uitgevoerd, toont het simpelweg transparant zijn met de beslissing om de feedback te deprioritiseren een groeimentaliteit en een focus op continu leren.

Azure DevOps bevat manieren om feedback aan te vragen, te geven en te beheren. Deze hulpprogramma's centraliseren feedback, zodat het team actie kan ondernemen en opvolging kan bieden in dienst van een transparante feedbacklus.

Continue integratie

Continue integratie is het automatiseren van code meerdere keren per dag om één bijgewerkt project te hebben. Naarmate de acceptatie schaalt en een hypothese dichter bij echte innovatie op schaal komt, groeit het aantal kleinere hypothesen dat moet worden getest snel. Voor nauwkeurige feedbacklussen en soepele acceptatieprocessen is het belangrijk dat deze hypothesen zijn geïntegreerd en de primaire hypothese achter de innovatie ondersteunen. Hiervoor moet u snel innoveren en groeien. Hiervoor zijn meerdere ontwikkelaars nodig om variaties van de kernhypothese te testen. Voor latere ontwikkelingsinspanningen hebt u mogelijk zelfs meerdere teams van ontwikkelaars nodig, die elk naar een gedeelde oplossing toebouwen. Continue integratie is de eerste stap naar het beheer van alle bewegende onderdelen.

Bij continue integratie worden codewijzigingen vaak samengevoegd met de hoofdbranch. Geautomatiseerde build- en testprocessen zorgen ervoor dat code in de hoofdbranch altijd productiekwaliteit is. Dit zorgt ervoor dat ontwikkelaars samenwerken om gedeelde oplossingen te ontwikkelen die nauwkeurige en betrouwbare feedbacklussen bieden.

Azure DevOps en Azure Pipelines bieden mogelijkheden voor continue integratie met slechts een paar stappen in GitHub of andere opslagplaatsen. Zie Wat is continue integratie? of probeer het praktijklab voor continue integratie voor meer informatie. Er zijn oplossingsarchitecturen beschikbaar die het maken van uw CI/CD-pijplijnen via Azure DevOps kunnen versnellen.

Betrouwbaar testen

Defecten in een oplossing kunnen fout-positieven of fout-negatieven creëren. Onverwachte fouten kunnen gemakkelijk leiden tot een onjuiste interpretatie van metrische gegevens voor gebruikersacceptatie. Ze kunnen ook negatieve feedback van klanten genereren die de test van uw hypothese niet nauwkeurig weergeeft.

Tijdens vroege iteraties van een MVP-oplossing worden defecten verwacht. Early adopters kunnen ze zelfs verleidend vinden. In vroege releases is acceptatietests doorgaans niet beschikbaar. Een aspect van het bouwen met empathie betreft echter de validatie van de behoefte en hypothese. Beide kunnen worden voltooid via eenheidstests op codeniveau en handmatige acceptatietests vóór de implementatie. Samen bieden deze een aantal manieren van betrouwbaarheid bij het testen. Probeer een goed gedefinieerde reeks build-, eenheids- en acceptatietests te automatiseren. Deze zorgen voor betrouwbare metrische gegevens met betrekking tot nauwkeurigere aanpassingen van de hypothese en de resulterende oplossing.

De functie Azure-testplannen biedt hulpprogramma's voor het ontwikkelen en uitvoeren van testplannen tijdens handmatige of geautomatiseerde testuitvoering.

Implementatie van de oplossing

Misschien is het meest zinvolle aspect van het stimuleren van acceptatie uw vermogen om de release van een oplossing voor klanten te beheren. Door een selfservice of geautomatiseerde pijplijn te bieden voor het vrijgeven van een oplossing aan klanten, versnelt u de feedbacklus. Door klanten snel te laten communiceren met wijzigingen in de oplossing, nodigt u ze uit voor het proces. Deze benadering activeert ook het sneller testen van hypothesen, waardoor veronderstellingen en mogelijke herwerkbewerkingen worden verminderd.

Er zijn verschillende methoden voor het implementeren van oplossingen. De drie meest voorkomende zijn:

• Continue implementatie is de meest geavanceerde methode, omdat codewijzigingen automatisch in productie worden geïmplementeerd. Voor volwassen teams die volwassen hypothesen testen, kan continue implementatie zeer waardevol zijn.
• Tijdens de eerste ontwikkelingsfasen is continue levering mogelijk geschikter. Bij continue levering worden eventuele codewijzigingen automatisch geïmplementeerd in een productieachtige omgeving. Ontwikkelaars, zakelijke besluitvormers en anderen in het team kunnen deze omgeving gebruiken om te controleren of hun werk gereed is voor productie. U kunt deze methode ook gebruiken om een hypothese met klanten te testen zonder dat dit van invloed is op lopende bedrijfsactiviteiten.
• Handmatige implementatie is de minst geavanceerde benadering voor releasebeheer. Zoals de naam al aangeeft, implementeert iemand in het team handmatig de meest recente codewijzigingen. Deze benadering is foutgevoelig, onbetrouwbaar en wordt door de meeste doorgewinterde technici beschouwd als een antipatroon.

Tijdens de eerste iteratie van een MVP-oplossing is handmatige implementatie gebruikelijk, ondanks de voorgaande evaluatie. Wanneer de oplossing zeer vloeiend is en de feedback van klanten onbekend is, bestaat er een aanzienlijk risico bij het opnieuw instellen van de hele oplossing (of zelfs de kernhypothese). Dit is de algemene regel voor handmatige implementatie: geen klantbewijs, geen implementatieautomatisering.

Vroeg investeren kan leiden tot verloren tijd. Wat nog belangrijker is, het kan afhankelijkheden maken op de release-pijplijn, waardoor het team beter bestand is tegen een vroege draai. Na de eerste paar iteraties of wanneer feedback van klanten potentieel succes suggereert, moet snel een geavanceerder implementatiemodel worden geïmplementeerd.

In elk stadium van de validatie van hypothesen bieden Azure DevOps en Azure Pipelines mogelijkheden voor continue levering en continue implementatie. Meer informatie over continue levering of bekijk het praktijklab. Oplossingsarchitectuur kan het maken van uw CI/CD-pijplijnen ook versnellen via Azure DevOps.

Geïntegreerde metingen

Wanneer u de impact van de klant meet, is het belangrijk om te begrijpen hoe klanten reageren op wijzigingen in de oplossing. Deze gegevens, ook wel telemetrie genoemd, bieden inzicht in de acties die een gebruiker (of cohort van gebruikers) heeft uitgevoerd bij het werken met de oplossing. Op basis van deze gegevens is het eenvoudig om een kwantitatieve validatie van de hypothese te verkrijgen. Deze metrische gegevens kunnen vervolgens worden gebruikt om de oplossing aan te passen en meer gedetailleerde hypothesen te genereren. Deze subtielere wijzigingen helpen bij het ontwikkelen van de eerste oplossing in latere iteraties, zodat uiteindelijk de acceptatie op schaal wordt herhaald.

In Azure biedt Azure Monitor de hulpprogramma's en interface voor het verzamelen en controleren van gegevens van klantervaringen. U kunt deze waarnemingen en inzichten toepassen om de achterstand te verfijnen met behulp van Azure Boards.

Volgende stappen

Nadat u inzicht hebt gekregen in de CI/CD-pijplijnhulpprogramma's en -processen die nodig zijn om acceptatie mogelijk te maken, is het tijd om een geavanceerdere innovatie-discipline te onderzoeken: interactie met apparaten. Deze discipline kan helpen de barrières tussen fysieke en digitale ervaringen te verminderen, waardoor uw oplossing nog eenvoudiger te gebruiken is.

Werken met apparaten