Agile and Lean: dalla pratica alla teoria

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

Teoria della teoria

4

5

6

1

3

2

Bellissima Teoria

Pratica della teoria

Formula Magica

??? ???

A new hope

Teoria

Quella volta che...

Allora forse...

Quella volta che...

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

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!

Il flusso

Product Owner User Advocate Tracking System Developer Product

E se l’UA team committasse sul trunk le risorse e le stringhe?

Product Owner User Advocate Tracking System Developer Product

…. Funziona benissimo!

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

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

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!

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!

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

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

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

Quella volta che ci hanno chiesto una bicicletta e li abbiamo fatti felici con un monopattino

Funambol System Integrator

Cliente

Cliente

Cliente

Cliente

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?

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

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

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

Non c’era bisogno di una bicicletta immediatamente

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)

Quella volta che abbiamo reso i piu’ flessibili i processi di un’altra azienda

Partner Funambol Cliente

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

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

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.

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

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

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

Quella volta che non abbiamo lasciato le decisioni tecniche agli sviluppatori

Business

Devs

Business

Devs

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

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.

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

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.

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.

Domande?grazie!

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