Agile Project Management - PMI-NIC
annuncio pubblicitario
Agile Project Management Ing. Roberto Chiavaccini Ordine degli Ingegneri di Livorno Seminario 18/12/2014 Cos'è ? • Un aiutino: è stato ideato nel 1902 dall'ingegnere tedesco Max Rietz Il Regolo calcolatore • Il Regolo calcolatore era il simbolo degli ingegneri! • All'Università ve l'hanno insegnato? • Lo utilizzate? Cos'è ? Un aiutino ... • ... è stato ideato nel 1917 dall'ingegnere americano H. Gantt, collaboratore del più famoso ingegnere F. W. Taylor Il Gantt • È il simbolo del metodo progettuale classico definito, dal PMI (Project Management Institute), Predittivo ! Il Gantt • A Ingegneria vi hanno insegnato il Gantt ed il Metodo Predittivo ? • Li utilizzate ? Il Metodo predittivo • Di seguito alcune considerazioni sul Metodo Predittivo basandole sul PMBOK5 del PMI, principale referente mondiale di Project Management PMBOK5 • “Nei cicli di vita predittivi si determinano (si prevedono) il prima possibile Ambito (il perimetro del progetto ovvero le cose da fare, chi le farà, ..),Tempi e Costi per realizzare il progetto” (Concept Paper) Metodo Predittivo • “Questi tipi di progetto passano attraverso una serie di fasi sequenziali o sovrapposte ….“ Sa lm W at er fa ll on i? Problemi • Nella progettazione “a cascata” sono necessari continui feedback informativi (effetto salmone) che, purtroppo, dilatano tempi e costi Metodo Predittivo • “Il lavoro svolto in una fase è generalmente di natura diversa da quello della fase precedente o successiva quindi la composizione e le capacità (le specializzazioni) richieste al Team di progetto (di Sviluppo) possono variare di fase in fase” Le Specializzazioni creano Problemi Silos Tayloristici Silos Metodo Predittivo • “Il Metodo predittivo dovrebbe essere preferito quando il prodotto da fornire è noto, quando esiste una base sostanziale di prassi del settore (delle Best Practices) o laddove un prodotto debba essere integralmente realizzato prima di avere Valore per i clienti e/o per altri Stakeholders” Dubbi • Vi possono essere alcuni dubbi sulla prima e sulla seconda affermazione (presuppongono delle certezze che, vedremo, sono oggi molto difficili) ma è soprattutto sull'ultima che vi invito a riflettere Dubbi • La realizzazione integrale “al buio” (prima cioè di avere Valore per i clienti – ovvero per chi pagherà) presuppone infatti: – O un grande azzardo proviamo comunque a sviluppare il prodotto ed .... io speriamo che me la cavo ! Dubbi – O stabilire preliminarmente, magari con un'analisi di Marketing, ciò che vogliono i clienti “imponendo loro”, con un Contratto, di non cambiare mai più idea Metodo Predittivo • Purtroppo, data l'attuale dinamica ambientale, i Bisogni dei Clienti evolvono molto rapidamente e non si può impedir loro di cambiare idea trincerandosi dietro un “Contratto”! Gestione adattiva • È evidente infatti che, contratto o non contratto, se per il cliente la colpa della sua insoddisfazione è del fornitore in seguito non comprerà più e magari …. renderà “difficili” gli attuali pagamenti ! Metodo Predittivo • Purtroppo oggi Incertezza e Complessità regnano sovrane Metodo Predittivo • Il nostro (degli ingegneri “più anziani”) bel Mondo Razional Meccanicistico (tutto è e deve essere noto a priori, il prima possibile) è scomparso Metodo Predittivo • Ed il metodo predittivo … non è più sufficiente! Metodo Predittivo • Le statistiche internazionali ce lo confermano: nei progetti complessi ed incerti gestiti in modo predittivo, le previsioni di Tempo sono rispettate solo nel 10% dei casi Metodo Predittivo • Ma il peggio è che anche l'Ambito ed i Costi sono rispettati solo nel 10% dei casi Metodo Predittivo • Il che vuole dire che le “previsioni” sono rispettate …. nel 1/1000 dei casi: è un po' poco per essere solo sfortuna! Metodo Predittivo • Molti poi sono scoraggiati dal tempo e dai costi di implementazione del Metodo Metodo Predittivo • In tal caso si rinuncia e si ricorre al classico Just do It (empirismo manageriale) Just Do It • Purtroppo con l'empirismo manageriale … le cose vanno anche peggio ! Just Do It • In Italia poi, per carenze di insegnamento di Project Management da parte delle Università, l'empirismo la fa decisamente da padrone Taylor & Gantt • In fin dei conti però, Taylor e Gantt una qualche ragione l'avevano: è il metodo scientifico sperimentale e non l'empirismo che dovrebbe essere alla base del Management e, quindi, anche del Project Management ! Taylor & Gantt • Perché allora, se il Principio è valido, le soluzioni del Taylor e del Gantt oggigiorno danno risultati non troppo brillanti ? Taylor & Gantt • È ovvio, i due ingegneri avevano formulate le loro proposte 100 anni fa in un mondo ben diverso dall'attuale e ormai sono, ... come il Regolo, un po' obsolete! Ohno & Shingo • Fortunatamente altri ingegneri (bene o male il Management operativo ha una grossa base “ingegneristica”), in particolare i giapponesi Taichi Ohno e Shigeo Shingo (ve ne hanno mai parlato?), hanno aggiornato le soluzioni del Taylor e del Gantt Ohno & Shingo • Gli ingegneri giapponesi hanno sviluppato tali nuove soluzioni manageriali “ancora scientifiche ma post Taylor”, universalmente conosciute come Lean Thinking, applicandole alla Toyota … con ottimi risultati sperimentali! “Agile” Project Management • Oggi il Lean Thinking, sulla scia di Toyota, è applicato anche allo Sviluppo e prende vari nomi: • Agile Project Managerment è uno di questi Agile • Generalmente con Agile ci si riferisce allo sviluppo di prodotti SW con specifici metodi Lean emersi a partire dai primi anni 2000 Agile • Tali metodi sono basati sui princìpi del "Manifesto Agile" pubblicato nel 2001 ad opera di 17 professionisti dello sviluppo SW Lean • Oltre ad Agile altri nomi che potreste sentire sono: – Lean Product Development per l'industria manifatturiera – Lean Costruction/Last Planner per l'edilizia – Lean Government (per la pubblica amministrazione) – Lean Healthcare (per la sanità) – --- Agile • Io preferisco parlare genericamente di Lean Project Management riferendolo così a tutte le tipologie di progetti lasciando il termine Agile per lo sviluppo SW Agile • Purtroppo per me il PMI definisce Agile il Metodo Adattivo che vedremo subito dopo e se lo dice il PMI ubi maior …. Agile • Di recente il PMI ha addirittura introdotto una specifica certificazione (PMI-ACP)SM - PMI Agile Certified Practitioner Lean Project Management Perchè Lean? Se ci pensate bene nella maggior parte dei casi il problema centrale nello Sviluppo di quasi tutti i prodotti è, soprattutto oggi, la mancanza di Conoscenza che hanno sia i Clienti che i Progettisti Lean Project Management Oggi il mondo cambia molto rapidamente e, quindi, per competere, si deve puntare sempre di più sull'Innovazione cioè su cose che, per definizione, … né i clienti né gli sviluppatori conoscono Un assioma famoso “Se fossi stato a sentire i miei clienti … avrei prodotto una carrozza più veloce!” H. Ford Lean Project Management Ed è proprio la mancanza di Conoscenza che rende velleitario il metodo predittivo Lean Project Management Se infatti manca la conoscenza è impossibile pretendere di restare nella comfort zone, quella zona dove siamo, dove sappiamo cosa fare e dove possiamo prevedere esattamente e a priori cosa fare, magari pianificandolo con un Gantt Lean Project Management In un mondo che cambia rapidamente si deve uscire volontariamente dal comfort per entrare nella zona dell'apprendimento Lean Project Management Se infatti il rimettere sempre tutto in discussione (il sano dubbio galileiano … eppur si muove!) e l'apprendimento continuo non entrano nel nostro DNA rischiamo il fallimento da panico in presenza delle inevitabili situazioni nuove Lean Project Management Panico perché, se ci adagiamo nella comfort zone e non impariamo a reagire ai cambiamenti ambientali, non solo non sapremo come risolvere i problemi dell'Innovazione ma non sapremo neppure come affrontarli Conoscenza & Sviluppo • Fortunati allora quei tecnici che possono gestire processi ongoing relativamente Well Structured Conoscenza & Sviluppo • Tali processi possono infatti essere “mappati” e, quindi, ottimizzati (per il Lean in ottica del Valore per il cliente ed ilVSM – Value Stream Mapping è una delle tecniche di base del Lean Manufacturing) Well Structured • Un processo è mappabile quando le sue attività, la loro sequenza ed i processi di controllo associati sono stabili e possono a priori essere descritti (abbastanza) accuratamente Conoscenza & Sviluppo • È quello che si fa anche nello Sviluppo con il metodo Predittivo utilizzando i reticoli di pianificazione (ad esempio il CPM-Critical Path Method), il Gantt e l'Earned Value Conoscenza & Sviluppo • La Progettazione purtroppo è oggi (non ai tempi del Gantt) un Processo di ricerca e apprendimento a prova ed errore nello spazio della Conoscenza Conoscenza & Sviluppo • Oltretutto, per complicare la vita, i progetti devono avere ben definite date di inizio e di termine: non c'è quindi molto tempo per recuperare gli errori Conoscenza & Sviluppo • La progettazione è, bene che vada, un processo Semi-Structured (ancora mappabile ma con molti If/Then) Semi-Structured Solo una parte di un processo semi-strutturato può essere definita in anticipo mentre un'altra parte non può essere completamente specificata sia per tipo e sequenza delle attività che per le modalità di controllo Conoscenza & Sviluppo • Più spesso è però un Processo Knowledge-Based, assolutamente non mappabile e, quindi, non ottimizzabile e predicibile Knowledge-based I processi knowledge based sono difficili da definire in anticipo e non possono avere transazioni fisse e strutture rigide in quanto le loro attività nascono da continue interazioni fra “attori” diversi e sinergici (a partire dai clienti) Knowledge-based • A priori, nei Processi Knowledge- based, si possono solo definire i Partecipanti e l'Elenco delle Cose ancora da Fare (in gergo Agile il Backlog) con l'ovvia necessità che tempi e costi dell'Apprendimento siano i più bassi possibile Oltre la gestione classica Per muoversi meglio nello Spazio della Conoscenza, il Lean spinge a utilizzare una gestione incrementale ed iterativa o, meglio, adattiva (PMBOK5 § 2.4.2.3/.4) PMBOK5 • “I cicli di vita incrementali ed iterativi sono quelli in cui le fasi ripetono intenzionalmente (si ripete per capire meglio e per migliorare) una o più attività del progetto mentre aumenta la comprensione del prodotto da parte del team di progettazione” Oltre la Cascata • Una gestione Lean “incrementale ed iterativa” richiede di svolgere lo Sviluppo con modalità: – Knowledge Based – Front Loaded (metodo 3P della Toyota) – Pull Knowledge Based • Sviluppo Knowledge Based vuol dire che, per muoversi nello spazio ignoto della Conoscenza, sono necessari, come detto, adeguati e continui (veloci) cicli di Apprendimento convalidati da sperimentazione Knowledge Based • Tali cicli, basati sul “metodo scientifico-sperimentale”, sono i classici PDCA (Plan, Do, Check, Act) • Almeno il ciclo PDCA di apprendimento ve l'hanno insegnato (dico ai più giovani) all'Università? Knowledge Based • Una banale conseguenza: se per migliorare i risultati e per ridurre i rischi si deve Apprendere, è necessario poter cambiare le cose e non “scriverle a priori sulla pietra” Knowledge Based • È allora sbagliato scegliere da subito, in fase Plan, la prima soluzione che si ritiene (o che il capo per fretta e pregiudizio ritiene) la migliore per soddisfare le specifiche iniziali (Point Based Engineering) Knowledge Based • È molto più ragionevole ipotizzare molte soluzioni, in comune però, in quanto più occhi …. vedono meglio di pochi, fra tutti “gli attori del ciclo di vita” Knowledge Based • Questo lo si fa utilizzando il Brainstrorming che rende il Plan una fase creativa a “imbuto divergente” Knowledge Based • Una volta trovate molte soluzioni si devono, dopo adeguate prove sperimentali (Do e Check), selezionare (Act) quelle migliori! Knowledge Based • Tali prove, generalmente grezze e veloci (dirty & quickly), serviranno a scartare (metodo incrementale a imbuto convergente) le soluzioni peggiori Knowledge Based • Si manderanno avanti le soluzioni potenzialmente migliori da sottoporre ad analisi più accurate (metodo del Set Based Engineering definito anche Toyota Paradox) Knowledge Based • Per poi congelare le soluzioni prescelte o, se necessario od opportuno, cambiarle ancora, mano a mano che migliora la conoscenza ! Front Loaded • Front Loaded vuol dire collaborazione fra tutti gli attori del Ciclo di vita in tutte le fasi dello Sviluppo, per evitare “l'effetto salmone” Front Loaded • Alcuni prevedono di farlo solo nella fase del Concept Paper previsionale ma, secondo me, questo è sbagliato Front Loaded • Si devono continuamente “Coinvolgere nel Team di sviluppo” anche gli specialisti di Marketing, Produzione, Montaggio, …, rompendo i tradizionali Silos Tayloristici ! Concurrent Engineering Pull • Pull vuol dire far pianificare il lavoro, a ciclo breve, dagli stessi sviluppatori delegando a loro le scelte delle attività da svolgere (sono loro gli Owners del Processo) Pull • Ed il coinvolgimento motiverà gli sviluppatori molto meglio che non la tradizionale “gerarchia” Pull • Per il Lean la ripianificazione pull deve essere frequente (pochi giorni) durante bervissimi “Stand up meeting” utilizzando strumenti visuali (Visual Project Board) Visual Workflow Management Per riassumere Di seguito vi propongo uno schema riassuntivo dello “Sviluppo Incrementale ed Iterativo” Steering Committee Gates Business Case Preliminary Processes Cicli Adattivi - PMBOK5 • “I cicli di vita adattivi, noti anche come metodologia Agile, sono volti a rispondere agli alti livelli di modifiche e al continuo coinvolgimento degli Stakeholders (in particolare dei clienti)” Gestione adattiva • La gestione “adattiva”, nota anche come Scrum, è un'estremizzazione di quella incrementale ed iterativa Gestione adattiva • Scrum spinge ad aggiornare ad ogni Sprint (brevi intervalli iterativi di tempo, da 2 a 4 settimane) anche i Requisiti in base all'aumento della Conoscenza che non solo gli Sviluppatori ma che gli stessi Clienti (e gli altri Stakeholders) avranno durante lo Sviluppo Gestione adattiva • Nella gestione “adattiva” gli Sprint devono portare a dei Risultati, parziali ma concreti (i classici Deliverables), che però i Clienti e gli altri Stakeholders possano provare e approvare, magari tramite Deliverables ad hoc (MVP – Minimum Viable Products) Gestione adattiva • In Scrum il Controllo a “maglia stretta” viene svolto ad ogni Sprint dal Product Owner (il PO rappresenta i Clienti e gli altri Stakeholders), un nuovo Ruolo, diverso dai classici Product Manager e Project Manager Il PO • Il PO è lo Zar del prodotto (non del processo che è, come detto, di “proprietà” del team di sviluppo) in quanto durante il ciclo di vita, rappresentando i clienti, ha tutti i poteri sullo stesso Gestione adattiva • La gestione adattiva è sicuramente necessaria nello sviluppo del SW e dei Servizi (generalmente i clienti si rendono conto delle vere funzionalità solo dopo averle effettivamente provate) Gestione adattiva • Oggi è però opportuna anche nello Sviluppo dei Prodotti manifatturieri Gestione adattiva • Si tenga presente oltretutto che oggi i prodotti manifatturieri: – possono essere simulati tramite SW per costruire degli MVP – la maggior parte ha una sostanziale componente SW che ne definisce le funzionalità Gestione adattiva • In sintesi la metodologia adattativa è la successiva Gestione adattiva Steering Committee Sprint Preliminari per Gate valutare il Business Case Sprint 1 Sprint i 2- 4 settimane PO Committee PO Committee Events Events Steering Committee Gate Sviluppo Incrementale e Adattivo del Prodotto Sprint n PO Committee Events Sprint n+1 PO Committee Events PO Committee Events Gestione adattiva Sprint – iterazione a periodo fisso (2-4 settimane) Scope (Ambito) Event: ✔ Requirements Sprint Planning Event Visual Workflow Management (Stand-up Meeting) ✔ Attributes ✔ Configuration ✔ Risk ✔ 3P PO Committee Events Design Review & Freeze Event Retrospective Event Conclusioni • Avendo detto che sono un po' obsoleti, quale strumento (Lean) vi propongo al posto del Gantt e del Earned Value ? Conclusioni • Ma è ovvio lo Scrum Board con la sua Burndown Chart ! To do Ongoing Done Sprint Goal Conclusioni • Ma c'è uno strumento ancora più Lean, magari utilizzabile anche individualmente, per programmare le proprie attività? Conclusioni • Ma certo: il Kanban Board ! Kanban Board Limiti Kanban (WiP) Bibliografia essenziale • PMBOK5 • Lean Thinking, J. P. Womack e D. T. Jones, Guerini e Associati • Essential Scrum, K. S. Rubin, AddisonWesley Series • Agile Estimating and Planning, M. Cohn, Prentice Hall • Innovazione Lean, L. Attolico, Hoepli [email protected] [email protected]
