Back to Agile - Codemotion 2013

2,931 views

Published on

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.

Published in: Business
3 Comments
21 Likes
Statistics
Notes
No Downloads
Views
Total views
2,931
On SlideShare
0
From Embeds
0
Number of Embeds
77
Actions
Shares
0
Downloads
0
Comments
3
Likes
21
Embeds 0
No embeds

No notes for slide

Back to Agile - Codemotion 2013

  1. 1. Incidente  minerario  a  Quecreek  2002    
  2. 2. Incidente  minerario  a  Quecreek  2002    
  3. 3. valori e principi alla base delle metodologie Lean e Agili
  4. 4. Chi sono•  Fabio Armani –  CEO di OpenWare –  Direttore artistico dell’etichetta Different Lands –  Certified Scrum Master Certified Scrum Professional, PMI-ACP, PSM I
  5. 5. di cosa parliamo?  
  6. 6.     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  
  7. 7.      campi di applicazione
  8. 8.     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  
  9. 9.      benefici 10  
  10. 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 dellimpegno e partecipazione delle persone, del loro senso di responsabilità e del grado di soddisfazione •  Migliore qualità del software 11  
  11. 11. punti di attenzione 12  
  12. 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  
  13. 13. il  passaggio  è  semplice?   14  
  14. 14.   Il passaggio allAgile è impegnativo sia per gli sviluppatori sia per   il resto dellorganizzazione.   Non si tratta della semplice applicazione di norme, quanto piuttosto di un cambiamento culturale. Lerrore 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  
  15. 15. Tempi   16  
  16. 16.    Il processo di trasformazione agile di un azienda avviene in modoincrementale ed iterativo adottando una metodologia agile ancheper guidare l’azienda nel processo di trasformazione stesso.Il processo di transizione richiede in media da un anno a tre anni perraggiungere un elevato grado di maturità, in funzione del contestospecifico.Normalmente dopo circa 6 mesi è già possibile rilevare i primi risultatisignificativi. 17  
  17. 17. false dicotomie  
  18. 18. false dicotomie
  19. 19. agilità   24  
  20. 20. disciplina   25  
  21. 21. disciplina   26  
  22. 22. agilità   27  
  23. 23.   •  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  
  24. 24. con:nuum   dettaglio investimento modellazionedocumentazione
  25. 25. AgilePra$che  Agili  Principi  Agili   Valori  Agili   Necessità  di  rispondere  al  cambiamento   con:nuo  
  26. 26. AgilePra$che  Agili  Principi  Agili   Valori  Agili   Necessità  di  rispondere  al  cambiamento   con:nuo  
  27. 27. AgilePra$che  Agili  Principi  Agili   Valori  Agili   Necessità  di  rispondere  al  cambiamento   con:nuo  
  28. 28. AgilePra$che  Agili  Principi  Agili   Valori  Agili   Necessità  di  rispondere  al  cambiamento   con:nuo  
  29. 29. valori  agili   37  
  30. 30. 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/  
  31. 31. Firmatari  del  Manifesto  Agile  
  32. 32. La nostra massima priorità è soddisfare il clienterilasciando software di valore, fin da subito e in maniera continua
  33. 33. Accogliamo i cambiamenti nei requisiti, anche a stadi avanzati dello sviluppo. I processi agili sfruttano il cambiamentoa favore del vantaggio competitivo del cliente.
  34. 34. Consegnamo frequentemente software funzionante,con cadenza variabile da un paio di settimane a un paio di mesi, preferendo i periodi brevi.
  35. 35. Committenti e sviluppatori devono lavorare insiemequotidianamente per tutta la durata del progetto.
  36. 36. Fondiamo i progetti su individui motivati. Diamo loro lambiente e il supporto di cui hanno bisognoe confidiamo nella loro capacità di portare il lavoro a termine.
  37. 37. Una conversazione faccia a facciaè il modo più efficiente e più efficace per comunicare con il team ed allinterno del team.
  38. 38. Il software funzionante è il principale metro di misura di progresso.
  39. 39. I processi agili promuovono uno sviluppo sostenibile.Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere indefinitamente un ritmo costante.
  40. 40. La continua attenzione alleccellenza tecnicae alla buona progettazione esaltano lagilità.
  41. 41. La semplicità - larte di massimizzare la quantità di lavoro non svolto - è essenziale.
  42. 42. Le architetture, i requisiti e la progettazione migliori emergono da team che si auto- organizzano.
  43. 43. A intervalli regolari il team riflette su comediventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza.
  44. 44. Why?Agile è importante
  45. 45. Why?Agile è importante
  46. 46. Processo predeterminato
  47. 47. Processo predeterminato
  48. 48. Processo predeterminato
  49. 49. Framework sistemico creato da Dave Snowden
  50. 50. Cynefin Framework
  51. 51. Cynefin Framework
  52. 52. Cynefin Framework
  53. 53. Cynefin Framework
  54. 54. Cynefin Framework
  55. 55. waterfall  
  56. 56. Tradizionale  
  57. 57. Tradizionale  
  58. 58. Tradizionale  
  59. 59. Tradizionale  
  60. 60. agile  
  61. 61. Tradizionale  Agile  
  62. 62. Tradizionale  Agile  
  63. 63. Tradizionale  Agile  
  64. 64. Tradizionale  Agile  
  65. 65. ?Qual’è il valore per i nostri stakeholder?
  66. 66. Compariamolo con lo sviluppo tradizionale Visibilità   AdaNabilità   Business  Value   Rischi   Sviluppo  Agile   Sviluppo  Tradizionale  
  67. 67. 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
  68. 68. lasciare che le cose evolvano
  69. 69. lasciare che le cose evolvano
  70. 70. prendere piccole decisioni•  Muoversi rapidamente•  Procedere in avanti•  Reversibile•  Ultimo momento responsabile quando ulteriori informazioni sono disponibili
  71. 71. outside  »  in  
  72. 72. 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
  73. 73. pensare in grande iniziare in piccolo
  74. 74. 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
  75. 75. Agile checkpoints
  76. 76. Flusso Agile
  77. 77. Where Are We with Agility? The  CHAOS  Manifesto,  Copyright  2011  
  78. 78. Lean Thinking, Principi e Discipline
  79. 79. Lean is a philosophy of work that seeks perfection.
  80. 80. Lean is a system, that seekreducing the time from order to cash.
  81. 81. Lean Key ConceptsMURI MURA MUDA
  82. 82. (muri)
  83. 83.  
  84. 84. non  sovraccaricare  i  processi  
  85. 85. (mura)
  86. 86. mantenere  il  flusso  regolare  e  costante  
  87. 87. (muda)
  88. 88. rimuovere   aGvità   che  non  aggiungono  valore  
  89. 89. Applicare i concetti lean allo sviluppo softwareVALORI LEAN
  90. 90. Lean| pilastri Goal Delivery PEOPLE KAIZEN Pillar Pillar Lean Thinking Foundation
  91. 91. Rispettare le persone
  92. 92. Respect People
  93. 93. Kaizen
  94. 94. Applicare i concetti lean allo sviluppo softwarePRINCIPI LEAN
  95. 95. Eliminate waste
  96. 96. Forms  of  waste   in  so?ware?  
  97. 97. 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
  98. 98. Eliminate Waste | in software?•  Provide market and technical leadership•  Creating nothing but value•  Write less code
  99. 99. 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.
  100. 100. Amplify learning
  101. 101. Create  knowledge   amplify  learning  
  102. 102. 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
  103. 103. Defer commitment
  104. 104. Defer  commitment   decide  as  late  as  possible  
  105. 105. 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
  106. 106. Defer Commitment | decide as late as possible
  107. 107. Deliver fast
  108. 108. Deliver  as  fast   as  possible  
  109. 109. Learn  as  fast   as  possible  
  110. 110. Deliver fast | learn as fast as possible•  Work in small batches•  Focus on cycle time, not utilization
  111. 111. 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.
  112. 112. Empower the team
  113. 113. Respect  people   empower  the  team  
  114. 114. Respect people | empower the team•  Train team leaders/supervisors•  More responsibility and decision making to the lower possible level•  Foster pride in workmanship
  115. 115. 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.
  116. 116. Build integrity in
  117. 117. Build  integrity  in   intrinsic  quality  
  118. 118. Build  integrity  in   intrinsic  quality  
  119. 119. Build Quality In | do it right the first time•  Synchronize•  Automate•  Refactor
  120. 120. 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
  121. 121. See the whole
  122. 122. Op:mize  the  whole   improve  the  system  
  123. 123. 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.
  124. 124. Declinate nelle diverse metodologie
  125. 125. Crystal   Clear   DSDM  Scrum   AgileUP   eXtreme   Kanban   Programming   Feature  Driven   Lean   Development   Development  
  126. 126. Quale metodologia? Metodologie  29%   49%   Scrum   Scrum/XP  Hibrid   22%   All  Others  
  127. 127. MetodologieMetodologia   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%  
  128. 128. Confronto per capire non per giudicarePiù  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  
  129. 129. pra:che   principi  e  valori  
  130. 130. Introduzione al framework
  131. 131. Stacey Matrix Enterprise   Scrum   Development  
  132. 132. Scrum  come  processo  empirico  
  133. 133. Scrum | edificio Goal PRODUCT INSPECT ADAPT Principles Rules Roles Pillar Pillar Transparency Foundation
  134. 134. impegno
  135. 135.          focalizzazione
  136. 136. apertura
  137. 137. coraggio
  138. 138. rispetto
  139. 139. high performance tree
  140. 140. comunicazione
  141. 141. semplicità
  142. 142. coraggio
  143. 143. feedback
  144. 144. rispetto 192  
  145. 145. high performance tree
  146. 146.           Q&A   195  
  147. 147. BibliografiaMetodologie Lean Agile (2010) i
  148. 148. 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)
  149. 149. 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)
  150. 150. 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)
  151. 151. 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)
  152. 152. 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)
  153. 153. 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)
  154. 154. XP » bibliografia•  eXtreme Programming Explained » Kent Beck•  Planning eXtreme Programming » Kent Beck, Martin Fowler•  eXtreme Programming Installed » Ron Jeffries, Ann Anderson, Chet Hendrickson
  155. 155. Grazie–  CEO di OpenWare–  Direttore artistico dell’etichetta Different Lands–  Certified ScrumMaster & Scrum Professional–  PMI-ACP Certified–  @fabioarmani–  www.open-ware.org
  156. 156. Disclaimer

×