“Low quality code is not cheaper; it is vastly more expensive, even in the short term. Bad code slows everyone down from the minute that it is written. It creates a continuous and copious drag on further progress. It requires armies of coders to overcome that drag; and those armies must grow exponentially to maintain constant velocity against that drag.”
I metodi agili sono un insieme di metodi di sviluppo che condividono alcuni principi e valori fondamentali, descritti nell'Agile Manifesto. I metodi agili più diffusi sono Extreme Programming e Scrum. L'approccio di Sourcesense è basato su Extreme Programming (XP), con l'aggiunta di alcune pratiche prese a prestito da Scrum.
In poche parole, i metodi agili si propongono di sviluppare codice che abbia un alto valore per il cliente, che sia rilasciato presto e a ritmo continuo.
Un tipico team XP rilascia una prima versione, molto incompleta ma già dimostrabile, del software commissionato, già dopo un paio di settimane. In questo modo il cliente ha un immediato feedback sulla qualità del software consegnato, e può a sua volta fornire agli sviluppatori un prezioso feedback, per mantenerli focalizzati su quello che al cliente serve veramente. Se il team XP è bravo, riesce a mantenere un ritmo continuo di rilasci frequenti, tipicamente ogni due settimane ma anche più frequentemente a seconda dei casi.
Il rilascio di nuove funzionalità a ritmo costante ha delle importanti implicazioni:
- Sviluppatori e clienti imparano insieme. Gli sviluppatori imparano il dominio applicativo del cliente, mentre il cliente, avendo a disposizione un prototipo, anche se incompleto, può capire meglio in che direzione lo sviluppo deve evolversi.
- Il cliente ha il controllo della situazione. Ad ogni rilascio ha a disposizione un sistema di qualità finale, anche se non ancora dotato di tutte le funzionalità. Dopo ogni rilascio è possibile, con costi ragionevoli, rinegoziare quello che resta da fare, modificare le funzionalità sviluppate in precedenza, o addirittura decidere che il sistema così com'è è già sufficiente ed interrompere lo sviluppo.
- Non c'è il tempo di fare una fase di design dettagliato. Altre pratiche ingegneristiche di XP permettono di sopperire a questa mancanza, in una maniera che in generale è molto più efficace e meno rischiosa del metodo "a cascata". Per evitare di ridurre il codice a una massa di spaghetti, gli sviluppatori applicano il design quotidianamente: il design emerge a piccoli passi. Così si evita l'errore opposto, di creare un'architettura ambiziosa, eccessiva e sovrabbondante: il design emergente è della taglia appropriata per il problema da risolvere.
- Il progresso del team è aperto e visibile. Non ci nascondiamo dietro a ingannevoli "percentuali di completamento". Una feature è o completamente sviluppata, oppure no. Il progresso del team si misura sulle feature completamente sviluppate, che il cliente può personalmente verificare sul sistema corrente. Per saperne di più: sulla pianificazione agile.