“O uso do termo bug (em português: “inseto”) para descrever defeitos inexplicáveis foi parte do jargão da engenharia por várias décadas; pode originalmente ter sido usado na engenharia mecânica para descrever maus funcionamentos mecânicos. Diz-se que o termo foi criado por Thomas Edison quando um inseto causou problemas de leitura em seu fonógrafo em 1878, mas pode ser que o termo seja mais antigo.”
Fonte: Wikipedia
Cronograma bem planejado, profissionais competentes e um bom gestor. O que poderia prejudicar o sucesso do projeto?
Resposta: O famigerado BUG!
Um dos grandes males que assolam a TI é a quantidade de bugs nos softwares o que obriga as empresas alocar recursos para solucioná-los. Com quase 22 anos de profissão vi bugs, dos mais simples aos mais complexos, em sistemas de engenharia, previdência, legistativo, financeiro e militar de grandes e pequenas empresas.
Os desenvolvedores tem que deixar de lado seus novos projetos para corrigir os bugs, ou seja, perde-se o foco na resolução de problemas dos softwares que estão em produção/certificação.
Isso impacta, e muito, no cronograma de um desenvolvedor, tanto pela qualidade como pelo prazo pré-estabelecido do projeto. Alguns gestores parecem não entender o quão isso é ruim para o profissional de TI, equipe e para empresa.
Numa grande empresa que trabalhei, cheguei a ficar 3 semanas sem programar uma única linha de código “nova”, somente resolvendo bugs. E eram bugs complexos de se resolver…e como eram…
E o que aconteceu com o meu cronograma? Foi pro espaço! Literalmente…
Cronogramas atrasados já geram um stress com gerência e sistemas entregues com atraso e com bugs geram mais stress ainda.
Cada empresa tenta combater esse mal da sua maneira, mas posso afirmar que é de fundamental importância, independente do tamanho da empresa, uma área de homologação com total conhecimento do business e com um roteiro de testes sempre atualizado.
Como os cronogramas atrasam, geralmente essas áreas são pressionadas a homologar o sistema o mais rápido possível, e é por ai que esse inseto, ops, bug se aproveita para sobreviver.
Acho muito válida a ideia de uma equipe de “infantaria”, ou seja, uma equipe que seja acionada quando um bug for detectado, assim o desenvolvedor só seria necessário em último caso.
Pode parecer utopia, mas converse com qualquer desenvolvedor e com certeza ele gostaria de trabalhar o dia inteiro focado na programação, sem ser interrompido por usuários. Será que um dia ainda verei isso?
Sei também que é muito mais fácil tudo isso na teoria que na prática, pois já presenciei áreas de homologação que não detectavam erros básicos e áreas de “infantaria” que só sabiam pegar o telefone e ligar para o desenvolvedor.
Para equipe de desenvolvedores e para o gestor, acho válido uma conversa franca e profissional, logo após um projeto ser entregue. Para se discutir o que pode ser feito para melhorar, para não os erros não se repitam.
Para finalizar, bugs + atraso de cronograma = prejuízo $$$ para empresa
Bom esse foi o primeiro artigo de 2014!
Espero conseguir a média de 1/mês… 🙂
[Crédito da Imagem: Watirmelon.com]
TDD, Code Review e CI.
Impossível eliminar bugs mas a qualidade do que se entrega pode atingir níveis muito satisfatórios se a forma de criar código for diferente:
http://en.wikipedia.org/wiki/Test_driven_development
http://en.wikipedia.org/wiki/Continuous_integration
http://en.wikipedia.org/wiki/Code_review
Moyses,
Obrigado pela participação.
Realmente ferramentas e metodologias para diminuir as quantidades de bugs existem, só faltam ser mais utilizadas pelas empresas.
E também concordo que BUG zero é impossível…
Abraço.