Questo post doveva essere una risposta al commento di Tom al post precedente, ma vista la sua lunghezza ho preferito renderlo indipendente.
Hei, non tirarti indietro !
Non far parlare il profeta al posto tuo.:)
…ops mi hai beccato.
Il discorso è tutt'altro che banale. Personalmente credo che le metodologie agili migliorino la produttività, intesa soprattutto come ritorno economico del committente e come accorciamento dei tempi con i quali il fornitore è in grado di andare in produzione con qualcosa di valore. Pensiamo ad esempio alle iterazioni brevi per dirne una soltanto. Inoltre uno dei punti cardine delle metodologie agili è proprio il voler eliminare tutto ciò che è utile a solo una delle parti in gioco (ad esempio a chi giova scrivere una montagna di documentazione interna, o quali vantaggi porta al committente pagare ed aspettare due mesi un documento di analisi super-dettagliato che copre un anno intero di sviluppo stimato?).
Ritengo però allo stesso modo pericoloso mettere al centro del processo di sviluppo il valore della velocità. Questo valore infatti porta a molte malattie, tra le quali ad esempio la bassa qualità (=bassa velocità a medio-lungo termine), una relazione tra committente e fornitore non schietta ma volta a nascondere la realtà, il voler sviluppare senza cercare il feedback dall'utente, a diminuire la comunicazione all'interno del team ecc. ecc. Tutto questo paradossalmente abbassa la velocità.
L'agilità pone al centro del processo i test, e questo ovviamente non è casuale: si sa da tempo che la fase più costosa dell'intero processo di sviluppo è la fase di manutenzione, che spesso fa rima anche con estensione. Porre al centro del processo i test, e farsi guidare da essi, riduce fortemente il costo di quella fase. Non solo: abbiamo tutti avuto esperienza di quanto sia difficile far evolvere un'applicazione mal scritta già dopo un mese o due dalla sua nascita se si sottovaluta l'importanza della qualità del design.
Entra qui in gioco dalla finestra la scelta del tool / linguaggio da utilizzare. Credo che tutti i programmatori Java si guardino ormai intorno per trovare qualcosa che sia più produttivo, e permetta di costruire cose ormai ritenute semplici, in un tempo ragionevole. I javisti più convinti guardano a Trails, altri ad APEX, altri a Ruby on Rails. Credo comunque (soprattutto dopo l'ultimo progetto che sto sviluppando 
) che una delle caratteristiche più importanti di un tool/linguaggio sia la sua intriseca testabilità. Se per avere questa testabilità devo rinunciare ad un po' di produttività per le cose semplici, pazienza. Al contrario non avrebbe senso se la rinuncia alla produttivà avesse un peso molto grande, per il tipo di applicazione da sviluppare.
E' questo il motivo per il quale personalmente sono ben impressionato da RoR: grande testabilità e alta produttività.
Personalmente tengo gli occhi ben aperti sulle scelte che faccio (siano di tool o siano di natura meno tecnica), chiedendomi sempre se in fondo non mi stia guidando il falso valore della "comodità", cioè il voler evitare quella "due dilligence" (dovuta cura) di cui parla Martin, cioè quel duro lavoro quotidiano, e quell'attenzione che pratiche come TDD richiedono. E' facile confondere (forse perché il confine è sottile) la ricerca della produttività con la ricerca di una soluzione di comodo che renda il lavoro meno brain intensive. Meglio dare l'impressione di essere un po' più lenti, ma sapendo cosa si sta rilasciando: "rilasciare una feature che non funziona è molto peggio di una che non c'è". Non solo: una feature in produzione che non funziona diventa una palla al piede di tutto il processo di sviluppo, rallentandolo inevitabilmente.
L'importante è avere principi e valori efficaci che ci guidano nelle scelte, è chiaro poi che lo stesso paradigma "sperimenta ed adatta" ed il principio del mutuo beneficio, prevedano scelte che spesso devono vedersela con dei trade-off.
September 26th, 2006 by 
Enri
12 Comments »