Supportare l'adozione con l'invenzione digitale

Il test definitivo dell'innovazione è la reazione dei clienti all'invenzione. L'ipotesi si è rivelata vera? I clienti usano la soluzione? È scalabile per soddisfare le esigenze della percentuale di utenti desiderata? L'aspetto più importante: continuano a tornare? Nessuna di queste domande può essere posta fino a quando non viene distribuita la soluzione per il prodotto minimo funzionante (MVP).

Questo articolo illustra come supportare l'adozione con strumenti per la pipeline di integrazione continua e distribuzione continua (CI/CD). L'integrazione continua è l'automazione del codice più volte al giorno per ottenere un singolo progetto aggiornato. La distribuzione continua è il recapito automatico di tali funzioni nel corso della giornata.

Ridurre gli attriti di CI/CD che influiscono sull'adozione

Alcuni ostacoli all'adozione possono essere ridotti al minimo tramite una combinazione di tecnologia e processi. Per i lettori con conoscenze dei processi CI/CD o DevOps, avranno familiarità con i processi della pipeline CI/CD seguenti. Questo articolo definisce un punto di partenza che alimenta l'innovazione e i cicli di feedback per i team di adozione del cloud. Questo punto di partenza potrebbe promuovere approcci di CI/CD o DevOps più solidi con l'evolversi della maturità dei prodotti e dei team.

Come descritto in Misurare l'impatto sui clienti, la convalida positiva di qualsiasi ipotesi richiede iterazione e determinazione. Questo articolo su CI/CD ha lo scopo di ridurre al minimo I picchi tecnici che rallentano l'innovazione, assicurando al tempo stesso di rispettare le procedure consigliate. Questo approccio consentirà al team di progettare per il successo futuro, con la garanzia di soddisfare al tempo stesso le esigenze attuali dei clienti.

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

L'obiettivo principale della metodologia Innovazione consiste nel creare partnership con i clienti e accelerare i cicli di feedback, che generano 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 affidabili: convalidare la qualità della soluzione e le modifiche previste per garantire l'affidabilità delle metriche di test.
• Distribuzione della soluzione: distribuire le soluzioni affinché il team possa condividere rapidamente le modifiche con i clienti.
• Misura 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, presupporre che la maturità rispetto a questi principi sia inizialmente bassa. Pianificare in anticipo allineando gli strumenti e i processi che possono crescere con l'aumentare del livello di dettaglio delle ipotesi. In Azure, GitHub e Azure DevOps consentono ai team di piccole dimensioni di iniziare con il minimo attrito. Questi team possono crescere fino a includere migliaia di sviluppatori che collaborano a soluzioni su larga scala e testano centinaia di ipotesi dei clienti. Nella parte restante di questo articolo viene illustrato l'approccio "pianificare in, iniziare in piccolo" per migliorare l'adozione di questi principi.

Soluzione condivisa

Come descritto in Misurare l'impatto sui clienti, la convalida positiva di qualsiasi ipotesi richiede iterazione e determinazione. Si riscontrerà un numero di errori molto maggiore rispetto a quello che si verifica durante qualsiasi ciclo di innovazione. Si tratta di un comportamento previsto. Tuttavia, quando l'esigenza di un cliente, un'ipotesi e una soluzione sono allineate su larga scala, il mondo cambia rapidamente.

Per supportare l'innovazione e l'invenzione digitale su larga scala, non esiste uno strumento più utile di una codebase condivisa per la soluzione. Sfortunatamente, non esiste un modo affidabile per stimare quale iterazione o quale prodotto minimo funzionante (MVP) costituisce la combinazione vincente. Per questo motivo non è mai troppo presto per stabilire una codebase o un repository condiviso. Questo è l'unico picco tecnico che non deve essere ritardato. Mentre il team esegue l'iterazione tra varie soluzioni MVP, un repository condiviso favorisce la collaborazione semplificata e lo sviluppo accelerato. Quando le modifiche alla soluzione causano una riduzione delle metriche di apprendimento, il controllo delle versioni consente di eseguire il rollback a una versione precedente e più efficace della soluzione.

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

Cicli di feedback

Rendere il cliente parte della soluzione è la chiave per creare partnership con i clienti durante i cicli di innovazione. Questa operazione viene eseguita, in parte, misurando l'impatto sul cliente. 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 per le esigenze del cliente. Ancora più importante, ogni feedback diretto del cliente rappresenta un'opportunità per migliorare la partnership. Se il feedback si trasforma in una soluzione MVP, festeggiare con il cliente. Anche se alcuni feedback non sono utilizzabili, essere semplicemente trasparenti con la decisione di ridurre la priorità del feedback dimostra una mentalità orientata alla crescita e un'attenzione particolare all'apprendimento continuo.

Azure DevOps include modi per richiedere, fornire e gestire i feedback. Questi strumenti centralizzano i feedback affinché il team possa intervenire e fornire il follow-up al fine di un ciclo di feedback trasparente.

Integrazione continua

L'integrazione continua è l'automazione del codice più volte al giorno per ottenere un singolo progetto aggiornato. Man mano che le adozioni si evolvono e un'ipotesi si avvicina alla vera innovazione su larga scala, il numero di ipotesi più piccole da testare tende a crescere rapidamente. Per cicli di feedback accurati e processi di adozione senza intoppi, è importante che tali ipotesi siano integrate e supportino l'ipotesi principale alla base dell'innovazione. A questo scopo è necessario agire rapidamente per innovare e crescere con l'aggiunta di più sviluppatori per testare le varianti dell'ipotesi di base. Per le attività di sviluppo delle fasi successive, potrebbero anche essere necessari più team di sviluppatori, ognuno dei quali gestisce una parte di una soluzione condivisa. L'integrazione continua è il primo passaggio 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 la qualità del codice nel ramo principale sia sempre del livello produzione. Questo garantisce che gli sviluppatori collaborino 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 l'esercitazione pratica sull'integrazione continua. Sono disponibili architetture di soluzioni che possono accelerare la creazione di pipeline CI/CD tramite Azure DevOps.

Test affidabili

In tutte le soluzioni i difetti possono creare falsi positivi o falsi negativi. Errori imprevisti possono facilmente causare un'errata interpretazione delle metriche di adozione da parte degli utenti. Possono anche generare feedback negativi da parte di clienti che non rappresentano accuratamente il test dell'ipotesi.

Durante le iterazioni iniziali di una soluzione MVP, i difetti sono previsti. Gli early adopter potrebbero persino trovarli avvincenti. Nelle versioni iniziali, il test di accettazione è in genere inesistente. Tuttavia, un aspetto della creazione con empatia riguarda la convalida dell'esigenza e dell'ipotesi. Entrambe possono essere completate tramite unit test a livello di codice e test di accettazione manuali prima della distribuzione. Insieme, forniscono alcuni mezzi per garantire l'affidabilità nei test. È consigliabile provare ad automatizzare una serie ben definita di test di compilazione, unit test e test di accettazione. Consentiranno di garantire metriche affidabili correlate a modifiche più fini all'ipotesi e alla soluzione risultante.

La funzionalità Azure Test Plans fornisce strumenti per sviluppare e gestire piani di test durante l'esecuzione di test manuali o automatizzati.

Distribuzione della soluzione

Probabilmente l'aspetto più significativo per supportare l'adozione è la possibilità 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. Consentire ai clienti di interagire rapidamente con le modifiche nella soluzione, significa invitarli nel processo. Questo approccio attiva anche test più rapidi delle ipotesi, riducendo i presupposti e le potenziali rilavorazioni.

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 stanno testando ipotesi mature, la distribuzione continua può essere estremamente utile.
• Durante le prime fasi di sviluppo, il recapito continuo potrebbe risultare più appropriato. Nel recapito continuo tutte le modifiche al codice vengono distribuite automaticamente in un ambiente di tipo produzione. Gli sviluppatori, i decisori aziendali e altri membri del team possono usare questo ambiente per verificare che il codice sia pronto per la produzione. È anche possibile usare questo metodo per testare un'ipotesi con i clienti senza compromettere le attività aziendali in corso.
• La distribuzione manuale è l'approccio meno sofisticato alla gestione del rilascio. Come suggerisce il nome, un utente del team distribuisce manualmente le modifiche più recenti al codice. Questo approccio è soggetto a errori, inaffidabile e considerato come un antipattern dai tecnici più 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, esiste un rischio significativo nel 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ò causare perdite di tempo. Inoltre, può creare dipendenze dalla pipeline di versione che rendono il team più resistente a una svolta anticipata. Dopo le prime iterazioni o quando il feedback dei clienti suggerisce un potenziale successo, è necessario adottare rapidamente un modello di distribuzione più avanzato.

In qualsiasi fase della convalida delle ipotesi, Azure DevOps e Azure Pipelines offrono funzionalità di recapito continuo e distribuzione continua. Altre informazioni sul recapito continuo o vedere l'esercitazione pratica. L'architettura della soluzione può anche accelerare la creazione delle pipeline CI/CD tramite Azure DevOps.

Misure integrate

Quando si misura l'impatto sui clienti, è importante comprendere in che modo i clienti reagiscono alle modifiche nella soluzione. Questi dati, noti come dati di telemetria, forniscono informazioni dettagliate sulle azioni eseguite da un utente (o da una coorte di utenti) durante l'uso della 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ù dettagliate. Queste modifiche più sottili consentono di maturare la soluzione iniziale nelle iterazioni successive al fine di incentivare la ripetizione dell'adozione su larga scala.

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

Passaggi successivi

Dopo aver acquisito una conoscenza degli strumenti e dei processi della pipeline CI/CD necessari per supportare l'adozione, è possibile esaminare una disciplina di innovazione più avanzata: interagire con i dispositivi. Questa disciplina consente di ridurre le barriere tra esperienze fisiche e digitali, semplificando ulteriormente l'adozione della soluzione.

Interagire con i dispositivi