Spedisco questo msg come prova, per verificare funzioni tutto dopo io mio
cambiamento di account...

Anzi, visto che ci sono, colgo l'occasione per comunicarvi che ho concluso
la mia tesi e la discuterò a fine mese. Ho anche inserito un'intervista
realizzata con Francesco Cirillo. Si tratta di una cosetta piuttosto
interessante, almeno dal mio punto di vista, ed io e l'intervistato abbiamo
tutta l'intenzione di pubblicarla. Non appena verrà fatto, ve ne daremo
notizia.

Intanto, un ciao e un grazie tutti.

Bye bye,
Massimo

OOP2003 (http://www.sigs-datacom.de/sd/kongresse/oop_2003/index.htm) è
una conferenza incentrata sul mondo OO*, principalmente rivolta al
pubblico tedesco. Mi aspettavo una partecipazione scarsa, ma alla fine
ho visto qualche centinaio di persone, provenienti da aziende
storicamente legate a Monaco come BMW e Siemens, ma anche altre come
Lufthansa, Deutsche Bank, ecc.
Le sessioni a cui ho partecipato erano in lingua inglese ==> c'erano
altre sessioni che potenzialmente potevano essere interessanti, ma
rigorosamente in tedesco. A breve dovrebbero essere disponibili sul sito
della conferenza la maggior parte delle slide e comunque di ogni
presentazione vi allego quantomeno un link al sommario.

*) [Objects versus the web] è stata una delle presentazioni più
interessanti. Alan Knight e Naci Dai hanno seguito un approccio
evolutivo alla definizione di un'architettura OO x il web che mi ricorda
molto da vicino gli sforzi che stiamo compiendo noi. Loro ad esempio
hanno approcciato il problema della navigazione attraverso la
definizione di una macchina a stati finiti (ma questa parte l'hanno solo
accennata). Gli ho posto il problema del mantenimento dello stato in
finestre contemporanee dello stesso browser (quindi con condivisione
della sessione), ma non sono stati in grado di rispondere, in pratica
gli ho dovuto spiegare come pensavo di poter risolvere il problema (e
comunque creando una sovrapposizione di stati possono esserci dei
conflitti non risolvibili tra le diverse finestre, ma questa è tutta
un'altra faccenda). Comunque, i 2 personaggi mi sono piaciuti molto,
finalmente qualcuno con le idee chiare sui pro e contro
dell'applicazione di MVC a sistemi HTTP-based.
==>
http://www.sigs-datacom.de/sd/kongresse/oop_2003/program/tuesday.htm#Di4

*) [Program transformations through the manipulation of semantic
graphs], cioè la opening keynote di Gosling, è stata abbastanza
divertente. Era la prima volta che ascoltavo Gosling (il papà di java, x
chi non lo sapesse) e devo dire che il ragazzo è un po' disturbato, ma
in gamba. Oggi lavora nei Sun Labs e fa solo ricerca. Il progetto a cui
sta lavorando è un bel tool di refactoring che lavora sul codice a
livello semantico, anzichè sintattico, manipolando direttamente gli AST
(Abstract Syntax Trees) attraverso una versione modificata di javac.
Durante la presentazione ha fatto vedere diverse rifattorizzazioni,
alcune piuttosto intrusive, su un progetto di suppergiù 90000 linee ==>
è stato impressionante vedergli applicare in modo praticamente
istantaneo delle regole definite lì davanti a noi, rimpiazzando il
codice rispondente a certi pattern match con un altro codice, in cui i
simboli sono stati trattati nel modo che ci si aspetta, cioè con le
dovute sostituzioni. Ecco, la potenza vera di questo tool, sta nel fatto
di essere completamente aperto: ognuno può definirsi le proprie regole
di refactoring, anche in modo molto complesso, senza dover sottostare a
un catalogo fatto da altri e quindi di solito incompleto.
Se volete, posso pubblicare da qualche parte il tiff della mia mappa
fatta al volo durante la presentazione. Sono molto curioso di vedere se
e quando Sun lo renderà pubblico, che impatto avrà sul modo di lavorare
di molti, ecc.
==>
http://www.sigs-datacom.de/sd/kongresse/oop_2003/program/keynotes.htm#key_di1

*) In [The Evolution of Java] invece Gosling è stato un po' sotto tono,
di fatto ha solo riassunto alcune cose già note, anche se ha posto
l'accento sugli aspetti dell'evoluzione del linguaggio che gli sembrano
più significativi. Ad esempio, è chiaro che con la versione 1.5 ci
saranno i Generics, cioè un'implementazione nativa dei template x java,
di fatto già disponibile anche in questo momento come library
aggiuntiva. Morire se Gosling faccia un poco di autocritica a favore del
dynamic typing! La cosa più divertente è stata la serie di domande botta
& risposta alla fine.
==>
http://www.sigs-datacom.de/sd/kongresse/oop_2003/program/tuesday.htm#CS2

*) [Generating GUls for Web Services] è una brutta presentazione
sull'idea di automatizzare la costruzione di interfacce attraverso l'uso
di XML. Il personaggio era brillante e preparato, era il tema in sè a
essere triste e debole. Se non altro c'è stata un'ulteriore conferma
all'uso di ApacheAxis per interfacciare WebServices.
==>
http://www.sigs-datacom.de/sd/kongresse/oop_2003/program/tuesday.htm#Di13

*) In [Extending Eclipse] Gamma ha presentato e supportato l'idea dello
sviluppo di plugin x Eclipse, con l'implementazione in diretta di un
semplice plugin, dopo aver eretto una specie di altare al lazy loading
==> comunque l'aggeggio è notevole, possiamo confermare x l'uso che ne
facciamo tutti i giorni, ed SWT è una valida e veloce (nel senso di
performante) alternativa a Swing.
In coda al tutto, Gamma ha spiegato meglio un aggeggio che ha fatto
vedere qua e là, chiamandolo Spider: si tratta di fatto di un
adattamento concettuale di HotDraw (http://c2.com/cgi/wiki?HotDraw),
fatto anche questo con Beck. E' una specie di navigatore grafico di
oggetti x Eclipse. Vedi il relativo progetto su Sourceforge
(http://sourceforge.net/projects/javaspider/)
==>
http://www.sigs-datacom.de/sd/kongresse/oop_2003/program/wednesday.htm#Mi7

*) [Creating End-to-End Application Security] In questo divertente
intervento, Sohbat Ali ha fatto vedere un po' di modi con cui si può
rompere un sistema esposto sul web attraverso il protocollo HTTP. La
cosa divertente è stato vedere quanto subdoli siano certi problemi, e
quali sono le tecniche che usano gli hacker. Allo stesso modo, ha
mostrato anche alcune tecniche che possono aiutare a prevenire questi
attacchi. Un esempio su tutti: non fate validazione sulla pagina web
attraverso javascript, ma solo ed esclusivamente sul server, o
quantomeno fatela comunque sul server. Perchè? Eh, eh, leggete le slide
quando saranno disponibili ... per me è stato molto istruttivo!
==>
http://www.sigs-datacom.de/sd/kongresse/oop_2003/program/wednesday.htm#Mi9

*) [Leading Creative Projects] Murray Cantor di Rational ha costruito un
divertente intervento sulla gestione creativa di progetti. Di fatto ha
spezzato una lancia nei confronti dei temi agili, ma solo ed
esclusivamente nel contesto di RUP ... che strano, eh?!? :-)
Tra le cose più interessanti, alcune considerazioni sull'applicazione
della legge di Pareto alle fasi di sviluppo: quando hai raggiunto
quell'80% di beneficio con il 20% di effort, non insistere ulteriormente
a dettagliare la fase corrente, ma passa alla fase successiva.
==>
http://www.sigs-datacom.de/sd/kongresse/oop_2003/program/keynotes.htm#key_mi2

*) Ekaterina Chtcherbina (di Siemens) ha fatto una presentazione
discreta dei temi legati al P2P in generale e a JXTA in particolare:
[Peer-to-Peer Computing with JXTA]. L'impressione è di una tecnologia
interessante, ma ancora molto immatura. Le applicazioni sono
potenzialmente infinite, alcune delle quali anche assai inquietanti.
==>
http://www.sigs-datacom.de/sd/kongresse/oop_2003/program/thursday.htm#Do1

*) [Agile and Iterative Requirements Analysis] - Nel primo intervento
Larman ha fatto innanzitutto una bella digressione sulle origini del
waterfall, menzionando un'intervista con il figlio di Royce, autore del
famoso articolo su cui tutti hanno basato l'implementazione del
waterfall, morto recentemente: ebbene, suo figlio ha candidamente
ammesso come il padre non abbia mai lavorato in quel modo in realtà, ma
sempre in maniera iterativa incrementale! Il problema storico legato
all'articolo di Royce è stato ricostruito da Larman: poco dopo l'uscita
dell'articolo un militare è stato incaricato dall'esercito USA di
costruire una raccomandazione per processi di sviluppo ==> il ragazzo,
allora praticamente neolaureato e inesperto, ha costruito il documento
incentrandolo sul paper di Royce ==> da questo documento purtroppo tutto
il mondo, Europa in testa, ha costruito le proprie raccomandazioni per
lo sviluppo del software, tanto che ancora oggi parecchi enti
governativi e non in mezzo mondo ne soffrono!! Sul finire degli anni '80
e con decisione negli anni '90 poi sono uscite nuove raccomandazioni
dell'esercito americano e del DoD, in cui in tutte è stato raccomandato
l'abbandono di waterfall a favore di metodi iterativi incrementali.
Larman ha poi citato una serie di importanti esempi di successo di
applicazione di metodi iterativi incrementali in contesti
tradizionalmente ostici (militari e NASA), datati in epoche non sospette
come anni '70 e '80. La parte più pingue però è stata dedicata a una
serie di tecniche agili di elicitazione dei requisiti, molto divertenti,
posso solo raccomandare l'ascolto della registrazione con lettura delle
slide.
==>
http://www.sigs-datacom.de/sd/kongresse/oop_2003/program/thursday.htm#Do11

*) L'intervento successivo di Larman, denominato [Fast Java Fast], si è
incentrato sulle performance di java, dando una serie di indicazioni.
Abbastanza divertente, ma un po' deboluccio, forse x l'aridità del tema:
si va dall'uso di ArrayList? al posto di Vector, al tuning del garbage
collector, come manipolare stringhe, lasciar riscaldare HotSpot?, ecc.
Vi consiglio di leggervi le slide quando saranno disponibili.
==>
http://www.sigs-datacom.de/sd/kongresse/oop_2003/program/nightschool.htm#Ndo5

*) Last but not least (spero), c'è stata la mia presentazione di
MarketInfo, strutturata sotto forma di case study. Presto vi metterò a
disposizione sia il paper che le slide sul sito di Quinary. E' andata
bene, ma non dovrei essere io a dirlo. Ci sono stati un 20-30
partecipanti, piuttosto interessati, che hanno fatto osservazioni,
domande, ecc. Per il resto, una volta pubblicato il materiale, mi
piacerebbe sentire le vostre domande e andare eventualmente avanti da
queste.
==>
http://www.sigs-datacom.de/sd/kongresse/oop_2003/program/thursday.htm#CS18

Ciao, Giuliano

Salve a tutti,

       grazie alla segnalazione di un membro dell'Italian Agile Movement sono
venuto a conoscenza di un articolo pubblicato su un periodico digitale di AICA
(Associazione Italiana per l'Informatica ed il Calcolo Automatico) che tenta di
esaminare l'XP e spiegare perchè non è nulla di nuovo e come si risolva in un
"silver bullet fallito".

Dato che AICA è un'associazione seria e che gli autori del pezzo sono
evidentemente in buona fede abbiamo deciso di scrivergli ma prima di farlo
abbiamo aperto la discussione a questo indirizzo:

http://agilemovement.it/modules.php?op=modload&name=News&file=article&sid=70&mod\
e=thread&order=0&thold=0

Chi meglio di voi potrebbe unirsi alla discussione? Mi piacerebbe in seguito
coinvolgere i due autori dell'articolo in questione per cercare di scambiarci le
idee.

I commenti possono essere lasciati anche dagli anonimi quindi non è necessario
che vi iscriviate per partecipare alla discussione.

Grazie per l'attenzione, buona notte :-)

Marco Abis
http://www.agilemovement.it - Uncovering better ways of developing software

Non so se l'avete notato, ma sul sito di sun è apparsa la prima parte di
un'intervista a Jaron Lanier:
==> http://java.sun.com/features/2003/01/lanier_qa1.html

Anche se non riguarda direttamente XP, è interessante e fa scattare a
mio avviso alcune considerazioni:
*) condivido al 100% l'osservazione che uno dei problemi principali del
fare software per come lo conosciamo oggi è l'amplificazione degli
errori ==> è di fatto il prezzo da pagare per muoversi in un mondo
digitalizzato, che quindi è caratterizzato da una tolleranza all'errore
prossima allo 0%
*) l'idea di proporre un nuovo paradigma tollerante agli errori, più
vicino a un approccio evoluzionistico-analogico, mi sembra accattivante
e intuitivamente immagino si possa sposare bene con un processo
inerentemente evoluzionista come quello XP
*) le parole chiave sono Phenotropic Computing e pattern matching: "In
phenotropic computing, components of software would connect to each
other through a gracefully error-tolerant means that's statistical and
soft and fuzzy and based on pattern recognition in the way I've
described."
*) curioso come in tutto il marasma dell'intervista Lanier si concentri
solo sul paradigma di programmazione, e non menzioni in alcun modo il
grande dibattito che c'è stato nel mondo dei processi con il fiorire del
movimento agile

Per inciso, Jaron Lanier è stato uno dei miei miti di gioventù, quando
verso il finire degli anni '80 diede il via all'ennesima
silver_bullet_golden_flop_will_never_really_work_buzzword, cioè il
concetto di realtà virtuale.

Buona lettura.
Ciao, Giuliano

Questo post è piuttosto lungo, sedetevi comodi, rilassatevi e leggetevelo con calma.

*) Non e' vero che "l'analisi sia in se' un appesantimento del progetto" ==> cio' che XP cerca di fare e' evitare di approcciare l'analisi attraverso specifiche fasi separate; nulla toglie che ci siano momenti continui in cui il team e' impegnato a esplorare i requisiti dell'utente, le possibilita' offerte dalla tecnologia, ecc. e comunque in generale lavorare su una user story comporta una significativa attivita' di analisi a confronto diretto con il customer. La scrittura dei test di accettazione ne e' una componente essenziale, ma non ne esaurisce tutti gli aspetti.
L'analisi quindi non e' eliminata e sicuramente ha un peso abbastanza importante all'inizio del progetto, quando il team vive un momento che io chiamo di "startup", iniziando a costruire il rapporto con il customer, collezionando storie; in aggiunta a cio', l'attivita' di analisi viene portata avanti durante tutto il progetto, con continue interazioni con il customer che non si limitano al planning game o alla "sola" accettazione delle carte pianificate.

*) Affermare che, secondo XP, "non serve prevedere i possibili cambiamenti" da' una visione semplicistica della vita di lavoro di un team XP: mi viene in mente l'immagine di questi coder stolidi che lavorano indefessamente ignorando cio' che accade all'esterno, un po' come l'orchestra che continuava a suonare nella sala da ballo del Titanic anche dopo la collisione con l'iceberg. Nella realta', cio' che succede e' che da un lato il team mantiene bassa la complessita' del sistema attraverso una continua rifinitura del design (refactoring) e dall'altro i cambiamenti che possono comportare un maggior rischio vengono esplorati con il customer ed eventualmente affrontati con degli spike che consentano di ridurre la componente di rischio. In questo senso, l'attivita' di spiking puo' costituire un modo efficace x fare scouting per come l'intende McCarthy in "Dynamics of Software Development".

*) Il presunto appiattimento della CCC (Cost of Change Curve) e' un tema assai dibattuto. Se da un lato e' vero che non esistono analisi sperimentali che corroborano la tesi, dall'altro l'esperienza che il mio team vive sulla propria pelle tutti i giorni sembrerebbe confermarla. Questa e' anche una delle idee di fondo che ho sostenuto nella mia presentazione di M@rketInfo a OOP2003 (e che spero di pubblicare a breve sul sito di Quinary). Empiricamente, posso affermare che in ogni progetto XP che ho affrontato ho potuto notare una maggior resistenza al cambiamento soprattutto nei momenti iniziali del progetto, dovuta probabilmente a una continua ricerca della forma piu' semplice per lo stato attuale del sistema. Mano a mano che le settimane passano, il sistema diventa contemporaneamente piu' potente (perche' sempre piu' funzionalita' vengono implementate) e piu' versatile (perche' ogni nuovo punto di flessibilita' induce una rifattorizzazione del design), senza che cio' sia guidato da pura speculazione basata sull'esperienza del progettista. Anche se non possiamo provarlo oggettivamente, una delle conseguenze principali di questo atteggiamento sperimentata in M@rketInfo e' stata la maggior velocita' percepita dal customer nella seconda meta' del progetto, causata non tanto da una maggior conoscenza del dominio o da una minore propensione al cambiamento, ma proprio da un sensibile incremento della maneggevolezza del sistema.

*) Non c'e' alcuna evidenza che l'affermazione seguente possa avere qualche fondamento: "Ma per tutti i sistemi di una certa complessita' che vengono costruiti prevedendone una certa sopravvivenza nel tempo, l’approccio dell’XP deve essere stemperato in forme meno estreme, in particolare, attraverso un maggiore investimento nelle attività di acquisizione, analisi e specifica dei requisiti." ==> al contrario, e' proprio quando il sistema deve sopravvivere nel tempo che un approccio come quello XP mostra la sua potenza. Credo che l'esperienza di Massimo Arnoldi di Lifeware, ma anche di Logica, nello sviluppo dell'MMSC, vada esattamente in questa direzione. Personalmente credo che uno dei limiti di XP sia cercare di competere con quei team che fanno microsviluppi di tipo "code & throw away" di poche settimane: in questo modo credo sia pressoche' impossibile rientrare dei costi di refactoring, cosi' come e' probabilmente inutile fare analisi o design ex-ante in senso tradizionale.

*) E' evidente che XP puo' degenerare in una pessima forma di "code & fix", cosi' come RUP puo' degenerare in waterfall. Cio' non vuol dire che XP sia "code & fix", cosi' come RUP non e' waterfall. E' triste che nell'intero articolo non vi sia alcuna menzione ai valori alla base di XP e al ruolo che essi giocano poprio per evitare degenerazioni di questo tipo. XP, visto solo ed esclusivamente come insieme di pratiche, e' destinato miseramente a fallire alle prime difficolta'.
Vorrei inoltre affermarlo a gran voce: XP e' tutto fuorche' "code & fix".

*) Il paragone con attivita' ingegneristiche proprie dei settori manifatturieri (i "calcoli del cemento armato...") e' risibile e assai criticato in contesti che vanno ben al di la' di XP e che sono sicuramente piu' datati. Si veda ad esempio l'articolo di Jack Reeves (http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm) e le discussioni relative su c2 (ie: http://c2.com/cgi/wiki?WhatIsSoftwareDesign), nonche' tutta la letteratura comparsa in seguito sul fare software come attivita' creativa, sulla gestione della complessita', le teorie del caos, ecc.

*) Sono totalmente in disaccordo con il seguente periodo: "Il suggerimento di Beck e', in sintesi, quello di sacrificare la generalita', rinunciando ad anticipare aleatorie e imprevedibili evoluzioni future e, quindi, rinunciando a produrre soluzioni progettuali che facilitino tale evoluzione." ==> affermare cio' significa non aver capito il senso dell'attivita' di refactoring, che e' esattamente svolta a facilitare l'evoluzione del software. Cio' che cambia e' il fattore motivante: da una parte la previsione della modifica in base a svariati criteri, dall'altra la ricerca della semplicita' e la riduzione della complessita'. Il primo e' un fattore esogeno, non controllabile, soggetto a un andamento incerto, mentre il secondo e' un fattore endogeno, interamente interno al sistema: qui sta il **VERO** nocciolo del contendere e di questo dovremmo discutere! Il resto e' solo fumo negli occhi.

*) L'annoso problema della documentazione: XP non vieta la produzione di documentazione, questo e' uno dei misconceptions piu' vecchi, tanto da meritare una risposta specifica sul sito di Ron Jeffries (e voi sapete quanto io sia critico con RJ, pero' in questo caso non posso che essere d'accordo ==> http://www.xprogramming.com/xpmag/Misconceptions.htm#N85). A ogni progetto, in funzione delle caratteristiche del team e delle necessita' che provengono dall'esterno del team, la giusta documentazione.

*) Il mio team e' in grado di "risalire dal codice alle sue motivazioni" e di "risalire dall'implementazione ai principi ispiratori delle scelte di progetto". Se fosse necessario, potremmo produrre un report che in un dato istante mappa ogni classe, ogni metodo, ogni riga di codice in una o piu' feature richieste dal customer, oppure in una o piu' scelte di design, anche se probabilmente a cio' non corrisponderebbe un formalismo documentale o diagrammatico di nessun tipo. Purtroppo o per fortuna non ho mai avuto bisogno di "dimostrare" questa tracciabilita' nei confronti di un committente o di un soggetto di auditing, ma se ne avessi bisogno potrei farlo. Indubbiamente non sono in grado di produrre questa tracciabilita' **prima** di scrivere il codice, ma e' veramente questo il punto?

*) Pair Programming: l'aumento del costo del personale riportato dallo studio di Nosek (29%) assume un significato diverso nel contesto del lavoro di Laurie Williams (successivo a quello di Nosek), la quale ha basato il proprio esperimento su un gruppo di studenti si' esperti, ma sicuramente non affiatati come un team XP abituato a lavorare assieme. I numeri che riporta la Williams, vanno da un massimo del 60% a un minimo del 15% di overhead; la riduzione e' conseguenza dell'aggiustamento mano a mano che i componenti della coppia si impratichiscono e imparano a conoscersi. E comunque vorrei ricordare che parliamo di un campione di 15 programmatori nel caso di Nosek su un task di 45 minuti (!) e di 41 studenti nel caso della Williams su 4 diversi programmi: anche se statisticamente significativo, e' il caso di non dimenticarsene. A quando studi piu' consistenti su team professionali che pratichino anche frequenti pair switch, nell'arco di diverse iterazioni o progetti? Oltre al sottoscritto, il mio team è composto da 6 persone che lavorano assieme da più di 1 anno (alcune da 3 anni ormai) e che si conoscono a tal punto a volte da intendersi con un semplice cenno ==> in che modo possiamo paragonare queste relazioni con quelle occasionali che necessariamente vengono condotte negli esperimenti di Nosek, Williams e altri?
Inoltre, uno dei punti salienti del lavoro di Laurie Williams e' l'impatto che questo (presunto) overhead di costo ha sulla qualita': non ne condivido in toto le conclusioni raggiunte, ma va da se' che il minor numero di difetti dei programmi fatti in coppia comporta in misura esponenziale una riduzione del tempo necessario a fissare tali difetti. Vogliamo ragionarci sopra?

*) La visione del TDD semplicemente come "una forma di programmazione per contratto", di tipo procedurale anziche' dichiarativo, e' un'altra di quelle semplificazioni che nascondono una gran parte della realta': il TDD e' anche una tecnica di esplorazione e di modellazione estremamente efficace, indissolubilmente collegata con simple design e refactoring

*) TDD per come e' visto da Mueller: ammetto che la definizione ripresa da Ron Jeffries e' sconsolante, ma per fortuna c'e' ormai parecchio materiale alternativo, come quello di Beck ==> stupisce che il paper di Mueller (aprile 2002) non lo menzioni dato che i primi draft di Beck sono pubblici a partire da febbraio 2002.
Al solito, l'esperimento e' condotto su studenti, e senza coinvolgere esponenti del mondo XP. In ogni caso, mi riservo di esporre in seguito mie critiche piu' approfondite su questo tema. Quantomeno mi sembra opinabile fare uso di questi dati, quando la Williams ha fatto almeno lo sforzo di coinvolgere Jeffries, Cunningham ecc.

*) Non capisco in che modo "affidando la convalida dei requisiti sempre e solo all ’esecuzione dell ’applicazione, la possibilità di esplorare soluzioni alternative è fortemente ridotta": intanto nulla in XP vieta di convalidare il sistema attraverso altri modi oltre a quello che passa per l'esecuzione dell'applicazione ==> diciamo che l'esecuzione non puo' essere evitata, ma potrebbe essere benissimo affiancata da altri modi. Inoltre, il tipo di rapporto che si instaura tra customer e sviluppatori e' tale da stimolare continuamente soluzioni alternative e nuove opportunità di business. Mi stupisce che questo aspetto, come altri, sia stato totalmente ignorato.

*) "L’integrazione continua e la proprietà condivisa di tutto il codice, poi, sembrano tecniche del tutto inapplicabili quando il numero di programmatori sale e il numero dei conflitti diventa ingestibile." ==> questa e' una delle poche critiche sensate e che infatti sono oggetto di una grande quantita' di ricerca e letteratura, ma il metodo con cui viene affrontato il tema non mi sembra molto corretto. E' un fatto che esistono team XP composti da decine di componenti. E' un fatto che esistono progetti XP che risultano in migliaia di classi (su tutti c3 e lifeware). Quindi il tema e' probabilmente un po' piu' vasto e complesso e non liquidabile superficialmente in poche parole.

*) Refactoring: "Al momento gli strumenti per operare queste ristrutturazioni in maniera semi-automatica sono ancora piuttosto rozzi. Pertanto, attualmente, sembra possibile ristrutturare in maniera consistente solo porzioni di codice di dimensioni relativamente modeste." ==> si veda ad esempio il progetto su cui sta lavorando Gosling e di cui vi ho parlato al ritorno da OOP2003, ma anche con gli strumenti attualmente disponibili (open source come Eclipse o con un costo tutto sommato modesto come IDEA) io sono in grado in un solo giorno di ristrutturare radicalmente centinaia di classi, avendo test continuamente funzionanti e integrando l'intera codebase magari piu' volte. E' questo che si intende per "porzioni di codice di dimensioni relativamente modeste"?

Cosi' come feci con un professore fiorentino animato da furore acrimonioso, penso di contattare personalmente Ghezzi e segnalargli queste critiche; inoltre, gli offriro' la mia disponibilita' a collaborare e a fornire quelle evidenze sperimentali che possano fare piazza pulita di molte misconceptions riguardo a XP. Vedremo se in questo caso ci sara' piu' spirito collaborativo. Vi faro' sapere se ci saranno evoluzioni.

Ciao, Giuliano
 
 

Marco Abis wrote:

Salve a tutti,

      grazie alla segnalazione di un membro dell'Italian Agile Movement sono venuto a conoscenza di un articolo pubblicato su un periodico digitale di AICA (Associazione Italiana per l'Informatica ed il Calcolo Automatico) che tenta di esaminare l'XP e spiegare perchè non è nulla di nuovo e come si risolva in un "silver bullet fallito".

Dato che AICA è un'associazione seria e che gli autori del pezzo sono evidentemente in buona fede abbiamo deciso di scrivergli ma prima di farlo abbiamo aperto la discussione a questo indirizzo:

http://agilemovement.it/modules.php?op=modload&name=News&file=article&sid=70&mode=thread&order=0&thold=0

Chi meglio di voi potrebbe unirsi alla discussione? Mi piacerebbe in seguito coinvolgere i due autori dell'articolo in questione per cercare di scambiarci le idee.

I commenti possono essere lasciati anche dagli anonimi quindi non è necessario che vi iscriviate per partecipare alla discussione.

Grazie per l'attenzione, buona notte :-)

Marco Abis
http://www.agilemovement.it - Uncovering better ways of developing software

To unsubscribe from this group, send an email to:
extremeprogramming-it-unsubscribe@egroups.com
 
 

L'utilizzo, da parte tua, di Yahoo! Gruppi è soggetto alle http://it.docs.yahoo.com/info/utos.html

Come già preannunciato qualche di tempo fa, il sottoscritto e Francesco
Cirillo (rispettivamente: laureando in Informatica, nonchè intervistatore, e
CEO di XPLabs, intervistato) hanno realizzato un'intervista sull'attuale
stato di salute dell'XP nel nostro paese e sulle sue prospettive future.

Cosa non vuol essere l'intervista: la spiegazione di cosa sia la
programmazione estrema. Cosa vuole essere allora? Il primo obiettivo è
quello di focalizzare sul "passaggio all'XP", indagando un caso reale
(Francesco ha fatto da cavia! ;-) ), approfondendo resistenze e difficoltà
incontrate ed indicando in qual modo vengano superate o sia consigliabile
superarle. Un secondo obiettivo, seguendo un'ideale linea cronologica
nell'esperienza dell'intervistato, è quello di sviscerare fino in fondo
l'effettiva utilità di questo nuovo metodo, indivuando eventuali punti
deboli o di forza. Per chi, come il sottoscritto, si avvicina per la prima
volta ad XP è fondamentale avere la sensazione di essere di fronte ad un
metodo di successo, al di là delle ovvie considerazioni di parte dei testi
scritti dai padri stessi dell'XP. L'ultima parte è dedicata ad una serie di
considerazione in merito alla capacità e alla possibilità di diffusione nel
breve e medio periodo di questo fenomeno.

Trovo il lavoro molto interessante, quanto meno dal punto di vista chi si
sta avvicinando all'XP, ma sono convinto che le risposte possano stimolare
un pò tutti. In fin dei conti solo rivedendo criticamente la propria
esperienza XP si ha modo di fare un bilancio, e questa intervista può
servirvi come traccia, come percorso interiore nel caso intendeste farlo.

Vi invitiamo quindi ad andare a leggere l'intervista
(http://www.communications.xplabs.com/experience2003-1.html), e attendiamo
(curiosi) vostro feedback.

Saluti,
Massimo

Vorrei segnalarvi un thread molto caldo di feedback/discussione
sull'intervista: http://www.wup.it/article.php/sid/3355.

Penso possano emergere argomenti interessanti per la chat. Anche per quella di
oggi se volete.

Attendo di leggere il vostro feedback sulla lista,

Francesco

Ho finalmente pubblicato un po' di informazioni sul progetto M@rketInfo,
di cui ho già parlato ogni tanto in passato.

Trovate tutti i link su
http://www.extremeprogramming.it/cgi-lib/wiki.cgi?ProgettoMarketInfo

Comunque sia un po' di materiale è disponibile su
http://www.quinary.com/pagine/clients/featured_frame.htm, in particolare

*) slides:
http://www.quinary.com/pagine/downloads/files/Resources/OOP2003Presentation.pdf

*) paper:
http://www.quinary.com/pagine/downloads/files/Resources/OOP2003Paper.pdf

Naturalmente mi piacerebbe molto avere il vostro feedback.
Ciao, Giuliano

Ciao Francesco,

ho letto il thread. Un sacco di polemica sterile contro cio' che e' nuovo e non
si conosce, come al solito.
Molti dei commenti contro xp vengono da persone che non l'hanno nemmeno mai
provato.

Lavoro con XP da ormai TRE anni e per me e' un successo.
Ti diro' di piu', ora che ho deciso di tornare in italia per un annetto o piu'
ho gia' organizzato i miei progetti in modo da usare XP. La mia piccola
"company" funzionera' secondo i principi di XP. Non seguendolo come una
religione, ma traendo tutto cio' che di buono offre (cioe' quasi tutto, per un
team piccolo).

Volevo inoltre segnalare un articolo apparso da poco su javasoft.com dove si
presenta l'ultima "Encyclopaedia Britannica" scritta quasi interamente in
java...
lo segnalo non tanto per java, ma perche' ...

"Following "XP" principles -- Extreme Programming -- the Britannica team relied
[...] Using four core developers, and farming small tasks out, they finished the
project in less than a year"

Paolo Polce
London / UK





>  from:    Francesco Cirillo <francesco.cirillo@...>
>  date:    Tue, 18 Feb 2003 07:08:02
>  to:      extremeprogramming-it@yahoogroups.com
>  subject: Re: [xp-it] Feedback su "Arrivare a XP" (interview)
>

ho dimenticato il link, sorry:

http://java.sun.com/features/2003/02/britannica.html

P

Ciao Paolo,

Mi sono preso un ringraziemento che non meritavo... :) (in realta' avevo detto
che nel gruppo xp-it avevano pubblicato il link del sito sun, Kent ha fatto il
resto :) )

http://groups.yahoo.com/group/extremeprogramming/message/69950

Quando torni in Italia ti devo una pizza. :)

Francesco

......................................
  Francesco Cirillo
  CEO, XPLabs S.R.L.
  Coach, Bees Team
......................................
  XPLabs Center
  Via dei Castagni 22
  01015 Sutri VT
  ITALY
......................................
  Phone:  +39 0761 659161
  Fax:    +39 06   233236936
  Mobile: +39 339  3805339
  E-mail: francesco.cirillo@...
  URL:    http://www.xplabs.com
.....................................

Hello Francesco,

Thursday, February 20, 2003, 8:58:38 PM, you wrote:

FC> Mi sono preso un ringraziemento che non meritavo... :) (in realta' avevo
detto
FC> http://groups.yahoo.com/group/extremeprogramming/message/69950

FC> Quando torni in Italia ti devo una pizza. :)

ah! Io sono napoletano, quindi molto esigente in fatto di pizze! ;-))

Paolo

Ho appena mandato un mio feedback a WUP.

Penso dobbiamo essere grati a quel thread di discussione. Ha fatto emergere
dei punti che sarebbe importante affrontare su questa lista. Ad esempio.

- Applicabilita' di XP in Italia.

Ecco il messaggio.

............................................................................
Ho seguito con attenzione la discussione su WUP, e' una discussione tra
programmatori e per questo ha il massimo rispetto da parte mia.

Ramtop sostiene di avere intrattenuto con me una serie di email. Finche'
rimane anonimo non posso ovviamente confermarlo :).

In quelle email gli avrei dato la sensazione di essere, cito "uno di quelli
che 'mai avuto dubbi in vita mia'". Beh, chiunque tu sia ramtop, di dubbi ne
ho sempre avuti e continuo ad averne. L'unica certezza che ho e' che non
voglio lavorare in certo un modo: requisiti che cambiano continuamente durante
lo sviluppo, qualcuno che stima al posto mio, programmatori che pur di non
chiedere aiuto sono disposti a farsi venire un esaurimento, lo sport
del "salto della fase di testing", la sindrome del "tutto e' colpa del
cliente", l'altra sindrome del "il design era giusto e' colpa del
programmatore", e quella del "io programmo, ma se il design e' sbagliato/non
c'e', non e' colpa mia", l'altra ancora del "stanotte ci penso io a mettere a
posto quel bug", l'altra del "caro cliente questa modifica non si puo' fare, o
se proprio la vuoi fare costera' tantissimo e non posso dirti quando l'avrai",
etc.

Bada bene ramtop, non parlo dall'alto di una esperienza teorica e astratta, io
le ho passate tutte almeno una volta, da programmatore, da project leader, da
project manager, da mentor, e non ci voglio ritornare. Da sempre lavoro per
trovare un altro modo di lavorare/far lavorare team di sviluppo e devo
continuare ad avere dubbi per non ricadere negli stessi errori.

E' inapplicabile XP in Italia?! Il vero problema non sta tanto nei clienti...
sta invece nel trovare un gruppo di programmatori che spontaneamente condivida
i valori di XP: la comunicazione, la semplicita', il feedback il coraggio (di
chiedere aiuto, di dire al cliente in questa iterazione abbiamo consegnato la
meta' delle funzionalita'). Le pratiche si costruiscono sopra i valori.

Con i clienti poi si e' chiari, costi e benefici, loro scelgono. (Se sai
veramente far crescere un sistema in modo evolutivo l'offerta e' assai
interessante per un cliente...)

I nostri clienti sono baronetti oxfordiani?! :). No in genere sono persone che
hanno interesse in quello che fanno (perche' vogliono far carriera con un
progetto di successo, perche' sono imprenditori che hanno un'idea di business
da sviluppare, etc.).

Cominciamo da quelli. Altri ne verranno quando capiranno cosa realmente puo'
offrire un team XP. Voi mi direte il mio cliente non ha interesse in quello
che fa. La mia risposta e' voi avete interesse in quello che fate?

XP e' un silver bullet? L'object oriented e' un silver bullet? I design
pattern sono un silver bullet?

Se sapete come usarli a vostro vantaggio no. Per sapere come usarli pero'
dovete lavorare parecchio, niente di regalato. Io ho dovuto lavorare parecchi
anni per iniziare a capire ognuna di  queste cose. Se dalla loro comprensione
traete spunto per rendere piu' efficace il vostro processo/come programmate,
no, non sono silver bullet. Innanzitutto pero' dovete sforzarvi di conoscerlo.
Fino a che penserete di usare i design pattern perche' avete il libro li'
vicino, o perche' state "copiando una soluzione" dal GoF (il libro sui Deisgn
Pattern di Gamma Vlissides, Helm, Johnson), i design pattern saranno un silver
bullet. Insomma per fare in modo che queste cose vi aiutino a sviluppare
meglio dovete lavorarci su e capirle. Nulla, ritengo neanche il
lambdazhang :), puo' acquisirsi senza sforzo. Niente scorciatoie.

Non dimentichero' mai una situazione che capito' in una grande banca italiana
qualche anno fa. Si parlava col capo dell'IT di XP. Ai tempi era praticamente
sconosciuto e a un certo punto il rappresentante di una grossa azienda
consulente, vedendo il manager molto interessato disse "anche noi abbiamo
sulla lavagna scritto XP, anche noi lo facciamo". Da allora, questa e' la mia
piu' grande paura.

Continuamente incontro persone che "fanno XP". O meglio pensano di fare XP.
Pensano di fare XP perche' pensano di fare refactoring (ma non sanno nulla di
design object oriented), perche' pensano di fare test-first (scrivendo ex-
ante, i test di una classe, senza farli evolvere), perche' pensano che
buttando giu', magari tra mezzanotte e l'una di notte, magari da soli, qualche
linea di codice non troppo documentata, che loro stessi non saprebbero
commentare dopo una settimana, stanno facendo XP, o che magari solo per il
fatto di trovarsi in due davanti a un computer, stiano facendo automaticamente
XP ;). Niente pratiche, niente valori! Ma la mia piu' grande paura e quando
incontro team in cui si applicano alcune o anche tutte le pratiche, senza
valori. Senza valori qualsiasi progetto XP e' destinato a fallire. Questa e'
la mia piu' grande paura.

Infine, a chi si dice interessato ad XP, al refactoring al test-driven
development, consiglio di seguire la lista italiana di XP
(http://it.groups.yahoo.com/group/extremeprogramming-it/).

Grazie per il vostro feedback.

--Francesco Cirillo
............................................................................

Francesco

......................................
  Francesco Cirillo
  CEO, XPLabs S.R.L.
  Coach, Bees Team
......................................
  XPLabs Center
  Via dei Castagni 22
  01015 Sutri VT
  ITALY
......................................
  Phone:  +39 0761 659161
  Fax:    +39 06   233236936
  Mobile: +39 339  3805339
  E-mail: francesco.cirillo@...
  URL:    http://www.xplabs.com
.....................................

>Ho appena mandato un mio feedback a WUP.

letto

>Penso dobbiamo essere grati a quel thread di discussione. Ha fatto emergere
>dei punti che sarebbe importante affrontare su questa lista. Ad esempio.

quando l'ho segnalato su Wup ne ero sicuro (come ero sicuro + o - dei commenti
che ci sarebbero stati date passate esperienze).

>- Applicabilita' di XP in Italia.

Ti diro': comincio a credere che ormai sia più una "nostra" (inteso come
Italiani) convinzione che in Italia è diverso, in Italia qui, in Italia la, bla
bla bla e anzi se vi leggete i commenti che la gente ha lasciato su Slashdot
alla recensione di "Agile Software Development with Scrum" vedrete che non si
discosta poi cosi tanto da quelli su Wup.

Sicuramente c'e' un fattore culturale da tenere in considerazione ma non so
quanto a questo punto sia un fattore culturale dei singoli Italiani: del resto
XP/Agile vanno comunque a far evolvere la cultura dell'azienda in cui vengono
"accettati e condivisi" sia essa Italiana o straniera.

Posso concedere che in Italia fino ad oggi non sempre si siano adottati
processi/metodologie (indipendentemente dal fatto che siano utili o meno a
nostro parere) ma forse questo potrebbe essere addirittura un vantaggio per noi:
in quelle realtà in cui il CMM o il PMI non sono mai entrati ci sarà una cultura
più facilmente adattabile che in altre dove ormai da anni l'obiettivo è
raggiungere un livello del CMM qualsiasi o la certificazione come PMP di tutti i
manager.



Marco Abis - CEO & Chairman
Agility SPI: Software Process Improvement
abis@... - abis@...
http://agilemovement.it

Queste sono le mie riflessioni che ho aggiunto al newsgroup di wup

------------------------------------------------------------------------
-----------------------------------------------
Ciao a tutti,
mi accodo a questa discussione per aggiungere alcune mie riflessioni
personali da XPer non praticante :-) nel senso che pur conoscendo le
pratiche di XP non le adotto tutte(in maniera estrema).

Uno dei punti da tenere in considerazione sempre e comunque è il
contesto, XP è un insieme di pratiche che sono efficaci anche da sole
diventano fortemente efficienti quando sono applicate tutte assieme.
Sono state pensate per risolvere dei problemi anche soggettivi in
maniera oggettiva.

Io sono arrivato a XP perché avevo dei problemi da risolvere, i classici
problemi nello sviluppo del software. Ho cercato delle pratiche che mi
aiutassero a risolverli

Perdonatemi questo esempio leggero:
- il cliente non riesce a comunicare con il team di sviluppo le
specifiche in modo chiaro ecco che le User Stories possono risolvere il
problema. Perché non ho usato Uses Cases (UML..) “semplicemente” perché
nel contesto in cui mi muovo non era applicabile. Per contesto mi
riferisco proprio al cliente e ai programmatori.

Non esiste la soluzione definitiva ma la soluzione migliore per quel
contesto. L’unico problema che ha XP, a mio avviso, è che necessità di
un team composto da programmatori con solide basi un team composto da
junior ha grosse difficoltà ad applicare XP perché deve affrontare il
problema “di come fare” ovvero fare esperienza sul linguaggio e sui
paradigmi di programmazione e non di cosa pensare per risolvere le
esigenze del cliente nel modo migliore possibile.
------------------------------------------------------------------------
--------------------------------------------

Marco De Toni
marco.detoni@...

ALLOS SpA
tel. +39 049 9414411
fax +39 049 9414430
http://www.allos.it
__________________________________________

PRIVACY
Se lei non è il destinatario in indirizzo la preghiamo
di avvisarci e di eliminare questa e-mail.

If you are not the intended recipient, please
notify us and destroy this e-mail.
__________________________________________

ecco il mio (postato su wup):


...

Salve a tutti,

vorrei dare il mio contributo a qs discussione.

Sono un XP'er da ormai tre anni ed ho avuto la fortuna di lavorare per una
azienda (qui a Londra) che e' stata <strong>fondata per lavorare con
XP</strong>. Abbiamo un ufficio con grossi pannelli scorrevoli per attaccare le
index card che usiamo per scrivere le storie, abbiamo le scrivanie progettate in
modo da far lavorare comodamente <strong>due persone ad ogni
postazione</strong>. Abbiamo (noi developers)
  insegnato a tutti i ragazzi delle vendite/marketing come scrivere le storie.
Abbiamo spiegato loro come interpretare gli estimates, il load factor e via
cosi'...
Con un rodato sistema di pair programming in ogni momento ogni singolo
programmatore conosce il 100% del codice com'era due settimane prima, 90%
com'era una settimana prima e l'80% di com'e' allo stato attuale.
Il che vuol dire che <strong>chiunque puo' lavorare sempre su ogni parte del
sistema</strong>.
Cio' ha degli enormi vantaggi: prima di tutto, si ha una visione di insieme del
sistema che e' condivisa fra tutti gli sviluppatori (in accordo col concetto di
metaphor) e secondo non c'e' il problema di tizio che non puo' andare in vacanza
perche' e' l'unico che conosce quel pezzo di sistema e proprio oggi c'e' il
cliente che vuole effettuare delle modifiche!
Inoltre, abbiamo avuto dei programmatori junior che si sono messi al passo con
gli altri ad una velocita' incredibile, sempre grazie al pair programming.
Certo, magari all'inizio hanno leggermente rallentato il senior che doveva
fermarsi e spiegare un po' quel che faceva, ma vi assicuro che ne abbiamo
davvero guadagnato.

<i>Integrazione continua e small releases</i>:
La ns azienda ha lavorato ad un progetto (parte web, parte client per windows)
per circa una 30ina di iterazioni da tre settimane. Man mano che i mesi
passavano i ns clienti hanno cominciato ad esprimere la volonta' di avere un
sistema sempre piu' web-based e con sempre meno parte client-windows.
Beh, refactor dopo refactor, mentre cmq il prodotto andava avanti, la ns
baseline si e'evoluta ed il prodotto e' completamente cambiato. Tutto nel
rispetto della barra verde dei ns 1500(circa) junit test, nonche' dei test
multi-piattaforma (vmware) ed altri scritti ad arte.
I ns clienti sanno che, sebbene a volte con qche piccolo ritardo, noi consegnamo
sempre. E questo secondo me e' uno dei punti forza di XP.

<i>Si puo' applicare XP in italia?</i>
Non credo sia facile convincere i manager che non e' vero che "si pagano due
persone per fare il lavoro di una" e via dicendo. O cmq non si puo' convincerli
a parole. Ma i fatti ci sono. Ogni giorno piu' aziende guardano ad XP come
soluzione o aiuto al loro processo produttivo.

oltre alla mia esperienza personale, una delle ultime storie che ho letto e'
questa:

http://java.sun.com/features/2003/02/britannica.html

Limiti di XP?
<li>Credo non sia applicabile se il team e' numeroso (piu' di 15 programmatori).
</li>
<li>Richiede un po' di programatori senior, perche' come ha osservato qcuno, hai
voglia a tentare di fare refactoring se non hai buoni skill di design oop e non
conosci bene il linguaggio che stai usando.</li>

Concludo dicendovi che credo talmente tanto ai "consigli" che XP mi ha dato, che
i miei prossimi progetti (non piu' con l'azienda per la quale lavoro ma con una
mia, in italia) saranno tutti seguiti (e portati a termine!) utilizzando
-appunto- i principi dell'eXtreme Programming.


bye,

Paolo Polce
London / UK







>  from:    Francesco Cirillo <francesco.cirillo@...>
>  date:    Fri, 21 Feb 2003 10:06:18
>  to:      extremeprogramming-it@yahoogroups.com
>  subject: Re: [xp-it] mio feedback a wup.it
>

ciao a tutti,
mi è arrivata un e-mail dove mi si chiede di presentare la mia esperienza
con XP... sarò quindi molto breve :)! Lavoro da 2 anni nell'ambito dell'IT,
finora al dicembre del 2002 il mio lavoro consisteva principalmente nella
manutenzione di programmi scritti in C, finchè non mi è stato affidato un
progetto nuovo in cui svolgo ogni ruolo: progettista, sviluppatore e chi più
ne ha più ne metta... sono entrato in contatto con XP durante un corso di
programmazione in C++, dove il tutore vi ha fatto un breve riferimento. Per
conto mio ho poi iniziato a gironzolare per internet, cercando di capire
cosa fosse questo XP, principalmente perchè il sito che il tutore ci aveva
fornito era carino a vedersi (sono superficiale, lo so! :-)),
www.extremeprogramming.org.

"Uhmm," mi dicevo "questo metodo sembra promettere di risolvere tutti i
problemi che ho sempre (e sottolineo sempre) visto nei progetti che mi è
capitato di seguire ultimamente... forte!", e da lì a poco è seguito
l'acquisto dell'ultimo libro di Robert Martin.

Purtroppo la mia azienda non vede di buon occhio questo metodo di sviluppo,
i responsabili pretendono che le fasi di analisi, design e sviluppo siano
separate, che i requisiti forniti dal cliente siano fissi ed immutabili e
che al momento dell'analisi si sappia già stimare i tempi richiesti per
sviluppare il progetto (affinchè i commerciali siano in grado di fare
l'offerta, ovviamente). In più, sono ancora troppo 'junior' per potermi
permettere di avanzare proposte rivoluzionarie di questo genere (la mia
opinione conta come il 2 di picche, in parole povere)... morale della
favola? il progetto che sto seguendo è destinato a fallire in partenza:
saranno necessarie ore di straordinario per consegnare nei tempi previsiti,
il cliente non sarà soddisfatto del risultato e tutte le altre belle cose
che probabilmente già vi immaginate.

be', questo è più o meno quanto, spero di poter collaborare in qualche
maniera alla crescita di questa ML, e di poter migliorare come
professionista dell'IT. Buona giornata a tutti!

Ho letto il thread presente su wup, e poi l'intervista a Francesco,
questa mattina in treno, e credo che in quest'ultima ci siano molti
spunti interessanti, soprattutto su perchè XP costituisca
un'alternativa valida ai tradizionali processi di sviluppo sw.

solo qualche esempio:
- considerare il cambiamento un rischio contro la rottura di
componenti del sistema già in produzione, e per questo,
strumentalizzare un documento di specifiche, per recusare richieste
di cambiamento
- preferire documenti formali alla comunicazione e interazione fra
gruppi di lavoro.
- trascurare la responsabilità di team, rispetto a quella del singolo
individuo ("quella classe non l'ho scritta io.." ;-))
- supportare costi di manutenzione del sistema maggiori rispetto a
quelli sostenuti per sviluppare nuove funzionalità.
- etc. etc.
Ecco, credo che qualsiasi organizzazione che si occupi di sviluppo
software, e che si ritrovi in uno di questi scenari debba porsi la
domanda se non esista un processo di sviluppo più efficace. Ho
sperimentato XP per un breve periodo, ma credo di poter affermare che
offre un'ottima alternativa; se poi sia l'unica non lo so, ma questo
è meno importante; d'altronde XP non è dogmatico: il confronto, il
cambiamento, non fanno paura a un team XP, o no?

ad majora!
ernesto



--- In extremeprogramming-it@y..., Francesco Cirillo
<francesco.cirillo@x> ha scritto:
> Vorrei segnalarvi un thread molto caldo di feedback/discussione
> sull'intervista: http://www.wup.it/article.php/sid/3355.
>
> Penso possano emergere argomenti interessanti per la chat. Anche
per quella di
> oggi se volete.
>
> Attendo di leggere il vostro feedback sulla lista,
>
> Francesco

Intanto benvenuto.

Capisco la frustrazione che può derivare dall'iniziare un nuovo progetto con la
convinzione che sarà
un fallimento, ma se tu avessi il potere di decidere autonomamente, qual è il
primo problema che
vorresti affrontare? In che modo? Come pensi che migliorerebbe l'efficacia del
team? In particolare,
quale aspetto di XP può aiutarti a risolvere il tuo problema più grave/urgente?

Ci sono molti modi x cambiare in positivo l'organizzazione nella quale si
lavora, ma in tutti quanti è
necessario portare dei risultati x essere + convincenti e vincere le resistenze
insite in ogni
organizzazione.

Personalmente ti consiglio di dare un occhio ai seguenti link, magari puoi
trovare qualche spunto
utile:
*) http://www.extremeprogramming.it/cgi-lib/wiki.cgi?XpTransformationDiary
*) http://c2.com/cgi/wiki?ChangeYourOrganizationDiary

Buona fortuna e facci sapere.
Ciao, Giuliano

Simone Finotti wrote:

> ciao a tutti,
> mi è arrivata un e-mail dove mi si chiede di presentare la mia esperienza
> con XP... sarò quindi molto breve :)! Lavoro da 2 anni nell'ambito dell'IT,
> finora al dicembre del 2002 il mio lavoro consisteva principalmente nella
> manutenzione di programmi scritti in C, finchè non mi è stato affidato un
> progetto nuovo in cui svolgo ogni ruolo: progettista, sviluppatore e chi più
> ne ha più ne metta... sono entrato in contatto con XP durante un corso di
> programmazione in C++, dove il tutore vi ha fatto un breve riferimento. Per
> conto mio ho poi iniziato a gironzolare per internet, cercando di capire
> cosa fosse questo XP, principalmente perchè il sito che il tutore ci aveva
> fornito era carino a vedersi (sono superficiale, lo so! :-)),
> www.extremeprogramming.org.
>
> "Uhmm," mi dicevo "questo metodo sembra promettere di risolvere tutti i
> problemi che ho sempre (e sottolineo sempre) visto nei progetti che mi è
> capitato di seguire ultimamente... forte!", e da lì a poco è seguito
> l'acquisto dell'ultimo libro di Robert Martin.
>
> Purtroppo la mia azienda non vede di buon occhio questo metodo di sviluppo,
> i responsabili pretendono che le fasi di analisi, design e sviluppo siano
> separate, che i requisiti forniti dal cliente siano fissi ed immutabili e
> che al momento dell'analisi si sappia già stimare i tempi richiesti per
> sviluppare il progetto (affinchè i commerciali siano in grado di fare
> l'offerta, ovviamente). In più, sono ancora troppo 'junior' per potermi
> permettere di avanzare proposte rivoluzionarie di questo genere (la mia
> opinione conta come il 2 di picche, in parole povere)... morale della
> favola? il progetto che sto seguendo è destinato a fallire in partenza:
> saranno necessarie ore di straordinario per consegnare nei tempi previsiti,
> il cliente non sarà soddisfatto del risultato e tutte le altre belle cose
> che probabilmente già vi immaginate.
>
> be', questo è più o meno quanto, spero di poter collaborare in qualche
> maniera alla crescita di questa ML, e di poter migliorare come
> professionista dell'IT. Buona giornata a tutti!
>
> To unsubscribe from this group, send an email to:
> extremeprogramming-it-unsubscribe@egroups.com
>
>
>
> L'utilizzo, da parte tua, di Yahoo! Gruppi è soggetto alle
http://it.docs.yahoo.com/info/utos.html

Ciao,

desideriamo farti sapere che, nella sezione File del gruppo
extremeprogramming-it, troverai un nuovo file appena caricato.

   File :        /xp-it chat 25-02-2003.txt
   Caricato da : loris_u <loris.u@...>
   Descrizione : log chat 25 febbraio 2003

Puoi accedere al file dal seguente indirizzo:
http://it.groups.yahoo.com/group/extremeprogramming-it/files/xp-it%20chat%2025-0\
2-2003.txt

Per ulteriori informazioni su come condividere i file con gli altri
iscritti al tuo gruppo, vai invece alla sezione di Aiuto al seguente
indirizzo:
http://help.yahoo.com/help/it/groups/files


Cordiali saluti,

loris_u <loris.u@...>

----- Original Message -----
> Intanto benvenuto.
>
> Capisco la frustrazione che può derivare dall'iniziare un nuovo progetto
con la convinzione che sarà
> un fallimento, ma se tu avessi il potere di decidere autonomamente, qual è
il primo problema che
> vorresti affrontare? In che modo? Come pensi che migliorerebbe l'efficacia
del team? In particolare,
> quale aspetto di XP può aiutarti a risolvere il tuo problema più
grave/urgente?

ora come ora il mio maggior problema è il fatto che il "team" è composto da
me e basta. Siccome non penso di avere la sufficiente esperienza per poter
gestire un progetto da solo la mia maggior preoccupazione è di fare troppi
errori nelle prime fasi e arrivare alla fine con un codice ingestibile
(sempre che arrivi alla fine)... o che non riesca a rispettare la deadline.

> Ci sono molti modi x cambiare in positivo l'organizzazione nella quale si
lavora, ma in tutti quanti è
> necessario portare dei risultati x essere + convincenti e vincere le
resistenze insite in ogni
> organizzazione.

senz'altro... il problema è che non so se sono in grado di portare qualcosa
che possa essere considerato un risultato positivo: il progetto in questione
non è propriamente banale (sempre a lamentarmi eh? :) )

> Personalmente ti consiglio di dare un occhio ai seguenti link, magari puoi
trovare qualche spunto
> utile:
> *) http://www.extremeprogramming.it/cgi-lib/wiki.cgi?XpTransformationDiary
> *) http://c2.com/cgi/wiki?ChangeYourOrganizationDiary

grazie, vedrò di leggerli appena posso!

Open Limited Term Researcher Position
Free University of Bozen
Center for Applied Software Engineering

A Limited Term Researcher position in the area of agile
methodologies for software engineering is being opened at the Free
University of Bozen in the Center for Applied Software Engineering.
The position is somehow equivalent to a Research Assistant Professor
position in North America, a C2 Researcher position in Germany, a
Lecturer in the UK.

Perspective candidates should have a Doctoral degree in Computer
Science; Software, Computer or Electrical Engineering; Management
Information Systems, or similar area.

The candidates should have strong software engineering and
mathematical skills, be proficient in English, interested in a R&D
career in the industry or the academia.

The Free University of Bozen is a newly established university,
located Bozen (Italy). Bozen is a multicultural, dual language city
located in the middle of the Dolomites, which enjoys proximity to
major industrial centers (Milan, Munich, Verona, ...), still
preserving the profile of a small mountain center. Bozen is the
provincial capital of the autonomous province of South Tyrol.

The conditions of work are remarkable, with competitive salaries and
excellent benefit packages.

Further information on the Free University of Bozen can be found at
the URL: http://www.unibz.it, on the city of Bozen at URL:
http://www.comune.bolzano.it, and on the autonomous province of
South Tyrol at URL: http://www.provinz.bz.it.

To apply for the position please contact Ms. Margit Pircher
(Margit.Pircher@...).

Applicants should e-mail a PDF file containing:

- their resume
- a summary of their education with grades
- TOEFL score, unless they have a degree from English,
   German or Italian speaking institutions
- list of papers published in English-speaking forums,
   if any; copies of papers published in English-speaking
   forums could also be attached, still in PDF format.


--

Giancarlo Succi, PhD, PEng
Professor and Director
Center for Applied Software Engineering
Faculty of Computer Science
Free University of Bozen
Domenikanerplatz 3 Piazza Domenicani
I-39100 Bozen, Italy
ph: +39(0471)315-640 - fax: +39(0471)315-649
e-mail: Giancarlo.Succi@...
XP2003 web site: www.xp2003.org

Simone Finotti wrote:

> ----- Original Message -----
> > Intanto benvenuto.
> >
> > Capisco la frustrazione che può derivare dall'iniziare un nuovo progetto
> con la convinzione che sarà
> > un fallimento, ma se tu avessi il potere di decidere autonomamente, qual è
> il primo problema che
> > vorresti affrontare? In che modo? Come pensi che migliorerebbe l'efficacia
> del team? In particolare,
> > quale aspetto di XP può aiutarti a risolvere il tuo problema più
> grave/urgente?
>
> ora come ora il mio maggior problema è il fatto che il "team" è composto da
> me e basta. Siccome non penso di avere la sufficiente esperienza per poter
> gestire un progetto da solo la mia maggior preoccupazione è di fare troppi
> errori nelle prime fasi e arrivare alla fine con un codice ingestibile
> (sempre che arrivi alla fine)... o che non riesca a rispettare la deadline.

Il mio consiglio non cambia molto: individua il problema principale, se non sei
in grado di risolverlo
da solo segnalalo al management, mettete in pratica delle azioni correttive e
verificate il risultato.
Anche questo è fare XP, o se preferisci lo puoi chiamare "buon senso".

Raccontaci come va.
Ciao, Giuliano

Ciao a tutti,
     giusto ieri ho mi sono laureato presentando la "famosa" tesi sull'XP. E'
andato tutto bene e sono piuttosto soddisfatto del lavoro fatto.

Giusto per darvi la possibilità di capire fino in fondo cosa possa essermi
passato attraverso in questi ultimi mesi nell'avvicinamento all'XP, vi
riporto (in coda) una piccola riflessione che ho scritto ripensando un pò
"dall'alto" al percorso fatto. Non è nulla di eccezionale, ma mi rappresenta
e rappresenta la mia attuale idea di XP. Naturalmente il cammino è ancora
lungo, ma ho la presunzione di essere sulla buona strada. ;-)

Ora mi attendono altri 4 esami, dopo i quali potrò laurearmi in modo
definitivo (la cosidetta laurea specialistica, non so se siete al corrente
dei nuovi ordinamenti). Per questo prossimo periodo probabilmente sarò preso
dagli studi e probabilmente verranno meno la mia attenzione e la mia
presenza in questa ML e su tutto ciò che ruota attorno ad XP, ma conto di
potervi comunque seguire a distanza.

Intanto vi ringrazio per le dritte e per il tempo che ognuno di voi ha
dedicato, anche in piccola parte, alla mia causa. Mi viene in mente uno
slogan simpatico per salutarvi: qualcuno direbbe "resistere resistere
resistere"... per quel che mi/ci riguarda potremmo dire "XP XP XP"! ;-))

Auguri a tutti,
Massimo



La prima volta che mi sono interessato all'XP ho avuto la netta sensazione
di avere a che fare con qualcosa di diverso più che nuovo. Ora, a distanza
di qualche mese dopo aver approfondito l'argomento per arrivarne a fare la
mia tesi di laurea, quella sensazione si è trasformata in convinzione. L'XP
è un metodo nuovo, perchè recente, ma è anche e soprattutto diverso, perchè
riporta il giusto equilibrio nello sviluppo software. Programmatore e
scrittura del codice innanzi tutto, il resto è solo uno strumento al
servizio di tale figura e della sua attività. La centralità della
programmazione non dovrebbe sconvolgere, eppure oggi ci  facciamo così
facilmente trasportare in un mare di cose ognuna delle quali ha
indubbiamente una sua importanza ma che se impiegate assieme nella misura
sbagliata impediscono anche al più abile programmatore di portare a termine
la sua opera. Siamo onesti: si perde un sacco di tempo a predisporre,
pianificare, progettare, scegliere gli strumenti adatti, rendere
generalizzabile, prevedere l'imprevedibile, ricamare, confezionare... e poi
si arriva alla fine che il prodotto è per metà ancora da fare! Allora scatta
la classica rincorsa alla consegna del giorno dopo, con i soliti inevitabili
catastrofici risultati. L'XP ha il merito innegabile di riportare in primo
piano il programmatore, fornendogli un set di pratiche già conosciute, ma
richiedendo di applicarle costantemente, non di tanto in tanto per validare
il codice o fare qualche controllo qua e là. Metodo e disciplina, sviluppare
in modo controllato e agile, muovendosi diritti verso l'obiettivo, senza
perdere tempo, mossi dal motore dei valori, condivisi e fatti propri a
priori. E' questo forse l'elemento che irrita i più, ovvero l'idea di
aderire a dei valori, come se non bastasse già la nostra religione a farci
rigar dritti! Mi domando: come si può immaginare di scindere il lato umano
dalla propria attività lavorativa? Non è concepibile, in ogni momento della
nostra vita, in qualunque lavoro siamo uomini innanzi tutto. Allora
l'assurdità non sta nel voler mettersi in gioco, ma nel ritenere che non vi
sia necessità di alcuna forma di controllo. Serve essere umili, ecco cosa
serve. Senza l'umiltà non si inizia neppure a fare XP, si sta solo cercando
di applicare qualche pratica, tutto lì.

Personalmente ho un solo rammarico: non aver potuto applicare questo metodo.
E' come essersi gustato una Ferrari guardandola e basta, senza poterci fare
un giro, insomma una soddisfazione a metà. Mi sono promesso di provare l'XP
non appena ne avrò l'opportunità e se l'azienda in cui lavorerò avrà la
consapevolezza delle potenzialità e del valore di XP, ma già ora, quando
scrivo qualche frammento di codice per le pagine del mio sito, quando creo
qualche script o semplicemente accendo il computer, penso subito: vediamo di
andar diritti al dunque, non serve aprire tanti programmi, far partire mille
processi in background, le cose che mi servono sono poche e semplici, e su
quelle devo concentrarmi. Se non lo si fosse capito nel mio piccolo sto già
facendo XP! E se questo metodo (o comunque lo vogliate chiamare) mi dà anche
solo la possibilità di risparmiare il  10% del mio tempo nelle cose che devo
fare... beh, direi che ha mantenuto le promesse!

Ho scritto una serie di articoli per la rivista IoProgrammo allo scopo di
diffondere il verbo dello unit testing (e di insegnare ad usare JUnit). Il
taglio della rivista è molto applicativo, quindi ho usato un tono un po'
evangelico e assolutista... Ma qui si trattava di convincere persone che
spesso sono abbastanza digiune di roba agile, qundi: a la guerre comme à la
guerre!

Nel numero attualmente in edicola dovrebbe esserci il secondo articolo della
serie (sono tre in tutto). Cercherò di convincere l'editore a pubblicare il
primo articolo sul sito della rivista. Ogni commento è ben accetto.

     Paolo Perrotta

Che posso dire? Ottimo feedback, continua così! :)

Ciao, Giuliano

Mhaxx wrote:

> Ciao a tutti,
>     giusto ieri ho mi sono laureato presentando la "famosa" tesi sull'XP. E'
> andato tutto bene e sono piuttosto soddisfatto del lavoro fatto.
>
> Giusto per darvi la possibilità di capire fino in fondo cosa possa essermi
> passato attraverso in questi ultimi mesi nell'avvicinamento all'XP, vi
> riporto (in coda) una piccola riflessione che ho scritto ripensando un pò
> "dall'alto" al percorso fatto. Non è nulla di eccezionale, ma mi rappresenta
> e rappresenta la mia attuale idea di XP. Naturalmente il cammino è ancora
> lungo, ma ho la presunzione di essere sulla buona strada. ;-)
>
> Ora mi attendono altri 4 esami, dopo i quali potrò laurearmi in modo
> definitivo (la cosidetta laurea specialistica, non so se siete al corrente
> dei nuovi ordinamenti). Per questo prossimo periodo probabilmente sarò preso
> dagli studi e probabilmente verranno meno la mia attenzione e la mia
> presenza in questa ML e su tutto ciò che ruota attorno ad XP, ma conto di
> potervi comunque seguire a distanza.
>
> Intanto vi ringrazio per le dritte e per il tempo che ognuno di voi ha
> dedicato, anche in piccola parte, alla mia causa. Mi viene in mente uno
> slogan simpatico per salutarvi: qualcuno direbbe "resistere resistere
> resistere"... per quel che mi/ci riguarda potremmo dire "XP XP XP"! ;-))
>
> Auguri a tutti,
> Massimo
>
> La prima volta che mi sono interessato all'XP ho avuto la netta sensazione
> di avere a che fare con qualcosa di diverso più che nuovo. Ora, a distanza
> di qualche mese dopo aver approfondito l'argomento per arrivarne a fare la
> mia tesi di laurea, quella sensazione si è trasformata in convinzione. L'XP
> è un metodo nuovo, perchè recente, ma è anche e soprattutto diverso, perchè
> riporta il giusto equilibrio nello sviluppo software. Programmatore e
> scrittura del codice innanzi tutto, il resto è solo uno strumento al
> servizio di tale figura e della sua attività. La centralità della
> programmazione non dovrebbe sconvolgere, eppure oggi ci  facciamo così
> facilmente trasportare in un mare di cose ognuna delle quali ha
> indubbiamente una sua importanza ma che se impiegate assieme nella misura
> sbagliata impediscono anche al più abile programmatore di portare a termine
> la sua opera. Siamo onesti: si perde un sacco di tempo a predisporre,
> pianificare, progettare, scegliere gli strumenti adatti, rendere
> generalizzabile, prevedere l'imprevedibile, ricamare, confezionare... e poi
> si arriva alla fine che il prodotto è per metà ancora da fare! Allora scatta
> la classica rincorsa alla consegna del giorno dopo, con i soliti inevitabili
> catastrofici risultati. L'XP ha il merito innegabile di riportare in primo
> piano il programmatore, fornendogli un set di pratiche già conosciute, ma
> richiedendo di applicarle costantemente, non di tanto in tanto per validare
> il codice o fare qualche controllo qua e là. Metodo e disciplina, sviluppare
> in modo controllato e agile, muovendosi diritti verso l'obiettivo, senza
> perdere tempo, mossi dal motore dei valori, condivisi e fatti propri a
> priori. E' questo forse l'elemento che irrita i più, ovvero l'idea di
> aderire a dei valori, come se non bastasse già la nostra religione a farci
> rigar dritti! Mi domando: come si può immaginare di scindere il lato umano
> dalla propria attività lavorativa? Non è concepibile, in ogni momento della
> nostra vita, in qualunque lavoro siamo uomini innanzi tutto. Allora
> l'assurdità non sta nel voler mettersi in gioco, ma nel ritenere che non vi
> sia necessità di alcuna forma di controllo. Serve essere umili, ecco cosa
> serve. Senza l'umiltà non si inizia neppure a fare XP, si sta solo cercando
> di applicare qualche pratica, tutto lì.
>
> Personalmente ho un solo rammarico: non aver potuto applicare questo metodo.
> E' come essersi gustato una Ferrari guardandola e basta, senza poterci fare
> un giro, insomma una soddisfazione a metà. Mi sono promesso di provare l'XP
> non appena ne avrò l'opportunità e se l'azienda in cui lavorerò avrà la
> consapevolezza delle potenzialità e del valore di XP, ma già ora, quando
> scrivo qualche frammento di codice per le pagine del mio sito, quando creo
> qualche script o semplicemente accendo il computer, penso subito: vediamo di
> andar diritti al dunque, non serve aprire tanti programmi, far partire mille
> processi in background, le cose che mi servono sono poche e semplici, e su
> quelle devo concentrarmi. Se non lo si fosse capito nel mio piccolo sto già
> facendo XP! E se questo metodo (o comunque lo vogliate chiamare) mi dà anche
> solo la possibilità di risparmiare il  10% del mio tempo nelle cose che devo
> fare... beh, direi che ha mantenuto le promesse!
>
> To unsubscribe from this group, send an email to:
> extremeprogramming-it-unsubscribe@egroups.com
>
>
>
> L'utilizzo, da parte tua, di Yahoo! Gruppi è soggetto alle
http://it.docs.yahoo.com/info/utos.html

Come suggerito da Francesco Cirillo:

1) Ma in pratica... in cosa consiste... cioe, si è bello parlare di
frasi ad effetto ma alla fin fine quali sono gli input che devono
arrivare ad un team per lavorare secondo le regole XP e quali sono le
regole per le quali un team XP si dice xp oriented... cioè io
programmatore che lavoro in standar MVC2 cosa devo cambiare del mio
tipo di lavoro? cosa devo leggere per apprendere queste tecniche di
lavoro?

Ciao Marco, spero di essere ancora in tempo per darti qualche risposta :-),
purtroppo di questo tempo il lavoro urge assai e visto il casino in cui sono
cercherò anche di dartele sensate... ma non ci giurare :-D!


>...quali sono gli input che devono arrivare ad un team per
>lavorare secondo le regole XP?
>
Secondo me innanzitutto deve esserne convinto il management: skillare e
creare un team XP richiede parecchi soldi, sforzi, e tempo, che non tutti
possono mettere a budget.
Se hai soldi, secondo me la cosa migliore è affidarti ad un mentor (come ad
esempio Francesco), altrimenti a qualcuno che comunque abbia già praticato
XP (come molti dei membri di questa comunità, me compreso) in modo che possa
guidarti nell'adattare il metodo per le esigenze del tuo business.

>...quali sono le regole per le quali un team XP si
>dice xp oriented?
>
Eh? Diciamo "si dice un team XP" e basta. Un team XP di solito mette in atto
le pratiche XP :-), ovvero usa il metodo XP opportunamente adattato nella
sua realtà.


>...cosa devo leggere per apprendere queste tecniche di lavoro?
>
Documentarti, innanzitutto! Leggi il bel libro di Kent Beck. "eXtreme
Programming", in pratica un manifesto di che cos'è XP. Quindi se riesci
partecipa a qualche seminario o incontro, vai su extremeprogramming.it nella
sezione eventi: fra poco c'e' XP2003 ma se ti accontenti o se non hai soldi
a Padova io tengo un mini seminario (gratis!)
Poi passa agli altri libri della serie, ma comunque ricordati che alla fine
ne avrai solo "un'idea": comunque la cosa migliore secondo me è appoggiarti
(insieme al tuo team) a qualcuno.


>... io programmatore che lavoro in standar MVC2
>
Ehm... che vor di? Forse model 2 di Sun?


Ciao,

     Bruno.



| Bruno Bossola
| CSP SpA - www.cspnet.it
| Responsabile area Sistemi Distribuiti

----- Original Message -----
From: "Bruno Bossola" <bbossola@...>

> a Padova io tengo un mini seminario (gratis!)

dove dove dove?

> >...quali sono le regole per le quali un team XP si
> >dice xp oriented?
> >
> Eh? Diciamo "si dice un team XP" e basta. Un team XP di solito mette in atto
> le pratiche XP :-), ovvero usa il metodo XP opportunamente adattato nella
> sua realtà.

Non per fare il pedante (ma forse un po' lo sono, chissà), ma un team XP
condivide innanzitutto un
insieme di valori sui quali fonda le pratiche che compongono il processo.
Diciamo che le pratiche
costituiscono l'aspetto esteriore di una costruzione che ha nei valori le
proprie fondamenta e senza i
quali è inesorabilmente destinata a sgretolarsi di fronte alle prime difficoltà.
Questa differenza
fondamentale rispetto al software engineering classico è da un lato uno dei
pregi di XP e dall'altro
uno degli aspetti più controversi.

Ciao, Giuliano