Deliverable in un progetto di sviluppo software

Come hai detto potrebbero verificarsi dei cambiamenti lungo il percorso, sarebbe possibile abbreviare il tempo di ciclo a solo 1-2 settimane e non aspettare fino alla fine di ogni mese? Questo darà all'utente qualcosa da vedere mentre sviluppi il software e anche l'utente può dare un feedback più velocemente. Questo farà loro sentire di vedere visivamente qualcosa cambiato, e di non vedere l'attesa nervosa alla fine di ogni mese. Quindi puoi fare una breve riunione per fargli sapere quali saranno i risultati per ogni settimana o due settimane. Questo perché penso che le piccole funzionalità non debbano essere l'intero mese da completare. Se l'attività è troppo grande, è possibile suddividerla e scomporla in quelle più piccole. Quindi gli utenti penseranno di aver visto molto più di quanto si aspettino.

E penso che il numero di versione sia la cosa che devi concordare con gli utenti. Variazioni più piccole lo chiamerei 1.1.1 e salirà ogni settimana a 1.1.2, quindi se la fine di ogni mese puoi sicuramente aumentare a 1.2 o 1.3.

Sulla base di quanto sopra hai un programma di lavoro. Questo lavoro include le specifiche, i requisiti tecnici e un prototipo.

In base a ciò mi aspetterei che i deliverable di maggio e agosto fossero una versione a fasi dell'applicazione / progetto con ogni versione basata sul prototipo in modo che a maggio l'applicazione / il progetto sarebbero completi al 25%, giugno 50% completo ecc.

Ovviamente entro il 25% completato a maggio alcuni moduli potrebbero essere completi al 100% e altri 0% completi.

Prima di uscire dai risultati finali per maggio e agosto, devi specificare quali aspetti / moduli della domanda / del progetto saranno completati ogni mese.

Sì, è possibile che sulla base di moduli consegnati / requisiti mutevoli che la versione possa essere spostata da 1.0 a 2.0, ma sarebbe più normale che le modifiche minori siano da 1.0 a 1.1 o 1.2 ecc.

Se a metà del progetto si verificano modifiche importanti della versione, è molto probabile che non sarà possibile completare il progetto in tempo con la funzionalità richiesta.