Vamos, antes, a definição do termo amador (grifo meu):
Amadorismo é o nome dado ao desempenho de uma atividade profissional por pessoas sem conhecimento avançado do assunto e utilizando equipamentos e técnicas não-profissionais.
Se você utiliza-se de algum método ágil de desenvolvimento (Scrum, Kanbam, XP, etc), a equipe de desenvolvimento ganha uma grande (e necessária) liberdade. Liberdade esta essencial para a construção de um software que atenda as necessidades dos usuários, com o risco compartilhado entre o cliente e a empresa de desenvolvimento. Sendo a área de programação uma criança aprendendo a andar, os métodos ágeis já provaram ser o que temos de melhor para construção de um software atualmente.
Só que toda esta liberdade é confundida com libertinagem, e fazemos isto de uma forma inconsciente. Não é porque o desenvolvimento está livre de processos rígidos e desnecessários que devemos abandonar uma mínima organização e preparação.
Deixar de usar ferramentas que:
- auxiliam no controle das versões;
- controlam quais funcionalidades foram e estão sendo desenvolvidas;
- procuram bugs;
- executam automaticamente os testes;
- etc;
Ou deixar de lado uma organização que poderia:
- definir um padrão de nomenclatura para nomes de classes, métodos, ações do sistema;
- crie um glossário dos termos mais comuns a serem utilizados;
- centralizar as dúvidas e soluções para problemas comuns de ambiente ou tecnologia;
- etc;
Estaremos abrindo mão da qualidade, não tenha dúvida. Abordaremos cada um destes itens aqui no blog no futuro.
Você pode estar irritado em eu levantar a possibilidade que fazemos um trabalho amador e nem nos darmos conta disto. Com experiência e maturidade, naturalmente aprendemos muito e passamos por diversas situações. Você, pode não ser amador e saber o tamanho da responsabilidade do seu código dentro do sistema. Mas e o programador novato ao seu lado? O restante da sua equipe? Sua empresa? E o seu chefe?
Nos próximos posts, vou comentar como cada um destes papéis citados anteriormente contribuem com a construção de um software de forma amadora, onde a qualidade certamente ficará aquém da desejada. Assim que terminar esta espécie de panorama da situação que muitas equipes estão com relação a qualidade do software que desenvolvem, partiremos para a parte técnica.
