Underlätta implementering med digitala uppfinningar

Det ultimata innovationstestet är kundernas reaktion på din uppfinning. Visade sig hypotesen vara sann? Använder kunderna lösningen? Skalas den för att uppfylla behoven hos den önskade procentandelen användare? Viktigast av allt, kommer de tillbaka hela tiden? Ingen av dessa frågor kan ställas förrän mvp-lösningen (Minimum Viable Product) har distribuerats.

I den här artikeln fokuserar vi på att underlätta implementeringen med pipelineverktyg för kontinuerlig integrering och kontinuerlig distribution (CI/CD). Kontinuerlig integrering är automatisering av kod flera gånger per dag för att få ett uppdaterat enskilt projekt. Kontinuerlig distribution är automatisk leverans av dessa funktioner under hela dagen.

Minska CI/CD-friktionen som påverkar implementeringen

Vissa hinder för implementering kan minimeras genom en kombination av teknik och processer. För läsare med kunskap om CI/CD- eller DevOps-processer är följande CI/CD-pipelineprocesser bekanta. Den här artikeln skapar en startpunkt för molnimplementeringsteam som underblåser innovations- och feedbackloopar. Den här utgångspunkten kan främja mer robusta CI/CD- eller DevOps-metoder när produkterna och teamen mognar.

Enligt beskrivningen i Mått för kundpåverkan kräver positiv validering av alla hypoteser iteration och bestämning. Den här CI/CD-artikeln syftar till att minimera tekniska toppar som saktar ner innovationen, samtidigt som du ser till att du håller bästa praxis på plats. Detta hjälper teamet att utforma för framtida framgång samtidigt som de levererar efter aktuella kundbehov.

Underlätta implementering och digitala uppfinningar: Mognadsmodellen

Det primära målet med innovationsmetoden är att skapa kundpartnerskap och påskynda feedbackslingor, vilket leder till marknadsinnovationer. Följande bild och avsnitt beskriver inledande implementeringar som stöder den här metoden.

• Delad lösning: Upprätta en central lagringsplats för alla aspekter av lösningen.
• Feedbackloopar: Kontrollera att feedbackloopar kan hanteras konsekvent via iterationer.
• Kontinuerlig integrering: Skapa och konsolidera lösningen regelbundet.
• Tillförlitlig testning: Validera lösningens kvalitet och förväntade ändringar för att säkerställa tillförlitligheten för dina testmått.
• Lösningsdistribution: Distribuera lösningar så att teamet snabbt kan dela ändringar med kunder.
• Integrerad mätning: Lägg till inlärningsmått i feedbackloopen för tydlig analys av hela teamet.

För att minimera tekniska toppar förutsätter du att mognaden initialt kommer att vara låg över dessa principer. Planera framåt genom att anpassa till verktyg och processer som kan skalas när hypoteser blir mer detaljerade. I Azure, GitHub och Azure DevOps kan små team komma igång med lite friktion. Dessa team kan växa till att omfatta tusentals utvecklare som samarbetar om skalningslösningar och testar hundratals kundhypoteser. Resten av den här artikeln illustrerar metoden "plan big, start small" för att underlätta implementeringen av dessa principer.

Delad lösning

Enligt beskrivningen i Mått för kundpåverkan kräver positiv validering av alla hypoteser iteration och bestämning. Du får mycket fler fel än vinster under någon innovationscykel. Detta är förväntat. Men när en kund behöver, hypoteser och lösningar anpassas i stor skala, förändras världen snabbt.

När du skalar digitala uppfinningar och innovationer finns det inget mer värdefullt verktyg än en delad kodbas för lösningen. Tyvärr finns det inget tillförlitligt sätt att förutsäga vilken iteration eller vilken MVP som ger den vinnande kombinationen. Därför är det aldrig för tidigt att upprätta en delad kodbas eller lagringsplats. Det här är den enda tekniska topp som inte bör fördröjas. När teamet itererar genom olika MVP-lösningar möjliggör en delad lagringsplats enkelt samarbete och snabbare utveckling. När ändringar i lösningen drar ned inlärningsmåtten kan du med versionskontrollen återställa till en tidigare och effektivare version av lösningen.

Det mest använda CI/CD-verktyget för att hantera kodlagringsplatser är GitHub, som gör att du kan skapa en lagringsplats för delad kod i bara några få steg. Dessutom kan Azure Repos-funktionen i Azure DevOps användas för att skapa en Git - eller TFVC-lagringsplats .

Feedbackslingor

Att göra kunden till en del av lösningen är nyckeln till att skapa kundpartnerskap under innovationscykler. Det åstadkoms delvis genom att mäta kundernas påverkan. Det kräver konversationer och direkt testning med kunden. Båda genererar feedback som måste hanteras effektivt.

Varje feedbackpunkt är en potentiell lösning för kundens behov. Ännu viktigare är att varje bit av direkt kundfeedback utgör en möjlighet att förbättra partnerskapet. Om feedback gör det till en MVP-lösning kan du fira det med kunden. Även om viss feedback inte kan användas, visar helt enkelt att vara transparent med beslutet att avprioritera feedbacken ett tillväxttänk och ett fokus på kontinuerlig inlärning.

Azure DevOps innehåller olika sätt att begära, tillhandahålla och hantera feedback. Dessa verktyg centraliserar feedback så att teamet kan vidta åtgärder och tillhandahålla uppföljning i en transparent feedbackloop.

Kontinuerlig integrering

Kontinuerlig integrering är att automatisera kod flera gånger per dag för att ha ett uppdaterat enskilt projekt. När implementeringarna skalas och en hypotes kommer närmare verklig innovation i stor skala tenderar antalet mindre hypoteser som ska testas att växa snabbt. För korrekta feedbackslingor och smidiga implementeringsprocesser är det viktigt att dessa hypoteser är integrerade och stöder den primära hypotesen bakom innovationen. Detta kräver att du snabbt går vidare för att förnya och växa, vilket kräver flera utvecklare för att testa varianter av kärnhypotesen. För senare utvecklingsinsatser kan du till och med behöva flera team med utvecklare, som var och en bygger mot en delad lösning. Kontinuerlig integrering är det första steget mot hantering av alla rörliga delar.

I kontinuerlig integrering sammanfogas kodändringar ofta i huvudgrenen. Automatiserade bygg- och testprocesser ser till att koden i huvudgrenen alltid är produktionskvalitet. Detta säkerställer att utvecklare arbetar tillsammans för att utveckla delade lösningar som ger korrekta och tillförlitliga feedbackslingor.

Azure DevOps och Azure Pipelines tillhandahåller funktioner för kontinuerlig integrering med bara några få steg i GitHub eller andra lagringsplatser. Mer information finns i Vad är kontinuerlig integrering? eller prova den praktiska övningen för kontinuerlig integrering. Lösningsarkitekturer är tillgängliga som kan påskynda skapandet av dina CI/CD-pipelines via Azure DevOps.

Tillförlitlig testning

Defekter i en lösning kan skapa falska positiva eller falska negativa identifieringar. Oväntade fel kan enkelt leda till feltolkning av mått för användarimplementering. De kan också generera negativ feedback från kunder som inte korrekt representerar testet av din hypotes.

Under tidiga iterationer av en MVP-lösning förväntas defekter. Tidiga adoptörer kanske till och med tycker att de är älskvärda. I tidiga versioner är godkännandetestning vanligtvis obefintligt. En aspekt av att bygga med empati handlar dock om valideringen av behovet och hypotesen. Båda kan slutföras via enhetstester på kodnivå och manuella godkännandetester före distributionen. Tillsammans ger dessa några sätt att vara tillförlitliga vid testning. Du bör försöka automatisera en väldefinierad serie med bygg-, enhets- och godkännandetester. Dessa säkerställer tillförlitliga mått relaterade till finare justeringar av hypotesen och den resulterande lösningen.

Funktionen Azure Test Plans innehåller verktyg för att utveckla och använda testplaner under manuell eller automatiserad testkörning.

Lösningsdistribution

Den kanske mest meningsfulla aspekten av att underlätta implementeringen är din förmåga att kontrollera lanseringen av en lösning till kunder. Genom att tillhandahålla en självbetjänings- eller automatiserad pipeline för att släppa en lösning till kunder påskyndar du feedbackloopen. Genom att låta kunderna snabbt interagera med ändringar i lösningen bjuder du in dem till processen. Den här metoden utlöser också snabbare testning av hypoteser, vilket minskar antaganden och potentiell omarbetning.

Det finns flera metoder för lösningsdistribution. De tre vanligaste är:

• Kontinuerlig distribution är den mest avancerade metoden, eftersom den automatiskt distribuerar kodändringar till produktion. För mogna team som testar mogna hypoteser kan kontinuerlig distribution vara mycket värdefullt.
• Under tidiga utvecklingsstadier kan kontinuerlig leverans vara lämpligare. Vid kontinuerlig leverans distribueras alla kodändringar automatiskt till en produktionsliknande miljö. Utvecklare, beslutsfattare och andra i teamet kan använda den här miljön för att kontrollera att deras arbete är produktionsklart. Du kan också använda den här metoden för att testa en hypotes med kunder utan att påverka pågående affärsaktiviteter.
• Manuell distribution är den minst avancerade metoden för versionshantering. Som namnet antyder distribuerar någon i teamet manuellt de senaste kodändringarna. Den här metoden är felbenägen, otillförlitlig och anses vara ett antimönster av de flesta erfarna tekniker.

Under den första iterationen av en MVP-lösning är manuell distribution vanligt, trots föregående utvärdering. När lösningen är extremt flytande och kundfeedback är okänd finns det en betydande risk för att återställa hela lösningen (eller till och med kärnhypotesen). Här är den allmänna regeln för manuell distribution: inget kundbevis, ingen distributionsautomatisering.

Att investera tidigt kan leda till förlorad tid. Ännu viktigare är att det kan skapa beroenden på versionspipelinen som gör teamet mer motståndskraftigt mot en tidig pivot. Efter de första iterationerna eller när kundfeedback tyder på potentiella framgångar bör en mer avancerad distributionsmodell snabbt antas.

I valfritt skede av hypotesvalidering tillhandahåller Azure DevOps och Azure Pipelines funktioner för kontinuerlig leverans och kontinuerlig distribution. Läs mer om kontinuerlig leverans eller kolla in det praktiska labbet. Lösningsarkitekturen kan också påskynda skapandet av dina CI/CD-pipelines via Azure DevOps.

Integrerade mått

När du mäter efter kundpåverkan är det viktigt att förstå hur kunderna reagerar på ändringar i lösningen. Dessa data, så kallade telemetri, ger insikter om de åtgärder som en användare (eller kohort av användare) vidtog när de arbetade med lösningen. Från dessa data är det enkelt att få en kvantitativ validering av hypotesen. Dessa mått kan sedan användas för att justera lösningen och generera mer detaljerade hypoteser. Dessa subtilare förändringar hjälper till att mogna den första lösningen i senare iterationer, vilket i slutändan driver på för att upprepa implementeringen i stor skala.

I Azure tillhandahåller Azure Monitor verktyg och gränssnitt för att samla in och granska data från kundupplevelser. Du kan använda dessa observationer och insikter för att förfina kvarvarande uppgifter med hjälp av Azure Boards.

Nästa steg

När du har fått en förståelse för de CI/CD-pipelineverktyg och processer som behövs för att underlätta implementeringen är det dags att undersöka ett mer avancerat innovationsområde: interagera med enheter. Det här området kan bidra till att minska hindren mellan fysiska och digitala upplevelser, vilket gör din lösning ännu enklare att implementera.

Interagera med enheter