L’insostenibile leggerezza del progettare

Una  metodologia che ho sempre trovato molto affascinante è l’Agile Programming.

Per chi non lo conoscesse (male!!) ne farò ora una breve descrizione perchè credo che sia un’ottimo modo di procedere per garantire dei buoni prodotti finali.

Innanzitutto le metodologie di sviluppo agili si contrappongono con le classiche metodologie di sviluppo quale ad esempio lo sviluppo a cascata. Tali metodologie hanno l’obiettivo di organizzare il processo di produzione del software per renderlo prevedibile, affidabile, efficiente e ripetitivo ma per ottenere questi risultati richiedono anche di applicare in modo rigoroso una serie di linee guida, di controlli, di adempimenti  “burocratici”, tra cui molta molta documentazione.

In contrapposizione a tutta questa pesantezza sono nate le metodologie “agili”.

Tra i vantaggi di questa tecnica vediamo innanzitutto la necessità di produrre poca documentazione (cosa fantastica a mio parere. Ho sempre creduto poco nelle aziende e nei team di sviluppo che meticolosamente compilano rapporti ogni giorno e soprattutto sono convinti che questo serva!), successivamente c’è il fatto che si adatta anche a piccoli team di sviluppo, anzi, questi sono nettamente preferibili, che ha come obiettivo principale una buona usabilità e quindi semplicità del software da produrre e che lo sviluppo avviene in maniera incrementale, ovvero a piccoli rilasci successivi.

Caratteristiche a mio parere assolutamente affascinanti per una metolodologia di programmazione.

Le metodologie di sviluppo agili partono dalla considerazione che i requisiti utente cambiano in continuazione durante il progetto, per cui non ha molto senso svolgere una pesante attività di analisi, di progettazione e di documentazione prima di iniziare la codifica, in quanto molto di questo lavoro potrebbe essere sprecato (questa frase mi fa letteralmente venire voglia di gridare a sguarciagola “Evviva Evviva!!!”).

Si può inoltre mantenere la documentazione essenziale all’interno del codice sorgente stesso: così quando si modifica il codice a seguito delle variazioni di specifiche richieste dal cliente, si modifica anche la documentazione.

A questo punto è mio assoluto dovere citare una delle più note e diffuse metodologie agili: l’ eXtreme Programming (XP).

Alcune pratiche dell’eXtreme Programming sono:

• La ricerca della soluzione più semplice;
• L’estrema semplicità del codice;
• Standard di codifica rispettato da tutti, nel senso che chiunque deve poter comprendere il codice scritto da un altro membro del gruppo;
• La progettazione dei test prima della codifica;
• La programmazione in coppia (pair programming), ovvero un tipo di programmazione che vede solo due persone coinvolte, una scrive e l’altra supervisiona con la possibilità/necessità di interscambiarsi i ruoli (chi scrive il codice è focalizzato sul modo migliore per realizzare un metodo, una classe, un algoritmo, mentre il collega che gli sta dietro mentre lui scrive è focalizzato sui controlli da effettuare, su cosa potrebbe non funzionare, su possibili strade alternative);
• Interazioni brevi e frequenti;
• Integrazione continua, ovvero si basa sul fatto che il testing intensivo e soprattutto continuo garantisce che ad ogni rilascio successivo il sistema rimanga comunque stabile;
• Refactoring del codice, cioè sua ristrutturazione per contrastare il possibile degrado dovuto alle continue implementazioni;
• Cliente sempre disponibile: un suo rappresentante deve sempre essere a disposizione del team di lavoto per rispondere alle domande;
• Riunioni in piedi;
• Proprietà collettiva del codice: chiunque all’interno del team di lavoro può modificare qualunque parte del codice in qualsiasi momento.

Cosa dire di più? descritta così verrebbe voglia di applicarla subito sempre e comunque!

Purtroppo (in Italia soprattutto) questa metodologia è ben poco applicata.

Infatti, nonostante spiegata così possa sembrare assolutamente perfetta (oggi mi sento evidentemente molto positiva!), essa riserva anche qualche difettucio che si potrebbe dire causa della scarsa applicazione nel nostro Paese.

Uno dei principali “pregi” di questa metodologia è il fatto che coinvolge molte figure di alto livello che collaborano tra loro in periodi continuati di forte concentrazione. Bello sì, ma ovviamente anche molto costoso!

Inoltre il voler ottenere in tempi brevi prototipi o prime versioni funzionali del prodotto dalla qualità eccelsa e perfettamente in tempo per il mercato, significa anche bloccare completamente interi team di progettazione e sviluppo per tempi medio-lunghi. Team di lavoro che oltretutto richiedono una particolare attenzione e abilità nell’essere formati. Lavorare in modalità agile è una tecnica soprattutto psicologica, prima ancora che tecnica. Nel senso che dovendo lavorare a così stretto contatto con altre persone e con il proprio lavoro costantemente messo sotto pressione e sotto il giudizio dagli altri membri, non è cosa così facile spicologicamente sostenibile. Richiede molta apertura mentale e stima reciproca tra tutti i membri del gruppo, senza che ci sia nessuno che voglia sopraffare gli altri. Caratteristiche credo non molto facili da trovare…

Insomma, in parole povere è una metodologia potenzialmente costosa (uso questa parola perchè in fondo essa avrebbe anche come obiettivo la riduzione di tempi e costi tramite eliminazione del lavoro inutile e dei tempi morti, ma questo non è sempre visibile da subito).

Quando il budget totale è relativamente basso, è praticamente insostenibile mantenere un processo di creazione agile ed il team tende quasi sempre a passare ad una metodologia di sviluppo a cascata: “si fa quello che si può… come viene viene” si preferisce dire, e purtroppo questa è una realtà molto comune.

Non è da nascondere che nel nostro mercato non sempre si punta alla qualità e che i clienti chiedono spesso, a prescindere da tutto e soprattutto da tutte le belle parole dei progettisti sulla potenziale usabilità/qualità del prodotto, una chiusura del progetto in tempi brevi e con costi contenuti.

Succede così che chi fa “agile” si trova, in breve tempo a dover affrontare più progetti “mediocramente” perchè non ha i fondi per affrontarne uno “seriamente”.

Alla fine dunque il risultato è sempre lo stesso: prodotto incompleto e di scarsa qualità.

La domanda che a questo punto viene spontaneo porsi dunque è: ma bisogna cambiare la mentalità della clientela/mercato portandola a comprendere i vantaggi di questi processi oppure identificare nuove strade che intermedino il tutto?

Il tempo ci darà una risposta… speriamo!

(parte di questo post è stata presa da un articolo di qualche mese fa di Luca Mascaro “Sostenibilità dell’Agile design”… la citazione è d’obbligo, trovandomi in assoluto accordo con lui, o meglio, questo è uno di quei milioni di casi in cui io penso una cosa e poi scopro che qualcun altro ha già scritto a riguardo e non ho quindi potuto far a meno di usare alcune sue parole per un esplicita citazione!)