Qualidade de Software Ltda

É muito comum encontrar literatura sobre as melhores práticas para o desenvolvimento de software. Mas vou dedicar alguns posts para elencar em ordem decrescente as dez piores práticas para o desenvolvimento de software. Espero que você não se identifique com essas práticas!

Neste post vou elencar do 10º ao 6º lugar:

10 º : Não estabelecer métricas para o desenvolvimento de software – cada software é desenvolvido de uma forma particular, em função das suas características, e também cada desenvolvedor tem um estilo próprio de codificação. Assim não é possível nem necessário estabelecer métricas como produtividade por linha de código, quantidade de erros por pontos de função detectados em ambiente de produção, cumprimento dos prazos de desenvolvimento, etc. A equipe, mesmo sem métricas tende a melhorar organicamente.

9 º : Não prever capacitação dos usuários para utilização do software – Atualmente as interfaces gráficas são muito intuitivas e de fácil utilização. As crianças já utilizam computadores desde a tenra idade e crescem em contato com esse ambiente. Como hoje os prazos de desenvolvimento são apertados não se faz necessário gastar tempo com a capacitação dos usuários para a utilização do software. Havendo dúvidas de utilização, o usuário sempre pode ligar para o help-desk.

8º : Não utilizar um processo definido para relato de defeitos – durante o processo de desenvolvimento e as diversas etapas de testes, à medida que os defeitos vão sendo encontrados, eles vão sendo priorizados e corrigidos segundo a própria experiência dos programadores. Não há necessidade de um software para gestão de defeitos, o que iria só burocratizar a agilidade da correção dos mesmos. Raramente ocorre de um software ir para a produção com defeitos já conhecidos, que foram esquecidos de serem consertados pelos programadores.

7º : Não utilizar um software de controle de versão – os códigos fontes são mantidos nas máquinas dos programadores envolvidos em cada projeto de desenvolvimento, de forma a dar maior liberdade e velocidade ao programador. O que importa é a experiência e o controle efetuado pelo programador na hora de colocar o software em produção. Um software de controle de versão é caro e burocrático.

6º : Definir a arquitetura do software à medida que o código vai ficando pronto – Pensar e desenhar a arquitetura do software antes do código estar pelo menos 60 a 80 % pronto não é produtivo, e acaba sendo uma atividade de abstração que quase sempre se demonstra inútil. O programador de acordo com a necessidade do código vai definindo a arquitetura necessária e assim o resultado é sempre um software com boa funcionalidade, usabilidade e performance.

Se você conseguiu ler essas cinco piores práticas, é sinal que tem o coração forte. Aguarde as cinco primeiras e faça o teste definitivo do seu coração!