Correva l'anno 2000 e stava scoppiando la bolla di internet. La prima almeno.

Tanti programmatori si incontrano e narrano i problemi con i loro clienti. Ne esce un incontro sulla neve, negli USA, dove i partecipanti, 17, all'unanimita' scrivono un manifesto su come sviluppare software.

Per anni ho seguito questo nome con assoluto disinteresse. Oggi mi sono incuriosito e documentato, sulla base della possibilita' di contrattualizzare questo metodo.

Se si legge il manifesto o wikipedia si resta molto sorpresi: ci sono principi estremamente generali e flessibili, uniti ad alcune metodologia che necessariamente integrano il manifesto che, da solo, a mio modo di vedere, e' una bella affermazione politica senza possibilita' di individuare obblighi e doveri precisi.

Che poi e' lo scopo del metodo agile: far felice il cliente.

Ora teniamo presente che il cliente e' americano, ed e' un cliente che sa di pagare quello che chiede.

Torniamo in Italia e mi rendo conto che i valori espressi dal manifesto, corretti, sono inapplicabili se portati cosi' come sono.

Di piu': scopro che uso questi principi anche io dal lontano 1986. e non sapevo si chiamasse agile ...

Sta di fatto che il metodo agile mette al centro la soddisfazione del cliente, cioe' gestendo lo sviluppo in piccole pillole verificabili spesso insieme al cliente tramite continue microconsegne. Appunto: quelllo che faccio da sempre.

Pare sia un metodo rivoluzionario. Mi chiedo come lavorano gli altri programmatori.

Sta di fatto che la contrattualizzazione non e' certo quella che ho visto fare in vari preventivi.

Un tema interessante, perche' il fulcro e' una idea importante: continui contatti, scambio di microconsegne, microparti autonome e modificabili, struttura elastica e semplice da sviluppare anche in parallelo con altri programmatori, o in sostituzione.

Ma il tutto significa struttura software. Come contrattualizzarlo ? La vedo grama, perche' e' una scelta della software house organizzare la struttura del software, a meno che il cliente non abbia gia' previsto anche una struttura.

Quindi nei contratti dovrebbero essere previste parti generali e parti tecniche su modelli di documentazione semplici ed elastici. Ne ho visti pochi di contratti cosi'.

Spataro

ps: nel video un interessante approccio