Gestione dei rischi in un progetto Agile

La gestione dei rischi in un progetto gestito con approccio agile è una questione piuttosto delicata.

Il ricorso ad una pianificazione sommaria nei progetti agili limita la possibilità di procedere ad una analisi preliminare.

Tuttavia sarebbe auspicabile che almeno per la parte relativa ai rischi venga prodotta una valutazione attenta per prefigurare possibili strategie di mitigazione da mettere in campo se necessario.

Invece sul fronte dell’attuazione di tali strategie, l’approccio agile garantisce elevata tempestività e flessibilità di intervento grazie ad incontri ravvicinati finalizzati al coordinamento delle iniziative da mettere in campo.

L’attenuazione dei rischi dovrebbe essere un principio di base della mentalità e cultura agili, e forse anche di una governance agile.

Ciò è particolarmente importante, ad esempio, in ambito Information Technology per i team che lavorano su tecnologie legacy complesse e anche quando i team sperimentano nuove piattaforme.

Può quindi essere utile esaminare alcune possibili strategie in questo ambito.

5 strategie di mitigazione del rischio

  1. Completare per prime le user stories che presentano particolari complessità di test. Testare e sviluppare user stories complesse due giorni prima della fine di uno sprint non è realistico. I team intelligenti rivedono i propri impegni per garantire di lavorare su storie complesse nelle prime fasi dello sprint. Se si stanno valutando gli story point, qualsiasi storia con tredici o più punti dovrebbe essere completata dagli sviluppatori entro la metà dello sprint.
  2. Disciplinare le modalità di aggiornamento dell’infrastruttura. La maggior parte dei team che eseguono lo sviluppo software separano gli aggiornamenti di sistema dalle versioni di sviluppo delle applicazioni come parte di una strategia di gestione dei rilasci. E’ quindi raccomandabile di mantenere l’infrastruttura (comprese le versioni dei componenti software e l’architettura sottostanti) fissa durante le versioni principali e secondarie e utilizzare le versioni di aggiornamento del sistema per eseguire aggiornamenti, miglioramenti e patch. Questa disciplina è più per proteggere le versioni principali e secondarie da problemi imprevisti derivanti dagli aggiornamenti.
  3. Affrontare le problematiche relative al debito tecnico nel 20% delle versioni maggiori del prodotto e nel 60% delle versioni minori. Per debito tecnico si intende l’insieme delle possibili complicazioni che subentrano in un progetto, tipicamente di sviluppo software, qualora non vengano adottate adeguate azioni volte a mantenerne bassa la complessità. Queste problematiche non possono essere affrontate separatamente dallo sviluppo.
  4. Predisporsi a gestire i sovraccarichi di lavoro quando si sperimentano nuove tecnologie. Alcuni team desiderano scaricare e utilizzare ogni nuova libreria o nuovo strumento che viene reso disponibile. Altri potrebbero aspettarsi che le nuove funzionalità funzionino come previsto ed essere eccessivamente ottimisti. Entrambi possono trovarsi nella situazione che le nuove funzionalità non funzionino o richiedano molto più sforzo del previsto perché non hanno avuto modo di dedicare tempo sufficiente per convalidare le loro ipotesi di partenza.
  5. Valutare l’esperienza e la durata dell’onboarding per ciascuno sviluppatore. Anche gli sviluppatori esperti non è detto che riescano ad essere produttivi fin dal primo giorno. Come i nuovi membri del team, anche le persone più esperte hanno bisogno di un po’ di tempo per conoscere meglio i prodotti, comprendere le esigenze dei clienti, rivedere l’architettura, comprendere gli approcci migliori per lo sviluppo del codice e per testare semplici modifiche al codice. Le organizzazioni più avanzate utilizzano sondaggi o altri strumenti per misurare l’esperienza di onboarding e definire dei KPI per misurare la produttività nello sviluppo del software.