Devo includere il tempo di ricerca in un'attività agile? [duplicare]

La parola "ricerca" viene infatti sovrautilizzata in modo agile. La parola può essere suddivisa in:

1. apprendimento, lettura della documentazione o apprendimento dal provante.
   • Questo è solo "apprendimento".
   • Questo non è destinato a sminuire il tempo necessario per l'apprendimento.
   • Può richiedere molto tempo, ad es. settimane o mesi, ma il processo di apprendimento dovrebbe essere considerato e incluso nella stima del tempo.
   • Può richiedere poco tempo - se la squadra ha già usato qualcosa di simile prima.
2. esamina ampiamente da un gran numero di opzioni, raccogliendo informazioni di base e caratteristiche (specifiche, limitazioni) su ciascuna, ma evitando la codifica effettiva (cioè senza impegnarsi in alcun modo).
   • Questo in precedenza si chiamava "ricerca", ma avrebbe dovuto essere chiamato "sondaggio".
3. eseguire un singolo tentativo di implementazione per convalidare / esplorare una scelta di implementazione semi-impegnata.
   • Questo è un "picco".
4. effettuare ripetuti tentativi di implementazione al fine di selezionare in modo competitivo una o più scelte di implementazione, ma con la consapevolezza che l'implementazione finale trarrà beneficio solo da una di queste scelte.
   • Questa è una vera "ricerca".
   • Il tempo di codifica speso per le scelte inferiori (che non sono note all'inizio ma vengono gradualmente rivelate durante i molteplici tentativi) non contribuisce al valore aziendale.
   • Per questo motivo, si consiglia di provare "furetto" ed eliminare le scelte inferiori il prima possibile.
   • Tuttavia, è necessario tenere presente la possibilità che una precedente determinazione di inferiorità possa cambiare man mano che maggiori informazioni diventano disponibili.

Nella tua situazione, appartiene al primo caso (apprendimento), quindi:

• Le 6 ore che hai citato sono il tempo pianificato per tutto il lavoro necessario per "creare un'attività che possa ..."
• Qualsiasi apprendimento (come spiegato nel primo caso) è incluso in questa 6 ore.
• È possibile che ci vorranno più di 6 ore. Le stime delle attività sono stime. Quando le stime vengono superate, il dirigente di controllo saprà che nella riunione del giorno successivo e in generale al team sarà consentito continuare a lavorarci. Le stime non sono scadenze.

Anche la parola "time-box" in Scrum ha più significati.

• All'interno di un singolo sprint , non è una "scadenza". Quando un compito richiede più delle stime, il team può discuterne, sia come follow-up dello stand-up quotidiano, sia durante la retrospettiva dello sprint.
  • Lo scopo di tale discussione è che se un'attività ha richiesto molto più della stima, il team ha implicitamente scoperto o sperimentato qualcosa di nuovo - qualcosa che rallenta l'attività, che non è stata presa in considerazione quando è stata fatta la stima originale.
  • Può darsi che l'attività sia effettivamente più difficile di quanto inizialmente previsto.
  • In ogni caso, tali nuove informazioni devono essere incorporate nelle stime temporali future.
  • La diffusione di tale esperienza è il motivo della discussione.
  • La parola "time-box", come usata qui, è per assicurarsi che questa discussione avvenga, che non passerà inosservata.
• Un "time-box" è una "scadenza" solo quando è deciso dal decisore finale, cioè quando lo stakeholder ha il consenso sul fatto che la funzionalità debba essere eliminata perché sembra non essere attuabile date le circostanze attuali e risorse.

Avvertenze.

• Questa è la mia opinione personale
• Non pratico alcuna metodologia agile.
• La mia opinione potrebbe avere molte inesattezze, errori e incomprensioni dal punto di vista della mischia o della metodologia agile.
• Non ho certificati, corsi di formazione o credenziali in relazione a qualcosa.
• Sono personalmente frustrato dall'uso eccessivo della parola "ricerca", perché nel raro caso in cui una persona che dichiara di fare "ricerche" per il caso uno (imparando qualcosa), possa impedire a una persona di fare effettivamente "ricerche" per il caso quattro (in realtà inventando alcuni nuovi algoritmi), indebolendo e sminuendo le affermazioni di fronte ai project manager o ai professionisti agili.

Ken Rubin ha risposto a questo in un seminario di formazione per noi. Il suo consiglio era di usare un picco di ricerca o di usare un compito di storia per l'allenamento. Nel tuo caso, sai quale prodotto stai usando e devi solo tenere conto della curva di apprendimento. Consiglierei un compito di apprendimento. Ricordo che durante la lezione qualcuno ha chiesto se potevamo semplicemente creare una storia del tipo "Come ingegnere del software, voglio imparare NLog ...." A questo è stato risposto con un "No" fermo perché la storia non fornisce valore aziendale, ma come gruppo sei libero di creare le attività necessarie per realizzare una storia. Il mio team ha recentemente avuto bisogno di imparare la ricerca elastica e abbiamo fatto proprio questo.

Ken Rubin elabora di più nella sezione "PBI Type: Knowledge Acquisition" qui link