Quando você é obrigado a usar o Anta Unified Process (AnUP)

Existem várias propostas de metodologias de desenvolvimento de software. Obviamente, não é o foco desse post discutí-las. Uma das mais famosas é o Rational Unified Process (RUP), um padrão adaptável e muitas vezes criticado pela criação excessiva de documentação mesmo para projetos nanicos a médios. Ele é largamente usado por empresas quando o maior custo é justificado, já que um projeto pode chegar a custar 40% mais.

Do lado oposto, temos as metodologias ágeis, como o SCRUM e o eXtreme Programming. E no meio temos literalmente dezenas de processos de desenvolvimento de software, cada uma atendendo requisitos específicos. Mas nada disso é importante e nenhum treinamento, experiência, livros, certificações ou mestrados serão capazes de derrotar o Anta Unified Process (AnUP) que existe em um nível acima da Programação Orientada a Gambiarras, o POG.

Quando você estiver em um projeto, tente detectar 3 "virtudes" humanas entrando em ação para começar um projeto de forma errada:
- Arrogância
- Soberba
- Ignorância

Quando as pessoas responsáveis por arquitetar o software possuem as duvidosas qualidades acima, prepare-se e redobre a atenção para que as bombas não caiam no seu colo. Infelizmente, profissionais ruins em posição de chefia existem aos montes. Eles não são líderes, são chefes, ou seja, poder através de outorga, não de conhecimento ou respeito. Some-se a isso desconhecimento e a falta de humildade em pedir ou aceitar ajuda e a receita está completa.

Decisões arquiteturais ruins, metodologias de desenvolvimento absurdas e escolhas tecnológicas duvidosas fazem parte do dia a dia de muitos profissionais. Uma empresa pode adotar uma série de padrões de código macarrônico, complicadíssimo de ser usado por simples desconhecimento que existe algo melhor. E quando alguém tenta ajudar, os superiores não ligam nem dão ouvidos. Alguns meses, depois, com o projeto em prejuízo e o diagnóstico feito, perguntam porque não foram avisados.

Outra decisão comum é adotar uma tecnologia ainda em beta, sem avaliar o impacto. É o uso da tecnologia por tecnologia: "Ouvi dizer que Ruby On Rails é muito bom, vamos fazer o projeto usando isso. Sei que o pessoal aqui só programa em PHP, mas acho que todo mundo vai pegar rápido." ou "O projeto é em .Net, então é só pegar o pessoal de Java pra programar as classes em C#, vai ser rapidinho." ou ainda "Vamos adotar Spring, a lista de recursos tem tudo que precisamos."

Essas decisões ruins, que levam ao POG é o Anta Unified Process. É a aplicação de uma série de erros, em cascata e sem aprender com os próprios. A empresa não cresce, tem alta rotatividade de profissionais e a diretoria não consegue pensar fora da caixa. O AnUP passa a fazer parte da cultura da empresa, deixando o mercado com essa imagem ruim de que profissionais de TI trocam demais de emprego.

Moral do Post:
- Quando você detectar as burradas, documente, um a um. Defenda-se cedo para não ter que se explicar mais tarde
- Lembre-se que com prazos estourados os ânimos se acirram. Nada melhor que dizer aos responsáveis pelo AnUP: "avisei na primeira semana de projeto, pega o e-mail do dia tal."
- Use o e-mail, ele é seu amigo. Copie todos os envolvidos. Não seja combativo ou agressivo, mas levante os pontos de preocupação. Por exemplo: "O custo do componente será inferior e com menor risco de erros e problemas que desenvolvê-lo do zero."
- Se você for obrigado a programar um lixo de código, faça-o da melhor forma possível, mas peça tudo por escrito. Peça com educação e caso não façam, use novamente o e-mail: "Conforme o AnUP Master disse, deveremos acessar a base de dados 19 vezes com os mesmos parâmetros, por causa do uso do padrão abcde."
- Muitas vezes, apontar problemas não significa que você será ouvido. Frustração faz parte do mercado e nem mesmo empresas CMMI 5 escapam da do AnUP, pois essa certificação não define qualidade de arquitetura ou desenvolvimento.

Fonte: Bicalho´s Memory About Fraked Up Projects