Pianificazione della risoluzione dei problemi in uno sprint

Question

Pianificazione della risoluzione dei problemi in uno sprint

#1 da (1 voti)
#2 da (0 voti)

1

Di tanto in tanto affrontiamo problemi difficili che sono difficili da riprodurre. La creazione di una pianificazione per risolvere tale problema è (quasi) annullabile.

Ciò che facciamo al momento è spezzarlo in analisi / riproduzione e risolvere il problema. Finché non sappiamo nulla, pianifichiamo un certo numero di ore per investigare e prenotare queste ore con impegno e non con risultati.

Questo non sembra un vero scatto agile. Avete qualche suggerimento su come migliorare questa situazione?

agile planning sprint

posta refro 05.05.2014 - 10:25

fonte

2 risposte

Leggi altre domande sui tag agile planning sprint

Iniezione delle dipendenze per le variabili di richiesta in un'applicazione web Come testare unitamente gli errori di conversione implicita in PHP?

score 1 · Answer 1

Penso che ITIL abbia una buona idea sull'argomento distinguendo tra problemi e incidenti. Non è possibile risolvere un incidente ... qualcuno deve indagare e capire il problema dietro quell'incidente. Quel modo di guardare le cose ha un certo overhead, ma può aiutare in molti modi diversi man mano che aumenta la portata di un progetto.

Questo è più o meno quello che stai facendo, suppongo. Non ho letto la domanda collegata che gnat ha pubblicato, ma penso che un incidente non appartenga a uno Sprint. Deve prima raggiungere lo stato del problema, il che significa che la causa deve essere conosciuta e una soluzione per il problema deve essere stata proposta.

In alcuni casi l'Impediment Backlog potrebbe essere il posto giusto, anche se ... se gli impedimenti sono da incolpare (non una mancanza di chiarezza) che il proprietario del prodotto (? Penso?) può affrontare (o avere qualcuno che affronta).

score 0 · Answer 2

In agile, c'è il termine Spike dove passi il tempo (di solito risolto nella mia esperienza ) indagando su un problema per poter fare una stima per una storia. Nel tuo caso, se stai facendo Scrum e stai cercando di ottenere delle stime per le attività su un bug, potresti dover eseguire un Spike (come stai facendo) in modo da poter stimare il lavoro rimanente.

Questi picchi possono anche essere usati per la prioritizzazione. Se lo Spike scopre che il problema è improbabile, o si verifica solo in scenari hardware molto specifici, o solo il secondo martedì di un mese che termina con "Y", puoi decidere di abbassare la priorità nel backlog per questo bug.

Detto questo, per gli errori non lo farei di solito. Io tendo ad afferrare i bug di "x" nello sprint e far lavorare il gruppo su di essi in ordine di priorità accanto al normale gruppo di storie su cui si sta lavorando. Se durante quel lavoro scopriamo informazioni che potrebbero influenzare la priorità, allora agiremo su di esso allora.