Ad inizio 2001, un gruppo di esperti del settore decise di trovarsi per discutere il futuro della disciplina dello sviluppo software. I membri di questo gruppo condividevano una comune frustrazione sullo stato attuale delle cose. Il problema fondamentale, secondo loro, era che le aziende erano talmente focalizzate nel pianificare e documentare eccessivamente i progetti che perdevano di vista l'obiettivo più importante: risolvere i problemi dei loro clienti.
Da questo primo incontro nacque l'Agile Manifesto, un insieme di principi che mettono a confronto alcuni degli aspetti cruciali di un progetto e stabiliscono quali siano da privilegiare per ottenere un prodotto di qualità e conforme alle aspettative del cliente.
Vediamoli in dettaglio nel seguito di questo articolo...
Gli individui e le interazioni più che i processi e gli strumenti
La filosofia Agile prevede un "livellamento" delle gerarchie al fine di rendere tutti i membri del team partecipi in egual modo allo svolgimento del progetto. In questo modo si ottiene indirettamente una maggior responsabiilzzazione del team, che cercherà con tutte le sue forze di portare a termine il progetto nel miglior modo possibile.
E' quindi molto importante che le interazioni tra gli individui siano il più agevoli possibile. Tanto più la comunicazione avviene in prima persona o comunque con il minor numero di "barriere" nel mezzo, tanto più sarà efficace ed efficiente.
Organizzare brevi meeting giornalieri è una pratica comune per discutere del lavoro fatto il giorno precedente, degli obiettivi per il giorno corrente e delle difficoltà incontrate. Ciononostante anche una semplice chiacchierata in pausa caffè può essere un prezioso momento di confronto.
Se questo tipo di comunicazione non dovesse essere possibile (ad esempio a causa della dislocazione fisica dei membri del team),si dovrà cercare di utilizzare strumenti il più vicino possibili ad un incontro di persona, come software di videoconferenza o chat. Insomma, strumenti che permettano la comunicazione sincrona, per minimizzare, in piena ottica Agile, le perdite di tempo che normalmente sono causate da strumenti asincroni come la mail.
Il software funzionante più che la documentazione esaustiva
Nella concezione "classica" del Project Management, una delle risorse ritenute più importanti consiste nella documentazione il più possibile esaustiva di progetto. Più le specifiche sono dettagliate, tanto più la valutazione dell'impegno economico e di risorse sarà esatta. Un approccio di questo tipo comporta notevoli difficoltà di adattamento in caso di variazione dei requisiti in corso d'opera, portando a rallentamenti dell'intero progetto.
Le metodologie Agile invece prescrivono la produzione di una documentazione "appena sufficiente" allo sviluppo di un progetto software, che descriva in maniera completa, seppur non completamente dettagliata, i requisiti.
Il formato della documentazione è poco imporante: può benissimo essere un grafico abbozzato su un foglio di carta, o un documento di testo senza particolari formattazioni. L'aspetto importante è che la documentazione non solo descriva in maniera comprensibile ed esauriente il problema, ma che sia condivisa con (e compresa da) tutto il team di lavoro.
Questo permette al contempo di mantenere una struttura e una forma mentale altamente flessibili, in modo da poter reagire con relativamente poco sforzo a cambiamenti o variazioni dell'ultimo minuto.
La documentazione dovrebbe inoltre rendere possibile la validazione del lavoro eseguito sia in corso d'opera che a posteriori. Ad esempio, i requisiti dovrebbero essere accompagnati da una serie di condizioni che devono essere rispettate per considerare la specifica pienamente soddisfatta.
Queste condizioni potranno poi essere utilizzate per creare test di conformità, che potranno essere rieseguiti in modo manuale o automatizzato prima di rilasciare una modifica al software. Nel tempo questi test andranno a formare una solida base che permetterà di assicurare non solo la qualità del software globalmente, ma anche intercettare e risolvere in tempo praticamente zero le anomalie appena introdotte.
In questo senso i test stessi possono essere considerati documentazione di progetto, perchè se ben scritti permettono di formalizzare le business rules e renderle accessibili a chiunque faccia parte del gruppo di lavoro (attuale o futuro).
La collaborazione col cliente più che la negoziazione dei contratti
L'Agile Manifesto prescrive che il cliente sia coinvolto durante tutto lo svolgimento del progetto software e non solo nelle fasi iniziali come avviene con le metodologie "classiche".
In questo modo si avrà la certezza che il prodotto software sia il più aderente possibile alle esigenze del cliente. Inoltre il cliente stesso si sentirà parte integrante e determinante del progetto invece che un semplice acquirente. Infine il team risulterà molto più reattivo ai cambiamenti limitando così il rischio di far arenare o peggio naufragare il progetto.
In alcuni progetti il cliente potrebbe essere preso in causa ad intervalli regolari, ad esempio per la presentazione di prototipi o demo. In altri progetti invece il cliente potrebbe avere un suo collaboratore come parte integrante del team, che verrebbe coinvolto in tutti i meeting di progetto per assicurarsi che il software soddisfi tutti i requisiti.
Rispondere al cambiamento più che seguire un piano
Come detto in precedenza, la documentazione di progetto dovrebbe essere semplicemente "sufficiente" per descrivere i requisiti ad un livello di dettaglio non troppo approfondito.
Utilizzando questo approccio il progetto si delinea e dettaglia nella sua interezza in corso d'opera ed è quindi da considerare un delivereable in continua evoluzione.
Ma mentre per le metodologie classiche il cambiamento è sinonimo di ulteriori "costi", per le metodologie Agile è invece percepito come un valore fondamentale, perchè permette di realizzare un prodotto che soddisfa pienamente le richieste del cliente.
Se si ragiona secondo la metodologia classica, introdurre dei cambiamenti in un progetto sviluppato secondo queste metodologie potrebbe minare le fondamenta del progetto stesso e costringere a rivedere improvvisamente parti anche significative del software prodotto.
Con le metodologie Agile i cambiamenti non sono mai di questa portata, proprio perchè vengono accettati ed incoraggiati durante tutto il progetto. In questo modo i cambiamenti non saranno mai radicali, ma delle variazioni di portata molto più "abbordabile".
Quando i principi non funzionano...
Intendiamoci, le metodologie Agile non sono una panacea contro tutti i mali, e non di rado si trovano detrattori più o meno agguerriti di queste pratiche.
I problemi maggiori insorgono quando in nome della metodologia si forzano i suoi principi, trasformando quello che dovrebbe essere un lavoro "umanizzante" in un lavoro "disumanizzante".
Ciò avviene quando ad esempio per rispondere ad una richiesta di cambiamento vengono imposte al team delle tempistiche assolutamente improponibili. In questo caso il risultato è un inevitabile abbassamento della qualità e un clima di poca serenità e stress generale.
Le principali metodologie
Seguendo i principi esposti, nel tempo sono nate diverse metodologie per la gestione di processi Agile, tra le quali:
- SCRUM: un framework che si presta molto bene per gestire i progetti in modo iterativo ed incrementale.
- Lean: una metodologia altamente flessibile senza particolari linee guida, regole o metodi.
- Kanban: un metodo visuale di gestione dei workflow che si presta molto bene al lavoro di team.
Nei prossimi articoli vedremo più in dettaglio ciascuna di queste metodologie, evidenziando le principali differenze, nonchè i (numerosi) punti in comune. Vedremo inoltre come spesso queste metodologie non si escludano a vicenda e come possano invece completarsi e complementarsi.