Sviluppo software agile: come reagisci * finanziariamente * al cambiamento delle esigenze degli utenti?

In un mondo Agile ideale, accetti un prezzo in anticipo e un numero di ore, ma non . Il cliente decide quale sia il prodotto minimo utile, piuttosto che il prodotto che desidera realmente e che dovrebbe stimare bene a meno del numero di ore concordate.

Quindi li consegni in modo iterativo e cambiano idea tutto ciò che vogliono, ma non riesci mai a superare il numero di ore concordate. In teoria, e spesso nella pratica, si ritrovano con il prodotto di cui hanno veramente bisogno piuttosto che con il prodotto che vogliono veramente.

E se vogliono continuare a pagarti ore extra dopo il valore concordato originale, va bene lo stesso. Se fai un lavoro abbastanza buono da rendere visibili i progressi, attraverso le story card, Greenhopper o qualsiasi altra cosa, puoi rendere molto evidente al cliente quali caratteristiche stanno perdendo (o almeno deprioritising) ogni volta che aggiungono qualcosa di nuovo, che in gran parte mette una fermata ai cambiamenti frivoli.

Ci sono due rischi degni di nota qui. Il primo è che il cliente può essere spaventato, se non ha capito l'Agilità in anticipo. Sembra che si stia prendendo tutti i rischi. Solo l'esperienza dimostra che non lo è davvero.

Il secondo è che devono essere coinvolti, durante l'intero processo, o che tutti perderanno. Molti clienti non riescono a capire quanto devono essere impegnati finché non è troppo tardi.

Ma se tu, come azienda, lo spieghi abbastanza bene, ognuno è un vincitore.

Alcuni persone provato < a href="http://agilediary.wordpress.com/2009/01/16/scrum-and-agile-in-a-fixed-price-project-environment/"> a give soluzioni per utilizzare Agility in progetti a prezzo fisso in passato. Personalmente ritengo che generalmente non sia possibile.

Scrum in particolare è adatto per aziende di software di prodotto ed è meno utilizzato nelle società di servizi.

Puoi usare un po 'di agilità nei tuoi progetti, come iterazioni, stand-up giornalieri, burndorn, ecc., ma posso assicurarti che se offri una certa quantità di cose per un certo prezzo e ottieni meno di quello che c'era in il contratto, avrai un problema.

Per favore non servi Agility à toutes les sauces . Dobbiamo utilizzare la soluzione appropriata per un determinato problema.

Questo non è realmente correlato alla programmazione Agile o al modello che usi. Lavorando come freelance, utilizzo un mix di Waterfall e V-model, ma ho ancora lo stesso problema: cosa succede se il cliente vuole cambiare qualcosa durante la progettazione dettagliata? Cosa succede se apporta modifiche durante l'implementazione?

L'approccio che devi utilizzare dipende dal cliente e dalle tue relazioni.

Se un contatto è un must per tutto ciò che fai per questo cliente, perché sai che cerca di non pagare quando può, o cercherà di farti causa quando possibile, allora sì, devi scrivere un offrire per ogni piccolo cambiamento nei requisiti. Non è un disastro: se sei ben organizzato, potrebbe non essere troppo difficile soddisfare un nuovo requisito durante lo sviluppo. Ma di sicuro, è una perdita di tempo e denaro, ed è piuttosto strano dover firmare un'offerta per un cambiamento che richiederà due ore per l'implementazione.

Per gli altri clienti, l'approccio che funziona bene è il seguente:

• Quando si firma la prima offerta, specificare il costo stimato e il costo massimo. Il costo stimato non significa nulla legalmente: è solo una stima. Il costo massimo ha valore legale: se dici che il prodotto avrà un costo di $ 3.000 per il tuo cliente, e alla fine ti costa $ 3,157.24, il cliente dovrà comunque pagare $ 3.000. In pratica, nella maggior parte dei casi, il costo reale sarà inferiore al massimo consentito e più vicino alla stima.

• Quando il cliente chiede di modificare un requisito, stimare il costo che ha e confrontarlo con il costo e lo stato effettivi. Se hai quasi finito il prodotto e il costo reale è di $ 2.108,36 e il costo del cambiamento è stimato a $ 150, fallo e basta. Se, d'altra parte, c'è il rischio di raggiungere il massimo, allora dì al tuo cliente che devi rivalutare il costo complessivo insieme.

Agile e 'Scrivi un'offerta' sembra un'antitesi :) - il secondo non è un'ingegneria del software produttivo: D

Ok, ora che abbiamo tolto la battuta - torna alla realtà.

"Come funziona in Agile ?" - Il contratto complica le cose ma spero di chiarire. Agile si basa sul principio della "fiducia" e del "co-working", il che significa che al cliente è permesso di cambiare qualsiasi cosa, ogni volta e capisce che potrebbe costare un po 'di più o se non invadente, magari senza costi aggiuntivi. / p>

Che cosa significa? Significa che il contratto stabilisce che noi (il cliente) possiamo fissare una stima iniziale del costo e la percentuale di variazione +/- che possiamo gestire, ad es. Offerta di $ 100K ma sono disposto a salire a $ 120K (questo MAGGIO non fa parte del contratto, ma nella mente del cliente).

Ora, quando arriva un cambiamento di progettazione, vai agile con la stima e la pianificazione per - ottieni la tua squadra insieme e chiedi loro la stima del 'story point' w.r.t. complessità di factoring dei cambiamenti. A causa di una stima della velocità, è possibile moltiplicarli e fornire una stima del programma. Dovrebbe essere relativamente facile escludere il costo per story point se conosci la squadra e i relativi salari (per favore non fare la media su tutti gli stipendi di EVERYONE, coglierai l'errore delle medie).

Hai bisogno di tornare al cliente con i dati finanziari? NO. Non necessariamente. Avrai il cliente a dare la priorità a questi e inserirli nel posto giusto nel backlog. Ora che conosci la dimensione del backlog (dovresti se non lo hai già fatto) e in base ai dati finanziari (costo per story point) sai quali requisiti a bassa priorità potrebbero non essere fattibili con il dato budget. Mostra loro il backlog rinegoziato con la stima delle funzionalità realizzabili come da contratto $$. Quindi lascia che LORO decidano se sono disposti a pagare di più per ottenere di più se / quando arrivano. Se lo vogliono gratuitamente ... prendi una posizione e Digli che costerà di più.

Questo dovrebbe aiutare senza che tu torni costantemente con i finanziari se puoi avere questo grafico da qualche parte per il cliente da vedere.

Spero che questo aiuti!

L'esperienza delle altre persone probabilmente varierà, ma un modo in cui l'ho visto è in gran parte lo stesso del tuo "tradizionale" con un paio di cose da notare:

1. Compilare un sovraccarico per le modifiche (ad esempio 10%)
2. Valuta e fattura separatamente per grandi cambiamenti o aggrega e apporta modifiche oltre al costo integrato (un buon esempio, sebbene non di programmazione, è il lavoro di progettazione, dove spesso il costo iniziale include, per esempio 3 revisioni e successive revisioni o forse i rifacimenti totali sono extra)

Spesso, anche i progetti agili iniziano come un elemento "core" e si estendono da lì in modo modulare in base alle necessità (ho visto che questo è accaduto parecchio sui progetti che ho coinvolto con). Quindi, inizi con un prodotto principale, diciamo che è un'applicazione di mappatura. La prima implementazione è solo una mappa centrata sulla posizione corrente (ciò che il cliente inizialmente ordinava).

Il cliente decide quindi di volere dei pin di alcune attrazioni intorno a te. Ok, questo è un pezzo abbastanza grande (relativamente parlando), quindi lo si fattura come un nuovo "modulo" o ordine di acquisto. Le modifiche a cose come il colore o il design di quei pin sono integrate nel costo di quell'ordine. Le indicazioni e gli overlay sono un altro ordine di acquisto, poiché non sono stati richiesti fino a dopo l'altro ordine di acquisto in corso, e così via e così via.