Agile Project Management. Ing. Roberto Chiavaccini Ordine degli Ingegneri di Livorno Seminario 18/12/2014

Transcript

1 Agile Project Management Ing. Roberto Chiavaccini Ordine degli Ingegneri di Livorno Seminario 18/12/2014

2 Cos'è? Un aiutino: è stato ideato nel 1902 dall'ingegnere tedesco Max Rietz

3 Il Regolo calcolatore Il Regolo calcolatore era il simbolo degli ingegneri! All'Università ve l'hanno insegnato? Lo utilizzate?

4 Cos'è?

5 Un aiutino è stato ideato nel 1917 dall'ingegnere americano H. Gantt, collaboratore del più famoso ingegnere F. W. Taylor

6 Il Gantt È il simbolo del metodo progettuale classico definito, dal PMI (Project Management Institute), Predittivo!

7 Il Gantt A Ingegneria vi hanno insegnato il Gantt ed il Metodo Predittivo? Li utilizzate?

8 Il Metodo predittivo Di seguito alcune considerazioni sul Metodo Predittivo basandole sul PMBOK5 del PMI, principale referente mondiale di Project Management

9 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)

10 Metodo Predittivo Questi tipi di progetto passano attraverso una serie di fasi sequenziali o sovrapposte.

11 Sa lm W at er fa ll on i?

12 Problemi Nella progettazione a cascata sono necessari continui feedback informativi (effetto salmone) che, purtroppo, dilatano tempi e costi

13 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

14 Le Specializzazioni creano Problemi Silos Tayloristici Silos

15 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

16 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

17 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!

18 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

19 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!

20 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!

21 Metodo Predittivo Purtroppo oggi Incertezza e Complessità regnano sovrane

22 Metodo Predittivo Il nostro (degli ingegneri più anziani ) bel Mondo Razional Meccanicistico (tutto è e deve essere noto a priori, il prima possibile) è scomparso

23 Metodo Predittivo Ed il metodo predittivo non è più sufficiente!

24 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

25 Metodo Predittivo Ma il peggio è che anche l'ambito ed i Costi sono rispettati solo nel 10% dei casi

26 Metodo Predittivo Il che vuole dire che le previsioni sono rispettate. nel 1/1000 dei casi: è un po' poco per essere solo sfortuna!

27 Metodo Predittivo Molti poi sono scoraggiati dal tempo e dai costi di implementazione del Metodo

28 Metodo Predittivo In tal caso si rinuncia e si ricorre al classico Just do It (empirismo manageriale)

29 Just Do It Purtroppo con l'empirismo manageriale le cose vanno anche peggio!

30 Just Do It In Italia poi, per carenze di insegnamento di Project Management da parte delle Università, l'empirismo la fa decisamente da padrone

31 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!

32 Taylor & Gantt Perché allora, se il Principio è valido, le soluzioni del Taylor e del Gantt oggigiorno danno risultati non troppo brillanti?

33 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!

34 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

35 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!

36

37 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

38 Agile Generalmente con Agile ci si riferisce allo sviluppo di prodotti SW con specifici metodi Lean emersi a partire dai primi anni 2000

39 Agile Tali metodi sono basati sui princìpi del "Manifesto Agile" pubblicato nel 2001 ad opera di 17 professionisti dello sviluppo SW

40 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à) ---

41 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

42 Agile Purtroppo per me il PMI definisce Agile il Metodo Adattivo che vedremo subito dopo e se lo dice il PMI ubi maior.

43 Agile Di recente il PMI ha addirittura introdotto una specifica certificazione (PMI-ACP)SM - PMI Agile Certified Practitioner

44 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

45 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

46 Un assioma famoso Se fossi stato a sentire i miei clienti avrei prodotto una carrozza più veloce! H. Ford

47 Lean Project Management Ed è proprio la mancanza di Conoscenza che rende velleitario il metodo predittivo

48 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

49 Lean Project Management In un mondo che cambia rapidamente si deve uscire volontariamente dal comfort per entrare nella zona dell'apprendimento

50

51 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

52 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

53 Conoscenza & Sviluppo Fortunati allora quei tecnici che possono gestire processi ongoing relativamente Well Structured

54 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)

55 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

56 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

57 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

58 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

59 Conoscenza & Sviluppo La progettazione è, bene che vada, un processo Semi-Structured (ancora mappabile ma con molti If/Then)

60 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

61 Conoscenza & Sviluppo Più spesso è però un Processo Knowledge-Based, assolutamente non mappabile e, quindi, non ottimizzabile e predicibile

62 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)

63 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

64 Oltre la gestione classica Per muoversi meglio nello Spazio della Conoscenza, il Lean spinge a utilizzare una gestione incrementale ed iterativa o, meglio, adattiva (PMBOK /.4)

65 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

66 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

67 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

68 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à?

69 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

70 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)

71 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

72 Knowledge Based Questo lo si fa utilizzando il Brainstrorming che rende il Plan una fase creativa a imbuto divergente

73 Knowledge Based Una volta trovate molte soluzioni si devono, dopo adeguate prove sperimentali (Do e Check), selezionare (Act) quelle migliori!

74 Knowledge Based Tali prove, generalmente grezze e veloci (dirty & quickly), serviranno a scartare (metodo incrementale a imbuto convergente) le soluzioni peggiori

75 Knowledge Based Si manderanno avanti le soluzioni potenzialmente migliori da sottoporre ad analisi più accurate (metodo del Set Based Engineering definito anche Toyota Paradox)

76 Knowledge Based Per poi congelare le soluzioni prescelte o, se necessario od opportuno, cambiarle ancora, mano a mano che migliora la conoscenza!

77 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

78 Front Loaded Alcuni prevedono di farlo solo nella fase del Concept Paper previsionale ma, secondo me, questo è sbagliato

79 Front Loaded Si devono continuamente Coinvolgere nel Team di sviluppo anche gli specialisti di Marketing, Produzione, Montaggio,, rompendo i tradizionali Silos Tayloristici!

80 Concurrent Engineering

81 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)

82 Pull Ed il coinvolgimento motiverà gli sviluppatori molto meglio che non la tradizionale gerarchia

83 Pull Per il Lean la ripianificazione pull deve essere frequente (pochi giorni) durante bervissimi Stand up meeting utilizzando strumenti visuali (Visual Project Board)

84 Visual Workflow Management

85 Per riassumere Di seguito vi propongo uno schema riassuntivo dello Sviluppo Incrementale ed Iterativo

86 Steering Committee Gates Business Case Preliminary Processes

87 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)

88 Gestione adattiva La gestione adattiva, nota anche come Scrum, è un'estremizzazione di quella incrementale ed iterativa

89 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

90 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)

91 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

92 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

93 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)

94 Gestione adattiva Oggi è però opportuna anche nello Sviluppo dei Prodotti manifatturieri

95 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à

96 Gestione adattiva In sintesi la metodologia adattativa è la successiva

97 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

98 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

99 Conclusioni Avendo detto che sono un po' obsoleti, quale strumento (Lean) vi propongo al posto del Gantt e del Earned Value?

100 Conclusioni Ma è ovvio lo Scrum Board con la sua Burndown Chart!

101 To do Ongoing Done Sprint Goal

102 Conclusioni Ma c'è uno strumento ancora più Lean, magari utilizzabile anche individualmente, per programmare le proprie attività?

103 Conclusioni Ma certo: il Kanban Board!

104 Kanban Board Limiti Kanban (WiP)

105 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

106