Franco Lombardo

All you know that TDD has god side effects. One of them is testing your application Another one is to force you to write less verbose code.
Sometimes (only sometimes ) when you write production code not writing tests (oh, well I do not do that, ehm) you accept that the code is not as concise and "speaking" as it should be: after all you are writing code that does its dirty work (maybe), that's enough!!! But when you write tests, you know that the goal of test code is to speak to other people. In other words, my attitude when I write production code is to write code that speaks to the machine, while when I write test code I'm trying to speak to people, and you know, when you're speaking to human beings you can't bore them. So your writing must be clear and concise. In order to do that, sometimes you're forced to write some helper classes that, after a short while, you'll find useful on the production side too.

Un altro Agile Day è passato ed eccomi nuovamente a scrivere un sommario della mia esperienza.

Peter Stevens - Fixed Price Projects With Agile – It can be done!

Possiamo stimare a priori tempi e costi di un progetto agile? Possiamo applicare i metodi agili quando il costo ed il tempo sono scolpiti nella pietra? Certo, sarebbe bello poter vivere in un mondo in cui tutti i contratti fossero tagliati sul concetto di iterazione, di sviluppo incrementale. Purtroppo ci sono occasioni nelle quali dobbiamo stimare i costi, nei quali dobbiamo sapere se riusciremo a rilasciare entro una certa data, magari remota. Chi, ad esempio, sviluppa il software per gestire grandi eventi come i mondiali di calcio non può chiedere di spostare la data della finale perché lavora in un team agile e ha bisogno di una nuova iterazione per completare le storie!

Peter Stevens ritiene che lo sviluppo agile si possa adattare a queste situazioni, anzi che sia il miglior metodo da adottare. Questo perché è l'unico sistema per valutare in corso d'opera la velocità alla quale lo sviluppo si sta svolgendo.

Per affrontare progetti di questo tipo occorre però:

• un cliente del quale fidarsi;
• una pianificazione che lasci "cuscinetti" liberi nei quali compensare eventuali ritardi;
• criteri certi (e automatizzabili) per determinare quando una funzionalità è conclusa;
• criteri per stabilire l'importanza delle varie funzionalità per realizzare prima le storie più importanti e consegnare alla fine del progetto, quando la pressione è maggiore e le energie si esauriscono, le funzioni di minor rilievo;
• un team esperto.

Maggiori dettagli sulla presentazione si trovano qui.

Alberto Brandolini - Possiamo fare di meglio

La presentazione mattutina di Alberto Brandolini è partita da una serie di provocazioni ad effetto sui seguenti temi.

• Spesso si rompe il rapporto di fiducia tra il software e chi lo usa, sia egli un utente finale o chi fa parte dello stesso team di sviluppo. Scatta allora il meccanismo della "complessità compensativa", cioè degli strani trucchi per aggirare i comportamenti errati dei sistemi.
• A volte gli sviluppatori accettano passivamente i requisiti che sono dati loro: ma chi dà questi requisiti è il vero esperto del problema, o, se lo è veramente, ha avuto modo di pensare ai requisiti in maniera critica? I requisiti non sono in alcuni casi semplicemente la mummificazione di un processo che potrebbe essere invece migliorato?
• Nei progetti software può nascere quello che è stato definito "technical debt". Brandolini suggerisce una metafora più calzante per questa progressiva deriva nella qualità del codice: inquinamento, ovverosia un processo estremamente dannoso, difficilmente reversibile e con un tempo di riparazione incalcolabile.
• A volte lo sviluppatore non ha abbastanza umiltà per capire di dover approfondire il dominio da un punto di vista non semplicemente informatico.

Dopo aver introdotto questi spunti di discussione, Brandolni ha lasciato la parola all'uditorio. L'esito di questo esperimento di "terapia di gruppo" a mio avviso non è però stato brillantissimo: purtroppo non è emerso molto di interessante, se non una collezione di aneddoti sul nostro lavoro.

Pietro Brambati - ASP.NET MVC: Programming & Testing

Dato che prima del pranzo non mi sembrava vi fossero relazioni degne d'interesse, mi sono infilato nell'auletta dedicata alla presentazione dell'ambiente di test creato per .NET MVC. Io odio gli strumenti di sviluppo Microsoft!!! Questo mio sentimento nacque anni fa quando Visual Basic 6, con un fantastico "Il controllo OCX non è registrato correttamente", mi fece affogare in un oceano marrone nel bel mezzo di una demo ad un centinaio di persone. Nonostante questo, mi è sembrato che il supporto di Microsoft ai test unitari sia discreto e che l'oratore, molto preparato, sia riuscito a dare a i colleghi della sponda Microsoft un buon numero di informazioni utili su come scrivere codice in modo più efficace. L'impressione comunque è che con questo prodotto Microsoft stia svolgendo un diligente compitino per conquistarsi la medaglietta "agile" e la relativa fetta di sviluppatori.

Alberto Quario - Scenario testing

Questo è forse stato l'intervento più interessante della giornata. All'Agile Day si è molto parlato di processi, ma ci si è un poco scordati del codice. Alberto Quario ci ha riportati nel cuore del problema, citando le parole di Gerard Meszaros: I test possono diventare il collo di bottiglia dei processi agili. (Ma allora non le sparavo così grosse quando parlavo dei test come palle al piede!). Uno dei principi da seguire per evitare che i nostri test divengano dei mostri incomprensibili, difficili da scrivere, leggere e manutenere è il seguente: nel corpo del test deve andare tutto e solo quanto è strettamente necessario per la sua comprensione.

Alcuni consigli sono quindi:

• radunare in metodi dal nome esplicito (operational methods) i dettagli di inizializzazione dello scenario del test
• se il test prevede, come nel caso si utilizzi DBUnit l'uso di file di inizializzazione, magari in XML, parametrizzarne la creazione rendendone chiaro l'intento all'interno del test

Francesco Mondora: vivere in un angolo proattivo

Francesco Mondora nel corso della sua presentazione ha detto di apprezzare eventuali riscontri da parte del pubblico. Ecco quindi il mio, che è purtroppo negativo. Il tema trattato mi è apparso fumoso, ed il tono ieratico utilizzato era probabilmente fuori luogo. Ma forse il problema è solo mio che non sono riuscito a capire cosa si volesse comunicare...

Alberto Brandolini - Introduzione al Domain Driven Design

Ecco un'altra gran bella sessione, nella quale Brandolini ha descritto con abilità e preparazione i principi del Domain Driven Design.

Entrare nel dettaglio di quanto visto è molto difficile, data la mole di informazioni trasmesse. Mi piacerebbe comunque segnalare il concetto di Bounded context, ossia il limite entro il quale il significato di un'astrazione del dominio è non ambigua, o, per usare una visione più orientata al codice, il limite di applicabilità di un gruppo di classi del sistema. Mi sono imbattuto in questo problema quando, nella mia presentazione su Scala, ho parlato di oggetti che ingrassano a dismisura. Da quanto ho capito, anche nel DDD ci si occupa di questo problema, ma da una prospettiva "sistemica": occorre definire l'ambito entro il quale è opportuno riutilizzare il codice che definisce un'astrazione. All'esterno di tale ambito è meno costoso riscrivere parte delle astrazioni ed accettare una certa duplicazione nei sistemi. Il tema, interessante e complesso, è alla base del fallimento di grandi utopie Object Oriented come il progetto San Francisco di IBM. Anzi, a mio avviso mette in discussione tutti i miti dell'Object Orientation a partire dalla riusabilità, ma forse converrà parlarne in un'altra occasione.

Conclusioni

Anche quest'anno l'Italian Agile Day non ha deluso le aspettative: relazioni quasi tutte di altissimo livello, con l'apprezzabile idea di aprire a contributi internazionali. Se proprio si vuole fare un piccolo appunto, si dovrebbe parlare di un'eccessiva enfasi posta sugli aspetti di processo a scapito delle sessioni "pratiche", anche se, come avete potuto leggere, i "puri" sviluppatori come me non hanno avuto occasione di annoiarsi.

Grazie a Marco Abis ed ai ragazzi dell'XPUG Bologna per l'enorme e riuscitissimo sforzo organizzativo.
(Ah, avete già donato qualcosa all'Agile Day? )

The way of organizing the code I will show in this post is very common, but, perhaps, it's useful to give it a name, and I will call it the "functional setter java idiom". Let's see.

In java there are no named parameters, i.e. parameters that I can pass to a method in the order I like calling them with their name. For example in Visual Basic for Applications we can sort some Excel cells this way:

 
SelectedSheets.PrintOut Copies:=1, _
    Preview:=True, _
    PrintToFile:=True, _
    Collate:= True
 

Note that the order in which I set the parameters is arbitrary, and that some parameters can be omitted, having it assigned with default values.

Now let's suppose we need to create an object with a long series of parameters (OK, I know, it's a code smell, but, please, close your nose for a while):

 
PrintType printType = new PrintType(1, true, true, true);
 

Well, not a good piece of code! Especially the sequence of boolean parameters is a mess. Moreover, sometimes I'd like to create my object with less parameters, having the others set with default values. I could create many constructors, but this would increase the complexity of my program.

I could solve the problem using some setters:

 
PrintType printType = new PrintType();
printType.setCopies(1);
printType.setPreview(true);
printType.setPrintToFile(true);
printType.setCollate(true);
 

Uhmm, better enough, but what if I need to assign my object to a constant, i.e. a final static field? I should write:

 
public final static PrintType DEFAULT_PRINT = new PrintType();
 
static {
	DEFAULT_PRINT.setCopies(1);
	DEFAULT_PRINT.setPreview(true);
	DEFAULT_PRINT.setPrintToFile(true);
	DEFAULT_PRINT.setCollate(true);
}
 

Mamma mia, this code is ugly! Maybe I could improve it just a bit using some functional setters, i.e. setters that have a return value, as a function. In the PrintType class I should write:

 
public PrintType setCopies(int copies) {
	this.copies = copies;
	return this;
}
 
public PrintType setPreview(boolean value) {
	this.preview = value;
	return this;
}
 
public PrintType setPrintToFile(boolean value) {
	this.printToFile = value;
	return this;
}
 
public PrintType setCollate(boolean value) {
	this.collate = value;
	return this;
}
 

Now the initialization of my static field becomes:

 
public final static PrintType DEFAULT_PRINT = new PrintType()
	.setCopies(1)
	.setPreview(true)
	.setPrintToFile(true)
	.setCollate(true);
 

This is not so bad, don't you think?

In questo post mostrerò la mia discutibilissima soluzione all’RDS Kata proposto sul blog di SI-Agile, il vivace gruppo che raccoglie gli agilisti della Svizzera Italiana. Il codice è presente in questo file zip, spero a breve di creare un progetto su Google Code per ulteriori sviluppi.

Funzioni di utilità

Partiamo subito con la prima sequenza di test.
Leggendo tutti i requisiti del Kata, ho pensato fosse necessario avere in primo luogo una funzione che centrasse le stringhe secondo le specifiche. Ho pertanto creato dei test per un metodo statico center da inserire nella mitica classe di utilità StringUtils, che non può mancare in qualsiasi progetto Java. Il primo banale test, testCenterDoesNotChangeTooLongStrings, mi è servito per disegnare l’interfaccia del metodo. Per scrivere i test successivi mi è sorta la necessità di avere una funzione blanks, che, guarda caso, mi è poi tornata utile anche nel codice di produzione. Ho deciso di non scrivere un test specifico per blanks, avendo fiducia che, una volta creata correttamente la funzione stringOf, la sua specializzazione che creasse stringhe di spazi fosse banale.
Uso qui volutamente il termine di funzione, in quanto questi metodi hanno la proprietà di trasparenza referenziale, ovvero restituiscono sempre gli stessi valori a fronte dei medesimi ingressi, indipendentemente da un qualsiasi concetto di “stato” del sistema; inoltre non hanno alcun effetto collaterale. Se ci fosse la possibilità di utilizzare i metodi statici come parametri di altre funzioni…
Concludendo le divagazioni, vorrei solo annotare che, per migliorare la leggibilità del codice e ridurre le duplicazioni, ho fatto un po’ di refactoring sui test estraendo il metodo assertCenterReturnsAStringOfFixedLength.

Le classi principali

Sono poi passato al disegno principale della mini applicazione tramite i test di RDSGeneratorTest che ho cercato di rendere indipendenti dal numero di caratteri del display.
Leggendo le specifiche del Kata ho cercato di elaborare una metafora: le varie parti da mostrare sul display (autore, data, titolo) sono gruppi distinti di parole, ovvero delle frasi. Ho quindi stilato i test di RDSSentenceTest, facendo anche in questo caso attenzione a rendermi indipendente dalla lunghezza del display. La prima stesura della classe RDSSentence, che comunque supera tutti i test, è stata la seguente:

 
public class RDSSentence {
 
  private final String sentence;
  private final int displaySize;
 
  public RDSSentence(String sentence, int displaySize) {
    this.sentence = sentence;
    this.displaySize = displaySize;
  }
 
  public String[] tokens() {
    if ("".equals(sentence.trim())) {
      return new String[]{};
    }
 
    String[] tokens = sentence.trim().split("\\s+");
    if (tokens.length == 0) {
      return new String[]{};
    }
 
    Collection<String> result = new ArrayList<String>();
    StringBuffer accumulator = new StringBuffer();
    for (int i = 0; i < tokens.length; i++) {
       if (accumulator.length() + tokens[i].length() + 1 <= displaySize) {
         if (accumulator.length() > 0)  {
           accumulator.append(" ");
         }
         accumulator.append(tokens[i]);
       } else {
         if (accumulator.length() > 0) {
           result.add(accumulator.toString());
         }
         accumulator = new StringBuffer(tokens[i]);
       }
       if (i == tokens.length -1) {
         result.add(accumulator.toString());
       }
    }
 
    return result.toArray(new String[]{});
  }
 
}
 

Come potete vedere, il codice è troppo complesso, con un numero ciclomatico molto elevato. Per un buon refactoring occorreva un’altra metafora: il display che accumula parole fino ad una certa lunghezza può essere appunto visto come un accumulatore elettrico, o, se vogliamo, idraulico che, raggiunta la capienza, si svuota in un tubo di scarico. Sono nate così le classi Accumulator e StringWharehouse, che non hanno test autonomi, ma vengono esercitate indirettamente dai test di RDSSentenceTest. La classe StringWharehouse, con una leggera modifica, mi è poi stata utile per migliorare il MockRadioStation, che in un primo tempo accumulava i dati in un semplice StringBuffer.

Conclusioni

Cosa ho cercato di esercitare con questo Kata?

• L’uso di metafore come guida per lo sviluppo.
• La costruzione di test robusti ad eventuali modifiche delle specifiche.
• La costruzione di codice di test leggibile e manutenibile quanto il codice di produzione.

Sicuramente non ho raggiunto completamente i miei obiettivi, spero comunque di aver fatto un piccolo passo in questa direzione.

Troppo spesso i sostenitori delle metodologie agili si fanno trasportare dall'entusiasmo, e, quando cercano di convincere qualche collega ad abbracciare l'agilismo, si lasciano scappare frasi come Quando inizierai a fare i test unitari vedrai che la tua produttività aumenterà. Niente di più falso: iniziare a scrivere i test unitari abbassa drammaticamente la produttività! Per quale motivo? Ho vissuto l'esperienza sulla mia pelle, ma la chiara consapevolezza delle ragioni del fenomeno mi è arrivata quando ho collaborato alla revisione di un ottimo volume pubblicato da Manning: The art of unit testing. Questo è il primo libro che abbia letto a mettere in evidenza un fatto spesso taciuto: i test unitari hanno un costo enorme, specialmente se non vengono scritti nel modo corretto.
Il costo dei test non risiede solamente nel tempo speso per la loro scrittura, ma, come per qualsiasi pezzo di software, soprattutto nello sforzo necessario per la loro manutenzione. Vi è inoltre un'altro aspetto da considerare nell'introduzione dei test unitari: il codice deve essere scritto in modo differente, secondo un design che consenta la testabilità. Questo, però, porta generalmente ad un miglioramento netto della qualità del software, anche se potrebbe indurre qualche programmatore maldestro in inutili complicazioni.
Dunque, perché i test unitari possono divenire una palla al piede? Perché il neofita generalmente non è in grado di scrivere test che abbiano le seguenti caratteristiche:

• Affidabilità
• Manutenibilità
• Leggibilità

Affidabilità

Come dicevo, i test unitari, anche se scritti bene, anche se generati automaticamente, costano. Quelli scritti male costano enormemente di più, ma tutti hanno in ogni caso un costo, quello della loro manutenzione. Siamo comunque invogliati a pagare un prezzo anche salato quando riceviamo in cambio un beneficio maggiore. Il beneficio dei test, oltre al già citato obbligo ad elaborare un design più efficiente, consiste nella loro affidabilità, che dovrebbe rispecchiare l'affidabilità generale del nostro software. Un test dovrebbe fallire se, E SOLO SE, esiste un errore nel software di produzione. Se il test fallisce anche per altre ragioni (un baco nel test, il DB che non è stato inizializzato opportunamente, il fatto che il test funzioni solo sul sitema operativo della mia macchina e non su quello che usano i miei colleghi), allora stiamo buttando dei soldi dalla finestra. Inoltre il test dovrebbe fallire in caso di errori. E' ovviamente impossibile riuscire a scrivere un test per tutti i possibili errori, ma questo dovrebbe essere il nostro obiettivo. Scrivere il test prima del codice, per poterlo vederlo fallire, è una tecnica che ci aiuta in questo senso.

Manutenibilità

Questa è la bestia nera dei test unitari. In molti casi è già un affare raggiungere l'affidabilità, la manutenibilità è in molti casi una chimera. Si dice spesso, a ragione, che dei buoni test aiutano il cambiamento del software. Test scritti male possono essere invece un ostacolo all'evoulzione del nostro programma. Quante volte ho visto andare in barra rossa decine di test per una piccola modifica nel protocollo di comunicazione con un oggetto! Come poter raggiungere questo obiettivo?

In primo luogo con il refactoring accurato del codice di test. Rimuovere duplicazioni dai test è fondamentale per non dover cambiare manualmente tonnellate di codice alla prima modifica nel nostro design.
Un altro punto chiave è quello di cercare di non testare lo stato privato di un oggetto, ma di verificarne il funzionamento in relazione ai suoi collaboratori (trasformati in opportuni Stub o Mock). Se questo non è possibile, allora potrebbe valere la pena di estrarre il comportamento nascosto in oggetti da testare separatamente.
Si deve inoltre fare attenzione a non testare più di quanto sia necessario: l'uso eccessivo di Mock quando degli Stub potrebbero essere sufficienti può farci incorrere in questo problema.

Leggibilità

La leggibilità dei test è fondamentale. Quando va in barra rossa un test illeggibile è come quando si accende una spia sconosciuta sul cruscotto di una macchina di cui non avete il libretto di manutenzione: o andate nel panico, o fate finta di nulla incrociando le dita e sperando che tutto vada bene.
Occorre curare i nomi dei test, senza aver paura di scrivere troppe lettere. testCarrello non significa nulla, testSeAggiungoUnProdottoAlCarrelloAumentaIlTotale indica chiaramente l'intento del test. Altri accorgimenti sono estrarre fasi di inizializzazione in medodi di servizio con nomi espressivi, definire il metodo toString in modo tale che mostri valori significativi in caso di fallimento, evitare di inserire magic numbers e, anche in questo caso, refactoring, refactoring, refactoring!

Conclusioni

Quindi non dobbiamo scrivere test, dobbiamo abbandonare il Test Driven Development (TDD)? No, al contrario, dobbiamo scrivere test con sempre maggiore cura, avendo ben chiaro che i test sono come i figli: non basta farli, poi bisogna anche mantenerli!

E' stata annunciata la data per lo svolgimento del sesto Italian Agile Day: si terrà il 20 novembre 2009 a Bologna. Come sempre la conferenza si annuncia interessantissima: vi darò aggiornamenti nei prossimi giorni.

E' stata una coincidenza fortunata. Nei giorni scorsi stavo scrivendo del codice, per la prima volta da tempo del codice altamente algoritmico. Da bravo scolaretto XP, avevo creato una serie completa di test, avevo rifattorizzato estraendo metodi, rinominando variabili, abbassando il numero ciclomatico. Le classi erano piccole, i metodi corti, eppure il codice, pur funzionando egregiamente, in qualche modo mi infastidiva.
Poi alla scorsa riunione dell'XP-UG di Milano, Matteo Vaccari ha parlato brevissimamente dell'argomento, ed è stato illuminante. Da qui il suo interessante post.
In particolare una frase pesa come un macigno su quanti, come me, pensano di essere agili solo perché fanno TDD (o qualche altra pratica XP):
"TDD could be a crouch that allows you to give up finding a good design and settle for a mediocre one".
Puoi fare tutto quello che dice il libro bianco di Kent Beck, ma forse non ti accorgi che c'è una tessera mancante....

In a very interesting interview, Martin Odersky said that Scala could be a little more difficult than Java for newcomers because in it you have not to write boilerplate code, but you have to think at your problem just from the first line of code. In some way, boilerplate code could be a kind of "warming up" for beginners. Writing some code, even if it's only syntactic noise, could give confidence to the programmer, generating a feeling of accomplishment.

But, is there a way to warm up without writing silly code? The best way of doing this is with unit testing. In TDD by example , Kent Beck describes "Starting tests": Start by testing a variant of an operation that doesn't do anything. Using these tests, not only you can start exploring your design, but you can also break the "white sheet syndrome".

Sì, va bene, avrei voluto commentare in diretta l'Agile day 2008, ma non ci sono riuscito per merito degli organizzatori: troppe le cose interessanti da seguire per poterle riportare immediatamente!
Cercherò quindi di dare il mio personalissimo riassunto a posteriori, che intende essere più un taccuino di viaggio che un'analisi accurata dei tantissimi stimoli ricevuti nella manifestazione. I protagonisti dei vari incontri non me ne vogliano se non sono riuscito a recepire esattamente quanto volevano esprimere

Agile e pragmatic: sinonimi o contrari?

La giornata è iniziata discutendo su "Agile e pragmatic: sinonimi o contrari?". Stimolo per il dibattito è stato un comune sentire che si sta facendo strada nell'ambiente Agile, emergente anche dagli ultimi thread della mailing list XP-it (e su cui mi sono permesso di scrivere un breve post). La sensazione è che nelle pratiche agili ci sia qualcosa da rivedere, pur non essendoci accordo sul cosa. Qualcuno pone l'accento sul dogmatismo con il quale esse sono a volte presentate. Altri sul fatto che, come in tutti i fenomeni diventati di massa, ci siano state delle cattive interpretazioni. Un altro dubbio riguarda la possibiltà di applicare solo in parte queste tecniche, senza che la mancata introduzione di una renda inutili tutte le altre. I più maligni (che però non hanno preso parte all'Agile Day ) arrivano a supporre che qualcuno abbia sfruttato la moda per interesse personali. La mia modestissima opinione è che effettivamente alcuni punti cardine dello Sviluppo Agile possano generare dei dubbi. In primo luogo mi chiedo se il design emergente sia in ogni situazione un valido sostituto del design preventivo, termine con cui non intendo la produzione di valanghe di documentazione e grafi UML che descrivono ogni metodo del progetto, ma una fase di analisi del "cosa fare" e "come farlo" proporzionale all'entità dell'impresa, analisi che potrebbe richiedere anche la generazione di documentazione di corredo. Mi domando inoltre se la programmazione agile sia veramente alla portata del programmatore medio, o richieda delle capacità fuori dal comune.
La maggiore prova a sostegno della bontà dell'approccio agile penso comunque sia stata portata da Simone Genini. Se un imprenditore come lui, che non fonda il proprio business sulla evangelizzazione dell'agilismo, bensì sulla consegna al cliente di codice funzionate, continua a scommettere da anni, pare anche con successo, su questi metodi di lavoro, allora si potrebbe financo pensare che funzionino veramente!

Refactoring di codice Legacy

La mia seconda tappa è stata il bellissimo workshop di Tommaso Torti e Fabiana Romagnoli su "Refactoring di codice Legacy". Cosa ho imparato? Che anche il refactoring deve misurarsi con il tempo e le risorse a disposizione. Il codice proposto presentava infatti diversi aspetti suscettibili di miglioramento, ma un limite insuperabile era costituito dai venti minuti a disposizione. Ci si poteva concentrare sull'eliminazione di numerosi "if" tramite l'utilizzo del polimorfismo, oppure lavorare sulla chiarezza del codice cancellando duplicazioni, rinominando variabili ed assegnando correttamente le responsabilità alle classi. Il primo refactoring sarebbe stato sicuramente più pirotecnico, ma probabilmente non avremmo avuto né il tempo, né le energie (ci siamo alzati alle cinque) per portarlo a termine. Il secondo, molto più banale, aveva invece il vantaggio di riuscire comunque a consegnare valore al cliente (nel nostro caso Tommaso e Fabiana) nel tempo stabilito.

Tool for agile planning and estimation

Altro workshop molto interessante è stato quello condotto da Simone Casciaroli. Lo strumento per la pianificazione agile proposto, chiamato ora Stuffplanner, pur essendo in versione alpha, ci è sembrato molto potente. Cosa ho imparato? Tutto, dato che sono assolutamente un novizio della pianificazione agile. Ecco i miei appunti ad uso principianti.

- E' importante suddividere il progetto in "storie" quanto più indipendenti fra loro al fine di evitare che una di esse costituisca un collo di bottiglia per lo sviluppo delle altre. Esse dovrebbero inoltre essere "verticali", ovverosia comprendere una funzionalità completa, dalla GUI al DB, per rappresentare una unità atomica di valore rilasciabile al cliente. In tal modo questi potrà valutarne correttamente la priorità all'interno della fase di pianificazione ed avremo sempre dei rilasci che aggiungono valore al prodotto.

- Un formato standard per le storie è: As a....I want...so that.....
As a... indica lo scenario di utilizzo che si immagina per la storia, per esempio Come utente esperto.
I want... indica il contenuto vero e proprio della storia, per esempio io voglio cercare un libro per ISBN.
Nella clausola so that.. si dovrebbe rendere esplicito il valore che la storia possiede per il cliente, al fine di aiutarlo nell'attribuzione del giusto peso durante la fase di pianificazione. Nel nostro esempio avremmo così da poter comprare un libro in brevissimo tempo.

- Una storia non dovrebbe occupare il team per più di due giorni, per evitare che il grafico di avanzamento lavoro (burndown chart) rimanga stabile per troppo tempo, abbassando il morale degli sviluppatori.

- La stima di una storia dovrebbe essere svolta preferibilmente in "story point", una misura di difficoltà relativa. Per esempio, "se si indica con 1 la difficoltà di sviluppo della storia più semplice, allora la storia X avrà peso 7". Il passaggio dagli "story points" al tempo reale dovrebbe essere realizzato analizzando lo storico delle iterazioni precedenti. Alla prima iterazione occorre solo confidare nell'esperienza dei membri del team.

- La stima di una storia non è un valore singolo, ma una curva di probabilità di consegna: suppongo che non ci sia alcuna probabilità di realizzare la storia in meno di x story point (valore minimo), mi aspetto che ne serviranno y (valore atteso), penso di essere certo di consegnarla dopo z story point (valore massimo). Tutti gli elementi del team esprimono queste tre valutazioni. Per determinare il peso da assegnare alla storia, che è un singolo numero, si possono scegliere diverse funzioni di interpolazione di questi dati, fissando inoltre una soglia di rischio: ad esempio potrei scegliere il valore della curva di probabilità che mi garantisca una affidabilità dell'80%. Uno strumento come Stuffplanner è di ausilio in questa fase.

- Se è ovviamente importante non sottostimare le storie, è altrettanto pericoloso sovrastimarle. Il team, infatti, vedendo che la propria velocità è molto maggiore del previsto potrebbe rilassarsi troppo e perdere concentrazione.

Processo al database server relazionale

Purtroppo ho potuto assistere solo ai momenti finali di questa divertente presentazione/rappresentazione, svolta con notevole capacità teatrale. Due brevi note da innocentista.
Come prova a carico del DB relazionale è stata portata una stored procedure, realmente messa in produzione, che occupava diverse pagine. A mio avviso le stored procedure non hanno un legame essenziale, oserei dire ontologico, con la struttura di un DB relazionale. Sono solo un posto, quasi sempre sbagliato, dove mettere del codice che lavora sui dati relazionali. La loro esistenza non è strutturalmente legata a tale modello. Il fatto che molti programmatori poco avveduti ne abbiano abusato non è sufficiente a dire che il modello relazionale sia negativo.
Un'altra critica mossa al DB è quella che lo vorrebbe d'impiccio nella fase di stesura dei test. Se da un lato questo è sicuramente vero, dall'altro occorre forse ristabilre una giusta proporzione tra le cose. Ricordiamo sempre che i test non sono un fine, ma solo un mezzo. Dobbiamo trovare il modo per testare meglio l'uso del DB, cercando di evitare che la parte di accesso ai dati contenga troppa logica, ma ciò non può scalfire la validità dell'approccio relazionale nella grande maggioranza dei casi.
Quando qualcuno parla male dei database, io ricordo sempre che lavoro da anni su un DB che è stato alimentato, interrogato e spippolato da programmi scritti in una decina di linguaggi diversi. I linguaggi sono cambiati, i programmi sono stati riscritti, ma la struttura del DB, ben congegnata, è rimasta. Diceva Cicerone Programmata volant, Datarum Basae manent

Uso dei Kanban, ovvero quando stimare è impossibile

Questo è stato il titolo di un open space fuori programma tenuto da Gabriele Lana.
Se non ho inteso male, il punto di vista di Gabriele è il seguente. In particolari situazioni, dove ad esempio il dominio del problema sia particolarmente difficile o inusuale, oppure dove vi sia una grossa dipendenza da programmi o prodotti sviluppati da terzi fuori dal nostro controllo, effettuare delle stime dei tempi di realizzazione è semplicemente impossibile. Non solo, ma la stima potrebbe risultare controproducente rispetto all'affidabilità del software. I programmatori potrebbero infatti cercare di abbassare la qualità (copia e incolla selvaggio, mancata stesura di test, design approssimativo e mancanza di refactoring) pur di rimanere all'interno dei tempi previsti. In questi casi l'approccio migliore sarebbe quello di stendere delle user story, che potremmo ora definire Kanban, che avrebbero solo la funzione di ordinare i lavori in base alla priorità e determinare lo stato di avanzamento degli stessi.
E la stima di tempi e costi? Visto che in ogni caso in queste situazioni una qualsiasi stima sarebbe solo una bugia, meglio concordare con il cliente un tipo di contratto flessibile, con punti di verifica frequenti ove poter eventualmente cambiare direzione.

Conclusioni

L'agile day si è confermato un grande evento. Un grosso ringraziamento a chi si è preso l'onere dell'organizzazione ed un arrivederci all'anno prossimo!!!

In un post molto interessante di James Shore leggo "Because Scrum works in short cycles and doesn't include any engineering practices, it's very easy for teams using Scrum to throw out design. Up-front design doesn't work when you're using short cycles, and Scrum doesn't provide a replacement. Without continuous, incremental design, Scrum teams quickly dig themselves a gigantic hole of technical debt."
Ovviamente l'autore pensa che ciò sia dovuto ad un cattivo impiego di Scrum, nel quale vengono tralasciate le seguenti pratiche:

• spazi di lavoro condivisi o tecniche che enfatizzino al massimo la comunicazione;
• contatto strettissimo con il cliente;
• gruppi di lavoro interfunzionali;
• pratiche di ingegneria del software prese da XP (EXtreme Programming): penso a refactoring, TDD, continuous integration.

Ma ciò sarà davvero sufficiente a colmare il debito tecnologico maturato con l'abbandono dell'up-front design?
Qualcosa su questi temi si sta muovendo, ne sia prova il recente thread sulla lista extremeprogramming-it dal titolo Perche' il design emergente non e' robusto?. Ovviamente scopo del thread era quello di cercare di confutare questa tesi, ma mi sembra che in ogni caso dei dubbi stiano emergendo.

Ora devo scappare, ma concludo segnalando un questo post al vetriolo sull'argomento. Forse qui si esagera, però.....