Se após a definição do Sprint backlog nenhuma outra história pode ser incluída, como fica a gestão de BUGs? Eles ficam a cargo de outro time? Entendo que para isso acontecer não poderiam existir bugs nas funções já desenvolvidas...
Solucionado
Se após a definição do Sprint backlog nenhuma outra história pode ser incluída, como fica a gestão de BUGs? Eles ficam a cargo de outro time? Entendo que para isso acontecer não poderiam existir bugs nas funções já desenvolvidas...
Oi Danilo, vou até encaminhar essa dúvida para os especialistas em agilidade, mas como já estou aqui, vou deixar meu pitaco.
Não leve a ferro e fogo essa parte de não entrar nada no spring. Se o bug é crítico, o que vamos fazer? deixar a app fora do ar :)? Vai ter que entrar no sprint e com prioridade alta, pq é um impeditivo.
O que eu já vi empresa fazendo é classificar os bugs pelo nível de problema que ele gera na app.. Se o bug for que uma tabela ficou desalinhada e vcs perceberam que isso não impacta muito na vida do usuário, aí pode deixar ele para depois... Aqui na alura tb é meio assim.. imagina se o exercício para de funcionar :)? Ou o fórum /o\?
o time e que vai resolver os problemas, um bom time sempre tem um testador mas pode acontecer de algo passar despercebido e o cliente ou usuário pode encontrar algo errado, é isso não e bom! o product owner retorna com o feedback e coloca no backlog, dependendo da feature volta pro backlog com prioridade.
Olá Danilo,
primeiramente, como o Alberto bem comentou, não precisa levar a ferro e fogo uma regra de algum processo ou framework ágil. Tem que sempre lembra que para a agilidade temos indivíduos e iterações mais que processos e ferramentas.
Segundo, não é totalmente verdade que o Sprint Backlog não pode ser alterado de jeito nenhum. Em diversos frameworks a ideia é que o Sprint Backlog seja mantido pelo time e "blindado" do cliente, no sentido de que o time pode atualizar o backlog seja desenvolvendo as histórias, adicionando uma nova história ou até mesmo removendo. Mas o cliente não pode simplesmente chegar no meio da sprint e alterar o Sprint Backlog como bem entender, ele primeiro precisa conversar e negociar com o time explicando o que aconteceu.
Por exemplo, no Scrum o Product Owner faz parte do time em si, então ele junto dos desenvolvedores e, eventuramente, o Scrum Master mantem o Sprint Backlog. Então se surgir um bug urgente, o cliente ou o usuário avisa o P.O., mostrando o bug encontrado e a gravidade daquilo, e gerar uma nova história. Caso seja urgente, o P.O. pode chamar os desenvolvedores para negociar de acrescentar uma história sobre o bug no Sprint Backlog, seja só colocando ela com todas as outras já definidas ou até mesmo removendo algumas histórias do Sprint Backlog para colocar o bug no lugar.
Outra estratégia que os times fazem quando os bugs aparentam serem frequentes é tirar uma métrica do número de bugs no sistema. Eles constroem um gráfico medido dia a dia de quantos bugs ainda não resolvidos existem ao todo no sistema e quantos bugs novos surgiram naquele dia. Se o time sente pelo gráfico que tem uma quantidade muito grande de bugs ou surgem muitos bugs novos todos os dias, os desenvolvedores e o P.O. entram em algum acordo de deixar um tempo de cada sprint reservado só para resolver bugs. Por exemplo, 15% de cada sprint será dedicada somente para solucionar bugs antigos ou novos que forem surgindo. Quando o gráfico estabiliza tira essa estratégia de 15% do tempo somente para os bugs.
Obrigado pelas respostas, é isso mesmo que eu imaginava... Tenho alguma vivência nestas situações e é isso mesmo que acontece, sempre que o BUG é crítico temos que solicitar ao time que arrume o quanto antes.
Obrigado!