Agile è entrato nel gergo comune di molte aziende che hanno a che fare con progetti IT. Questa è una buona cosa: il termine è conosciuto e accettato come una buona prassi, le persone sono ben disposte ad adottare metodi e pratiche che consentono di migliorare la gestione del ciclo di vita di un prodotto software e sono favorevoli al cambiamento. Quando però si parte veramente mi sono trovato in diverse situazioni dove Agile si limitava alla parte “persone” e “organizzazione” ma non entrava nel merito di come si sviluppa il codice! La provocazione “Stop Meeting, Start Coding” vuol ridurre all’essenziale i momenti di confronto e concentrarsi a scrivere buon codice, insieme! In questo talk presenterò alcune buone pratiche di coding che favoriscono anche l’efficacia organizzativa.

2. Giulio Roggero
www.agilereloaded.it
www.mia-platform.eu
www.intre.it
Di cosa mi occupo?
“Mettere a terra” le
strategie digitali delle
aziende.

3. Qual’è il valore del
nostro lavoro?
Realizzare servizi che soddisfano i
bisogni degli utenti.
Ad un costo accettabile, al momento
giusto e che siano convenienti nella
loro operatività.

4. La scrittura
del codice.
Qual è l’attività che
consente di realizzarlo?
Tip
Con codice si intende:
● sourcecode
● contenuti
● visual
● ambienti
… e tutto quello che
serve per far funzionare
il servizio.

5. Tutto il resto è
potenzialmente uno spreco!

6. Il progetto perfetto?
Tip
Ovviamente una
provocazione.
Comunicazione
semplice.
Bisogni chiari.
Sai quando sei arrivato al
risultato.
io sono il team, io sono il cliente, io pago

7. Contesto
É molto più complesso:
➔ Molti stakeholders
Tanti canali di comunicazione e tante
idee.
➔ Molti utenti finali
Non un solo bisogno chiaro ma diverse
sfumature.
➔ Obiettivi contrastanti
Non un solo obiettivo ma diversi livelli a
seconda del ruolo in azienda.

8. Questo comporta un sacco di
riunioni spesso poco efficaci

9. Passiamo più
tempo in riunione
rispetto a
scrivere “codice”

10. Passare da una riunione all’altra
Non riuscire a concentrarsisullo sviluppo
Diventare inconcludenti a fine giornata
Andare in ritardo
Creare debito tecnico
Gestire interruzioniimpreviste perchè il
software è di bassa qualità
Insoddisfazione

12. Il cambiamento parte da noi
Non dire che è colpa degli altri ma partiamo da noi stessi come developers.
Spezziamo il ciclo caotico delle riunioni adottando buone pratiche di
sviluppo del codice.

13. ordine, disciplina e metodo

14. Difficile da comprendere
Difficile da gestire
Difficile da far evolvere
Semplice da comprendere
Semplice da gestire
Semplice da far evolvere

15. Clean Code
pulizia e metodo nello scrivere codice

16. Copertura dei test
la legge di Murphy ci vede benissimo!
TDD
Se poi si approccia lo
sviluppo con un metodo
guidato dai test si ha sia
codice pulito che
coperto dai test!

17. Il codice è di tutti!
Adottiamo regole
comuni, automatiche.

18. Pareto 80/20
Nello sviluppo software
“fare il giro che funzioni”
costa relativamente poco.
È nel dettaglio che si
nascondono i veri costi e
problemi.

19. Non innamorarsi della
tecnologia!
I tecnici si innamorano delle tecnologie; le persone di
business si innamorano dei KPI. E' normale ma poco
efficace. Solo quando un'azienda, nel suo insieme di
business e tecnici, si innamora dei suoi utenti finali si fa
il vero salto di qualità!

20. Framework last
Spesso ci vuole più tempo a scegliere il
framework più adeguato che sviluppare
il prodotto. Non perdere il tuo tempo,
parti semplice ed evolvi gradualmente:-)

21. “Informagica”
Se vedi un errore una volta sola e non lo analizzi più perché pensi che si sia risolto
da solo ricordati che sicuramente quell'errore si presenterà di nuovo e soprattutto
nel momento peggiore: in produzione, la domenica, mentre tuo figlio ti chiede
quanto costa la DS su Amazon e quando non hai rete per connetterti ai server.
L’informagicanon esiste!
Segna ogni errore e chiudilo solo quando hai capito perché è successo. Malgrado
lo stia scrivendo mi è già successo più volte e succederà ancora. La soluzione più
sicura è automatizzare tutto: continuous integration, delivery, deploy e rollback.
Automatizza dalla prima linea di codice che scrivi, altrimenti dopo non lo farai più!
https://www.flickr.com/photos/randar/31727903135

22. Puntare alla semplicità
Il programmatore “pigro”:
● scrive poco codice per raggiungere l’obiettivo
● automatizza tutti i lavori noiosi
● non si arrovella a progettare cose che non conosce
ancora
● dorme la notte, per cui fa in modo che se succedono
crash il sistema riparta da solo
● si dimentica le cose, per cui scrive codice leggibile e non
criptico
● cerca di riutilizzare quello che ha fatto
● non gli piace il copia-incolla (troppo noioso da
manutenere)

23. Lavorare insieme

24. concludendo

25. 3 consigli + 1
1. Il cambiamento parte da noi e dal
nostro modo di scrivere codice
2. Fidiamoci dei colleghi: non
sempre tutti in riunione
3. Tenere le riunioni brevi, con
un’agenda e una conversazione
visuale
4. Alla fine sempre azioni chiare,
fattibili nel breve

26. Benefici dello
scrivere buon
codice
● Il software risulta di
maggiore qualità
● Per cui ci saranno meno
interruzioni impreviste
● Meno riunioni e di
minor durata
● Ogni riunione ha uno
scopo e le persone
portano valore
● Avremo più tempo per
le cose importanti:
apprendere e innovare