Sviluppo con metodologia Agile

Lo sviluppo agile è un approccio alla creazione di software che prevede la consegna del lavoro in iterazioni brevi, l'integrazione continua del feedback e l'adattamento dei piani man mano che la comprensione migliora. È stato formulato nel Manifesto Agile del 2001, che enunciava quattro valori fondamentali: individui e interazioni al di sopra di processi e strumenti, software funzionante al di sopra di una documentazione esaustiva, collaborazione con il cliente al di sopra della negoziazione del contratto e capacità di rispondere al cambiamento al di sopra del seguire un piano.

La formulazione del manifesto viene spesso citata in modo errato, con conseguenze significative. Ogni affermazione esprime una preferenza tra due elementi che hanno entrambi valore, non un rifiuto del secondo. Il documento afferma esplicitamente che, sebbene gli elementi a destra abbiano valore, quelli a sinistra sono considerati più importanti. Le implementazioni che interpretano il manifesto come un divieto di documentazione, pianificazione o contratti hanno di fatto scartato metà del suo contenuto e in genere producono quel disordine che i critici attribuiscono all'approccio stesso.

Il principio alla base di questo approccio è l'incertezza. Lo sviluppo sequenziale presuppone che i requisiti possano essere specificati con precisione in anticipo, il che è valido per problemi ben definiti ma non per prodotti il ​​cui valore dipende da come le persone reagiscono ad essi. La consegna iterativa riduce il costo degli errori accorciando l'intervallo tra una decisione e la possibilità di verificarla, un aspetto che acquista valore in proporzione al grado di incertezza del problema.

L'errore più comune nella pratica è quello di adottare le cerimonie senza i principi. Le organizzazioni introducono riunioni giornaliere, limiti di iterazione e pratiche di stima, mantenendo però un ambito fisso, scadenze fisse, pianificazione annuale e nessun meccanismo per agire in base al feedback. Il risultato è uno sviluppo sequenziale condotto in segmenti di due settimane con riunioni aggiuntive, che è più lento di entrambi gli approcci se applicati correttamente e genera il diffuso scetticismo nei confronti della metodologia.

La collaborazione con i clienti è l'aspetto che le organizzazioni trovano più difficile da gestire e che più spesso trascurano. Adattarsi al feedback richiede di ottenerlo effettivamente, il che significa che utenti reali interagiscono regolarmente con il software funzionante. I team che operano basandosi su un intermediario, che sia un interlocutore interno o una specifica scritta, seguono un ritmo di iterazione senza però ricevere l'input che gli conferisce significato, e procedono con sicurezza in una direzione che nessuno ha validato.

La scalabilità introduce una reale difficoltà che la formulazione originale non aveva affrontato, poiché il manifesto era stato scritto pensando a piccoli team che lavoravano nello stesso luogo. Coordinare molti team su un unico prodotto richiede meccanismi di allineamento, gestione delle dipendenze e coerenza architetturale, e i vari framework di scalabilità che affrontano questo problema sono spesso criticati per aver reintrodotto il peso dei processi che l'approccio intendeva ridurre. La tensione è reale, non è frutto di un'incomprensione.

La valutazione dovrebbe concentrarsi sui risultati piuttosto che sulla mera conformità. Le domande rilevanti sono se il tempo che intercorre tra l'idea e l'apprendimento validato si sia ridotto, se il team sia in grado di cambiare direzione quando le prove lo giustificano, se la qualità venga mantenuta anziché compromessa a causa delle scadenze e se il prodotto sia misurabilmente migliore per gli utenti. I team che eseguono ogni pratica prescritta, rilasciando annualmente un prodotto con specifiche fisse, hanno adottato la terminologia ma non i benefici.

Poiché l'approccio dipende tanto dalle condizioni organizzative quanto dalla pratica del team, l'adozione spesso richiede cambiamenti nella governance, nel finanziamento e nella pianificazione che si trovano al di fuori del team di implementazione. In pratica questo viene affrontato all'interno sviluppo del prodotto insieme al processo di consegna stesso, con il ciclo di feedback supportato da ricerca dell'utentee le organizzazioni che sviluppano la capacità internamente di solito la stabiliscono all'interno di un reparto prodotti dove la pianificazione e la responsabilità dell'attuazione sono strettamente interconnesse.