O documento apresenta os princípios e metodologias ágeis, destacando que cerca de 30% dos projetos de TI tradicionais têm sucesso contra 80% dos projetos ágeis. Apresenta o Manifesto Ágil e seus princípios como entrega contínua, colaboração, resposta a mudanças. Também descreve as metodologias Scrum, Extreme Programming e Unified Process como exemplos de processos ágeis.
2. Por que, afinal, ser Ágil?
• Em torno de 30% dos projetos de TI são bem sucedidos
• Em torno de 80% dos projetos Ágeis são bem sucedidos
Fontes: CHAOS Report 2009 e Agile Survey 2009
3. Origem do Agile
Contexto
Modelos de processo iterativo incremental
Deming
Melhoria Contínua - PDCA (Plan Do Check Act)
Lean Manufacturing - Eliminação de desperdícios
Manifesto Ágil
The new methodology
4. Princípios por trás do Manifesto Ágil
Nossa maior prioridade é
satisfazer o cliente através da
entrega contínua e adiantada
de software com valor
agregado
Mudanças nos requisitos são
bem-vindas, mesmo
tardiamente no
desenvolvimento. Processos
ágeis tiram vantagem das
mudanças visando vantagem
competitiva para o cliente
Entregar frequentemente software
funcionando, de poucas semanas a
poucos meses, com preferência à
menor escala de tempo.
Pessoas de negócio e
desenvolvedores devem trabalhar
diariamente em conjunto por todo o
projeto
5. Princípios por trás do Manifesto Ágil
Construa projetos em torno de
indivíduos motivados. Dê a
eles o ambiente e o suorte
necessário e confie neles para
fazer o trabalho.
O método mais eficiente e
eficaz de transmitir
informações para e entre uma
equipe de desenvolvimento é
através de conversa face a
face.
Software funcionando é a medida
primária de progresso.
Os processos ágeis promovem
desenvolvimento sustentável.
Os
patrocinadores, desenvolvedores e
usuários devem ser capazes de
manter um ritmo constante
indefinidamente
6. Princípios por trás do Manifesto Ágil
Contínua atenção à
excelência técnica e bom
design aumenta a agilidade
Simplicidade – a arte de
maximizar a quantidade de
trabalho não realizado – é
essencial
As melhores arquiteturas, requisitos
e designs emergem de equipes
auto-organizáveis.
Em intervalos regulares, a equipe
reflete sobre como se tornar mais
eficaz e então refina e ajusta seu
comportamento de acordo
12. Nokia Test
O Time entrega software executável ao final de cada
Sprint (< 4 semanas) que teve todas as funcionalidades
testadas?
O Time especifica o mínimo necessário antes de
começar uma Sprint? O Product Backlog está pronto
antes de se começar uma Sprint?
O Time tem um Product Owner? Um Product Backlog?
Ele foi estimado pela equipe?
O Time tem um gráfico de Burndown? Eles sabem qual é
a sua velocidade?
O Time está livre de interrupções durante o Sprint?
15. Scrum: papéis e responsabilidades
Cliente
Product
Owner
Usuário Final
16. Dinâmica
Em equipe, entregue o máximo de produtos possível.
Produto: bolas de tênis entregues no galão.
Restrições
Cada bola tem de passer na mão de todos os membros da
equipe
A bola não pode passer na mão do membro da equipe que
estiver imediatamente ao seu lado (em fila)
Timebox:
2 minutos para o planejamento
1 minuto para execução
2 minutos para retrospectiva
19. 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
Dave Thomas
Manifesto para Desenvolvimento Ágil de Software
Estamos descobrindo maneiras melhores de desenvolver
software, fazendo-o nós mesmos e ajudando outros a
fazerem o mesmo. Através deste trabalho, passamos a valorizar:
Indivíduos e interações mais que processos 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.