In mischia, come si fornisce una stima per un articolo arretrato che è principalmente di ricerca?

se non riesci a stimare - e in questo scenario sembra che non ci sia davvero modo di sapere in anticipo quanto tempo impiegherà una parte particolare del processo - quindi l'opzione successiva migliore è quella di time- box lo sforzo: quanto tempo sei disposto a spendere per questo, indipendentemente dal fatto che tu arrivi ovunque o meno

una volta entrati, potresti avere un'idea migliore di come stimare lo sforzo rimanente

Incredibilmente semplice: è sempre 3 punti.

(o scegli una costante diversa). Questo è l'approccio che abbiamo preso nel nostro ultimo lavoro e penso che abbia funzionato relativamente bene.

L'idea è che tu abbia un backlog pieno di storie reali e una di queste è una storia di integrazione con un dispositivo di cui non sai nulla. Se qualcuno mi chiedesse di ridimensionare quella storia (effettiva integrazione) senza ulteriori conoscenze, darei una stima molto prudente. Se facessi integrazioni simili in passato, potrei scegliere un punto della storia in una fascia alta. Se non avessi mai fatto un lavoro simile e non sapessi nemmeno da dove iniziare, selezionerei solo un milione di punti.

Quindi, ovviamente, il proprietario del prodotto torna e dice che non possiamo avere un milione di punti, quindi creiamo un'altra storia sulla ricerca. L'obiettivo della ricerca non è codificare l'integrazione. Non si tratta di risolvere ogni possibile problema che potresti incontrare. L'obiettivo primario e solo della storia di ricerca è quello di fornire una migliore stima del punto per la storia del lavoro reale. Non perderti cercando di capire come utilizzare ogni singola chiamata API e trovare un vero design / codice di integrazione. Invece, affrontalo da un livello elevato per capire la complessità che ti precede.

Alla fine della storia della ricerca, il tuo prodotto n. 1 (insieme a possibili note di ricerca, prototipi, ecc.) è una stima puntuale dell'integrazione e, eventualmente, la rottura della storia di integrazione in diverse parti più piccole. Tieni presente che ognuno di questi ha ancora un componente sconosciuto a fronte di una ricerca sufficiente, dovresti essere in grado di controllare per quella parte sconosciuta (ad esempio hai letto sull'utilizzo di alcune API e sembra che saranno 5 punti, beh, scegli 8) per sicurezza)

Quello che abbiamo scoperto è che lo sviluppatore assegnato al compito di ricerca ha sempre esaurito il vapore a quasi un numero costante di ore (ovviamente c'è qualche fluttuazione, ma alla fine ha una media). Dopo potrai spendere il doppio delle ore, ma la stima della tua storia di integrazione non migliorerà.

Ecco perché li chiamano preventivi.

È improbabile una stima accurata per il lavoro puramente correlato alla ricerca. Questa è la natura della ricerca. Ma penso che valga la pena sottolineare che a volte pensi di non poterlo stimare, quando in realtà puoi farlo. Gli scienziati lo sanno; la maggior parte del lavoro di ricerca è ripetitivo e banale ... è la teorizzazione e i cambiamenti di direzione che causano variazioni nel tempo necessario per verificarsi.

Quindi il modo in cui ottieni una stima per il lavoro relativo alla ricerca è lo stesso con cui ti viene proposta una stima per lo sviluppo ordinario: suddividi l'attività in parti più piccole e valuta ciascun pezzo separatamente. Il lavoro di ricerca non è diverso a tale riguardo dallo sviluppo ordinario, non di ricerca; quantifica il lavoro e poi dai la tua ipotesi migliore.

Ad esempio, potresti non essere in grado di stimare l'attività "Determina come funziona questa scatola nera e come interfacciare il nostro software con esso." Ma potresti essere in grado di fornire stime indipendenti per:

1. Valuta e comprendi l'API della scatola nera
2. Valuta i comportamenti della scatola nera
3. Determina quali comandi eseguiranno i comportamenti che vogliamo
4. Analizza, identifica e attenua possibili problemi di sicurezza
5. Gestisci i comandi dal nostro software ai comandi nella casella nera e valuta i dati restituiti.

E così via.

Alcune stime possono dipendere dal completamento dei passaggi precedenti. Ad esempio, la stima del passo # 3 potrebbe non essere possibile fino al completamento del passo # 2.

Le stime non sono numeri singoli. Una stima è un intervallo che ha una fascia alta, una fascia bassa e una sicurezza. Con la domanda iniziale di "quanto tempo ci vorrà" una stima non è "mi ci vorranno 14 ore", ma piuttosto "mi ci vorranno tra 10 e 18 ore".

Mentre raffini il processo, puoi ottenere un intervallo più stretto e più stretto sulla stima

link

Si noti che questo mostra la variabilità della stima, non che "converge alla media". Una stima può iniziare a "mi ci vorranno 10 a 18 ore" e quindi essere "ci vorranno 14 a 18 ore" e poi "ci vorranno 16 a 18 ore" come si ottiene più avanti nel compito.

Uno dei libri più citati nella stima è Stima del software: Demistificazione della Black Art di Steve McConnell.

Inizia con una stima molto ampia che presenta il caso migliore e il caso peggiore. Poi a breve nella ricerca, fai un'altra stima, e poi un'altra e un'altra. Non impegnarsi quando sarà fatto con un numero e poi provare a farlo.

Esistono diverse tecniche per generare una stima. Utilizza i dati storici da stime precedenti. Cerca di farti un'idea di quanto è grande, la complessità e il lavoro da fare (la lista continua, c'è un intero libro scritto su questo).

Due modi in cui sto utilizzando:

L'approccio di scoperta deliberata : inizia con due storie (in ordine inverso):

• quanto tempo hai bisogno di capire il sistema
• quanto tempo hai bisogno di stimare quanto tempo hai bisogno per capire il sistema - tieni quello molto breve di proposito

La chiave è che ognuno di questi è limitato dal valore della funzione. Non ha senso passare un anno a capire un sistema per consegnare la caratteristica X, se nella metà di quel tempo si potrebbe fornire la caratteristica Y e Y ha più valore aziendale. Il tuo PO dovrebbe essere in grado di darti un numero: "se hai bisogno di più di due mesi per capirlo, non ne vale la pena". Affina la stima per la prima storia quando completi la seconda.

L'approccio Discover as you go :

how to get our product to interoperate with a very complex black box that we did not develop.

Questo è il modo di fare una grande storia. Qual è la prima cosa / funzione / aspetto su cui lavorerai (quale è il più prezioso?). Potrebbe essere semplice come 'accedere alla scatola nera'. Questa è una storia semplice, i punti di integrazione non dovrebbero essere così male ed è ragionevolmente facile da stimare con una ricerca minima. Stimare quello. Metti qualsiasi altra storia al suo limite di valore aziendale e perfeziona man mano che impari di più.

Entrambi gli approcci sono problematici per quanto riguarda la pianificazione a lungo termine. Quando inizi, non puoi dire quando avrai completato tutte le funzioni. Va bene - inizierai con previsioni affidabili per domani, poi la prossima settimana, poi il mese prossimo, poi 6 mesi man mano che sviluppi le tue competenze.

Mentre molti compiti di ricerca possono essere aperti, questo ha un chiaro requisito (ish): "come far interagire il nostro prodotto con una ... scatola nera".

Siamo bravi a stimare i lavori che sono simili / relativi ai lavori che abbiamo fatto prima. Dal momento che non lo hai mai fatto prima, puoi solo suddividere il lavoro in blocchi e dare a ciascun blocco un time-box. Un lavoro di questo tipo può durare all'infinito, alla fine di ogni time-box, e le attività rimanenti dovrebbero essere rivalutate. In casi estremi, questo è il caso in cui dovrebbe essere presa una decisione di andare / non andare.

Quando lavoro su tali lavori, definisco un processo in 5 passaggi

• (1) Pianificazione iniziale. Fai un'ipotesi iniziale su (2) che cosa deve essere fatto per iniziare e definisci (3) un gruppo di iterazioni / stadi, ciascuno seguito da (4) una revisione e (5) una fase di ripianificazione. Ad esempio:

• Attività iniziali. In questo caso potrebbe essere "ottenere le specifiche della scatola nera", "studiare le specifiche", "ottenere una scatola nera", "ottenere software di esempio", "stabilire un collegamento di supporto".

• Iterazione 1. Forse "Verifica le operazioni di base, imposta l'ambiente di base per il debug, riesamina il piano."

• Iterazione 2 ... e così via, con almeno 3 ma non più di 5 o forse 7 iterazioni prima di una grande revisione del progresso.

Quanto durerà ogni iterazione? Il tempo li inscatola - tali lavori andranno avanti all'infinito se non lo fai. Solo tu puoi dire se le scatole dovrebbero essere un'ora, un giorno, una settimana, ....

Inoltre, sii flessibile: mentre impari, il piano potrebbe dover cambiare. Non punire te stesso. Questo tipo di lavoro è come il debugging: devi insegnare a te stesso. Ma anche come il debugging, può aiutare a ottenere input dagli altri. E come il debugging, non puoi farlo durante il multi-tasking.