Sviluppo software agile: come reagisci * finanziariamente * alle mutevoli esigenze degli utenti?

C'è una cosa che mi sono sempre chiesto quando leggevo di tutto questo "sviluppo agile" qui su SE e altri siti:

Nell'ingegneria del software "tradizionale", tu

1. raccogliere i requisiti dell'utente,
2. scrivere una specifica basata su questi requisiti,
3. darlo al cliente e fatturarlo per il lavoro svolto finora,
4. fare una progettazione (approssimativa) tecnica, in modo da poter stimare i costi di implementazione,
5. dare all'utente un preventivo per l'implementazione,
6. attendere che il cliente firmi le specifiche e accetti l'offerta,
7. progettare, implementare, testare,
8. conto.

Se, durante il processo, i requisiti cambiano, invii un'offerta (con un prezzo) per le modifiche desiderate (o lo fai gratuitamente se la modifica è piccola, ti piace il cliente e il cliente non lo fa troppo spesso) .

Quindi, come funziona (finanziariamente) in un progetto agile, in cui frequenti cambiamenti dei requisiti fanno parte del processo?

• Scrivi un'offerta per ogni modifica del design? (Non sarebbe un bel casino?)
• O negozia un prezzo fisso e speri che il cliente non cambi i requisiti troppo spesso? (Potrebbe essere rischioso, conosco i clienti che utilizzerebbero questa opportunità per richiedere nuove funzionalità per anni prima di accettare il completamento del progetto.)
• O addebitate semplicemente al cliente il tempo totale richiesto? (Potrebbe essere rischioso per il cliente, che non conosce il costo in anticipo.)

In un mondo Agile ideale, accetti un prezzo in anticipo e un numero di ore, ma non l' ambito. Il cliente decide quale sia il prodotto minimo utile, piuttosto che il prodotto che desidera veramente, e questo dovrebbe stimare ben al di sotto del numero di ore concordate.

Quindi consegnate loro in modo iterativo e cambiano idea tutto quello che vogliono, ma non superate mai il numero di ore concordate. In teoria, e spesso in pratica, finiscono con il prodotto di cui hanno davvero bisogno piuttosto che con il prodotto che desiderano davvero.

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

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

Il secondo è che devono essere coinvolti, durante l'intero processo, altrimenti tutti perderanno. Molti clienti non riescono a capire quanto devono essere coinvolti fino a quando non è troppo tardi.

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

Alcune persone hanno tentato di fornire soluzioni per utilizzare l'agilità in progetti a prezzo fisso in passato. Personalmente penso che generalmente non sia possibile.

Scrum in particolare è adatto per le società 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 a un certo prezzo e consegni meno di quanto previsto dal contratto, avrai un problema.

Per favore, non servire Agility à toutes les sauces . Dobbiamo usare la soluzione appropriata per un determinato problema.

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

L'approccio che devi usare 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 ogni volta che è possibile, allora sì, devi scrivere un'offerta 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 essere implementato.

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 costerà $ 3.000 per il tuo cliente e alla fine ti costerà $ 3.157,24, il cliente dovrà comunque pagare $ 3.000. In pratica, nella maggior parte dei casi, il costo reale sarà inferiore al massimo indicato 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 della modifica è stimato a $ 150, fallo. Se, d'altra parte, c'è il rischio di raggiungere il massimo, quindi dire al cliente che è necessario rivalutare il costo complessivo insieme.

Agile e "Scrivi un'offerta" sembra un'antitesi :) - quest'ultima non è un'ingegneria del software produttiva: D

Bene, ora che abbiamo la battuta fuori dai piedi - torniamo alla cosa reale.

"Come funziona in Agile ?" - il contratto complica le cose ma spero di chiarirlo. Agile è fondata sul principio di "fiducia" e "collaborazione", il che significa che al cliente è consentito cambiare qualunque cosa, ogni volta e comprende che può costare un po 'di più o se non invadente, forse senza costi aggiuntivi.

Cosa significa questo? Significa che il contratto stabilisce che noi (il cliente) fissiamo una stima iniziale del costo e la +/- varianza% che possiamo gestire, ad esempio un'offerta di $ 100.000, ma sono disposto ad aumentare fino a $ 120.000 (questo MAGGIO non può essere parte del contratto, ma nella mente del cliente).

Ora, quando arriva un cambiamento di progettazione, si diventa agili con la stima e la pianificazione - si riunisce il proprio team e si chiede loro la stima del "punto di storia" rispetto alla complessità del factoring delle modifiche. A causa di una stima della velocità, è possibile moltiplicarli e fornire una stima del programma. Dovrebbe essere relativamente facile scovare il costo per punto storia se conosci la squadra e i loro salari relativi (per favore non fare la media attraverso lo stipendio di TUTTI, cederai al difetto delle medie).

Devi tornare dal cliente con i dati finanziari? NO. Non necessariamente. Avrai il cliente la priorità di questi e inserirli nella posizione corretta nel backlog. Ora che conosci le dimensioni del backlog (dovresti farlo se non lo hai già fatto) e in base ai dati finanziari (costo per punto storia) sai quali requisiti a bassa priorità potrebbero non essere realizzabili con il budget dato. MOSTRARE loro l'arretrato ridimensionato con la stima delle funzionalità realizzabili come da contratto $$. Quindi lascia che decidano se sono disposti a pagare di più per ottenere di più se / quando ci arrivano. Se lo vogliono gratis ... prendi posizione e DIRE loro che costerà di più.

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

Spero che sia di aiuto!

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

1. Integrare alcune spese generali per le modifiche (ad esempio il 10%)
2. Valutare e fatturare separatamente grandi cambiamenti o modifiche aggregate e di fatturazione oltre il costo integrato (un buon, sebbene non di programmazione, ad esempio è un lavoro di progettazione, dove spesso il costo iniziale include, diciamo 3 revisioni, e le revisioni successive o forse le ripetizioni totali sono extra)

Spesso, anche i progetti agili iniziano come un elemento "core", e da lì escono in modo modulare secondo le necessità (ho visto che ciò accade un po 'sui progetti con cui sono stato coinvolto). 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 ha ordinato).

Il cliente decide quindi di voler disporre di spille di alcune attrazioni intorno a te. Va bene, è un pezzo piuttosto grande (relativamente parlando), quindi lo fatturi come un nuovo "modulo" o un 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 quando non è stato avviato l'altro ordine di acquisto, e così via e così via.