Franco Lombardo

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.

Sometimes I hear sentences like Domain Specific Languages (DSL) can be generated effectively only using dynamic languages, or This super-cool feature could not be possible in a static typed language. More and more, some people would transmit the idea that dynamic languages are agile and cool, while static ones are rigid and old. I strongly disagree! I think that in static languages lots of unit tests are generated and maintained automatically by the compiler, while in dynamic ones the programmer should create and maintain these tests. So static languages have lots more unit tests: isn't this agile programming? And what about cool features? Well, what do you think about a language in which you can write something like this?

 
(5.0 USD) + (2.0 USD) == (7.0 USD)

Cool DSL, isn't it? Sure, and I will show you that this is possible (and very easy) using a language with a strong and static type system: Scala.

As we are going to write yet another money example, we could begin with the definition of currencies.

 
abstract class Currency {
  def name: String;
  override def toString = name
}    
 
object Euro extends Currency {
  def name ="EUR"
}    
 
object Dollar extends Currency {
  def name = "USD"
}

Not very exciting. We simply define an abstract Currency class and two singleton objects that extend this class. Note that these objects are instances of anonymous subclasses of Currency. This does matter, as we'll see in a moment.

Now let's define money.

 
case class Money[C <: Currency](amount: Double, currency: C) {
  def + (otherMoney: Money[C]) = {
    new Money(amount + otherMoney.amount, currency)
  }
  override def toString = amount + " " + currency
}

Our class is parametric in the type C, and we tell to the compiler that it must be a subclass of Currency. This way we have the nice consequence that the + operator can add only money of the same currency, and this test is done by the compiler before our code is running.

It's time to get to the cool feature: implicit conversion. So, in the same file Money.scala in which we defined the Money class, we create a Money object, which has the responsibility to convert doubles, let me say, "annotated" with a currency, into Money.

 
object Money {
  implicit def doubleConverter(d: Double) = new {
    def EUR = {
      new Money(d, Euro)
    }    
 
    def USD = {
      new Money(d, Dollar)
    }
  }
}

Uhm, it sounds a bit strange. How we can use it? Let's see an example.

 
import Money._    
 
object MoneyMainProgram extends Application {    
 
  val tenDollars = (4.0 USD) + (6.0 USD)     
 
  println(tenDollars)
}

Now some explanations are required.

In the first line we import the Money object. We can see it as a kind of static import, that, among other things, adds to the scope of our code all the implicit conversions defined in that object.

When we write 4.0 USD, we try to invoke the USD method on the 4.0 object, which is a double. Obviously there isn't such a method in the Double class, but the compiler, before giving up and throwing an error, tries to see if there is some way to convert the 4.0 in an object that does understand the USD method. Luckily we have imported the doubleConverter which takes a Double and transforms it in an instance of an anonymous class with a USD method: bingo! So the compiler transforms our code in something like this:

 
  doubleConverter(4.0).USD()

But what is the result of this expression? Well, it's an instance of the Money class expressed in Dollar. This class has the + method that we can use to add another Money in the same currency. Cool!

Let's take a look to our work. We needed to add some features to the Double class. In some dynamic languages we could monkey patch this class. In Scala we did it using a dynamic conversion from Double to a class with the methods we need, so we reached the same purpose in a static and safer way.

And so, an old fashioned static language could have such cool features? It seems....

Nel volume che appena terminato di leggere, Lean software development di Mary e Tom Poppendieck, ho trovato una frase illumninante.

Un tipico sistema è costituito per il 64% da funzionalità usate raramente o è del tutto inutilizzate, il che suggerisce che il terreno più fertile per il miglioramento della produttività dello sviluppo software stia nel non implementare funzionalità non necessarie.

Anche due semplici, ma inutili, campetti aggiunti su una maschera di immissione dati contribuiscono ad abbassare la produttività. Generano infatti una buona dose di spreco (Eliminare gli sprechi è il principio numero uno del "Lean development"):

• sprecano il tempo necessario per codificarli e per testarne il funzionamento;
• sprecano il tempo necessario per il caricamento dal database, nonché per il loro salvataggio;
• sprecano spazio sul database;
• sprecano spazio sulla maschera video, costringendo chi la disegna a difficili compromessi per non uscire dai margini dello schermo;
• sprecano tempo per la loro documentazione, se esiste ;
• sprecano il tempo del personale di supporto che è costretto a ricercare le ragioni, inesistenti, della loro presenza per rispondere ai quesiti del cliente;
• sprecano la fiducia che il cliente ha nei confronti degli sviluppatori (che fiducia possiamo avere in chi spreca tanto per costruire un sistema così inutilmente complesso?).

A seguito del bel seminario di Simone Casciaroli "Tool for agile planning and estimation" all'Agile Day 2008, di cui ho già parlato, il mio piccolo gruppo di sviluppatori ha deciso di sperimentare la stima agile dei progetti.
Sentendoci dei novizi, abbiamo pensato di utilizzare come unità di misura delle storie le vecchie care ore di lavoro e non gli Story points. Abbiamo anche semplificato il processo di determinazione delle stime: ogni persona deve indicare il tempo minimo e massimo che ritiene necessario per la realizzazione della storia. Vengono quindi elaborate le medie dei tempi minimi e dei tempi massimi e si utilizza come stima ufficiale l'80% dell'intervallo così ottenuto:

(media(massimi) - media(minimi)) * 0,8 + media(minimi)

ll tutto è stato elaborato tramite un banalissimo foglio di Excel.
Attendiamo di vedere i risultati

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!!!