Sviluppo Notes Agile

Uno dei paradigmi emergenti dell'ingegneria del software è lo sviluppo Agile.

Non voglio qui tracciare la storia e le caratteristiche di questa metodologia, mi limito solo a dare qualche riferimento che ho trovato utile:
Agile Manifesto
Agile Alliance

Inoltre cito anche il sito della comunità italiana che organizza l'Agile Day che è sempre molto interessante (ho partecipato alle ultime due edizioni) e la prossima sarà a breve:
Agile Day

Fra i blog che trattano dell'argomento trovo estremamente interessante quello di Piergiorgio Grossi e quello dell'amico Emanuele (Bonus), anche se quest'ultimo è molto specifico per .Net.

Per mancanza di tempo non ho, purtroppo, approfondito l'argomento come merita, ma da quello che ho superficialmente e sottolineo superficialmente ho colto, le basi della metodologia Agile sono le seguenti (qualsiasi correzione è ben accetta ;-)):

• coinvolgimento molto forte del cliente durante tutto il processo di sviluppo;
• rilasci stabili e molto "vicini" (una, al massimo due settimane) di nuove features;
• scrittura e gestione di test che permettano di controllare che eventuali modifiche inficino quanto scritto in precedenza (Unit test);
• refactoring, ossia riscrittura continua del codice al fine di renderlo il più "snello" ed efficiente possibile.

Ovviamente, ripeto, le metodologie Agili prevedono molte più cose, ma per me i punti salienti sono questi.

Dopo questa sbrodolata iniziale vado finalmente al punto: com'è possibile applicare le metodologie agili allo sviluppo Notes?

Personalmente devo dire che da sempre (ancora prima di conoscere le metodologie Agili ;-) ) applico i primi due punti: a volte mi rendo conto di essere pedante, ma sviluppando praticamente da cliente mi trovo ogni 5 minuti a chiedere: "Ti piace così o preferisci cosà?".
Devo dire che questo a volte rallenta i tempi di sviluppo, ma mi porta difficilmente a correggere qualcosa che porto in produzione (a meno di enormi bachi miei ;-P).
Inoltre difficilmente trascino lo sviluppo di caratteristiche particolari per più di due settimane.
In questo sono ovviamente molto aiutato dalle caratteristiche di sviluppo di Lotus Domino/Notes: costruire un form o una vista e modificare al volo campi e colonne è estremamente veloce e ti permette di aderire senza fatica, almeno a mio parere, alle caratteristiche che dicevo.

Le cose molto più difficili da fare in ambiente Lotus sono invece il Test e il refactoring.
Nonostante la nascita di qualche strumento in tal senso (vedi LSUnit) vedo molto difficile la strada del test in LotusScript e il versionamento di quanto fatto.
Certo, si potrebbe portare lo sviluppo solamente in Java e in Eclipse con strumenti tipo Domiclipse, ma a parer mio si perderebbe velocità e immediatezza dovendo usare poi strumenti di testing non nati per il mondo Lotus.
Non ho ancora provato LSUnit e mi auguro di riuscire a farlo presto, magari vi farò sapere o, se qualcuno l'ha già usato mi farà sapere.

La parte che vedo più complessa è la gestione del versionamento.
Io vedo due vie.
La prima prevede di copiare gli elementi di Design e poi agire su una versione nuova.
La seconda è quella di fare una copia del modello del database e lavorare su quello.
Il problema di entrambe le soluzioni si potrebbe già vedere nel singolo database (come faccio ad automatizzare i test?), ma diventa spinoso in un'applicazione multi database: non saprei come tracciare tutte le interazioni: anche se sono poche, spesso sfuggono e diventa un problema poi gestirle nel modo più opportuno.