Quando os gerentes de projetos enxergam que o processo está falhando, sua primeira sugestão é: temos pouco processo. Então, inflam ainda mais o portfólio de documentos a serem produzidos. Isto é feito porque acredita-se que, se for empregado esforço suficiente, todos os requisitos poderiam ser antecipados.
O desenvolvimento ágil apresenta uma quebra de paradigma: O objetivo é gerenciar o projeto para que as mudanças custem menos, ao invés de tentar prevê-las. Esta é uma resposta à espectativa do mercado, que demanda mais qualidade em menos tempo. Qualidade? Pois é, cada método ágil tem sua preocupação com a qualidade. Alguns, baseados no “mythical man-month“, lembram que introduzir novas pessoas, assim como novos documentos, em um projeto atrasado, não significa melhorá-lo. Pelo contrário, o efeito pode ser bastante negativo. O scrum planeja reuniões diárias para o alinhamento das tarefas. O XP exige que o teste de um módulo seja escrito antes de iniciar seu desenvolvimento.
Existem alguns autores que defendem a idéia de que o ágil é uma máscara para a indisciplina. Assim, criou-se na comunidade de engenharia de software uma guerra entre árabes e judeus: Os defensores do Ágil chegaram com um discurso fervoroso favorecendo sua nova metodologia, provocando grande crítica por parte dos defensores das metodologias tradicionais. Por utilizarem argumentos pretensiosos e utópicos, a nova proposta soou como uma afronta.
Para o professor Julio Leite, o maior erro das pessoas é pensar que a mesma roupa veste todo mundo. Os dois lados da moeda têm muito o que acrescentar, e quem vai estudar o tema tem que ter a maturidade de filtrar as informações úteis do que está lendo. A razão não é algo que possa ser expressado em 0 ou 1. Em todas as discussões, todas as partes tem argumentos relevantes, que merecem ser analisados.
As regras do Ágil não pretendem englobar tudo que é necessário para a produção do software. Elas são apenas uma base, um conjunto de pontos fundamentais que devem ser abordados por quem pretende construir software usando métodos ágeis. Portanto, como Barry Boehm sugere, é possível que haja métodos híbridos, e estes podem ser a melhor solução para a maioria dos negócios.
Os métodos ágeis se apoiam em dois princípios básicos: no código funcionando e no fator pessoa.
O código funcionando é uma nova forma de se comunicar com o cliente: não envolve abstração, e assim elimina possíveis mal-entendidos. O que se tem é o que se pode ver. No ágil, a equipe se compromete a entregar código funcionando em curtos intervalos, de duas a cinco semanas. O cliente pode verificar se o que está sendo feito realmente atende às expectativas.
O fator pessoa se apoia na idéia de que as pessoas interagindo diretamente são a melhor forma de transmissão de conhecimento. O ágil exige proximidade para funcionar, tanto entre os membros da equipe quanto entre a equipe e o cliente. Estando juntas e conversando diretamente, tarefas como constante definição de prioridade, inclusão de um novo membro na equipe, eliminação de mal-entendidos, etc., podem ser realizadas com mais velocidade e menos custo.
Apoiados nessas idéias, 17 pessoas que desenvolviam seus próprios métodos alternativos de desenvolvimento de software assinaram um documento, chamado Manifesto para Desenvolvimento Ágil de Software:
Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar:
Indivíduos e interações entre eles mais que processos e ferramentas
Software funcionando 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.
Os métodos ágeis possuem características comuns, apesar de cada um implementá-las de forma diferente.
No ágil, especificação, projeto e desenvolvimento ocorrem simultâneamente. Isto quer dizer que nenhuma das tarefas é pré-requisito de outra. O desenvolvimento, por exemplo, ajuda a elicitação dos requisitos.
As iterações, ou seja, o tempo entre as entregas dos incrementos, é bastante curto. Desta forma, é mantido um feedback constante para o cliente. O planejamento é sempre feito para o próximo incremento. O que vai ser feito depois vai ser planejado depois.
Um ponto importantíssimo do ágil é a priorização dinâmica. A todo tempo é necessário rever o que será feito primeiro. O scrum, por exemplo, tem um esquema de priorização de tarefas por pontos, que é revisto junto com o cliente em todo início de iteração.
A equipe deve estar sempre próxima, já que a comunicação no ágil é feita através de interação direta. Tudo deve ser tratado verbalmente, por mais que se escreva algo sobre o que foi discutido depois. Como foi dito anteriormente, este é um dos pilares da metodologia, grande parte do sucesso dos projetos reside aqui.
Da mesma forma que a comunicação dentro da equipe é feita diretamente, o cliente também é tratado desta forma. É importante que, ao menos uma vez a cada ciclo, exista uma reunião entre cliente e equipe que aborde o que foi e o que será feito. A reunião deve ter a presença de todos os integrantes da equipe, além do cliente. Cabe ressaltar que o cliente não necessariamente é alguém da empresa que comprou o software. O cliente pode ser alguém que trabalhe na mesma organização que a equipe, mas o seu papel de cliente deve estar bem claro.
Por fim, os membros da equipe precisam ter em mente a possibilidade de mudança. Portanto, o software precisa ser construído para suportá-la. Assim, princípios como o KISS(keep it simple) são frequentemente acoplados aos métodos.
Referências: HIGHSMITH, Jim, COCKBURN, Alistair: Agile Software Development: The Business
of Innovation. IEEE Computer 34(9): 120-122 (2001)
