Modismos

A área de TI no brasil é cheia de Modismos que propõem soluções que não resolvem e buscam apenas confrontar com as alternativas existentes. Desde 1993, eu venho presenciando um confronto entre metodologia ágil e cascata para o desenvolvimento de programas. Mais recentemente foi incorporado o DevOps nesta batalha. Nada tenho contra o DevOps e outras técnicas da metodologia ágil. Elas são boas funcionam bem e resolvem muitos problemas. Eu uso no meu dia a dia e sei do enorme valor delas.

No entanto elas não são capazes de corrigir falhas estruturais na ti brasileira. A dura realidade é que nem a metodologia ágil, nem a cascata são capazes de resolver o grave problema de qualificação da mão de obra nacional. A velocidade das mudanças nos negócios é enorme e exige um desenvolvimento cada vez mais rápido. No entanto, o desenvolvimento brasileiro ainda comete o mesmo erro por quase três décadas. Os profissionais de TI pouco ou nada conhecem sobre o negócio e por isto o processo de captura dos requisitos dos projetos é muito falho.

Em geral, a captura dos requisitos de um software é feita de uma forma apressada e amadora. Normalmente, existe a pretensão de estabelecer entre usuário e desenvolvedor sem conhecimento do negócio um canal de comunicação de duas ou três horas para os requisitos. O resultado final desta pratica é um documento horizontal com uma infinidade de requisitos e sem nenhuma verticalidade. Verticalidade significa profundidade na especificação de cada uma das funcionalidades e horizontalidade reflete a quantidade de funcionalidades. Como nem sempre todas as funcionalidades solicitadas são úteis, o desenvolvedor sai deste encontro sem saber o que vai desenvolver e o usuário acha que fez a sua parte no trabalho.

Nem metodologia ágil, nem a cascata, nem o DevOps, nem qualquer outro método é capaz de corrigir tal distorção. As empresas querem maior velocidade no desenvolvimento de software, mas não querem investir o tempo correto no projeto. Iniciar um desenvolvimento com uma enorme quantidade de funcionalidades que em geral são inúteis como requisito do projeto é pedir para fracassar. Por isto, tantos falam que o método a b ou c não funciona. É preciso elencar as prioridades e aprofundar a descrição das funcionalidades. Isto é feito através do function e code description. Apenas depois desta etapa é que é possível trabalhar eficientemente com uma metodologia de desenvolvimento. Eu já usei este procedimento várias vezes e posso atestar que o resultado final é muito bom desde que exista coerência.

O function description é o documento onde todas as funcionalidades do software são descritas com clareza e profundidade. A leitura deste documento pelo desenvolvedor faz com que ele entenda exatamente o que está sendo solicitado. O code description descreve como o código será desenvolvido. Neste documento são elencadas as prioridades das funcionalidades em função das necessidades do negócio. Este é ponto de partida para quebrar o projeto em unidades funcionais menores independentes que podem serem entregues em prazos menores. O code descrition é a linha base para as famosas trocas entre usuários e desenvolvedores. O pleno regime de trocas aumenta a velocidade das entregas porque o que é mais importante ou mais estratégico é entregue antes para a operação do negócio. Não existe perda de tempo em trabalhos irrelevantes para o negócio e novas funcionalidades podem ser incorporadas ao projeto sem impactar o custo qualidade e prazo do projeto. Neste caso, a matriz de prioridade permite trocar funcionalidades, atividades e etc. para que o objetivo de negócio seja alcançado.