@Joe "Siamo un negozio" Agile ", quindi capisco che dovremmo adeguarci e cosa no, ma a volte il cambiamento è grande e non banale."
Se il tuo processo non ti consente di controllare il tasso di variazione dei requisiti, il tuo processo non è agile, ma casuale. Agile non significa "prendere tutto ciò che mi capita".
Per controllare il cambio di requisito / creep puoi adottare - nel tuo processo - la nozione che un requisito non cambia (una nozione che sia il cuore di Scrum.) Trattare un cambiamento di requisito come sostituire un vecchio requisito con uno nuovo . È necessario disporre di un backlog di requisiti e l'utente deve scegliere quali 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) tra due settimane e consegnare la rimanente dopo. Scegli.
Ecco come negoziare con i clienti. Questo è il modo in cui comunichi il costo della modifica dei requisiti. Se il tuo gruppo non ha quel potere, non sei in un negozio agile, e non c'è nulla 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 dai progetti passati e presenti.
Raccogli la stima dell'orario 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 passati e richieste.)
Supponiamo di avere una metrica con cui puoi parlare con l'utente. Sapete che una nuova richiesta richiederà, ad esempio, 1K di 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 ai tuoi progetti passati (alcuni per linee di codice, alcuni per pagine web, alcuni per punti di funzione effettivi) e puoi stimare come ognuno di questi costi in termini di tempo di completamento assoluto. Per quelli con dati sufficienti, puoi anche identificare quei requisiti che tengono traccia di un conteggio degli sviluppatori effettivi.
Quindi lo usi e lo comunichi al cliente in base a dati storici; argomentate che i fallimenti del progetto tendono a seguire un seguito di distribuzione esponenziale; e quindi sei armato del seguente argomento per il tuo cliente:
Based on data from our past and present projects and available
resources, the requirement you are asking will take
X amount of time to complete with a 25% probability of failure (or
75% of success)
1.5 * X amount of time to complete with a 5% of failure (or 95% of success)
0.5 * X amount of time to complete with a 95% of failure (or 5% of success)
La probabilità di fallimento in funzione della quantità di risorse temporali in genere va al 95%, al 25% e al 5% (simile a una distribuzione esponenziale). Trasmetti il messaggio che una certa quantità di base fornisce una probabilità abbastanza decente di successo (ma con rischi reali). 1.5 di questo potrebbe dare quasi una certa probabilità di successo con un rischio minimo, ma molto meno di quello (0,5 delle garanzie originali quasi certo di fallimento).
Li hai lasciati digerire. Se vanno ancora per la proposta rischiosa ( fatto ieri! ) almeno hai scritto per iscritto che glielo hai detto. Se c'è speranza che il tuo gruppo non sia solo agile ma ingegnoso, il cliente potrebbe prendere seriamente in considerazione i tuoi numeri e pianificare di conseguenza queste e le richieste future.
Il tuo lavoro di ingegnere è quello di spiegare in termini ingegneristici, verificabili e chiari che richiedono modifiche non sono un pasto gratuito.