Tradicional x Moderno - Realidade contra Falsidade

Recentemente eu li um artigo que comparava o ITIL (Information Technology Infrastructure Library) e CMMI (Capability Maturity Model Integration) em relação ao DevOps. O autor apresentou com ênfase diversas vantagens do DevOps. Infelizmente, o texto estava impregnado de desconhecimento sobre o que foi chamado pelo autor de métodos tradicionais. Vários dos benefícios atribuídos ao DevOps em relação aos métodos tradicionais não são benefícios reais. São apenas e tão somente erros. Os erros cometidos não eram consequência dos processos dos métodos tradicionais, eles eram o resultado da falta de capacidade e conhecimento dos profissionais envolvidos no planejamento dos projetos.

Para ficar mais claro vou pontuar cada um dos benefícios atribuídos ao DevOps. O primeiro é muito citado em diversos artigos e diz que métodos ágeis como o DevOps são capazes de oferecer entregas frequentes de pacotes menores e por causa disto mais rápidas. Este estratagema dos métodos ágeis assegura um ciclo permanente de evolução da entrega e prazos menores. Na prática, basta que o gerente de projeto ou portfólio planeje o projeto em unidades funcionais enxutas onde as entregas são rápidas, frequentes e evolutivas para o que o planejamento enderece a necessidade de velocidade e flexibilidade do negócio.

Tal planejamento é possível de ser executado em qualquer metodologia existente na face terrestre. Não é uma vantagem dos métodos ágeis. É uma vantagem da contratação de profissionais qualificados para o planejamento do projeto. A segunda vantagem atribuída ao DevOps é que o mesmo não segura a equipe de testes parada enquanto o desenvolvimento faz o seu trabalho. Novamente não estamos falando de uma vantagem do DevOps em relação ao ITIL ou CMMI. Se em um projeto de ITIL ou CMMI a equipe de testes ficava parada esperando o desenvolvimento, isto é um erro do planejamento. O profissional que planejou o projeto não tinha conhecimento e capacidade para gerir o mesmo. Não existe um único processo nestas ferramentas que exija que a equipe de testes fique parada esperando o desenvolvimento.

O autor cita como vantagem para o DevOps em detrimento das técnicas tradicionais a pequena quantidade de funcionalidades novas que são transportadas para o ambiente de produção. O que ele descreveu foi um erro de planejamento do projeto. O envio de muitas funcionalidades novas para a produção não é uma característica intrínseca do modelo ITIL ou CMMI. Os dois modelos permitem o envio de apenas uma nova funcionalidade para a produção. A quantidade de novas funcionalidades para a produção é escolhida pelo gerente do projeto. Profissionais capacitados sabem o que podem fazer em um projeto e qual é o impacto das suas decisões.

No próximo item o autor do artigo comete dois equívocos simultâneos. Quando ele afirma que uma grande entrega consome muito processamento por conta de trabalho duplicado ele assume erradamente que o ITIL e o CMMI geram obrigatoriamente pacotes grandes para entrada na publicação. Em nenhum destes dois métodos existem determinações ou especificações sobre o tamanho do pacote a ser publicado. É o gerente do projeto que vai decidir o tamanho do pacote que será publicado. Além disto, um pacote grande só gera o desperdício de retrabalho quando existem erros de planejamento. Um gerente de projetos capacitado não comete estes erros em qualquer modelo que ele esteja utilizando. Novamente não é um benefício gerado pelo DevOps.

No quinto item o autor apontou benefícios do DevOps para o inventario. Novamente ele aponta o problema de um pacote de publicação grande. Por conta disto, o benefício apontado é um equívoco. Em nenhum momento o ITIL ou CMMI exige ou obriga que os pacotes publicados sejam grandes. Quem define isto é o gerente do projeto. No texto, o autor afirmou que o inventário mais afetado era o de Work In Progress (WIP) que são os materiais ou componentes que estão na fase de transformação para o produto acabado. Foi afirmado erradamente que uma publicação grande tem muitos itens em WIP e por causa disto o desenvolvimento é um gargalo e que os envolvidos nas próximas etapas ficam em compasso de espera por muito tempo gerando desperdício de recursos, tempo e dinheiro. O equívoco da afirmação está na dimensão que estas perdas são consequências de um pacote grande de publicação.

O problema do tempo de espera elevado é consequência de um planejamento falacioso não do tamanho do pacote. Isto significa que não devemos atribuir ao DevOps a virtude da solução da eliminação do desperdício da espera. Um planejamento adequado para a entrada de um pacote grande na produção impede que existam gargalos e perdas de recursos, dinheiro e tempo por causa de espera. Um gerente de projetos qualificado é capaz de identificar todos os gargalos do projeto e encontrar soluções compatíveis com o negócio. Estas soluções são independentes dos modelos adotados.

O sexto item apontado foi o movimento, onde várias funcionalidades estão sendo desenvolvidas por diversas equipes. A sexta vantagem do DevOps sobre o ITIL e CMMI apontada pelo autor foi a movimentação, ou seja, as várias funcionalidades que estão sendo desenvolvidos pelos diversos times estão navegando entre as raias dos processos. Os responsáveis pela qualidade estão neste caso recebendo informações de diversos times sobre a mesma funcionalidade. Mais um equívoco é cometido pelo autor. Em nenhum momento o ITIL ou CMMI determina a quantidade simultânea de funcionalidades desenvolvidas. Este é mais um caso onde o gerente do projeto é o responsável pela decisão. No desenvolvimento do cronograma ele define quantas funcionalidades serão desenvolvidas simultaneamente.

No sétimo e último benefício do DevOps apontado pelo autor que uma entrega grande aumenta a probabilidade de defeitos após o lançamento. O propalado benefício é apenas e tão somente mais do mesmo equívoco. Em nenhum momento o ITIL ou CMMI determina o tamanho da entrega. O responsável pelo tamanho da entrega de um projeto é o gerente do projeto. Ele escolhe o que será entregue e quando será no desenvolvimento do cronograma do projeto. Infelizmente o artigo que li revela que existe um profundo desconhecimento sobre as ferramentas de governança disponíveis no mercado. Tem-se a pretensão de identificar benefícios que em geral são inexistentes por ouvir falar. Em nenhum momento é colocado o dedo na ferida e apontado que as decisões pobres dos gerentes dos projetos estão comprometendo o seu desenvolvimento. Estas decisões pobres são tomadas quer o modelo em uso seja o ITIL, CMMI ou DevOps. Simplesmente trocar de modelo como proposto pelo autor de ITIL para DevOps não vai resolver o problema brasileiro de desenvolvimento. Aliás os números de 2015 mostram que os resultados continuam tão pobres como sempre foram. É preciso evoluir a honestidade intelectual e afirmar que o real problema do desenvolvimento é a falta de capacitação do gerente de projetos. As certificações de gerenciamento de projetos existentes no mercado brasileiro são claramente insuficientes para aferir o nível mínimo de qualificação que um gerente de projetos tem que ter para gerar resultados aceitáveis.

O desenvolvimento é pobre não por causa dos modelos utilizados, mas sim por causa da falta de conhecimento do gerente do projeto. No Brasil, muitos querem ser gerentes de projetos. Este trabalho é para profissionais experientes que são capazes de identificar os desafios e elaborar um plano de projeto capaz de gerar um resultado positivo. Existem no mercado profissionais que acham que o fato deles não conseguirem resolver um problema isto significa que o problema é insolúvel quando na realidade os profissionais qualificados estão resolvendo este problema. É por este motivo que o Brasil ficou na rabeira no mercado de software.