Breaking the ice with agile - cinque strade per rompere il ghiaccio e introdurre i metodi agili in una azienda

La nostra esperienza ha mostrato che esistono alcune pratiche “rompighiaccio” che, con un costo di introduzione relativamente basso, permettono di far prendere coscienza alle persone di alcune problematiche e dinamiche tipiche dei progetti software e che ne minano il successo.
La presa di coscienza di queste problematiche e dinamiche è il primo passo per comprendere e abbracciare valori e principi dei metodi agili.
Le pratiche di cui vorremmo parlare e che definiamo “ice breakers” per quel che riguarda le metodologie agili sono:
- adozione della lavagna per rappresentare il flow del lavoro
- standup meeting
- retrospective
- build automatica (e automazione in genere)
- acceptance testing
A cascata poi queste pratiche se ne portano dietro altre più difficili da adottare fin da subito, ma più facili da far adottare quando le persone prendono coscienza dei problemi che gli impediscono di lavorare in modo efficace (pair, tecnica del pomodoro, user stories, TDD, CI, simple design, daily journal, etc) e abbracciano i principi dell’agile.
Per ogni pratica “ice breakers”, a partire dalla nostra esperienza, illustreremo il motivo per cui secondo noi sono tali, le dinamiche secondo noi migliori per proporne l’introduzione, anti-pattern e resistenze al cambiamento che abbiamo incontrato e come le abbiamo affrontate.

Transcript

1. Breaking the ice with agile Agile Day 2012 Milano, 24 Novembre Pietro Di Bello pietro.dibello@xpeppers.com www.xpeppers.com cinque strade per rompere il ghiaccio e introdurre i metodi agili in una azienda
2. Pietro Di Bello ★ Uso e diffondo i metodi agili (dal 2002) ★ Mi piace programmare in Ruby e Java (ho iniziato con Java nel 2000 e da tre anni sono passato a Ruby) ★ Sono sempre alla ricerca di modi migliori di fare le cose pietro.dibello@xpeppers.com @pierodibello github.com/xpepper
3. Non è facile... Introdurre i metodi agili in una azienda è dannatamente difficile
4. Situazioni che abbiamo incontrato Multitasking
5. Situazioni che abbiamo incontrato Multitasking Stress
6. Situazioni che abbiamo incontrato Settorializzazione delle conoscenze e delle competenze
7. Situazioni che abbiamo incontrato Overtime
8. Situazioni che abbiamo incontrato Overtime Stress
9. Situazioni che abbiamo incontrato Processo di sviluppo "opaco" e poco predicibile
10. Situazioni che abbiamo incontrato Processo di sviluppo "opaco" e poco predicibile Stress
11. Situazioni che abbiamo incontrato Processo di sviluppo "opaco" e poco predicibile Stress Manager Stressati
12. Situazioni che abbiamo incontrato Frequenti interruzioni al lavoro
13. Situazioni che abbiamo incontrato Frequenti interruzioni al lavoro Stress
14. Situazioni che abbiamo incontrato Fretta
15. Situazioni che abbiamo incontrato Fretta Stress
16. Situazioni che abbiamo incontrato Scarsa attenzione alle buone pratiche di programmazione
17. Situazioni che abbiamo incontrato Deploy “a mano”
18. Situazioni che abbiamo incontrato Deploy “a mano” Stress
19. Situazioni che abbiamo incontrato Hotfix direttamente in produzione
20. Situazioni che abbiamo incontrato Hotfix direttamente in produzione Stress
21. Situazioni che abbiamo incontrato Mancanza di sistemi di versionamento
22. Situazioni che abbiamo incontrato Mancanza di sistemi di versionamento Dropbox non è git
23. Situazioni che abbiamo incontrato Nascondere i problemi http://www.slideshare.net/jchyip/lean-software-development-on-radiators-and-refrigerators-presentation
24. Strategie Quali strategie si adottano per introdurre i metodi agili in una azienda?
25. Quali strategie si adottano per introdurre metodi agili in un team? Prima i valori e i principi
26. Quali strategie si adottano per introdurre metodi agili in un team? Solo pratiche organizzative
27. Le pratiche rompighiaccio Per prendere coscienza delle problematiche che possono compromettere il successo
28. Le pratiche rompighiaccio La presa di coscienza di queste problematiche e dinamiche è il primo passo per comprendere e abbracciare valori e principi dei metodi agili. • coraggio • feedback • semplicità • comunicazione • rispetto • coraggio • commitment • openness • focus • rispetto XP Scrum
29. Le pratiche rompighiaccio ...con un costo di introduzione relativamente basso
30. Le pratiche rompighiaccio ★ lavagna ★ standup meeting ★ retrospettiva ★ build automatica ★ test di accettazione automatici
31. Perché cinque? Per poter equilibrare l'introduzione di pratiche tecniche con la comprensione dei valori e dei principi
32. Rompighiaccio #1: Lavagna •perché è rompighiaccio? •quali valori esercita? •quali altre pratiche attiva? •a cosa stare attenti •resistenze
33. Se vuoi capire come lavora il team, guarda la sua lavagna Rompighiaccio #1: Lavagna
34. Se vuoi capire come lavora il team, guarda la sua lavagna Se vuoi capire come sta andando il progetto, guarda la lavagna Rompighiaccio #1: Lavagna
35. Se vuoi capire come lavora il team, guarda la sua lavagna Se vuoi capire come sta andando il progetto, guarda la lavagna Se vuoi capire quali problemi ha il processo di sviluppo, guarda la lavagna Rompighiaccio #1: Lavagna
36. Rompighiaccio #1: Lavagna
37. Rompighiaccio #1: Lavagna Lavagna dell’iterazione
38. Rompighiaccio #1: Lavagna Lavagna backlog
39. Rompighiaccio #1: Lavagna
40. Rompighiaccio #1: Lavagna (elettronica)
41. Consente di visualizzare in modo non ambiguo il processo produttivo del team... #1 Lavagna: perché è rompighiaccio?
42. ...e ne evidenzia tutti i problemi #1 Lavagna: perché è rompighiaccio?
43. ...e ne evidenzia tutti i problemi #1 Lavagna: perché è rompighiaccio? troppe storie in progress
44. ...e ne evidenzia tutti i problemi #1 Lavagna: perché è rompighiaccio? troppe storie in progress storie che tornano indietro a causa di un bug
45. ...e ne evidenzia tutti i problemi #1 Lavagna: perché è rompighiaccio? troppe storie in progress storie che tornano indietro a causa di un bug storie bloccate in QA
46. ...e ne evidenzia tutti i problemi #1 Lavagna: perché è rompighiaccio? troppe storie in progress storie che tornano indietro a causa di un bug storie bloccate in QA storie bloccate in progress
47. E’ un ottimo punto di partenza per far riflettere il team #1 Lavagna: perché è rompighiaccio?
48. E’ visibile a tutti #1 Lavagna: perché è rompighiaccio?
49. Consente di sincronizzare tutti su un workflow condiviso #1 Lavagna: perché è rompighiaccio?
50. #1 Lavagna: quali valori esercita? •Comunicazione •Feedback •Openness •Commitment •Focus
51. #1 Lavagna: quali altre pratiche attiva? •user stories •informative workspace •iteration planning •standup meeting •whole team •incremental design •simple design
52. #1 Lavagna: precauzioni d’uso e resistenze •tenerla costantemente aggiornata •introdurre al più presto i principi della pianificazione agile •guardarla •e se il team è distribuito o il cliente è spesso via? •dove l’appendiamo?
53. Rompighiaccio #2: Standup Meeting •perché è rompighiaccio? •quali valori esercita? •quali altre pratiche attiva? •a cosa stare attenti •resistenze
54. #2 Standup Meeting: cos’è?
55. #2 Standup Meeting: cos’è?
56. #2 Standup Meeting: perché è rompighiaccio? •Maggiore comunicazione tra gli elementi del team •Commitment reciproco (“Oggi farò questo…”) •Rafforzamento del senso di team •“ti aiuto io su questo problema di cui parli…” •imparare a chiedere e offrire aiuto
57. #2 Standup Meeting: perché è rompighiaccio? •Maggiore reattività agli ostacoli che emergono •C’è subito evidenza se la pianificazione è corretta •ci sono persone che non sanno cosa faranno? •ci sono persone che hanno troppe cose in lavorazione?
58. #2 Standup Meeting: quali valori esercita? •Comunicazione •Feedback •Rispetto •Coraggio •Openness •Commitment •Focus
59. #2 Standup Meeting: quali altre pratiche attiva? •pair programming •whole team •collective-code ownership
60. #2 Standup Meeting: precauzioni d’uso e resistenze •si riporta sempre al team-leader •i manager o stakeholders “dirottano” lo standup meeting •si inizia sempre in ritardo o in un orario diverso
61. #2 Standup Meeting: precauzioni d’uso e resistenze •va sempre per le lunghe, si scende in dettagli tecnici fuori luogo •le persone sono evasive •le persone non ricordano quello che hanno fatto ieri
62. Rompighiaccio #3: Retrospettiva •perché è rompighiaccio? •quali valori esercita? •quali altre pratiche attiva? •a cosa stare attenti •resistenze
63. #3 Retrospettiva: cos’è?
64. #3 Retrospettiva: cos’è?
65. #3 Retrospettiva: cos’è?
66. #3 Retrospettiva: cos’è?
67. #3 Retrospettiva: cos’è?
68. #3 Retrospettiva: cos’è?
69. #3 Retrospettiva: cos’è?
70. #3 Retrospettiva: perché è rompighiaccio? •è il primo tassello del process improvement •il team ha la possibilità di riflettere sui propri errori e porre azioni correttive •il team ha al suo interno tutte le potenzialità per lavorare meglio
71. #3 Retrospettiva: quali valori esercita? •Comunicazione •Rispetto •Openness •Commitment •Coraggio
72. #3 Retrospettiva: quali altre pratiche attiva? •whole team •continuous improvement
73. •va preparata per tempo •facilitatore esterno •periodica •time-boxed •spiegare bene il suo scopo #3 Retrospettiva: precauzioni d’uso e resistenze
74. #3 Retrospettiva: precauzioni d’uso e resistenze •alcuni manager potrebbero lamentarsi dell'eccessivo costo di queste attività •alcuni membri del team potrebbero non partecipare volentieri •decidere prima se coinvolgere o meno esterni al team o manager
75. #3 Retrospettiva: precauzioni d’uso e resistenze •effetto "vogliamoci bene" •pubblicare in uno spazio visibile a tutti la lista delle azioni correttive scelte •moderare la discussione in modo che non sfoci nel "finger pointing"
76. Rompighiaccio #4: Build automatica •perché è rompighiaccio? •quali valori esercita? •quali altre pratiche attiva? •a cosa stare attenti •resistenze
77. “Nothing forces us to understand a process better than trying to automate it.” Growing Object-Oriented Software, Guided by Tests (S.Freeman, N.Pryce) #4 Build automatica
78. #4 Build automatica: perché è rompighiaccio? Si collabora anche con parti "nuove" del team
79. #4 Build automatica: perché è rompighiaccio? Si affrontano prima problematiche che emergerebbero solo con la messa in produzione
80. #4 Build automatica: perché è rompighiaccio? Consente al team di progettare fin dall'inizio il sistema e i suoi rilasci in modo incrementale
81. #4 Build automatica: perché è rompighiaccio? Il team impara cosa significa "finito" e ha la possibilità di verificare realmente il progresso fatto
82. #4 Build automatica: perché è rompighiaccio? Consente di rilasciare con maggiore frequenza le features sviluppate
83. #4 Build automatica: perché è rompighiaccio? Migliora la fiducia nel team da parte del cliente, che vede che il team è in grado di rilasciare frequentemente senza panico
84. •Feedback •Coraggio #4 Build automatica: quali valori esercita?
85. #4 Build automatica: quali altre pratiche attiva? •test automation •test-driven development •refactoring •rilasci incrementali •continuous deployment •devops e configuration management
86. #4 Build automatica: come si applica? E’ necessario analizzare con cura la situazione iniziale
87. #4 Build automatica: come si applica? E’ necessario analizzare con cura la situazione iniziale il codice è sotto controllo versione?
88. #4 Build automatica: come si applica? E’ necessario analizzare con cura la situazione iniziale il codice è sotto controllo versione? esistono ambienti di test/ collaudo?
89. #4 Build automatica: come si applica? E’ necessario analizzare con cura la situazione iniziale il codice è sotto controllo versione? esistono ambienti di test/ collaudo? quanto è facile creare un nuovo ambiente di test?
90. #4 Build automatica: come si applica? E’ necessario analizzare con cura la situazione iniziale il codice è sotto controllo versione? esistono ambienti di test/ collaudo? quanto è facile creare un nuovo ambiente di test? come vengono effettuati i rilasci?
91. #4 Build automatica: come si applica? E’ necessario analizzare con cura la situazione iniziale il codice è sotto controllo versione? esistono ambienti di test/ collaudo? quanto è facile creare un nuovo ambiente di test? come vengono effettuati i rilasci? quante dipendenze da sistemi terzi ci sono?
92. #4 Build automatica: come si applica? E’ necessario analizzare con cura la situazione iniziale il codice è sotto controllo versione? esistono ambienti di test/ collaudo? quanto è facile creare un nuovo ambiente di test? come vengono effettuati i rilasci? quante dipendenze da sistemi terzi ci sono? esistono sistemi di monitoring della produzione?
93. #4 Build automatica: come si applica? E’ necessario analizzare con cura la situazione iniziale il codice è sotto controllo versione? esistono ambienti di test/ collaudo? quanto è facile creare un nuovo ambiente di test? come vengono effettuati i rilasci? quante dipendenze da sistemi terzi ci sono? esistono sistemi di monitoring della produzione? con chi bisogna interagire per avere accesso agli ambienti di test?
94. #4 Build automatica: come si applica? E’ necessario analizzare con cura la situazione iniziale il codice è sotto controllo versione? esistono ambienti di test/ collaudo? quanto è facile creare un nuovo ambiente di test? come vengono effettuati i rilasci? quante dipendenze da sistemi terzi ci sono? esistono sistemi di monitoring della produzione? con chi bisogna interagire per avere accesso agli ambienti di test? come gestisco le dipendenze da sistemi esterni negli ambienti di test?
95. #4 Build automatica: come si applica? A piccoli passi si deve pianificare una serie di interventi di automazione ad es partire da uno script che automatizza tutti i processi manuali effettuati per mettere in produzione una nuova versione
96. #4 Build automatica: a cosa stare attenti? •stabilire una collaborazione positiva con la parte operational / sistemistica dell'azienda •procedere a piccoli passi
97. Rompighiaccio #5: Test di accettazione automatici •perché è una pratica rompighiaccio? •quali valori esercita? •quali altre pratiche attiva? •a cosa stare attenti •resistenze
98. #5 Test di accettazione automatici: perché è una pratica rompighiaccio? •I test di accettazione mettono in comunicazione stretta analisti, cliente e sviluppatori •Consentono lo switch di mentalità da "code & fix" a "rilascio di feature finita" •Consentono a tutti di chiarire qual'è lo scope della feature
99. #5 Test di accettazione automatici: perché è una pratica rompighiaccio? •Trasmettono fiducia al cliente •Sono propedeutici per l'intero tema del testing e del design test-driven
100. #5 Test di accettazione automatici: come si può applicare? Quando si pianifica una nuova feature, parte dell'analisi consiste nel descrivere quali sono i criteri di accettazione della feature
101. Si può iniziare anche solo a raccogliere dei test di accettazione manuali durante il planning della feature #5 Test di accettazione automatici: come si può applicare?
102. Si può iniziare anche solo a raccogliere dei test di accettazione manuali durante il planning della feature poi si passa a proporre la loro automazione #5 Test di accettazione automatici: come si può applicare?
103. Si può iniziare anche solo a raccogliere dei test di accettazione manuali durante il planning della feature poi si passa a proporre la loro automazione e si mettono i test nella build automatica #5 Test di accettazione automatici: come si può applicare?
104. #5 Test di accettazione automatici: quali valori esercita? •Feedback •Comunicazione
105. #5 Test di accettazione automatici: quali altre pratiche attiva? •Testing automatico •Test-Driven Development •Continuous integration •Refactoring
106. #5 Test di accettazione automatici: a cosa stare attenti? •Va bene partire da test manuali, ma non fermarsi a quelli •Fare in modo che i test automatici rimangano verdi •Non devono mentire •Devono essere veramente automatici
107. #5 Test di accettazione automatici: resistenze •Alcuni test automatici saranno difficili da scrivere •non scoraggiatevi
108. Effetto cascata :^) A cascata queste pratiche se ne portano dietro altre più difficili da adottare fin da subito...
109. Effetto cascata ...ma più facili da introdurre quando le persone prendono coscienza dei problemi che gli impediscono di lavorare in modo efficace e fanno propri i principi dei metodi agili ★Pair Programming ★Test-Driven Development ★Refactoring ★Design Incrementale ★Continuous Integration ★Tecnica del Pomodoro ★Daily Journal ★Collective Code Ownership ★ ... a piccoli passi, applicando un approccio iterativo e incrementale :^)
110. Come andare avanti Procedere a piccoli passi
111. Come andare avanti Make things visible
112. Come andare avanti Learn
113. Come andare avanti Tenere una retrospettiva periodica sul processo
114. L'integrazione con il resto dell'azienda ...ovvero, quando un collo di bottiglia in meno ti può strozzare lo stesso :)
115. Cosa può andare male?
116. La resistenza al cambiamento
117. Come andare avanti? Per avere i risultati migliori, si devono valutare e sperimentare tutte le pratiche di XP. Ogni pratica XP è sostenuta e rafforzata dalle altre. Adottare solo un subset di pratiche potrebbe causare "asimmetrie" nel processo (alcune pratiche senza pratiche di sostegno funzionano meno bene, o rischiano di fallire).
118. Contacts •www.xpeppers.com •info@xpeppers.com •@xpeppers