Acceptatie mogelijk maken met digitale uitvindingen

De ultieme test van innovatie is de reactie van klanten op uw uitvinding. Is de hypothese waar gebleken? Gebruiken klanten de oplossing? Wordt deze geschaald om te voldoen aan de behoeften van het gewenste percentage gebruikers? Hebben ze vooral de neiging om terug te blijven komen? 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 pijplijnhulpprogramma's voor continue integratie en continue implementatie (CI/CD). 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. In dit artikel wordt een uitgangspunt voor cloudacceptatieteams vastgelegd die innovatie- en feedbacklussen stimuleren. Dit startpunt kan een krachtigere CI/CD- of DevOps-benadering bevorderen naarmate de producten en teams volwassener worden.

Zoals beschreven in Measure for customer impact, vereist positieve validatie van elke hypothese iteratie en bepaling. Dit CI/CD-artikel is gericht op het minimaliseren van technische pieken die de innovatie vertragen, terwijl u ervoor zorgt dat u de aanbevolen procedures behoudt. Dit helpt het teamontwerp voor toekomstig succes bij het leveren van de huidige behoeften van klanten.

Acceptatie en digitale uitvinding mogelijk maken: het volwassen model

Het belangrijkste doel van de innovatiemethodologie is het bouwen van klantpartnerverbanden en het versnellen van feedbacklussen, wat leidt tot marktinnovaties. In de volgende afbeelding en secties worden de eerste implementaties beschreven die ondersteuning bieden voor deze methodologie.

• gedeelde oplossing: een gecentraliseerde opslagplaats maken voor alle aspecten van de oplossing.
• Feedbacklussen: zorg ervoor dat feedbacklussen consistent kunnen worden beheerd via iteraties.
• Continue integratie: bouw en consolideert de oplossing regelmatig.
• Betrouwbare tests: 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 vervaldatum 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 kunnen GitHub en Azure DevOps kleine teams met weinig wrijving aan de slag. Deze teams kunnen groeien tot duizenden ontwikkelaars die samenwerken aan schaaloplossingen en honderden klanthypotheses testen. De rest van dit artikel illustreert de benadering 'plan big, start small' om acceptatie in deze principes mogelijk te maken.

Gedeelde oplossing

Zoals beschreven in Measure for customer impact, vereist positieve validatie van elke hypothese iteratie en bepaling. Tijdens elke innovatiecyclus ondervindt u veel meer fouten dan wint. Dit wordt verwacht. Wanneer een klant echter behoefte heeft aan hypothesen en oplossingen op schaal, verandert de wereld snel.

Wanneer u digitale uitvindingen en innovatie schaalt, is er geen waardevollere tool 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 vertraagd. Naarmate het team door verschillende MVP-oplossingen doorloopt, maakt een gedeelde opslagplaats eenvoudige samenwerking en versnelde ontwikkeling mogelijk. Wanneer veranderingen in de oplossing de leerresultaten verslechteren, 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 Azure-opslagplaatsfunctie van Azure DevOps worden gebruikt om een Git - of TFVC-opslagplaats te maken.

Feedbacklussen

Het maken van het klantgedeelte van de oplossing is de sleutel tot het bouwen van klantpartnerschappen tijdens innovatiecycli. Dat wordt deels bereikt door de impact van klanten 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. Belangrijker is dat elke beetje directe feedback van klanten een kans vormt om het partnerschap te verbeteren. Als feedback het in een MVP-oplossing maakt, viert u dat met de klant. Zelfs als sommige feedback niet uitvoerbaar is, is het simpelweg transparant met de beslissing om de feedback te deprioritiseren, toont een groeimentaliteit en een focus op doorlopend leren.

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

Continue integratie

Continue integratie is het automatiseren van code meerdere keren per dag om één project te hebben bijgewerkt. Naarmate acceptaties worden geschaald 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 worden geïntegreerd en ondersteund door de primaire hypothese achter de innovatie. Hiervoor moet u snel innoveren en groeien. Hiervoor moeten meerdere ontwikkelaars variaties van de kernhypothese testen. Voor latere ontwikkelingsinspanningen hebt u mogelijk zelfs meerdere teams van ontwikkelaars nodig, die elk bouwen naar een gedeelde oplossing. Continue integratie is de eerste stap voor het beheer van alle bewegende onderdelen.

In continue integratie worden codewijzigingen vaak samengevoegd in 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 waarmee u uw CI/CD-pijplijnen sneller kunt maken via Azure DevOps.

Betrouwbare tests

Defecten in elke oplossing kunnen fout-positieven of fout-negatieven maken. Onverwachte fouten kunnen eenvoudig leiden tot onjuiste interpretatie van metrische gegevens voor gebruikersimplementatie. Ze kunnen ook negatieve feedback genereren van klanten die de test van uw hypothese niet nauwkeurig vertegenwoordigen.

Tijdens vroege iteraties van een MVP-oplossing worden defecten verwacht. Vroege gebruikers vinden ze misschien zelfs verdraagd. In vroege releases is acceptatietests doorgaans niet-bestaand. Een aspect van 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. U moet proberen een goed gedefinieerde reeks build-, eenheids- en acceptatietests te automatiseren. Deze zorgen voor betrouwbare metrische gegevens met betrekking tot nauwkeurigere aanpassingen aan de hypothese en de resulterende oplossing.

De functie Azure Test Plans 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 acceptatie uw mogelijkheid 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 in staat te stellen snel te communiceren met wijzigingen in de oplossing, nodigt u ze uit voor het proces. Deze aanpak activeert ook sneller testen van hypothesen, waardoor veronderstellingen en potentiële herwerkbewerkingen worden verminderd.

Er zijn verschillende methoden voor de implementatie 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.
• In een vroeg stadium van ontwikkeling is continue levering mogelijk beter geschikt. Bij continue levering worden alle codewijzigingen automatisch geïmplementeerd in een productieachtige omgeving. Ontwikkelaars, 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 beschouwd als een antipatroon door de meeste doorgewinterde technici.

Tijdens de eerste iteratie van een MVP-oplossing is handmatige implementatie gebruikelijk, ondanks de voorgaande evaluatie. Wanneer de oplossing extreem vloeiend is en feedback van klanten onbekend is, is 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. Belangrijker nog, het kan afhankelijkheden creëren met de release-pijplijn, waardoor het team minder flexibel is om vroeg van koers te veranderen. Na de eerste paar iteraties of wanneer feedback van klanten potentiële succes voorstelt, moet snel een geavanceerder implementatiemodel worden aangenomen.

In elk stadium van hypothesevalidatie bieden Azure DevOps en Azure Pipelines continue levering en continue implementatiemogelijkheden. 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 meet wat de impact van de klant is, 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 krijgen. Deze metrische gegevens kunnen vervolgens worden gebruikt om de oplossing aan te passen en nauwkeurigere hypothesen te genereren. Deze subtielere wijzigingen helpen bij het ontwikkelen van de eerste oplossing in latere iteraties, wat uiteindelijk een herhaling van de acceptatie op schaal mogelijk maakt.

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

Volgende stappen

Nadat u kennis hebt gekregen van 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