Ambito e risorse fissi - ma mi viene richiesta una data di rilascio esatta [duplicato]

Sono un po 'perplesso; per favore portami con me Mi sembra che tu ti trovi in una situazione ideale che la maggior parte dei direttori di sviluppo può solo sognare! Hai fissato il campo di applicazione (chi ha visto in questo giorno ed età i requisiti aziendali in costante evoluzione ?!), hai un team dedicato (idem!) E hai esperienza di lavoro con il team - quindi la loro velocità è conosciuta / generalmente compresa .

Se la velocità è nota, deve già tenere in considerazione la qualità che possono fornire, la quantità di rilavorazione che potrebbero aver dovuto fare in passato, e il tasso di consegna "netto" o "velocità netta". Davvero non puoi fare molto su questioni impreviste fin d'ora - eccetto per provvedere a un po 'di contingenza - che, idealmente, potresti essere in grado di fare da esperienze passate con piani di progetto e superamenti. Forse l'ambito potrebbe espandersi. Oppure un membro del team potrebbe ammalarsi per una settimana o due. Un contingente di pianificazione del 10-20% potrebbe essere in ordine.

Quindi dov'è il problema? Oppure mi sfugge qualcosa? Di quali possibili incognite sei preoccupato? Penso che dovrebbe essere possibile per te - in base al tuo piano di rilascio / sprint - prevedere una data di completamento, con un fattore di contingenza (o un fattore di confidenza per una data specifica).

Finché fornisci una motivazione generale, non sono sicuro di quali obiezioni potrebbero suscitare il tuo Product Owner o altri rappresentanti di gestione per il piano che fornisci. Chiedono una data fissa, ne prenderanno una, con un po 'di contingenza lanciata.

Non sono sicuro che questo ti possa aiutare - dal momento che è tutto abbastanza ovvio - ma spero che lo faccia.

Sono d'accordo con il suggerimento di @ Frank - continui a dare priorità al proprietario del prodotto - dando loro il vantaggio della possibilità di cambiare idea su alcune delle priorità - e in effetti anche di eliminare del tutto alcune cose - aggiungendo nuove cose nel backlog, mantenendo l'ambito generale invariato in generale. Uno dei principi chiave di Kanban, di cui io sono un grande sostenitore, è la capacità di ridefinire le priorità fino all '"ultimo momento responsabile", concentrandosi sulle cose più importanti in qualsiasi momento, consegnando spesso e aiutando il cliente a ottenere l'importante roba in tempo.

Triage l'ambito, in modo che le caratteristiche / i requisiti più importanti siano completati per primi. Rendi il progetto "sbloccabile" almeno ogni settimana, in modo che se i tuoi fondi sono tagliati a metà, non hai un fallimento completo.

A proposito, questa è una pratica standard per manager / responsabili dello sviluppo con esperienza, poiché è raro finire tutto entro la scadenza, se la scadenza è fissa e ottimistica.

Sei uno sviluppatore di software! Non rispondere alle domande fuorvianti! Invece, aiuta il tuo manager a porre la domanda giusta. Quindi, rispondi alla bella domanda.

Quando sarà pronta la mia funzione? è una domanda fuorviante. Esempi di buone domande sono:

1. Qual è la probabilità di avere la mia funzione in tre mesi ?
2. Qual è la data entro cui la mia funzione sarà pronta con una probabilità del 70% ?

Ora, come risponderesti a queste domande una volta che ti saranno poste? Bene, dovrai utilizzare i tuoi record per costruire una distribuzione di probabilità empirica della variabile casuale DevTime . L'ho fatto io stesso e ho scoperto che le distribuzioni di Lognormal hanno un adattamento eccellente.

Una distribuzione Lognormal ha due parametri: media e deviazione standard. In alternativa puoi definirli fornendo significato e dispersione P90 / P10.

Ci sono molti approcci per trovare buone stime della media e della dispersione. Se hai dati di altri progetti con un ambito simile, usali e usa un algoritmo di adattamento della curva (ad es. BoxCox.)

Se vuoi essere più rigoroso, dovrai creare un modello che tenga conto dei seguenti fattori incerti :

1. Dimensioni del progetto
2. Focus -% risorse che assegnerai per il progetto (hai altre attività, giusto?)
3. Endurance -% di righe di codice integrate che sono sopravvissute, ad esempio > = 6 mesi
4. Velocità - Linee di codice (o # classi) prodotte dal team / giorno.

Per la dimensione ho usato il numero di classi coinvolte come proxy, ho collocato una distribuzione triangolare attorno ad essa e ho moltiplicato questa variabile casuale per la distribuzione (empirica) di # menthods / classe.

L'attenzione è più semplice, vorrei iniziare con il 40%. Puoi utilizzare questo parametro per negoziare con il tuo manager.

Quello che ho chiamato resistenza è misurabile dai tuoi dati storici. Ancora, non usare una media, calcola la distribuzione empirica di probabilità di questa quantità.

Lo stesso per la velocità.

Con tutte queste distribuzioni è abbastanza facile costruire un modello probabilistico ed eseguire Monte Carlo su di esso. Ciò ti darà i valori di media e dispersione che stavi cercando.

Una volta che hai la distribuzione, tracciala e insegna al tuo manager come leggerla. La risposta a tutte le domande che hanno senso sarà proprio lì.

Se non hai dati, o non hai tempo e amp; risorse per costruire il modello che sto proponendo, quindi giocare con le migliori stime "esperte" della media e della dispersione e utilizzare alcune app per tracciare la distribuzione Lognormal risultante. Una volta che ti senti sicuro con una curva, usa quella per le tue stime da uomo povero.

Bottomline: non rispondere a domande sciocche. Trasformali in buoni che forniranno approfondimenti.