@Joe "Siamo un negozio" Agile ", quindi capisco che dovremmo adeguarci e cosa no, ma a volte il cambiamento è grande e niente di banale."
Se il processo non consente di controllare il tasso di variazione dei requisiti, il processo non è agile, ma casuale. Agile non significa "prendere tutto ciò che mi viene incontro".
Per controllare il cambiamento / scorrimento dei requisiti puoi adottare - nel tuo processo - l'idea che un requisito non cambi (un concetto che è al centro di Scrum.) Tratta un cambiamento di requisito come la sostituzione di un vecchio requisito con uno nuovo. Devi avere un backlog di requisiti e devi fare in modo che l'utente scelga quali desidera implementare.
Volevi X e Y in due settimane, ma all'improvviso vuoi Z. Bene, allora posso consegnarti tutti e tre in 4 settimane. Oppure posso dare una coppia (X e Z) o (X e Y) o (Y e Z) in due settimane e consegnare quella rimanente in seguito. Scegliere.
Ecco come negoziare con i clienti. Ecco come comunicare il costo della modifica dei requisiti. Se il tuo gruppo non ha quel potere, non sei in un negozio agile e non c'è niente che tu possa fare al riguardo. Fa schifo, ma è vero.
Nel caso in cui sia possibile negoziare, è necessario tenere traccia (con precisione) del tempo necessario per implementare i requisiti e le modifiche dei requisiti. Cioè, devi raccogliere questi dati da progetti passati e presenti.
Raccogli la stima del tempo originale e il tempo di completamento effettivo (oltre alle risorse come il conteggio degli sviluppatori) per richiesta (o modulo interessato da N richieste). Meglio ancora, stimare la dimensione della richiesta / modifica della richiesta (in termini di righe di codice o punti funzione in progetti e richieste passati).
Supponi di avere una metrica con cui puoi parlare con l'utente. Sai che una nuova richiesta prenderà, diciamo, 1K righe di codice o 10 pagine Web con una media di 5 campi di input ciascuno (50 punti funzione).
Quindi, guardando i dati storici specifici dei tuoi progetti passati (alcuni per righe di codice, alcuni per pagine Web, altri per punti di funzione effettivi), puoi stimare come ciascuno di questi costi sia in termini di tempo di completamento assoluto. Per quelli con dati sufficienti, è anche possibile identificare quei requisiti che tengono traccia di un effettivo conteggio degli sviluppatori.
Quindi lo usi e dici al tuo cliente che sulla base di dati storici; Lei sostiene che i fallimenti del progetto tendono a seguire una distribuzione esponenziale; e poi sei armato con il seguente argomento per il tuo cliente:
Sulla base dei dati dei nostri progetti passati e presenti e delle risorse disponibili, il requisito richiesto verrà soddisfatto
X quantità di tempo per completare con una probabilità di fallimento del 25% (o 75% di successo)
1,5 * X quantità di tempo per completare con un 5% di errore (o 95% di successo)
0,5 * X quantità di tempo per completare con un 95% di fallimento (o 5% di successo)
La probabilità di fallimento in funzione della quantità di risorse di tempo in genere va al 95%, 25% e 5% (simile a una distro esponenziale). Trasmetti il messaggio che un determinato importo di base offre una probabilità decente di successo (ma con rischi reali ). 1,5 di questo potrebbe dare quasi una certa possibilità di successo con un rischio minimo, ma molto meno di quello (0,5 dell'originale garantisce quasi un certo fallimento).
Li lasci digerire su quello. Se vanno ancora per la proposta rischiosa ( fatta ieri! ) Almeno hai scritto che glielo hai detto. Se c'è speranza per il tuo gruppo di non essere solo agile ma ingegneristico, il cliente potrebbe prendere in seria considerazione i tuoi numeri e pianificare di conseguenza questa e le richieste future.
Spetta a te come ingegnere spiegare in termini ingegneristici, verificabili e chiari che richiedere modifiche non è un pasto gratuito.