lunedì 30 luglio 2012

Non molto Agili... fin qui!

Navigando sul sito http://agilemanifesto.org mi sono accorto che sono passati otto anni da quando firmai il manifesto sullo sviluppo agile.



Cos'è successo in questi otto anni? Si fa un gran parlare, è vero, delle tecniche di sviluppo agili e termini come Scrum ed eXtreme Programming sono molto di moda, ma di fatto nella realtà enterprise - specie in quella italiana - continuano a non vedersi progetti sviluppati secondo la filosofia Agile dello sviluppo del software. Viceversa, nel mondo Open Source, l'Agile è di fatto la norma.

Spesso si vedono applicate le tecniche agili, come ad esempio Pair programming o Feature Driven Programming, ma in contesti che sono quelli tradizionali, e cioè quelli dello sviluppo waterfall, che nella realtà enterprise è tuttora l'unico modello supportato.

Frequentemente ho proposto di utilizzare un approccio Agile in diversi progetti reali, ma al di là di un qualche superficiale apprezzamento non si è mai andati.

Perché dunque, nonostante l'entusiasmo, specie degli addetti ai lavori, la metodologia Agile non ha preso piede? Io credo che le cause siano principalmente tre.

1. Il sistema non recepisce processi iterativi

Quello che caratterizza principalmente l'approccio Agile rispetto al Waterfall è il suo essere iterativo by design. Il progettista Agile sa che lo sviluppo software è spesso un processo "prima volta-primo uso", caratterizzato da un altissimo grado di incertezza, per affrontare il quale deve applicarsi una metodologia di gestione del rischio che non può che essere iterativa. L'iterazione tipica dell'Agile è quella indicata in figura:


Normalmente, in un progetto complesso, le iterazioni possono essere decine. Ma il "sistema" non è in grado di gestire le iterazioni! Se da una parte il Cliente vuole subito sapere quanto costerà il suo nuovo sistema informativo e quanto durerà il suo sviluppo, anche dall'altra il Fornitore ha tutta una serie di strumenti che funzionano solo se vengono immessi valori "a preventivo": quante risorse il progetto occuperà e per quanto tempo. Come ho riportato in altri post, la stima del costo (tempo, denaro e altre risorse) di un progetto "prima volta-primo uso" è un esercizio di fantasia destinato al fallimento. Tipicamente perciò chi fornisce un servizio di sviluppo software applica dei coefficienti di rischio molto alti proprio per cercare di assorbire questa incognita. Di fatto, nei sistemi dove è "necessaria" una stima dei costi a preventivo, il metodo Agile è escluso a priori.


2. Un processo che ricicla è considerato un processo di "serie B"

Nella concezione del Project Management classico,  il "riciclo" - quindi la re-iterazione - è considerato come un "difetto", o meglio come la "conseguenza di un difetto". Il progetto perfetto non presenta ricicli: viene eseguito così com'era stato pensato la prima volta. Per chi non possiede una cultura informatica (direi, una cultura informatica recente) l'idea stessa che una metodologia preveda molti ricicli è semplicemente orrenda. E' orrendo dover immaginare di avere stime riviste, nuove implementazioni e nuovi test ad ogni riciclo. Impensabile immettere ad ogni nuova iterazione nuove funzioni e quindi nuovi bug! Il Cliente percepisce il metodo Agile come una mancanza di professionalità (non sviluppano: provano a sviluppare!) e lo staff non tecnico del Fornitore la percepisce come una intollerabile mancanza di certezze: quanto ci costerà il progetto, quante risorse impiegherà e per quanto tempo.
Bisogna però fare i conti con la dura realtà: che è tanto più vera e documentata quanto più i progetti aumentano in complessità e novità: all'inizio nessuno può sapere quanto costerà il progetto, nemmeno a grandi linee. Si possono fare delle stime, sulle quali però non può essere calcolato il prezzo al Cliente. Proprio per la grande aleatorietà di queste stime "a-priori", il prezzo sarà o largamente esagerato per assorbire il rischio, o sottostimato destinato cioè ad andare in perdita. Come dicevo, i sistemi (finanziari, di controllo e gestione e via dicendo) aziendali prevedono che questo prezzo venga calcolato all'inizio, sulla base del quale verranno poi derivati tutti i driver economici dell'azienda. Un calcolo basato, il più delle volte, sulla fantasia.


3. La metodologia Agile presuppone il Time&Materials

Esistono tipicamente due modi per vendere un servizio informatico: a pacchetto (turn-key o fixed bid) o a tempo (time&materials, T&M). Nel primo, chi offre "scommette" su quanto effettivamente gli costerà il servizio: applica alla scommessa il proprio coefficiente di profitto e ottiene il prezzo. Nel secondo, semplicemente vengono erogati dei servizi e il Cliente paga "il tempo" di erogazione.
Per quanto abbiamo detto sin qui, la metodologia Agile presuppone la seconda opzione. Perché per poter vendere qualcosa turn-key occorre essere confidenti sulla stima dei costi, cosa che abbiamo visto è molto difficile nel caso di progetti complessi. E perchè l'Agile è iterativo di suo.
Il committente di un progetto informatico complesso è molto poco propenso a iniziare a lavorare T&M, perché anche lui deve fornire una stima di quali saranno i suoi costi/tempi, e questo a priori! La naturale conseguenza di questo stato di cose è che si formulerà un'offerta turn-key molto sovrastimata nei costi, ed esageratamente lunga nei tempi.


Io credo che queste tre siano le cause principali che hanno bloccato l'introduzione dei modelli Agili nella pratica dello sviluppo software a livello enterprise. Sono convinto che un approccio iterativo e T&M possa permettere significative economie sia per chi vende, sia per chi compra soluzioni software. Tuttavia, perché lo sviluppo Agile possa essere effettivamente utilizzato, occorrono notevoli cambiamenti in termini di cultura, processi e strumenti di supporto aziendali.



venerdì 13 luglio 2012

Ajax + Prototype + CoffeeScript

In rete abbondano gli esempi CoffeeScript per chiamate Ajax con la libreria jQuery. Se uno - come me - preferisce Prototype, è abbandonato al proprio destino.

Perciò pubblico qui sotto l'esempio di una pagina CoffeeScript con chiamate Ajax in Prototype.

//= require prototype

pe = null

invitations_args =
  method: 'get'
  onSuccess: (transport) ->
    inviter = transport.responseText
    if inviter.length > 1
      $('invitation').show()
      $('proposal').update
             (inviter + ' invites you to join a game:')
      pe.stop()
      return
  onFailure: ->
    $('invitation').show() 
    $('proposal').update('Error retrieving invitation')
    return

invitations = ->
  new Ajax.Request 
      '/player/lookforinvitations', invitations_args
  
main_loop = ->
  pe = new PeriodicalExecuter( invitations, 3 )

Event.observe(window, 'load', main_loop)


La parte principale (main_loop) è invocata sull' onLoad della pagina HTML. Qui, un PeriodicalExecuter esegue una chiamata Ajax ogni tre secondi ad un metodo (/player/lookforinvitations) che cerca se sul database qualcuno ci ha invitato a giocare. Se sì la pagina mostra un messaggio: ad esempio: Pippo ti invita a giocare con lui, e ferma il processo PeriodicalExecuter. Altrimenti la pagina continua ad inviare richieste Ajax al server finchè l'utente non cambia pagina.

(Una cosa interessante e che mi ha fatto perdere molto tempo è che anche in CoffeeScript l'ordine in cui vengono definite le funzioni è importante!! Se mettete ad esempio Event.Observe all'inizio del file, otterrete un errore di oggetto undefined: l'oggetto in questione è main_loop, che viene definito solamente più sotto!)




mercoledì 11 luglio 2012

CoffeeScript e le var locali


CoffeeScript è un linguaggio moderno, sintetico ed efficace che compila in JavaScript. Nei progetti web complessi, l'uso di CoffeeScript si sta via via imponendo, perché rende la creazione e la manutenzione del codice lato client molto più veloce e snella.

Una delle prime difficoltà, tuttavia, che si incontrano quando si comincia ad usare CoffeeScript è il fatto che per convenzione tutte le variabili (e quindi anche le funzioni, che in CoffeeScript sono anonime e associate ad un nome di variabile) sono locali.

Un esempio può chiarire meglio. Supponiamo di avere questa semplice pagina in HTML5:

<!DOCTYPE html>
<html>
<head>
    <title>CoffeeScript Palestra</title>
    <link rel="stylesheet" href="css/main.css">
    <script src="js/vendor/jquery-1.7.2.min.js"></script>
    <script src="js/script.js"></script>
</head>
<body>
    <h2>CoffeeScript Scripts</h2>
    <p>Premi <a href="#" onclick="run()">qui</a></p>
    <div id="pippo">&nbsp;</div>
</body>
</html>

Se l'utente preme il link "qui" vogliamo che accada qualcosa, ad esempio compaia la scritta "Ciao Mondo!"

La prima idea che ci viene in mente è quella di scrivere due funzioni, una che ritorna "Ciao Mondo" e una che aggiorna il contenuto del DIV "Pippo" appunto con "Ciao Mondo", in questo modo:

# COFFEESCRIPT SCRIPTS

run = ->
  $("#pippo").html(helloworld)
  null


helloworld = -> 'Ciao Mondo!'

Mettiamo questo codice nel file "script.coffee" e poi lo compiliamo con CoffeeScript. Otterremo script.js che viene poi richiamato dal nostro file HTML (sotto la riga che carica JQuery).

Peccato che una volta eseguito il tutto, quando l'utente preme "qui", non accade nulla.

Il motivo è che il compilatore CoffeeScript traduce le due funzioni "run" e "helloworld" come funzioni locali, quindi di fatto invisibili all'esterno dello stesso codice. Ecco il codice compilato:

// Generated by CoffeeScript 1.3.3
(function() {
  var run, helloworld;

  run = function() {
    $("#pippo").html(helloworld);
    return null;
  };

  helloworld = function() {
    return 'Ciao Mondo!';
  };

}).call(this);

E' giusto che sia così: infatti per evitare conflitti di nomi e variabili globali che rimangono inutilmente appese, mentre in JavaScript è buona norma dichiarare tutto con "var", in CoffeeScript questa diviene la regola.

Per "esportare" il nome di una variabile all'esterno si può agire in diversi modi. Quello che personalmente preferisco è di associare allo spazio dei nomi dello script un nome che espliciti la sua funzione di "esportatore" (ad esempio: exports), e poi di dichiarare le variabili da esportare come appartenenti a questo spazio.

# COFFEESCRIPT SCRIPTS

exports = this

exports.run = ->
  $("#pippo").html(helloworld)
  null


helloworld = -> 'Ciao Mondo!'

In questo modo, la funzione run() - o meglio, la variabile 'run' associata alla funzione anonima - diventa visibile all'interno del nostro file HTML e perciò direttamente utilizzabile.


// Generated by CoffeeScript 1.3.3
(function() {
  var exports, helloworld;

  exports = this;

  exports.run = function() {
    $("#pippo").html(helloworld);
    return null;
  };

  helloworld = function() {
    return 'Ciao Mondo!';
  };

}).call(this);


Come conseguenza non banale, le funzioni ancillari come per esempio la 'helloworld', non vengono esposte, diventando di fatto 'private'.