Il tuo team "agile" scrive codice "flaccido"? Forse scrum non basta
•
0 likes•173 views
Essere agli vuol dire adattarsi velocemente ai cambiamenti che il mondo esterno ci impone. Scrum ti consente di cambiare velocemente le priorità, modificare velocemente i tuoi requisiti di business e migliorare i tuoi processi, ma il sw che stai scrivendo è altrettanto “adattivo” e in grado di accogliere i cambiamenti? Se così non fosse presto la tua “agilità” verrà ostacolata dalla “flaccidità” del tuo codice e dovrai porvi rimedio. Vedremo insieme come accorgersene il prima possibile e quali misure adottare.
Recommended
More Related Content
Similar to Il tuo team "agile" scrive codice "flaccido"? Forse scrum non basta
Similar to Il tuo team "agile" scrive codice "flaccido"? Forse scrum non basta (20)
More from Stefano Muro
More from Stefano Muro (7)
Il tuo team "agile" scrive codice "flaccido"? Forse scrum non basta
- 1. Il tuoteamagilescrivecodice “flaccido”? Quando Scrum non è sufficiente Stefano.muro@inspearit.com @stefanoMuro stefano_muro https://www.linkedin.com/in/stefanomuro/ Stefano Muro
- 2. Versioneone 12° State of Agile Report
- 4. PerchèScrum? E’ semplice Consente di rilasciare valore per l’utente molto presto Implementa cicli di feedback sul prodotto che consentono di rilasciare valore con continuità Implementa cicli di feedback sul processo consentendo di aumentare la produttività del team tramite collaborazione e miglioramento continuo.
- 5. Scrum è sufficiente? 5 Realizzare qualcosa di utile per l’utente Realizzare SW presto e con continuità Realizzare SW funzionante Realizzare SW che supporti i cambiamenti
- 6. Scrum è sufficiente? 6 Dove spendete più tempo? Correggendo bug Aggiungendo funzionalità Che dite quando vi chiedono una modifica? Acciderbolina! Si romperà tutto! «Tuttapposto», devo solo cambiare un po’ il design Quanto è complicata la vostra codebase attuale? Non ne ho la minima idea E’ ampia ma facile da capire e cambiarla non è un problema
- 7. Scrum è sufficiente? Vi racconto qualche aneddoto 7
- 10. 10 Il simulator
- 11. Spenderepoconon vuoldirespendere poconellosviluppo ….They piled story on story as quickly as possible with the least possible investment in design. Without daily attention to design, the cost of changes does skyrocket. The result is poorly designed, brittle, hard-to-change systems.” ― Kent Beck, Extreme Programming Explained: Embrace Change
- 12. Scrum non è sufficiente Se il nostro team è Agileanche il nostro codice lo deve essere! Talvolta invece scriviamo codice
- 13. Come èfatto un codice “Flaccido” Ha molti difetti (anche noti) rilasciati in produzione 1 Non è manutenibile: E’ difficile individuare l’origine di un difetto perchè il codice non è leggibile o non se ne capisce l’intent.Spesso risolvere un difetto vuol dire crearne un altro. 2 Non è estensibile: E’ difficile estendere le funzionalità di un’applicazione se non è modulare, flessibile e utilizza design pattern riconoscilbili. 3
- 15. Sintomi tipici di un codice “flaccido” Rigidità Fragilità Immobilità Viscosità Inutile complessità Inutili ripetizioni Opacità Robert C. Martin «Design principles and Design Patterns»
- 17. Legge della complessità crescente di Lehman La struttura di un sistema che evolve si deteriora man mano che cambia, e devono essere spese risorse aggiuntive per preservarne la funzione e semplificarne la struttura
- 18. CostodelcambiamentodelSWtradizionale Equazione di Lehman e Belady: M= p+ K c-d M= sforzo di manutenzione, p= sforzo di sviluppo totale, c = complessità causata dalla mancanza di strutturazione (leggi: debito tecnico), d = grado di familiarità del team di manutenzione col software. K è una costante da individuare confrontando il modello con i dati reali,
- 19. Costo del cambiamento applicando pratiche agili di sviluppo SW
- 21. Come? Adottando pratiche che consentono di: Realizzare e mantenere nel tempo un buon Design Individuare i bug molto presto nel ciclo di vita del SW
- 23. Riprendiamo alcune pratiche XP Pair Programming Test Driven Development Continuous Integration Design Improvement Collective Code Ownership Simple Design
- 24. Le pratiche sono utili ma quello che guida le pratiche sono i principi
- 25. Principi fondamentali XP Rapid Feedback Assume Simplicity Incremental Change Embracing Change Quality Work
- 26. Grazie ai principi le pratiche si evolvono 26
- 27. Richiede lavoroe tempo:come conciliarloconla delivery? Rendersi conto che è un investimento che si ripaga nel tempo. Ritagliari tempo per allenarsi Sperimentando pratiche un po’ alla volta. Condividendo.
- 29. Perchè Agile? Versioneone 12° State of Agile Report
- 30. Perchè Agile? Versioneone 12° State of Agile Report
- 31. Valori XP Feedback Respect Communication Simplicity Courage