Agile and Lean: dalla pratica alla teoria
0 likes347 views
Il documento discute l'applicazione dei principi Agile e Lean in un contesto reale, evidenziando case studies di successo e fallimento nella gestione dei progetti. Viene descritto come l'ottimizzazione del flusso di valore e la riduzione degli sprechi abbiano portato vantaggi significativi, inclusa una comunicazione efficace tra i team. Attraverso approcci iterativi e flessibilità, Funambol è riuscita a migliorare la soddisfazione dei clienti e a rispondere prontamente alle loro esigenze.
Agile and Lean: dalla pratica alla teoria
- 1. Agile and Lean: dalla pratica alla teoria
- 2. Funambol - www.funambol.com ● B2B2C white label cloud solution ● Platform for cloud services Francesco Mapelli - @mapelli ● Android Dev in Funambol ● Docente di Lean Development and Agile Methodologies all’ Universita dell’Insubria
- 6. Agenda ● Quella volta che… ○ L’UA team ha iniziato a committare sul trunk ○ Abbiamo deciso di fissare i bug immediatamente ○ Ci hanno chiesto una bicicletta e abbiamo consegnato un monopattino, facendoli felici ○ Abbiamo reso più flessibili i processi di un’altra azienda ● Quella volta che non... ○ Abbiamo lasciato le decisioni tecniche agli sviluppatori ○ Abbiamo chiacchierato abbastanza
- 7. Quella volta che L’UA team ha iniziato a committare sul trunk ● UA = User Advocate. Team che si occupa di usabilita’, coerenza dell’applicazione, definizione e discussione delle User Stories e dei dettagli ● Flusso di immagini e testi avanti e indietro tra UA - Designer - PO - Devs. ● Processo iterativo, coinvolge diversi team. E’ normale… ● … ma che noia!
- 8. Il flusso Product Owner User Advocate Tracking System Developer Product
- 9. E se l’UA team committasse sul trunk le risorse e le stringhe? Product Owner User Advocate Tracking System Developer Product …. Funziona benissimo!
- 10. Concetti di teoria Lean ● Value (valore) - tutto cio’ per cui il cliente e’ disposto a pagare ● Waste (spreco) - attivita’ che non produce valore Obiettivi: ● Eliminare gli sprechi (Defects, Overproduction, Transportation, Waiting, Inventory, Motion, Processing) ● Portare valore in mano al cliente il piu’ velocemente possibile facendo scorrere l’intero flusso del valore
- 11. Cosa abbiamo fatto in termini di principi lean e agili? ● Analizzato e ottimizzato il flusso di valore attraverso diversi gruppi ● Ridotto lo spreco eliminando attese, spostamento e il passaggio di consegne ● Ridotte le barriere e resi piu’ flessibili i ruoli e i compiti all’interno del team ● Incentivato lo scambio di competenze Product Owner User Advocate Tracking System Developer Product
- 12. Quella volta che abbiamo deciso di fissare i bugs immediatamente Approccio tradizionale: ● Periodo di bug fixing prima dei rilasci ○ Una feature con un bug trovato a inizio sviluppo e non fissato non e’ veramente finita fino a fine sviluppo ○ Bisogna lasciare un buffer… ma di quanto? ● Infinite bug review ● Bugs discussi, posticipati, ridiscussi, posticipati di nuovo ○ Questo e’ veramente fastidioso: continuano a tornare!
- 13. Bugs vs Mistake ● A bug is a unexpected behaviour given my current understanding and knowledge of the problem ○ Patologico! ● A mistake is a unplanned behaviour given my current understanding and knowledge of the problem ○ Fisiologico!
- 14. E se i bugs li fissassimo subito? ● I bugs sono inaccettabili, interveniamo immediatamente ● Ogni mattina facciamo review e prendiamo in carico i bugs il piu’ velocemente possibile
- 15. Cosa succede? ● Periodo di bug mistake fixing prima dei rilasci ridotto e piu’ prevedibile ● Features complete prima (senza bugs ancora da risolvere) ● Molte meno bug review ● Ri-discussione di bugs ridotta
- 16. Cosa abbiamo fatto dal punto di vista Agile e Lean? ● La lista di bugs e’ una coda! Le code sono sintomo di uno spreco ● I bugs sono in stato di attesa, l’attesa e’ un spreco ● Accettato User Stories piu’ velocemente (una US con un baco… la consideriamo veramente Done?) ● Messo piu’ velocemente valore nel prodotto
- 17. Quella volta che ci hanno chiesto una bicicletta e li abbiamo fatti felici con un monopattino Funambol System Integrator Cliente Cliente Cliente Cliente
- 18. Quella volta che ci hanno chiesto una bicicletta e li abbiamo fatti felici con un monopattino ● Cliente molto importante, inaspettatamente molto insoddisfatto ed ostile, ci ha chiesto modifiche notevoli in pochissimo tempo, minacciando di andare dalla concorrenza se non fosse stato soddisfatto ● Impossibile soddisfarlo appieno nei tempi richiesti ● Roadmap da cambiare ● Come farli felici senza fare le cose che ci chiedevano?
- 19. Cosa abbiamo fatto (1) ● Identificato insieme al cliente le feature piu’ importanti ● Proposto approccio iterativo, consegnando subito le feature a piu’ alta priorita’ e pianificando per release successive le feature a priorita’ minore ● Ridotto i tempi di release
- 20. Cosa abbiamo fatto (2) ● System integrator fisicamente in ufficio da noi per la seconda meta’ del ciclo di release (1 mese, dal Sud America) ● Collaborazione e interazione costante
- 21. Risultato ● Consegnato molto velocemente la prima release, che conteneva le feature fondamentali per il cliente ● Il cliente ha smesso di essere ostile non appena ha ricevuto le feature piu’ importanti ● La pressione e’ immediatamente diminuita ● Abbiamo potuto ridiscutere tempi e feature delle versioni successive in modo piu’ sereno e produttivo
- 22. Non c’era bisogno di una bicicletta immediatamente
- 23. In termini di Agile e Lean ● Customer collaboration over contract negotiation ● Responding to change over following a plan ● Abbiamo consegnato il valore in mano al cliente il piu’ velocemente possibile ● Evitato overproduction (extra features)
- 24. Quella volta che abbiamo reso i piu’ flessibili i processi di un’altra azienda Partner Funambol Cliente
- 25. Quella volta che abbiamo reso i piu’ flessibili i processi di un’altra azienda ● Cliente vuole una soluzione SIM - Cloud ● Partner fornisce la parte di interazione sulla SIM, Funambol il servizio Cloud
- 26. Differenti approcci Funambol ● Definizione dei flussi di massima ● I dettagli tecnici e le specifiche implementative le definiamo iterativamente ● Iniziamo lo sviluppo immediatamente ● Incontri periodici per risolvere i dubbi e le sfide che vengono fuori durante lo sviluppo Partner ● Definizione dei flussi precisa ● I dettagli tecnici e le specifiche implementative chiaramente definite ● Criteri di acceptance definiti ● Sviluppo inizia dopo che tutto questo e’ stato scritto e firmato
- 27. Timeline ● Customer vuole soluzione in mano per fine Novembre ● A spanne, 2 mesi di sviluppo ● Primi contatti a settembre, kick off a inizio Ottobre. ● Partner voleva tutto definito poco dopo il kick off… ma la realta’ non era d’accordo: i dettagli non sono tutt’ora completamente definiti.
- 28. Cos’e’ successo? ● Funambol ha aiutato il partner ad accettare processi piu’ flessibili e abbandonare almeno in parte l’approccio piu rigido ● Il progetto e’ in corso e la definizione degli aspetti tecnici specifici viene fatta mano a mano che si rende necessaria ● Va tutto bene
- 29. In termini teorici Agile + Scrum ● Iteriamo su definizione requirement, soluzione dei dubbi, design e implementazione e periodicamente definiamo gli step successivi Waterfall ● Analyze requirements ● Design ● Build ● Verify ● Maintain
- 30. Quella volta che non abbiamo lasciato le decisioni tecniche agli sviluppatori ● Incontro a livello business discute come procedere con il prodotto nella nuova release ● Vengono identificate esigenze dell’utente finale ● Viene deciso come soddisfarle tramite una certa feature ● Viene deciso come some sviluppare la nuova feature e il flusso nell’applicazione ● Viene concordato che Funambol sviluppera’ sulla base di un SDK sviluppato da terza parte per conto di Customer
- 31. Quella volta che non abbiamo lasciato le decisioni tecniche agli sviluppatori Business Devs Business Devs
- 32. Cosa e’ successo? ● La feature come disegnata al livello business era molto piu’ complessa di quanto stimato ● Al team che sviluppa l’SDK vine chiesto di fare qualcosa che non e’ quello che serve al team Funambol ● Grosse incomprensioni tra le parti ● Alla fine la feature viene sviluppata con funzionalita’ limitate ma costi molto piu’ elevati del previsto
- 33. Dal punto di vista teorico quali principi non abbiamo seguito? ● Business people and developers must work together daily throughout the project. ● The best architectures, requirements, and designs emerge from self-organizing teams.
- 34. Quella volta che non abbiamo chiacchierato abbastanza ● Vogliamo mostrare l’intervallo di date di una collezione di foto ● User Story viene scritta chiaramente con buon livello di dettaglio e criteri di acceptance ● Inizia lo sviluppo, assegnato a dev junior
- 35. Cosa succede? ● Vengono trovati alcuni corner cases, aggiunti dettagli e gestione dei casi non coperti inizialmente ● Trovati alcuni bugs ● … ● Sviluppo e complessita’ crescono: vengono mandate mail e fatte riunioni su come risolvere i vari casi ● … ● Alla fine un altro sviluppatore interviene e ridiscute alcuni aspetti della User story. Ne abbatte la complessita’, propone e implementa soluzione alternativa. In meno di un’ora.
- 36. Dal punto di vista teorico cosa non abbiamo fatto? ● Card, Conversation, Confirmation ● Simplicity--the art of maximizing the amount of work not done--is essential. ● The best architectures, requirements, and designs emerge from self-organizing teams.
- 37. Domande? grazie!
- 38. Riferimenti, link ecc. ● http://agilemanifesto.org/ Agile Manifesto ● https://bugfreedevelopment.wordpress.com/ Bug Free Development, distinzione tra Bugs e Mistake ● https://www.mountaingoatsoftware.com/ Mountain Goat Software ● Lean Thinking - Womack, Jones - Guerini e Associati