La metodologia di gestione dei progetti agile si basa su un processo iterativo e incrementale, caratterizzato da cicli di sviluppo brevi — gli sprint — al termine dei quali si rilascia una versione progressiva del prodotto o del servizio. Anziché percorrere una volta sola una sequenza lunga, si percorre molte volte una sequenza breve.
Le caratteristiche principali
- Flessibilità — adattamento continuo ai cambiamenti di requisiti e di priorità. Il piano non è un impegno da difendere, è un’ipotesi da rivedere.
- Collaborazione — coinvolgimento attivo del cliente e del team in ogni fase del progetto, non soltanto all’inizio e al collaudo.
- Feedback continuo — richiesta e valutazione costante del riscontro per migliorare il prodotto o il servizio.
- Focus sul valore — prioritizzazione delle funzionalità che apportano maggiore valore al cliente, invece di trattare ogni requisito come equivalente.
Questo approccio è particolarmente adatto a progetti con requisiti incerti o in continua evoluzione, dove è fondamentale la capacità di adattarsi e di rispondere alle esigenze emergenti.
La condizione che rende agile applicabile
C’è un presupposto che raramente viene reso esplicito, e che decide tutto: agile funziona quando il costo di cambiare idea è basso e quando è possibile consegnare qualcosa di parziale ma utilizzabile.
Nel software entrambe le condizioni valgono. Una funzionalità sbagliata si riscrive; una versione con metà delle funzioni serve comunque a qualcuno. Su una macchina speciale nessuna delle due vale: una struttura tagliata alla misura sbagliata è rottame, e mezza linea di confezionamento non confeziona nulla. Trasferire il metodo senza verificare il presupposto è il modo più rapido per ottenere le riunioni di agile senza i benefici di agile.
Che cosa si trasferisce comunque
Detto questo, alcune pratiche reggono benissimo anche fuori dal software, e in genere sono quelle che le aziende manifatturiere adottano senza chiamarle per nome.
La cadenza breve è la prima. Rivedere lo stato di una commessa ogni settimana, sempre nello stesso giorno e con lo stesso formato, produce più valore di una revisione mensile approfondita: gli scostamenti si scoprono quando sono ancora piccoli. Non serve chiamarlo sprint.
Il riscontro anticipato del cliente è la seconda. Non si può consegnare mezza macchina, ma si può far vedere il layout prima di ordinare la carpenteria, o far approvare lo schema elettrico prima del cablaggio. Sono iterazioni sul rischio, che è ciò che le iterazioni servono a ridurre.
La priorità esplicita è la terza. Quando in reparto ci sono sei commesse e le persone per quattro, qualcuno sta già decidendo le priorità — di solito il capo officina, in base a chi ha telefonato per ultimo. Renderlo un elenco ordinato e visibile è una pratica agile che non richiede alcun cambio di modello.
Ibridi, e dove si taglia
Nella pratica industriale il caso più frequente non è la scelta fra i due modelli, ma la loro convivenza dentro la stessa commessa. La regola pratica è tagliare dove cambia la stabilità dei requisiti.
Le fasi a valle, dove i requisiti sono congelati e i vincoli sono fisici — approvvigionamento, lavorazioni, montaggio, collaudo — si governano bene in modo sequenziale, come descritto nella voce metodologia waterfall. Le fasi a monte, dove il progetto è ancora in discussione con il cliente, guadagnano moltissimo da cicli brevi di proposta e verifica: è lì che l’incertezza è concentrata ed è lì che le iterazioni la riducono.
Un avvertimento sul vocabolario
Agile è la parola più abusata del settore, e conviene diffidare di due usi. Il primo è agile come sinonimo di “senza pianificazione”: il metodo prescrive più punti di controllo, non meno. Il secondo è agile come sinonimo di “veloce”: un ciclo iterativo non accorcia il lavoro, ne accorcia la distanza fra un errore e la sua scoperta. Su una commessa è comunque il beneficio che conta di più, ma è bene sapere che cosa si sta comprando.