(luKa)

A parole, sembra un'ottimo metodo, eppure per esperienza personale non funziona.
Per quanto mi impegni a suddividere in task piccoli e apparentemente facili da stimare, quando passi a realizzarli ti accorgi sistematicamente di aver tralasciato qualcosa di importante.
Le uniche volte che questo non è accaduto è stato con progetti medio / piccoli di cui conoscevo bene il dominio applicativo.
L'unica strada che vedo percorribile in questi casi è di instaurare un rapporto di fiducia con il cliente, cercando di fargli capire che non vuoi "fregarlo" cercando di gonfiare i costi, ma che nel software questo accade regolarmente e tu farai di tutto per limitarlo.

Luca, sarebbe molto bello. Peccato però che poi tutte le volte io mi svegli tutto sudato...
il vero problema è che la stragrande maggioranza delle volte il cliente ha un budget preciso in quel preciso momento (esempio classico e ricorrente, il finanziamento dell'Unione Europea) e deve spenderlo entro una certa data (in genere entro qualche settimana), quindi comuinque il software nella sua interezza alla fine deve costare quella cifra (a volte anche diverse migliaia di euro) con _tutte_ quelle funzionalità.
Sarò stato molto sfortunato io, ma ad oggi un cliente come tu lo descrivi non l'ho davvero ancora incontrato...
saluti

sono d'accordo con Antonio. In genere, con i miei clienti ho un buon rapporto, e questo li ha portati pian piano a fidarsi di me. Quando invece ho a che fare con un nuovo cliente, l'importante secondo me è frenarlo, perchè lui vorrebbe sempre riempire il sw di features che poi non utilizzerà mai. Non è raro il caso in cui si fa l'analisi, si implementa il sw, si torna dal cliente e saltano fuori un sacco di cose non previste. Preventivare i costi è davvero impossibile, perchè il cliente non sa MAI cosa vuole. E con MAI intendo proprio MAI. Io personalmente sono giunto alla conclusione che è errato dare un costo al sw in base al tempo richiesto per la sua creazione, per il numero di features presenti, etc. etc.

Un utile metodologia, che però quasi sempre non si ha il tempo di applicare, è quella degli UML Use Cases, vedete ad es qui: http://www.agilemodeling.com/artifacts/useCaseDiagram.htm

Un ottimo libro in proposito è quello di Alistair Cockburn: http://www.amazon.com/gp/product/0201702258/ref=ase_ambysoftinc/102-9604365-8312924?s=books&v=glance&n=283155&tagActionCode=ambysoftinc

Il problema è sempre la scelta tra una grande astrazione ed un qualcosa di più pratico. Se si ha tempo la metodologia degli Use cases è ottima

ciao

Teoria perfetta .. pratica dubbia, o meglio raramente realizzabile. Questo succede perchè spesso il Cliente "parte" con la fantasia credendo che con i "Compiuter" si possa fare tutto .. con pochi "clicchi di mauser" .. [la dura realtà]

da questi feddback dovrei ritenermi fortunato perché da tempo riesco ad applicare con soddisfazione questo modo di lavoro e com me i 5 team con cui ho lavorato negli ultimi 3 anni.

In verità è più semplice e accessibile di quello che sembra.

Compilare un semplice elenco puntato di singole funzionalità ha un costo minimo e presto diventa il naturale modo di fare. La flessibilità che dà nell'arco del progetto è notevole.

Questo modo di procedere funziona anche a budget fisso, permette di iniziare a consegnare software funzionante all'utente con continuità gia dalle prime fasi del progetto. L'utente così può capire meglio cosa vuole, anticipare la scoperta degli imprevisti e quindi ridurne l'impatto.

Quando il numero di funzionalità è almeno 10 gli errori di stima si compensano tra di loro e col procedere del progetto è possibile misuratre la velocità di viaggio e ricalcolare l'ora prevista per l'arrivo.

La flessibilità che mette il volante in mano al cliente, le nuove funzionalità consegnate con continuità, una visibilità sempre aggiornata dell'ora di arrivo prevista sono gli elementi che portano alla fiducia.

Questo modo di procedere non da indicazioni sul modo di stimare (la scomposizione di una funzionalità in task è un buon inizio) e sulla gestione contrattuale del cliente che sono problemi diversi; il lato positivo è che può essere applicato indipendentemente da come si decide di fare queste cose dando sempre un contributo che migliora la _Prevedibilità_ del risultato.

Nel team dove sviluppo ora (e te Luka lo conosci) siamo arrivati proprio a questo punto.
Prima di iniziare una nuova fase di progetto viene fatta un'analisi fino al minimo dettaglio con la relativa stima. Ogni voce di questa analisi la facciamo corrisponde ad un task in TFS.
Da quando abbiamo iniziato a lavorare con questo sistema, sappiamo dare una data certa al cliente (cosa che precedentemente non accadeva) e riusciamo a stare nei tempi.
In più, applicandolo poi a una struttura come TFS è davvero il massimo.
L'unica cosa da dire è che un'analisi di questo tipo richiede parecchio tempo e conoscenza delle risorse a disposizione.

Luca, quando dici che la metodologia che suggerisci è in qualche modo slegata dal come si tratta la contrattualizzazione col cliente, sono perfettamente d'accordo con te, ma il punto (purtroppo) sta proprio qui!
nella mia esperienza di sviluppatore ma anche collegamento tipo PM col cliente, ciò che davvero risulta tedioso, stressante e spesso problematico _non_ è la gestione del processo di sviluppo, quanto proprio mla contrattualistica. Il vero problema è che il cliente dal punto di vista della gestione day by day del progetto lo si riesce a gestire anche, ed è anche possibile (cosa che faccio in genere) "taskettizzare" il sw da produrre, ma proprio perchè "change happens" ed inevitabilmente il cliente cambia idea, nascono i problemi di discontinuità fra gestione del processo di sviluppo/release e gestione del contratto.
Il vero problema è che chi da parte del cliente segue il progetto non è in genere chi detiene i cordoni della borsa e cioè colui che ha inizialmente contrattualizzato tempi e costi (e nero su bianco features dell'applicativo). Troppo spesso capita che colui che chiede i cambiamenti in corso d'opera non abbia alcuna autorità interna. da qui nasce il fatto che quest'ultimo si rende conto che ciò che è stato contrattualizzato come feature non è proprio ciò che gli serve (con danno per il cliente stesso), lo comunica al referente che alla fine indice una riunione con il fornitore (io...) in cui volano velate accuse di aver fatto male l'analisi ed ovviamente di non rispettare i tempi previsti. Il fornitore a questo punto si impunta sul documento di offerta tecnico/economica e ribadisce che quelle sono le feature controfirmate da entrambi e quelle verranno alla fine sviluppate. ovviamente le posizioni diventano inconciliabili e i poveri sviluppatori ci vanno di mezzo.
Ora non voglio fare la vittima, ma situazioni di questo tipo mi sono accadute, troppo spesso a mio avviso i clienti non hanno minimamente la cultura dello stakeholder per cui si nomina un vero responsabile di progetto che abbia una certa autorità anche sul budget e sul suo utilizzo (distribuzione nell'arco dell'intero progetto).
Quello che ho imparato in questi anni è riconoscere un cliente di questo tipo, in genere è quello che dopo il primo incontro dove ci sono tutti (dal capo supremo fino all'ultima segretaria), dal secondo si presenta solo una sorta di tecnico/tuttofare che sarà il vero referente di progetto. In questi casi però sono perfettamente d'accordo con Igor per cui è strettamente necessario limitare le richieste (e ci sono diversi modi per dissuadere un clientem alcuni diretti, ed alcuni in diretti) in modo che per forza di cose il progetto diventi di diemensioni ed obiettivi verosimili.
saluti

Bravo Luca!

Aggiungo che il modo migliore per fare fallire questo sistema e' di farsi degli sconti.

Es: ho tanti bei task ... e poi QUESTO task che e' un po' un casino. Vebbe' .. lo stimo un po' cosi'!

Li' c'e' probabilmente il problema, la parte oscura del dominio del problema (o della soluzione).

NO NO NO! Spezzare please!

E" un po' come quelli che coprono di unit test il codice, trannte QUEL metodo che e' 'troppo un casino'!!! Probabilmente sono gli stessi che si lamentano che il sistema NON funziona! :)

PierG

Andrea, felice di sapere che le cose sono andate nella migliore direzione; saperlo mi fa ricordare con orgoglio il primo step che ci ha portato dalla lasta della spesa composta da milestooe a grana grossa o dal numero di pagine web da realizzare alla lista della spesa composta di singole funzioni applicative.

Il tuo feedback insieme a quello di PierG mi danno il riscontro che quello che quanto ho descritto piace e lascia soddisfatti chi lo applica.

Roberto, la situazione che descrivi è oggettivamnte difficile e non a causa dell'informatico che viene messo in mezzo. Quanto di propongono una nuova funzionalità hai provato a pesarla e poi chiedere al cliente di scegliere una o più funzionalità di pari peso d togliere per far posto a uella nuova?

Luca, quello che volevo far capire nel mio post non è tanto l'impossibilità di gestire le richieste di cambiamento, cosa che alla fine si riesce sempre a fare (anche con il suggerimento che mi hai dato, ma ce ne sono decine di modi di mettersi d'accordo), quanto l'impossibilità di gestire in maniera concordata e senza stress problematiche di questo tipo (ed enormi perdite di tempo..).
é una questione di cultura, che fa ancora fatica a passare. Ma stai sicuro Luca che da settembre, quando diventerò padrone di me stesso, le cose potrò impostarle io fin dall'inizio, e credo sinceramente che per me sarà un bel salto nella qualità della mia vita professionale.
saluti