Requisiti e documentazione in Agile

Question

Requisiti e documentazione in Agile

#1 da (3 voti)
#2 da (3 voti)
#3 da (2 voti)

2

La mia azienda ha recentemente iniziato a intraprendere progetti di sviluppo software più piccoli. Applicazioni web tipicamente piccole da utilizzare sulla intranet di un cliente. Di solito sono 3-5 mesi di lavoro in totale.

In genere, il cliente non sa cosa vuole esattamente, quindi ci paga per progetti più piccoli (3-4 settimane) per raccogliere i requisiti e scrivere un design funzionale. Una volta che è stato approvato, entrambi sappiamo cosa è voluto e possiamo citare per il resto del progetto e continuare. Questo perché preferiscono avere contratti a prezzo fisso piuttosto che pagare tempo e materiali.

Questo sviluppo si presta molto bene a un modello a cascata, raccogliamo requisiti, progettiamo, implementiamo, testiamo, forniamo. Tuttavia, nonostante ciò, a volte arriviamo alla consegna e il cliente dice "non è quello che intendevo".

Il mio istinto è di assicurarmi di avere un design più dettagliato in anticipo, ma mi viene detto che dovremmo essere "più agili" e sviluppare in modo iterativo il sistema con il cliente in modo che possano vederlo svilupparsi e possiamo avere problemi con aspettative precedenti.

Sto facendo fatica a vedere come adattarlo a un modello a prezzo fisso. Come posso stimare un progetto quando il cliente non sa nemmeno cosa vuole? Vedo che lo sviluppo Agile sarebbe utile in questo scenario, ma non con un prezzo fisso.

Mi manca qualcosa?

estimation agile development-methodologies

posta A Jackson 12.11.2015 - 12:14

fonte

3 risposte

Leggi altre domande sui tag estimation agile development-methodologies

Come mostrare l'operazione di cancellazione nel diagramma di contesto DFD? Implementazione di un modello aziendale pay-per-user

score 3 · Answer 1

L'importante è concordare ciò che verrà consegnato e quindi crearlo in una serie di sprint di 2 settimane - sviluppi a cascata minima se lo farai.

Se il cliente non è chiaro su come funzionerà qualcosa, va bene, ma non dovrebbe essere impegnato nello sprint di sviluppo in quanto non può realisticamente avere uno sforzo di sviluppo accurato ad esso assegnato. Metti insieme alcuni wireframe e elimina prima i problemi.

Può essere allettante pensare che sapere ciò che il cliente vorrà dato che si tratta di contanti in banca ma se alla fine dello sprint (s), il cliente non è ancora felice, poi ti hanno superato un barile. Nella loro mente, hanno pagato per la funzionalità e lo sviluppo dovrebbe progredire fino a quando non viene fatto. Questo scenario da incubo deve essere evitato a tutti i costi. Ho lavorato su uno sviluppo di medie dimensioni in cui l'account manager ha accettato ciò che il cliente ha definito "alcuni report semplici" senza esaminare i dettagli. Questi "semplici rapporti" hanno bruciato un terzo del nostro budget di sviluppo, nonostante avessimo inizialmente un 1/10 preventivato. Spiega al cliente che sei disposto a lanciare progetti finché non sono felici, ma impegnati solo nello sviluppo una volta che hai un'idea precisa di ciò che è richiesto.

Se il processo di progettazione sembra richiedere un po 'di tempo, allora con tutti i mezzi avrai anche una serie di sprint paralleli. Il cliente può decidere, alla fine dello sprint, che non è chiaro cosa è richiesto e quindi potrebbe buttare via l'idea, o meglio - sarà stata in grado di restringere ciò che esattamente volevano sfoglia il prossimo sprint.

score 3 · Answer 2

Il semplice fatto è che non riesci a soddisfare un modello a prezzo fisso: fai progettazione, codice e consegna ans, quindi il cliente dice "oh no, vogliamo che sia diverso" e cosa fai poi? Caricali extra per il nuovo lavoro o completa le modifiche gratuitamente?

Agile cambia semplicemente il modello di sviluppo per far fronte a questo problema, i tuoi prezzi sono o dal tempo trascorso o dalla data di consegna fissa. Nel primo caso, continuate finché il cliente non è felice, nel secondo continuate finché non si esaurisce il denaro. (questo è uno dei motivi per cui devi sempre avere qualcosa di deliverable alla fine di ogni timebox, potrebbe non essercene un altro)

Si spera che agilmente si possa arrivare a completare più lavoro in quanto la cattura dei requisiti è più economica (come iterativa e richiede una documentazione e un signoff meno completi) in modo che il client ottenga ciò che desidera più rapidamente. Questa è l'idea .. ma secondo la mia esperienza, il cliente non è mai soddisfatto e quindi finisce per pagare di più (in un sistema di fatturazione speso) senza accorgersene .. il che semplifica sempre la gestione: -)

score 2 · Answer 3

Se il cliente sta pagando bene per un progetto di 3-4 settimane, dovrebbero pagare bene per un progetto di 2 settimane. E poi il prossimo progetto di 2 settimane. E poi il prossimo. E il prossimo e così via. E alla fine di ognuno di questi progetti, dai loro un'applicazione semi-finita e chiedi loro cosa manca o cosa è sbagliato. Chiedi anche cosa è più importante da ciò che manca o che non va, quindi può essere incluso nel prossimo progetto.