[vari]Reinventare la ruota

[^TiGeRShArK^]

Originariamente inviato da tomminno

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.

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.

[javaboy]

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]

Originariamente inviato da javaboy

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^]

Originariamente inviato da khelidan1980

ormai quì emigrano tutti, mi sa che me tocca prima o poi..

ah io ho trovato un altro mondo.

[tomminno]

Originariamente inviato da ^TiGeRShArK^

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.

Forse perchè prima ci dobbiamo liberare del marciume esistente che impedisce l'adozione di tali tecniche di sviluppo?

[tomminno]

Originariamente inviato da ^TiGeRShArK^

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^]

Originariamente inviato da tomminno

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.
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.

Originariamente inviato da tomminno

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.

[WarDuck]

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^]

Originariamente inviato da WarDuck

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.

[Johnn]

Dico il mio pensiero, sperando di aggiungere qualcosa, dal... basso della mia inesperienza :

1. l'ingegneria del software non è ancora complessivamente matura come lo sono le altre ingegnerie;
2. 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;
3. 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;
4. (questa cosa potrebbe risultare a voi una banalità, ma ricordatevi l'inesperienza... ) 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^]

Originariamente inviato da Johnn

Dico il mio pensiero, sperando di aggiungere qualcosa, dal... basso della mia inesperienza :

1. l'ingegneria del software non è ancora complessivamente matura come lo sono le altre ingegnerie;
2. 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;
3. 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;
4. (questa cosa potrebbe risultare a voi una banalità, ma ricordatevi l'inesperienza... ) 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.

[Johnn]

Originariamente inviato da ^TiGeRShArK^

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 )? Web, controllo di un sistema industriale, software di un aereo, kernel di un sistema operativo?

Originariamente inviato da ^TiGeRShArK^

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.

[marco.r]

Originariamente inviato da cdimauro

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. ), utilizzare per raggiungere i nostri obiettivi.

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 . 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..

[marco.r]

Originariamente inviato da gugoXX

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 .
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

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

[marco.r]

Originariamente inviato da ^TiGeRShArK^

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

[^TiGeRShArK^]

Originariamente inviato da Johnn

Ma in quali ambiti (chiedo perché non so, non in tono polemico )? 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^]

Originariamente inviato da marco.r

Prova a fare un prodotto che va certificato e poi mi dici se non esistono i documenti

per fortuna non è il mio caso.

[cdimauro]

Originariamente inviato da marco.r

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 .

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.

[gugoXX]

Originariamente inviato da marco.r

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]

Originariamente inviato da ^TiGeRShArK^

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.