"[...] riportava molti bug critici che richiedevano attenzione immediata" suoni sgradevoli.
Se il tuo team è in grado di risolvere 5 bug al giorno e decine di utenti hanno segnalato dozzine di bug che richiedono tutti attenzione immediata, non c'è modo di poter fare ciò che vogliono. Semplicemente devono aspettare, e maggiore è la loro leva per affrettare le cose, peggio sarà, perché la fretta incoraggerà la tua squadra ad abbandonare i test, le revisioni del codice o la programmazione della coppia e portare a più bug.
Inoltre, saltando il backlog e spingendo l'attività direttamente nello sprint corrente, stai creando un pasticcio . Gli sviluppatori stavano lavorando su un compito; ora devono sospendere il loro lavoro e affrontare un nuovo compito. Questo da solo è abbastanza frustrante da abbassare la produttività, ma anche tornare al compito precedente poche ore dopo è doloroso: la persona potrebbe aver dimenticato dove si trovava.
Infine, devi essere sicuro di assegnare le priorità in modo che solo una piccola parte delle attività appaia ad alta priorità. Ho visto progetti in cui su 100 attività, 30 stavano "richiedendo attenzione immediata" e 60 erano "ad alta priorità": in tale contesto, gli sviluppatori stanno semplicemente considerando che ci sono 30 attività importanti, 60 attività a bassa priorità e 10 che non saranno mai essere implementato.
Se il tuo cliente, capo o utente sta chiedendo di risolvere un bug adesso , l'unica risposta possibile è:
We added this task to our backlog and we set it to be a high priority task. We are currently solving 68 other high priority tasks which might take us from four to five weeks. We'll keep you updated.
Cosa succede se il bug sta bloccando?
Che cosa succede se il bug dovrebbe essere effettivamente risolto adesso , a causa della sua gravità (come un utente non può accedere)?
-
Se questo è un caso isolato, allora Come tenere conto di un'iterazione di correzione dei bug? menzionato da Gnat è pertinente.
-
Se questo diventa un pattern (come diversi bug al momento al giorno), allora c'è qualcosa di completamente sbagliato nel modo in cui il tuo team sta sviluppando il prodotto software.
Se il team sta usando la paia di programmazione o revisioni del codice, se la copertura del codice di destinazione è sufficientemente elevata, se tutti i membri del team comprendono i requisiti, se esegui test di regressione (tramite integrazione continua) e se la distribuzione è automatizzata ( nessuno sta scherzando con i tuoi server), questo non dovrebbe accadere.
Anche in questo caso, indipendentemente dal modo in cui la tua squadra sta svolgendo il proprio lavoro, di tanto in tanto potrebbero accadere cose brutte. Ma se questo accade regolarmente, qualcosa è fuori controllo.