In un precedente post avevo elencato, prendendo spunto da una pagina in Wikipedia, le tecniche che costituiscono un approccio Agile allo sviluppo sw. Per ognuna di esse avevo inserito un commento che riflette l’uso o meno della pratica nell’ambito dei progetti che porto avanti (commento per forza di cose maggiormente focalizzato sull’ultimo progetto). Le pratices precedenti erano: Automazione, Close Communication, Customer Involvement, Design & Documentation, Frequent Delivery, Hierarchy, Pair Programming. 

Le rimenenti sono: 

• Refactoring – Ossia la riscrittura completa di parti di codice mantenendone invariato l’aspetto esterno, nel caso di una funzione ciò significa riscriverne completamente il core mantenendone invariato header ed ovviamente sintassi, trattandola cioè come una black box; è una delle pratiche più diffuse e suggerite, ma anche questa, come il Pair Programming, ha differenti studi che ne attestano l’inutilità ed in alcuni casi la dannosità; il refactoring non è una tecnica utilizzata, per lo meno non in maniera metodica. Il grosso problema che attualmente abbiamo nel mio gruppo di lavoro è la mancanza di Unit Test che sono la rete di salvataggio del refactoring. Anzi qualcuno del mio gruppo per indicare che è meglio non fare refactoring ha coniato la parola “Tuca nò” che non vuole indicare un grosso volatile dal beco multicolare ma bensì è un’espressione in dialetto Milanese che significa “non toccare”,  tradotto “non modificare quella parte di software che funziona!”
• Reflective Improvement – Nata con l’avvento della programmazione Object-Oriented, non è altro che la presa di coscienza della produzione di conoscenza che si fa un un’azienda man mano che si produce codice; questa conoscenza prodotta non deve andare perduta ed è per far ciò che si sfruttano spesso le altre pratiche, come la comunicazione stretta o la condivisione della proprietà del codice; Attualmente questa “produzione di conoscenza” è relegata a ciascun professionista, della serie che iniziato un nuovo progetto si riutilizzano le best-pratices utilizzate negli altri progetti svolti dal medesimo (dunque al momento è l’esperienza professionale personale). E qui l’interrogativo: se l’azienda è fatta di persone, l’esperienza di ciascuna forma l’esperienza dell’azienda? Io penso di no, basta in fatti che quel “qualcuno” cambi azienda  per perdere dunque preziosa esperienza. E’ nata quindi l’esigenza, sentita ormai da tempo, di avere un repository aziendale di questa conoscenza.. per cui qualcosa si sta muovendo, staremo a vedere.
• Reverse Engineering – Ossia ottenere, spesso in maniera automatica, la documentazione a partire dal codice già prodotto; è una delle pratiche più diffuse e più controverse, diffusa perché permette un guadagno enorme in termini di tempo, ma controversa perché spesso la documentazione prodotta è inutilizzabile oppure è prodotta solo per una richiesta burocratica del cliente e non verrà mai realmente utilizzata; il reverse engineering lo usiamo ma proprio quando manca la documentazione e non certo per ottenerla in maniera automatica ma bensì per districarsi dal “guano” di qualche problema identificato dal cliente sob sob!
• Simplicity – Uno dei punti chiave delle metodologie leggere, direttamente mutuato dalla programmazione Object-Oriented, è la semplicità; semplicità nel codice, semplicità nella documentazione, semplicità nella progettazione, semplicità nella modellazione; i risultati così ottenuti sono una migliore leggibilità dell’interno progetto ed una conseguente facilitazione nelle fasi di correzione e modifica; eh beata semplicità: diciamo che solitamente la complessità si fiuta subito ma alle volte il mondo gira tanto vorticosamente che …. “ok passi per questa volta”, per poi pagarla dopo!
• Team forming & Code property – La formazione del team di sviluppo è condizionata dalla scelta sulla gerarchia interna, ma segue regole precise che permettono di ottenere un team produttivo nell’ambito della metodologia scelta; la scelta dei membri del team è condizionata anche alla scelta della proprietà del codice, che può essere individuale o collettiva; nel primo caso la responsabilità sullo sviluppo è individuale, nel secondo dipende da tutto il team e quindi dal project manager; io sono un convinto sostenitore che per mantenere una struttura uniforme il codice deve essere comunque validato/rivisto/ristrutturato da uno solo e solitamente il Project Leader. Se poi, come è successo su un progetto inglese, ho tra i membri del team persone di cui mi fido, sicuramente lascio più libertà anche perchè spesso non si ha il tempo per validare tutto un progetto dalla A alla Z. Sicuramente una volta ero più “accentratore” ma ora ho sposato il motto ”delega tutto ciò che puoi delegare!”
• Testing – Pratica diffusissima anche prima della nascita delle metodologie leggere, ha prodotto una letteratura vastissima ed una serie di approcci differenti come il Rapid Testing o il Pair Testing; nell’ambito delle metodologie leggere vengono spesso utilizzati insieme tre tipi di test differenti: i test funzionali, utilizzati per verificare che il software faccia effettivamente ciò che è previsto debba fare, i test unitari, utilizzati per verificare che ogni pezzo di codice funzioni correttamente, e i test indiretti effettuati inconsciamente dal cliente ogni volta che gli si consegna una versione; tutte le tipologie di test vengono fatte (d’altronde lavorando su progetti medio-grossi non può essere diversamente), quello che ci manca è, come dicevo prima, l’automatizzazione del test. Mi sono sempre proposto di introdurre in azienda il TDD (ed in effetti avevo iniziato ad usare il package UTPLSQL, una sorta di NUNIT per PLSQL) senza mai andare oltre l’uso personale. Okay questo può essere un buon proposito per il futuro. 
• Version Control – Una delle conseguenze dirette dell’iterazione nella produzione è la necessità di introdurre un modello, un metodo, uno strumento, per il controllo delle versioni del software prodotto e rilasciato; uno degli strumenti più diffusi e maggiormente suggeriti per ottemperare automaticamente a questa pratica è CVS. Strumento indispensabile per non affogare tra le miriade di versioni/rilasci al cliente. Su quest’ultimo progetto (il mio primo con piattaforma SQLServer) avrei voluto utilizzare “Visual Studio for database developers” per poi inserire tutto in PVCS (il nostro tool di version control) ma alla fine non sono riuscito a far funzionare il plug-in per cui sto inserendo le revision manualmente. Per il resto direi che da Project Leader il version control è il mio pane quotidiamo.

Se volessi tirare le somme, direi che i punti da migliorare sono: Automation, Customer Involvement, Pair Programming, Refactoring, Reflective Improvement, Testing.

All’orizzonte c’è un nuovo lavoro che mi aspetta di cui prima o poi parlerò in questo blog: riuscirò a tener comunque fede a queste mie promesse di miglioramento?

Lo vedremo presto.