[vari]Reinventare la ruota

[cdimauro]

[PGI-Bis]

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?

[edit]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.[/edit]

[gugoXX]

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?

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.

[PGI-Bis]

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]

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.

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

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.

Ne approfitto per fare gli auguri di buone feste a tutti.

[PGI-Bis]

Mi ricorda quello sketch di guzzanti...

Questa è la casa delle libertà, facciamo un po' come cazzo ci pare!

[cdimauro]

http://www.youtube.com/watch?v=u-NRmT0R5eg

[PGI-Bis]

E' lui!

[rеpne scasb]

■

[gugoXX]

Originariamente inviato da rеpne scasb

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

[PGI-Bis]

Non leggere.

Spoiler:

E LAVA ANCHE PIU' BIANCO!

[Sgurbat]

Originariamente inviato da gugoXX

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!!!"

[Sgurbat]

Originariamente inviato da PGI-Bis

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.

[PGI-Bis]

A me piace da matti.

[zakmckraken]

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

[Sgurbat]

Originariamente inviato da zakmckraken

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]

Originariamente inviato da gugoXX

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

Originariamente inviato da PGI-Bis

Se è per quello non c'è neanche il project. E avrei qualche dubbio sul fatto che sia programming.

Di certo è agile.

Si vede che non hai mai programmato con l'agile programming.
Continuate pure a lavorare all'italiana, io finalmente mi sto divertendo un mondo al lavoro.

[khelidan1980]

Originariamente inviato da ^TiGeRShArK^

Si vede che non hai mai programmato con l'agile programming.
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..

[^TiGeRShArK^]

Originariamente inviato da gugoXX

Nono, lo so bene perche' funziona.

Non avrei saputo dirlo meglio, mi hai risparmiato un bel pò di fatica.