Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Dimitri favre #noprojects - Modern software development focuses on Teams and Products

130 Aufrufe

Veröffentlicht am

Lo sviluppo del software moderno e agile può fare a meno dei progetti? Quali sono le disfunzioni del modo di pensare orientato ai progetti?
Queste le slide del mio intervento ad Agile Venture Milano 2019

Veröffentlicht in: Präsentationen & Vorträge
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Dimitri favre #noprojects - Modern software development focuses on Teams and Products

  1. 1. https://www.linkedin.com/in/dimitri-favre-088675/ @DimitriFavre Dimitri Favre #noprojects Modern software development focuses on Teams and Products 26 gennaio 2019
  2. 2. Inspirato al lavoro di Allan Kelly, Shane Estie, Evan Leybourn e altri
  3. 3. Inspirato al lavoro di Allan Kelly, Shane Estie, Evan Leybourn e altri e alla mia esperienza personale
  4. 4. Siamo così abituati al concetto di progetto che diamo per scontata la sua presenza nella nostra vita
  5. 5. Cos’è un progetto?
  6. 6. Un progetto è un sforzo temporaneo intrapreso al fine di creare un prodotto, servizio o risultato unico. Source: What is Project Management, PMI - https://www.pmi.org/about/learn-about-pmi/what-is-project-management
  7. 7. «Software is eating the world» Marc Andreessen, 2011 Why Software is eating the world http://www.wsj.com/articles/SB10001424053111903480904576512250915629460
  8. 8. Non stiamo semplicemente facendo software. Stiamo facendo prodotti software
  9. 9. prodotto: ciò che costituisce il risultato di un processo naturale o di un’operazione umana
  10. 10. La mentalità orientata al progetto (o modello a progetto) è un fattore di inibizione dell’agilità
  11. 11. Stiamo (ancora) scoprendo modi migliori di creare software facendolo ed aiutando altri a farlo Agile Manifesto, 2001
  12. 12. Si è creato il il ruolo di PRODUCT Owner
  13. 13. Ma avete mai sentito parlare di Project Owner?
  14. 14. Si vendono progetti con la massima nonchalance. Ma voi comprereste un progetto?
  15. 15. I want to stress is the importance of getting rid of software projects as a notion. Instead we want to switch to a product-oriented view of the world where instead of projects that you spin up, run for a while and then stop; you instead say, "Let's focus on things that are much more long-lasting and organize a product team around that.“ Martin Fowler, «The State of Agile», August 2018
  16. 16. Ho alcuni personalissimi problemi con il modello a progetto (e qualche suggerimento per mitigarli)
  17. 17. Non è il progetto per sé E’ la mentalità orientata al progetto
  18. 18. Un progetto è un sforzo temporaneo intrapreso al fine di creare un prodotto, servizio o risultato unico. Source: What is Project Management, PMI - https://www.pmi.org/about/learn-about-pmi/what-is-project-management
  19. 19. Bruce Tuckman, 1965
  20. 20. Bruce Tuckman, 1965 Fine del progetto Disfiamo il team Creeremo un team nuovo di zecca se e quando ci sarà un progetto su cui farlo lavorare
  21. 21. E mentre si celebra il successo del progetto, il valore del team viene distrutto per effetto del suo smantellamento
  22. 22. Focus on teams
  23. 23. Un team che gestisce più prodotti è molto meglio di tanti piccoli team usa e getta creati e disfatti ad hoc in funzione dei progetti
  24. 24. Gestite un team backlog (attraverso un team Products Owner)
  25. 25. Non è una questione di felicità E’ anche una questione economica (e comunque i soldi non comprano la felicità)
  26. 26. I prodotti software sono per sempre (più o meno) ed evolvono continuamente
  27. 27. Perché diavolo dovremmo gestire una cosa che vive a lungo e cambia continuamente nel tempo con una cosa effimera chiamata progetto?
  28. 28. Il progetto è temporaneo. Di conseguenza ha un inizio
  29. 29. … e una fine (beh, non proprio tutti)
  30. 30. Il super domandone: Quando inizia un progetto?
  31. 31. Alla fine della fiera, il successo di un progetto è tipicamente dettato dalla soddisfazione dei soliti tre elementi: - On time (schedule) - On budget - On scope (Scusate i bullet point)
  32. 32. Dov’è il valore per il cliente? E la qualità?
  33. 33. Il successo del progetto è valutato sulle cose sbagliate (ciò che si può misurare invece che ciò che produce valore)
  34. 34. L’obiettivo è quello di creare valore, per il cliente, per l’organizzazione e per la società nel suo complesso
  35. 35. Invece di chiedersi “Quanto costa?” chiediamoci “Quanto vale?”
  36. 36. Cosa succede quando il progetto finisce?
  37. 37. Generalmente abbiamo due possibilità: - Il progetto viene esteso - Passaggio di consegne (Scusate i bullet point)
  38. 38. Estendere un progetto significa elemosinare un extra budget (e far partire un nuovo progetto)
  39. 39. I prodotti vivi hanno tipicamente una lunga lista di bisogni che aspettano di essere risolti (e nuovi bisogni arrivano in continuazione durante la vita del prodotto)
  40. 40. Per dire… Non abbiate paura di avere team e persone non allocate Non lo saranno
  41. 41. L’AMS è la casa di riposo dei prodotti software
  42. 42. Dove risiedono fino a quando non sono dichiarati ufficialmente morti dismessi
  43. 43. La manutenzione dovrebbe essere uno stato transitorio in attesa del prossimo step evolutivo Source: By Dzonatas - Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=4376189
  44. 44. I conflitti di interessi tra chi sviluppa e chi gestisce il supporto
  45. 45. Squadre di serie A VS Squadre di serie B
  46. 46. L’handover è uno spreco
  47. 47. E per dirla tutta: Non c’è miglior posto per fare la manutenzione di un prodotto software se non il team che l’ha realizzato
  48. 48. In un mondo in cui l’IT è un centro di costo, i progetti (anche quelli agili) vengono costruiti intorno ai silos aziendali
  49. 49. L’ottimizzazione locale prevale sul pensiero sistemico La conseguenza è che anziché produrre valore per il cliente, si finisce per creare sistemi ridondanti e di complessità crescente
  50. 50. I silos aziendali combattono per ottenere budget sulla base del costo (e dell’ottimizzazione dei costi)
  51. 51. The Black Friday syndrome
  52. 52. Probabilmente non sarete in grado di abbattere i silo organizzativi, ma potete fare qualcosa per mitigarne gli effetti nel software che implementerete
  53. 53. Siate lean
  54. 54. Siate lean adottando un pensiero sistemico e lavorando sull’ottimizzazione globale
  55. 55. Siate lean nella gestione del portfolio delle iniziative (potreste prendere spunto da quella che probabilmente è la miglior parte di SAFe)
  56. 56. Agile e Progetto nella stessa frase sono un ossimoro
  57. 57. Ooops
  58. 58. Previsioni e budget sono generalmente definiti sulla lista di requisiti che poi diventeranno le fondamenta del progetto
  59. 59. Il che porta a contratti blindati sui requisiti
  60. 60. #noproject world Un mondo senza progetti
  61. 61. La perfezione non si ottiene quando non c'è più nulla da aggiungere, bensì quando non c'è più nulla da togliere Antoine de Saint-Exupéry
  62. 62. Oggigiorno tutto è continuo
  63. 63. Continuous Improvement
  64. 64. Continuous Integration
  65. 65. Continuous Delivery
  66. 66. Continuous Release
  67. 67. Continuous Learning
  68. 68. Ma non si è mai sentito parlare di Continuous Project
  69. 69. Lo sviluppo agile di software dovrebbe abbandonare il concetto di progetto e la sua eredità (e il suo gergo)
  70. 70. Concentrate i vostri sforzi sull’evoluzione del portfolio di soluzioni e prodotti
  71. 71. … portate il lavoro verso i team (stabili) e gestite le priorità
  72. 72. … e scalate se e quando necessario
  73. 73. Validate e prioritizzate continuamente le iniziative in modo da massimizzare il valore
  74. 74. Finanziate la capacity anziché lo scope
  75. 75. Gestite le iniziative come esperimenti
  76. 76. Attraverso un ciclo di feedback breve
  77. 77. In altre parole, sperimentate continuamente
  78. 78. Quando un progetto non raggiunge gli obiettivi è un fallimento
  79. 79. Quando un esperimento fallisce è un momento di apprendimento
  80. 80. Non importa quanto sia bella la vostra teoria, né quanto siate in gamba. Se la vostra teoria non è confermata da un esperimento, è sbagliata. Questa è la scienza Richard Feynman, Cornell University Lecture, 1964
  81. 81. #noprojects manifesto Experiments over instead of Projects
  82. 82. WARNING #noprojects è dire no ai progetti
  83. 83. C’è spazio per i progetti nell’IT (e a volte anche per il software)
  84. 84. In alcuni casi il modello a progetti è ancora la scelta migliore
  85. 85. Per tutto il resto ci sono Prodotti, Teams and #noprojects
  86. 86. References
  87. 87. Project Myopia: Why projects damage software #NoProjects Allan Kelly, 2018
  88. 88. Continuous Digital: An agile alternative to projects for digital business Allan Kelly, 2018
  89. 89. #noprojects: A Culture of Continuous Value Evan Leybourn, Shane Estie, 2018
  90. 90. Company-Wide Agility with Beyond Budgeting, Open Space & Sociocracy Jutta Eckstein, 2018
  91. 91. Agendashift Outcome-oriented change and continuous transformation Mike Burrows, 2018
  92. 92. https://www.linkedin.com/in/dimitri-favre-088675/ @DimitriFavre Dimitri Favre Grazie
  93. 93. Domande?

×