Cos'è una release in ingegneria software?
Nell'ingegneria del software, una release è un software nuovo o modificato e il processo della sua creazione. Una release costituisce una versione completamente funzionale del software ed è il culmine dei processi di sviluppo e ingegneria del software. Le versioni alfa e beta del software in genere precedono la sua release.
Mentre i lanci delle versioni alfa e beta possono essere definiti anche release alfa o beta, quando si usa il singolare ci si riferisce principalmente alla versione finale del software. Potrebbero anche esistere release definite lanci o incrementi.
La maggior parte delle organizzazioni identifica le release con un insieme univoco di numeri o lettere che si aggiornano in sequenza. Questo processo di denominazione è chiamato versioning del software. Non esistono regole a livello di settore per il modo in cui questi identificatori univoci cambiano da release a release, ma ogni azienda segue costantemente il proprio standard interno.
Cos'è il processo di gestione delle release?
Le organizzazioni migliorano la qualità, la velocità e l'efficienza della costruzione o dell'aggiornamento del software concentrandosi sulla gestione delle release. Questo è il processo di pianificazione, programmazione e gestione di una compilazione software attraverso le fasi di sviluppo, test, distribuzione e supporto alla release. Tecniche come lo sviluppo Agile, la consegna continua, DevOps e l'automazione hanno contribuito a ottimizzare la gestione delle release.La velocità di questo processo si è accelerata di recente, al punto che diversi anni fa Amazon ha superato il traguardo di 50 milioni di distribuzioni di codice all'anno, più di una al secondo.
La gestione delle release è una disciplina relativamente nuova nell'ingegneria del software, ma sta anche crescendo rapidamente grazie a frequenti innovazioni tecnologiche. Come disciplina, attinge sia alla gestione dei progetti tradizionale e orientata al business, sia alle conoscenze tecniche del ciclo di vita dello sviluppo dei sistemi (SDLC) e alla libreria dell'infrastruttura IT, un insieme di pratiche per la gestione dei servizi IT.
Gli obiettivi e i vantaggi della gestione delle release
Eseguita in modo efficace, la gestione delle release aumenta il numero di release di successo da parte di un'organizzazione e riduce i problemi di qualità. La produttività, la comunicazione e la coordinazione sono migliorate e l'organizzazione può fornire software più rapidamente riducendo i rischi.
Questi miglioramenti significano che il team può produrre ripetutamente software di qualità con tempi di commercializzazione più brevi, il che consente all'azienda di essere più reattiva all'ambiente operativo.
La gestione delle release aiuta anche a standardizzare e semplificare il processo di sviluppo e le operazioni. Il team implementa i controlli di release verificabili, creando così un repository per tutte le release durante il ciclo di vita. Avere un unico processo ben documentato che deve essere seguito per tutte le release aumenta la maturità organizzativa. L'aumento della standardizzazione e l'attenzione al prodotto consentono ai team di trarre lezioni più utili dall'esperienza e di applicarle nelle release future.
I reparti operativi apprezzano la maggiore coordinazione con gli sviluppatori perché ci sono meno sorprese. Ora possono evitare di riscontrare release semplicemente "buttate lì" dopo lo sviluppo, con i team operativi che devono risolvere le problematiche e applicare patch sperando che tutto vada bene, a causa delle tempistiche strette. C'è anche l'opportunità di risolvere i problemi di configurazione tra gli ambienti di sviluppo e quelli operativi.
In breve, la gestione delle release abbatte le barriere del team tra più funzioni in un'organizzazione IT. Di conseguenza, è possibile migliorare la consegna del prodotto in modo olistico.
Gabriel Gutierrez, a Solutions Architect at Boeing and former Release Manager at Costco, says that when executing a release, it’s important to give adequate consideration to the impacts on other areas of the organization. “Companies must provide a common forum where changes are fully vetted and put through thorough architectural and design reviews that eventually lead to integrated testing. Cross-functional and technical reviews are essential to minimizing the inevitable pain after go-live. A smooth post-go-live operation is a critical success factor of any release,” he explains.
Una breve cronologia della gestione delle release
L'ascesa della gestione delle release deriva dal passaggio dell'ingegneria del software dall'offerta basata sui progetti a quella di prodotto. Secondo il paradigma di sviluppo basato sul progetto, gli sviluppatori di software considerano ogni release come un progetto, non come un prodotto; un software completamente sviluppato ha segnalato in gran parte la fine del ruolo degli sviluppatori.
Nel corso del tempo, tuttavia, il processo di sviluppo software è arrivato ad assomigliare più da vicino al ciclo del prodotto in cui i prodotti vengono supportati, migliorati e ripetutamente rilanciati nel corso di una durata molto estesa. In questo quadro, la release non era l'obiettivo finale dello sviluppo, ma piuttosto un punto di transizione per il supporto e la revisione.
Con questa maggiore complessità è nata una maggiore necessità di coordinare le fasi. Ecco perché le attuali pratiche di gestione delle release sono ispirate, in parte, ai principi della gestione dei progetti incentrata sul business, che si estende al supporto post-vendita e all'ulteriore sviluppo.
La gestione delle release fa parte della più ampia disciplina IT della gestione delle modifiche, che si occupa delle turbolenze intrinseche dello sviluppo del software, in cui i requisiti degli stakeholder che sembrano mutare in eterno e il panorama della conformità e della regolamentazione che continuano anch'esse a cambiare. Per navigare in questo ambiente, i processi di ingegneria del software devono essere ben sincronizzati e la gestione delle release aiuta a raggiungere questo obiettivo. Nota: la gestione delle modifiche non deve essere confusa con il cambiamento organizzativo, che consiste nel rimodellamento della cultura, nel ricambio di persone e nella ristrutturazione interna delle organizzazioni.
A “common pitfall is disregarding the importance of a well-thought-out change management process,” says Jen Dunbeck, a release manager at automated IT services provider BitTitan. “A change control board's or change advisory board's significance cannot be underestimated in a release. A key function of their job is to help the organization assess risk and impact with impartiality. They also help root out technical dependencies that may not have been evident as individual contributions to the deployment,” she adds.
Per sviluppare il tuo processo di gestione delle modifiche, troverai utili modi standard per proporre le modifiche al progetto e registrarle man mano che vengono approvate e apportate. Avvia l'impegno scaricando i seguenti modelli gratuiti per una proposta di modifica e un registro di gestione delle modifiche.
Modello di proposta di modifica
Una proposta di cambiamento delinea il tipo e la scala del cambiamento ed è spesso il primo passo di un processo di gestione del cambiamento. Descrivi il motivo che rende necessario un cambiamento, i risultati e gli impatti previsti, i tempi e le risorse necessarie e qualsiasi altro fattore che deve essere rivisto. Questo modello include anche spazio per aggiungere informazioni descrittive e sezioni per calcolare i costi e i benefici.
Scarica il modello in formato Excel
Registro di gestione delle modifiche
Un registro della gestione delle modifiche è un documento che monitora chi ha richiesto quali modifiche e quando, lo stato della richiesta di modifica, la sua priorità e le informazioni sull'esito. Se hai bisogno di un registro più approfondito, includi altri dettagli come il tipo e l'impatto della modifica. Questo modello di registro è stato progettato per tenere traccia delle informazioni essenziali, in modo che le richieste di modifica possano essere facilmente prioritizzate, affrontate e recensite in seguito.
Scarica il modello in formato Excel
Come funziona la gestione delle release: una panoramica
Non tutti i software sono creati uguali. A seconda della funzionalità e dell'applicazione del programma, il processo di ingegneria del software varia in rigore e intensità.
Ad esempio, il software progettato per l'uso negli aerei viene sottoposto a test rigorosi. Se non si soddisfano le ristrette tolleranze di prestazione, è necessario creare una documentazione completa e implementare più correzioni. I requisiti funzionali e le metriche di qualità sono rigorosi e il software deve passare attraverso molti livelli di approvazione prima di avvicinarsi a un aereo.
Un processo di gestione disciplinato delle release aiuterà a garantire che il software sia costruito, testato e consegnato in linea con le disposizioni degli stakeholder principali. Il team verificherà il software per vedere se fa quello che dovrebbe fare e se sarà pronto nei tempi previsti.
La gestione delle release combina i seguenti elementi in un archivio centrale:
- Gli imperativi aziendali di fornire ai clienti ciò di cui hanno bisogno quando ne hanno bisogno
- I compiti tecnici dell'assicurazione della qualità e della conformità
- La gestione degli artefatti software
Dal repository, gli artefatti vengono rilasciati in un ambiente di produzione client per la distribuzione delle applicazioni. Quindi, si può pensare alla gestione delle release come al collante che tiene insieme le attività interconnesse ma distinte che comprendono l'ingegneria del software: progettazione, sviluppo, test, implementazione, manutenzione e requisiti aziendali e dei clienti.
Una release comprende molto di più delle funzioni principali di ingegneria del software. Mentre gli sviluppatori considerano ovviamente una release come la consegna avvenuta di un prodotto finito, sono coinvolte anche diverse attività aziendali di supporto, come la formazione dei venditori e del personale di assistenza clienti e la pubblicità e il marketing della nuova release. Queste attività devono essere svolte in sincronia con il tempo di rilascio, aggiungendo complessità al processo di gestione della release.
Inoltre, la gestione delle release non è solo per i software di nuova concezione. Il software modificato passa attraverso lo stesso processo per garantire che gli stakeholder abbiano ciò che vogliono.
La release effettiva può essere effettuato manualmente o, sempre più spesso, può essere automatizzata, a seconda della maturità del processo di gestione. Amazon utilizza un processo di release automatico per ottenere una nuova versione ogni secondo. Storicamente, gli aggiornamenti settimanali, mensili e trimestrali sono stati più comuni per i team di sviluppo software.)
Le release possono essere disponibili in molte forme diverse: come prodotto fisico in una scatola, come download da un sito Web o da un server, come push a un dispositivo da un app store mobile o come aggiornamento continuo a un'applicazione basata sul web.
Tutti i gruppi di ingegneria del software, sia grandi che piccoli e in tutti i settori, utilizzano la gestione delle release per rendere più fluido il processo. Possono applicarlo a software utilizzati internamente o venduti come prodotto. I gruppi di ingegneria del software grandi e piccoli impiegano la gestione delle release in tutti i settori e possono utilizzare il software risultante per eseguire il proprio prodotto o i propri sistemi, o per venderla come prodotto in sé ai clienti.
Uno degli approcci di sviluppo più favorevoli alla gestione delle release è chiamato DevOps, un termine formato dalla combinazione di sviluppo e operazioni. Come suggerisce il nome, DevOps cerca di aumentare il coordinamento tra gli sviluppatori e le operazioni nell'ingegneria del software utilizzando una combinazione di automazione e monitoraggio in tutte le fasi dello sviluppo del software per ridurre il time-to-market e migliorare la soddisfazione dei clienti.
Termini chiave nella gestione delle release
Per padroneggiare la gestione delle release, è necessario comprendere i termini comunemente utilizzati.
Ordine di lavoro di sviluppo: è un ordine di lavoro per lo sviluppo o la modifica di un'applicazione o di un sistema software.
Team DevOps: poiché l'intero punto di DevOps è quello di aumentare il coordinamento tra le funzioni di sviluppo e le operazioni, la creazione di un team separato rende il termine un nome sbagliato. Nonostante il nome, il termine si riferisce solitamente ai membri chiave del team sia sul lato dello sviluppo che delle operazioni che lavorano per coordinare le due funzioni.
Ordine di lavoro di installazione: simile a un ordine di lavoro di sviluppo, un ordine di lavoro di installazione si riferisce all'installazione di un'applicazione software, di un sistema o di un componente infrastrutturale.
Product owner: il product owner di un progetto di sviluppo è il principale stakeholder. Di solito rappresenta l'azienda o gli utenti (eventuali) del prodotto e definisce la visione del prodotto stesso.
Project Manager: un project manager si occupa della direzione di un singolo prodotto. È responsabile della definizione della roadmap, della visione del prodotto e della negoziazione dei deliverable. In genere, le responsabilità principali di un project manager non si estendono oltre un singolo prodotto o una famiglia di prodotti strettamente correlati.
Release: una versione è composta da una o più unità di release.
Release manager: il ruolo del release manager è quello di pianificare, coordinare, gestire e programmare tutti gli elementi che comprendono una release. Tutti questi elementi non devono necessariamente provenire dallo stesso prodotto. Ad esempio, questo manager deve anche coordinare il lavoro su qualsiasi altro prodotto progettato per l'integrazione con la nuova versione.
Politiche di release: si tratta di un insieme di regole per la distribuzione delle release nell'ambiente operativo in tempo reale. A diverse release si applicano diverse politiche, a seconda di fattori come l'impatto e l'urgenza.
Record di release: un record di release documenta la storia di una release, dalla pianificazione alla chiusura del processo di sviluppo.
Unità di release: questo termine si riferisce a una serie di elementi di configurazione che un team testa e rilascia contemporaneamente nell'ambiente in tempo reale per implementare le modifiche approvate. Un elemento di configurazione, a sua volta, è un componente di un'infrastruttura in gestione della configurazione, ovvero il processo per assicurarsi che gli attributi e le prestazioni di un prodotto siano coerenti con il suo design, i requisiti e le informazioni operative.
Proprietario del servizio: un proprietario del servizio si assume la responsabilità generali per uno specifico servizio IT. Sono meno interessati alle operazioni quotidiane necessarie per fornire il servizio, che è il ruolo di un service manager.
Responsabile della qualità: un responsabile della qualità garantisce che una release soddisfi gli standard stabiliti. Potrebbe disporre di release manager che fanno capo a lui.
Concetti chiave nella gestione delle release
La gestione delle release è talvolta descritta come una superdisciplina, perché prevede la supervisione di diverse discipline interconnesse ma distinte, nota l'esperto di gestione delle configurazioni Salman Khwaja.
Una delle pratiche centrali nella gestione delle release è la gestione del codice, che è il processo di gestione delle modifiche al codice informatico. Utilizzando moduli o raccolte di righe, la gestione del codice semplifica e accelera le modifiche al codice e ad altre attività relative al codice, come la manutenzione e il debug. Un tipo di gestione del codice che costituisce un aspetto importante della gestione delle release è il controllo delle versioni. Si tratta della gestione del codice per diverse release dello stesso software ai fini del confronto e del riferimento. La gestione del codice segue molti dei principi della gestione dei record.
Per svolgere efficacemente il proprio ruolo, un release manager deve favorire la facilitazione e la collaborazione, principalmente tra i team ma anche all'interno dei team. I release manager sono in genere professionisti con esperienza, quindi potrebbe essere chiesto spesso il loro aiuto.
I processi e le politiche sono fondamentali per una gestione efficace delle release. I problemi sono destinati a sorgere e, quando lo fanno, devono esserci dei protocolli per affrontarli. Il release manager funziona anche come guardiano o custode del codice di produzione. Sa ogni volta che un artefatto del codice esce dall'organizzazione.
In diverse release, diventa possibile misurare le metriche di produttività e throughput in modo che l'efficienza della gestione delle release diventi visibile. Le metriche comuni includono cose come la velocità e il tasso di burndown.
Il ciclo di gestione delle release
La gestione delle release segue in genere un percorso chiaramente definito. Inizia con la creazione di un piano di release a livello aziendale. Alcune aziende possono rilasciare aggiornamenti software continuamente, ma altre preferiscono un piano prestabilito. Successivamente viene la pianificazione della release del prodotto o della soluzione.
La gestione delle release inizia solitamente nella prima fase del ciclo di sviluppo, quando il release manager riceve richieste di modifiche o nuove funzionalità. Dopo l'approvazione della richiesta, il team progetta la nuova release e inizia la pianificazione. Gli sviluppatori costruiscono il nuovo software. Dopo lo sviluppo, la release viene testata e il team può apportarvi modifiche prima che venga accettata. Successivamente, la release passa alla distribuzione, dove viene resa disponibile per l'uso completo. La fase post-distribuzione è il supporto, in cui i bug o le user story che il team documenta qui possono essere inseriti nel ciclo di sviluppo come materiale per una nuova versione.
Modello di piano di rilascio semplice
Utilizza il modello seguente per un piano di release semplice. Per progetti particolarmente complessi e ad alto budget, il quadro di piano di release sviluppato dal Center for Medicaid Services, che può essere scaricato qui, è un buon riferimento.
Scarica il modello di piano di rilascio semplice — Word
Sfide che la gestione delle release può aiutare ad affrontare
Storicamente, molte aziende non disponeva di processi per gestire il ciclo delle release Tuttavia, poiché i problemi possono rappresentare un colpo per i profitti, con bug e crash che costano molto tempo e denaro (nonché affidabilità e reputazione), la gestione delle release è nata come disciplina per affrontare alcune sfide comuni.
Alcune organizzazioni hanno difficoltà a distribuire codice dagli ambienti di sviluppo a test e produzione e, sebbene questo possa avere un impatto minore sui profitti, non è motivo di minore preoccupazione per il personale delle operazioni.
Altre volte, la struttura interna di un'organizzazione può dare origine a conflitti tra i team e la gestione delle release può ridurre gli attriti. Allo stesso modo, quando ci sono molti team di consegna che lavorano in tandem, si aumenta il rischio che il lavoro di un team interrompa quello di un altro. Un processo di gestione delle release efficiente può aiutare le organizzazioni a evitare una serie di problemi.
Gestione delle release e DevOps in un mondo Agile
Le organizzazioni che basano lo sviluppo del software su principi Agile popolari producono solitamente release più frequenti. L'approccio Agile alle release del software si chiama consegna continua, un metodo che mira a creare codice pronto per la distribuzione in qualsiasi momento. Elimina quasi completamente le fasi convenzionali di integrazione e test e automatizza il processo di release su cicli molto brevi.
Software product development expert and author Jon Quigley of Value Transformation notes that studies have shown an inverse relationship between project size and success. He also says research suggests that customers do not use 45 percent of developed features. These statistics argue for small, focused releases that prioritize features highly valued by customers. “The upshot of all of this has driven deliveries of software or development of increments of software that are small, the smaller the better,” he says.
Nella distribuzione continua, la gestione delle release rimane il connettore critico tra sviluppo e produzione. La gestione delle release verifica l'integrità del codice e si assicura che funzioni come previsto. I metodi Agile suddividono i silos spesso osservati con le metodologie a cascata, ma Agile richiede una documentazione approfondita, quindi i processi sono chiari.
Gutierrez di Boeing afferma che c'è molta confusione sulla consegna continua e su un'altra pratica popolare, la distribuzione continua. "La distribuzione continua è il concetto che ogni modifica apportata alla base del codice verrà distribuita quasi immediatamente alla produzione se i risultati della pipeline avranno successo. La consegna continua è il concetto secondo cui ogni modifica alla base del codice passa attraverso la pipeline fino al punto di distribuirsi in ambienti non di produzione. Il team trova e risolve i problemi immediatamente, non in un secondo momento, quando prevede di rilasciare il codice di base. Il codice di base è sempre a un livello di qualità sicuro per la release. Quando rilasciare il codice di base alla produzione è deciso dall'azienda", spiega.
Per rilasciare in modo efficace ed efficiente la base di codice alla produzione, i release manager si affidano a tre cose: l'automazione, la mentalità DevOps e l'integrazione continua. L'automazione si riferisce principalmente alle funzioni di testing, mentre la mentalità DevOps migliora notevolmente il coordinamento tra sviluppo e operazioni (le persone di consegna e di infrastruttura possono essere le stesse) al fine di appianare il passaggio potenzialmente brusco dalle prime alle seconde.
L'integrazione continua, invece, è la pratica degli sviluppatori che aggiornano frequentemente le proprie copie di codice funzionanti su una linea principale, di solito circa una volta al giorno. L'integrazione continua si basa su un rigoroso sistema di test automatizzati e tende a eliminare rapidamente gli errori e accelerare il processo di modifica.
Modello di piano di rilascio Agile
La pianificazione delle release Agile si verifica prima del primo sprint, in modo da poterti concentrare sugli obiettivi di rilascio, sulle caratteristiche e sull'assegnazione delle risorse. Questo modello di rilascio Agile consente di elencare tutte le attività, assegnare ogni attività a uno sprint e calcolare la durata in base alle date di inizio e fine. Puoi anche indicare lo stato di ogni attività dal menu a discesa e definire ogni obiettivo corrispondente.
Modello per la pianificazione dei test Agile
Nei progetti Agile, la fase di test è un processo dinamico e iterativo destinato a garantire l'utilizzo delle informazioni più aggiornate per definire i test ed evitare eventuali malintesi nell'ambito. Questo modello di piano di test fornisce spazio per monitorare le azioni, i risultati attesi, i risultati effettivi e se il test è stato superato o non riuscito.
Scarica il modello di pianificazione dei test Agile — Excel
Gestione delle release con la libreria dell'infrastruttura IT/Gestione dei servizi IT
La gestione dei servizi IT è un superinsieme di attività che le organizzazioni utilizzano per progettare, pianificare, fornire, gestire e controllare i servizi IT che offrono. Tra queste c'è un insieme dettagliato di pratiche note come Information Technology Infrastructure Library (ITIL). Nelle organizzazioni che gestiscono le proprie operazioni IT utilizzando ITSM, e in particolare ITIL, la gestione delle release è guidata dai principi ITIL.
Nella sua forma attuale, nota come ITIL 2011, ITIL si compone di cinque volumi. La gestione delle release è inclusa nel terzo di questi volumi, il volume di transizione del servizio, che riguarda la fornitura di servizi a uso operativo. Come si potrebbe intuire, il processo di gestione delle release e della distribuzione mira a "pianificare, programmare e controllare lo spostamento delle release in ambienti di test e live." Anche la gestione delle modifiche è inclusa nel terzo volume.
Le release nelle organizzazioni ITIL avvengono molto meno frequentemente rispetto alle organizzazioni Agile. I processi di release in ITIL sono gestiti utilizzando i sistemi di ticketing ITSM e non c'è molta enfasi sui processi di release automatizzati. Questo non significa che siano meno efficaci. Le organizzazioni che implementano le pratiche ITIL possono fare molto di più che aumentare l'efficienza dei processi di release; possono anche realizzare guadagni finanziari e aumentare il valore aziendale dei servizi che offrono.
Gestione delle release aziendali
La gestione delle release aziendali (ERM) gestisce il quadro generale delle release a livello organizzativo di entità con software di grandi dimensioni o complessi, come sistemi sanitari, grandi aziende, università e simili. ERM si occupa del coordinamento delle singole release di software e del modo in cui si inseriscono nei piani, nelle strategie e nel calendario più ampi dell'organizzazione.
Perché è importante? Immaginiamo un'organizzazione che sviluppa sistemi complessi di software. Più gruppi di sviluppo lavorano su diversi componenti di questi sistemi di grandi dimensioni. Questa struttura ha senso internamente perché consente agli sviluppatori di specializzarsi, aumentare l'attenzione e costruire i componenti pezzo per pezzo. Ma, in definitiva, i pezzi devono convergere in un unico sistema perfettamente integrato. Senza una gestione generale delle release a livello aziendale, il portafoglio IT dell'organizzazione sarebbe privo di coesione.
ERM consente alle organizzazioni di implementare prodotti software di grandi dimensioni che funzionano bene come un insieme integrato, e li aiuta a farlo in modo efficiente. Gli sforzi di ERM richiedono in genere che molti release manager lavorino in tandem, in modo che possano sincronizzare le rispettive release.
Gestione delle release e le aree chiave della conoscenza PMI
In un documento del 2000 presentato al Project Management Institute Annual Seminar and Symposium, Franck Aguilh ha discusso della necessità di una disciplina specializzata che si concentrasse esclusivamente sulla gestione delle release tra le aziende di sviluppo software. Questo ruolo sarebbe svolto dal release manager piuttosto che dal project manager, poiché il project manager ha priorità molto più ampie.
Aguilh ha affermato che una gestione delle release di successo è un processo che raggiunge quattro obiettivi principali: implementazione nei tempi previsti, implementazione in base al budget, impatto trascurabile sui clienti esistenti e soddisfazione delle esigenze dei nuovi clienti, il tutto tenendo a mente le pressioni della concorrenza e i progressi tecnologici. Ha anche descritto la gestione delle release come un processo che coinvolge diverse "attività principali" che devono essere svolte da "organizzazioni" distinte.
La gestione delle release richiede il coordinamento tra molti reparti all'interno di un'organizzazione, ognuno dei quali svolge un ruolo specializzato. Le "organizzazioni" di Aguilh si estendono dalle vendite e marketing alla ricerca e sviluppo, dalle operazioni e dall'ingegneria dei sistemi all'assistenza clienti e legale.
"Una release di successo richiede una sincronizzazione tra reparti", afferma Dunbeck di BitTitan. "Gli sviluppatori devono controllare il codice nei punti giusti. Il reparto QA deve eseguire controlli. Le operazioni devono gestire le filiali e preparare la build per la distribuzione. Ma questi sono solo i componenti tecnici. Se non hai modo di comunicare la modifica internamente, i tuoi venditori saranno sorpresi quando mostreranno ai clienti demo che hanno modifiche alle funzionalità o ai pulsanti. Il tuo team di supporto non sarà in grado di rispondere alle domande che arrivano e i tuoi clienti non otterranno le risposte di cui hanno bisogno se non hai comunicato loro le modifiche tramite note di release, articoli del Centro assistenza o simili", sottolinea.
"Il modo più semplice per risolvere questi problemi è identificare chiaramente gli stakeholder per la release e coinvolgerli frequentemente durante il ciclo del progetto. Ogni organizzazione ha preferenze di comunicazione diverse. Riunioni, un canale di chat, una pagina Wiki o semplicemente un'e-mail sono tutti buoni modi per mantenere le persone in contatto. La parte importante è identificare una cadenza e rispettarla", conclude Dunbeck.
Secondo la visione di Aguilh, la gestione delle release si fonda in parte sull'applicazione dei principi di project management alle release di software. Queste includono le principali aree del processo di gestione dei progetti: avvio, pianificazione, esecuzione, controllo e chiusura.
Tuttavia, Aguilh ha anche ipotizzato nove processi specifici per la gestione delle release. Di seguito sono riportate le descrizioni di questi nove processi e l'ordine in cui si verificano:
- Richiesta di prodotto funzionale (FPR): questo è il meccanismo per cui un "gruppo funzionale" formalizza la propria richiesta di nuove funzionalità o funzioni da aggiungere al software.
- Processo di documentazione: il team mette in atto protocolli di condivisione delle informazioni per la prossima release.
- Processo di packaging della release: durante questo processo, il team prende una decisione sui contenuti della release finale, in base a fattori quali la pressione del mercato, i costi, le entrate, i tempi di sviluppo e l'integrazione.
- Processo di sviluppo/processo di controllo delle modifiche: queste due fasi vengono eseguite in tandem e sono auto-esplicative. Durante lo sviluppo, i "gate" di qualità possono essere utilizzati per indicare le pietre miliari del ciclo di sviluppo. Il controllo delle modifiche continua nei test di laboratorio e sul campo, che controllano sia se le nuove funzionalità funzionano come previsto sia se hanno influenzato le funzionalità esistenti.
- Processo di formazione: si tratta di una formazione del personale di supporto tecnico, del personale di vendita e marketing diretto e del personale di telemarketing.
- Test dei clienti: questa fase avviene tramite rilasci beta per i clienti.
- Processo di notifica del cliente: l'ultima fase prima della distribuzione prevede di informare i clienti che è in arrivo una release.
- Distribuzione: la distribuzione stessa è un processo a più fasi che include la pre-distribuzione, la distribuzione effettiva e la post-distribuzione.
Aguilh ha suggerito che i processi di gestione delle release corrispondono abbastanza strettamente a quelli del project management. Ad esempio, la FPR e il packaging delle release sono fondamentalmente una considerazione dell'ambito e della pianificazione, mentre la qualità corrisponde alla documentazione, allo sviluppo, al controllo delle modifiche e alla formazione. L'esecuzione e il controllo, a loro volta, corrispondono alla formazione, ai test dei clienti, alla notifica dei clienti e alla distribuzione. La chiusura, naturalmente, corrisponde alla distribuzione. Diventa evidente, quindi, che si possono tracciare paralleli utili tra la gestione del progetto e la gestione delle release e che un release manager efficace deve possedere le stesse competenze di un project manager.
Processi di gestione delle release in fasi nel ciclo di vita dello sviluppo software
Hai visto come i processi di gestione delle release si allineano ai processi di gestione dei progetti principali. Diamo ora un'occhiata a come i processi di gestione delle release si allineano alle fasi del ciclo di vita dello sviluppo software (SDLC). In genere sono presenti sei fasi in SDLC:
- Raccolta e analisi dei requisiti
- Design
- Implementazione o codificazione
- Test
- Distribuzione
- Manutenzione
Durante lo sviluppo, i manager delineano una politica di release, un documento che definisce l'ambito, i principi e gli obiettivi finali del processo di gestione delle release. Utilizza gli obiettivi strategici dell'organizzazione per informare e guidare il processo di gestione delle release. Per vedere un esempio, dai un'occhiata alle politiche di release della Apache Software Foundation, che promuove progetti software open source per il bene pubblico.
I responsabili delle release redigono i piani di release in base ai criteri di rilascio. Questi piani sono linee guida generali per la distribuzione di più release.
Durante la fase di progettazione, il release manager si assicura che le risorse hardware e software che supporteranno la release siano progettate e configurate. Quindi, inizia la codifica.
Durante l'implementazione, gli sviluppatori creano e configurano il codice. Durante i test, i tester provano il codice in un ambiente operativo. Durante la distribuzione, il personale distribuisce una versione live del software e il team di garanzia della qualità conduce una revisione della qualità per verificare che la release soddisfi i requisiti stabiliti. Se la release supera la revisione della qualità, viene convalidata e programmata per la produzione; questo sigillo di approvazione è chiamato release accettata. Se rimangono dei bug, il team respingerà la release. Una release accettata ha un piano di rollout che copre i dettagli della distribuzione e l'azienda informa i clienti e gli utenti finali della release imminente. La formazione può essere necessaria.
Le unità di release vengono distribuite alla produzione per il lancio completo. Alcune organizzazioni scelgono di verificare l'implementazione in questa fase per verificare se la release verrà eseguita senza intoppi quando è in corso.
Nella fase di manutenzione, gli sviluppatori conducono una revisione della release e registrano i problemi da risolvere per quella successiva.
Modello di piano di gestione delle release
Per rendere chiara la sequenza temporale per tutte le attività di release, crea un piano di gestione delle release. Usa questo modello per tenere traccia dei deliverable e delle scadenze chiave e mantenere tutti aggiornati.
Scarica il modello di piano di gestione delle release
Le differenze nei nomi: distribuzione, release e spedizione
Il termine distribuzione è spesso utilizzato in modo intercambiabile con le parole rilasciare e spedire, ma non significano esattamente la stessa cosa. La distribuzione rappresenta l'installazione o l'esecuzione di una nuova versione di codice su un server, pubblicata "live" con il software. Questa distribuzione può verificarsi su un server di test piuttosto che su un server di produzione. Una release è la forma software di questa nuova versione. È destinata a un pubblico che va oltre gli sviluppatori: altri utenti nell'organizzazione o clienti. Una release generalmente include un numero di versione. Quando un cliente distribuisce una release, questa viene generalmente descritta come un'installazione del software. La spedizione descrive il processo di acquisizione del codice attraverso l'intero ciclo di costruzione, test e distribuzione.
La distribuzione è un momento cruciale sia nel ciclo di vita dello sviluppo software che nel ciclo di gestione delle release. La distribuzione segna il momento in cui la nuova versione del software è disponibile per l'uso e la nuova release viene pubblicata. Secondo Paul Jackson della University of Edinburgh School of Informatics, la distribuzione sta "facendo uscire il software dalle mani degli sviluppatori per metterla nelle mani degli utenti". Per questa fase, gli utenti finali potrebbero aver bisogno di formazione.
Jackson osserva che la distribuzione è spesso problematica: oltre il 50% del software commissionato non viene utilizzato, soprattutto perché non riesce nella distribuzione. Se il software incorre in problemi durante la distribuzione, gli sviluppatori "riprendono" la versione precedente fino a quando i problemi non vengono risolti.
Jackson riferisce anche che l'80% della spesa per il software commissionato si verifica durante e dopo la distribuzione. Naturalmente, questo non significa necessariamente che la distribuzione in sé sia un fallimento; può semplicemente indicare che i problemi nello sviluppo emergono solo durante la distribuzione.
Ma a volte il problema è la distribuzione stessa. Forse, il cliente semplicemente non è pronto a un cambiamento nell'esperienza del prodotto, come spesso richiedono le release di sistemi di grandi dimensioni. La mancanza di adozione del software può anche derivare da una serie di altri fattori: l'hardware del cliente non può gestire la nuova release; il cliente ha problemi nell'installazione del software; la mancanza di formazione rappresenta un ostacolo; oppure la nuova installazione "rompe" l'altro software preesistente del cliente.
Molti dei problemi direttamente associati alla distribuzione possono essere risolti utilizzando l'automazione e la formazione, in modo che l'utente finale non debba pensare a cose come la compatibilità di sistema. L'utilizzo delle best practice nella gestione delle release rende queste soluzioni una procedura operativa standard.
Cos'è un processo di distribuzione delle release?
Il processo di distribuzione delle release si concentra sul rendere il software operativo in un ambiente live. Per questo, il software deve essere sottoposto a test ed essere ufficialmente accettato dal proprietario del prodotto o da un altro stakeholder aziendale. Durante il processo di distribuzione, gli utenti ricevono una formazione sull'aggiornamento software e i membri del team conducono una valutazione o una revisione delle prestazioni e delle modalità di distribuzione.
Best practice nella gestione delle release
Nella gestione delle release, le best practice sono le linee guida create e affinate dalle aziende che hanno già implementato ITIL con successo. Le linee guida sono di proprietà e pubblicate dal British Cabinet Office. I processi di gestione delle release ITIL sono stati utilizzati con buoni risultati da programmi spaziali, servizi sanitari, banche e aziende di intrattenimento. Le linee guida devono essere modificate dalle organizzazioni per soddisfare i propri requisiti e capacità. Ricorda, però: questi sono un quadro di partenza, non una verità assoluta.
Sebbene la gestione delle release sia più importante durante il passaggio dallo sviluppo alla produzione, essa inizia con la pianificazione delle release durante lo sviluppo. Ad esempio, è una buona idea istituire un comitato consultivo per le modifiche che supervisioni i cambiamenti in tutta l'organizzazione. È inoltre saggio progettare un sistema di gestione a singola release che possa essere utilizzato in tutto l'SDLC.
Allo stesso modo, la creazione di una lista di controllo del processo di release incoraggia la trasparenza e la comprensione condivisa del processo di gestione delle release e del modo in cui crea valore aziendale. Integrando il libro Checklist Manifesto di Atul Gawande, l'utilizzo di una checklist rende più facile esercitare il controllo sul processo di release, soprattutto se ci sono metriche da monitorare. Inoltre, aiuta ad avere un utente principale senior attivo.
“The most common pitfall with release management is not following a release checklist,” says Chris Harding, a Release Manager at Microsoft. “The details in a release checklist are key. You may be having an off day, or something may distract you while you’re configuring a product, but the checklist never lies,” he points out.
Harding crede che un semplice errore che sarebbe stato coperto da una checklist sia stato alla base della release da parte di Walmart Canada di diversi titoli di videogiochi sul suo sito web nel maggio 2018, prima del loro debutto ufficiale in una conferenza del settore. "La tempistica è stata probabilmente impostata in modo errato per le pagine del prodotto e nessuno ha notato l'errore prima della pubblicazione. Nella comunità medica, le checklist salvano vite umane. La gestione delle release non è così drammatica, ma probabilmente può salvare il tuo lavoro."
Modello di checklist per le release software
Per tenere traccia di tutte le attività di release, prendi in considerazione l'utilizzo di una checklist. Questo modello è disponibile nei formati Microsoft Word ed Excel e include spazio per elencare note e stato su marketing, sviluppo di prodotti, QA, ingegneria/DevOps, esperienza utente, supporto tecnico, servizi e attività legali. Modifica il modulo in base alle tue esigenze di progetto.
Scarica il modello di checklist per le release software
Alcune best practice sono in realtà solo buon senso. L'integrazione continua, ad esempio, migliora la qualità della release finale catturando rapidamente gli errori. Inoltre, non è una buona idea effettuare una release il venerdì, in quanto non lascerà tempo per la risoluzione dei problemi settimanale se qualcosa va storto. Vale anche la pena programmare una release durante un periodo di basso traffico: dovrai sapere quando i tuoi clienti sono attivi, in modo da poter controllare meglio i danni se le cose vanno male. Un'altra opzione è un lancio a fasi in cui le funzionalità sono rese disponibili solo a un piccolo numero di utenti alla volta. Naturalmente, è necessario eseguire il backup dei database prima delle release.
Infine, ricorda che l'implementazione di un processo di gestione delle release è un processo di per sé. La gestione delle release può essere iterata e automatizzata gradualmente nel tempo. Non cercare di forzare il processo.
Strumenti software per la gestione delle release
Gli strumenti software possono accelerare e facilitare il processo di gestione delle release.
Ad esempio, i prodotti software contemporanei sono costruiti per supportare alcune piattaforme, dai browser Internet ai server delle applicazioni e ai sistemi operativi. Quindi, devono essere testati in questi ambienti prima della release. La creazione e la manutenzione di tutti gli ambienti necessari per i test pone un problema. Ma c'è una soluzione facile: utilizzare servizi virtualizzati e cloud, come Selenio e SmartBear, che semplificano il processo di distribuzione delle configurazioni per le piattaforme target creando un ambiente simulato di ciascuna di esse per i test.
“A common challenge is automating the release but not having good automated testing in place,” notes Brian White, Senior Solutions Architect at custom software developer Small Footprint. “If you don’t have confidence in the quality of your release, it doesn’t matter how fast it can be deployed if it’s always going to break when someone starts using it,” he says.
Per facilitare l'intero processo di gestione delle release, le piattaforme di sviluppo software e i sistemi di gestione delle release, come GitHub, Jira e molti altri, offrono una stretta integrazione dei componenti necessari per una release di successo. Questi possono essere utilizzati in tutto l'SDLC, dalla pianificazione della release alla produzione.
Tali strumenti sono in genere scalabili, in base alle esigenze dell'organizzazione e centralizzano le funzioni di aggiornamento e amministrazione, il che è particolarmente utile quando sono accessibili via Internet come strumenti SaaS (software as a service). Gli strumenti migliori supporteranno anche il testing e la distribuzione dei componenti di gestione, insieme alla gestione delle modifiche e alle integrazioni con i componenti di gestione dei servizi di terze parti, che consentono un sistema di consegna end-to-end. Cerca strumenti che siano conformi alle linee guida ITIL V3 dell'IT Service Management Forum.
Gli strumenti che consentono un'automazione almeno parziale del processo di release sono di grande aiuto. Potrebbe essere possibile automatizzare la consegna del software fino alla produzione o impostare una serie semi-automatica di processi con approvazioni e implementazioni on-demand.
Altre funzioni utili includono la possibilità di tenere traccia delle modifiche tra le versioni, in modo che sia facile arrivare alla radice dei problemi e avere una struttura che elimina il dolore del rollback all'ultima versione funzionante. È utile anche la registrazione del feedback delle applicazioni, una funzionalità che può essere spostata in un backlog per le versioni future.
Inoltre, prendi in considerazione gli strumenti che possono supportare l'integrazione continua e la distribuzione continua. La distribuzione continua va oltre la consegna continua per distribuire immediatamente le modifiche quando passano attraverso la pipeline di produzione. Questo approccio accelera il processo di feedback e migliora notevolmente l'efficienza.
Metriche e KPI di gestione delle release
Una volta maturato un processo di gestione delle release, un release manager può rivolgere la propria attenzione alle metriche di prestazione con l'obiettivo di migliorare il processo. Diamo un'occhiata ad alcune di queste:
- Tempi di inattività della release: questa è la prima metrica importante. Qualsiasi release di software comporta il rischio di tempi di inattività, la cui durata può variare da pochi minuti a un certo numero di ore o addirittura giorni. I tempi di inattività non sono negativi di per sé; spesso sono una necessità. Detto questo, è importante essere in grado di differenziare i diversi tipi di tempi di inattività. I tempi di inattività stimati, ad esempio, sono i tempi di inattività necessari e integrati nel programma di release, ed è una buona idea confrontarli con i tempi di inattività effettivi, che vengono misurati dopo la release. Ci sono anche tempi di inattività non pianificati, che in alcuni release possono essere un segno di problemi alla radice non risolti.
- Tipo e priorità delle release: ogni release è classificata come maggiore, minore o da qualche parte nel mezzo e ha una priorità: alta, media o bassa. In una serie di release, esamina una ripartizione delle release per tipo e priorità. Dovrebbe esserci un buon mix di release per dimensioni e priorità. Troppi release importanti per lo stesso prodotto possono indicare problemi seri con l'assicurazione della qualità, mentre avere troppi release ad alta priorità suggerisce che il tuo team è bloccato in un tipo approccio che rischia solo di provocare burnout tra tutti.
- Il numero di release puntuali: poiché una release non è assicurata nei tempi previsti, possiamo anche avere dei ritardi. Ci sono alcune informazioni interessanti da raccogliere. Ad esempio, alcuni team di sviluppo hanno release più tardive o puntuali rispetto ad altri? Esiste un modello di consegna tardiva o puntuale basato sulla priorità della release? Quali sono le cause principali di release ripetutamente tardive?
È possibile tenere traccia di alcune metriche interessanti anche a livello aziendale. Queste includono le dimensioni delle release aziendali da tre diverse prospettive: progetti, implementazioni di sistemi e funzionalità. Un'altra serie utile di metriche tiene traccia del numero di progetti, sistemi e funzionalità con ambito ridotto. La riduzione degli ambiti si verifica quando qualcosa previsto per la release non supera il proprio "gate" di release e viene quindi tolto dalla release aziendale per non tenere quest'ultima in sospeso.
Casi di studio nella gestione delle release
Abbiamo trattato molte teorie finora e ti starai chiedendo come funziona la gestione delle release nel mondo reale. Microsoft è un ottimo esempio.
Microsoft Core Services Engineering (CSE) si basa su una combinazione di integrazione continua, distribuzione continua e una piattaforma ospitata su cloud chiamata Visual Studio Team Services (VSTS). Il loro approccio allo sviluppo, che hanno definito "ingegneria moderna", si basa sui principi dello sviluppo Agile e su DevOps.
Esamina come Microsoft struttura il suo sviluppo intorno alla consegna continua e capirai come trae così tanto vantaggio da una migliore gestione delle release. Gli ingegneri software Microsoft si concentrano sulla creazione di un prodotto con funzionalità minime, che attira i primi utenti e consente agli sviluppatori di raccogliere feedback per le versioni successive.
Gli sviluppatori Microsoft possono provare il codice in qualsiasi ambiente di distribuzione in qualsiasi momento e utilizzano la componentizzazione per facilitare la creazione del codice. Con il processo di gestione delle release di Microsoft, è possibile avviare build automatiche e una distribuzione automatica che richiede solo pochi minuti, senza competere per le risorse. Inoltre, il loro processo di convalida della distribuzione è automatizzato.
CSE adotta anche i principi Agile di progettazione iterativa e prototipazione rapida, utilizzando al contempo l'automazione per ridurre i tempi di test. Ciò significa che il CSE può accelerare i propri cicli di release, correggere rapidamente i problemi e fornire aggiornamenti e miglioramenti continui in parti più piccole, l'ultima delle quali riduce anche i rischi, poiché c'è meno tempo dedicato allo sviluppo di ciascuna funzionalità.
E non sono solo le aziende tecnologiche a trarre vantaggio dalla gestione delle release. Tra il 2008 e il 2010, la divisione IT del Central Securities Depository of Turkey ha intrapreso un'ampia automazione della gestione della configurazione, della gestione delle dipendenze e dell'infrastruttura, della gestione delle modifiche, dei database e della configurazione delle applicazioni, al fine di "rimuovere completamente" i problemi con le release, abbreviare i tempi di release e ridurre radicalmente gli errori relativi all'implementazione.
In United Airlines, un modello in quattro fasi per le release che comprende pianificazione, coordinamento, esecuzione e automazione, il tutto informato da dati completi, ha aiutato l'azienda a passare dalla gestione delle release centrata sui fogli di calcolo a un sistema centralizzato di monitoraggio e gestione delle release con dashboard.
Come migliorare la gestione delle release
Il miglioramento delle funzionalità di gestione delle release della tua organizzazione richiede la comprensione dello stato attuale del processo di gestione. Dovresti farlo in due modi: quantitativamente e qualitativamente.
Quantitativamente, è necessario raccogliere alcune metriche di base, tra cui i tempi medi di release, il tipo e la priorità delle release, il numero di errori e il numero di release in ritardo. Queste servono sia per identificare lo stato attuale della gestione delle release sia per capire le linee di base delle prestazioni.
Qualitativamente, parla con le persone che fanno parte del processo di gestione delle release, in particolare dove lo sviluppo si interfaccia con le operazioni, e scopri cosa pensano. Saranno in grado di indicare le realtà che non appaiono nei numeri.
È possibile gestire le release stabilendo un ciclo regolare, che aiuta a creare coerenza. Questo non sarà possibile per tutte le release, naturalmente, ma lo sarà per quelle di grandi dimensioni e pre-pianificate. Metti in atto processi di release leggeri invece di cercare di sviluppare una cultura fin dall'inizio. Ciò consente di stabilire l'infrastruttura per le release in anticipo e di testarla e rivederla, se necessario.
Nel corso del tempo, i processi che funzionano meglio diventeranno una pratica standard. In base al tuo sondaggio iniziale sulla gestione delle release, potresti ora essere in grado di iniziare ad imporre requisiti di qualità più rigorosi e migliorare i parametri di efficienza. È possibile ridurre al minimo l'impatto delle release sui tuoi utenti eliminando i tempi di inattività e testando le regressioni. In questa fase, puoi anche iniziare a pensare alla regolarizzazione e all'automatizzazione dei processi, come il test e la verifica.
Una cultura di release veramente collaborativa richiede tempo per crescere e ha bisogno di un'infrastruttura. È possibile promuovere questa cultura facendo investimenti nel personale e in strumenti e tecniche di gestione delle release che incoraggiano le persone ad avere una visione olistica dell'intero processo di gestione.
Il miglioramento della comunicazione e dell'accesso alle informazioni favorirà il coordinamento. Fai sapere alle persone che le release, miglioreranno, perché impostare aspettative positive è importante. "Una delle sfide che i team devono affrontare è quando considerano i release come un ostacolo puramente tecnico e dimenticano il ruolo di una buona comunicazione all'interno dell'azienda e con gli stakeholder. Per ovviare a questo problema, assicurati che tutti i membri del team comprendano gli obiettivi e i rischi e assicurati di comunicare le modifiche agli utenti finali per evitare sorprese", afferma White di Small Footprint.
Il lavoro del release manager
Se guidare gli sviluppatori e le operazioni verso un obiettivo finale e una scadenza di produzione ti sembra divertente, prendi in considerazione la possibilità di diventare un release manager.
Un release manager deve navigare in un panorama complesso di progetti, metodi di sviluppo, infrastrutture e stakeholder, coordinando al contempo gli sforzi tra tutti coloro che contribuiscono alle release aziendali. I release manager devono anche riferire ai top manager dell'organizzazione, fino al CEO (anche se per le organizzazioni più mature, la gestione delle release è probabilmente una funzione più autonoma) ed è loro la responsabilità in caso di release negative.
Harding di Microsoft afferma che è importante che i release manager dispongano di ampie competenze di project management. "Fornire agli altri stakeholder del progetto formazione e accesso è fondamentale per ridurre la dipendenza da un unico individuo. I release manager hanno generalmente un insieme piuttosto specifico di capacità di risoluzione dei problemi, ma possono affidarsi ad altri PM per gestire elementi di configurazione e processo del prodotto", spiega.
Quindi, quali sono le qualità di un buon release manager? Hanno familiarità con il funzionamento dello sviluppo e delle operazioni, cioè sia il funzionamento tecnico che il modo in cui le persone lavorano insieme. Possiedono eccellenti capacità di gestione quando si tratta di lavoro, tempo e soprattutto persone. Si impegnano per la qualità, l'efficienza e i processi. Sono sostenitori dell'automazione e, dal lato tecnico, devono essere operatori esperti di repository di codice sorgente. Inoltre, sono perfettamente in grado di comprendere le innumerevoli dipendenze inter-progetto, interfunzionali e inter-dipartimentali che definiscono una release aziendale.
Sanno anche cosa credere (e cosa no) riguardo la gestione delle release.
Miti della gestione delle release e delle release software
C'è molta saggezza convenzionale sulla gestione delle release, ma quanto ne vale veramente la pena? Per nostra fortuna, Slinger Jansen e Sjaak Brinkkemper, due ricercatori dell'Università di Utrecht, nei Paesi Bassi, hanno già cercato di rispondere a questa domanda confrontando costi e valore. Hanno scoperto che prevalgono molti miti e idee sbagliate.
Mito 1: i clienti vogliono rimanere aggiornati. In realtà, i clienti si preoccupano degli aggiornamenti solo quando forniscono funzionalità utili. Se una release non migliora la loro esperienza, non gliene importa.
Mito 2: i clienti devono (dal punto di vista del fornitore) rimanere aggiornati. Si tratta di una situazione in cui i fornitori si preoccupano più dei clienti per quanto riguarda l'utilizzo dell'ultima versione del software. Come abbiamo già notato, i clienti effettuano gli aggiornamenti quando vogliono, altrimenti rimangono soddisfatti delle versioni precedenti.
Mito 3: la versione più recente è sempre la migliore. A seconda del caso d'uso di un cliente, una versione vecchia (o proprio antica) potrebbe funzionare bene, mentre una nuova potrebbe richiedere di dedicare del tempo all'apprendimento di una nuova interfaccia o di nuove funzionalità.
Mito 4: le correzioni possono attendere fino alla release principale successiva. Purtroppo, "la release principale successiva" è raramente puntuale. E, fino a quando non sarà finalmente pubblicata, i problemi rimarranno con i clienti.
Mito 5: le soluzioni alternative devono essere evitate a tutti i costi. A volte, alle persone non dispiace avere semplici soluzioni alternative quando quella principale è un aggiornamento costoso e dispendioso (in termini di tempo) a una nuova versione.
Mito 6: i clienti vogliono sempre nuove funzionalità. Se le nuove funzionalità ostacolano i flussi di lavoro consolidati e conosciuti, i clienti non le vorranno.
Mito 7: un ciclo di release frequenti è negativo. Finché non si invia ogni singola release ai clienti esterni, le release frequenti non sono pericolose. Le release frequenti possono abbreviare il ciclo di feedback, ma lo limiteranno per la maggior parte agli utenti interni e ai clienti pilota.
Mito 8: un cliente tranquillo è un cliente felice. Sono i clienti che contattano il supporto più spesso durante le prime fasi di utilizzo che si rivelano i più contenti del prodotto stesso. Rimani in contatto con i tuoi clienti.
Mito 9: i clienti leggono le note di release. Certo che no. Lo fanno se devono, cioè se sono limitati per scelta e stanno selezionando software professionali, ma preferiscono di gran lunga informazioni mirate che riassumano ciò che è necessario per loro conoscere.
Mito 10: avere molte release diverse sul campo è negativo. Questo può essere un problema se il fornitore offre assistenza continua ai clienti che utilizzano versioni precedenti, ma anche in questo caso si tratta di numeri. Avere un piccolo numero di clienti che utilizzano la versione precedente non è un problema ingestibile.
Tendenze principali nello spazio di gestione delle release
Le pratiche Agile e l'automazione stanno gradualmente diventando i principi fondamentali della gestione delle release, e per una buona ragione. L'automazione riduce i tempi di release e può ridurre sostanzialmente il rischio di errore. Le pratiche Agile spingono per l'adozione dell'automazione di costruzione, test, distribuzione e feedback, riducendo gli oneri per il team di sviluppo.
"Sia l'automazione che l'uso di piattaforme virtualizzate/cloud promuovono e supportano un'altra tendenza nella gestione delle release: la consegna continua", afferma Gabriel Gutierrez, Release Manager di Boeing. "Con la consegna continua, ogni nuova revisione software viene costruita, testata e preparata automaticamente per l'implementazione, trasformando rapidamente le idee in realtà. La consegna continua consente distribuzioni più frequenti, il che significa un feedback più frequente da parte del cliente. Di conseguenza, si perde meno tempo imparando rapidamente se si stanno apportando le modifiche di cui i clienti hanno bisogno e di cui si preoccupano", aggiunge.
Un'altra tendenza che ha preso piede è l'utilizzo di sistemi di controllo delle versioni distribuite (DVCS), come GIT, Mercurial e Perforce, che cambiano radicalmente il modo in cui i team collaborano. I DVCS consentono agli utenti di mantenere dei repository auto-contenuti sui computer locali, con cronologia completa delle versioni. Questa funzionalità consente di lavorare offline e di eseguire il commit delle modifiche solo alla configurazione locale. Gli sviluppatori possono apportare modifiche senza influire sul codice centrale, il che è ottimo per la sperimentazione.
Si ritiene che la cultura e la pratica DevOps diventeranno mainstream nelle aziende più grandi, con l'automazione di tutte le fasi che sarà un obiettivo raggiungibile. Le startup, nel frattempo, probabilmente inizieranno ad adottare la metodologia DevOps fin dall'inizio. Ciò è dovuto in parte al fatto che il DevOps, eseguito correttamente, porta a meno tempi di fallimento, tassi di recupero più rapidi e un maggior numero di distribuzioni, il che, a sua volta, significa una diminuzione dei tempi di inattività (molto costosi). Con l'aumento dell'adozione di DevOps, si diffonderà anche il processo di spostamento verso sinistra, ovvero quando i test automatizzati e il monitoraggio delle prestazioni avvengono prima nel ciclo di vita e la verifica della sicurezza diventa parte della pipeline di consegna.
"Sebbene non sia una nuova tendenza, le implementazioni più frequenti e rapide sono passate da una sfida tecnica a essere un'aspettativa da parte degli stakeholder", aggiunge White di Small Footprint. "Poiché gli stakeholder sono più informati sulle possibilità e i vantaggi delle distribuzioni più frequenti, non sono più soddisfatti delle settimane di attesa tra una release e l'altra e stanno spingendo i team di sviluppo a effettuarle più di frequente. Se il team non dispone di una solida infrastruttura di integrazione continua/consegna continua, lo stress sarà enorme", conclude.
Quigley afferma che l'esecuzione di successo di questi incrementi rapidi e ben definiti di contenuti software richiede "un livello di diligenza per quanto riguarda la gestione della configurazione e il monitoraggio della crescita di un prodotto nel tempo, poiché ci sono più iterazioni consegnate al cliente."
Ulteriori risorse sulla gestione delle release
Per un'introduzione più tecnica alla gestione delle release, consulta questo white paper di Jez Humble di ThoughtWorks Studios. Inoltre, una volta consultato, Electric Cloud dispone di una vasta gamma di risorse per la gestione delle release che approfondiscono le specifiche.
Se stai pensando alla gestione delle release come professione e stai già lavorando su Agile, dai un'occhiata a questo breve corso di Jan-Erik Sandberg su Pluralsight. E, se pensi che ottenere la certificazione ITIL sia una buona idea, Pink Elephant offre corsi ufficiali di certificazione ITIL, a partire dal livello Foundation.
Infine, se stai solo cercando di dedicarti da subito alla gestione delle release, dai un'occhiata a come lo fa Harvard Information Technology.
Migliora la gestione delle release con Smartsheet per lo sviluppo di software
Potenzia il rendimento dei tuoi dipendenti con una piattaforma flessibile progettata per soddisfare le esigenze del tuo team e capace di adattarsi alle condizioni mutevoli del lavoro. La piattaforma Smartsheet semplifica la pianificazione, l'acquisizione, la gestione e la creazione di report sul lavoro da qualsiasi luogo, aiutando il tuo team a essere più efficace e ottenere di più. Crea report sulle metriche chiave e ottieni visibilità in tempo reale sul lavoro mentre accade con report di riepilogo, pannelli di controllo e flussi di lavoro automatizzati creati per mantenere il tuo team connesso e informato. Quando i team hanno chiarezza sul lavoro da svolgere, possono ottenere maggiori risultati in meno tempo. Prova Smartsheet gratuitamente, oggi.