Mischia in un progetto a costo fisso

Question

Ho letto il manifesto agile e trascorro una buona giornata navigando sul Web alla ricerca di questa risposta elusiva. Ma purtroppo non ho avuto una risposta che avrebbe coperto tutte le basi.

Quando si guardano tutti i post dei blog e i notiziari dei predicatori Agile, si sente parlare di open scope o di aprire progetti "time". Come si applica a un progetto di costi fissi?

Da quello che ho scoperto il problema più grande è la gestione dell'ambito. Come si determina se qualcosa non è all'interno dell'ambito previsto e come si formulano argomenti per la propria decisione? A causa del modo agile con cui stai implementando il tuo software, non c'è un progetto dettagliato su cui discutere. Nella maggior parte dei casi hai solo una vaga lista dei desideri che il cliente ti consegna. Ed è così generale che puoi interpretare qualsiasi funzione in esso.

E con la crescente percentuale di progetti a costi fissi mi sembra un problema reale.

Quindi le domande sarebbero:

• Come si fa a gestire la portata in un progetto di costo fisso?
• Come si determina se le funzioni desiderate sono al di fuori dell'ambito originale?

Answer 1

Scrum non sostituisce i requisiti appropriati, o anche i rilasci occasionali o le pietre miliari. Piuttosto, ti dà un mezzo per mantenere la tua squadra produttiva e concentrata, ed evita gli effetti collaterali sprecati nel tempo di un processo a cascata.

In effetti, uno dei maggiori vantaggi di un processo agile come Scrum è che ti fa "fallire rapidamente e rumorosamente" su aree problematiche del tuo progetto. Se, dopo un paio di sprint, la tua squadra non è ancora in grado di stimare il tempo e le risorse necessarie per implementare una particolare funzionalità, potrebbe valere la pena di tornare indietro sui requisiti in quella zona - potrebbe essere necessario chiarire, semplificare, o rottamato del tutto. In un tradizionale processo a cascata, tuttavia, queste "caratteristiche del problema" possono spesso essere riportate indietro all'ultimo minuto possibile, con il risultato del consueto effetto di morte e insufficienza di consegna in cui la maggior parte dei progetti devolve.

Tuttavia, il ruolo del Product Owner è ancora più critico nei team che utilizzano Scrum e che hanno una vasta serie di requisiti. Lasciati ai propri dispositivi, la maggior parte dei team di sviluppo si concentrerà sulle funzionalità più interessanti/divertenti/geek (API di servizio, memorizzazione nella cache, ricerca) e lascerà le cose "disordinate" come il processo di pagamento, il design UX e i18n fino all'ultimo minuto . Una voce utente forte è essenziale per garantire che le funzionalità essenziali per l'utente finale ricevano la loro giusta dose di attenzione.

Answer 2

Ho risposto di recente a similar question on SO. Potresti trovare utile la risposta.

Answer 3

Ok, questa non è la risposta ideale che stai cercando, ma può aiutare non-meno.

Per il primo punto:

Con agile, e Scrum in particolare, lo stile è adatto verso il cambiamento specifiche e le scadenze non fissate utilizzando modelli di iterazione. Essere in grado di gestirlo in un progetto a portata fissa sarà un incubo. Quello che si farebbe normalmente è impostare un budget per l'ambito specificato e qualsiasi aggiunta a questo produrrebbe ore fatturabili al di sopra e al di là del budget dell'ambito. Fare ciò in Scrum sarebbe inutile, poiché il backlog del prodotto sarà continuamente riempito dagli stakeholder. Se non ci sono "punizioni" per i cambiamenti di scope in un budget fisso, non ci sarà nulla che trattiene le persone dal semplice caricamento a voi.

L'alternativa è di avere fissato portata successioni sprint, così per esempio:

5x Sprints = x Cost with minimal scope change.

Per il secondo punto:

L'uso di Analisi e Design è uno strumento prezioso. Utilizzando casi d'uso, tabelle degli eventi, diagrammi di sequenza, macchine a stati e simili; a lungo termine ti risparmierai gli oceani di lacrime. Fondamentalmente, una volta completata la pianificazione, qualsiasi aggiunta a questa che richiede ulteriori (si prega di notare ulteriori, non le cose che sono state trascurate), i casi d'uso e le modifiche al codice di grandi dimensioni saranno fuori portata. In realtà, tutto ciò che non è stato trascurato nella pianificazione e non è nelle specifiche, è fuori dall'ambito.

In chiusura, sarà necessario disporre di una documentazione molto ben pianificata e di accordi molto solidi con i propri clienti per poterlo togliere al 100%.

Spero che questo aiuti.

Answer 4

Ho lavorato in un ambiente in cui avevamo costi fissi e progetti a tempo fisso. Siamo passati a una metrica Scrum-esque da una metologia Waterfall/VModel. Scrum può funzionare molto bene in progetti a costi/tempi fissi in quanto il concetto è che il cliente è messo sotto controllo, tuttavia per farlo funzionare bisogna essere in grado di determinare in modo un po 'preciso il lavoro richiesto e quanto costerà (tempo, denaro , risorsa). E questo è un situtation in cui Scrum è candidato ideale.

Si abbattono la lista dei desideri/requisiti/schermate in documenti attendibili. Per esempio. un cliente può dire "Voglio l'e-commerce, con Paypal", è necessario suddividerlo in risultati reali, ad es. "1. Registrazione e accesso cliente, 2. Catalogo prodotti, 3. Shopping Bag, 4. Pagamento, 5. Ordine di conferma". In questa fase, è ancora impossibile determinare quanto tempo ci vorrà, e ofc abbiamo bisogno di fornire tutto quanto sopra per completare il progetto (cioè non puoi avere e-commerce senza pagamento). Quindi, abbattili di nuovo, e di nuovo, fino a quando non avrai risultati tangibili, veramente deleteri entro poche ore, forse giorni, ma certamente non settimane, ad es.

1 Catalogue 
1a View all Items 
1ai View all items on 1 page with an image and item name underneath in a grid, 4 items per row 
1aii View 10 items per page with paging 
1aiii View a user slected number of items per page, with paging 
1aiiii View all items on 1 page with an image and item name, descriptioon and price on the same line, 1 item per row 

1b View by Category 
... 
1c Search 
... 
1d Attribute Filter 
... 

E così via, può essere fatto molto rapidamente, e si può ora probabilmente guesstimate quanto tempo ci sarebbe voluto todo x (OFC, potrei rompere il sopra giù ancora di più, aggiungere un testo più descrittivo per descrivere la il lavoro richiesto, come ad esempio le strutture di dati persistenti di cui Ill potrebbe necessitare, i dati in quelle strutture, come verranno aggiunti i dati, andando oltre si potrebbe persino definire gli stati di inizio e di uscita richiesti).

Una volta fatto questo, si noterà che alcune funzioni e il depenant su altri, e..g non si può avere funzionalità di paging su un catalogo a meno che non si disponga di un catalogo per iniziare con witj, e il catagloge richiedere al CMS screesn di aggiungere e modificare elementi ecc. ecc. Evidenziare questi 'non possono vivere senza funzionalità' in qualsiasi strumento tu usi e questo costituisce il progetto principale, e in un giorno o due hai un sacco di funzioni che possono essere sviluppate un po 'standalone, con costi, che sommati fanno il costo del progetto. E ora il cliente è al comando, decidono di voler aggiungere una funzione e aumentare il costo, a suo avviso, dopotutto.

Tutto quanto sopra è ovviamente solo una piccola parte di ciò che è scrum o qualsiasi processo agile.

Answer 5

Non penso che un contratto a prezzo fisso con scope creep e un processo Scrum siano incompatibili. Hai solo bisogno di concordare con il tuo cliente come funzionerà.Se si crea il backlog iniziale con il cliente, stimando mentre si procede, è possibile utilizzarlo come base per il costo e il programma a prezzo fisso. Puoi anche accettare un tasso di punti della storia "X" uguale al costo "Y" e al programma "Z" all'inizio.

È poi fare il normale cosa mischia, avendo il cliente allocare storie per l'iterazione corrente, ecc

come il cliente si impegna in scope creep, si lavora con loro per aggiungere il "creep", come le storie degli utenti a l'arretrato. Ogni volta che aggiungi una nuova storia, fai notare che per ogni X punti aggiunto al backlog, dovranno aumentare i costi di Y e programmare per Z, oppure dovranno rinunciare a punti storia di uguale valore. Dal momento che stanno selezionando ciò che si lavora ogni iterazione, i punti che rinunciano (se questa è la scelta) saranno le funzionalità meno preziose. Quando il tuo programma termina, ti verrà lasciato un backlog delle funzionalità meno importanti che possono scegliere di abbandonare o di darti un nuovo contratto da finire.

Il trucco, naturalmente, è di essere bravo a stimare costi e tempi per ogni storia/compito ;-)

Answer 6

Il progetto potrebbe essere suddiviso in parti più piccole e tassi fissi potrebbero essere apposti su quelli. Le altre fasi del progetto potrebbero quindi essere modificate.

Devi essere in grado di vendere il processo agile contro i tuoi concorrenti. Se un cliente ha una storia di progetti di offerte fisse consegnati in tempo, specifiche e costi, perché sprecare il proprio tempo prendendo offerte da altri sviluppatori?

Answer 7

Per me, la risposta breve su Agile e il prezzo fisso è che non è possibile farlo, almeno non con un ambito fisso.

So che alcune persone diranno "che non è vero, lo stiamo facendo", ma, con tutto il rispetto, non credo che stanno realmente facendo agile e ti spiego il perché. In realtà, la spiegazione è piuttosto semplice: il prezzo fisso implica un ambito fisso e si basa sulla prevedibilità in cui Agile si concentra sull'ambito della variabile, sulla gestione dell'ambito e sull'adattabilità. Quindi il prezzo fisso con ambito fisso è sostanzialmente l'opposto di Agile.

Con un approccio Agile, il prezzo fisso offre un numero di iterazioni per una determinata dimensione della squadra. Durante queste iterazioni, il cliente sarà in grado di fare in modo che il team costruisca prima le caratteristiche più preziose e quindi di massimizzare il valore aziendale generato. L'idea è quindi quella di interrompere l'iterazione quando il costo di un'iterazione è maggiore del valore generato. Ecco come funziona Agile.

Così quando le persone dicono di fare un prezzo fisso con scope fisse in modo agile, introducono effettivamente alcuni vincoli che non sono realmente compatibili con la teoria di Agile - come fare una stima anticipata di un determinato set di funzionalità e il congelamento queste caratteristiche e stime - e perdono importanti vantaggi di Agile (a meno che non abbiano una perfetta conoscenza delle tecnologie e del dominio aziendale e li padroneggiano abbastanza da prevedere tutto ma conosco pochi progetti simili a questo).

Ecco comunque una buona raccolta di vari contratti Agile: 10 Contracts for your next Agile Software Project che potrebbero essere utili. Ma penso che tutti richiedano una certa formazione dei clienti, in particolare quella che viene utilizzata per fissare il prezzo con ambito fisso (e consegne in ritardo).

Answer 8

Fixed Cost non significa singolo sprint. L'ambito viene trasferito al Product Backlog e, mentre gli Sprint avanzano, l'ambito viene regolato, negoziato e consegnato. Scrum consente una consegna rapida dei valori e fornisce una rapida convalida e l'opportunità di identificare il potenziale placcatura in oro.

La modifica dell'ambito può comportare l'aggiunta di elementi arretrati e la cancellazione di altri.È un bilancio del ROI rispetto al budget fisso fornito.

Se la portata non aumenta (e aggiungere valore), e il costo è fisso, quindi il vincolo tripla (costo, durata e portata) deve essere gestito di conseguenza.

Ricordate che il costo fisso non significa lunghezza fissa.