• Non ci sono risultati.

Un approccio integrato: tecniche tradizionali e Agile

5. Agile Project Management nelle costruzioni

5.3 Agile Project management nella fase di esecuzione: la programmazione mista

5.3.2 Un approccio integrato: tecniche tradizionali e Agile

La programmazione a lungo termine proposta dalle tecniche di gestione tradizionali ha sì il vantaggio di restituire un’idea globale dell’andamento del progetto, ma anche il limite di riuscire ad identificare gli scostamenti, in termini di tempi, costi e quantità prodotte, con tempistiche che molto spesso non permettono di agire in tempo, con conseguenti ritardi del progetto e aumento dei costi.

I limiti della programmazione a lungo termine potrebbero essere superati sfruttando, durante la gestione di un progetto di costruzione, metodologie e strumenti Agile, quali il framework Scrum e Kanban. Nella Figura 41 è rappresentato uno schema che illustra una possibile integrazione di Scrum a Kanban all’interno di una pianificazione tradizionale. Nel seguito se ne riporta una descrizione.

140

Figura 41- Schema di una possibile soluzione per integrare le Metodologie Scrum e Kanban all’interno di una programmazione tradizionale per un progetto dell’industria delle costruzioni.

141

La soluzione di integrazione proposta prevede che il Project Manager (che si identifica nella figura del Responsabile Unico del Procedimento, con il compito di seguire la realizzazione dell’opera in ogni fase, dalla progettazione, all’esecuzione), formuli una pianificazione completa dell’intero processo in modo tradizionale, ovvero attraverso un opportuno diagramma di Gantt. Il cronoprogramma dovrà riportare preferibilmente solo le macro-attività, per rendere più facile la lettura del documento; il compito di eseguire la programmazione per le singole macro-attività sarà demandato alle impresa appaltatrice, contrattata dal Committente o identificata dal Project Manager nel caso di edilizia privata e scelta in seguito a gara d’appalto nel caso di lavori pubblici.

Se per la pianificazione generale del processo, scomposto in macro-attività, è previsto l’utilizzo di una metodologia tradizionale, per la programmazione e lo sviluppo di ogni singola macro-attività si adotterà un approccio Agile e si applicherà la metodologia Scrum, suddividendo la macro-attività in cicli brevi e iterativi, di lunghezza diversa a seconda della loro durata.

Nel caso di applicazione ad un progetto delle costruzioni, le figure del Team Scrum saranno:

• Product Owner: ruolo ricoperto dal Project Manager, ovvero dal Responsabile Unico del Procedimento che, esattamente come il Product Owner, è responsabile di controllare che le attività vengano svolte correttamente e che vengano rispettate le tempistiche imposte dalla programmazione generale;

• Scrum Master: ruolo ricoperto dal Direttore Tecnico di Cantiere (che può coincidere con la figura del capocantiere nel caso di piccoli progetti o esserne un diretto superiore) che, come lo Scrum Master, è il punto di riferimento per il Team di lavoro. Una differenza fondamentale tra le due figure riguarda il diverso livello di responsabilità: essendo i Team di Sviluppo Scrum auto-organizzati al loro interno, in un tradizionale processo Scrum lo Scrum Master ha sì il compito di garantire che il lavoro si svolga secondo i piani, ma non la responsabilità su come le parti vengano realizzate; al contrario il Direttore Tecnico di Cantiere ha poteri decisionali sia in materia di programmazione operativa sia di condotta esecutiva dei lavori.

• Team di sviluppo: rappresentato dalle maestranze ovvero dall’insieme dei lavoratori che consente la realizzazione materiale dell’oggetto edilizio; nel mondo dell’edilizia si fa riferimento al termine “squadra” come ad un gruppo di maestranze con diverse qualifiche e competenze. Due principali differenze tra il Team di sviluppo Scrum e quello tradizionale riguardano la possibilità del gruppo Scrum di auto-organizzarsi e di prendere decisioni sul lavoro da svolgere ed il numero di persone coinvolte, che nel processo Scrum deve essere compreso tra cinque e nove persone.

142

• Direttore dei lavori: figura non prevista nel Team Scrum, è però indispensabile in un processo delle costruzioni perché responsabile della corretta esecuzione dei lavori. E’ una figura professionale nominata dal committente per tutelare i propri interessi nei confronti dell’impresa costruttrice e dei terzi. Il direttore dei lavori emana ordini di servizio, controlla la fedele esecuzione, verifica la qualità dei materiali impiegati, compila gli stati d'avanzamento e tiene i rapporti economici con l'impresa. Secondo l’approccio integrato proposto, dopo aver identificato l’impresa sub-appaltatrice la macro-attività deve essere scomposta in cicli brevi e iterativi (Sprint), della durata variabile da una a quattro settimane in base alla tipologia di progetto e alla durata complessiva della macro-attività stessa.

Nella Figura 42 si riporta un esempio di scomposizione di una macro-attività in più cicli brevi e iterativi. La scomposizione consente un controllo più frequente dello stato di avanzamento del progetto e consente quindi di adottare opportune misure correttive in tempi più brevi rispetto a quanto accade in un processo pianificato in modo tradizionale.

143

Prima dell’inizio del primo Sprint, il Direttore Tecnico di Cantiere (Scum Master), seguendo le scadenze fissate dal Project Manager (Product Owner) e soggetto al controllo del Direttore dei Lavori, formula il Product Backlog, documento nel quale sono elencate tutte le attività previste per il completamente della macro- attività; ad ogni attività è associato un valore di priorità in base al rischio e alle tempistiche di consegna. Sulla base del Product Backlog e potendo contare sulla propria esperienza, il Direttore Tecnico di Cantiere costruisce un diagramma di Gantt generale per lo svolgimento della macro-attività, che consideri la suddivisione della stessa in un certo numero di Sprint.

All’inizio di ogni Sprint, si tiene un incontro denominato Sprint Planning Meeting a cui partecipano il Direttore Tecnico di Cantiere e le squadre di lavoro. La durata dell’evento è proporzionale alla durata della Sprint e dura circa due ore per uno Sprint di una settimana. Durante l’incontro viene formulato lo Sprint Backlog, nel quale si identificano le attività da eseguire durante lo Sprint in corso, nel rispetto delle priorità già previste nel Product Backlog, e si definiscono i dettagli tecnici su come queste verranno realizzate. Il Direttore Tecnico di Cantiere formula quindi un cronoprogramma specifico per lo Sprint in corso, con le attività previste nello Sprint Backlog.

Alla fine di ogni Sprint si tengono due diversi incontri:

• Sprint Review Meeting: incontro a cui partecipano il Project Manager, il Direttore dei Lavori, il Direttore Tecnico di Cantiere e le squadre di lavoro. L’obiettivo del meeting è quello di valutare lo stato di avanzamento dei lavori. La presenza del Project Manager a questo incontro è fondamentale perché durante la riunione viene informato dell’andamento del progetto e di eventuali ritardi o anticipi rispetto a quanto programmato. Un utile strumento da utilizzare soprattutto durante questo incontro è il Burndown Chart, diagramma nel quale è chiaramente indicato l’andamento che si era previsto di seguire rispetto e quello che si è seguito realmente durante lo Sprint appena concluso. • Spring Retrospective Meeting: incontro a cui partecipano solo il Direttore Tecnico di Cantiere e le

squadre di lavoro; rappresenta un’occasione di auto-analisi finalizzata al miglioramento del gruppo durante lo Sprint successivo.

Un modo efficace per migliorare il controllo giornaliero dello stato di avanzamento del progetto, monitorando costantemente lo stato delle attività, è quello di introdurre dei brevi incontri giornalieri, proposti nella metodologia Scrum con il nome di Daily Scrum Meeting. Gli incontri, ai cui partecipano il Direttore Tecnico di Cantiere e le squadre di lavoro, sono un occasione per il Direttore dei Lavori per dare eventualmente indicazioni sul lavoro da svolgere. L’incontro ha le seguenti caratteristiche:

• incontro quotidiano sempre alla stessa ora e della durata di 15 minuti al massimo, senza necessità di prendere posto intorno ad un tavolo per mantenere alto il livello di attenzione;

144

• partecipazione di tutti i membri delle squadre di lavoro ma intervento esclusivo dei componenti con un ruolo principale;

• discussione su cosa è stato fatto in più rispetto al giorno precedente, su cosa si intende fare prima dell’incontro del giorno successivo e su eventuali ostacoli o impedimenti riscontrati.

L’introduzione della pratica di brevi incontri giornalieri, ben gestiti e strutturali secondo il metodo Agile, migliorebbe le comunicazioni all’interno del gruppo, consentirebbe di identificare subito ritardi nei lavori ed eventuali ostacoli allo sviluppo del progetto e di applicare azioni correttive immediate, garantirebbe una maggiore conoscenza del progetto da parte di tutti i componenti del team di lavoro.

Nella Figura 43 sono riassunti i principali incontri previsti per ogni Sprint e per ognuno di questi sono messi in evidenza gli obiettivi e gli eventuali strumenti utilizzati.

Figura 43- Gli eventi Scrum durante un singolo Sprint: obiettivi e strumenti utilizzati

Un pratico strumento per monitorare lo stato del lavoro durante un processo, adottabile anche per il controllo dello stato delle lavorazioni di un processo costruttivo, è la lavagna Kanban, sulla quale posizionare tutti i cartellini, ovvero i kanban, corrispondenti alle attività in programma. Per poter comprendere meglio lo stato attuale del lavoro all’interno dell’organizzazione è utile mappare il processo di lavorazione, posizionando i cartellini relativi alle attività in tre colonne distinte:

• To Do (da fare): contiene i compiti e le attività da iniziare;

• In Progress (in lavorazione): sono inseriti i compiti contestualmente in elaborazione; • Done (fatto): raccoglie i compiti eseguiti o conclusi.

145

Come visto nel Paragrafo 4.4.1, implementazioni della più semplice lavagna Kanban potrebbero prevedere: • la suddivisione della fase di lavorazione (in progress) in ulteriori colonne che identifichino la

percentuale di avanzamento fisico dell’attività (appena iniziata, completa al 50%, quasi terminata); • l’utilizzo di icone rappresentanti i vari membri del team, da apporre sui cartellini delle diverse attività,

con l’obiettivo di migliorare il controllo del flusso di lavorazione e di individuare più facilmente le responsabilità ed i compiti all’interno del team di lavoro;

• l’aggiunta di una “corsia di emergenza” (expedite lane), distinguibile attraverso l’impiego di un colore diverso o di appropriata simbologia, nella quale posizionare le attività che devono avere una priorità di esecuzione rispetto a tutte le altre;

• la scomposizione orizzontale del flusso di lavoro (scatter marge), nel caso di attività che devono essere necessariamente eseguite in parallelo;

• l’introduzione del limite WIP (Work in Progress) pari al numero massimo di attività che si possono svolgere contemporaneamente in parallelo, col fine di impedire il sovraccarico e lo sbilanciamento del flusso di lavorazione.

Questo pratico strumento da un lato permette di aumentare il senso di responsabilità dei membri delle squadre di lavoro che hanno così modo di vedere come il loro eventuale ritardo potrebbe intaccare il lavoro degli altri membri, dall’altro consente di avere una chiarissima visualizzazione del processo di lavoro, ovvero di sapere subito quali sono le attività che ancora devono essere intraprese, quelle che sono in elaborazione e che devono essere portate a termine, e quelle già concluse. La chiarezza di questo schema lo rende facilmente comprensibile anche ai meno esperti e, per questo, la lavagna Kanban potrebbe essere un prezioso strumento da utilizzare durante gli incontri giornalieri tra i membri del team del progetto per aggiornare tutti sullo stato di avanzamento, su ciò che è stato concluso e su quali i passi successivi da seguire. Un secondo strumento particolarmente utile per valutare l’andamento del lavoro svolto e da svolgere e per migliorare le stime future per la produzione di nuovi incrementi è il Burndown Chart, un diagramma cartesiano in cui sono indicati, sull'asse X, i giorni dello Sprint e sull'asse Y, le ore di lavoro che resta da svolgere (effort). Durante ogni giorno dello Sprint si tracciano due linee di colori diversi: la prima rappresenta la stima del lavoro che rimane da completare, calcolato sulla base della velocità di sviluppo del gruppo; la seconda rappresenta l’effettivo lavoro ancora da concludere, in funzione del reale andamento dei lavori in cantiere. Attraverso la rappresentazione grafica del Burndown Chart è chiaramente messa in evidenza la situazione di eventuale ritardo o anticipo del progetto rispetto a quanto previsto ed è quindi possibile da un lato monitorare lo stato del progetto giorno per giorno, dall’altro avere un’idea del progresso del singolo Sprint se lo strumento viene utilizzano come riferimento durante lo Sprint Review Meeting.

147