Secondo incontro del Roma-xpug nel quale si effettuerà una 'round-table' sui valori e i principi che sono alla base delle metodologie Lean e Agili. L'incontro prevede una breve presentazione di Fabio Armani a cui seguirà un panel aperto per scambiarsi opinioni e esperienze.
Second Meeting of the Rome-xpug in which we'll make a 'round-table' on the values and principles that are the basis of Lean and Agile methodologies. The meeting includes a short presentation by Fabio Armani, followed by an open panel to exchange views and experiences.
5. Chi sono
• Fabio Armani
– CEO di OpenWare
– Direttore artistico
dell’etichetta Different Lands
– Certified Scrum Master
Certified Scrum Professional,
PMI-ACP, PSM I
7. Le metodologie agili hanno l’obiettivo di migliorare la qualità del
prodotto e attraverso un costante e trasparente scambio di informazioni, il
coinvolgimento attivo del cliente, la gestione tempestiva dei cambiamenti
di contesto e il controllo empirico di processo.
• Del mondo Agile fanno parte più metodologie che si distinguono
per livelli diversi di formalismo e prescrizione:
(es. RUP +120, XP 13, Scrum 10, Kanban 3, …)
• Oggi la metodologia maggiormente adottata è Scrum, che spesso
viene impiegata in combinazione con XP (eXtreme Programming).
• Nell’ultimo decennio le metodologie agili si sono rapidamente
diffuse, passando dall’essere una nuova corrente di pensiero ad una
realtà consolidata, non solo in ambito IT.
7
8.
campi di applicazione
9. Le metodologie agili si applicano pressoché a tutti i settori.
Le dimensioni delle aziende che le adottano variano da poche decine a
migliaia di persone.
Esempi di aziende che hanno effettuato (o stanno effettuando)
una transizione Agile sono:
• Adobe • SAP
• BBC • Sapient
• Cisco Systems • Spotify
• Ericson • Yahoo!
• Expedia • …
• General Electric • DADA (IT)
• Google • Dedagroup (IT)
• IBM • Ericsson Italia (IT)
• Lockheed Martin • Siemens (IT)
• Microsoft • Venere (IT)
• Motorola • Yoox (IT)
• Oracle • …
9
10.
benefici
10
11.
• Consegna definita da un calendario fisso
• Più rapido time-to-market
• Coinvolgimento attivo del cliente, estrema focalizzazione
sulle priorità e più rapido adattamento alle mutazioni di
contesto
• Allineamento regolare e frequente sullo stato delle attività
• Gestione tempestiva delle criticità
• Miglioramento dell'impegno e partecipazione delle persone,
del loro senso di responsabilità e del grado di soddisfazione
• Migliore qualità del software
11
13. • Le persone e il team sono al centro della trasformazione e
devono essere adeguatamente preparate e accompagnate
• Il passaggio richiede una delega reale e il rispetto dei nuovi ruoli
• I metodi agili richiedono disciplina e rigore
• I metodi agili mettono in luce tutte le disfunzioni e fanno
emergere i conflitti nascosti
• La documentazione esiste e deve essere preparata secondo
regole ben definite
• I team devono essere cross-funzionali e devono lavorare insieme
in una modalità auto-organizzata
13
15. Il passaggio all'Agile è impegnativo sia per gli sviluppatori sia per
il resto dell'organizzazione.
Non si tratta della semplice applicazione di norme, quanto piuttosto di un
cambiamento culturale.
L'errore più frequente è quello di pensare di essere giunti alla meta: Agile è
un 'mind set' e un processo di continuo miglioramento e apprendimento.
In estrema sintesi il passaggio alle metodologie agili è difficile
perché:
• i cambiamenti non sono solo di tipo top down o bottom up
• lo stato finale è imprevedibile
• il cambiamento è pervasivo
• il cambiamento è estremo
• richiede molta disciplina e organizzazione
15
17.
Il processo di trasformazione agile di un azienda avviene in modo
incrementale ed iterativo adottando una metodologia agile anche
per guidare l’azienda nel processo di trasformazione stesso.
Il processo di transizione richiede in media da un anno a tre anni per
raggiungere un elevato grado di maturità, in funzione del contesto
specifico.
Normalmente dopo circa 6 mesi è già possibile rilevare i primi risultati
significativi.
17
28. • Puoi essere disciplinato o agile.
• Abbiamo bisogno di documentazione dettagliata di tutti i
requisiti nel fase uno, oppure non possiamo conoscere
obiettivi o sforzo.
• Tutto sarà completato entro il 1 di maggio?
• Le stime sono corrette oppure no?
• Tutti i passi devono essere predeterminati, o non possiamo
fare previsioni.
• I gruppi auto-organizzati sono anarchia.
• Dobbiamo assegnare tutte le attività alle risorse, oppure non
pianifichiamo.
• Facciamo TDD, quindi non facciamo nessuna modellazione.
28
46. Manifesto per lo Sviluppo Agile di Software
S:amo
scoprendo
modi
migliori
di
creare
so?ware,
sviluppandolo
e
aiutando
gli
altri
a
fare
lo
stesso.
Grazie
a
questa
aGvità
siamo
arriva:
a
considerare
importan::
Gli
individui
e
le
interazioni
più
che
i
processi
e
gli
strumen:
Il
so?ware
funzionante
più
che
la
documentazione
esaus:va
La
collaborazione
col
cliente
più
che
la
negoziazione
dei
contraG
Rispondere
al
cambiamento
più
che
seguire
un
piano
Ovvero,
fermo
restando
il
valore
delle
voci
a
destra,
consideriamo
più
importan:
le
voci
a
sinistra.
hNp://agilemanifesto.org/iso/it/
51. La nostra massima priorità è soddisfare il
cliente
rilasciando software di valore, fin da subito
e in maniera continua
53. Accogliamo i cambiamenti nei requisiti,
anche a stadi avanzati dello sviluppo.
I processi agili sfruttano il cambiamento
a favore del vantaggio competitivo del cliente.
55. Consegnamo frequentemente software
funzionante,
con cadenza variabile da un paio di settimane
a un paio di mesi,
preferendo i periodi brevi.
59. Fondiamo i progetti su individui motivati.
Diamo loro l'ambiente e il supporto di cui
hanno bisogno
e confidiamo nella loro capacità di portare il
lavoro a termine.
61. Una conversazione faccia a faccia
è il modo più efficiente e più efficace per
comunicare
con il team ed all'interno del team.
65. I processi agili promuovono uno sviluppo
sostenibile.
Gli sponsor, gli sviluppatori e gli utenti dovrebbero
essere in grado
di mantenere indefinitamente un ritmo costante.
67. La continua attenzione all'eccellenza tecnica
e alla buona progettazione esaltano l'agilità.
69. La semplicità - l'arte di massimizzare la
quantità
di lavoro non svolto - è essenziale.
71. Le architetture, i requisiti e la progettazione
migliori emergono da team che si auto-
organizzano.
73. A intervalli regolari il team riflette su come
diventare più efficace, dopodiché regola e adatta
il proprio comportamento di conseguenza.
101. Compariamolo con lo sviluppo
tradizionale
Visibilità
AdaNabilità
Business
Value
Rischi
Sviluppo
Agile
Sviluppo
Tradizionale
102. lasciare che le cose evolvano
• Lasciate che i dettagli emergano man mano che le
cose sono più a fuoco e che ottenete dei feedback
• Preoccupatevi dei dettagli solo quando questi
contano davvero
• Le migliori architetture, i requisiti e la progettazione
evolvono nel tempo
107. muoversi dell’esterno verso l’interno
• Permettere agli utenti di guidare il nostro lavoro
• Vedere tutto dal punto di vista dell’utente
• Comprendere il valore dalla prospettiva dell’utente
• Chiedere agli utenti
che cosa vogliono
successivamente
109. pensare in grande iniziare in piccolo
• Ottenere qualcosa di
piccolo ma di grande
impatto e mostrarlo
presto
• Collezionare feedback
dagli utenti reali
• Costruire a partire da
qui con regolari rilasci
incrementali
139. Eliminate Waste
Over-production Extra features
Inventory Requirements, unused code
Extra Processing Extra steps, task switching
WASTE
Motion Finding information, chasing people
Defects Defects not caught by tests
Waiting Waiting around
Transportation Handing stuff over the others
140. Eliminate Waste | in software?
• Provide market and technical leadership
• Creating nothing but value
• Write less code
141. Eliminate Waste | in software?
• The three biggest wastes in SW development
are:
– Extra Features: We need a process which allows us to develop
just those 20% of the features that give 80% of the value.
– Churn: If you have requirements churn, you are specifying too
early. If you have test and fix cycles, you are testing too late.
– Crossing Boundaries: Organizational boundaries typically
increase cost by over 25%; they interfere with communication.
144. Create knowledge | amplify learning
• Create design-build teams
• Maintain a culture of constant improvement
• Teach problem-solving methods
• Use the Scientific Method
• Standards Exist to be Challenged and Improved
• Predictable Performance is Driven by Feedback
147. Defer Commitment | decide as late as possible
• Abolish the idea that it is a good idea to start
development with a complete specification.
– Break Dependencies: System architecture should support the
addition of any feature at any time
– Maintain Options: Think of code as an experiment – make it
change-tolerant
– Schedule Irreversible Decisions at the Last Responsible Moment:
Learn as much as possible before making irreversible decision
152. Deliver fast | learn as fast as possible
• Work in small batches
• Focus on cycle time, not utilization
153. Deliver fast | learn as fast as possible
• Lists and queues are buffers between
organizations that simply slow things down.
– Rapid Delivery, High Quality, and Low Cost are Fully
Compatible: Companies that compete on the basis of speed
have a big cost advantage, are more attuned to their customers’
needs, and deliver superior quality
– Queuing Theory Applies to Development, not Just Servers:
Focusing on utilization creates a traffic jam that actually reduces
utilization. Drive down cycle time with small batches and fewer
things-in-process.
– Limit Work to Capacity: Establish a reliable, repeatable velocity
with iterative development. Aggressively limit the size of lists
and queues to your capacity to deliver.
156. Respect people | empower the team
• Train team leaders/supervisors
• More responsibility and decision making to the
lower possible level
• Foster pride in workmanship
157. Respect people | empower the team
• Engaged, thinking people provide the most
sustainable competitive advantage.
– Teams Thrive on Pride, Commitment, Trust, and Applause: What
makes a team? Members mutually committed to achieve a
common goal.
– Provide Effective Leadership: Effective teams have effective
leaders who bring out the best in the team.
– Respect Partners: Allegiance to the joint venture must never
create a conflict of interest.
161. Build Quality In | do it right the first time
• Synchronize
• Automate
• Refactor
162. Build Quality In | do it right the first time
• If you routinely find defects during verification,
your development process is defective.
– Mistake-Proof Code with Test-Driven Development: Write
executable specifications instead of requirements.
– Stop Building Legacy Code: Legacy code is code that
lacks automated unit and acceptance tests.
– The Big Bang is Obsolete: Use continuous integration and
nested synchronization
165. Optimize the Whole
• Brilliant products emerge from a unique
combination of opportunity and technology.
– Focus on the Entire Value Stream: from concept to cash, from
customer request to deployed software.
– Deliver a Complete Product: Develop a complete product, not
just software. Complete products are built by complete teams.
– Measure Up: Measure process capability with cycle time.
Measure team performance with delivered business value.
Measure customer satisfaction with a net promoter score.
197. Agile » bibliografia
• Agile & Iterative Development » Craig Larman (Addison-Wesley, 2003)
• Agile Software Development Ecosystems » Jim Highsmith (Addison-Wesley, 2003)
• Succeding with Agile » Mike Cohn (Addison-Wesley, 2009)
198. Agile » bibliografia
• Agile Project Management: Creating Innovative Products » Jim Highsmith (, 2005)
• Agile Software Development » Alistair Cockburn (Addison-Wesley, 2003)
• Agile Estimating and Planning » Mike Cohn (Addison-Wesley, 2003)
199. Agile » bibliografia
• User Stories Applied » Mike Cohn (Addison-Wesley Signature Series)
• Test Driven Development » Kent Beck (The Addison-Wesley Signature Series)
• Refactoring to Patterns » Joshua Kiriewsky (Addison-Wesley Signature Series)
200. Lean » bibliografia
• Lean Software Development » Mary & Tom Poppendieck (Addison-Wesley, 2003)
• Implementing Lean Software Development » Mary & Tom Poppendieck (Addison-Wesley, 2005)
• Leading Lean Software Development » Mary & Tom Poppendieck (Addison-Wesley, 2008)
201. Scrum » bibliografia
• Agile Software Development with Scrum » Ken Schwaber, Mike Beedle (Prentice Hall, 2001)
• Agile Project Management with Scrum » Ken Schwaber (Microsoft Press, 2004)
• The Enterprise and Scrum » Ken Schwaber (Microsoft Press, 2005)
• Agile Product Management with Scrum » Roman Pichler (Addison-Wesley, 2010)
202. Scrum » bibliografia
• Agile Retrospectives » Ester Derby, Diana Larsen (Pragmatic, 2006)
• ScrumMaster Guide » James Schiel (CRC Press, 2011)
• Software in 30 Days » Ken Schwaber, Jeff Sutherland (Prentice Hall, 2012)
203. XP » bibliografia
• eXtreme Programming Explained » Kent Beck
• Planning eXtreme Programming » Kent Beck, Martin Fowler
• eXtreme Programming Installed » Ron Jeffries, Ann Anderson, Chet Hendrickson
204. Grazie
– CEO di OpenWare
– Direttore artistico
dell’etichetta Different Lands
– Certified ScrumMaster &
Scrum Professional
– PMI-ACP Certified
– @fabioarmani
– www.open-ware.org