Skip to main content

Tutto ha origine con un articolo letto qualche tempo fa su un mensile. Una breve intervista a un coach di metodi di lavoro ispirati alla mischia del rugby (Scrum, in gergo): i membri del team di lavoro si muovono all’unisono, come fossero una cosa sola quando si passa all’azione. Incuriositi cominciamo a setacciare la rete per capire bene che roba è ed entriamo fatalmente nel mondo delle metodologie di programmazione Agili, popolato da etichette decisamente oscure: Kanban, eXtreme Programming, Lean software development…

Stiamo quasi per abbandonare il campo e relegarlo a faccenda da specialisti, quando incappiamo nel Manifesto Agile, dove leggiamo cose come queste: “I processi agili sfruttano il cambiamento a favore del vantaggio competitivo del cliente; […] Una conversazione faccia a faccia è il modo più efficiente e più efficace per comunicare con il team ed all’interno del team; […] La semplicità – l’arte di massimizzare la quantità di lavoro non svolto – è essenziale; […] Fondiamo i progetti su individui motivati; […]”.
Messa giù così diventa un po’ più familiare: persone, produttività, qualità, gerarchia, cambiamento, competitività, sono cose quotidiane, anche per i mortali che non hanno mai scritto una riga di codice. Mutatis mutandis, anche a noi viene voglia di sottoscrivere un manifesto del genere: decidiamo quindi di rivolgerci a un guru del settore, l’Ing. Paolo “Nusco” Perrotta.

Cosa sono i metodi di programmazione Agili?
Dodici anni fa cominciarono ad essere pubblicati studi che dimostravano che la percentuale di progetti software fallimentari è altissima: il 25% fallisce completamente, oltre l’80% fallisce in qualche modo – costano di più, hanno tempi lunghissimi, etc. Un fenomeno così diffuso doveva avere una ragione e una soluzione. Ci siamo resi conto che fino ad allora nello sviluppo software avevamo cercato di ingegnerizzare il processo imitando l’industria. E qui stava l’errore perché i software sono progetti di ricerca e non di costruzione, cioè progetti nei quali capisci cosa devi fare mentre lo stai facendo. Le metodologie Agili nascono quindi dal fallimento delle metodologie tradizionali, e prendono a piene mani da esperienze di organizzazione del lavoro in altri settori. Negli anni ’80 sono giunti in occidente alcuni interessanti principi applicati dai giapponesi nell’industria automobilistica: da loro abbiamo imparato per esempio il just in time: perché tenersi in magazzino le autovetture?! La vettura si produce quando la si è venduta.

Quali sono allora i valori del metodo Agile?
Primo, gli individui e le interazioni sono più importanti che i processi e gli strumenti: badiamo cioè alle relazioni nel team più che al fatto, per esempio, di avere un software che consenta di controllare il team. Secondo, il software funzionante è più importante che la documentazione esaustiva: i documenti sono spesso utili; ma è altrettanto fondamentale capire che se si producono 1000 documenti e 0 righe di codice, non si può pensare di misurare con i primi lo stato di avanzamento dei lavori. Terzo, la collaborazione col cliente è più importante che la negoziazione dei contratti. L’esperienza ci ha insegnato che nella maggior parte dei casi il cliente non sa cosa vuole, e lo scopre solo dopo, quando per la prima volta si confronta con quello che è stato sviluppato. Quindi? Il modo migliore per affrontare questo ineliminabile dato di fatto è accettarlo e considerare il software non come un prodotto ma come un servizio – solo quelli come Microsoft possono permettersi il primo approccio… Quarto, rispondere al cambiamento è più importante che seguire un piano. Un’altra scena tipica nelle software house è la lamentela degli sviluppatori con il project manager che chiede modifiche continue. Ma lamentarsi non serve a niente! Bisogna accettare il cambiamento come connaturato a qualsiasi progetto software.

“Nusco” fa un esempio illuminante su cosa possa significare essere in grado di accogliere il cambiamento.
Facebook sarebbe stato impossibile da creare con i metodi tradizionali di sviluppo.
Quasi ogni giorno, accedendo al proprio profilo, ognuno può constatare più o meno significative modifiche: nuove icone, nuove funzioni, nuovo layout… come si sarebbero potuti prevedere fin dall’inizio? è fondamentale oggi usare metodi di progettazione software che consentano di cambiare.

Ma non ci hai ancora svelato in cosa consistono queste metodologie…
Innanzitutto si separa il progetto in piccoli step che durano settimane, non mesi. Al termine di ciascuno step si consegna al cliente una funzionalità: non un pezzo inutile, ma qualcosa di cui si possa apprezzare l’utilità. In ciascuno step si applica il metodo scientifico: guardo cosa accade, faccio ipotesi, le verifico; in caso di fallimento ricomincio. Questo metodo generalissimo viene però sempre declinato sul team che lo applica: sono le persone coinvolte che devono trovare il processo che fa al caso loro. Il ruolo del manager cambia in modo sottile: da capo, diventa leader, cioè non dice più ai membri del team cosa fare, piuttosto li aiuta a fare quello che devono.

Quali sono i vantaggi per chi sceglie l’Agile?
Non è nella nostra cultura di italiani collaborare – del resto fin dai banchi di scuola, quando si aiuta il compagno di banco si sta copiando… Però quando un team diventa davvero un team è impensabile tornare indietro: è talmente performante che conviene alle aziende. Sulla lunga distanza certo la iper-produttività è il vantaggio più significativo, ma sul breve termine la cosa più interessante per le aziende ha a che fare con il time-to-market. L’Agile è molto interessante per quei prodotti per i quali il tempo che intercorre tra l’ideazione, la progettazione e l’immissione sul mercato deve essere molto breve, pena l’obsolescenza. Supponiamo di avere un progetto software che ci occuperà per un anno intero: con l’Agile, invece di consegnare 100 feature alla scadenza, tra un anno, ne consegneremo un paio ogni due settimane, ordinandole secondo priorità. In questo modo ogni due settimane avremo un ritorno di cassa e un feedback, che significa anche un risparmio sul fronte dell’errore.

Tutti quegli strani nomi che si riuniscono sotto l’etichetta di Agile in cosa differiscono?
Nella comunità Agile c’è una grande unità di vedute anche in merito a questo: sono tutti metodi per cercare il proprio metodo, perchè questa è l’idea fondamentale dell’Agile. Poi, è vero che ci sono metodi che hanno avuto più successo di altri su questa strada: ad esempio Scrum, che parla il linguaggio dei manager; o eXtreme Programming che invece dice cosa si deve fare davanti al PC. Tra gli sviluppatori, le pratiche di lavoro introdotte da XP sono considerate oggi lo stato dell’arte. Queste completano approcci più gestionali come quello di Scrum e gli permettono di diventare efficaci: con Scrum si decide per esempio che ogni due settimane si deve consegnare uno sprint, ma per creare qualcosa di potenzialmente usabile devi avere alta competenza tecnica e su questo sono le pratiche di XP a indicare la strada.

Come funziona il tuo lavoro e chi lo richiede?
Queste metodologie sono diffuse soprattutto all’estero. Per quel che riguarda le grandi aziende generalmente si tratta di aziende all’avanguardia oppure di aziende che hanno problemi con il time-to-market; quelle medio piccolo invece sono interessate ad alcuni aspetti dell’Agile, per esempio la riduzione del numero di bug generati da un team di sviluppo.
Quando un’azienda richiede la nostra attività di coaching, ci muoviamo in gruppo e dopo una sessione di formazione molto veloce, aiutiamo i team, giorno per giorno, in real time non in provetta, a cambiare il loro modo di lavorare.

Per concludere, abbandoniamo la guida sicura di “Nusco” e ci concediamo il lusso di una riflessione poco ortodossa e un po’ irriverente.
Qualunque mortale abbia avuto a che fare con un Ingegnere, affidandosi alla sua imperscrutabile conoscenza con fede quasi mistica, per risolvere arcani informatici del tipo «La stampante non stampa», «Ho la mail rotta», «Non riesco ad aprire il file» si sarà certamente sentito rivolgere risposte del tipo «Hai collegato il cavo?», «Hai aggiornato il programma di posta?», «Hai il programma che legge quel file?». Urticante, per i mortali. Ma necessario per gli Ingegneri: loro sono programmati per risolvere i problemi e sanno molto bene che spesso il problema sono i mortali. Ora abbiamo capito che anche gli Ingegneri sono mortali. Agile humanum est.

2 Comments

  • Mirzio ha detto:

    “Ma non ci hai ancora svelato in cosa consistono queste metodologie…”

    “consistAno”
    I congiuntivi, i congiuntivi

  • grammrnazi ha detto:

    ” Incuriositi cominciamo a setacciare la rete per capire bene che roba è” – “che roba SIA”.
    E “perché” si scrive “perché”, non”perchè”.

    Per il resto, ottimo articolo.