SlideShare a Scribd company logo
Introduzione alle metodologie Agile
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
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
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
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
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.
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.
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
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.
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.
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.
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.
AGILE
Mirko Cuneo
Perché un’azienda deve adottare una
metodologia AGILE per gestire i suoi
processi produttivi?
APPROCIO TIPICO
Mirko Cuneo
NON siamo degli INDOVINI
Mirko Cuneo
Utilizzo delle Funzionalità
La Sorte dei Progetti Software
Mirko Cuneo
Come vengono Conclusi i progetti?
44% Manca Qualcosa
24% Fallisce
32% Successo
2009 Standish Chaos Report
Il Progetto Tipico
Mirko Cuneo
Il Progetto Tipico
Mirko Cuneo
Il Progetto Tipico
Mirko Cuneo
Il Progetto Tipico
Mirko Cuneo
Come Migliorare?
Mirko Cuneo
Come Migliorare?
Mirko Cuneo
Diagrammi dei casi d’uso
Mirko Cuneo
Diagramma di sequenza
Mirko Cuneo
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
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.
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.
Confronto tra metodologia Agile e tradizionale
Mirko Cuneo
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.
Quali Metodologie Agile
Mirko Cuneo
Analizzeremo queste 3
Metodologie confrontandole:
• KanBan
• SCRUMBAN
• Scrum
Kanban
Mirko Cuneo
KanBan – HOW TO
« MIGLIORARE LA
COMUNICAZIONE TRAMITE UNA
GESTIONE VISUALE DEL
PROCESSO»
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.
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à.
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.
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;
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.
Kanban
Mirko Cuneo
Per prima cosa si dispone in modo libero su una parete l’elenco delle attività
che si dovranno svolgere
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.
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.
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.
Kanban
Mirko Cuneo
Come ultimo raffinamento si possono introdurre i limiti WIP (Work In Progress)
sul numero massimo di elementi in lavorazione contemporanea.
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).
Kanban
Mirko Cuneo
I limiti di lavorazione favoriscono l’approccio pull, evitando l’insorgere di colli
di bottiglia delle attività.
Kanban
Mirko Cuneo
Il Flusso
Mirko Cuneo
Fluso senza WIP
Mirko Cuneo
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
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.
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).
Kanban – Avatar
Mirko Cuneo
Yury, completato il suo lavoro, si rende libero per fare altro.
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.
Kanban – Avatar
Mirko Cuneo
In alterntativa Yury invece potrebbe mettersi a lavorare un nuovo task.
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.
Emergenze
Mirko Cuneo
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.
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.
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.
Mappatura
Mirko Cuneo
Mappare il processo su una kanban board
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
mappare il workflow
Mirko Cuneo
Si definisce un primo modello sintetico del processo.
mappare il workflow
Mirko Cuneo
Dal workflow alla board.
mappare il workflow
Mirko Cuneo
Cambia il livello di dettaglio del workflow, cambia la forma della board.
mappare il workflow
Mirko Cuneo
Si inseriscono le colonne buffer.
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.
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à.
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.
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.
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.
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
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à.
SCRUM
Mirko Cuneo
SCRUM – Come Funziona
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".
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
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
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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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
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
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.
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.
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.
Differences and Similarities: Scrum vs Kanban
Mirko Cuneo
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.
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.
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.
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.
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.
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.
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.
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
Kanban vs Scrumban
Mirko Cuneo
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
Quando prendere in considerazione la Scrumban
Mirko Cuneo
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
CONTATTI
www.nextre.it
mirko.cuneo@nextre.it
contattaci@nextre.it
Social

More Related Content

What's hot

just in time and lean manufacturing
just in time and lean manufacturingjust in time and lean manufacturing
just in time and lean manufacturing
Akhil Bhatia
 
Kanban Basics for Beginners
Kanban Basics for BeginnersKanban Basics for Beginners
Kanban Basics for Beginners
Zsolt Fabok
 
Kanban Explained in 11 Slides
Kanban Explained in 11 SlidesKanban Explained in 11 Slides
Kanban Explained in 11 Slides
Brent Brewington
 
Lean Strategy Deployment - Quick Overview
Lean Strategy Deployment -  Quick OverviewLean Strategy Deployment -  Quick Overview
Lean Strategy Deployment - Quick Overview
Edgar Cardenas Sanchez
 
the toyota way (SCIT) pune PPt
the toyota way (SCIT) pune PPtthe toyota way (SCIT) pune PPt
the toyota way (SCIT) pune PPt
ravindra sharma
 
Effective time management strategies ( pdf drive )
Effective time management strategies ( pdf drive )Effective time management strategies ( pdf drive )
Effective time management strategies ( pdf drive )
AditGupta20
 
The Lean Journey
The Lean JourneyThe Lean Journey
The Lean Journey
Dave Salzwedel
 
Powerful TPM-OEE implementation details
Powerful TPM-OEE  implementation details Powerful TPM-OEE  implementation details
Powerful TPM-OEE implementation details
Tan Moses
 
Kanban
KanbanKanban
Kanban
atif22
 
The toyota way
The toyota wayThe toyota way
The toyota way
vrkraam
 
05 Seminar Slide
05 Seminar Slide05 Seminar Slide
05 Seminar Slide
praful_m_n
 
Andon presentation
Andon presentationAndon presentation
Andon presentation
robjfletcher72
 
Implementing Kanban to Improve your Workflow
Implementing Kanban to Improve your WorkflowImplementing Kanban to Improve your Workflow
Implementing Kanban to Improve your Workflow
Jennifer Davis
 
KANBAN
KANBANKANBAN
KANBAN
Ujjwal Joshi
 
Lean manufacturing basics
Lean manufacturing basicsLean manufacturing basics
Lean manufacturing basics
sarah bridge
 
Kaizen Funnel Roadmap
Kaizen Funnel RoadmapKaizen Funnel Roadmap
Kaizen Funnel Roadmap
Michael Job
 
Designing your kanban board to map your process
Designing your kanban board to map your processDesigning your kanban board to map your process
Designing your kanban board to map your process
Yu Liang
 
Toyota production system
Toyota production systemToyota production system
Toyota production system
Deepa Ram Suthar
 
LeanKaizenTraining
LeanKaizenTrainingLeanKaizenTraining
LeanKaizenTraining
ahmad bassiouny
 
Kanban
KanbanKanban

What's hot (20)

just in time and lean manufacturing
just in time and lean manufacturingjust in time and lean manufacturing
just in time and lean manufacturing
 
Kanban Basics for Beginners
Kanban Basics for BeginnersKanban Basics for Beginners
Kanban Basics for Beginners
 
Kanban Explained in 11 Slides
Kanban Explained in 11 SlidesKanban Explained in 11 Slides
Kanban Explained in 11 Slides
 
Lean Strategy Deployment - Quick Overview
Lean Strategy Deployment -  Quick OverviewLean Strategy Deployment -  Quick Overview
Lean Strategy Deployment - Quick Overview
 
the toyota way (SCIT) pune PPt
the toyota way (SCIT) pune PPtthe toyota way (SCIT) pune PPt
the toyota way (SCIT) pune PPt
 
Effective time management strategies ( pdf drive )
Effective time management strategies ( pdf drive )Effective time management strategies ( pdf drive )
Effective time management strategies ( pdf drive )
 
The Lean Journey
The Lean JourneyThe Lean Journey
The Lean Journey
 
Powerful TPM-OEE implementation details
Powerful TPM-OEE  implementation details Powerful TPM-OEE  implementation details
Powerful TPM-OEE implementation details
 
Kanban
KanbanKanban
Kanban
 
The toyota way
The toyota wayThe toyota way
The toyota way
 
05 Seminar Slide
05 Seminar Slide05 Seminar Slide
05 Seminar Slide
 
Andon presentation
Andon presentationAndon presentation
Andon presentation
 
Implementing Kanban to Improve your Workflow
Implementing Kanban to Improve your WorkflowImplementing Kanban to Improve your Workflow
Implementing Kanban to Improve your Workflow
 
KANBAN
KANBANKANBAN
KANBAN
 
Lean manufacturing basics
Lean manufacturing basicsLean manufacturing basics
Lean manufacturing basics
 
Kaizen Funnel Roadmap
Kaizen Funnel RoadmapKaizen Funnel Roadmap
Kaizen Funnel Roadmap
 
Designing your kanban board to map your process
Designing your kanban board to map your processDesigning your kanban board to map your process
Designing your kanban board to map your process
 
Toyota production system
Toyota production systemToyota production system
Toyota production system
 
LeanKaizenTraining
LeanKaizenTrainingLeanKaizenTraining
LeanKaizenTraining
 
Kanban
KanbanKanban
Kanban
 

Similar to Introduzione alla Metodologia Scrumban

Management per l'innovazione: la metodologia Agile (principi e applicazione)
Management per l'innovazione: la metodologia Agile (principi e applicazione)Management per l'innovazione: la metodologia Agile (principi e applicazione)
Management per l'innovazione: la metodologia Agile (principi e applicazione)
Studio Sabrina Fattori - Consulenza Fiscale e Societaria - Roma Eur
 
Agile working
Agile workingAgile working
Agile working
Free Your Talent
 
Workshop di Business Design sul Business Model Canvas: dall'idea all'impresa
Workshop di Business Design sul Business Model Canvas: dall'idea all'impresaWorkshop di Business Design sul Business Model Canvas: dall'idea all'impresa
Workshop di Business Design sul Business Model Canvas: dall'idea all'impresa
Gino Tocchetti
 
Agile è il futuro? PMI Rome Webinar Presentation
Agile è il futuro? PMI Rome Webinar PresentationAgile è il futuro? PMI Rome Webinar Presentation
Agile è il futuro? PMI Rome Webinar Presentation
inspearit Italy
 
PMI Rome Agile Project Management è il futuro?
PMI Rome Agile Project Management è il futuro?PMI Rome Agile Project Management è il futuro?
PMI Rome Agile Project Management è il futuro?
Emiliano Soldi
 
PMexpo16 - DPO - Workshop
PMexpo16 - DPO - WorkshopPMexpo16 - DPO - Workshop
PMexpo16 - DPO - Workshop
PMexpo
 
Leonardo Lillo - Progettare lo Smart Working - Rinascita Digitale | DAY #15
Leonardo Lillo - Progettare lo Smart Working - Rinascita Digitale | DAY #15Leonardo Lillo - Progettare lo Smart Working - Rinascita Digitale | DAY #15
Leonardo Lillo - Progettare lo Smart Working - Rinascita Digitale | DAY #15
Stefano Saladino
 
Open Innovation Campus - 05/04/2018 - Agile challenges: essere agili nello sv...
Open Innovation Campus - 05/04/2018 - Agile challenges: essere agili nello sv...Open Innovation Campus - 05/04/2018 - Agile challenges: essere agili nello sv...
Open Innovation Campus - 05/04/2018 - Agile challenges: essere agili nello sv...
Vittorio Polizzi
 
Agile Lean Conference 2016 - Barengo _I principi del lean software development
Agile Lean Conference 2016 - Barengo _I principi del lean software developmentAgile Lean Conference 2016 - Barengo _I principi del lean software development
Agile Lean Conference 2016 - Barengo _I principi del lean software development
Agile Lean Conference
 
Marketing Automation Best Practices
Marketing Automation Best PracticesMarketing Automation Best Practices
Marketing Automation Best Practices
DML Srl
 
Project management: un must per imprese e professionisti
Project management: un must per imprese e professionistiProject management: un must per imprese e professionisti
Project management: un must per imprese e professionisti
Marco Turolla
 
Project management
Project managementProject management
Project management
mobi-TECH
 
Evolutive experience design
Evolutive experience designEvolutive experience design
Evolutive experience design
Luca Mascaro
 
ITSMF Conferenza 2014 - L'officina Agile per innovare l'IT Service Management
ITSMF Conferenza 2014 - L'officina Agile per innovare l'IT Service ManagementITSMF Conferenza 2014 - L'officina Agile per innovare l'IT Service Management
ITSMF Conferenza 2014 - L'officina Agile per innovare l'IT Service Management
Simone Onofri
 
BOLDideas 2014, Business Intelligence School: Sales process engineering
BOLDideas 2014, Business Intelligence School: Sales process engineeringBOLDideas 2014, Business Intelligence School: Sales process engineering
BOLDideas 2014, Business Intelligence School: Sales process engineering
BOLDideas
 
La metodologia Six Sigma come strumento di innovazione
La metodologia Six Sigma come strumento di innovazioneLa metodologia Six Sigma come strumento di innovazione
La metodologia Six Sigma come strumento di innovazione
Advance Operations Management School srl
 
La mappa strategica: la creazione delle strategie di crescita e il loro monit...
La mappa strategica: la creazione delle strategie di crescita e il loro monit...La mappa strategica: la creazione delle strategie di crescita e il loro monit...
La mappa strategica: la creazione delle strategie di crescita e il loro monit...
CentoCinquanta srl
 
Agile e Lean in sintesi
Agile e Lean in sintesiAgile e Lean in sintesi
Agile e Lean in sintesi
Stefano Muro
 
Usabilità e User Experience Design: #2 Test e Monitoraggio
Usabilità e User Experience Design: #2 Test e MonitoraggioUsabilità e User Experience Design: #2 Test e Monitoraggio
Usabilità e User Experience Design: #2 Test e Monitoraggio
FormazioneTurismo
 

Similar to Introduzione alla Metodologia Scrumban (20)

Management per l'innovazione: la metodologia Agile (principi e applicazione)
Management per l'innovazione: la metodologia Agile (principi e applicazione)Management per l'innovazione: la metodologia Agile (principi e applicazione)
Management per l'innovazione: la metodologia Agile (principi e applicazione)
 
Agile working
Agile workingAgile working
Agile working
 
Workshop di Business Design sul Business Model Canvas: dall'idea all'impresa
Workshop di Business Design sul Business Model Canvas: dall'idea all'impresaWorkshop di Business Design sul Business Model Canvas: dall'idea all'impresa
Workshop di Business Design sul Business Model Canvas: dall'idea all'impresa
 
Agile è il futuro? PMI Rome Webinar Presentation
Agile è il futuro? PMI Rome Webinar PresentationAgile è il futuro? PMI Rome Webinar Presentation
Agile è il futuro? PMI Rome Webinar Presentation
 
PMI Rome Agile Project Management è il futuro?
PMI Rome Agile Project Management è il futuro?PMI Rome Agile Project Management è il futuro?
PMI Rome Agile Project Management è il futuro?
 
PMexpo16 - DPO - Workshop
PMexpo16 - DPO - WorkshopPMexpo16 - DPO - Workshop
PMexpo16 - DPO - Workshop
 
Leonardo Lillo - Progettare lo Smart Working - Rinascita Digitale | DAY #15
Leonardo Lillo - Progettare lo Smart Working - Rinascita Digitale | DAY #15Leonardo Lillo - Progettare lo Smart Working - Rinascita Digitale | DAY #15
Leonardo Lillo - Progettare lo Smart Working - Rinascita Digitale | DAY #15
 
Open Innovation Campus - 05/04/2018 - Agile challenges: essere agili nello sv...
Open Innovation Campus - 05/04/2018 - Agile challenges: essere agili nello sv...Open Innovation Campus - 05/04/2018 - Agile challenges: essere agili nello sv...
Open Innovation Campus - 05/04/2018 - Agile challenges: essere agili nello sv...
 
Enterprise 2.0
Enterprise 2.0Enterprise 2.0
Enterprise 2.0
 
Agile Lean Conference 2016 - Barengo _I principi del lean software development
Agile Lean Conference 2016 - Barengo _I principi del lean software developmentAgile Lean Conference 2016 - Barengo _I principi del lean software development
Agile Lean Conference 2016 - Barengo _I principi del lean software development
 
Marketing Automation Best Practices
Marketing Automation Best PracticesMarketing Automation Best Practices
Marketing Automation Best Practices
 
Project management: un must per imprese e professionisti
Project management: un must per imprese e professionistiProject management: un must per imprese e professionisti
Project management: un must per imprese e professionisti
 
Project management
Project managementProject management
Project management
 
Evolutive experience design
Evolutive experience designEvolutive experience design
Evolutive experience design
 
ITSMF Conferenza 2014 - L'officina Agile per innovare l'IT Service Management
ITSMF Conferenza 2014 - L'officina Agile per innovare l'IT Service ManagementITSMF Conferenza 2014 - L'officina Agile per innovare l'IT Service Management
ITSMF Conferenza 2014 - L'officina Agile per innovare l'IT Service Management
 
BOLDideas 2014, Business Intelligence School: Sales process engineering
BOLDideas 2014, Business Intelligence School: Sales process engineeringBOLDideas 2014, Business Intelligence School: Sales process engineering
BOLDideas 2014, Business Intelligence School: Sales process engineering
 
La metodologia Six Sigma come strumento di innovazione
La metodologia Six Sigma come strumento di innovazioneLa metodologia Six Sigma come strumento di innovazione
La metodologia Six Sigma come strumento di innovazione
 
La mappa strategica: la creazione delle strategie di crescita e il loro monit...
La mappa strategica: la creazione delle strategie di crescita e il loro monit...La mappa strategica: la creazione delle strategie di crescita e il loro monit...
La mappa strategica: la creazione delle strategie di crescita e il loro monit...
 
Agile e Lean in sintesi
Agile e Lean in sintesiAgile e Lean in sintesi
Agile e Lean in sintesi
 
Usabilità e User Experience Design: #2 Test e Monitoraggio
Usabilità e User Experience Design: #2 Test e MonitoraggioUsabilità e User Experience Design: #2 Test e Monitoraggio
Usabilità e User Experience Design: #2 Test e Monitoraggio
 

More from Nextre Engineering

La mente del copywriter
La mente del copywriterLa mente del copywriter
La mente del copywriter
Nextre Engineering
 
Instagram da samurai (crea il tuo profilo)
Instagram da samurai (crea il tuo profilo)Instagram da samurai (crea il tuo profilo)
Instagram da samurai (crea il tuo profilo)
Nextre Engineering
 
Fara branding con i social media
Fara branding con i social mediaFara branding con i social media
Fara branding con i social media
Nextre Engineering
 
Differenze tra manager e leader
Differenze tra manager e leaderDifferenze tra manager e leader
Differenze tra manager e leader
Nextre Engineering
 
Differenza fra branding marketing
Differenza fra branding marketingDifferenza fra branding marketing
Differenza fra branding marketing
Nextre Engineering
 
Scrivere blog post da killer
Scrivere blog post da killerScrivere blog post da killer
Scrivere blog post da killer
Nextre Engineering
 
Sconti scatenano -le -vendite
Sconti scatenano -le -venditeSconti scatenano -le -vendite
Sconti scatenano -le -vendite
Nextre Engineering
 
Primo incontro con cliente come prepararsi
Primo incontro con cliente come prepararsiPrimo incontro con cliente come prepararsi
Primo incontro con cliente come prepararsi
Nextre Engineering
 
Pensa come Gucci
Pensa come GucciPensa come Gucci
Pensa come Gucci
Nextre Engineering
 
Come trovare clienti
Come trovare clientiCome trovare clienti
Come trovare clienti
Nextre Engineering
 
Come generare contenuti di valore
Come generare contenuti di valoreCome generare contenuti di valore
Come generare contenuti di valore
Nextre Engineering
 
Le 3 risposte della vendita
Le 3 risposte della venditaLe 3 risposte della vendita
Le 3 risposte della vendita
Nextre Engineering
 
1isettedaevitare
1isettedaevitare1isettedaevitare
1isettedaevitare
Nextre Engineering
 
Workshop instagram
Workshop instagram Workshop instagram
Workshop instagram
Nextre Engineering
 
Corso seo 3
Corso seo 3Corso seo 3
Corso seo 3
Nextre Engineering
 
Workshop seo middle
Workshop seo middleWorkshop seo middle
Workshop seo middle
Nextre Engineering
 
Workshop Seo Basic
Workshop Seo BasicWorkshop Seo Basic
Workshop Seo Basic
Nextre Engineering
 
Facebook Ads - Introduzione agli obiettivi di campagna
Facebook Ads - Introduzione agli obiettivi di campagnaFacebook Ads - Introduzione agli obiettivi di campagna
Facebook Ads - Introduzione agli obiettivi di campagna
Nextre Engineering
 
Workshop sulla Sicurezza Informatica
Workshop sulla Sicurezza InformaticaWorkshop sulla Sicurezza Informatica
Workshop sulla Sicurezza Informatica
Nextre Engineering
 
Nextre company profile_2017
Nextre company profile_2017Nextre company profile_2017
Nextre company profile_2017
Nextre Engineering
 

More from Nextre Engineering (20)

La mente del copywriter
La mente del copywriterLa mente del copywriter
La mente del copywriter
 
Instagram da samurai (crea il tuo profilo)
Instagram da samurai (crea il tuo profilo)Instagram da samurai (crea il tuo profilo)
Instagram da samurai (crea il tuo profilo)
 
Fara branding con i social media
Fara branding con i social mediaFara branding con i social media
Fara branding con i social media
 
Differenze tra manager e leader
Differenze tra manager e leaderDifferenze tra manager e leader
Differenze tra manager e leader
 
Differenza fra branding marketing
Differenza fra branding marketingDifferenza fra branding marketing
Differenza fra branding marketing
 
Scrivere blog post da killer
Scrivere blog post da killerScrivere blog post da killer
Scrivere blog post da killer
 
Sconti scatenano -le -vendite
Sconti scatenano -le -venditeSconti scatenano -le -vendite
Sconti scatenano -le -vendite
 
Primo incontro con cliente come prepararsi
Primo incontro con cliente come prepararsiPrimo incontro con cliente come prepararsi
Primo incontro con cliente come prepararsi
 
Pensa come Gucci
Pensa come GucciPensa come Gucci
Pensa come Gucci
 
Come trovare clienti
Come trovare clientiCome trovare clienti
Come trovare clienti
 
Come generare contenuti di valore
Come generare contenuti di valoreCome generare contenuti di valore
Come generare contenuti di valore
 
Le 3 risposte della vendita
Le 3 risposte della venditaLe 3 risposte della vendita
Le 3 risposte della vendita
 
1isettedaevitare
1isettedaevitare1isettedaevitare
1isettedaevitare
 
Workshop instagram
Workshop instagram Workshop instagram
Workshop instagram
 
Corso seo 3
Corso seo 3Corso seo 3
Corso seo 3
 
Workshop seo middle
Workshop seo middleWorkshop seo middle
Workshop seo middle
 
Workshop Seo Basic
Workshop Seo BasicWorkshop Seo Basic
Workshop Seo Basic
 
Facebook Ads - Introduzione agli obiettivi di campagna
Facebook Ads - Introduzione agli obiettivi di campagnaFacebook Ads - Introduzione agli obiettivi di campagna
Facebook Ads - Introduzione agli obiettivi di campagna
 
Workshop sulla Sicurezza Informatica
Workshop sulla Sicurezza InformaticaWorkshop sulla Sicurezza Informatica
Workshop sulla Sicurezza Informatica
 
Nextre company profile_2017
Nextre company profile_2017Nextre company profile_2017
Nextre company profile_2017
 

Introduzione alla Metodologia Scrumban

  • 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?
  • 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
  • 23. Diagrammi dei casi d’uso 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à.
  • 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.
  • 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à.
  • 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
  • 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