SlideShare ist ein Scribd-Unternehmen logo
1 von 205
Back to Agile - Codemotion 2013
Incidente	
  minerario	
  a	
  Quecreek	
  
2002	
  
	
  
Incidente	
  minerario	
  a	
  Quecreek	
  
2002	
  
	
  
valori e principi alla base delle
  metodologie Lean e Agili
Chi sono

•  Fabio Armani
   –  CEO di OpenWare

   –  Direttore artistico
      dell’etichetta Different Lands

   –  Certified Scrum Master
      Certified Scrum Professional,
      PMI-ACP, PSM I
di cosa parliamo?	
  
 
	
  
       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	
  
  	
   	
  campi di applicazione
  	
  
     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	
  
  	
   	
  benefici




                         10	
  
 
	
   •  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	
  
punti di attenzione
                 12	
  
•  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	
  
il	
  passaggio	
  è	
  semplice?	
  
                                 14	
  
  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	
  
Tempi	
  
            16	
  
 
	
  
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	
  
false
 dicotomie	
  
false
 dicotomie
Back to Agile - Codemotion 2013
Back to Agile - Codemotion 2013
Back to Agile - Codemotion 2013
Back to Agile - Codemotion 2013
agilità	
  
              24	
  
disciplina	
  
             25	
  
disciplina	
  
             26	
  
agilità	
  
              27	
  
  •    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	
  
con:nuum	
  
      dettaglio

   investimento

  modellazione

documentazione
Back to Agile - Codemotion 2013
Back to Agile - Codemotion 2013
Back to Agile - Codemotion 2013
Agile
Pra$che	
  Agili	
  




Principi	
  Agili	
  




 Valori	
  Agili	
  




 Necessità	
  di	
  
rispondere	
  al	
  
cambiamento	
  
   con:nuo	
  
Agile
Pra$che	
  Agili	
  




Principi	
  Agili	
  




 Valori	
  Agili	
  




 Necessità	
  di	
  
rispondere	
  al	
  
cambiamento	
  
   con:nuo	
  
Agile
Pra$che	
  Agili	
  




Principi	
  Agili	
  




 Valori	
  Agili	
  




 Necessità	
  di	
  
rispondere	
  al	
  
cambiamento	
  
   con:nuo	
  
Agile
Pra$che	
  Agili	
  




Principi	
  Agili	
  




 Valori	
  Agili	
  




 Necessità	
  di	
  
rispondere	
  al	
  
cambiamento	
  
   con:nuo	
  
valori	
  agili	
  
                      37	
  
Back to Agile - Codemotion 2013
Back to Agile - Codemotion 2013
Back to Agile - Codemotion 2013
Back to Agile - Codemotion 2013
Back to Agile - Codemotion 2013
Back to Agile - Codemotion 2013
Back to Agile - Codemotion 2013
Back to Agile - Codemotion 2013
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/	
  
Firmatari	
  del	
  
Manifesto	
  Agile	
  
Back to Agile - Codemotion 2013
Back to Agile - Codemotion 2013
Back to Agile - Codemotion 2013
La nostra massima priorità è soddisfare il
                  cliente
rilasciando software di valore, fin da subito
           e in maniera continua
Back to Agile - Codemotion 2013
Accogliamo i cambiamenti nei requisiti,
      anche a stadi avanzati dello sviluppo.
    I processi agili sfruttano il cambiamento
a favore del vantaggio competitivo del cliente.
Back to Agile - Codemotion 2013
Consegnamo frequentemente software
                funzionante,
con cadenza variabile da un paio di settimane
             a un paio di mesi,
        preferendo i periodi brevi.
Back to Agile - Codemotion 2013
Committenti e sviluppatori devono lavorare
                    insieme
quotidianamente per tutta la durata del progetto.
Back to Agile - Codemotion 2013
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.
Back to Agile - Codemotion 2013
Una conversazione faccia a faccia
è il modo più efficiente e più efficace per
                comunicare
    con il team ed all'interno del team.
Back to Agile - Codemotion 2013
Il software funzionante è il principale metro di
              misura di progresso.
Back to Agile - Codemotion 2013
I processi agili promuovono uno sviluppo
                      sostenibile.
Gli sponsor, gli sviluppatori e gli utenti dovrebbero
                   essere in grado
 di mantenere indefinitamente un ritmo costante.
Back to Agile - Codemotion 2013
La continua attenzione all'eccellenza tecnica
e alla buona progettazione esaltano l'agilità.
Back to Agile - Codemotion 2013
La semplicità - l'arte di massimizzare la
                quantità
  di lavoro non svolto - è essenziale.
Back to Agile - Codemotion 2013
Le architetture, i requisiti e la progettazione
  migliori emergono da team che si auto-
                 organizzano.
Back to Agile - Codemotion 2013
A intervalli regolari il team riflette su come
diventare più efficace, dopodiché regola e adatta
   il proprio comportamento di conseguenza.
Back to Agile - Codemotion 2013
Why?
Agile è importante
Why?
Agile è importante
Back to Agile - Codemotion 2013
Back to Agile - Codemotion 2013
Back to Agile - Codemotion 2013
Back to Agile - Codemotion 2013
Processo predeterminato
Processo predeterminato
Processo predeterminato
Framework sistemico creato da Dave Snowden
Cynefin Framework
Cynefin Framework
Cynefin Framework
Cynefin Framework
Cynefin Framework
waterfall	
  
Tradizionale	
  
Tradizionale	
  
Tradizionale	
  
Tradizionale	
  
agile	
  
Tradizionale	
  




Agile	
  
Tradizionale	
  




Agile	
  
Tradizionale	
  




Agile	
  
Tradizionale	
  




Agile	
  
?
Qual’è il valore per i nostri stakeholder?
Compariamolo con lo sviluppo
        tradizionale
 Visibilità	
                  AdaNabilità	
  




 Business	
  Value	
           Rischi	
  




       Sviluppo	
  Agile	
            Sviluppo	
  Tradizionale	
  
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
lasciare che le cose evolvano
lasciare che le cose evolvano
prendere piccole decisioni
•    Muoversi rapidamente
•    Procedere in avanti
•    Reversibile
•    Ultimo momento
     responsabile quando
     ulteriori informazioni
     sono disponibili
outside	
  »	
  in	
  
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
pensare in grande iniziare in piccolo
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
Agile checkpoints
Flusso Agile
Where Are We with Agility?




             The	
  CHAOS	
  Manifesto,	
  Copyright	
  2011	
  
Back to Agile - Codemotion 2013
Lean Thinking, Principi e Discipline
Back to Agile - Codemotion 2013
Lean is a philosophy of work
   that seeks perfection.
Lean is a system, that seek
reducing the time from order to
             cash.
Lean Key Concepts

MURI MURA MUDA
Back to Agile - Codemotion 2013
(muri)
 
non	
  sovraccaricare	
  i	
  
processi	
  
(mura)
Back to Agile - Codemotion 2013
mantenere	
  il	
  flusso	
  
regolare	
  e	
  costante	
  
Back to Agile - Codemotion 2013
(muda)
Back to Agile - Codemotion 2013
rimuovere	
    aGvità	
         che	
  
non	
  aggiungono	
  valore	
  
Applicare i concetti lean allo sviluppo software

VALORI LEAN
Lean| pilastri
                             Goal


                          Delivery


               PEOPLE




                                        KAIZEN
               Pillar                   Pillar




                        Lean Thinking
         Foundation
Rispettare le persone
Respect People
Kaizen
Back to Agile - Codemotion 2013
Applicare i concetti lean allo sviluppo software

PRINCIPI LEAN
Eliminate waste
Forms	
  of	
  waste	
   in	
  so?ware?	
  
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
Eliminate Waste | in software?
•  Provide market and technical leadership
•  Creating nothing but value
•  Write less code
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.
Amplify learning
Create	
  knowledge	
   amplify	
  learning	
  
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
Defer commitment
Defer	
  commitment	
   decide	
  as	
  late	
  as	
  possible	
  
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
Defer Commitment | decide as late as possible
Deliver fast
Deliver	
  as	
  fast	
   as	
  possible	
  
Learn	
  as	
  fast	
   as	
  possible	
  
Deliver fast | learn as fast as possible
•  Work in small batches
•  Focus on cycle time, not utilization
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.
Empower the team
Respect	
  people	
   empower	
  the	
  team	
  
Respect people | empower the team
•  Train team leaders/supervisors
•  More responsibility and decision making to the
   lower possible level
•  Foster pride in workmanship
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.
Build integrity in
Build	
  integrity	
  in	
   intrinsic	
  quality	
  
Build	
  integrity	
  in	
   intrinsic	
  quality	
  
Build Quality In | do it right the first time
•  Synchronize
•  Automate
•  Refactor
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
See the whole
Op:mize	
  the	
  whole	
   improve	
  the	
  system	
  
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.
Back to Agile - Codemotion 2013
Back to Agile - Codemotion 2013
Declinate nelle diverse metodologie
Back to Agile - Codemotion 2013
Crystal
                                        	
  
                                   Clear	
  
                DSDM	
  


Scrum	
  
                                                AgileUP	
  
 eXtreme	
                    Kanban	
  
 Programming	
  
                                    Feature	
  Driven	
  
            Lean	
                  Development	
  
            Development	
  
Quale metodologia?
            Metodologie	
  




29%	
  
               49%	
          Scrum	
  
                              Scrum/XP	
  Hibrid	
  
  22%	
                       All	
  Others	
  
Metodologie
Metodologia	
                                   Percentuale	
  

Scrum	
                                                           49.1%	
  

Scrum/XP	
  Hybrid	
                                              22.3%	
  

Extreme	
  Programming	
  (XP)	
                                   8.0%	
  

Custom/Hybrid	
                                                    5.3%	
  

Don’t	
  Know	
                                                    3.7%	
  

Agile	
  Unified	
  Process	
  (AgileUP)	
                          2.2%	
  

Other	
                                                            2.2%	
  

Feature-­‐Driven	
  Development	
  (FDD)	
                         2.1%	
  

Lean	
  Development	
                                              1.9%	
  

OpenUP	
                                                           0.6%	
  

Agile	
  Modeling	
                                                0.6%	
  

Crystal	
                                                          0.5%	
  
Confronto per capire non per
                                                         giudicare
Più	
  prescriGva                                                                   	
                                                                                                                 Più	
  adaNa:va	
  

                                  RUP	
  (120+)	
                                                                      XP	
  	
  (13)	
       Scrum	
  (9)	
               Kanban	
  (3)	
           Do	
  Whatever	
  (0)	
  
•    Architecture	
  Reviewer	
                               •    Business	
  use	
  case	
  realiza:on	
  
•    Business	
  Designer	
                                   •    Business	
  use-­‐case	
  model	
              •  Whole	
  team	
          •  Scrum	
  Master	
         •  Visualize	
  the	
  
•    Business-­‐Model	
  Reviewer	
                           •    Business	
  vision	
  
                                                                                                                  •  Coding	
  standard	
     •  Product	
  Owner	
  
• 
• 
     Business-­‐Process	
  Analyst	
  
     Capsule	
  Designer	
  
                                                              • 
                                                              • 
                                                                   Change	
  request	
  
                                                                   Configura:on	
  audit	
  findings	
                                                                          workflow	
  
•    Change	
  Control	
  Manager	
                           •    Configura:on	
  management	
  plan	
            •  TDD	
                    •  Team	
  
• 
• 
     Code	
  Reviewer	
  
     Configura:on	
  Manager	
  
                                                              • 
                                                              • 
                                                                   Data	
  model	
  
                                                                   Deployment	
  model	
                          •  Collec:ve	
              •  Sprint	
  planning	
      •  Limit	
  WIP	
  
• 
• 
     Course	
  Developer	
  
     Database	
  Designer	
  
                                                              • 
                                                              • 
                                                                   Deployment	
  plan	
  
                                                                   Design	
  guidelines	
                            ownership	
                 mee:ng	
                  •  Measure	
  and	
  
•    Deployment	
  Manager	
                                  •    Design	
  model	
  
•    Design	
  Reviewer	
                                     •    Development	
  case	
                          •  Customer	
  tests	
      •  Daily	
  Scrum	
             op:mize	
  lead	
  
•    Designer	
                                               •    Development-­‐organiza:on	
  assessment	
  
                                                                                                                  •  Pair	
                   •  Sprint	
  review	
  
• 
• 
     Graphic	
  Ar:st	
  
     Implementer	
  
                                                              • 
                                                              • 
                                                                   End-­‐user	
  support	
  mateirla	
  
                                                                   Glossary	
                                                                                                 :me	
  
•    Integrator	
                                             •    Implementa:on	
  model	
                          programming	
            •  Product	
  backlogt	
  
•    Process	
  Engineer	
                                    •    Installa:on	
  ar:facts	
  
•    Project	
  Manager	
                                     •    Integra:on	
  build	
  plan	
                  •  Refactoring	
            •  Sprint	
  backlog	
  
•    Project	
  Reviewer	
                                    •    Issues	
  list	
  
•    Requirements	
  Reviewer	
                               •    Itera:on	
  assessment	
                       •  Planning	
  game	
       •  BUrndown	
  chart	
  
• 
• 
     Requirements	
  Specifier	
  
     So?ware	
  Architect	
  
                                                              • 
                                                              • 
                                                                   Itera:on	
  plan	
  
                                                                   Manual	
  styleguide	
                         •  Con:nuous	
  
•    Stakeholder	
                                            •    Programming	
  guidelines	
  
•    System	
  Administrator	
                                •    Quality	
  assurance	
  plan	
                    integra:on	
  
•    System	
  Analyst	
                                      •    Reference	
  architecture	
  
•    Technical	
  Writer	
                                    •    Release	
  notes	
                             •  Simple	
  design	
  
• 
• 
     Test	
  Analyst	
  
     Test	
  Designer	
  
                                                              • 
                                                              • 
                                                                   Requirements	
  aNributes	
  
                                                                   Requirements	
                                 •  Sustainable	
                                                                         Henrik Kniberg
•    Test	
  Manager	
                                             management	
  plan	
  
•    Tester	
                                                 •    Review	
  record	
                                pace	
  
•    Tool	
  Specialist	
                                     •    Risk	
  list	
  
•    User-­‐Interface	
  Designer	
                           •    Risk	
  management	
  plan	
                   •  Metaphor	
  
•    Architectural	
  analysis	
                              •    So?ware	
  architecture	
  
•    Assess	
  Viability	
  of	
  architectural	
  proof-­‐        document	
                                     •  Small	
  releases	
  
     of-­‐concept	
                                           •    So?ware	
  development	
  
•    Capsule	
  design	
                                           plan	
  
•    Class	
  design	
                                        •    So?ware	
  requirements	
  specifica:on	
  
•    Construct	
  architectural	
  proof-­‐of-­‐              •    Stakeholder	
  requests	
  
     concept	
                                                •    Status	
  assessment	
  
•    Database	
  design	
                                     •    Supplementary	
  business	
  specifica:on	
  
•    Describe	
  distribu:on	
                                •    Supplementary	
  specifica:on	
  
•    Describe	
  the	
  run-­‐:me	
  architecture	
           •    Target	
  organiza:on	
  assessment	
  
•    Design	
  test	
  packages	
  and	
  classes	
           •    Test	
  automa:on	
  architecture	
  
•    Develop	
  design	
  guidelines	
                        •    Test	
  cases	
  
•    Develop	
  programming	
  guidelines	
                   •    Test	
  environment	
  configura:on	
  
•    Iden:fy	
  design	
  elements	
                          •    Test	
  evalua:on	
  summary	
  
•    Iden:fy	
  design	
  mechanisms	
                        •    Test	
  guidelines	
  
•    Incorporate	
  design	
  elements	
                      •    Test	
  ideas	
  list	
  
•    Priori:ze	
  use	
  cases	
                              •    Test	
  interface	
  specifica:on	
  
•    Review	
  the	
  architecture	
                          •    Test	
  plan	
  
•    Review	
  the	
  design	
                                •    Test	
  suite	
  
•    Structure	
  the	
  implementa:on	
  model	
             •    Tool	
  guidelines	
  
•    Subsystem	
  design	
                                    •    Training	
  materials	
  
•    Use-­‐case	
  analysis	
                                 •    Use	
  case	
  model	
  
•    Use-­‐case	
  design	
                                   •    Use	
  case	
  package	
  
•    Analysis	
  model	
                                      •    Use-­‐case	
  modeling	
  guidelines	
  
•    Architectural	
  proof-­‐of-­‐concept	
                  •    Use-­‐case	
  realiza:on	
  
•    Bill	
  of	
  materials	
                                •    Use-­‐case	
  storyboard	
  
•    Business	
  architecture	
  document	
                   •    User-­‐interface	
  guidelines	
  
•    Business	
  case	
                                       •    User-­‐interface	
  prototype	
  
•    Business	
  glossary	
                                   •    Vision	
  
•    Business	
  modeling	
  guidelines	
                     •    Work	
  order	
  
•    Business	
  object	
  model	
                            •    Workload	
  analysis	
  model	
  
•    Business	
  rules	
  
•    Business	
  use	
  case	
  
pra:che	
  




              principi	
  e	
  valori	
  
Introduzione al framework
Stacey Matrix



      Enterprise	
  
      Scrum	
  
     Development	
  
Scrum	
  come	
  processo	
  empirico	
  
Scrum | edificio
                                  Goal


                         PRODUCT


               INSPECT




                                                  ADAPT
                              Principles

                                         Rules
                         Roles
               Pillar                             Pillar




                         Transparency
         Foundation
Back to Agile - Codemotion 2013
impegno
 
  	
  
  	
  




  	
  
  	
  




focalizzazione
apertura
coraggio
rispetto
Back to Agile - Codemotion 2013
high performance tree
Back to Agile - Codemotion 2013
comunicazione
semplicità
coraggio
feedback
rispetto




      192	
  
Back to Agile - Codemotion 2013
high performance tree
 
	
  
	
  




	
  
	
     Q&A	
  


                 195	
  
Bibliografia
Metodologie Lean Agile (2010) i
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)
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)
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)
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)
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)
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)
XP » bibliografia
•    eXtreme Programming Explained » Kent Beck
•    Planning eXtreme Programming » Kent Beck, Martin Fowler
•    eXtreme Programming Installed » Ron Jeffries, Ann Anderson, Chet Hendrickson
Grazie

–  CEO di OpenWare
–  Direttore artistico
   dell’etichetta Different Lands
–  Certified ScrumMaster &
   Scrum Professional
–  PMI-ACP Certified
–  @fabioarmani
–  www.open-ware.org
Disclaimer

Weitere ähnliche Inhalte

Was ist angesagt?

Agile Project Management
Agile Project ManagementAgile Project Management
Agile Project ManagementGiulio Roggero
 
Sviluppo Agile secondo l'approccio SCRUM
Sviluppo Agile secondo l'approccio SCRUMSviluppo Agile secondo l'approccio SCRUM
Sviluppo Agile secondo l'approccio SCRUMMatteo Papadopoulos
 
Impatti dell'introduzione di Scrum
Impatti dell'introduzione di ScrumImpatti dell'introduzione di Scrum
Impatti dell'introduzione di ScrumAndrea Di Pinto
 
Agile raccontato a mia nonna
Agile raccontato a mia nonnaAgile raccontato a mia nonna
Agile raccontato a mia nonnaFelice Pescatore
 
Agile requirements - alla ricerca del filo rosso (iad 2013)
Agile requirements - alla ricerca del filo rosso (iad 2013)Agile requirements - alla ricerca del filo rosso (iad 2013)
Agile requirements - alla ricerca del filo rosso (iad 2013)Fabio Armani
 
Scrum! Sopravvivere e gestire progetti tra polli, maiali e clienti
Scrum! Sopravvivere e gestire progetti tra polli, maiali e clientiScrum! Sopravvivere e gestire progetti tra polli, maiali e clienti
Scrum! Sopravvivere e gestire progetti tra polli, maiali e clientiMarco Da Rin Zanco
 
Percorsi formativi Lean-Agile
Percorsi formativi Lean-AgilePercorsi formativi Lean-Agile
Percorsi formativi Lean-AgileGiulio Roggero
 
Agile Project Management - the Board Game workshop
Agile Project Management  - the Board Game workshopAgile Project Management  - the Board Game workshop
Agile Project Management - the Board Game workshopGiulio Roggero
 
2014 07-08 7° webinar pmi-rome agile scrum
2014 07-08 7° webinar pmi-rome agile scrum2014 07-08 7° webinar pmi-rome agile scrum
2014 07-08 7° webinar pmi-rome agile scrumEmiliano Soldi
 
Agile@scale - Agile Day 2013
Agile@scale - Agile Day 2013Agile@scale - Agile Day 2013
Agile@scale - Agile Day 2013Felice Pescatore
 
Agile Lean Conference 2016 - Romano Lean_scrum_kanban
Agile Lean Conference 2016 - Romano Lean_scrum_kanbanAgile Lean Conference 2016 - Romano Lean_scrum_kanban
Agile Lean Conference 2016 - Romano Lean_scrum_kanbanAgile Lean Conference
 
Manifesto per lo Sviluppo Agile di Software
Manifesto per lo Sviluppo Agile di SoftwareManifesto per lo Sviluppo Agile di Software
Manifesto per lo Sviluppo Agile di SoftwareAmmLibera AL
 
Scrum una breve introduzione
Scrum una breve introduzioneScrum una breve introduzione
Scrum una breve introduzionerhubbit
 
Scrum? E' come fare il bucato!
Scrum? E' come fare il bucato!Scrum? E' come fare il bucato!
Scrum? E' come fare il bucato!Manuel Scapolan
 
5 scrum dalle trincee - principi agili
5   scrum dalle trincee - principi agili5   scrum dalle trincee - principi agili
5 scrum dalle trincee - principi agiliAlessio Del Toro
 

Was ist angesagt? (20)

Agile in 45 minuti
Agile in 45 minutiAgile in 45 minuti
Agile in 45 minuti
 
Agile Project Management
Agile Project ManagementAgile Project Management
Agile Project Management
 
Sviluppo Agile secondo l'approccio SCRUM
Sviluppo Agile secondo l'approccio SCRUMSviluppo Agile secondo l'approccio SCRUM
Sviluppo Agile secondo l'approccio SCRUM
 
Impatti dell'introduzione di Scrum
Impatti dell'introduzione di ScrumImpatti dell'introduzione di Scrum
Impatti dell'introduzione di Scrum
 
Agile raccontato a mia nonna
Agile raccontato a mia nonnaAgile raccontato a mia nonna
Agile raccontato a mia nonna
 
Agile requirements - alla ricerca del filo rosso (iad 2013)
Agile requirements - alla ricerca del filo rosso (iad 2013)Agile requirements - alla ricerca del filo rosso (iad 2013)
Agile requirements - alla ricerca del filo rosso (iad 2013)
 
Scrum! Sopravvivere e gestire progetti tra polli, maiali e clienti
Scrum! Sopravvivere e gestire progetti tra polli, maiali e clientiScrum! Sopravvivere e gestire progetti tra polli, maiali e clienti
Scrum! Sopravvivere e gestire progetti tra polli, maiali e clienti
 
Percorsi formativi Lean-Agile
Percorsi formativi Lean-AgilePercorsi formativi Lean-Agile
Percorsi formativi Lean-Agile
 
Agile Project Management - the Board Game workshop
Agile Project Management  - the Board Game workshopAgile Project Management  - the Board Game workshop
Agile Project Management - the Board Game workshop
 
Dal waterfall allo scrum
Dal waterfall allo scrumDal waterfall allo scrum
Dal waterfall allo scrum
 
2014 07-08 7° webinar pmi-rome agile scrum
2014 07-08 7° webinar pmi-rome agile scrum2014 07-08 7° webinar pmi-rome agile scrum
2014 07-08 7° webinar pmi-rome agile scrum
 
Agile@scale - Agile Day 2013
Agile@scale - Agile Day 2013Agile@scale - Agile Day 2013
Agile@scale - Agile Day 2013
 
La salute del software
La salute del softwareLa salute del software
La salute del software
 
Semplicemente Agile
Semplicemente AgileSemplicemente Agile
Semplicemente Agile
 
Agile Lean Conference 2016 - Romano Lean_scrum_kanban
Agile Lean Conference 2016 - Romano Lean_scrum_kanbanAgile Lean Conference 2016 - Romano Lean_scrum_kanban
Agile Lean Conference 2016 - Romano Lean_scrum_kanban
 
Manifesto per lo Sviluppo Agile di Software
Manifesto per lo Sviluppo Agile di SoftwareManifesto per lo Sviluppo Agile di Software
Manifesto per lo Sviluppo Agile di Software
 
Scrum una breve introduzione
Scrum una breve introduzioneScrum una breve introduzione
Scrum una breve introduzione
 
Scrum? E' come fare il bucato!
Scrum? E' come fare il bucato!Scrum? E' come fare il bucato!
Scrum? E' come fare il bucato!
 
Lezione 1: I metodi agili
Lezione 1: I metodi agiliLezione 1: I metodi agili
Lezione 1: I metodi agili
 
5 scrum dalle trincee - principi agili
5   scrum dalle trincee - principi agili5   scrum dalle trincee - principi agili
5 scrum dalle trincee - principi agili
 

Andere mochten auch

Lean Agile Adoption Enterprise Challenges - XP 2012
Lean Agile Adoption Enterprise Challenges - XP 2012Lean Agile Adoption Enterprise Challenges - XP 2012
Lean Agile Adoption Enterprise Challenges - XP 2012Fabio Armani
 
Shape Shift - XP 2009
Shape Shift - XP 2009Shape Shift - XP 2009
Shape Shift - XP 2009Fabio Armani
 
The Tao of Agile - XP2012
The Tao of Agile - XP2012The Tao of Agile - XP2012
The Tao of Agile - XP2012Fabio Armani
 
Behavior Driven Development - WPC 2011
Behavior Driven Development - WPC 2011Behavior Driven Development - WPC 2011
Behavior Driven Development - WPC 2011Fabio Armani
 
Lean Agile Contracts - iad 2012
Lean Agile Contracts - iad 2012Lean Agile Contracts - iad 2012
Lean Agile Contracts - iad 2012Fabio Armani
 
Chorale 2 the Tao of Change
Chorale 2   the Tao of ChangeChorale 2   the Tao of Change
Chorale 2 the Tao of ChangeFabio Armani
 
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014Fabio Armani
 
Design Patterns - Enterprise Patterns (part 2)
Design Patterns - Enterprise Patterns (part 2)Design Patterns - Enterprise Patterns (part 2)
Design Patterns - Enterprise Patterns (part 2)Fabio Armani
 
Design patterns - parte 1
Design patterns - parte 1Design patterns - parte 1
Design patterns - parte 1Fabio Armani
 
Scrumban a Methodology Fusion - Bettersoftware & Codemotion 2011
Scrumban a Methodology Fusion - Bettersoftware & Codemotion 2011Scrumban a Methodology Fusion - Bettersoftware & Codemotion 2011
Scrumban a Methodology Fusion - Bettersoftware & Codemotion 2011Fabio Armani
 
Scrum buts » but Scrum - which is worse?
Scrum buts » but Scrum - which is worse?Scrum buts » but Scrum - which is worse?
Scrum buts » but Scrum - which is worse?Fabio Armani
 
Mapping the Value (Agilia Budapest 2016)
Mapping the Value (Agilia Budapest 2016)Mapping the Value (Agilia Budapest 2016)
Mapping the Value (Agilia Budapest 2016)Fabio Armani
 
Agile soft skills suitecase - iad 2011
Agile soft skills suitecase - iad 2011Agile soft skills suitecase - iad 2011
Agile soft skills suitecase - iad 2011Fabio Armani
 
Design Patterns - enterprise patterns (part I)
Design Patterns - enterprise patterns (part I)Design Patterns - enterprise patterns (part I)
Design Patterns - enterprise patterns (part I)Fabio Armani
 
Lean UX - Integrated Teams
Lean UX - Integrated TeamsLean UX - Integrated Teams
Lean UX - Integrated TeamsFabio Armani
 
Scaling lean agile agile prage 2014 (armani)
Scaling lean agile   agile prage 2014 (armani)Scaling lean agile   agile prage 2014 (armani)
Scaling lean agile agile prage 2014 (armani)Fabio Armani
 
User Stories Writing - Codemotion 2013
User Stories Writing - Codemotion 2013User Stories Writing - Codemotion 2013
User Stories Writing - Codemotion 2013Fabio Armani
 
User Stories writing - Bettersoftware 2012
User Stories writing - Bettersoftware 2012User Stories writing - Bettersoftware 2012
User Stories writing - Bettersoftware 2012Fabio Armani
 
Impact Mapping LEGO Game - Agile Business Day 2016
Impact Mapping LEGO Game - Agile Business Day 2016Impact Mapping LEGO Game - Agile Business Day 2016
Impact Mapping LEGO Game - Agile Business Day 2016Fabio Armani
 

Andere mochten auch (20)

Perdere il controllo (IAD09)
Perdere il controllo (IAD09)Perdere il controllo (IAD09)
Perdere il controllo (IAD09)
 
Lean Agile Adoption Enterprise Challenges - XP 2012
Lean Agile Adoption Enterprise Challenges - XP 2012Lean Agile Adoption Enterprise Challenges - XP 2012
Lean Agile Adoption Enterprise Challenges - XP 2012
 
Shape Shift - XP 2009
Shape Shift - XP 2009Shape Shift - XP 2009
Shape Shift - XP 2009
 
The Tao of Agile - XP2012
The Tao of Agile - XP2012The Tao of Agile - XP2012
The Tao of Agile - XP2012
 
Behavior Driven Development - WPC 2011
Behavior Driven Development - WPC 2011Behavior Driven Development - WPC 2011
Behavior Driven Development - WPC 2011
 
Lean Agile Contracts - iad 2012
Lean Agile Contracts - iad 2012Lean Agile Contracts - iad 2012
Lean Agile Contracts - iad 2012
 
Chorale 2 the Tao of Change
Chorale 2   the Tao of ChangeChorale 2   the Tao of Change
Chorale 2 the Tao of Change
 
Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014Scaling Lean Agile - mini iad 2014
Scaling Lean Agile - mini iad 2014
 
Design Patterns - Enterprise Patterns (part 2)
Design Patterns - Enterprise Patterns (part 2)Design Patterns - Enterprise Patterns (part 2)
Design Patterns - Enterprise Patterns (part 2)
 
Design patterns - parte 1
Design patterns - parte 1Design patterns - parte 1
Design patterns - parte 1
 
Scrumban a Methodology Fusion - Bettersoftware & Codemotion 2011
Scrumban a Methodology Fusion - Bettersoftware & Codemotion 2011Scrumban a Methodology Fusion - Bettersoftware & Codemotion 2011
Scrumban a Methodology Fusion - Bettersoftware & Codemotion 2011
 
Scrum buts » but Scrum - which is worse?
Scrum buts » but Scrum - which is worse?Scrum buts » but Scrum - which is worse?
Scrum buts » but Scrum - which is worse?
 
Mapping the Value (Agilia Budapest 2016)
Mapping the Value (Agilia Budapest 2016)Mapping the Value (Agilia Budapest 2016)
Mapping the Value (Agilia Budapest 2016)
 
Agile soft skills suitecase - iad 2011
Agile soft skills suitecase - iad 2011Agile soft skills suitecase - iad 2011
Agile soft skills suitecase - iad 2011
 
Design Patterns - enterprise patterns (part I)
Design Patterns - enterprise patterns (part I)Design Patterns - enterprise patterns (part I)
Design Patterns - enterprise patterns (part I)
 
Lean UX - Integrated Teams
Lean UX - Integrated TeamsLean UX - Integrated Teams
Lean UX - Integrated Teams
 
Scaling lean agile agile prage 2014 (armani)
Scaling lean agile   agile prage 2014 (armani)Scaling lean agile   agile prage 2014 (armani)
Scaling lean agile agile prage 2014 (armani)
 
User Stories Writing - Codemotion 2013
User Stories Writing - Codemotion 2013User Stories Writing - Codemotion 2013
User Stories Writing - Codemotion 2013
 
User Stories writing - Bettersoftware 2012
User Stories writing - Bettersoftware 2012User Stories writing - Bettersoftware 2012
User Stories writing - Bettersoftware 2012
 
Impact Mapping LEGO Game - Agile Business Day 2016
Impact Mapping LEGO Game - Agile Business Day 2016Impact Mapping LEGO Game - Agile Business Day 2016
Impact Mapping LEGO Game - Agile Business Day 2016
 

Ähnlich wie Back to Agile - Codemotion 2013

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 ManagementSimone Onofri
 
Agile project management 1 giornata - board game - v2
Agile project management   1 giornata - board game - v2Agile project management   1 giornata - board game - v2
Agile project management 1 giornata - board game - v2Giulio Roggero
 
Agile e Lean in sintesi
Agile e Lean in sintesiAgile e Lean in sintesi
Agile e Lean in sintesiStefano Muro
 
Agile Lean Conference 2016 - Paragano_Agile per vincere le resistenze
Agile Lean Conference 2016 - Paragano_Agile per vincere le resistenzeAgile Lean Conference 2016 - Paragano_Agile per vincere le resistenze
Agile Lean Conference 2016 - Paragano_Agile per vincere le resistenzeAgile Lean Conference
 
Introduzione alla Metodologia Scrumban
Introduzione alla Metodologia ScrumbanIntroduzione alla Metodologia Scrumban
Introduzione alla Metodologia ScrumbanNextre Engineering
 
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
 
DAD e Visual Studio Online
DAD e Visual Studio OnlineDAD e Visual Studio Online
DAD e Visual Studio OnlineFelice Pescatore
 
PMexpo16 - DPO - Workshop
PMexpo16 - DPO - WorkshopPMexpo16 - DPO - Workshop
PMexpo16 - DPO - WorkshopPMexpo
 
Agile Lean Conference 2016 - Pescatore_ Road to Disciplined DevOps
Agile Lean Conference 2016 - Pescatore_ Road to Disciplined DevOpsAgile Lean Conference 2016 - Pescatore_ Road to Disciplined DevOps
Agile Lean Conference 2016 - Pescatore_ Road to Disciplined DevOpsAgile Lean Conference
 
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 developmentAgile Lean Conference
 
Come ti cambio l'organizzazione con un Capo Progetto e un Team SCRUM
Come ti cambio l'organizzazione  con un Capo Progetto e un Team SCRUMCome ti cambio l'organizzazione  con un Capo Progetto e un Team SCRUM
Come ti cambio l'organizzazione con un Capo Progetto e un Team SCRUMStefania Di Cristofalo
 
Agile e Lean Management
 Agile e Lean Management Agile e Lean Management
Agile e Lean ManagementSimone Onofri
 
L'innovazione manageriale nello sviluppo dei servizi e dei prodotti
L'innovazione manageriale nello sviluppo dei servizi e dei prodottiL'innovazione manageriale nello sviluppo dei servizi e dei prodotti
L'innovazione manageriale nello sviluppo dei servizi e dei prodottiClaudio Saurin
 
La Formazione, Leva del Cambiamento Organizzativo
La Formazione, Leva del Cambiamento OrganizzativoLa Formazione, Leva del Cambiamento Organizzativo
La Formazione, Leva del Cambiamento OrganizzativoNicola Mezzetti
 
Trasformazioni Agili - Agile Transformation - Business Agility
Trasformazioni Agili - Agile Transformation - Business AgilityTrasformazioni Agili - Agile Transformation - Business Agility
Trasformazioni Agili - Agile Transformation - Business AgilityEmiliano Soldi
 

Ähnlich wie Back to Agile - Codemotion 2013 (20)

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
 
Agile project management 1 giornata - board game - v2
Agile project management   1 giornata - board game - v2Agile project management   1 giornata - board game - v2
Agile project management 1 giornata - board game - v2
 
Agile e Lean in sintesi
Agile e Lean in sintesiAgile e Lean in sintesi
Agile e Lean in sintesi
 
Agile Lean Conference 2016 - Paragano_Agile per vincere le resistenze
Agile Lean Conference 2016 - Paragano_Agile per vincere le resistenzeAgile Lean Conference 2016 - Paragano_Agile per vincere le resistenze
Agile Lean Conference 2016 - Paragano_Agile per vincere le resistenze
 
Introduzione alla Metodologia Scrumban
Introduzione alla Metodologia ScrumbanIntroduzione alla Metodologia Scrumban
Introduzione alla Metodologia Scrumban
 
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...
 
DAD e Visual Studio Online
DAD e Visual Studio OnlineDAD e Visual Studio Online
DAD e Visual Studio Online
 
Agile@scale: be SAFe!
Agile@scale: be SAFe!Agile@scale: be SAFe!
Agile@scale: be SAFe!
 
PMexpo16 - DPO - Workshop
PMexpo16 - DPO - WorkshopPMexpo16 - DPO - Workshop
PMexpo16 - DPO - Workshop
 
Agile Lean Conference 2016 - Pescatore_ Road to Disciplined DevOps
Agile Lean Conference 2016 - Pescatore_ Road to Disciplined DevOpsAgile Lean Conference 2016 - Pescatore_ Road to Disciplined DevOps
Agile Lean Conference 2016 - Pescatore_ Road to Disciplined DevOps
 
Disciplined Agile DevOps
Disciplined Agile DevOpsDisciplined Agile DevOps
Disciplined Agile DevOps
 
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 working
Agile workingAgile working
Agile working
 
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)
 
Come ti cambio l'organizzazione con un Capo Progetto e un Team SCRUM
Come ti cambio l'organizzazione  con un Capo Progetto e un Team SCRUMCome ti cambio l'organizzazione  con un Capo Progetto e un Team SCRUM
Come ti cambio l'organizzazione con un Capo Progetto e un Team SCRUM
 
Agile e Lean Management
 Agile e Lean Management Agile e Lean Management
Agile e Lean Management
 
Smartworking
SmartworkingSmartworking
Smartworking
 
L'innovazione manageriale nello sviluppo dei servizi e dei prodotti
L'innovazione manageriale nello sviluppo dei servizi e dei prodottiL'innovazione manageriale nello sviluppo dei servizi e dei prodotti
L'innovazione manageriale nello sviluppo dei servizi e dei prodotti
 
La Formazione, Leva del Cambiamento Organizzativo
La Formazione, Leva del Cambiamento OrganizzativoLa Formazione, Leva del Cambiamento Organizzativo
La Formazione, Leva del Cambiamento Organizzativo
 
Trasformazioni Agili - Agile Transformation - Business Agility
Trasformazioni Agili - Agile Transformation - Business AgilityTrasformazioni Agili - Agile Transformation - Business Agility
Trasformazioni Agili - Agile Transformation - Business Agility
 

Mehr von Fabio Armani

Agile Music from the Trenches
Agile Music from the TrenchesAgile Music from the Trenches
Agile Music from the TrenchesFabio Armani
 
Alien eXperience - FuffaDay 2022 (Fabio Armani & Virginia Capoluongo)
Alien eXperience - FuffaDay 2022 (Fabio Armani & Virginia Capoluongo)Alien eXperience - FuffaDay 2022 (Fabio Armani & Virginia Capoluongo)
Alien eXperience - FuffaDay 2022 (Fabio Armani & Virginia Capoluongo)Fabio Armani
 
Product Values - Ethical Considerations - ver 1.4 (no video).pdf
Product Values - Ethical Considerations - ver 1.4 (no video).pdfProduct Values - Ethical Considerations - ver 1.4 (no video).pdf
Product Values - Ethical Considerations - ver 1.4 (no video).pdfFabio Armani
 
Surfing on the Edge of Chaos
Surfing on the Edge of ChaosSurfing on the Edge of Chaos
Surfing on the Edge of ChaosFabio Armani
 
Agile marketing - beyond it 2021
Agile marketing - beyond it 2021Agile marketing - beyond it 2021
Agile marketing - beyond it 2021Fabio Armani
 
Agile Myths and Pitfalls - 2020 (ver 0.8)
Agile Myths and Pitfalls - 2020 (ver 0.8)Agile Myths and Pitfalls - 2020 (ver 0.8)
Agile Myths and Pitfalls - 2020 (ver 0.8)Fabio Armani
 
Appreciative Inquiry - an overview
Appreciative Inquiry - an overviewAppreciative Inquiry - an overview
Appreciative Inquiry - an overviewFabio Armani
 
Appreciative Inquiry - an introduction
Appreciative Inquiry - an introductionAppreciative Inquiry - an introduction
Appreciative Inquiry - an introductionFabio Armani
 
Mapping the Change - final
Mapping the Change - final Mapping the Change - final
Mapping the Change - final Fabio Armani
 
Manifiesto de Mañana Programming
Manifiesto de Mañana Programming Manifiesto de Mañana Programming
Manifiesto de Mañana Programming Fabio Armani
 
From Manana Programming to Zen Delivery (final) - 2019
From Manana Programming to Zen Delivery (final) - 2019From Manana Programming to Zen Delivery (final) - 2019
From Manana Programming to Zen Delivery (final) - 2019Fabio Armani
 
Human Side of Agile (Agile Venture 2019)
Human Side of Agile (Agile Venture 2019)Human Side of Agile (Agile Venture 2019)
Human Side of Agile (Agile Venture 2019)Fabio Armani
 
Psychological Safety - ABD19
Psychological Safety - ABD19Psychological Safety - ABD19
Psychological Safety - ABD19Fabio Armani
 
Enterprise lean agile 2018 challenges ver 0.3
Enterprise lean agile 2018   challenges ver 0.3Enterprise lean agile 2018   challenges ver 0.3
Enterprise lean agile 2018 challenges ver 0.3Fabio Armani
 
Business Agility 2017 (final)
Business Agility 2017 (final)Business Agility 2017 (final)
Business Agility 2017 (final)Fabio Armani
 
Lean Change Management (part II) - IAD 2014
Lean Change Management (part II) - IAD 2014Lean Change Management (part II) - IAD 2014
Lean Change Management (part II) - IAD 2014Fabio Armani
 
Lean Change Management (part I) - IAD 2014
Lean Change Management (part I) - IAD 2014Lean Change Management (part I) - IAD 2014
Lean Change Management (part I) - IAD 2014Fabio Armani
 
User Story Mapping - mini iad 2014 (Armani, Rodriguez)
User Story Mapping - mini iad 2014 (Armani, Rodriguez)User Story Mapping - mini iad 2014 (Armani, Rodriguez)
User Story Mapping - mini iad 2014 (Armani, Rodriguez)Fabio Armani
 

Mehr von Fabio Armani (18)

Agile Music from the Trenches
Agile Music from the TrenchesAgile Music from the Trenches
Agile Music from the Trenches
 
Alien eXperience - FuffaDay 2022 (Fabio Armani & Virginia Capoluongo)
Alien eXperience - FuffaDay 2022 (Fabio Armani & Virginia Capoluongo)Alien eXperience - FuffaDay 2022 (Fabio Armani & Virginia Capoluongo)
Alien eXperience - FuffaDay 2022 (Fabio Armani & Virginia Capoluongo)
 
Product Values - Ethical Considerations - ver 1.4 (no video).pdf
Product Values - Ethical Considerations - ver 1.4 (no video).pdfProduct Values - Ethical Considerations - ver 1.4 (no video).pdf
Product Values - Ethical Considerations - ver 1.4 (no video).pdf
 
Surfing on the Edge of Chaos
Surfing on the Edge of ChaosSurfing on the Edge of Chaos
Surfing on the Edge of Chaos
 
Agile marketing - beyond it 2021
Agile marketing - beyond it 2021Agile marketing - beyond it 2021
Agile marketing - beyond it 2021
 
Agile Myths and Pitfalls - 2020 (ver 0.8)
Agile Myths and Pitfalls - 2020 (ver 0.8)Agile Myths and Pitfalls - 2020 (ver 0.8)
Agile Myths and Pitfalls - 2020 (ver 0.8)
 
Appreciative Inquiry - an overview
Appreciative Inquiry - an overviewAppreciative Inquiry - an overview
Appreciative Inquiry - an overview
 
Appreciative Inquiry - an introduction
Appreciative Inquiry - an introductionAppreciative Inquiry - an introduction
Appreciative Inquiry - an introduction
 
Mapping the Change - final
Mapping the Change - final Mapping the Change - final
Mapping the Change - final
 
Manifiesto de Mañana Programming
Manifiesto de Mañana Programming Manifiesto de Mañana Programming
Manifiesto de Mañana Programming
 
From Manana Programming to Zen Delivery (final) - 2019
From Manana Programming to Zen Delivery (final) - 2019From Manana Programming to Zen Delivery (final) - 2019
From Manana Programming to Zen Delivery (final) - 2019
 
Human Side of Agile (Agile Venture 2019)
Human Side of Agile (Agile Venture 2019)Human Side of Agile (Agile Venture 2019)
Human Side of Agile (Agile Venture 2019)
 
Psychological Safety - ABD19
Psychological Safety - ABD19Psychological Safety - ABD19
Psychological Safety - ABD19
 
Enterprise lean agile 2018 challenges ver 0.3
Enterprise lean agile 2018   challenges ver 0.3Enterprise lean agile 2018   challenges ver 0.3
Enterprise lean agile 2018 challenges ver 0.3
 
Business Agility 2017 (final)
Business Agility 2017 (final)Business Agility 2017 (final)
Business Agility 2017 (final)
 
Lean Change Management (part II) - IAD 2014
Lean Change Management (part II) - IAD 2014Lean Change Management (part II) - IAD 2014
Lean Change Management (part II) - IAD 2014
 
Lean Change Management (part I) - IAD 2014
Lean Change Management (part I) - IAD 2014Lean Change Management (part I) - IAD 2014
Lean Change Management (part I) - IAD 2014
 
User Story Mapping - mini iad 2014 (Armani, Rodriguez)
User Story Mapping - mini iad 2014 (Armani, Rodriguez)User Story Mapping - mini iad 2014 (Armani, Rodriguez)
User Story Mapping - mini iad 2014 (Armani, Rodriguez)
 

Back to Agile - Codemotion 2013

  • 2. Incidente  minerario  a  Quecreek   2002    
  • 3. Incidente  minerario  a  Quecreek   2002    
  • 4. valori e principi alla base delle metodologie Lean e Agili
  • 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  
  • 14. il  passaggio  è  semplice?   14  
  • 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  
  • 16. Tempi   16  
  • 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  
  • 24. agilità   24  
  • 25. disciplina   25  
  • 26. disciplina   26  
  • 27. agilità   27  
  • 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  
  • 29. con:nuum   dettaglio investimento modellazione documentazione
  • 33. Agile Pra$che  Agili   Principi  Agili   Valori  Agili   Necessità  di   rispondere  al   cambiamento   con:nuo  
  • 34. Agile Pra$che  Agili   Principi  Agili   Valori  Agili   Necessità  di   rispondere  al   cambiamento   con:nuo  
  • 35. Agile Pra$che  Agili   Principi  Agili   Valori  Agili   Necessità  di   rispondere  al   cambiamento   con:nuo  
  • 36. Agile Pra$che  Agili   Principi  Agili   Valori  Agili   Necessità  di   rispondere  al   cambiamento   con:nuo  
  • 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.
  • 57. Committenti e sviluppatori devono lavorare insieme quotidianamente per tutta la durata del progetto.
  • 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.
  • 63. Il software funzionante è il principale metro di misura di progresso.
  • 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.
  • 84. Framework sistemico creato da Dave Snowden
  • 100. ? Qual’è il valore per i nostri stakeholder?
  • 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
  • 103. lasciare che le cose evolvano
  • 104. lasciare che le cose evolvano
  • 105. prendere piccole decisioni •  Muoversi rapidamente •  Procedere in avanti •  Reversibile •  Ultimo momento responsabile quando ulteriori informazioni sono disponibili
  • 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
  • 108. pensare in grande iniziare in piccolo
  • 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
  • 112. Where Are We with Agility? The  CHAOS  Manifesto,  Copyright  2011  
  • 114. Lean Thinking, Principi e Discipline
  • 116. Lean is a philosophy of work that seeks perfection.
  • 117. Lean is a system, that seek reducing the time from order to cash.
  • 120. (muri)
  • 121.  
  • 122. non  sovraccaricare  i   processi  
  • 123. (mura)
  • 125. mantenere  il  flusso   regolare  e  costante  
  • 127. (muda)
  • 129. rimuovere   aGvità   che   non  aggiungono  valore  
  • 130. Applicare i concetti lean allo sviluppo software VALORI LEAN
  • 131. Lean| pilastri Goal Delivery PEOPLE KAIZEN Pillar Pillar Lean Thinking Foundation
  • 134. Kaizen
  • 136. Applicare i concetti lean allo sviluppo software PRINCIPI LEAN
  • 138. Forms  of  waste   in  so?ware?  
  • 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.
  • 143. Create  knowledge   amplify  learning  
  • 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
  • 146. Defer  commitment   decide  as  late  as  possible  
  • 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
  • 148. Defer Commitment | decide as late as possible
  • 150. Deliver  as  fast   as  possible  
  • 151. Learn  as  fast   as  possible  
  • 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.
  • 155. Respect  people   empower  the  team  
  • 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.
  • 159. Build  integrity  in   intrinsic  quality  
  • 160. Build  integrity  in   intrinsic  quality  
  • 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
  • 164. Op:mize  the  whole   improve  the  system  
  • 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.
  • 168. Declinate nelle diverse metodologie
  • 170. Crystal   Clear   DSDM   Scrum   AgileUP   eXtreme   Kanban   Programming   Feature  Driven   Lean   Development   Development  
  • 171. Quale metodologia? Metodologie   29%   49%   Scrum   Scrum/XP  Hibrid   22%   All  Others  
  • 172. Metodologie Metodologia   Percentuale   Scrum   49.1%   Scrum/XP  Hybrid   22.3%   Extreme  Programming  (XP)   8.0%   Custom/Hybrid   5.3%   Don’t  Know   3.7%   Agile  Unified  Process  (AgileUP)   2.2%   Other   2.2%   Feature-­‐Driven  Development  (FDD)   2.1%   Lean  Development   1.9%   OpenUP   0.6%   Agile  Modeling   0.6%   Crystal   0.5%  
  • 173. Confronto per capire non per giudicare Più  prescriGva   Più  adaNa:va   RUP  (120+)   XP    (13)   Scrum  (9)   Kanban  (3)   Do  Whatever  (0)   •  Architecture  Reviewer   •  Business  use  case  realiza:on   •  Business  Designer   •  Business  use-­‐case  model   •  Whole  team   •  Scrum  Master   •  Visualize  the   •  Business-­‐Model  Reviewer   •  Business  vision   •  Coding  standard   •  Product  Owner   •  •  Business-­‐Process  Analyst   Capsule  Designer   •  •  Change  request   Configura:on  audit  findings   workflow   •  Change  Control  Manager   •  Configura:on  management  plan   •  TDD   •  Team   •  •  Code  Reviewer   Configura:on  Manager   •  •  Data  model   Deployment  model   •  Collec:ve   •  Sprint  planning   •  Limit  WIP   •  •  Course  Developer   Database  Designer   •  •  Deployment  plan   Design  guidelines   ownership   mee:ng   •  Measure  and   •  Deployment  Manager   •  Design  model   •  Design  Reviewer   •  Development  case   •  Customer  tests   •  Daily  Scrum   op:mize  lead   •  Designer   •  Development-­‐organiza:on  assessment   •  Pair   •  Sprint  review   •  •  Graphic  Ar:st   Implementer   •  •  End-­‐user  support  mateirla   Glossary   :me   •  Integrator   •  Implementa:on  model   programming   •  Product  backlogt   •  Process  Engineer   •  Installa:on  ar:facts   •  Project  Manager   •  Integra:on  build  plan   •  Refactoring   •  Sprint  backlog   •  Project  Reviewer   •  Issues  list   •  Requirements  Reviewer   •  Itera:on  assessment   •  Planning  game   •  BUrndown  chart   •  •  Requirements  Specifier   So?ware  Architect   •  •  Itera:on  plan   Manual  styleguide   •  Con:nuous   •  Stakeholder   •  Programming  guidelines   •  System  Administrator   •  Quality  assurance  plan   integra:on   •  System  Analyst   •  Reference  architecture   •  Technical  Writer   •  Release  notes   •  Simple  design   •  •  Test  Analyst   Test  Designer   •  •  Requirements  aNributes   Requirements   •  Sustainable   Henrik Kniberg •  Test  Manager   management  plan   •  Tester   •  Review  record   pace   •  Tool  Specialist   •  Risk  list   •  User-­‐Interface  Designer   •  Risk  management  plan   •  Metaphor   •  Architectural  analysis   •  So?ware  architecture   •  Assess  Viability  of  architectural  proof-­‐ document   •  Small  releases   of-­‐concept   •  So?ware  development   •  Capsule  design   plan   •  Class  design   •  So?ware  requirements  specifica:on   •  Construct  architectural  proof-­‐of-­‐ •  Stakeholder  requests   concept   •  Status  assessment   •  Database  design   •  Supplementary  business  specifica:on   •  Describe  distribu:on   •  Supplementary  specifica:on   •  Describe  the  run-­‐:me  architecture   •  Target  organiza:on  assessment   •  Design  test  packages  and  classes   •  Test  automa:on  architecture   •  Develop  design  guidelines   •  Test  cases   •  Develop  programming  guidelines   •  Test  environment  configura:on   •  Iden:fy  design  elements   •  Test  evalua:on  summary   •  Iden:fy  design  mechanisms   •  Test  guidelines   •  Incorporate  design  elements   •  Test  ideas  list   •  Priori:ze  use  cases   •  Test  interface  specifica:on   •  Review  the  architecture   •  Test  plan   •  Review  the  design   •  Test  suite   •  Structure  the  implementa:on  model   •  Tool  guidelines   •  Subsystem  design   •  Training  materials   •  Use-­‐case  analysis   •  Use  case  model   •  Use-­‐case  design   •  Use  case  package   •  Analysis  model   •  Use-­‐case  modeling  guidelines   •  Architectural  proof-­‐of-­‐concept   •  Use-­‐case  realiza:on   •  Bill  of  materials   •  Use-­‐case  storyboard   •  Business  architecture  document   •  User-­‐interface  guidelines   •  Business  case   •  User-­‐interface  prototype   •  Business  glossary   •  Vision   •  Business  modeling  guidelines   •  Work  order   •  Business  object  model   •  Workload  analysis  model   •  Business  rules   •  Business  use  case  
  • 174. pra:che   principi  e  valori  
  • 176. Stacey Matrix Enterprise   Scrum   Development  
  • 177. Scrum  come  processo  empirico  
  • 178. Scrum | edificio Goal PRODUCT INSPECT ADAPT Principles Rules Roles Pillar Pillar Transparency Foundation
  • 181.           focalizzazione
  • 192. rispetto 192  
  • 195.           Q&A   195  
  • 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