Newsgroup: it.lavoro.informatica
Titolo: Metodologia nel Project Management

Buongiorno a tutti, vorrei una vostra impressione riguardo la comprensione
da parte delle piccole-medie aziende, dell'importanza della metodologia nel
PM.
Premetto che sono un consulente applicativo, da 10 anni lavoro nell'IT, mi
manca la laurea, č vero (spero un giorno di riuscire a coniugare il lavoro
con l'impegno gravoso di un corso universitario), ma dedico in media 2
giorni alla settimana (oltre ad alcuni week end) all'aggiornamento su
metodologie ed evoluzioni non solo applicative, ma anche organizzative e
tecnologiche.
Negli ultimi anni, mi sono trovato a gestire diversi progetti e queste
esperienze hanno generato in me la convinzione che un approccio metodologico
alla modellazione č di grande aiuto al PM ed č pertanto importante (se non
fondamentale) per la buona riuscita di un progetto.
Tuttavia, ultimamente, quando espongo questi concetti ai miei clienti (PMI),
mi sembra di essere un predicatore nel deserto. A quasto punto mi chiedo:
c'č qualcosa di sbagliato nella mia forma comunicativa oppure il mercato
delle PMI non č ancora pronto ad investire in metodologie che evitino i
bagni di sangue?
Vi ringrazio di cuore per lo spazio dedicatomi e spero di ricevere i vostri
sempre interessanti commenti.
Daniele

 bagni di sangue?
Secondo la mia modesta esperienza le PMI del nord-est (ma da quello che
leggo la situazione è generalizzata) non sono ancora pronte per accettare
certe metodologie.
Da quello che vedo procedono ancora con metodi artigianali, familiari,
consolidatisi nelle precedenti generazioni (ove ci siano state) e si
affidano alle capacità personali delle singole persone per restare a galla
in una totale disorganizzazione.
Mi domando se a qualcuno sia mai passata per la testa l'idea di analizzare
quanto si PERDE nella propria azienda a causa della disorganizzazione.
Ritengo che purtroppo la situazione non cambierà finchè le aziende non
saranno messe con le spalle al muro dalla crisi e dalla concorrenza,
sperando che quando questo avverrà non sia troppo tardi per porvi rimedio,
altrimenti... bye bye
Continua a proporre le "nuove" metodologie, chissà che questo mercato si dia
una mossa prima o poi. Mah!

quanto si PERDE nella propria azienda a causa della disorganizzazione.
Esistono società di consulenza di impronta americana (il modello è
nato negli Stati Uniti prima della guerra) che fanno proprio questo
lavoro, in Italia,  presso le PMI.
Per una serie di ragioni le tariffe applicate sono talmente alte che
difficilmente la piccola impresa ne trae giovamento in quanto i costi
dell'intervento sono spesso superiori ai benefici (quando misurabili).
Questo ovviamente è il mio parere ma parlo per esperienza diretta.
Tuttavia sono talmente tante le piccole imprese in Italia che dei
bravi commerciali trovano sempre nuovi clienti per queste società di
consulenza non informatiche che continuano a prosperare in un mercato
dove ci sarebbe viceversa molto spazio per società di consulenza
informatiche.

Quali metodologie hai usato finora?
Ciao
Luigi.


Ed a cui bisognerebbe in qualche modo agganciarsi per riuscire a penetrare
in questo mercato con soluzioni di qualita'.


... ad esempio l'utilizzo di OOA fin dallo StartUp di progetto...
...la revisione degli step progettuali dalle canoniche fasi, ad un'ottica
che attribuisca più importanza alla modellazione (conseguenza di una
progettazione) piuttosto che allo sviluppo...
... e poi l'utilizzo di strumenti come UML anche per la comunicazione
interdipartimentale in fase di studio di fattibilità...
Secondo me il punto è che l'informatica in Italia è rimasta al: "ESISTE UN
PROBLEMA? SCRIVIAMO UNA FUNZIONE CHE LO RISOLVA!!!" e via di questo passo
abbiamo acquisito un mentalità "conservatrice".
Ciao
Daniele

 ha scritto nel messaggio
news:rQhm9.35438$e31.7...@twister2.libero.it...

Voglio solo darti un esempio di quella che è la mentalità dell'azienda in
cui lavoro, oggi il mio direttore tecnico alla mia richiesta di mettere su
carta il funzionamento di un nuovo opzionale della macchina che produciamo
mi ha risposto con la seguente frase: " noi non siamo la Nasa, prima
facciamo il missile e poi vediamo se vola"
Non penso sfortunatamente che la mia azienda sia la sola con questa
mentalità
Ciao
Alberto

 lavoro, in Italia,  presso le PMI.
[cut]
Di quali società parli, potresti fornire un elenco o dove trovarlo, mi
piacerebbe entrare in contatto.
Grazie.

 mentalitą
Al contrario, e' purtroppo normalissimo, non saprei farti degli esempi
contrari...
Forse il mercato non e' abbastanza selettivo da eliminare chi non riesce ad
evolvere.
Non me ne volere, Alberto, non ho nulla contro la ditta in cui lavori, pero'
e' chiaro che se le aziende cosi' vivono e crescono comunque, i vari
direttori non hanno motivazioni per voler cambiare le cose.
Metodo vincente non si cambia, sensato o meno che sia.

Grazie.
Un elenco (spero qualificato) di società di consulenza organizzativa
per le piccole medie imprese lo puoi trovare su 
http://www.fita.it/
(Federazione del terziario avanzato - vedi banca dati).
Ciao

 facciamo il missile e poi vediamo se vola"
E' il famoso time to market :)

 ... e poi l'utilizzo di strumenti come UML anche per la comunicazione
UML è un'ottima cosa, come tu sottolinei per la comunicazione. Comunque ciò
non toglie che utilizzato con metodologie sbagliate porta ai BDS (Bagni di
Sangue) esattamente come l'uso dei flowchart o dei geroglifici :-)
Ad esempio, è abbastanza riconosciuto come fatto certo che non è possibile
passare 6 mesi sull'analisi di un progetto scrivendo quintali di diagrammi
UML di ogni tipo per poi passare alla fase di coding, quindi al testing,
quindi fixing, quindi al suicidio... :-)
Pare che le ultime direzioni siano invece verso le metodologie lightweight,
che prevedono un sconvolgimento totale delle fasi "ben distinte" come lo
erano fino a ieri (e sullo ieri, molti sono ancora bloccati). Ho degli amici
XP-entusiasts, quindi può essere che la cosa funziona. Viceversa ho vissuto
un progetto bancario di dimensioni colossali che è stato più che un bagno di
sange, eppure dichiarava di utilizzare metodologie "alla moda" quali RUP
notazione UML per l'analisi e quant'altro. Ora ciò che è necessario, imho, è
riconoscere che non si può fare 6 mesi di analisi pensando ad ogni problema
possibile e poi passare mattonate di analisi a "coder-stupidi"
(possibilmente a basso costo) che implementino in 3 mesi l'analisi senza
intoppi.
Dò per scontato che non i BDS di cui parli sono gli stessi che ho vissuto io
(come programmatore) grazie a metodologie OOA quali RUP, waterfall o "code &
fix".

Prova a dare uno sguardo quě:
http://www.extremeprogramming.org/
Quě ci scrivono dei miei amici :-)
http://www.extremeprogramming.it/
ciao
Luigi.

 evitino i bagni di sangue?
Ho lavorato con varie ditte: quasi nessuno usa l'approcio prima di
progettare/pianificare il progetto, e poi di sviluppare. Non credo che sia
neanche una mancanza di preparazione: penso sia una mancanza di buon
senso. Credo che sia piu' un problema sociologico che un problema tecnico.
Tanto per dipingere uno scenario caricaturale: la mattina arriva un
responsabile (direttore tecnico, padrone,..) che ti informa che bisogna
fare un certo progetto, da' le disposizioni, organizza dal suo punto di
vista il lavoro, e poi va via. Tutti gli altri problemi sono problemi da
tecnici. Scrivere delle specifiche viene vista come
una perdita di tempo. Una persona e' produttiva solo se si mette a
codificare. Nessuno pensa che una buona progettazione sia anche la strada
piu' veloce per arrivare al risultato. I nostri manager sono abituati a
lavorare in un certo modo, e poiche' nel bene o nel male questo modo ha
funzionato, nel senso che ha portato a dei risultati, continueranno a
lavorare cosi'. Cambiare e' sempre un rischio, e dal punto di vista
personale doloroso.
Se vuoi una prova della mancanza di buon senso dei nostri mamanger basta
pensare a come sono organizzati gli spazi in cui si svolge il lavoro. Open
space affollatissimi, con poca superfice scrivania, rumorosissimi. Quanti
di voi devono ascoltare la musica in cuffia per isolarsi dall'ambiente?
Anche in questi ambienti il codice alla fine viene scritto, dal punto di
vista manageriale si e' risparmiato qualcosa sull'affitto, nessuno si
pone il problema che in un ambiente migliore la gente possa essere piu'
produttiva, o quanto meno piu' soddisfatta. 
Scusatemi la divagazione sull'ultimo paragrafo :)
S.

 waterfall o "code & fix".
Le metodologie che citi, a parte waterfall e "code & fix", prevedono fasi
iterative, una volta si diceva anche modello a spirale. Anche RUP e' a
iterazioni. Non credo che RUP sia stata la principale responsabile del tuo
BDS (bagno di sangue). Non voglio difendere RUP, ne' sono un esperto. Ho
solo letto qualcosa su RUP, XP e qualcun'altra. RUP  e' una metodologia
molto complessa, e piu' che una metodologia e' un framework per costruirsi
una metodologia, nel senso che la "vendono" come adattabile al contesto.
RUP e' spinta molto fortemente dal marketing di Rational. Quando i manager
adottano RUP si sentono rassicurati dalla paura che un progetto possa
fallire. Questa e' una senzazione psicologica indotta dal marketing.
Secondo me il problema non sta nella metodologia, ma nella mancanza di
buon senso delle persone, e nella non focalizzazione sull'obiettivo. Lo
scopo di un team di persone non e' eseguire una metodologia, ma di
riuscire a sviluppare software, la metodologia e' un mezzo. Le metodologie
agili sono tutte adattabili al team che le adotta. Mi piacerebbe
conoscere un posto in Italia dove si segue veramente un processo di
sviluppo.
 
S.
P.S. Ne ho piene le @!$%^ di BDS :)

 XP-entusiasts, quindi può essere che la cosa funziona.
... su progetti di piccola-media dimensione può funzionare... ma su quelli
grandi credi che sarebbero veramente entusiasti di scrivere e riscrivere per
customizzare qualcosa che nemmeno il cliente ha la benchè minima idea di
ottenere?



per approccio metodologico intendo un approccio sistemico... non solo
"quando serve"...
per metodologia intendo l'impiego coerente e rigoroso di un metodo (in
questo caso la modellazione) e pertanto la conoscenza della metodologia si
traduce nella conoscenza dei modelli e conoscere modelli č indispensabile
per scegliere in modo consapevole e concreto.
Inoltre penso che conoscere attraverso la  metodologia equivalga a costruire
astrazioni che, contrariamente a quanto si crede, costringono alla sintesi
ed evidenziano l'effettiva comprensione dei problemi.

sono pienamente d'accordo!!!


 ottenere?
Nel passaggio di un'architettura bancaria host verso architettura "open"
J2EE, io ho sperimentato, in qualità di sviluppatore, che alcuni approcci
hanno dei buchi.
I requisiti cambiavano continuamente, l'analisi era tutt'altro che stabile.
Era stato fatto un ciclo di analisi di circa 8/9 mesi (o più non mi ricordo)
e poi dovevamo realizzare tutto in 3 mesi. Un progetto la cui durata era
stimata di un anno, credo che sia ancora in fase di implementazione ora (a
oltre 3 anni di distanza). Sai quante volte al giorno andavo a rompere le
scatole agli analisti perché non quadrava un tubo? Un sacco di volte. Questo
perché i PM hanno passato mesi e mesi a discutere di OO e di sistemi campati
in aria.
Io trovo poco furbo pensare che un'analista possa avere una visione completa
d'insieme e gli sviluppatori poi prendono in mano un sacco di documentazione
e in poco tempo implementano tutto senza intoppi. Almeno, io questo non l'ho
mai visto realizzato, ma sono pronto a cambiare idea, quando lo vedo
funzionare.
I fatti sono che il cliente (o l'analista, che è il cliente per lo
sviluppatore) spesso non sa che direzioni prenderò il sistema, poiché le
cose cambieranno di sicuro. Le certezze crollano, i requisiti cambiano
etc.etc... Non può prevedere l'impatto anche di una piccola modifica
sull'intero sistema, soprattutto quando il sistema è grosso. Il cliente
comincia a capire ciò che vuole quando prova un pezzetto di programma
funzionante. E poi dà il feedback per indirizzare gli sviluppi futuri. Il
design applicativo e l'analisi di dominio dovrebbero essere a stretto
contatto IMHO. Non si può realizzare un palazzo intero d'un botto. Si fa un
pezzettino per volta, ed è anche più facile progettare e far funzionare un
pezzettino per volta, forse.
Comunque piccolo o grande. Il guaio è che i requisiti cambiano sempre.
bye :)
Luigi

 sviluppo.
Ho un amico che è fortemente orientato su XP, e pare trarne grossi benefici.
Pare che ci siano in Italia vari gruppi che fanno di XP una linea guida
concreta.
Questi ragazzi tengono un wiki su XP, magari c'è qualche info sulla loro
esperienza:
http://www.extremeprogramming.it/

Ho l'impressione che nuove direzioni, anche citate nei libri più recenti
individuino nelle metodologie leggere/agili, la strada da percorrere per il
futuro.
E' un po' il modo per dire "addio mesi e mesi di analisi preventiva e
discussioni sui massimi sistemi"...  :-)
Faccio un piccolo riferimento all'ultimo libro dello Zio Bob:
http://objectmentor.com/home
Leggete di chi sono i commenti.
Ciao
Luigi.

 futuro.
Regola del 3 :)
Un programma/progetto per arrivare a regime deve essere rifatto 3 volte.
La prima volta si capiscono i reali problemi tecnici e funzionali che
l'analisi preventiva (per quanto approfondita) non ha evidenziato.
La seconda si risolvono i problemi suddetti, eventualmente se ne evidenziano
degli altri minori (si spera!), si migliorano un po' le cose e si ottiene
qualcosa di funzionante da dare al cliente.
La terza si ottimizza e si aggiungono quelle funzionalità che il cliente si
accorge sono indispensabili al programma/progetto.
Che dite, scrivo un libro anch'io? :))


bye :)
Daniele

 la modifichi..." ... minimo minimo mi prendono per pazzoide.. ;-)
La costruzione di un edificio si basa su modelli parametrizzati altamente
collaudati.
I parametri di intervento sono estremamente ridotti e il cliente bene o male
ha un'idea abbastanza precisa di cosa vuole (o meglio di cosa può ottenere).
Un programma di sua natura è qualcosa di altamente variabile che il cliente
percepisce in minima parte.
Arriverei a dire che nemmeno un analista/programmatore sa cosa uscira' prima
di metterci le mani.
Saro' blasfemo, ma considero la programmazione come un'arte creativa.
Il programma è, a suo modo, un'opera d'arte e come tale non si riesce a far
rientrare in schemi definiti.
Le metodologie di sviluppo posso essere viste come "stili".
Il programma è una massa informe di bit che le sagge mani del programmatore
plasmano...
Istruzioni colorate che si depositano dolcemente sul monitor...
D'ora in poi chiamatemi Michelangelo!
Scusate, ho sentito una sirena fuori dall'ufficio. Vado a vedere...

 ed evidenziano l'effettiva comprensione dei problemi.
Sono d'accordo con te, quando dici che e' sulla base dei modelli che si
possono prendere le decisioni. Pero' si rischia di astrarre troppo e di
lasciarsi sfuggire qualche problema, o arrivare a delle soluzioni che non
possono essere implementate. 
 
Bye
S.

 
Ci daro' un'occhiata. 
Suggerisco anche il sito di Martin Fowler che dovrebbe essere
www.martinfowler.com
. (non posso controllare perche' sono offline).
Il sito contiene una panoramica sulle metodologie agili.
Bye
S.

 per pazzoide.. ;-)
I libri di analisi/design del software utilizzano questa metafora della
costruzione della casa, che imho e' assolutamente sbagliata e non si
applica al software, almeno nella nostra epoca. Fare software non e'
cosi' standardizato come costruire un edificio. Puo' darsi che fra molti
anni non sara' piu' cosi': costruiamo edifici da migliaia di anni e
sviluppiamo software da meno di un secolo.
Anche il rapporto che si instaura tra chi ha bisogno di software e chi
sviluppa deve essere piu' un rapporto di partnership, cioe' siamo uniti
verso un obiettivo, piu' che un rapporto fornitore/cliente.
Bye
S.

 Scusate, ho sentito una sirena fuori dall'ufficio. Vado a vedere...
Grande :)

Io la conoscevo come regola della 3^ release. Più o meno simile: un
programma comincia ad essere utilizzabile a partire dalla 3^ release.

E inoltre c'è online un'ottimo libro online:
http://martinfowler.com/isa/index.html
che non è stato ancora pubblicato. Per metà tratta di argomenti di design di
applicazioni enterprise, per l'altra metà è un catalogo di pattern.

 Saro' blasfemo, ma considero la programmazione come un'arte creativa.
Mi sembra d'aver scritto qualcosa di simile proprio su questo newsgroup
qualche mese fa quando ho cominciato a postare.
Luigi

 sviluppiamo software da meno di un secolo.
Su questo pare che ci stiamo accordando tutti.

 Esattamente. A volte č il codice a prender vita e a "guidare".
ragazzi... mi dispiace non posso pensare che io gestisco un "qualcosa di non
ben identificato" che prenda il sopravvento sulle mie idee e su quello che
ho progettato. Questo significherebbe che io sono in balia della mia
creazione... scusate, forse sembrerň superbo, ma se lo facessi sarebbe come
ammettere che non sono capace di fare il mio lavoro... :-(
Ciao
Daniele



Sante parole.
Intervento breve, forse inutile, di un XPer che ha un casino di cose da fare!!! (purtroppo
non di programmazione... sic!)
Ciao,
    Bruno.
---
| Bruno Bossola 
| A Java Software Engineer :-)
| 
http://digilander.iol.it/bbossola
|
| Membro del JUG Torino - 
http://www.jugtorino.it
| 

 ho progettato.
E' un modo di vedere le cose :)