No silver bullet - Diventare agili non è banale, nè scontato
-
Upload
francesco-degrassi -
Category
Software
-
view
124 -
download
0
Transcript of No silver bullet - Diventare agili non è banale, nè scontato
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