O lançamento do Visual Studio Team System (VSTS) acendeu no Brasil um forte interesse pelo issue management. Sem dúvida o controle de itens, é um dos principais aspectos de um ALM (Application Lifecycle Management).

Acredito que muitas empresas estão começando a ser interessar pelo assunto e devem adotar algum aplicativo de issue management/bug tracking em um futuro próximo, seja ele o VSTS ou não.

Um sistema como este pode ajudar bastante uma empresa, mas também pode atravancar bastante o processo, principalmente das fases iniciais, onde todos ainda estão começando a entender o conceito da coisa.

Uma das piores conseqüências que pode acontecer é o jogo de “comigo não está”. A regra é assim: O suporte abre o bug o mais rápido possível, mesmo sem todas as informações e manda para o desenvolvedor. Este retorna o bug, geralmente no último minuto do seu SLA perguntando informações complementares.

O jogo fica mais legal quando o gerente de produto ou analista de negócios é envolvido para confirmar se o problema é realmente um bug, ou se é um change request. O bug fica rodando entre os participantes indefinidamente até que um cliente entra em contato com o diretor da empresa, que manda um email simpático pedindo que o problema seja resolvido hoje, caso contrário, cabeças vão rolar.

Para que este tipo de coisa não comece a acontecer no seu – ultra, super – recém implementado processo, ai vão algumas dicas de como abrir e tratar um bug.

Todo bug deve ser aberto com as seguintes informações:

• Titulo: Uma sucinta descrição do problema, que seja fácil de buscar (quando seu banco de bugs crescer, isto vai ser muito útil)
• Descrição: Descreva o bug tentando diminuir o tempo de investigação e aumentar a assertividade da triagem. Sua equipe é divida por módulos do sistema? Então deixe claro qual módulo está sendo afetado. O usuário está usando Firefox 1.0? Escreva, não deixe nada subentendido. Além disto, anexe qualquer log gerado pela aplicação.
• Como reproduzir: Qual é o passo a passo necessário para reproduzir bug. Elimine todos os passos desnecessários, mas não pule nenhum necessário. Imagine que para começar a corrigir o bug o desenvolvedor terá que reproduzi-lo.
• Resultado esperado e encontrado: Nem todo mundo conhece tão bem as regras de negócio do sistema quanto você, portanto, deixe claro qual era o resultado esperado ao final do repro steps e qual foi o resultado encontrado. Se envolver alguma UI tire foto, marque em vermelho o problema e anexe.

Todo bug aberto deve ter:

• Um dono, o tempo todo, caso contrário ele cairá no esquecimento.
• Uma prioridade. Para que sua equipe invista seu tempo de forma eficiente
• Um prazo. Nem preciso explicar por que. Este prazo pode estar vinculado à prioridade do bug.
• Uma única pessoa responsável pelo fechamento: quem o abriu. O desenvolvedor pode achar que o bug foi corrigido, o gerente de suporte pode achar que o problema não é um bug, mas o único que pode fechá-lo é a pessoa que o abriu.
• Uma forma rápida e eficiente de se fazer visto. Cada minuto que um bug fica parado no sistema esperando o responsável tomar ciência dele é um minuto perdido na sua resolução dentro do prazo. Seu time não deixa o sistema aberto porque ele é pesado? Faça-o mandar um email. Seu desenvolvedor fecha o email para se concentrar? Mande um recado no IM (Istant Messenger). Seu tester não usa um IM? Manda ele embora porque eu nunca vi alguém que trabalha com tecnologia não usar Messenger :)

Além de todas boas práticas acima, e outras que você vai descobrir com a sua experiência é fundalmental envolver os participantes. É importante criar uma cultura de solucionar os problemas o mais rápido possível, atuando de forma colaborativa.