Conheça práticas de controle de bugs no banco de dados

Este artigo apresenta um conjunto de práticas que podem ser seguidas para facilitar o controle e a gestão de defeitos em projetos que envolvam banco de dados.

Fique por dentro
Este artigo apresenta recomendações, práticas e sugestões para o controle e a gestão de defeitos de software. Em particular, discutiremos como tratar estas questão sob a perspectiva de defeitos presentes em bancos de dados.

A aplicação do conhecimento apresentado é essencial no sentido de manter o banco de dados funcional ao longo do ciclo de vida do produto. Outros benefícios do entendimento dos conceitos apresentados neste artigo são: melhoria na comunicação da equipe, agilização dos processos, redução de conflitos internos e agregação de qualidade ao software.

Todo projeto que envolve desenvolvimento de software acaba gerando bugs, ou seja, problemas relacionados com o funcionamento do software. Além do controle de bugs também é comum que a equipe responsável pelo projeto implemente novas funcionalidades e altere o software para atender a mudanças ou novos requisitos.

A organização e gestão de atividades possui um impacto muito grande na forma como os membros da equipe de desenvolvimento se comunicam e realizam o trabalho que deve ser feito, mesmo no caso onde existem bugs relacionados ao banco de dados que devem ser resolvidos por um DBA.

Com base neste cenário, este artigo visa abordar atividades do controle de projetos de software e outros detalhes relacionados com a organização e gerenciamento do acesso aos membros da equipe que precisam resolver bugs envolvendo de alguma forma o banco de dados.

A partir da análise e estudo dos problemas discutidos serão sugeridas recomendações com o objetivo de auxiliar a gestão de artefatos associados ao software e ao banco de dados junto com o gerenciamento dos membros da equipe.

Cenário de exemplo: projeto de software com banco de dados

Como cenário podemos imaginar um projeto de software de qualquer tipo (aplicação desktop, Web, mobile, etc.) que conta com uma equipe de desenvolvedores e demais profissionais (designers, DBAs, DevOps). Cada membro desta equipe possui habilidades diferentes e eles são coordenados por um gerente de projeto, que possui pouco conhecimento técnico de programação, banco de dados, design e infraestrutura.

Na teoria o gerente de projeto é responsável pela atribuição de tarefas, controle de prazos, organização da equipe, produção de alguns artefatos (diagramas, documentação, relatórios) e gestão completa dos aspectos de qualidade do software.

Durante todo o projeto, novas versões do software são liberadas quase diariamente de acordo com a correção de bugs e implementação de novas funcionalidades.

E devido à necessidade de novas versões frequentes, não há um planejamento estratégico e cronograma ligando a versão do software com as requisições aos membros da equipe, tarefas realizadas e lista de bugs corrigidos.

É comum algum usuário final ligar e conversar diretamente com membros da equipe sobre algum bug ou nova funcionalidade. Como resultado, diversas vezes os usuários acabam modificando a prioridade de bugs e interrompem tarefas que já estavam sendo realizadas anteriormente pelos profissionais técnicos.

Neste projeto de software há também o clássico cenário onde um usuário final “privilegiado”, tal como o presidente da empresa ou o cliente mais importante, exige que um bug ou funcionalidade específica seja tratada o mais rápido possível, sem levar em consideração o que cada membro do projeto está fazendo no momento. "

[...] continue lendo...

Artigos relacionados