Valores

Nós estamos descobrindo novas maneiras de desenvolver software fazendo e ajudando outros a fazê-lo. Através deste
trabalho nós valorizamos:

- Indivíduos e interações mais que processos e ferramentas.
- Software funcionando mais que documentação compreensiva.
- Colaboração do cliente mais que negociação de contrato.
- Responder à mudanças mais que seguir um plano.

“Isto é, muito embora valorizemos os itens da direita, valorizamos mais os da esquerda!”

NÃO é ruptura! É ÊNFASE!

Autoria

17 Autores (11 a 13 de Fevereiro de 2001)

http://agilemanifesto.org/

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland

Os 12 Princípios

Diretrizes para um projeto de software de sucesso:

1) A mais alta prioridade é a satisfação do cliente através da liberação mais rápida e contínua de software de valor.

2) Receba bem as mudanças de requerimentos, mesmo em estágios tardios do desenvolvimento. Processos ágeis devem admitir mudanças que trazem vantagens competitivas para o cliente.

3) Libere software com a frequência de um par de semanas até um par de meses, com preferência para a escala de tempo mais curta.

4) Mantenha as pessoas dos negócios e os desenvolvedores trabalhando juntos a maior parte do tempo do projeto.

5) Construa projetos com indivíduos motivados, dê a eles o ambiente e suporte que precisam e confie neles para ter o trabalho realizado.

6) O método mais eficiente e efetivo de repassar informação entre uma equipe de desenvolvimento é através de conversação cara-a-cara.

7) Software funcionando é a principal medida de progresso.

8) Processos ágeis promovem desenvolvimento sustentado. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter conversação pacífica indefinidamente.

9) A atenção contínua para a excelência técnica e um bom projeto aprimora a agilidade.

10) Simplicidade – a arte de maximizar a quantidade de trabalho não feito – é essencial.

11) As melhores arquiteturas, requerimentos e projetos emergem de equipes auto-organizadas.

12) Em intervalos regulares, as equipes devem refletir sobre como se tornarem mais efetivas, e então refinarem e ajustarem seu comportamento de acordo.