Fornire stime per progetti su larga scala in un ambiente agile [chiuso]

Question

La mia azienda ha appena ricevuto la sua prima inchiesta di progetto di sviluppo su larga scala e vorrei utilizzare un processo Agile. Il cliente ha una visione per l'applicazione ma ammette apertamente di avere pochissimi requisiti e riconosce che dovremo addebitare a ore. Per questo motivo, l'ho quasi venduto con un approccio Agile.

Il problema è che vuole una cifra da preventivare. Ho letto una serie di articoli che sostengono praticamente di rinunciare a una stima perché il cliente effettuerà il budget per quel numero e anche se i requisiti cambiano, il numero nella loro testa e nei libri non lo fa.

Ho letto che esistono diversi modi per tener conto dei prezzi nel contratto, ma quasi tutti (tranne uno) incorporano un numero iniziale. Questo sembra violare l'intero insieme di principi dello sviluppo Agile.

Quindi la mia domanda è, se sei un negozio Agile, come riesci a aggirare questo Catch-22 dello sviluppo Agile?

Answer 1

Ecco la domanda fondamentale.

Quando il cliente penserà di aver finito?

Se pensano che sarà fatto entro giugno, allora metterai in atto una squadra Agile. Sono 4-6 persone per 6 mesi. Questo è il budget. In sostanza, fai la moltiplicazione per loro. squadra * tasso * 6 mesi.

Se pensano che per lo più saranno completati entro giugno, ma dopo ci sarà più lavoro, probabilmente stai guardando 9 mesi di lavoro. Ancora una volta, stai solo facendo una moltiplicazione che potrebbero fare da soli. squadra * tasso * 9 mesi.

Se pensano che sarai il loro team di sviluppo per il prossimo futuro, dai loro un prezzo che porterà il progetto fino alla fine dell'anno. squadra * tasso * 12 mesi.

Dal momento che ogni versione è un'opportunità per ridistribuire la priorità, dovresti valutare ciascuna versione come un lavoro separato basato sulle cose che farai in quella versione. Dal momento che è il loro schema prioritario, controllano ciò che costruisci, controllano il budget, fase per fase.

Spesso il tuo cliente vuole davvero sapere quanto costerà un determinato set di funzionalità. Invece di chiederlo, chiedono del budget complessivo (che è sciocco). Dedica molto tempo alla prima versione mostrando ciò che ottengono e quanto costerà quella prima.

Alla fine vedranno la verità fondamentale.

Stanno acquistando le funzionalità dal più importante al meno importante . Se assegnano correttamente le priorità, possono smettere di spendere soldi in qualsiasi momento e avere qualcosa di utile.

Fatto è un termine relativo. Alcuni progetti sono "realizzati". perché non ci sono più soldi. Altri sono fatti perché non c'è più tempo. Raramente (almeno nello sviluppo di software) è un progetto mai realizzato perché abbiamo finito le cose da fare.

Answer 2

Per questa situazione, abbiamo fornito una stima per il primo pezzo di lavoro, quindi lasciamo che il cliente acquisti più sprint come richiesto per completare il lavoro al livello desiderato.

Man mano che si sviluppa più sistema e si incorpora il feedback del cliente nei risultati dello sprint, entrambi si sentiranno meglio per la quantità di lavoro coinvolto e quindi i costi.

Modifica: Fantastico. Eccellente! Dal fatto che li hai venduti su un approccio Agile, a proposito buono !, è probabile che sarai in grado di vederli avvicinandoli da un punto di vista agile in termini di funzionalità da implementare. Forse ascoltate questo " Intro to Scrum " podcast. Potresti essere in grado di venderli sul fatto che probabilmente non avranno bisogno di avere tutte le campane e fischietti che pensano di aver bisogno in questo momento.

HTH

applausi,

Rob

Answer 3

Guarda, c'è un fatto fondamentale qui. Ti verrà chiesto di stimare i costi, stipulare un contratto per una determinata data di consegna e impegnarti in una serie completa di funzioni fornite.

Non puoi fare tutti e tre.

Non " Non dovresti " o "sarebbe saggio non"; tu (per tutti gli scopi pratici) non puoi. Con questo intendo dire che la probabilità di fare con successo tutti e tre è estremamente ridotta.

La migliore risposta è impegnarsi in un costo e una pianificazione e in un processo iterativo con iterazioni rapide e feedback regolari, quindi scrivere l'accordo in modo che ciò che viene fatto non superi i costi fissi e la pianificazione è ciò che verrà consegnato. Cioè, continui a offrire nuove funzionalità (e modifiche) fino allo scadere del tempo e del denaro.

La verità è che, anche se fai ti iscrivi a tutti e tre, il meglio che sarai mai in grado di fare è comunque due su tre. Potrebbe anche essere aperto al riguardo.

Answer 4

Ecco come lo ha affermato un vecchio appaltatore governativo di recente: " Come dicono le prostitute, prima devi portarle di sopra. "

Questo non risponde alla tua domanda, ma vale la pena ricordare. Se non vengono di sopra senza il numero in primo piano (e non lo faranno), devi dare loro un numero.

Chiunque sponsorizzi un progetto software deve avere un'idea del tipo di rendimento che otterrà dal proprio investimento, in modo da poter valutare se vale la pena investire. Può valere la pena fare un progetto se costa $ 1 milione e impiega 12 mesi. Potrebbe non valere la pena farlo se costa $ 2 milioni e impiega 24 mesi.

La vera domanda è: puoi realizzare questo progetto in un arco di tempo e budget che consenta al cliente di realizzare un ritorno sull'investimento adeguato? Se la tua risposta a questa domanda è tutt'altro che "sì", quindi non dovrebbero assumerti per fare il progetto. Altrimenti, stanno solo spendendo soldi e lanciando i dadi.

Se la tua risposta attuale a questa domanda è " non lo sappiamo ancora " quindi non dovrebbero assumerti per fare il progetto. Ma ciò non significa che non dovrebbero assumerti per scoprire se vale la pena fare il progetto. Una buona parola d'ordine della società di consulenza per questo è "esercizio preliminare di scoping". & Quot;

Lo sviluppo agile riguarda la gestione di una curva in tre dimensioni: denaro speso, tempo di calendario e set di funzionalità. È un dato di fatto che se il budget e la pianificazione sono fissi, il set di funzionalità deve essere variabile. Non puoi sapere quale sarà il set di funzionalità finali , dati questi vincoli. Ma puoi sapere se un set di funzionalità che sarai in grado di produrre entro quei limiti rientra in un intervallo che il tuo cliente troverà accettabile.

Puoi saperlo e scoprirlo. Scoprirlo è qualcosa che la tua azienda può fare e il tuo cliente non può. È un servizio che puoi fornire loro e che dovrebbero pagare per te. Evita la tentazione di farlo gratuitamente e chiamalo un costo di vendita. L'ambito del progetto fa tanto parte dei servizi professionali quanto lo sviluppo del software. Non lo stai facendo per chiudere una vendita; lo stai facendo per aiutare il tuo cliente a prendere una decisione aziendale che non ha ancora abbastanza informazioni da prendere.

Ma prima devi farli venire di sopra.

Answer 5

Queste risposte sono davvero fantastiche. Non ho molta esperienza da condividere, ma ho pensato a un'analogia:

L'anno scorso io e mia moglie abbiamo ristrutturato la nostra cucina. Il contraente ha proposto la fatturazione in tempo & amp; materiali invece di fornire una stima, perché non sapevamo cosa avremmo scoperto riguardo all'impianto idraulico, al danneggiamento del sottofondo e così via. Abbiamo concordato, perché lavoro da casa ed ero continuamente disponibile a rispondere alle domande. Il contraente e io abbiamo avuto un buon rapporto, quindi quando è successo qualcosa, si è sentito libero di bussare alla porta del mio ufficio e ne discutevamo. Le decisioni sono state prese rapidamente e il lavoro è stato fatto come volevo. Sembra simile alla priorità Agile sulla revisione frequente dei clienti .

Al contrario, anche il cugino di mia moglie sta ristrutturando la sua casa. È un medico ER ed è non disponibile sul posto durante la ristrutturazione. Così descrisse di essere regolarmente sorpreso dagli appaltatori che prendevano decisioni importanti senza consultarlo ("Cosa? Non volevo che quella finestra fosse bloccata! Strappa il muro e ridisegna la finestra com'era!"). Questo è ovviamente dolorosamente costoso e fa esplodere il programma dall'acqua. Sicuramente non agile.

Quindi un modo per convincere un cliente che un tempo & amp; la modalità materiali funzionerà per assicurare loro che farai frequenti rapporti sullo stato di avanzamento per ottenere il loro feedback. Credo che questa sia già una raccomandazione di base della maggior parte delle metodologie Agili. Per iniziare, ovviamente, ciò richiede che il cliente si affidi al consulente.

Come risorsa separata, ho cercato e trovato un libro su questo argomento: " Agile Stima e pianificazione " di Mike Cohn. Leggi le citazioni di lode in quella pagina, da un impressionante gruppo di esperti Agile.

Answer 6

Prima di tutto, voglio dire che penso sia grandioso che tu gli abbia venduto un approccio agile e prezzi all'ora. È molto difficile da fare.

Per quanto riguarda il tuo dilemma, penso che dovresti presentargli una stima approssimativa dei prezzi e le caratteristiche / ambito che include. Durante il processo di sviluppo, se vedi qualcosa di importante che cambierà l'ambito / costo, dici al cliente "stop - questo è fantastico, ma capisci che cambia l'ambito originale di cui abbiamo discusso. & Quot;

A questo punto il cliente ha il privilegio di concordare, essendo consapevole che pagherà più di quanto pensasse inizialmente, o fermando il nuovo sviluppo per ora. Molti progetti agili sono costruiti in molti mini-stage - per i quali è possibile fornire una stima abbastanza accurata del prezzo / tempo. Prima che inizi un nuovo mini-stage, è importante che tu e il tuo cliente vediate di persona cosa succederà dopo e quanto tempo / costi vi verranno spesi.

Answer 7

Come sempre, qualità, funzionalità e tempo (= risorse) sono i tuoi parametri principali. Non roviniamo più la qualità, quindi restano solo funzionalità e risorse. Abbastanza spesso puoi cavartela convincendo che una certa quantità di risorse raggiungerà almeno un certo set di funzionalità. Quindi, finché riesci a trovare una quantità di risorse che offre un set di funzionalità plausibile, credo che questo sia sufficiente per un bel po 'di clienti. Il lato positivo è che possono controllare i progressi mentre sono in movimento e c'è sempre la possibilità di ritirarsi.

Answer 8

Il modo in cui l'ho fatto è usare la mia velocità attuale e stimare un intervallo basato su stime approssimative della complessità (numero di storie). Lo aggiorneresti mentre inizi a pianificare l'applicazione in modo che la stima dell'intervallo diventi gradualmente sempre migliore.

Ad esempio, fornisci una stima da 6mos a 2 anni (se sei sicuro che ci vorrà meno tempo di 2 anni. Man mano che lo scomponi in funzionalità, quindi pianifichi tali funzionalità, ti viene in mente un migliore e stime migliori in modo che dopo 6 secondi si possa dire in modo affidabile (in assenza di altre modifiche), si effettuerà tra altri 2-3 mesi (in totale 8-9 mesi). Alla fine, si arriva al punto in cui si può dire, noi verrà eseguito dopo la successiva iterazione (da 2 settimane a 1 mese).

Devi abbinarlo per far sapere al cliente che l'aggiunta di funzionalità aumenterà il tempo necessario per il completamento, quindi lascia che decida come procedere: o abbassa la funzione o aumenta il tempo. Per ogni dato progetto, ambito e tempo sono davvero le uniche variabili che puoi cambiare in modo efficace. La qualità e le risorse sono praticamente fisse. In realtà, puoi aggiungere risorse, ma generalmente vedi un aumento del tempo e una diminuzione della qualità inizialmente, quindi funziona solo se il tuo orizzonte temporale è lungo.

Answer 9

Un approccio che potresti adottare è quello di dare al cliente una stima generale che ritieni sia relativamente vicina. Dai anche una percentuale. La percentuale sarà un aumento o una riduzione dell'assegnazione nel bilancio a causa del cambiamento dei requisiti.

Esempio: stima generale di $ 10.000 ma poiché i requisiti sono vaghi e il progetto potrebbe cambiare rotta facilmente, c'è un'opzione di aggiustamento del prezzo del +/- 30%.

In questo modo il cliente può avere un'idea generale di cosa preventivare e si ha una certa flessibilità nell'addebito al progetto.

Answer 10

Questo è un problema davvero difficile. Scopri cosa ha da dire Robert Glass sull'argomento nel suo libro " Facts and Fallacies of Software ingegneria " ;. ( Nota che Amazon ha libri disponibili nuovi a meno di quelli disponibili di seconda mano! [a partire dal 2009-01-05 12:20 -08: 00]; anche su Google books. )

Answer 11

Se hai venduto con successo al cliente un approccio Agile e fatturazione a ore, non fornire loro una stima di quanto costerà per completare il progetto! . Anche se dicono di volerlo solo a fini di budget, non farlo! .

Il motivo è che qualsiasi stima dei costi verrà trattata come un impegno definito; non importa quante volte dici che non lo è, e quante volte il cliente dice che lo capiscono, sarà trattato come un impegno. Anche se il cliente capisce, il loro capo non lo farà, e anche se non saranno in grado di costringerti legalmente a consegnare per il prezzo che hai detto, verrai conosciuto come una società che non mantiene ciò che ha promesso. Fornire una stima elimina in primo luogo tutti i vantaggi di essere agili.

Quello che suggerisco è di dire loro che non spenderai più di tale importo prima della fine dell'esercizio finanziario (o qualsiasi altro periodo di fatturazione a cui il tuo cliente è interessato). Ciò dovrebbe essere sufficiente per loro di pianificare finanziariamente senza dire in alcun modo che il progetto sarà finito entro allora.

Answer 12

  

Questo era il mio risposta a una domanda chiusa relativo ai punti della storia. Lo uso sempre per la stima macro.

Quando sono passato ai punti, ho deciso di farlo solo se avessi potuto soddisfare i due seguenti punti; 1) trova e argomenta che giustifica il passaggio e che convincerà il team 2) Trova un metodo semplice per usarlo.

Convincere

Mi ci sono volute molte letture sull'argomento, ma alla fine ho trovato l'argomento che ha convinto me e il mio team: è quasi impossibile trovare due programmatori che saranno d'accordo sul tempo impiegato da un'attività, ma gli stessi due programmatori quasi concordare sempre quale attività è la più grande quando vengono mostrate due attività diverse.

Questa è l'unica competenza necessaria per "stimare" il tuo arretrato. Qui uso la parola "stima", ma in questa fase iniziale è più come ordinare l'arretrato da difficile a facile.

Inserimento di punti nel backlog

Questo passaggio viene eseguito con la partecipazione di tutto il team di Scrum.

Inizia a far cadere le storie una ad una in un nuovo foglio di calcolo mantenendo il seguente ordine: la più grande storia in alto e la più piccola in fondo. Fallo finché tutte le storie non sono nell'elenco.

Ora è il momento di mettere punti su quelle storie. Personalmente uso la scala di pianificazione del poker (1 / 2,1,2,3,5,8,13,20,40,100), quindi questo è ciò che userò per questo esempio. In fondo a quell'elenco probabilmente avrai delle micro-attività (cose che richiedono 4 ore o meno). Dai a ogni micro compito il valore di 1/2. Quindi continua l'elenco dando il valore 1 (successivo nella scala) alle storie fino a quando non è chiaro che una storia è molto più grande (2 invece di 1, quindi due volte più grande). Ora usando il valore "2", continua l'elenco fino a quando non trovi una storia che dovrebbe avere chiaramente un 3 anziché un 2. Continua questo processo fino in cima all'elenco.

NOTA: cerca di mantenere la stragrande maggioranza dei punti tra 1 e 13. La prima volta potresti avere un sacco di storie grandi (20, 40 e 100) e dovrai ridurle in blocchi più piccoli o uguale a 13.

Questo è tutto per i punti e l'arretrato originale. Se hai mai avuto una nuova storia, confrontala con quella lista per vedere dove si adatta (processo più grande / più piccolo) e dagli il valore dei suoi vicini.

Velocity & amp; Stima (pianificazione macro)

Per stimare quanto tempo ci vorrà per eseguire quel backlog, fare la prima pianificazione dello sprint. Rendi il totale dei punti collegati alle storie scelte dalle squadre e VOILA !, questa è la tua prima misura di velocità. È quindi possibile dividere il totale dei punti nel backlog per quella velocità, per sapere quanti sprint saranno necessari.

Quella velocità cambierà e si stabilizzerà nei primi 2-3 sprint, quindi è sempre bene tenere d'occhio quel valore