Requisitos: A Disciplina "Ágil" Esquecida II

Após um "breve" hiato de 5 meses, cá estou. Não gosto de falar sobre futurologia do passado principalmente no que se refere ao meu trabalho, mas estou continuando um post que estava em rascunho de 17/09/2008. Vou concluir este trabalho abaixo e depois tentar dar continuidade frente a alguns fatos novos ocorridos nas últimas semanas.

Segue o "original".

No contexto de Engenharia de Processos em Software acredito que estejamos vivendo em um movimento pendular entre níveis de formalismo e agilidade. De um lado temos o que foi confortavelmente rotulado de "tradicional" pela liderança da comunidade ágil (um mix dos estratagemas de Schopenhauer números 12 e 19), do outro lado temos tudo que é bom, belo, justo e providencial regido sob os auspícios do manifesto ágil.

Qual o problema? O problema é justamente o seguinte: praticamente tudo o que é passível de adoção pela comunidade ágil é uma aceitação a priori da verdade de temas sem que uma avaliação crítica honesta seja feita por seus membros. Estes temas (ou variações menores sobre o mesmo tema) são propagados como rastilho de pólvora e aceitos (take for granted) sem contestação. Na velocidade do blogosfera é praticamente impossível avaliar criteriosamente o que blogueiros postam, fazendo com que o valor potencial da informação de fontes primárias seja prejudicado.

Um exemplo do prejuízo causado pela falta de contextualização histórica e análise crítica é justamente a presunção de achar que todos os benefícios do desenvolvimento de sistemas moderno é derivado das práticas ágeis. Trocando em miúdos, o mundo começou com o manifesto ágil, com o Scrum e com o XP.

Várias práticas efetivas dos "métodos ágeis" não foram uma invenção originária dos luminares dos métodos ágeis. Bem da verdade várias práticas "ágeis" já eram adotadas até dez anos (ou mais) antes do manifesto ágil (olhem McConnell). As práticas se tornaram cool apenas pelo rebranding.

Neste cenário quem é diretamente prejudicado? Esta é a deixa do nosso desenvolvedor Joe Six-pack. O Joe é um cara ocupado. Entrou para informática para desenvolver jogos, mas acabou se tornando um programador comercial.

Joe trabalha numa empresa onde a TI está em sua adolescência ainda. A TI não trabalha mais com sistemas meio e sim na própria atividade fim da empresa. A atividade fim, ao contrário de uma folha de pagamento ou sistema de manutenção, deve se adaptar ao mercado. Se os sistemas não se adaptam, a empresa simplesmente é engolida pelo mercado.

Com o peso de sistemas "fim" sob seus ombros, Joe não tem benefício da reflexão devido às pressões do ambiente. Joe tem que entregar. Joe já tentou uma série de metodologias para tentar se adaptar melhor ao ambiente, mas falhou em todas, por diversas razões: falta de buy-in da gerência, falta de priorização da diretoria e, principalmente, a falta de um plano de melhoria contínua, o que na administração é chamado de PDCA.

Joe, já desistindo completamente do processo de software (afinal o que não tem solução, solucionado está) houve falar de uma nova tendência de mercado, um tal de movimento ágil. Nele simplificamos as coisas (afinal é o que os blogueiros dizem) : não desenvolvemos documentação, aliás podemos até queimar a documentação, afinal o usuário sempre estará por perto para dar uma dica; não nos preocupamos em refletir sobre o que construir, afinal tudo muda tão rápido que é mais fácil construir primeiro e perguntar para o usuário depois, afinal já temos um lembrete na parede sobre o que devemos construir, qualquer dúvida, o usuário está lá.

A maior baixa neste fogo cruzado foi justamente a Engenharia de Requisitos, alvo do atrelamento infundado de grandes mitificações. Requisitos não são software em funcionamento, requisitos são um calhamaço de documentos do Word que podem ser jogados fora assim que o software estiver rodando, afinal para que requisitos escritos enquanto testes de software são "requisitos vivos".

Finalmente Joe achou alguma coisa valiosa. Tentou gerenciar a complexidade de desenvolvimento com processos prescritivos e não conseguiu, agora está mais tranquilo. Afinal ele já sabe nada o que foi feito antes chegou a funcionar algum dia.

Voltei

É claro que isto é apenas uma alegoria. Super simplificação? Com certeza, não tenho aspirações a fazer uma tese neste blog. Muito menos tenho a pretensão de expor A VERDADE em poucas linhas.

Agora retomo o assunto nos próximos posts.