Newsgroup: it.lavoro.informatica
Titolo: Cosa si intende per Extreme Programming?

CDT.
MI fate qualche esempio che mi faccia capire'?
Mi sa molto di roba seria seria... :)
-- 
WWW.AKUMA.SPLINDER.COM
งง-Blog, funny, fashion-งง


così, in due righe mi pare un pò difficile.un pò di link :-)
http://en.wikipedia.org/wiki/Extreme_programming
http://spaces.msn.com/bozzellialfonso/
http://www.extremeprogramming.org/
http://www.agilexp.org/
saluti
LostMyE 

 
http://www.agilexp.org/
Aggiungo anche:
www.italianagilemovement.it
www.agileday.it
-- 
Lawrence - 
http://www.oluyede.org/blog
"Anyone can freely use whatever he wants but the light at the end
of the tunnel for most of his problems is Python"

MI fate qualche esempio che mi faccia capire'?
devi programmare vestito con un completino fatto in latex.

 Mi sa molto di roba seria seria... :)
Un'esempio non è proprio facile. Io la uso da qualche anno e mi trovo
bene, tutto il resto lo trovi su: 
http://www.extremeprogramming.org/
  ngw

 MI fate qualche esempio che mi faccia capire'?
Non è esattamente un qualcosa che si possa capire per esempi.
Si tratta di un approccio al processo di sviluppo del software che
(detto in soldoni) si pone in ogni fase obiettivi più concreti e adatti
al mondo reale rispetto all'approccio tradizionale. Coinvolgimento del
committente, rilasci frequenti, test metodizzati e così via.
Un occhiata ai rules ti dovrebbe schiarire le idee:
http://www.extremeprogramming.org/rules.html


"serio" e' proprio il contrario dell'extreme programmming.
Per capirlo bene dovresti leggere il libro di kent beck, ma in soldoni
l'idea e' di un approccio "light" alla programmazione. Spiegando un po'
meglio,
piu' importanza al codice e meno alal documentazione formale, il
principio di utilizzare
"la cosa piu' semplice che funziona" , invece di complicarsi la vita
con design
ultracomplessi senza avere la certezza che servano in questo momento,
l'utilizzo del test driven development, cioe' sviluppare prima i test
che le nostre classi
devono superare e poi le classi stesse, la programmazione in coppia , e
l'utilizzo di di piccole
iterazioni nel processo di sviluppo.  Molte di tutto cio' e solo "buon
senso spinto" ,  e alcune
sembrano assurde all inizio (come il pair programming) ma quando le
provi, ti rendi conto
che sono molto "serie" ma nel modo giusto.

 bene, tutto il resto lo trovi su: 
http://www.extremeprogramming.org/
Da quel - poco - che ho capito io, non è assolutamente un vestito che va 
bene per tutte le stagioni, ma è un approccio - passatemi il termine - 
sociale a problemi complessi. Molto interessante per uno sviluppo 
sostenuto e che si evolve nel tempo, non applicabile in realtà in cui 
dopo il rilascio le modifiche devono essere nel minor numero possibile.
Pero' mi piacerebbe discuterne - e, visto che ci siamo, farlo in un 
newsgroup differente da questo, visto che siamo OT.
-- 
Ciao!
Luca

 committente, rilasci frequenti, test metodizzati e così via.
Ripeto, non si adatta a qualsiasi realtà, IMHO. Pero' ha l'innegabile 
vantaggio che il committente finalmente si rende conto di cosa significa 
lo sviluppo di un'applicazione.
-- 
Ciao!
Luca

 newsgroup differente da questo, visto che siamo OT.
Non direi molto OT.
-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4
Blog: 
http://vvolonghi.blogspot.com
New Pet: 
http://www.stiq.it

 ha scritto nel messaggio 
news:qgfFf.77745$eD5.1...@twister2.libero.it...


 gusto del cavolo. 
Mi sono spiegato io. Desculpe.
Io mi trovo a contatto con una realtà - ammetto, insolita - nella quale 
il collaudo è di un impianto intero, software compreso; nel momento in 
cui l'impianto è in funzione, non è possibile metterci le mani se non 
per questioni eccezionali (che peraltro comportano la ri-certificazione 
dell'intero impianto).
Questo è ciò che intendevo.
-- 
Ciao!
Luca

 Questo è ciò che intendevo.
Si ma ancora non mi e` chiaro. Il TDD non e` mica solo testing del
sistema. E` anche unit testing e tanti altri testing. Non ti serve il
sistema in funzione per vedere che riesci a estrarre le informazioni che
ti servono da finti sensori. Neanche per testare che il protocollo di
comunicazione che usi sia ben formato e ben interpretato per qualsiasi
input, anche i piu` strani.
Se quando sistemi l'impianto fai partire i test e ti rendi conto che
tutti funzionano, quando qualcosa va male sei piu` tranquillo
sull'origine delle cause, perche` quantomeno non e` imputabile a
sottosistemi che hai testato. Ovviamente puoi testare male o in modo non
completo, ma questo e` ancor piu` vero quando i test mancano del tutto.
Il vantaggio di poter cambiare le carte in tavola velocemente ce l'hai
durante lo sviluppo, dopo lo sviluppo ottieni solo che puoi modificare
parti del software restando ragionevolmente certo che non hai spaccato
il resto.


 vuoi fare il ricercatore allora ok...
Vai con le cazzate :D


 ha scritto nel messaggio 
news:873bixz...@voodoo.myself...


 lo sviluppo di un'applicazione.
L'innegabile vantaggio è che la programmazione risponde velocemente al
committente e con software funzionante.

 vuoi fare il ricercatore allora ok...
Ma che scemenza...

 ha scritto nel messaggio 
news:ds5082$uds$2...@area.cu.mi.it...


 quello che pensi?? Siamo messi male ragazzi....
Guarda che sei tu ad aver dato una risposta senza motivazione. Io mi
sono limitato a sottolineare la scemenza, tanto è dovuto.
Se ti interessano le motivazioni su quello che penso, leggiti pure le
altre risposte che ho dato sull'argomento.

 quello che pensi?? Siamo messi male ragazzi....
Sei tu che non hai dato motivazioni Marco.


 poi ne parliamo, ok?
Ti invito a fare lo stesso, perche` non hai fatto altro che dire che l'XP e`
una cazzata senza portare motivazioni pratiche.


 completo, ma questo e` ancor piu` vero quando i test mancano del tutto.
In generale, come tutti sanno, non esiste la possibilita' di un testing 
"completo". 

 "completo". 
Ci mancherebbe. E i software non sono neanche mai esenti da bachi. Non
per questo nessuno li compra.


 "completo". 
Ma può (deve) essere esaustivo.

 "completo". 
Vero, ma il TDD ti aiuta ad arrivare al 100%, meglio 90 che 0.


Lascia perdere..... non ti servira' mai a nulla nel mondo del lavoro.
Guarda che XP e' nato dal mondo del lavoro e si usa nel mondo del
lavoro, in determinate realta'.
Non ha senso per alcune, ha senso per altre.
Che tu non lo usi mica significa che non ha senso e che nessuno lo
usa.
Non sei il mondo, nemmeno una regione e nemmeno un punto di
riferimento.
-- 
Legge di Flon
Non c'e' linguaggio in cui sia difficile scrivere cattivi programmi.
FAQ del gruppo : 
http://www.sen.it/faq/it.lavoro.informatica.faq.html

 ha scritto nel messaggio 
news:949cu11mmlmk856nf...@4ax.com...


 esperienza nel settore, tutto qui. Non pretendo certo che lei sia d'accordo.
Certo ma come continuo a dire ci si aspetta che il tuo parere venga avvallato
da qualcosa di pratico, anche personale. Altrimenti perche` dovremmo crederti?


esperienza nel settore, tutto qui. Non pretendo certo che lei sia d'accordo.
Ah pure del lei ? :-)
Visto che ti piacciono le formalita' e visto che sei un pluriennale
professionista, che diresti di imparare a quotare ?
Lo sanno fare i bambini, non vedo perche' un pluriennale
professionista laureato non debba esserne capace.
Stammi bene


da qualcosa di pratico, anche personale. Altrimenti perche` dovremmo crederti?
Ma perche' e' un pluriennale professionista laureato, ecco perche' :-)
Che domande.
L'informatica l'ha inventata lui che credi ? :-)
Oh dici che sono troppo minaccioso ?
Quasi quasi gli disegno una vignetta :-)


 "completo". 
Pero' esiste una metodologia con profonde radici nella storia per 
approcciare il testing. Certo, l'approccio per singolo mattoncino (mi 
perdoneranno i puristi) è un'idea che è corretta e che in qualche modo 
spiazza quanto precedentemente teorizzato. Io trovo però che presupponga 
una fase di progettazione accurata (anche del test?) sia per quanto 
riguarda il singolo mattoncino sia per quanto riguarda la costruzione 
generale.
Pero' sto parlando senza cognizione e solo per esperienza. Mi ritiro nel 
silenzio finché non mi sarò fatto un'idea più basata su studio che su 
chiacchiere.
-- 
Ciao!
Luca

 
Beh, io nella mia vita non ho mai rilasciato un software che non fosse 
testato almeno a livello di decenza (anche prendendomi male parole, 
talvolta). Ammetto che invece ho visto fare rilasci quanto meno avventati.
Certo, ho un paio di casi che dimostrano come gli utenti siano in grado 
di trovare anche quelli più impensabili con grandissima rapidità!! :-D
-- 
Ciao!
Luca

 
Scusami, Lawrence, č una sua opinione, valida tanto quanto la tua. Mi 
piacerebbe che entrambi argomentaste di piů, ma capisco che forse chiedo 
troppo... ;)
-- 
Ciao!
Luca

 vuoi fare il ricercatore allora ok...
E due. Marco, senti, a me le verità di fede non sono mai piaciute, in un 
senso e nell'altro. Se hai delle convinzioni tue, forse aiuterebbe 
sapere quali sono. Ma negare senza motivare la negazione è assolutamente 
inutile.
-- 
Ciao!
Luca

 lavoro, in determinate realta'.
AAAAAHHH!!!!
Ma non stiamo parlando di Windows XP!!! :DDDDDDDDDDD
-- 
Ciao!
Luca

 Che toni minacciosi!
Santa pace, distribuiscono code di paglia, oggi!!
Mi dici dove Stefano è stato minaccioso? Perché io l'italiano lo conosco 
discretamente, e non ho visto 'sta minaccia.
-- 
Ciao!
Luca

 generale.
Non ti seguo, a che serve l'XP se devi progettare sulla carta il test e tutto
il programma? La progettazione del programma ok, ma si parla di funzionalita`
macroscopiche, l'XP ti aiuta a non perderti quando approcci quelle
microscopiche.


 quali sono. Ma negare senza motivare la negazione è assolutamente inutile.
E` un troll, non ci sono altre spiegazioni cosi in superficie. Lascia perdere.x


 trovare anche quelli più impensabili con grandissima rapidità!! :-D
?


 troppo... ;)
Certo ma e` lui che in primis deve argomentare. Se io vengo da te (poniamo che
tu sia un Javista) e ti dico "Java e` la piu` grande porcata del secolo", sono
io che devo dirti perche` no? Oppure sei tu che mi snoccioli i suoi successi
commerciali?


discretamente, e non ho visto 'sta minaccia.
Non c'e' nulla come la verita' a minacciare e scaldare gli animi :-)


AAAAAHHH!!!!
Stessa reazione mia le prime volte che vedevo la sigla XP :-)
Vero che potremmo parlare di Extreme programming anche riferito al
mondo Windows ... se non e' programmazione estrema quella, nel senso
negativo ovviamente, da NON imitare ... ;-)


 microscopiche.
Occhio, anch'io parlo di unità macroscopiche. Ed è ovvio che quando 
scrivi qualcosa devi a mio avviso a) avere un'idea di massima di dove 
andrà a finire e b) avere un'idea di massima dei test che vorrai 
condurre. Ma credo che stiamo dicendo la stessa cosa.
-- 
Ciao!
Luca

 esperienza nel settore, tutto qui. Non pretendo certo che lei sia d'accordo.
Vista la sua pluriennale esperienza perche` non la mette a frutto
dandoci un taglio col top posting? Neanche nel giurassico insegnavano a
fare top posting e persino i novellini con le mani ancora sporche di
cioccolato sanno che non si fa top posting. Un po` di professionalita` e
che diamine.


 ''The burden of proof is always on the person asserting something. 
Scusa, se invece di citare un dotto articolo in inglese, dicevi che 
l'onere della prova è all'accusa, che oltre tutto è uno dei pilastri del 
  nostro diritto, non facevi prima?
-- 
Ciao!
Luca

 MI fate qualche esempio che mi faccia capire'?
premessa: vorrei evitare guerre di religioni che in quanto tali
presuppongono il NON voler prendere in considerazione soluzioni diverse
per contesti diversi.
Come gia' altri hanno detto non e' possibile in due parole spiegare nel
dettagli cosa sia XP (per cui e' sicuramente meglio fare riferimento ai
numerosi link che ti sono stati segnalati) quindi cerco di essere generico.
eXtreme Programming e' un cosiddetto Metodo Agile (preferisco metodo o
meglio ancora approccio piuttosto che metodologia). I Metodi Agili sono
una famiglia di approcci alla gestione del ciclo di vita del software
alternativi a quelli tradizionali ed XP e' il + famoso, anche per via del
nome ;-)
E' sicuramente vero che si tratta in buona sostanza di pratiche gia'
conosciute in alcuni casi da decenni messe insieme, probabilmente la
novita' sta' proprio nel come sono messe insieme e nei principi e valori
di fondo. Ad esempio l'idea di unit testing e' stata "portata alla massa"
dal libro Code Complete di Steve McConnell la cui prima edizione risale al
1993 pero' in XP il Test Driven Development - pratica per cui scrivi prima
un test "eseguibile" che una volta lanciato fallisce e poi sviluppi la
funzionalita' relativa fino a quando il test non passa - in XP e' una
tecnica di design (la parola test porta spesso confusione, motivo per cui
stanno nascendo proposte alternative tipo Behaviour Driven Development:
http://jbehave.codehaus.org/
)
Tutti i Metodi Agili sono letteralmente emersi osservando sul campo come i
progetti di successo negli ultimi 20 anni sono stati eseguiti piuttosto
che nella maniera tipica in cui qualche accademico se ne esce con qualche
bella idea ordinata e formale che ha senso sulla carta ma poco riscontro
nella realta' ;-)
Se ti interessa approfondire di persona oltre a venire all'edizione 2006
dell'Italian Agile Day (no, non ho ancora idea di quando lo faremo) ti
consiglio di unirti ad uno degli XPUG Italiani che stanno partendo proprio
in questo periodo, maggiori info qui:
http://www.agilemovement.it/index.php?name=News&file=article&sid=761
Per domande specifiche sono a disposizione (sempre che non venga
considerato troppo OT dal NG).
Buona serata
Marco Abis
http://www.agilemovement.it
 - Italian Agile Movement
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 E` un troll, non ci sono altre spiegazioni cosi in superficie. Lascia
perdere.x
Sarebbe ora. Era abbastanza evidente anche. Peccato, l'argomento era
interessante...... 
p.s. il MSF (Microsoft Framework) a prima vista scopiazza un po' l'XP...


 negativo ovviamente, da NON imitare ... ;-)
Te scherzi, ma MS ha usato SCRUM per SQLServer.
Sarà per quello che è più o meno l'unico che si salva ? :D
  ngw

 chiacchiere.
Infatti non č cosě :)
La scrittura dei test e del codice deve essere coordinata, e i test
spesso aiutano proprio nel cosidetto "refactoring", ovvero utilizzando
realmente il codice che hai scritto nei test riesci a riflettere
sull'implementazione, e tramite piccoli aggiustamente arrivi al prodotto
finito.
I test non richiedono progettazione, spesso sono piccole operazioni.
  ngw

 troppo... ;)
Come giustamente ha detto Marco Abis in un altro post, XP, come la maggior parte
delle altre metodologie agili, e' nata sintetizzando le pratiche, i principi e i
valori dei team che hanno prodotto codice di qualita'
In pratica e' stato un processo evolutivo, e lo e' ancora oggi, sia all'interno
della comunita' degli exteme programmer[*], sia all'interno dei singoli team
Infatti il focus non e' incentrato sull'applicazione della metodologia[**], ma
sul miglioramento costante, miglioramento in senso lato:
- tecnico = codice migliore
- umano = ambiente lavorativo migliore
- economico = il prodotto deve raggiungere i propri obiettivi di business [***]
Tutto questo per dire che e' abbastanza improbabile vedere XP come prodotto di
un studio accademico, che al limite potrebbe essere retrospettivo, e anche in
questo caso ci si va con i piedi di piombo, in quanto si tirano in ballo sistemi
evolutivi, sistemi complessi, fattori umani, sociali, relazionali, teoria del
caos, sistemi autoorganizzati, ecc... tutte cose difficilmente formalizzabili
E poi, essendo sostanzialmente un processo "rozzo" di natura empirica, diciamo
che attrae poco la natura "pulita" degli studi accademici
Quindi dire che al limite ci si puo' trovare coinvolti in XP solo in ambienti
accademici, denota ignoranza della materia
Sono disponibile via mail per eventuali approfondimenti, oppure se volete fare
due chiacchiere sulla materia e siete di Milano, vi aspetto ai meeting del XP
user group 
http://milano-xpug.pbwiki.com/
[*] Il manifesto di XP "Extreme Programming Explained" di Kent Beck esiste in
due edizioni, la seconda e' stata ampiamente riveduta alla luce dell'esperienza
accumulata in cinque anni dopo la pubblicazione del primo volume, al punto che
molti lo considerano un altro libro
[**] L'applicazione "cieca" di XP viene chiamata "foto XP" (vedi intervento di
Francesco Cirillo all'ultimo 
www.agileday.it
) e viene vista come una cosa
negativa
[***] L'obiettivo non e' implementare delle specifiche, ma e' raggiungere gli
obiettivi per i quali le metodologie classiche scrivono le specifiche. Durante
lo sviluppo viene continuamente (anche ogni settimana) rilasciato del codice
funzionante che viene costantemente messo alla prova per verificare se
effettivamente la sua addozione possa raggingere gli obiettivi prefissi, se
cosi' non fosse, si valutano costantemente delle alternative. Un progetto non
viene "mai" considerato finito finche' viene utilizzato da qualcuno
-- 
SunGray aka Gabriele Lana
www.agilemovement.it

Contesto.
Dei dettami proposti dalla XP programming ne abbiamo adottati alcuni in
un progetto in cui avevamo i tempi ristrettissimi (1 mese e mezzo).
Abbiamo chiuso il progetto nei tempi, testato e funzionante in
produzione, con codice leggibile e manutenibile.
Quello che abbiamo applicato :
- Unit Testing
- Refactoring
- Pair Programming
Ci è mancata la forza di ... non fare straordinari, la mezzoretta la
sera ci sfuggiva di mano :-(( ed inoltre gli 'Stand Up meeting' sono
stati sostituiti da mini-riunioni da 5-10 minuti giornalieri su temi
molto mirati.
Stefano Grevi

peccato che la maggior parte delle software americane ora usa questo
sistema.

peccato che la maggior parte delle software house americane ora usa
questo sistema.

 Mi sa molto di roba seria seria... :)
il mio ex project-manager era ciecamente convinto che il suo
significato fosse qualche cosa del tipo "quando il cliente si sveglia
con una modifica, non importa quanto sia assurda, quanto sia incoerente
con le specifiche accordate o quanto sia impossibile da realizare ma tu
devi fargliela immediatamente".
quando poi qualcuno si lamentava perche' quel weekend o quella sera
alle 21.30 aveva altri impegni e non poteva essere al lavoro, lui ti
guardava scandalizzato e ti diceva "lo sapevi che facevamo extreme
progeamming, potevi evitare di farti assumere!"

 devi fargliela immediatamente".
non sono d'accordo. la mia azienda è americana e usa questo sistema da
tempo e dio solo sa quanto è difficile far passare una modifica
all'engineering. spesso è difficile anche con i bug, non perchè non
ci sia sensibilità nella qualità (anzi) ma perchè si segue la logica
che non tutto deve funzionare. se una feature non è sfruttata, non ha
senso perderci del tempo.
riguardo alle modifiche queste richiedono tempo e denaro. non sempre XP
è applicata a progetti in cui c'è un committente. si applica anche a
prodotti diffusi su larga scala, orizzontali dove le richieste di
miglioramento sono varie. bene, devono prendere in considerazione vari
fattori, tra cui appunto l'effettivo interesse della feature da parte
di tutti
i clienti che usano il prodotto.

 progeamming, potevi evitare di farti assumere!"
Tentativo maldestro di far passare dei cattivi comportamenti sotto una bandiera
"buona" come quella di XP che ha fra i suoi principi quello di
preservare/migliorare la qualita' della vita del team
Ho definito maldestro il project-manager di cui sopra proprio perche' quella
storiella non puo' essere raccontata a chi ha una minima conoscenza di XP. Cito
"Extreme Programming Explained 2/ed", la descrizione di "Energized Work" una
delle tredici pratiche primarie: "Work only as many hours as you can be
productive and only as may hours as you can sustain. Burning yourself [...]
isn't good for you or the team"
Non sto dicendo che XP sia la soluzione di tutti i mali, ma sicuramente e' un
metodo efficace per essere piu' produttivi rispettando se stessi, i propri
colleghi e i propri committenti


 Mi sa molto di roba seria seria... :)
No non c'e' da fare la battutina, e' roba seria davvero.
L'idea di base e' che il ciclo di vita del software tradizionale, sia quello
a cascata che quello a spirale e' troppo rigido. E questo e' innegabile.
1. Rallenta i progetti
2. Ingessa troppo i requisiti e quindi crea una discrepanza fra il prodotto
e la realta'
3. Va a finire che alla fine in quasi quasi tutti i progetti tradizionali
salta per aria il modello e quindi si finisce nell'improvvisazione.
L'XP dice: se e' vero il punto 3 , e quindi i progetti iperingegnerizzati
finiscono nel caos, facciamo l'oppsto, cioe' facciamo che la norma e' il
caos e' ingegnerizziamolo.
Come ? Direi che leggerti i link che ti hanno suggerito gli altri e' la
strada maestra.
In Italia posso citare un esempio su tutti dove hanno deciso di applicare in
modo sistematico XP : H3G
almeno all'inizio era rigorosa, poi hanno un po' ammorbidito soprattutto
perche gli costava una cifra avere la "Coppia" di programmatori
Oggi non so piu' bene perche' e' un annetto che non ho notizie fresce dal
fronte H3G ( c'e' un via via laggiu' , perche' tutti bvogliono passarci per
mettterla a curriculum pero' dopo 6 mesi scappano :)
Io sono molto a favore pero' va tutto preso con le pinze e adattato caso per
caso.
1. Se si applica la XP e' fondamentale che il PM, Architect, Capo progetto,
o come lo vuoi chiamare comunque conosca perfettamente il modello a cascata
e quello a spirale.
2. Secondo me la XP funziona solo se hai dei developer iene, cioe' degli
Architect/Developer che di fatto tengono ingegnereizzato il tutto per loro
natura. Se lo applichi nelle aziende carrozzone con i junior a coco e' un
suicidio. In quel caso un modello iper rigido con gli use case tradizionali
e pattern iper rigidi direi che e' d'obligo.
Della serie o fai cosi' o ti licenzio
3. La programmazione "a coppia" e' interessantissima. Bidogna capire
l'impatto sui costi.
-)Una coppia costa il doppio, e qua non ci piove.
-)Lavorando in 2 elimini tantissimi bug, forse la magior parte, e questo e'
un costo inquantificabile ma puo' essere enorme, soprattutto in progetti ad
alta criticita'.
-)In 2 hai un vantaggio enorme nella diffusione dell'analisi, e quindi se va
via uno il team ne risente poco o nulla
-)E' velocissimo l'inserimento di nuovo personale che apprendera' alla
velocita' della luce sia le tecnologie sia l'analisi del progetto
-) Bisogna vedere quanto i singoli sono disposti a lavorare in coppia,
soprattutto i piu' esperti sappiamo quanto sono gelosi della loro conoscenza
-) C'e' il fattore umano che non e' irrilevante. Se 2 diventano Sturky e
Hutch ( o come si scrive) diventano micidiali , se pero' diventano 2
divorziati in casa ho paura che esplodono come una bomba :)
Io sono per un mix fra tradizionale e xp insomma
ciauz Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 legate dietro la schiena e a testa in giù, potevi evitare di farmi assumere!"
Guarda se la frase del tuo ex project-manager va bene. A me sembra più
consona :-))
SG

 divorziati in casa ho paura che esplodono come una bomba :)
Argomento delicato. In questo caso è compito del Team Leader rivedere
chi lavora con chi e far capire ai più esperti che non è col segreto
di Pulcinella che avranno dei vantaggi.
Alla fine del progetto mi sono guardato intorno ed ho scoperto di
essermi divertito, anche se abbiamo lavorato come iene.
Stefano Grevi

 - Pair programming : una persona skillata con 
ASP.NET
 e C# che affianca
Ho letto tutto, e l'ho trovato interessante.
Mi fai perņ un piacere personale?  Puoi in futuro usare "preparata" o 
"competente" al posto di skillata? E' un termine che mi ha sempre fatto 
torcere le budella.
Grazie.
-- 
Ciao!
Luca

 testato almeno a livello di decenza 
Il TDD è un approccio diverso e porta il test direttamente nel ciclo di
sviluppo. In pratica lo unit test diventa le specifiche fatte codice e
il programma viene sviluppato dentro di esso. Seguendo questo metodo lo
unit test rispecchia sempre le specifiche anche quando queste variano di
frequente.
La documentazione è tanto bella, ma lo sforzo di tenerla aggiornata è
tanto immane quanto inutile. Invecchia in ore.

 tanto immane quanto inutile. Invecchia in ore.
Oltre tutto, e parlo per esperienza, è uno sforzo (si, a me non piace 
fare documentazione) assolutamente inutile, visto che poi nessuno la legge.
-- 
Ciao!
Luca

 SG

Mi spiace ! Mi è sfuggito ! Di solito sono rigoroso, ma stavolta mi
sono fatto tradire dalle parole ricorrenti.
SG

 Mi sa molto di roba seria seria... :)
Della serie "XP non serve a un cazzo":
"Videogame development e Extreme Programming"
http://blogs.ugidotnet.org/PuntoRete/archive/2006/02/07/34411.aspx
-- 
Lawrence - 
http://www.oluyede.org/blog
"Anyone can freely use whatever he wants but the light at the end
of the tunnel for most of his problems is Python"