Sviluppo Agile e criteri di ottimizzazione

sviluppo agileMolte organizzazioni iniziano con pratiche di Sviluppo Agile “ad hoc”, cioè non standardizzate ma mirate di volta in volta a soddisfare le esigenze.

Poi lasciano che siano i singoli Product Owner, con o senza l’accordo dei loro team, a decidere quando le applicazioni sono pronte per essere rilasciate, quando pianificare le date di rilascio e quanto frequentemente programmarle.

Questo modo di operare può generare una serie di problemi.

In primo luogo, questi team di solito non agiscono da soli e la loro programmazione può entrare in conflitto con quella di altri team del cui supporto ad un certo punto possono avere bisogno.

In secondo luogo, la natura di uno Sviluppo Agile “ad hoc” rende più difficile la previsione delle tabelle di marcia in quanto l’ammontare dei costi generali legati a differenti programmi di rilascio potrebbe non essere coerente da una versione all’altra.

In terzo luogo, questi gruppi di lavoro possono generare problemi di qualità se non ci sono indicazioni su quali tipi di modifiche in corso d’opera alle applicazioni sono appropriate per cicli di rilascio brevi o più lunghi.

Infine, questi team tendono a voler apportare “correzioni rapide”, “patch”, “modifiche di supporto” o “modifiche di emergenza” frequentemente e senza rendersi conto che ciò rende difficile concentrarsi su miglioramenti più strategici per ciascuna applicazione.

In questo caso accade che il team di sviluppo agile rilascia una versione, il product owner segnala reclami degli utenti o problemi di produzione e richieste di correzioni, il team predispone un rilascio di patch che risolve solo parzialmente i problemi, il product owner segnala ulteriori difetti, il team lo insegue con un’altra patch e il ciclo si ripete.

Se si va avanti così, gli utenti si sentono frustrati dalla qualità dell’applicazione, i team perdono reputazione e i product owner non riescono a rispettare la loro roadmap strategica.

Uscire da questo ciclo è fondamentale e molti team non possono farlo da soli.

Hanno bisogno di qualcuno che li guidi:

  1. riconoscendo i problemi creati da uno Sviluppo Agile “ad hoc”;
  2. definendo le politiche di rilascio che hanno senso per la strategia aziendale e per gli utenti/clienti;
  3. facendo in modo che tali modalità diventino uno standard interno.

Definire le modalità di rilascio dei prodotti di uno Sviluppo Agile

Per passare da un approccio “ad hoc” ad un approccio standardizzato è necessario:

  1. Definire una frequenza di cambiamento che abbia senso per la strategia aziendale e per gli utenti. Una società del settore B2C che attua piccole modifiche incrementali potrebbe desiderare versioni più frequenti di un’azienda del settore B2B che sviluppa analisi per i propri clienti. Qualsiasi versione che contenga nuove funzionalità, modifiche funzionali o modifiche sostanziali all’interfaccia utente richiede spesso qualche forma di test e formazione degli utenti, pertanto la cadenza di rilascio dovrebbe allinearsi a quanto sia facile coinvolgere la comunità degli utenti.
  2. Definire i tipi di rilascio che producono impatto minimo sugli utenti. (Minor release, Major release, Nuova versione, Aggiornamento di sistema). Occorre fare in modo che le release si concentrino sui cambiamenti delle applicazioni rispetto alle modifiche del sistema. Inoltre, le versioni minori sono caratterizzate da durate più brevi che richiedono meno tempo per coinvolgere gli utenti sulle modifiche, hanno quindi un impatto e un rischio tecnico minori. Le versioni principali non possono avere durate indefinite e la durata dovrebbe essere standardizzata in base alla strategia aziendale e alle capacità tecniche dell’organizzazione.
  3. Il rilascio inizia quando viene avviata la pianificazione, non quando si è pronti per la consegna. Questo è un cambiamento che il team di Sviluppo Agile deve riconoscere. La pianificazione della distribuzione per portare un’applicazione in produzione non è la stessa cosa della pianificazione del rilascio. La pianificazione dei rilasci dovrebbe iniziare prima dell’inizio di qualsiasi sviluppo. Deve partire definendo gli obiettivi aziendali, selezionando il tipo di rilascio e definendo almeno parte del backlog per ciò che deve essere sviluppato. Dovrebbe includere la definizione di quali attività commerciali sono richieste prima e dopo il rilascio. Una volta valutati tutti questi aspetti, è possibile selezionare una data di rilascio.
  4. Definire il programma dei rilasci successivi. Una volta che un team ha completato almeno una versione di successo, in base alle lesson learned può pensare ad una strategia di rilascio di più ampio respiro. Questa strategia deve tenere in considerazione il numero di rilasci importanti, quanti aggiornamenti di sistema sono necessari per mantenere aggiornate le tecnologie e il modo migliore per pianificare le versioni secondarie.

Una volta implementate queste modalità di governance, l’ottimizzazione del ciclo di sviluppo agile porta a tempi di rilascio più brevi e alla possibilità di produrre versioni più frequenti.