Gabriele Lana

www.cio.com per un consulente come me è una risorsa importante, quando nella carriera di libero professionista fai il salto di qualità passando da fornitore di tecnologia (vendi la tua conoscenza di una determinata tecnologia) a fornitore di servizi (vendi soluzioni), è meglio informarsi su quello che vogliono quei signori che gestiscono i budget IT delle aziende, ovvero i vari CIO, CTO, CEO, … insomma avete capito

Gli articoli per me più interessanti sono quelli che parlano di sviluppo software, per capire quali risultati ci si aspetta di ottenere, in quali modi, ecc… Un esempio è questo articolo che propone un’introduzione alle metodologie agili rispondendo alle seguenti domande

What Are the Business Reasons for Using Agile?
What Makes Agile Programming Different?
Won’t I Have to Do a Lot of Extra Work?
What’s Different, Besides Working in Iterations?
Won’t Working Like this Change Our Corporate Culture?
When Should I Avoid Using Agile Programming Techniques?
Is There Just One Kind of Agile Programming?

Un buon articolo che cattura l’essenza del business di queste metodologie

Won’t I Have to Do a Lot of Extra Work?

Some people imagine that Agile programming techniques require a lot of extra work to implement. However, it actually reduces workload and makes the return on investment significantly faster because of the shorter turnaround time on each component and putting the software into action more quickly.

In fact, because of the swift response that developers can give to such software, managers often use Agile programming techniques to rescue projects that are in trouble

Me è un’altra parte che ha sollevato qualche polemica

When Should I Avoid Using Agile Programming Techniques?

[cut]

Applications that require a distributed development don’t work well with Agile programming techniques, either. If you have some developers in England and others in the United States, team members can’t communicate quickly enough. Distributed teams have difficulty getting all of the benefits of Agile methods, even though tools such as instant messaging or IRC may compensate somewhat. The system can quickly bog down, and you’ll find yourself devoting a lot of time to keeping individual team members updated.

Joshua Kerievsky (che non è proprio l’ultimo arrivato) ha subito replicato su questo punto dicendo che ormai ci sono prove evidenti (nella sua azienda e in altre) della scalabilità di XP/Agile a team numerosi e distribuiti. Questa replica è stata ripresa anche da InfoQ sottolineando che la realizzabilità non implica la semplicità di realizzazione, ovvero anche se è possibile scalare, è giusto mettere in guardia le aziende sulle difficoltà che potrebbero incontrare. Concordo

Io infatti vorrei controbattere su un’altro punto

When Should I Avoid Using Agile Programming Techniques?

[cut]

You may also find it hard to use Agile programming techniques with mission-critical applications where every single piece has to work at the outset. Because Agile programming techniques work best with small iterations, you won’t get a whole application put together immediately. The process requires that the organization deploy the partial application to invite comment from the organization as a whole. The goal is to fix any real bugs and usage problems quickly, not to create one monolithic application that can’t be tested until the end of the project.

Questo evidenzia due fatti

• In molti non hanno capito come funziona uno sviluppo di tipo incrementale
• C’è la credenza mitologica che le “specifiche” seguano il modello del tutto o niente

Il fatto che un progetto venga sviluppato in maniera incrementale non significa che tale sviluppo non possa essere guidato da delle “specifiche complete”. Quando parlo di “specifiche complete” mi riferisco a: stadard, protocolli, formati, grammatiche, ecc… la leggenda vuole che non possano essere implementati in maniera incrementale, perche?

Forse perchè un’implementazione parziale non ha valore? Ne dubito fortemente! Quanti compilatori C++ standard esistono? Forse solo il Comeau, gli altri? Non valgono niente? Quanti browser supportano tutti gli standard del W3C? Nessuno! Eppure mi sembra che anche con un’implementazione parziale si possa navigare decentemente

Inoltre sviluppo incrementale non vuol dire sviluppo parziale, alla fine verrà comunque rilasciata un’implementazione corretta e completa delle specifiche, la differenza è che lo sviluppo (e magari anche le specifiche :-)) verranno valutate a fronte di un feedback continuo derivato dall’utilizzo di un’implementazione parziale. Ammesso e non concesso che il software non sia inutilizzabile dall’utente finale se le specifiche sono implementate in maniera parziale, di proprietà da valutare ce ne sono anche altre, sopratutto per le applicazioni critiche: performance, conformance, deployment, load, stress, usability, …; tutti parametri che potrebbero mettere a rischio la buona riuscita del progetto, meglio verificarli continuamente!

E’ possibile implementare una specifica in maniera parziale? Certo! Intuitivamente sembra di no, ma solo perchè non ci siamo abituati. Prendiamo per esempio un compilatore, l’approcio classico è quello di implementare in sequenza: il lexer, il parser, l’interprete semantico, il generatore di bytecode, l’ottimizzatore, ecc… E’ l’approcio più intuitivo perchè è la pipeline seguida dal flusso d’esecuzione del compilatore, è chiaro però che questa non è implementazione incrementale. Con il lexer e basta che feedback vuoi raccogliere? Un approcio incrementale potrebbe essere quello di implementare tutti i moduli per un linguaggio semplificato, per esempio un linguaggio che supporti solo somme, nelle iterazioni successiva aggiungiamo tutte le altre operazioni aritmetiche, poi l’assegnazione a variabile, gli operatori/statement di controllo del flusso d’esecuzione, …

Potrebbe non sembrare semplice, ma la difficoltà è solo nel cambio di prospettiva, da tecnologica (per moduli software) a funzionale (per funzionalità utente), proprio per questo al Milano eXtreme Programming User Group abbiamo in programma un workshop sul modello di quello di Beck per far pratica su questo argomento

Come ultima cosa vorrei chiedere: che cosa vuol dire effettivamente implementazione parziale? Parziale rispetto a cosa? Rispetto alle specifiche di oggi? I linguaggi di programmazione, i protocolli, gli standard in generale non evolvono? Un’implementazione completa oggi non è forse un’implementazione incompleta domani? Quindi vi chiedo, esistono implementazioni complete? Ha ancora senso dire che un’implementazione incompleta non ha valore o che non può essere utilizzata?

Ho lavorato per anni nel campo dell’automazione industriale scrivendo quelle che potremmo tranquillamente definire “applicazioni critiche”, nonostante quello che si potrebbe pensare, è proprio in questo ambiente che ho visto le cose peggiori (dal punto di vista della qualità del codice), la mia esperienza personale/professionale vi garantisce che si possono ottenere ottimi risultati applicando una metodologia agile a questo tipo di applicazioni e, a differenza della scalabilità, senza compromessi o particolari difficoltà