Diventare “agili” non in senso fisico (anche se magari ciò potrebbe aiutare), ma nella più vasta asserzione che ha acquisito negli ultimi tempi nel mondo informatico, e dello sviluppo software in particolare.

Per chi non ne ha mai sentito parlare, il termine “agile”, in questo mondo, comprende e racchiude in sé tutta una serie di abitudini, best practices, idee ed approcci affinché un progetto software evolva con successo.

Sotto il “cappello” di metodologie agili rientrano diversi intendimenti più o meno simili: Extreme Programming e Scrum sono due di queste.

Quest’ultimo è sempre costituito da più di una persona, un team appunto, ed è in questa dinamica interpersonale che si inseriscono le tecniche “agili”. In Italia, purtroppo, queste metodologie non sono ancora pervasive come all’estero, ma ci si inizia a muovere in tal senso, ed alcune aziende (“lungimiranti”) hanno sposato con efficacia e successo questi approcci.

 

Ho raccolto quindi 45 punti, molto sintetici, per iniziare a prendere pratica di questa disciplina, e capire, perlomeno a grandi linee, di cosa tratta. Dico subito che, per poter iniziare a prendere pratica con queste metodologie, non basta leggere un libro o seguire una conferenza (e ce ne sono che la trattano), ma bisogna poi metterle in atto nel proprio ambiente di lavoro, e qua, mi rendo conto, il singolo non può fare più di tanto. Serve anche il supporto del management e un ambiente circostante ricettivo e disponibile.

 

Questi punti sono tratti dal libro “Practice of an Agile Developer” di Andy Hunt e Venkat Subramaniam, edito dalla Pragmatic Bookshelf nel 2006, di cui ieri ne ho pubblicato la recensione.

Non è però una mera traduzione, ma ho cercato di adattarli alla situazione italiana e soprattutto di basarli sulla mia pur ancora breve esperienza (circa 1 anno) con questo tipo di metodologie.

Non sono nemmeno dogmi scolpiti nella pietra. Ognuno li può adattare e interpretare come meglio crede, cercando comunque di tener fede ai principi base. Per chi poi è interessato ad approfondire l’argomento, basta che esegua una ricerca coi termini “agile development”, “extreme programming” e “Scrum” in Amazon.  

Sono scritti nella seconda persona singolare, come se fosse un discorso diretto ad un persona interessata ad assimilare i concetti che portano ad metodo di sviluppare software “agilMente” (“agile” + “mente”, nel senso di coscienza).

 

 

AGILE STARTING

 

1) Lavora per il risultato  

Al verificarsi di un problema ci si prodiga per cercare il colpevole o per risolverlo? Ovviamente la seconda opzione. È l’approccio positivo e il risultato finale quello che conta.

 

2) Veloci “fix” portano il progetto al caos

Quando si incappa in un bug o in un problema, cercare di trovare il tempo per capirlo a fondo. La rapida applicazione di un trucchetto o di un bug fix, anche se a prima vista lo risolve, creerà le basi per rendere ingovernabile il miglior software.

 

3) Critica le idee, non le persone

Oltre a rendere i propri collaboratori frustrati, e poco propensi in futuro ad esporre altre idee, l’aspetto importante è di arrivare ad una soluzione, e non fare a gara su quale sia la soluzione migliore o meno.

 

4) Sostieni le tue idee, anche se sono contro il “credo” aziendale

Se credi che il team stia intraprendendo la strada sbagliata, o che ci sia qualcosa di sbagliato in qualsiasi aspetto che riguardi il progetto, abbi il coraggio di dirlo.

 

AGILE FEEDING

 

5) Stai al passo con l’evolversi della tecnologia

Il mondo informatico è un mondo eccitante ma che evolve rapidamente. Chi pensa di aver imparato già tutto il necessario, prima o poi non ne farà più parte. Non è necessario essere esperti di tutto, ma con le giuste conoscenze base poi sarà più facile approfondire quando serve.

 

6) Investi nel tuo team (e su te stesso)

Investire sulla preparazione tecnica (e non solo) del proprio team, aiuta a creare software di successo. Ciò porta anche a considerare che è meglio essere il meno preparato in un team di persone molto esperte, piuttosto che il più “skillato” in un team mediocre.

 

7) Sii capace di “disimparare”

Man mano che si acquisiscono nuove competenze ed abitudini, è importante anche riuscire a “dismettere” quelle vecchie, che potrebbero ostacolare nell’apprendimento e nell’uso di quelle nuove.

 

8) Domandare, domandare, domandare…..fino a capire

Per capire completamente il perché si verifica un problema, è necessario conoscere tutto ciò che lo riguarda, e per farlo bisogna chiedere, a chi di dovere, tutto ciò che potrebbe tornare utile. I dottori non fanno la stessa cosa coi pazienti? Prima di emettere una diagnosi si informano sulla vita del malato.

 

9) Affronta gli impegni prima che si accumulino

Organizzati intervalli di tempo prestabiliti per fare il punto della situazione ed affrontare i problemi che man mano nascono. Il tempo è amico, non nemico. Organizzandolo meglio si evitano anche gli stressanti straordinari e si procede con costanza e sicurezza.

 

AGILE TARGET

 

10) Lascia le decisioni importanti riguardo al business agli utenti

Gli sviluppatori non dovrebbero decidere su aspetti legati al business dell’applicazione, ma come implementare tecnicamente ciò che il business decide e desidera.

 

11) Un buon design software è una mappa, indica ed evolve nel tempo

Il design iniziale di un progetto ne traccia i primi passi, ma è suscettibile di cambiamenti man mano che si procede con lo sviluppo. Non bisogna diventare ostaggi della progettazione iniziale.

 

12) Scegli la tecnologia che meglio si adatta per lo scopo finale…

….e non adatta lo scopo finale alla tecnologia/framework/linguaggio che vuoi utilizzare, magari solo per prendere esperienza con una novità. 

 

13) Fa in modo che la tua applicazione sia “deployabile” in qualsiasi momento

Su richiesta, e in ogni momento, il progetto dovrebbe essere compilabile, testato e pronto per essere rilasciato.

Lasciare il software in uno stato inconsistente per lungo tempo, pregiudica il lavoro di tutti.

 

14) Integra il tuo codice con quello degli altri presto e spesso

Integrando il codice 2/3 volte al giorno (indicativamente) si mitigano e si circoscrivono i problemi che potrebbero sorgere, facendoli diventare semplici da sistemare.

 

15) Non aspettare l’ultimo momento per installare e provare il software nell’ambiente dove verrà poi utilizzato dagli utenti

Non è sufficiente che tutto funzioni sulla propria macchina o sul server di sviluppo. Iniziare fin da subito a provare delle efficienti strategie per il rilascio in produzione.

 

16) Utilizza frequenti demo per ottenere costanti ed aggiornati feedback da parte del cliente

Non lasciare passare troppo tempo prima di dare una release, anche incompleta (ma funzionante), al cliente. I suoi consigli e feedback aiutano nel proseguire lungo la strada corretta.

 

17) Abituati a sviluppare per incrementi ed iterazioni successive, meglio se piccole

Una buona regola è di rilasciare una versione funzionante dell’applicazione ogni 4 settimane (iterazione), mantenendo una settimana cuscinetto per rivedere il tutto.

 

18) Non trascurare le stime

Prima di procedere a scrivere il codice, una stima, anche presunta e poco realistica, è utile per te e per il cliente. Tieni presente che sarà soggetta a cambiamenti, ma nel frattempo acquisterai precisione per le stime successive.

 

AGILE FEEDBACK

 

19) Lo Unit Testing è un tuo prezioso alleato…

… ti fa vivere più tranquillo. Dedica del tempo a realizzare dei test unitari che coprano tutte le funzionalità del software. Sono un investimento per il futuro, e ti danno subito la percezione se c’è qualcosa che non va.

 

20) Provare prima di rilasciare

Il Test Driven Development può essere un eccellente strumento di design, e di test effettivo prima di rilasciare una versione.

 

21) Testare su differenti piattaforme e differenti sistemi operativi…

… facendosi aiutare da un tool di Continuous Integration (TeamCity ad es.). Spesso il software che funziona sulla macchina dello sviluppatore, non funziona presso il cliente. 

 

22) Crea dei test specifici per la business logic dell’applicazione

Non solo l’applicazione non deve contenere bug, ma deve elaborare e fornire i dati secondo le logiche del cliente.

 

23) Misura i progressi

Tieni traccia del tempo, sia quello impiegato per realizzare una funzionalità, sia quello eventualmente rimanente. La metodologia “Scrum” prevede, ad es,. periodi di 30gg (gli “Sprint”) per portare a termine micro attività (i “backlog”). Uno strumento utile allo scopo può essere “Versione One” (V1).

 

24) Ascolta i problemi degli utenti

Quante volte chi si occupa di Customer Care considera gli utenti degli stupidi inetti? Spesso invece le loro osservazioni, anche le più banali, possono celare problemi che ad un primo esame passano inosservati.

 

AGILE CODING

 

25) Scrivi il codice in modo che si capisca l’intento e lo scopo solo guardandolo

Scrivere codice complesso e contorto è più facile che scrivere del codice semplice e lineare. Ricorda che il codice viene letto molte, molte più volte di quante viene scritto.

 

26) Scrivere del codice che si autocommenti da solo

I commenti sono importanti, ma il codice dovrebbe farsi leggere e capire anche senza di essi. Il codice ben scritto e con una giusta scelta dei nomi, non ha bisogno di molti commenti.

 

27) Valuta i criteri di performance, usabilità, costi e tempistica con equilibrio

Se per aumentare dell’1% le performance implica lunghi tempi e costi extra, forse è il caso di accettare delle pur buone prestazioni per dare spazio a miglioramenti in altri settori.

 

28) Scrivi il codice in brevi sessioni incrementali, e testa subito quello che hai scritto

Questo aiuta a scrivere codice più compatto, più semplice e più testabile. Non scrivere codice a testa bassa per ore; fermati, fai un break, un caffè o altro, e rivedi quello che hai fatto prima di proseguire.

 

29) Ricorda il detto: “Keep it simple”

Introduci feature o costrutti avanzati solo se ne esiste veramente la necessità. Il codice semplice ed elegante è anche più manutenibile ed estendibile.

 

30) Scrivi codice “coeso”

Classi e metodi con funzionalità simili dovrebbero stare vicini. Immagina un negozio di abbigliamento: tutti i vestiti stanno nello stesso reparto, come tutte le scarpe stanno nel reparto calzature. Questa è la filosofia alla base del pattern MVC (Model-View-Controller).

 

31) Mantieni l’incapsulamento fra gli oggetti

Il codice procedurale ottiene informazioni ed attua decisioni; il codice object-oriented invece dice agli oggetti di effettuare delle azioni.

 

32) Estendi l’applicazione estendendo il codice

Questa frase, un po’ criptica, esprime il concetto di valutare bene se l’ereditarietà è realmente necessaria. Spesso infatti non lo è, ed apporta più problemi che benefici. La regola di fondo è di fare in modo che il sistema non si accorga se una parte di esso viene sostituita con un’altra più ricca di funzionalità.

 

AGILE DEBUGGING

 

33) Mantieni un lista delle soluzioni per i problemi riscontrati

Spesso problemi tecnici di varia natura, ricapitano a distanza di tempo. Sapere come erano stati risolti la prima volta che erano successi può risparmiare tutto il tempo che si era speso quella stessa prima volta che si era risolto.

 

34) Considera gli “Warnings” come “Errors”

Un buon codice, oltre a compilare senza errori (ovviamente) non dovrebbe produrre nemmeno “warnings” dal proprio ambiente di sviluppo. Questi possono celare problemi o comportamenti inaspettati quando l’applicazione va in produzione.

 

35) I bug si risolvono isolando il codice

A ciò aiutano anche gli unit test ben fatti, che disaccoppiano classi e layer di funzionalità dell’applicazione.

E’ più facile trovare uno spillo in una tazza che in un fienile.

 

36) Gestisci le eccezioni in modo che siano precise e dettagliate … (1/2)

Una “NullReferenceException” è meno utile di un’eccezione che spiega il motivo e il luogo del perché qualcosa è andato storto. La scrittura delle eccezioni non è tempo speso inutilmente.

 

37) … e i messaggi di errore il più possibile informativi

Questo però senza sommergere l’utente di lunghissimi dettagli tecnici. In alcuni casi può risultare utile mantenere un log di questi errori dettagliati, e consultabile al bisogno.

 

AGILE COLLABORATION

 

38) All’inizio della giornata organizza brevi meeting in piedi

Il fatto di non sedersi aiuta a mantenerli brevi (10/15 min); in tale occasione ogni membro del team racconta cosa ha fatto ieri, cosa farà oggi ed eventuali problemi che ha riscontrato (e che se complessi andranno approfonditi fuori da questo breve “MM – Morning Meeting).

 

39) Gli architetti scrivano codice e gli sviluppatori si occupino anche di design

Diffida dai “Software Architect” che non vogliono sporcarsi le mani con il codice.

 

40) Ogni sviluppatore dovrebbe conoscere, almeno a grandi linee, ogni parte dell’applicazione

Meglio non tenere le competenze e le attività di ciascuno in compartimento stagni, ma far ruotare ciascuno anche su codice scritto da altri. Si evita in tal modo che tutto si blocchi se manca chi ha scritto una parte di codice, e qualcun altro può apportarvi nuove idee e consigli.

 

41) Le competenze crescono quando vengono condivise

Non appena scopri di avere delle conoscenze superiori a quelle dei tuoi colleghi, condividile. Gli altri si sentiranno motivati a migliorarsi e gli skill di tutto il team cresceranno di conseguenza. 

 

42) Aiuta gli altri a trovare le soluzioni

Piuttosto che mostrare la soluzione finale, indica il percorso da fare per arrivarci. Si stimola la persona a trovare nuove idee, e magari, qualcuna di esse potrà anche sorprenderti.

 

43) Condividi il tuo codice solo quando pronto

Questo significa non fare “check-in” di codice che non compila o che non passa i test.

 

44) Rivedi regolarmente il codice scritto

Il tuo codice fallo revisionare ad un collega, e tu fai altrettanto; questo è un eccellente modo per avere codice di qualità. Il “Pair Programming” (due su uno stesso pc) è una buona tecnica per ottenere un revisione in tempo reale.

 

45) Mantieni il team informato sull’avanzamento delle tue attività

A questo tornano utili i meeting mattutini in piedi (Punto 38). Specie nelle difficoltà, far sapere per tempo agli altri la situazione può essere di aiuto affinché si trovi insieme una soluzione.

 

 

MUOVERSI VERSO L’AGILITA’

 

Giunti alla fine di questi punti, si possono trarre alcune conclusioni.

Innanzitutto, in un ambiente che non ha mai sentito parlare di metodologie agili ed extreme programming, sarà molto difficile (e deleterio) introdurre in massa tutti i concetti sopra esposti.

La strada migliore da seguire sarà quella dei piccoli passi: iniziare – ad esempio – con i meeting in piedi mattutini, poi con il “code review”, e in seguito applicare man mano tutti gli altri punti, senza imporli come un dogma obbligatorio.

In quanto sviluppatore singolo in un team già avviato, il modo migliore (ed unico) per far nascere i germogli dell’agilità è tramite esempi. Non ci sarà modo a parole di convincere nessuno ad usare il proprio editor preferito, o a crearsi degli unit test efficaci, ma se vedono che il lavoro può migliorare radicalmente e i bug diminuire con l’uso dei test unitari e dei principi sopra esposti, chiunque vorrà seguire quella strada.

Se si vuole condurre il proprio team verso un territorio nuovo, bisogna essere i primi a percorrerlo.