Certa vez ouvi um palestrante dizer a seguinte frase: "Para os desenvolvedores, XP é uma opção extremamente sexy". E engraçado como tal afirmação é verdadeira. Explicar para alguém que trabalha em um projeto de software é visivelmente mais fácil do que um patrocinador, ou diretor de empresa.
Como uma forma de dar início a um projeto Ágil, tenta-se adaptar as práticas mais apelativas: Testes automatizados, desenvolvimento interativo e pair programming. Mesmo que os benefícios de tais práticas sejam evidentes, é comum que elas sejam mal interpretadas. Isto porque a aparente facilidade que "automatização de testes" ou "programação em dupla" transmite, é completamente diferente da realidade.
Aplicar testes em projetos de software pode ser um processo muito doloroso, por desafiar os principais hábitos dos programadores e trazer uma aparente queda na produtividade. Principalmente por isso, no momento em que você optar em seguir para o "Mundo Ágil", é muito importante utilizar as práticas em sua essência, ganhando a experiência necessária para seguir na criação de um modelo sustentável de desenvolvimento de sofware. É preciso experimentar os reais benefícios das práticas, ganhando confiança para mudanças mais críticas em sua empresa.
Mais uma vez, Ross Pettit apresenta sua visão no site Agile Journal de como a interpretação errada de práticas pode levar a sérios problemas no desenvolvimento, ou ainda causar a impressão errada à equipe e diretoria.
Mito #1: Nós escrevemos testes unitários, mas não importa se eles passam ou não...
Não existe prática com os benefícios mais evidentes que automatizar os testes de software e integrá-los num ambiente de build automático. Entretanto, poucas pessoas se lembram de que é necessário manter os testes criados. Isto é, os desenvolvedores escrevem inúmeros testes automatizados mas não existe a preocupação em manter todos os testes funcionando no momento do build. Assim, a falha de um teste não se torna um "chamado para os desenvolvedores". Esta característica pode ser reflexo de:
- Pressão para que os desenvolvedores mostrem "código finalizado"
- Desenvolvedores não sentem responsabilidade pelos testes que eles não escreveram
- Testes unitário não são desenvolvidos como uma especificação executável, apenas como informação (talvez cumprindo a requisição por documentação)
Desenvolvimento Ágil não é sobre aparências, mas sobre fatos. Esta falsa impressão de qualidade, com a existência de inúmeros testes unitários que não fucionam, deve ser combatida. Sem o comprometimento em manter o conjunto de testes sempre funcionando, todo este código gerado não passará de lixo. Isto mesmo: lixo
Todo o controle de riscos existente em uma equipe Ágil estará perdido. Uma vez que os testes não garantem que o código está funcionando, qualquer problema/bug/nova funcionalidade adicionada não poderá ser analisada com confiança.
(...)
Leia o documento completo
[]s
Nenhum comentário:
Postar um comentário