Chiunque sia coinvolto nei processi di sviluppo del software, o abbia un minimo di familiarità con questo tipo di ambiente di lavoro, avrà sicuramente presenti alcune caratteristiche ricorrenti: la necessità di massimizzare la scrittura di codici per far fronte a richieste e tempistiche sempre più pressanti, la tendenza ad arrivare comunque in ritardo rispetto alle scadenze concordate con il cliente o con prodotti non ancora completi di tutte le funzionalità attese dal committente, uno sviluppo che procede a singhiozzo tra accelerazioni e pause, con la necessità di riprendere in mano più volte il lavoro svolto nelle settimane e nei mesi precedenti.
«Pur con tutti i distinguo del caso – spiega Sergio Mieli, responsabile del Centro di Sviluppo Software di Sanmarco Informatica, dove lavorano circa 90 specialisti tra i circa 300 addetti dell’azienda veneta – si tratta di uno scenario comune nella gran parte delle aziende di sviluppo che adottano un’organizzazione del lavoro di tipo tradizionale. Erano criticità che avevamo anche noi, in una certa misura, finché due anni fa non abbiamo introdotto gradualmente un modello organizzativo basato sulla metodica Agile e più in particolare sugli strumenti Scrum. Il percorso di implementazione è stato graduale, ma oggi guardandoci indietro possiamo dire di avere raggiunto importanti risultati e allo stesso tempo possiamo trarre alcune conclusioni che possono essere un interessante spunto di riflessione per gli operatori del settore».
Un’esperienza, quella di Sanmarco Informatica con la metodologia Agile-Scrum, che conferma l’attenzione dell’Azienda per la valorizzazione delle risorse umane e per l’innovazione: «Due anni fa abbiamo intrapreso questo percorso – sottolinea l’ing. Renato Bardin, presidente di Sanmarco Informatica – perché crediamo importante creare un ambiente di lavoro il più possibile aperto al confronto costruttivo e stimolante, nel quale siano favoriti la condivisione e il trasferimento delle conoscenze. Solo così possiamo far crescere i giovani e più in generale tutti i nostri collaboratori. Inoltre, essere un’azienda innovativa non vuol dire soltanto utilizzare tecnologie all’avanguardia o dedicare ingenti risorse finanziarie alla ricerca e sviluppo, ma anche essere aperti al cambiamento, pronti a sperimentare in prima persona anche nuove soluzioni organizzative».
La metodologia Agile – Scrum
Com’è noto, la metodologia Agile fa riferimento ad una serie di principi e linee guida fondamentali per lo sviluppo del software, enunciati nel 2001 da un gruppo di programmatori in un vero e proprio manifesto. Nell’ambito di Agile, sono stati via via affinate alcune metodologie innovative, tra cui Scrum. Questo termine, mutuato dal rugby dove indica il pacchetto di mischia, è una metafora che indica l’importanza di avere un team di sviluppo in grado di lavorare insieme in modo che tutti gli attori del progetto spingano nella stessa direzione, agendo come un’unica entità coordinata. In estrema sintesi, la metodologia Scrum prevede di suddividere il progetto in blocchi (“sprint”) di 2-3 settimane, all’interno dei quali devono essere sviluppate delle funzioni/moduli/applicazioni complete e pronte per la potenziale installazione da parte del cliente. In questo modo, un progetto lungo e complesso viene parcellizzato in una serie di fasi, con molteplici benefici: grazie alla verifica molto più frequente del lavoro svolto, è più facile rispettare i tempi e produrre software di qualità. Inoltre, altri capisaldi della metodologia sono la condivisione delle informazioni e degli obiettivi e l’organizzazione per piccoli gruppi di lavoro multidisciplinari: ad ogni “sprint” lavorano infatti analisti, sviluppatori e tester, nonché le figure più direttamente a contatto con il cliente. All’inizio di ogni “sprint” viene svolto un incontro per la discussione e la pianificazione del lavoro (“Sprint Planning Meeting”) all’interno del quale vi è un confronto aperto su obiettivi da raggiungere, problematiche, tempistiche ed eventuali altre criticità. Ogni giorno inoltre vi è un’ulteriore, breve riunione di verifica dello stato di avanzamento del progetto. Alla fine dello “sprint” il risultato raggiunto, funzionante, viene presentato al committente e parallelamente viene svolto un incontro di analisi del lavoro svolto ai fini del miglioramento continuo (“Sprint Retrospective Meeting”).
I vantaggi
I benefici ottenuti sono molteplici: «Abbiamo registrato un miglioramento generale dell’ambiente di lavoro – racconta Sergio Mieli – con livelli più elevati di motivazione, spirito di gruppo e positività. C’è maggiore chiarezza su cosa va fatto e perché, a tutti i livelli, e aumenta la focalizzazione sugli obiettivi, ovvero si lavora solo su ciò che serve davvero. E ancora, si riducono i malintesi tra le diverse funzioni interne ed è possibile prevenire alcune problematiche tipiche di un modello organizzativo tradizionale che appaiono dei veri e propri paradossi». E come in tutti i paradossi, al di là della provocazione, vi sono significativi elementi di verità: vediamo i principali.
1° paradosso: si lavora per l’efficienza dei clienti, in modo altamente inefficiente
Buona parte dei software sviluppati ha come fine ultimo quello di migliorare l’efficienza dei processi dell’utilizzatore, qualsiasi sia la natura della sua attività. Eppure, mentre si lavora con il massimo dell’impegno per produrre efficienza, spesso lo si fa con modalità altamente inefficienti. «Con un modello organizzativo di tipo tradizionale o a cascata, dove i vari specialisti svolgono la propria funzione in modo poco o per nulla integrato, può capitare ad esempio di sviluppare software per centinaia di ore salvo poi bloccarsi perché i tester sono impegnati su altri progetti, e nel frattempo poi le priorità saranno cambiate, con il risultato che a volte alcuni codici sviluppati nemmeno arrivano alla fase di testing».
2° paradosso: si mettono in rete i computer, ma non i cervelli
«L’organizzazione del lavoro per piccoli gruppi nella metodologia Agile-Scrum evita fraintendimenti e riduce gli errori nella fase di sviluppo, ma più in generale ha anche un’altra valenza in quanto rende più semplice e rapido il trasferimento delle competenze e consente di creare un maggiore grado di conoscenza diffusa, evitando così che all’interno del team di sviluppo ci sia solo una persona a conoscenza di determinati aspetti
». Con la metodologia tradizionale, invece, si mettono in rete i computer, ma non i cervelli.
3° paradosso: “Perdere tempo” migliora l’efficienza
«Naturalmente – conclude Mieli – tutto questo ha un costo, inteso come tempo dedicato agli incontri quotidiani e a quelli di pianificazione e follow up. Rispetto ad un modello tradizionale, nel quale i vari specialisti si dedicano al proprio specifico compito e basta, si potrebbe dire che “perdiamo” un sacco di tempo, eppure l’efficienza complessiva del processo, a medio e lungo termine, è estremamente superiore, proprio perché consente di evitare gli errori, le contraddizioni e le diseconomie viste in precedenza. La sfida, naturalmente, sta nel rendere i vari momenti di incontro, in primis quelli quotidiani, il più produttivi possibile».