1. Introduzione alle metodologie Agile

2. NEXTRE ENGINEERING
Nextre Engineering da 10 anni offre ai suoi
clienti una gamma di servizi al top nella progettazione
NEXTRE ENGINEERING È UNA SOCIETÀ DI SVILUPPO SOFTWARE, WEB MARKETING E
CONSULENZA STRATEGICA.
Il nostro team è composto da figure professionali eterogenee e complementari:
programmatori software, UX e web designer, esperti SEO e marketing, project manager.
Per questo Nextre si propone come partner in grado di accompagnare i clienti nella
realizzazione del proprio posizionamento su internet in tutto il suo percorso: dalla
definizione del business model alla progettazione, fino al delivery online, alla
comunicazione e al consolidamento sul mercato.
DRAFT

3. AGILE MANIFESTO
Mirko Cuneo
Questo è il pensiero dei diciassette sviluppatori “anarchici”.
Stiamo scoprendo modi migliori di creare software, sviluppandolo e aiutando
gli altri a fare lo stesso.
Grazie a questa attività siamo arrivati a considerare importanti:
• Gli individui e le interazioni più che i processi e gli strumenti
• Il software funzionante più che la documentazione esaustiva
• La collaborazione col cliente più che la negoziazione dei contratti
• Rispondere al cambiamento più che seguire un piano

4. COSA VUOL DIRE ESSERE AGILI
Mirko Cuneo
• REAZIONE: efficace (rapida e adattiva) ai cambiamenti
• COMUNICAZIONE: efficace per tutti gli stakeholder
• IL CLIENTE ALL’INTERNO DEL TEAM di sviluppo
Prodotto …
• CONSEGNE INCREMENTALI
Ogni progetto è considerate come se fosse un piccolo
progetto a sé stante
• PRIORITA’ DI PROGETTO: alla fine di ogni progetto
va rivalutata

5. RADICAL MANAGEMENT
Mirko Cuneo
The Leader’s Guide to Radical Management di Stephen Denning
Consiglio questo libro per chi si vuole avvicinare al mondo Agile e per chi ha già
familiarità con l’AGILE MANIFESTO, con SCRUM e KANBAN.
L’autore di questo libro vi guiderà nella comprensione dei valori e dei principi che sono
alla base della filosfia Agile
Il libro possiamo riassumerlo in 7 punti fondamentali

6. L’obiettivo del lavoro è la soddisfazione del cliente
Mirko Cuneo
#1
Il primo punto da cui partire per rivoluzionare e migliorare il modo con cui fare
management è passare da una gestione focalizzata sulla produzione di beni o
servizi, a una in cui il focus di tutta l’organizzazione — non solo il marketing
— è rivolto nel soddisfare il cliente finale e le sue necessità di business.

7. Fondare il lavoro su team autoorganizzati
Mirko Cuneo
#2
Un gruppo di persone autoorganizzate, in cui ognuno partecipa alla buona riuscita
del progetto, consente di ottenere risultati migliori, in termini di qualità finale, di
soluzioni trovate, di reattività agli imprevisti.
In contesti complessi — come quelli in cui ci muoviamo ormai tutti i giorni nel
mondo della produzione del software e non solo — spesso un team autonomo e
autoorganizzato riesce a muoversi con maggior efficacia ed efficienza di uno
organizzato secondo un modello gerarchico tradizionale, in cui c’è un capo/PM
che comanda e controlla e in cui ogni decisione deve passare attraverso un
articolato organigramma.

8. Organizzare il lavoro secondo un approccio iterativo e incrementale
Mirko Cuneo
#3
Ad ogni rilascio il prodotto prende forma permettendo al team di raffinare la
definizione del prodotto, tramite il feedback raccolto dal cliente che vede nascere
il prodotto.
In questo modo il team si focalizza nel massimizzare l’interazione con il
cliente/utente, in modo da apportare correzioni in corso d’opera prima che sia
troppo tardi o troppo costoso.
Il feedback raccolto, oltre a permettere di migliorare quando già rilasciato,
consente di aumentare le informazioni che saranno utili per realizzare le parti
successive del prodotto

9. Ogni iterazione deve rilasciare valore al cliente
Mirko Cuneo
#4
Lavorare secondo un approccio iterativo e incrementale è realmente utile solo se
ad ogni iterazione il team si impegna a rilasciare qualcosa di valore per l’utente
finale. Solo in questo modo si riesce a creare un prodotto in modo incrementale e
a ottenere feedback utile.

10. Il management deve incentivare la trasparenza
Mirko Cuneo
#5
I punti precedenti — l’autoorganizzazione e il rilascio di valore in modo iterativo
— si rendono possibili solo se il management crea le condizioni affinché ciò possa
accadere in modo spontaneo. Fra queste condizioni, Denning suggerisce che il
management incentivi la trasparenza in ogni forma: trasparenza fra le persone del
team, trasparenza del team nei confronti del management, trasparenza del
management nei confronti del team.
Muoversi all’interno di un clima di massima trasparenza permette di migliorare la
collaborazione da parte di tutti, di favorire un approccio propositivo e non
assertivo, di stimolare la contribuzione nel lavoro e di abilitare la creazione
collaborativa. Tutto questo perché, nel Radical Management così come in Agile, si
opera nella convinzione che il risultato del lavoro di un gruppo sia maggiore e
migliore della somma delle attività slegate svolte dai singoli.

11. Il management deve incentivare il miglioramento continuo
Mirko Cuneo
#6
Talvolta il management pone — e si pone — degli obiettivi stringenti definiti sulla
base di metriche differenti: numero di funzionalità implementate o, peggio
ancora, numero di punti realizzati se il team usa i punti per misurare la propria
velocità [5], o livelli minimi di qualità, o tolleranza nel rispetto delle scadenze.
Spesso ci si rende conto che il rispetto di tali obiettivi non è realistico, sia per le
metriche scelte che per i valori che ci si è prefissati, e questo porta il management
a “stressare il sistema al suo massimo” per ottenere almeno una parte di quanto
prefissato.
Purtroppo, nella maggior parte dei casi, questo clima di maggior stress porta a un
evidente abbassamento della produttività: il rispetto degli obiettivi iniziali finisce
per tramutarsi in onorevole “filosofia del buono abbastanza” o del “più di così non
potevamo”. Nella pratica, un tale approccio comporta la creazione di un prodotto
che contenga un numero “tollerabile” di difetti, in maniera da soddisfare in modo
accettabile le aspettative del cliente.

12. Usare la comunicazione interattiva
Mirko Cuneo
#7
Per abilitare trasparenza (punto 5), favorire il miglioramento continuo (punto 6) e
quindi rilasciare costantemente valore al cliente (punto 4), gli attori coinvolti nella
realizzazione di un prodotto devono svolgere diverse attività. E una delle cose più
importanti che devono fare è parlarsi in modo efficace, diretto, autentico.
Si dovrebbero quindi rimuovere tutte quelle barriere che limitino il fluire delle
informazioni. Denning propone il termine di comunicazione interattiva basata
sull’ascolto attivo, sullo scambio bidirezionale di informazioni e commenti, in cui
la sincerità — una franchezza senza ipocrisie, ma rispettosa e gentile — sia
sempre alla base di ogni scambio. Nella raccolta dei requisiti, per esempio, sono
da evitare forme gergali o descrizioni del lavoro tecnicistiche, a cui si dovrebbero
preferire forme narrative — raccontare storie, storytelling — che meglio
esprimono le necessità dell’utente finale.

13. AGILE
Mirko Cuneo
Perché un’azienda deve adottare una
metodologia AGILE per gestire i suoi
processi produttivi?

14. APPROCIO TIPICO
Mirko Cuneo

15. NON siamo degli INDOVINI
Mirko Cuneo
Utilizzo delle Funzionalità

16. La Sorte dei Progetti Software
Mirko Cuneo
Come vengono Conclusi i progetti?
44% Manca Qualcosa
24% Fallisce
32% Successo
2009 Standish Chaos Report

17. Il Progetto Tipico
Mirko Cuneo

18. Il Progetto Tipico
Mirko Cuneo

19. Il Progetto Tipico
Mirko Cuneo

20. Il Progetto Tipico
Mirko Cuneo

21. Come Migliorare?
Mirko Cuneo

22. Come Migliorare?
Mirko Cuneo

23. Diagrammi dei casi d’uso
Mirko Cuneo

24. Diagramma di sequenza
Mirko Cuneo

25. Perché dottare l’AGILE
Mirko Cuneo
L'adozione di metodologie agili offre una
serie di vantaggi, che possiamo
suddividere in tre tipologie:
• vantaggi per il committente
• vantaggi per il team di progetto
• vantaggi per l'organizzazione

26. Vantaggi per il cliente
Mirko Cuneo
• Il cliente è coinvolto più attivamente, ottiene un controllo
maggiore sulle priorità.
• Viene a sapere in modo regolare e frequentemente lo stato
dell'applicazione.
• I requisiti sono accettati dopo ogni iterazione.
• Poiche' la metodologia sottolinea consegne rapide, si ha un
minor time-to-market. In questo modo le funzionalità chiave
del sistema possono essere disponibili all'uso prima.
• La consegna è definita da un calendario fissato. Così il cliente è
certo di ricevere alcune funzionalità a un determinato periodo
di tempo fisso e regolare.
• Grazie all'enfasi sui test (sia automatici che manuali), la qualità
del software fornito è decisamente migliore.

27. Vantaggi per i gruppi di progetto
Mirko Cuneo
• I team di progetto sono coinvolti più attivamente in tutte le fasi, e devono
effettuare le domande giuste. Le squadre prendono le decisioni in maniera
collaborativa e sono più responsabilizzati.
• Dal momento che lo sviluppo è incrementale, i team possono concentrarsi sulle
esigenze specifiche in un qualsiasi momento.
• Viene posta una maggiore enfasi sullo sviluppo dell'applicazione, che non sulla
documentazione.
• Vengono utilizzati documenti semplici e minimali allo scopo di scambiare le
opinioni. Si dà particolare importanza alla comunicazione diretta.
• Dato che i team ricevono feedback frequenti grazie a test integrati e
automatici, la rilavorazione è ridotta al minimo.
• Viene speso molto meno tempo nella raccolta di requisiti, in quanto non
vengono più raccolti tutti i requisiti in anticipo, ma sono analizzati e
implementati man mano che si presentano.
• Questo comporta anche un tempo minore per le attività di pianificazione. Che
inoltre diventa molto meno incerta in quanto utilizza il concetto del just in time
(JIT)
• Minori costi di sviluppo complessivo in quanto vengono drasticamente ridotti i
costi relativi a rielaborazione, gestione, documentazione e ogni altra attività
non direttamente di-sviluppo.
• I team sviluppano le applicazioni in modo collaborativo, in ambiente altamente
cooperativo.

28. Confronto tra metodologia Agile e tradizionale
Mirko Cuneo

29. Sfide coinvolte nello sviluppo agile del software
Mirko Cuneo
• Le metodologie agili richiedono essenzialmente un diverso approccio
mentale oltre che l'acquisizione di nuove competenze e quindi
lanciano una sfida al nostro approccio convenzionale.
• - Difficolà
• - Disciplina
• - Pianificazione
• - Supporto
• culturale: l'organizzazione deve essere aperta al cambiamento;
• gerarchico: il management deve essere pronto ad autorizzare i
team;
• burocratico: viene richiesta una minore focalizzazione su processi
e passi operativi.

30. Quali Metodologie Agile
Mirko Cuneo
Analizzeremo queste 3
Metodologie confrontandole:
• KanBan
• SCRUMBAN
• Scrum

31. Kanban
Mirko Cuneo
KanBan – HOW TO
« MIGLIORARE LA
COMUNICAZIONE TRAMITE UNA
GESTIONE VISUALE DEL
PROCESSO»

32. Kanban
Mirko Cuneo
La parola kanban infatti deriva dalla
composizione delle parole Kan (che
significa “visuale”) e Ban (che significa
“segnale”) e difatti la metodologia faceva
uso di cartellini visuali e di lavagne dove
questi cartellini erano attaccati per
monitorare gli stati di avanzamento della
produzione, l’approvvigionamento,
l’acquisto o la movimentazione dei
materiali.

33. Kanban - Aspetti
Mirko Cuneo
• Visualizzare il flusso di lavoro: rappresentare visivamente il processo di
lavorazione, ponendo in risalto, per ogni fase del processo complessivo, il
valore prodotto.
• Limitare il Work-in-Progress: porre dei limiti espliciti sul lavoro complessivo
eseguibile all’interno di ogni fase della lavorazione.
• Misurare e gestire il flusso: misurare e gestire il flusso per avere sempre
informazioni attendibili e poter quindi prendere decisioni coerenti col sistema.
Per ogni azione intrapresa, visualizzare sempre conseguenze.
• Rendere esplicite le politiche di processo: definire e condividere con tutti gli
interessati le regole a cui processo e stakeholder devono attenersi è il modo
più semplice ed efficace per garantire il miglioramento delle prestazioni, la
riduzione degli sprechi, l’ottenimento degli obiettivi.
• Identificare le possibili opportunità di miglioramento: creare
nell’organizzazione una cultura (kaizen), in cui il continuo miglioramento del
sistema, del processo e delle performance siano obbiettivi condivisi in tutti i
membri della comunità.

34. Kanban – 3 Regole Fondamentali
Mirko Cuneo
Usare gli strumenti già in possesso: partire da quello che si sa fare senza
aspettare di imparare.
Condividere un percorso di cambiamento che abbia come obiettivo la
crescita e l’evoluzione dell’organizzazione.
Rispettare l’organizzazione attuale: il processo di cambiamento ed
evoluzione non deve imporre stravolgimenti nel processo, modifiche nei
ruoli e nelle persone, ma introdurre le novità in modo graduale e
compatibile con le necessità e gli obiettivi. Per questo la visualizzazione
del processo, la misurazione, la definizione esplicita delle policy sono
così importanti.

35. Kanban – la lavagna e il suo scopo
Mirko Cuneo
Limitare il numero di attività per fase di lavorazione
permette di stabilizzare il flusso della lavorazione,
impedendo che, per esempio, il lavoro si accumuli in
alcuni punti del ciclo di lavorazione (“colli di bottiglia”)
o che altre parti siano completamente scariche (le
“secche” a valle del restringimento): Il sovraccarico e lo
sbilanciamento del flusso sono due fenomeni che
abbassano in modo evidente le performance del
sistema, tanto che nella teoria della produzione snella
(Lean Production) insieme allo spreco diretto, sono
indicati come le tre principali motivi di degrado di un
sistema di produzione;

36. Filosofia Lean: Le 3 M
Mirko Cuneo
• Mura (“sbilanciamento”)
• Muri (“sovraccarico”)
• Muda (“spreco”)
La scelta dei valori da assegnare alle
varie colonne non è affatto casuale nè
semplice.

37. Kanban
Mirko Cuneo
Per prima cosa si dispone in modo libero su una parete l’elenco delle attività
che si dovranno svolgere

38. Kanban
Mirko Cuneo
Il primo miglioramento che si può introdurre è una suddivisione in colonne per
raggruppare le attività da svolgere, quelle in lavorazione e quelle che invece
sono già terminate.

39. Kanban
Mirko Cuneo
La colonna della lavorazione può essere scomposta nella corrispondenti
attività di dettaglio. In un processo di sviluppo software, potrebbero essere le
classiche analisi, sviliuppo, test e deploy.

40. Kanban
Mirko Cuneo
Il passo successivo potrebbe essere quello di introdurre le colonne di
parcheggio, in modo da gestire il passaggio da un approccio push a uno pull.

41. Kanban
Mirko Cuneo
Come ultimo raffinamento si possono introdurre i limiti WIP (Work In Progress)
sul numero massimo di elementi in lavorazione contemporanea.

42. Kanban
Mirko Cuneo
Le attività svolte in contemporanea (Work In Progress, WIP) non devono essere
troppe. Se non si impone alcun limite di lavorazione (WIP limit), vi è una
elevata probabilità che si verifichino degli ingorghi prima delle fasi lente
(colli di bottiglia).

43. Kanban
Mirko Cuneo
I limiti di lavorazione favoriscono l’approccio pull, evitando l’insorgere di colli
di bottiglia delle attività.

44. Kanban
Mirko Cuneo

45. Il Flusso
Mirko Cuneo

46. Fluso senza WIP
Mirko Cuneo

47. Perché usare il WIP
Mirko Cuneo
Si nota come il vincolo imposto sulle colonne permetta
di impedire l’accumulo, e anzi renda più omogenea la
lavorazione delle attività: in questo caso infatti, non
appena si raggiunge il limite per una qualsiasi
colonna, il sistema tende a saturarsi impedendo
ulteriori inserimenti in lavorazione. In casi come
questo infatti, se i WIP Limits sono stati assegnati con
criterio, solo agendo in modalità pull (si tirano verso
destra le attività da svolgere) si può prevenire il blocco
totale del sistema

48. Gestione delle emergenze
Mirko Cuneo
L’ordine con cui le varie attività sono messe in
lavorazione segue l’ordinamento che viene dato ai
cartellini nella colonna iniziale del ToDo, la quale viene
ordinata in base a una qualche priorità: valore
rilasciato al cliente, come in Scrum, urgenza o tempo
di arrivo come spesso avviene in Kanban.
Per non perturbare il team con qualcosa che esula
dall’applicazione del processo Kanban, la presa in
carico e la soluzione di questi problemi potrebbe
essere inserita nella Kanban board come normali
attività alle quali si assegna una priorità maggiore: si
tratta infatti di emergenze che devono essere evase
prima possibile.

49. Kanban – Avatar
Mirko Cuneo
Gli avatar sono molto utili per rappresentare in modo rapido e visuale chi
sta facendo cosa. In questo caso una parte della board è utilizzata come
deposito di tutte le icone delle persone del team (parcheggio degli
avatar).

50. Kanban – Avatar
Mirko Cuneo
Yury, completato il suo lavoro, si rende libero per fare altro.

51. Kanban – Avatar
Mirko Cuneo
Yury, dopo aver terminato il suo task, non ne inizia uno nuovo, ma si
mette in coppia con Francesco per aiutarlo a completare prima il suo
lavoro.

52. Kanban – Avatar
Mirko Cuneo
In alterntativa Yury invece potrebbe mettersi a lavorare un nuovo task.

53. Kanban – Avatar
Mirko Cuneo
Se Yury è in grado di eseguire il test o il deploy, potrebbe mettersi a dare
una mano ad Andrea per “scodare” le attività nella parte destra della
board.

54. Emergenze
Mirko Cuneo

55. Kanban – Avatar
Mirko Cuneo
L’emergenza è presa in lavorazione. Due persone interrompono il loro
lavoro “normale” e si dedicano a tempo pieno ad analizzare il problema. I
rispettivi cartellini rimasti liberi sono lasciati nella loro posizione anche
se di fatto occupano WIP senza che nessuno vi stia lavorando.

56. Kanban – Avatar
Mirko Cuneo
Caso simile al precedente ma con una sua specifica diversità è quello del
difetto di lavorazione: il bug è trovato prima che la funzionalità sia
messa in produzione. Una prima soluzione consiste semplicemente nel
“retrocedere” il cartellino nella colonna di lavorazione necessaria per
risolvere il problema.

57. Kanban – Avatar
Mirko Cuneo
I passi successivi sono analoghi al caso precedente. Il cartellino giallo
urgente viene messo in lavorazione con priorità nella corsia delle
emergenze.

58. Mappatura
Mirko Cuneo
Mappare il processo su una kanban board

59. mappare il workflow – PASSO 1
Mirko Cuneo
Mappare un processo di produzione tramite una kanban board è una
attività che può essere svolta iterativamente in modo incrementale,
aggiungendo ad ogni passaggio un dettaglio o una nuova parte.
Il suggerimento è di iniziare dall’individuazione del flusso del processo,
o workflow; il flusso può essere definito anche in maniera grossolana,
ma c’è un aspetto a cui va prestata la massima attenzione: cosa sta
dentro e cosa sta fuori del processo, in modo di individuare
approssimativamente il contorno del sistema che si vuole modellare.
In questa fase ci si può avvalere di strumenti grafici piuttosto semplici
come un diagramma di flusso o un diagramma di stato UML

60. mappare il workflow
Mirko Cuneo
Si definisce un primo modello sintetico del processo.

61. mappare il workflow
Mirko Cuneo
Dal workflow alla board.

62. mappare il workflow
Mirko Cuneo
Cambia il livello di dettaglio del workflow, cambia la forma della board.

63. mappare il workflow
Mirko Cuneo
Si inseriscono le colonne buffer.

64. Passi Successivi
Mirko Cuneo
Passo numero 2: introduzione delle aree di buffer
Dopo aver disegnato le colonne, il passo successivo potrebbe essere
quello di introdurre le aree di parcheggio o colonne buffer.

65. Passi Successivi
Mirko Cuneo
Passo numero 3: limitare la lavorazione in parallelo tramite il WIP limit
Dopo aver introdotto le colonne buffer, il passo successivo potrebbe
essere dato dall’aggiunta, in testa alle colonne, dei WIP limit, in modo da
vincolare il numero di attività che potranno essere svolte in parallelo
all’interno di ogni fase.
Anche in questo caso non esistono regole o formule magiche per la
scelta del limite del WIP: si consiglia quindi di seguire un approccio
sperimentale per tentativi.
Il valore ottimale in genere si trova dopo alcune prove valutando, per
ogni variazione, gli impatti sulle performance complessive sul sistema:
per esempio si potrebbe individuare come metrica di riferimento il lead
time medio necessario per completare la lavorazione delle attività prese
in esame, prendendo il valore medio per avere una valutazione che tenga
conto delle differenti tipologie di attività.

66. Passi Successivi
Mirko Cuneo
Passo numero 4: definizione delle card
Oltre alla progettazione e al raffinamento della board, si può lavorare per
aggiungere dettagli e informazioni ai cartellini corrispondenti ai task in
lavorazione. cartellino dovrebbe contenere tutte le informazioni
significative relative all’attività da svolgere: dovrebbe essere presente un
titolo che esprima in modo chiaro scopo e tipologia della attività,
dovrebbe essere riportare l’owner o comunque il responsabile, la data di
nascita (quando il cartellino è stato inserito nella lavorazione) e una data
di consegna richiesta (oltre la quale il non completamento rappresenta
un problema). Utile anche, qualcosa che ne specifichi la “classe” ossia
l’importanza, urgenza o semplicemente il valore.

67. Passi Successivi
Mirko Cuneo
Passo numero 5: definizione delle classi di servizio
Una board realizzata seguendo i passi descritti fino a questo punto,
potrebbe essere uno strumento già molto utile per esempio per
controllare lo stato di avanzamento delle attività di un team di sviluppo.
Un ulteriore e importantissimo passaggio è quello di introdurre la
possibilità di gestire le diverse tipologie di attività.
Nella realtà, infatti, alcune sono molto urgenti tanto che ogni minuto
speso per la soluzione costa all’azienda molti soldi: si pensi a un bug
bloccante in produzione.
Altre invece possono attendere per essere messe in lavorazione quando
non ci sono urgenze da completare.
Infine ci sono attività a bassa priorità che possono essere lavorate solo
quando non ce ne sono altre in coda.
La classificazione delle attività potrebbe essere fatta anche in funzione di
altri parametri, per esempio considerando la persona che può svolgere
quel lavoro.
In Kanban si parla di classi di servizio, per indicare la differente modalità
di presa in carico in funzione dell’urgenza o dell’importanza.

68. Passi Successivi
Mirko Cuneo
Per inserire la gestione delle classi di servizio all’interno di una kanban
board, la prima cosa da fare è identificare le varie tipologie di attività:
per esempio in un progetto software si potrebbero considerare le
seguenti:
• implementazione di nuove funzionalità;
• bug fixing a bassa priorità;
• bug fixing ad alta priorità;
• documentazione;
• attività di formazione a supporto degli utenti;
• setup ambienti e installazione software di supporto;
• studio per realizzazione di prototipi.
Per ognuna di queste categorie si prova a definire le priorità, per
esempio valutando il Cost of Delay, eventuali SLA (Service Level
Agreement) contrattualizzati o altro ancora.

69. Passi Successivi
Mirko Cuneo
Passo numero 6: migliorare la board tramite le metriche
L’inserimento delle colonne buffer, la definizione dei WIP limit, così come
la definizione delle varie colonne della board, sono decisioni che
dovrebbero essere sempre soggette a valutazioni e riconsiderazioni sulla
base dell’osservazione diretta del sistema e dell’efficacia della board
stessa.
Spesso la configurazione migliore si verifica grazie alla naturale capacità
che ha una board di fornire una rappresentazione visuale del sistema.
Altre volte invece si rendono necessari approfondimenti basati su
sperimentazioni e analisi retrospettive, successi e fallimenti. Non esiste
una soluzione buona a prescindere, ma si deve trovare di volta in volta la
configurazione migliore. Misurare quindi la risposta del sistema è un
modo oggettivo per valutare l’efficacia delle varie prove.
Oltre alle metriche di cui si è già parlato, lead time e il cycle time, molto
utilizzate anche il Cumulative Flow Diagrams (CFD), il Defect Rate e il
Blocked Items. La scelta della metrica da usare è spesso funzione del tipo

70. Definizione delle card
Mirko Cuneo
Parallelamente alla progettazione e al raffinamento
della board, si può lavorare per la definizione dei
cartellini corrispondenti ai task in lavorazione. Ogni
card dovrebbe contenere tutte le informazioni
significative relative all’attività da svolgere: dovrebbe
essere presente un titolo che esprima in modo chiaro
scopo e tipologia della attività, dovrebbe essere
presenta l’owner o comunque il responsabile, una data
di scadenza e ovviamente qualcosa che ne identifichi il
valore, per esempio un qualche punteggio che ne
esprima la priorità.

71. SCRUM
Mirko Cuneo
SCRUM – Come Funziona

72. SCRUM – Cos’è
Mirko Cuneo
Scrum è una metodologia agile di sviluppo del
software. Come tutte le metodologie agili è incentrata
sulla riduzione del numero di ruoli e del numero di
artefatti da produrre. Ha ovviamente anche delle sue
peculiarità e, rispetto ad altre metodologie, si
differenzia in quanto si delinea come un "framework".
In tal modo, Scrum non è un metodo rigido, ma
piuttosto rappresenta una base su cui costruire un
processo di sviluppo, che sarà di volta in volta adattato
alla realtà in cui viene calato. Non a caso, il motto di
Scrum è "l'arte del possibile".

73. User Story
Mirko Cuneo
Gli elementi che caratterizzano Scrum sono molti, ma alcuni sicuramente hanno
un peso maggiore rispetto ad altri. In particolare viene introdotto un concetto
"nuovo": la User Story. È abbastanza normale cercare di fare paragoni con altri
ambiti: in metodologie diverse ci si potrebbe riferire alla User Story con termini
quali "requisito utente" o "funzionalità" o "specifica". Sono tutte parole abbastanza
adeguate ma non catturano pienamente lo "spirito" che Scrum assegna a una User
Story.
Descrivere una storia utente è molto complicato e spesso la sua identificazione
può essere difficile. Un buon punto di partenza per capire di cosa stiamo parlando
è il modello INVEST [WP4]. Esso è un acronimo che viene sciolto come segue:
• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

74. User Story
Mirko Cuneo
Gli elementi che caratterizzano Scrum sono molti, ma alcuni sicuramente hanno
un peso maggiore rispetto ad altri. In particolare viene introdotto un concetto
"nuovo": la User Story. È abbastanza normale cercare di fare paragoni con altri
ambiti: in metodologie diverse ci si potrebbe riferire alla User Story con termini
quali "requisito utente" o "funzionalità" o "specifica". Sono tutte parole abbastanza
adeguate ma non catturano pienamente lo "spirito" che Scrum assegna a una User
Story.
Descrivere una storia utente è molto complicato e spesso la sua identificazione
può essere difficile. Un buon punto di partenza per capire di cosa stiamo parlando
è il modello INVEST [WP4]. Esso è un acronimo che viene sciolto come segue:
• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

75. Gestione delle emergenze
Mirko Cuneo
Vediamo di tradurre tali aggettivi in pratica. Secondo tale impostazione INVEST,
una User Story quindi dovrà soddisfare una serie di condizioni.
Non deve dipendere da nessuna altra storia (Independent). Deve essere possibile
chiarirla in tutti i suoi aspetti (Negotiable) attraverso il dibattito fino a quando tutti
gli attori coinvolti non concordano sul suo contenuto. Esiste solo se anche l'utente
finale trae vantaggio (Valuable) dalla sua realizzazione e deve essere possibile
effettuarne una stima (Estimable). Essa deve inoltre essere piccola (Small) e
oggettivamente verificabile (Testable).
Inoltre, durante la fase di "negoziazione", si devono identificare tutti gli ostacoli
che possono impedire o rallentare la realizzazione di una storia. In questo modo è
più facile mettere in evidenza i rischi e attivarsi per tempo per rimuovere ogni
impedimento.
A questo punto, quando una storia viene identificata, deve essere anche registrata
e catalogata. Scrum prevede un artefatto specifico per questo compito chiamato
Product Backlog. Al momento del suo inserimento, ad ogni storia viene associata
una "importanza" o una priorità in modo tale da poter decidere quali realizzare
prima e quali dopo.

76. Il Tempo
Mirko Cuneo
In Scrum ogni attività è time boxed, cioè ha
una durata certa! Assegnare dei limiti di tempo
(molto stretti) per ogni attività aiuta a
concentrarsi solo sulle cose strettamente
necessarie. La consegna delle storie avviene
quindi con una frequenza molto alta: in tal
modo, si possono ricevere dei feedback molto
velocemente ed eventualmente correggere
subito le cose che non vanno bene, senza
traumi tardivi.

77. I Ruoli
Mirko Cuneo
In Scrum, le persone che partecipano al progetto vengono
inquadrate in ruoli a cui corrispondono delle responsabilità. In
pratica esistono 2 macro categorie: pig e chicken. Scrum ha un
linguaggio molto colorito e questa divisione fra "maiali" e "polli"
deriva da una barzelletta in cui un pollo propone a un maiale di
aprire insieme un ristorante, da chiamare "uova e prosciutto".
Chiaramente, in un accordo del genere, la categoria più coinvolta
è proprio quella del "maiale"...
Pertanto, della macrocategoria pig fanno parte i ruoli di Product
Owner (PO), di Scrum Master (SM), e il Team, cioè coloro che a
vario titolo identificano e realizzano le User Story.
Della seconda, categoria, quella dei chicken, fanno parte gli Stake
Holder, i manager e qualsiasi altra persona che si può ritenere un
"osservatore interessato" del progetto a qualsiasi titolo, ma che
non si occupa in alcun modo di realizzare le storie utente.

78. Team
Mirko Cuneo
Il Team è l'insieme delle persone più direttamente
coinvolte nella fase di sviluppo e deve esprimere tutte
le competenze, funzionali e tecniche, utili alla
consegna del lavoro. Esso si autogestisce e quindi tutti
i componenti del Team hanno stessa "dignità" e
responsabilità. Il Team è l'unico ruolo che può
effettivamente dire quanto costa realizzare una storia.

79. Product Owner
Mirko Cuneo
Il Product Owner (PO) è una singola persona e
rappresenta gli interessi degli utenti. Il suo compito è
quindi quello di analizzare le richieste degli Stake
Holder per poterle poi "tradurre" al Team e allo Scrum
Master. Il PO è l'unico che può assegnare importanza e
priorità alle User Story.

80. Scrum Master
Mirko Cuneo
Lo Scrum Master (SM) è una persona al servizio del
Team e del PO. Il suo compito è quello di sorvegliare
che il processo venga "implementato" nel modo
corretto. Lo SM deve rimuovere tutti gli ostacoli che gli
vengono segnalati e deve aiutare il PO a massimizzare
il ROI.

81. Sprint Planning e Sprint Backlog
Mirko Cuneo
Le "pulsazioni" (o per meglio dire le iterazioni) di un processo basato su
Scrum sono chiamate Sprint. Uno Sprint è pertanto un periodo di
sviluppo, che ha le seguenti caratteristiche:
• ha un obiettivo dichiarato (goal) espresso in modo chiaro e non
tecnico;
• ha una durata prefissata (generalmente di 3 o 4 settimane) e quindi
una data di consegna (demo) ben identificata;
• deve portare alla realizzazione completa di una lista di storie presenti
nel Product Backlog.
• Tutte queste informazioni sono raccolte in un altro artefatto previsto
da Scrum chiamato Sprint Backlog creato alla fine dello Sprint
Planning, che è una riunione a cui partecipano PO, SM e tutto il Team e
che non dovrebbe durare più di un giorno di lavoro.

82. Sprint (Execution)
Mirko Cuneo
Dopo la pianificazione (che vi assicuro sarà l'attività più difficile) è giunto
il momento di lavorare sul serio. Questo è il periodo dello sprint vero e
proprio, in cui tutto il Team è concentrato nella realizzazione delle storie
e si fa aiutare dallo SM nell'eliminazione degli ostacoli individuati. Lo
Scrum Master ha anche il compito di evitare che altri interferiscano in
modo inopportuno con il Team perche' questo riduce la capacità di
concentrazione e quindi anche la velocità di lavoro.
Può sembrare che questo periodo sia tutto sommato facile da "gestire",
ma nella realtà questo è il periodo in cui si concentrano i maggiori rischi,
perche' alla fine del planning è stata fatta una promessa (formalizzata
nello Sprint Backlog) e ora si deve mantenerla!

83. Daily Scrum
Mirko Cuneo
In ogni caso la giornata di lavoro ha un proprio "rito"
per cominciare le attività, chiamato Daily Scrum che si
può concludere in soli 15 minuti. In pratica è una
brevissima riunione, in cui ogni persona deve
rispondere alle seguenti domande:
• cosa ho fatto ieri?
• cosa farò oggi?
• quali sono gli ostacoli che ho rilevato?
Questa mini riunione a cui partecipano SM e Team si
dovrebbe svolgere al mattino, più o meno sempre alla
stessa ora, prima di iniziare le attività della giornata.

84. Sprint Retrospective
Mirko Cuneo
Dopo la demo, lo SM incontra il Team per illustrare a
tutti il risultato della demo e per ragionare insieme su
quali sono i problemi che maggiormente ostacolano il
lavoro. Questa riunione non dovrebbe andare oltre le 4
ore di lavoro; però spesso è necessario formalizzare in
qualche modo (documentare) il contenuto della
riunione: e quindi arrivare fino a un massimo di 8 ore
è a mio parere assolutamente accettabile.
In particolare è possibile che si debbano aggiornare le
linee guida del progetto in termini di standard di
design e architettura oppure aggiornare un documento
di FAQ in cui vengono raccolte domande, "tips &
tricks", e così via, che aiutano a condividere in modo
più veloce ed efficace le soluzioni adottate.

85. Sprint Monitoring
Mirko Cuneo
Come tutti i progetti, anche quelli realizzati con Scrum
devono essere monitorati per capire cosa sta
succedendo; come in tutti i processi agili, è necessario
che siano resi effettivi i concetti di chiarezza e
trasparenza nei confronti di tutti, in particolare degli
Stake Holder.
Questa operazione è sempre molto complicata ed è
difficile formalizzarla in modo assoluto e quindi sarà
soggetta a forte personalizzazione in quanto è molto
utile al Team ma spesso è necessaria anche per coloro
che valutano il progetto: persone che generalmente
ignorano Scrum e i suoi principi.

86. Daily Scrum
Mirko Cuneo
In ogni caso la giornata di lavoro ha un proprio "rito"
per cominciare le attività, chiamato Daily Scrum che si
può concludere in soli 15 minuti. In pratica è una
brevissima riunione, in cui ogni persona deve
rispondere alle seguenti domande:
• cosa ho fatto ieri?
• cosa farò oggi?
• quali sono gli ostacoli che ho rilevato?
Questa mini riunione a cui partecipano SM e Team si
dovrebbe svolgere al mattino, più o meno sempre alla
stessa ora, prima di iniziare le attività della giornata.

87. Daily Scrum
Mirko Cuneo
Quello che è veramente importante sono le informazioni
che vengono scambiate all’interno del team e il
raggiungimento degli obiettivi che questa pratica si
prefigge
• Identificare/sottolineare gli obiettivi del team
• Identificare/sottolineare gli ostacoli in modo che altri
componenti del team possano rimuoverli
• Identificare/sottolineare lo stato attuale, i progressi
fatti e i piani futuri
• Migliorare la comunicazione all’interno del team
• Migliorare la collaborazione all’interno del team

88. Daily Scrum
Mirko Cuneo
quali sono gli elementi che identificano un buon
Stand-Up Meeting?
• Rapido: massimo 10/15 minuti
• Focalizzato: niente persone che si guardano in giro
please! E’ mancanza di rispetto verso chi sta
parlando
• Energico: deve essere un momento attivo, un
momento in cui tutto il team è chiamato a
partecipare
• Di supporto: le persone devono sentirsi ascoltate,
un buon modo per creare questa sensazione è di
occuparsi dei problemi che vengono sollevati
durante il meeting.
• Auto organizzato: non ci deve essere un “centro”, la

89. Velocity
Mirko Cuneo
La velocity di un Team è l'effort esprimibile durante uno sprint!
Teoricamente è quindi molto facile calcolare tale informazione:
Vt = nT * nD
Dove nT è il numero di sviluppatori e nD è il numero di giorni di
esecuzione dello sprint. Quindi per esempio se c'è un Team di 5
persone (nT = 5) e uno sprint di 3 settimane (nD = 15) allora la
velocità sarà di V = 5 * 15 = 75 giorni di lavoro per sprint. Ma
occorre fare attenzione! Questa velocità è solo teorica e va
verificata prima di ogni sprint per svariate ragioni. Anzitutto, il
numero di giorni lavorativi reali potrebbe essere più basso del
previsto, a causa di ferie e festività; e sono poi possibili sia
imprevisti personali di ogni partecipante che sforamenti delle
stime. Inoltre, cè un ulteriore aspetto da tenere in considerazione
ed è che lo Scrum Master non dovrebbe essere conteggiato nel
nT per definire la velocity, in quanto il suo lavoro è oggetto di
forti interazioni con l'esterno e quindi non può effettivamente
concentrarsi solo su una serie di attività isolate.

90. Burndown Chart
Mirko Cuneo
Un burndown chart è un diagramma cartesiano per
monitorare l'andamento di uno sprint: sull'asse X sono
indicati i giorni dello sprint, mentre sull'asse Y sono
indicati i giorni di effort.

91. Task Board
Mirko Cuneo
Un altro strumento utile per monitorare l'andamento
del progetto è la Task Board. Essa è semplicemente
una lavagnetta in cui si appiccica un post-it per ogni
task diviso per storia e stato.

92. Differences and Similarities: Scrum vs Kanban
Mirko Cuneo

93. Differences and Similarities: Scrum vs Kanban
Mirko Cuneo
• Scrum requires specific roles whereas Kanban has no required
roles.
• Scrum is based on timeboxed iterations, combining planning,
process improvement, and release. In Kanban, you can choose
to do these activities on a regular cadence or whenever you
need.
• Scrum limits work in progress (WIP) in each iteration, whereas
Kanban limits WIP in each workflow.
• Scrum resists change, whereas Kanban easily accommodates
and embraces change. In Scrum, once the team has committed
stories to a sprint, you can’t add additional stories later on. In
Kanban, you can add or change stories as you please,
assuming that it’s within WIP limits.
• A Scrum board is reset after each sprint. A Kanban board is
continuously used.
• A Scrum team is cross-functional and one team owns the
Scrum board. In Kanban, teams don’t need to be cross-
functional and anyone can own the Kanban board.

94. Scrumban
Mirko Cuneo
Noi conosciamo Kanban e Scrum come metodologie di gestione
Agile. Lo Scrumban unisce le migliori caratteristiche di entrambi i
metodi. Combina la natura prescrittiva dello Scrum e la capacità
di miglioramento dei processi del Kanban, consentendo ai team di
avvicinarsi allo sviluppo Agile e di migliorare costantemente i loro
processi.
Lo Scrumban sta diventando particolarmente popolare in settori in
cui lo sviluppo e il mantenimento dei progetti vanno di pari
passo.

95. Scrumban
Mirko Cuneo
Lo Scrumban si è evoluto partendo da uno Scrum a cui sono stati
aggiunti alcuni elementi del Kanban. Questi ultimi sono:
visualizzazione, limite dei lavori in corso, gestione del flusso di
lavoro e policy di non riservatezza.
I principi di implementazione di base dello Scrumban includono:
- Inizio con i riti, i tabelloni e i ruoli che utilizzi ora.
- Accettazione di perseguire miglioramenti verso un processo più
efficace.
- Rispetto dei ruoli e delle responsabilità attuali, puntando ad un
loro miglioramento.

96. Scrumban
Mirko Cuneo
La gestione del flusso di lavoro in Scrumban prevede un'attenta
gerarchizzazione dei compiti, suddivisi soprattutto secondo il
concetto di "risultato economico". Si deve tenere ben in conto
che, il concetto di "economia" qui considerato, include anche la
gestione - il più efficiente possibile - dei tempi di progetto e dei
team assegnati ad ogni compito.
Proprio come in Kanban, anche qui ogni progetto viene
parcellizzato e assegnato a uno specifico gruppo di lavoro. A
differenza di Kanban, però, Scrumban non prevede la possibilità
di cambi di team in corsa: ogni team sarà fisso, e focalizzato su
un unico compito per tutta la durata del progetto.
Le deadline sono genericamente piuttosto brevi: nel prontuario
Scrumban si parla di un limite massimo di 2 settimane
dall'assegnazione per il termine ultimo, cosa che sottolinea la
necessità di una grande frammentazione del progetto.

97. Scrumban
Mirko Cuneo
Ogni team lavorerà in
contemporanea sui diversi
aspetti del progetto,
aggiornando gli altri gruppi in
continuazione sull'andamento
del proprio lavoro: per questo
motivo i singoli compiti
vengono distinti in più
obiettivi, più piccoli e
facilmente gestibili.

98. Scrumban
Mirko Cuneo
La gestione delle tempistiche è piuttosto libera, fermi restando gli
obiettivi intermedi: il manager si assumerà l'incarico di verificare
il giusto procedimento delle varie fasi di lavoro di ogni singolo
team, controllando anche l'applicazione delle metodologie di
lavoro stabilite a inizio progetto.
Naturalmente, il manager dovrà curare anche l'aspetto della
comunicazione tra team, verificando che la tabella visuale
contenente i vari progressi ed obiettivi - secondo la forma "Da
fare, In lavorazione, Terminato" sia costantemente aggiornata.
Questo sistema prevede, inoltre, la possibilità di programmare
obiettivi a lungo o lunghissimo termine secondo "bucket",
obiettivi cristallizzati da mantenere in tabella anche dopo il loro
completo svolgimento, per garantire una visione d'insieme il più
possibile esauriente.

99. Tabelloni Scrumban
Mirko Cuneo
Il tabellone Scrumban ti offre un’eccellente panoramica del flusso di lavoro di un processo. Ti informa sul
numero di elementi su cui un team sta lavorando in un preciso momento, oltre al numero di attività già
completato. Migliora la responsabilità, la trasparenza, la comunicazione e i risultati.

100. Quando prendere in considerazione la Scrumban
Mirko Cuneo
• Maintenance projects
• Event-driven work
• Help desk/support
• Hardening/packaging phases
• Projects with frequent and unexpected user stories or programming
errors
• Sprint teams focused on new product development
• Work preceding sprint development (backlog, R&D)
• Work following sprint development (system testing, packaging,
and deployment)
• If Scrum is challenged by workflow issues, resources and processes
• To manage improvement communities during/after Scrum roll-out

101. Kanban vs Scrumban
Mirko Cuneo

102. Scrum vs Scrumban
Mirko Cuneo
• Maintenance projects
• Event-driven work
• Help desk/support
• Hardening/packaging phases
• Projects with frequent and unexpected user stories or programming
errors
• Sprint teams focused on new product development
• Work preceding sprint development (backlog, R&D)
• Work following sprint development (system testing, packaging,
and deployment)
• If Scrum is challenged by workflow issues, resources and processes
• To manage improvement communities during/after Scrum roll-out

103. Quando prendere in considerazione la Scrumban
Mirko Cuneo

104. Bibliografia
Mirko Cuneo
• Mokabyte.it
• Agile Software Development with Scrum - Ken Schwaber
• Agile Transition di Andrea Tomasini e Martin Kearns
• Agile Samurai
• The Machine That Changed World
• LiftOff" Diana Larsen e Ainsley Nies
• Fabio Armani
• ScrumAlliance AgileAtlas
• Scrum and XP from the trenches
• Essential Scrum

105. CONTATTI
www.nextre.it
mirko.cuneo@nextre.it
contattaci@nextre.it
Social