Come possiamo* fissare * le scadenze, per permetterci di lavorarci efficacemente, in modo agile?[chiuso]

Question

Chiuso. Questa domanda è off-topic.Attualmente non accetta risposte.

---

Vuoi migliorare questa domanda? Aggiorna la domanda quindi è sul tema per Stack Overflow.

Chiuso 2 anni fa.

Sto lavorando in un team che ha lavorato in modo coerente e abbastanza con successo in un approccio agile, e questo ha funzionato alla grande per il progetto attuale fino ad ora, per il nostro lavoro iniziale, mentre costruiamo il prodotto in modo incrementale.

Ora ci stiamo muovendo nella fase successiva di questo però, e la direzione è desiderosa di fissare alcune scadenze specifiche noi stessi, per quando saremo in grado di dimostrarlo e venderlo a clienti reali, nell'ordine di mesi.

Abbiamo un backlog abbastanza ben organizzato per ciascuno degli elementi di funzionalità che vorremmo includere e un buon senso della priorità di questi singoli bit di funzionalità.

La soluzione ingenua è quella di ottenere l'elenco minimo di storie che fornirebbero un prodotto dimostrabile, stimare tutti quelli individualmente, e aggiungerli e combinarli con la nostra velocità per ottenere una data, e annunciare che faremo una demo da allora.Ciò non lascia margine di manovra, e sembra probabile che si traduca in una crisi folle mentre ci avviciniamo al tempo della scadenza, che voglio disperatamente evitare.

Come miglioramento, vorrei aggiungere un rapporto di più storie opzionali per agire come contingenza o miglioramenti bonus, a seconda di come progrediamo, ma non abbiamo idea di quale rapporto sarebbe ragionevole, o se questo è l'approccio standard.

Sono anche preoccupato di dover stimare l'intero nostro backlog tutto in un colpo solo, in quanto sembra molto dispendioso in termini di tempo, e sembra probabile che scopriremo ulteriori informazioni nei mesi prima di arrivare a quella storia, che influenzerà le nostre stime.

Ci sono approcci raccomandati per affrontare la fissazione di scadenze per consentire un processo di sviluppo agile?La maggior parte delle informazioni che ho visto sembra essere in giro a gestire la situazione una volta che hai una scadenza fissa per colpire invece.Sarei anche interessato a qualsiasi letteratura pertinente o post di blog interessanti che coprano questo problema.

Answer 1

Per quanto riguarda la letteratura:il miglior libro che conosco per quanto riguarda la stima nel software è " Stima del software:Demistificare l'arte nera " di Steve McConnel.Copre il tuo caso.Inoltre, descrive la differenza tra stima e impegno (set-deadline, in altre parole) e spiega come derivare il secondo dal primo in modo affidabile.

Answer 2

La soluzione ingenua è quella di ottenere l'elenco minimo di storie che fornire un prodotto dimostrabile, stimare tutti quelli individualmente e aggiungerli e combinare con la nostra velocità per ottenere una data, e annunciare da allora faremo una dimostrazione.Che non lascia spazio però, e sembra probabilmente si tradurrà in uno scricchiolio pazzo mentre ci avviciniamo al tempo di scadenza, che Voglio disperatamente evitare.

Questa è la soluzione che ho usato in passato.La vostra stima iniziale sta per essere fuori un po 'in modo da aggiungere un po' di allentamento tramite un paio di sprint aggiuntivi prima di impostare la data di rilascio.Se si ottiene dietro si può fare in su nel gioco.In caso contrario, il tuo product backlog ti offre funzionalità aggiuntive che puoi includere nella versione se lo desideri.Questo dipenderà dalla tua metrica di velocità per la squadra.Regola il tuo slack in base a quanto ti senti preciso questa metrica è per il team corrente.Una volta che hai una release di destinazione puoi tornare indietro per vedere se hai dei vincoli di risorse noti che potrebbero influire su quella release.

Answer 3

L'approccio che descrivi è probabilmente corretto.Potresti voler stimare tutte le funzionalità desiderabili e dare priorità agli elementi dell'interfaccia utente (perché investitori e clienti fondamentalmente vedono solo l'interfaccia utente lucida), e quindi la scadenza sarà quella data stimata per il completamento;quindi aggiungi un po ' di allentamento sotto forma di ridimensionamento delle tue stime.Usa il rapporto tra la produttività attuale e il tuo periodo peggiore per creare una stima pessimistica.È possibile utilizzare lo stesso rapporto per ridimensionare stime più brevi (ad es.per la tua stima al set di funzionalità minimo).