Ricerca di errori nelle attività

Spostalo indietro Gli ambienti di sviluppo agili devono funzionare in base alla loro "definizione di fatto" e finché l'attività non viene "completata", non scorre fuori dal bordo destro della scheda . In un ambiente agile buono , "done" include comportamento testato-per-imprevisto e verificato-contro-requisiti . Ancora meglio dell'aspetto maternità-e-mela-torta di non inquinare la tua scheda, motiva anche i tuoi sviluppatori a finire l'operazione: " Dannalo, il WidgetFrobulator è di nuovo in TO-DO di nuovo - Ho bisogno di prenderlo fuori bordo! "

La risposta alla tua domanda è semplice. Realizza la versione più adatta al tuo processo e al tuo sistema. Agile, e soprattutto Lean, tutto ruota attorno all'adattamento delle idee alla tua squadra e al tuo processo.

Per quanto riguarda i 2 modi che hai citato, abbiamo fatto entrambe le cose e talvolta facciamo ancora entrambe le cose. Per esempio, se ho una storia in "Testing" alla lavagna e uno dei miei colleghi trova qualcosa di sbagliato, me lo dirà immediatamente. Nella maggior parte dei casi questi problemi sono banali o relativamente facili da risolvere e verranno risolti. A volte anche il tester può risolvere il problema. Inoltre, dobbiamo considerare che la storia è nell'ultima fase prima di essere "Done" e di solito è meglio renderla tale. Risolvi il bug in modo che la storia possa essere completata e considerata conclusa. La storia di One Done è molto meglio di 2 non terminate.

D'altra parte, a volte, ma molto raramente, un problema fondamentale viene scoperto nelle ultime fasi di quella storia. Quando ciò accade, potrebbero essere necessari più lavoro e tempo e potresti essere già a metà con la seconda storia che hai iniziato nel frattempo. In questo caso puoi ancora scegliere di finire la storia che può essere fatta più velocemente e aggiungere un altro compito per "recuperare" con la storia fasulla o riportarla alla lavagna, come desideri.