Uploaded bySimone Onofri
Agile Project Framework
Il documento discute l'approccio Agile nel project management, evidenziando la sua filosofia collaborativa e orientata al cliente, sottolineando l'importanza di comprendere quando è opportuno applicare tale metodologia. Viene presentato l'Agile Project Framework (AgilePF), che integra principi chiave e pratiche per la pianificazione e la gestione dei progetti. Infine, vengono analizzate tecniche specifiche come il timeboxing e la priorità MoSCoW per garantire la riuscita dei progetti agili.
Agile Project Framework
- 1. Agile Project FrameworkPMI®-NIC Branch Lombardia 16 Giugno 2016 Simone Onofri
- 2. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Oggi dialoghiamo con… Simone Onofri
- 3. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Agenda • Agile – Introduzione • Cosa intendiamo per Agile • Vantaggi • AgilePF – il PAQ • AgilePF – Introduzione • Principi e valori • Ruoli e Project Manager • Ciclo di vita e configurazione • Prodotti • Integrazione con Scrum • Tecniche • Tempo – Timebox • Priorità – MoSCoW • Stima – Planning Poker
- 4.
- 5. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Cosa intendiamo per Agile? “Agile” è un termine “ombrello” che descrive solo un approccio collaborativo al lavoro e fortemente oriento al cliente. La filosofia agile è stata poi declinata in molti modi facendo nascere diverse interpretazioni e di conseguenza a molti agile framework e differenti agile mindset. DSDM® AgilePM™Scrum SAFe™ XP Crystal ASD AUP FDD RAD DAD AgilePF™ AgilePgM™ AgileBA™
- 6. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Quindi Agile è… “Buonsenso… ma non sempre usiamo il buonsenso quando applichiamo la filosofia Agile!” Riflessioni su Agile tra Arie Van Bennekum (firmatario del Manifesto Agile per il DSDM) e Steve Messenger (Chairman dell’Agile Business Consortium) avvenute tra il 2013 e il 2015 all’Agile Business Conference
- 7. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo La piramide di Agile Prassi e Tecniche specialistiche Framework e Modelli di Gestione per prodotto (o servizio) e/o per il progetto Principi Filosofia e Valori (Manifesto Agile, 2001)
- 8. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Manifesto Agile Stiamo scoprendo modi migliori di creare software, sviluppandolo e aiutando gli altri a fare lo stesso. Grazie a questa attività siamo arrivati a considerare importanti: Gli individui e le interazioni più che i processi e gli strumenti Il software funzionante più che la documentazione esaustiva La collaborazione col cliente più che la negoziazione dei contratti Rispondere al cambiamento più che seguire un piano Ovvero, fermo restando il valore delle voci a destra, consideriamo più importanti le voci a sinistra. N.B. Sostituendo la parola software con soluzione il manifesto può essere applicato a qualsiasi settore produttivo
- 9. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Sfatiamo un falso mito In Agile non si fa la documentazione! “Abbracciamo la documentazione, ma non centinaia di pagine che nessuno gestisce e in ‘tomi’ difficilmente utilizzabili” (Manifesto Agile)
- 10. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Sfatiamo un falso mito In Agile non si fa la pianificazione! “Facciamo la pianificazione, ma ne riconosciamo i limiti in un ambiente turbolento” (Manifesto Agile)
- 11. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Sfatiamo un falso mito Per essere agili si può usare solo Scrum! Agile è un modo di pensare e di lavorare, Scrum è uno dei TANTI framework agili nato per lavorare al solo livello di prodotto
- 12. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Sfatiamo un falso mito Il Project Manager è morto, viva il Project Manager! In alcuni framework non è previsto il ruolo/figura del Project Manager ma… i framework in cui non è presente si occupano del livello di progetto? oppure le sue responsabilità sono semplicemente state redistribuite?
- 13. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo «quelli che ritengono di poter fare a meno della gestione in un progetto sono solo dei cowboy» Andrew Craddock
- 14. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Sfatiamo un falso mito «Conviene sempre essere agili» Spesso Agile viene interpretato come «partiamo subito con lo sviluppo», ma è sempre la scelta migliore? Conviene sempre essere agili? Dipende! AgilePF fornisce gli strumenti per capirlo.
- 15. Agile – Vantaggidi essere Agili
- 16. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Vantaggi dell’essere Agili, più successo 50% 36% 14% Approccio tradizionale Waterfall Hanno Successo Sfidanti Falliscono 67% 27% 6% Approccio Agile IT Project Success Survey
- 17. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Come fare ad avere successo? 20% utilizzate SPESSO 50%utilizzate praticamente MAI 30%utilizzate RARAMENTE • Il problema è di solito relativo ai requisiti/funzionalità che sono messe nel piano di progetto. • Hanno un livello di importanza diverso • E’ importante focalizzarsi su quel 20% dei requisiti che porta l’80% dei benefici/vantaggi. • Identificare quel 20% è complicato (spesso lo sappiamo dopo). • Cosa fare quando tutti i requisiti sono importanti per il rilascio del progetto? (l’esempio di Amazon)
- 18. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Il triangolo dei Vincoli Il Project Manager mantiene le variabili di progetto all’interno delle tolleranze stabilite e nel rispetto degli obiettivi strategici, ma il modo in cui lo fa può variare moltissimo. Qualità Tempi Funzio- nalità Qualità Costi Tempi Funzio- nalità Approccio tradizionale Waterfall Approccio Agile Costi Variabili Fisse Adapted from DSDM®, reproduced with permission
- 19. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Come garantire Tempi, Costi e Qualità fissi? Principalmente utilizzando due importanti tecniche che sono alla base dell’AgilePF: il Timeboxing per gestire il tempo e MoSCoW per assegnare le priorità alle funzionalità da implementare
- 20. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo La tecnica del timeboxing in breve Timeboxing è una tecnica per la gestione del tempo che ci impone di consegnare alla scadenza e organizza il lavoro in funzione di questo obiettivo. Trasforma la variabile "tempo" in una costante, prefissando brevi periodi di tempo entro cui ottenere un determinato risultato.
- 21. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo La tecnica MoSCoW in breve Usiamo MoSCoW, una tecnica per l’assegnazione delle priorità. L’acronimo è ottenuto dai nomi attribuiti ai 4 livelli di priorità: • Must per un elemento di vitale importanza che deve essere soddisfatto. • Should per un elemento importante e in alta priorità che dovrebbe essere soddisfatto. • Could per un elemento desiderabile, ma non strettamente necessario. • Won’t (have this time, but would like) per un elemento che non sarà soddisfatto in questo momento. Nota: Bisogna fare attenzione a chiarire cosa intendiamo per “this time”, per esempio in questo incremento? In questo progetto?
- 22. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Scomporre il progetto in priorità per avere successo Perché nel business può essere una strategia vincente scomporre la soluzione/prodotto/servizio in sotto-prodotti più piccoli e poi attribuire una priorità di business alle singole parti che compongono? Perché possiamo utilizzare queste informazioni per anticipate il ROI, ridurre gli investimenti, ottimizzare alcuni rischi. …prendiamo l’esempio di una certificazione di sicurezza PCI-DSS
- 23. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Flusso di cassa e punto di pareggio Tempo Flussodicassa Punto di Pareggio Rilascio completo Tempo Flussodicassa Rilascio 2 Rilascio 3 Punto di Pareggio Rilascio 4 Benefici: • Time to market • Ottimizzazione del flusso di cassa • Feedback anticipato • Meno ri-lavorazione Rilascio 1
- 24. AgilePF – IlPAQ (come capire se è convenienti essere agili)
- 25. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Scegliere il giusto approccio La scelta della metodologia di gestione da applicare a un progetto è delicata: va fatta nelle primissime fasi e deve essere eseguita con attenzione. Non tutti i progetti sono adatti a una gestione di tipo agile e utilizzarla in contesti non idonei a recepirla introduce pericolosi e inutili fattori di rischio. Questo "rischio agile" va analizzato e valutato.
- 26. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Il Project Approach Questionnarie 1. Tutti i membri del progetto comprendono e accettano l’approccio del DSDM (filosofia, principi e prassi). 2. Il Business Sponsor e il Business Visionary dimostrano una ownership chiara e proattiva sul progetto. 3. La visione di Business che guida il progetto è chiara ed è compresa da tutti i membri del progetto. 4. Tutti i membri del progetto comprendono e accettano che la consegna nei tempi di una soluzione che rispetta i criteri di accettazione è il modo principale con cui si valuterà il successo del progetto. 5. Ai requisiti possono essere date priorità differenti e c’è la comprensione che i vincoli di tempi e budget possano essere gestiti rendendo flessibile l’ambito. 6. Tutti i membri del progetto accettano che i requisiti nelle prime fasi del progetto saranno definiti solo ad alto livello e che i dettagli emergeranno man mano.
- 27. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Il Project Approach Questionnarie 7. Tutti i membri del progetto accettano che il cambiamento nei requisiti è inevitabile e che solo abbracciando il cambiamento sarà possibile rilasciare la soluzione corretta. 8. Il Business Sponsor e il Business Visionary comprendono che il coinvolgimento attivo dei ruoli di business è essenziale e devono avere l’autorità per impegnare le persone del business nel progetto. 9. E’ possibile lavorare in maniera collaborativa, in particolare le persone del business e gli sviluppatori. 10.La responsabilizzazione del Solution Development Team è appropriata e sufficiente per supportare le attività decisionali giornaliere all’interno delle Timebox. 11.I ruoli e le responsabilità del DSDM siano allocate in maniera appropriata e chi ha un ruolo ha ben capito le sue responsabilità. 12. Il Solution Development Team ha, collettivamente, le conoscenze e le abilità (sia soft che tecniche) per far evolvere tutti insieme la soluzione.
- 28. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Il Project Approach Questionnarie 13.Il Solution Development Team è allocato per il progetto ad un livello appropriato per permettere lo svolgimento del lavoro all’interno della Timebox. 14.Le prassi e gli strumenti di lavoro collaborativi all’interno del Solution Development Team sono appropriati così da permettere il lavoro della soluzione. 15.Tutte le attività di revisione e test sono totalmente integrate all’interno delle prassi di sviluppo. 16.Lo stato di avanzamento è misurato principalmente attraverso gli incrementi dimostrabili di business value. 17. Non ci sono norme obbligatorie o altri vincoli che NON permettono l’applicazione della filosofia e delle prassi del DSDM per questo progetto
- 29. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo A cosa serve veramente il PAQ E’ uno strumento diagnostico per capire anzitutto se un approccio Agile è conveniente. Serve identificare eventuali rischi, così da poterli gestire correttamente. Serve per capire come personalizzare il framework per aumentare le possibilità di successo.
- 30.
- 31. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Cosa è Agile Project Framework • Framework dell’Agile Business Consortium (ex DSDM) • Sviluppato dal 1994. • E’ pensato per essere Agile ma anche coprire quelle attività relative al progetto «full-lifecycle». • E’ strutturato per essere integrato con altre metodologie, framework e corpi di conoscenze (e.g. Scrum, PRINCE2, PMI). • Agile Project Management si basa su Agile Project Framework e si focalizza su quello che può essere utile ad un Project Manager
- 32. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Gli 8 principi dell’Agile Project Framework 1. Essere focalizzati sulle necessità di Business. 2. Consegnare nei tempi. 3. Collaborare. 4. Non compromettere mai la qualità. 5. Costruire in maniera incrementale su solide fondamenta. 6. Sviluppare in maniera iterativa. 7. Comunicare continuamente e chiaramente. 8. Dimostrare controllo.
- 33. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Il Project Manager in AgilePF • Si interfaccia con le strutture di governance del progetto e delle parti interessate esterne al progetto. • Esegue la pianificazione di alto livello, e lascia quella di dettaglio (e.g. il Timebox Planning) o la pianificazione delle attività all’SDT. • Collabora con l’SDT e con le altre parti interessate per produrre il Delivery Plan • Monitora i progressi rispetto al Delivery Plan • Gestisce i rischi e si occupa delle escalation • Monitora e si assicura che avvenga la comunicazione • Motiva e responsabilizza tutto il team • Gestisce le escalation • Supporta il team in caso di difficoltà • Partecipa agli stand-up meeting se necessario per tenere traccia dei progressi del team e per gestire eventuali problematiche Si trova nel livello di progetto e coordina gli aspetti di gestione/ di alto livello, lasciando gli quelli di dettaglio all’SDT
- 34. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Caratteristiche delle «squadre» agili! • La parola chiave è Collaborazione • Competenze hard «T-Shaped» • Competenze soft importanti sugli aspetti di comunicazione, collaborazione e problem- solving • Attenzione • Dimensioni del team • Ai vari stakeholder sin da FEFO https://onofri.org/b/team-la-dimensione-di-un-team-di-progetto-quale-ottimale/ .... 4.6 (Hackman/Vidmar) ..... 5 (Steiner) … 3 …… 9 (DSDM) ….. 5 …. 9 (Scrum) due pizze «americane» (Bezos)
- 35. Tecniche – Tempo- Timeboxing
- 36. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Timeboxing Una timebox è un intervallo di tempo prefissato, una finestra temporale in cui viene creato un incremento di prodotto/progetto rilasciabile, potenzialmente utilizzabile dall'utente finale.
- 37. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Kick-Off Close-Out Investigation (10-20% del tempo) Consolidation (10-20% del tempo) Refinement (60-80% del tempo) 2-4 settimane (massimo 6) Adapted from DSDM®, reproduced with permission La struttura della Timebox di AgilePF
- 38. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo La development Timebox di AgilePF • Kick-off (1-3 ore): una breve sessione per comprendere l'obiettivo della timebox, il contenuto, le priorità, i ruoli e le responsabilità. • Investigation (10-20% del tempo totale): una iteration (iterazione) iniziale per dettagliare tutti i prodotti da rilasciare nella Timebox, compresi gli Acceptance Criteria (Criteri di Accettazione) / Definition of Done. • Refinement (60-80% del tempo totale): una iteration (iterazione) in cui sono eseguiti sviluppo, test e redazione della documentazione (se necessaria) in linea con le priorità. Alla fine di questa iterazione, si raccomanda di non cominciare nuove attività, ma di concentrasi nel consolidare quanto già fatto. • Consolidation (10-20% del tempo totale): una iteration (iterazione) per assicurarsi che i prodotti rispettino gli Acceptance Criteria (criteri di accettazione). • Close-out (1-3 ore): una breve sessione per l'accettazione formale di quanto realizzato nella Timebox, una retrospettiva per capire cosa è andato bene e cosa no; una ripianificazione di eventuali elementi che non sono stati rilasciati.
- 39. Tecniche – Priorità- MoSCoW
- 40. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo «Tutto ha una priorità» Risposte semplici a domande complesse
- 41. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo La tecnica MoSCoW in breve Usiamo MoSCoW, una tecnica per l’assegnazione delle priorità. L’acronimo è ottenuto dai nomi attribuiti ai 4 livelli di priorità: • Must per un elemento di vitale importanza che deve essere soddisfatto. • Should per un elemento importante e in alta priorità che dovrebbe essere soddisfatto. • Could per un elemento desiderabile, ma non strettamente necessario. • Won’t (have this time, but would like) per un elemento che non sarà soddisfatto in questo momento. Nota: Bisogna fare attenzione a chiarire cosa intendiamo per “this time”, per esempio in questo incremento? In questo progetto?
- 42. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Cosa vuol dire usare MoSCoW nel nostro progetto • Consegnare ad una data predefinita e garantita vuol dire che, probabilmente, parte del lavoro pianificato in origine sarà rimandato. • Inoltre potrebbe essere necessario rilasciare del lavoro che, invece, non era stato inizialmente pianificato. • Può essere comunque escluso solo il lavoro non strettamente necessario. • E’ importante utilizzare MoSCoW su più livelli (Progetto, Incremento, singola timebox).
- 43. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Esempio: la valigia di Keith • Per un breve fine settimana in un altra città d’Europa cosa metti in un piccolo bagaglio a mano? • MUST – Documento valido per l’espatrio. Deve essere portato altrimenti non vi fanno salire sull’aereo. • SHOULD – Magliette, devono essere presenti, ma si potrebbero anche comprare in loco. • COULD – Guida del luogo. E’ utile averla prima della partenza, ma non è fondamentale Anzi, solitamente è possibile trovarne di gratuite all’arrivo!
- 44. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Esempio: la penna di Keith Possiamo applicare la tecnica MoSCoW per attribuite le priorità ai requisiti per produrre una penna a sfera? Certo! MUST serbatoio con inchiostro punta con relativa sfera SHOULD fusto in plastica COULD cappuccio in plastica tappo in plastica CC-BY-NC-NDSimone Onofri e Claudia Spagnuolo
- 45. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo CC-BY-NC-NDSimone Onofri e Claudia Spagnuolo In ambito di progetto è importante garantire il rilascio dei Must. Si procede quindi bilanciando la quantità di Must, Should e Could secondo l’impegno (effort) necessario. Tecnica MoSCoW: perché bilanciare i requisiti
- 46. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Tecnica MoSCoW: bilanciare i requisiti Should (20%) 4 Contingency (20%) Business Case (80%) Must (60%) Minimum Usable Subset Could (20%) DSDM® consiglia questa “regola del pollice. Se non la rispettiamo va gestito un rischio apposito. Adapted from DSDM® , reproduced with permission CC-BY-NC-NDSimone Onofri e Claudia Spagnuolo
- 47. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo «ogni corpo immerso parzialmente o completamente in un fluido (liquido o gas) riceve una spinta verticale dal basso verso l'alto, uguale per intensità al peso del volume del fluido spostato» Risposte semplici a domande complesse
- 48. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Tecnica MoSCoW: abbracciare il cambiamento! Should (20%) 4 Contingency (20%) Business Case (80%)Must (60%) Minimum Usable Subset Could (20%) Adapted from DSDM® , reproduced with permission CC-BY-NC-NDSimone Onofri e Claudia Spagnuolo Must Won’t Probabilmente i requisiti cambieranno durante il progetto e sarà necessario rivalutare la lista dei requisiti e le relative priorità. Attenzione: se siamo in una Timebox di Sviluppo e il Team ha intenzione di togliere un Must, deve essere contattato il livello superiore!
- 49. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Tecnica MoSCoW: priorità non bilanciate Se le priorità non sono bilanciate, dobbiamo gestire il rischio associato (e.s. avere poca contingenza): Modificare nuovamente le priorità e/o scomporre i requisiti. Valutare ed accettare esplicitamente il rischio (lato fornitore e committente), quindi monitorarlo.
- 50. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Tecnica MoSCoW: dipendenze fra i requisiti E se i requisiti sono fra loro indipendenti? Come assegno le priorità se esistono delle dipendenze? Vediamo un esempio… CC-BY-NC-NDSimone Onofri e Claudia Spagnuolo
- 51. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Esempio: il tappo della penna di Keith 1/4 E se avessimo un vincolo per questioni di sicurezza sulla forma del tappo di plastica? Andrebbe aggiunto un requisito “cavità sulla punta del tappo". CC-BY-NC-NDSimone Onofri e Claudia Spagnuolo
- 52. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo SENZA vincolo di sicurezza: • MUST – serbatoio con inchiostro • MUST – punta con relativa sfera • SHOULD – fusto in plastica • COULD – cappuccio in plastica • COULD – tappo in plastica CC-BY-NC-NDSimone Onofri e Claudia Spagnuolo Esempio: il tappo della penna di Keith 2/4 Come classifichiamo il nuovo requisito “cavità sulla punta del tappo”?
- 53. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo SENZA vincolo di sicurezza: • MUST – serbatoio con inchiostro • MUST – punta con relativa sfera • SHOULD – fusto in plastica • COULD – cappuccio in plastica • COULD – tappo in plastica CC-BY-NC-NDSimone Onofri e Claudia Spagnuolo Esempio: il tappo della penna di Keith 3/4 CON vincolo di sicurezza: • MUST – serbatoio con inchiostro • MUST – punta con relativa sfera • SHOULD – fusto in plastica • COULD – cappuccio in plastica • COULD – tappo in plastica • MUST - cavità sulla punta del tappo
- 54. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Esempio: il tappo della penna di Keith 4/4 In definitiva… Il requisito "cavità sulla punta del tappo” non è un vero è proprio MUST, in quanto se decidessimo di non realizzare il tappo anche il requisito di sicurezza andrebbe a decadere. Quindi: Al gruppo dei COULD andrebbe aggiunto un requisito di tipo MUST – cavità sulla punta del tappo. CC-BY-NC-NDSimone Onofri e Claudia Spagnuolo
- 55. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Tecnica MoSCoW: Lesson Learned • Le priorità NON sono ‘assolute’ perché: • Possono esserci delle dipendenze • Le priorità possono essere assegnate a livello di progetto, di incremento e di timebox e possono NON coincidere. • Variano nel tempo • Variano se cambiano le esigenze di business CC-BY-NC-NDSimone Onofri e Claudia Spagnuolo
- 56. Tecniche – Stima- Planning Poker
- 57. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Tecniche di stime Agili: Cosa sono le stime? “La stima è una previsione di quello che costerà fornire un insieme di requisiti o, al contrario, quali requisiti (per esempio funzionalità) possono essere rilasciate in una quantità di tempo definita o ad un determinato costo. A tale valore sono associate anche altre informazioni come il grado di accuratezza o un livello rischio.” Definizione di Mairi Osborne e Barry Fazackerley in “DSDM Atern Estimating”
- 58. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Tecniche di stime Agili: Accuratezza delle stime 4x 2x 1x .5x .25x Accuratezzadellastima Pre-project Feasibility Foundations Development Deployment Il cono di incertezza di Barry Bohem e Agile Project Management
- 59. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Tecniche di stime Agili: regole di base 1/3 Dal manuale di PRINCE2® “Presumere che le risorse saranno produttive solo per l’80% del tempo.”
- 60. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Tecniche di stime Agili: regole di base 2/3 Dal manuale di DAD "Durante la durata di un iterazione parte del tempo è dedicato a riunioni, a supportare gli altri componenti del team, trasferte ecc… ”
- 61. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Tecniche di stime Agili: regole di base 3/3 “Far eseguire la stima a chi realizzerà il prodotto” Dal manuale di PRINCE2®
- 62. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Tecniche di stime Agili: cos’è il Planning Poker il Planning Poker® “Lo scopo è ottenere una ‘stima collaborativa’ condivisa dal gruppo che ha le necessarie conoscenze/competenze. Per farlo utilizza un mazzo di carte su cui sono riportati i valori di una progressione numerica”
- 63. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Tecniche di stime Agili: il Planning Poker® • Il Planning Poker consiste in una serie di iterazioni così strutturate: • Il Moderatore introduce la sessione • Per ogni elemento da stimare il Moderatore legge la descrizione. Se ci sono dei dubbi l’Esperto di prodotto può fornire chiarimenti. • Ogni Estimator seleziona una carta dal suo mazzo e la tiene coperta. • Allo scadere del tempo (timebox) - o quando tutti hanno deciso - si girano le carte simultaneamente. Se le stime ottenute sono molto differenti il Moderatore chiede agli Estimator “fuori dal coro” di spiegare le motivazioni, con lo scopo di condividere il punto di vista. Dopo la spiegazione si procede con una nuova iterazione.
- 64. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Analisi delle stime Agili dopo una sessione di stima collaborativa Angela Barbara Carla Daniela Emanuela Filippo Scenario “A” 2 4 5 4 3 1 Scenario “B” 5 3 3 3 1 3 Scenario “C” 2 2 3 3 3 2 Scenario “D” 1 2 4 2 4 1 Scenario “E” 1 3 2 2 1 6
- 65. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Stime Agili: varianti del Planning Poker® •E’ possibile utilizzare il Planning Poker in diverse varianti: •Senza carte, in stile morra cinese •Variando i valori delle carte: •Serie numeriche lineari: 0, 1, 2, 4, 8, 16, 32... •Fibonacci: 1, 2, 3, 5, 8, 13, 21… •Taglie delle Magliette: XS, S, M, L, XL…
- 66. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Stime Agili: unità di misura Le unità di misura possono essere diverse. Possiamo usare unità di misura assolute (p.e. le giornate/uomo) o relative (p.e. “story point”) usando come riferimento una storia (un requisito) che come riferimento. Nota: quando si usano le unità relative in contesti con più team - o quando il nostro team cambia - può creare problemi. In tal caso far stimare gli stessi requisiti di riferimento ai diversi team per poter normalizzare la stima.
- 67. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Esempio di stima: Penetration Test «Abbiamo un BrightRay™ Portal con 2 portlet personalizzate e una per il pagamento con carte di pagamento fatta con SecurePaymentGatewy™» Dice il Team Leader ai tester che sono intorno ad un tavolo. Pensate ad una stima e mettete una carta coperta sul tavolo senza farla vedere agli altri, così da non influenzarli. 67
- 68. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Planning Poker – la prima mano 68 13 13 13 5 Tester #1 Tester #2 Tester #3 Tester #4
- 69. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Planning poker – condivisione delle informazioni Il Team Lead vede che uno dei tester non è allineato con gli altri. Pertanto potrebbe avere delle informazioni interessant ida condividere, quindi il Team Lead chiede a tutti di ascoltare il Tester #3 «Ho fatto un test BrightRay™ qualche settimana fa e ho fatto uno strumento personalizzato che rende più buonaparte delle attività di Information Gathering e ho già preparato del codice da inserire su BrightRayan™ da caricare sul portale se troviamo una falla per prendere il controllo della macchina» Tester #1 risponde «questa è una bella notizia, l’ultima volta sono stato invece molto tempo su un altro componente che aveva delle difese piuttosto efficaci.» 69
- 70. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Planning Poker – seconda mano 8 13 5 5 Tester #1 Tester #2 Tester #3 Tester #4
- 71. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Grazie Simone Onofri simone@onofri.org https://onofri.org/
- 72. CC-BY-NC-NDSimone Onofri eClaudia Spagnuolo Riferimenti e approfondimenti • Agile Business Consortium • AgilePF Handbook (online) – https://www.agilebusiness.org/resources/dsdm- handbooks/the-dsdm-agile-project-framework-2014-onwards • Agile Business Change - https://www.agilebusiness.org/resources/downloads/agile- business-change-framework-overview • PAQ - https://www.agilebusiness.org/content/appendix-b-project-approach- questionnaire-paq • Contract - https://www.agilebusiness.org/resources/templates-and-tools/dsdm- agile-project-framework-contract-template • Facilitation • Tony Mann – Facilitation - https://www.apmg-businessbooks.com/books/facilitation- book-bound-develop-your-expertise-2014-4 • Lego Serious Play – Un breve manuale - https://onofri.org/b/lego-serious-play-un- breve-manuale-come-si-struttura/