E-Mail Killer

11 March, 2007 (17:04) | agile

Tutti noi abbiamo avuto dei miti, delle persone che nella loro vita hanno fatto quello che noi vorremmo fare, delle persone dalle quali traiamo ispirazione, anch’io ho avuto i miei, uno di questi è Adriano Comai. Al tempo in cui ero ancora un fervido sostenitore del BDUF mi ero iscritto alla mailing list UML-Italia da lui stesso fondata (o comunque fortemente sostenuta)

Il mio punto di vista sull’UML da allora è cambiato, ora lo considero un valido strumento a supporto di un team di sviluppo, ma non è di questo che voglio parlarvi; voglio parlarvi di un mio intervento su quella mailing list.

Un giorno ricevo la segute mail

Subject: [UML-Italia] simple design
From: anna.pegna@csi.it
Reply-To: UML-Italia@yahoogroups.com
Date: Thu, 13 Apr 2006 10:03:08 +0200
To: UML-Italia@yahoogroups.com

Sto dando un’occhiata (sic!) a eXtreme Programming.
I principi fondamentali (the key practices) di XP sono tutti convincenti
ed importanti per lo sviluppo del software. C’e’ pero’ un principio di cui
non capisco bene il significato, ed e’ quello del “simple design”.

Qualcuno puo’ spiegarmi qual e’ il vantaggio di non guardare oltre il
proprio naso, oppure oltre il problema di oggi, mentre si progetta un
sistema software che potrebbe essere anche molto complesso? Non sarebbe
meglio avere una visione piu’ ampia, anticipare i problemi con
un’architettura provata ed eseguibile, ma che venga consolidata prima di
passare allo sviluppo?

Grazie
Anna

La mia risposta è stata la seguente

Subject: Re: [UML-Italia] simple design
From: Gabriele Lana
Reply-To: UML-Italia@yahoogroups.com
Date: Thu, 13 Apr 2006 13:13:18 +0200
To: UML-Italia@yahoogroups.com
X-Organization: http://www.agilemovement.it
X-Operating-System: Linux 2.6.12-gentoo-r9
User-Agent: Mutt/1.5.11

Sto dando un’occhiata (sic!) a eXtreme Programming.

Perche’ “sic”? Ti ha costretto qualcuno?

I principi fondamentali (the key practices) di XP sono tutti
convincenti ed importanti per lo sviluppo del software. C’e’ pero’
un principio di cui non capisco bene il significato, ed e’ quello
del “simple design”

E’ un approcio evolutivo che si basa sulla capacita’ di poter
manipolare agevolmente il codice sorgente dell’applicazione

In maniera molto rozza:

  • Si parte con un insieme minimo di funzionalita’ che hanno il piu’
    alto valore economico
  • Si implementano i test per verificare che il sistema implementi
    veramente le funzionalita’ desiderate
  • Si implementano le funzionalita’ nel modo piu’ semplice possibile,
    finche’ tutti i test non passano
  • Si ripete dall’inizio

Implementare le funzionalita’ nel modo piu’ semplice vuole dire
chiedersi, per ogni nuova funzionalita’, se l’architettura attuale
puo’ essere in grado di “accettare” questa nuova funzionalita’ in
maniera “semplice”, ovvero in maniera dolce, naturale.

“semplice” = la struttura del codice preesistente non deve aggiungere
complessita’ nell’introduzione del nuovo codice, ma anzi la deve
diminuire

Se l’architettura attuale non risulta adatta, la si rifattorizza, e
solo dopo si aggiunge la nuova funzionalita’, una funzionalita’ viene
considerata integrata all’interno del sistema solo quando tutti i test
relativi a quella funzionalita’ vengono soddisfatti
Dopo che una funzionalita’ e’ stata introdotta, il sistema e’
perfettamente funzionante e pronto per essere utilizzato in produzione
(i rilasci vengono fatti regolarmente, generalmente ogni settimana, al
piu’ tardi ogni mese)

L’implementazione del progetto funzionalita’ per funzionalita’, e
l’utilizzo immediato di questo prodotto “parziale”, sottendono ad un
meccanismo conoscitivo/esplorativo che porta notevoli vantaggi:

  • L’obiettivo dello sviluppo non e’ quello di implementare delle
    specifiche, ma e’ quello di soddisfare gli obiettivi del cliente, le
    funzionalita’ che dovranno essere implementate nel progetto vengono
    continuamente riviste e rivalutate basandosi sulle metriche di
    business del cliente
  • Il processo che ho illustrato prima permette di mantenere il costo
    di manutenzione del codice costante, il costo per introdurre una
    nuova funzionalita’ non varia durante il progetto
  • Il cliente non e’ costretto a pagare per una flessibilita’ che
    potrebbe non utilizzare
  • Il cliente e’ in grado di ottenere immediatamente un ritorno
    dell’investimento in quanto l’applicazione (con un set anche molto
    ridotto di funzionalita’) e’ utilizzabile in tempi brevissimi
  • ecc…

Migliorare la nostra capacita’ di far fronte agli imprevisti, senza
tentare di prevederli a priori, ci permette di considerare gli
“imprevisti” come delle semplici funzionalita’ che non erano state
previste all’inizio, e infatti generalmente vengono accolte di buon
grado, in quanto significa che il processo conoscitivo messo in atto
funziona

Non sarebbe meglio avere una visione piu’ ampia,
anticipare i problemi con un’architettura provata ed eseguibile

Permettimi un’osservazione schietta: questa e’ una barzelletta;
l’unico modello eseguibile del progetto e’ il codice sorgente del
progetto stesso, se avessi veramente un modello
eseguibile prima dello sviluppo, non avresti bisogno dello
sviluppo. Una “specifica” semanticamente non ben definita o una
specifica ben definita ma senza uno strumento automatico di verifica
che l’implementazione soddisfi alla specifica stessa (vedi i test
automatici di cui sopra) e’ utile solo per favorire la comunicazione,
e allora a questo punto preferisco altri strumenti per favorire la
comunicazione all’interno del team o fra customer e team

Ok, va bene, come al mio solito non ci sono andato leggero, ma il mio intento era veramente quello di poter comunicare a questa persona (e a tutti gli iscritti alla lista) ciò che avevo appreso sulla mia pelle, ed ero veramente interessato alle repliche che avrebbero potuto farmi (anche per questo ho spinto un pochino sui toni), magari sarei riuscito a convincere qualcuno, magari qualcuno sarebbe riuscito a convincermi del contrario, ma sapete una cosa? Non mi ha risposto nessuno…

Ok, è un gruppo di discussione libero, a basso traffico, non è che posso pretendere niente. Dopo un mese però mi accorgo che nessuno aveva più scritto, passa un’altro mese… niente, un altro ancora… niente, dopo un anno… damn! ho ucciso la mailing list :-)

E invece no, oggi scopro che (anche se poco) hanno continuato a scrivere su quella lista, ma io non ne risulto più iscritto… per questo anche dopo averlo scoperto non ho cambiato il titolo del post, in quanto sempre di e-mail killer si tratta :-)

NOTA: Non è un’accusa nei confronti dell’owner della mailing list, non penso che siano arrivati a bannarmi per così poco, fatto sta che oggi mi sono iscritto di nuovo, magari qualcuno mi aveva veramente risposto :-)

Write a comment