Horsa ebook

LE METODOLOGIE DI AGILE
PROJECT MANAGEMENT

UNO SGUARDO APPROFONDITO

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

SOMMARIO

Dynamic Systems Development Method.............................................. 3

1.1 Il DSDM...................................................................... 3

La metodologia SCRUM....................................................................... 5
2.1 Lo SCRUM.................................................................. 5
2.2 I ruoli......................................................................... 7
2.3 Gli artefatti............................................................... 8
2.4 Gli eventi................................................................... 10
2.5 I vantaggi dello SCRUM............................................. 11

La metodologia Kanban......................................................................... 12
3.1 Il Kanban.................................................................... 12
3.2 Sistema pull del supermarket.................................... 12
3.3 Kanban Board............................................................. 13
3.4 Vantaggi dell’utilizzo del Kanban......................... 15
3.5 SCRUM e Kanban a confronto................................... 15

Extreme Programming......................................................................... 17
4.1 Cosa è l’XP............................................................... 17
4.2 Valori e pratiche dell’XP............................................ 18
3.2 Caratteristiche e vantaggi dell’XP............................. 19
4.4 La pratica DevOps..................................................... 20

Bibliografia.......................................................................................... 21

pagina 2 di 22
INTRODUZIONE

Nel precedente ebook “Gestire i progetti in maniera Agile” abbiamo conosciuto

la metodologia Agile del Project Management: un nuovo approccio alla gestione
dei progetti in azienda, che supera il metodo tradizionale “Waterfall” per garantire
più flessibilità e capacità di adattarsi ai cambiamenti all’interno del flusso di un
progetto. Abbiamo visto i dodici principi fondamentali della metodologia Agile, fatto
un confronto con l’approccio tradizionale, esplorato i ruoli delle persone coinvolte in
progetti di questo tipo e compreso vantaggi e limitazioni.

Questo ebook si propone uno sguardo più approfondito sui tipi di metodologie
Agile che si possono applicare, per dare modo ai lettori di comprenderne appieno
le diverse caratteristiche e renderli autonomi nella scelta dell’approccio più adatto.

CAPITOLO 1
DYNAMIC SYSTEMS DEVELOPMENT METHOD

1.1 Il DSDM – Agile Business Consortium

Il DSDM, conosciuto come Dynamic System Development Method, mette a

disposizione un framework e definisce le best practice per lo sviluppo rapido di
applicazioni (RAD). A partire dal 1994 si è diffuso in particolare grazie al successo
ottenuto in UK.
Recentemente il DSDM Consortium ha deciso, dopo il grande successo riscontrato
in tutto il mondo, di estendere la propria attività con l’obiettivo di portare i valori e
la filosofia Agile nel mondo del business. A seguito di questa decisione il DSDM è
diventato a tutti gli effetti Agile Business Consortium.

L’Agile Business Consortium è un’associazione che ha come obiettivo quello di

diffondere la metodologia Agile cercando di ottenere gli stessi risultati raggiunti con
l’approccio tradizionale del Waterfall. L’approccio Agile si concentra sul ciclo di vita
del progetto e si sviluppa in otto principi:
1. Focus sui bisogni di business: ogni decisione dovrà essere presa sulla base
dell’obiettivo di business per cui si è avviato il progetto.
2. Rilasci entro il tempo stabilito: il principale risultato atteso dal progetto è
la consegna in tempo del prodotto. Il tempo è, infatti, ritenuto come uno
dei principali fattori per misurare il successo di un progetto. Per poter gestire
nel migliore dei modi questa variabile critica, il tempo viene suddiviso in
timeboxes.
pagina 3 di 22
 Agile Project Management - seconda parte

3. Collaborazione: permette di aumentare la velocità, la comprensione e la

responsabilità del team di sviluppo
4. Non compromettere la qualità: definito il livello di qualità da raggiungere,
conforme a quello richiesto dal cliente, non si dovrà mai produrre
un’applicazione inferiore alle aspettative, che sarà considerata non accettabile
5. Costruzione incrementale: lo sviluppo avviene in modo incrementale,
definendo di volta in volta le priorità. Per fare questo sfrutta la tecnica
MoSCow, suddividendo le funzionalità richieste dallo scope in must, should
e could.
6. Sviluppo iterativo: le prime versioni rilasciate non saranno mai perfettamente
conformi a quella richiesta dal committente. Attraverso l’iteratività si giungerà
all’ultima applicazione rilasciata, che rispetterà il minimo livello di accettabilità
7. Comunicazione continua e chiara: la comunicazione spesso è la causa del
fallimento dei progetti; per tale motivo l’approccio DSDM lavora per migliorare
questo aspetto
8. D
imostrazione di controllo: per essere Agile è importante lavorare in modo
coordinato, agendo in funzione di un obiettivo comune.

Il Dynamic System Development Method, sviluppato dall’organizzazione DSDM, è

una soluzione efficace su progetti aziendali complessi anche non in ambito IT, perciò
non riguarda solo lo sviluppo di software.

Le tecniche chiave su cui si fonda il DSDM sono, quindi: il timeboxing, per consentire
di completare il progetto in modo incrementale, la tecnica MoScoW per prioritizzare
lo scope e la prototipazione, per dare la possibilità di rilasciare il progetto anche a
stadi intermedi del suo sviluppo.

Altra pratica, che permette di portare il progetto al successo, è il testing: testando

infatti l’applicazione ad ogni iterazione è possibile mantenere il livello di qualità
pari a quello che si aspetta il cliente. Infine, i workshop incentivano le relazioni e la
comunicazione con gli stakeholder, aprendo discussioni in merito alle funzionalità da
implementare nel prodotto.
In seguito verranno esposte altre tecniche (i.e. SCRUM e Kanban) che hanno in
comune al DSDM alcune caratteristiche tipiche dell’Agile.

pagina 4 di 22
CAPITOLO 2
LA METODOLOGIA SCRUM

2.1 Lo SCRUM

Il principale approccio per lo sviluppo di software Agile è lo SCRUM: un framework

Agile che racchiude un insieme di pratiche, ideato nel 1993 da Ken Schwaber e
da Jeff Sutherland. Esso suddivide in “Sprint” (finestra temporale con durezza
prefissata) il processo di gestione di un progetto in modo da riuscire a migliorare il
coordinamento del processo di sviluppo di un prodotto, controllando le interazioni
tra committente e cliente. SCRUM è un termine preso in prestito dal mondo del
rugby, traducibile in “mischia”; esso indica il bisogno di spingere tutto il team verso
un obiettivo comune.

Nell’ambiente dinamico dello sviluppo software di oggi si ritiene inadatto l’utilizzo

degli strumenti tradizionali, come l’approccio Waterfall, e cresce la necessità di
mantenere sotto controllo progetti molto complessi, che vedono alcuni parametri
progettuali in costante fluttuazione e, quindi, imprevedibili, come il budget, le
specifiche del cliente ecc. È per questo che nasce lo SCRUM, una metodologia
secondo la quale tutte le modifiche apportate al progetto derivano dall’esperienza
accumulata dal team di lavoro e non solo da una base teorica. Infatti, la teoria
alla base di tale processo è l’empirismo; tale teoria evidenzia il fatto che il processo
decisionale è mosso da ciò che il decisore conosce e che l’esperienza deriva essa
stessa dalla conoscenza. Da questo segue la considerazione dell’approccio SCRUM:
il progetto viene gestito secondo un processo incrementale di Sprint successivi che
ottimizza la prevedibilità e il controllo del rischio.

Trasparenza, ispezione e adattamento sono i pilastri che sostengono il controllo

empirico di processo:
• Trasparenza: gli aspetti più significativi del progetto devono essere visibili
e chiari agli stakeholder, responsabili del risultato finale. Affinché vi sia
trasparenza è essenziale che il team di lavoro condivida la comprensione di
ciò che osserva attraverso, per esempio, un linguaggio comune
• Ispezione: serve a tracciare l’avanzamento verso l’obiettivo identificato e
a seguire gli artefatti in modo tale da rilevare in anticipo uno scostamento
rispetto a quanto è stato pianificato
• Adattamento: mantenere la coerenza con il processo e, in caso di deviazioni,
adattarlo rapidamente a quanto stabilito serve per ridurre l’ulteriore deviazione.

Il framework SCRUM è costituito dallo Scrum Team e dai ruoli, eventi, artefatti
e regole ad esso associati. Ognuno di questi elementi è essenziale per l’utilizzo
efficace dello SCRUM.

pagina 5 di 22
 Agile Project Management - seconda parte

Figura 2.1: Elementi chiave dell’approccio SCRUM (Joe Justice, 2018).

Figura 2.2: Il processo SCRUM (Denys Prylutskyi, 2015).

pagina 6 di 22
2.2 I ruoli

Nello SCRUM vengono identificati quattro ruoli differenti, ossia: Product Owner,
Scrum Master, Scrum Team e Stakeholders.

• Il Product Owner è colui che dirige il progetto e ne è proprietario. Si interfaccia

con gli stakeholder e i clienti e, dall’altro lato, con il team di lavoro. Conosce
i requisiti richiesti al prodotto e deve assicurarsi di portare avanti gli interessi
del cliente, massimizzando il valore che deriverà dal prodotto e il lavoro che
il Team di Sviluppo dovrà svolgere. Compito del Product Owner è gestire il
Product Backlog risolvendo i conflitti che possono emergere, definendo le
priorità tra le attività e modificando le funzionalità qualora fosse necessario.
• Lo Scrum Team (o Team di Sviluppo) è un gruppo, formato tra le quattro
e le otto persone, con competenze specialistiche cross-funzionali in grado
di tradurre le richieste del Product Owner in un prodotto che può essere
rilasciato entro la fine dello Sprint. Lo Scrum Team si auto-organizza per
portare a termine un certo lavoro e, poiché possiede tutte le abilità richieste,
non dipende da altri al di fuori del gruppo. Tipicamente si trovano figure
quali analisti, programmatori, addetti al controllo qualità, architetti e
amministratori di database. Lo Scrum Team sviluppa il prodotto e ne testa
le funzionalità; in particolare esso è addetto a creare un elenco di task,
chiamati “Sprint Backlog” per realizzare parte dello sprint pianificato.
• Lo Scrum Master funge da facilitatore. Egli non entra nel merito delle
funzionalità o della schedulazione del task, ma detiene le conoscenze
dell’approccio SCRUM e supporta il team di lavoro evitando le distrazioni dal
lavoro in corso e mantenendo attivi la motivazione e l’interesse. Lo Scrum
Master incontra il team prima di aprire ogni Sprint per discutere quanto è
stato imparato da quello precedente e come migliorare il processo evitando
di ripetere gli errori commessi.

pagina 7 di 22
 Agile Project Management - seconda parte

2.3 Gli artefatti

Gli artefatti rappresentano il valore e il lavoro che si sta portando avanti in modo da
incentivare la trasparenza e rendere maggiormente semplice l’ispezione e l’eventuale
adattamento del processo. Le funzionalità di prodotto sono contenute nei Backlog,
gestiti dai Product Owner; i Backlog possono essere di due tipi:

• Il Product Backlog racchiude le funzionalità del prodotto in via di sviluppo.

Nell’approccio SCRUM i requisiti vengono definiti durante varie fasi e vengono
aggiornati nello Sprint successivo all’interno dei Backlog, aumentando così
la conoscenza del prodotto. Per tale motivo il Product Backlog non è mai
completo, ma è dinamico e identifica in modo continuo cosa è necessario
al prodotto; si tratta perciò di un artefatto vivente. Esso viene aggiornato
continuamente al fine di aggiungere dei dettagli, delle stime e di assegnare
delle priorità ai requisiti del cliente.
• Lo Sprint Backlog individua quali product backlog sono stati selezionati per
uno specifico Sprint. Esso fornisce la previsione del team di lavoro sulle
attività da svolgere per raggiungere lo Sprint Goal. Lo Sprint Backlog fornisce
in sostanza un’immagine in tempo reale per monitorare l’avanzamento dello
Sprint. Essa viene aggiornata durante tutto lo Sprint, man mano che il team
di lavoro viene a conoscenza dei dettagli su come lavorare per raggiungere
lo Sprint Goal. L’incremento del lavoro viene misurato come somma di tutti
gli elementi del Product Backlog completati durante uno Sprint e i suoi
precedenti.

Per monitorare quotidianamente il flusso dei progressi si analizza la BurndownChart.

La Burndownchart è un diagramma cartesiano che analizza l’andamento di uno

Sprint misurandone la quantità di lavoro residuo. Nell’asse delle ordinate sono indicati
i giorni di effort, mentre le ascisse mostrano la timeline dello Sprint; stabilito a che
velocità il team di lavoro completa le attività previste, si disegna la linea ideale
dell’effort erogabile giorno per giorno; quindi si confronta tale linea con i giorni che
mancano alla consegna dello Sprint. Nel caso in cui la linea che rappresenta i giorni
mancanti dello Sprint si trovi sopra a quella ideale dell’effort, significherebbe un
ritardo del progetto.

pagina 8 di 22
Figura 2.3: Burndown Chart (Marco Caciotti, 2018).

La metodologia SCRUM è basata sulla trasparenza: da questo approccio derivano

anche le decisioni assunte allo scopo di massimizzare il valore fornito e ridurre il
rischio. Infatti, a seconda di come sono percepiti gli artefatti, le decisioni possono
avere una base solida o meno; più sono veritieri e trasparenti, più le decisioni prese
risulteranno corrette.

Nei casi in cui lo Scrum Master e il Product Owner non si fidino degli artefatti, ci
sono pratiche per gestire le situazioni meno chiare. Per evidenziare le condizioni
di poca trasparenza è importante ispezionare gli artefatti e identificare le differenze
rispetto ai risultati attesi.

La trasparenza si ottiene attraverso un percorso che comprende una fase di

apprendimento, una di persuasione ed una di cambiamento.

pagina 9 di 22
 Agile Project Management - seconda parte

2.4 Gli eventi

Gli eventi di SCRUM si sviluppano all’interno di precise e definite finestre temporali
(Sprint); in questo modo un evento avrà una durata massima e sempre chiara. Mentre
la durata della finestra temporale non può essere modificata, gli eventi terminano
quando si è raggiunto il loro scopo; lo Sprint, quindi, raccogli diversi eventi.
L’evento di SCRUM fornisce l’occasione di ispezionare un punto e di adattarlo al
processo; è progettato per incentivare la trasparenza e l’ispezione.

Lo Sprint è l’elemento chiave dell’approccio SCRUM. Esso può avere durata

massima di un mese; in questo tempo il prodotto in via di sviluppo incrementa le
sue funzioni e al termine viene prodotta una versione potenzialmente rilasciabile.
Lo Sprint successivo parte immediatamente al termine di quello precedente. Ogni
Sprint viene considerato come un progetto al quale è assegnato anche uno scopo
preciso, chiamato Sprint Goal: esso inizialmente deve essere pianificato, motivo per
cui durante il meeting che avviene all’avvio dello Sprint (il Meeting Sprint Planning),
si definisce lo Sprint Goal e si determina come rilasciare gli incrementi prodotti. In
sostanza, si definisce:
• Cosa si può fare in questo Sprint.
• Come si procederà per completare il lavoro scelto.

Un altro meeting importante per controllare l’avanzamento giorno per giorno e per
definire e sincronizzare le attività per le 24 ore successive è il Daily Scrum, che si tiene
ogni giorno alla stessa ora. In questa occasione si controlla il lavoro svolto dopo l’ultimo
Daily Scrum e si pianifica come procedere fino al prossimo incontro. Ogni persona del
team in questa riunione, che non deve durare più di quindici minuti, espone:
• Cosa ha fatto il giorno prima per contribuire al raggiungimento dello Sprint
Goal
• Cosa ha in programma di fare in quel giorno
• Se riconosce degli ostacoli al raggiungimento dell’obiettivo.

Lo Scrum Master deve assicurarsi che il Team di Sviluppo tenga la riunione ogni
giorno e che non duri più di quanto previsto, ma la responsabilità della conduzione
del meeting è del Team di Sviluppo.

Al termine delle Sprint si tiene un altro incontro: la Sprint Review. Attraverso questa
riunione si ispeziona l’incremento avuto durante lo Sprint e si adatta il Product Backlog,
se necessario, in modo da averlo aggiornato per lo Sprint successivo. Presentando
l’incremento ottenuto si migliora la collaborazione e si cercano feedback. Il risultato
di questa riunione è proprio il Product Backlog rivisitato con gli elementi da introdurre
nel prodotto nel periodo successivo.

pagina 10 di 22
 CRM Solution Integrator

La Sprint Retrospective, invece, è una riunione di circa tre ore (per uno Sprint della
durata massima di un mese) in cui il team si riunisce per creare un piano di miglioramento
da attuare nello Sprint successivo. Quindi, si tratta di un’ispezione dello stesso team di
lavoro al fine di adattarlo in preparazione al periodo di lavoro che seguirà.

2.5 I vantaggi dello SCRUM

Si utilizza l’approccio Agile, e in particolare la metodologia SCRUM, qualora la

complessità dei progetti e la difficoltà di allineare il lavoro necessario alle richieste
mutevoli dei clienti lo richiedano. In particolare, tale metodologia si adatta bene
al contesto digitale in cui vengono sviluppati progetti complessi che richiedono un
team di professionisti con competenze multidisciplinari e commissionati da clienti
che cercano trasparenza ed efficienza nel lavoro svolto. Lo SCRUM permette di
ottenere benefici sostanziali per l’azienda, ma anche per il team di lavoro e per il
management.

L’azienda ne ricava velocità di esecuzione del lavoro grazie all’aumento dell’efficienza

e al controllo sul tempo effettivamente speso per ogni attività, minor dispersione
delle risorse grazie a un aumento della concentrazione sull’attività in corso e relazioni
migliori con i clienti, migliorando così la loro soddisfazione finale a lavoro consegnato.

Il team di sviluppo risulta maggiormente responsabilizzato e focalizzato

sull’obiettivo da raggiungere. La visibilità sull’avanzamento del progetto consente
di migliorare la motivazione e l’interessa verso le attività che si stanno portando
avanti. Conseguentemente migliora l’empowerment generale delle risorse coinvolte
nel progetto.

Infine, il management ottiene un allineamento costante con il business e una

pianificazione e un monitoraggio efficienti, così da poter intervenire nel caso sorgano
problemi. Grazie ad una chiara panoramica sullo stato complessivo del progetto è
semplice ottimizzare anche la linea strategica e, eventualmente, apportare delle
correzioni.

pagina 11 di 22
 Agile Project Management - seconda parte

CAPITOLO 3
LA METODOLOGIA KANBAN

3.1 Il Kanban

Kanban (in giapponese “cartellino”), è un framework che nasce dalla filosofia Lean
(snella) ed è utilizzato per la gestione dei progetti. Prende spunto dall’approccio
just-in-time (JIT) e si basa sull’uso di “lavagne” dette “Kanban board”. I prerequisiti
per l’utilizzo di tale metodologia sono la comunicazione real-time e la trasparenza
nel lavoro.

La pratica Kanban, come detto, si basa sul metodo di produzione Lean: l’idea è nata
nel 1940 dopo un’osservazione sul metodo di gestione dello stock di articoli sugli
scaffali dei supermercati. Si è scoperto che riducendo il numero di scatole dello
stesso articolo a scaffale, ma contemporaneamente assicurandosi che l’articolo
resti sempre disponibile, si ottiene un aumento dell’efficienza. L’utilizzo del
cartellino serve a comunicare in real-time la necessità di produrre un certo materiale
che è stato utilizzato dalla linea produttiva, o è stato venduto, motivo per cui non è
più disponibile e deve essere sostituito. Quindi, il cartellino costituisce un metodo
di segnalazione visuale che identifica la mancanza di una certa fornitura per
una stazione di lavoro. Questo implementa una logica di produzione “pull” che
contrasta la logica “push” tipica delle aziende occidentali.

Oggi, il principio JIT viene applicato anche nell’ambito dello sviluppo software,
allineando la quantità di work in progress con la capacità del team di lavoro; si è poi
diffuso nella maggior parte dei settori industriali.

3.2 Sistema pull del supermarket

L’utilizzo del Kanban prende spunto dal flusso con cui vengono mossi i materiali
all’interno di un supermarket; da qui nasce l’approccio “pull” utilizzato nel sistema
di produzione giapponese in Toyota (produzione Lean).
I supermarket sono magazzini in cui sono disponibili a scaffale tutti i prodotti. La
produzione, attraverso il Kanban, si attiva solo nei casi in cui è necessario sostituire
un pezzo che manca a scaffale. Tramite questa metodologia, lo stadio a valle, ossia
lo scaffale, riesce a dare una cadenza di produzione a quello a monte. Quindi, un
materiale prodotto viene posizionato a scaffale; nel momento in cui viene spedito
o prelevato dal cliente, il suo Kanban, che contiene il codice del pezzo e altre
specifiche, viene staccato e rimesso in coda affinché venga prodotto nuovamente il
materiale che manca nel supermarket.

pagina 12 di 22
Figura 3.1: Logica Pull in un supermarket (Logistica efficiente, 2018)

3.3 Kanban Board

Nelle catene produttive circola un vero e proprio cartellino che indica la necessità di
produrre un pezzo; tale Kanban viene posizionato in una lavagna per comunicare lo
stato di lavorazione di quel materiale. Invece, nel caso di un team di sviluppatori
di software si utilizza una lavagna chiamata “Kanban board” che può essere
anche virtuale. Tale lavagna può essere perciò un tool per visualizzare il flusso di
lavoro e ottimizzarlo. L’utilizzo di strumenti visuali è uno dei capisaldi della filosofia
Agile, poiché questi strumenti permettono la collaborazione, la comunicazione e
l’accessibilità ai dati. Anche nei casi in cui la Kanban board debba essere condivisa
con un team di persone esteso, oppure tra diversi gruppi di lavoro, è necessario
l’utilizzo di una lavagna virtuale.

Una Kanban board può essere facilmente adattata alle esigenze di ogni team, ma
quella standard suddivide il flusso di lavoro in tre stati:
• To do / New
• In progress
• Done / Completed

Per ogni colonna della lavagna viene visualizzata una precisa fase del processo da
seguire. I cartellini posizionati sulla lavagna rappresentano le attività in esecuzione,
ad ogni colonna è associato un limite al numero di lavori in WIP (Work in Progress);
il movimento dei cartellini da una fase ad un’altra, perciò, è attivato dalla capacità
residua delle colonne a valle. In una lavagna fisica normalmente vengono utilizzati
dei post-it.

pagina 13 di 22
 Agile Project Management - seconda parte

L’utilizzo di una Kanban Board virtuale permette diversi vantaggi; spesso infatti si
tratta di tool scalabili e facilmente espandibili. Inoltre, tali strumenti dispongono di
molte caratteristiche, fra cui:
• L’integrazione delle mail
• Accessibilità da remoto
• Strumenti di reporting e misure di performance
• Integrazione con altri sistemi aziendali, come software di Project Portfolio
Management o piattaforme HelpDesk.

Figura 3.2: Kanban Board in Needful.cloud.

pagina 14 di 22
3.4 Vantaggi dell’utilizzo del Kanban

Il Kanban, da strumento visuale per indicare la lista delle attività da svolgere,

diviene un potente strumento per ottimizzare il flusso di lavoro e incentivare la
collaborazione evidenziando i problemi e le possibilità di miglioramento.

L’obiettivo di questa tecnica è limitare la quantità di lavoro etichettato come “in

progress” in modo tale che il flusso in lavorazione non ecceda la capacità produttiva;
così facendo si velocizza il flusso di lavoro perché si evitano i colli di bottiglia. La
lavagna in cui sono posizionati i Kanban rende chiaramente visibile a colpo d’occhio
se ci sono degli step produttivi che necessitano di attenzione. Grazie alla metodologia
Agile del Kanban il team si focalizza sul lavoro che viene etichettato in progresso;
inoltre, il Product Owner è libero di assegnare delle priorità ai Kanban che devono
essere lavorati senza interferire con le lavorazioni in atto. In questo modo viene
raggiunta un’elevata flessibilità di pianificazione.

Un altro vantaggio è il corto tempo di ciclo, considerato una metrica per il team di
lavoro. Con tempo di ciclo si intende il tempo in cui un cartellino transita nel flusso
di lavorazione, dal momento in cui inizia ad essere lavorato fino a quando non
viene spedito. Ottimizzando il tempo di ciclo diventa facilmente prevedibile la
consegna dei lavori futuri.

Infine, si cerca di ridurre al minimo i colli di bottiglia. Per raggiungere questo

obiettivo è necessario aumentare l’efficienza promuovendo la distribuzione di
capacità e skill tra il team. Per ridurre i colli di bottiglia, inoltre, vengono posti
dei limiti per quanto riguarda la capacità del work in progress (WIP) della linea di
produzione.

3.5 SCRUM e Kanban a confronto

Le metodologie Agili si dicono “leggere” perché sono meno prescrittive rispetto a

quelle tradizionali. Per metodologia prescrittiva si intende una metodologia con molte
regole e norme da seguire che impediscono al dipendente di avere libertà di decisione;
al contrario, una metodologia “adattiva” ha pochi standard da osservare. SCRUM e
Kanban sono entrambe molto adattive, ma lo SCRUM presenta più vincoli, lasciando
così meno libertà. Infatti, mentre lo SCRUM ha delle logiche da seguire per operare
all’interno delle finestre temporali Sprint, prescrive dei ruoli e così via, la metodologia
Kanban risulta maggiormente libera.

pagina 15 di 22
 Agile Project Management - seconda parte

Per quanto riguarda la cadenza del processo, lo SCRUM ha una lunghezza precisa e
definita entro la quale bisogna rispondere ad un obiettivo e rilasciare una versione
del prodotto, che va approvata dal product owner, invece, il Kanban incentiva un
flusso di lavoro continuo, supervisionato dal team.

Nell’approccio Scrum, inoltre, esistono dei ruoli definiti: il product owner, lo

scrum master e il team di sviluppo, nel Kanban non esistono ruoli all’interno
del team. Queste metodologie vengono comparate anche per quanto le metriche
utilizzate per valutare le prestazioni. Nello SCRUM si tiene sotto controllo la velocità
con cui si portano a compimento le attività, attraverso la Burndown Charnt, invece,
nel Kanban si valuta il tempo di ciclo con cui ogni cartellino completa tutti gli step
nel flusso di lavoro.

Infine, un ulteriore differenza riguarda la filosofia con cui si approccia il cambiamento.

Nello SCRUM, una volta pianificato e avviato uno Sprint questo non può essere
modificato. Eventuali modifiche vengono introdotte nella finestra temporale
successiva che, una volta iniziata, dovrà giungere a compimento senza cambiamenti
nelle previsioni iniziali. Nel Kanban il cambiamento viene gestito in ogni momento.

Esiste tuttavia il termine “Scrumban” con il quale alcuni team uniscono le due
idee. In particolare, dallo SCRUM ereditano i ruoli e la lunghezza fissa degli
Sprint, mentre dal Kanban la focalizzazione sul WIP e l’analisi del tempo ciclo.
Quest’idea in ogni caso non rientra nelle metodologie Agili riconosciuto; infatti,
viene raccomandato di attenersi ad un approccio unico e utilizzare i suoi standard.

pagina 16 di 22
CAPITOLO 4
EXTREME PROGRAMMING

4.1 Cosa è l’XP

La programmazione Extreme Programming (XP) è una metodologia agile e un

approccio all’ingegneria del software, sviluppata da Kent Beck nel 2000, che ha
avuto successo nel mondo dei software.
A fine anni ’90, infatti, l’industria del software stava cercando nuovi metodi di
sviluppo software per ridurre il rischio di errori causati dai modelli di sviluppo
tradizionali XP1. Si tratta appunto di un metodo Agile, quindi, permette di rilasciare
frequenti versioni successivamente a sviluppi ciclici di breve durata che migliorano
in modo incrementale la qualità del software e introducono i nuovi requisiti del
cliente, promuovendo la reattività alle mutevoli esigenze.
Inoltre, l’obiettivo è quello di ridurre il costo delle modifiche tardive.

XP è una metodologia, efficiente, considerata adatta per progetti e a basso rischio,

flessibile e prevedibile per lo sviluppo di software, efficace in particolare modo
in un team relativamente piccolo, composto da 12-16 sviluppatori. In particolare,
attraverso l’Extreme Programming si può:
• Controllare il processo e ridurre il lavoro dedicato al supporto.
• Evitare di produrre semilavorati non necessari, ma concentrare lo sforzo sulla
produzione dell’applicazione.
• Fornire meccanismi per apprendere cosa serve costruire per soddisfare il
cliente.

L’innovazione dell’Extreme Programming sta nel definire a priori solo tre delle
quattro variabili che entrano in gioco dei progetti software, ossia: costo, tempo,
qualità e portata.
La quarta variabile rappresenta il grado di libertà che verrà definito dal gruppo di
lavoro sulla base delle altre tre. Nelle pratiche tradizionali il management tende a
fissare tutte e quattro le variabili, creando un ostacolo al gruppo di lavoro.

pagina 17 di 22
 Agile Project Management - seconda parte

4.2 Valori e pratiche dell’XP

L’Extreme Programming si compone di quattro valori:
• Comunicazione per permettere di elaborare le informazioni nel modo corretto
al fine di rimanere aderenti alle esigenze espresse dal cliente
• Semplicità: mantenendo pulito il design del sistema si favorisce la
manutenzione nel tempo del software e ridurre il costo delle modifiche
• Feedback: mantenendo la relazione con il cliente durante tutto il progetto è
possibile governare al meglio i cambiamenti che si renderanno necessari
• Coraggio nel modificare il sistema e per testare il corretto funzionamento
anche dopo molte modifiche.

Alla base dell’EX si trovano dodici pratiche:

• Pair Programming: è la pratica maggiormente conosciuta dell’XP. il codice del
programma viene scritto da una coppia di programmatori che lavorano allo
stesso terminale; un programmatore assume il ruolo di ”guidatore” e l’altro
di “navigatore”. Le coppie si compongono associando le migliori competenze
per portare a termine un determinato progetto. Il lavoro in coppia permette
lo scambio periodico dei ruoli e di mantenere un livello di concentrazione
maggiore
• Planning Game: le funzionalità che conterrà il prossimo rilascio vengono
descritte come la storia della versione
• Test driven development: l’applicazione è verificata a livello di sistema e a
livello del singolo metodo
• Whole Team: il team di lavoro include persone con competenze diverse
negli ambiti della progettazione, programmazione, analisi e test
• Continuous integration: il codice deve essere fortemente integrato così da
avere una versione funzionante disponibile al team di lavoro
• Design Improvement: il design viene periodicamente rivisto per semplificare
la struttura
• Small Releases: vengono rilasciate versioni funzionanti dell’applicazione ad
ogni iterazione di sviluppo
• Coding standard: il codice si basa su regole condivise comprensibili da tutti
gli sviluppatori
• Collective code ownership: il codice è aperto a tutti gli sviluppatori, tutti
possono apportare modifiche
• Simple design: l’architettura deve essere più semplice possibile
• System metaphor: ogni progetto viene descritto da una metafora condivisa
da responsabili e sviluppatori. In questo modo non è necessario scendere nei
dettagli dell’implementazione per capire di quale progetto si sta parlando
• Sustainable pace: le attività richiedono molta concentrazione, è consigliabile
non allungare le sessioni di lavoro per non ridurre la qualità dell’impegno.

pagina 18 di 22
4.3 Caratteristiche e vantaggi dell’XP

I modelli di sviluppo software Agili forniscono un modo iterativo e incrementale di

sviluppo del software, per creare il prodotto con maggiore enfasi sulla soddisfazione
del cliente, la collaborazione del team e la gestione dei mutevoli requisiti. Come per
lo SCRUM e le altre tecniche Agili, anche XP è un modello iterativo e incrementale.
Utilizza piccole iterazioni, a partire dalle funzionalità di base del sistema, per produrre
una nuova versione del software.

La metodologia XP è consigliata a chi vuole ridurre al massimo il tempo di

sviluppo di un software coinvolgendo molto il cliente durante l’intero processo e
prevenendo in modo scrupoloso i malfunzionamenti.
Tale approccio è ideale nei casi in cui ci sia un’alta predisposizione al cambiamento
e non ci sia il timore di dover rivedere e modificare il codice molte volte.
Secondo i principi Agile, XP mette al centro le persone, rispettando i loro bisogni
personali, sociali e psicologici.

Tuttavia, la mancanza di documentazione, la scarsa struttura architettonica e una

minore attenzione al design sono i suoi principali svantaggi che ne influenzano
le prestazioni. A causa di questi problemi, non può essere utilizzato per tutti i tipi
di progetti.

Le considerazioni fatte per i progetti in ambito di sviluppo software sono, tuttavia,

valide e sempre più utilizzate anche per progetti di altro tipo. Infatti, gli approcci
Agili si sono diffusi in qualsiasi settore di mercato, proprio per la loro caratteristica
di essere efficaci in ambiti dove le variabili di progetto sono poco prevedibili.

pagina 19 di 22
 Agile Project Management - seconda parte

4.4 La pratica DevOps

DevOps è una metodologia di sviluppo del software che sfrutta le nuove logiche della
collaborazione e condivisione.
L’obiettivo di DevOps è quello di accelerare i tempi in cui vengono rilasciate le
applicazioni. Ciò è possibile proprio grazie a una nuova filosofia di condivisione
e di integrazione tra gli sviluppatori e gli addetti alle operations che consente di
accelerare i tempi di progettazione, testing e di rilascio delle soluzioni applicative
aziendali.
Il DevOps è un set di pratiche che portano a dei cambiamenti nella cultura aziendale
supportati da strumenti automatici e processi di Lean Management, che consente di
automatizzare il rilascio del software rispetto alla sua catena di produzione. Le
aziende possono così garantire un’elevata qualità delle applicazioni sviluppate e, al
tempo stesso, accontentare il cliente nei minor tempo possibile.

Figura 4.1: pratica DevOps.

pagina 20 di 22
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 21 di 22
 Agile Project Management - seconda parte

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 22 di 22