OptionFactory

No Silver BulletDiventare agili non è banale, nè scontato

Presentazioni

● Francesco Degrassi○ Sviluppatore software, coordinatore, consulente○ Attivo nell’ambito dello sviluppo lean e agile da una decina d’anni

● OptionFactory○ Sviluppo software con approccio lean

■ High availability, performance, scaling, security○ Supporto operativo alle aziende che sviluppano o fanno sviluppare

■ assessment, consulenza, formazione○ Piccole, medie e grandi aziende, italiane ed estere

Agile è fuori moda

● Siamo oltre il picco di interesse

● Molti l’hanno provato

● Non è più un tratto distintivo○ neppure in Italia

...ma il plateau di produttività è lontano

● Contrariamente ad altre metodi / approcci / tecnologie○ E’ ancora molto controverso○ Opinioni molto polarizzate○ Nessun consenso sulla sua validità e applicabilità

● Uno dei fattori è quello delle aspettative○ non tanto esagerate, quanto errate

Non un proiettile d’argento, quanto una strategia con precisi trade-off che richiede capacità non banali

Agile Manifesto● Un set condiviso di principi guida per un modo “migliore” di sviluppare● Nel tempo vi si sono associati

○ pratiche○ strumenti○ metodologie, nuove ed esistenti

Principi e pratiche universali● automazione dei processi ripetitivi, non di concetto

○ maggiore velocità, meno sprechi, meno errori● pairing

○ resilienza, meno errori● esplicitazione e discussione del valore

○ chiarezza, maggiori opportunità di massimizzazione● testing pragmatico, automatico, durante lo sviluppo● passo sostenibile● refactoring● ...

Agile Software Development Manifesto

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaborationover contract negotiation

Responding to changeover following a plan

Un approccio agile privilegia alcuni aspetti su altri allo scopo di ottenere un risultato netto migliore

in uno specifico contesto.

Trade-off: Latenza / Throughput

Never underestimate the bandwidth of a station

wagon full of tapes hurtling down the highway.

–Andrew Tanenbaum, 1981

Trade-off: Latenza / Throughput● Assunzione

○ ci sono assunzioni da validare e molto da imparare○ molte delle feature realizzate non saranno usate o andranno cambiate

● Sviluppo iterativo, per avere feedback più frequente○ scrum

● team cross-funzionali, per evitare colli di bottiglia● Simple design, YAGNI● Value stream mapping● kanban board● “See the whole”, System Thinking

Trade-off: Flessibilità / Uniformità● Assunzione

○ Soluzioni non standardizzate● Team cross-funzionali, per minimizzare le dipendenze esterne● DevOps, per integrare elementi di operations nello sviluppo della soluzione

Trade-off: Reattività / Controllo ● Assunzione

○ Il personale sul campo ha (o può avere) il set di informazioni più completo e la capacità per prendere decisioni

● Decentralizzazione delle decisioni○ Team auto-organizzati○ Empower the team

Trade-off: Collaborazione / Tutela● Assunzione

○ C’è modo di allineare gli obiettivi delle parti e condividere il rischio● Trasparenza, partecipazione e visibilità nel processo● Contratti cosiddetti “agili”

○ incrementali○ revenue sharing○ clausole di bail-out

Appropriatezza al contesto - 1Più appropriato Dimensione Meno appropriato

Differenziato Tipo di mercato Indifferenziato, commoditizzato

Ridotte Dimensioni Ampie

Flessibile Processo* Regolamentato

Distribuita Distribuzione della conoscenza

Centralizzata

Alta Trasparenza in azienda Bassa

Performance orientedMessengers trained

Cultura aziendale Rule / Power orientedMessenger neglected / messenger shot

Appropriatezza al contesto - 2Più appropriato Dimensione Meno appropriato

Colocato Distribuzione del personale Distribuito

FacileCliente interno, accesso all’utente finale

Facilità di ottenere feedback DifficileIntermediari, subappalti, ambienti militari

Interno TIpologia di cliente* Esterno

Alto Allineamento degli obiettivi tra cliente e fornitore

Basso

Incertiservizio innovativo verso il pubblico

Certezza dei requisiti Certimodulo di integrazione tra prodotti di mercato

Instabilipiattaforma di HFT

Stabilità dei requisiti Stabili

Appropriatezza al contesto - 3Più appropriato Dimensione Meno appropriato

Nuovo, da esplorare Stack tecnologico* Noto, stabile

MinimiWeb application, SaaS

Vincoli di deployment SignificativiAppliance, embedded, ambienti militari

RidottoSaaS

Numero di installazioni ElevatoApplicazioni mobile*

Capabilities per un approccio agile● Competenza tecnica, gli errori si pagano e rallentano● Responsabilità e autonomia, per le decisioni decentralizzate● Attrazione, selezione del personale (e retention!)● Comunicazione efficace, sia orizzontale e verticale● Rapporto positivo e trasparente con il cliente

Diverse, non necessariamente superiori, ad approcci di altro tipo.

Metodologie● Framework / template di processo con annessi ruoli, pratiche, strumenti

● Guidano nel mettere in pratica principi e valori

● Principi e valori, sempre al primo posto

● Rischioso se calate dall’alto (“Make us agile!”)

● Vanno adattate se limitanti

● Shu in Shu-Ha-Ri

Problemi comuni● Metodologia come Il Processo, o

anche best practice● Metodologia per imbrigliare gli

elementi più disruptive

● Scrum come “Agile with control”○ Un ossimoro

Cynefin Framework

Pratiche - Daily standup● Obiettivi:

○ comunicazione ed allineamento nel team○ spinge le persone ad identificare e affrontare gli impedimenti

● Rischi:○ semplice reporting○ meccanismo di controllo○ sit-down meeting

● Altre opzioni:○ comunicazione costante ed informale tramite colocazione / chatter○ Ad-hoc standup

Pratiche - Kanban board● Obiettivi:

○ visualizzazione del work in progress○ minimizzazione del WIP○ prioritizzazione○ allineamento

● Rischi:○ backlog (il cimitero delle storie)○ nessun limite o definition of done○ board multiple per le stesse persone / team

● Altre opzioni:○ small releases

Pratiche - Retrospettiva● Obiettivi:

○ creare un ciclo di sperimentazione e apprendimento○ creare consapevolezza sui successi oltre che sui fallimenti

● Rischi:○ blame game○ valvola di sfogo

● Altre opzioni:○ spike, deliberate discovery○ root cause analysis

Pratiche - Pairing● Obiettivi:

○ allineamento○ resilienza○ spinge il team a prendere responsabilità sull’intera codebase

● Rischi:○ pairing anche dove non porta valore○ coaching travestito da pairing

● Altre opzioni:○ design / code review

Pratiche - Coding standard● Obiettivi:

○ aumentare la comprensibilità○ ridurre il carico cognitivo○ aumentare il rapporto segnale/rumore

● Rischi:○ standard controproduttivi○ ingessamento

Come procedere?1. Applicare liberamente i principi e le pratiche di buona ingegneria del

software che non comportano trade-off2. Valutare il posizionamento di azienda e progetto sulle varie dimensioni3. Valutare le proprie capabilities ed i punti di attenzione

● una prospettiva esterna può essere utile

Se si decide di procedere4. Sperimentare, eventualmente appoggiandosi ad un partner già esperto

● rende evidenti i punti di attrito● aiuta a superare la diffidenza al cambiamento

Agility cannot be imposed from the top, simply because good

agile practices have to be discovered by the people using them.

Dave Thomas

OptionFactory

Thanks!http://optionfactory.netfrancesco.degrassi@optionfactory.net