Agile Manifesto: a "Bíblia" da agilidade no desenvolvimento de produto

Formalmente, o Agile Manifesto teve início em 2001, mas na realidade, muitas das técnicas e princípios já existiam e eram aplicadas há muitos anos. O exemplo mais marcante é o "Toyota Production System” que advoga a eliminação de desperdícios, para aumentar o valor para o cliente e a eficiência da organização. Este sistema é visto como o precursor do pensamento Lean que está na base do movimento Agile.

 

Regressando ao Agile: Foi em 2001, que dezassete experientes profissionais na área de desenvolvimento de software se reuniram numa estância de esqui, no Utah, nos Estados Unidos da América (durante um fim-de-semana), com um objetivo comum: "revolucionar o modo como o mundo desenvolve software”.

 

Apesar de terem backgrounds diversos e defenderem práticas diferentes e, por vezes divergentes, havia algo que os unia: todos estavam insatisfeitos com o modo como os projetos de desenvolvimento de software eram geridos na altura: excessivo foco na documentação do projeto e processos de desenvolvimento demasiado rígidos, pesados e burocráticos.

 

Durante dois dias, discutiram, debateram e chegaram finalmente a um consenso sobre o que deveria ser considerado o desenvolvimento Ágil de software. Surgiu, assim, o "Manifesto para o Desenvolvimento Ágil de Software” (o Santo Graal do movimento Agile). 

Este manifesto, apesar de curto e simples, encerra os segredos de qualquer implementação Agile bem-sucedida. À primeira vista, pode parecer algo vago e abstrato, mas só depois de verdadeiramente compreendidos e levados à prática os seus princípios, é que podemos ter um produto desenvolvido com qualidade, aportando o maior valor possível para o cliente, com equipas altamente produtivas e motivadas.

 

 

 

 

• "Indivíduos e interações mais do que processos e ferramentas”

 

O mais importante são as pessoas e as suas relações/necessidades/comunicação – quer a nível de equipa, quer na relação com o cliente.

 

É muito mais produtivo e eficaz quando temos toda a equipa envolvida, por exemplo, na análise e discussão dos requisitos e funcionalidades, do que apenas uma pessoa responsável (mesmo que seja o maior expert mundial sobre determinado assunto). Todos os inputs, mesmo de elementos mais juniores ou de áreas diferentes, podem e devem contribuir para um melhor produto ou para uma melhor solução.

 

Devemos privilegiar ao máximo a troca de opiniões e de pontos de vista, porque é em equipa que surgem sempre as melhoras soluções. É interagindo que se identifica e ultrapassa mais facilmente as dificuldades.

 

Também no desenvolvimento de software se aplica a máxima "Duas cabeças pensam melhor que uma”. Todas as variantes de frameworks ágeis privilegiam a comunicação quer dentro da equipa, quer para fora dela (restante organização e clientes).

 

• "Software funcional mais do que documentação abrangente”

 

A única e verdadeira medida de progresso de um projeto de desenvolvimento de software é ter Software funcional. Só tendo algo funcional que possa ser demonstrado, avaliado e criticado é que podemos dizer que estamos a progredir no projeto.

 

Não é suficiente ter documentos extensos ou muito bem escritos, cheios de requisitos, arquitetura ou informação técnica, quando, para o cliente final, estes pouco ou nada representam em termos práticos. Podemos ter tudo isso, mas se não tivermos produto para demonstrar (mesmo que inacabado), não estamos a progredir no projeto.

 

Uma das premissas fundamentais do Agile é ter, desde o início do projeto, software funcional para demonstrar. Porque só assim se pode aprovar/rejeitar, dar feedback e fazer evoluir o produto que queremos construir.

 

• "Colaboração com o cliente mais do que negociação contratual”

 

 

Hoje em dia, e em especial nas áreas de TI, o que é verdade hoje, pode não o ser amanhã. O que o mercado quer hoje, pode já não significar nada amanhã.

De pouco importa entregar um software que, apesar de cumprir escrupulosamente as cláusulas e requisitos estabelecidos em contrato, não vai de encontro às verdadeiras necessidades do cliente e que tantas vezes mudam ao longo do projeto.

 

Por isso, é importante ouvir e envolver o cliente ao longo do projeto e incorporar, constantemente, o seu feedback no desenvolvimento do produto, para que no final vá de encontro às suas expectativas. 

• "Responder à mudança mais do que seguir um plano”

 

Os planos são apenas isso mesmo; "meros planos”! Não são certezas, nem devemos ficar demasiado presos a eles.

 

Os imprevistos, a concorrência, o mercado, os clientes, e a própria organização devem ser vistos como entidades ‘vivas’ que evoluem, às quais nos devemos adaptar constantemente, sob pena de sermos ultrapassados.

 

Este ponto está muito ligado ao ponto anterior. O plano deve ser encarado como uma lista de intenções/objetivos mas não se deve sobrepor ao que é realmente mais importante: a qualidade do produto entregue e da satisfação do cliente.

 

Uma expressão que costumo usar é "logo desde o 1º dia do projeto que o plano já está desatualizado”. Pode parecer exagero, mas é verdade. Desenvolver software é uma arte e não uma ciência exata. Imprevistos vão acontecer, dificuldades vão surgir, os clientes/mercado vão pedir coisas diferentes, a equipa vai identificar melhores modos de entregar produto. Por isso, é fundamental a capacidade de adaptação e de evolução.

 

Apesar de se valorizar mais os pontos identificados à esquerda da frase, não quer dizer que o que está à direita não tenha valor ou que deva ser simplesmente ignorado.

É óbvio que uma correta gestão de projeto precisa de ferramentas e de processos, de documentação (mesmo que interna), de contratos e de planos. O que não deve acontecer é ficarmos de tal modo presos a estes que nos esquecemos do fundamental: a capacidade de reagir à mudança.