Scrum in combinazione con correzioni di bug ad hoc [duplicate]

3

Ho lavorato in un'azienda in cui hanno cercato di utilizzare Scrum ma in pratica era difficile creare un solido backlog di sprint perché avevano una base di utenti molto attiva, che utilizzava il software 8 ore al giorno e, per questo motivo, molti bug critici che richiedevano attenzione immediata.

Questo mi ha fatto chiedere ... Qual è il modo migliore per risolvere questo tipo di carico di lavoro non pianificato durante l'utilizzo di Scrum? Ho visto qualcosa su Scrumban e Kanban, ma ancora non vedo come sia possibile dare al cliente una stima abbastanza corretta delle funzionalità che verranno completate all'interno di determinati sprint in combinazione con il lavoro non pianificato (bug) che richiede attenzione immediata.

Devo cercare una metodologia che possa far fronte a un carico di lavoro inaffidabile o devo dare un'occhiata ad altre fasi del processo di sviluppo del sotware? Ad esempio, per garantire che il processo di qualità sia migliorato per ridurre il numero di bug e con che quantità di lavoro non pianificato?

    
posta Bram 14.12.2014 - 13:19
fonte

1 risposta

5

"[...] 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.

risposta data 14.12.2014 - 13:28
fonte

Leggi altre domande sui tag