Um problema que vejo bastante é o fato de ter que parar para resolver bugs. Gostaria de exemplificações do cenário ideal para lidar com bugs no sistema no momento do sprint.
Um problema que vejo bastante é o fato de ter que parar para resolver bugs. Gostaria de exemplificações do cenário ideal para lidar com bugs no sistema no momento do sprint.
hoje, com a Alura e o Google Gemini
Se os bugs se referem ao projeto e:
Se o bug é crítico (parado em produção), ele tem que ser tratado mesmo que no meio da sprint. Além disso, deve ser contabilizado como um card não previsto.
Se o bug não é crítico, o time avalia (junto com o PO) se esta demanda pode ser tratada na próxima sprint. Um dos pontos a ser considerado é se este bug impacta diretamente nos cards tratados na sprint corrente. Se impactar, possivelmente deve ser tratado na sprint, adicionando esta tarefa (e contabilizada como uma tarefa não prevista).
É importante ter o controle destas tarefas adicionadas no meio da sprint (e/ou o controle de bugs) para avaliar a qualidade das entregas. Porque se estes bugs forem recorrentes, é sinal de que a qualidade está comprometida. Além disso, tem que verificar qual o limite tolerável deste overhead. Por exemplo, três cards não previstos por sprint é aceitável? Então tem que definir até quando se suporta tarefas não previstas, porque com certeza impactará negativamente na meta da sprint.
Uma quantidade extrema de bugs também pode indicar a existência de uma "dívida técnica": algum refactoring do código que deve ser feito para que não surjam mais (tantos) bugs, para melhorar as entregas ou para que as estimativas sejam mais fieis (no decorrer da sprint, se verifica que o problema é mais complexo e por isso ou se perde mais tempo, ou a solução não é a melhor).
Se os bugs não se referem ao projeto, então não. Deveria haver uma outra equipe dedicada para manutenções corretivas ou evolutivas. O time Scrum não pode parar para resolver problemas de outros sistemas/módulos que não sejam escopo do projeto. E trabalhar em paralelo em duas demandas (projeto e correções) é altamente improdutivo. Não se faz nem um nem outro de forma correta.
Agora, o time todo parar para resolver o bug é assustador (mas possível). Geralmente, só se para um ou dois devs do time para resolver o bug. Os demais se preocupam com a meta: a meta da sprint não pode ser esquecida. Isto reforça a necessidade de alguma correção mais pesada. Pode ser avaliada a necessidade de se fazer uma sprint somente para correções no código.