44.220.251.236
(+244) 921 543 587Ligue Já!
Ou nós ligamos!Deixe os seus dados para contacto.
Seremos breves!
Horário - dias úteis das 9h30 às 18h30
Agile manifesto
{alt:Paulo Correia}

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

Afinal, como surgiu o Agile Manifesto?

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.
 

Eis o seu conteúdo:

 

Ao desenvolver e ao ajudar outros a desenvolver software,

temos vindo a descobrir melhores formas de o fazer.

Através deste processo começámos a valorizar:

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

Software funciona, mais do que documentação abrangente

Colaboração com o cliente mais do que negociação contratual

Responder à mudança mais do que seguir um plano

Ou seja, apesar de reconhecermos valor nos itens à direita,

valorizamos mais os itens à esquerda.
 
 

Derramando alguma luz sobre o seu conteúdo:

 
• "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”
 
O que é mais importante: cumprir à risca um contrato ou ter um cliente satisfeito?
 
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.
 
É este o verdadeiro sentido da AGILIDADE.
Receba a newsletter com as nossas melhores histórias!