Bug no software! De quem é a culpa? – Parte 2

Bug no software! De quem é a culpa? - Parte 2Na primeira parte do artigo sobre quem leva a culpa quando um bug é encontrado no software, alguns critérios foram empregados para definir a discussão, como a documentação, ambiente de testes e complexidade do requisito funcional. Em continuidade à discussão, este artigo traz uma perspectiva voltada para o processo ao invés de um recurso físico. Vamos continuar?

 

Há quem diga que a culpa é coletiva e não deve ser direcionada a apenas uma pessoa. Por exemplo, a culpa é do Analista de Sistemas por não alertar a equipe sobre a probabilidade do bug, do desenvolvedor por introduzi-lo e do testador por não encontrá-lo. No entanto, ao invés de despediçar tempo procurando o culpado, a empresa deveria preocupar-se em corrigir o processo no qual permitiu a ocorrência do bug, como também o processo que falhou em encontrá-lo. Na minha visão, isso faz total sentido.

Ao se esforçar em decretar a culpa em alguém, a empresa será ineficaz e improdutiva. Em um ambiente ideal, a “culpa”, ou melhor, a não conformidade, é resultado da falha de um  processo e cabe à equipe corrigi-la para evitar novas ocorrências. Este é um procedimento condizente com os conceitos do CMMI, portanto, é altamente adequado.
Na verdade, os processos que abrangem desde o desenvolvimento até os testes deverão ser revistos. Em uma primeira instância, os processos envolvidos na garantia da qualidade do software podem ser averiguados, como, por exemplo: 

  • Quais são os controles de revisão da atividade de desenvolvimento?
  • Existe revisão de código (Code Review)?
  • Os desenvolvedores executam testes funcionais no código?
  • Os desenvolvedores criam testes automatizados?
  • Os testadores criam planos de testes devidamente relacionados ao requisito implementado?
  • Quais são os processos de comunicação entre a equipe de desenvolvimento e de testes?
  • Existe alguma validação para verificar se os testes criados atendem as expectativas?

 

Observe que os 7 itens acima, ao invés de refletirem a culpa em uma única pessoa, refletem em conjuntos de atividades, ou seja, em processos. Dessa forma, o termo “culpa” é transformado em “falha do processo” e toma uma dimensão abstrata.
Mesmo que uma equipe tenha ótimos desenvolvedores e testadores, é necessário que exista processos bem definidos para a validação da implementação. São os processos que giram as engrenagens no fluxo de atividades de uma empresa.
Para facilitar a compreensão, imagine que, em uma fábrica de móveis, uma determinada peça de um produto está sendo pintada antes de ser cortada. De modo geral, essa falha não está relacionada aos operadores, mas ao processo de fabricação. Basta inverter as funções de corte e pintura para que a falha deixe de existir. O trabalho dos operadores simplesmente continua o mesmo.

Pensando por um lado mais pessoal, direcionar culpa pode ser prejudicial para a equipe e é sinônimo de desmotivação. No ambiente corporativo, é comum que um profissional seja raramente reconhecido pelos seus esforços e excessivamente punido pelos seus erros, levando-o a procurar por outras oportunidades de emprego. Se a empresa direcionar o foco para os processos ao invés de incriminar a equipe, essa desmotivação se torna um problema a menos e mantém bons profissionais comprometidos.
Certa vez, li um estudo de caso de uma empresa que, ao trocar o direcionamento da culpa pela revisão dos processos, diminuiu a ocorrência dos bugs em produção em 50%. E só pra constar, essa porcentagem não é fixa. Na proporção em que o processo de desenvolvimento é aprimorado, a tendência de erros no software é cada vez menor, naturalmente.

Antes de fechar o artigo, devo dizer que bugs no software não devem ser considerados apenas como vilões. Nós aprendemos com os nossos erros, certo? Portanto, os bugs representam uma excelente oportunidade de aprendizado desde que sejam utilizados a nosso favor. Cada bug identificado, resolvido e rastreado contribui para a maturidade tanto dos processos quantos dos próprios profissionais.
Além disso, equipes devem ser colaborativas e cooperativas. Testadores, por exemplo, enxergam o software em uma perspectiva diferente dos desenvolvedores, os ajudando a identificar suas próprias falhas e aumentar o campo de prevenção de erros. Oras, isso pode ser parte do processo, não é? Claro!

 

Aqui termino o artigo, leitores.
Espero que os pontos de vista apresentandos aqui tenham sido úteis!
E lembre-se: não se esforce em encontrar o culpado. Se esforce em melhorar os processos!

Semana que vem eu volto!


Confira também as outras partes dessa série de artigos:

Bug no software! De quem é a culpa? – Parte 1
Bug no software! De quem é a culpa? – Parte 2


 

Compartilhe!
Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Pin on PinterestEmail this to someone

8 comentários

  1. Ola Andre,

    Excelente conjunto de artigos, parabéns e obrigado por compartilhar informações em uma linguagem agradável e objetiva. Isso, sem duvidas, valoriza nossa área.

    Grande Abraço.

  2. Parabéns pela continuação do artigo, e obrigado por compartilhar conhecimentos de uma forma bem didática.
    Abraços.

  3. Em minha visão de administrador, que é minha formação acadêmica, eu chamaria este artigo de “Administração de Processos Produtivos”, que é a ideia por trás dele.

    Achei interessantíssima a perspectiva administrativa de mudar o enfoque de “procurar culpados” para “identificar inconformidades, melhorar processos e consequentemente reduzir novas falhas futuras”. É simples e por isso mesmo genial! É uma pena que Administradores ou gestores de processos, no geral, se utilizem apenas da míope e contraproducente visão de “procurar culpados e apagar incêndios” e em consequencia disso, forçar profissionais a sair da organização por desmotivação!

    Mais um ótimo artigo, parabéns!

    1. Grande, Jadilson! Como já era de se esperar, seu comentário foi excelente! Concordo com a sua afirmação a respeito da visão contrária que muitos gestores conduzem. Hoje, infelizmente, ainda existe uma grande parcela destes profissionais que, ao meu ver, são um dos fatores que causam irregularidades ou até a descontinuação de projetos, principalmente relacionados à área de TI. Espera-se que, com a adoção cada vez maior de metodologias de gerenciamento (como o Desenvolvimento Ágil) e a constante atualização do perfil de gestores, esse cenário se estabilize.
      Obrigado pelo comentário!

  4. Oi André, tudo bem ? achei bastante interessante o seu artigo. Não pude deixar de notar que vc também é um entusiasta em Desenvolvimento ágil. Desta forma, me permita perguntar qual a sua visão sobre o primeiro dos valores do manifesto ágil?

    1. Olá, Paulo!

      Obrigado pelo feedback sobre o artigo!
      Sim, Paulo, sou um grande entusiasta em Desenvolvimento Ágil, principalmente em Scrum e XP. Tanto o meu trabalho de conclusão do curso superior quanto da pós-graduação foram focados neste tema.
      Bom, o primeiro valor do Manifesto Ágil no qual você se refere é:

      “Indivíduos e interação entre eles mais que processos e ferramentas”

      Quando realizei uma pesquisa de campo sobre Desenvolvimento Ágil na cultura das empresas, a maior vantagem apontada pelos entrevistados foi a comunicação com os clientes. Não demorou para que eu notasse que este era um dos grandes pilares do Agile. A interação entre a equipe (na qual inclui-se o próprio o cliente) é um excelente recurso para identificar falhas de requisitos de forma pontual através do sistema de feedback constante do cliente. Além disso, essa interação também permite a definição de prioridades, aumentando a qualidade do projeto do ponto de vista de negócio.
      Um dos objetivos deste valor do manifesto ágil é despertar a importância da comunicação entre a equipe em comparação com processos burocráticos ou excessivamente restritos, que podem resultar em projetos mal sucedidos.
      Gostaria de falar muito mais sobre este valor, mas este comentário se tornaria um jornal, rsrs. 🙂

      Espero ter esclarecido um pouco da minha visão, Paulo!
      Abraço!

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Preencha o campo abaixo * Time limit is exhausted. Please reload CAPTCHA.