Horsa ebook

GESTIRE I PROGE T TI IN
MODO AGILE
INTRODUZIONE ALL’AGILE
PROJECT MANAGEMENT

#neverstopexploring www.horsa.com
 Agile Project Management - prima parte

SOMMARIO

Introduzione all’Agile............................................................................ 3
1.1 Il Project Management............................................... 3
1.2 I vincoli di progetto................................................... 5
1.3 Il Manifesto Agile....................................................... 6
1.4 L’Agile e gli approcci tradizionali............................... 8
1.5 Confronto tra Agile e Waterfall................................ 9

Strumenti e ruoli nell’Agile................................................................. 12

2.1 Caratteristiche dei metodi Agile............................... 12
2.2 Sfide nello sviluppo Agile del software................... 13
2.3 Metodologie Agili..................................................... 14
2.4 Hybrid Project Management.................................... 14

pagina 2 di 18
CAPITOLO 1
INTRODUZIONE ALL’AGILE

1.1 Il Project Management

Tutte le aziende vivono e organizzano, a volte anche inconsapevolmente, progetti

di vario tipo nel quotidiano; imparare a gestirli significa acquisire strumenti
fondamentali per aumentarne l’efficacia (do the right things) e l’efficienza (do the
things right).

Un progetto è definito da Wikipedia come “Il complesso di attività correlate tra

loro e finalizzate a creare prodotti o a pubblicare servizi rispondenti a obiettivi
specifici determinati”. Non è, quindi, semplicemente il disegno di ciò che si
deve realizzare (“Design”), ma è l’insieme di attività che si devono svolgere per
giungere a un obiettivo prefissato (“Project”). In altre parole, è lo svolgimento di
un piano studiato per raggiungere una meta predefinita. Dove c’è un obiettivo
da raggiungere, il progetto è l’insieme di attività necessarie per raggiungere tale
obiettivo.

Dalla definizione di progetto del Project Management Institute, secondo cui “un
Progetto è uno sforzo temporaneo sostenuto per creare un prodotto o servizio
unico”, desumiamo tre caratteristiche comuni ad ogni progetto:

•  Temporaneità: un progetto è tale (in senso stretto) se ha un inizio e,

soprattutto, una fine. In altri termini, se non si riesce ad intravederne la fine,
probabilmente non è un progetto (magari un processo?);
•  Creazione: un progetto è volto a creare e/o a realizzare qualcosa;
•  Unicità: l’oggetto della creazione è unico, non ripetitivo.

Per quanto ogni progetto sia unico e impossibile da replicare, potrebbe (e

dovrebbe) esistere un processo di gestione progetti, ben definito a priori, da
seguire per gestire in maniera strutturata i progetti aziendali.

pagina 3 di 18
 Agile Project Management - prima parte

Il PMBOK® (Project Management Body of Knowledge) individua cinque processi

di Project Management:

•  Initiating: si determina il valore del progetto e la sua fattibilità creando così il

Business Case e il Feasibility Study. Il progetto viene sottoposto, a questo punto,
agli stakeholder.
•  Planning: una volta che il progetto è stato approvato viene identificato il team
di lavoro e inizia la fase di pianificazione. Il progetto viene, quindi, pianificato
in termini di tempi, costi, risorse, qualità; vengono inoltre identificati i rischi/
opportunità e il piano di comunicazione.
•  Executing: creato il piano di progetto, inizia la fase operativa. Il progetto prende
il via e si lavora alle diverse fasi e attività.
•  Controlling: questa fase consiste nel verificare che il progetto stia andando
nella “direzione” giusta (scope control), che il lavoro sia svolto rispettando i
vicoli di tempi, costi e qualità e eventualmente nell’apportare i cambiamenti
necessari a quanto pianificato. Durante tutta la durata del progetto, viene svolto,
quindi, quello che si definisce “avanzamento” del progetto, ossia la verifica del
raggiungimento degli obiettivi e la ri-pianificazione delle attività a finire.
•  Closing: così come è fondamentale avviare correttamente un progetto, lo è
anche chiuderlo con ordine. Una chiusura pianificata del progetto consente di
normalizzare tutte le informazioni e le esperienze maturate (lesson learned)
oltre a gestire in maniera appropriata tutte le eventuali attività amministrative
ad esso legate.

MONITORING & CONTROLLING

PLANNING

INITIATING CLOSING

EXECUTING

Figura 1.1: I processi di Project Management secondo il PMBOK®.

pagina 4 di 18
 1.2 I vincoli di progetto
I progetti sono tipicamente gestiti prendendo in considerazione quattro variabili
che descrivono i vincoli ai quali un progetto deve attenersi. Tali variabili sono:

•  Tempi: le tempistiche di progetto dipendono da quanto le attività sono

interdipendenti;
•  Costi: legati al budget disponibile per il progetto e al costo delle risorse
appartenenti al team di lavoro;
•  Qualità: dipende da quanto il risultato finale risponde alle esigenze espresse
dal committente;
•  Ambito: si riferisce alle diverse funzionalità da implementare.

Mentre nella metodologia tradizionale l’ambito non è modificabile, l’approccio

Agile rovescia il triangolo che rappresenta queste variabili, trasformando in
vincoli non mutabili i Costi e i Tempi.

Con “Timeboxing” ci si riferisce alla pratica di definire i Tempi: quindi ad ogni

Timebox la soluzione prodotta incrementa e muta, producendo una nuova
versione. Inoltre, per fissare la Qualità si definiscono dei criteri di accettazione.

L’Ambito nell’Agile diviene invece un parametro che identifica, nelle funzionalità

da implementare, un diverso livello di priorità. Questo è possibile grazie alla
tecnica MoSCoW, che classifica i requisiti del committente in “Must have”, “Should
have”, “Could have” e “Won’t”.

APPROCCIO TRADIZIONALE APPROCCIO AGILE

AMBITO TEMPI COSTI

FISSE

QUALITÀ QUALITÀ

VARIABILI

TEMPI COSTI AMBITO

Figura 1.2: Le variabili di progetto (Simone Onofri, 2013).

pagina 5 di 18
 Agile Project Management - prima parte

1.3 Il manifesto Agile

Il termine Agile nell’ambito del project management viene utilizzato per la prima
volta nel 2001 da Kent Beck nel suo “Manifesto for Agile Software Development”.

In questa pubblicazione l’autore, citando le sue stesse parole, propone “migliori

modalità di sviluppare software” ossia, un nuovo approccio alla gestione dei
progetti basato su metodologie più agili di quelle tradizionali, spesso non adatte
a progettualità di questo tipo. I quattro capisaldi fondamentali, su cui si basa il
Manifesto, sono:

1. Gli individui e le interazioni vengono prima dei processi e degli strumenti;

2. Il software funzionante è più importante della redazione di documentazione
completa;
3. La collaborazione con il cliente è più importante della negoziazione dei
contratti (il cliente è parte attiva nel progetto);
4. Rispondere al cambiamento ha maggior valore rispetto a seguire un piano.

A partire da questi punti fondamentali, appare chiaro il cambiamento di

prospettiva rispetto al project management come si era inteso fino a quel
momento. Senza negare l’importanza di processi, strumenti, documentazione,
aspetti contrattuali e pianificazione, Beck restituisce dignità ad aspetti che fino ad
ora erano rimasti in secondo piano.

In primo luogo, infatti, si sottolinea l’importanza degli individui e delle interazioni:

assumono quindi un’importanza centrale la comunicazione e la condivisione
delle informazioni, il team building e la coesione del gruppo e, di conseguenza,
l’importanza del risultato globale più che delle performance del singolo.

In secondo luogo, nel manifesto viene posta un’attenzione particolare al software

funzionante, ossia ai risultati del progetto più che alla documentazione. Pur
ritenendo importante la documentazione, più rilevante è produrre un output di
qualità nel più breve tempo possibile. Per fare questo è necessario essere agili,
il che implica concentrarsi in primo luogo sulla documentazione di progetto
effettivamente necessaria, e successivamente sul resto.

I progetti di sviluppo software sono spesso caratterizzati da specifiche definite

solo parzialmente o che cambiano nel tempo; per questa ragione è importante
poter far fronte a questi cambiamenti in corso di progetto. Adottando metodologie
tradizionali e contratti rigidi è difficoltoso adattarsi a variazioni di questo tipo.
A tal proposito, l’approccio Agile propone di concentrarsi sulla collaborazione
tra cliente e fornitore, più che sulla redazione di contratti che definiscano nel
dettaglio i singoli deliverable di progetto.

pagina 6 di 18
Per poter gestire questa flessibilità è necessario contrattualizzare le attività con
contratti adatti (o contratti “agili”). Ne sono esempio:
•  contratti a forchetta minima e massima;
•  contratti a condivisione del rischio;
•  contratti a soglie;
•  contratti Time & Material.

Strettamente legato al tema della collaborazione è il quarto caposaldo proposto nel

Manifesto Agile. Rispondere al cambiamento crea maggior valore aggiunto rispetto
a seguire alla lettera un piano predeterminato. Essere agili significa poter cambiare
in parte gli obiettivi in corrispondenza di rischi e opportunità che si presentano
in corso di progetto, al fine di raggiungere il miglior risultato possibile.
A partire da questi quattro capisaldi, gli autori del Manifesto hanno stilato una
lista di dodici principi che dovrebbero essere applicati alla gestione di un progetto
Agile:

1. La priorità è soddisfare il cliente tramite la veloce e continua consegna di

software di qualità.
2. I cambiamenti nei requisiti sono benvenuti anche nelle fasi avanzate di
sviluppo. I processi Agile sfruttano il cambiamento per dare vantaggio
competitivo al cliente.
3. Bisogna consegnare software funzionanti con frequenza, settimanalmente o
mensilmente, preferibilmente con l’orizzonte temporale più breve.
4. Il business e i tecnici devono lavorare insieme ogni giorno sul progetto.
5. I progetti si costruiscono con individui motivati. È necessario dare a queste
persone l’ambiente e il supporto necessari, così come la fiducia necessaria
per permettere che il lavoro venga svolto.
6. Il modo più efficace ed efficiente per scambiare le informazioni con il team
è faccia a faccia.
7. Il software funzionante è la misura del progresso del progetto.
8. I processi Agile promuovono lo sviluppo sostenibile. Lo sponsor di progetto,
gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere un
ritmo costante per un tempo indefinito.
9. È necessaria un’attenzione continua all’eccellenza tecnica, perché il buon
design migliora l’agilità.
10. È essenziale la semplicità, ossia massimizzare la quantità di lavoro non
fatto.
11. Le migliori architetture, requisiti e design emergono da team che si
organizzano autonomamente.
12. Ad intervalli regolari il team deve riflettere su come diventare più efficace e
modificare i propri comportamenti di conseguenza.

pagina 7 di 18
 Agile Project Management - prima parte

1.4 L’Agile e gli approcci tradizionali

Per comprendere l’Agile e il successo che ha avuto negli ultimi due decenni è
necessario fare un passo indietro ed esaminare gli approcci al project management
di tipo più tradizionale.

Quando si parla di approccio tradizionale si fa riferimento al modello cosiddetto

“Waterfall” (a cascata). Questo approccio al project management si caratterizza
per una rigida sequenzialità delle attività di progetto: il progetto è composto da
una serie di fasi che vengono svolte con una sequenzialità ben definita a priori.
Ognuna delle fasi non inizia prima della fine dell’attività precedente, in quanto
l’output di ciascuna fase rappresenta l’input della fase successiva. Nel caso di
progetti di sviluppo software le fasi sequenziali potrebbero essere:

1. analisi dei requisiti;

2. design della soluzione;
3. sviluppo;
4. collaudo;
5. manutenzione.

REQUIREMENT
ANALYSIS

DESIGN

DEVELOPMENT

TESTING

MAINTENANCE

Figura 1.3: Le fasi dello sviluppo di un software.

pagina 8 di 18
Nell’esempio, la fase di Design inizierà una volta terminata l’analisi dei requisiti,
lo sviluppo a seguito della fase di Design, il Test una volta concluse le attività
di sviluppo e così via. Un approccio di questo tipo presenta alcune peculiarità
intrinseche:
•  Rischi relativi alla schedulazione. Esiste un alto rischio di non centrare gli
obiettivi di tempo prefissati; risulta infatti impossibile considerare fin da subito
tutte le variabili in gioco e descrivere in maniera completamente definita i
requisiti e il design della soluzione.
•  Limitata flessibilità. Ad esempio, i requisiti che sono alla base del software
che verrà sviluppato sono congelati molto presto senza possibilità di essere
rivisti in seguito. Accade spesso però che i requisiti non siano completamente
definiti nelle fasi iniziali del progetto o che gli stessi possano cambiare in corso
d’opera per il manifestarsi di rischi/opportunità che devono essere tenuti in
considerazione per ottenere un output di qualità nei tempi e al costo definiti.
•  Scarso coinvolgimento del cliente. Il cliente viene coinvolto solo nelle prime
fasi del progetto, con il conseguente rischio di non riuscire a soddisfarne i
desideri in maniera completa.

1.5 Confronto tra Agile e Waterfall

L’approccio Waterfall viene descritto da un modello sequenziale lineare;
suggerisce, quindi, un metodo sistematico e sequenziale allo sviluppo. Tale
approccio è stato adottato negli anni Settanta per ridurre i costi di sviluppo e
progettare fin da subito applicazioni rilasciabili e funzionanti; negli anni è divenuto
un punto di riferimento per tutte le metodologie successive e i processi di
sviluppo.

Tuttavia, si tratta di una metodologia che non risponde in modo efficace

all’instabilità dei requisiti del cliente e non costruisce una forte relazione con
esso, ma richiede confronti principalmente nei momenti di avvio e di conclusione
dei progetti. Operando attraverso delle fasi successive a cascata, i problemi
non vengono rilevati nell’immediato e non si producono versioni intermedie
funzionanti.

Inoltre, qualora una fase dovesse terminare in ritardo, questo si ripercuote

sull’intero processo. Per questi motivi, si tratta di un approccio utile in presenza
di requisiti chiari e definiti in un contesto tecnologico maturo, ma risulta
di difficile applicazione qualora il software richiesto sia complesso e richieda
tecnologie innovative.

pagina 9 di 18
 Agile Project Management - prima parte

Gli approcci più innovativi del mondo Agile rivisitano in chiave iterativa i passaggi
della Waterfall aderendo, così, al contesto complesso e incerto di oggi; contesto in
cui i clienti rivedono i requisiti nel corso dello sviluppo e le tecnologie sono in continua
innovazione. Questa instabilità rende impossibile sviluppare un’applicazione in un unico
processo che parte da un’attività e arriva all’ultima, senza produrre versioni intermedie
che rappresentino il prodotto richiesto e che rendano possibile fare dei test e apportare
modifiche in modo veloce. Con gli approcci Agile, infatti, ad ogni step vengono
rivalutati i requisiti e fissati nuovi obiettivi.

Sebbene grazie alla metodologia Agile sia disponibile una prima versione di
prodotto in tempi brevi, prima di arrivare alla versione definitiva sono richieste
numerose revisioni e modifiche, non contemplate in un approccio tradizionale a
Waterfall. In definitiva, l’approccio tradizionale permette di operare in modo
strutturato quando sono definite e fisse le variabili di Budget, Tempo e
Requisiti, mentre il metodo Agile risulta una valida alternativa per rispondere
alla richiesta di flessibilità in cui si guarda alle esigenze della domanda. La scelta
va fatta perciò tra un sistema più prescrittivo, ossia maggiormente vincolato da
standard e uno adattivo, quindi più libero da vincoli.

La metodologia Agile, pur proponendo uno sviluppo iterativo, non abbandona

gli standard descritti nel PMBOK®. Questo contiene infatti anche delle logiche
iterative che si consiglia di mettere in pratica in alcune tipologie di progetto. In
particolare, nonostante si preveda un approccio a cascata che sviluppi le fasi in
modo sequenziale per descrivere il ciclo di vita di un progetto, per altre fasi, come
l’ingegnerizzazione, si espone la possibilità di utilizzare le iterazioni proposte, per
esempio, dalla metodologia SCRUM. I due approcci si adattano quindi a situazioni
diverse, e talvolta è anche possibile l’integrazione tra le due per gestire sia il
rilascio di molteplici versioni, sia il controllo dei costi e dei rischi del progetto. Un
modo per confrontare le due metodologie è guardare ai costi di pianificazione e
ai costi da sostenere per introdurre delle modifiche.

Figura 1.4: Confronto tra i costi di pianificazione.

pagina 10 di 18
 CRM Solution Integrator

Come si può vedere dai grafici, mentre la metodologia tradizionale ha alti costi
di pianificazione iniziali, che poi vanno riducendosi di molto, quelli dell’approccio
Agile crescono nel tempo fino a stabilizzarsi, nelle fasi finali, su di un costo
maggiore rispetto a quello dell’approccio classico. Tuttavia, nel caso sia necessario
apportare delle modifiche allo scope o alle caratteristiche implementate, i costi nel
caso del metodo tradizionale crescono in modo esponenziale, mentre hanno un
andamento più costante nell’Agile.

Figura 1.5: Confronto tra i costi di modifica.

pagina 11 di 18
 Agile Project Management - prima parte

CAPITOLO 2
STRUMENTI E RUOLI NELL’AGILE

2.1 Caratteristiche dei metodi Agile

Agile significa adattarsi alle contingenze. Come detto, Agile è un insieme di

metodologie che mettono a disposizione una serie di strumenti, tool, framework
che consentono di abbattere il peso delle attività necessarie a gestire il progetto
(pianificare, controllare, comunicare…).
Alcuni tra i più efficaci paradigmi operativi, testati negli anni, sono: SCRUM,
Kanban e DSDM. Tali approcci hanno suscitato interesse nel panorama dello
sviluppo software perché forniscono un sistema per analizzare un problema
complesso e risolverlo. Ognuno di questi metodi ha le sue caratteristiche, ma tutti
condividono i valori dell’Agile esposti nel Manifesto.

Un altro elemento, che lega le diverse metodologie, è il ciclo di vita dello sviluppo
Agile, il quale si articola secondo quattro fasi: una prima fase denominata
Interation 0, una fase di Sviluppo in cui seguendo step incrementali si crea il
sistema, una fase di Rilascio che produce l’ultima versione dell’applicazione e,
infine, la Produzione.

1. L’iterazione iniziale: Iterazione 0, dà avvio al progetto cercando i fondi

necessari e individuando gli stakeholder, quindi crea una prima lista dei requisiti e
realizza un modello dell’architettura che assumerà il prodotto.

2. L’iterazione di sviluppo ha lo scopo di fornire versioni funzionanti del

software. Questo è possibile grazie alla collaborazione tra il team e gli stakeholder,
che si scambiano feedback, dall’analisi dei requisiti basata sulla tecnica Just in
Time (JIT) e dall’attenzione alla qualità, che assicura il miglior design possibile.
Tutto il processo di sviluppo Agile si fonda su una cultura del test; tutte le
funzionalità implementate vengono, infatti, testate sia con automatismi sia
manualmente.

3. Terminata la fase di sviluppo si passa a quella di Rilascio. Questa può essere

descritta da una o più iterazioni che hanno lo scopo di lanciare in produzione
il sistema. Si testa il sistema ottenuto e si procede a formare gli utenti e gli
operatori che utilizzeranno l’applicazione.

4. La fase di Produzione è l’ultima: l’obiettivo, in questo caso, è quello di

mantenere i sistemi produttivi anche dopo essere entrati in utilizzo. Questa fase
termina quando il software viene sostituito da un altro.

pagina 12 di 18
2.2 Sfide nello sviluppo Agile del software
Per riuscire ad utilizzare in modo efficiente le metodologie Agili è importante
sviluppare nuove competenze e approcciare l’argomento con una mentalità
diversa, rispetto a quella che richiederebbe il processo di sviluppo tradizionale.
Innanzitutto, l’Agile richiede molta perseveranza, perché il processo completo
è lungo e iterativo. Inoltre, anche al management è richiesta una maggiore
attenzione per seguire lo sviluppo in ogni sua parte e per consentire al team
libertà nel prendere le decisioni.

La disciplina è un elemento fondamentale. Il codice sviluppato deve sempre

essere rilasciabile in una versione funzionante e inoltre deve essere integrato
in modo continuo. Le competenze tecniche e manageriali richieste sono più
complesse e cross-funzionali, motivo per cui per approcciare queste tecniche il
team deve essere consapevole dello sforzo e dell’impegno necessario per portare il
progetto a termine. Anche la pianificazione del progetto richiede uno sforzo in più;
infatti, una pianificazione Agile deve essere più dettagliata di quella proposta
nelle metodologie tradizionali. Questo tipo di pianificazione viene effettuata in
diverse fasi ed è continuamente rivista e aggiornata, deve adattarsi alle esigenze
mutevoli del cliente, e questo aumenta notevolmente la sua complessità.

Per sviluppare un’applicazione attraverso una metodologia Agile il livello di

supporto deve essere molto elevato. Si rende necessario sia il supporto a
livello organizzativo, per promuovere la cultura al cambiamento, permettere il
coinvolgimento delle gerarchie superiori ed eliminare la burocrazia, sia a livello
infrastrutturale e logistico, in modo da rendere disponibili tutte le pratiche
utili per sviluppare sistemi di questo tipo (come i sistemi di integrazione, il Pair
programming ecc.).

Infine, fondamentale per la buona riuscita del progetto è il team di sviluppo.

Le persone appartenenti al team dovrebbero essere motivate e legate dalla
passione per l’argomento, dovrebbero essere di mentalità aperta, pronte al
cambiamento e molto flessibili. In genere, è necessario che il team sia localizzato
in un unico posto, così da poter favorire lo scambio di informazioni.

pagina 13 di 18
 Agile Project Management - prima parte

2.3 Metodologie Agili

L’Agile Project Management comprende molte metodologie e approcci per la
gestione di progetti nell’ambito dell’Information Technology e non solo. Tra questi
si trovano: Scrum, DSDM (Dynamics System Development Method), Kanban, che
segue la filosofia Lean e altri. Tra le metodologie Agili per il Project Management
spesso si cita anche l’XP (Extreme Programming), ma questa dovrebbe essere
distinta poiché è una metodologia di sviluppo software e non di Project
Management.

Il Project Management Institute® (PMI®) promuove la conoscenza dell’Agile,

riconoscendo quali sono le capacità da assimilare per essere riconosciuto come
un professionista in grado di operare con un approccio Agile. PMI® mette a
disposizione diverse certificazioni, come l’esame Agile PMI-ACP®, che individua
dei criteri per riconoscere i professionisti che utilizzano le metodologie Agile nei
progetti.

Esiste poi il DSDM che identifica un altro metodo per fare Agile; esso è fondato su
otto principi. Tale metodo è stato diffuso dal consorzio DSDM, nato allo scopo di
definire uno standard per lo sviluppo rapido delle applicazioni.
Infine, la metodologia SCRUM, che diffonde il principio del Timeboxing e definisce
dei ruoli chiave che lavorano al progetto.

2.4 Hybrid Project Management

L’approccio tradizionale spesso non è considerato il metodo più efficace; tuttavia,
in alcuni casi anche l’Agile non è idoneo ad alcuni tipi di progetti. Si introduce,
perciò, l’approccio Ibrido che punta a combinare gli aspetti vantaggiosi degli
approcci Waterfall-Agile-Lean.

La metodologia ibrida permette al team di progetto di pianificare il lavoro

prima dell’avvio del progetto, ma al tempo stesso, suddivide il ciclo di sviluppo
in finestre temporali. Inoltre, l’ibrido è capace di gestire i cambiamenti nei
requisiti grazie all’iteratività dello sviluppo.

Mentre la pianificazione viene fatta utilizzando i principi tradizionali descritti da

fasi consecutive in cascata, l’esecuzione del progetto e il suo rilascio seguono la
filosofia Agile.

pagina 14 di 18
Quest’ultima fase si può affrontare inoltre attraverso dei “Cartellini” (Kanban) che
rappresentano le task da svolgere nell’ambito delle singole iterazioni. Si ottiene
così una stima e una pianificazione accurata, pur permettendo al team di reagire ai
cambiamenti.

Hybrid Project Management negli anni si sta diffondendo notevolmente, tanto

che è considerato uno dei maggiori trend dell’ultimo anno. Le panoramiche
metodologiche nel campo del project management, quindi, sono sempre più
ampie, così da permettere di scegliere l’approccio che si ritiene più adatto a
seconda delle caratteristiche del progetto che si sta avviando.

Vuoi saperne di più? - Abstract seconda parte

Nel prossimo e-book, in uscita nei prossimi mesi, saranno esposte più nel dettaglio
alcune delle metodologie Agile, quali: il Dynamic System Develompent Method, la
metodologia SCRUM, la metodologia Kanban.
Queste sono le metodologie più conosciute e più utilizzate nelle aziende che
adottano l’Agile. Ognuna porta vantaggi diversi e richiede particolari conoscenze
per essere applicata nel migliore dei modi.
L’obiettivo del secondo e-book dedicato all’Agile è quindi quello di mettere a
confronto le varie metodologie, così da capirne appieno le diverse caratteristiche e
imparare a destreggiarsi nella scelta dell’approccio che si adatta meglio alla propria
realtà.

pagina 15 di 18
 Agile Project Management - prima parte

BIBLIOGRAFIA
Ambler, S., & Holitza, M. (2012). Agile for dummies. John Wiley & Sons, Inc.

Anwer, F., & Aftab, S. (2017). SXP: Simplified Extreme Programing Process Model.
Modern Education and Computer Science(6), 25-31.

Caciotti, M. (2018). Burn Down Graph and Project requirements reporting. Tratto da help.
wrike.com: https://help.wrike.com/hc/en-us/community/posts/360001265865-Burn-
Down-Graph-and-Project-requirements-reporting

Caracciolo, S. (2018, ottobre 1). Extreme Programming. Tratto da pmi.it: https://www.

scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf

Justice, J. (2018). The 3-5-3 of Scrum. Tratto da scruminc.com: https://www.scruminc.

com/the-3-5-3-of-scrum/

Kniberg, H., & Skarin, M. (2014). Kanban e Scrum - ottenere il massimo da entrambi.

Logistica efficiente. (2018). Supermarket. Tratto da https://www.logisticaefficiente.it/

wiki-logistica/magazzino/supermarket.html

Onofri, S. (2013). Le variabili di progetto nell’approccio “Agile” e “Tradizionale”. Tratto

da onofri.org: {http://onofri.org/b/dsdm-le-variabili-di-progetto-nellapproccio-agile-e-
tradizionale/

Ovais, M., Dennehy, D., Conboy, K., & Oivo, M. (2018). Kanban in software engineering:
A systematic mapping study. Journal of Systems and Software, 96 - 113.

Project management center. (2018). Metodologia Agile e PMBOK: waterfall e metodo

iterativo. Tratto da Humanwareonline: http://www.humanwareonline.com/project-
management/center/pmbok-agile/

Project Management Institute. (2017). PMBOK Guide.

Prylutskyi, D. (s.d.). Scrum and Kanban – Are They That Different After All? Tratto da
perfectial.com: https://perfectial.com/blog/scrum-and-kanban-are-they-different/

Schwalbe, K. (s.d.). Information Technology Project Management.

Stapleton, J. (1997). DSDM, Dynamic Systems Development Method: The Method in

Practice.

Agile Business Consortium, DSDM Consortium diventa Agile Business Consortium.

Tratto da: https://www.imlearning.it/dsdm_abc/

pagina 16 di 18
Gli autori

Maurizio Ciraolo
Maurizio Ciraolo Responsabile di Horsa PPM Division. PMP® – Prince2® Practitioner - P3O®
(Portfolio, Programme and Project Offices) - Oracle Primavera Implementation Specialist -
Change Management®, AgilePM® - PMO Value Ring® Practitioner.

Alessia Collavo
Alessia Collavo Consulente della divisione PPM di Horsa – Laureata in Ingegneria Gestionale
con tesi: “Change Management nell’implementazione di strumenti a supporto del Project
Portfolio Management”. Ha partecipato a vari progetti in ambito PPM.

Riccardo Masullo
Riccardo Masullo Consulente della divisione PPM di Horsa – Prince2® Foundation, ITIL®
Foundation – Laureato in Ingegneria Gestionale, ha coordinato numerosi progetti nel campo
del Project Portfolio Management, come consulente e come Project Manager.

HORSA - Conosciamo i problemi delle aziende, e le difficoltà a superarli attraverso la riorganizzazione e

l’adozione di nuove soluzioni applicative, anche in ambito PPM.
Ma conosciamo anche i vantaggi di tali trasformazioni, è per questo che abbiamo basato il nostro
Business sull’innovazione, per essere al fianco delle aziende che vogliono crescere ed evolvere, alle volte
salvarsi.
Ci consideriamo un fattore abilitante, alla stregua delle soluzioni best of breed che veicoliamo ai nostri
clienti, per il successo dei progetti di modernizzazione.
I nostri clienti sono pronti a testimoniarlo.

info@horsa.com
www.horsa.com

pagina 17 di 18
Iscrivendosi ad uno dei prossimi corsi Horsa Academy entro il 30 Giugno 2019 potrà godere di uno
sconto del 20% sulla quota di adesione.
Usufruirne è semplicissimo: le basterà inserire il codice PROMOEBOOK19 nel campo “CODICE
DEL BUONO”, presente nella pagina carrello, una volta selezionata l’opzione “ISCRIVITI” sulla
pagina del corso stesso.

PROMO Partecipa ai corsi Horsa

PROMOEBOOK19
EBOOK Academy con il
20% di SCONTO

COUPON CHE GARANTISCE LO SCONTO DEL 20% PER LA PARTECIPAZIONE AI

CORSI PROPOSTI DA HORSA ACADEMY DURANTE IL 2019.

Per consultare l’elenco dei corsi visita il sito www.horsacademy.com

La promozione non è cumulabile con altre iniziative in programma e non è applicabile a corsi con certificazione o corsi
Qlik. Maggiori informazioni al link www.horsacademy.com/termini-e-condizioni. Horsa Academy si riserva ad ogni modo
di validarne l’applicabilità. Promozione valida fino al 30 Giugno 2019.

BOLOGNA VICENZA MILANO

www.horsacademy.com

pagina 18 di 18