[vari]Reinventare la ruota

[tomminno]

Originariamente inviato da ^TiGeRShArK^

La documentazione è nel codice e negli unit-test.

Quindi se qualcuno volesse documentarsi su qualcosa invece che consultare una comoda interfaccia web dovrebbe scaricarsi il software da svn aprire l'editor di turno e cominciare a spulciare il codice per capire cosa fa e come lo fa?

[gugoXX]

Originariamente inviato da tomminno

Quindi se qualcuno volesse documentarsi su qualcosa invece che consultare una comoda interfaccia web dovrebbe scaricarsi il software da svn aprire l'editor di turno e cominciare a spulciare il codice per capire cosa fa e come lo fa?

Ci sono anche le storie. Esse contengono la vera documentazione di progetto.
Ogni volta che si rilascia un pezzo di codice nel repository centrale, questo rilascio e' sempre legato ad una storia in particolare. In questo modo si ha a posteriori il legame sul perche' e' stato introdotta o modificata la singola linea di codice.
Ci sono plug-in dei tool di versioning che permettono di posizionarsi su un gruppo di linee di codice, e vengono esposte in ordine cronologico tutte le storie che hanno avuto a che fare con tale gruppo, ciascuna esponendo come era il codice in quel momento. Sono plug-in di brdige tra il prodotto di versioning e il prodotto che serve per gestire il sistema agile, quello dove vengono pubblicate le storie, dove si possono aggiungere commenti, i test, assegnare i lavori, stimare le difficolta' per ciascuna storia, etc.

Comunque per capire il cosa e il perche' un pezzo di codice sta facendo qualcosa, ci sono i commenti che sono proprio finalizzati a questo.
Anche lo stile di commentazione del codice e' una parte ben definita e importante nello sviluppo Agile. Niente di trascendentale, solo il formalizzare concetti comunque altrimenti ragionevoli, che sarebbero da applicare ovunque.
Innanzitutto bisogna commentare sempre.
Quindi a chi non piace commentare, e sul forum si vedono sovente esempi, direi che questa metodologia non e' da proporre.
Il commento e' una forma di rispetto verso di se e verso gli altri. Chi non commenta e' bene che sia tanto bravo da poter lavorare da solo.

E laddove si commenta occorre spiegare proprio cosa e perche' si sta facendo un qualcosa, e non il come.
Bannati commenti come "Sposto il valore di ciccio nella variabile Pluto", perche' e' il codice stesso che dice come si stanno facendo le cose.
Meglio p.es.
"Salvo ciccio perche' verra' distrutto dalla chiamata a metodo caio"

Non "Ordino il risultato", ma "Ordino il risultato perche'..."

[gugoXX]

Originariamente inviato da tomminno

Beh intanto è venuto fuori che in 2 settimane non si può pubblicare perchè non c'è l'intervento dei grafici. Che non consideri i grafici parte integrante del gruppo di lavoro.
Io consegno ogni 4/6 settimane un prodotto finito con tanto di grafica e traduzioni e tutto concordato con il cliente durante lo sviluppo.
Sono le tempistiche molto ristrette che non riesco a comprendere.

Come si diceva, il primo rilascio e' ad 1 mese. I successivi ogni 2 settimane.
E comunque si'. All'inizio si rilascia in produzione un set di funzionalita' minime, e da li' si comincia poi ad arricchire.
Che poi il cliente decida veramente di esporre/sostituire un prodotto vecchio con questo on-going e' un altro discorso. Per il team di sviluppo quella e' la produzione, ed e' la produzione sulle macchine vere (hardware permettendo). Quelle per le quali basterebbe solo un solo click del cliente per decidere di esprre il prodotto all'esterno oppure no.
Per un sito di ricerca come google potrebbe essere solo una brutta textbox al centro, senza immagini, con il solo tasto "Search" e senza funzionalita' particolari se non una ricerca magari inefficiente sul database locale che non viene neppure rinfrescato con lo spidering.

I discorsi su bachi di fatturazione/carrello di cui parlavi sono assorbiti dal tempo di QA (Quality assurance)
Un altro dei concetti dell'Agile e' che DEVE esserci un team (magari anche una persona sola) dedita alla QA.
Quando il team di sviluppo rilascia una candidate release, viene rilasciata nell'ambiente QA, in certificazione. QA ha tempo 2 settimane per testare le nuove funzionalita' aggiunte, e per completare i test con le regressioni sulle parti non copribili dai test degli sviluppatori. Al termine delle 2 settimane la candidate release, eventualmente nel frattempo aggiustata, viene rilasciata in produzione.
In pratica capita che allo stesso istante gli sviluppatori rilasciano verso QA quello che e' lo Sprint 75 (uno sprint equivale alle 2 settimane di lavoro), e QA rilascia in produzione quello che e' lo sprint 74.
Per progetti piu' complessi tra QA e produzione c'e' un ulteriore ambiente di UAT (User acceptance test) In questo ambiente i test sono i test di accettazione utente, durante i quali l'utente stesso certifica che quanto e' stato aggiunto corrisponde alle storie che erano state decise per lo sprint in particolare.

[Mixmar]

Mi iscrivo a questa discussione perchè è una figata

Una curiosità per gugoXX: ma editi sempre i tuoi post dopo averli fatti? Ho dato un'occhiata, e hanno tutti una data di "post-modifica"... non è che oramai sei Agile anche nello sviluppo dei post?

E' solo una battuta, però mi piace pensare a te che architetti test per provare i tuoi post e poi fare il refactoring se non ti piacciono...

Non prenderla come un'offesa, eh!

[jappilas]

Originariamente inviato da gugoXX

Ci sono anche le storie. Esse contengono la vera documentazione di progetto.

ma (da quel che ricordo di diamonds) soprattutto i test

Innanzitutto bisogna commentare sempre.

va anche detto che se il codice è autoesplicativo ("il codice va letto come se fosse inglese" - fek) algoritmicamente semplice (quindi tale da non porre dubbi sul motivo per cui si sia raggiunto un certo risultato attraverso "quella" sequenza di operazioni) e facilmente padroneggiabile (metodi compatti, ridotta complessità ciclomatica, ecc) non si pone la necessità di commenti nel codice

E laddove si commenta occorre spiegare proprio cosa e perche' si sta facendo un qualcosa, e non il come.
Bannati commenti come "Sposto il valore di ciccio nella variabile Pluto", perche' e' il codice stesso che dice come si stanno facendo le cose.
Meglio p.es.
"Salvo ciccio perche' verra' distrutto dalla chiamata a metodo caio"

Non "Ordino il risultato", ma "Ordino il risultato perche'..."

pienamente d' accordo qui

[gugoXX]

Originariamente inviato da Mixmar

Mi iscrivo a questa discussione perchè è una figata

Una curiosità per gugoXX: ma editi sempre i tuoi post dopo averli fatti? Ho dato un'occhiata, e hanno tutti una data di "post-modifica"... non è che oramai sei Agile anche nello sviluppo dei post?

E' solo una battuta, però mi piace pensare a te che architetti test per provare i tuoi post e poi fare il refactoring se non ti piacciono...

Non prenderla come un'offesa, eh!

No figurati. E che spesso scrivo veloce, poi pubblico per non perdere il post (gia' capitato che si perdesse tra un tasto sbagliato e un altro), e poi correggo solitamente gli errori di ortografia.

[Johnn]

Penso che "Tommino vs Resto del mondo XP" sia dovuto ai diversi ambiti di lavoro dove probabilmente il processo di sviluppo di uno non può essere applicato nell'altro. La discussione mi pare erroneamente incentrata sull'efficacia o meno della programmazione estrema in assoluto, dando scarso peso al contesto.

Qui:

http://books.google.it/books?id=h-hC...age&q=&f=false

c'è l'anteprima completa del capitolo riguardante i metodi agili di sviluppo e la programmazione estrema del libro Ingegneria del Software di Ian Sommerville (sento fischi dagli spalti... ). Mi pare molto interessante la fine della pagina 385 e l'inizio della 386 che in estrema sintesi dice (niente copia/incolla ):
"Negli anni 80-90 gli ingegneri del software ritenevano che per sviluppare sofware di qualità fossero necessari metodi rigorosi di pianificazione, analisi, progettazione.
Le persone che sostenevano ciò lavoravano per progetti di grandi dimensioni, di lunga durata, spesso composti da sistemi critici. Inoltre diversi gruppi di lavoro lontani nello spazio e nel tempo producevano il software.
Quando si applicò questo approccio nelle aziende medio-piccole emerse che la lunga fase si raccolta di requisiti formali e progettazione era preponderante rispetto allo sviluppo stesso.
Si pensò quindi ad un approccio agile, dove era centrale lo sviluppo ed il test del software piuttosto che la pianificazione e la documentazione; si deve procedere quindi in maniera ciclica per il rilascio di sottoparti di sistemi con requisiti fortemente dinamici."

Tra i vari pregi e difetti di tale approccio riporto testualmente (fine pagina 387):

... i metodi agili sono adatti solo ad alcuni tipi di sviluppo di sistemi: sviluppo di sistemi aziendali di dimensioni medio-picocle e dei prodotti per PC. Non sono molto adatti allo sviluppo di sistemi su vasta scala con team di sviluppatori in posti diversi [questo non mi pare confermato, almeno in parte, dalle vostre esperienze] e interazioni compesse con altri sistemi hardware o software [questo invece mi pare confermato]. I metodi agili non dovrebbero essere usati per lo sviluppo di sistemi critici dove è necessaria un'analisi dettagliata di tutti i requisiti di sistema per comprendere le loro implicazioni di sicurezza e protezione.

[Johnn]

Originariamente inviato da tomminno

Quindi se qualcuno volesse documentarsi su qualcosa invece che consultare una comoda interfaccia web dovrebbe scaricarsi il software da svn aprire l'editor di turno e cominciare a spulciare il codice per capire cosa fa e come lo fa?

Per questa cosa secondo me sarebbe meglio farsi guidare dall'obiettivo che non dal metodo utlizzato:
a chi serve la documentazione? O ancor più in generale, cosa voglio comunicare, a che livello di astrazione, a chi?

Se per esempio è necessario riassumere la logica di funzionamento di una certa parte del software, ad un livello di astrazione superiore al codice, rivolto a chi dovrà manutenere/modificare quella parte in futuro, si potrebbe pensare di scrivere una breve descrizione in linguaggio naturale supportato da diagramma di flusso, senza quindi costringere l'utente di quella documentazione a leggersi le storie o i sorgenti.

[^TiGeRShArK^]

Originariamente inviato da tomminno

Veramente non hai capito: il materiale viene rilasciato via via che viene sviluppato solo su un ambiente che non è produzione. E si va avanti chiedendo l'approvazione del cliente. Solo che il cliente dopo un pò di tempo si rimangia l'approvazione. Mai capitato?

Su un ambiente che non è di produzione posso pure permettermi di salvare un ordine in modo errato tanto devo solo mostrare all'utente qualcosa. In un ambiente di produzione questo non sarebbe possibile.



Il che sarebbe da chiedersi con quante risorse.
Un mio progetto tipo coinvolge tipicamente la creazione di un sito web e di tutto il backend fino alla fatturazione e può funzionare solo se c'è tutta la catena.
Come fai a creare un sito web con la grafica in 2 settimane? Come fai sempre nelle 2 settimane a modificare anche la intranet? E sempre nelle 2 settimane come modifichi tutto il backend che ci sta dietro?
Sono progetti formalmente indipendenti ma la pubblicazione deve essere atomica. Dopotutto una intranet per la gestione di una parte non in produzione non può essere utilizzata, un sito web senza il backend farebbe infuriare gli utenti, un carrello d'ordine che contiene la metà delle cose non è accettabile dal cliente...




E te pensi di mettere in produzione un sito web per una multinazionale senza che siano intervenuti i grafici? Come fai a pensare di pubblicare un sito web a pezzi? E se anche fosse come farebbe l'utente ad usare la business logic di un sito web se non ha ancora l'interfaccia?

I grafici non sono dei programmatori, ma concorrono alla realizzare del prodotto e come tali devono essere presi in considerazione. Al cliente consegni un prodotto non del codice!



Quindi in 2 settimane non puoi pubblicare niente.



Scusa ma se è quello che accade nella realtà di tutti i giorni come fai a dire che non gliene deve fregare niente?



Certo nelle prime fasi valuta le funzionalità, poi quando ha visto anche la grafica decide che vanno modificate anche le funzionalità, che dopotutto si utilizzano tramite l'interfaccia grafica, se troppo macchinose per l'utente finale si tagliano o si modificano.



Se il singolo sistema si chiama database aziendale può eccome. Specialmente se il nuovo progetto richiede l'inserimento nel sistema di nuovi dati che tutti poi dovranno gestire.



Scusa ma se il sistema completo è tutta l'infrastruttura di un'azienda sviluppato caoticamente in 15 anni modulare non potrà essere. Ovvio che gli interventi o le nuove aggiunte debbano inserirsi nel contesto preesistente.



Lo sviluppo può anche essere indipendente, ma alla fine tutto deve essere pubblicato nello stesso momento.



Boh secondo me finchè si rimane sul tecnico è quello che avviene quotidianamente, già quando si passa agli aspetti legali il programmatore ne sa veramente poco. Se un task deve dipendere da leggi e/o contratti il programmatore difficilmente ne conscerà i dettagli. Ad esempio un programmatore potrebbe decidere in autonomia di creare un database di appoggio per il suo applicativo dove magari inserire gli ordini per elaborarli prima di passarli al sistema centrale. Ecco che hai appena esposto l'azienda a rischio di essere accusata di tenere una doppia contabilità, con tutte le conseguenze del caso (praticamente nessuna se in Italia). Il programmatore magari che ne sa?
Se un dato va conservato in maniera particolare perchè la legge lo impone sei certo che il programmatore ne sia a consocenza?



Più o meno è così anche da noi.



Scusa ma perchè il project manager non dovrebbe avere idea del sistema nel suo complesso?
E poi scusa i singoli programmatori avrebbero ognuno la visione d'insieme?
Le volte in cui capita che dei gruppi partano a sviluppare in autonomia finisce che ognuno ha fatto l'interfaccia che riteneva migliore per il proprio pezzo di codice e che ovviamente non consente la comunicazione tra i vari moduli per manifesta incompatibilità.



Bah non vedo la differenza, parli sempre di un coordinatore, chiamarlo project manager o scrum master che cambia?

E se il project manager deve stare dietro al cliente, ovviamente non potrà scrivere codice che è un'attività che richiede una dedizione a tempo pieno.



Le funzioni che hai elencato sono quelle del project manager. Puoi chiamarlo come ti pare ma la sostanza è quella.



Si infatti il reparto test serve appunto per i test di integrazione infattibili via codice.



Questa confidenza nel fatto che il cliente si accorga subito che qualcosa non va è preoccupante. Per la mia esperienza passa sempre del tempo, può essere 1 giorno come una settimana o anche di più, ma se viene fuori in un ambiente di staging durante la fase di sviluppo non c'è problema, se viene fuori in produzione sono dolori.



Eh oggi ero fuso... Troppa cioccolata



Benvenuto nel mio mondo. Solo che nel mio caso nel 95% dei casi è il cliente che non capisce niente di quello che vuole e del sistema con cui lavora, tanto che il più delle volte viene lui a fare domande sul suo sistema!
Ah e i documenti descrittivi li manda il cliente per far cominciare il progetto.



Ti ci voglio vedere a modificare una funzionalità dopo un mese dall'approvazione...



Nel mio caso i progetti vengono pubblicati ogni mese, mese e mezzo, i progetti più grandi sono suddivisi in fasi della stessa durata. Ma sono fondamentalmente le classiche milestones. In tempi inferiori non è possibile realizzare qualcosa che lasci il sistema in uno stato stabile.
La pubblicazione deve essere atomica, quello che puoi fare successivamente sono correzioni marginali aggiunta di funzionalità secondarie ecc...



Noi lavoriamo con gruppi di 3/4 persone su 3/4 progetti paralleli, ogni progetto viene pubblicato in 4/6 settimane.



Nemmeno noi, il nostro problema pricipale è la volubilità del cliente.
Il caso opposto è il cliente che arriva già con la checklist (tipico caso delle multinazionali), le fregature in quel caso sono da cercarsi nelle centinaia di pagine di requisiti scritte appositamente per far intervenire i legali e non pagare.



Scusa ma credi di essere il solo a fare così?



Beh intanto è venuto fuori che in 2 settimane non si può pubblicare perchè non c'è l'intervento dei grafici. Che non consideri i grafici parte integrante del gruppo di lavoro.
Io consegno ogni 4/6 settimane un prodotto finito con tanto di grafica e traduzioni e tutto concordato con il cliente durante lo sviluppo.
Sono le tempistiche molto ristrette che non riesco a comprendere.



No non riesco ad immaginare di applicare tali tecniche in un contesto ben preciso, che è quello in cui lavoro, pieno di vincoli legali e di clienti che non capiscono niente.

si, ok sei andato in loop ripetendo le cose che ho spiegato prima.
E anche riuscendo a confondere lo scrum master con la persona che si interfaccia con il cliente e con il project manager che sono tutti ruoli diversi.
A questo punto mi sa che non ci capiremo mai, ti posso solo dire che queste metodologie se correttamente applicate funzionano e alla grande anche.
Sei libero di non crederci.

[rеpne scasb]

■

[gugoXX]

Originariamente inviato da rеpne scasb

Ti ringrazio per l'esauriente spiegazione. Molto interessante. Volevo porti alcuni quesiti, se avrai tempo e pazienza di ripondermi:

1) Tale metologia agile mi ricorda i metodi e modelli matematici di predizione e correzione. E' corretta tale analogia?

Premettendo che non sono affatto esperto nella matematica che utilizza metodi di predizione e correzione (me li ricordo solo applicati ad alcuni tipi di equazioni differenziali usate in problemi come la meteorologia), direi che intuitivamente e' una direzione giusta.
Ovviamente la metodologia Agile serve per trovare la soluzione di un problema non ben determinato (la richiesta del cliente), le cui soluzioni potrebbero essere molteplici e tutte giuste, magari con diversi gradi di piacimento.
Campo quindi non cosi' rigoroso come i modelli di cui sopra.

2) Sono stati sviluppati dei modelli per la quantificazione di quantita' quali: tempo di sviluppo su algoritmo-costante, densita' di bugs per linee di codice o per tempo di sviluppo (anche solo l'andamento qualitativo di tali curve)?

3) Ci sono in letteratura, dati comparativi tra la metodologia di sviluppo agile, ed altre metodologie, anche su coppie di variabili non comprese nel punto 2)?

L'unico di cui mi ricordo bene il grafico comparativo con tempi presi tra 2 gruppi di sviluppo. Il grafico e' la comparazione tra soluzioni classiche e agile e mette in relazione il tempo necessario per aggiungere/modificare una funzionalita' a seconda della maturita' del progetto.
Sulle ordinate si trova il tempo necessario per aggiungere (o modificare) una funzionalita', sulle ascisse quanto tempo e' trascorso dall'inizio del progetto.

Nelle soluzioni classiche il grafico si approssima con una retta, poiche' si scopre che man mano che il tempo passa e' sempre piu' difficile aggiungere funzionalita'.
Nelle soluzioni agile invece si approssima con il logaritmo (Ovviamente facendolo passare per zero). Inizialmente aggiungere una funzionalita' ha un costo maggiore rispetto alle soluzioni classiche, dato che la fase di progettazione e' meno organica. Ma dopo un certo periodo le due curve si incrociano, e dopo il treshold risulta piu' semplice con metodi agile che con quelli classici. Il tempo per aggiungere le funzionalita' con metodi agile e' ovviamente crescente man mano che passa il tempo (Occorre inserire il pezzo nuovo pur mantenendo la soluzione organica), ma con meno sforzo. Questo grazie principalmente alla rifattorizzazione vs pezze.


Il tempo di sviluppo per algoritmo costante direi che e' minore con soluzioni classiche. Agile vince quando non si ha bene chiaro in mente all'inizio dove si andra' a finire, e dove si sa' che verranno chieste modifiche impreviste in corso d'opera.
Se le idee sono invece ben chiare dal principio consiglio un approccio classico con progettazione iniziale e sviluppo tutto insieme (Che e' poi cio' che si fa quando si affronta ogni singola storia anche nell'Agile. Le storie sono da considerarsi blocchi atomici non modificabili. Se e quando occorrono modifiche si creano altro storie)


Relativamente ai bug. Un bug in Agile equivale ad un test non scritto. Al termine di un progetto le linee di codice per i test superano quelle del codice stesso, e questo significa che c'e' sempre meno spazio per i bug.
Facendo lavorare gli strumenti appositi, mettendo insieme concetti come la copertura al codice locale e la complessita' ciclomatica vengono anche fuori classifiche su quali sono le parti di codice piu' sensibile, dove probabilmente possono essere nascosti bug, e dove quindi indirizzare l'attenzione.
Mentre durante lo sviluppo c'e' chi prefreisce scrivere prima il codice e poi gli unit test, come me (non c'e' una regola precisa), quando si trova un bug invece prima si scrivono i test di regressione, e poi si corregge il codice fino a che i test non passano tutti, sia quelli nuovi che quelli vecchi.



Butto qui altre comparative

Indici di progetti gestiti con metodi Agile, rispetto a metodologie tradizionali.




Questo e' invece basata sul numero di progetti portati a buon fine




Questo invece fa vedere il costo di un bug, a seconda del momento in cui viene scoperto. Agile cerca di far venire fuori i bug tra i momenti meno costosi, rispetto a metodi tradizionali


Documenti e libri annessi a questi dati: http://www.agilemodeling.com/essays/proof.htm

[fero86]

sbaglio a pensare che l'ultimo grafico sia una gran cavolata? non mi sembra il risultato di una statistica, mi sembra una curva disegnata appositamente per esporre un concetto opinabile in quanto molto variabile da un caso all'altro.

[gugoXX]

Originariamente inviato da fero86

sbaglio a pensare che l'ultimo grafico sia una gran cavolata? non mi sembra il risultato di una statistica, mi sembra una curva disegnata appositamente per esporre un concetto opinabile in quanto molto variabile da un caso all'altro.

Qualcosa in piu' su quel grafico

http://www.ambysoft.com/essays/whyAg...sFeedback.html

[fero86]

Originariamente inviato da gugoXX

Qualcosa in piu' su quel grafico

http://www.ambysoft.com/essays/whyAg...sFeedback.html

quella pagina sembra rispondere "esattamente." al mio post precedente, non mi sembra che vada a favore di quel grafico.

inoltre, sbaglio a pensare che le teorie esposte in quella pagina siano un sacco di castelli colorati campati per aria e privi di riscontro statistico? lo chiedo perché ho letto velocemente e senza andarmi a leggere pure le varie pagine linkate.

[^TiGeRShArK^]

boh...
non l'ho manco aperta quella pagina..
ma so solo che quelle teorie che secondo alcuni sarebbero "campate in aria" nella pratica funzionano perfettamente.
E questo mi fa venire in mente quello che mi ha detto la mia collega neozelandese,
autrice di un libro sull'agile programming e nuova assunta:

"WPF seems like magic: it's so simple that you are astonished when you see the result...
you don't know how it is possible but it works!"

(Pubblicità progresso )

[gugoXX]

Originariamente inviato da fero86

quella pagina sembra rispondere "esattamente." al mio post precedente, non mi sembra che vada a favore di quel grafico.

Esattamente in che senso?

inoltre, sbaglio a pensare che le teorie esposte in quella pagina siano un sacco di castelli colorati campati per aria e privi di riscontro statistico? lo chiedo perché ho letto velocemente e senza andarmi a leggere pure le varie pagine linkate.

Cosa itendi per "senza riscontro statistico"?
Per dichiarare determinate percentuali come 72%, 19% etc. avranno pure dei dati sotto mano immagino.

Prova a vedere qui http://www.ambysoft.com/downloads/su...option2007.pdf

http://www.ambysoft.com/downloads/su...option2007.csv

http://www.ambysoft.com/downloads/su...option2007.ppt

[gugoXX]

Originariamente inviato da ^TiGeRShArK^

"WPF ..."

Immagino sia un lapsus

[^TiGeRShArK^]

Originariamente inviato da gugoXX

Esattamente in che senso?


Cosa itendi per "senza riscontro statistico"?
Per dichiarare determinate percentuali come 72%, 19% etc. avranno pure dei dati sotto mano immagino.

Prova a vedere qui http://www.ambysoft.com/downloads/su...option2007.pdf

http://www.ambysoft.com/downloads/su...option2007.csv

http://www.ambysoft.com/downloads/su...option2007.ppt

e magari visto che ci sei dimmi come va 'sto coso:
http://www.hwupgrade.it/forum/showpo...3&postcount=26

[tomminno]

Originariamente inviato da gugoXX

Il tempo per aggiungere le funzionalita' con metodi agile e' ovviamente crescente man mano che passa il tempo (Occorre inserire il pezzo nuovo pur mantenendo la soluzione organica), ma con meno sforzo. Questo grazie principalmente alla rifattorizzazione vs pezze.

Scusa e perchè con le tecniche standard non è possibile rifattorizzare il codice? Praticamente mi stai fondendo una tecnica di sviluppo di un progetto software con la qualità del codice. Perchè il codice non potrebbe essere identico nei 2 casi?

Un bug in Agile equivale ad un test non scritto

Sbaglio o non sempre è possibile scrivere test?
Tutte le volte che il codice gira in un contesto esterno (es codice di applicativo web .NET che gira nel contesto di IIS, oppure servizi), i test verificano il funzionamento del codice non nel contesto in cui questo girerà. Quindi potrebbero evidenziarsi bug che nei test non emergono.

Al termine di un progetto le linee di codice per i test superano quelle del codice stesso, e questo significa che c'e' sempre meno spazio per i bug.

Ma il tempo di scrittura del codice aumenta (non dirmi che il codice dei test si scrive da sè). Nel mio caso il tempo per scrivere il codice quasi raddoppia (al che mi lasciano sempre perplesso le 2 settimane per pubblicare, cazzarola scrivete il codice alla velocità della luce!).

Mentre durante lo sviluppo c'e' chi prefreisce scrivere prima il codice e poi gli unit test, come me (non c'e' una regola precisa),

Meno male non sono il solo, mi sono sempre chiesto come si faccia a scrivere il test prima del codice. Ci vuole qualcuno che lo abbia in mente prima di scriverlo.

[^TiGeRShArK^]

Originariamente inviato da gugoXX

Immagino sia un lapsus

no, parlava proprio del WPF che con il MVVM è il complemento perfetto dell' agile development.
Prima se dovevi testare un interfaccia grafica facevi prima a spararti sulle bOlls, ora separando la view è nettamente + semplice e i binding ti danno quel "pizzico di magia" in + che non fa mai male.