Como lidar com Bugs ou alteracoes de requisitos não planeadas que entram no meio do Sprint ou Release

É sempre irritante quando algo surge fora do plano e a equipe tem que o corrigir ou gerir dentro do Sprint. Infelizmente, temos de lidar com a imprevisibilidade. Mas é sempre bom analisar por que tivemos que lidar com estes aborrecimentos.

Estes incidentes que nos causatam tanto aborrecimento sao normalmente bugs críticos ou alteração de requisitos não planeados. Neste post, vamos abordar, algumas razões para que isto aconteca  e que outras medidas que devemos considerar para manter o Sprint numa velocidade estável e a equipa motivada e focada.

O que pode considerar dentro deste grupo de incidentes ou acontecimentos imprevistos que nos causam aborrecimento, custos e desmotivacao das equipas

Num post anterior já abordei o tema de o que considero bugs e mudanca de requisitos e o problema que isto causa ao Product Owner pois é uma influencia negativa, pressao que se trás para a gestao de capacidade e prioridade dos items em backlog.

Então, essencialmente, incidentes são bugs e mudança de requisitos inesperados. A mudanca de requisitos faz parte do processo de evolução normal do produto, no entanto, pode revelar também alguma ineficiência se ocorrer com muita frequência e obrigar à alteracao do escopo/ambito do Sprint, como definido previamente na reuniao de planeamento. É ainda mais crítico se nos referimos a alteracoes radicais no design de features, com impacto na arcquitectura da aplicacao ou em diferentes componentes.

Isto é com certeza um cenário irritante para qualquer equipe de desenvolvimento. E, a meu ver, revela algumas ineficiência de planeamento por parte do Product Owner ou do Arquitecto.

Quem pode identificar e, idealmente, antecipar estes incidentes

Eu diria que a identificacao de bugs faz parte das tarefas de um test manager, durante a execucao dos mesmos. É mau sinal quando um bug é identificado pela primeira vez pelo usuário/ utilizador.

Muitas vezes, os bugs são também escritos por key-users, ou por toda a equipa de desenvolvimento (Dev Team), incluindo Product Owner e Scrum Master, que também podem identificar e relatar bugs no backlog. Outra fonte, sao os servicos de suporte ao utilizador. Este será um tópico para um próximo post, o fluxo de trabalho entre diferentes niveis de suporte para reporter e resolver um bug. Este tópico é particularmente interessante em um contexto de DevOps.

Muitas vezes, uma alteracao de requisitos, não planeada, pode representar uma solução de contingencia, para corrigir uma dependência, por exemplo. Num cenário destes, observamos o um esforco conjunto por parte do arquiteto e da equipe de desenvolvimento para, rapidamente criarem uma solucao de recurso (muitas vezes de natureza temporaria até à dependencia ser corrigida) para cumprir o deployment da funcionalidade.




Como reporter em backlog bugs e alteracao de requisitos?

Durante do reporte do bug em backlog, é extremamente importante elaborar uma boa descrição do mesmo: nível de severidade, frequência, como repetir a ocorrência, melhorar a descricao com o relato da sequencia de todos os passos, e adicionar screenshots, etc.

Esta descrição completa facilita o esforço do test manager para reproduzir o bug, e sua tarefa será adicionada uma descrição técnica completa do bug com outro tipo de informação, como os logs de servidor, as mensagens do browser, ou outras consolas tecnicas da aplicacao, etc. Todo este esforco tem como único objetivo: tornar mais fácil e rápida a resolução do bug.

Normalmente, alteracoes de requisitos a nível funcional são escritos pelo UX designer ou pelo Product Owner. Requisitos não funcionais, normalmente são escritos pela equipe de desenvolviment, muitas vezes pelo arquiteto que tem o papel explícito para procurar permanentemente alcancar melhorias arquitectónicas na aplicacao.

Mas esta é a forma saudável de introduzir alteracao de requisitos em backlog. 

Mas como deve lidar a equipa com este imprevistos desagradaveis que entram no meio do Sprint?

Na minha opinião aqui entra a capacidade de negociação do Scrum Master, a fim de proteger a equipe: se algum esforço não planeado entra no Sprint, o esforço equivalente já planeado deve ser retirado do Sprint.

A que stories nos referimos exatamente é sempre uma discussão que deve ser moderado pelo Scrum Master, entre a equipe e o Product Owner.