GUIDA ALLE PRATICHE DELL’AGILE

Richiesta presentata alla Libreria del Congresso - Catalogazione dei dati di pubblicazione.

ISBN: 978-1-62825-4-167

Pubblicato da:Project Management Institute, Inc.14 Campus BoulevardNewtown Square, Pennsylvania 19073-3299 USATelefono: +1 610-356-4600Fax: +1 610-356-4647Email: customercare@pmi.orgInternet: www.PMI.org

©2017 Project Management Institute, Inc. Tutti i diritti riservati.

I contenuti del Project Management Institute, Inc. sono protetti da diritto d’autore in base alla legge statunitense sulla proprietà intellettuale riconosciuta nella maggior parte dei Paesi. Per ripubblicare o riprodurre i contenuti del PMI, è necessario ottenere la nostra autorizzazione. Andare sul sito http://www.pmi.org/permissions per ulteriori dettagli.

Per inoltrare un ordine commerciale o per informazioni sui prezzi, contattare Independent Publishers Group:Independent Publishers GroupOrder Department814 North Franklin StreetChicago, IL 60610 USATelefono: +1 800-888-4741Fax: +1 312- 337-5985E-mail: orders@ipgbook.com (solo per ordini)

Per tutte le altre richieste, contattare il PMI Book Service Center.PMI Book Service CenterP.O. Box 932683, Atlanta, GA 31193-2683 USATelefono: 1-866-276-4764 (dagli Stati Uniti o dal Canada) o +1-770-280-4129 (dal resto del mondo)Fax: +1-770-280-4113 E-mail: info@bookorders.pmi.org

Stampato negli Stati Uniti d'America. È fatto divieto di riprodurre o trasmettere qualsiasi sezione di questo lavoro sotto qualsiasi forma o mediante qualsiasi mezzo, sia esso elettronico, manuale, per fotocopiatura o registrazione o mediante sistemi di recupero e memorizzazione dati, senza previa autorizzazione scritta da parte dell'editore.

La carta utilizzata in questo manuale è conforme allo standard per la carta stampata emanato dalla National Information Standards Organization (Z39.48—1984).

PMI, il logo PMI, PMBOK, OPM3, PMP, CAPM, PgMP, PfMP, PMI-RMP, PMI-SP, PMI-ACP, PMI-PBA, PROJECT MANAGEMENT JOURNAL, PM NETWORK, PMI TODAY, PULSE OF THE PROFESSION e lo slogan MAKING PROJECT MANAGEMENT INDISPENSABLE FOR BUSINESS RESULTS sono tutti marchi del Project Management Institute, Inc. Per un elenco completo dei marchi del PMI, contattare il Dipartimento Legale del PMI. Tutti gli altri marchi commerciali, marchi di servizio, nomi commerciali, immagini aziendali, nomi di prodotti e loghi presenti nel volume sono di proprietà dei rispettivi titolari. Qualsiasi diritto non espressamente garantito nel presente manuale è riservato.

SAFe è un marchio registrato di Scaled Agile, Inc.

Agile Alliance e il logo Agile Alliance sono marchi di Agile Alliance.

La presente Guida pratica è stata finanziata con Agile Alliance® e sviluppata in collaborazione con i membri di Agile Alliance®. Agile Alliance® non promuove alcuna metodologia o certificazione agile.

10 9 8 7 6 5 4 3 2 1

NOTA

Le pubblicazioni sugli standard e sulle linee guida del Project Management Institute, Inc. (PMI), di cui fa parte questo documento, vengono sviluppate mediante un processo di elaborazione degli standard basato sul consenso volontario. Questo processo riunisce volontari e/o ricerca l'opinione di persone interessate all'argomento trattato in questa pubblicazione. Sebbene amministri il processo e stabilisca quali regole promuovere a garanzia della correttezza nella creazione del consenso, il PMI non redige il documento e non esamina, valuta o verifica in modo autonomo l'accuratezza e la completezza delle informazioni o la solidità dei criteri contenuti nelle sue pubblicazioni su standard e direttive.

Il PMI declina qualsiasi responsabilità per lesioni a persone o beni o per altri danni di qualsivoglia natura, siano essi particolari, indiretti, conseguenti o compensativi, derivanti direttamente o indirettamente dalla pubblicazione, dall'applicazione o dalla fiducia riposta in questo documento. Il PMI declina qualsiasi responsabilità e non fornisce alcuna garanzia, espressa o implicita, in merito all'accuratezza o alla completezza delle informazioni pubblicate nel presente documento, e declina altresì qualsiasi responsabilità e non garantisce che tali informazioni rispondano a obiettivi o esigenze particolari. Il PMI non fornisce alcuna garanzia in merito alle prestazioni dei singoli prodotti e servizi dei produttori o fornitori in virtù di questo standard o di questa guida.

Pubblicando e rendendo disponibile questo documento, il PMI non si impegna a rendere servizi professionali o di altra natura per o per conto di qualsiasi persona fisica o giuridica, né si impegna a eseguire qualsiasi servizio dovuto da qualsiasi persona fisica o giuridica a terzi. Chiunque utilizzi questo documento deve affidarsi alla propria capacità di giudizio o, eventualmente, può richiedere il parere di un professionista competente per stabilire il grado di attenzione necessario in determinate circostanze. Le informazioni e gli altri standard riguardanti gli argomenti trattati in questa pubblicazione potrebbero essere disponibili presso altre fonti, che l'utente può consultare per ottenere opinioni alternative o informazioni non trattate dalla presente pubblicazione.

Il PMI non dispone dell'autorità per obbligare, né si impegna a controllare e a far rispettare la conformità ai contenuti di questo documento. Il PMI non certifica, controlla o ispeziona i prodotti, i progetti o le installazioni ai fini del rispetto delle norme di sicurezza e sanitarie. Qualsiasi certificazione o dichiarazione di conformità a qualsiasi informazione in materia sanitaria o di sicurezza riportata nel presente documento non potrà essere attribuita al PMI ma sarà di responsabilità esclusiva dell'entità che ha certificato o effettuato la dichiarazione.

PREFAZIONE

Il Project Management Institute e l’Agile Alliance® hanno realizzato questa guidaper favorire una maggiore comprensione degli approcci agili nelle rispettive comunità. La finalità di questa guida è quella di fornire ai gruppi di progetto strumenti, linee guida situazionali e una comprensione delle tecniche e degli approcci agili disponibili, per facilitare il raggiungimento di risultati migliori.

I gruppi di progetto adottano approcci agili in una varietà di settori che non si limitano allo sviluppo software. Entrambe le organizzazioni sono consapevoli che questa diffusione ha creato l’esigenza di un linguaggio comune, di una mentalità aperta e di una maggior propensione a essere flessibili per quanto riguarda le modalità di introduzione sul mercato di prodotti e deliverable. Inoltre, entrambe le organizzazioni sono convinte che sono molti i modi per rilasciare con successo. La gamma di strumenti, tecniche e schemi di riferimento a disposizione è ampia: i gruppi possono scegliere pratiche e approcci adeguati ai propri progetti e alla cultura della propria organizzazione per raggiungere il risultato desiderato.

I membri del comitato centrale dell’Agile Practice Guide provengono da esperienze diverse e adottano vari approcci. Alcuni membri del comitato sono consulenti e altri operano all’interno di organizzazioni. Operano tutti in modalità agile da molti anni.

SOMMARIO

1. INTRODUZIONE ........................................................................................................................... 1

2. INTRODUZIONE ALL’AGILE ......................................................................................................... 72.1 Lavoro definibile vs. lavoro a elevata incertezza ............................................................ 72.2 L’Agile Manifesto e la Mentalità agile ............................................................................. 82.3 Lean e il metodo Kanban ................................................................................................ 122.4 Incertezza, rischio e scelta del ciclo di vita .................................................................. 13

3. SELEZIONE DEL CICLO DI VITA ................................................................................................ 173.1 Caratteristiche dei cicli di vita del progetto .................................................................. 18

3.1.1 Caratteristiche dei cicli di vita predittivi ........................................................... 203.1.2 Caratteristiche dei cicli di vita iterativi ............................................................. 213.1.3 Caratteristiche dei cicli di vita incrementali ..................................................... 223.1.4 Caratteristiche dei cicli di vita agili ................................................................... 243.1.5 Filtri di idoneità agili .......................................................................................... 253.1.6 Caratteristiche dei cicli di vita ibridi ................................................................. 263.1.7 Approcci agili e predittivi combinati ................................................................. 273.1.8 Approccio prevalentemente predittivo con alcune componenti agili .............. 283.1.9 Un approccio significativamente agile con una componente predittiva ......... 283.1.10 Cicli di vita ibridi come idonei allo scopo ....................................................... 293.1.11 Cicli di vita ibridi come strategia di transizione ............................................. 30

3.2 Abbinare approcci agili .................................................................................................. 313.3 Fattori di progetto che influenzano la personalizzazione ............................................. 32

I

4. IMPLEMENTAZIONE DI AGILE: CREARE UN AMBIENTE AGILE ................................................. 334.1 Iniziare con una mentalità agile .................................................................................... 334.2 La servant leadership rafforza e responsabilizza il team ............................................. 33

4.2.1 Responsabilità del servant leader ..................................................................... 344.2.2 Il ruolo del Project Manager in un ambiente agile ............................................ 374.2.3 I Project Manager utilizzano la servant leadership .......................................... 38

4.3 Composizione del team .................................................................................................. 384.3.1 Team agili ........................................................................................................... 394.3.2 Ruoli agili ............................................................................................................ 404.3.3 Specialisti generalisti ........................................................................................ 424.3.4 Strutture del team .............................................................................................. 434.3.5 Membri del gruppo dedicati ............................................................................... 444.3.6 Spazi di lavoro del team .................................................................................... 464.3.7 Superamento dei silos organizzativi ................................................................. 47

5. IMPLEMENTAZIONE DI AGILE: OPERARE IN UN AMBIENTE AGILE .......................................... 495.1 Ufficializzare il progetto e il team .................................................................................. 495.2 Pratiche agili comuni ..................................................................................................... 50

5.2.1 Retrospettive ...................................................................................................... 505.2.2 Preparazione del backlog .................................................................................. 525.2.3 Affinamento del backlog .................................................................................... 525.2.4 Daily Stand-up .................................................................................................... 535.2.5 Dimostrazioni/Revisioni ..................................................................................... 555.2.6 Pianificazione per l’agile iteration-based ......................................................... 555.2.7 Pratiche di esecuzione che aiutano i gruppi a rilasciare valore ...................... 565.2.8 In che modo iterazioni e incrementi contribuiscono al rilascio di un prodotto funzionante ......................................................................................... 57

5.3 Risoluzione dei problemi nei progetti agili .................................................................... 575.4 Misurazioni nei progetti agili ......................................................................................... 60

5.4.1 risultati della misurazione dei gruppi agili ....................................................... 61

II Sommario

6. CONSIDERAZIONI ORGANIZZATIVE SULL’AGILITÀ NEI PROGETTI ........................................... 716.1 Gestione del cambiamento organizzativo ..................................................................... 71

6.1.1 Fattori determinanti per la gestione del cambiamento .................................... 736.1.2 Prontezza al cambiamento ................................................................................ 73

6.2 Cultura organizzativa ..................................................................................................... 756.2.1 Creare un ambiente sicuro ................................................................................ 756.2.2 Valutazione della cultura ................................................................................... 75

6.3 Approvvigionamento e Contratti .................................................................................... 776.4 Pratiche aziendali ........................................................................................................... 796.5 Coordinamento e dipendenze multiteam (scalabilità) .................................................. 80

6.5.1 Schemi di riferimento ........................................................................................ 806.5.2 Considerazioni .................................................................................................... 80

6.6 Agile e il Project Management Office (PMO) ................................................................. 816.6.1 Un PMO agile è una unità con orientamento al valore ...................................... 816.6.2 Un PMO agile è una unità con orientamento all’invito ..................................... 816.6.3 Un PMO agile è una unità multidisciplinare ...................................................... 82

6.7 Struttura organizzativa .................................................................................................. 836.8 Far evolvere l’organizzazione ........................................................................................ 84

7. CALL TO ACTION ...................................................................................................................... 87

ALLEGATO A1 MAPPATURA GUIDA PMBOK® ...................................................................................................... 89

ALLEGATO A2 MAPPATURA DELL’AGILE MANIFESTO ........................................................................................ 97

ALLEGATO A3 PANORAMICA DEGLI SCHEMI DI RIFERIMENTO AGILI E LEAN .................................................... 99

APPENDICE X1 PARTECIPANTI E REVISORI ........................................................................................................ 115

III

APPENDICE X2 ATTRIBUTI CHE INFLUENZANO LA PERSONALIZZAZIONE .......................................................... 119

APPENDICE X3 STRUMENTI DI FILTRO DI IDONEITÀ AGILI ................................................................................ 125

RIFERIMENTI .............................................................................................................................. 139

BIBLIOGRAFIA ............................................................................................................................ 141

GLOSSARIO ................................................................................................................................. 149

INDEX ......................................................................................................................................... 157

IV Sommario

ELENCO DELLE TABELLE E DELLE FIGURE

Figura 2-1. I quattro valori dell’Agile Manifesto ................................................................... 8

Figura 2-2. I dodici principi alla base dell’Agile Manifesto .................................................. 9

Figura 2-3. La relazione tra i valori, i principi e le pratiche comuni dell’Agile Manifesto ........................................................................................... 10

Figura 2-4. Agile è un termine generico per molti approcci ............................................... 11

Figura 2-5. Incertezza e modello di complessità ispirato al Modello della complessità di Stacey .............................................................................. 14

Figura 3-1. Il continuum dei cicli di vita .............................................................................. 19

Figura 3-2. Ciclo di vita predittivo ....................................................................................... 21

Figura 3-3. Ciclo di vita iterativo .......................................................................................... 21

Figura 3-4. Un ciclo di vita con incrementi di varie dimensioni ......................................... 22

Figura 3-5. Cicli di vita agili Iteration-Based e Flow-Based ............................................... 24

Figura 3-6. Sviluppo agile seguito da un’implementazione predittiva ............................... 27

Figura 3-7. Un approccio agile e uno predittivo combinati e utilizzati simultaneamente ............................................................................. 27

Figura 3-8. Un approccio significativamente predittivo con componenti agili .................. 28

Figura 3-9. Un approccio significativamente agile con una componente predittiva ............ 28

Figura 5-1. Grafico burn-down per gli story point rimanenti ............................................. 62

Figura 5-2. Grafico burn-up che mostra gli story point completati ................................... 63

Figura 5-3. Esempio di una lavagna Kanban ....................................................................... 65

Figura 5-4. Grafico delle funzionalità .................................................................................. 67

Figura 5-5. Grafico burn-up del product backlog ............................................................... 68

V

Figura 5-6. Earned Value in un contesto agile .................................................................... 69

Figura 5-7. Diagramma di flusso cumulativo delle funzionalità completate ..................... 70

Figura 6-1. La relazione tra la gestione del cambiamento e gli approcci agili .................. 72

Figura 6-2. Esempio di valutazione della cultura dell'organizzazione ............................... 76

Figura 6-3. Backlog iniziale prioritizzato delle azioni di cambiamento ............................. 85

Figura 6-4. Uso dei backlog e delle lavagne kanban per organizzare e monitorare le azioni di cambiamento. ........................................................... 86

Figura A3-1. Approcci agili rappresentati per ampiezza e profondità ............................... 100

Figura A3-2. Lavagna Kanban che mostra i limiti del lavoro in corso e un sistema pull per ottimizzare il flusso di lavoro ...................................... 105

Figura A3-3. Metodologie Crystal ......................................................................................... 106

Figura A3-4. Ciclo di vita del progetto Feature-Driven Development ................................. 109

Figura A3-5. Approccio DSDM all’agilità guidata da vincoli ............................................... 110

Figura A3-6. Rappresentanti dei gruppi Scrum che partecipano a gruppi SoS ................. 112

Figura X3-1. Modello di idoneità dell’approccio agile......................................................... 127

Figura X3-2. Valutazione del supporto (buy-in) all’approccio ............................................ 129

Figura X3-3. Valutazione della fiducia nel team .................................................................. 130

Figura X3-4. Valutazione del potere decisionale del team .................................................. 130

Figura X3-5. Valutazione delle dimensioni del team ........................................................... 131

Figura X3-6. Valutazione del livello di esperienza .............................................................. 131

Figura X3-7. Valutazione dell’accesso al cliente/all’azienda ............................................. 132

Figura X3-8. Valutazione della probabilità di modifiche ..................................................... 132

Figura X3-9. Valutazione della criticità di un prodotto o servizio ...................................... 133

Figura X3-10. Valutazione del rilascio incrementale ............................................................ 133

Figura X3-11. Diagramma di Kiviat (grafico radar) di valutazione dell’idoneità .................... 134

Figura X3-12. Progetto della farmacia ................................................................................... 135

Figura X3-13. Esempio del sistema di messaggistica militare ............................................. 137

VI Elenco delle tabelle e delle figure

Tabella 1-1. Voci incluse ed escluse ....................................................................................... 4

Tabella 3-1. Caratteristiche delle quattro categorie di cicli di vita ...................................... 18

Tabella 3-2. Opzioni di personalizzazione per migliorare la compatibilità ......................... 32

Tabella 4-1. Attributi di team agili di successo .................................................................... 40

Tabella 4-2. Ruoli dei team agili ............................................................................................ 41

Tabella 5-1. Punti deboli dell’agile e possibilità di risoluzione dei problemi ...................... 58

Tabella A1-1. Gruppo di processi di Project Management e mappatura delle aree di conoscenza ................................................................................... 90

Tabella A1-2. Applicazione di Agile nelle aree di conoscenza della Guida PMBOK®............. 91

Tabella A2-1. I valori dell’Agile Manifesto trattati nella Guida alle Pratiche dell’Agile ............ 97

Tabella A2-2. Mappatura dei principi dell’Agile Manifesto nella Guida alle Pratiche dell’Agile ............................................................................................................ 98

Tabella A3-1. Eventi ed elaborati Scrum ............................................................................... 101

Tabella A3-2. Le pratiche di eXtreme Programming ............................................................. 102

Tabella A3-3. Principi fondamentali e proprietà del metodo Kanban .................................. 104

Tabella A3-4. I valori cardine e le proprietà comuni di Crystal ............................................ 107

Tabella A3-5. I principali elementi dell’Agile Unified Process .............................................. 111

Tabella A3-6. Confronto tra LeSS e Scrum ............................................................................ 113

Tabella X2-1. Linee guida per la personalizzazione ............................................................. 121

VII

1

1INTRODUZIONE

Benvenuti alla Guida alle Pratiche dell’Agile. Questa guida è frutto della collaborazione tra il Project Management Institute (PMI) e l’Agile Alliance®. I membri del gruppo centrale di redazione che hanno sviluppato questa guida pratica comprendono volontari di entrambe le organizzazioni, con esperti in materia scelti tra un’ampia gamma di professionisti e leader con diverse formazioni, credenze e culture.

Questa guida fornisce indicazioni pratiche rivolte a leader di progetto e membri del team che si adattano a un approccio agile nella pianificazione e nell’esecuzione dei progetti. Il nostro gruppo centrale di redazione riconosce che l’uso di approcci predittivi gode di ampio riconoscimento, ma è consapevole anche del diffuso interesse a passare a mentalità, valori e principi agili: questa guida illustra un approccio pratico all’agilità di progetto e rappresenta un ponte per comprendere il percorso da seguire per passare da un approccio predittivo a uno agile. In realtà, tra i due approcci vi sono attività simili, come ad esempio la pianificazione, che sono gestite in modo diverso ma si verificano in entrambi gli ambienti.

Il nostro gruppo centrale di redazione ha utilizzato una mentalità agile per collaborare e gestire lo sviluppo di questa prima edizione della guida. Man mano che la tecnologia e la cultura cambieranno, i futuri aggiornamenti e perfezionamenti di questa guida rifletteranno gli approcci correnti.

Il nostro gruppo centrale di redazione ha adottato uno stile di scrittura più informale e rilassato per questa guida pratica rispetto ai tipici standard del PMI. La guida integra nuovi elementi, quali suggerimenti, barre laterali e casi di studio per illustrare al meglio i punti e i concetti principali. L’obiettivo del nostro gruppo è, attraverso tali modifiche, rendere questa guidapiù leggibile e di facile utilizzo.

Poiché l’Agile si è diffuso in contesti diversi, la guida non si limita a indirizzare il tema dell’Agile nel settore dello sviluppo software. Industria manifatturiera, istruzione, sanità e altri settori stanno diventando più agili in misure diverse e quindi il perimetro della presente guida si estende oltre l’industria del software.

2 Sezione 1

Quindi, perché una Guida alle Pratiche dell’Agile e perché ora? I team di progetto adottano tecniche e approcci agili in varie forme da diversi decenni. L’Agile Manifesto [1]1 esprimeva valori e principi Agile autorevoli in un momento in cui il suo uso aveva acquisito uno slancio sostanziale (vedere la Sezione 2.1). Oggi, leader e team di progetto si trovano ad operare in un ambiente turbato da progressi tecnologici esponenziali e da clienti che richiedono un rilascio di valore sempre più anticipato. Le tecniche e gli approcci agili sono in grado digestire in modo efficace le tecnologie più dirompenti. Inoltre, il primo principio dell’Agile identifica la soddisfazione del cliente quale massima priorità: è quindi essenziale fornire prodotti e servizi in grado di soddisfare pienamente i clienti (vedere la Sezione 2.1). Grazie al diffuso uso dei social media, sono immediatamente disponibili cicli rapidi e trasparenti di gestione dei feedback dei clienti. Di conseguenza, per restare competitivi e contestualizzati, le organizzazioni non possono più restare focalizzate solo internamente, ma hanno invece bisogno di aprirsi verso l’esterno concentrandosi sulla customer experience.

1 I numeri tra parentesi rimandano all’elenco di riferimenti nella parte finale della presente guida.

APPRENDIMENTO AGILE-BASED

L’istruzione è terreno fertile e di primaria importanza per espandere le pratiche agili oltre lo sviluppo software. Gli insegnanti delle scuole medie, superiori e delle università in tutto il mondo stanno iniziando a utilizzare l’Agile per creare una diversa cultura di apprendimento. Le tecniche agili sono utilizzate per concentrarsi sulle priorità in caso di conflitti tra le stesse. Interazioni faccia a faccia, apprendimento significativo, gruppi auto-organizzati e apprendimento incrementale e/o iterativo, che sfruttano l’immaginazione, sono tutti principi agili che possono modificare la mentalità in aula e far progredire gli obiettivi educativi (Briggs, 2014).*

*Briggs, Sara. “Agile Based Learning: What Is It and How Can It Change Education?” Opencolleges.edu.au 22 febbraio 2014, recuperato da http://www.opencolleges.edu.au/informed/features/agile-based-learning-what-is-it-and-how-can-it-change-education/

3

Tecnologie dirompenti stanno modificando rapidamente le regole del gioco, riducendo le barriere all’ingresso. Le organizzazioni più mature tendono sempre più a un’alta complessità e sono potenzialmente lente ad abbracciare l’innovazione, rischiando di restare indietro nel fornire nuove soluzioni ai loro clienti. Queste organizzazioni si ritrovano in competizione con aziende e start-up più piccole che sono in grado di produrre rapidamente prodotti che soddisfano le esigenze dei clienti. Questa velocità di cambiamento continuerà a spingere le grandi organizzazioni ad adottare una mentalità agile per restare competitive e mantenere la propria quota di mercato.

La Guida alle Pratiche dell’Agile si incentra sui progetti e si occupa della selezione del ciclo di vita del progetto, dell’implementazione agile e di considerazioni organizzative per i progetti agili. La gestione del cambiamento organizzativo (OCM) è essenziale per l’implementazione o la trasformazione delle pratiche ma, dal momento che OCM è una disciplina in sé, non rientra nell’ambito di questa guida. Chi cerca indicazioni sull’OCM può fare riferimento a Managing Change in Organizations— A Practice Guide [2].

Le voci aggiuntive che rientrano o meno nel campo di applicazione della presente guidasono elencate nella Tabella 1-1.

TECNOLOGIE DIROMPENTI

Le tecnologie dirompenti sono particolarmente favorite dalla transizione al cloud computing. Le aziende di tutto il mondo stanno sfruttando questo modello per un accesso rapido ed economico alle risorse informatiche e per entrare nei mercati tradizionali. Il cloud computing richiede minori pagamenti anticipati, ma si ripaga nel tempo attraverso servizi di sottoscrizione, basati su un modello di pagamento al consumo o secondo le funzioni utilizzate. Applicazioni, infrastrutture e piattaforme aggiornate vengono rilasciate nel cloud in modo iterativo e incrementale, al passo con i miglioramenti della tecnologia e la domanda dei clienti in costante evoluzione.

4 Sezione 1

Tabella 1-1. Voci incluse ed escluse

In ambito Fuori ambito

Implementare approcci agili a livello di progetto o di team

Copertura degli approcci agili più diffusi, come elencato nei sondaggi di settore

Fattori di idoneità da considerare quando si sceglie un approccio e/o una pratica agile

Mappatura dell’Agile sui processi e le aree di conoscen-za della Guida PMBOK®

Discussione sull’uso dell’Agile in settori diversi dallo sviluppo software

Indicazioni, tecniche e approcci da prendere in consider-azione quando si implementa l’agile in progetti od organizzazioni

Definizioni dei termini generalmente accettati

Implementing agile throughout the organization or creating agile programs

Copertura di approcci di nicchia, metodi aziendali specifici o tecniche incomplete di gestione del ciclo di vita

Raccomandazione o sostegno di un approccio/una pratica particolari

Cambiamenti o modifiche dei processi e/o le aree di conoscenza della Guida PMBOK®

Eliminazione dell’influenza del settore software sugli approcci agili (si osservi che il settore del software è referenziato in questa guida sebbene l’uso dell’Agile si stia diffondendo in molti altri settori diversi da quello del software).

Istruzioni prescrittive dettagliate su come implementare l’Agile in progetti od organizzazioni

Nuovi termini e/o definizioni

Questa guida si rivolge ai team di progetto che si trovano nella difficile situazione di essere a metà strada tra approcci predittivi e agili, che cercano di indirizzare una rapida innovazione e complessità, e che sono dedicati al miglioramento del team stesso. Fornisce utili indicazioni per il successo di progetti che producono valore al fine di soddisfare le aspettative e le esigenze del cliente.

5

La presente guida è organizzata come segue:

Sezione 2 Introduzione all’Agile—Questa sezione illustra la mentalità, i valori e i principi dell’Agile Manifesto. Tratta anche i concetti di lavoro sia definibile che a elevata incertezza e la correlazione tra Lean, il metodo Kanban e approcci agili.

Sezione 3 Selezione del ciclo di vita—Questa sezione presenta i vari cicli di vita trattati nella presente guida. Questa sezione si occupa inoltre di filtri di idoneità, linee guida per la personalizzazione e tipiche combinazioni di approcci.

Sezione 4 Implementazione di Agile: Creare un ambiente Agile—Questa sezione analizza i fattori critici da considerare quando si crea un ambiente agile quali Servant Leadership e composizione del team.

Sezione 5 Implementazione di Agile: Rilascio in un ambiente Agile—Questa sezione include informazioni su come organizzare i team e le pratiche comuni che i team possono utilizzare per generare valore con continuità. Fornisce esempi di misurazioni empiriche sui team e sul di reporting di andamento.

Sezione 6 Considerazioni organizzative sull’agilità nei progetti—Questa sezione esplora i fattori organizzativi che influenzano l’uso di approcci agili quali cultura, prontezza, pratiche aziendali e il ruolo di un PMO.

Sezione 7 Call to Action—La sezione Call to Action si propone diraccogliere input per il continuo miglioramento di questa guida.

Gli allegati, le appendici, i riferimenti, la bibliografia e il glossario forniscono definizioni e informazioni utili:

uu Allegati. Contengono informazioni obbligatorie troppo lunghe da includere nel corpo principale della guida.

uu Appendici. Contengono informazioni non obbligatorie che integrano il corpo principale di questa guida.

uu Riferimenti. Indicano dove reperire standard e altre pubblicazioni citate in questa guida.

uu Bibliografia. Elenca pubblicazioni aggiuntive per sezione che forniscono informazioni dettagliate su argomenti trattati nella presente guida.

uu Glossario. Presenta un elenco di termini e relative definizioni utilizzate nella presente guida.

7

2INTRODUZIONE ALL’AGILE

2.1 LAVORO DEFINIBILE VS. LAVORO A ELEVATA INCERTEZZA

Il lavoro di progetto spazia da lavoro definibile a lavoro a elevata incertezza. I progetti con lavoro definibile sono caratterizzati da procedure chiare che si sono dimostrate di successo in progetti simili nel passato. La costruzione di un’auto, di apparecchiature elettriche o di una casa dopo il completamento della progettazione sono esempi di lavoro definibile. Il campo della produzione e i processi in essa coinvolti sono solitamente ben compresi e presentano generalmente bassi livelli di incertezza di esecuzione e di rischio.

Nuove progettazioni, risoluzione di problemi e lavori mai svolti in precedenza sono esempi di lavoro esplorativo. Richiedono la collaborazione di esperti in materia per risolvere problemi e trovare una soluzione. Tra le persone che si trovano ad affrontare lavori a elevata incertezza si annoverano ingegneri di sistemi software, progettisti di prodotti, medici, insegnanti, avvocati e molti ingegneri che si occupano di risoluzione dei problemi. Dal momento che il lavoro più definibile è automatizzato, i team di progetto si occupano perlopiù di progetti con lavoro a elevata incertezza, che richiedono le tecniche descritte in questa guida.

I progetti a elevata incertezza hanno alti tassi di cambiamento, complessità e rischio. Queste caratteristiche possono generare problemi ai tradizionali approcci predittivi, che mirano a determinare anticipatamente gran parte dei requisiti e che tengono sotto controllo i cambiamenti attraverso un processo di richiesta di modifica. Al contrario, gli approcci agili sono stati creati per esplorare la fattibilità in cicli brevi e adattarsi rapidamente sulla base di valutazioni e feedback.

8 Sezione 2

2.2 L’AGILE MANIFESTO E LA MENTALITÀ AGILE

I leader di pensiero nel settore software hanno formalizzato il movimento agile nel 2001 con la pubblicazione del Manifesto per lo sviluppo agile del software (vedere la Figura 2-1).

Figura 2-1. I quattro valori dell’Agile Manifesto

Stiamo scoprendo modi migliori per sviluppare il software lavorandoci e aiutando gli altri a farlo. Attraverso questo lavoro abbiamo imparato ad apprezzare:

Individui e interazioni rispetto a processi e strumenti

Software funzionante rispetto a documentazione completa

Collaborazione con il cliente rispetto a negoziazione dei contratti

Risposta al cambiamento rispetto a seguire un piano

Intendiamo dire che mentre riconosciamo che esiste valore nelle voci a destra, apprezziamo maggiormente le voci a sinistra.

© 2001, autori dell’Agile Manifesto

9

Da questi valori sono stati derivati dodici principi chiarificatori come mostrato nella Figura 2-2.

Figura 2-2. I dodici principi alla base dell’Agile Manifesto

1. La nostra principale priorità è soddisfare il cliente attraverso un rilascio anticipato e continuo di software di valore.

2. I cambiamenti dei requisiti, anche nelle ultime fasi di sviluppo, sono ben accetti. I processi Agile sfruttano il cambiamento in nome del vantaggio competitivo del cliente.

3. Rilasciare frequentemente software funzionante, da un paio di settimane a un paio di mesi, con preferenza per una tempistica più ridotta.

4. I referenti aziendali e gli sviluppatori devono collaborare quotidianamente nel corso del progetto.

5. Costruire progetti attorno a individui motivati. Dare loro l’ambiente e il supporto di cui hanno bisogno e fidarsi di loro per ottenere che il lavoro venga svolto.

6. Il modo più efficiente ed efficace di trasmettere informazioni all’interno di un team di sviluppo è la conversazione faccia a faccia.

7. Il software funzionante è la principale misura dell’avanzamento.

8. I processi Agile promuovono lo sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti devono poter mantenere un ritmo costante di lavoro indefinitamente.

9. La continua attenzione all’eccellenza tecnica e alla buona progettazione potenzia l’agilità.

10. La semplicità - l’arte di massimizzare la quantità di lavoro non svolto - è essenziale.

11. I migliori requisiti, architetture e progettazioni nascono da team auto-organizzati.

12. A intervalli regolari, il team riflette su come diventare più efficace, quindi calibra e adegua di conseguenza il proprio comportamento.

10 Sezione 2

Sebbene originari del settore software, questi principi si sono da allora diffusi a molti altri settori.

L’insieme di mentalità, valori e principi definisce un approccio agile. I vari approcci agili attualmente in uso condividono radici comuni con la mentalità, i valori e i principi agili originari. Questa relazione è mostrata nella Figura 2-3.

Figura 2-3. La relazione tra i valori, i principi e le pratiche comuni dell’Agile Manifesto

Come mostrato nella Figura 2-3, il modello - ispirato da Ahmed Sidky - descrive l’Agile come mentalità definita dai valori dell’Agile Manifesto, guidata dai principi dell’Agile Manifesto e abilitata da varie pratiche. Si sottolinea che, sebbene il termine “agile” sia diventato popolare dopo il Manifesto, gli approcci e le tecniche utilizzati oggi dai team di progetto esistevano già da molti anni e, in alcuni casi, decenni prima dell’Agile Manifesto.

L’Agile è una mentalità definita da valori, guidata da principi ed espressa da molte pratiche diverse. I professionisti dell’Agile scelgono le pratiche in base alle loro esigenze.

4 valori 12 principi PraticheMentalitàAgile

11

Figura 2-4. Agile è un termine generico per molti approcci

Gli approcci agili e i metodi agili sono termini onnicomprensivi che coprono una varietà di schemi di riferimento e metodi. La Figura 2-4 contestualizza l’agile e lo visualizza come un termine generico che si riferisce a qualsiasi tipo di approccio, tecnica, schema di riferimento, metodo o pratica che soddisfi i valori e i principi dell’Agile Manifesto. La Figura mostra anche l’Agile e il metodo Kanban come sottoinsiemi di Lean. Ciò è dovuto al fatto che si tratta di istanze identificate del pensiero lean che condividono concetti lean quali: “focus sul valore”, “piccoli lotti” ed “eliminazione degli sprechi”.

AgileKanban

Scrum

Crystal

ScrumBan

AUP

FDDXP

DSDM

Lean

L’Agile è un approccio, un metodo, una pratica, una tecnica o uno schema di riferimento? Nessuno o tutti questi termini sono applicabili a seconda della situazione. Questa guida utilizza il termine “approccio” a meno che uno degli altri termini sia evidentemente più corretto.

12 Sezione 2

In generale, sono due le strategie per soddisfare i valori e i principi agili. La prima consiste nell’adottare un approccio agile formale, intenzionalmente studiato e dimostratosi valido per garantire i risultati desiderati. Poi ci si prende del tempo per apprendere e comprendere gli approcci agili adottati, prima di cambiarli o personalizzarli. Una personalizzazione prematura e approssimativa può ridurre significativamente gli effetti dell’approccio e quindi limitarne i benefici (vedere l’Appendice X2 per considerazioni sulla personalizzazione).

La seconda strategia consiste nell’implementare cambiamenti alle pratiche del progetto in modo adeguato al contesto, per ottenere progressi su un valore centrale o un principio fondante. Utilizzare intervalli a tempo fisso per creare funzionalità o tecniche specifiche per affinare iterativamente le funzionalità. Prendere in considerazione la divisione di un progetto grande in vari rilasci se ciò si adatta al contesto specifico del progetto. Implementare cambiamenti che favoriranno il successo del progetto: i cambiamenti non devono necessariamente riguardare le procedure formali dell’organizzazione. L’obiettivo finale non è essere agili in sé ma piuttosto generare un flusso continuo di valore per i clienti e raggiungere migliori risultati.

2.3 LEAN E IL METODO KANBAN

Un modo per pensare alla relazione tra Lean, Agile e il metodo Kanban è considerare Agile e il metodo Kanban come discendenti dal pensiero Lean. In altre parole, il pensiero Lean è un insieme più ampio che condivide attributi con Agile e Kanban.

Questo patrimoniocondiviso si incentra sulla generazione di valore, sul rispetto per le persone, sulla riduzione al minimo degli sprechi, sulla trasparenza, sull’adattamento al cambiamento e sul miglioramento continuo. Talvolta i team di progetto trovano utile adottare contemporaneamente vari metodi: si deve fare qualunque cosa funzioni per l’organizzazione o il team, indipendentemente dalla sua origine. L’obiettivo è conseguire il miglior risultato indipendentemente dall’approccio utilizzato.

Il metodo Kanban si ispira all’originale sistema di controllo della produzione lean ed è utilizzato appositamente nel lavoro basato sulla conoscenza. È emerso a metà degli anni 2000 come alternativa ai metodi agili, all’epoca prevalenti.

13

Il metodo Kanban è meno prescrittivo rispetto ad alcuni approcci agili e meno rivoluzionario poiché prevede l’approccio originale “comincia da dove sei”. I team di progetto possono iniziare ad applicare il metodo Kanban con relativa facilità e progredire verso altri approcci agili se lo ritengono necessario o appropriato. Per maggiori dettagli sul metodo Kanban vedere l’Allegato A3 sulla Panoramica degli schemidi riferimento Agili e Lean.

2.4 INCERTEZZA, RISCHIO E SCELTA DEL CICLO DI VITA

Alcuni progetti si contraddistinguono per una considerevole incertezza dei requisiti di progetto e su come soddisfare tali requisiti utilizzando la conoscenza e la tecnologia attuali. Queste incertezze possono determinare alti tassi di cambiamento e di complessità del progetto. Tali caratteristiche sono illustrate nella Figura 2-5.

Man mano che l’incertezza del progetto aumenta, lo stesso accade per il rischio di rilavorazione e per la necessità di adottare un approccio differente. Per mitigare l’impatto di tali rischi, i team scelgono i cicli di vita che consentono loro di gestire i progetti a elevata incertezza attraverso piccoli incrementi del lavoro.

Quando utilizzano piccoli incrementi, i team possono verificare il proprio lavoro e modificare i passi successivi. Quando i team generano piccoli incrementi, sono in grado di comprendere meglio i veri requisiti del cliente e di farlo in modo più rapido e preciso rispetto all’uso di specifiche scritte statiche.

CA

SO Si discute e probabilmente si discuterà sempre del metodo Kanban e se appartenga al

Lean o al movimento Agile. È stato concepito all’interno e attorno alla produzione Lean ma è ampiamente utilizzato in contesti agili.

14 Sezione 2

Ince

rtez

za d

ei re

quis

iti

Elev

ata

ince

rtez

zaBa

ssa

ince

rtez

za

Grado di incertezza tecnico

Bassa incertezza Elevata incertezza

Fondamentalmente rischioso

Gli approcci adattativi funziona-

no bene inquesto caso

Gli approcci lineari funzionano benein questo caso

Complicato

Complesso

Caos

Semplice

Figura 2-5. Incertezza e modello di complessità ispirato al Modello della complessità di Stacey

I team possono pianificare e gestire con poca difficoltà progetti che presentano requisiti stabili e chiari e sfide tecniche conosciute,. Tuttavia, man mano che l’incertezza nel progetto aumenta, cresce anche la probabilità di cambiamenti, di lavoro sprecato e di rilavorazione, dispendiosi in termini di tempo e di denaro.

15

Alcuni team hanno evoluto i cicli di vita del progetto verso approcci iterativi e incrementali. Molti team scoprono che, quando esplorano i requisiti in modo iterativo e procedono a rilasci incrementali più frequenti, si adattano ai cambiamenti più facilmente. Questi approcci iterativi e incrementali riducono gli sprechi e la rilavorazione perché i team possono contare su feedback. Questi approcci utilizzano:

uu Cicli di feedback molto brevi,

uu Frequente adeguamento dei processi,

uu Riassegnazione delle priorità,

uu Aggiornamento regolare dei piani e

uu Rilascio frequente.

SU

GG

ERIM

ENTO

Cosa significano progetti semplici, complicati e complessi? Si prendano in considerazione grandi progetti, come il progetto di costruzione chiamato Boston Big Dig (o Grande Scavo). A prima vista il progetto sembrava piuttosto semplice: spostare l’autostrada sopraelevata in un tunnel. Il livello di accordo sui requisiti era elevato (vedere l’asse Y nella Figura 2-5). Vi era scarsa incertezza su come il progetto sarebbe andato avanti fino a che non iniziò. Come accade per molti progetti di grandi dimensioni, il progetto incontrò delle sorprese lungo il percorso.

Quando il team lavora su un progetto in cui vi è scarsa opportunità di creare deliverable intermedi o prototipi, esso probabilmente adotterà un ciclo di vita predittivo per gestire il progetto. Il team può adattarsi a ciò che scopre, ma non sarà in grado di utilizzare approcci agili per gestire i requisiti scoperti iterativamente o i deliverable incrementali destinati alla raccolta di feedback.

Il progetto Big Dig non è stato assolutamente semplice. Tuttavia, molti progetti che si collocano inizialmente nella parte inferiore sinistra del Modello della Complessità di Stacey non hanno mezzi reali per passare ad altri approcci. Va valutato il progetto, sia da un punto di vista dei requisiti che nelle sue modalitàdi rilascio, per determinare il miglior approccio al ciclo di vita da adottare.

16 Sezione 2

Questi approcci iterativi, incrementali e agili funzionano bene per progetti che hanno a che fare con nuovi strumenti, tecniche, materiali o campi di applicazione (fare riferimento alla Sezione 3 sulla Selezione del ciclo di vita). Funzionano bene anche per i progetti che:

uu Richiedono ricerca e sviluppo;

uu Hanno alti tassi di cambiamento;

uu Hanno requisiti poco chiari o ignoti, incertezza o rischio, o

uu Hanno un obiettivo finale difficile da descrivere.

Creando un piccolo incremento e poi testandolo e rivedendolo, il team può esplorare l’incertezza a basso costo e in breve tempo, ridurre il rischio e massimizzare il valore. Questa incertezza può riferirsi ad appropriatezza e requisiti (si sta realizzando il prodotto giusto?), alla fattibilità tecnica e alle prestazioni (questo prodotto può essere costruito in questo modo?) o al processo e alle persone (è un modo efficace di lavorare per il team?). Tutte e tre queste caratteristiche - specifiche del prodotto, capacità di produzionee idoneità del processo - hanno solitamente elementi di alta incertezza.

Tuttavia, gli approcci iterativi e incrementali hanno propri limiti di applicabilità. Quando sia l’incertezza tecnologica che quella legata ai requisiti sono molto elevate (la parte superiore destra della Figura 2-5), il progetto va oltre la complessità e diventa caotico. Affinché il progetto diventi attendibilmente fattibile, una delle variabili di incertezza deve essere limitata.

17

3SELEZIONE DEL CICLO DI VITA

I progetti possono assumere varie forme ed esistono diversi modi per affrontarli. I team di progetto devono essere consapevoli delle peculiarità del progetto e delle opzioni gestionali disponibili per selezionare l’approccio prevedibilmente migliore per il successo del progetto in base alla situazione.

Questa guida fa riferimento a quattro tipi di cicli di vita, definiti come segue:

uu Ciclo di vita predittivo. Un approccio più tradizionale, con la maggior parte della pianificazione svolta in anticipo, poi l’esecuzione avviene in un unico passaggio; un processo sequenziale.

uu Ciclo di vita iterativo. Un approccio che consente che feedback sul lavoro non ancora completato, possano migliorarlo e modificarlo e.

uu Ciclo di vita incrementale. Un approccio che fornisce deliverable finiti che il cliente può utilizzare immediatamente.

uu Ciclo di vita agile. Un approccio al tempo stesso iterativo e incrementale per perfezionare parti di lavoro e consentire rilasci frequenti.

COME CHIAMARE GLI APPROCCI NON AGILI?

Non esiste un unico termine universalmente utilizzato per descrivere gli approcci non agili. Inizialmente, la guida utilizzava il termine plan-driven per rappresentare l’enfasi posta su un piano anticipato e sulla conseguente esecuzione. Alcuni preferiscono i termini waterfall (a cascata) o seriale per descrivere questo ciclo di vita. Alla fine, abbiamo optato per il termine predittivo poiché è utilizzato in A Guide to the Project Management Body of Knowledge (Guida PMBOK®) [3] e nella Software Extension to the PMBOK® Guide Fifth Edition [4].

Molte organizzazioni non adottano nessuno di questi estremi e occupano posizioni intermedie. Ciò è naturale, ma occorre comunque trovare un modo per parlare di entrambe le estremità dello spettro. Se un estremo è agile, l’altro estremo è predittivo.

18 Sezione 3

3.1 CARATTERISTICHE DEI CICLI DI VITA DEL PROGETTO

La Tabella 3-1 riassume le caratteristiche delle quattro categorie di cicli di vita trattate in questa guida.

Tabella 3-1. Caratteristiche delle quattro categorie di cicli di vita

È importante notare che tutti i progetti presentano queste caratteristiche: nessun progetto è completamente privo di considerazioni riguardanti requisiti, rilasci, cambiamenti e obiettivi. Le caratteristiche intrinseche di un progetto determinano il miglior ciclo di vita per il progetto in questione.

Un altro modo per comprendere come variano i cicli di vita del progetto è quello di utilizzare un intervallo continuo che va dai cicli predittivi a un’estremità ai cicli agili all’altra estremità, con cicli più iterativi o incrementali al centro.

La Figura X3-1 dell’Appendice X3 della Guida PMBOK® – Sesta edizione mostra il continuum come una linea piatta. Questa rappresentazione enfatizza lo spostamento delle caratteristiche di un progetto da un’estremità all’altra. Un altro modo per visualizzare il continuum è con un quadrato bidimensionale, come mostrato nella Figura 3-1.

Requisiti Attività Rilascio ObiettivoApproccio

Caratteristiche

Predittivo

Iterativo

Incrementale

Agile

Fisso

Dinamico

Dinamico

Dinamico

Eseguite una volta per l’intero progetto

Ripetute fino a quando si ottiene un risultato corretto

Eseguite una sola volta per un determinato incremento

Ripetute fino a quando si ottiene un risultato corretto

Singolo rilascio

Singolo rilascio

Rilasci più piccoli e frequenti

Rilasci piccoli e frequenti

Gestire i costi

Correttezza della soluzione

Velocità

Valore per il cliente attraverso rilasci e feedback frequenti

19

Figura 3-1. Il continuum dei cicli di vita

Nessun ciclo di vita può essere la soluzione ottimale per tutti i progetti. Al contrario, ogni progetto si posiziona in un punto del continuum che rappresenta il bilanciamento ottimale delle caratteristiche in riferimento al suo contesto. Nello specifico,

uu Cicli di vita predittivi. Sfruttano elementi noti e comprovati. Queste incertezze e complessità ridotte, consentono ai team di scomporre il lavoro in una sequenza di blocchi prevedibili.

uu Cicli di vita iterativi. Consentono la raccolta di feedback sul lavoro non ancora completato al fine di migliorarlo e modificarlo.

uu Cicli di vita incrementali. Forniscono deliverable finiti che il cliente può utilizzare immediatamente.

uu Cicli di vita agili. Sfruttano sia le caratteristiche iterative che quelle incrementali. Quando i team utilizzano approcci agili, reiterano lo sviluppo del prodotto per creare deliverable finiti. Il team riceve feedback anticipati e genera visibilità per il cliente, fiducia e controllo sul prodotto. Dal momento che il team è in grado di effettuare rilasci progressivi, il progetto può fornire un ritorno anticipato sull’investimento in quanto il team rilascia prima di tutto il lavoro di massimo valore.

Freq

uenz

a di

rila

scio

Bass

oAl

to

Grado di cambiamento

Predittivo

Incrementale

Iterativo

Agile

Basso Alto

Continuum

20 Sezione 3

3.1.1 CARATTERISTICHE DEI CICLI DI VITA PREDITTIVI

I cicli di vita predittivi prevedono di poter sfruttare l’elevata certezza determinata da requisiti consolidati, team stabili e basso livello di rischio. Di conseguenza, le attività di progetto spesso si svolgono in modo seriale, come mostrato nella Figura 3-2.

Per adottare questo approccio, il team ha bisogno di piani dettagliati per comprendere cosa rilasciare e come. Questi progetti hanno successo quando altri potenziali cambiamenti vengono limitati (ad es, cambiamenti dei requisiti o dei deliverable da parte dei membri del team). I team leader mirano a minimizzare i cambiamenti per i progetti predittivi.

Quando il team crea requisiti e piani dettagliati all’inizio del progetto, può articolare l’insieme dei vincoli. Il team può quindi utilizzare tali vincoli per gestire rischi e costi. Man mano che il team procede secondo il piano di dettaglio, monitora e controlla i cambiamenti che potrebbero influenzare l’ambito, la schedulazione o il budget.

Enfatizzando una sequenza di lavoro serializzata ed efficiente a livello di dipartimento, i progetti predittivi solitamente non forniscono valore prima della fine del progetto. Se il progetto predittivo si imbatte in cambiamenti o disaccordi riguardo ai requisiti, o se la soluzione tecnologica si complica, andrà incontro a costi imprevisti.

LA PIANIFICAZIONE È SEMPRE ESSENZIALE

È fondamentale ricordare che ogni ciclo di vita condivide l’elemento della pianificazione. Ciò che differenzia un ciclo di vita non è lo svolgimento o meno della pianificazione ma la relativa entità e tempistica.

All’estremità predittiva del continuum, è il piano a guidare il lavoro. La maggior parte della pianificazione si svolge per quanto possibile in anticipo. I requisiti vengono identificati nel modo più dettagliato possibile. Il team effettua una stima di quando potrà rilasciare determinati deliverable e svolge tutte le necessarie attività di approvvigionamento.

Negli approcci iterativi, vengono pianificati anche prototipi e prove, ma gli output che ne derivano sono finalizzati a modificare i piani inizialmente creati. Revisioni intermedie del lavoro non ancora completato contribuiscono a migliorare il lavoro futuro del progetto.

Iniziative incrementali, invece, mirano a fornire in progressione parti del progetto complessivo. I team possono pianificare più rilasci successivi in anticipo, oppure solo uno alla volta. I rilasci forniscono informazioni per il lavoro futuro del progetto.

Anche i progetti agili prevedono una pianificazione. La differenza principale è che il team pianifica e ripianifica man mano che diventano disponibili maggiori informazioni a seguito della revisione dei frequenti rilasci. Indipendentemente dal ciclo di vita, il progetto richiede una pianificazione.

21

Figura 3-2. Ciclo di vita predittivo

3.1.2 CARATTERISTICHE DEI CICLI DI VITA ITERATIVI

I cicli di vita iterativi migliorano il prodotto o risultato attraverso prototipi o dimostrazioni pratiche successivi. Ogni nuovo prototipo produce nuovi feedback da parte degli stakeholder e fa emergere nuovi approfondimenti del team. Il team integra quindi le nuove informazioni ripetendo una o più attività di progetto nel ciclo successivo. I team possono utilizzare la scomposizione in intervalli di tempo fissi su una determinata iterazione per alcune settimane, acquisire approfondimenti e quindi rilavorare l’attività in base ad essi. In tal modo, le iterazioni contribuiscono a identificare e ridurre l’incertezza del progetto.

I progetti beneficiano di cicli di vita iterativi quando la complessità è elevata, il progetto incorre in cambiamenti frequenti o quando l’ambito è soggetto alle visioni contrastanti degli stakehoder rispetto al prodotto finale desiderato. I cicli di vita iterativi possono richiedere tempi più lunghi poiché sono ottimizzati per facilitare l’apprendimento più che per assicurare la velocità di rilascio.

La Figura 3-3 illustra alcuni elementi di un ciclo di vita del progetto iterativo per un singolo rilascio di un prodotto.

Figura 3-3. Ciclo di vita iterativo

Analisi Progettazione Realizzazione Test Rilascio

AnalisiAnalisi

Progettazione

Prototipazione Perfezionamento

Realizzazione

TestRilascio

22 Sezione 3

3.1.3 CARATTERISTICHE DEI CICLI DI VITA INCREMENTALI

Alcuni progetti sono ottimizzati per la velocità di rilascio. Molte attività e iniziative non possono permettersi di aspettare che tutto sia completato; in tali casi, i clienti sono disposti a ricevere un sottoinsieme della soluzione complessiva. La frequente consegna di deliverable parziali viene chiamata ciclo di vita incrementale (vedere la Figura 3-4).

Figura 3-4. Un ciclo di vita con incrementi di varie dimensioni

Analisi

Progettazione

Realizzazione

Test

Rilascio

Analisi

Progettazione

Realizzazione

Test

Rilascio

Analisi

Progettazione

Realizzazione

Test

Rilascio

Avete mai partecipato a progetti in cui i requisiti sembravano cambiare ogni giorno e avete pensato di poter conoscere i requisiti soltanto dopo aver rilasciato un prototipo approvato dai riferenti aziendali? In tal caso, per il progetto in questione sarebbero stati utili approcci agili. I prototipi incoraggiano i feedback e una migliore comprensione dei requisiti che possono essere integrati in ciascun deliverable.

SU

GG

ERIM

ENTO

Siete incerti su come un nuovo servizio di business possa funzionare nella pratica? Create una dimostrazione pratica con criteri di valutazione adatti ad esplorare i risultati desiderati. Adottate approcci iterativi quando sospettate che i requisiti cambieranno in base al feedback del cliente.

23

I cicli di vita incrementali ottimizzano il lavoro e forniscono conseguentemente valore agli sponsor o ai clienti più spesso che con un unico prodotto finale. I team pianificano i deliverable iniziali prima di iniziare il lavoro, e cominciano a lavorare sul primo rilascio il prima possibile. Alcuni progetti agili generano valore entro alcuni giorni dall’inizio del progetto. Altri possono richiedere più tempo, da una a diverse settimane.

Man mano che il progetto evolve, il team può discostarsi dalla visione originale. Il team può gestire le deviazioni poiché genera valore in tempi più ridotti. Il grado di cambiamento e variazione è meno importante del garantire che i clienti possano ottenere valore prima del termine del progetto.

Fornire a un cliente una singola funzionalità o una parte di prodotto finito, sono esempi di approccio incrementale.

Ad esempio, i costruttori possono voler mostrare una camera o un piano finiti di un edificio prima di continuare con il resto della costruzione. In tal caso, possono completare un piano con impianti, intonaco e tutto l’occorrente per un piano finito prima di procedere con quello successivo. Il cliente potrà vedere e approvare lo stile, il colore e altri dettagli, consentendo le modifiche da apportare prima di ulteriori investimenti di tempo e denaro. Ciò riduce la potenziale rilavorazione e/o l’insoddisfazione del cliente.

La completezza e il rilascio sono soggettivi. Il team può avere bisogno di feedback su un prototipo e può quindi scegliere di fornire un prodotto minimo funzionante (MVP, Minimum Viable Product) a un sottoinsieme di clienti. I feedback dei clienti aiutano il team ad apprendere ciò che è necessario fornire per il successivo rilascio della funzionalità finale finita.

I team agili, come elemento di differenziazione principale, generano valore spesso. Quando il prodotto considera una serie più ampia di funzionalità e raggiunge uno spettro più ampio di consumatori, diciamo che viene fornito in modo incrementale.

24 Sezione 3

3.1.4 CARATTERISTICHE DEI CICLI DI VITA AGILI

In un ambiente agile, il team si aspetta che i requisiti cambino. Gli approcci iterativi e incrementali forniscono feedback per pianificare meglio la parte restante del progetto. Tuttavia, nei progetti agili, il rilascio incrementale consente di mettere in luce requisiti nascosti o incompresi. La Figura 3-5 illustra due possibili modi per raggiungere i rilasci incrementali in modo che il progetto si mantenga allineato con le esigenze del cliente e possa essere adattato secondo necessità.

Figura 3-5. Cicli di vita agili Iteration-Based e Flow-Based

Requisiti

Analisi

Progettazione

Realizzazione

Test

Requisiti

Analisi

Progettazione

Realizzazione

Test

NOTA: Ogni intervallo di tempo fisso ha le stesse dimensioni. Ogni intervallo di tempo fisso include funzionalità testate e funzionanti.

Requisiti

Analisi

Progettazione

Realizzazione

Test

Requisiti

Analisi

Progettazione

Realizzazione

Test

Ripetere secondo

necessità...

Requisiti

Analisi

Progettazione

Realizzazione

Test

Requisiti

Analisi

Progettazione

Realizzazione

Test

Agile iteration-based

Requisiti

Analisi

Progettazione

Realizzazione

Test

numero difunzionalitànel

limite WIP

Requisiti

Analisi

Progettazione

Realizzazione

Test

numero difunzionali-

tànellimite WIP

Requisiti

Analisi

Progettazione

Realizzazione

Test

numero difunzionalitànel

limite WIP

Ripetere secondo

necessità...

Requisiti

Analisi

Progettazione

Realizzazione

Test

numero difunzionalitànel

limite WIP

Requisiti

Analisi

Progettazione

Realizzazione

Test

numero difunzionalitànel

limite WIP

NOTA: Nel flusso, il tempo necessario per completare una funzionalità non è lo stesso per ognuna di esse.

Agile flow-based

25

Nei progetti agili Iteration-Based, il team lavora in iterazioni (intervalli di tempo fissi di pari durata) per rilasciare funzionalità complete. Il team lavora sulla funzionalità più importante, collaborando per terminarla. Quindi, passa alla funzionalità successiva di maggiore importanza e la termina. Il team può decidere di lavorare su alcune funzionalità alla volta, ma non si occupa contemporaneamente di tutto il lavoro per l’iterazione (ovvero non si occupa di tutti i requisiti, seguiti da tutte le analisi, ecc.).

Nei progetti agili Flow-Based, il team estrae le funzionalità dal backlog in base alla sua capacità di iniziare a lavorare piuttosto che a una schedulazione Iteration-Based. Il team definisce e rappresenta il suo flusso di lavoro sulle colonne di unalavagna delle attività e gestisce il lavoro in corso per ciascuna colonna. Ogni funzionalità può richiedere una quantità di tempo diversa per essere terminata. I team mantengono basso il numero delle attività contemporaneamente in corso per identificare meglio e in anticipo le questioni e ridurre la rilavorazione qualora siano necessari cambiamenti. In assenza di iterazioni per definire la pianificazione e i punti di revisione, il team e gli stakeholder aziendali creano la schedulazione più appropriata per la pianificazione, le revisioni dei prodotti e le retrospettive.

I cicli di vita agili sono quelli che soddisfano i principi dell’Agile Manifesto. In particolare, la soddisfazione dei clienti aumenta con un rilascio anticipato e continuo di prodotti di valore. Inoltre, un deliverable incrementale funzionale e che fornisce valore è la principale misura dell’avanzamento. I cicli di vita agili combinano sia approcci iterativi che incrementali per adattarsi ad alti tassi di cambiamento e generare più spesso valore per progetto.

3.1.5 FILTRI DI IDONEITÀ AGILI

Esistono vari modelli di valutazione per contribuire a determinare la probabilità di adeguatezza o meno rispetto all’uso di approcci agili. Questi modelli valutano specifiche caratteristiche di progetto e dell’organizzazione relative all’adozione e all’idoneità di approcci agili e quindi forniscono punteggi che evidenziano l’allineamento o potenziali aree di rischio. L’Appendice X3 fornisce una sintesi dei più diffusi modelli di valutazione da utilizzare come filtro di idoneità agili.

26 Sezione 3

3.1.6 CARATTERISTICHE DEI CICLI DI VITA IBRIDI

Non è necessario adottare un approccio unico per un intero progetto. I progetti spesso combinano elementi di diversi cicli di vita per raggiungere determinati obiettivi. Una combinazione di approcci predittivi, iterativi, incrementali e/o agili è un approccio ibrido.

La Figura 3-6 illustra approcci puri di base a tipi di progetti, che si combinano per formare un modello ibrido. I primi processi utilizzano un ciclo di vita di sviluppo agile che viene quindi seguito da una fase di implementazione predittiva. Questo approccio può essere utilizzato quando nella parte di sviluppo del progetto vi sono incertezza, complessità e rischio che potrebbero beneficiare di un approccio agile e seguito da un’appropriata fase di implementazione definita e ripetibile da svolgere in modo predittivo, magari da parte di un team diverso. Un esempio di questo approccio è lo sviluppo di un nuovo prodotto high-tech seguito dall’implementazione e dalla formazione per migliaia di utenti.

ESEMPIO DI UN PROGETTO CON CICLO DI VITA IBRIDO

Un’azienda farmaceutica ha avuto un lungo processo di approvazione presso la FDA (U.S. Food and Drug Administration) posizionato al termine del suo processo di sviluppo e l’intero ciclo di vita ha avuto l’aspetto della Figura 3-6. Mentre iteam di progetto svolgevano le sperimentazioni cliniche in modo agile, hanno dovuto presentare i farmaci a un gruppo esterno per il processo di approvazione dell’FDA. Un consulente ha contribuito a integrare la parte del processo di approvazione dell’FDA in un processo di sviluppo agile per creare un approccio ibrido accelerato.

In breve, dal momento che l’approvazione dell’FDA deve essere completata al temine del processo di sviluppo o ripetuta dopo qualsiasi cambiamento (ciò include anche le modifiche più piccole), il processo è dovuto rimanere al termine come fase distinta. L’integrazione tramite un processo iterativo non ha avuto successo. Tuttavia, il consulente ha creato alcune utili guide rapide e protocolli di test che hanno abbreviato il processo di approvazione finale dell’FDA.

27

Figura 3-6. Sviluppo agile seguito da un’implementazione predittiva

3.1.7 APPROCCI AGILI E PREDITTIVI COMBINATI

Un altro approccio consiste nell’utilizzare una combinazione di approcci agili e predittivi nel corso del ciclo di vita.

Figura 3-7. Un approccio agile e uno predittivo combinati e utilizzati simultaneamente

Nella Figura 3-7, si adotta nello stesso progetto una combinazione di approcci predittivi e agili. Probabilmente il gruppo sta effettuando una transizione incrementale all’agile e utilizza alcuni approcci come iterazioni brevi, daily standup e retrospettive, ma altri aspetti del progetto quali stima anticipata, assegnazione del lavoro e monitoraggio dell’avanzamento seguono ancora approcci predittivi.

L’uso combinato di approcci predittivi e agili è uno scenario comune. Sarebbe fuorviante chiamare questo approccio agile poiché chiaramente non incarna appieno la mentalità, i valori e i principi agili. Tuttavia, sarebbe impreciso anche chiamarlo predittivo perché si tratta di un approccio ibrido.

Agile

Predittivo

Agile

Predittivo

Agile

Predittivo

Agile Agile Agile Predittivo Predittivo Predittivo

28 Sezione 3

3.1.8 APPROCCIO PREVALENTEMENTE PREDITTIVO CON ALCUNE COMPONENTI AGILI

La Figura 3-8 mostra un piccolo elemento agile in un progetto principalmente predittivo. In questo caso, una parte del progetto caratterizzata da incertezza, complessità e possibilità di alterazione dell’ambito, viene gestita in modo agile ma il resto del progetto viene gestito adottando approcci predittivi. Un esempio di questo approccio è rappresentato da un’azienda di ingegneria che costruisce una struttura con un nuovo componente.

Figura 3-8. Un approccio significativamente predittivo con componenti agili

Sebbene la maggior parte del progetto possa essere routinaria e prevedibile, come molti altri progetti di strutture che l’organizzazione ha affrontato in precedenza, questo progetto incorpora un nuovo materiale per il tetto. L’appaltatore potrà pianificare alcune prove di installazione sul campo su scala ridotta per determinare il miglior metodo di installazione e scoprire precocemente eventuali questioni quando c’è ancora tutto il tempo per risolvere e migliorare incrementalmente i processi attraverso la sperimentazione e l’adattamento.

3.1.9 UN APPROCCIO SIGNIFICATIVAMENTE AGILE CON UNA COMPONENTE PREDITTIVA

La Figura 3-9 illustra un approccio significativamente agile con una componente predittiva. Questo approccio potrebbe essere utilizzato quando un particolare elemento non è negoziabile né eseguibile utilizzando un approccio agile. Gli esempi includono l’integrazione di un componente esterno sviluppato da un fornitore diverso che non può o non è disponibile a lavorare in modo collaborativo o incrementale. Dopo il rilascio del componente è necessaria una singola integrazione.

Figura 3-9. Un approccio significativamente agile con una componente predittiva

Predittivo Predittivo Predittivotivo Predittivotivo PredittPredittAgile Agile Agile

Agile Agile AgileAgileAgileAgilePredittivo Predittivo Predittivo

29

3.1.10 CICLI DI VITA IBRIDI COME IDONEI ALLO SCOPO

I gruppi di progetto possono progettare un ciclo di vita ibrido in base ai rischi di progetto. Ad esempio, un progetto di costruzione di un campus può avere più edifici da ristrutturare e costruire. Un approccio incrementale concentra le risorse sul completamento di alcuni edifici prima di altri, accelerando il ritorno sull’investimento. Ogni singolo rilascio può essere sufficientemente ben noto per trarre vantaggio da un ciclo di vita predittivo per il singolo edificio.

L’obiettivo del Project Management è produrre valore nel modo migliore possibile considerato il contesto corrente. Non importa se il modo scelto è agile o predittivo. La domanda da porsi è: “Come possiamo avere più successo?”

Sono necessari feedback man mano che il gruppo genera valore? In tal caso, gli incrementi saranno utili. È necessario gestire i rischi man mano che si esplorano idee? In tal caso, saranno utili iterazioni o un approccio agile.

Quando l’organizzazione non è in grado di fornire valore intermedio, gli approcci agili possono rivelarsi scarsamente utili. Nessun problema: l’obiettivo non è un approccio agile fine a se stesso. Il punto chiave è scegliere un ciclo di vita o una combinazione di cicli di vita che funzionino per il progetto, i rischi e il contesto culturale.

L’approccio agile si sostanzia in rilasci frequenti orientati al cliente. Questo tipo di rilasciogenera feedback per il team. Il team utilizza i feedback per pianificare e ripianificare il successivo blocco di lavoro.

Un dipartimento governativo ha gestito un progetto di sviluppo di un’applicazione per la sottoscrizione di assicurazione del credito. Il progetto, esteso su più anni, prevedeva la sostituzione di un sistema di sottoscrizione obsoleto con una nuova interfaccia più reattiva e alcune integrazioni del sistema. La maggior parte del progetto è stata effettuata adottando un approccio agile con continui input dai referenti aziendali.

I calcoli della tariffa premium sono stati trasmessi dall’Organizzazione per la cooperazione e lo sviluppo economico (OECD) sotto forma di una specifica di 200 pagine. I passaggi sono stati spiegati molto chiaramente con bassa possibilità di confusione (o con risultati intermedi confermati da parte dei referenti aziendali) e sono stati codificati da un team dedicato nelle fasi di calcolo. I due team hanno collaborato sulle variabili di input necessarie per il calcolo e sulle modalità d’uso e di visualizzazione dei valori di output ma, a parte questo, il team di calcolo ha lavorato in modo ampiamente predittivo.

Quando la parte del team di calcolo è stata completata, gli output dei calcoli della tariffa premium sono stati visualizzati sugli schermi e nei report. Poi, gli utenti aziendali hanno fornito feedback sull’aspetto e l’uso delle informazioni. I due gruppi hanno lavorato parallelamente ma hanno avuto scarse esigenze di interazione. La vicinanza fisica ha reso più semplice verificare l’avanzamento dello sviluppo ma si è trattato per lo più di sottoprogetti distinti.

30 Sezione 3

3.1.11 CICLI DI VITA IBRIDI COME STRATEGIA DI TRANSIZIONE

Molti team non sono in grado di effettuare in breve tempo il passaggio a modi agili di lavorare. Le tecniche agili sono viste e percepite come molto diverse da chi è abituato a un ambiente predittivo e ha ottenuto successi. Più grande è l’organizzazione e maggiore è il numero di parti impattate, più tempo sarà necessario per la transizione. Per tale motivo, ha senso pianificare una transizione graduale.

Una transizione graduale comporta l’integrazione di tecniche più iterative per migliorare l’apprendimento e l’allineamento tra i team e gli stakeholder. Successivamente, è opportuno considerare l’aggiunta di tecniche maggiormente incrementali per accelerare la generazione di valore e il ritorno sull’investimento per gli sponsor. Questa combinazione di vari approcci è considerata un approccio ibrido.

Provate queste nuove tecniche su un progetto poco rischioso con un livello di incertezza medio-basso. Quindi, quando l’organizzazione ha avuto successo con un approccio ibrido, provate su progetti più complessi che richiedono l’aggiunta di ulteriori tecniche di questo tipo. Si tratta di un modo per personalizzare una transizione progressiva all’ibrido in base alla situazione dell’organizzazione, ai rischi specifici e alla prontezza del team ad accettare i cambiamenti.

31

3.2 ABBINARE APPROCCI AGILI

I team agili limitano raramente le proprie pratiche a un unico approccio agile. Ogni contesto di progetto ha le proprie peculiarità, quali un mix variegato di competenze e formazione dei membri del team, le varie componenti del prodotto in sviluppo, ed età, dimensioni, criticità, complessità e vincoli normativi dell’ambiente in cui si svolge il lavoro.

Gli schemi di riferimento agili non sono personalizzati per il team. Il team può avere la necessità di adattare le pratiche per generare valore su base regolare. Spesso i gruppi adottano un proprio mix speciale di approcci agili, anche se utilizzano uno schema di riferimento particolare come punto di partenza.

COMBINARE GLI APPROCCI

Come esempio di personalizzazione di schemi di riferimento agili, uno dei mix più comunemente diffusi comporta un uso coordinato dello schemadi riferimento Scrum, del metodo Kanban e di elementi del metodo Extreme Programming (XP). Scrum fornisce linee guida sull’uso di un product backlog, un product owner, uno scrum master e un team di sviluppo interfunzionale, oltre a pianificazione dello sprint, daily scrum, sprint review e sessioni retrospettive di sprint. Una lavagna Kanban aiuta il gruppo a migliorare la sua efficienza visualizzando il flusso di lavoro, rendendo gli impedimenti facilmente visibili e consentendo la gestione del flusso attraverso limitazioni poste alle attività contemporaneamente in corso. Inoltre, le pratiche di ingegneria ispirate a XP quali uso di story card, integrazione continua, refactoring, test automatizzati e sviluppo guidato dai test aumentano ulteriormente l’efficacia del team agile. In sintesi, il mix di pratiche di queste varie fonti produce un risultato sinergico con prestazioni superiori rispetto a ogni singola componente individuale.

32 Sezione 3

3.3 FATTORI DI PROGETTO CHE INFLUENZANO LA PERSONALIZZAZIONE

Talvolta gli attributi di progetto richiedono la personalizzazione di un approccio per renderlo più adeguato. La Tabella 3-2 identifica alcuni fattori di progetto e opzioni di personalizzazione da prendere in considerazione.

Tabella 3-2. Opzioni di personalizzazione per migliorare la compatibilità

Per ulteriori indicazioni sui fattori che influenzano la personalizzazione, vedere l’Appendice X2 sugli Attributi che influenzano la personalizzazione.

Fattore di progetto Opzioni di personalizzazione

Schema della domanda: stabile o sporadico

Tasso di miglioramento dei processi richiesto dal livello di esperienza del team

Il flusso di lavoro è spesso ininterrotto da vari ritardi o impedimenti

La qualità degli incrementi di prodotto è scarsa

Servono più team per la realizzazione del prodotto

I membri del team di progetto non hanno esperienza nell’uso di approcci agili

Molti team trovano che l’utilizzo di una cadenza temporale (sotto forma di un intervallo di tempo fisso e regolare) li aiuti nella produzione di demo, nelle analisi retrospettiva e nel farsi carico di nuovo lavoro. Inoltre, alcuni team hanno bisogno di maggiore flessibilità nell’accettazione di ulteriore lavoro. I team possono utilizzare approcci agili flow-based con cadenza per ottenere il meglio da entrambi i mondi.

Eseguire più spesso retrospettive e prioritizzare i miglioramenti.

Prendere in considerazione la possibilità di rendere il lavoro visibile tramite l’utilizzo di lavagne kanban e sperimentare diversi limiti nelle varie aree del processo di lavoro per migliorare il flusso.

Prendere in considerazione l’uso di varie pratiche di sviluppo guidato dai test. Questa disciplina a prova di errore facilita l’individuazione dei difetti.

Per passare da uno a più team agili con il minimo impatto, per prima cosa serve apprendere schemi di riferimento formali scalabili e di gestione agile dei programmi. Confezionare poi un approccio adeguato al contesto del progetto.

Prendere in considerazione la possibilità di iniziare formando i membri del team sulla mentalità e sui principi Agili. Se il team decide di utilizzare un approccio specifico quale Scrum o Kanban, organizzare un workshop su tale approccio in modo che i membri del team possano imparare a utilizzarlo.

33

4IMPLEMENTAZIONE DI AGILE: CREARE UN AMBIENTE AGILE

4.1 INIZIARE CON UNA MENTALITÀ AGILE

La gestione di un progetto con un approccio agile richiede che il team di progetto adotti una mentalità agile. Le risposte alle seguenti domande aiuteranno a sviluppare una strategia di implementazione:

uu In che modo il team di progetto può agire in modo agile?

uu Cosa il team di progetto può produrre in modo rapido per ottenere feedback precoci e trarne vantaggio nel prossimo ciclo di rilascio?

uu In che modo il team può agire in modo trasparente?

uu Quali parti di lavoro possono essere evitate per concentrarsi sugli elementi ad alta priorità?

uu In che modo un approccio di servant-leadership può facilitare il raggiungimento degli obiettivi del team?

4.2 LA SERVANT LEADERSHIP RAFFORZA E RESPONSABILIZZA IL TEAM

Gli approcci agili enfatizzano la servant leadership come modo di dare potere ai team. La servant leadership è la pratica di guidare mettendosi al servizio del team, concentrandosi sulla comprensione e sull'indirizzamento dei bisogni e dello sviluppo dei componenti del team, per facilitare l’ottenimento delle migliori prestazioni possibili.

Il ruolo di un servant leader è quello di facilitare la scoperta e la definizione dell’Agile da parte del team. I servant leader adottano pratiche agili e le diffondono, affrontando il lavoro di progetto in questo ordine:

uu Scopo. Lavorare con il team per definire il “perché” o lo scopo, in modo da coinvolgersi e riunirsi attorno all’obiettivo del progetto. L’intero team si valorizza appieno a livello di progetto, non a livello di singola persona.

uu Persone. Una volta stabilito lo scopo, incoraggiare il team a creare un ambiente in cui tutti possono avere successo. Chiedere a ogni membro del team di contribuire al lavoro del progetto.

uu Processo. Non programmare di seguire il processo agile “perfetto” ma piuttosto ricercare il risultato. Quando un team interfunzionale genera valore finito frequentemente e riflette sul prodotto e sul processo, è un team agile. Non importa quale nome dà il team al processo seguito.

34 Sezione 4

Le seguenti caratteristiche della servant leadership consentono ai leader di progetto di diventare più agili e facilitare il successo del team:

uu Promuovere la consapevolezza di sé;

uu Ascoltare;

uu Mettersi al servizio dei membri del team;

uu Aiutare le persone a crescere;

uu Coaching vs. controllo;

uu Promuovere sicurezza, rispetto e fiducia, e

uu Promuovere l’energia e l’intelligenza degli altri.

La servant leadership non è un’esclusiva dell’agile ma, dopo averla praticata, i servant leader solitamente si rendono conto di come essa si integri perfettamente nella mentalità e nei valori agile.

Quando i leader sviluppano la propria servant leadership o le proprie doti di facilitazione, hanno più probabilità di diventare agili. Di conseguenza, i servant leader possono aiutare i loro team a collaborare per generare valore più rapidamente.

I team agili di successo abbracciano una mentalità orientata alla crescita, in cui le persone sono confidenti di poter sviluppare nuove competenze. Quando il team e i servant leader sono convinti di poter imparare tutti, ognuno diventa più capace.

4.2.1 RESPONSABILITÀ DEL SERVANT LEADER

I servant leader gestiscono le relazioni per costruire una comunicazione e un coordinamento nel team e nell’ambito dell’organizzazione. Queste relazioni aiutano i leader a muoversi all’interno dell’organizzazione per supportare il team. Questo tipo di supporto contribuisce a rimuovere gli ostacoli e facilita il team nell’ottimizzare i propri processi. Dal momento che i servant leader comprendono l’agile e adottano un approccio specifico all’agile, possono essere d’aiuto nel soddisfare le esigenze del team.

35

4.2.1.1 I SERVANT LEADER FACILITANO

Quando i Project Manager agiscono da servant leader, l’enfasi passa dal “gestire il coordinamento” a “facilitare la collaborazione”. I facilitatori aiutano ognuno a fare del proprio meglio nel pensare e nel lavorare. Incoraggiano la partecipazione, la comprensione e la responsabilità condivisa del team sui propri risultati. Essi aiutano il team a creare soluzioni accettabili.

I servant leader promuovono la collaborazione e la conversazione all’interno del team e tra team diversi. Ad esempio, un servant leader aiuta a esporre e comunicare i colli di bottiglia all’interno dei team e tra di essi. Sono poi i team a risolvere i colli di bottiglia individuati.

Inoltre, un facilitatore incoraggia la collaborazione con riunioni interattive, dialogo informale e condivisione della conoscenza. I servant leader svolgono tale ruolo fungendo da contatto e da coach imparziali piuttosto che prendendo decisioni di cui altri dovrebbero essere responsabili.

4.2.1.2 I SERVANT LEADER RIMUOVONO GLI OSTACOLI ORGANIZZATIVI

Il primo valore dell’Agile Manifesto sono gli individui e le interazioni rispetto a processi e strumenti. Quale migliore responsabilità per un servant leader che uno sguardo critico ai processi che impediscono l’agilità dell’organizzazione o di un team e quindi lavorare per ottimizzarli? Ad esempio, se un reparto richiede un’ampia documentazione, il ruolo del servant leader potrebbe essere quello di lavorare con tale reparto per rivedere la documentazione richiesta, fornire assistenza nella creazione di una comprensione condivisa di come i deliverable agili soddisfino tali requisiti e valutare la quantità di documentazione necessaria in modo che i gruppi spendano più tempo a fornire un prodotto di valore invece che a produrre una documentazione esaustiva.

I servant leader devono inoltre individuare altri processi prolissi, che causano colli di bottiglia e impediscono l’agilità di un team o di un’organizzazione. Esempi di processi o reparti che possono richiedere attenzione sono finanza, comitati di gestione dei cambiamenti o audit. I servant leader possono collaborare e lavorare con altri per sfidarli a rivedere i propri processi al fine di sostenere team e leader agili. Ad esempio, in cosa consiste il vantaggio di un team che fornisce un prodotto di lavoro ogni due settimane se poi il prodotto finisce in coda o in un processo il cui rilascio può richiedere 6 o più settimane? Troppe organizzazioni presentano questi processi “a collo di bottiglia” che impediscono ai team di fornire rapidamente prodotti o servizi di valore. Il servant leader ha la capacità di modificare o rimuovere questi ostacoli per supportare i team di rilascio.

36 Sezione 4

4.2.1.3 I SERVANT LEADER PREPARANO LA STRADA AL CONTRIBUTO DEGLI ALTRI

Nell’agile, il team gestisce i propri processi e il prodotto del proprio lavoro. Questa autogestione e auto-organizzazione si applica a chiunque serva e supporti l’organizzazione e il progetto. I servant leader lavorano per soddisfare le esigenze dei team, dei progetti e dell’organizzazione. Possono gestire le strutture per offrire uno spazio fisico destinato al team, con il management per consentire al team di concentrarsi su un progetto alla volta, o con il product owner per sviluppare le user story in collaborazione con il team. Alcuni servant leader collaborano con i revisori per affinare i processi necessari negli ambienti normativi, e altri lavorano con il dipartimento finanziario per guidare la transizione dell’organizzazione verso una gestione del budget in forma incrementale.

Il servant leader si occupa di spianare la strada al team per consentirgli di svolgere al meglio il proprio lavoro. Il servant leader influenza i progetti e incoraggia l’organizzazione a pensare in modo diverso.

4.2.1.4 RESPONSABILITÀ DEL SERVANT LEADER DA PRENDERE IN CONSIDERAZIONE

I servant leader possono avere vari titoli ma ciò che conta di più è ciò che fanno. Ecco alcuni esempi delle responsabilità che un servant leader può avere:

CAPACITÀ INTERPERSONALI VS. CAPACITÀ TECNICHE

Oltre alla servant leadership, i membri del gruppo enfatizzano le loro capacità interpersonali e di intelligenza emotiva, non soltanto le doti tecniche. Ogni componente del team lavora per mostrare più iniziativa, integrità, intelligenza emotiva, onestà, collaborazione, umiltà e volontà di comunicare in vari modi affinché l’intero team possa collaborare al meglio.

Il team ha bisogno di tali competenze per poter rispondere adeguatamente a cambiamenti nella direzione del progetto e a modifiche tecniche del prodotto. Quando tutti possono adattarsi al lavoro da svolgere e l’uno all’altro, l’intero team ha maggiori probabilità di successo.

37

uu Educare gli stakeholder sul perché e come essere agili. Spiegare i benefici del valoregenerato dalla prioritizzazione, da una maggiore responsabilità e produttività di team responsabilizzati e una migliore qualità grazie a revisioni più frequenti, ecc.

uu Supportare il team attraverso mentoring, incoraggiamento e supporto. Sostenere la formazione e lo sviluppo della carriera dei membri del team. La citazione ossimorica “Guidiamo i gruppi stando alle loro spalle” esprime il ruolo del leader nello sviluppo dei membri del suo team. Attraverso il sostegno, l’incoraggiamento e lo sviluppo professionale, i membri del team acquisiscono fiducia, assumono ruoli di maggior rilevanza e contribuiscono a livelli superiori nelle loro organizzazioni. Uno dei ruoli principali del servant leader è far crescere i membri del team attraverso e oltre i ruoli attuali, anche se ciò significa perderli dal team.

uu Aiutare il team con tecniche di Project Management quali l’analisi quantitativa del rischio. Talvolta i membri del team potrebbero non disporre della conoscenza o dell’esperienza adeguata ai ruoli o alle funzioni. I servant leader, che possono avere maggior dimestichezzai o formazione sulle tecniche, possono a loro voltasupportare il team erogando formazione o svolgendo queste attività.

uu Celebrare i successi del team, sostenere e facilitare la costruzione di relazioni con gruppi esterni. Creare circoli virtuosi di apprezzamento e buona volontà per raggiungere maggiore collaborazione.

4.2.2 IL RUOLO DEL PROJECT MANAGER IN UN AMBIENTE AGILE

Il ruolo del Project Manager in un progetto agile è in una certa misura indefinito poiché molti schemi di riferimento e approcci agili non si interessano del suo ruolo. Alcuni professionisti agili pensano che il ruolo di un Project Manager non sia necessario poiché i gruppi auto-organizzati si assumono le sue precedenti responsabilità. Tuttavia, le organizzazioni e i professionisti agili pragmatici sono consapevoli che i Project Manager possono aggiungere un valore significativo in molte situazioni. Il punto principale è che i loro ruoli e responsabilità appaiono piuttosto differenti.

SU

GG

ERIM

ENTO

Il valore del Project Manager non risiede nella sua posizione ma nella capacità di rendere migliori tutti gli altri.

38 Sezione 4

4.2.3 I PROJECT MANAGER UTILIZZANO LA SERVANT LEADERSHIP

La Guida PMBOK® – Sesta edizione definisce il Project Manager come “la persona incaricata dalla Performing Organization di guidare il team responsabile del raggiungimento degli obiettivi del progetto”.

Molti Project Manager sono abituati a essere al centro del coordinamento del progetto, monitorando e rappresentando lo stato del lavoro del team al resto dell’organizzazione. Questo approccio era adeguato quando i progetti erano scomposti in funzioni separate.

Tuttavia, nei progetti con un alto tasso di cambiamento, vi è maggiore complessità di quanto una persona possa gestire. Al contrario, i team interfunzionali coordinano il proprio lavoro e collaborano con il referente aziendale (il product owner).

Quando lavorano su progetti agili, i Project Manager passano da essere il fulcro del progetto a servire il team ed il management. In un ambiente agile, i Project Manager sono servant leader, spostando l’enfasi sul coaching delle persone che desiderano aiutare, favorendo una maggiore collaborazione nel team e allineando le esigenze degli stakeholder. In qualità di servant leader, i Project Manager incoraggiano la distribuzione di responsabilità al team, o meglio a quelle persone che hanno la conoscenza necessaria per svolgere il lavoro.

4.3 COMPOSIZIONE DEL TEAM

Un punto cardine nei valori e nei principi dell’Agile Manifesto è l’importanza degli individui e delle loro interazioni. Agile ottimizza il flusso di valore, ponendo l’enfasi sul rapido rilascio delle funzionalità al cliente invece che sulle modalità di impiego delle persone.

SU

GG

ERIM

ENTO

Costruite progetti attorno a individui motivati. Date loro l’ambiente e il supporto necessari e fidatevi che riusciranno a svolgere il loro lavoro.

39

Quando i gruppi riflettono su come ottimizzare il flusso di valore, i seguenti benefici diventano evidenti:

uu Le persone sono più inclini a collaborare.

uu I gruppi terminano il lavoro importante in tempi più rapidi.

uu I gruppi perdono molto meno tempo poiché non sono multitasking e non devono ristabilire il contesto.

4.3.1 TEAM AGILI

I gruppi agili si incentrano su un rapido sviluppo dei prodotti in modo da poter ottenere feedback. In pratica, i team agili più efficienti tendono ad avere un numero di membri compreso tra tre e nove. Idealmente, i team agili sono colocati in uno spazio ad essi riservato. I membri del team sono allocati al 100% nel team. L’Agile incoraggia i team autogestiti, in cui i componenti decidono chi svolgerà il lavoro inerente l’ambito del periodo successivo. I team agili traggono vantaggio dalla servant leadership. I leader supportano l’approccio voluto dai team al proprio lavoro.

I team agili interfunzionali producono frequentemente incrementi funzionali del prodotto. Ciò è dovuto al fatto che i team sono collettivamente responsabili del loro lavoro e -insieme - dispongono di tutte le competenze necessarie rilasciare il lavoro completato.

Indipendentemente dall’approccio agile generale, più un gruppo limita le attività contemporaneamente in corso, più è probabile che i suoi membri possano collaborare per velocizzare il lavoro esposto sulla lavagna. I membri nei team agili di successo lavorano per collaborare in vari modi (quali pairing, swarming e mobbing) in modo da non cadere nella trappola delle mini-waterfall invece di adottare un lavoro collaborativo. Le mini-waterfall si verificano quando il team si occupa di tutti i requisiti in un determinato periodo, quindi tenta di svolgere tutta la progettazione e poi passa alla realizzazione di tutta la costruzione. In questo scenario, a un certo punto della costruzione della soluzione o nel test a seguito della stessa, il team potrà rendersi conto che i suoi assunti non sono più validi. In questo caso, il team ha perso tempo nell’occuparsi di tutti i requisiti. Al contrario, quando i membri del team collaborano per produrre un piccolo numero di funzionalità presenti sulla lavagna, apprendono mentre procedono e producono funzionalità finite più piccole.

I progetti agili beneficiano di strutture del team che migliorano la collaborazione all’interno e tra i gruppi. La Tabella 4-1 mostra in che modo membri di team collaborativi incrementano la produttività e facilitano la risoluzione innovativa di problemi.

40 Sezione 4

Tabella 4-1. Attributi di team agili di successo

4.3.2 RUOLI AGILI

Nell’agile, si utilizzano tre ruoli comuni:

uu Membri del team interfunzionale,

uu Product owner e

uu Facilitatori del team.

La Tabella 4-2 descrive questi ruoli del team.

Attributo Obiettivo

Risorse dedicate

Membri del team interfunzionale

Colocazione o abilità a gestire eventuali questioni legate all’ubicazione

Gruppo misto di generalisti e specialisti

Ambiente di lavoro stabile

• Maggiore focalizzazione e produttività• Gruppo di piccole dimensioni, meno di dieci persone

• Sviluppare e rilasciare spesso• Generare valore finito in quanto team indipendente• Integrare tutte le attività per rilasciare lavori finito• Fornire feedback dall’interno del team e da altri stakeholder, ad esempio il product owner

• Migliore comunicazione• Migliori dinamiche di gruppo • Condivisione della conoscenza• Ridotto costo di apprendimento• In grado di impegnarsi a lavorare insieme

• Gli specialisti portano competenze verticali mentre i generalisti la flessibilità di adattarsi a compiti diversi• i membri delteam mettono a disposizione le proprie competenze specifiche e spesso diventano specialisti generalisti, con una specializzazione approfondita più una vasta esperienza in diversi ambiti

• Dipendenza reciproca orientata al rilascio• Approccio concordato al lavoro• Calcoli semplificati dei costi di gruppo (costi di gestione)• Salvaguardia ed espansione del capitale intellettuale

41

Tabella 4-2. Ruoli dei team agili

Ruolo Descrizione

Membro del team interfunzionale

Product owner

Facilitatore del team

I team interfunzionali sono costituiti da membri dotati di tutte le competenze necessarie per produrre un prodotto funzionante. Nello sviluppo software, i team interfunzionali sono generalmente costituiti da progettisti, sviluppatori, tester e altri ruoli necessari. I team di sviluppo interfunzionali consistono di professionisti che rilasciano un prodotto potenzialmente consegnabile a cadenza regolare. I team interfunzionali sono determinanti perché possono rilasciare un prodotto finito nel più breve tempo possibile, con maggiore qualità e senza dipendenze esterne.

Il product owner è responsabile di indirizzare le scelte di prodotto. I product owner classificano il lavoro da fare in base al valore che genera. I product owner lavorano quotidianamente con i team fornendo feedback sul prodotto e fissando la direzione della funzionalità successiva da sviluppare/rilasciare. Ciò significa che il lavoro è di piccola dimensione, spesso così piccolo da poter essere descritto su una scheda.

Il product owner lavora con stakeholder, clienti e team per indirizzare le scelte di prodotto. Generalmente, i product owner hanno una estrazione aziendale e portano una profonda esperienzadiambito utile per il processo decisionale. Talvolta il product owner richiede l’aiuto di persone con una profonda esperienza di settore, quali architetti, o un’approfondita esperienza di mercato, quali i product manager. I product owner hanno bisogno di formazione su come organizzare e gestire il flusso di lavoro all’interno del team.

Nell’agile, i product owner creano il backlog per il team e con esso. Il backlog aiuta i team a vedere come rilasciare il massimo valore senza creare sprechi.

Un fattore critico per il successo dei gruppi agili è una forte responsabilzzazione sul prodotto. Se non si presta attenzione al massimo valore per il cliente, il team agile può creare funzionalità non apprezzate o di valore non sufficiente, sprecando lo sforzo fatto.

Il terzo ruolo tipicamente osservato nei team agili è quello del facilitatore, ovvero un servant leader. Questo ruolo può essere chiamato project manager, Scrum Master, leader del team di progetto, coach del team o facilitatore del team.

Tutti i team agili hanno bisogno di servant leadership. Le persone hanno bisogno di tempo per costruire le proprie competenze di servant leadership: facilitazione, coaching e rimozione degli impedimenti.

Inizialmente, molte organizzazioni invitano coach agili esterni per farsi aiutare quandole loro abilità interne di coaching non sono ancora pienamente sviluppate.

I coach esterni hanno il vantaggio dell’esperienza ma lo svantaggio di relazioni deboli all’interno dell’organizzazione del cliente. I coach interni, invece, hanno forti relazioni nella loro organizzazione ma mancano dell’esperienza che li renderebbe altamente efficaci.

42 Sezione 4

4.3.3 SPECIALISTI GENERALISTI

I team agili sono interfunzionali ma spesso le persone non iniziano in questo modo. Tuttavia, molti team agili di successo sono costituiti da specialisti generalisti, o persone con “profilo a T”.

Ciò significa che i membri del team hanno sia una specializzazione principale che una vasta esperienza di più capacità invece che un’unica specializzazione. I membri di un team agile lavorano per sviluppare tali caratteristiche facendo leva sull’intensa collaborazione e l’autorganizzazione per consentire lo swarming e il completamento del lavoro in tempi rapidi; a tal fine, devono abitualmente aiutarsi l’un l’altro.

L’efficienza produttivadi una singola persona non è rilevante. La focalizzazione sull’efficienza produttiva di una singola persona può rivelarsi persino nociva se crea un collo di bottiglia per il resto del team. L’obiettivo è che il team ottimizzi il rilascio di prodotti finiti per ottenere feedback.

Se il cliente desidera risultati straordinari, quali un rapido rilascio di funzionalità di ottima qualità, il team non può essere strutturato soltanto con ruoli specializzati nel tentativo di massimizzare l’efficienza delle risorse. L’obiettivo del team è l’efficienza del flusso di lavoro, con conseguente ottimizzazione dell’efficienza produttiva dell’intero team. Lotti di piccole dimensioni promuovono la collaborazione di gruppo. Il compito del product owner è assicurarsi che il team si occupi delle attività a più alto valore.

“PERSONE CON PROFILO A I E CON PROFILO A T”

Alcune persone hanno profonde specializzazioni in un campo di competenza ma raramente contribuiscono al di fuori di tale dominio. Nelle comunità agile sono note come “persone con profilo a I” poiché, come la lettera “I,” hanno profondità ma mancano di trasversalità. Al contrario, le “persone con profilo a T” integrano la loro esperienza in una specifica area con competenze ausiliarie, ma meno sviluppate in aree associate, e buone doti di collaborazione. Ad esempio, una persona che può testare alcune aree del prodotto e sviluppare aree diverse del prodotto è considerata con profilo a T.

Una persona con profilo a T ha una specializzazione definita e riconosciuta e un ruolo primario, ma dispone delle capacità, della versatilità e dell’attitudine per collaborare e aiutare le altre persone quando e dove necessario. Questa collaborazione riduce i passaggi di consegne e i vincoli legati al fatto che ci siauna sola persona in grado di svolgere il lavoro.

43

4.3.4 STRUTTURE DEL TEAM

I team hanno adottato principi e pratiche agili in numerosi settori. Organizzano le persone in team interfunzionali per sviluppare in modo iterativo prodotti funzionanti.

Alcune organizzazioni sono state in grado di creare team colocati e interfunzionali, altre si trovano in situazioni differenti. Invece di colocare tutti i membri del team, alcune organizzazioni hanno gruppi distribuiti o dislocati in aree geografiche diverse. I gruppi distribuiti hanno sottogruppi interfunzionali in diversi luoghi. Nei team dislocati in aree geografiche diverse, ogni componente del gruppo può trovarsi a lavorare in una location completamente diversa, in un ufficio o a casa. Sebbene questo tipo di organizzazione non sia ideale a causa di più alti costi di comunicazione, essa potrebbe comunque essere praticabile.

CA

SO

Il core team riunito per scrivere questa guida presentava profili eterogenei, alcuni in rappresentanza del PMI e altri dell’Agile Alliance. Erano auto-organizzati e lavoravano ad incrementi per completare il lavoro. Il PMI ha riunito un gruppo di esperti in materia per ispezionare il lavoro fatto, e ciò ha consentito al team di integrare feedback e migliorare il prodotto man mano che veniva sviluppato. Tuttavia, il core team non era rappresentativo di un tipico team agile poiché i membri non erano dedicati al 100% a questa attività.

44 Sezione 4

4.3.5 MEMBRI DEL GRUPPO DEDICATI

Cosa accade quando i membri del team non sono allocati al 100% al team? Si tratta di una condizione non ideale ma purtroppo a volte inevitabile.

Il problema principale quando qualcuno investe una capacità del solo 25% o 50% nel team, è il multitasking e il passaggio ad altre attività. Il multitasking riduce l’efficienza produttiva del lavoro del team e influisce sulla capacità del gruppo di prevedere realistiche modalità di rilascio.

2 Nel processo di sviluppo “follow the sun” il lavoro viene trasferito al termine di ogni giornata da un sito all’altro, con fusi orari diversi, per accelerare lo sviluppo del prodotto.

Una grande istituzione finanziaria statunitense aveva un programma con una serie di team i cui membri erano dislocati sulla costa orientale degli Stati Uniti e in diverse località dell’India. Inizialmente, il gruppo era grande e dislocato in aree geografiche diverse (UX, analisti, sviluppatori e tester) e operava sulla base della pratica di sviluppo “follow the sun”2 in cui parte dell’orario di lavoro si sovrappone tra i membri del team per consentire un fluido passaggio di mano delle attività. Il team conduceva daily standup e utilizzava webcam per coinvolgere tutti i membri del team. I ruoli chiave (analisti, product owner, progettisti UX e leader di sviluppo) negli Stati Uniti iniziavano a lavorare prima per rispondere a domande dei membri del team con sede in India e aiutare a rimuovere gli ostacoli.

Quando il prodotto ha iniziato ad ampliarsi e sono arrivati maggiori finanziamenti, hanno deciso di dividersi in cinque team più piccoli. A tal fine, hanno deciso di costituire team distribuiti colocati in vari luoghi. Si è scelto di costituire team interfunzionali colocati in ciascuna delle sedi, composti da sviluppatori e tester.

Disponevano anche di un gruppo centrale di analisti con sede in due località statunitensi, che hanno collaborato con il product manager e i product owner e hanno lavorato con ciascuno dei team, rispettivamente. Pur avendo reso operative delle strutture in cui conducevano revisioni del prodotto a livello di programma, gran parte delle attività è stata svolta a livello di team, in base a ciò che garantiva i migliori risultati per ciascun gruppo, consentendo in questo modo loro di auto-organizzarsi.

SU

GG

ERIM

ENTO

Il multitasking rallenta l’avanzamento delle attività dell’intero team poiché i membri sprecano tempo passando da un contesto all’altro e/o aspettando che altri finiscano il proprio lavoro. Quando le persone sono dedicate al 100% al team, quest’ultimo raggiunge la massima efficienza produttiva.

45

Si rileva una perdita di produttività tra il 20% e il 40% quando le persone passano da un’attività all’altra. La perdita aumenta esponenzialmente il crescere del numero di attività.

Quando una persona è multitasking tra due progetti, non è al 50% in nessuno dei due. Al contrario, a causa del costo del passaggio tra attività diverse, la persona risulterà allocata al 20-40% su ciascun progetto.

Quando le persone operano in multitasking, hanno maggiori probabilità di commettere errori. Il passaggio tra diverse attività fa perdere memoria di lavoro e quando operano in multitasking, le persone hanno meno probabilità di ricordare il contesto.

Quando ogni membro del team è assegnato al 100% a un solo progetto, tutti possono collaborare in modo continuativo in gruppo rendendo il lavoro più efficace.

Vedere la Tabella A1-2 riguardante il Gruppo di processi di Project Management e la mappatura delle aree di conoscenza per ulteriori suggerimenti sui team negli ambienti agili, in particolare sui processi nell’area di conoscenza della Gestione delle risorse del progetto.

SU

GG

ERIM

ENTO Non tutti i team posseggono al loro interno tutti i ruoli di cui hanno bisogno. Ad esempio, alcuni

team hanno bisogno del supporto di amministratori di database o di ricercatori. Quando un gruppo ha specialisti assegnati in via temporanea, è importante garantire che ciascuno abbia le stesse aspettative. Questo specialista è allocato al 100% nel team? E per quanto tempo? Condividete le aspettative con tutti (lo specialista e il team) per chiarire il livello di ingaggio personale e far sì che il team possa rilasciare. Gli incarichi part-time generano rischi per il progetto.

CA

SO

Dal momento che i membri del core team che sviluppano questa guida non possono dedicare il 100% della propria disponibilità alle attività del team, la loro efficienza produttiva è sostanzialmente inferiore a quella che avrebbe potuto essere se fossero stati colocati e avessero potuto dedicarsi a tempo pieno al progetto. Tuttavia, sebbene siano disponibili le risorse economiche per collaborare, benché dislocati in aree geografiche diverse e lavorando a tempo parziale, non è possibile raggiungere la colocazione e una focalizzazione a tempo pieno. Di conseguenza, il team ha identificato la dispersione geografica come un potenziale rischio. Il team tiene traccia e monitora l’avanzamento del proprio lavoro attraverso l’uso di strumenti collaborativi e adegua gli incarichi in base alla disponibilità individuale.

46 Sezione 4

4.3.6 SPAZI DI LAVORO DEL TEAM

I team hanno bisogno di uno spazio di lavoro in cui collaborare per condividere il proprio stato di gruppo e per lavorare insieme. Alcuni team agili lavorano tutti insieme in una stanza. Altri hanno uno spazio di lavoro per il team per standup e grafici, e lavorano ciascuno nella propria postazione o ufficio.

Mentre le aziende migrano verso ambienti di collaborazione aperti, le organizzazioni devono anche creare spazi riservati per i lavoratori che necessitano di non essere disturbati per pensare e lavorare. Di conseguenza, le aziende stanno progettando i propri uffici per bilanciare aree comuni e sociali con aree riservate o spazi privati in cui i singoli possano lavorare senza interruzioni (talvolta chiamate “caves and common”).

Quando i gruppi hanno membri distribuiti a livello geografico, il team decide in che misura il luogo di lavoro sia virtuale o fisico. Tecnologie quali condivisione di documenti, videoconferenze e altre forme di collaborazione virtuale aiutano le persone a lavorare insieme a distanza.

I team distribuiti a livello geografico hanno bisogno di spazi di lavoro virtuali. Inoltre, occorre riunire fisicamente il team a intervalli regolari in modo che possa generare fiducia e apprendere come collaborare.

Alcune tecniche da prendere in considerazione per gestire la comunicazione in gruppi dislocati geograficamente sono le fishbowl window e il remote pairing:

uu Create una fishbowl window impostando collegamenti adatti a lunghe videoconferenze tra le varie sedi in cui il team è distribuito. Le persone avviano il collegamento all’inizio della giornata lavorativa e lo chiudono al termine. In tal modo, possono vedersi e avere scambi reciproci, riducendo il lag di collaborazione altrimenti implicito nella distanza geografica.

uu Impostate il “remote pairing” utilizzando strumenti per videoconferenze per condividere gli schermi ed i collegamenti audio e video. A patto che si tengano in considerazione i diversi fusi orari, questo metodo può dimostrarsi efficace quanto il “face-to-face pairing”.

SU

GG

ERIM

ENTO

Formate i team riunendo persone con competenze diverse provenienti da varie funzioni. Educate responsabili e leader a comprendere la mentalità agile e coinvolgeteli il prima possibile nella trasformazione agile.

47

4.3.7 SUPERAMENTO DEI SILOS ORGANIZZATIVI

Il modo migliore per iniziare a costituire i team agili è quello di creare una base di fiducia e un ambiente di lavoro sicuro in modo da garantire che tutti i membri del team abbiano pari voce e possano essere ascoltati e tenuti in considerazione. Questo, insieme allo sviluppo di una mentalità agile, è il fattore di successo portante: tutte le altre sfide e i rischi possono essere mitigati.

Spesso, le organizzazioni a silos creano impedimenti alla costituzione di team interfunzionali agili. I componenti necessari per costituire team interfunzionali generalmente riportano a responsabili diversi e hanno metriche differenti in base alle quali i responsabili misurano le loro prestazioni. I manager devono concentrarsi sull’efficienza del flusso di lavoro (e su metriche basate sul team) piuttosto che sull’efficienza delle singole risorse.

Per superare le rigidità organizzative, occorre lavorare con i vari responsabili dei membri del team e accertarsi che essi dedichino le risorse necessarie al team interfunzionale. Ciò non soltanto crea sinergia nel team ma consente anche all’organizzazione di vedere in che modo, sfruttando le risorse umane a disposizione, è possibile ottimizzare il progetto o prodotto in via di realizzazione.

Per ulteriori informazioni sui team, vedere l’Appendice X2 sugli Attributi che influenzano la personalizzazione.

SU

GG

ERIM

ENTO

In qualità di Project Leader agili, concentratevi come prima cosa su come creare un team che sia interfunzionale e dedicato al 100% al team. Anche se questo significa soltanto ottenere che i membri chiave del team, quali sviluppatori e tester, lavorino e comunichino tra loro quotidianamente, è un passo nella giusta direzione verso l’agilità.

49

5IMPLEMENTAZIONE DI AGILE: OPERARE IN UN AMBIENTE AGILE

5.1 UFFICIALIZZARE IL PROGETTO E IL TEAM

Ogni progetto ha bisogno di un Project Charter in modo che il team di progetto sappia perché il progetto è importante, dove è diretto il team e qual è l’obiettivo del progetto. Tuttavia, il Project Charter in sé potrebbe non essere sufficiente per il team. I team agili richiedono norme e una comprensione di come lavorare insieme. In tal caso, il team potrebbe avere bisogno di un Team Charter.

Il processo di avvio aiuta il team ad apprendere come lavorare insieme e riunirsi attorno al progetto.

Come minimo, per un progetto agile, il team ha bisogno di una visione o scopo di progetto e di una chiara serie di accordi di lavoro. Un Project Charter agile risponde a queste domande:

uu Perché stiamo facendo questo progetto? Questa è la visione del progetto.

uu Chi ne beneficia e come? Ciò può fare parte della visione del progetto e/o del suo scopo.

uu Cosa significa “done” per il progetto? Questi sono i criteri di rilascio del progetto.

uu Come lavoreremo insieme? Questo spiega il flusso di lavoro auspicato.

Un servant leader può facilitare il processo di ufficializzazione. Un team può saldarsi lavorando insieme e il Project Charter è un modo straordinario per iniziare a lavorare. Inoltre, i membri del team possono voler collaborare per comprendere come lavoreranno insieme.

50 Sezione 5

I team non hanno bisogno di un processo formale di ufficializzazione a condizione che comprendano come lavorare insieme. Alcuni team beneficiano di un processo di ufficializzazione del team. Ecco alcune idee di ufficializzazione che i membri del team possono utilizzare come base per il loro patto interno:

uu Valori del team, quali ritmo di lavoro sostenibile e gli orari chiave di disponibilità;

uu Accordi di lavoro, come per esempio cosa significa “ready” in modo tale che il team possa comprendere a fondo il lavoro da fare; il significato di “done” affinché il team possa valutare la completezza del lavoro fatto in modo consistente; il rispetto degli intervalli di tempo fissi o l’utilizzo dei limiti del “work-in progress”.

uu Regole di base, ad esempio che in una riunione si parla uno alla volta, e

uu Norme del team, ad esempio il modo in cui il team gestisce i tempi di riunione.

Il servant leader, insieme con il team, può decidere di indirizzare ulteriori comportamenti.

Ricorda che il patto interno del team - il suo Team Charter - rappresenta il modo in cui i membri del team interagiscono tra loro. L’obiettivo del Team Charter è creare un ambiente agile in cui i membri del team possano lavorare al meglio delle proprie capacità come team.

5.2 PRATICHE AGILI COMUNI

Le sezioni da 5.2.1 a 5.2.8 descrivono alcune delle più comuni pratiche agili di progetto.

5.2.1 RETROSPETTIVE

La pratica più importante è la retrospettiva perché consente al team di apprendere, migliorare e adattare i suoi processi.

Le retrospettive aiutano il team ad apprendere dal lavoro precedente svolto sul prodotto e dai suoi processi. Uno dei principi alla base dell’Agile Manifesto è: “A intervalli regolari, il team riflette su come diventare più efficace, quindi si sintonizza e adegua di conseguenza il proprio comportamento”.

51

Molti team adottano le iterazioni - soprattutto quelle di 2 settimane - poiché l’iterazione porta a una dimostrazione e una retrospettiva finali. Tuttavia, il team non ha bisogno di iterazioni per fare una retrospettiva. I membri del team possono decidere di eseguire una retrospettiva in questi momenti chiave:

uu Quando il team completa un rilascio o spedisce qualcosa. Non deve trattarsi necessariamente di un incremento sostanziale. Può trattarsi di qualsiasi rilascio, non importa quanto piccolo.

uu Quando è trascorsa qualche settimana dalla retrospettiva precedente.

uu Quando il team sembra bloccato e il lavoro completato non fluisce all’interno del team.

uu Quando il team raggiunge qualsiasi altra milestone.

I team beneficiano dell’allocazione di tempo sufficiente per l’apprendimento, da una retrospettiva temporanea o alla fine del progetto. I team devono conoscere il prodotto del loro lavoro e il processo da seguire. Ad esempio, alcuni team hanno problemi a terminare il lavoro. Quando i team pianificano tempo sufficiente, possono strutturare la loro retrospettiva per raccogliere dati, elaborarli e decidere cosa sperimentare successivamente.

Anzitutto e in primo luogo, una retrospettiva non è un’attribuzione di colpa: è un momento per il team in cui apprendere dal lavoro precedente e apportare piccoli miglioramenti.

La retrospettiva analizza i dati qualitativi (sensazioni delle persone) e quantitativi (misurazioni), quindi li utilizza per individuare le cause originarie, progettare contromisure e sviluppare piani d’azione. Il team di progetto può ritrovarsi con molte azioni da svolgere per rimuovere ostacoli.

Occorre considerare di limitare il numero di azioni in base alla capacità del team, in termini di disponibilità di risorse, di migliorare nella successiva iterazione o periodo di lavoro. Il tentativo di migliorare molte cose contemporaneamente senza finirne nessuna è molto peggiore rispetto a pianificare un minor numero di attività e completarle con successo. Poi, quando il tempo lo consente, il team può lavorare sull’opportunità di miglioramento successiva in elenco. Quando il team seleziona i miglioramenti, occorre decidere come misurare i risultati. Poi, nel periodo successivo, serve misurare i risultati per convalidare il successo o il fallimento di ciascun miglioramento.

Un facilitatore del team lo aiuta a classificare l’importanza di ogni azione di miglioramento. Quando i miglioramenti sono prioritizzati dal team, quest’ultimo sceglie il numero appropriato di azioni su cui lavorare nell’iterazione successiva (o aggiunge lavoro al flusso in caso di lavoro flow-based).

52 Sezione 5

5.2.2 PREPARAZIONE DEL BACKLOG

Il backlog è l’elenco ordinato di tutto il lavoro, presentato sotto forma di story, per un team. Non occorre creare tutte le story per l’intero progetto prima dell’inizio del lavoro: servono solo quelle sufficienti per comprendere a grandi linee il primo rilascio e quindi quelle necessarie per l’iterazione successiva.

I product owner (o un team di product owner che include il product manager e tutti i responsabili chiave di prodotto diquell’area di prodotto) possono costruire una product roadmap per mostrare la sequenza di deliverable prevista nel tempo. Il product owner ripianifica il piano d’azione in base a ciò che il team produce (vedere l’Appendice X3 sugli Strumenti di filtro dell’idoneità agili per esempi dei piani d’azione).

5.2.3 AFFINAMENTO DEL BACKLOG

Neiprogetti agili iteration-based, spesso il product owner lavora con il team per preparare alcune story per l’iterazione successiva durante una o più sessioni nel mezzo dell’iterazione. Lo scopo di tali riunioni è quello di definire le story a un livello sufficiente tale per cui il team comprenda in cosa consistono e quale sia la loro dimensione relativa.

Non esiste consenso su quanto debba durare questo affinamento. Esiste un continuum di:

uu Affinamento di tipo “just-in-time” per l’agile flow-based. Il team prende la card successiva dalla colonna “Da fare” e ne discute.

uu Molti team coinvolti nell’agile iteration-based dedicano 1 ora didiscussione a metà di un’iterazione di 2 settimane (il team decide una durata delleiterazioni che possa fornire feedback sufficientemente frequenti).

uu Molteplici discussioni di affinamento per team agili iteration-based. I team possono utilizzare questa soluzione quando sono nuovi al prodotto, all’area del prodotto o al dominiodel problema.

SU

GG

ERIM

ENTO

Considerate l’utilizzo della mappatura degli impatti per vedere come il prodotto risulta assemblato. In circostanze normali, è il product owner a gestire questo lavoro. Un servant leader può facilitare le riunioni necessarie come modo per servire il progetto.

53

Le riunioni di affinamento consentono al product owner di proporre al team delle story e al team di apprendere le potenziali opportunità o problemi associati ad esse. Se il product owner è incerto riguardo alle relazioni di dipendenza, può richiedere al team uno spike sulla funzionalità per comprenderne i rischi.

Sono numerosi i modi in cui il product owner può condurre riunioni di preparazione e affinamento del backlog, tra cui ad esempio:

uu Incoraggiare il team a lavorare come triade di sviluppatore, tester e business analyst/product owner per discutere e scrivere la story.

uu Presentare il concept generale della story al team. Il team la discute e la affina in tante story quante sono necessarie.

uu Collaborare con il team per trovare vari modi per esplorare e scrivere insieme le story, accertandosi che tutte le story siano sufficientemente piccole da far sì che il team possa produrre un flusso costante di lavoro completato. Cercare di essere in grado di completare una story almeno una volta al giorno.

Spesso i team si fissano come obiettivo quello di dedicare non più di un’ora a settimana all’affinamento delle story per il lotto di lavoro successivo. I team mirano a massimizzare il tempo dedicato all’esecuzione del lavoro rispetto al tempo dedicato alla pianificazione del lavoro. Se il team deve dedicare più di un’ora a settimana all’affinamento delle story, può essere che il product owner abbia dedicato troppo tempo alla preparazione o che il team manchi di alcune competenze chiave per valutare e perfezionare il lavoro.

5.2.4 DAILY STAND-UP

I gruppi utilizzano gli stand-up per impegnarsi reciprocamente su micro attività, portare alla luce i problemi e garantire che il lavoro scorra agevolmente nel team.

Prevedere non oltre 15 minuti per lo stand-up. Il team analizza la lavagna delle attività o Kanban; qualsiasi membro del team può facilitare lo stand-up.

Nell’agile iteration-based, tutti rispondono alle seguenti domande a turno:

uu Cosa ho portato a termine dall’ultimo stand-up?

uu Cosa prevedo di completare da qui al il prossimo stand-up?

uu Quali sono i miei ostacoli (o rischi, o problemi)?

54 Sezione 5

Domande come queste generano risposte che consentono al team di auto-organizzarsi e ritenersi responsabile l’uno nei confronti dell’altro del completamento del lavoro concordato il giorno precedente e nel corso dell’iterazione.

L’agile flow-based ha un approccio diverso agli stand-up, concentrandosi sull’efficienza produttiva del team. Il team valuta la lavagna da destra a sinistra. Le domande sono:

uu Cosa dobbiamo fare per portare avanti questa parte di lavoro?

uu Qualcuno sta lavorando su qualcosa che non è sulla lavagna?

uu Di cosa abbiamo bisogno come team per finire?

uu Vi sono colli di bottiglia od ostacoli al flusso del lavoro?

Uno degli anti-pattern tipici degli stand-up è che diventino riunioni di avanzamento lavori. I team che hanno tradizionalmente lavorato in un ambiente predittivo possono tendere a cadere in questo anti-pattern poiché sono abituati a fornire uno stato di avanzamento.

Un altro anti-pattern tipicamente osservato negli stand-up è che il team inizi a risolvere i problemi non appena diventano evidenti. Gli stand-up servono a rendersi conto dell’esistenza dei problemi, non a risolverli. Aggiungere le questioni a un parking lot e successivamente organizzare un’altra riunione, che può essere fissata subito dopo lo stand-up, durante la quale l’obiettivo è risolvere i problemi.

I team gestiscono i propri stand-up. Se ben gestiti, gli stand-up possono essere molto utili, a condizione che la natura del lavoro del team richieda un’intensa collaborazione. Occorre prendere una decisione consapevole riguardo a quando il team ha bisogno o può utilizzare efficacemente gli stand-up.

SU

GG

ERIM

ENTO

Incoraggiate tutti i membri del team a facilitare lo stand-up sostituendosi al Project Manager o leader, per garantire che non si trasformi in una riunione sullo stato di avanzamento, ma che questo tempo venga utilizzato per l’auto-organizzazione del team e per prendere impegni reciproci.

55

5.2.5 DIMOSTRAZIONI/REVISIONI

Man mano che il team completa le funzionalità - solitamente sotto forma di user story - dimostra regolarmente che il prodotto funzioni. Il product owner assiste alla dimostrazione e accetta o rifiuta le story.

Nell’agile iteration-based, il team presenta tutto il lavoro completato al termine dell’iterazione. Nell’agile flow-based, il team dimostra il lavoro completato quando è il momento di farlo, solitamente quando un numero sufficiente di funzionalità è disponibile e costituisce un insieme coerente. I team, incluso il product owner, hanno bisogno di sapere quanto in anticipo richiedere feedback sul prodotto.

Come indicazione generale, occorre presentare qualsiasi cosa il team ha come prodotto funzionante almeno una volta ogni due settimane. Si tratta di una frequenza sufficiente per la maggior parte dei team, affinché i membri del gruppo possano ottenere feedback che impediscano loro di andare nella direzione sbagliata. Tale frequenza è anche sufficiente a far sì che il team possa mantenere lo sviluppo del prodotto sufficientemente pulito per costruire un prodotto completo con la frequenza necessaria o desiderata.

Una parte fondamentale che rende un progetto agile è il rilascio frequente di un prodotto funzionante. Un team che non effettua dimostrazioni o rilasci non può apprendere in modo sufficientemente rapido e probabilmente non sta adottando tecniche agili. Il team può richiedere un coaching aggiuntivo per facilitare rilasci frequenti.

5.2.6 PIANIFICAZIONE PER L’AGILE ITERATION-BASED

La capacità produttiva di ciascun team è diversa. Le dimensioni tipiche delle story di ogni product owner sono diverse. I team devono considerare le dimensioni delle loro story in modo da evitare di impegnarsi su un numero di story maggiore di quanto il team ne possa completare in un’iterazione.

Quando le persone non sono disponibili (ad es. festività, vacanze o qualsiasi cosa impedisca di partecipare alle successive attività), il product owner capisce che il team ha una ridotta capacità produttiva. Il team non sarà in grado di portare a termine la stessa quantità di lavoro conclusa nel periodo di tempo precedente. Quando i team hanno una capacità produttiva ridotta, pianificheranno solo il lavoro che tale capacità produttiva può coprire.

I team stimano ciò che possono completare, il che diventa una misura della propria capacità produttiva (vedere la Sezione 4.10 per esempi). I team non possono prevedere con certezza assoluta ciò che possono rilasciare perché non possono conoscere l’imprevisto. Quando i product owner creano story più piccole e i team vedono l’avanzamento sotto forma di un prodotto finito, apprendono ciò che sono in grado di fare per il futuro.

I team agili non pianificano solo una volta in un singolo lotto di lavoro. Al contrario, essi pianificano un po’, rilasciano, apprendono e poi ripianificano un altro po’, in un ciclo continuo.

SU

GG

ERIM

ENTO

Richiamate l’attenzione del team sugli anti-pattern e aiutate il team a scoprire come migliorare i propri stand-up.

56 Sezione 5

5.2.7 PRATICHE DI ESECUZIONE CHE AIUTANO I GRUPPI A RILASCIARE VALORE

Se il team non presta attenzione alla qualità, presto diventerà impossibile rilasciare qualsiasi cosa in tempi brevi.

Le seguenti pratiche tecniche, molte delle quali provenienti dall’eXtreme Programming, possono aiutare il team a rilasciare i prodotti con la massima velocità:

uu Integrazione continua. Eseguire una frequente integrazione del lavoro svolto nel tutto, indipendentemente dal prodotto, e quindi procedere a un nuovo test per determinare se l’intero prodotto funzioni ancora come previsto.

uu Testare a tutti i livelli. Utilizzare un collaudo a livello di sistema per informazioni end-to-end e test unitari per i singoli elementi costitutivi. Tra i due test, è importante valutare se vi sia esigenza di un collaudo integrato e in quale punto. I team trovano utile la prova del fumo come primo sguardo al prodotto per vedere se è minimamente buono. I team hanno riscontrato che la decisione di quando e quali test di regressione eseguire li aiuta a mantenere le prestazioni del prodotto di buona qualità. I team agili hanno una spiccata preferenza per i test automatizzati che consentono di creare e mantenere una costante spinta al rilascio.

uu Acceptance test-driven development (ATDD, sviluppo guidato dai test di accettazione). Nell’ATDD, l’intero team si riunisce e discute dei criteri di accettazione per un prodotto del lavoro. Quindi, il team crea i test per consentire di scrivere codice e test automatizzati sufficienti per soddisfare i criteri. Per i progetti diversi dallo sviluppo software, occorre considerare come testare il lavoro man mano che il team completa elementi di valore.

uu Test-Driven Development (TDD, sviluppo guidato dai test) e Behavior-Driven Development (BDD, sviluppo guidato dal comportamento). La scrittura di test automatizzati prima della scrittura/creazione del prodotto aiuta le persone a progettare e rendere a prova di errore il prodotto. Per i prodotti diversi dal software, considerare come rendere test-drive la progettazione del team. I progetti hardware e meccanici spesso utilizzano simulazioni per i test temporanei delle progettazioni.

uu Spike (ricerche o esperimenti in un intervallo temporale). Gli spike sono utili per l’apprendimento e possono essere utilizzati in circostanze quali: stima, definizione dei criteri di accettazione e comprensione del comportamento di un utente attraverso il prodotto. Sono utili quando il team ha bisogno di apprendere alcuni elementi tecnici o funzionali critici.

57

5.2.8 IN CHE MODO ITERAZIONI E INCREMENTI CONTRIBUISCONO AL RILASCIO DI UN PRODOTTO FUNZIONANTE

Le iterazioni aiutano un team a creare una cadenza per rilasci e per molti tipi di feedback. I team producono incrementi di valore per il rilascio e per i feedback. La prima parte di questo rilascio è una dimostrazione. I team ricevono feedback riguardo all’aspetto e al funzionamento del prodotto attraverso una demo. I membri del team eseguono una retrospettiva per vedere come ispezionare e adattare il proprio processo perché abbia successo.

Le dimostrazioni o le revisioni sono una parte necessaria del flusso di un progetto agile. Occorre schedulare le dimostrazioni secondo la cadenza di rilascio definita dal team.

5.3 RISOLUZIONE DEI PROBLEMI NEI PROGETTI AGILI

Gli approcci agili nascono dall’esigenza di risolvere questioni associate ad alti tassi di cambiamento, incertezza e complessità dei progetti. A causa di queste origini, contengono una varietà di strumenti e tecniche per gestire le questioni che presentano problemi negli approcci predittivi. Fare riferimento alla Tabella 5-1.

SU

GG

ERIM

ENTO

I team dovrebbero effettuare demo spesso per ricevere feedback e mostrare l’avanzamento. Incoraggiate il PMO e le altre parti interessate ad assistere alle dimostrazioni in modo che i responsabili decisionali in merito al portfolio del progetto possano vedere l’avanzamento effettivo.

58 Sezione 5

Tabella 5-1. Punti deboli dell’agile e possibilità di risoluzione dei problemi

Punto debole Possibilità di risoluzione dei problemi

Scopo o missione poco chiari per il team

Accordi di lavoro poco chiari per il team

Contesto del team poco chiaro

Requisiti poco chiari

Scarsa user experience

Stima inaccurata

Assegnazione del lavoro o avanzamento del lavoro poco chiari

Il team incontra degli ostacoli

Ritardi/sforamenti del lavoro a causa di voci del product backlog non suf�cientemente perfezionate

Difetti

Il lavoro non è completo.

Debito tecnico (degradata qualità del codice)

Uf�cializzazione agile dello scopo: visione, missione e test della missione

Uf�cializzazione agile sull’allineamento: valori, principi e accordi di lavoro

Uf�cializzazione agile sul contesto: limiti, asset impegnati e analisi delle prospettive

Aiutare sponsor e stakehoder a produrre una visione del prodotto. Considerare la creazione di un piano d’azione correlato al prodotto utilizzando l’approccio Speci�cation by Example, mappatura delle user story e mappatura degli impatti. Riunire il team e il Product Owner per chiarire le aspettative e il valore di un dato requisito. Decomporre progressivamente il piano d’azione in backlog di requisiti concreti più piccoli.

Le pratiche di progettazione della user experience adottate dal team di sviluppo coinvolgono gli utenti in anticipo e spesso.

Ridurre le dimensioni delle story dividendole. Utilizzare una stima relativa condivisa con l’intero team. Considerare la modellazione agile o l’utilizzo di spike per comprendere cos’è la story.

Aiutare il team a comprendere che autogestisce il proprio lavoro. Considerare l’uso di lavagne Kanban per vedere il �usso di lavoro. Considerare un daily stand-up per analizzare la lavagna e vedere dove il lavoro è collocato.

Un servant leader può aiutare a eliminare tali ostacoli. Se il team non conosce le opzioni a disposizione, prendere in considerazione l'adozione di un coach. A volte, il team ha bisogno di procedere all’escalation di problemi sulle story che il team leader o il servant leader non è stato in grado di eliminare.

Il product owner e il team realizzano insieme workshop dedicati alle story. Creare una De�nition of Ready per le story. Considerare la scomposizione delle story in story più piccole.

Considerare le pratiche tecniche che funzionano per l’ambiente. Alcune possibilità sono: lavoro in coppia, responsabilità collettiva del prodotto, test pervasivo (approcci di collaudo automatizzati e guidati dai test) e una robusta De�nition of Done.

Il team de�nisce la De�nition of Done per le story, inclusi i criteri di accettazione. Aggiungere anche i criteri di rilascio per i progetti.

Refactoring, modellazione agile, test pervasivo, analisi automatica della qualità del codice, De�nition of Done

59

Tabella 5-1. Punti deboli dell’agile e possibilità di risoluzione dei problemi (cont.)

Punto debole Possibilità di risoluzione dei problemi

Eccessiva complessità del prodotto

Miglioramento lento o assente nel processo di lavoro del team

Troppo lavoro svolto anticipatamente che comporta rilavorazione

False partenze, impegno sprecato

Voci di product backlog ordinate in modo non ef�ciente

Flusso di lavoro non uniforme che crea urgenza/attesa

Richieste impossibili di stakeholder

Ritardi inattesi o imprevisti

Team a silos, invece che interfunzionali

Per software e non software, incoraggiare il team a pensare sempre: “Qual è la cosa più semplice che può funzionare?" e applicare il principio agile della "Semplicità: l’arte di massimizzare la quantità di lavoro non svolta". Ciò contribuisce a ridurre la complessità.

Concentrarsi su non più di tre voci da migliorare a ogni retrospettiva. Chiedere al servant leader di aiutare il team ad apprendere come integrare tali voci.

Invece di svolgere molto lavoro in anticipo, considerare degli spike che consentono al team di apprendere. Inoltre, misurare il WIP �n dall’inizio del progetto e vedere quali sono le opzioni del team per generare valore invece di sola documentazione. Abbreviare le iterazioni e creare una solida “De�nition of Done”.

Chiedere al product owner di diventare parte integrante del team.

Classi�care secondo valore, incluso il costo del ritardo diviso per la durata (CD3) e altri modelli di misurazione del valore

Programmare in base alla capacità produttiva del team senza superarla. Chiedere di interrompere il multitasking e di dedicarsi a un singolo team. Chiedere al team di lavorare in coppie, fare swarming o fare mobbing per uniformare le abilità all’intero gruppo.

Servant leadership per lavorare con lo stakeholder (e possibilmente product owner).

Chiedere al team di effettuare controlli più frequenti, utilizzare lavagne Kanban per vedere il �usso di lavoro e i limiti del WIP per comprendere l’impatto delle richieste sul team o sul prodotto. Monitorare anche gli impedimenti e la relativa eliminazione su un’apposita lavagna.

Chiedere alle persone che fanno parte del team di progetto di auto-organizzarsi in modo interfunzionale. Utilizzare le competenze di servant leadership per aiutare i manager a comprendere perché l’agile ha bisogno di gruppi interfunzionali.

60 Sezione 5

5.4 MISURAZIONI NEI PROGETTI AGILI

La transizione all’agile comporta l’uso di diverse misurazioni. Utilizzare l’agile significa considerare nuove metriche che sono importanti per il team e per il management. Queste metriche sono importanti perché si incentrano sul valore per il cliente.

Un problema del reporting dello stato avanzamento è l’abilità del team di prevedere il completamento o di utilizzare dei semaforo per descrivere lo stato del progetto. Ad esempio, i leader del progetto dichiarano cheil progetto è completato al 90%. A quel punto il team prova a integrare i pezzi in un prodotto unico. Il team scopre requisiti mancanti o sorprese, o che il prodotto non si integra come pensava.

Il progetto è svolto solo in parte, e lo stato dei semafori non riflette lo stato reale. Troppo spesso, il team di progetto realizza che avrà bisogno di molto tempo per completare il resto del progetto. Per troppi progetti, il team si rende conto di essere al massimo al 10% del lavoro completato a causa di questioni che il team ha scoperto.

Il problema delle misurazioni predittive è che spesso non riflettono la realtà. Accade spesso che il semaforo sia verde fino a un mese prima della data di rilascio; questo progetto viene talvolta chiamato progetto anguria (verde all’esterno e rosso all’interno). Spesso il semaforo diventa rosso senza nessuna avvisaglia, poiché non esistono dati empirici riguardo al progetto fino a un mese prima della data di rilascio.

Le metriche per i progetti agili contengono informazioni importanti che forniscono uno storico, dal momento che i progetti agili forniscono valore (lavoro finito) con regolarità. I team di progetto possono utilizzare tali dati per migliorare le previsioni e i processi decisionali.

Misurazioni sostitutive quali la percentuale di completamento sono meno utili rispetto a misurazioni empiriche quali le funzionalità finite. Vedere la Sezione 4.10 per ulteriori informazioni sulla gestione del valore. Agile aiuta i team a individuare problemi e questioni in modo che possano essere diagnosticati e risolverlti.

In aggiunta alle misure quantitative, il team può prendere in considerazione la raccolta di misure qualitative. Alcune di queste misure qualitative si incentrano sulle pratiche scelte dal team e valutano in che misura il team utilizza tali pratiche, ad esempio la soddisfazione dei referenti aziendali in merito alle funzionalità fornite, il morale del team e qualsiasi altro aspetto che il team voglia monitorare come misura qualitativa.

61

5.4.1 RISULTATI DELLA MISURAZIONE DEI GRUPPI AGILI

Agile favorisce misurazioni empiriche e basate sul valore invece di misurazioni predittive. Misura ciò che il team rilascia effettivamente, non ciò che il team prevede di rilasciare.

Un team abituato ad avere baseline di progetto, stime dell’earned value e del ROI può essere disorientato nel lavorare su un progetto e non gestire una baseline. L’agile si basa suprodotti funzionanti di dimostrabile valore per i clienti.

Le baseline sono spesso un manufatto derivante da un tentativo di previsione. Nell’agile, il team limita le stime al massimo alle settimane immediatamente successive. Nell’agile, se esiste una bassa variabilità nel lavoro del team e se i membri del team non operano in modalità multitasking, la capacità produttiva del team può diventare stabile. Ciò consente una migliore predizione per le due settimane successive.

Dopo aver completato il lavoro in una iterazione o in un flusso, il team può ripianificare. L’Agile non aumenta l’abilità di svolgere più lavoro. Tuttavia, è dimostrato che più piccolo è il blocco di lavoro da fare, maggiore è la probabilità che le persone lo rilascino.

Lo sviluppo di un prodotto software, come qualsiasi altro lavoro basato sulla conoscenza, implica apprendimento – apprendimento mentre si rilascia valore. Lo sviluppo hardware e meccanico è simile nelle parti di progettazione del progetto. L’apprendimento avviene sperimentando, rilasciando piccoli incrementi di valore e ottenendo feedback su ciò che è stato completato fino a quel momento. Anche molti altri progetti di sviluppo di prodotti prevedono apprendimento.

Generalmente gli sponsor desiderano sapere quando il progetto sarà terminato. Una volta che il team ha stabilito una velocity affidabile (numero medio di story o di story point per iterazione) o il tempo medio del ciclo, può prevedere quanto tempo il progetto richiederà.

Ad esempio, se il team ha una media di 50 story point per iterazione e il team stima che vi sono altri 500 story point rimanenti, stimerà di avere circa 10 iterazioni rimanenti. Quando il product owner perfeziona le story rimanenti e il team perfeziona le sue stime, la stima di progetto può salire o scendere ma il team resta in grado di fornire una stima.

Se il team ha un ciclo medio di tre giorni per story e vi sono 30 story rimanenti, il team avrà 90 giorni lavorativi rimanenti, circa 4-5 mesi di calendario.

Occorre riflettere la variabilità della stima con grafici Hurrican-style o con altre misure di variabilità che gli sponsor possano comprendere.

62 Sezione 5

Proprio perchè l’apprendimento è una parte così importante del progetto, il team deve bilanciare l’incertezza e fornire valore ai clienti. Il team pianifica la prossima piccola parte di progetto. Il team rendiconta i dati empirici di andamento e ripianifica ulteriori piccoli incrementi per gestire l’incertezza del progetto.

Alcuni progetti iteration-based utilizzano i grafici burn-down per vedere dove il progetto sta andando nel tempo. La Figura 5-1 mostra un esempio di un grafico burn-down in cui il team ha pianificato di rilasciare 37 story point. Gli story point stimano il lavoro corrispondente, il rischio e la complessità di un requisito o di una story. Molti team agili utilizzano gli story point per stimare l’impegno. La linea tratteggiata del grafico burn-down rappresenta il piano. Nella Figura 5-1, il team può vedere che è a rischio per il rilascio dal Giorno 3.

Figura 5-1. Grafico burn-down per gli story point rimanenti

StoryPointrimanenti

LEGENDA

Giorno1

40

35

30

25

20

15

10

5

0Giorno

2Giorno

3Giorno

4Giorno

5Giorno

6Giorno

7Giorno

8Giorno

9Giorno

10

Story Point rimanenti

63

Alcuni team di progetto preferiscono i grafici burn-up. Gli stessi dati utilizzati nella Figura 5-1 sono mostrati nella Figura 5-2 in un grafico burn-up.

Figura 5-2. Grafico burn-up che mostra gli story point completati

I grafici burn-up mostrano il lavoro completato. I due grafici nelle Figure 5-1 e 5-2 si basano sugli stessi dati ma visualizzati in due modi diversi. I gruppi possono scegliere come visualizzare i propri dati.

Quando un team vede ciò che non ha ancora completato mentre lavora su un’iterazione, può scoraggiarsi e affrettarsi a completare il lavoro da fare senza soddisfare i criteri di accettazione. Tuttavia, il team può avere diverse buone ragioni per non completare il lavoro da fare secondo le attese. I grafici burn-down mostrano l’effetto del multitasking dei membri del team, di story troppo grandi o di membri del team assenti.

LEGENDA

Giorno1

35

30

25

20

15

10

5

0Giorno

2Giorno

3Giorno

4Giorno

5Giorno

6Giorno

7Giorno

8Giorno

9Giorno

10

StoryPointcompletati

Story Point completati

64 Sezione 5

Soprattutto nei gruppi nuovi all’agile, i grafici burn-up mostreranno i cambiamenti all'ambito durante una iterazione. I grafici burn-up consentono ai team di visualizzare ciò che hanno completato, fatto che li aiuta a procedere con la parte di lavoro successiva.

Sia che i team utilizzino grafici burn-down o grafici burn-up, possono vedere ciò che hanno completato man mano che l’iterazione progredisce. Al termine dell’iterazione, possono basare la successiva misurazione della capacità produttiva (il numero di story o story point) su ciò che hanno completato nell’iterazione in corso. Ciò consente al product owner di ripianificare insieme al team che cosa ha maggiori probabilità di essere rilasciato con successo nell’iterazione successiva.

La velocity, ovvero la somma delle dimensioni degli story point delle funzionalità effettivamente completata nell’iterazione, consente al team di pianificare la capacità produttiva futura in modo più accurato, osservando le proprie prestazioni storiche.

I team agili flow-based utilizzano diverse misurazioni: il lead time (il tempo totale necessario per rilasciare un elemento, misurato dal momento in cui esso viene aggiunto alla lavagna fino al momento in cui viene completato), il tempo di ciclo (il tempo richiesto per lavorare un elemento) e il tempo di risposta (il tempo di attesa di un elemento prima dell’inizio della sua lavorazione). I team misurano il tempo di ciclo per vedere colli di bottiglia e ritardi, non necessariamente all’interno del team.

SU

GG

ERIM

ENTO

I team potrebbero scoprire che possono essere necessarie da quattro a otto iterazioni per raggiungere una velocity stabile. I team hanno bisogno di feedback da ciascuna iterazione per apprendere in merito a come lavorano e a come possono migliorare.

65

Lavagna Kanban

Pronto Sviluppo etest unitario

Sviluppocompletato

Test disistema Fatto

8 3 2 Tempo di ciclo: dal momento in cui si inizia un’attività al suo completamento.

Lead Time: dal momento di inserimento sulla lavagna fino al completamento. Dal momento che è possibile modificare l’ordine delle voci nella colonna “Pronto”, il Lead Time può essere imprevedibile.

C’è un limite in questa colonna. È possibile aggiungere e togliere elementi in qualsiasi momento.

Rilascio al cliente

Figura 5-3. Esempio di una lavagna Kanban

66 Sezione 5

Il lead time è utile per comprendere il tempo di ciclo dal momento in cui una particolare funzionalità viene considerata sulla lavagna e il tempo necessario per rilasciare la funzionalità al cliente. I limiti del Work in Progress (WIP) in cima a ogni colonna, mostrati qui nelle caselle, consentono al team di vedere come tirare in avanti il lavoro sulla lavagna. Quando il team ha raggiunto i suoi limiti WIP, non può portare il lavoro a sinistra nella colonna successiva di destra. Al contrario, il team lavora dalla colonna destra più carica e si chiede: “Cosa facciamo come team per spostare questo lavoro nella colonna successiva?”

Ogni funzionalità è unica, quindi il suo tempo di ciclo è unico. Tuttavia, un product owner può notare che funzionalità più piccole hanno tempi di ciclo ridotti. Il product owner desidera avere visibilità sull’efficienza produttiva, quindi crea funzionalità più piccole o collabora con il team per raggiungere questo obiettivo.

Grafici burn-up, grafici burn-down (misure di capacità produttiva), lead time e tempo di ciclo (misure di prevedibilità) sono utili per le misurazioni alla data. Esse aiutano i team a comprendere quanto altro lavoro devono svolgere e se potranno finire o meno in tempo.

La misurazione degli story point non è uguale alla misurazione delle story o delle funzionalità completate. Alcuni team tentano di misurare gli story point senza completare le funzionalità o le story effettive. Quando i gruppi misurano solo gli story point, essi misurano la capacità produttiva e non il lavoro finito, il che viola il principio “la misura primaria dell’avanzamento è il software funzionante” (o altro prodotto, se non si tratta di software).

Ogni team ha una sua capacità produttiva. Quando un team utilizza gli story point, fare attenzione al fatto che il numero di story point che un team può completare in un determinato tempo è unico per il team in questione.

SU

GG

ERIM

ENTO Quando i team dipendono da persone o gruppi esterni, misurano il tempo di ciclo per vedere quanto

tempo è necessario al team per completare il lavoro. Occorre misurare il lead time per vedere le dipendenze esterne dopo che il team ha completato il lavoro. I team possono anche misurare il tempo di reazione, il tempo di passaggio dalla colonna “pronto” alla colonna successiva, per vedere di quanto tempo hanno bisogno, in media, per rispondere a nuove richieste.

67

Quando i team forniscono le proprie misure, sono maggiormente in grado di valutare, stimare e rilasciare il proprio lavoro. Lo svantaggio della stima relativa è che non esiste un modo per confrontare i team tra loro o di aumentare la velocity tra di essi.

Il team può misurare il lavoro completato della funzionalità in un grafico burn-up/burn-down e in un grafico burn-up del product backlog. Questi grafici forniscono tendenze di completamento nel tempo, come mostrato nella Figura 5-4.

Figura 5-4. Grafico delle funzionalità

I grafici burn-up/burn-down possono evidenziare che i requisiti sono aumentati nel corso del progetto. La linea “funzionalità completate” mostra che il team procede con ritmo regolare. La linea “funzionalità totali” mostra come esse sono cambiate nel progetto nel corso del tempo. La linea burn down “numero delle funzionalità rimanenti” mostra che il tasso di completamento delle funzionalità varia. Ogni volta che si aggiungono funzionalità al progetto, la linea di burn-down cambia.

Nell’Agile, l’earned value si basa sulle funzionalità finite, come mostrato nella Figura 5-5. Il grafico burn-up del product backlog mostra il lavoro completato in confronto al lavoro totale previsto a intervalli di milestone o iterazioni.

700

600

500

400

300

200

100

0

Numero di funzionalità rimanenti

Funzionalità complete, rimanenti e totali

Numero di funzionalità complete

Numero totale di funzionalità

Funz

iona

lità

Tempo

LEGENDA

68 Sezione 5

Figura 5-5. Grafico burn-up del product backlog

Un team può terminare una sola story alla volta. Per completare una grande funzionalità che contiene diverse story, il team dovrà completare le story rimanenti e potrebbe non completare l’intera funzionalità fino a quando sono trascorsi altri periodi di tempo. Il team può mostrare il valore completato con un grafico burn-up del product backlog come mostrato nella Figura 5-5.

Se un team deve misurare l’earned value, può prendere in considerazione l’uso del grafico burn-up nella Figura 5-6 come esempio: Notare che l’asse Y a sinistra rappresenta gli story point come ambito, e l’asse Y a destra rappresenta la spesa di progetto.

Data iterazione o di scadenza intermedia

Funz

iona

lità

cum

ulat

ive

FS 3

FS 2

FS 1

FS 3

FS 2

FS 1

FS 3

FS 2

FS 1

FS 3

FS 2

FS 1

FS 3

FS 2

FS 1

69

Figura 5-6. Earned Value in un contesto agile

Le tradizionali metriche EVM come l’indice di efficienza della schedulazione (SPI) e l’indice di efficienza dei costi (CPI) possono essere facilmente tradotte in termini agili. Ad esempio, se il team ha programmato di completare 30 story point in un’iterazione ma ne ha completati solo 25, l’SPI sarà 25/30 o 0,83 (il team sta lavorando solo all’83% del tasso pianificato). Analogamente, il CPI è l’earned value (valore delle funzionalità completate) alla data attuale diviso per i costi effettivi alla data attuale o come mostrato nella Figura 5-6, 2,2/2,8 milioni di dollari = 0,79. Ciò significa un risultato di soli 79 centesimi per dollaro rispetto al piano (ma naturalmente ciò presume che la previsione sia ancora corretta).

1/10/13 1/2/14 1/5/14 1/10/14 1/2/15 1/5/15 1/10/15 1/2/16 1/5/16 1/10/16 1/2/17 1/5/17

3.000

2.500

2.000

1.500

1.000

500

0

$6.000.000

$5.000.000

$4.000.000

$3.000.000

$2.000.000

$1.000.000

$0

Avanzamento progetto ABCAm

bito

(pu

nti) Spesa

Avanzamento previsto Ambito realizzato Spesa prevista Spesa

Costo effettivo (AC)

Valore piani�cato (PV)

Earned Value (EV)

Scostamentodei tempi (SV)

Scostamentodei costi (CV)

PREVISIONE

FATTURAZIONE

CONTRATTI

VENDITE

SCORTE

CONFIGURAZIONE

REPORTING

INTERFACCIA SAP

CPI =Earned ValueCosti effettivi

SPI =Funzionalità completateFunzionalità piani�cate

LEG

ENDA

70 Sezione 5

Un diagramma del flusso cumulativo, illustrato nella Figura 5-7, mostra il lavoro in corso su una lavagna. Se un team ha molte story in attesa del collaudo, la fascia di test si ingrosserà. L’accumulo del lavoro è visibile in un attimo.

I team hanno problemi quando il lavoro si accumula: è presente Work in Progress invece di lavoro completato. Quando i team hanno molto Work in Progress, ritardano il rilascio complessivo della funzionalità. Più lungo è il tempo necessario al team per rilasciare, maggiore sarà la pressione sul team per ulteriori funzionalità nello stesso periodo di tempo.

Figura 5-7. Diagramma di flusso cumulativo delle funzionalità completate

Adattare questo flusso cumulativo alla lavagna delle attività del progetto.

20

18

16

14

12

10

8

6

4

2

0

Funz

iona

lità

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Coda Analisi Sviluppo Test Rilascio

Mesi

LEG

ENDA

Tempo di risposta

Lead Time

Tempo di ciclo

Lavoro in coda

Lavoro residuo

Lavorocom

pletato

71

6CONSIDERAZIONI ORGANIZZATIVE SULL’AGILITÀ NEI PROGETTI

Ogni progetto si colloca in un contesto organizzativo. Culture, strutture e politiche organizzative possono influenzare sia la direzione che l’esito di qualunque progetto. Tali dinamiche possono mettere alla prova i leader di progetto.

Sebbene questi ultimi possano non avere la capacità di modificare le dinamiche organizzative, ci si aspetta da loro che sappiano gestirle abilmente.

Questa sezione esplora il modo in cui l’organizzazione e, in alcune circostanze, il contesto progettuale influenzano i progetti. I leader possono esplorare diverse alternative di cambiamento per aumentare la probabilità di successo del progetto.

6.1 GESTIONE DEL CAMBIAMENTO ORGANIZZATIVO

La gestione del cambiamento organizzativo copre le competenze e le tecniche per influenzare i cambiamenti che supportano l’agilità.

La pubblicazione del PMI, Managing Change in Organizations: A Practice Guide [2], descrive un approccio completo e olistico per introdurre con successo cambiamenti significativi. Le raccomandazioni in essa suggerite comprendono:

uu Modelli per la descrizione delle dinamiche di cambiamento,

uu Schema di riferimento per realizzare il cambiamento, e

uu Applicazione delle pratiche di gestione del cambiamento a livello di progetto, programma e portfolio.

Le sezioni 6.1.1 e 6.1.2 esplorano le considerazioni sulla gestione del cambiamento specifiche per un contesto agile.

La Figura 6-1 mostra la relazione tra questi due argomenti.

L’agilità nei progetti è più efficace e robusta quando l’organizzazione si adegua per supportarla.

72 Sezione 6

Figura 6-1. La relazione tra la gestione del cambiamento e gli approcci agili

ConsiderazioniAgile

Gestione delcambiamento

Concetti descritti in Guida alle Pratiche dell’Agile

Concetti descritti inManaging Change in Organizations:

A Practice Guide

73

6.1.1 FATTORI DETERMINANTI PER LA GESTIONE DEL CAMBIAMENTO

Tutti i progetti hanno a che fare con il cambiamento. Tuttavia, vi sono due fattori principali che giustificano ulteriormente l’uso delle pratiche di gestione del cambiamento in un contesto agile:

uu Cambiamenti associati a un rilascio accelerato Gli approcci agili enfatizzano il rilascio anticipato e frequente degli output di progetto. Tuttavia, l’organizzazione ricevente potrebbe non essere pienamente preparata a integrare tali output con maggior velocità. L’accelerazione dei rilasci metterà alla prova la capacità dell’organizzazione di accoglierli. Individuare e rilasciare con successo le funzionalità di un progetto non è sufficiente. Se l’organizzazione pone resistenza a far proprio l’output di progetto, l’atteso ritorno sull’investimento sarà posticipato. L’accettazione degli output di progetto da parte del cliente e il suo allineamento con essi diventano ancora più significativi in un ambiente agile.

uu Cambiamenti associati ad approcci agili Le organizzazioni che hanno da poco iniziato a utilizzare approcci agili si devono confrontare con un alto livello di cambiamento. Più spinti livelli di collaborazione possono richiedere interscambi più frequenti tra i team, le unità organizzative o i fornitori. La scomposizione del lavoro in prototipi iterativi comporta rilavorazione che potrebbe essere considerata negativamente. I leader dovrebbero prendere in considerazione le tecniche di gestione del cambiamento per superare gli ostacoli relativi alla transizione verso approcci agili.

6.1.2 PRONTEZZA AL CAMBIAMENTO

Le organizzazioni che iniziano ad usare approcci agili dovrebbero comprenderne la compatibilità con gli approcci attualmente in uso. Alcune organizzazioni potrebbero avere caratteristiche che supportano più facilmente i principi agili della collaborazione interdipartimentale, l’apprendimento continuo e l’evoluzione dei processi interni. Esempi di queste caratteristiche aperte al cambiamento includono:

uu Apertura dell’alta direzione al cambiamento;

uu Apertura dell’organizzazione a cambiare il modo in cui considera, controlla e valuta i dipendenti;

uu Centralizzazione o decentralizzazione delle funzioni di gestione del progetto, programma e portfolio;

uu Focalizzazione su budget e metriche a breve termine rispetto agli obiettivi a lungo termine, e

uu Maturità e capacità nella gestione dei talenti.

74 Sezione 6

Al contrario, vi sono altre caratteristiche istituzionali che possono ostacolare il raggiungimento dei cambiamenti associati all’agilità dell’organizzazione. Gli esempi includono:

uu Il lavoro è frammentato su silos dipartimentali, che creano dipendenze che impediscono rilasci accelerati, invece di creare team interfunzionali supervisionati dai centri di competenza.

uu Le strategie di approvvigionamento si basano su modelli di definizione dei prezzi a breve termine invece che sulla scelta di competenze a lungo termine.

uu I leader sono premiati più su efficienze settoriali che su rilasci progettuali di flussi end-to-end o sull’ottimizzazione del tutto (rispetto all’organizzazione).

uu I dipendenti sono contributori specializzati con limitati strumenti o stimoli a diversificare le proprie competenze invece di diventare specialisti con profilo a T.

uu Portfoli decentralizzati impegnano i dipendenti simultaneamente su un numero eccessivo di progetti invece di mantenerli concentrati su un progetto alla volta.

Il grado con cui un’organizzazione è disposta a rivedere e modificare tali pratiche determinerà la rapidità e l’efficacia con cui sarà possibile adottare approcci agili. Tuttavia, in risposta a questi ostacoli organizzativi all’agilità, i leader di progetto possono tentare vari approcci per accelerare una compatibilità culturale con:

uu Sponsorizzazione dell’alta direzione visibile e proattiva,

uu Pratiche di gestione del cambiamento, tra cui gestione della comunicazione e coaching,

uu Adozione progressiva di pratiche agili progetto dopo progetto,

uu Introduzione incrementale di pratiche agili nel team, e

uu Guidare con l’esempio utilizzando tecniche e pratiche agili, ove possibile.

75

6.2 CULTURA ORGANIZZATIVA

La cultura di un’organizzazione è il suo DNA, la sua identità essenziale. La cultura influenzerà sempre l’uso di approcci agili. La cultura di un’organizzazione si colloca in un continuum, che va da pianificazioni altamente predittive a lean start-up in cui tutto è un esperimento. Sebbene gli approcci agili si adattino bene alla cultura di una lean start-up, un’organizzazione altamente predittiva può incoraggiare misurazioni empiriche, piccoli esperimenti e apprendimento in modo che possa progredire verso l’agilità.

6.2.1 CREARE UN AMBIENTE SICURO

La cultura dell'organizzazione è difficile da cambiare, ma la norma culturale più importante in un’organizzazione che desidera provare un nuovo metodo o tecnica è abilitare un ambiente di lavoro sicuro.

Solo in un ambiente sicuro, onesto e trasparente i membri del team e i leader possono davvero riflettere sui propri successi per garantire il progredire continuo dei propri progetti, o applicare le lesson learned provenienti dai progetti falliti in modo da non ricadere negli stessi errori.

6.2.2 VALUTAZIONE DELLA CULTURA

Ogni progetto si trova a dover bilanciare finalità contrapposte. In che modo il team può procedere velocemente senza compromettere la qualità? In che modo il team può salvaguardare la flessibilità anche nel rispetto di una data fissa? Aspetto più importante, in che modo il team soddisfa i requisiti del cliente?

I leader di progetto possono ritenere che il proprio lavoro consista nel soddisfare ogni aspettativa di ogni stakeholder, ma quando si è costretti a fare una scelta spesso esiste una priorità dettata dalla cultura e dalle caratteristiche del contesto aziendale. Ad esempio, un progetto di telecomunicazione mobile subisce una distorsione verso la velocità, mentre un programma in ambito governativo potrà avere una maggiore tendenza alla generalizzazione e alla stabilità.

“La cultura si mangia la strategia a colazione” — Peter Drucker

Questa affermazione sottolinea l’importanza dell’impegno e della passione delle persone per una causa. Indipendentemente dalla strategia o dal piano che implementi con il tuo team, il successo sarà decretato dalle persone coinvolte. Se le persone che governano la strategia non si appassionano al cambiamento che devono implementare o, peggio, sono apatiche rispetto al proprio lavoro e alla propria organizzazione, si hanno poche possibilità di riuscita.

76 Sezione 6

Per governare queste dinamiche, i leader di progetto dovrebbero dedicare del tempo a valutare su cosa l’organizzazione più spesso pone l’enfasi. La Figura 6-2 illustra come può essere rappresentata una valutazione. In questo esempio, un leader di progetto inizia una conversazione sulle priorità organizzative con gli stakeholder, i membri del team e la direzione. Tali priorità vengono quindi posizionate su una scala indicizzata tra due estremi. I risultati sono quindi utilizzati per individuare le tecniche agili che meglio si adattano a tali priorità.

Figura 6-2. Esempio di valutazione della cultura dell'organizzazione

Esistono diversi modelli per valutare tali dinamiche; tuttavia, il modello o il metodo utilizzato non riveste grande importanza. È più importante che i leader di progetto si impegnino a comprendere le forze che caratterizzano il contesto in cui operano. La comprensione dell’organizzazione e dei requisiti di settore a cui una organizzazione deve attenersi consente di scegliere le conversazioni giuste, i compromessi giusti e, soprattutto, le tecniche giuste.

Quantità Qualità

{Altri fattori}

Velocità Stabilità

Esecuzione

Flessibilità Prevedibilità

Esplorazione

77

6.3 APPROVVIGIONAMENTO E CONTRATTI

Come menzionato in precedenza in questa guida, l’Agile Manifesto dà maggior valore alla “collaborazione con il cliente rispetto alla negoziazione dei contratti”. Molti insuccessi nei progetti derivano dal deteriorarsi della relazione tra cliente e fornitore. I progetti vanno incontro a un maggiore rischio quando chi è coinvolto nel contratto si pone nella prospettiva di vincitori vs vinti. Un approccio è collaborativo quando persegue una relazione di condivisione rischio-guadagno, nella quale tutte le parti coinvolte risultano vincenti. Alcune tecniche di contrattualizzazione che ben formalizzano questa dinamica includono:

uu Struttura a più livelli Invece di formalizzare un’intera relazione contrattuale in un unico documento, le parti coinvolte possono ottenere maggiore flessibilità trattando aspetti diversi in documenti differenti. La maggior parte degli elementi invariabili (ad es. garanzie, arbitrato) può essere definita in un accordo quadro. Contemporaneamente, tutte le parti coinvolte elencano gli elementi soggetti a modifiche (ad es. tariffe di servizio, descrizioni dei prodotti) nell’ambito della fornitura dei servizi. Il contratto può richiamarli nell’accordo quadro. Infine, elementi più dinamici quali ambito, schedulazione e budget possono essere formalizzati in un capitolato snello. La separazione degli elementi più mutevoli di un contratto in un documento a parte semplifica le modifiche e quindi aumenta la flessibilità.

uu Enfatizzare il valore rilasciato Molte relazioni con i fornitori sono disciplinate da milestone fisse o “revisioni di fase” che si incentrano su elaborati intermedi più che su un deliverable completo di valore incrementale per l’azienda. Spesso questi controlli limitano l’uso di feedback per migliorare il prodotto. Al contrario, le milestone e i termini di pagamento possono essere strutturati in base a deliverable orientati al valore per potenziare l’agilità del progetto.

uu Incrementi a prezzo fisso Invece di racchiudere l’intero ambito e budget del progetto in un unico accordo, un progetto può scomporre l’ambito in microdeliverable a prezzo fisso, quali le user story. Per il cliente, questo offre un maggior controllo su come viene speso il denaro. Per il fornitore limita il rischio finanziario di un impegno eccessivo per realizzare una singola funzionalità o deliverable.

SU

GG

ERIM

ENTO

Cultura vs. Struttura

Alcune persone spingono la realizzazione di nuove strutture organizzative prima di iniziare qualsiasi cambiamento culturale. Altre sostengono l’opposto: la realizzazione di nuove strutture organizzative è solo un adeguamento superficiale fino a quando la cultura collettiva non si muove in una direzione significativa. In realtà, l’una non può progredire senza l’altro. I leader di progetto che desiderino conseguire agilità dovrebbero considerare lo stato attuale e futuro di entrambi tali aspetti dell’organizzazione.

78 Sezione 6

uu Time & Materials con limite fissato I clienti incorrono in rischi indesiderati a causa di un approccio tradizionale Time & Materials. Un’alternativa consiste nel limitare il budget complessivo a un importo prefissato. Ciò consente al cliente di inglobare nel progetto nuove idee e innovazioni non originariamente pianificate. Quando i clienti desiderano inglobare nuove idee, dovranno rapportarsi a una data capacità produttiva, sostituendo il lavoro iniziale con parti nuove. Il lavoro dovrebbe essere attentamente monitorato man mano che le ore allocate raggiungono il limite. Inoltre, ore aggiuntive di contingency potrebbero essere pianificate nel budget massimo complessivo, se ritenuto utile.

uu Time & Materials graduale Un’altra alternativa è un approccio condiviso al rischio finanziario. Nell’agile, i criteri di qualità sono insclusi nel significato di “done”. Di conseguenza, il fornitore può essere ricompensato con una tariffa oraria superiore quando il rilascio è antecedente la scadenza concordata. Al contrario, il fornitore potrebbe subire una decurtazione della tariffa in caso di ritardo nel rilascio.

uu Opzione di cancellazione anticipata Quando un fornitore agile fornisce valore sufficiente soltanto con la metà dell’ambito completato, il cliente non dovrebbe essere vincolato a pagare la metà restante se non ne ha più bisogno. Al contrario, un contratto può offrire al cliente di acquistare il resto del progetto in cambio di una quota di cancellazione. Il cliente limita l’esposizione di budget e il fornitore ha un ricavo per i servizi non più richiesti.

uu Opzione dell’ambito dinamico Per i contratti con budget fisso, un fornitore può offrire al cliente l’opzione di variare l’ambito del progetto in momenti specifici dello stesso. Il cliente può adeguare le funzionalità alla capacità produttiva. Il cliente può quindi sfruttare le opportunità di innovazione limitando il rischio di impegno eccessivo del fornitore.

uu Accrescimento del team Probabilmente l’approccio contrattuale più collaborativo consiste nell’integrare i servizi del fornitore direttamente nell’organizzazione del cliente. Finanziando i team piuttosto che uno specifico ambito progettuale si preserva il potere decisionale strategico del cliente in merito al lavoro che dovrebbe essere effettivamente svolto.

79

uu Favorire i fornitori che offrono un servizio completo Per diversificare il rischio, i clienti possono individuare una strategia che preveda più fornitori. Tuttavia, la tentazione sarà quella di appaltare il lavoro in modo che ogni singolo fornitore faccia una sola cosa, creando una rete di dipendenze prima che si concretizzi un qualsiasi servizio o prodotto utilizzabile. Al contrario, è preferibile porre l’enfasi su formalizzazioni contrattuali che rilascino pieno valore complessivo (come nel caso di serie di funzionalità indipendenti completate).

È inoltre possibile creare contratti agili. L’Agile si basa su una sinergia di collaborazione e fiducia. Il fornitore può contribuire rilasciando valore in anticipo e frequentemente. Il cliente può farlo fornendo un feedback tempestivo.

6.4 PRATICHE AZIENDALI

La disponibilità e capacità di creare nuove competenze in un’organizzazione quando nasce un bisogno è un segno di agilità organizzativa. Non deve trattarsi necessariamente di cambiamenti sconvolgenti e potrebbero essere meno dirompenti in un’organizzazione incentrata sull’agilità e sui risultati che fornisce. La trasparenza e la collaborazione aperta sono assolutamente fondamentali.

Con i team interfunzionali che rilasciano valore, i team e gli individui possono incontrare problemi nel rapportarsi alle varie funzioni di supporto nell’organizzazione.

Poiché i team rilasciano valore regolarmente, i dipartimenti finanziari possono avere l’opportunità di capitalizzare il prodotto in modo diverso. Se il team ha contratti con altre organizzazioni, i dipartimenti di approvvigionamento possono dover modificare tali contratti per aiutare le organizzazioni a rilasciare valore di frequente e sincronizzarsi con il team.

Una volta che i team iniziano a lavorare in modo coeso e collaborativo, metteranno alla prova le politiche gestionali interne. Il dipartimento delle risorse umane può rilevare che gli incentivi individuali acquistano meno significato, e i responsabili potrebbero avere difficoltà con le valutazioni delle prestazioni dei dipendenti che operano in gruppi auto-organizzati. In ogni caso, si tratta di opportunità per rivedere in che misura le pratiche esistenti supportano modi agili di lavorare.

Man mano che le organizzazioni progrediscono verso una maggiore agilità, anche altre unità operative aziendali dovranno ovviamente modificare il modo in cui interagiscono e assolvono le proprie responsabilità. I cambiamenti che hanno generato dei benefici in altre aree dell’organizzazione devono ora essere adottati in modo che sia possibile realizzare l’efficacia dell’intera organizzazione.

80 Sezione 6

6.5 COORDINAMENTO E DIPENDENZE MULTITEAM (SCALABILITÀ)

Molti progetti hanno dipendenze, anche quando non sono gestiti all’interno di un dato programma. Per questo motivo, è necessario comprendere come l’Agile funziona in un contesto di gestione di un programma e portfolio esistente.

6.5.1 SCHEMI DI RIFERIMENTO

Le indicazioni dei metodi agili più diffusi come Scrum ed eXtreme Programming si focalizzano sulle attività di un singolo team interfunzionale, piccolo, solitamente co-locato. Sebbene sia molto utile per attività che impegnano un unico team, questa scelta può fornire indicazioni insufficienti per iniziative che richiedono la collaborazione di più team agili in un programma o portfolio.

È emersa una serie di schemi di riferimento (quali Scaled Agile Framework, Large Scale Scrum e Disciplined Agile) e di approcci (ad es. Scrum of Scrums) proprio per soddisfare tali circostanze. Ulteriori dettagli al riguardo sono forniti nell’Allegato A3.

6.5.2 CONSIDERAZIONI

Esiste più di un modo per scalare il lavoro. Il team potrebbe avere bisogno di scalare il lavoro di diversi progetti agili in un unico programma agile. In alternativa, l’organizzazione può progettare una struttura che supporti approcci agili nell’intero portfolio.

Ad esempio, è utile iniziare in piccolo e imparare il più rapidamente possibile ciò che fornisce buoni risultati nel contesto organizzativo. I team possono raggiungere risultati di successo anche quando non tutto è completamente ricondotto a un approccio agile.

Indipendentemente dall’approccio, un fattore critico di successo è un team agile sano. Se l’utilizzo di un approccio agile per un singolo team non dà buoni risultati, non provare a scalarlo utilizzandolo a livello più ampio; al contrario, cerca di superare gli ostacoli organizzativi che impediscono ai team di lavorare in modo agile.

L’obiettivo di progetti agili su larga scala è quello di coordinare le attività di diversi team per portare valore ai clienti. Esiste più di un modo per farlo. I team possono adottare uno schema di riferimento formale o applicare il pensiero agile per adeguare le pratiche di program management esistenti.

81

6.6 AGILE E IL PROJECT MANAGEMENT OFFICE (PMO)

Il PMO esiste per supervisionare il valore per l’azienda in tutta l’organizzazione. Può farlo aiutando i progetti a raggiungere i loro obiettivi. Talvolta, il PMO educa i team (od organizza la formazione) e supporta i progetti. A volte, il PMO consiglia il management sul valore per l’azienda di un determinato progetto o gruppo di progetti.

Dal momento che l’Agile genera un cambiamento culturale, nel tempo l’organizzazione potrebbe avere bisogno di cambiare, incluso il PMO. Ad esempio, i manager prendono decisioni su quali progetti finanziare e quando, e i team decidono di cosa hanno bisogno in termini di formazione e consulenza.

6.6.1 UN PMO AGILE È UNA UNITÀ CON ORIENTAMENTO AL VALORE

Un progetto dovrebbe rilasciare il giusto valore, alla giusta audience, nel momento giusto. Lo scopo del PMO è facilitare e consentire questo obiettivo. L’approccio di un PMO agile-based è fondato su una mentalità di collaborazione con il cliente ed è presente in tutti i programmi del PMO. In molti casi, ciò significa che il PMO opera come se fosse una società di consulenza, personalizzando il suo impegno per soddisfare le esigenze specifiche richieste da un dato progetto. Alcuni progetti possono avere bisogno di strumenti e modelli, mentre altri possono beneficiare di attività di coaching. Il PMO dovrebbe tentare di fornire ciò che è necessario e tenere il polso dei clienti per assicurarsi di conoscere le loro esigenze e di essere in grado di adattarsi ad esse. Questo approccio imprenditoriale si concentra sulle attività del PMO che sono percepite come le più preziose per i progetti che il PMO è chiamato a supportare.

6.6.2 UN PMO AGILE È UNA UNITÀ CON ORIENTAMENTO ALL’INVITO

Per accelerare l’avanzamento di un progetto con charter basato sul valore, un PMO può essere tentato di imporre alcune soluzioni o approcci, ad esempio che tutti operino allo stesso modo per ottenere successi di breve termine. Tuttavia, una prospettiva di più ampio respiro risponde al desiderio di coinvolgimento dei dipendenti. Ciò si ottiene coinvolgendo nei servizi del PMO solo coloro che sono interessati. Un maggiore coinvolgimento nelle pratiche del PMO semplifica l’adesione a tali pratiche. Se il PMO sta fornendo valore ai suoi clienti, è più probabile che i clienti ne richiedano i servizi e ne adottino le pratiche.

82 Sezione 6

6.6.3 UN PMO AGILE È UNA UNITÀ MULTIDISCIPLINARE

Per supportare esigenze specifiche di progetto, il PMO deve essere competente in vari ambiti oltre al Project Management in sé, poiché progetti diversi richiedono abilità differenziate. Ad esempio, un progetto può richiedere che la progettazione organizzativa risolva i problemi di personale mentre un altro può avere bisogno di tecniche di gestione del cambiamento organizzativo per il coinvolgimento degli stakeholder o di modelli aziendali unici per supportare gli obiettivi dei clienti.

Alcune organizzazioni hanno trasformato i propri PMO in centri agili di eccellenza che forniscono servizi quali:

uu Sviluppo e implementazione di standard Fornire modelli per user story, test case, diagrammi di flusso cumulativi, ecc. Fornire strumenti agili ed educare i gruppi di supporto su concetti di sviluppo iterativo.

uu Sviluppo professionale attraverso formazione e mentoring Coordinare corsi di formazione sull’agile, di coaching e mentoring per aiutare le persone nella transizione a una mentalità agile e nell’aggiornamento delle loro competenze. Incoraggiare e supportare le persone a partecipare a eventi locali sull’agile.

uu Gestione multiprogetto Realizzare attività di coordinamento tra team agili promuovendo la comunicazione tra progetti. Considerare la possibilità di condividere elementi quali l’avanzamento, le questioni critiche, le risultanze delle retrospettive e gli esperimenti di miglioramento. Aiutare a gestire i principali rilasci al cliente a livello di programma e le tematiche di investimento a livello di portfolio usando lo schema di riferimento più appropriato.

uu Facilitare l’apprendimento organizzativo Raccogliere i profili di velocity del progetto e acquisire, archiviare e indicizzare i risultati delle retrospettive.

uu Gestire gli stakeholder Fornire al Product Owner formazione, linee guida sull’accettazione dei test e indicazioni sulle modalità di valutazione e di restituzione di feedback sui sistemi. Sostenere l’importanza degli esperti in materia (SME) per i progetti.

uu Reclutare, selezionare e valutare i team leader Sviluppare delle linee guida per le interviste con i professionisti agili.

uu Eseguire attività specialistiche nei progetti Formare e mettere a disposizione facilitatori delle retrospettive, creare accordi con risolutori di problemi nei progetti agili e mettere a disposizione mentor e coach.

83

6.7 STRUTTURA ORGANIZZATIVA

La struttura di un’organizzazione influenza fortemente la sua capacità di far leva su nuove informazioni o su esigenze di mercato in continuo cambiamento. Ecco un elenco delle principali caratteristiche:

uu Geografia Le organizzazioni di progetto distribuite a livello geografico possono trovarsi di fronte a numerose sfide che ostacolano il loro lavoro su un qualsiasi progetto. I leader di progetto e i responsabili locali possono avere obiettivi diversi o persino in competizione. In più, differenze culturali, barriere linguistiche e scarsa visibilità possono rallentare la produttività. Fortunatamente, l’uso di approcci agili può incoraggiare collaborazione e fiducia più di quanto accadrebbe altrimenti. I leader di progetto in questi contesti dovrebbero incoraggiare il dialogo sia a livello di team che a livello direzionale, al fine di adattare le tecniche al contesto e di gestire le aspettative sull’impegno necessario per farlo.

uu Strutture funzionali Alcune organizzazioni sono collocate su uno spettro che va da strutture marcatamente per progetti, a strutture a matrice e a strutture altamente funzionali. I progetti con strutture altamente funzionali possono incontrare una diffusa resistenza alla collaborazione all’interno dell’organizzazione.

uu Dimensioni dei deliverable di progetto La riduzione delle dimensioni dei deliverable di progetto induce a interscambi più frequenti tra dipartimenti, e quindi a interazioni più frequenti e a un più rapido flusso di valore nell’organizzazione.

uu Allocazione delle persone ai progetti Un altro approccio consiste nel chiedere che una singola persona di ogni dipartimento sia allocata temporaneamente ma a tempo pieno al progetto con la massima priorità.

uu Organizzazioni fortemente basate sull’approvvigionamento Alcune organizzazioni scelgono di implementare progetti perlopiù avvalendosi di fornitori. Sebbene gli obiettivi di progetto possano essere chiari, i fornitori hanno la responsabilità di tenere sotto controllo la propria sostenibilità finanziaria. In più, una volta che i fornitori adempiono ai propri obblighi e concludono l’incarico, la conoscenza maturata nel progetto se ne va con loro. Ciò impoverisce le competenze interne necessarie per poter operare con flessibilità e velocità sostenute. Tecniche agili quali le retrospettive e i follow-up su possibili aree di miglioramento quando il fornitore è ancora coinvolto, possono contribuire a mitigare la perdita di conoscenza del prodotto.

84 Sezione 6

6.8 FAR EVOLVERE L’ORGANIZZAZIONE

Quando si affronta una specifica iniziativa sfidante o si implementa un nuovo approccio ibrido o agile, si raccomanda di svolgere il lavoro in modo incrementale. Una pratica comune consiste nel trattare il processo di cambiamento come un progetto agile con un proprio backlog di azioni di cambiamento che possono essere introdotte e prioritizzate dal team in base al valore percepito o ad altre considerazioni. Ciascuna azione di cambiamento può essere trattata come un esperimento che viene testato per un breve periodo di tempo per determinare l’idoneità così com’è o l’esigenza di ulteriore affinamento/riconsiderazione.

Usare le lavagne kanban per monitorare l’avanzamento, mostrando i cambiamenti già consolidati come “done”, quelli in via di test come “in progress” e quelli in attesa di essere introdotti come “to do”. Vedere la Figura 6-3 per la lavagna iniziale con un backlog prioritizzato. La Figura 6-4 mostra un esempio di una lavagna man mano che il lavoro procede.

85

Backlog prioritizzato

Analisi azione di

cambiamento

Risoluzione azione di

cambiamento

Gestione o mitigazione dei rischi

Decisione necessaria post-azione

In attesa: Elementi bloccati

Fatto

In corso

Cambiamento1

Cambiamento2

Cambiamento3

Cambiamento4

Cambiamento5

Cambiamento6

Cambiamento7

Cambiamento8

Cambiamento9

Cambiamento10

Figura 6-3. Backlog iniziale prioritizzato delle azioni di cambiamento

86 Sezione 6

Figura 6-4. Uso dei backlog e delle lavagne kanban per organizzare e monitorare le azioni di cambiamento.

L’uso di questi strumenti per organizzare e gestire l’implementazione delle azioni di cambiamento fornisce visibilità sull’avanzamento e inoltre configura gli approcci da implementare. La messa a regime delle azioni di cambiamento in modo trasparente e accattivante migliora la loro probabilità di successo.

Backlog prioritizzato

Analisiazione di

cambiamento

Risoluzione azione di

cambiamento

Gestione o mitigazione dei rischi

Decisione necessaria post-azione

In attesa: Elementi bloccati

Fatto

In corso

Cambiamento

1

Cambiamento

2

Cambiamento

3

Cambiamento

4Cambiamento

5

Cambiamento

6

Cambiamento

7

Cambiamento

8

Cambiamento

9

Cambiamento

10

87

7CALL TO ACTION

L’adozione dell’Agile e dei suoi approcci per la gestione dei progetti è aumentata drasticamente dalla prima pubblicazione dell’Agile Manifesto nel 2001. L’adozione e il desiderio di operare con una mentalità agile non si limitano più a organizzazioni di determinate dimensioni o specializzate esclusivamente in tecnologie informatiche. La mentalità ha validità universale e gli approcci riscuotono successo in numerosi contesti.

Oggi la domanda di “essere agili” è più elevata che mai. Il dibattito su quale sia il percorso migliore verso l’agilità mantiene in costante evoluzione il confronto e l’innovazione su questo tema. Una verità resta costante: ispezione, adattamento e trasparenza restano essenziali per generare valore.

La presente guidapotrebbe non trattare tutti gli aspetti attesi. Il nostro core team è consapevole della possibilità di dissensi - anche notevoli - con alcuni elementi e approcci che si è scelto di presentare. Facciamo appello alla vostra passione per portare avanti il dibattito e migliorare la prossima iterazione di questa guida. Questo è il vostro percorso: apprendere, sperimentare, ricevere feedback e tornare a sperimentare. Quindi, aiutateci nella retrospettiva fornendoci un feedback sulle indicazioni e contribuendo alle future edizioni di questa guida. Dopotutto, l’ispezione senza adattamento è un impegno sprecato.

Infine, desideriamo incoraggiarvi a partecipare alle comunità di Project Management e Agile di maggior rilievo per portare avanti le conversazioni su questi argomenti. Cercate i rappresentanti del PMI e di Agile Alliance® in occasione di conferenze e riunioni e discutete con loro. Utilizzate i social media e i blog per esprimere i vostri pensieri e le vostre opinioni.

Potete fornire feedback e partecipare al dibattito in merito ai contenuti della presente guida sul blog “Agile in Practice” all’indirizzo https://www.projectmanagement.com/blogs/347350/Agile-in-Practice.

89

ALLEGATO A1 MAPPATURA GUIDA PMBOK ®

La Tabella A1-1 illustra la mappatura dei gruppi di processi di Project Management alle aree di conoscenza definite nella Guida PMBOK® – Sesta edizione.

Questo allegato descrive in che modo l’approccio ibrido e quello agile gestiscono gli attributi descritti nelle aree di conoscenza della Guida PMBOK® (vedere la Tabella A1-2). L’allegato tratta di ciò che resta immutato e delle differenze, insieme ad alcune linee guida da considerare per aumentare le probabilità di successo.

90 Allegato A1

Tabella A1-1. Gruppo di processi di Project Management e mappatura delle aree di conoscenza

4.1 Sviluppareil Project Charter

4.2 Sviluppare il piano di Project Management

4.3 Dirigere e gestire il lavoro del progetto4.4 Gestire le conoscenze di progetto

4.5 Monitorare e controllare il lavoro del progetto4.6 Eseguire il controllo integrato delle modi�che

4.7 Chiudereil progetto o una fase

Areedi conoscenza

Gruppi di processi di Project Management

Gruppodi processi

di pianicazione

Gruppodi processi

di esecuzione

Gruppodi processi

di avvio

Gruppodi processi

di monitoraggioe controllo

Gruppodi processidi chiusura

Gestione dell’integrazione di progetto

Gestione dell’ambito del progetto

Gestione della schedulazione del progetto

Gestione dei costi di progetto

Gestione della qualità di progetto

Gestione delle risorse del progetto

Gestione delle comunicazioni di progetto

Gestione dei rischi di progetto

Gestione dell’approvvigio-namento di progetto

Gestione degli stakeholder del progetto

4.

5.

6.

7.

8.

9.

10.

11.

12.

13. 13.1 Identi�care gli stakeholder

13.2 Piani�care il coinvolgimento degli stakeholder

13.3 Gestire il coinvolgimento degli stakeholder

13.4 Monitorare il coinvolgimento degli stakeholder

12.1 Piani�care la gestione degli approvvigionamenti

12.2 De�nire gli approvvigionamenti

12.3 Controllare gli approvvigionamenti

11.1 Piani�care la gestione dei rischi11.2 Identi�care i rischi11.3 Eseguire l’analisi qualitativa dei rischi11.4 Eseguire l’analisi quantitativa dei rischi11.5 Piani�care le risposte ai rischi

11.6 Eseguire le risposte ai rischi

11.7 Monitorare i rischi

10.1 Piani�care la gestione delle comunicazioni

10.2 Gestirele comunicazioni

10.3 Monitorare le comunicazioni

9.1 Piani�care la gestione delle risorse9.2 Stimare le risorse per le attività

9.3 Acquisire le risorse9.4 Sviluppare il gruppo di lavoro9.5 Gestire il gruppo di lavoro

9.6 Controllarele risorse

8.1 Piani�carela gestione della qualità

8.2 Gestire la qualità

8.3 Controllarela qualità

7.1 Piani�care la gestione dei costi7.2 Stimare i costi7.3 Determinare il budget

7.4 Controllare i costi

6.1 Piani�carela gestione della schedulazione6.2 De�nire le attività6.3 Sequenzializzare le attività6.4 Stimarele durate delle attività6.5 Sviluppare la schedulazione

6.6 Controllare la schedulazione

5.1 Piani�care la gestione dell’ambito5.2 Raccoglierei requisiti5.3 De�nire l’ambito5.4 Creare la WBS

5.5 Convalidare l’ambito5.6 Controllare l’ambito

91

Tabella A1-2. Applicazione di Agile nelle aree di conoscenza della Guida PMBOK®

Area di conoscenza della Guida PMBOK® Applicazione in un processo di lavoro Agile

Sezione 4Gestione dell’integrazione di progetto

Sezione 5Gestione dell’ambito del progetto

Gli approcci iterativi e agili promuovono il coinvolgimento dei membri del gruppo quali esperti locali del settore nella gestione dell'integrazione. I membri del gruppo determinano il modo in cui devono integrarsi piani e componenti.

Le aspettative dei Project Manager indicate nelle sezioni Principali concetti della gestione dell'integrazione della Guida PMBOK® non cambiano in un ambiente adattivo, ma il controllo della piani�cazione dettagliata del prodotto e della consegna è delegato al gruppo. Il Project Manager si occupa di creare un ambiente decisionale collaborativo e di garantire che il gruppo possa reagire alle modi�che. Questo approccio collaborativo può essere ulteriormente potenziato quando i membri del gruppo possiedono un'ampia base di conoscenze più che una specializzazione ristretta.

Nei progetti con requisiti in evoluzione, ad alto rischio o con un signi�cativo livello di incertezza, spesso l'ambito non è chiaro all'inizio del progetto o si evolve nel corso dello stesso. I metodi agili dedicano volutamente un tempo minore al tentativo di determinare e accordarsi sull'ambito nella fase iniziale del progetto e un tempo maggiore a stabilire il processo per una de�nizione e un af�namento continui. Molti ambienti con requisiti emergenti trovano che ci sia spesso un divario tra gli effettivi requisiti aziendali e quelli dichiarati in origine. Quindi, i metodi agili costruiscono i prototipi, li rivedono e rilasciano versioni appositamente allo scopo di af�nare i requisiti. Il risultato è una continua ride�nizione dell'ambito nel corso dell'intero progetto. Negli approcci agili, i requisiti costituiscono il product backlog.

92 Allegato A1

Tabella A1-2. Applicazione di Agile nelle aree di conoscenza della Guida PMBOK® (cont.)

Area di conoscenza della Guida PMBOK® Applicazione in un processo di lavoro Agile

Sezione 6Gestione della schedulazione del progetto

Sezione 7Gestione dei costi di progetto

Gli approcci adattivi utilizzano cicli brevi per intraprendere il lavoro, rivedere i risultati e adeguarsi secondo necessità. Questi cicli forniscono un rapido riscontro sugli approcci e sull'idoneità dei deliverable, e generalmente si manifestano come schedulazione iterativa, a richiesta e di tipo "pull", come discusso nella sezione sulle Principali tendenze e prassi emergenti per la Gestione della schedulazione di progetto nella Guida PMBO®.

Nelle grandi organizzazioni può esservi un mix di piccoli progetti e grandi iniziative che richiedono piani d'azione a lungo termine per gestire lo sviluppo di questi programmi utilizzando fattori di scala (ad es. dimensioni del gruppo, distribuzione geogra�ca, conformità normativa, complessità organizzativa e complessità tecnica). Per gestire l'intero ciclo di vita di consegna per sistemi più grandi a livello aziendale, può essere necessario adottare una serie di tecniche che utilizzano un approccio predittivo, un approccio adattivo o un ibrido di entrambi. L'organizzazione può dover combinare prassi di diversi metodi di riferimento o adottare un metodo già utilizzato, e alcuni principi e prassi di tecniche più tradizionali.

Il ruolo del Project Manager non cambia in base alla gestione dei progetti sia che utilizzino un ciclo di vita dello sviluppo predittivo che in ambienti adattivi. Tuttavia, per avere successo nell'uso di approcci adattivi, il Project Manager deve avere familiarità con gli strumenti e le tecniche per comprendere come applicarli in modo ef�cace.

I progetti con un elevato grado di incertezza o quelli in cui l’ambito non è ancora stato interamente de�nito potrebbero non trarre vantaggio da calcoli dettagliati dei costi a causa delle frequenti modi�che. Al contrario, è possibile utilizzare metodi di stima sempli�cati per generare una previsione rapida e di alto livello dei costi di manodopera del progetto, che possono essere facilmente adeguati man mano che si veri�cano cambiamenti. Le stime dettagliate sono riservate alla piani�cazione a breve termine in modalità just-in-time.

Nei casi in cui progetti ad alta variabilità siano anche soggetti a budget ridotti, l'ambito e la schedulazione sono adeguati più spesso per rientrare nei vincoli di costi.

93

Tabella A1-2. Applicazione di Agile nelle aree di conoscenza della Guida PMBOK® (cont.)

Area di conoscenza della Guida PMBOK® Applicazione in un processo di lavoro Agile

Sezione 8Gestione della qualità di progetto

Sezione 9Gestione delle risorse del progetto

Per gestire le modi�che, i metodi agili richiedono che all'interno dell'intero processo siano integrate fasi frequenti di qualità e revisione, piuttosto che riservarle per la �ne del progetto.

Le retrospettive ad intervalli regolari veri�cano in modo costante l'ef�cacia dei processi della qualità. Ricercano la causa alla radice delle questioni e in seguito suggeriscono di sperimentare nuovi approcci per migliorare la qualità. Le retrospettive successive valutano eventuali processi sperimentali per de�nire se stiano funzionando e possano essere portati avanti, se necessitino di un adeguamento oppure se non debbano più essere utilizzati.

Per facilitare la consegna frequente e incrementale, i metodi agili si concentrano su piccoli lotti di lavoro, integrando il maggior numero possibile di elementi dei deliverable del progetto. Il sistema a piccoli lotti mira a svelare le incongruenze e le questioni relative alla qualità in una fase iniziale del ciclo di vita del progetto, quando i costi globali delle modi�che sono inferiori.

I progetti a elevata variabilità traggono vantaggio da strutture di gruppo che massimizzino la concentrazione e la collaborazione, come i gruppi auto-organizzati con specialisti generalisti.

La collaborazione mira a stimolare la produttività e facilitare la risoluzione creativa dei problemi. I gruppi collaborativi possono facilitare una più rapida integrazione di attività di lavoro distinte, migliorare la comunicazione, intensi�care la condivisione delle conoscenze e fornire �essibilità negli incarichi lavorativi, oltre ad altri vantaggi.

Sebbene i bene�ci della collaborazione siano validi anche per altri ambienti di progetto, i gruppi collaborativi sono spesso critici per il buon esito di progetti con un alto grado di variabilità e rapide modi�che, perché in questi casi vi è meno tempo per una gestione centralizzata dell’assegnazione dei compiti e delle decisioni.

La piani�cazione di risorse materiali ed umane nei progetti ad alta variabilità è molto meno prevedibile. In questi ambienti, gli accordi di fornitura rapida e i metodi lean (agili) sono fondamentali per il controllo dei costi e il rispetto della schedulazione.

94 Allegato A1

Tabella A1-2. Applicazione di Agile nelle aree di conoscenza della Guida PMBOK® (cont.)

Area di conoscenza della Guida PMBOK® Applicazione in un processo di lavoro Agile

Sezione 10Gestione delle comunicazioni di progetto

Sezione 11Gestione dei rischi di progetto

Gli ambienti di progetto soggetti a vari elementi di ambiguità e cambiamento hanno un'esigenza intrinseca di comunicare dati in evoluzione ed emergenti con più rapidità e frequenza. Ciò spinge a snellire l’accesso alle informazioni da parte dei membri del gruppo, aumentare i momenti di veri�ca e per quanto possibile co-locare il team.

Inoltre, la pubblicazione degli elaborati di progetto in modo trasparente e le revisioni periodiche degli stakeholder mirano a promuovere la comunicazione con la direzione e gli stakeholder.

Gli ambienti ad elevata variabilità, per de�nizione, sono soggetti a maggiore incertezza e rischio. Per affrontarli, i progetti gestiti utilizzando approcci adattivi fanno uso di revisioni frequenti dei prodotti del lavoro incrementale e di gruppi di progetto inter-funzionali, in modo da accelerare la condivisione della conoscenza e garantire che il rischio sia compreso e gestito. Quando si seleziona il contenuto di ogni singola iterazione si considera il rischio, che sarà anche identi�cato, analizzato e gestito all'interno della stessa.

Inoltre, i requisiti sono trattati come documenti vivi che sono aggiornati regolarmente e nel corso del progetto è possibile che le priorità delle attività cambino in conseguenza di una migliore comprensione dell'attuale esposizione al rischio.

95

Tabella A1-2. Applicazione di Agile nelle aree di conoscenza della Guida PMBOK® (cont.)

Area di conoscenza della Guida PMBOK® Applicazione in un processo di lavoro Agile

Sezione 12Gestione dell’approvvigionamento di progetto

Sezione 13Gestione degli stakeholder del progetto

Negli ambienti agili, per ampliare il gruppo è possibile utilizzare fornitori specici. Questa relazione di lavoro collaborativa può portare a un modello di approvvigionamento con rischio condiviso in cui sia l'acquirente che il fornitore condividono il rischio e le ricompense associati a un progetto.

I progetti più grandi possono utilizzare un approccio adattivo per alcuni deliverable e un approccio più stabile per le altre parti. In tali casi, è possibile utilizzare un accordo disciplinante quale un Master Service Agreement (MSA) per le condizioni generali di fornitura, con il lavoro adattivo in un'appendice o un supplemento. Ciò consente le modiche dell'ambito adattivo senza effetto sul contratto generale.

I progetti con un alto livello di modiche richiedono un coinvolgimento e la partecipazione attiva degli stakeholder del progetto. Per facilitare una discussione e un processo decisionale puntuali e produttivi, i gruppi adattivi coinvolgono direttamente gli stakeholder invece di passare attraverso la linea gerarchica. Spesso il cliente, l’utente e lo sviluppatore si scambiano informazioni in un processo dinamico di co-creazione che porta a un maggiore coinvolgimento e grado di soddisfazione degli stakeholder. Interazioni regolari con la comunità di stakeholder nel corso del progetto riducono il rischio, creano ducia e permettono correzioni nelle prime fasi del ciclo di progetto, riducendo i costi e aumentando la probabilità di successo per il progetto.

Per accelerare la condivisione delle informazioni con l’organizzazione, i metodi agili promuovono una trasparenza aggressiva. Lo scopo di invitare gli stakeholder alle riunioni di progetto e alle revisioni o di pubblicare i manufatti di progetto in spazi pubblici è quello di portare alla luce possibili disallineamenti, relazioni di dipendenza o altre questioni legate alle modiche del progetto.

97

ALLEGATO A2 MAPPATURA DELL’AGILE MANIFESTO

Questo allegato descrive il modo in cui vengono trattati gli elementi dell’Agile Manifesto nella Guida alle Pratiche dell’Agile.

Tabella A2-1. I valori dell’Agile Manifesto trattati nella Guida alle Pratiche dell’Agile.

Valore Copertura della Guida alle Pratiche dell’Agileper sezione e titolo

Individui e interazioni rispetto a processi e strumenti

Software funzionante rispetto a documen-tazione completa

Collaborazione con il cliente rispetto a negoziazione dei contratti

Risposta al cambiamento rispetto a seguire un piano

4.2 La servant leadership rafforza e responsabilizza il team4.3 Composizione del team5.1 Ufficializzare il progetto e il team5.2.4 Daily Stand-Up6.2 Cultura organizzativa

5.2.2 Preparazione del backlog5.2.3 Affinamento del backlog5.2.5 Dimostrazioni/Revisioni5.2.7 Pratiche di esecuzione che aiutano i gruppi a rilasciare valore

4.3 Composizione del team5.4 Misurazioni nei progetti agili6.2 Cultura organizzativa6.3 Approvvigionamento e contratti6.7 Struttura organizzativa

5.2.1 Retrospettive5.2.3 Affinamento del backlog5.2.5 Dimostrazioni/Revisioni

98 Allegato A2

Tabella A2-2. Mappatura dei principi dell’Agile Manifesto nella Guida alle Pratiche dell’Agile.

Principio Copertura della Guida alle Pratiche dell’Agile

La nostra principale priorità è soddisfare il cliente attraverso un rilascio anticipato e continuo di software di valore.

I cambiamenti dei requisiti, anche nelle ultime fasi di sviluppo, sono benvenuti. I processi Agile sfruttano il cambiamento in nome del vantaggio competitivo del cliente.

Rilasciare frequentemente software funzionante, da un paio di settimane a un paio di mesi, con preferenza per una tempistica più ridotta.

I referenti aziendali e gli sviluppatori devono collaborare quotidianamente nel corso del progetto.

Costruire progetti attorno a individui motivati. Dare loro l’ambiente e il supporto di cui hanno bisogno e fidarsi di loro per ottenere che il lavoro venga svolto.

Il modo più efficiente ed efficace di trasmettere informazioni all’interno di un team di sviluppo è la conversazione faccia a faccia.

Il software funzionante è la principale misura dell’avanzamento.

I processi Agile promuovono lo sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti devono poter mantenere un ritmo costante di lavoro indefinitivamente.

La continua attenzione all’eccellenza tecnica e alla buona progettazione potenzia l’agilità.

La semplicità - l’arte di massimizzare la quantità di lavoro non svolto - è essenziale.

I migliori requisiti, architetture e progettazioni nascono da team auto-organizzati.

A intervalli regolari, il team riflette su come diventare più efficace, quindi calibra e adegua di conseguenza il proprio comportamento.

3.1 Caratteristiche dei cicli di vita del progetto5.2.7 Pratiche di esecuzione che aiutano i gruppi a rilasciare valore

5.2.3 Affinamento del backlog

5.2 Pratiche agili comuni

4.2 La servant leadership rafforza e responsabilizza il team5.2.2 Preparazione del backlog5.2.3 Affinamento del backlog

4.3 Composizione del team5.1 Ufficializzare il progetto e il team5.2.1 Retrospettive

4.3.4 Strutture del team5.2.4 Daily Stand-Up

5.2.7 Pratiche di esecuzione che aiutano i gruppi a rilasciare valore5.2.8 In che modo iterazioni e incrementi contribuiscono al rilascio di un prodotto funzionante

5.1 Ufficializzare il progetto e il team

5.2 Pratiche agili comuni

5.2.2 Preparazione del backlog5.2.3 Affinamento del backlog

4.3 Composizione del team

5.2.1 Retrospettive

99

ALLEGATO A3 PANORAMICA DEGLI SCHEMI DI RIFERIMENTO AGILI E LEAN

Questo allegato descrive alcuni degli approcci agili più comunemente usati. Tali approcci possono essere utilizzati così come sono o combinati tra loro per adattarli nel miglior modo possibile a un dato ambiente o situazione. Non è necessario utilizzare uno di questi: è infatti possibile sviluppare un approccio agile da zero a condizione che esso rispetti la mentalità, i valori e i principi dell’Agile Manifesto. Se si seguono i principi agili per generare valore a un ritmo sostenibile, e l’approccio sviluppato promuove la collaborazione con il cliente, non occorre un approccio specifico. Ulteriori riferimenti riguardo a ciascun approccio sono disponibili nella sezione Bibliografia di questa guida.

A3.1 CRITERI DI SELEZIONE PER LA GUIDA ALLE PRATICHE DELL’AGILE

Gli approcci e le tecniche agili sono troppo numerosi per essere inclusi esplicitamente nella presente guida. La Figura A3-1 illustra un campione di approcci agili basati sulla profondità delle loro linee guida e sulla ampiezza dei loro cicli di vita. Gli approcci specifici selezionati per la discussione sono i più diffusi e hanno le seguenti caratteristiche:

uu Progettati per un uso olistico Alcuni approcci agili si concentrano su una singola attività di progetto, come le stime o la riflessione retrospettiva. Gli esempi elencati includono solo gli schemi di riferimento agili più olistici. Alcuni hanno funzionalità più complete di altri, ma tutti gli approcci selezionati sono quelli che sono stati pensati per guidare un’ampia serie di attività di progetto.

uu Formalizzati per l’uso comune Alcuni schemi di riferimento sono di natura proprietaria e progettati per l’uso specifico da parte di una singola organizzazione o nell’ambito di un singolo contesto. Gli schemi di riferimento descritti nelle Sezioni da A3.2 a A3.14 sono quelli che sono stati pensati per l’uso comune in una varietà di contesti.

uu Diffusi nell’uso moderno Alcuni schemi di riferimento agili sono progettati olisticamente e ben formalizzati ma semplicemente non sono comunemente utilizzati nella maggior parte dei progetti o delle organizzazioni. Gli schemi di riferimento agili descritti nel presente allegato sono stati adottati in un numero significativo di settori, come rilevato da una serie di recenti sondaggi di settore.

100 Allegato A3

Figura A3-1. Approcci agili rappresentati per ampiezza e profondità

Ampi

ezza

di c

oper

tura

del

ciclo

di v

ita

Profondità delle linee guida

Agile UP

Kanban

DSDM

Scrum

XP

FDD

SAFe®

LeSS

Lean

DisciplinedAgile

MetodiCrystal

Scrum ofScrums

Metodo dilavoro di gruppo

Approccioscalato

LEGENDA

101

A3.2 SCRUM

Scrum è uno schema di riferimento di processi per un team singolo, utilizzato per gestire lo sviluppo di prodotto. Lo schema di riferimento consiste in ruoli, eventi, elaborati e regole Scrum, e utilizza un approccio iterativo per rilasciare un prodotto funzionante. Scrum è gestito in intervalli di tempo fisso di un mese o meno di durata costante chiamati “sprint” in cui viene realizzato un incremento di prodotto potenzialmente rilasciabile. La Tabella A3-1 elenca gli eventi e gli elaborati Scrum utilizzati per l’esecuzione del progetto.

Il team Scrum è costituito dal Product Owner, il team di sviluppo e lo Scrum Master.

uu Il Product Owner ha la responsabilità di massimizzare il valore del prodotto.

uu Il team di sviluppo è un gruppo auto-organizzato e interfunzionale composto da membri che dispongono di tutto l’occorrente per rilasciare un prodotto funzionante senza dipendere da soggetti esterni al team.

uu Lo Scrum Master ha la responsabilità di garantire che il processo Scrum sia seguito e funzioni in modo da assicurare che il team Scrum rispetti le prassi e le regole. Lo Scrum Master ha anche la responsabilità di fare coaching al team su come superare gli ostacoli.

Tabella A3-1. Eventi ed elaborati Scrum

Eventi Elaborati

Sprint

Pianificazione dello sprint

Daily scrum

Revisione dello Sprint

Retrospettiva dello sprint

Product backlog

Sprint backlog

Incrementi

102 Allegato A3

A3.3 EXTREME PROGRAMMING

eXtreme Programming (XP) è un metodo di sviluppo software basato su cicli frequenti. Il nome si basa sulla filosofia di distillare per una determinata best practice la sua forma più semplice e pura e di applicarla in maniera continuativa per tutto il progetto.

XP è noto soprattutto per aver reso popolare una serie olistica di pratiche volte a migliorare i risultati dei progetti software. Il metodo è stato inizialmente formalizzato come una serie di dodici pratiche primarie ma poi si è gradualmente evoluto per adottare diverse altre pratiche a corollario. Queste sono elencate nella Tabella A3-2.

Tabella A3-2. Le pratiche di eXtreme Programming

Questa evoluzione è stata il risultato della progettazione e dell’adozione di tecniche basate sui valori cardine (comunicazione, semplicità, feedback, coraggio, rispetto) e arricchite dai principi chiave (umanità, aspetti economici, vantaggio reciproco, somiglianza, miglioramento, diversità, riflessione, flusso, opportunità, ridondanza, insuccesso, qualità, primi passi, responsabilità accettata).

Area di pratica XP Principale Secondaria

Organizzativa

Tecnica

Pianicazione

Integrazione

• Sedersi insieme• Team completo• Spazio di lavoro in cui circolano informazioni

• Pair Programming• Test-First Programming• Progettazione incrementale

• User story• Ciclo settimanale• Ciclo trimestrale• Slack

• Creazione in 10 minuti• Integrazione continua• Test-first

• Coinvolgimento del cliente reale• Continuità del team• Ritmo sostenibile

• Codice condiviso/responsabilità collettiva• Documentazione da codice e test• Refactoring

• Analisi delle cause originarie• Contrazione dei team• Pagamento al consumo• Contratto con ambito negoziato• Daily Stand-up

• Codebase unico• Incremental deployment• Daily deployment

103

A3.4 METODO KANBAN

Kanban nella produzione Lean è un sistema per la schedulazione del controllo e del rifornimento delle scorte. Questo processo di rifornimento delle scorte “just-in-time” venne originariamente osservato nei negozi di alimentari in cui gli scaffali venivano riassortiti in base agli spazi vuoti e non all’inventario del fornitore. Ispirandosi a questi sistemi di inventario “just-in-time”, Taiichi Ohno sviluppò Kanban, che venne applicato nella principale struttura di produzione di Toyota nel 1953.

Letteralmente il termine kanban significa “segno visivo” o “scheda”. Le lavagne fisiche kanban con schede consentono e promuovono la visualizzazione e il flusso del lavoro attraverso il sistema affinché tutti possano vederlo. Tale information radiator (sistema di ampia visualizzazione) è costituito da colonne che rappresentano gli stati che il lavoro deve attraversare per essere completato. Le lavagne più semplici hanno tre colonne (ad es. da fare, in corso, e fatto) ma sono adattabili agli stati giudicati necessari dal team che le utilizza.

Il metodo Kanban è utilizzato e applicabile in vari scenari e permette un flusso continuo di lavoro e di valore per il cliente. Il metodo Kanban è meno prescrittivo rispetto ad altri approcci agili e quindi la sua introduzione è meno di rottura dato che il metodo è di tipo “comincia da dove sei”. Le organizzazioni possono iniziare ad applicare i metodi Kanban con relativa facilità e progredire verso la piena implementazione del metodo se lo ritengono necessario o appropriato.

Diversamente dalla maggior parte degli approcci agili, il metodo Kanban non prescrive l’uso di iterazioni con intervalli di tempo fisso. Nel metodo Kanban possono essere utilizzate le iterazioni, ma il principio di acquisire continuamente singoli elementi nel processo e di limitare il lavoro in corso per ottimizzare il flusso deve sempre rimanere invariato. Il metodo Kanban porta risultati ottimali quando un gruppo o un’organizzazione hanno bisogno delle seguenti condizioni:

uu Flessibilità Ii team non sono solitamente vincolati da intervalli di tempo fisso e lavorano sull’elemento di massima priorità nel backlog del lavoro.

uu Attenzione al rilascio continuo I team si concentrano sul flusso di lavoro attraverso il sistema fino al completamento senza iniziare del nuovo lavoro fino a quando quello in corso non viene terminato.

uu Maggiore produttività e qualità La produttività e la qualità aumentano limitando il lavoro in corso.

104 Allegato A3

uu Maggiore efficienza Controllo per ogni attività delle sottoattività a valore aggiunto o meno ed eliminazione di quelle che non ne apportano.

uu Attenzione da parte dei membri del team. La limitazione del lavoro in corso consente al team di concentrarsi sul lavoro corrente.

uu Variabilità del carico di lavoro. Quando vi è imprevedibilità nelle modalità di arrivo del lavoro e diventa impossibile per i team prendere impegni prevedibili, anche per brevi periodi di tempo.

uu Riduzione degli sprechi La trasparenza rende visibili gli sprechi in modo che sia possibile eliminarli.

Il metodo Kanban deriva dai principi del pensiero Lean. I principi che definiscono il metodo Kanban e le sue proprietà cardine sono elencati nella Tabella A3-3.

Il metodo Kanban è uno schema di riferimento olistico per processi evolutivi e incrementali e cambiamenti dei sistemi nelle organizzazioni. Il metodo utilizza un “sistema pull” per far muovere il lavoro nell’ambito del processo. Quando il team completa un elemento, può portarne un altro nel medesimo stato.

Tabella A3-3. Principi fondamentali e proprietà del metodo Kanban

Principi fondamentali Proprietà cardine

Iniziare dallo stato attuale

Concordare di apportare modifiche evolutive e incrementali

Rispettare i processi, i ruoli, le responsabilità e i titoli attuali

Incoraggiare azioni di leadership a tutti i livelli

Visualizzare il flusso di lavoro

Limitare il lavoro in corso

Gestire il flusso

Rendere esplicite le regole operative del processo

Implementare cicli di feedback

Migliorare in maniera collaborativa

105

Le lavagne Kanban, come quella mostrata nella Figura A3-2, si basano su una tecnologia low-tech e high-touch che può apparire eccessivamente semplicistica a un primo sguardo, ma chi le utilizza presto ne comprenderà la forza. Con direttive per l’ingresso e l’uscita dalle colonne, oltre a vincoli quali la limitazione del lavoro in corso, le lavagne Kanban forniscono una visione chiara del flusso di lavoro, dei colli di bottiglia, degli ostacoli e dello stato complessivo. Inoltre, la lavagna funge da information radiator a chiunque la osservi, fornendo informazioni aggiornate sullo stato del lavoro di un team.

Figura A3-2. Lavagna Kanban che mostra i limiti del lavoro in corso e un sistema pull per ottimizzare il flusso di lavoro

Nel metodo Kanban è più importante completare il lavoro che iniziarne di nuovo. Non vi è valore derivante dal lavoro non completato quindi il team collabora per implementare e attenersi ai limiti del lavoro in corso (WIP) e portare ogni pezzo del lavoro nel sistema su “completato”.

6Da fare

4Analisi

5Sviluppo

3Test

4Rilascio

In corso Fatto In corso Fatto

106 Allegato A3

A3.5 METODI CRYSTAL

Crystal è una famiglia di metodologie. Le metodologie Crystal sono progettate per essere scalabili e fornire un diverso livello di rigore metodologico basato sulle dimensioni del progetto (numero di persone coinvolte) e sulla sua criticità.

Figura A3-3. Metodologie Crystal

Vita(L)

Denaroessenziale

(E)

Denarodiscrezionale

(D)

Comfort(C)

Criti

cità

(I di

fetti

cau

sano

per

dite

di..

.)

Crystal Clear Crystal Yellow Crystal Orange Crystal Red

L3

E3

D3

C3

L10

E10

D10

C10

L30

E30

D30

C30

L80

E80

D80

C80

L150

E150

D150

C150

L300

E300

D300

C300

L600

E600

D600

C600

Numero di persone coinvolte(Dimensioni totali del team +–20%)

1-4 6-20 20-40 5-100 100-200 200-500 500

LEG

ENDA

107

La metodologia Crystal parte dal presupposto che ciascun progetto può richiedere una serie di direttive, pratiche e processi lievemente personalizzati per rispondere alle caratteristiche uniche del progetto. La famiglia di metodologie utilizza diversi colori in base al “peso” per determinare quale metodologia utilizzare. L’uso della parola crystal deriva dalla gemma in cui le varie “facce” rappresentano i principi e i valori cardine sottostanti. Le facce sono una rappresentazione delle tecniche, degli strumenti, degli standard e dei ruoli elencati nella Tabella A3-4.

Tabella A3-4. I valori cardine e le proprietà comuni di Crystal

Valori cardine Proprietà comuniA

Persone

Interazione

Comunità

Abilità

Talenti

Comunicazioni

Rilascio frequente

Miglioramento attraverso la riflessione

Comunicazione stretta od osmotica

Sicurezza personale

Concentrazione

Accesso facile a utenti esperti

Ambiente tecnico con test automatizzati, gestione della configurazione e integrazione frequente

A Maggiore è il numero di queste proprietà in un progetto, maggiori sono le probabilità di successo.

108 Allegato A3

A3.6 SCRUMBAN

Scrumban è un approccio agile originariamente progettato come modo per effettuare la transizione da Scrum a Kanban. Con l’emergere di ulteriori schemi di riferimento e metodologie agili , è divenuto uno schema ibrido in continua evoluzione in cui i team utilizzano Scrum come schema di riferimento e kanban per il miglioramento dei processi.

In Scrumban, il lavoro è organizzato in piccoli “sprint” e sfrutta l’uso di lavagne kanban per la visualizzazione e il monitoraggio del lavoro. Le story sono collocate sulla lavagna Kanban e il team gestisce il proprio lavoro attenendosi ai limiti del lavoro in corso. Si svolgono riunioni giornaliere per mantenere viva la collaborazione all’interno del team e rimuovere gli impedimenti. Generalmente, quando il livello del lavoro in corso è inferiore a un limite predeterminato,si attiva un segnale che informa il team su quando cominciare la pianificazione successiva.. Non vi sono ruoli predefiniti in Scrumban, il team conserva i propri ruoli.

A3.7 FEATURE-DRIVEN DEVELOPMENT

Feature-Driven Development (FDD) è stato progettato per soddisfare le esigenze specifiche di un grande progetto di sviluppo software. Le funzionalità si riferiscono a piccole componenti di valore per l’azienda.

I progetti Feature-Driven Development prevedono sei ruoli principali in cui gli individui possono svolgere uno o più dei seguenti ruoli:

uu Project Manager,

uu Chief Architect,

uu Development Manager,

uu Chief Programmer,

uu Class Owner, e/o

uu Domain Expert.

109

Un progetto Feature-Driven Development è organizzato attorno a cinque processi o attività che vengono svolti iterativamente:

uu Sviluppare un modello generale,

uu Creare un elenco di funzionalità,

uu Pianificare per funzionalità,

uu Progettare per funzionalità, e

uu Realizzare per funzionalità.

Il flusso del ciclo di vita e l’interazione di questi cinque processi sono illustrati nella Figura A3-4.

Le attività del Feature-Driven Development sono sostenute da un corpo centrale di best practices di ingegneria software:

uu Modellazione del domain object,

uu Sviluppo per funzionalità,

uu Responsabilità di una individual class,

uu Team specializzati su funzionalità,

uu Ispezioni,

uu Gestione della configurazione,

uu Compilazioni regolari e

uu Visibilità di avanzamenti e risultati.

Figura A3-4. Ciclo di vita del progetto Feature-Driven Development

Rivedere il modello

Realizzare per

funzionalità

Sviluppareun modello

di alto livello

Sviluppare l’elenco delle funzionalità

Pianicare per

funzionalità

Progettare per

funzionalità

110 Allegato A3

A3.8 DYNAMIC SYSTEMS DEVELOPMENT METHOD

Dynamic Systems Development Method (DSDM) è uno schema di riferimento per il rilascio di progetti agili inizialmente progettato per aggiungere maggiore rigore ai metodi iterativi esistenti e diffusi negli anni ‘90. Venne sviluppato come collaborazione non commerciale tra i leader del settore.

DSDM è noto perlopiù per la sua enfasi sul rilascio guidato da vincoli. Lo schema di riferimento definisce all’inizio costo, qualità, tempo e quindi prioritizza le componenti dell’ambito per soddisfare tali vincoli come mostrato nella Figura A3-5.

Figura A3-5. Approccio DSDM all’agilità guidata da vincoli

Otto principi guidano l’uso dello schema di riferimento DSDM:

uu Attenzione alle esigenze aziendale.

uu Rilascio nei tempi.

uu Collaborazione.

uu Nessun compromesso sulla qualità.

uu Realizzazione incrementale su basi consolidate.

uu Sviluppo iterativo.

uu Comunicazione continuativa e chiara.

uu Assicurazione di controllo (uso delle tecniche appropriate).

Fisso

Variabile

Funzionalità Costo Tempo

Costo FunzionalitàTempo

Approccio DSDMApproccio tradizionale

Qualità

Qualità

111

A3.9 PROCESSO UNIFICATO AGILE

Il Processo Unificato Agile (Agile Unified Process – AgileUP) deriva da Unified Process (UP) per i progetti software. Presenta cicli più accelerati e processi più snelli rispetto al predecessore Unified Process. L’intento è svolgere più cicli iterativi attraverso le sette discipline chiave e integrare il feedback associato prima del rilascio formale. Le discipline e i principi guida sono elencati nella Tabella A3-5.

Tabella A3-5. I principali elementi dell’Agile Unified Process

A3.10 SCHEMI DI RIFERIMENTO SCALABILI

A3.10.1 SCRUM OF SCRUMS

Scrum of Scrums (SoS), noto anche come “meta Scrum”, è una tecnica utilizzata quando due o più gruppi Scrum costituiti da tre a nove membri ciascuno hanno bisogno di coordinare il proprio lavoro invece di un unico grande team Scrum. Un rappresentante di ogni team partecipa a una riunione con l’altro o gli altri rappresentanti dei gruppi, potenzialmente su base giornaliera ma di solito due o tre volte a settimana. La riunione giornaliera si svolge in modo simile al Daily Stand-up in Scrum dove il rappresentante riferisce il lavoro completato, la serie successiva di lavoro, eventuali impedimenti attuali e i potenziali impedimenti futuri che potrebbero bloccare l’altro o gli altri team. L’obiettivo è garantire che i team stiano coordinando il lavoro e rimuovendo gli impedimenti per ottimizzare l’efficienza di tutti i gruppi.

Grandi progetti con diversi team possono comportare la conduzione di uno Scrum of Scrum of Scrums, che segue lo stesso schema di SoS con un rappresentante di ogni SoS che riferisce a un gruppo più ampio di rappresentanti come mostrato nella Figura A3-6.

Discipline coinvolte nel rilascio Principi guida delle discipline

Modello

Implementazione

Test

Rilascio

Gestione della configurazione

Project Management

Ambiente

Il team sa cosa sta facendo

Semplicità

Agilità

Concentrazione su attività ad alto valore

Indipendenza dello strumento

Personalizzazione per la compatibilità

Attenzione alla situazione specifica

112 Allegato A3

Figura A3-6. Rappresentanti dei gruppi Scrum che partecipano a gruppi SoS

A3.11 SCALED AGILE FRAMEWORK

Lo Scaled Agile Framework (SAFe®) si concentra sulla fornitura di una knowledge base di schemi per scalare il lavoro progettuale a tutti i livelli aziendali.

SAFe® si concentra sui seguenti principi:

uu Acquisire un punto di vista sugli aspetti economici.

uu Applicare un pensiero sistemico.

uu Presupporre variabilità; Salvaguardare opzioni.

uu Costruire in modo incrementale con cicli di apprendimento rapidi e integrati.

uu Basare le milestone su una valutazione obiettiva di soluzioni funzionanti.

Scrumof

Scrums

Scrum ofScrums ofScrums

TeamScrum

113

uu Visualizzare e limitare il lavoro in corso, ridurre le dimensioni dei lotti e gestire la lunghezza delle code.

uu Definire un ritmo di lavoro; sincronizzarsi con la pianificazione intersettoriale.

uu Stimolare la motivazione intrinseca dei knowledge worker (lavoratori della conoscenza).

uu Decentralizzare le attività decisionali.

SAFe® si concentra su pratiche, ruoli e attività dettagliate a livello di portfolio, programma e team ed enfatizzacome organizzare l’azienda attorno a flussi di valore che si concentrano sulla fornitura di valore continuo al cliente.

A3.12 LARGE SCALE SCRUM (LeSS)

Large Scale Scrum (LeSS) è uno schema di riferimento per l’organizzazione di diversi team di sviluppo verso un obiettivo comune che estende il metodo Scrum mostrato nella Figura A3-6. Il principio organizzativo cardine è preservare il più possibile gli elementi del modello Scrum tradizionale basato su un solo team. Ciò contribuisce a ridurre al minimo le estensioni del modello che potrebbero creare confusione o complessità inutili. La Tabella A3-6 mostra un confronto tra LeSS e Scrum.

Tabella A3-6. Confronto tra LeSS e Scrum

Per estendere Scrum senza perderne l’essenza, LeSS promuove l’uso di determinati principi distintivi, quali pensiero sistemico, attenzione all’intero prodotto, trasparenza e altri.

Analogie tra LeSS e Scrum Tecniche LeSS aggiunte a Scrum

Un unico product backlog

Una “Definition of Done” per tutti i team

Un incremento di prodotto potenzialmente rilasciabile al termine di ogni sprint

Un unico Product Owner

Team consistenti e interfunzionali

Un unico sprint

La pianificazione dello sprint è divisa più formalmente in due parti, cosa e come

Coordinamento organico tra team

Affinamento complessivo tra team

Retrospettiva complessiva concentrata sui miglioramenti tra team

114 Allegato A3

A3.13 ENTERPRISE SCRUM

Enterprise Scrum è uno schema di riferimento progettato per applicare il metodo Scrum a un livello organizzativo complessivo piuttosto che a una singola iniziativa di sviluppo del prodotto. Nello specifico, lo schema di riferimento suggerisce ai leader dell’organizzazione di:

uu Estendere l’uso di Scrum a tutte le componenti dell’organizzazione;

uu Generalizzare le tecniche Scrum per applicarle facilmente ai vari componenti, e

uu Scalare il metodo Scrum con tecniche aggiuntive secondo necessità.

L’intento è di usare gli approcci agili oltre l’esecuzione dei singoli progetti facilitando un’innovazione di rottura.

A3.14 DISCIPLINED AGILE (DA)

Disciplined Agile (DA) è uno schema di riferimento decisionale che integra diverse best practice agili in un modello unico omnicomprensivo. DA è stato progettato per bilanciare tra loro i metodi più diffusi ritenuti o troppo restrittivi come ambito di applicazione (ad es, Scrum) o eccessivamente prescrittivi (ad es. AgileUP). Per raggiungere tale equilibrio, combina varie tecniche agili in base ai seguenti principi:

uu Le persone prima Elencare i ruoli e gli aspetti organizzativi ai vari livelli.

uu Orientamento all’apprendimento Incoraggiare un miglioramento basato sulla collaborazione.

uu Ciclo di vita completo di rilascio Promozione di vari cicli di vita personalizzati.

uu Orientamento agli obiettivi Processi di personalizzazione per raggiungere risultati specifici.

uu Consapevolezza aziendale Fornitura di linee guida sulla governance interdipartimentale.

uu Scalabilità Copertura delle diverse dimensioni di complessità del programma.

115

APPENDICE X1 PARTECIPANTI E REVISORI

X1.1 COMITATO CENTRALE DELLA GUIDA ALLE PRATICHE DELL’AGILE

Le seguenti persone sono i membri del Comitato centrale del progetto responsabili della stesura della guida, compresa la revisione e la validazione delle raccomandazioni dei revisori.

X1.1.1 IN RAPPRESENTANZA DEL PROJECT MANAGEMENT INSTITUTE:

Mike Griffiths, PMP, PMI-ACP, (Presidente del Comitato)Jesse Fewell, CST, PMI-ACPHoria Slușanschi, PhD, CSMStephen Matola, BA, PMP

X1.1.2 IN RAPPRESENTANZA DI AGILE ALLIANCE:

Johanna Rothman, MS (Vicepresidente del Comitato)Becky Hartman, PMI-ACP, CSPBetsy Kauffman, ICP-ACC, PMI-ACP

116 Appendice X1

X1.2 REVISORI ESPERTI IN MATERIA DELLA GUIDA ALLE PRATICHE DELL’AGILE

Le seguenti persone sono state invitate come esperti in materia per revisionare le bozze e fornire raccomandazioni attraverso la Revisione SME.

Joe Astolfi, PMP, PSMMaria Cristina Barbero, PMI-ACP, PMPMichel Biedermann, PhD, PMI-ACPZach BonakerRobert Bulger, PfMP, CSMSue BurkShika Carter, PMP, PMI-ACPLauren Clark, PMP, CSMLinda M Cook, CSM, CSPOPamela Corbin-Jones, PMI-ACP, CSMJeff CovertAlberto Dominguez, MSc, PMPScott P. Duncan, CSM, ICP-ACCSally Elatta, PMI-ACP, EBACFrank R. Hendriks, PMP, PMI-ACPDerek HuetherRon JeffriesFred KoosPhilippe B. Kruchten, PhD, PEngSteve Mayner, SPCT4, PMPMichael S. McCalla, PMI-ACP, CSPDon B. McClure, PMP, PMI-ACPAnthony C. Mersino, PMI-ACP, CSPKenneth E. Nidiffer, PhD, PMPMichael C. Nollet, PMP, PMI-ACP

Laura Paton, MBA, PMPYvan Petit, PhD, PMPDwayne Phillips, PhD, PMPPiyush Prakash, PMP, Prince2Dave Prior, PMP, CSTDaniel Rawsthorne, PhD, PMPAnnette D. Reilly, PMP, PhDStephan Reindl, PMI-ACP, PMPReed D. Shell, PMP, CSPCindy Shelton, PMP, PMI-ACPTeresa ShortLisa K. Sieverts, PMP, PMI-ACPChristopher M. Simonek, PMP, CSMRobert “Sellers” Smith, PMP, PMI-ACPRam Srinivasan, PMP, CSTChris Stevens, PhDKaren Strichartz, PMP, PMI-ACPRahul Sudame, PMI-ACPJoanna L. Vahlsing, PMPErik L. van DaalenAnnette Vendelbo, PMP, PMI-ACPDave Violette, MPM, PMPAnton Vishnyak, PMI-ACP, CSMChuck Walrad, MA, MS

117

X1.3 FOCUS GROUP PER IL FORMATO

Le seguenti persone hanno collaborato allo sviluppo del nuovo stile grafico e alla formattazione degli elementi per la Guida alle Pratiche dell’Agile.

Goran Banjanin, PgMP, PMPAndrew CraigCătălin-Teodor Dogaru, PhD, PMPJorge Espinoza, PMPJennifer M. Forrest, CSM, PMPHelen Fotos, PMP, PMI-ACPDave Hatter, PMP, PMI-ACPChristopher Healy, PMPMike Hoffmann, MBA, PMPChadi Kahwaji, PMP

Rajaraman Kannan, PMP, MACS CPAmit Khanna PMP, PMI–ACPAriel Kirshbom, PMI-ACP, CSPBernardo Marques, PMPNoura Saad, PMI-ACP, CSPOKurt Schuler, PMPDemetrius L. Williams, MBA, PMPLiza WoodMelody Yale, CSP, SPC4

X1.4 PMI STANDARDS MEMBER ADVISORY GROUP (MAG)

Le seguenti persone sono i membri del PMI Standards Member Advisory Group che hanno fornito indicazioni e l’approvazione finale per conto del PMI per la Guida alle Pratiche dell’Agile.

Maria Cristina Barbero, PMI-ACP, PMPBrian Grafsgaard, PMP, PgMPHagit Landman, PMP, PMI-SPYvan Petit PhD, PMPChris Stevens, PhDDave Violette, MPM, PMPJohn Zlockie, MBA, PMP, PMI Standards Manager

X1.5 AGILE ALLIANCE BOARD®

Le seguenti persone sono i membri del Consiglio di Amministrazione di Agile Alliance che hanno fornito indicazioni e l’approvazione finale per conto di Agile Alliance per la Guida alle Pratiche dell’Agile.

Juan BandaPhil Brock (Direttore Generale)Linda CookStephanie DavisEllen Grove

Paul Hammond (Presidente)Victor Hugo GermanoRebecca Parsons (Segretario)Craig SmithDeclan Whelan

118 Appendice X1

X1.6 PERSONALE DI SUPPORTO AL PMI E ALLA RICERCA ACCADEMICA

Le seguenti persone hanno lavorato per supportare il Comitato centrale nello sviluppo e nell’approvazione delle bozze, a sostegno del Focus Group e dell’impegno di marketing del PMI.

Melissa M. Abel, Specialista comunicazioni marketingKarl F. Best, PMP, CStd, Specialista degli standardAlicia C. Burke, MBA, CSM, Responsabile di prodotto, CredenzialiEdivandro C. Conforto, PhD, Consulente PMI sulla ricerca AgileDave Garrett, CSPO, Vicepresidente TrasformazioneErica Grenfell, Assistente amministrativa al VP, Relazioni dell’organizzazioneM. Elaine Lazar, MA, MA, AStd, Specialista di progettoAndrew Levin, PMP, Project ManagerTim E. Ogline, User Experience DesignerStephen A. Townsend, Direttore dei programmi di reteMichael Zarro, PhD, Ricercatore UX

X1.7 PERSONALE DI PRODUZIONE PMI

Donn Greenberg, Manager, PubblicazioniKim Shinners, Associato di Produzione pubblicazioniRoberta Storer, Editor prodottoBarbara Walsh, Supervisore della produzione delle pubblicazioni

X1.8 GRUPPO VOLONTARIO INCARICATO DELLA VERIFICA DELLA TRADUZIONE ITALIANA

Maria Cristina Barbero, PMP, PMI-ACPCarlo Massarelli, MBA, PMPSimone Rosichini, MSc, PMP, MSPTiziano Villa, PMP, PMI-ACP

X1.9 COMITATO INCARICATO DELLA VERIFICA DELLE TRADUZIONI

Barbara Walsh, Supervisora della produzione per le pubblicazioniMargaret Lyons, Sviluppo esamiStephen Townsend, Direttore, Network ProgramsVivian Isaak, Presidente, Magnum Group, Inc., Agenzia di traduzioni Brian Middleton, Manager soluzioni strategiche, Magnum Group, Inc., Agenzia di traduzioni

119

APPENDICE X2 ATTRIBUTI CHE INFLUENZANO LA PERSONALIZZAZIONE

X2.1 INTRODUZIONE

Questa appendice fornisce indicazioni di massima su quando e come personalizzare gli approcci agili. Può essere utilizzata per determinare le circostanze che possono giustificare la modifica o l’introduzione di nuove tecniche, e propone delle raccomandazioni da tenere in considerazione.

X2.2 AVVERTIMENTI PRELIMINARI

La personalizzazione è un argomento avanzato che deve essere affrontato da professionisti esperti che hanno applicato con successo approcci agili come originariamente descritti in più ambienti prima di considerarne la personalizzazione. In altre parole, occorre acquisire esperienza e applicare con successo un approccio prima di tentare di personalizzarlo.

Una risposta comune quando si hanno difficoltà ad adottare una pratica agile è considerare se applicarla o meno. Un’affermazione come “Le retrospettive erano impopolari, quindi abbiamo deciso di abbandonarle” illustra questo problema e indica un problema più fondamentale per il team, che difficilmente sarà risolto dalla personalizzazione del metodo. La situazione sarà peggiorata omettendo l’attività retrospettiva che mira a migliorare il processo.

Il modello di acquisizione delle competenze Shu-Ha-Ri descrive la progressione dall’obbedienza alle regole (Shu 守, significa obbedire e proteggere), attraverso un allontanamento consapevole dalle regole (Ha 破, significa modificare o allontanarsi) e infine attraverso una pratica e un miglioramento costante per trovare un percorso individuale (Ri 離, significa separare o abbandonare). Dobbiamo iniziare e praticare a livello Shu prima di essere pronti a passare al livello Ha per personalizzare il processo o al livello Ri per inventare un nuovo processo di personalizzazione.

120 Appendice X2

Infine, la personalizzazione deve essere intrapresa in collaborazione con i colleghi del team o con chiunque risentirà dell’impatto. Le persone devono essere coinvolte nel processo valutativo e decisionale in merito al cambiamento dei processi affinché si impegnino e approvino detti cambiamenti per operare una transizione efficace. L’esclusione delle persone dalla personalizzazione di un processo comporterà probabilmente resistenze e risentimento al cambiamento, anche se è tecnicamente sensato. Spesso, coach o leader esperti possono contribuire a coinvolgere le persone in modo efficace.

X2.3 COME UTILIZZARE QUESTA APPENDICE

Per beneficiare delle indicazioni fornite in questa appendice, raccomandiamo per prima cosa di applicare correttamente gli approcci agili come progettati. Quindi, invitiamo a rivedere le linee guida per la personalizzazione nella Tabella X2-1 relativamente alla situazione da affrontare e a leggere le associate raccomandazioni. Successivamente, si discuterà la personalizzazione con le persone impattate e si concorderà un piano di azione.

Come discusso nella Sezione 5, un buon modo per valutare una personalizzazione è provarla per un paio di iterazioni, prima di adottarla in modo permanente. Oppure, considerare un approccio flow-based e provare a rilasciare più funzionalità. Quindi, riflettere con una retrospettiva e rivalutare.

Quando le persone sanno di poter sperimentare e fornire un feedback sull’esperimento, sono più predisposte a provare qualcosa di nuovo. Avendola provata in un intervallo di tempo fisso, il team deve rivederne l’efficacia in una retrospettiva per determinare se continuare allo stesso modo, modificarla per migliorarla o abbandonarne l’uso.

Infine, gli approcci adottati con successo e personalizzati possono essere istituzionalizzati nei processi standard utilizzati per progetti che condividono tali caratteristiche. Si raccomanda inoltre di seguire le linee guida della Sezione 5 che descrivono l’adozione (o la personalizzazione) di nuovi approcci.

X2.4 RACCOMANDAZIONI PER LA PERSONALIZZAZIONE

A seguire si elencano alcune buone pratiche da considerare prima di personalizzare un approccio.

121

X2.4.1 PRESTARE ATTENZIONE ALL’ELIMINAZIONE DI ELEMENTI

Molte pratiche agili agiscono come coppie in sinergia. Ad esempio, la co-locazione e frequenti conversazioni aziendali consentono requisiti leggeri poiché le lacune nella comprensione possono essere colmate rapidamente. Analogamente, la modalità aggressiva di test di XP indirizza un coraggioso refactoring, e in questo modo le due pratiche si supportano a vicenda. La rimozione di qualcosa senza comprendere o considerare la pratica correlata creerà più problemi di quanti ne risolva.

X2.4.2 USO DELLA TABELLA CON LE LINEE GUIDA PER LA PERSONALIZZAZIONE

Usando la Tabella X2-1, trovare le circostanze che corrispondono a una data situazione e considerare le raccomandazioni per la personalizzazione. Discutere di eventuali modifiche con coloro che risentiranno della modifica e pianificare prima una breve prova, seguita da una schietta revisione di follow-up prima di impegnarsi nel cambiamento definitivo.

Tabella X2-1. Linee guida per la personalizzazione

Situazione Raccomandazione per la personalizzazione

Team di progetto molto grandi

Riorganizzare grandi progetti in progetti più piccoli. Provare prima con un progetto di test della tecnologia e quindi con un progetto di implementazione.

Considerare rilasci più frequenti ciascuno con un numero inferiore di funzionalità, il che permette la creazione di team di progetto più piccoli.

Considerare la riduzione del team ai suoi membri chiave. Spesso troppe persone ostacolano un processo, non lo aiutano. La riduzione delle dimensioni di un team può contenere la confusione nonché i costi.

Scomporre team grandi in gruppi più piccoli e utilizzare il Program Management per sincronizzarsi e coordinarsi.

Utilizzare il Program Management agile e lean per organizzare il carico di lavoro più ampio.

Considerare un quadro di riferimento su scala agile o lean quale DA, SAFe® o LeSS. Ciascuno di essi da un lato offre idee utili e dall’altrocomporta rischi di implementazione e incremento di peso/costo del processo.

122 Appendice X2

Tabella X2-1. Linee guida per la personalizzazione (cont.)

Situazione Raccomandazione per la personalizzazione

Team distribuiti

Alcuni prodotti critici per la sicurezza possono richiedere documentazione aggiuntiva e controlli della conformità oltre quanto previsto dai processi agili

Requisiti stabili e processo di esecuzione

I team sono in silos organizzativi all’interno di organizzazioni funzionali

Molti progetti hanno (alcuni) membri di progetto distribuiti. Strumenti quali messaggistica istantanea, videoconferenze e lavagne di gruppo elettroniche aiutano a colmare molte lacune di comunicazione.

Quando si prevede che i team possano rimanere stabili, organizzare il prima possibile riunioni faccia a faccia per rendere più ef�caci le successive conversazioni a distanza. Le persone che si sono incontrate faccia a faccia, grazie alla �ducia reciproca costruita, hanno maggiore probabilità di entrare in un dibattito franco.

Quando si effettuano riunioni a distanza in cui vi è carenza di messaggi facciali e di linguaggio corporeo, considerare controlli di tipo round-robin per garantire la partecipazione e misurare il consenso ottenuto sulle decisioni.

Inoltre, considerare l’uso di approcci agili iteration-based. Quando i membri del team operano in fusi orari diversi, considerare l’uso meno frequente di interazioni collettive trasversali all’intero progetto, incoraggiando più riunioni personali (due o tre persone alla volta) più di frequente.

Gli approcci agili possono essere comunque utilizzati in questi ambienti ma devono prevedere livelli aggiuntivi appropriati di revisione della conformità, della documentazione e delle certi�cazioni richieste dallo speci�co settore di mercato. In quel caso, la documentazione potrebbe essere parte di ciò che il team fornisce insieme alle funzionalità completate. Le funzionalità potrebbero non rese disponibili �no al completamento della documentazione.

Considerare l’uso di un approccio ibrido (più approcci agili) per ottenere i bene�ci derivanti da una migliore collaborazione e comunicazione grazie a un approccio agile integrato dal maggior rigore richiesto dall’ambiente di prodotto. Gli sviluppatori dei sistemi di volo degli aerei e le aziende farmaceutiche utilizzano approcci agili accoppiati ai propri processi organizzativi con il duplice obiettivo di ottenere bene�ci e conservare i controlli appropriati.

E’ davvero necessario adottare l’Agile? Se l’incertezza dei requisiti è bassa, i tassi di modi�ca sono contenuti e il rischio di esecuzione è minimo, l’intera suite di approcci agili può non essere necessaria. Sebbene alcuni progetti bene�cino di una maggiore collaborazione e trasparenza, alcuni cicli iterativi di costruzione e revisione possono essere eccessivi.

Se i cicli di costruzione/feedback non scoprono o af�nano regolarmente i requisiti, considerare l’estensione delle durate per ridurre al minimo l’impatto dei costi del tempo di revisione.

Se il progetto ha alti tassi di modi�ca durante la progettazione e lo sviluppo, ma l’implementazione presso i clienti è un processo de�nito e ripetibile, possono essere più adatti gli approcci ibridi che utilizzano il modello del ciclo di vita appropriato per ogni fase di progetto.

Agile si basa sull’idea di team interfunzionali. Considerare di chiedere alle persone di creare team interfunzionali senza coinvolgere il management e vedere cosa accade.

Se il sistema di retribuzione è organizzato per riconoscere e ricompensare aree funzionali, considerare di cambiare prima questo aspetto. Le persone potrebbero non agire nell’interesse del prodotto o del team �no a quando ciò in�uenza in qualche modo la loro retribuzione.

123

Tabella X2-1. Linee guida per la personalizzazione (cont.)

Situazione Raccomandazione per la personalizzazione

La trasparenza può intimorire

Molti dei membri del team hanno scarse conoscenze tecniche di dominio

Mancanza di supporto (buy-in) da parte della direzione

I termini e il linguaggio agile non si adattano alla cultura dell'organizzazione.

Agile crea una cultura di trasparenza: le persone mostrano e condividono il loro lavoro attraverso l’intero sviluppo. Questa condivisione di deliverable intermedi insieme all’apertura e all’onestà su successi, fallimenti e situazione attuale, signi cano trasparenza. La trasparenza richiede coraggio.

Guidare con l’esempio e dimostrare trasparenza nei processi decisionali usando una lavagna di stato o un tabellone.

Gli approcci agili incoraggiano e fanno uso di team autodiretti per prendere decisioni locali su come trattare gli elementi del lavoro, quali la sequenzializzazione delle attività e l’approccio da utilizzare quando si risolve un problema. Quando la maggior parte dei membri del team non ha esperienza, gli approcci basati sul consenso possono portare a problemi e rilavorazione. Quindi, per questi team, può essere necessario un aiuto per “assegnare” e “dirigere” il lavoro  no a quando il team acquisirà le competenze necessarie. In altre parole, si consiglia di non limitarsi a dichiarare l’uso di Agile per poi lasciare un team inesperto a tentare di risolvere i problemi solo perché è stato responsabilizzato e opera in modo autodiretto. Considerare la creazione di centri di competenza per fornire indicazioni e costruire conoscenza di dominio.

Se manca il supporto (buy-in) della direzione, i team dovranno gestire il con�itto tra mentalità e approcci di tipo agile e quelli di tipo predittivo.

Trovare un terreno comune, aree per il miglioramento basate sulle esigenze dell’organizzazione e quindi usare esperimenti e retrospettive per progredire.

Considerare l’istruzione/la formazione per la direzione. Prendere in considerazione la spiegazione dell’ Agile in termini di pensiero lean: cicli brevi, piccole dimensioni dei lotti, revisioni frequenti e retrospettive con piccoli miglioramenti.

Modi care i termini in modo che le persone comprendano e concordino le attività, se non il linguaggio agile. Essere speci ci sul signi cato di ogni termine.

Ad esempio, se l’organizzazione trova la parola “gioco” non professionale, non utilizzare termini come “gioco di piani cazione”. Considerare invece l’uso del termine “workshop di piani cazione”.

125

APPENDICE X3 STRUMENTI DI F ILTRO DI IDONEITÀ AGILI

X3.1 INTRODUZIONE

La letteratura agile contiene molti strumenti di filtro di idoneità agili che aiutano a valutare in quali circostanze è appropriato utilizzare un approccio agile. Nel 1994 il Dynamic Systems Development Method (DSDM) ha sviluppato un Questionario sull’idoneità dei progetti agili e un Questionario sull’idoneità organizzativa per contribuire a valutare le aree di adeguatezza e quelle potenzialmente problematiche.

Anche la famiglia di approcci Crystal utilizzava criteri di idoneità, classificando i progetti per dimensioni del team e criticità del prodotto o del servizio in corso di sviluppo. Crystal raccomanda di intraprendere progetti più piccoli e meno critici con controlli inferiori e approcci più semplici. Ai progetti grandi, con missione critica o critici per la vita si raccomanda di applicare maggiore rigore e controllo.

Dallo sviluppo di questi approcci sono stati creati molti altri modelli per contribuire a determinare dove e quando utilizzare approcci agili. Boehm e Turner hanno adottato alcuni degli elementi di DSDM e Crystal per sviluppare un modello di valutazione popolare per aiutare a determinare se i progetti debbano essere intrapresi con approcci agili o più tradizionali.

In base ai modelli precedenti e con un ampliamento per prendere in considerazione la terra di mezzo degli approcci ibridi, viene proposto il seguente modello. Rappresenta una sintesi dei vari attributi dei filtri di idoneità per aiutare le organizzazioni a valutare e discutere se i progetti debbano essere intrapresi con approcci predittivi, ibridi o agili.

126 Appendice X3

X3.2 PANORAMICA DEL MODELLO

Gli attributi organizzativi e di progetto sono valutati secondo tre categorie principali:

uu Cultura. Esiste un ambiente che esprime supporto (buy-in) verso l’approccio e la fiducia nel team?

uu Team. Il team è di dimensioni adeguate per avere successo nell’adozione di agile? i suoi membri hanno l’esperienza necessaria e possono contare su rappresentanti aziendali per avere successo?

uu Progetto. Vi sono alti tassi di modifica? È possibile un rilascio incrementale? Quanto è critico il progetto?

Le domande in ciascuna di queste categorie ricevono una risposta e i risultati sono riportati su un diagramma di Kiviat (grafico radar). I gruppi di valori attorno al centro del grafico indicano l’idoneità ad approcci agili. I valori sulla parte esterna indicano che un approccio predittivo potrebbe essere più adatto. I valori nella parte centrale (tra agile e predittivo) indicano che un approccio ibrido potrebbe dare buoni risultati. Un esempio è mostrato nella Figura X3-1.

127

Figura X3-1. Modello di idoneità dell’approccio agile

Dim

ensi

oni d

el te

am

Espe

rienza

Accesso Supporto (buy-in) Fiducia Capacità decisionale

Te

am

Cultura

Progetto

Modi�che Criticità Rilascio

109876543210 Agile Ibrido Predi-

ttivo

128 Appendice X3

X3.3 ISTRUZIONI PER L’USO

X3.3.1 COMPLETARE IL QUESTIONARIO COME TEAM

Per i progetti piccoli, questo gruppo può essere formato semplicemente dallo sponsor, dal technical leader e dal cliente. Per progetti grandi, esso può includere rappresentanti del gruppo di sponsorizzazione, il team esecutivo di progetto, i gruppi aziendali impattati, i gruppi di governance del progetto e la comunità cliente. L’idea è che, così come un solo stakeholder non dovrebbe stimare o pianificare un progetto poiché porta un solo punto di vista e inserisce una distorsione personale, allo stesso modo nessun singolo dovrebbe valutare l’idoneità di un approccio poiché una sola persona può avere una visione limitata distorta.

Al contrario, il valore dello strumento consiste nell’incoraggiare la conversazione con le parti interessate del progetto. Anche se i risultati suggeriscono di seguire un approccio ibrido ma gli stakeholder desiderano procedere con un approccio ampiamente agile o predittivo, seguire il consenso degli stakeholder. Questo strumento consente soltanto una diagnostica di alto livello, la decisione finale spetta e deve essere sostenuta dalle persone coinvolte.

X3.3.2 PUNTEGGIO DELLE DOMANDE DA 1 A 10

Come gruppo, discutere e concordare (o trovare un compromesso su) un punteggio che descriva nel modo più accurato la valutazione soggettiva della domanda. Mentre opzioni predefine sono fornite solo per i punti iniziali, centrali e finali dello spettro di risposte, rappresentati dai punteggi 1, 5 e 10, è accettabile (e auspicabile) utilizzare punteggi quali 2 per “quasi 1 ma non del tutto” o 7 per “qualcosa tra 5 e 10”. Ancora una volta, la valutazione è uno strumento di discussione: i punti di vista sono soggettivi e sono da attendersi sfumature di grigio.

Quando il gruppo non riesce a concordare un punteggio, discutere apertamente e onestamente le divergenze. Prima di suggerire compromessi (ovvero utilizzare punteggi medi o contrassegnare i punteggi PMO con una “X” blu e il gruppo di sviluppo con una “O” verde), occorre considerare le probabilità di successo del progetto qualora i partecipanti non riescano neppure a concordare il completamento di una semplice valutazione. Quando si discute delle divergenze, se è possibile identificare le differenze di opinione, la situazione è ottimale e funziona; a questo punto però occorrerà raggiungere un accordo. Analogamente, se la valutazione indica un approccio predittivo ma tutti vogliono provare un approccio agile (o viceversa), anche questa soluzione è adottabile ma occorre comprendere le divergenze e discutere di come saranno gestiti gli impatti dell’approccio che sarà adottato.

129

X3.3.3 INTERPRETARE I RISULTATI

Contrassegnare le risposte alle domande su un grafico vuoto di valutazione dell’idoneità e collegare i punti. I risultati raggruppati attorno al centro nella zona agile indicano una buona propensione ad un approccio puramente agile.

I risultati prevalentemente nella zona ibrida indicano che una combinazione di approcci agili e predittivi potrebbe essere la soluzione migliore. Tuttavia, è possibile anche che un approccio agile con alcuni passaggi ulteriori di riduzione del rischio come formazione e istruzione aggiuntiva e un maggior controllo e rigore documentale, in caso di progetti ad alta criticità, possa essere sufficiente. In alternativa, potrebbe funzionare anche un approccio predittivo integrato da attività di sperimentazione dimostrativa o processi aggiuntivi.

I risultati prevalentemente nella zona predittiva indicano una buona propensione ad un approccio puramente predittivo. Come menzionato nella Sezione X3.3.2 (passaggio Punteggio alle domande), questo strumento diagnostico mira ad avviare conversazioni significative con le parti impattate sull’approccio più appropriato da utilizzare. Se l’approccio suggerito dallo strumento non è accettabile, è consentito utilizzare un approccio diverso. Utilizzare i risultati come input per il processo di gestione dei rischi, poiché lo strumento indica delle discrepanze che dovranno essere gestite.

X3.4 DOMANDE DEL FILTRO DI IDONEITÀ

X3.4.1 CATEGORIA: CULTURA

X3.4.1.1 SUPPORTO (BUY-IN) ALL’APPROCCIO

Esiste uno sponsor con adeguata seniority che comprende e sostiene l’utilizzo di un approccio agile per questo progetto? Vedere la Figura X3-2.

Figura X3-2. Valutazione del supporto (buy-in) all’approccio

Parziale

5Sì

1No

10

Valutazione = _______

130 Appendice X3

X3.4.1.2 FIDUCIA NEL TEAM

Considerare gli sponsor e i rappresentanti aziendali che lavoreranno con il team. Questi stakeholder hanno fiducia che il gruppo possa trasformare la loro visione e le loro esigenze in un prodotto o servizio di successo, facendo leva su supporto e feedback continui in entrambe le direzioni? Vedere la Figura X3-3.

Figura X3-3. Valutazione della fiducia nel team

X3.4.1.3 POTERE DECISIONALE DEL TEAM

Il team avrà l’autonomia per prendere decisioni locali su come intraprendere il lavoro? Vedere la Figura X3-4.

Figura X3-4. Valutazione del potere decisionale del team

Probabile

5Sì

1Improbabile

10

Valutazione = _______

Probabile

5Sì

1Improbabile

10

Valutazione = _______

131

X3.4.2 CATEGORIA: TEAM

X3.4.2.1 DIMENSIONI DEL TEAM

Quali sono le dimensioni del core team? Utilizzare questa scala: 1-9 = 1, 10-20 = 2, 21-30 = 3, 31-45 = 4, 46-60 = 5, 61-80 = 6, 81-110 = 7, 111-150 = 8, 151 – 200 = 9, 201+ = 10. Vedere la Figura X3-5.

Figura X3-5. Valutazione delle dimensioni del team

X3.4.2.2 LIVELLI DI ESPERIENZA

Considerare l’esperienza e i livelli di competenza dei ruoli del core team. Sebbene sia normale avere un mix di persone esperte e inesperte nei ruoli affinché i progetti agili si svolgano in modo fluido, è più semplice quando in ciascun ruolo vi è almeno un membro esperto. Vedere la Figura X3-6.

Figura X3-6. Valutazione del livello di esperienza

51 10

Valutazione = _______

Parziale

5Sì

1No

10

Valutazione = _______

132 Appendice X3

X3.4.2.3 ACCESSO AL CLIENTE/ALL’AZIENDA

Il team avrà accesso giornaliero ad almeno un rappresentante aziendale/del cliente per ottenere un feedback? Vedere la Figura X3-7.

Figura X3-7. Valutazione dell’accesso al cliente/all’azienda

X3.4.3 CATEGORIA: PROGETTO

X3.4.3.1 PROBABILITÀ DI MODIFICHE

Quale percentuale di requisiti ha probabilità di cambiare o di essere scoperta mensilmente? Vedere la Figura X3-8.

Figura X3-8. Valutazione della probabilità di modifiche

25%

550%

15%

10

Valutazione = _______

Parziale

5Sì

1No

10

Valutazione = _______

133

X3.4.3.2 CRITICITÀ DEL PRODOTTO O SERVIZIO

Per contribuire a determinare i probabili livelli aggiuntivi di controllo e rigore documentale eventualmente necessari, valutare la criticità del prodotto o servizio da realizzare. Utilizzando una valutazione che consideri la perdita dovuta al possibile impatto dei difetti, determinare quali potrebbero essere le conseguenze di un insuccesso. Vedere la Figura X3-9.

Figura X3-9. Valutazione della criticità di un prodotto o servizio

X3.4.3.3 RILASCIO INCREMENTALE

Può il prodotto o servizio essere realizzato e valutato in parti? L’azienda o i rappresentanti del cliente saranno disponibili a fornire un feedback puntuale sugli incrementi rilasciati? Vedere la Figura X3-10.

Figura X3-10. Valutazione del rilascio incrementale

Fondi essenziali

5Tempo

1Molte vite

10Vita singolaFondi discrezionali

Valutazione = _______

Forse/Talvolta

5Sì

1Improbabile

10

Valutazione = _______

134 Appendice X3

X3.5 GRAFICO DI VALUTAZIONE DELL’IDONEITÀ

La Figura X3-11 è il diagramma di Kiviat (grafico radar) utilizzato per la valutazione dell’idoneità.

Figura X3-11. Diagramma di Kiviat (grafico radar) di valutazione dell’idoneità

Dim

ensi

oni d

el te

am

Espe

rienza

Accesso Supporto (buy-in) Fiducia Capacità decisionale

Team

Cultura

Progetto

Modi�che Criticità Rilascio

109876543210 Agile Ibrido Predi-

ttivo

135

X3.5.1 CASI DI STUDIO

Per illustrare il funzionamento del diagramma di Kiviat (grafico radar), ecco due esempi dell’utilizzo del modello per assegnare un punteggio ai vari tipi di progetti. Il primo è un esempio di un progetto di una farmacia online (vedere la Figura X3-12) e il secondo (Figura X3-13) è un esempio di un sistema di messaggistica militare. Questi due casi di studio illustrano alcune differenze osservabili nei progetti. Il raggruppamento centrale indica una buona propensione ad approcci agili, i punteggi periferici indicano invece che potrebbero essere più adatti approcci predittivi. Alcuni progetti si dispongono attorno al centro ma poi hanno picchi su uno o due assi. Questi progetti possono essere gestiti al meglio con un approccio ibrido.

Figura X3-12. Progetto della farmacia

Dim

ensi

oni d

el te

am

Espe

rienza

Accesso Supporto (buy-in) Fiducia Capacità decisionale

Team

Cultura

Progetto

Modi�che Criticità R

ilascio

109876543210 Agile Ibrido Predi-

ttivo

136 Appendice X3

X3.5.1.1 ESEMPIO DELLA FARMACIA

Il progetto prevedeva lo sviluppo di una farmacia online per vendere farmaci canadesi con prescrizione a prezzi più convenienti a clienti principalmente negli Stati Uniti. La vendita di questi farmaci è oggetto di contesa sia in Canada che negli Stati Uniti e di conseguenza il settore è caratterizzato da rapide modifiche normative e da una forte concorrenza. Il progetto doveva affrontare requisiti estremamente volatili con importanti modifiche su base settimanale. Utilizzava iterazioni molto brevi (2 giorni) e rilasci settimanali per gestire gli alti tassi di modifica.

Come mostrato nella Figura X3-12, alti livelli di supporto (buy-in) e fiducia sono evidenti per coloro che lavoravano in modo responsabilizzato. La natura visiva del sito web rendeva semplice mostrare i nuovi incrementi di funzionalità ma la criticità del sistema era piuttosto alta con messa a rischio di fondi essenziali per la farmacia. Come menzionato, c’erano altissimi tassi di modifica ma il piccolo team esperto li gestiva bene e accedeva facilmente a un rappresentante aziendale competente. L’approccio ha avuto grande successo ed è risultato estremamente agile.

X3.5.1.2 ESEMPIO DEL SISTEMA DI MESSAGGISTICA MILITARE

Ora confronteremo il primo esempio con un grande progetto per sviluppare un sistema di messaggistica militare già in corso da 5 anni quando è stata effettuata la valutazione. Vedere la Figura X3-13.

137

Figura X3-13. Esempio del sistema di messaggistica militare

Dim

ensi

oni d

el te

am

Espe

rienza

Accesso Supporto (buy-in) Fiducia Capacità decisionale

Te

am

Cultura

Modi�che Criticità Rilascio

Progetto

109876543210 Agile Ibrido Predi-

ttivo

138 Appendice X3

Mancava il supporto (buy-in) ad un approccio agile perché questo non era stato considerato. La fiducia nei fornitori era contrastante ma in generale i fornitori erano rispettati. I processi decisionali non erano locali ma di responsabilità dei comitati architetturali e di valutazione dei requisiti. Sebbene gli elementi progettati potessero essere testati in modo incrementale in laboratorio, non era possibile consolidarli per una dimostrazione end-to-end della funzionalità. Molte vite erano potenzialmente a rischio, quindi la criticità era molto elevata. I requisiti erano bloccati perché le modifiche avevano impatto su molte organizzazioni di subfornitori.

Il progetto era grande con oltre 300 persone presso un solo fornitore, ma ogni ruolo aveva molti professionisti esperti. Infine, l’accesso all’azienda/al cliente non era possibile ma erano disponibili analisti a contratto per porre domande sulle specifiche, che solitamente rispondevano o chiedevano chiarimenti entro 10 giorni. Parti del progetto avrebbero potuto essere estrapolate e gestite come progetti agili ma il cuore dell’iniziativa era un unico grande progetto.

X3.6 SINTESI

I filtri di idoneità per un approccio agile sono strumenti utili per identificare potenziali successi e lacune per approcci agili. Non dovrebbero essere utilizzati come criteri definitivi di inclusione o esclusione ma come argomenti per una discussione obiettiva con tutte le parti interessate.

139

RIFERIMENTI

[1] Manifesto per lo sviluppo agile del software. (2001). Recuperato da http://agilemanifesto.org/

[2] Project Management Institute. 2013. Managing Change in Organizations: A Practice Guide. Newtown Square, PA: Autore.

[3] Project Management Institute. 2017. Guida al Project Management Body of Knowledge (Guida PMBOK®) – Sesta edizione. Newtown Square, PA: Autore.

[4] Project Management Institute. 2013. Software Extension to the PMBOK® Guide Fifth Edition. Newtown Square, PA: Autore.

141

BIBLIOGRAFIA

A seguire si riportano materiali di lettura aggiuntiva suddivisi per sezione e/o argomento:

SEZIONE 2 - INTRODUZIONE ALL’AGILE

Briggs, Sara. “Agile Based Learning: What Is It and How Can It Change Education?” Opencolleges.edu.au 22 febbraio 2014, recuperato da http://www.opencolleges.edu.au/informed/features/agile-based-learning-what-is-it-and-how-can-it-change-education/.

Manifesto for Agile Software Development, 2001, http://agilemanifesto.org/.

Peha, Steve. “Agile Schools: How Technology Saves Education (Just Not the Way We Thought it Would).” InfoQ. 28 giugno 2011, recuperato da https://www.infoq.com/articles/agile-schools-education.

Principles behind the Agile Manifesto, 2001, http://agilemanifesto.org/principles.html.

Rothman, Johanna. 2007. Manage It! Your Guide to Modern, Pragmatic Project Management. Raleigh: Pragmatic Bookshelf.

Sidky, Ahmed (Keynote). 2015. https://www.slideshare.net/AgileNZ/ahmed-sidky-keynote-agilenz.

Stacey Complexity Model. 2016. http://www.scrum-tips.com/2016/02/17/stacey-complexity-model/.

SEZIONE 3 - SELEZIONE DEL CICLO DI VITA

“Agile Modeling (AM) Home Page: Effective Practices for Modeling and Documentation,” Agile Modeling, (n.d.), http://www.agilemodeling.com/

Anderson, David, and Andy Carmichael. 2016. Essential Kanban Condensed. Seattle: Blue Hole Press.

Anderson, David. 2010. Kanban: Successful Evolutionary Change for Your Technology Business. Seattle: Blue Hole Press.

142 Bibliografia

Benson, Jim, and Tonianne DeMaria Barry. 2011. Personal Kanban: Mapping Work | Navigating Life. Seattle: Modus Cooperandi Press.

Burrows, Mike. 2014. Kanban from the Inside: Understand the Kanban Method, connect it to what you already know, introduce it with impact. Seattle: Blue Hole Press.

Domain Driven Design Community. 2016. http://dddcommunity.org/.

Gothelf, Jeff, and Josh Seiden. 2016. Lean UX: Designing Great Products with Agile Teams. Sebastopol: O’Reilly Media.

Hammarberg, Marcus, and Joakim Sunden. 2014. Kanban in Action. Shelter Island: Manning Publications.

“Kanban,” Wikipedia, ultima modifica 4 maggio 2017, recuperato il 22 novembre 2016 da https://en.wikipedia.org/wiki/Kanban.

“Kanban (sviluppo),” Wikipedia, ultima modifica 4 maggio 2017, recuperato il 22 novembre 2016 da https://en.wikipedia.org/wiki/Kanban_(development).

Larsen, Diana, and Ainsley Nies. 2016. Liftoff: Start and Sustain Successful Agile Teams. Raleigh: Pragmatic Bookshelf.

“Learning Kanban,” Leankit, (n.d.), https://leankit.com/learn/learning-kanban/.

Leopold, Klaus, and Siegrfried Kaltenecker. 2015. Kanban Change Leadership: Creating a Culture of Continuous Improvement. Hoboken: Wiley.

“Make a big impact with software products and projects!” Impact Mapping, (n.d.), https://www.impactmapping.org/.

Patton, Jeff, and Peter Economy. 2014. User Story Mapping: Discover the Whole Story, Build the Right Product. Sebastopol: O’Reilly Media.

Reinertsen, Donald. 2009. The Principles of Product Development Flow: Second Generation Lean Product Development. Redondo Beach: Celeritas Publishing.

Rothman, Johanna. “Dispersed vs. Distributed Teams,” Rothman Consulting Group, Inc., 25 ottobre 2010, http://www.jrothman.com/mpd/2010/10/dispersed-vs-distributed-teams/.

Schwaber, Ken, and Jeff Sutherland. “The Scrum Guide™,” Scrum.org, luglio 2016, http://www.scrumguides.org/scrum-guide.html e http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf#zoom=100.

Skarin, Mattias. 2015. Real-World Kanban: Do Less, Accomplish More with Lean Thinking. Raleigh: Pragmatic Bookshelf.

“The High Cost of Multitasking: 40% of Productivity Lost by Task Switching,” Wrike.com, 24 settembre 2015, https://www.wrike.com/blog/high-cost-of-multitasking-for-productivity/.

Wells, Don. “Extreme Programming: A Gentle Introduction,” Extreme Programming, 8 ottobre 2013, http://www.extremeprogramming.org/.

143

SEZIONE 4 - IMPLEMENTAZIONE DI AGILE:

Amabile, Teresa, and Steven Kramer. 2011. The Progress Principle: Using Small Wins to Ignite Joy, Engagement, and Creativity at Work. Boston: Harvard Business Review Press.

“Early Warning Signs of Project Trouble—Cheat Sheet, 2017, https://agilevideos.com/wp-content/uploads/2017/02/WarningSignsOfProjectTrouble-CheatSheet.pdf.

Dweck, Carol. 2006. Mindset: The New Psychology of Success. New York: Penguin Random House.

Kaner, Sam. Facilitator’s Guide to Participatory Decision-Making. 3rd ed. 2014. San Francisco: Jossey-Bass.

Keith, Kent. The Case for Servant Leadership. 2008. Westfield: Greenleaf Center for Servant Leadership.

Rothman, Johanna. 2016. Agile and Lean Program Management: Scaling Collaboration Across the Organization. Victoria, British Columbia: Practical Ink.

Rothman, Johanna. “Dispersed vs. Distributed Teams,” Rothman Consulting Group, Inc., 25 ottobre 2010, http://www.jrothman.com/mpd/2010/10/dispersed-vs-distributed-teams/.

Rothman, Johanna. 2007. Manage It! Your Guide to Modern, Pragmatic Project Management. Raleigh: Pragmatic Bookshelf.

Rothman, Johanna. 2016. Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects. Raleigh: Pragmatic Bookshelf.

Schwaber, Ken, e Jeff Sutherland. “The Scrum Guide™,” Scrum.org, luglio 2016, http://www.scrumguides.org/scrum-guide.html e http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf#zoom=100.

Sinek, Simon. 2011. Start with Why: How Great Leaders Inspire Everyone to Take Action. New York: Portfolio, Penguin Random House.

“The High Cost of Multitasking: 40% of Productivity Lost by Task Switching,” Wrike.com, 24 settembre 2015, https://www.wrike.com/blog/high-cost-of-multitasking-for-productivity/.

REPORT DI ESPERIENZA:

“Experience Reports,” Agile Alliance, (n.d.), https://www.agilealliance.org/resources/experience-reports/.

SALUTE DEL PROGETTO E DEL TEAM:

“Early Warning Signs of Project Trouble—Cheat Sheet.” 2017. https://agilevideos.com/wp-content/uploads/2017/02/WarningSignsOfProjectTrouble-CheatSheet.pdf

“TeamHealth Radar – Summary View,” Agilehealth. 2014. http://agilityhealthradar.com/wp-content/uploads/2014/11/bigradar.gif.

144 Bibliografia

EFFICIENZA DELLE RESORSE:

Modig, Niklas, and Pär Åhlström. 2015. This is Lean: Resolving the Efficiency Paradox. London: Rheologica Publishing.

Rothman, Johanna. “Resource Efficiency vs. Flow Efficiency, Part 5: How Flow Changes Everything,” Rothman Consulting Group, Inc., 20 settembre 2015, http://www.jrothman.com/mpd/agile/2015/09/resource-efficiency-vs-flow-efficiency-part-5-how-flow-changes-everything/.

SCALABILITÀ:

Disciplined Agile 2.X—A Process Decision Framework. 2016. http://www.disciplinedagiledelivery.com/.

Kniberg, Henrik. “Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds,” Crisp, 14 novembre 2012, http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify.

“Overview—Large Scale Scrum,” LeSS. 2016. http://less.works/.

“SAFe® for Lean Software and System Engineering,” SAFe®. 2016. http://www.scaledagileframework.com/.

ABILITÀ:

Beck, Kent. Paint Drip People, 4 agosto 2016, https://www.facebook.com/notes/kent-beck/paint-drip-people/1226700000696195/.

“Generalizing Specialists: Improving Your IT Career Skills,” Agile Modeling, (n.d.), http://www.agilemodeling.com/essays/generalizingSpecialists.htm.

Hunter, Brittany. “Of Software Designers & Broken Combs,” Atomic Object, 27 giugno 2013, https://spin.atomicobject.com/2013/06/27/broken-comb-people/.

SEZIONE 5 - IMPLEMENTAZIONE DI AGILE: OPERARE IN UN AMBIENTE AGILE

Larsen, Diana, and Ainsley Nies. 2016. Liftoff: Start and Sustain Successful Agile Teams. Raleigh: Pragmatic Bookshelf.

RETROSPETTIVE:

Derby, Esther, and Diana Larsen. 2006. Agile Retrospectives: Making Good Teams Great. Raleigh: Pragmatic Bookshelf.

Gonçalves, Luis, and Ben Linders. 2015. Getting Value out of Agile Retrospectives: A Toolbox of Retrospective Exercises. Victoria, British Columbia: Leanpub.

145

BACKLOG:

Adzic, Gojko, Marjory Bissett, and Tom Poppendieck. 2012. Impact Mapping: Making a Big Impact with Software Products and Projects. Woking, Surrey: Provoking Thoughts.

Patton, Jeff, and Peter Economy. 2014. User Story Mapping: Discover the Whole Story, Build the Right Product. Sebastopol: O’Reilly Media.

Rothman, Johanna. “We Need Planning; Do We Need Estimation?” Rothman Consulting Group, Inc., 21 gennaio 2015, http://www.jrothman.com/mpd/project-management/2015/01/we-need-planning-do-we-need-estimation/.

STAND-UP:

Brodzinski, Pawel. “Effective Standups around Kanban Board,” Brodzinski.com, 30 dicembre 2011, http://brodzinski.com/2011/12/effective-standups.html.

Fowler, Martin. “It’s Not Just Standing Up: Patterns for Daily Standup Meetings,” Martinfowler.com, 21 febbraio 2016, http://martinfowler.com/articles/itsNotJustStandingUp.html.

Hefley, Chris. “How to Run Effective Standups and Retrospectives,” Leankit, 15 settembre 2014, https://leankit.com/blog/2014/09/run-effective-standups-retrospectives/.

EARNED VALUE:

Griffiths, Mike. “A Better S Curve and Simplified EVM,” Leading Answers, 6 giugno 2008, http://leadinganswers.typepad.com/leading_answers/2008/06/a-better-s-curve-and-simplified-evm.html.

SEZIONE 6 - CONSIDERAZIONI ORGANIZZATIVE PER I PROGETTI AGILI

Bankston, Arlen, and Sanjiv Augustine. Agile Team Performance Management: Realizing the Human Potential of Teams, 14 giugno 2010, www.lithespeed.com/transfer/Agile-Performance-Management.pptx.

Browder, Justin, and Brian Schoeff. Perfect Strangers: How Project Managers and Developers Relate and Succeed. CreateSpace Independent Publishing Platform, 2016, https://www.createspace.com/.

Griffiths, Mike. “Agile Talent Management,” Leading Answers, 14 ottobre 2015, http://leadinganswers.typepad.com/leading_answers/2015/10/agile-talent-management.html.

Kohn, Alfie. 1999. Punished by Rewards: The Trouble with Gold Stars, Incentive Plans, A’s, Praise, and Other Bribes. New York: Mariner Books.

Mar, Kane. “How to do Agile Performance Reviews,” Scrumology, (n.d.), https://scrumology.com/how-to-do-agile-performance-reviews/.

McChrystal, Stanley, Tantum Collins, David Silverman, and Chris Fussell. 2015. Team of Teams: New Rules of Engagement for a Complex World. New York: Portfolio, Penguin Random House.

Pink, Daniel. 2011. Drive: The Surprising Truth About What Motivates Us. New York: Riverhead Books.

146 Bibliografia

SEZIONE 7 - CALL TO ACTION

Dennis, Pascal. 2006. Getting the Right Things Done: A Leader’s Guide to Planning and Execution. Cambridge: Lean Enterprise Institute.

Griffiths, Mike. “Introducing Agile Methods: Mistakes to Avoid—Part 3,” Leading Answers, 15 marzo 2007, http://leadinganswers.typepad.com/leading_answers/2007/03/introducing_agi_2.html.

Little, Jason. Lean Change Management: Innovative Practices for Managing Organizational Change. Happy Melly Express, 2014, http://www.happymelly.com/category/hm-express/.

Rising, Linda, and Mary Lynne Manns. 2004. Fearless Change: Patterns for Introducing New Ideas. Upper Saddle River: Addison-Wesley Professional.

“The IDEAL Model,” Software Engineering Institute, Carnegie Mellon, 2006, http://www.sei.cmu.edu/library/assets/idealmodel.pdf.

ALLEGATO A1 - MAPPATURA GUIDA PMBOK®

Larsen, Diana and Ainsley Nies. 2016. Liftoff: Start and Sustain Successful Agile Teams. Raleigh: Pragmatic Bookshelf.

ALLEGATO A2 - MAPPATURA AGILE MANIFESTO

Manifesto for Agile Software Development, 2001, http://agilemanifesto.org/.

Principles behind the Agile Manifesto, 2001, http://agilemanifesto.org/principles.html.

ALLEGATO A3 - PANORAMICA DEGLI SCHEMI DI RIFERIMENTO AGILI E LEAN

Agile Business Consortium, 2014, https://www.agilebusiness.org/what-is-dsdm.

Ambler, Scott. “The Agile Unified Process,” Ambysoft, 13 maggio 2006, http://www.ambysoft.com/unifiedprocess/agileUP.html.

Anderson, David. 2010. Kanban: Successful Evolutionary Change for Your Technology Business. Seattle: Blue Hole Press.

Beedle, Mike. Enterprise Scrum: Executive Summary: Business Agility for the 21st Century, 7 gennaio 2017, http://www.enterprisescrum.com/enterprise-scrum/.

147

Cockburn, Alistair. 2004. Crystal Clear: A Human-Powered Methodology for Small Teams. Upper Saddle River: Pearson Education.

Cockburn, Alistair. “Crystal Methodologies,” alistair.cockburn.us, 28 marzo 2014, http://alistair.cockburn.us/Crystal+methodologies.

Disciplined Agile 2.X—A Process Decision Framework, 2016, http://www.disciplinedagiledelivery.com/.

Joint MIT-PMI-INCOSE Community of Practice on Lean in Program Management. 2012. The Guide to Lean Enablers for Managing Engineering Programs. Newtown Square, PA: Autore.

“Kanban,” Wikipedia, ultima modifica 4 maggio 2017, recuperato il 22 novembre 2016 da https://en.wikipedia.org/wiki/Kanban.

“Kanban (sviluppo),” Wikipedia, ultima modifica 4 maggio 2017, recuperato il 29 novembre 2016 da https://en.wikipedia.org/wiki/Kanban_(development).

Reddy, Ajay, and Jack Speranza. 2015. The Scrumban [R]Evolution: Getting the Most Out of Agile, Scrum, and Lean Kanban. Boston: Addison-Wesley Professional.

“Overview—Large Scale Scrum,” LeSS, 2016, http://less.works/.

“SAFe® for Lean Software and System Engineering,” SAFe®, 2016, http://www.scaledagileframework.com/.

Schwaber, Ken, and Jeff Sutherland. “The Scrum Guide™,” Scrum.org, luglio 2016, http://www.scrumguides.org/scrum-guide.html e http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf#zoom=100.

“Scrum of Scrums,” Agile Alliance, (n.d.), https://www.agilealliance.org/glossary/scrum-of-scrums/.

“Scrumban,” Wikipedia, 2 marzo 2017, https://en.wikipedia.org/wiki/Scrumban.

“State of Agile Report: Agile Trends,” VersionOne, 2017, http://stateofagile.versionone.com/.

Sutherland Jeff. “Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies.” Cutter IT Journal 14, no. 12 (2001): 5-11 http://www.controlchaos.com/storage/scrum-articles/Sutherland 200111 proof.pdf.

“The 2015 State of Agile Development,” Scrum Alliance®, 2015, https://www.forrester.com/report/The+2015+State+Of+Agile+Development/-/E-RES122910

Wells, Don. “Extreme Programming: A Gentle Introduction,” Extreme Programming, 8 ottobre 2013, http://www.extremeprogramming.org/.

Why Scrum? State of Scrum Report, 2016, https://www.scrumalliance.org/why-scrum/state-of-scrum-report/2016-state-of-scrum.

148 Bibliografia

APPENDICE X2 - ATTRIBUTI CHE INFLUENZANO LA PERSONALIZZAZIONE

Griffiths, Mike. “Agile Suitability Filters,” Leading Answers, 2007, http://leadinganswers.typepad.com/leading_answers/files/agile_suitability_filters.pdf.

Jeffries, Ron. “We Tried Baseball and It Didn’t Work,” ronjeffries.com, 2 maggio 2006, http://ronjeffries.com/xprog/articles/jatbaseball/.

Rothman, Johanna. “One Experimental Possibility: Self-Organization from Component Teams to Feature Teams,” Rothman Consulting Group, Inc., 23 settembre 2014, http://www.jrothman.com/mpd/agile/2014/09/one-experimental-possibility-self-organization-from-component-teams-to-feature-teams/.

149

GLOSSARIO

1. ACRONIMI

ATDD acceptance test-driven development / acceptance test-driven development (sviluppo guidato dai test di accettazione)

BDD behavior-driven development / behavior-driven development (sviluppo guidato dal comportamento)

BRD business requirement documents / documentazione dei requisiti aziendali

DA Disciplined Agile / Disciplined Agile

DoD definition of done / definition of done

DoR definition of ready / definition of ready

DSDM Dynamics Systems Development Model / Dynamic Systems Development Method

Evo evolutionary value delivery / evolutionary value delivery

LeSS Large-Scale Scrum / Large-Scale Scrum

LSD Lean Software Development / Lean Software Development

PDCA Plan–Do–Check–Act / Plan–Do–Check–Act

PMO project management office / project management office

ROI return on investment / ritorno dell’investimento

RUP Rational Unified Process / Rational Unified Process

SAFe® Scaled Agile Framework® / Scaled Agile Framework®

SBE specification by example / specification by example

XP eXtreme Programming / Extreme Programming

150 Glossario

2. DEFINIZIONI

A3 / A3. Un modo di pensare e un processo sistematico di risoluzione dei problemi che raccoglie le informazioni pertinenti su un unico foglio in formato A3.

Abbinamento / Pairing. Vedere Lavoro in coppia.

Acceptance test-driven development (ATDD, sviluppo guidato dai test di accettazione) / Acceptance Test-Driven Development (ATDD). Metodo per definire in maniera collaborativa i criteri da utilizzare per formulare i test di accettazione, prima di avviare la consegna.

Adatto all’uso / Fit for Use. Descrive un prodotto che può essere utilizzato nella sua forma attuale per ottenere le finalità per cui è stato pensato.

Adatto allo scopo / Fit for Purpose. Descrive un prodotto adatto allo scopo per cui è stato ideato..

Affinamento del backlog / Backlog Refinement. Elaborazione progressiva dei requisiti di progetto e/o delle attività in corso nella quale il team rivede, aggiorna e redige i requisiti in modo collaborativo per soddisfare le necessità espresse nelle richieste del cliente.

Agile / Agile. Termine utilizzato per descrivere una mentalità basata sui valori e sui principi dichiarati nell’Agile Manifesto

Agile Coach / Agile Coach. Soggetto con conoscenza ed esperienza in ambito agile che possa formare, consigliare e guidare organizzazioni e gruppi durante la loro trasformazione.

Agile Manifesto / Agile Manifesto. Definizione originale ed ufficiale dei valori e dei principi agili.

Agilist / Agilist. Vedere Professionista Agile.

Analisi automatica della qualità del codice / Automated Code Quality Analysis. Test automatizzato del codice per individuare errori e vulnerabilità.

Anti-pattern / Anti-Pattern. Schema abituale di lavoro solitamente utilizzato ma inadatto, e pertanto sconsigliabile.

Apprendimento double-loop / Double-Loop Learning. Processo che mette in discussione il principi e gli assunti che stanno alla base delle decisioni prese, per meglio ricercare le cause scatenanti e per studiare contromisure migliorative, invece di concentrarsi esclusivamente sui sintomi.

Apprendimento single-loop / Single-Loop Learning. Pratica che prevede di tentare di risolvere i problemi utilizzando soltanto metodi specifici predefiniti, senza metterli in discussione alla luce dell’esperienza.

Approccio ibrido / Hybrid Approach. Combinazione di due o più elementi agili e non agili che determina un risultato finale non agile.

Approccio Plan-Driven / Plan-Driven Approach. Vedere Approccio predittivo.

Approccio predittivo / Predictive Approach. Approccio alla gestione del lavoro che utilizza un piano di lavoro e una gestione dello stesso nel corso del ciclo di vita di un progetto.

Backlog / Backlog. Vedere Product Backlog.

Behavior-driven development (BDD, sviluppo guidato dal comportamento) / Behavior-Driven Development (BDD). Modalità di progettazione e validazione che utilizza principi di tipo “test-first” e script basati su termini inglesi.

Blended Agile / Blended Agile. Due o più schemi di riferimento, metodi, elementi o pratiche agili utilizzati in abbinata, come ad esempio l’uso di Scrum in combinazione con il Methodo XP e Kanban.

151

Broken Comb / Broken Comb. Persona con vari livelli di specializzazione nelle varie competenze richieste dal gruppo. Noto anche come Dripping. Vedere anche Profilo a T e Profilo a I.

Cadenza / Cadence. Ritmo di esecuzione. Vedere anche Intervallo di tempo fisso.

Ciclo di vita / Life Cycle. Processo tramite il quale un prodotto è ideato, realizzato e messo in uso.

Ciclo di vita agile / Agile Life Cycle. Approccio al tempo stesso iterativo e incrementale volto a perfezionare gli elementi del lavoro e a favorire una consegna frequente.

Ciclo di vita incrementale / Incremental Life Cycle. Approccio che fornisce deliverable finiti per l’uso immediato da parte del cliente.

Ciclo di vita iterativo / Iterative Life Cycle. Approccio che consente di utilizzare il feedback sul lavoro non terminato per migliorarlo e modificarlo.

Daily Scrum / Daily Scrum. Una breve riunione giornaliera di allineamento in cui il team riesamina l’avanzamento rispetto al giorno precedente, dichiara le intenzioni per il giorno corrente ed evidenzia gli ostacoli incontrati o previsti. Noto anche come Daily Stand-up.

Debito tecnico / Technical Debt. Costo differito nel tempo che si viene a creare a causa del lavoro svolto male durante lo sviluppo del prodotto.

Definition of Done (DoD) / Definition of Done (DoD). Una lista di controllo del team condivisa con tutti i criteri che devono essere soddisfatti affinché un deliverable possa essere considerato pronto per l’utilizzo da parte del cliente.

Definition of Ready (DoR) / Definition of Ready (DoR). Una lista condivisa di controllo di un requisito centrato sull’utente, che contiene tutte le informazioni di cui il team ha bisogno per iniziare a lavorare sul requisito.

DevOps / DevOps. Insieme di pratiche per la creazione di un passaggio di consegne lineare, attraverso il miglioramento della collaborazione tra il personale dello sviluppo e il personale della gestione operativa.

Disciplined Agile (DA) / Disciplined Agile (DA). Schema di riferimento che semplifica la presa di decisioni in merito al rilascio incrementale e iterativo della soluzione.

Documentazione dei requisiti aziendali (BRD) / Business Requirement Documents (BRD). Elenco di tutti i requisiti di business per uno specifico progetto.

Dripping / Paint Drip. Vedere Broken Comb.

Dynamic Systems Development Method (DSDM) / Dynamic Systems Development Model (DSDM). Schema di riferimento per la gestione agile dei progetti.

Elaborazione progressiva / Progressive Elaboration. Processo iterativo che consiste nell’aumentare il livello di dettaglio di un piano di Project Management man mano che diventano disponibili maggiori informazioni e stime più accurate.

Eventi Kaizen / Kaizen Events. Eventi volti al miglioramento del sistema.

Evolutionary value delivery (Evo) / Evolutionary Value Delivery (EVO). Considerato pubblicamente il primo metodo agile con una specificità non presente negli altri metodi: l’attenzione a rilasciare a tutti gli stakeholder elementi il cui valore può essere misurato da diversi punti di vista.

Extreme Programming / eXtreme Programming. Metodo agile di sviluppo software che consente di ottenere software di migliore qualità, maggiore adattabilità ai cambiamenti dei requisiti cliente e rilasci più frequenti su cicli più brevi.

152 Glossario

Feature-Driven Development / Feature-Driven Development. Metodo leggero e agile di sviluppo software, guidato dal rilascio delle funzionalità ritenute di maggior valore per il cliente.

Flow Master / Flowmaster. Il coach di un team e del Service Request Manager che opera in un contesto di lavoro a flusso continuo o di tipo Kanban. Equivalente a Scrum Master.

Flusso di valore / Value Stream. Struttura organizzativa focalizzata sulla creazione di valore per i clienti attraverso la fornitura di specifici prodotti o servizi.

Gestione del cambiamento organizzativo / Organizational Change Management. Un approccio complessivo, ciclico e strutturato per guidare la transizione di individui, gruppi e organizzazioni dallo stato attuale a uno stato futuro per il conseguimento di benefici di business.

Grafico burn-down / Burndown Chart. Rappresentazione grafica del lavoro rimanente rispetto al tempo residuo in un intervallo di tempo fisso.

Grafico burn-up / Burnup Chart. Rappresentazione grafica del lavoro completato rispetto al prodotto da rilasciare.

Hoshin Kanri / Hoshin Kanri. Metodo di implementazione di una strategia o di una direttiva.

IDEAL / IDEAL. Modello di miglioramento organizzativo che prende il nome dalle cinque fasi che lo compongono: Initiating (Inizializzazione), Diagnosing (Diagnosi), Establishing (Definizione), Acting (Azione) e Learning (Apprendimento).

Impedimento / Impediment. Ostacolo che impedisce al gruppo di raggiungere i suoi obiettivi. Noto anche come ostacolo.

Incremento / Increment. Deliverable funzionale, testato e accettato, che è un sottoinsieme del risultato complessivo del progetto

Information radiator / Information Radiator. Lavagna ad alta visibilità che fornisce informazioni al resto dell’organizzazione, consentendo la condivisione di informazioni aggiornate senza dover disturbare il team.

Integrazione continua / Continuous Integration. Pratica in cui i prodotti del lavoro di tutti i membri del team vengono frequentemente integrati e validati insieme.

Intervallo di tempo fisso / Timebox. Periodo fisso di tempo, ad esempio 1 settimana, 15 giorni, 3 settimane o 1 mese. Vedere anche Iterazione.

Iterazione / Iteration. Ciclo di sviluppo di un prodotto o deliverable basato su un intervallo di tempo fisso, durante il quale viene svolto tutto il lavoro necessario per rilasciare il valore atteso.

Large-Scale Scrum (LeSS) / Large-Scale Scrum (LeSS). Large-Scale Scrum è uno schema di riferimento per lo sviluppo del prodotto, che estende Scrum su più ampia scala, pur mantenendo la finalità originaria.

Lavagna Kanban / Kanban Board. Strumento di visualizzazione che consente di migliorare il flusso di lavoro rendendo visibili colli di bottiglia e quantità di lavoro.

Lavagna Scrum / Scrum Board. Un “information radiator” utilizzato per gestire il prodotto e gli sprint backlog ed evidenziare il flusso di lavoro e i colli di bottiglia.

Lavoro in coppia / Pair Work. Tecnica in cui si affiancano due componenti del team che lavoreranno simultaneamente sullo stesso elemento di lavoro.

Lean Software Development (LSD) / Lean Software Development (LSD). Il Lean Software Development è una rivisitazione di principi e pratiche della produzione lean applicati al campo dello sviluppo software e si basa su una serie di principi e pratiche per raggiungere qualità, velocità e allineamento alle necessità del cliente.

153

Mappatura degli impatti / Impact Mapping. Tecnica di pianificazione strategica che funge da piano d’azione per tutta l’organizzazione durante la creazione di nuovi prodotti.

Mappatura del flusso di valore / Value Stream Mapping. Tecnica snella utilizzata nelle organizzazioni per documentare, analizzare e migliorare il flusso di informazioni o materiali necessari a produrre o fornire un prodotto o servizio ad un cliente.

Mappatura delle user story / User Story Mapping. Pratica visuale per organizzare il lavoro in una forma utile a comprendere le funzionalità ad alto valore da creare nel tempo, identificare omissioni nel backlog e pianificare in modo efficace i rilasci che portano valore agli utenti.

Mentalità Agile / Agile Mindset. Modo di pensare e di agire basato sui quattro valori e sui dodici principi dell’Agile Manifesto.

Metodo Kanban / Kanban Method. Metodo agile ispirato all’originale sistema di controllo degli inventari di Kanban e utilizzato appositamente per il lavoro della conoscenza.

Metodologie Crystal / Crystal Family of Methods. Serie di metodi di sviluppo software agili e leggeri incentrati sull’adattabilità alle singole situazioni.

Mobbing / Mobbing. Tecnica in cui più componenti del team si concentrano simultaneamente su un particolare lavoro e coordinano i propri contributi.

Organizzazione a silos / Siloed Organization. Organizzazione strutturata in modo tale da contribuire soltanto a un sottoinsieme degli aspetti necessari per fornire valore ai clienti. In contrasto, vedere Flusso di valore.

Ostacolo / Blocker. Vedere Impedimento.

Pair Programming / Pair Programming. Lavoro in coppia focalizzato sullo sviluppo software.

Pianificazione a finestra mobile / Rolling Wave Planning. Tecnica di pianificazione iterativa in cui il lavoro da portare a compimento a breve termine viene pianificato in modo dettagliato mentre quello futuro è pianificato con minore livello di dettagli.

Pianificazione dello sprint / Sprint Planning. Evento collaborativo in Scrum durante il quale il team pianifica il lavoro per lo sprint in avvio.

Pivot / Pivot. Un cambio di direzione intenzionale, studiato per testare una nuova ipotesi riguardo a un prodotto o a una strategia.

Plan–Do–Check–Act (PDCA) / Plan–Do–Check–Act (PDCA). Metodo di gestione iterativo utilizzato nelle organizzazioni per facilitare il controllo e il miglioramento continuo di processi e prodotti.

Principi Agile / Agile Principles. I dodici principi dell’approccio agile ai progetti espressi nell’Agile Manifesto.

Processo Unificato Agile / Agile Unified Process. Approccio semplice e chiaro per lo sviluppo di soluzioni software, che utilizza tecniche e concetti agile. Versione semplificata del Rational Unified Process (RUP).

Product backlog / Product Backlog. Elenco ordinato di requisiti definiti dall’utente e che il team di sviluppo elabora per realizzare il prodotto.

Product Owner / Product Owner. Persona responsabile della massimizzazione del valore del prodotto, approvatore finale e responsabile ultimo del prodotto realizzato. Vedere anche Service Request Manager.

Professionista agile / Agile Practitioner. Persona che adotta la mentalità agile e che collabora con colleghi che condividono gli stessi orientamenti in gruppi interfunzionali. Chiamato anche Agilist.

154 Glossario

Profilo a I / I-shaped. Persona che possiede una conoscenza approfondita in un’unica area di specializzazione e nessun interesse o abilità nel resto delle competenze richieste dal team. Vedere anche Profilo a T e Broken Comb.

Profilo a T / T-shaped. Persona che possiede una conoscenza approfondita in un’area di specializzazione e una significativa abilità nelle altre aree di competenza richieste dal team. Vedere anche Profilo a I e Broken Comb.

Profilo tipo / Personas. Archetipo che rappresenta un insieme di utenti finali simili descritti sulla base dei loro obiettivi, motivazioni e caratteristiche personali tipiche.

Progettazione UX / UX Design. Processo di miglioramento della User Experience che si incentra sul miglioramento dell’usabilità e dell’accessibilità nell’interazione tra l’utente e il prodotto.

Project Management Office (PMO) / Project Management Office (PMO). Struttura gestionale che standardizza i processi di governance legati al progetto e facilita la condivisione di risorse, metodologie, strumenti e tecniche.

Propensione organizzativa / Organizational Bias. Le preferenze di un’organizzazione rispetto a una serie di parametri e di valori di fondo: esplorazione vs. esecuzione, velocità vs. stabilità, quantità vs qualità, flessibilità vs. prevedibilità.

Proprietà condivisa del codice / Collective Code Ownership. Tecnica di accelerazione e collaborazione per la gestione di un progetto in base alla quale ogni membro del team è autorizzato a modificare qualsiasi prodotto del lavoro o deliverable del progetto incrementando in tal modo il grado di condivisione del risultato e il senso di responsabilità dell’intero team.

Prova del fumo / Smoke Testing. Pratica che prevede l’utilizzo di una serie leggera (non dettagliata) di test per garantire che le funzioni più importanti del sistema in corso di sviluppo siano quelle previste.

Refactoring / Refactoring. Tecnica di gestione della qualità del prodotto in base alla quale un prodotto viene migliorato in termini di manutenibilità e di caratteristiche strutturali senza alterarne il comportamento funzionale atteso.

Requisito funzionale / Functional Requirement. Un comportamento specifico che un prodotto o servizio dovrebbe esibire.

Retrospettiva / Retrospective. Workshop periodico in cui i partecipanti analizzano il proprio lavoro e i propri risultati per migliorare sia il processo che il prodotto.

Rilascio continuo / Continuous Delivery. Pratica che prevede il rilascio incrementale delle funzionalità ai clienti, spesso tramite l’uso di piccoli lotti di lavoro e di tecnologie automatizzate.

Scaled Agile Framework (SAFe®) / Scaled Agile Framework (SAFe®). Raccolta di schemi consolidati di lavoro, integrati tra loro, per uno sviluppo lean-agile su scala aziendale.

Schema di riferimento / Framework. Sistema o struttura basilare di idee o fatti a supporto di un approccio.

Scrum / Scrum. Schema di riferimento agile per la facilitazione e lo sviluppo di prodotti complessi con specifici ruoli, eventi ed elaborati.

Scrum Master / Scrum Master. Il coach del team di sviluppo e del responsabile del processo in Scrum. Rimuove gli ostacoli, facilita la produttività e protegge il team di sviluppo da interruzioni indesiderate. Vedere anche Flow Master.

Scrum of Scrums / Scrum of Scrums. Tecnica per facilitare l’uso di Scrum su più ampia scala con più team che lavorano contemporaneamente allo stesso prodotto, rilevando in maniera congiunta gli avanzamenti sulle parti interdipendenti e focalizzandosi su come integrare i rilasci della soluzione, in particolar modo nelle aree di sovrapposizione.

155

Scrumban / Scrumban. Schema di riferimento gestionale che si viene a creare quando i team adottano Scrum come schema di lavoro e utilizzano il Metodo Kanban come lente attraverso la quale visualizzare, comprendere e migliorare costantemente il proprio lavoro.

Servant Leadership / Servant Leadership. La pratica di guidare mettendosi al servizio del team, concentrandosi sulla comprensione e sull’indirizzamento dei bisogni e dello sviluppo dei componenti del team, per facilitare le migliori prestazioni possibili.

Service Request Manager / Service Request Manager. Persona responsabile della prioritizzazione delle richieste di servizio, con l’obiettivo di massimizzare il valore in un contesto di lavoro a flusso continuo o in un ambiente Kanban. Equivalente a Product Owner.

Specifica funzionale / Functional Specification. Una funzione specifica che un sistema o un’applicazione deve saper svolgere. Generalmente riportata in un documento di specifiche funzionali.

Specification by Example (SBE) / Specification by Example (SBE). Approccio collaborativo finalizzato alla definizione dei requisiti e dei test funzionali di business per prodotti software, e basato sull’acquisizione e l’illustrazione dei requisiti con esempi realistici invece che affermazioni astratte.

Spike / Spike. Breve intervallo di tempo in un progetto, in genere di durata fissa, durante il quale un team conduce ricerche o realizza prototipi su uno specifico aspetto di una soluzione per provarne la sostenibilità.

Sprint / Sprint. Descrive un’iterazione con intervallo di tempo fisso in Scrum.

Sprint backlog / Sprint Backlog. Elenco delle parti di lavoro identificate dal team Scrum che devono essere completate durante uno sprint.

Story Point / Story Point. Metrica priva di unità di misura, utilizzata per stimare in maniera relativa tra loro le user story.

Sviluppo guidato dai test / Test-Driven Development. Tecnica in cui prima di iniziare il lavoro si definiscono i test, affinché il lavoro in corso sia validato in modo continuativo, consentendo di lavorare con una mentalità “zero difetti”.

Swarming / Swarming. Tecnica in cui più membri del team si concentrano collettivamente sulla risoluzione di un impedimento specifico.

Team auto-organizzato / Self-Organizing Team. Team interfunzionale in cui le persone si assumono liberamente la leadership secondo necessità per raggiungere gli obiettivi del team.

Team interfunzionale / Cross-Functional Team. Team che comprende professionisti dotati di tutte le abilità necessarie per rilasciare incrementi del prodotto che abbiano valore.

Team Scrum / Scrum Team. Identifica la combinazione del Team di sviluppo, dello Scrum Master e responsabile di processo utilizzati in Scrum.

User story / User Story. Breve descrizione del valore di un deliverable per uno specifico utente. È un impegno ad avviare un confronto per chiarire i dettagli.

157

INDICE

AA3, 150Abbinamento. Vedere Lavoro in coppiaAcceptance test-driven development (ATDD, sviluppo

guidato dai test di accettazione).definizione, 150generazione di valore e, 56

Accettazione dei test, 82Accordi di lavoro, 50Accumulo di lavoro, 70

accumulo di, 70sprecato, 14

Adattamentogenerazione di valore e, 87processi e, 15, 28

Adatto all’uso, 151Adatto allo scopo, 151Affiancamento, 38, 55Affinamento del backlog, 52–53

conduzione di riunioni per l’, 53definizione, 150lunghezza affinamento e, 52

Agile Alliance, 1, 43Agile coach, 150Agile iteration-based

agile flow-based a confronto con, 24, 25grafici burn-down e, 62pianificazione per l’, 55stand-up e, 53

Agile Manifestocicli di vita agili e, 25definizione, 150mentalità e, 8–12

pratiche e, 10principi dell’, 9, 10, 50pubblicazione dell’, 87punti cardine, 38valori dell’, 2, 8, 10, 35, 77

Agileadozione di, 87definizione, 150implementazione dell’, 33–47popolarizzazione del termine, 10vari approcci e, 11

Agilist. Vedere Professionista agile Agilità organizzativa, ostacoli all’, 74Alterazione dell’ambito, 28Ambiente agile, creazione di un, 33–47Ambienti normativi, 36Analisi, dimostrazioni e, 55Analisi automatica della qualità del codice, 150Analisi quantitativa dei rischi, 37Anti-pattern

definizione, 150stand-up e, 55

Apprendimento Agile-based, 2Apprendimento continuo , 73Apprendimento double-loop, 151Apprendimento organizzativo, 82Apprendimento single-loop, 150Apprendimento

continuo, 73organizzativo, 82valore e, 61–62

Approcci/ocombinazione di, 31utilizzo del termine nella guida, 11

158 Indice

Approcci/o agili/eabbinare, 31approccio predittivo combinato con, 27componente predittiva e, 28componenti di, 10transizione verso, 73

Approcci non agili, 17Approcci predittivi

approccio agile combinato con, 27con componenti agili, 28misurazioni e, 60

Approccio “comincia da dove sei”, 13, 16Approccio contrattuale all’accrescimento del team, 76Approccio contrattuale ambito dinamico, 78Approccio ibrido, 27, 150Approccio imprenditoriale, PMO e, 81Approccio plan-driven, 150Approccio Time and Materials

con limite prefissato, 78graduale, 78

Approccio Time and Materials con limite prefissato, 78Approvvigionamento

contratti e, 77–79pratiche aziendali e, 79

Aspettative, definizione delle, 45Assegnazione del lavoro, 27ATDD. Vedere Acceptance test-driven development (sviluppo guidato dai test di accettazione)Autogestione , 36Automazione, 7Azioni, 51

BBacklog: Vedere Product backlogBaseline, 61BDD. Vedere Behavior-driven development (sviluppo guidato dal comportamento)Behavior-driven development (BDD)

definizione, 150generazione di valore e, 56

Big Dig, Boston (o Grande Scavo), 15Blended agile, 151Boston Big Dig (o Grande Scavo), 15BRD. Vedere Documentazione dei requisiti aziendaliBroken comb, 151

CCadenza

definizione, 151rilascio di un un prodotto funzionante e, 57

Call to action, 87Cambiamento/i. Vedere anche Incertezza

approcci agili e, 73essere pronti al, 73–74lavagna Kanban e, 85ostacoli al, 74requisiti e, 24rilascio accelerato e, 73sicurezza e, 75velocità di, mentalità agile e, 3

Capacità, interpersonali vs. tecniche, 36Capacità interpersonali, 36Capacità tecniche, 36Charter, progetto, 49–50Cicli di feedback , 2, 15Cicli di feedback cliente, 2Cicli di vita del progetto. Vedere Ciclo/i di vitaCiclo di vita agile flow-based

agile iteration based a confronto con, 24, 25stand-up e, 54

Ciclo di vita seriale, 17. Vedere anche Ciclo di vita predittivoCiclo di vita waterfall (a cascata), 17. Vedere anche Ciclo

di vita predittivoCiclo/i di vita agile/i

Agile Manifesto e, 25Caratteristiche dell’, 24–25approccio flow-based, 24approccio iteration-based, 24continuum dei cicli di vita e, 19definizione, 150

Ciclo/i di vita ibrido/icaratteristiche del/dei, 26–27come idoneo/i allo scopo, 29come strategia di transizione, 30esempio di, 26

Ciclo/i di vita incrementale/icaratteristiche del/dei, 22–23continuum dei cicli di vita e, 19definizione, 151incrementi di varie dimensioni e, 22

159

Ciclo/i di vita iterativo/icaratteristiche del/dei, 21–22continuum dei cicli di vita e, 19definizione, 151singolo rilascio di un prodotto, 21

Ciclo/i di vita predittivo/icaratteristiche del/dei, 20–21continuum dei cicli di vita e, 19definizione, 153

Ciclo/i di vita. Vedere anche Ciclo/i di vita agile/i; Ciclo/i di vita ibrido/i; Ciclo/i di vita incrementale/i; Ciclo/i di vita iterativo/i; Ciclo/i di vita predittivo/icaratteristiche del/dei, 18continuum del/dei, 19definizione, 151pianificazione e, 20selezione del/dei, 17tipologie del/dei, 17

Cloud computing, 3Collaborazione

buona volontà e, 37facilitazione di, 35, 38interdipartimentale, 73lavoro velocizzato e, 39mentalità di collaborazione con il cliente, 81processo di ufficializzazione e, 49relazione di condivisione rischio-guadagno, 77trasparenza e, 79

Collaudo a livello di sistema, 56Colli di bottiglia, 35, 42, 64Combinare gli approcci, 31Comitati di gestione dei cambiamenti, 35Competenze

interne, 83ostacoli e, 74PMO e, 82

Complessità. Vedere anche Modello della complessità di Staceycicli di vita ibridi e, 26cicli di vita iterativi e, 21incertezza e, 7, 13progetti con un alto tasso di cambiamento e, 38risoluzione dei problemi e, 57

Completezzanatura soggettiva della, 23accordi di lavoro e, 50

Componente predittivo, approccio agile con, 28

Compromessi , 76Comunicazione

facilitatori e, 35team distribuiti e, 46

Concetti base della guida. Vedere Concetti di baseConcetti di base, 1–5

apprendimento Agile-based e, 2motivo della guida, 2organizzazione della guida, 5sviluppo della guida, 1tecnologie dirompenti e, 3voci incluse/escluse, 4

Conoscenza, prodotto, 83Conoscenze di progetto, fornitori e, 83Coordinamento

di più team, 80servant leadership e, 35

Coordinamento multi-team, scalabilità eCPI. Vedere Indice di efficienza dei costiCriteri di accettazione

iterazioni e, 63pratiche di esecuzione e, 56

Cultura. Vedere Cultura dell’organizzazioneCultura dell’organizzazione, 75–77

ambiente sicuro e, 75valutazione, esempio di, 76PMO e, 81struttura organizzativa vs., 77valutazione della, 74–75

DDA. Vedere Disciplined AgileDaily scrum, 151Daily stand-up, 27, 44, 53–54

agile flow-based, 54agile iteration-based, 53anti-pattern e, 54

Debito tecnico, 151Definition of done (DoD), 151Definition of ready (DoR), 151Deliverable intermedi, 15Deliverable. Vedere anche Servizio/servizi

intermedio/intermedi, 15microdeliverable , 77orientato/i al valore, 77requisiti eriduzione delle dimensioni del progetto, 83

160 Indice

DevOps, 151Diagramma di flusso cumulativo , 70, 82Dimensioni dei lotti, 42Dimostrazione pratica, 22Dimostrazioni

revisioni e , 55rilasci e, 57

Dipendenze, coordinamento multi-team e, 80Disciplined Agile (DA), 151Documentazione dei requisiti aziendali (BRD), 151DoD. Vedere Definition of doneDoR. Vedere Definition of readyDripping. Vedere Broken combDSDM. Vedere Dynamic Systems Development MethodDynamic Systems Development Method (DSDM), 151

EEarned Value (EV), 61

funzionalità finite e, 67–68misurazione dell’, 68–69

Efficienza del flusso, 42Efficienza produttiva, 42

multitasking e, 44product owner e, 66stand-up e, 54

Elaborazione progressiva, 153. Vedere anche Affinamento del backlog

EV. Vedere Earned ValueEventi Kaizen, 151EVO. Vedere Evolutionary value deliveryEvolutionary value delivery (EVO), 151

eXtreme Programming (XP)collaborazione e, 80combinazione di approcci e, 31definizione, 152generazione di valore e, 56

FFacilitatore del team, ruolo del, 41Facilitatori, 35, 51Fattori di progetto, opzioni di personalizzazione e, 32Feature-Driven Development, 152Feedback

dimostrazioni e, 55integrazione del, 43iterazioni e, 57

lavoro sprecato, rilavorazione e, 15pianificazione e, 29prototipi e, 22, 23team agili e, 39, 42

Filtri di idoneità agili, 25Fishbowl window, 46Flow master, 152Flusso di valore, 152Formazione, 82Fornitori, che offrono un servizio completo, 79Fornitori, conoscenze di progetto e, 83

GGenerazione di valore per l’azienda, 16, 23, 29Gestione del budget, incrementale, 36Gestione del cambiamento. Vedere Gestione del

cambiamento organizzativoGestione del cambiamento organizzativo (OCM), 3,

71–74, 152approcci agili e, 71–72fattori determinanti per la, 73prontezza al cambiamento e, 73–74

Gestione multiprogetto, 82Grafici burn-up/burn-down delle funzionalità, 67Grafici delle funzionalità, 67Grafico burn-down

definizione, 152grafici delle funzionalità e, 67story point e, 62

Grafico burn-up del product backlog, 68Grafico burn-up

definizione, 152earned value e, 68–69grafici delle funzionalità e, 67modifiche all’ambito del progetto e, 64product backlog, 68story point e, 63

Gruppi auto-gestiti, 39Gruppo/i auto-organizzato/i. Vedere anche Team auto-organizzato/i

esempio, 43esempio di istituzione finanziaria , 44project manager e, 37stand-up e, 54

Guida PMBOK, 17, 38Guide to the Project Management Body of Knowledge, A.

Vedere Guida PMBOK

161

HHoshin Kanri, 152

IIDEAL, 152

product owner e, 52Idoneità, filtri di, 25Idoneità, opzioni di personalizzazione per migliorare l’, 32Idoneità allo scopo. Vedere anche Adatto allo scopo.

cicli di vita ibridi e, 29Impedimento/i

definizione, 152servant leader e, 35

Implementazione predittiva, a seguito di uno sviluppo agile, 26–27Incarichi part-time, rischio e, 45Incertezza. Vedere anche Cambiamento/icomplessità e, 7, 13esplorazione dell’, 16grado di incertezza tecnico, 14livello di incertezza medio-basso, 30requisiti e, 13, 14, 16, 22, 24rischio, selezione del ciclo di vita e, 13–16

Incertezza e modello della complessità, 14Incremento/i, rilascio di un un prodotto funzionante e, 57Indice di efficienza dei costi (CPI), 69Indice di efficienza della schedulazione (SPI), 69Information radiator, 152Iniziative incrementali, 20Insuccessi del progetto, 77Integrazione continua

combinazione di approcci e, 31definizione, 152generazione di valore e, 56

Integrazione. Vedere Integrazione continuaIntelligenza emotiva, 36Interazione faccia a faccia, 46Intervallo/i di tempo fisso. Vedere anche Spike

definizione, 152stand-up e, 53uso del/degli, 12

Ispezione, generazione di valore e, 87Iterazione/i

definizione, 152rilascio di un un prodotto funzionante e, 57story point e, 61, 64velocità e, 64

KKanban, analisi, 53

LLarge Scale Scrum (LeSS), 152Lavagna delle attività del progetto

analisi della 53diagramma di flusso cumulativo e, 70lavoro in corso e, 25

Lavagna delle attività. Vedere anche Lavagna Kanban; Lavagna delle attività del progettoanalisi della, 53

Lavagna Kanbanavanzamento del lavoro e, 86backlog delle azioni di cambiamento, prioritizzato, 85combinazione di approcci e, 31definizione, 152esempio di, 65

Lavagna Scrum, 152LavoroLavoro del progetto, 7Lavoro in coppia, 39Lavoro in corso, 31Lavoro sprecato, 14Lead Time

dipendenze esterne e, 66team agili flow-based e, 64tempo di ciclo e, 66

Leader di progetto, stakehoder e, 75Leadership. Vedere Servant leadershipLean Software Development (LSD), 153Lean

approccio agile e, 11Metodo Kanban e, 12–13

LeSS. Vedere Large-Scale ScrumLSD. Vedere Lean Software Development

MManaging Change in Organizations: A Practice Guide,

3, 71Manifesto. Vedere Agile ManifestoManifesto per lo sviluppo agile del software, 8Mappatura degli impattiMappatura del flusso di valore, 153Mappatura delle user story, 153Membri del gruppo dedicati, 44–45

162 Indice

Mentalità. Vedere Mentalità agileMentalità agile

Agile Manifesto e, 8–12, 10applicazione universale dell’, 87collaborazione con il cliente, 81definizione, 153iniziare con l’, 33organizzazioni a silos e, 47velocità di cambiamento, 3

Mentalità di collaborazione con il cliente, 81Mentoring, 37, 82Metodi agili

metodo Kanban e, 12schemi di riferimento e, 11, 80

Metodo Kanban, 16, 153approccio lean e, 11combinazione di approcci e, 31Lean e, 12–13nascita del, 12

Metodologie Crystal , 151Metriche. Vedere MisurazioniMetriche EVM, tradizionali, 69Microdeliverable a prezzo fisso, 77Minimum viable product (MVP), prodotto minimo

funzionante, 23Mini-waterfall, 39Misurazioni

baseline e, 61capacità, 66earned value e, 68–69EVM, 69prevedibilità, 66progetti agili e, 60–70qualitative, 60risultati e, 61–70story point e, 66team agili flow-based e, 64variabilità e, 61

Misure di capacitàagile iteration-based e, 55misurazioni alla data e, 66story point e, 66

Misure qualitative, 60Mobbing, 39, 153Modello della complessità di Stacey, 14, 15

Modello di pagamento al consumo o secondo le funzioni utilizzate, 3

Monitoraggio dell’avanzamento, 27. Vedere anche Lavagna Kanban

Multitaskinggrafici burn-down e, 63produttività e, 44–45

MVP. Vedere Minimum viable product, prodotto minimo funzionante

NNorme del gruppo, 50

OOCM. Vedere Gestione del cambiamento organizzativoOpzione di cancellazione anticipata, contratti e, 78Opzione di cancellazione, contratti e , 78Organizzazione/i

a silos, 47, 153far evolvere l’/le, 84–86fortemente basata/e sull’approvvigionamento, 83

Organizzazione a silosdefinizione, 153team interfunzionali e, 47

Organizzazioni di progetto distribuite a livello geografico, 83Organizzazioni fortemente basate sull’approvvigionamento,

83Ostacoli organizzativi, 35Ostacoli, agilità organizzativa e, 74Ostacolo. Vedere Impedimento

PPair programming, 102, 153Parking lot, problemi e, 54Passaggio tra attività diverse, produttività e, 44–45Passare da un contesto a un altro, 44, 45Patto interno. Vedere Project Charter.PDCA. Vedere Plan-Do-Check-ActPensiero lean, 11, 12Personale, sviluppo del, 82Personalizzazione

fattori di progetto che influenzano la, 32PMO e, 81prematura o approssimativa, 12transizione all’ibrido e, 30

163

Pianificazione a finestra mobile, definizione, 153Pianificazione dello sprint

definizione, 153Schema di riferimento Scrum e, 31

Pianificazioneagile iteration-based e, 55cicli di vita e, 20feedback e, 29ripianificazione e, 61

Pivot, 153Plan-Do-Check-Act (PDCA), 153PMO. Vedere Project management officePMO Agile. Vedere Project Management OfficePratica di sviluppo “follow the sun”, 44Pratiche agili, 50–57Pratiche aziendali, 79Pratiche di esecuzione, 56Pratiche di ingegneria ispirate a XP, 31Principi agili

apprendimento Agile-based e, 2definizione, 153prontezza al cambiamento e, 73team interfunzionali e, 43

Problemirisoluzione dei problemi, 57–59stand-up e, 54

Processi di pensiero. Vedere Mentalità agileProcessi interni, evoluzione dei, 73Processo di approvazione dell’FDA negli Stati Uniti, 26Processo di richiesta di modifica, 7, 8–12Processo unificato Agile, 153Prodotto finito. Vedere ValoreProdotto, minimum viable (minimo funzionante), 23Product backlog. Vedere anche Affinamento del backlog

definizione, 153iniziale, prioritizzato delle azioni di cambiamento, 85preparazione del, 52schema di riferimento Scrum e, 31

Product ownerdefinizione, 154efficienza produttiva e, 66product roadmap e, 52ruolo, membro del team agile, 41schema di riferimento Scrum e, 31team interfunzionali e, 38

Product roadmap, 52Produttività

incremento della, 39–40passaggio tra diverse attività e, 44–45

Professionista agiledefinizione, 150ruolo di project manager e, 37

Profilo a I, 42, 154Profilo a T, 42, 154Profilo tipo, 154Progettazione UX, 154Progetti a elevata incertezza, 7Progetti con lavoro definibile, 7Progetti con un alto tasso di cambiamento, 38Progetto/i

caratteristiche intrinseche e, 18di grandi dimensioni, 15

Project charter, 49–50Project Management Institute (PMI®), 1, 43Project Management office (PMO), 81–82

definizione, 154dimostrazioni e, 57multidisciplinare, 82orientato al valore, 81orientato all’invito, 81

Project Management, obiettivo del, 29Project Manager

ambiente agile edefinizione, 38ruolo del/dei, 37servant leadership e, 38

Propensione organizzativa, 154Proprietà condivisa del codice, 154Prototipazione, 15, 22Prova del fumo

definizione, 154generazione di valore e, 56

Punti deboli, risoluzione dei problemi e, 57–59

RRational Unified Process (RUP), 149Refactoring

combinazione di approcci e, 31definizione, 154

164 Indice

Regole di base, 50Relazione cliente-fornitore, deterioramento della, 77Remote pairing, 46Reporting sullo stato del progetto con il semaforo, 60Requisiti

cicli di vita predittivi e, 20cultura e, 75esplorazione iterativa dei, 15grafici burn-up/burn-down delle funzionalità e, 67incertezza e, 13, 14, 16, 22, 24mancanti, 60occuparsi di tutti i, 39prototipi e, 22

Requisiti del cliente. Vedere RequisitiRequisito funzionale, 154Retrospettiva, 27, 50–51

conoscenza del prodotto e, 83definizione, 153momenti chiave per le, 51

“Revisioni di fase” 77Riduzione degli sprechi, 15Rilasci. Vedere anche Generazione di valore per l’azienda

accelerati, 73frequenti, 55iterazioni, incrementi e, 57lavoro in corso e, 70natura soggettiva della, 23orientati al cliente, 29

Rilascio accelerato, cambiamenti associati al, 73Rilascio continuo, 154Rilascio del prodotto. Vedere RilasciRilascio delle funzionalità. Vedere RilasciRilavorazione

riduzione della potenziale, 23rischio di, 13, 14

Rischi di progetto, ciclo di vita ibrido e, 29Rischio/rischi

ciclo di vita ibrido e, 29incarichi part-time e, 45incertezza, selezione del ciclo di vita e, 13–16incrementi a prezzo fisso e, 77progetti a elevata incertezza e, 7relazione cliente-fornitore e, 77

Risoluzione dei problemi, 57–59, 82Risoluzione dei problemi, facilitazione della, 39–40Risorse umane, 79, 82Ritardi, 64

Ritorno sull’investimento (ROI), 30, 61Riunioni. Vedere Daily stand-upRiunioni sullo stato del progetto, 54Roadmap, product, 52ROI. Vedere Ritorno sull’investimentoRuoli agili, 40–41Ruolo/ruoli

project manager, 37specialisti temporanei e, 45team agili e, 40–41

RUP. Vedere Rational Unified Process

SSAFe®. Vedere Scaled Agile Framework®

SBE. Vedere Specification by exampleScalabilità, 80Scaled Agile Framework (SAFe®), 154Schema/i di riferimento

definizione, 154metodi agili, 80

Scrumcollaborazione e, 80definizione, 154schema di riferimento per lo, 31

Scrum Masterdefinizione, 154schema di riferimento Scrum e, 31

Scrum of Scrums, 154Scrumban, 155Servant leader

caratteristiche del/dei, 34facilitazione e, 35, 52ostacoli organizzativi e, 35processo di ufficializzazione e, 49, 50project manager che fanno uso del/dei, 38responsabilità del/dei, 34, 36–37ruolo del/dei, 33

Servant leadershipdefinizione, 155project manager e, 38responsabilizzazione del team e, 33–38 team agili e, 39

Service Request Manager, 155Servizio/servizi

PMO e, 82rilascio del/dei, 35

165

Servizio di business. Vedere Servizi/oSicurezza, ambiente di, 75Silos organizzativi. Vedere Organizzazione a silosSistema di sottoscrizione di un’assicurazione, 29SME. Vedere Subject matter experts, esperti in materiaSocial media, 2Soddisfazione aziendale, 60Soddisfazione del cliente, 2, 25Software Extension to the PMBOK® Guide Fifth Edition, 17Spazi di lavoro del team, 46Spazi di lavoro virtuali, 46Specialisti generalisti, 42Specialisti temporanei, 45, 83Specifica funzionale, 155Specification by example (SBE), 155SPI Vedere Indice di efficienza della schedulazioneSpike

affinamento del backlog e, 52definizione, 155generazione di valore e, 56

Sponsor, completamento del progetto e, 61Sprint, 155Sprint backlog, 155Stakeholder

formazione degli, 37gestione degli, 82leader di progetto e, 75

Stand-up. Vedere Daily stand-upStima

relativa, 67anticipata, 27

Stima anticipata, 27Stima relativa, 67Story card, 31Story point

completamento, 63definizione, 155grafico burn-down e, 62grafico burn-up e, 63iterazioni e, 61, 64misurazione, 66velocità e, 64

Story. Vedere anche User Storyaffinamento del backlog e, 52, 53terminare una story alla volta, 68velocity affidabile e, 61

Strategiacultura e, 75passione per una causa, 75

Strategia di transizione, cicli di vita ibridi come, 30Strumento visuale. Vedere Lavagna KanbanStruttura organizzativa, 83Strutture del team, 43Strutture funzionali, 83Subject matter experts (SME), 43, 82Sviluppo guidato dai test. Vedere anche Test-driven

development combinazione di approcci e, 31definizione, 155

Sviluppo softwareAgile Manifesto e, 8pratiche agili e, 2apprendimento e, 61leader di pensiero nello, 8

Swarming, 39, 155

TTDD. Vedere Sviluppo guidato dai test Team. Vedere anche Team agili; Team interfunzionale/i; Team auto-organizzato/i

auto-gestito/i, 39accumulo di lavoro e, 70colocato/i, 39, 43, 44, 45composizione del/dei, 38–47coordinamento, multi-team, 80dislocato/i, 43, 44, 45distribuito/i, 43, 46facilitatore, ruolo del/dei, 41gruppo centrale di redazione, guida e, 1membri chiave del/dei, 45pratiche aziendali e, 79progetto di avvio e, 49–50rilascio, 35

Team agilicaratteristiche per il successo dei , 39–40ruoli nei, 40–41

Team auto-organizzato/i, 9, 98definizione, 155

Team charter, 49–50Team colocati , 39, 43, 44, 45Team di rilascio, 35

166 Indice

Team distribuiti, 43, 44, 45Team distribuiti a livello geografico, 46Team interfunzionale/i

definizione, 155incrementi funzionali del prodotto e, 39leadership di progetto e, 47pratiche aziendali e, 79principi agili e, 43progetti con un alto tasso di cambiamento e, 38ruolo, membro del team agile, 41Schema di riferimento Scrum e, 31servant leadership e, 33sviluppo del prodotto e, 43

Team leader, 82Team Scrum, 154Tecniche di contrattualizzazione, 77–79

accrescimento del team, 76fornitori che offrono un servizio completo, 79incrementi a prezzo fisso, 77opzione dell’ambito dinamico, 78opzione di cancellazione anticipata, 78struttura a più livelli, 77time & materials con limite prefissato, 78time & materials graduale, 78valore generato e, 77

Tecnologie dirompenti, 2, 3Tempo di ciclo

dipendenze esterne e, 66lead time e, 66team agili flow-based e, 64

Tempo di reazione, 66Tempo di risposta, 64Test

accettazione, 82a tutti i livelli, 56automatizzati, 31, 56incertezza e, 16

Test automatizzati, 31, 56Test-driven development (TDD, sviluppo guidato dai test).

generazione di valore e, 56Test unitari, 56Trasparenza

collaborazione e, 79generazione di valore e, 87successo e, 85

UUser story

come microdeliverable, 77definizione, 155dimostrazioni e, 55

VValore. Vedere anche Generazione di valore per l’azienda;

Deliverableaccelerazione del, 30apprendimento e, 61–62generazione di, 16, 23, 56intermedio, 29metriche e, 60ottimizzazione del flusso, 38–39tecniche di contrattualizzazione e, 77

Valore cliente. Vedere ValoreValori del team, 50Variabilità, misure di, 61Velocità

definizione, 64stima relativa e, 67

Video conferenze, 46Vincoli, 20, 31, 42Visione del progetto, 49Voci escluse, 4Voci incluse, 4

WWIP. Vedere Work in progress (WIP - lavoro in corso)Work in progress (WIP - lavoro in corso), 39

diagramma di flusso cumulativo e, 70lavagna delle attività e, 25lavagna Kanban e, 66

XXP. Vedere eXtreme Programming