Come gestisci i requisiti in evoluzione? [chiuso]

13

Nel mio attuale lavoro sembra che abbiamo molti cambiamenti nei requisiti. Siamo un negozio "Agile", quindi capisco che dovremmo adeguarci e cosa no, ma a volte il cambiamento è grande e niente di banale.

La mia domanda è: come comunichi efficacemente il costo del cambiamento? A causa dell'essere agili, se una modifica è abbastanza grande qualcosa verrà eliminato dallo sprint corrente, ma di solito verrà aggiunto la volta successiva. Dal momento che il nostro modello è SaaS, il cliente finale è effettivamente l'azienda stessa e sa che otterrà la funzionalità n settimane dopo.

Immagino che quello che sto cercando di ottenere sia la rimozione di una funzionalità in realtà non è nulla da usare per la comunicazione poiché è stata solo ritardata di n settimane. In quali altri modi devi convincere l'azienda a capire cosa costa una modifica?

    
posta Joe 04.09.2010 - 18:17
fonte

4 risposte

13

@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

  1. X amount of time to complete with a 25% probability of failure (or 75% of success)

  2. 1.5 * X amount of time to complete with a 5% of failure (or 95% of success)

  3. 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.

    
risposta data 12.10.2010 - 19:36
fonte
8

Da quanto hai descritto, non hai problemi. Chiedono un cambiamento e sono disposti ad aspettare fino a quando tu dici che può essere fatto o sono disposti a rinviare un'altra funzione. Sembra un equilibrio tra: tempo, risorse e requisiti.

    
risposta data 15.09.2010 - 17:08
fonte
4

Potresti provare a impostare un'età minima di una nuova aggiunta / modifica (non applicabile alle correzioni di bug). Ad esempio, non è possibile elaborare nuove modifiche fino a 3 settimane.

Avere un'età minima di un'attività è bello perché all'inizio ogni attività sembra estremamente importante, ma se aspetti un po 'di tempo la sua importanza spesso diminuirà in modo significativo. A seconda dell'intervallo di tempo, ti darà almeno una quantità di tempo di stabilità nelle attività su cui stai lavorando.

Per rintracciare l'età, consenti alle attività di essere aggiunte a qualche elenco, ma non saranno considerate come attività su cui lavorare fino a quando quel periodo non sarà scaduto.

    
risposta data 04.09.2010 - 18:35
fonte
0

Questo è un problema molto comune, non importa quanto velocemente un progetto sta avanzando in termini tecnici, il cliente lo percepisce come molto più lento e si sente libero di cambiare i requisiti a loro piace pensare che gli sviluppatori non devono fare molto comunque.

Questa percezione imperfetta deriva da tre principali attività di sviluppo che consumano tempo e che non verranno mai spiegate correttamente dai clienti:

  1. Revisioni del codice / ripulitura: il vecchio codice diventa gonfio e incasinato e necessita di revisioni periodiche e pulizia, questo richiede molto tempo e il cliente non ci crederà mai.
  2. Controllo della sicurezza e correzioni: specialmente se hai membri junior del team avrai molti problemi di sicurezza legati al codice e vorresti passare regolarmente attraverso tutto quel nuovo codice che è stato scritto e riscrivere cose che non sembrano buone dal punto di vista della sicurezza, il cliente non conoscerà o non potrà mai contare per questa volta.
  3. Modifiche relative all'architettura: una base di codice in crescita può (e molto probabilmente lo sarà) in più punti richiedere un ripensamento strutturale e il refactoring può comportare: A - Modifiche / ottimizzazioni relative alle prestazioni (modifiche dell'algoritmo, sostituzioni di librerie, motori di cache, ecc.) O: B - Modifiche / ottimizzazioni relative alla produttività (leggibilità, riusabilità del codice, facilità di comprensione, nuove convenzioni di codifica, un nuovo framework, ... ecc.)

Nessuno dei precedenti sarà mai compreso e adeguatamente rappresentato dai clienti finali.

Fondamentalmente qualunque cosa non ha "viste" (elementi della GUI) non è stata fatta.

Chiamiamo questo il teorema di Projenix, haha no, sto scherzando: D

    
risposta data 19.01.2016 - 18:15
fonte

Leggi altre domande sui tag