Potenziare l'adozione con l'invenzione digitale

Il test finale dell'innovazione è la reazione dei clienti all'invenzione. L'ipotesi è vera? I clienti usano la soluzione? È in grado di scalare per soddisfare le esigenze della percentuale desiderata di utenti? Soprattutto, continuano a tornare? Nessuna di queste domande può essere posta fino a quando non viene distribuita la soluzione MVP (Minimum Viable Product).

In questo articolo ci concentreremo sull'agevolare l'adozione di strumenti di integrazione continua e distribuzione continua (CI/CD) attraverso l'uso di pipeline. L'integrazione continua è l'automazione del codice più volte al giorno per avere un singolo progetto aggiornato. La distribuzione continua è il recapito automatico di tali funzioni durante il giorno.

Ridurre l'attrito CI/CD che influisce sull'adozione

Alcuni ostacoli all'adozione possono essere ridotti al minimo tramite una combinazione di tecnologie e processi. Per i lettori con conoscenza dei processi CI/CD o DevOps, i seguenti processi di pipeline CI/CD saranno familiari. Questo articolo definisce un punto di partenza per i team di adozione del cloud che alimentano cicli di innovazione e feedback. Questo punto di partenza potrebbe favorire approcci CI/CD o DevOps più affidabili man mano che i prodotti e i team maturano.

Come descritto in Misurare l'impatto dei clienti, la convalida positiva di qualsiasi ipotesi richiede iterazione e determinazione. Questo articolo ci/cd mira a ridurre al minimo i picchi tecnici che rallentano l'innovazione, assicurandosi di mantenere le procedure consigliate. Questa operazione aiuterà il team a progettare per il successo futuro, offrendo al tempo stesso le esigenze correnti dei clienti.

Potenziare l'adozione e l'invenzione digitale: il modello di maturità

L'obiettivo principale della metodologia di innovazione è quello di creare partnership con i clienti e accelerare i cicli di feedback, che portano a innovazioni di mercato. L'immagine e le sezioni seguenti descrivono le implementazioni iniziali che supportano questa metodologia.

• soluzione condivisa: stabilire un repository centralizzato per tutti gli aspetti della soluzione.
• Cicli di feedback: assicurarsi che i cicli di feedback possano essere gestiti in modo coerente tramite iterazioni.
• Integrazione continua: compilare e consolidare regolarmente la soluzione.
• Test affidabile: convalidare la qualità della soluzione e le modifiche previste per garantire l'affidabilità delle metriche di test.
• Distribuzione della soluzione: distribuire soluzioni in modo che il team possa condividere rapidamente le modifiche con i clienti.
• Misurazione integrata: aggiungere metriche di apprendimento al ciclo di feedback per un'analisi chiara da parte del team completo.

Per ridurre al minimo i picchi tecnici, si supponga che la maturità inizialmente sia bassa in questi principi. Pianificare in anticipo allineandosi a strumenti e processi che possono essere ridimensionati man mano che le ipotesi diventano più granulari. In Azure, GitHub e Azure DevOps consentono ai team di piccole dimensioni di iniziare con poco attrito. Questi team possono aumentare fino a includere migliaia di sviluppatori che collaborano su soluzioni di scalabilità e testano centinaia di ipotesi dei clienti. Il resto di questo articolo illustra l'approccio "pianificare in grande, iniziare in piccolo" per favorire l'adozione di questi principi.

Soluzione condivisa

Come descritto in Misurare l'impatto dei clienti, la convalida positiva di qualsiasi ipotesi richiede iterazione e determinazione. Sperimenterai molti più fallimenti che successi durante qualsiasi ciclo di innovazione. Questo è previsto. Tuttavia, quando un bisogno del cliente, un'ipotesi e una soluzione si allineano su larga scala, il mondo cambia rapidamente.

Quando si scala l'invenzione digitale e l'innovazione, non esiste uno strumento più prezioso di una base di codice condivisa per la soluzione. Sfortunatamente, non c'è modo affidabile di prevedere quale iterazione o quale MVP produrrà la combinazione vincente. Ecco perché non è mai troppo presto per stabilire una codebase o un repository condiviso. Si tratta di un picco tecnico che non dovrebbe essere ritardato. Man mano che il team esegue l'iterazione di varie soluzioni MVP, un repository condiviso consente una facile collaborazione e uno sviluppo accelerato. Quando le modifiche apportate alla soluzione trascinano le metriche di apprendimento, il controllo della versione consente di eseguire il rollback a una versione precedente e più efficace della soluzione.

Lo strumento CI/CD più diffuso per la gestione dei repository di codice è GitHub, che consente di creare un repository di codice condiviso in pochi passaggi. Inoltre, la funzionalità Azure Repos di Azure DevOps può essere usata per creare un repository Git o TFVC .

Cicli di feedback

Rendere parte del cliente della soluzione è la chiave per creare partnership con i clienti durante i cicli di innovazione. Questa operazione viene eseguita, in parte, misurando l'impatto sui clienti. Richiede conversazioni e test diretti con il cliente. Entrambi generano feedback che devono essere gestiti in modo efficace.

Ogni punto di feedback è una potenziale soluzione alla necessità del cliente. Ancora più importante, ogni bit di feedback diretto dei clienti rappresenta un'opportunità per migliorare la partnership. Se il feedback viene inserito in una soluzione MVP, celebratelo con il cliente. Anche se alcuni feedback non sono interattivi, semplicemente essere trasparenti con la decisione di deprioritizzare il feedback dimostra una mentalità orientata alla crescita e un focus sull'apprendimento continuo.

Azure DevOps include modi per richiedere, fornire e gestire commenti e suggerimenti. Questi strumenti centralizzano il feedback in modo che il team possa intervenire e fornire un follow-up in servizio di un ciclo di feedback trasparente.

Integrazione continua

L'integrazione continua è l'automazione del codice più volte al giorno per avere un singolo progetto aggiornato. Man mano che le adozioni scalano e un'ipotesi si avvicina all'innovazione su larga scala, il numero di ipotesi più piccole da testare tende a crescere rapidamente. Per ottenere cicli di feedback accurati e processi di adozione senza problemi, è importante che tali ipotesi siano integrate e di supporto dell'ipotesi principale alla base dell'innovazione. Ciò richiede di passare rapidamente all'innovazione e alla crescita, che richiede più sviluppatori per testare le variazioni dell'ipotesi di base. Per le attività di sviluppo in fasi successive, potrebbero essere necessari anche più team di sviluppatori, ognuno dei quali si basa su una soluzione condivisa. L'integrazione continua è il primo passo verso la gestione di tutte le parti mobili.

Nell'integrazione continua, le modifiche al codice vengono spesso unite nel ramo principale. I processi di compilazione e test automatizzati assicurano che il codice nel ramo principale sia sempre di qualità di produzione. In questo modo gli sviluppatori collaborano per sviluppare soluzioni condivise che forniscono cicli di feedback accurati e affidabili.

Azure DevOps e Azure Pipelines offrono funzionalità di integrazione continua con pochi passaggi in GitHub o in altri repository. Per altre informazioni, vedere Che cos'è l'integrazione continua? o provare il lab pratico per l'integrazione continua. Sono disponibili architetture di soluzioni che consentono di accelerare la creazione delle pipeline CI/CD tramite Azure DevOps.

Test affidabili

I difetti in qualsiasi soluzione possono creare falsi positivi o falsi negativi. Gli errori imprevisti possono causare facilmente errori di interpretazione errata delle metriche di adozione degli utenti. Possono anche generare feedback negativo da parte dei clienti che non rappresenta accuratamente i risultati del test della tua ipotesi.

Durante le iterazioni iniziali di una soluzione MVP, sono previsti difetti. I primi utenti potrebbero persino trovarli adorabili. Nelle versioni precedenti, i test di accettazione sono in genere inesistenti. Tuttavia, un aspetto della compilazione con empatia riguarda la convalida dell'esigenza e dell'ipotesi. Entrambi possono essere completati tramite unit test a livello di codice e test di accettazione manuali prima della distribuzione. Insieme, questi forniscono alcuni mezzi di affidabilità nei test. È consigliabile provare ad automatizzare una serie ben definita di test di compilazione, unità e accettazione. Queste metriche garantiranno metriche affidabili correlate alle modifiche più appropriate all'ipotesi e alla soluzione risultante.

La funzionalità Piani di test di Azure offre strumenti per sviluppare e gestire piani di test durante l'esecuzione manuale o automatizzata dei test.

Distribuzione della soluzione

Forse l'aspetto più significativo dell'adozione potenziata è la tua capacità di controllare il rilascio di una soluzione ai clienti. Fornendo una pipeline self-service o automatizzata per il rilascio di una soluzione ai clienti, si accelera il ciclo di feedback. Consentendo ai clienti di interagire rapidamente con le modifiche nella soluzione, è possibile invitarli nel processo. Questo approccio attiva anche test più rapidi delle ipotesi, riducendo i presupposti e le potenziali rielaborazioni.

Esistono diversi metodi per la distribuzione della soluzione. I tre più comuni sono:

• La distribuzione continua è il metodo più avanzato, perché distribuisce automaticamente le modifiche al codice nell'ambiente di produzione. Per i team maturi che testano ipotesi mature, la distribuzione continua può essere estremamente utile.
• Durante le fasi iniziali dello sviluppo, la continuous delivery potrebbe essere più appropriata. Nel recapito continuo, tutte le modifiche al codice vengono distribuite automaticamente in un ambiente simile a quello di produzione. Gli sviluppatori, i decision maker aziendali e altri utenti del team possono usare questo ambiente per verificare che il lavoro sia pronto per la produzione. È anche possibile usare questo metodo per testare un'ipotesi con i clienti senza influire sulle attività aziendali in corso.
• La distribuzione manuale è l'approccio meno sofisticato alla gestione delle versioni. Come suggerisce il nome, un utente del team distribuisce manualmente le modifiche al codice più recenti. Questo approccio è soggetto a errori, inaffidabile e considerato un antipattern dalla maggior parte dei tecnici esperti.

Durante la prima iterazione di una soluzione MVP, la distribuzione manuale è comune, nonostante la valutazione precedente. Quando la soluzione è estremamente fluida e il feedback dei clienti è sconosciuto, c'è un rischio significativo per reimpostare l'intera soluzione (o anche l'ipotesi principale). Ecco la regola generale per la distribuzione manuale: nessuna prova del cliente, nessuna automazione della distribuzione.

Investire in anticipo può portare a perdere tempo. Ancora più importante, può creare dipendenze dalla pipeline di rilascio che rende il team meno incline a un cambiamento anticipato. Dopo le prime iterazioni o quando il feedback dei clienti suggerisce un potenziale successo, è consigliabile adottare rapidamente un modello più avanzato di distribuzione.

In qualsiasi fase di convalida dell'ipotesi, Azure DevOps e Azure Pipelines offrono funzionalità di distribuzione continua e distribuzione continua. Per altre informazioni sul recapito continuo, vedere il lab pratico. L'architettura della soluzione può anche accelerare la creazione di pipeline CI/CD tramite Azure DevOps.

Misurazioni integrate

Quando si misura l'impatto dei clienti, è importante comprendere in che modo i clienti reagiscono alle modifiche nella soluzione. Questi dati, noti come telemetria, forniscono informazioni dettagliate sulle azioni eseguite da un utente (o una coorte di utenti) quando si lavora con la soluzione. Da questi dati, è facile ottenere una convalida quantitativa dell'ipotesi. Queste metriche possono quindi essere usate per modificare la soluzione e generare ipotesi più granulari. Queste modifiche più sottili aiutano a maturare la soluzione iniziale nelle iterazioni successive, alla fine guidando a ripetere l'adozione su larga scala.

In Azure Monitoraggio di Azure offre gli strumenti e l'interfaccia per raccogliere ed esaminare i dati dalle esperienze dei clienti. È possibile applicare tali osservazioni e informazioni dettagliate per perfezionare il backlog usando Azure Boards.

Passaggi successivi

Dopo aver acquisito una conoscenza degli strumenti e dei processi di pipeline CI/CD necessari per supportare l'adozione, è il momento di esaminare una disciplina di innovazione più avanzata: interagire con i dispositivi. Questa disciplina può contribuire a ridurre le barriere tra esperienze fisiche e digitali, rendendo la soluzione ancora più semplice da adottare.

Interagire con i dispositivi