View Full Version : [vari]Reinventare la ruota
Prendo spunto dalla frase che ho nella mia firma:
If you have a new fundamental assumption, throw away your old code and rewrite it from scratch. Incremental patching and modifying seems easier at first, and is the normal course of things in software development, but ends up being much harder and producing bulkier, markedly inferior code in the long run.
La frase è di Michael Abrash (guru dell'assembly x86, è ideatore dell'architettura del processore intel larrabee, ha lavorato sul kernel di windows e sull'engine di quake) ed è conosciuta come carmack's law.
Nella mia esperienza lavorativa (principalmente grossi progetti real time in c++) questa "legge" non l'ho mai vista mettere in pratica. Bisogna trascinarsi dietro codice vecchio di 20 anni, mal progettato, mal scritto e mal documentato perchè va bene perdere 2 anni a mettere le pezze ad una vecchia carcassa ma non va bene riscrivere il software da zero in un anno perchè si "reinventa la ruota".
Allo stesso modo certe volte si tende ad esagerare con l'utilizzo dei framework. Se è necessario implementare una particolare funzionalità e questa viene offerta da un framework LO SI DEVE USARE PER FORZA anche se magari l'utilizzo del framework ti porta a snaturare completamente l'architettura dell'applicazione e a buttar giù tutti i santi dal calendario ogni volta che vuoi distaccarti dal comportamento previsto.
Che ne pensate?
Nella maggior parte dei progetti sui quali ho lavorato ho visto questo genere di cose:
1)Codice assolutamente inutile, morto e abbandonato ma mai cancellato per chissà quale ragione.
2)Interi moduli che facevano la stessa cosa di altri moduli.
3)Classi con oltre 10.000 righe di codice e dalle funzionalità completamente eterogenee
4)Classi diverse create col cut-paste col 99% del codice in comune
5)Varie versioni fun1, fun2, fun3 della stessa funzione modificate a casaccio e mantenute nel caso ci si accorga che forse era meglio quella vecchia...
In ambito lavorativo penso che la questione che vale per ogni professione valga anche per l'informatica. E' quella del maximus paraculus: se usi gli strumenti più diffusi nell'ambito in cui lavori quando le cose vanno a schifìo dirai che hai fatto ciò che la migliore esperienza del momento storico suggeriva fosse giusto.
E' uno dei cardini dell'irresponsabilità professionale.
Poniamo che io e te scriviamo un programma "enterprise" (significa bubbole ma va bene lo stesso).
Io uso il J2EE, con un database oracle, su un server IBM.
Tu usi un framework che ti inventi tu, con un sistema di immagazzinamento dati che ti inventi tu, il tutto che funziona su un cluster di portatili 386.
Una volta venduti al cliente, entrambi i nostri programmi vanno a puttane e il cliente si becca 25 milioni di euro di danni per downtime.
Di fronte al randello chiodato io posso applicare il maximus paraculus: sono professionista, ho usato le tecnologie profescional che chiunque avrebbe usato, ho usato i pattern, ho usato tutto quello che di stantìio c'è in giro, con un po' di culo risulta che il danno derivi dall'inevitabile fallacia della tecnologia.
Ma tu... oh oh oh, tu sei nella cacca fino al collo! A parità di disastro, infatti, la puttanata profescional è quasi vergine rispetto a quella che non è trita e ritrita.
E' la famosa attività "di concetto": non è importante se il risultato sia l'apocalisse a meno che non sia il frutto di uno scostamento irragionevole dai binari del così fan tutti.
Non è un caso che siano le start-up quelle che apportano le maggiori innovazioni: non hanno clienti che li possano perseguire fino alla morte, sono libere di osare strade diverse.
Nell'ambito non lavorativo, la reinvenzione della ruota è un obbligo morale!
cdimauro
02-04-2010, 23:45
@javaboy: il museo degli orrori insomma. :D
Quando posso riscrivo e/o rifattorizzo il mio codice. Infatti quasi tutto ciò che ho realizzato nei 6 anni che lavoro nella mia azienda, l'ho praticamente riscritto quando ho dovuto rimetterci mano per qualche motivo.
Questo perché col tempo mi vengono in mente nuove soluzioni, o forse più eleganti e/o efficienti per realizzare la stessa cosa. E poi, almeno per me, il codice dev'essere "bello" anche da leggere. :cool:
lupoxxx87
03-04-2010, 01:34
scrivere codice dev'essere arte ragazzi !
dev'essere semplice da leggere per noi una volta che dobbiamo andare a riguardarlo, ma allo stesso tempo trovare spunti che ci facciano dire "cacchio questo si che è geniale"
se poi vogliamo incasinarlo per obbligare il cliente a tornare da noi...chi più ne ha più ne metta xD
Prendo spunto dalla frase che ho nella mia firma:
[i]
Nella mia esperienza lavorativa (principalmente grossi progetti real time in c++) questa "legge" non l'ho mai vista mettere in pratica. Bisogna trascinarsi dietro codice vecchio di 20 anni, mal progettato, mal scritto e mal documentato perchè va bene perdere 2 anni a mettere le pezze ad una vecchia carcassa ma non va bene riscrivere il software da zero in un anno perchè si "reinventa la ruota".
Allo stesso modo certe volte si tende ad esagerare con l'utilizzo dei framework. Se è necessario implementare una particolare funzionalità e questa viene offerta da un framework LO SI DEVE USARE PER FORZA anche se magari l'utilizzo del framework ti porta a snaturare completamente l'architettura dell'applicazione e a buttar giù tutti i santi dal calendario ogni volta che vuoi distaccarti dal comportamento previsto.
Che ne pensate?
Che in parte e' vero, tranne per la parte
...ma non va bene riscrivere il software da zero in un anno perchè si "reinventa la ruota".
Ci sono metodologie di progettazione software che permettono di avere un risultato in 1 mese circa, con qualcosa da fare vedere gia' dopo le prime 2 settimane, che possono essere applicate anche alla sostituzione di software vecchi.
E Quoto CDiMauro. La rifattorizzazione e' un punto cardine di queste metodologie. Si procede alla sostituzione parziale di un pezzo alla volta, fino a che si riesce a generalizzare comportamenti, riuscendo quindi a tagliare via intere branche di codice divenuto duplicato.
Riscrivere da capo tutto, personalmente, è sempre la cosa più irresistibile :D
Per me è un vero gusto iniziare da 0, mettere giù i mattoni fondamentali, eccetera...
nell'ordine, ho iniziato una decina di giochi, un rasterizzatore software, un traduttore da assembly Z80 a x86, un compressore di files, una rete neurale, un paio di motori grafici e un'AI.
Chiaramente non ho mai finito nulla :asd:
Per quanto mi riguarda a questo punto la tentazione di reinventare la ruota (insieme a quella di scrivere sempre codice generico e riusabile (che non è sempre un bene anzi)) è IL MALE, e tento sempre di forzarmi a riciclare altro codice.
Chissà che almeno un gioco non riesca a finirlo :asd:
Riassumendo: se si dovesse seguire solo la logica del realizzare programmi eccellenti, si finirebbe continuamente in un ciclo di riscritture, dato che un programma finito è per definizione più brutto di come lo si immaginava.
L'unico modo per realizzare davvero qualcosa è tentare di tenere insieme la baracca anche se è brutta, possibilmente usando tecniche come quelle descritte da cdimauro...
1)Codice assolutamente inutile, morto e abbandonato ma mai cancellato per chissà quale ragione.
La ragione è semplice. Se il codice non lo cancella chi l'ha scritto non lo cancellerà mai nessuno perchè la domanda più naturale che ci si pone in questo caso è "si sputtanerà tutto se cancello questo codice?" e per non avere problemi lo lasci li e fai finta di niente. Un po' come quando trovi il codice commentato e ti chiedi, "perchè è qui? servirà a qualcosa?". Io lo cancello sempre, al massimo tramite svn si riesce a recuperarlo.
Ti consiglio di regalare ai tuoi colleghi questo libro: http://tinyurl.com/ygv6wrm, è un must :)
tomminno
03-04-2010, 15:07
@javaboy: il museo degli orrori insomma. :D
Normale amministrazione per lo meno anche per la mia esperienza.
Quando posso riscrivo e/o rifattorizzo il mio codice.
Ok per il tuo ma per quello scritto da altri?
Puoi permetterti di rischiare di perderti nei meandri di un programma che magari funziona da anni? Sicuramente non documentato e di cui rischi di perderti qualche "nuanche" nascosta nelle decine di if annidati?
Doppotutto la scadenza è fissa (ed è sempre troppo a ridosso).
Infatti quasi tutto ciò che ho realizzato nei 6 anni che lavoro nella mia azienda, l'ho praticamente riscritto quando ho dovuto rimetterci mano per qualche motivo.
Se la scadenza te lo consente...
Per la mia esperienza non lo consente mai, anche perchè magari ti ci vuole un mese solo per riscrivere quanto esistente e magari la modifica deve finire in produzione in meno di 2 settimane (test inclusi). E da capo progetto se qualcuno mi dicesse questo codice fa schifo lo riscrivo da 0 mi ci vuole 1 mese in più ovviamente gli direi si hai ragione il codice fa schifo, per me puoi fare tutto quello che vuoi ma in 2 settimane deve essere in produzione.
Specialmente perchè i tempi dei progetti sono stimati sul tempo necessario a realizzare la modifica, non per il rifacimento completo.
tomminno
03-04-2010, 15:12
E Quoto CDiMauro. La rifattorizzazione e' un punto cardine di queste metodologie. Si procede alla sostituzione parziale di un pezzo alla volta, fino a che si riesce a generalizzare comportamenti, riuscendo quindi a tagliare via intere branche di codice divenuto duplicato.
Si se il software di partenza è scritto abbastanza bene lo puoi fare, ma il tipico codice è talmente interdipendente che sostituire una parte significa dove necessariamente andare a cambiarne anche un'altra e così via a catena fino alla riscrittura completa dell'intero software.
Per non parlare di software realizzati con vecchi linguaggi ormai morti es: VB6 o ASP.
Devi riscrivere tutto da 0 usando un linguaggio più moderno.
cdimauro
03-04-2010, 15:15
Aggiungo soltanto un'altra cosa. Alcune volte mi capita di dover mettere mano a codice altrui. Ebbene, quando posso, me lo studio e cerco di estenderlo o trarre spunto.
Ma quasi sempre finisco col chiedere spiegazioni su cosa dovrebbe fare quel codice, per rifarmelo da zero. Perdo molto meno tempo a scrivere il codice dalla descrizione dell'algoritmo, che a cercare di capire cosa fa la sua implementazione scritta da qualcuno.
Sì, a volte reinventare la ruota è decisamente la soluzione "migliore". :fagiano:
cdimauro
03-04-2010, 15:22
Ok per il tuo ma per quello scritto da altri?
Puoi permetterti di rischiare di perderti nei meandri di un programma che magari funziona da anni? Sicuramente non documentato e di cui rischi di perderti qualche "nuanche" nascosta nelle decine di if annidati?
Doppotutto la scadenza è fissa (ed è sempre troppo a ridosso).
Manco a farlo apposta, ho scritto poco fa un commento a tal proposito riflettendo sugli altri che sono scritti dall'ultima volta che avevo letto il thread. :asd:
Se la scadenza te lo consente...
Per la mia esperienza non lo consente mai, anche perchè magari ti ci vuole un mese solo per riscrivere quanto esistente e magari la modifica deve finire in produzione in meno di 2 settimane (test inclusi). E da capo progetto se qualcuno mi dicesse questo codice fa schifo lo riscrivo da 0 mi ci vuole 1 mese in più ovviamente gli direi si hai ragione il codice fa schifo, per me puoi fare tutto quello che vuoi ma in 2 settimane deve essere in produzione.
Specialmente perchè i tempi dei progetti sono stimati sul tempo necessario a realizzare la modifica, non per il rifacimento completo.
Dalla mia ho un paio di vantaggi: in azienda in Python ci lavoro quasi esclusivamente io (adesso finalmente c'è un collega che sta seguendo le mie orme :)), e poi con questo linguaggio scrivo codice molto velocemente.
Comunque un po' di tempo per la rifattorizzazione lo si trova. Non dico sempre, ma dopo diversi mesi mi capita di trovare qualche giorno a disposizione per poterlo fare.
Oppure, mentre lavoro a un nuovo progetto o funzionalità per uno esistente, se mi capita di rimettere mano a codice già scritto e mi accorgo che c'è un pattern ricorrente, rifattorizzo solo quel pezzetto, lasciando il resto com'è.
Si se il software di partenza è scritto abbastanza bene lo puoi fare, ma il tipico codice è talmente interdipendente che sostituire una parte significa dove necessariamente andare a cambiarne anche un'altra e così via a catena fino alla riscrittura completa dell'intero software.
Per non parlare di software realizzati con vecchi linguaggi ormai morti es: VB6 o ASP.
Devi riscrivere tutto da 0 usando un linguaggio più moderno.
OK, ma a me capita di rado una situazione del genere. Vuoi perché, appunto, ci lavoro soltanto io. Vuoi perché ho la tendenza a scrivere codice con una certa interfaccia ben definita e "stabile" nel tempo, per cui la rifattorizzazione quasi sempre mi comporta un cambiamento dell'implementazione e non dell'interfaccia, quindi garantendo il funzionamento del codice già esistente che ne fa uso.
tomminno
03-04-2010, 15:58
Dalla mia ho un paio di vantaggi: in azienda in Python ci lavoro quasi esclusivamente io (adesso finalmente c'è un collega che sta seguendo le mie orme :)), e poi con questo linguaggio scrivo codice molto velocemente.
Te parti dalla visione di un progetto portato avanti da una singola persona. Nel mio caso i progetti coinvolgono almeno 3 persone che devono intervenire su parti diverse di un sistema che comporta modifiche a più software. In tali circostanze è impensabile anche solo proporre le tempistiche per la riscrittura.
Poi alle volte date le capacità di chi andrà a mettere mano al codice il risultato di una riscrittura non sarebbe difforme dall'originale...
astorcas
03-04-2010, 16:02
io ormai sono entrato nell'ottica "A lavoro scrivo porcherie e a casa mi do all'arte della programmazione". Più che altro è un mix di rassegnazione e menefreghismo :fagiano:
tomminno
03-04-2010, 16:20
io ormai sono entrato nell'ottica "A lavoro scrivo porcherie e a casa mi do all'arte della programmazione". Più che altro è un mix di rassegnazione e menefreghismo :fagiano:
A volte se vuoi fare un dispetto è più facile riuscirci se scrivi codice con tutti i crismi, in modo che sia praticamente incomprensibile a gente che scrive programmi tutti nel main.
Se la scadenza te lo consente...
Per la mia esperienza non lo consente mai, anche perchè magari ti ci vuole un mese solo per riscrivere quanto esistente e magari la modifica deve finire in produzione in meno di 2 settimane (test inclusi). E da capo progetto se qualcuno mi dicesse questo codice fa schifo lo riscrivo da 0 mi ci vuole 1 mese in più ovviamente gli direi si hai ragione il codice fa schifo, per me puoi fare tutto quello che vuoi ma in 2 settimane deve essere in produzione.
Specialmente perchè i tempi dei progetti sono stimati sul tempo necessario a realizzare la modifica, non per il rifacimento completo.
Il problema è che per rispettare una milestone si produce del codice che moltiplicherà per 10 il tempo necessario a rispettare le milestone successive.
E' necessario trovare il coraggio di fermarsi e buttare il codice vecchio a volte.
Un altro problema è che i programmatori vengono considerati infima manovalanza intercambiabile, non puoi far lavorare una persona per 3 mesi e poi allocarla su un altro progetto passando la patata bollente a un altro che impiegherà mesi a capire quel che è stato fatto dal collega.
Molto spesso poi manca una figura di programmatore capo o direttore tecnico: ci sono i project manager che perdono completamente il contatto con gli aspetti tecnologici e i programmatori: tutti allo stesso livello, tutti allo sbaraglio.
Ogni programmatore pensa al suo orticello e a soddisfare il requisito nel minor tempo possibile, in questo modo si crea del codice spazzatura.
astorcas
03-04-2010, 16:49
Molto spesso poi manca una figura di programmatore capo o direttore tecnico: ci sono i project manager che perdono completamente il contatto con gli aspetti tecnologici e i programmatori: tutti allo stesso livello, tutti allo sbaraglio.
Ogni programmatore pensa al suo orticello e a soddisfare il requisito nel minor tempo possibile, in questo modo si crea del codice spazzatura.
bene... dunque è una realtà comune, non solo dei posti dove ho lavorato fino ad ora :rolleyes:
khelidan1980
03-04-2010, 16:51
P
Bisogna trascinarsi dietro codice vecchio di 20 anni, mal progettato, mal scritto e mal documentato perchè va bene perdere 2 anni a mettere le pezze ad una vecchia carcassa ma non va bene riscrivere il software da zero in un anno perchè si "reinventa la ruota".
20 anni? Ti va di lusso qui ci si trascina dietro servizi cobol scritti negli anni 70 :asd:
Nella maggior parte dei progetti sui quali ho lavorato ho visto questo genere di cose:
1)Codice assolutamente inutile, morto e abbandonato ma mai cancellato per chissà quale ragione.
2)Interi moduli che facevano la stessa cosa di altri moduli.
3)Classi con oltre 10.000 righe di codice e dalle funzionalità completamente eterogenee
4)Classi diverse create col cut-paste col 99% del codice in comune
5)Varie versioni fun1, fun2, fun3 della stessa funzione modificate a casaccio e mantenute nel caso ci si accorga che forse era meglio quella vecchia...
Ordinaria amministrazione!
cdimauro
03-04-2010, 16:55
Te parti dalla visione di un progetto portato avanti da una singola persona. Nel mio caso i progetti coinvolgono almeno 3 persone che devono intervenire su parti diverse di un sistema che comporta modifiche a più software. In tali circostanze è impensabile anche solo proporre le tempistiche per la riscrittura.
Poi alle volte date le capacità di chi andrà a mettere mano al codice il risultato di una riscrittura non sarebbe difforme dall'originale...
Non mi sono spiegato bene allora. La parte a cui lavoro io la gestisco quasi esclusivamente io (a parte il nuovo aiuto; finalmente), ma ai progetti in cui sono coinvolto lavorano diverse persone (con linguaggi diversi).
La domanda del non addetto sorge spontanea: ma di fronte alla richiesta di manutenere queste ignominie, uno non dovrebbe dire: "questa cosa va riscritta perchè x, y, z" e, in caso di cieca insistenza, "qui c'è la tastiera, se vuoi fare 'sta schifezza te la fai tu"?
Questioni di pagnotta?
cdimauro
03-04-2010, 17:11
Ovvio.
In questi casi non è che ci sono problemi: vuoi che lo faccio lo stesso? Non c'è problema, ci metto mani io, ma c'è almeno un mese di lavoro...
La domanda del non addetto sorge spontanea: ma di fronte alla richiesta di manutenere queste ignominie, uno non dovrebbe dire: "questa cosa va riscritta perchè x, y, z" e, in caso di cieca insistenza, "qui c'è la tastiera, se vuoi fare 'sta schifezza te la fai tu"?
Questioni di pagnotta?
Direi di si......
tomminno
03-04-2010, 17:19
Molto spesso poi manca una figura di programmatore capo o direttore tecnico: ci sono i project manager che perdono completamente il contatto con gli aspetti tecnologici e i programmatori: tutti allo stesso livello, tutti allo sbaraglio.
Già. E vuoi sapere da cosa deriva? Dalle menate psicologiche sulla gestione dei gruppi di lavoro. Se fai si che qualcuno sia messo sul "piedistallo" poi si ingenereranno dinamiche confluttuali all'interno del gruppo. Questo discorso mi è stato fatto tempo fa dal mio capo (ho un amico psicologo a cui ho sentito fare gli stessi discorsi, ah gli psicologi brutte bestie!), solo che se tieni tutti allo stesso livello mortifichi i più bravi che dopo un pò se ne andranno e rimarrai con gli elementi peggiori, che via via produrranno sempre prodotti qualitativamente più scadenti. Ma ti ritroverai da gestire un branco di pacifiche pecore.
Ogni programmatore pensa al suo orticello e a soddisfare il requisito nel minor tempo possibile, in questo modo si crea del codice spazzatura.
Considera anche che molti di quelli che lavorano come programmatori non sono assolutamente all'altezza del lavoro. Gente che non si è mai aggiornata professionalmente (aggiornamento di cui l'azienda non interessa farsi carico) e che comunque non possiede le capacità logiche per realizzare un software.
Direi di si......
E allora la questione è accademica.
tomminno
03-04-2010, 17:24
La domanda del non addetto sorge spontanea: ma di fronte alla richiesta di manutenere queste ignominie, uno non dovrebbe dire: "questa cosa va riscritta perchè x, y, z" e, in caso di cieca insistenza, "qui c'è la tastiera, se vuoi fare 'sta schifezza te la fai tu"?
Nel mio caso alla domanda: "questa cosa va riscritta perchè x, y, z" la risposta sarebbe "perfetto basta che sia tutto consegnato nei tempi previsti". Ovviamente i tempi sono sempre molto stretti anche solo per apportare le modifiche richieste, figuriamoci il rifacimento di un sistema che sta in piedi da più di dieci anni.
Questioni di pagnotta?
Decisamente. Alternative di un certo livello per quanto posso vedere in giro non ce ne sono.
cdimauro
03-04-2010, 17:36
figuriamoci il rifacimento di un sistema che sta in piedi da più di dieci anni.
A parte il "più", è così anche per me. Con buona parte della piattaforma scritta in PHP, ma questo è il meno peggio che possa capitare: bisogna vedere COME è stata scritta. :muro: :muro: :muro:
Già. E vuoi sapere da cosa deriva? Dalle menate psicologiche sulla gestione dei gruppi di lavoro. Se fai si che qualcuno sia messo sul "piedistallo" poi si ingenereranno dinamiche confluttuali all'interno del gruppo. Questo discorso mi è stato fatto tempo fa dal mio capo (ho un amico psicologo a cui ho sentito fare gli stessi discorsi, ah gli psicologi brutte bestie!),
Ci son già i project manager sul piedestallo e mille altre figure....Non capisco perchè non ci possano essere delle gerarchie fra i tecnici.
Parliamo del programmatore medio.
Magari laureato in ing. elettronica, sa di chimica, fisica, matematica, campi elettromagnetici, ritiene la programmazione un lavoro di basso livello inadatto al suo titolo di studio TUTTAVIA non sa programmare.
Credo che in italia uno dei problemi maggiori sia proprio la scarsa professionalità in alcuni ambiti.
Il fatto che gente non preparata si svegli una mattina e improvvisi un mestiere è a lungo andare dannoso... ma ancora più dannoso è il fatto che pur di guadagnare qualche spiccio lavora facendosi pagare la metà di quanto fanno i professionisti (poi ovviamente c'è caso e caso, ma l'andazzo sembra essere questo).
Questo a casa mia si chiama concorrenza sleale.
Riguardo alle gerarchie io sono assolutamente del parere che ci debba essere una figura di riferimento che:
a) si prenda la responsabilità di alcune scelte
b) aiuta a sbrogliare alcune dispute tra approcci diversi
In questo paese c'è bisogno di gente che si impari a prendere le proprie responsabilità.
RagingBull
03-04-2010, 20:23
Spero di non cadere nel banale con le mie affermazioni.
Ho avuto poche esperienze lavorative ma, per quel poco che ho visto, di tutto quello che ci hanno insegnato durante il corso di ingegneria del software all'università ho visto praticamente nulla. Si punta solo a finire il progetto nei tempi stabiliti fregandosene di tutta quella che è la prassi che c'è a monte: analisi, progettazione, fase di test...tutta roba che per molti sembra essere solo una perdita di tempo.
E' proprio da questo modus operandi che scaturiscono in futuro domande del tipo: "ma se io cancello sto metodo/classe cosa succede?". E nessuno mai si prenderà la responsabilità di eventuali casini derivanti da quella eliminazione.
Dunque reinventare la ruota va bene...ma bisogna anche sapere come è stata inventata la prima volta per sapere dove si nascondono pregi e difetti.
- Tratto da "Pensieri di un neolaureato in informatica" (IO) :) -
Purtroppo molti non capiscono che sviluppare il software non basta, poi devi poterlo manutenere...
Anche perché poi bisogna sobbarcarsi i costi di una cattiva progettazione.
In questo paese c'è bisogno di gente che si impari a prendere le proprie responsabilità.
Alle prossime politiche sulla scheda scrivo WarDuck. Adesso vedi tu se candidarti o no, ma il mio voto ce l'hai comunque.
Molto spesso poi manca una figura di programmatore capo o direttore tecnico: ci sono i project manager che perdono completamente il contatto con gli aspetti tecnologici e i programmatori: tutti allo stesso livello, tutti allo sbaraglio.
Ogni programmatore pensa al suo orticello e a soddisfare il requisito nel minor tempo possibile, in questo modo si crea del codice spazzatura.
Nell'agile programming non esiste il project manager.
Tutti a casa :asd:
Ad esempio nella metodologia conosciuta come Scrum, e' prevista la figura dello scrum master.
Lo scrum master e' pero' a sua volta sia architetto che sviluppatore. E' colui che guida tutto il gruppo, e deve essere in grado di fare tutto il lavoro anche da solo, se avesse a disposizione tutto il tempo necessario.
A differenza dei project manager di vecchio stampo, tanto cari all'Italia, che forse una volta erano in grado di fare, e diventano project manager perche' non si sa piu' cosa fargli fare perche' non sono piu' al passo con la tecnologia.
Nell'agile programming non esiste il project manager.
Tutti a casa :asd:
Se è per quello non c'è neanche il project. E avrei qualche dubbio sul fatto che sia programming.
Di certo è agile.
Se è per quello non c'è neanche il project. E avrei qualche dubbio sul fatto che sia programming.
Di certo è agile.
Dispiace che qualcuno riesca a lavorare e anche bene? :asd:
Eppure non mi sembri cosi' vecchio.
Comunque, continua a rileggerti la firma. Potresti imparare molto.
Be', questa:
A proposito di politica, ci sarebbe qualcosa da mangiare?
e' stupenda.
Circa l'agile programming ho avuto modo di leggere beck e fowler. Ottimi scrittori del genere giallo. Per chi non l'avesse fatto, vi dico come va a finire:
la vittima è la logica, assassinata dagli autori.
Be', questa:
e' stupenda.
Circa l'agile programming ho avuto modo di leggere beck e fowler. Ottimi scrittori del genere giallo. Per chi non l'avesse fatto, vi dico come va a finire:
la vittima è la logica, assassinata dagli autori.
La tua di firma. Non la mia.
Comunque si vede lontano un miglio che sai proprio poco, e probabilmente non hai alcuna esperienza pratica, di cio' che stai tentando di parlare. Tante frasi fatte, ma passando tutto attraverso il processo di sintetisi di Asimoviana memoria, non esce nulla.
E a differenza tua invece io conosco sia il vecchio che il nuovo.
E anche se non c'entra nulla, conosco e ho lavorato sia in C# che in Java. E per tua norma tutti quelli che ho conosciuto, che conoscevano Java e poi hanno transito a c#, non ci penserebbero nemmeno lontanamente a tornare indietro.
Buon futuro :asd:
Se stai cercando di darmi dell'inetto devi osare un po' di più perchè io ho un ego misurabile in unità astronomiche.
Se stai cercando di darmi dell'inetto devi osare un po' di più perchè io ho un ego misurabile in unità astronomiche.
Inetto no, come potrei non ti conosco.
Ma probabilmente poco furbo nel tentare di sparlare di campi che non consci forse si'. E con me lo fai spesso. Sara' che non ti piaccio. Chissa'. O forse mi becchi sempre quando hai mangiato pesante.
Hai magari paura di confrontarti con chi potrebbe saperne piu' di te?
cdimauro
03-04-2010, 23:50
http://www.cre8asiteforums.com/forums/style_emoticons/others/popcorn.gif
E' una questione di argomenti, non di persone. E' nota la mia avversione per l'agile programming e per .NET, ho avuto modo di discuterne anche animatamente in più occasioni. Credo che siano in archivio, scazzottate memorabili.
Quanto alle paure, io pendo letteralmente dalle labbra di chi ne sa più di me. Da buon ignorante, mi capita di chiedere. Uno può non ricordarlo ma la critica è la richiesta che uno fa a qualcuno di risolvere una contraddizione.
Quando dico che l'agile programming è una stronzata mi riferisco provocatoriamente alla sua mancanza di principi falsificabili. Ho letto qualcosa sull'argomento e non li ho trovati, neppure al livello del tentativo - a meno che non fosse il rinvio al libro sullo stile di vita delle tribù amazzoniche ma ne dubito.
La domanda nella mia critica è: quali sono le affermazioni che devono essere vere affinchè l'agile developement sia vero e che lo fanno cadere nel caso in cui se ne dimostri la falsità ovvero quali sono i suoi principi?
Una precisazione di metodo. Non mi interessa che siano detti da Rubbia o che siano il frutto di osservazione personali: la logica prescinde dall'autorevolezza.
Ma guarda che non e' una dimostrazione, o un teorema.
E' una metodologia di gestione di progetto.
Pertanto non ha affermazioni che possano essere verificate o falsificabili.
C'e'. Esiste. Se hai un gruppo di lavoro che con questa metodologia funziona meglio di altre, lo usi e vai avanti. Se invece il gruppo di lavoro non lo riesce ad usare o e' meno efficiente che con altri metodi, allora non lo usi e vai avanti lo stesso. (Piu' lento e con piu' problemi, dico io e non solo io, peccato per voi).
Mi sa che stai applicando critiche sbagliate.
E relativamente al .Net e al C# in particolare.
E' solo un linguaggio. Nemmeno inventato da Microsoft, ma da essa privilegiato.
Ed essendo un linguaggio, ha i sui pregi e i suoi difetti. (Piu' pregi e meno difetti di Java, aggiungo io).
Come si fa poi a rodersi il fegato nell'essere avversi ad un linguaggio proprio non lo capisco. Non ti piace? Non lo usi, finito li'.
Sara' magari che hai paura di avere torto? :asd:
Comunque la tua avversione ad Agile e .net puo' essere nota e stranota tanto quanto vuoi, ma davvero don't care.
Ne' le mie parole ne' le tue serviranno per smouvere alcunche' la' fuori.
Quindi vivi serereno e continua pure a lavorare nell'IT in Italia, dove probabilmente nel marasma poco professionale che contraddistingue il nostro paese avrai per tua fortuna poco a che fare.
Tanto peggio di quello che gia' c'e' sara' molto difficile che potrai combinare.
Le uniche cose buone che per l'IT e' riuscita a tirare fuori l'Italia sono state l'Olivetti dei tempi andati e Python.
Non so neanche cosa dire.
Signori, io sono un magazziniere con l'hobby dell'informatica e SO che le metodologie di una scienza sono fondate su principi di logica.
Mi auguro che lo sappiate anche voi che nel campo ci lavorate.
cdimauro
04-04-2010, 07:01
Francamente non pensavo che continuassi a fare il magazziniere. Nel periodo in cui l'hai reso noto sei praticamente sparito (quasi un annetto, se non erro), per poi ritornare nuovamente in maniera più o meno stabile, per cui pensavo fossi tornato a lavorare come programmatore. :p
Chiusa questa parentesi, il problema è sempre lo stesso: sei troppo legato alla teoria. Questo non significa che agli altri faccia schifo, o non si facciano masturbazioni mentali, ma diciamo che il pragmatismo spesso prende il sopravvento.
La metodologia agile, come la programmazione a oggetti, ad esempio, è empiricamente più fruttifera. Ne abbiamo già discusso. Non serve una teoria dietro per intuire che spesso consente di raggiungere risultati "migliori" (in meno tempo e/o più manutenibili).
Non ci sono teoremi che lo dimostrano? No, perché non c'è nemmeno una teoria. Poco male. "it works". E noi, da buoni informatici, cerchiamo di valutare quali strumenti, anche poco "ortodossi" (non approvati da Turing, Goedel, ecc. :D), utilizzare per raggiungere i nostri obiettivi. :cool:
x "gugu": le idee di "PGI" sull'argomento sono ben note, e il suo sarcasmo al vetriolo pure.
Non c'è nessuna "sfida" né mancanza di "coraggio": semplicemente è fatto così, e lo trovo spesso esilarante (sia chiaro: NON ridicolo; mi spancio dalla risate con certe sue uscite, ma apprezzo il suo punto di vista perché è comunque istruttivo).
Non a caso stanotte ho messo quella emoticon coi popcorn. :D
Ne approfitto per fare gli auguri di buone feste a tutti. :)
Mi ricorda quello sketch di guzzanti...
Questa è la casa delle libertà, facciamo un po' come cazzo ci pare! :D
cdimauro
04-04-2010, 07:35
http://www.youtube.com/watch?v=u-NRmT0R5eg
:D
rеpne scasb
04-04-2010, 09:54
■
Non voglio irritarti il giorno di Pasqua, ma stai dicendo che "sai che funziona, ma non sai PERCHE' funziona", oppure non ho compreso quello che volevi manifestare?
Mi interesserebbe capire questo passaggio.
Nono, lo so bene perche' funziona. Meglio, so bene perche' funziona rispetto alle classiche piu' vecchie metodologie di progetto.
Le macrofasi delle classiche metodologie di progetto.
La raccolta di requisiti, la stesura del contratto tipicamente di 100-200 pagine in concomitanza con la fase progettuale, poi c'e' la fase di produzione, consegna e validazione. 1 anno.
In pratica all'inizio dei tempi dell'informatica di consumo, quando si era in assenza di alternative o di passate esperienze a cui ispirarsi, si e' "provato" ad applicare alla produzione di software quelle che erano e sono tutt'ora le metodologie di progetto del settore civile o meccanico. Siamo alla meta' anni 80.
Dopo 8 mesi si entrava nelle stanze dei progetti grandi e si vedevano stuoli di decine e decine di sottogruppi intenti a sviluppare. In realta' lo sviluppo era gia' terminato da tempo. "In 4 mesi consegneremo tutto". Cosa facevano nei 4 mesi restanti? Integrazione. Si' perche' sulla carta tutto era bello, ben disegnato con grossi schemi UML, ma poi nella pratica c'era sempre questo problema qui, quel problema li', e i pezzi costruiti dai vari gruppi di lavoro non parlavano mai bene tra di loro.
Alla fine, quando si consegnava, e per la prima volta il cliente vedava qualcosa, non era contento. Anzi. Era il piu' delle volte rosso dalla rabbia.
Perche'? Perche' il cliente non sa mai quello che vuole veramente all'inizio. Ha qualche parvenza, qualche idea, ma non e' mai tipicamente quello che ha in testa o quello che vorrebbe avere avuto. Si e' imparato che il cliente all'inizio in realta' non ha la piu' pallida idea di cosa vorrebbe venisse fuori. O addirittura le sue proposte sono controproducenti e difficili da realizzare, e se si fosse realizzato il tutto con strumenti che nemmeno lui conosceva, il tutto sarebbe stato piu' semplice e sarebbe stato anche piu' contento (Ovvero, non solo non sa quello che vuole, ma neppure sa neppure quello che c'e' in giro)
E quindi dopo 1 anno iniziavano quindi i bagni di sangue sia pratici che legali per quelle che sono le modifiche al contratto.
Il sistema Agile invece fa di un punto di forza quello che classicamente era un punto debole. Le variazioni di progetto sono bene accette. Anzi, sono una componente essenziale, senza le quali i pregi principali rispetto alle altre metodologie vengono meno.
C'e' la gestione di gruppi distribuiti. Nelle metodologie classiche e' bene che tutti si stia nello stesso stanzone. Grandi organizzazioni hanno problemi in questo. Ci sono sviluppatori in USA, altri in Europa, altri in far est, tutti che lavorano allo stesso progetto. Se si incontrassero e si mettesse insieme i codici una volta ogni 3 mesi si incorrerebbe negli stessi problemi di integrazione di cui sopra, e si spenderebbe piu' tempo a integrare che a sviluppare.
Le metodologie Agile prescindono da questo, e hanno cercato modi per gestire piu' efficientemente gruppi di lavoro distribuiti.
Poi c'e' l'altra considerazione. Nelle metodologie classiche il maggior fuoco d'attenzione e' dato al progetto. Il progetto e' il centro di tutto. Piani di lavoro, milestone, Project manager che a seconda dei lavori da fare alloca operai qui e operai la'. Presunta intercambiabilita' delle risorse, etc.
In tutte le metodolgie Agile invece il punto centrale e' il singolo sviluppatore. Lui sa quello che sa fare e quello che sa fare meglio.
In alcune metodologie come lo Scrum il punto focale e' invece il gruppo di lavoro, il gruppo degli sviluppatori, ma cambia poco. Ma non si tratta di autogestione. Nel gruppo di sviluppatori deve esserci anche uno dei clienti, e partecipare a tutte le fasi di progetto.
Rilasci continui, parziali, incrementanti e funzionanti direttmente nell'ambiente di produzione, il primo dopo 1 mese, gli altri ogni 15 giorni.
Il cliente alla fine NON puo' essere scontento. E' egli stesso che disegna l'applicazione man mano che passa il tempo. E' egli stesso che decide la priorita' delle varie "Storie" (Sottopezzi di funzionalita' da aggiungere in produzione) E' egli stesso che decide le varianti da applicare, che nella peggiore delel ipotesi vengono portate in produzione entro 1 mese.
Poi si condisce il tutto nel cercare di rendere l'ambiente di sviluppo il piu' piacevole possibile per il gruppo di lavoro. Lavorare deve essere il piu' divertente possibile.
Altri concetti pratici essenziali sono la integrazione continua del codice e i test.
Tutti i gruppi di lavoro, ogni singolo sviluppatore, non appena ha terminato un piccolo pezzettino integra direttamente il proprio codice in quello che e' il repository centrale, il quale immediatamente compila la nuova versione del prodotto e lo rilascia in un opportuno ambiente pronto per essere testato dal gruppo QA.
Nel frattempo vengono continuamente e incessantemente eseguiti i test globali su tutti i pezzi di codice (E sulle integrazioni verso i componenti esterni), in modo tale a validare il pezzettino di codice appena rilasciato, alla ricerca di eventuali bug di regressione. La macchina di test opera continuamente per mesi e mesi, eseguendo in continuazione tutti i test ogni volta che una singola linea di codice viene rilasciata, fatto che in grossi gruppi di lavoro, magari distribuiti su tutto il globo, avviene di continuo.
In questo modo si sa che, fatto salvo che il piccolo pezzetto di codice rilasciato fosse la traduzione in linguaggio informatico di cio' che la relativa storia richiedeva, cosa che un computer non e' ancora in grado di valutare ( :) ), si potrebbe prendere il risultato appena compilato in ambiente QA e passarlo direttamente in ambiente di produzione.
E si puo' andare a dormire tranquilli la sera, sicuri che il singolo pezzo che e' stato fatto entra perfettamente nel disegno globale, che non provoca danni al tutto e che fa proprio quello che deve fare.
Un sunto di tutto insieme
http://www.extremeprogramming.org/rules.html
Non leggere.
E LAVA ANCHE PIU' BIANCO!
anonimizzato
04-04-2010, 11:11
Inetto no, come potrei non ti conosco.
Ma probabilmente poco furbo nel tentare di sparlare di campi che non consci forse si'. E con me lo fai spesso. Sara' che non ti piaccio. Chissa'. O forse mi becchi sempre quando hai mangiato pesante.
Hai magari paura di confrontarti con chi potrebbe saperne piu' di te?
Perdonatemi, non voglio mettermi in mezzo ma ... questa mi suona molto come: "Sei solo un fifone McFly!!!" :asd:
anonimizzato
04-04-2010, 11:26
Non so neanche cosa dire.
Signori, io sono un magazziniere con l'hobby dell'informatica e SO che le metodologie di una scienza sono fondate su principi di logica.
Mi auguro che lo sappiate anche voi che nel campo ci lavorate.
Questo mi fà parecchio dispiacere PGI-Bis, sinceramente.
Io sono un umile programmatore web (da 6 anni) non laureato che durante il tempo ha avuto modo di capire, su questo forum, il tuo alto grado di competenza informatica, in particolare riguardo a Java.
Sia chiaro: ho fatto anch'io il magazziniere e l'operaio ma poi ho dato e stò dando tutto per cercare di fare un lavoro che ancora mi piace (forse).
Spero per te, se ovviamente il lavoro che fai ora non ti piace, che sia solo una parentesi in attesa di trovare un impiego sicuramente più adatto alle tue capacità e competenze.
zakmckraken
04-04-2010, 11:43
Giusto per inserirmi nella discussione...
Per quello che mi e'parso gli unici progetti che ho visto concludere bene e in tempo erano quelli gestiti da PM validi con programmatori validi, che fosse metodologia agile o tdd o rup o chi per esso.
Con valido non intendo esperto, intendo gente in grado di ragionare in modo logico che non si fa prendere dall'esaltazione per ogni buzz-framework che passa di li per caso o per ogni linguaggio appena nato e instabile che gli rotola davanti anche se e'troppo piu'cool... Mi sembra bello questo articolo di DrDobbs:
Why Software Really Fails And What to Do About It (http://www.drdobbs.com/cpp/223700002), in cui tra l'altro descrive un progetto di un "Personal TRansportation Device" come sarebbe fatto da un gruppo di sviluppo software, da cui cito la parte piu'vera ed inquietante Our goals include low fuel cost and no pollution, so the motor will be powered by helium fusion. Fusion is an emerging standard, but we believe that this project will provide synergy to fusion research, both driving the research and serving as a test bed for it.
E ci credo che poi la nostra professione va a rotoli.. ormai non servono metodologie, competenze...basta tanta gente che scrive codice che funzionicchia a malapena, poi tanto si cambia ogni anno tutto e l'economia gira....
AAARRRGGHHH perche non ho fatto economia :(
anonimizzato
04-04-2010, 11:59
E ci credo che poi la nostra professione va a rotoli.. ormai non servono metodologie, competenze...basta tanta gente che scrive codice che funzionicchia a malapena, poi tanto si cambia ogni anno tutto e l'economia gira....
Su questo sono d'accordo ma poi stà di fatto che è il mercato che decide e spesso mi sorgono dubbi sul fatto che la "verità" stia tutta da una parte.
AAARRRGGHHH perche non ho fatto economia :(
Non è che quelli laureati in economia se la passino tanto meglio ad oggi.
P.S.
Io ho fatto due anni di economia e commercio a Milano.
tomminno
04-04-2010, 12:17
Perche'? Perche' il cliente non sa mai quello che vuole veramente all'inizio.
Ha qualche parvenza, qualche idea, ma non e' mai tipicamente quello che ha in testa o quello che vorrebbe avere avuto.
Per mia esperienza non lo sa neanche alla fine.
Prima viene approvato un documento di progetto (e quello ci vuole non è che cominci qualcosa senza avere nemmeno un pezzo di carta). E ti dicono va tutto bene. Parti con lo sviluppo. Cominci a far vedere le prime bozze e va sempre tutto bene, poi avanzi nello sviluppo e va sempre tutto bene. Poi arrivi a una settimana dalla data di consegna e si sveglia qualcuno che ancora non aveva mai visto oppure che fino a quel momento aveva dato l'approvazione senza nemmeno guardare il progetto e la realizzazione e dice che quello non va bene, quello va rifatto in altra maniera ecc...
Puoi essere agile quanto ti pare, ma ad una settimana dalla consegna con già tutto il materiale praticamente completo già in fase di test avanzato andare a demolire gli assiomi intorno a cui gira il software non è proprio fattibile.
Il sistema Agile invece fa di un punto di forza quello che classicamente era un punto debole. Le variazioni di progetto sono bene accette. Anzi, sono una componente essenziale, senza le quali i pregi principali rispetto alle altre metodologie vengono meno.
Sempre che le variazioni di progetto non arrivino a ridosso della consegna... Come sempre avviene (almeno nel mio caso).
In tutte le metodolgie Agile invece il punto centrale e' il singolo sviluppatore. Lui sa quello che sa fare e quello che sa fare meglio.
Diciamo che il programmatore sa fare il suo mestiere. Come fa a sapere cosa deve fare? Ha una visione d'insieme di quello che deve essere il risultato?
Se c'è da modificare intranet, interfaccia pubblica, webservice, e sistemi interni si autoassegna i compiti? E chi valuta cosa c'è da modificare?
Con chi dialoga il singolo programmatore? Direttamente con il committente? Dialogare con il committente significa comunque produrre documenti. Il programmatore sa produrre documenti comprensibili al cliente che di informatica ovviamente sa una cippa?
In alcune metodologie come lo Scrum il punto focale e' invece il gruppo di lavoro, il gruppo degli sviluppatori, ma cambia poco. Ma non si tratta di autogestione. Nel gruppo di sviluppatori deve esserci anche uno dei clienti, e partecipare a tutte le fasi di progetto.
E se il cliente non c'è? Mica sempre il cliente (o un suo rappresentante) può permettersi di tenere una pesona fissa in contatto con il gruppo di sviluppo. Perchè poi quando emergono problemi nello sviluppo e vengono segnalati, chi ha l'incarico di scegliere quale sarà la strada corretta? Il cliente il più delle volte non capisce o non ha idea delle implicazioni che questa scelta potrebbe avere, tranne accorgersene a ridosso della consegna per cui dice "ma io veramente volevo quest'altro". Quando in realtà aveva sempre dato l'approvazione in precedenza...
Rilasci continui, parziali, incrementanti e funzionanti direttmente nell'ambiente di produzione, il primo dopo 1 mese, gli altri ogni 15 giorni.
Ma che scherzi? Pubblichi in produzione direttamente? Così per un errore (di integrazione) magari scopri che hai sputtanato giorni e giorni di fatturazione o comunque di dati nel db...
Gli avanzamenti nello sviluppo li fai vedere in un ambiente di test replica di quello di produzione.
Oltretutto in sistemi un minimo complessi non puoi pubblicare un nuovo software senza prima aver apportato le modifiche anche agli altri che magari non sono ancora pronti o che comunque richiedono il completamento delle modifiche prima di integrarsi correttamente nel resto del sistema.
Il cliente alla fine NON puo' essere scontento.
Ti posso assicurare che invece lo è. Nel mio caso perchè il cliente approva le varie fasi di sviluppo e poi alla fine avanza tutte le pretese e richieste di modifica che prima non aveva mai fatto o che contraddicono palesemente quelle fatte in precedenza. In questi casi che fai?
E' egli stesso che disegna l'applicazione man mano che passa il tempo. E' egli stesso che decide la priorita' delle varie "Storie" (Sottopezzi di funzionalita' da aggiungere in produzione) E' egli stesso che decide le varianti da applicare, che nella peggiore delel ipotesi vengono portate in produzione entro 1 mese.
Ok e se poi si accorge che le sue scelte erano sbagliate? Magari durante lo sviluppo gli vengono anche fatte notare le incongruenze ma lui insiste fino ad accorgersi tardivamente delle sue scelte errate? Dopotutto non è nemmeno detto che il cliente abbia una visione d'insieme del suo sistema per cui fa delle scelte senza avere un'opportuna base di informazioni.
In questo modo si sa che, fatto salvo che il piccolo pezzetto di codice rilasciato fosse la traduzione in linguaggio informatico di cio' che la relativa storia richiedeva, cosa che un computer non e' ancora in grado di valutare ( :) ), si potrebbe prendere il risultato appena compilato in ambiente QA e passarlo direttamente in ambiente di produzione.
Mi sembra una visione troppo semplicistica di sistemi un minimo complessi (o magari fatti male e incasinati, ma la realtà è comunque quella). Se il mio pezzo di codice passa tutte le validazioni ma l'output finale è sbalgiato perchè mancano ancora le modifiche agli altri componenti della catena?
E si puo' andare a dormire tranquilli la sera, sicuri che il singolo pezzo che e' stato fatto entra perfettamente nel disegno globale, che non provoca danni al tutto e che fa proprio quello che deve fare.
A me sembra invece che manchino tutte le premesse affinche il singolo pezzo di codice produca il risultato corretto.
Un semplice esempio, per una modifica è necessario modificare una stored procedure aggiungendo un parametro obbligatorio, il nuovo codice userà correttamente il parametro, ma tutti gli altri software che la utilizzano? Ovviamente cominceranno a fallire. Ma i test sul mio software daranno tutti OK.
Sicuro di poter dormire sonni tranquilli solo perchè nel tuo orticello vedi il verde dei test completati con successo?
E se intorno a te tutto è rosso fuoco non ti viene il dubbio che il tuo verde sia solo una pia illusione?
Andresti direttamente in produzione con il rischio di far smettere di funzionare un'intera azienda?
Secondo me finchè il progetto non è portato a termine nella sua interezza non può essere pubblicato. O comunque finchè non sono portate a termine le milestones che lasciano il sistema in un contesto stabile e funzionante.
Ma chi lo decide questo? Il singolo programmatore?
Ecco lo sviluppo agile per certi aspetti mi lascia sempre molto perplesso.
^TiGeRShArK^
04-04-2010, 13:53
Se è per quello non c'è neanche il project. E avrei qualche dubbio sul fatto che sia programming.
Di certo è agile.
:asd:
Si vede che non hai mai programmato con l'agile programming. :asd:
Continuate pure a lavorare all'italiana, io finalmente mi sto divertendo un mondo al lavoro. :)
khelidan1980
04-04-2010, 13:54
:asd:
Si vede che non hai mai programmato con l'agile programming. :asd:
Continuate pure a lavorare all'italiana, io finalmente mi sto divertendo un mondo al lavoro. :)
ormai quì emigrano tutti, mi sa che me tocca prima o poi.. :D
^TiGeRShArK^
04-04-2010, 14:01
Nono, lo so bene perche' funziona.
Non avrei saputo dirlo meglio, mi hai risparmiato un bel pò di fatica. :D
^TiGeRShArK^
04-04-2010, 14:06
Per mia esperienza non lo sa neanche alla fine.
Prima viene approvato un documento di progetto (e quello ci vuole non è che cominci qualcosa senza avere nemmeno un pezzo di carta). E ti dicono va tutto bene. Parti con lo sviluppo. Cominci a far vedere le prime bozze e va sempre tutto bene, poi avanzi nello sviluppo e va sempre tutto bene. Poi arrivi a una settimana dalla data di consegna e si sveglia qualcuno che ancora non aveva mai visto oppure che fino a quel momento aveva dato l'approvazione senza nemmeno guardare il progetto e la realizzazione e dice che quello non va bene, quello va rifatto in altra maniera ecc...
Puoi essere agile quanto ti pare, ma ad una settimana dalla consegna con già tutto il materiale praticamente completo già in fase di test avanzato andare a demolire gli assiomi intorno a cui gira il software non è proprio fattibile.
Sempre che le variazioni di progetto non arrivino a ridosso della consegna... Come sempre avviene (almeno nel mio caso).
Ma proprio no.
Il cliente NON basa le proprie decisioni e richieste su un "documento di progetto" o su una "prima bozza".
Il cliente lavora direttamente SULL'APPLICAZIONE che viene mandata in produzione subito dopo il controllo della QA ogni due settimane.
I clienti quindi usano in queste due settimane l'applicazione e abbiamo un feedback IMMEDIATO.
Inutile dire che in italia non ho MAI lavorato a niente del genere, tranne che con il progetto diamonds.
Ma dubito che prima di una decina di anni inizino ad arrivare anche nel "bel paese" queste metodologie. :rolleyes:
Diciamo che il programmatore sa fare il suo mestiere. Come fa a sapere cosa deve fare? Ha una visione d'insieme di quello che deve essere il risultato?
Se c'è da modificare intranet, interfaccia pubblica, webservice, e sistemi interni si autoassegna i compiti? E chi valuta cosa c'è da modificare?
Con chi dialoga il singolo programmatore? Direttamente con il committente? Dialogare con il committente significa comunque produrre documenti. Il programmatore sa produrre documenti comprensibili al cliente che di informatica ovviamente sa una cippa?
Nessun documento.
C'è una lista di task da fare (che costruiamo e stimiamo noi stessi) e ognuno sceglie quale lavorare e lo completa.
C'è una persona che si occupa di interfacciare i programmatori con il cliente ed anch'essa è presente a tutte le riunioni e partecipa attivamente nelle decisioni sulle funzionalità da aggiungere, sulla priorità e a cui possiamo chiedere conferma del risultato del nostro lavoro dato che conosce le esigenze dei clienti.
E se il cliente non c'è? Mica sempre il cliente (o un suo rappresentante) può permettersi di tenere una pesona fissa in contatto con il gruppo di sviluppo. Perchè poi quando emergono problemi nello sviluppo e vengono segnalati, chi ha l'incarico di scegliere quale sarà la strada corretta? Il cliente il più delle volte non capisce o non ha idea delle implicazioni che questa scelta potrebbe avere, tranne accorgersene a ridosso della consegna per cui dice "ma io veramente volevo quest'altro". Quando in realtà aveva sempre dato l'approvazione in precedenza...
Tutto compito della persona di interfaccia di cui sopra.
Ma che scherzi? Pubblichi in produzione direttamente? Così per un errore (di integrazione) magari scopri che hai sputtanato giorni e giorni di fatturazione o comunque di dati nel db...
Gli avanzamenti nello sviluppo li fai vedere in un ambiente di test replica di quello di produzione.
Oltretutto in sistemi un minimo complessi non puoi pubblicare un nuovo software senza prima aver apportato le modifiche anche agli altri che magari non sono ancora pronti o che comunque richiedono il completamento delle modifiche prima di integrarsi correttamente nel resto del sistema.
Se sei coperto da unit test, da test di integrazione e dal lavoro della QA non hai problemi.
Ti posso assicurare che invece lo è. Nel mio caso perchè il cliente approva le varie fasi di sviluppo e poi alla fine avanza tutte le pretese e richieste di modifica che prima non aveva mai fatto o che contraddicono palesemente quelle fatte in precedenza. In questi casi che fai?
Non può accadere perchè il cliente USA direttamente l'applicazione e si rende conto immediatamente se c'è qualcosa che non va.
Ma solitamente non sono così folli qui da chiedere una cosa una settimana e la settimana dopo da chiedere l'opposto.
Ok e se poi si accorge che le sue scelte erano sbagliate? Magari durante lo sviluppo gli vengono anche fatte notare le incongruenze ma lui insiste fino ad accorgersi tardivamente delle sue scelte errate? Dopotutto non è nemmeno detto che il cliente abbia una visione d'insieme del suo sistema per cui fa delle scelte senza avere un'opportuna base di informazioni.
La persona di interfaccia si occupa di tutto questo.
Mi sembra una visione troppo semplicistica di sistemi un minimo complessi (o magari fatti male e incasinati, ma la realtà è comunque quella). Se il mio pezzo di codice passa tutte le validazioni ma l'output finale è sbalgiato perchè mancano ancora le modifiche agli altri componenti della catena?
A me sembra invece che manchino tutte le premesse affinche il singolo pezzo di codice produca il risultato corretto.
Un semplice esempio, per una modifica è necessario modificare una stored procedure aggiungendo un parametro obbligatorio, il nuovo codice userà correttamente il parametro, ma tutti gli altri software che la utilizzano? Ovviamente cominceranno a fallire. Ma i test sul mio software daranno tutti OK.
Sicuro di poter dormire sonni tranquilli solo perchè nel tuo orticello vedi il verde dei test completati con successo?
E se intorno a te tutto è rosso fuoco non ti viene il dubbio che il tuo verde sia solo una pia illusione?
Andresti direttamente in produzione con il rischio di far smettere di funzionare un'intera azienda?
Modifiche su risorse condivise ovviamente richiedono il lavoro concertato dei vari team che si occupano dei vari prodotti che utilizzano le risorse.
Mi sembra assolutamente banale e scontato.
Secondo me finchè il progetto non è portato a termine nella sua interezza non può essere pubblicato. O comunque finchè non sono portate a termine le milestones che lasciano il sistema in un contesto stabile e funzionante.
Ma chi lo decide questo? Il singolo programmatore?
Ecco lo sviluppo agile per certi aspetti mi lascia sempre molto perplesso.
Secondo me non hai mai visto nemmeno di striscio le metodologie agile e meno che mai ci hai lavorato. :)
Ma tranquillo, come dicevo prima, potete dormire sonni tranquilli, prima di altri 10 anni dubito che in italia si inizino a diffondere queste metodologie. :)
Io intanto ho finalmente riscoperto il PIACERE di programmare. :)
Come viene valutata la bravura dei programmatori qui in italia?
Ho avuto colleghi estremamente preparati, intelligenti e appassionati, ragazzi che tornavano a casa e si mettevano a programmare su progetti personali che non son stati minimamente apprezzati per non dire peggio.
In italia il programmatore apprezzato è quello che dice sempre di si: quello disposto a lavorare anche la domenica e a rimanere 3 ore in più senza segnare gli straordinari, il programmatore mulo che è disposto a passare 10 ore sul debugger provando modifiche a caso finchè l'effetto di diversi bug si controbilancia causando un comportamento vagamente simile a quello previsto dai requisiti.
Le persone veramente competenti, quelle che sanno progettare e sviluppare un software non servono assolutamente. Tanto si tratta sempre di sguazzare fra bug vecchi di vent'anni.
khelidan1980
04-04-2010, 14:15
Come viene valutata la bravura dei programmatori qui in italia?
Ho avuto colleghi estremamente preparati, intelligenti e appassionati, ragazzi che tornavano a casa e si mettevano a programmare su progetti personali che non son stati minimamente apprezzati per non dire peggio.
In italia il programmatore apprezzato è quello che dice sempre di si: quello disposto a lavorare anche la domenica e a rimanere 3 ore in più senza segnare gli straordinari, il programmatore mulo che è disposto a passare 10 ore sul debugger provando modifiche a caso finchè qualcosa non funziona.
Le persone veramente competenti, quelle che sanno progettare e sviluppare un software non servono assolutamente. Tanto si tratta sempre di sguazzare fra bug vecchi di vent'anni.
putroppo ti devo quotare, le aziende che non usano questi criteri di valutazione sono davvero poche, per inciso, la mia li usa (questi sopra descritti)
^TiGeRShArK^
04-04-2010, 14:17
ormai quì emigrano tutti, mi sa che me tocca prima o poi.. :D
ah io ho trovato un altro mondo. :)
tomminno
04-04-2010, 14:33
Ma proprio no.
Il cliente NON basa le proprie decisioni e richieste su un "documento di progetto" o su una "prima bozza".
No il cliente valuta il sistema su un ambiente identico a quello di produzione via via che viene sviluppato.
Ma il problema è che il cliente ti dice si va bene, salvo poi rimangiarsi tutto nelle fasi conclusive.
Il cliente lavora direttamente SULL'APPLICAZIONE che viene mandata in produzione subito dopo il controllo della QA ogni due settimane.
E questo per lo meno nel mio contesto sarebbe impossibile perchè significa che in 2 settimane devi finire l'intero progetto, dato che non può finire in produzione una singola parte, pena il non funzionamento generale dell'azienda.
Ad esempio se devi fare una nuova interfaccia web per un nuovo prodotto con tanto di ordini e pagamenti , in 2 settimane è difficile avere la grafica completa, non credo proprio che in 2 settimane il cliente ti dia l'autorizzazione a pubblicare un sito scarno, senza css o con la grafica penosa (che generalmente è in grado di realizzare un programmatore medio, e i grafici lavorano con i loro tempi).
Sai quante modifiche l'utente vuole sull'interfaccia grafica? E' tutto un balletto di richieste che non si placano mai.
E poi che fai pubblichi il sito con mezzo carrello d'ordine perchè l'altra parte non è ancora pronta, oppure non hai completato la parte di pagamento/fatturazione? A che servirebbe?
I clienti quindi usano in queste due settimane l'applicazione e abbiamo un feedback IMMEDIATO.
Si certo e ti direbbero subito nel giro di un giorno che hanno le fatture sbagliate (e lì sono cazzi perchè ormai sono già state emesse), o ancora peggio si accorgono dopo qualche settimana di avere il database corrotto da dati non validi.
Certo avresti un feedback immediato dagli avvocati, con richiesta danni di minimo 100.000 Euro al giorno.
Inutile dire che in italia non ho MAI lavorato a niente del genere, tranne che con il progetto diamonds.
Dipende anche dal contesto. Se pensi di lavorare in un contesto isolato dove la tua modifica di 2 settimane non impatta sul restante sistema ok, ma se la tua modifica deve comportare l'adeguamento anche di diversi altri software è ovvio che in 2 settimane non fai quasi niente.
Ma dubito che prima di una decina di anni inizino ad arrivare anche nel "bel paese" queste metodologie. :rolleyes:
Forse perchè prima ci dobbiamo liberare del marciume esistente che impedisce l'adozione di tali tecniche di sviluppo?
tomminno
04-04-2010, 15:04
Nessun documento.
C'è una lista di task da fare (che costruiamo e stimiamo noi stessi) e ognuno sceglie quale lavorare e lo completa.
Scusa ma la lista dei task chi la compila? Chi analizza i task da realizzare? Come fai a sapere in quali punti del sistema andare ad intervenire se non hai fatto un'analisi a priori?
Come fai a sapere che devi modificare la fatturazione perchè magari un nuovo articolo non deve comparire nella fattura ma deve solo modificare la descrizione di un articolo già presente?
Se non hai analizzato il progetto non lo saprai mai. E il cliente non è che ti si presenta chiedendotelo esplicitamente, perchè magari neanche lo sa.
C'è una persona che si occupa di interfacciare i programmatori con il cliente ed anch'essa è presente a tutte le riunioni e partecipa attivamente nelle decisioni sulle funzionalità da aggiungere, sulla priorità e a cui possiamo chiedere conferma del risultato del nostro lavoro dato che conosce le esigenze dei clienti.
Aka project manager.
Se sei coperto da unit test, da test di integrazione e dal lavoro della QA non hai problemi.
I test d'integrazione mi risultano complicati da realizzare perchè fondamentamentalmente dovrei replicare nei miei test l'intero sistema. Il che significa avere dei test che replicano una macchina complessa da qualche milione di righe di codice. Oltretutto è necessario rispettare anche le tempistiche, non potrei lanciare i test a mezzogiorno se una procedura deve girare a mezzanotte, non sarebbe un'integrazione affidabile.
Quando poi ci sono eventi non replicabili nei test (sistemi esterni verso cui non esiste ambiente di test) ecco che questo diventa impossibile.
E non saprei nemmeno come definire che un test è ok oppure no, perchè il risultato è quello dell'intera macchina a stati. I risultati parziali potrebbero essere corretti oppure no a seconda dell'intero sistema. Per non parlare di procedure asincrone che possono durare giorni...
Non può accadere perchè il cliente USA direttamente l'applicazione e si rende conto immediatamente se c'è qualcosa che non va.
Troppo ottimista. Forse negli Usa dove il cliente sa tutto, da noi un pò meno.
E comunque chi ti dice che quel qualcosa che non va non possa essere deficitante per il funzionamento dell'intera azienda?
Ma solitamente non sono così folli qui da chiedere una cosa una settimana e la settimana dopo da chiedere l'opposto.
Ok negli Usa e in Italia?
Se non ti è mai capitato di lavorare su clienti che cambiano idea su decisioni già prese magari un mese prima allora sei fortunato.
Cioè secondo me in un contesto ideale con un cliente competente e tutta una serie di ipotesi abbastanza utopiche (o forse che si possono realizzare solo non trattando con italiani) il tutto può anche funzionare.
La persona di interfaccia si occupa di tutto questo.
Se ne occupa come? Se il cliente cambia idea in continuazione, alla fine è il cliente che paga e sei lì per cercare di soddisfare tutti i suoi capricci.
Ma il cliente paga solo se gli consegni il lavoro da lui richiesto nei tempi previsti.
Se cade uno di questi 2 requisiti ovviamente non paga.
Modifiche su risorse condivise ovviamente richiedono il lavoro concertato dei vari team che si occupano dei vari prodotti che utilizzano le risorse.
Mi sembra assolutamente banale e scontato.
Quindi confermi che andare in produzione con il pezzettino di codice funzionante non è possibile.
Ergo cade subito il postulato della pubblicazione direttamente in produzione.
Secondo me non hai mai visto nemmeno di striscio le metodologie agile e meno che mai ci hai lavorato. :)
E te in che contesti ci hai lavorato?
Per principio nel mio contesto non sono applicabili. A meno di non avere a disposizione forse 100 sviluppatori che in 2 settimane finiscono il lavoro e poi lo adattano piano piano alle richieste marginali del cliente.
Ma tranquillo, come dicevo prima, potete dormire sonni tranquilli, prima di altri 10 anni dubito che in italia si inizino a diffondere queste metodologie. :)
Io intanto ho finalmente riscoperto il PIACERE di programmare. :)
E che vorresti farmi invidia?
Qui si sta discutendo della validità di una tecnica di sviluppo software. Io ti sto postando una casistica in cui mi sembra che non si possa adattare.
Troppo facile finire con tanto per i prossimi 10 anni in Italia non si useranno queste tecniche.
Entrare nel merito no? Fondamentalmente alle mie casistiche hai risposto che non è possibile e che non capita. Invece io ti dico che è possibilissimo e che capita tutti i giorni. Quindi?
^TiGeRShArK^
04-04-2010, 15:28
No il cliente valuta il sistema su un ambiente identico a quello di produzione via via che viene sviluppato.
Ma il problema è che il cliente ti dice si va bene, salvo poi rimangiarsi tutto nelle fasi conclusive.
E questo per lo meno nel mio contesto sarebbe impossibile perchè significa che in 2 settimane devi finire l'intero progetto, dato che non può finire in produzione una singola parte, pena il non funzionamento generale dell'azienda.
Perchè in italia non esiste proprio il concetto di continuous design e si fa vedere qualcosa al cliente solo dopo che è tutto pronto.
E grazie al cazzo che non gli va bene in quel caso.
Con il continuous design è possibile aggiungere le funzionalità richieste dal sistema in sole due settimane.
Tutto il lavoro è estremamente modulare e modulabile e permette di aggiungere anche parti molto piccole che il cliente potrà quindi utilizzare.
Ad esempio se devi fare una nuova interfaccia web per un nuovo prodotto con tanto di ordini e pagamenti , in 2 settimane è difficile avere la grafica completa, non credo proprio che in 2 settimane il cliente ti dia l'autorizzazione a pubblicare un sito scarno, senza css o con la grafica penosa (che generalmente è in grado di realizzare un programmatore medio, e i grafici lavorano con i loro tempi).
Sai quante modifiche l'utente vuole sull'interfaccia grafica? E' tutto un balletto di richieste che non si placano mai.
In quel caso è lui che utilizza le FUNZIONALITA' del sistema.
I grafici idealmente non hanno nulla a che fare con i programmatori, e i programmatori devono lavorare sulle FUNZIONALITA' del sistema, sta poi ai grafici rendere tutto sbrilluccicoso.
E poi che fai pubblichi il sito con mezzo carrello d'ordine perchè l'altra parte non è ancora pronta, oppure non hai completato la parte di pagamento/fatturazione? A che servirebbe?
Per pubblicare un sito web visibile a tutti ovviamente deve essere pronta anche la parte grafica.
Ma al programmatore e al cliente che parla con loro non gliene deve fregare una mazza di discutere della grafica.
Egli dovrà solo valutare se le funzionalità del sistema rispettano i suoi requisiti e se gli vanno bene.
Si certo e ti direbbero subito nel giro di un giorno che hanno le fatture sbagliate (e lì sono cazzi perchè ormai sono già state emesse), o ancora peggio si accorgono dopo qualche settimana di avere il database corrotto da dati non validi.
Certo avresti un feedback immediato dagli avvocati, con richiesta danni di minimo 100.000 Euro al giorno.
Si, infatti. :asd:
Peccato che da noi le cose sono strutturate *lievemente* meglio e ogni sistema è modulare e si interfaccia con gli altri.
Non c'è un singolo sistema che può impedire il funzionamento degli altri, al massimo, in caso di problemi, gli altri sistemi non potranno usare le funzionalità esposte dal sistema malfunzionante.
Dipende anche dal contesto. Se pensi di lavorare in un contesto isolato dove la tua modifica di 2 settimane non impatta sul restante sistema ok, ma se la tua modifica deve comportare l'adeguamento anche di diversi altri software è ovvio che in 2 settimane non fai quasi niente.
Mi pare anche OVVIO che il sistema completo deve essere pensato con la modularità come principio base, d'altro canto è il requisito fondamentale per utilizzare una metodologia di sviluppo agile lo spezzare i problemi e le soluzioni in piccole parti per quanto possibile indipendenti tra di loro.
Scusa ma la lista dei task chi la compila? Chi analizza i task da realizzare? Come fai a sapere in quali punti del sistema andare ad intervenire se non hai fatto un'analisi a priori?
Come fai a sapere che devi modificare la fatturazione perchè magari un nuovo articolo non deve comparire nella fattura ma deve solo modificare la descrizione di un articolo già presente?
Se non hai analizzato il progetto non lo saprai mai. E il cliente non è che ti si presenta chiedendotelo esplicitamente, perchè magari neanche lo sa.
L'ho già detto prima.
La compiliamo noi, tutto il gruppo, in base alle indicazioni dell'interfaccia col cliente.
E ognuno di noi sa dove mettere le mani nelle parti che conosce meglio e sa come scrivere i task e come stimarli correttamente.
Un project manager che non ha la minima idea nè del sistema nel suo complesso nè del suo codice non potrà mai e poi mai fare una cosa del genere.
E in italia un project manager per definizione non conosce tutto il codice del sistema.
Quindi tutti i componenti del gruppo, coordinati dallo scrum master, possono agevolmente svolgere questo compito.
Aka project manager.
Ma anche no. :)
I test d'integrazione mi risultano complicati da realizzare perchè fondamentamentalmente dovrei replicare nei miei test l'intero sistema. Il che significa avere dei test che replicano una macchina complessa da qualche milione di righe di codice. Oltretutto è necessario rispettare anche le tempistiche, non potrei lanciare i test a mezzogiorno se una procedura deve girare a mezzanotte, non sarebbe un'integrazione affidabile.
Quando poi ci sono eventi non replicabili nei test (sistemi esterni verso cui non esiste ambiente di test) ecco che questo diventa impossibile.
E non saprei nemmeno come definire che un test è ok oppure no, perchè il risultato è quello dell'intera macchina a stati. I risultati parziali potrebbero essere corretti oppure no a seconda dell'intero sistema.
Ecco perchè questo è un lavoro che deve fare la QA con gli appositi tool e manualmente ove necessario. :)
Troppo ottimista. Forse negli Usa dove il cliente sa tutto, da noi un pò meno.
E comunque chi ti dice che quel qualcosa che non va non possa essere deficitante per il funzionamento dell'intera azienda?
E chi ha parlato di USA?
Io ho detto che il cliente USA = UTILIZZA l'applicazione direttamente in produzione e dunque si rende conto IMMEDIATAMENTE se c'è qualcosa che non va, e con la pratica, non certo leggendo fumosi documenti e vedendo prototipi malrispondenti alle sue idee rilasciati poco prima della consegna definitiva. :)
Ok negli Usa e in Italia?
Se non ti è mai capitato di lavorare su clienti che cambiano idea su decisioni già prese magari un mese prima allora sei fortunato.
Cioè secondo me in un contesto ideale con un cliente competente e tutta una serie di ipotesi abbastanza utopiche (o forse che si possono realizzare solo non trattando con italiani) il tutto può anche funzionare.
Guarda che solo tu hai parlato di USA. :)
Comunque un cliente che in DUE SETTIMANE (e non un mese) cambia idea radicalmente può voler dire solo queste cose:
1) è pazzo
2) colui che si dovrebbe interfacciare col cliente non ha la benchè minima idea di come fare il suo lavoro
3) il cliente non ha capito una mazza dato che non ha UTILIZZATO il sistema, ma ha solo visto documenti descrittivi del cappero.
Se ne occupa come? Se il cliente cambia idea in continuazione, alla fine è il cliente che paga e sei lì per cercare di soddisfare tutti i suoi capricci.
Ma il cliente paga solo se gli consegni il lavoro da lui richiesto nei tempi previsti.
Se cade uno di questi 2 requisiti ovviamente non paga.
Il cliente DEVE cambiare idea in continuazione.
Il continuo feedback del cliente è la base delle metodologie di programmazione agili.
Quindi confermi che andare in produzione con il pezzettino di codice funzionante non è possibile.
Ergo cade subito il postulato della pubblicazione direttamente in produzione.
No, questa è una tua invenzione. :)
io ti confermo che noi ANDIAMO in produzione ogni DUE SETTIMANE. :)
E il cliente ci da i suoi feedback lavorando sull'ultima versione dell'applicazione
E te in che contesti ci hai lavorato?
Per principio nel mio contesto non sono applicabili. A meno di non avere a disposizione forse 100 sviluppatori che in 2 settimane finiscono il lavoro e poi lo adattano piano piano alle richieste marginali del cliente.
Meno di dieci sviluppatori tra gui e server.
Infatti noi plasmiamo l'applicazione di settimana in settimana, non facciamo certo il grandissimo errore di farla tutta come la intendiamo noi per poi modificarla secondo le esigenze del cliente. :)
Noi la creiamo passo-passo, seguendo continuamente i feedback del cliente e aggiungendo piccoli pezzettini alla volte.
E che vorresti farmi invidia?
Qui si sta discutendo della validità di una tecnica di sviluppo software. Io ti sto postando una casistica in cui mi sembra che non si possa adattare.
Troppo facile finire con tanto per i prossimi 10 anni in Italia non si useranno queste tecniche.
Entrare nel merito no? Fondamentalmente alle mie casistiche hai risposto che non è possibile e che non capita. Invece io ti dico che è possibilissimo e che capita tutti i giorni. Quindi?
Avevo già risposto anche prima alle tue obiezioni, ma evidentemente non VUOI capire. :)
Si vede che non riesci proprio ad immaginare come funzionino certe cose abituato al modo di lavorare italiano.
Di certo la situazione in Italia non migliorerà grazie a quelli che se ne vanno all'estero...
Intendiamoci anche io sono fortemente tentato ad andarmene, ma non senza prima aver "combattuto", e spero che coloro che siano andati all'estero l'abbiano almeno provato a fare qui.
Se i programmatori non si ribellano ad un certo modo di lavorare, chessò mettendo su una azienda insieme (chiamiamolo pure laboratorio) per mettere in pratica le loro idee, è tutto un cacchio.
Ma chi lo deve cambiare questo paese? I 4 personaggi-fantocci che stanno seduti in parlamento o le persone che ogni giorno vanno a lavorare?
E' chiaro che la politica conta, ma in ogni caso senza persone che abbiano un minimo di palle, non cambierà mai niente, e mi dispiace per coloro che sperano e aspettano in qualcuno, forse una divinità non so, che risolve i problemi con la bacchetta magica.
Ripeto non conosco chi è andato all'estero, ma spero fortemente che prima di farlo abbia provato a fare qualcosa di nuovo QUI, in grado di attrarre persone che siano realmente interessate a cambiare e migliorare questo paese.
Poi questo discorso potrà sembrare campato in aria, o forse troppo idealistico, però io credo che se una persona VUOLE veramente qualcosa, può ottenerla.
E credo che cmq anche in Italia ci siano persone che abbiano passione per questo lavoro e vogliano dare il massimo. Tutto sta a metterle insieme.
^TiGeRShArK^
04-04-2010, 15:34
Di certo la situazione in Italia non migliorerà grazie a quelli che se ne vanno all'estero...
Intendiamoci anche io sono fortemente tentato ad andarmene, ma non senza prima aver "combattuto", e spero che coloro che siano andati all'estero l'abbiano almeno provato a fare qui.
Se i programmatori non si ribellano ad un certo modo di lavorare, chessò mettendo su una azienda insieme (chiamiamolo pure laboratorio) per mettere in pratica le loro idee, è tutto un cacchio.
Ma chi lo deve cambiare questo paese? I 4 personaggi-fantocci che stanno seduti in parlamento o le persone che ogni giorno vanno a lavorare?
E' chiaro che la politica conta, ma in ogni caso senza persone che abbiano un minimo di palle, non cambierà mai niente, e mi dispiace per coloro che sperano e aspettano in qualcuno, forse una divinità non so, che risolve i problemi con la bacchetta magica.
Ripeto non conosco chi è andato all'estero, ma spero fortemente che prima di farlo abbia provato a fare qualcosa di nuovo QUI, in grado di attrarre persone che siano realmente interessate a cambiare e migliorare questo paese.
Poi questo discorso potrà sembrare campato in aria, o forse troppo idealistico, però io credo che se una persona VUOLE veramente qualcosa, può ottenerla.
E credo che cmq anche in Italia ci siano persone che abbiano passione per questo lavoro e vogliano dare il massimo. Tutto sta a metterle insieme.
Ci ho provato per due anni, ma dopo essermi reso conto che in italia non c'è futuro, visto che mi era capitata quest'occasione non ci ho pensato troppo a lungo e non me la sono fatta sfuggire. :)
E comunque, come puoi vedere, anche su un forum del genere le nuove metodologie di programmazione vengono viste come "inutili" o addirittura si crede che "non funzionino" semplicemente perchè non le si è mai utilizzate e non si è in grado di concepire come possano funzionare. :)
In italia il mercato dell'IT, per quanto mi riguarda, dopo aver visto situazioni parecchio diverse, sia al sud che a roma che al nord, non ha futuro.
Dico il mio pensiero, sperando di aggiungere qualcosa, dal... basso della mia inesperienza :D :
l'ingegneria del software non è ancora complessivamente matura come lo sono le altre ingegnerie;
un problema grande è la "distanza" tra il cliente e l'informatico: se il cliente fosse uno con le stesse competenze di chi realizza il software, o viceversa il progettista/sviluppatore conoscesse il dominio, ci sarebbero molti meno problemi;
mi pare naturale che ognuno racconti la propria esperienza e le tecniche preferite, ma non può essere trascurato cosa si sta sviluppando ed eventuali altri vincoli: andare in produzione ogni 2 settimane può essere fatto per alcuni software, ma non per altri; non penso si possa sostenere che una metodologia che permette una cosa del genere possa essere la migliore in assoluto, o viceversa; magari potrebbe essere che ognuno lavori con la tecnica più adatta rispetto a ciò che sta sviluppando;
(questa cosa potrebbe risultare a voi una banalità, ma ricordatevi l'inesperienza... :D ) un metodo, che sia quello a cascata, che sia l'agile, o qualsiasi altro, detta una serie di linee guida: produrre il documento X, fare quel test, commentare così, ecc. Io penso che si debba utilizzare uno strumento se serve e non usarlo perché imposto dalla teoria: la documentazione che viene scritta viene usata spesso dallo sviluppatore stesso? E' una cosa palesemente utile, che agevola il lavoro, comoda (anche relativamente al futuro del software), accettata, scritta un tutt'uno con il codice? Se sì, andare avanti in quel modo. Se invece è una documentazione scritta a posteriori, per forza, mai consultata, non aggiornata con le versioni del codice (o difficilmente manutenibile essa stessa rispetto alle versioni), allora non farsi troppi problemi a non farla più anche se lo dice la "teoria".
^TiGeRShArK^
04-04-2010, 17:45
Dico il mio pensiero, sperando di aggiungere qualcosa, dal... basso della mia inesperienza :D :
l'ingegneria del software non è ancora complessivamente matura come lo sono le altre ingegnerie;
un problema grande è la "distanza" tra il cliente e l'informatico: se il cliente fosse uno con le stesse competenze di chi realizza il software, o viceversa il progettista/sviluppatore conoscesse il dominio, ci sarebbero molti meno problemi;
mi pare naturale che ognuno racconti la propria esperienza e le tecniche preferite, ma non può essere trascurato cosa si sta sviluppando ed eventuali altri vincoli: andare in produzione ogni 2 settimane può essere fatto per alcuni software, ma non per altri; non penso si possa sostenere che una metodologia che permette una cosa del genere possa essere la migliore in assoluto, o viceversa; magari potrebbe essere che ognuno lavori con la tecnica più adatta rispetto a ciò che sta sviluppando;
(questa cosa potrebbe risultare a voi una banalità, ma ricordatevi l'inesperienza... :D ) un metodo, che sia quello a cascata, che sia l'agile, o qualsiasi altro, detta una serie di linee guida: produrre il documento X, fare quel test, commentare così, ecc. Io penso che si debba utilizzare uno strumento se serve e non usarlo perché imposto dalla teoria: la documentazione che viene scritta viene usata spesso dallo sviluppatore stesso? E' una cosa palesemente utile, che agevola il lavoro, comoda (anche relativamente al futuro del software), accettata, scritta un tutt'uno con il codice? Se sì, andare avanti in quel modo. Se invece è una documentazione scritta a posteriori, per forza, mai consultata, non aggiornata con le versioni del codice (o difficilmente manutenibile essa stessa rispetto alle versioni), allora non farsi troppi problemi a non farla più anche se lo dice la "teoria".
Non esiste la metodologia migliore in assoluto e applicabile in ogni caso, ma le metodologie agili hanno dimostrato di dare risultati molto migliori e in molti casi rispetto alle metodologie tradizionali.
Quanto ai documenti non esistono, a parte documenti di configurazione dell'ambiente/spiegazione delle metodologie agili utilizzate.
La documentazione è nel codice e negli unit-test.
Da notare che nonostante questo ho iniziato a fare i miei task il giorno dopo aver ricevuto visual studio.
Non esiste la metodologia migliore in assoluto e applicabile in ogni caso, ma le metodologie agili hanno dimostrato di dare risultati molto migliori e in molti casi rispetto alle metodologie tradizionali.
Ma in quali ambiti (chiedo perché non so, non in tono polemico :D )? Web, controllo di un sistema industriale, software di un aereo, kernel di un sistema operativo?
Quanto ai documenti non esistono, a parte documenti di configurazione dell'ambiente/spiegazione delle metodologie agili utilizzate.
La documentazione è nel codice e negli unit-test.
La documentazione era solo un esempio e comunque il discorso vale lo stesso per quella che va nel codice.
La metodologia agile, come la programmazione a oggetti, ad esempio, è empiricamente più fruttifera. Ne abbiamo già discusso. Non serve una teoria dietro per intuire che spesso consente di raggiungere risultati "migliori" (in meno tempo e/o più manutenibili).
Non ci sono teoremi che lo dimostrano? No, perché non c'è nemmeno una teoria. Poco male. "it works". E noi, da buoni informatici, cerchiamo di valutare quali strumenti, anche poco "ortodossi" (non approvati da Turing, Goedel, ecc. :D), utilizzare per raggiungere i nostri obiettivi. :cool:
Beh quando si vuole mostrare che una cosa funziona empiricamente si portano dati statistici. Non ne ho visti molti in giro francamente. Anzi uno solo, che confrontava gruppi all'interno della Microsoft che usavano metodologie agili con quelli che non le usavano e il risultato era che chi le usava completava i progetti nel 30% del tempo in piu' ma con meno bugs. Il che vuol dire tutto e niente :D. In sostanza cosi' come sbaglia chi le critica senza conoscerle, cosi' non e' detto perche' funzioni per qualcuno funzioni altrettanto bene per altri. Senza contare che poi bisogna vedere il tipo di progetto..
Le macrofasi delle classiche metodologie di progetto.
La raccolta di requisiti, la stesura del contratto tipicamente di 100-200 pagine in concomitanza con la fase progettuale, poi c'e' la fase di produzione, consegna e validazione. 1 anno.
In pratica all'inizio dei tempi dell'informatica di consumo, quando si era in assenza di alternative o di passate esperienze a cui ispirarsi, si e' "provato" ad applicare alla produzione di software quelle che erano e sono tutt'ora le metodologie di progetto del settore civile o meccanico. Siamo alla meta' anni 80.
No, sono le metodologie di progetto delle grandi aziende, quelle che costruiscono centrali e ponti nel doppio degli anni e con il triplo del budget. Non c'e' da stupirsi che non funzioni neanche col software :D.
Se vai a vedere come sviluppano prodotti le aziende piu' piccole anche nostrane, noterai come tanto per il software quanto per l'hardware l'approccio e' molto piu' incrementale. Si parte da una idea iniziale si cominciano a fare i disegni, si stampano i prototipi, si vedono i difetti e come correggerli, si modificano i disegni e nel frattempo viene scritto il software per simulare le singole parti e viene man mano adattato per star dietro alle modifiche hardware o a sopperire alle sue mancanze che vengono rilevate nel corso dello sviluppo.
Poi noi le chiamiamo "modifiche incrementali" e "star in due davanti al pc" invece che Agile e pair-programming, ma penso sia la stessa cosa :D
Poi c'e' l'altra considerazione. Nelle metodologie classiche il maggior fuoco d'attenzione e' dato al progetto. Il progetto e' il centro di tutto. Piani di lavoro, milestone, Project manager che a seconda dei lavori da fare alloca operai qui e operai la'. Presunta intercambiabilita' delle risorse, etc.
In tutte le metodolgie Agile invece il punto centrale e' il singolo sviluppatore. Lui sa quello che sa fare e quello che sa fare meglio.
In alcune metodologie come lo Scrum il punto focale e' invece il gruppo di lavoro, il gruppo degli sviluppatori, ma cambia poco. Ma non si tratta di autogestione. Nel gruppo di sviluppatori deve esserci anche uno dei clienti, e partecipare a tutte le fasi di progetto.
Rilasci continui, parziali, incrementanti e funzionanti direttmente nell'ambiente di produzione, il primo dopo 1 mese, gli altri ogni 15 giorni.
Il cliente alla fine NON puo' essere scontento. E' egli stesso che disegna l'applicazione man mano che passa il tempo. E' egli stesso che decide la priorita' delle varie "Storie" (Sottopezzi di funzionalita' da aggiungere in produzione) E' egli stesso che decide le varianti da applicare, che nella peggiore delel ipotesi vengono portate in produzione entro 1 mese.
Ci sono contesti in cui e' difficile seguire questo, soprattutto quelle dove il prodotto ha senso solo se e' "completo". Una macchina per dialisi o e' completa o non funziona, ho ha tutte le funzionalita' di sicurezza o non puo' operare, ed e' difficile per il cliente valutarne le funzionalita' fintanto che il prodotto non e' completo e quindi avere un feedback non e' facile. Il progetto prosegue comunque incrementalmente, ma le variazioni avvengono piu' sulla base di altri fattori.
Altri concetti pratici essenziali sono la integrazione continua del codice e i test.
Tutti i gruppi di lavoro, ogni singolo sviluppatore, non appena ha terminato un piccolo pezzettino integra direttamente il proprio codice in quello che e' il repository centrale, il quale immediatamente compila la nuova versione del prodotto e lo rilascia in un opportuno ambiente pronto per essere testato dal gruppo QA.
Nel frattempo vengono continuamente e incessantemente eseguiti i test globali su tutti i pezzi di codice (E sulle integrazioni verso i componenti esterni), in modo tale a validare il pezzettino di codice appena rilasciato, alla ricerca di eventuali bug di regressione. La macchina di test opera continuamente per mesi e mesi, eseguendo in continuazione tutti i test ogni volta che una singola linea di codice viene rilasciata, fatto che in grossi gruppi di lavoro, magari distribuiti su tutto il globo, avviene di continuo.
In questo modo si sa che, fatto salvo che il piccolo pezzetto di codice rilasciato fosse la traduzione in linguaggio informatico di cio' che la relativa storia richiedeva, cosa che un computer non e' ancora in grado di valutare ( :) ), si potrebbe prendere il risultato appena compilato in ambiente QA e passarlo direttamente in ambiente di produzione.
E si puo' andare a dormire tranquilli la sera, sicuri che il singolo pezzo che e' stato fatto entra perfettamente nel disegno globale, che non provoca danni al tutto e che fa proprio quello che deve fare.
Again, nello stesso contesto di cui sopra non e' facile da implementare. Anche noi facciamo un sacco di test, ma la maggior parte non e' possibile farli in automatico perche' richiedono l'uso diretto dell'hardware. Alcune parti si possono simulare in software, ma ci sono comportamenti che e' impossibile o perlomeno proibitivo modellare, per cui si e' un po' meno "agili" su alcune parti del software, perche' poi le modifiche te le devi testare a mano :D
Quanto ai documenti non esistono, a parte documenti di configurazione dell'ambiente/spiegazione delle metodologie agili utilizzate.
Prova a fare un prodotto che va certificato e poi mi dici se non esistono i documenti :asd: :cry:
^TiGeRShArK^
04-04-2010, 19:11
Ma in quali ambiti (chiedo perché non so, non in tono polemico :D )? Web, controllo di un sistema industriale, software di un aereo, kernel di un sistema operativo?
La documentazione era solo un esempio e comunque il discorso vale lo stesso per quella che va nel codice.
Io personalmente l'ho utilizzata per un gioco multi-piattaforma (diamonds) e per un applicazione desktop.
Per le applicazioni web a quanto ne so è utilizzato abbastanza con RoR.
Per le applicazioni enterprise non l'ho mai utilizzata, ma credo che sia l'ambito dove potrebbe dare i maggiori risultati, vista la complessità dei problemi in quest'ambito.
^TiGeRShArK^
04-04-2010, 19:12
Prova a fare un prodotto che va certificato e poi mi dici se non esistono i documenti :asd: :cry:
per fortuna non è il mio caso. :ciapet:
cdimauro
04-04-2010, 19:55
Beh quando si vuole mostrare che una cosa funziona empiricamente si portano dati statistici.
Vero.
Non ne ho visti molti in giro francamente. Anzi uno solo, che confrontava gruppi all'interno della Microsoft che usavano metodologie agili con quelli che non le usavano e il risultato era che chi le usava completava i progetti nel 30% del tempo in piu' ma con meno bugs. Il che vuol dire tutto e niente :D.
Mi spiace che non ci siano statistiche più accurate.
Personalmente l'esperienza di Diamonds prima e di C/WPython adesso, mi portano ad affermare che la programmazione agile permette di essere più produttivi, e il codice più stabile / molto meno soggetto a bug.
Anzi, posso dirti in tutta franchezza che se CPython non si portasse dietro quell'enorme batteria di test che mi ha permesso di trovare bug rognosissimi, quasi sicuramente WPython non sarebbe mai nato come progetto, perché avrei alzato le mani moooolto tempo prima.
In sostanza cosi' come sbaglia chi le critica senza conoscerle, cosi' non e' detto perche' funzioni per qualcuno funzioni altrettanto bene per altri. Senza contare che poi bisogna vedere il tipo di progetto..
D'accordo anche su questo.
In sostanza cosi' come sbaglia chi le critica senza conoscerle, cosi' non e' detto perche' funzioni per qualcuno funzioni altrettanto bene per altri. Senza contare che poi bisogna vedere il tipo di progetto..
Mai detto il contrario.
Anzi, ho proprio detto cosi':
Ma guarda che non e' una dimostrazione, o un teorema.
E' una metodologia di gestione di progetto.
Pertanto non ha affermazioni che possano essere verificate o falsificabili.
C'e'. Esiste. Se hai un gruppo di lavoro che con questa metodologia funziona meglio di altre, lo usi e vai avanti. Se invece il gruppo di lavoro non lo riesce ad usare o e' meno efficiente che con altri metodi, allora non lo usi e vai avanti lo stesso. (Piu' lento e con piu' problemi, dico io e non solo io, peccato per voi).
tomminno
05-04-2010, 01:45
Perchè in italia non esiste proprio il concetto di continuous design e si fa vedere qualcosa al cliente solo dopo che è tutto pronto.
E grazie al cazzo che non gli va bene in quel caso.
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.
Con il continuous design è possibile aggiungere le funzionalità richieste dal sistema in sole due settimane.
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...
In quel caso è lui che utilizza le FUNZIONALITA' del sistema.
I grafici idealmente non hanno nulla a che fare con i programmatori, e i programmatori devono lavorare sulle FUNZIONALITA' del sistema, sta poi ai grafici rendere tutto sbrilluccicoso.
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!
Per pubblicare un sito web visibile a tutti ovviamente deve essere pronta anche la parte grafica.
Quindi in 2 settimane non puoi pubblicare niente.
Ma al programmatore e al cliente che parla con loro non gliene deve fregare una mazza di discutere della grafica.
Scusa ma se è quello che accade nella realtà di tutti i giorni come fai a dire che non gliene deve fregare niente?
Egli dovrà solo valutare se le funzionalità del sistema rispettano i suoi requisiti e se gli vanno bene.
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.
Peccato che da noi le cose sono strutturate *lievemente* meglio e ogni sistema è modulare e si interfaccia con gli altri.
Non c'è un singolo sistema che può impedire il funzionamento degli altri, al massimo, in caso di problemi, gli altri sistemi non potranno usare le funzionalità esposte dal sistema malfunzionante.
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.
Mi pare anche OVVIO che il sistema completo deve essere pensato con la modularità come principio base,
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.
d'altro canto è il requisito fondamentale per utilizzare una metodologia di sviluppo agile lo spezzare i problemi e le soluzioni in piccole parti per quanto possibile indipendenti tra di loro.
Lo sviluppo può anche essere indipendente, ma alla fine tutto deve essere pubblicato nello stesso momento.
L'ho già detto prima.
La compiliamo noi, tutto il gruppo, in base alle indicazioni dell'interfaccia col cliente.
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?
E ognuno di noi sa dove mettere le mani nelle parti che conosce meglio e sa come scrivere i task e come stimarli correttamente.
Più o meno è così anche da noi.
Un project manager che non ha la minima idea nè del sistema nel suo complesso nè del suo codice non potrà mai e poi mai fare una cosa del genere.
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à.
E in italia un project manager per definizione non conosce tutto il codice del sistema.
Quindi tutti i componenti del gruppo, coordinati dallo scrum master, possono agevolmente svolgere questo compito.
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.
Ma anche no. :)
Le funzioni che hai elencato sono quelle del project manager. Puoi chiamarlo come ti pare ma la sostanza è quella.
Ecco perchè questo è un lavoro che deve fare la QA con gli appositi tool e manualmente ove necessario. :)
Si infatti il reparto test serve appunto per i test di integrazione infattibili via codice.
Io ho detto che il cliente USA = UTILIZZA l'applicazione direttamente in produzione e dunque si rende conto IMMEDIATAMENTE se c'è qualcosa che non va, e con la pratica, non certo leggendo fumosi documenti e vedendo prototipi malrispondenti alle sue idee rilasciati poco prima della consegna definitiva. :)
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.
Guarda che solo tu hai parlato di USA. :)
Eh oggi ero fuso... Troppa cioccolata :)
Comunque un cliente che in DUE SETTIMANE (e non un mese) cambia idea radicalmente può voler dire solo queste cose:
1) è pazzo
2) colui che si dovrebbe interfacciare col cliente non ha la benchè minima idea di come fare il suo lavoro
3) il cliente non ha capito una mazza dato che non ha UTILIZZATO il sistema, ma ha solo visto documenti descrittivi del cappero.
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.
Il cliente DEVE cambiare idea in continuazione.
Il continuo feedback del cliente è la base delle metodologie di programmazione agili.
Ti ci voglio vedere a modificare una funzionalità dopo un mese dall'approvazione...
No, questa è una tua invenzione. :)
io ti confermo che noi ANDIAMO in produzione ogni DUE SETTIMANE. :)
E il cliente ci da i suoi feedback lavorando sull'ultima versione dell'applicazione
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...
Meno di dieci sviluppatori tra gui e server.
Noi lavoriamo con gruppi di 3/4 persone su 3/4 progetti paralleli, ogni progetto viene pubblicato in 4/6 settimane.
Infatti noi plasmiamo l'applicazione di settimana in settimana, non facciamo certo il grandissimo errore di farla tutta come la intendiamo noi per poi modificarla secondo le esigenze del cliente. :)
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.
Noi la creiamo passo-passo, seguendo continuamente i feedback del cliente e aggiungendo piccoli pezzettini alla volte.
Scusa ma credi di essere il solo a fare così?
Avevo già risposto anche prima alle tue obiezioni, ma evidentemente non VUOI capire. :)
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.
Si vede che non riesci proprio ad immaginare come funzionino certe cose abituato al modo di lavorare italiano.
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.
tomminno
05-04-2010, 01:50
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?
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'..."
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.
Mi iscrivo a questa discussione perchè è una figata :D
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? :sofico:
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... :asd:
Non prenderla come un'offesa, eh! :help:
jappilas
05-04-2010, 12:11
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
Mi iscrivo a questa discussione perchè è una figata :D
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? :sofico:
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... :asd:
Non prenderla come un'offesa, eh! :help:
:)
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.
Penso che "Tommino vs Resto del mondo XP" :D 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-hCKFMbqNMC&pg=PR6&source=gbs_selected_pages&cad=3#v=onepage&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... :asd:). Mi pare molto interessante la fine della pagina 385 e l'inizio della 386 che in estrema sintesi dice (niente copia/incolla :muro: ):
"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.
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^
05-04-2010, 19:32
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
06-04-2010, 22:10
■
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.
http://www.ambysoft.com/artwork/agileWorks.jpg
Questo e' invece basata sul numero di progetti portati a buon fine
http://www.ambysoft.com/artwork/successRate.jpg
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
http://www.ambysoft.com/artwork/comparingTechniques.jpg
Documenti e libri annessi a questi dati: http://www.agilemodeling.com/essays/proof.htm
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.
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/whyAgileWorksFeedback.html
Qualcosa in piu' su quel grafico
http://www.ambysoft.com/essays/whyAgileWorksFeedback.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^
07-04-2010, 00:24
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 :O )
:D
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/surveys/AgileAdoption2007.pdf
http://www.ambysoft.com/downloads/surveys/AgileAdoption2007.csv
http://www.ambysoft.com/downloads/surveys/AgileAdoption2007.ppt
"WPF ..." Immagino sia un lapsus :)
^TiGeRShArK^
07-04-2010, 00:33
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/surveys/AgileAdoption2007.pdf
http://www.ambysoft.com/downloads/surveys/AgileAdoption2007.csv
http://www.ambysoft.com/downloads/surveys/AgileAdoption2007.ppt
e magari visto che ci sei dimmi come va 'sto coso:
http://www.hwupgrade.it/forum/showpost.php?p=31524143&postcount=26
:p
tomminno
07-04-2010, 00:36
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^
07-04-2010, 00:38
Immagino sia un lapsus :)
no, parlava proprio del WPF che con il MVVM è il complemento perfetto dell' agile development. :p
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. :D
^TiGeRShArK^
07-04-2010, 00:46
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?
Puoi sempre rifattorizzare.
Ma se non hai scritto il codice pensando prima ai test "sò cazzi tua :O".
Rifattorizzare un codice non adeguatamente coperto dai test equivale a giocare ad una ruolette russa.
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.
Per questo puoi scrivere i mock sia a mano che con librerie che ti semplificano notevolmente il lavoro.
In moltissimi casi i test sono fattibilissimi.
E nei casi che stai considerando in questa discussione, tipici scenari enterprise a quanto ho capito, non solo sono fattibilissimi, ma anche ASSOLUTAMENTE auspicabili.
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!).
Ovvio.
Mai negato che il tempo di scrittura del codice aumenti.
Io in media sto impiegando più tempo a scrivere i test che il codice per risolvere il task.
Ma in realtà non è uno spreco è un INVESTIMENTO per il futuro.
E' un pò come la differenza tra l'affitto e il mutuo.
Con l'affitto ovviamente paghi di meno, ma alla fine non ti resta niente in mano.
Con il mutuo alla fine hai qualcosa di SOLIDO E FUNZIONALE che ti appartiene.
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.
Me lo chiedevo sempre anch'io come fare. :)
Poi dopo tante bestemmie, frustrate e ditine spezzate con fek per diamonds, finalmente ho imparato. :)
P.S. A proposito.. che fine hanno fatto tutti i post nella sezione DIAMONDS????!?!??!?!?
:eek::eek::eek::eek::eek::eek::eek::eek:
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?
Direi che e' molto difficile che 2 approcci alla produzione software possano portare ad avere lo stesso codice.
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.
Ovviamente i test non sono di "Prodotto completo", ma vengono testate le singole unita'. Alcuni pattern permettono la scrittura di test piu' efficientemente che altri. P.Es. per le GUI e' consigliato MVC (Model-View-Controller) o MVVM (Model-View-ViewModel), per i quali se correttamente applicati, la logica puo' essere completamente testata.
Ci sono anche tecniche che permettono la costruzione di unit test in assenza dei contesti esterni. Queste tecniche sono conosciute con il termine di Mock, e ci sono parecchie librerie che possono aiutare a creare questi Mock object.
Il risultato dei test sara' qualcosa come "Se il contesto esterno si comportera' come io penso si debba comportare, allora se questo test viene passato significa che il codice scritto funzionera' anche con il servizio esterno".
E ci sono test chiamati di Integrazione, per verificare infine che il mock object da me creato sia corrispondente al contesto esterno relativo, per i quali ho pero' bisogno della controparte reale del servizio (puntando tipicamente alle relative macchine di QA)
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!).
Il tempo per la scrittura del codice alla fine diminuisce perche' si evitano i tempi morti e quelli per la integrazione, per la correzione di bachi postumi.
Come dicevo prima, all'inizio lo sviluppo e' piu' lento, ma man mano che si va avanti, aggiungere o modificare pezzi risulta essere piu' veloce che con tecniche tradizionali, compreso il tempo per la scrittura dei test.
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.
Ho colleghi che lo fanno. Non sono tanti ma ci sono.
Scrivere il test quando e' stato rilevato un bug invece e' piu' semplice, e davvero aiuta nel trovare la soluzione.
Es. recente: Quando clicco su quel pulsante di qulla finestra, dovrebbe aprirsi una form che chiede un elenco di ruoli dal server di autenticazione, li presenta a video.
Associato a ciascun ruolo c'e' una checkbox. L'utente puo' scegliere di abilitare/disabilitare tanti ruoli quanti vuole.
Alla pressione del tasto OK questa nuova form deve chiudersi, e il nuovo elenco di ruoli dovra' servire all'applicazione ogni volta che si faranno chiamate per qualsiasi altro servizio.
E' stato verificato da QA che un utente sembra poter cambiare gli ruoli, ma tali ruoli non sembrano essere usati dall'applicazione.
Creo un Mock Object relativo al servizio del server di autenticazione. PEr poterlo fare e' necessario che i metodi di ciascun servizio siano esposti tramite interfaccia. Guarda caso WCF espone i metodi di ciascun servizio traminte Interface.
Creo uno Stub Object relativo al servizio del server di autenticazione. In realta' sara' gia' stato creato per qualche altro test.(La differenza tra Mock e Stub la tralascio. Per iniziare, uno Stub simula il funzionamento di un servizio esterno, un Mock invece serve per controllare che alcuni metodi esterni al test siano stati chiamati. Tali metodi possono essere remote procedure call di un servizio esterno, oppure anche metodi di oggetti interni al progetto ma da non testare con questo test in questione)
Inizio con il simulare la pressione del tasto della finestra, andando a il metodo Execute del Comando del ViewModel della finestra che e' legato al pulsante in questione. (Command Pattern)
Vado a verificare tramite il Mock Object che il corretto metodo del servizio remoto sia stato richiamato
Verifico che il Factory relativo al AbstractFactory pattern impiegato dal viewModel per la creazione di nuove finestre abbia creato una nuova finestra del tipo atteso, e ne vado a prendere il ViewModel relativo.
Ottengo il risultato fake del servizio di autenticazione tramite lo Stub, che sara' anche cio' che e' stato passato al ViewModel di questa nuova finestra.
Il ViewModel di questa nuova finestra esporra' probabilmente un elenco di ruoli. Vado a verificare che tale elenco contenga gli stessi elementi restituiti dallo Stub.
Vado a simulare la scelta di alcuni checkbox a caso, agendo sulla relativa proprieta' di ciascun ruolo, tenendo a mente quale e' stata la mia scelta.
Vado a simulare la pressione del tasto OK, richiamando il comando Execute del Command relativo al pulsante di OK, Command residente sul viewmodel di questa nuova finestra.
etc.
Lancio il test e verifico che effettivamente non capita quanto dovrebbe capitare, ma capita invece quanto QA ha dichiarato.
Quindi inizio a cercare il baco, e quando lo trovo rilancio il mio test, e se funziona sono a posto.
Verifico che il mio cambiamento non abbia rotto niente rilanciando tutti gli altri test, e in caso positivo committo sul repository del codice.
(Il quale, non fidandosi, ricompilera' tutto e rilancera' di nuovo tutti i test per conto suo. In caso di errore ci sara' una notifica sui desktop di tutti gli sviluppatori)
Cosa resta fuori da questo test?
Relativamente alla GUI resta fuori il binding tra ciascun ViewModel e la relativa finestra. Se i binding sono corretti allora abbiamo effettivamente simulato un tutto quanto richiesto.
Relativamente al servizio, dobbiamo verificare che il Mock Object e lo Stub relativi al servizio esterno si comportano effettivamente come il servizio esterno stesso.
Abbiamo probabilmente utilizzato uno Stub gia' creato in precedenza per qualche altro test. Altrimenti dobbiamo scrivere anche il test di integrazione per verificarlo. I test di integrazione vengono lanciati meno spesso degli Unit test, proprio perche' capita meno sovente che gli Stub e i Mock vengano cambiati. Essi fanno veramente uso dei servizi esterni, tipicamente nel relativo ambiente di QA.
Nelle 2 settimane di tempo si fa rientrare cio' che si riesce a far rientrare, a seconda del numero di sviluppatori presenti in quel tempo.
C'e' l'elenco delle storie ancora da risolvere, proiritizzate dal cliente a seconda della importanza che lui assegna, tra le quali ci sono anche le storie infrastrutturali scritte dal gruppo di sviluppo stesso (e prioritizzate anch'esse)
Nella metodologia Agile chiamata SCRUM all'inizio delle 2 settimane si pesano (si gioca a poker) e si concordano quali sono le storie che devono essere risolte dal gruppo di lavoro, assegnandole a ciascuna risorsa.
Nella metodologia Agile chiamanta Kanban invece le storie sono considerate una pila, e ogni volta che uno sviluppatore termina una storia va a prendere la prima disponbile e la risolve.
Al termine delle 2 settimane il tempo scade e si pubblica cosa c'e'.
Detto in soldoni, ma in realta' ci sono dei limiti al tipo di storie che possono essere scodate, che dipendono anche dal carico che QA puo' risolvere.
Quando ci sono tempi morti vengono scritti i test di copertura dei metodi scoperti a piu' alta complessita' ciclomatica.
tomminno
07-04-2010, 09:21
Puoi sempre rifattorizzare.
Ma se non hai scritto il codice pensando prima ai test "sò cazzi tua :O".
Rifattorizzare un codice non adeguatamente coperto dai test equivale a giocare ad una ruolette russa.
Boh tanto i test li devi comunque riscrivere. Se rifattorizzi cambi il codice quindi cambiano anche i test.
Per questo puoi scrivere i mock sia a mano che con librerie che ti semplificano notevolmente il lavoro.
Con i mock testi sempre il codice, non il contesto in cui girerà. Quando esegui i test il codice gira in un ambiente che non è quello a cui è destinato.
Codice perfettamente funzionante ai test può in realtà risultare buggato.
In moltissimi casi i test sono fattibilissimi.
E nei casi che stai considerando in questa discussione, tipici scenari enterprise a quanto ho capito, non solo sono fattibilissimi, ma anche ASSOLUTAMENTE auspicabili.
E come si fanno? Io più che i tradizionali test con NUnit e TypeMock non riesco a fare.
Ad esempio mi è capitato ieri un codice perfettamente funzionante che passava tutti i test ma nel contesto in cui girava (un sito web in Sharepoint) dava errore (dovuto al caching dei dati di Sharepoint).
Risultato ho dovuto modificare il codice per risolvere il problema. Ma i test sul codice erano corretti ed erano ok, solo che occorreva qualche linea di codice in più, ovviamente non testabile, che andasse ad interagire con il sistema, in tal caso il codice nel contesto reale di esecuzione non forniva più errore ma mostrava il comportamento atteso e previsto dai test.
tomminno
07-04-2010, 10:35
Direi che e' molto difficile che 2 approcci alla produzione software possano portare ad avere lo stesso codice.
Non capisco perchè no. La stessa persona davanti allo stesso problema potrebbe benissimo scrivere lo stesso codice.
Ci sono anche tecniche che permettono la costruzione di unit test in assenza dei contesti esterni. Queste tecniche sono conosciute con il termine di Mock, e ci sono parecchie librerie che possono aiutare a creare questi Mock object.
Non riuscirei mai a scrivere un Mock che mi simuli il contesto di esecuzione del processo w3wp di IIS e quindi mi consenta di testare il codice in un contesto di esecuzione simile a quello reale.
Capita di avere l'ok in NUnit o CC.NET e poi l'errore su IIS. Cosa cambia? Il contesto.
Il risultato dei test sara' qualcosa come "Se il contesto esterno si comportera' come io penso si debba comportare, allora se questo test viene passato significa che il codice scritto funzionera' anche con il servizio esterno".
Assunzione forte che ho verificato personalmente non rivelarsi vera.
Magari scopri sempre qualcosa di nuovo sul contesto esterno, magari ti manca qualche interazione che non sai di dover fare in assenza della quale il tuo codice in realtà non funziona.
Un caso banale banale di un codice che cerca di accedere al registro di windows sulla chiave CurrentUser. Scrivi tutti i test che ti pare, ti danno tutti ok perchè il codice funziona. Poi il tuo codice viene eseguito in un servizio e in realtà scopri che non funziona. E' un bug del software c'è poco da fare.
Ma non ne hai segnalazione nei test.
Altri casi come path di esecuzione differenti portano, sempre nello stesso contesto, alla non esistenza di alcune variabili di sistema.
Ad esempio sempre quella schifezza di Sharepoint: un codice può risultare perfettamente funzionante se richiamato tramite interfaccia web, ma non funzionare se richiamato da un workflow, perchè mancano i presupposti del sistema affinchè quel codice funzioni correttamente (permessi piuttosto che variabili non esistenti).
Tutto concorre a fare bug nell'applicazione.
Il tempo per la scrittura del codice alla fine diminuisce perche' si evitano i tempi morti e quelli per la integrazione, per la correzione di bachi postumi.
Quali sarebbero i tempi morti?
Verifico che il mio cambiamento non abbia rotto niente rilanciando tutti gli altri test, e in caso positivo committo sul repository del codice.
(Il quale, non fidandosi, ricompilera' tutto e rilancera' di nuovo tutti i test per conto suo. In caso di errore ci sara' una notifica sui desktop di tutti gli sviluppatori)
La notifica automatica a tutti gli sviluppatori mi manca. Abbiamo vari plugin che avvisano delle modifiche ma niente di automatico da parte del server se non email di segnalazione.
Cosa usate per il continous integration? Noi abbiamo CruiseControl .NET.
Nelle 2 settimane di tempo si fa rientrare cio' che si riesce a far rientrare, a seconda del numero di sviluppatori presenti in quel tempo.
Nel mio caso i progetti perdono priorità ad ogni rilascio quindi i tempi generalmente si dilatano: il primo dopo 6 settimane il secondo generalmente dopo 4 per eventuali correzioni, il terzo è capace anche dopo 6 mesi, perchè le priorità sono diventate altre (già dopo il primo rilascio il team dedicato al secondo spesso viene dimezzato, per essere riallocato sui nuovi progetti) e il rapporto costo/benefici di un terzo o successivo rilascio è considerato negativamente.
Direi tutto fuorchè sviluppo agile, ma dopotutto sceglie chi paga, ovvero il cliente.
Non capisco perchè no. La stessa persona davanti allo stesso problema potrebbe benissimo scrivere lo stesso codice.
difficile che le stesse persone, ma interagenti su un codice in modo diverso, arrivino a dare lo stesso risultato.
Ma tanto e' aria fritta, un po' come se cercassi di convincermi che per risolvere un problema esiste un solo codice ottimale.
Se hai una vaga idea di come fare a dimostrarlo, sei sulla buona strada per dimostrare la riducibilita' dei problemi NP-Completi.
Non riuscirei mai a scrivere un Mock che mi simuli il contesto di esecuzione del processo w3wp di IIS e quindi mi consenta di testare il codice in un contesto di esecuzione simile a quello reale.
Capita di avere l'ok in NUnit o CC.NET e poi l'errore su IIS. Cosa cambia? Il contesto.
Assunzione forte che ho verificato personalmente non rivelarsi vera.
Magari scopri sempre qualcosa di nuovo sul contesto esterno, magari ti manca qualche interazione che non sai di dover fare in assenza della quale il tuo codice in realtà non funziona.
Ogni test ha il suo scopo, preciso e limitato.
Costruire uno Stub per un web server e' abbastanza semplice, e farai uso di quello.
Altri sono i test di integrazione. Puoi testare limitatamente "quanto" hai capito del servizio esterno in un test specifico. Un test come questo avrebbe magari tirato fuori il bug sulla cache di Sharepoint.
Nota anche che non e' tuo scopo testare le funzionalita' di terze parti, ma solo l'integrazione, ovvero solo quanto da te fatto.
Un caso banale banale di un codice che cerca di accedere al registro di windows sulla chiave CurrentUser. Scrivi tutti i test che ti pare, ti danno tutti ok perchè il codice funziona. Poi il tuo codice viene eseguito in un servizio e in realtà scopri che non funziona. E' un bug del software c'è poco da fare.
Ma non ne hai segnalazione nei test.
Questo e' un apporccio sbagliato per un test.
Quando testi il tuo codice non dovrai fare accesso al registro di Windows, ma dovrai itnerfacciarlo ad uno Stub e magari anche un Mock del registro di Windows, che restituisce risultati ben precisi utilizzati per validare quel codice.
Questo Mock, se ben fatto, restituira' valori ben precisi per il CurrentUser.
Un altro test (integrazione) invece servira' per verificare quanto hai capito del registro di Windows, e cerchera' magari di leggere e scrivere delle chiavi.
La notifica automatica a tutti gli sviluppatori mi manca. Abbiamo vari plugin che avvisano delle modifiche ma niente di automatico da parte del server se non email di segnalazione.
Cosa usate per il continous integration? Noi abbiamo CruiseControl .NET.
Usiamo TeamCity e il suo plugin per Visual Studio, con compresa la notify bar per le notifiche di cui sopra.
Comunque ritengo vhe la programmazione di SharePoint sia piu' simile ad un "Configurare" un tool di terze parti piuttosto che uno "Sviluppare" software. Stessa cosa direi per monoliti come SAP.
Ovvio che immersi in un contesto come quello e' difficile fare qualunque cosa, e semplicemente ci si fida del prodotto e di quanto si ha capito.
Concluderei con una considerazione.
Ovviamente quanto qui esposto non serve per te, e ne tu pensavi oramai piu' che sarebbe mai potuto servirti.
Lo sto esponendo per eventuali altri lettori che non si siano ancora addormentati.
Se vai a leggere uno dei documenti linkati sopra, noterai un altro grafico, sul quale si puo' notare la natura media dei detrattori dell'Agile programming.
Essi sono nella stragrande maggioranza dei casi persone che non l'hanno ancora mai provato (e quindi poco attendibili nelle critiche).
Quando inoltre fanno piu' di 3 domande, non lo fanno allo scopo di capire se e' una metodolgia che puo' loro servire, ma piuttosto come critica gratuita, e fanno parte di organizzazioni che molto probabilmente non lo adotteranno mai.
E tu le 3 domande le hai gia' fatte... :)
tomminno
07-04-2010, 12:21
Questo e' un apporccio sbagliato per un test.
Quando testi il tuo codice non dovrai fare accesso al registro di Windows, ma dovrai itnerfacciarlo ad uno Stub e magari anche un Mock del registro di Windows, che restituisce risultati ben precisi utilizzati per validare quel codice.
Questo Mock, se ben fatto, restituira' valori ben precisi per il CurrentUser.
Un altro test (integrazione) invece servira' per verificare quanto hai capito del registro di Windows, e cerchera' magari di leggere e scrivere delle chiavi.
Sta di fatto che il programma reale poi non funziona ugualmente anche se hai fatto tutti i test con e senza Mock verso il registro.
Il programma ha un bug indipendentemente dal fatto che si comporti come previsto nei test (ovvero il test di mancato accesso al registro).
Poichè un servizio non può accedere al CurrentUser sei obbligato a cambiare il codice ed accedere a Users, ma questo non significa che il vecchio codice fosse sbagliato in sè, è il contesto che lo rende sbagliato. Ma i test questo non te lo dicono.
Questo caso è ovviamente solo un esempio, mi è capitato tempo fa che un collega riutilizzasse codice esistente per il suo nuovo servizio, i test erano tutti ok, come provavi il codice svincolato dal servizio tutto funzionava perfettamente, ma una volta inserito nel reale contesto di esecuzione non funzionava...
Comunque ritengo vhe la programmazione di SharePoint sia piu' simile ad un "Configurare" un tool di terze parti piuttosto che uno "Sviluppare" software. Stessa cosa direi per monoliti come SAP.
Finchè qualcuno non si mette in testa di fare un sito "enterprise" utilizzando Sharepoint come base...
A tutti i problemi di progetto sollevati (numero massimo di record globali gestibili, mancanza di transazionalità, ecc) il cliente ha risposto che va bene così perchè il vantaggio dell'utilizzo di dati destrutturati è stato considerato prevalente rispetto ai problemi evidenziati. Ma è ovvio che poi una volta in produzione tutto questo risulterà un grave handicap, ma il cliente rifiuta di prendere atto di questo. Quando ci sbatterà il muso saranno dolori perchè dovremo trovare soluzioni a problemi architetturali in tempi rapidi.
Programmare all'interno di Sharepoint è una rogna allucinante. Possibilità di debug pari a 0, possibilità che il codice smetta di funzionare da un momento all'altro altissima (basta che qualche utente modifichi qualche impostazione e il codice sottostante sicuramente smetterà di funzionare, tutto già previsto anche nei test). Possibilità di eseguire i test dentro Sharepoint praticamente nulla, ovvero io vedrò sempre verde anche quando niente funzionerà più.
Se vai a leggere uno dei documenti linkati sopra, noterai un altro grafico, sul quale si puo' notare la natura media dei detrattori dell'Agile programming.
Essi sono nella stragrande maggioranza dei casi persone che non l'hanno ancora mai provato (e quindi poco attendibili nelle critiche).
Quando inoltre fanno piu' di 3 domande, non lo fanno allo scopo di capire se e' una metodolgia che puo' loro servire, ma piuttosto come critica gratuita, e fanno parte di organizzazioni che molto probabilmente non lo adotteranno mai.
E tu le 3 domande le hai gia' fatte... :)
Ci sono delle pratiche dell'agile programming che nel mio contesto di lavoro non sono assolutamente applicabili (su tutti pubblicare in produzione, il rischio di fare danni costosi da rimediare sarebbe troppo alto) e ci sono assunti che sempre nel mio contesto non risultano veri (il cliente non si accorge subito degli errori).
Infine le iterazioni: le priorità dei progetti cambiano molto velocemente, difficilmente un progetto arriva a 3 pubblicazioni. Dopo 2 è già concluso (3 mesi al massimo, non si parla comunque di tempi lunghi).
Oltretutto i miei rilasci sono spesso condizionati a rilasci contemporanei da parte di aziende esterne (oppure legati a campagne di marketing), non potrei mai modificare il sistema interno senza che anche i sistemi esterni siano aggiornati.
Insomma mi ritrovo con troppi vincoli per addentrarmi completamente nello sviluppo agile, di cui fondamentalmente ho adottato soltanto i test sul codice (e non credo nemmeno che si possa definire Test Driven, visto che i test vengono scritti dopo il codice).
zakmckraken
07-04-2010, 16:03
Ciao a tutti!
Ma..una domanda, se uno lavora in un progetto in cui sono coinvolti 6 gruppi da una ventina di persone, in 4 localita'diverse che devono lavorare su sei moduli di una applicazione enterprise. Moduli che richiedono accesso a WebServices esterni, code JMS, interfacce web complesse (100/150 forms), reportistica su pdf/excel, tutto in multilingua, telecamere e sensori, su commessa statale quindi con un capitolato.
Io vedrei sinceramente piu'realistico un'approccio tipo UP piu'che uno agile, solo definire le interfacce diventa un delirio (premetto che parlo di un progetto reale ed in corso di completamento) !! Oltre che i clienti tipicamente vogliono sapere quanto tempo ci vorra'e quanto spendera'per il progetto, finche si parla di un sito web o di una applicazione medio piccola posso capire (penso ad un post qualche pagina fa che diceva appunto questo) ma un coso tipo quello descritto sopra non puo'essere non deterministico (imho).
Potrei essere daccordo a sviluppare secondo metodologie agili le sottoparti di cui sono composti i singoli moduli ma non senza una analisi corposa e precisa di interfacce interazioni e use cases su tutto il progetto.
Ripeto, tutto imho, intanto sto cercando di capire meglio il tutto...
Esattamente in che senso? nel senso: "esattamente, quel grafico é una gran cavolata, non é il risultato di una statistica ma una curva disegnata appositamente per esporre un concetto opinabile in quanto molto variabile da un caso all'altro."
Cosa itendi per "senza riscontro statistico"? che sono un sacco di belle teorie non verificate ne' formalmente ne' empiricamente. all'inizio della pagina l'autore dice che queste teorie vengono soltanto dalla sua esperienza e da quella di migliaia di altre fantomatiche persone: One of the great debates raging within the IT industry is whether or not agile software development techniques work. My experience, and the experience of thousands of others, is that they do. dice che é soltanto la sua opinione: One of several reasons why agile techniques are so effective, in my opinion, is that they reduce the feedback cycle between the generation of an idea (perhaps a requirement or a design strategy) and the realization of that idea. [...] In this article I explore this idea in detail.
Per dichiarare determinate percentuali come 72%, 19% etc. avranno pure dei dati sotto mano immagino. ecco, sarei stato felice di leggerli nella pagina che mi hai linkato, nella quale non vedo 72, non vedo 19 e non vedo neanche eccetera.
ad ogni modo, tornando al mio argomento iniziale, ci tenevo a precisare che quel grafico era una fesseria perché nella discussione si é detto che quando si osserva qualcosa empiricamente bisogna riportare i dati a testimoniarlo (e giá tocca fidarsi che i dati siano reali e onesti) e i tre grafici che sconquassano il layout della pagina precedente sono i dati che tu hai riportato, ma va precisato che l'ultimo dei tre non raffigura dei dati raccolti, é solo un disegno creato ad hoc per esporre un concetto che a mio dire resta molto opinabile finché qualcuno non lo supporta con dei dati veri e onesti. tutto qui.
Ciao a tutti!
Ma..una domanda, se uno lavora in un progetto in cui sono coinvolti 6 gruppi da una ventina di persone, in 4 localita'diverse che devono lavorare su sei moduli di una applicazione enterprise. Moduli che richiedono accesso a WebServices esterni, code JMS, interfacce web complesse (100/150 forms), reportistica su pdf/excel, tutto in multilingua, telecamere e sensori, su commessa statale quindi con un capitolato.
Io vedrei sinceramente piu'realistico un'approccio tipo UP piu'che uno agile, solo definire le interfacce diventa un delirio (premetto che parlo di un progetto reale ed in corso di completamento) !! Oltre che i clienti tipicamente vogliono sapere quanto tempo ci vorra'e quanto spendera'per il progetto, finche si parla di un sito web o di una applicazione medio piccola posso capire (penso ad un post qualche pagina fa che diceva appunto questo) ma un coso tipo quello descritto sopra non puo'essere non deterministico (imho).
Potrei essere daccordo a sviluppare secondo metodologie agili le sottoparti di cui sono composti i singoli moduli ma non senza una analisi corposa e precisa di interfacce interazioni e use cases su tutto il progetto.
Ripeto, tutto imho, intanto sto cercando di capire meglio il tutto...
Sembra uno di quei progetti da me descritti all'inizio, come esempio di progetti che giungono prima o poi a problemi che possono minare l'intera fattibilita'.
Giunti alla fine mi dirai quanto tempo si spendera' per l'integrazione finale di tutte le parti, nonostante le interfaccie e interazioni siano state ben decise a priori.
Sempre che il cliente non cambi idea alla fine su qualche funzionalita' che magari va ad intaccare proprio il substrato comune, la prima volta che gli farete vedere qualcosa.
L'approccio Agile in questi casi suggerisce di iniziare con un piccolo gruppo di lavoro a creare le interfaccie e tutta la sovrastruttura. Ma non solo a studiare. Proprio a scrivere e creare il codice relativo a questa sovrastruttura.
Poi in seguito si possono aggiungere gli altri seguenti gruppi di lavoro, ognuno a seguire un modulo specifico, che potranno scrivere e testare le loro parti direttamente con quello che sara' l'architettura finale, mostrando di volta in volta al cliente.
Comunque il progetto che sto seguendo ora non e' cosi' grande in quanto a numero di persone coinvolte, ma e' comunque complesso in quanto a moduli. un modulo principale (le tue interfaccie di cui sopra) e 4 domini seguiti da diversi gruppi di sviluppo, ciascuno con sviluppatori GUI e ServerSide, e l'approccio seguito e' stato proprio questo.
Ah, il fatto che nella metodologia agile si stimoli parecchio il pair programming e il peer reviewing rende anche il gruppo di lavoro stesso resistente alle persone che se ne vanno. A meno che non se ne vadano tutte insieme c'e' sempre il giusto livello di competenza nel gruppo.
Sviluppare in 2 davanti allo stesso monitor da soddisfazioni incredibili. E' un ottimo mezzo di passaggio di conoscenze tra piu' esperti a meno esperti, un modo per condividere trucchi, evitare errori banali e parere mio si sviluppa piu' in fretta che in 2 macchine separatamente.
nel senso: "esattamente, quel grafico é una gran cavolata, non é il risultato di una statistica ma una curva disegnata appositamente per esporre un concetto opinabile in quanto molto variabile da un caso all'altro."
Hai letto da qualche parte che quel grafico in particolare e' una statistica?
Hai mai visto il grafico risultato da una statistica, pensi che una parabola perfetta possa essere uno di questi?
Pensi che a qualcun altro all'infuori di te possa essere venuto in mente che quello e' il grafico di una vera raccolta dati?
Riesci a trovare grossi errori nella stima dei tempi riportati?
Ritieni spesso che quanto riportato da altri sia "fesseria"?
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. mi sento chiamato in causa visto che sono l'unico ad aver usato quell'espressione mi pare.
permettimi di obiettare che, non avendo aperto la pagina, non hai neanche idea di quali teorie si stia parlando. é troppo scontata come obiezione? :stordita:
...per le GUI e' consigliato MVC (Model-View-Controller) o MVVM (Model-View-ViewModel)...
Per quanto riguarda la metodologia Agile, la trovo molto interessante e, sebbene la scrittura dei test possa sembrare tediosa, consente un'elevata manutenibilità del codice (a lungo andare fa la differenza).
Per quanto concerne il testing di applicativi web, quali tool/framework utilizzate di solito (per l'interfaccia, test interattivi, etc.)? HttpUnit o simili??
Per quanto riguarda la metodologia Agile, la trovo molto interessante e, sebbene la scrittura dei test possa sembrare tediosa, consente un'elevata manutenibilità del codice (a lungo andare fa la differenza).
Per quanto concerne il testing di applicativi web, quali tool/framework utilizzate di solito (per l'interfaccia, test interattivi, etc.)? HttpUnit o simili??
Viene applicato MVVM anche per le interfaccie web, e viene testata solo ma tutta la logica (Il ViewModel) negli unit test scritti dagli sviluppatori.
Per il test delle form invece si demanda a QA, che di solito per l'automazione dei test puramente GUI usa framework come QTP.
La QA di un altro gruppo di lavoro usa un framework chiamato SAHI, che e' open source.
Uno dei miei collaboratori QA mi dice ora di avere usato in passato un altro tool chiamato Selenium per automatizzare i test per web.
Hai letto da qualche parte che quel grafico in particolare e' una statistica? prendi un bel respiro e rilassati: non é un problema che nessuno l'abbia detto.
Hai mai visto il grafico risultato da una statistica, pensi che una parabola perfetta possa essere uno di questi? e secondo te io cosa stavo obiettando allora?
Pensi che a qualcun altro all'infuori di te possa essere venuto in mente che quello e' il grafico di una vera raccolta dati? il mio discorso é un altro: con un disegno che espone un concetto opinabile non supportato da una verifica onestaci facciamo poco. chi mi dice che quel disegno rappresenti la realtá delle cose?
Riesci a trovare grossi errori nella stima dei tempi riportati? non ho abbastanza persone, ne' risorse economiche ne' motivazioni per verificare raccogliendo dati, e a quanto pare non ne aveva neanche chi ha fatto il disegno. tuttavia non significa che non ci possano essere grossi errori.
Ritieni spesso che quanto riportato da altri sia "fesseria"? é il segreto del successo.
P.S. A proposito.. che fine hanno fatto tutti i post nella sezione DIAMONDS????!?!??!?!?
:eek::eek::eek::eek::eek::eek::eek::eek: mi dispiace dirtelo ma quel progetto é morto: era un progetto agile :asd:
In sostanza avevi capito poco, non hai i mezzi per verificare e ritieni che il parere altri sia a priori una fesseria, motivandolo come segreto di successo.
Vabbe'. Buon proseguimento.
mi dispiace dirtelo ma quel progetto é morto: era un progetto agile
Piu' che altro mi sembra di avere capito che fosse un progetto open-source e non pagato. Non molti sono disposti a lavorare con continuita', solo per la causa.
In sostanza avevi capito poco, ah si? e spiegami tu allora, mi sembra troppo facile uscirsene con "buon proseguimento".
ma ho idea che non mi spiegherai un bel nulla, vero? chissá perché.
Piu' che altro mi sembra di avere capito che fosse un progetto open-source e non pagato. non era solo open-source, era addirittura public domain: chiunque puó farcene quello che gli pare, ma io francamente non ho trovato molto semplice accedere a sti sorgenti.
^TiGeRShArK^
07-04-2010, 17:42
Sta di fatto che il programma reale poi non funziona ugualmente anche se hai fatto tutti i test con e senza Mock verso il registro.
Il programma ha un bug indipendentemente dal fatto che si comporti come previsto nei test (ovvero il test di mancato accesso al registro).
Poichè un servizio non può accedere al CurrentUser sei obbligato a cambiare il codice ed accedere a Users, ma questo non significa che il vecchio codice fosse sbagliato in sè, è il contesto che lo rende sbagliato. Ma i test questo non te lo dicono.
:mbe:
E per quale motivo? :mbe:
Basta dare i privilegi di utente locale al servizio e può fare quello che vuole su currentUser utilizzando le credenziali dell'utente inserito.
Quello che dici vale per i network e i local system services.
Quindi il problema non è un problema dei test ma dalla tua scarsa conoscenza del dominio che ti ha fatto scrivere un mock errato dato che il mock corretto non permette ai servizi di sistema e di rete di accedere alle chiavi del current user dato che utilizza un account legato alla macchina e non all'utente.
Questo caso è ovviamente solo un esempio, mi è capitato tempo fa che un collega riutilizzasse codice esistente per il suo nuovo servizio, i test erano tutti ok, come provavi il codice svincolato dal servizio tutto funzionava perfettamente, ma una volta inserito nel reale contesto di esecuzione non funzionava...
Anche in questo caso bisogna costruire il mock in maniera corretta, se i test non passano vuol dire che non si è capito come funziona il sistema con cui interfacciarsi ed il mock è errato.
Finchè qualcuno non si mette in testa di fare un sito "enterprise" utilizzando Sharepoint come base...
A tutti i problemi di progetto sollevati (numero massimo di record globali gestibili, mancanza di transazionalità, ecc) il cliente ha risposto che va bene così perchè il vantaggio dell'utilizzo di dati destrutturati è stato considerato prevalente rispetto ai problemi evidenziati. Ma è ovvio che poi una volta in produzione tutto questo risulterà un grave handicap, ma il cliente rifiuta di prendere atto di questo. Quando ci sbatterà il muso saranno dolori perchè dovremo trovare soluzioni a problemi architetturali in tempi rapidi.
Programmare all'interno di Sharepoint è una rogna allucinante. Possibilità di debug pari a 0, possibilità che il codice smetta di funzionare da un momento all'altro altissima (basta che qualche utente modifichi qualche impostazione e il codice sottostante sicuramente smetterà di funzionare, tutto già previsto anche nei test). Possibilità di eseguire i test dentro Sharepoint praticamente nulla, ovvero io vedrò sempre verde anche quando niente funzionerà più.
Questo è purtroppo abbastanza vero.
L'ambiente + orrendo su cui ho lavorato è proprio sharepoint.
Però in realtà puoi debuggare se il problema è nel codice che hai scritto tu, non puoi fare niente se per caso ti scompare la webpart che è stata correttamente deployata e ti dice che non la trova sparandoti errori del cazzo nei log. :muro:
L'unico modo che avevo per risolverla, dopo aver creduto di non aver capito una mazza di come effettuare il dispose di SPWeb e di SPSite era fare un clean, fare un retract della soluzione, uscire da visual studio, rientrare ribuildare e ri-deployare. :muro:
Ma questo non ha nulla a che fare col codice.
Il mio codice per le webpart era praticamente PROCEDURALE dato che per fortuna non sono di una complessità elevata e avevo paura di qualche strano comportamento (tipo col redirect che non funziona a seconda del punto del codice in cui lo metti e della tecnica utilizzata... bisogna provare tute le combinazioni possibili per farlo andare. :muro: ).
Ecco, questa è una situazione in cui mi concentrerei sui santi da invocare piuttosto che sulla programmazione.
Mi è capitato di scrivere codice davvero banale, roba da 10 minuti, e di metterci due giorni a farlo funzionare.
La cosa buona è che almeno pagavano bene e ora ho finito di metterci mano finalmente. :)
Ci sono delle pratiche dell'agile programming che nel mio contesto di lavoro non sono assolutamente applicabili (su tutti pubblicare in produzione, il rischio di fare danni costosi da rimediare sarebbe troppo alto) e ci sono assunti che sempre nel mio contesto non risultano veri (il cliente non si accorge subito degli errori).
Infine le iterazioni: le priorità dei progetti cambiano molto velocemente, difficilmente un progetto arriva a 3 pubblicazioni. Dopo 2 è già concluso (3 mesi al massimo, non si parla comunque di tempi lunghi).
Oltretutto i miei rilasci sono spesso condizionati a rilasci contemporanei da parte di aziende esterne (oppure legati a campagne di marketing), non potrei mai modificare il sistema interno senza che anche i sistemi esterni siano aggiornati.
Insomma mi ritrovo con troppi vincoli per addentrarmi completamente nello sviluppo agile, di cui fondamentalmente ho adottato soltanto i test sul codice (e non credo nemmeno che si possa definire Test Driven, visto che i test vengono scritti dopo il codice).
Diciamo che il problema è che con sharepoint la parte di programmazione è marginale come dicevo prima.
^TiGeRShArK^
07-04-2010, 17:44
mi dispiace dirtelo ma quel progetto é morto: era un progetto agile :asd:
A parte che è morto per mancanza di tempo di noi tutti che ricordo lavoravamo normalmente durante il giorno e avevamo magari anche altri progetti da seguire.....
Ma sono stati proprio CANCELLATI i post. :mbe:
banryu79
07-04-2010, 17:49
Ma sono stati proprio CANCELLATI i post. :mbe:
Peccato perchè ogni tanto andavo a consultare quel materiale a scopo di studio e per curiosità, sia per vedere come erano state concepite le storie che per quanto riguardava la parte più strettamente inerente le pratiche di TDD.
@GugoXX: grazie per le esaurienti informazioni e spiegazioni; per me sono state molto interessanti. Il pair-programming mi piacerebbe molto provarlo un giorno.
Stare in due davanti al pc a programmare è una cosa che facevo spessimo all'università per i progetti. Non che qualcuno ce lo avesse detto, nè per aderire a chissà quale tecnica di ingegneria del software avanzata :asd: , ma semplicemente perché o si avevano pochi pc, o c'era uno più avanti dell'altro nella compresione di certi concetti. Imho la produttività a 4 mani supera di gran lunga quella a 2:
- chi scrive non può tenere sotto controllo molte cose (l'erroruccio, la virgola, il copia incolla fatto male viene fatto notare da chi non scrive);
- un intoppo per quanto banale di uno dei due viene superato con l'aiuto dell'altro; ragionare insieme ad un'altra persona (anche se la disparità di consocenze è notevole) permette di conseguire risultati superiori al singolo pure se skillatissimo;
- un periodo di calo di concentrazione dell'uno non porta ad aprire subito Facebook o venire qui a filosofeggiare :fiufiu: , pure se non si ha affianco il capo con la frusta;
- se la coppia è assortita bene (basta poco) ognuno sopperisce alle mancanze dell'altro e si ottimizzano le capacità di ciascuno;
- si possono parallelizzare compiti semplici/ripetitivi;
- come già detto, se manca uno per qualsiasi motivo, c'è comunque l'altro che sa lavorare su quella parte di progetto.
Mi ha sorpreso che nel mondo del lavoro sia una "scoperta".
EIDT: Pensate a cosa si potrebbe arrivare se utenti che hanno scritto in questo thread programmassero in coppia :oink:
Peraltro non mi sembra difficile validare concetti come:
- Un problema trovato durante un pair programming costa secondi a metterlo a posto, (e spesa pressoche' nulla)
- Lo stesso probelma trovato dal cliente dopo la consegna costa settimane (e spesa potenzialmente molto grossa).
Se avessi anche solo voglia di aprire quei link, potresti fare questo ragionevole gioco da solo.
ah si? e spiegami tu allora, mi sembra troppo facile uscirsene con "buon proseguimento".
ma ho idea che non mi spiegherai un bel nulla, vero? chissá perché.
Ma comunque no.
Non ti spieghero' si' nulla, proprio come pensi, ma non ti lascero' senza motivo.
I don't care :asd:
A parte che è morto per mancanza di tempo di noi tutti che ricordo lavoravamo normalmente durante il giorno e avevamo magari anche altri progetti da seguire.....
Ma sono stati proprio CANCELLATI i post. :mbe:
Ci sono tutti. Sono solo stati spostati qui perché la sezione dovrebbe essere cancellata... forse.
http://www.hwupgrade.it/forum/showthread.php?t=1200995
^TiGeRShArK^
07-04-2010, 18:37
Ci sono tutti. Sono solo stati spostati qui perché la sezione dovrebbe essere cancellata... forse.
http://www.hwupgrade.it/forum/showthread.php?t=1200995
ah ok, m'era preso un colpo, tnx. :D
tomminno
07-04-2010, 19:38
Anche in questo caso bisogna costruire il mock in maniera corretta, se i test non passano vuol dire che non si è capito come funziona il sistema con cui interfacciarsi ed il mock è errato.
Scusa la domanda, ma il mock mi deve simulare il comportamento atteso e non atteso e testare quindi che il codice si comporti come previsto es nel caso non atteso che venga sollevata una eccezione ben precisa o sbaglio?
Ma se il programma (che ha fatto errato uso del modulo) non deve incappare nel caso non atteso per funzionare correttamente poco importa che io abbia un test che mi conferma che in quella condizione il software non funziona, il software non doveva incappare nella condizione simulata dal mock e confermata dai test d'integrazione.
D'altra parte non posso nemmeno far fallire il test perchè in quelle condizioni il software ha effettivamente imboccato la strada prevista, che però è causa di un non funzionamento: ovvero scrivere nell'event log e salutare, invece di eseguire l'operazione dato che le circostanze in realtà lo consentivano.
Questo è purtroppo abbastanza vero.
L'ambiente + orrendo su cui ho lavorato è proprio sharepoint.
Però in realtà puoi debuggare se il problema è nel codice che hai scritto tu, non puoi fare niente se per caso ti scompare la webpart che è stata correttamente deployata e ti dice che non la trova sparandoti errori del cazzo nei log. :muro:
L'unico modo che avevo per risolverla, dopo aver creduto di non aver capito una mazza di come effettuare il dispose di SPWeb e di SPSite era fare un clean, fare un retract della soluzione, uscire da visual studio, rientrare ribuildare e ri-deployare. :muro:
Sai che non riusciamo a debuggare perchè Visual Studio dà errori di deploy (eppure pare essere tutto configurato a dovere) e quindi non fa partire il debug remoto?
Tocca andare di debug stile ASP a forza di Response.Write.
Ma questo non ha nulla a che fare col codice.
Il mio codice per le webpart era praticamente PROCEDURALE dato che per fortuna non sono di una complessità elevata e avevo paura di qualche strano comportamento (tipo col redirect che non funziona a seconda del punto del codice in cui lo metti e della tecnica utilizzata... bisogna provare tute le combinazioni possibili per farlo andare. :muro: ).
Ecco, questa è una situazione in cui mi concentrerei sui santi da invocare piuttosto che sulla programmazione.
:D
Ah beh io mi sono salvato grazie a SmartPart (non smetterò mai di ringrazinare Jan Tielens), ho il mio bel progetto strutturato a livelli e suddiviso in assembly a seconda delle funzionalità (riusati sia dalle smartpart sia da workflow), insomma scrivo codice come fosse un normale sito web.
La cosa più brutta che mi è toccato fare è usare degli hidden field per passare le variabili tra le smartpart in quanto il meccanismo Ajax di comunicazione non funziona se l'evento scatenante proviene da una gridview.
Ma alla fine è una bruttura con cui si può allegramente convivere visto il contesto...
Mi è capitato di scrivere codice davvero banale, roba da 10 minuti, e di metterci due giorni a farlo funzionare.
La cosa buona è che almeno pagavano bene e ora ho finito di metterci mano finalmente. :)
Io ho cominciato 1 mese fa con sharepoint (alla fine per realizzare un sito che normalmente si tirerebbe su in 3/4 giorni di lavoro...) e fortunatamente ho già finito, adesso è il momento di far intervenire le Telerik per gli abbellimenti.
Diciamo che il problema è che con sharepoint la parte di programmazione è marginale come dicevo prima.
E' comunque una problematica di "progetto".
cdimauro
07-04-2010, 20:40
Uno dei miei collaboratori QA mi dice ora di avere usato in passato un altro tool chiamato Selenium per automatizzare i test per web.
[Pubblicità progresso]
C'è giusto un talk su Selenium (http://www.pycon.it/conference/talks/using-python-and-selenium-parallel-cross-browser-t) alla prossima PyCon.
[/Pubblicità progresso]
:cool:
A parte che è morto per mancanza di tempo di noi tutti che ricordo lavoravamo normalmente durante il giorno e avevamo magari anche altri progetti da seguire.....
Ma sono stati proprio CANCELLATI i post. :mbe:
Tranquillo, che una copia di backup si trova, eventualmente. :fiufiu:
EIDT: Pensate a cosa si potrebbe arrivare se utenti che hanno scritto in questo thread programmassero in coppia :oink:
Come minimo un omicidio.
khelidan1980
07-04-2010, 22:14
A parte che è morto per mancanza di tempo di noi tutti che ricordo lavoravamo normalmente durante il giorno e avevamo magari anche altri progetti da seguire.....
Ma sono stati proprio CANCELLATI i post. :mbe:
No i post sono stati spostato qui nella sezione principale, un po di tempo fa Cionci aveva postato la query per recuperarli tutti via google ma non la trovo più
wingman87
07-04-2010, 23:36
No i post sono stati spostato qui nella sezione principale, un po di tempo fa Cionci aveva postato la query per recuperarli tutti via google ma non la trovo più
Ecco il post a cui ti riferisci:
http://www.hwupgrade.it/forum/showpost.php?p=31333754&postcount=67
Tranquillo, che una copia di backup si trova, eventualmente. :fiufiu:
Hai fatto un rip della sezione?
cdimauro
08-04-2010, 07:44
Qualcosina di più, ma sono fermo a un paio d'anni fa. :fagiano:
Per tutto il resto c'è... praticamente tutto; comprese le diatribe fra fek e repne scasb. :D
Interessantissimo il progetto Diamonds, anche se riesco a vedere chiaramente i motivi che lo hanno portato al disastro :asd:
Qualcuno ha i links alle discussioni che hanno portato ad iniziare il progetto? Non quelle dove era già stato deciso di farlo, come quelle postate da cionci. Google non mi è venuto in aiuto.
Vorrei fare un pò di ingegneria sociale su di voi :asd:
Sarebbe figo iniziare una roba simile, ad averci tempo...
rеpne scasb
08-04-2010, 09:34
■
Giusto per inserirmi nella discussione...
Per quello che mi e'parso gli unici progetti che ho visto concludere bene e in tempo erano quelli gestiti da PM validi con programmatori validi, che fosse metodologia agile o tdd o rup o chi per esso.
Con valido non intendo esperto, intendo gente in grado di ragionare in modo logico che non si fa prendere dall'esaltazione per ogni buzz-framework che passa di li per caso o per ogni linguaggio appena nato e instabile che gli rotola davanti anche se e'troppo piu'cool... Mi sembra bello questo articolo di DrDobbs:
Why Software Really Fails And What to Do About It (http://www.drdobbs.com/cpp/223700002), in cui tra l'altro descrive un progetto di un "Personal TRansportation Device" come sarebbe fatto da un gruppo di sviluppo software, da cui cito la parte piu'vera ed inquietante
E ci credo che poi la nostra professione va a rotoli.. ormai non servono metodologie, competenze...basta tanta gente che scrive codice che funzionicchia a malapena, poi tanto si cambia ogni anno tutto e l'economia gira....
AAARRRGGHHH perche non ho fatto economia :(
Purtroppo questa è la triste realtà.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.