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.
Nenhum comentário:
Postar um comentário