Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Stop Meeting, Start Coding!

507 views

Published on

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.

Published in: Business

Stop Meeting, Start Coding!

  1. 1. Giulio Roggero www.agilereloaded.it www.mia-platform.eu www.intre.it Di cosa mi occupo? “Mettere a terra” le strategie digitali delle aziende.
  2. 2. 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à.
  3. 3. 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.
  4. 4. Tutto il resto è potenzialmente uno spreco!
  5. 5. 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
  6. 6. 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.
  7. 7. Questo comporta un sacco di riunioni spesso poco efficaci
  8. 8. Passiamo più tempo in riunione rispetto a scrivere “codice”
  9. 9. 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
  10. 10. 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.
  11. 11. ordine, disciplina e metodo
  12. 12. Difficile da comprendere Difficile da gestire Difficile da far evolvere Semplice da comprendere Semplice da gestire Semplice da far evolvere
  13. 13. Clean Code pulizia e metodo nello scrivere codice
  14. 14. 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!
  15. 15. Il codice è di tutti! Adottiamo regole comuni, automatiche.
  16. 16. Pareto 80/20 Nello sviluppo software “fare il giro che funzioni” costa relativamente poco. È nel dettaglio che si nascondono i veri costi e problemi.
  17. 17. 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à!
  18. 18. 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:-)
  19. 19. “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
  20. 20. 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)
  21. 21. Lavorare insieme
  22. 22. concludendo
  23. 23. 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
  24. 24. 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

×