Newsgroup: it.lavoro.informatica
Titolo: Drift verso l'incerto

Prima il must  era :
Specifiche funzionali scritte, meglio se in linguaggi formali
Linguaggi fortemente tipizzati
Piani di rilascio e team strutturati
Adesso va di moda :
Specifiche fumose o espresse in forma non analitica (user stories,
game)
Linguaggi  dinamici
Sviluppo Agile o cumunque con continue interazioni (leggi
aggiustamenti)
Insomma alla fine abbiamo fatto il giro e siamo tornati al clipper,
alle interviste e le "prova se va bene" dal cliente ;-)

 Adesso va di moda :


Un buon compromesso tra formalità e 'agilità' potrebbe essere questo:
http://www.agilemodeling.com/essays/amdd.htm
 ? 
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 aggiustamenti)
Non sarà un adattamento alla qualità delle risorse umane e tecniche
oggi disponibili?
Ognuno poi può giudicare se sono migliorate o peggiorate  :-)


e' la politica di recuperare le risorse alla fermata dell'autobus !
e' troppo forte il richiamo dell'auto nuova, per i'imprenditore italico,
e' un must a cui nessuno di loro vuole rinunciare, a qualsasi costo
felice&pago
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

Il Mon, 10 Nov 2008 15:44:41 -0800 (PST), enricoe ha scritto:
[cut]
Io questo cambiamento di paradigmi non lo vedo così pervasivo, nel senso
che ho progetti dove ho sempre lavorato e lavoro in modo "agile" perché
comportandomi come una risorsa quasi fissa e on-site gli sviluppi sono
fatti sulle esigenze momentanee o quasi del cliente. 
In quese situazioni la formalizzazione di un analisi richiederebbe quasi lo
stesso tempo dello sviluppo vero e proprio.
In altre situazioni oppure in altri parti di un medesimo progetto dove
nascono richieste più "corpose" allora uno straccio di analisi scritta è
necessaria, sia per verificare di aver capito bene le richieste del
cliente, sia per pararsi il backside in caso di un cambio in corso d'opera.
Per quanto riguarda i linguaggi...essendo nato con una mentalità C/C++
based non mi attirano i linguaggi non tipizzati, ma questa è una mia
personale limitazione.
PaF

 oggi disponibili?
Ma no, perchè alla fine queste sono Pensatone fatte da gruppi (spesso
di programmatori) che poi rilasciano qualcosa e che diventano "cool"
grazie al passa parola o Oreilly.
Prendi Ruby, c'è di tutto e di più. E' a oggetti, ma puoi anche
dichiarare una funzione fuori dalle classi, tanto.. che problema c'è ?
Se scrivi "importo" è una variabile, se scrivi "Importo" è una
costante, ed ovviamente è un interpretato....
Io non lo conosco, ma qualche anni fa un linguaggio del genere sarebbe
stato considerato un accrocchio... oggi leggi che è il linguaggio del
futuro. Mi chiedo di quale.

> Un buon compromesso tra formalità e 'agilità' potrebbe essere questo:
http://www.agilemodeling.com/essays/amdd.htm
?
Ach! Se quello è un compromesso.

 Ognuno poi può giudicare se sono migliorate o peggiorate  :-)
 >:)
-- 
DES

 > :)
Confesso di essere logorroico :-) Ed inoltre di aver usato l'ottimo
servizio del nostro Google, che evidentemente anche lui talvolta ha
qualche bugghetto.

 costante, ed ovviamente è un interpretato....
flessibilità, ci vuole flessibilità :-)
 

 personale limitazione.
Io non ne conosco di linguaggi non tipizzati sinceramente. Ma
sicuramente esisteranno.
-- 
Lawrence, 
oluyede.org
 - 
neropercaso.it
 - 
stacktrace.it
"It is difficult to get a man to understand 
something when his salary depends on not
understanding it" - Upton Sinclair

 sicuramente esisteranno.
forse (e sottolineo forse) intendeva i linguaggi a tipizzazione dinamica...

 forse (e sottolineo forse) intendeva i linguaggi a tipizzazione dinamica...
Si, mi sono espresso male.
Anni di "int c;" oppure "Dim o as Integer" sono duri da superare, a parte
il fatto che non avrei neanche richieste in merito.
Ora sto lavorando in X++, ma non č che sia cosě diverso dal C++.
PaF
 

 wrote:

In parte e' dovuto al fatto che l'essere umano fiisce spesso per
estremizzare quello che fa, finendo per portarlo
a livelli ridicoli, disgustarsene  e partire per la tangente opposta.
In parte questo allontanemento dal "rigore" e'
che la creazione di software e' un'attivita' troppo complessa e
variegata per essere gestita con metodi rigidi.
Nessun metodo e' perfetto, ma credo che le pratiche agili e iterative
siano un paso avanti rispetto a waterfall e alla
pretesa di voler fare analisi e design prima di vare scrito una
singola riga di codice.

 singola riga di codice.
Ma mica vero. Secondo me, semplicemente il waterfall non è adatto a
certi tipi di progetti, specialmente i "2.0" dal contenuto funzionale
nullo, quelli che io chiamo arnesi software : un forum, una whiteboard
ajax o un blog qualcosa non hanno bisogno di analisi ma di
creatività.... e spesso il cliente è un 2.0 esso stesso.
Se vai in banca a fare "agilmente" la procedura per acquisire i mutui
credo proprio che il cliente di mandi agilmente a stendere dopo 2
iterazioni...


mm io in banca ho lavorato e so quanto i manager siano inchiodati su
metodi rigidi,
ma e' per paura e ignoranza non per un "informed decision". E ho visto
anche come rigidita' dei metodi,
formalismo, inutile produzione di documenti e pretesa di fare analisi
e design "a priori" portino a un immenso spreco
di tempo energie pazienza e denaro.
Credo che in parte il problema sia dovuto all'idea deformata che molti
hanno dei metodi agili.
Metodi agili non vuol dire "metodi alla cazzo come viene viene"...
Se c'e' bisogno di un documento che specifica in maniera precisa e
incontrovertibile cosa deve fare il codice che
gestsce un mutuo, non c'e' nulla nei metodi agili che ti dica di non
usarlo.
Sono i documenti INUTILI che vanno evitati. Oppue le situazini come
quelle descritte nel thread sul "reactoring" .. in cui
ci si ritrova con codice "intoccabile", oppure codice che " se lo devo
modificare devo chiamare tizio, ma poi lui ci mette tre giorni a
ripondere" etc etc..