Metodologias Ágeis são mais antigas que o Manifesto Ágil

Metodologias Ágeis: a partir de quando?

É cada vez mais frequente a adoção das Metodologias Ágeis por parte das empresas produtoras de Software, principalmente C.R.M. e E.R.P.

Convém salientar que o Manifesto Ágil foi oficialmente assinado em 2001, quando um grupo de desenvolvedores veteranos resolveu se reunir para discutir a agilidade no desenvolvimento de software.

E esta é uma informação importante.

Em 1995, comecei a dar consultoria independente, desenvolvendo aplicativos de Gestão para Indústrias, Comércios e Prestadoras de Serviços.

Costumava fazer visitas semanais, quinzenais ou mensais, para entregar novas funcionalidades, e fazer novos levantamentos de requisitos.

Desta rotina, fazia parte:

• Realizar entrevistas com o responsável de cada setor, para levantamento de requisitos mais detalhados;
• Solicitar cópias de documentos para visão do negócio;
• Quando possível, gravar o áudio das reuniões;
• Apontar as prioridades;
• Já de volta ao local de trabalho, analisar os requisitos e criar as especificações funcionais, já modelando o banco de dados;
• Desenvolver o pacote a ser entregue na próxima visita.

Este tipo de rotina, além de extremamente produtivo, também era bem parecido com o que prega a maioria das metodologias ágeis. E não era pra ser diferente.

Mas também tinha o lado negativo.

Muitas vezes não havia condições de  desenvolver uma só linha de código, pois coincidentemente, todos os usuários resolviam ligar justamente no mesmo dia, cada um em um momento.

Outro lado ruim era o inverso; quando era preciso conversar com alguém do próprio setor no cliente para levantar algum detalhe e esta pessoa ou não estava, ou estava em reunião, ou tinha se atrasado, ou tinha saído mais cedo, ou estava ocupada.

Algumas ocorrências deste tipo e sugeriu-se apontar, em cada empresa, um único responsável pelo software, com quem seria mantido contato  conforme a necessidade.

Isto facilitou em muito o trabalho, pois nos casos apontados anteriormente, algumas vezes travava totalmente a produtividade, pois não poderia continuar enquanto não tivesse aquela dúvida bem sanada.

Falando sobre as especificações funcionais, não se tratavam de documentação excessiva ou extremamente minuciosa. Era um tipo de Caso de Uso (para os mais atuais entenderem), que continham as informações necessárias ao desenvolvimento.

Isto se mostrou extremamente útil quando, após uns anos, fui chamado para trabalhar em uma software-house que operava de um modo um pouco mais burocrático e não produtivo.

Muitos excelentes desenvolvedores não tinham o “dom” da comunicação com usuários, e criavam-se alguns atritos desnecessários.

A ES’s, além de sua utilidade prática, colaborava para evitar estes tipos de confronto.

Uma outra utilidade grande das ES’s, era funcionar como um documento de validação e aceite pelo cliente, pois já havia acontecido a solicitação de uma determinada funcionalidade ser tirada, recolocada, retirada, recolocada, uma 6 vezes. Por “sorte”, tudo estava sempre documentado. E a alteração dos requisitos não eram tão substanciais.

Mas por que toda esta abordagem?

Simples: tenho visto muitos artigos deturpando a essência do desenvolvimento ágil, tornando metodologias não prescritivas em verdadeiras ditaduras, contribuindo para falhas e, em muitas vezes, a não utilização de frameworks que seriam verdadeiros aliados.

Para tirar um pouco da dúvida, vou repetir as 4 abordagens do Manifesto Ágil:

• Indivíduos e interação entre eles, mais que processo e ferramentas;
• Software em funcionamento, mais que documentação abrangente;
• Colaboração com o cliente, mais que negociação de contratos;
• Responder a mudanças, mais que seguir um plano;

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda. “

O texto deixa bem claro que são valorizados os itens à esquerda, mas em nenhum momento diz que os itens à direita devem ser erradicados.

Para se conseguir uma excelência em desenvolvimento, onde apenas os itens à esquerda seja levados ao pé da letra, deverá existir uma equipe excelente, extremamente qualificada e capacitada, e com muito conhecimento de vários tipos de negócios.

Concluindo: para cada empresa, para cada realidade, deve haver uma adequação dos frameworks. Grandes corporações, percebendo a falta de suficiência em um determinado framework, estão partindo para uma “versão” própria de desenvolvimento ágil, onde se chega à um consenso através da tentativa e erro.

E sua empresa, como trabalha?

Sobre o Colunista: Carlos Amaral tem formação em Gestão da Produção Industrial, especialização em Gestão da T.I. e certificação PRINCE2. Trabalha com desenvolvimento de software desde 1989, tendo atuado em praticamente todas as funções dentro de seu ciclo de vida, e participando de projetos ERP e CRM para os mais diversos segmentos de mercado. Entusiasta de software livre, acredita que liberdade é respeitar, também, os entusiastas de software proprietário. Consultor em Projetos de Software, VLogger e autor de artigos na sua área de atuação, não se prende à uma determinada metodologia, procurando extrair o melhor de cada mundo, conforme o cenário.

E-mail de contato: chayimamaral@gmail.com – Site: www.carlosamaral.eti.br

Se você tem comentários, sugestões ou alguma dúvida que gostaria de esclarecer, aproveite o espaço a seguir.