Este documento fornece um resumo dos principais conceitos de metodologias ágeis para desenvolvimento de software. Ele descreve como os métodos ágeis surgiram em resposta aos métodos tradicionais rígidos e enfatizam a adaptação às mudanças através de entregas frequentes e colaboração estreita com os clientes. O documento também resume os 12 princípios e práticas comuns dos métodos ágeis, como planejamento iterativo, integração contínua e simplicidade.

1. Conceitos Básicos Sobre Metodologias
Ágeis Para Desenvolvimento de Software
Charles Sá

2. •Formado em Ciências da Computação
•Pós-Graduado em Engenharia de Sistemas
•Pós-Graduado em EAD
•Gerente de Projetos do Núcleo de Tecnologia da
Informação da Universidade Vale do Acaraú – NTI UVA
•Desenvolvedor Autônomo Java, PHP e Delphi
/felizardocharles
/charlessoftwares
www.charles.esy.es
felizardocharles@hotmail.com

3. Métodos Clássicos/Tradicionais

4. Métodos Clássicos/Tradicionais
lBaseados em processos e planejamento;
lModelo “cascata”, seguem rigorosamente uma cronologia;
lSupõe-se que é possível prever o futuro;
lPouca interação com o cliente;
lÊnfase em burocracias (documentação);
lInflexibilidade (controle rígido);
lFalhas de comunicação interna.

5. Métodos Clássicos/Tradicionais
FUNCIONA?

6. Métodos Ágeis
Velocidade?

7. Métodos Ágeis
Não! Adaptação às mudanças.

8. Métodos Ágeis
Maior interatividade.

9. Metodologias Ágeis
lNasceu como uma resposta aos métodos “pesados” a
partir de 1990, por programadores experientes e
consultores em desenvolvimento de software;
l17 “gurus” publicaram o MANIFESTO ÁGIL em 2001 em
uma estação de esqui em Utah, EUA;

10. Métodos Ágeis – Missão dos Gurus
lDefinir um estilo de desenvolvimento de software que
trate dos riscos que envolvem esse processo;
lComunicar essa disciplina da maneira mais clara
possível para programadores, gerentes e clientes;
lDefinir recomendações para adaptá-lo às condições
locais;
l– Kent Beck

11. Métodos Ágeis – Mudanças
lRequisitos mudam;
lO projeto muda;
lOs negócios mudam;
lA tecnologia muda;
lO time (parte ou todo) muda;
l“DEVE-SE TER HABILIDADE PARA LIDAR COM A
MUDANCA QUANDO ELA ACONTECER”.

12. Métodos Ágeis – Riscos
lDeslizes no cronograma
lProjeto cancelado
lO sistema "azeda"
lAlta taxa de erros
lNegocio mal compreendido
lMudanças de requisitos
lFalsa riqueza de funcionalidades
lRotatividade da equipe
Guarde este
slide!!!

13. Métodos Ágeis – O que são?
lNão há uma definição precisa;
lVisam a melhoria constante do trabalho;
lPráticas específicas variam muito e a maioria dos
métodos ágeis possuem conceitos similares;
lAbordagem de planejamento e execução interativa
voltado para processos empíricos (complexos, caóticos
e com muitas incertezas);
lPrincipais métodos: XP (Extreme Programming), Scrum,
FDD (Feature Driven Development), MSF (Microsoft
Solution Framework), DSDM (Dynamic System
Development Model), Crystal Clear, etc.

14. Métodos Ágeis – Problemáticas
“Em um novo projeto de software, os requisitos nunca serão
completamente conhecidos até que o usuário os tenha utilizado.”
Watts Humphrey, IBM Research
“A incerteza é inerente e inevitável nos processos de
desenvolvimento de software e produtos.”
Hadar Ziv, University of California

15. Métodos Ágeis – Problemáticas
Relatório do Caos (Chaos Report) -
2004

16. Métodos Ágeis – Problemáticas
Relatório do Caos (Chaos Report) -
2004
Mais de 64% de um sistema de
software quase nunca não é utilizado!

17. Métodos Ágeis – O Manifesto Ágil
“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:”

18. Métodos Ágeis – O Manifesto Ágil

19. Princípios Ágeis
lNossa maior prioridade é satisfazer o cliente através da
entrega contínua e adiantada de software com valor
agregado.
lMudanças nos requisitos são bem-vindas, mesmo
tardiamente no desenvolvimento. Processos ágeis tiram
vantagem das mudanças visando vantagem competitiva
para o cliente.
lEntregar frequentemente software funcionando, de
poucas semanas a poucos meses, com preferência à
menor escala de tempo.

20. Princípios Ágeis
lPessoas de negócio e desenvolvedores devem trabalhar
diariamente em conjunto por todo o projeto.
lConstrua projetos em torno de indivíduos motivados. Dê
a eles o ambiente e o suporte necessário e confie neles
para fazer o trabalho.
lO método mais eficiente e eficaz de transmitir
informações para e entre uma equipe de
desenvolvimento é através de conversa face a face.

21. Princípios Ágeis
lSoftware funcionando é a medida primária de progresso.
lOs processos ágeis promovem desenvolvimento
sustentável. Os patrocinadores, desenvolvedores e
usuários devem ser capazes de manter um ritmo
constante indefinidamente.
lContínua atenção à excelência técnica e bom design
aumenta a agilidade.

22. Princípios Ágeis
lSimplicidade – a arte de maximizar a quantidade de
ltrabalho não realizado – é essencial.
lAs melhores arquiteturas, requisitos e designs emergem
de equipes auto-organizáveis.
lEm intervalos regulares, a equipe reflete sobre como se
tornar mais eficaz e então refina e ajusta seu
comportamento de acordo.

23. 12 Práticas do Desenvolvimento Ágil

24. 12 Práticas do Desenvolvimento Ágil
l1 - O JOGO DO PLANEJAMENTO
lReuniões periódicas, a cada ciclo de iteração;
lEvita planejamento extenso e rígido;
lPossibilidade de correções de rota durante o processo;
lPlanejamento das próximas entregas;
lFacilita estimativas de custo e gerenciamento.

25. 12 Práticas do Desenvolvimento Ágil
l2 – DESENVOLVIMENTO ORIENTADO A TESTES
lTestes constantes e não só ao final do processo;
lDesenvolvimento limpo e organizado;
lDescarte das partes desnecessárias do código a cada
iteração.

26. 12 Práticas do Desenvolvimento Ágil
l3 – PROGRAMAÇÃO EM PARES
l2 desenvolvedores em uma mesma aplicação, ao mesmo
tempo, em uma só máquina;
l“Fiscalização” constante da codificação;
lDesenvolvedores codificando sozinhos são mais
propensos a erros;
lCódigo de qualidade, menos propenso à falhas.

27. 12 Práticas do Desenvolvimento Ágil
l4 – INTEGRAÇÃO CONTÍNUA
l Possibilidade de integrar constantemente e rapidamente
os códigos desenvolvidos em um ambiente de
integração automatizada para o ambiente de produção.

28. 12 Práticas do Desenvolvimento Ágil
l5 – REFATORAÇÃO CONSTANTE
lReestruturar o código sempre que necessário, sem
alterar seu comportamento externo;
lMelhoria da qualidade interna do software para que ele
não “azede” quando chegar em produção;
lReduzir a complexidade da programação.

29. 12 Práticas do Desenvolvimento Ágil
l6 - SIMPLICIDADE
lNenhuma linha de código será escrita caso não tenha
um valor real para o sistema e seus usuários;
lDeve-se fazer somente o necessário, nada mais
lO melhor design é o design funcional.

30. 12 Práticas do Desenvolvimento Ágil
l7 – CICLOS CURTOS DE ENTREGA
lEm um método tradicional, o cliente só entra em contato
com o software quando um grande número de
funcionalidades já foram finalizadas e entregues;
lEntregas pequenas garantem maior agilidade ao
processo de desenvolvimento, permitindo que o usuário
utilize o sistema logo no início, estimulando a
colaboração e os ajustes no código em uma fase mais
adequada do projeto.

31. 12 Práticas do Desenvolvimento Ágil
l8 - METÁFORA
lDescrição mental de como o sistema funciona.
l9 – PROPRIEDADE COLETIVA DO CÓDIGO
lQualquer desenvolvedor pode alterar qualquer parte do
código a qualquer momento;
lNão existe “dono do código”.

32. 12 Práticas do Desenvolvimento Ágil
l10 – RITMO SUSTENTÁVEL
lSemana de 40 horas;
lSem horas-extras;
lDiminui a evasão de colaboradores do time.

33. 12 Práticas do Desenvolvimento Ágil
l11 – CLIENTE PRESENTE
lO cliente como parte integrante do time;
lPossibilita feedbacks constantes;
lAumenta o tempo de resposta à mudanças de escopo no
meio do processo.

34. 12 Práticas do Desenvolvimento Ágil
l12 – PADRÕES DE CODIFICAÇÃO
lCódigo padronizado agrega qualidade;
lDar a impressão de que todo o código foi escrito por
uma única pessoa.

35. Métodos Ágeis – Riscos
lDeslizes no cronograma = ciclos curtos de entrega;
lProjeto cancelado = menor release priorizado pelo negócio
/entregas frequentes;
lO sistema "azeda" = testes abrangentes;
lAlta taxa de erros = testes desenvolvedor e cliente;
lNegócio mal compreendido = cliente presente como parte do
time;
lMudanças de requisitos = ciclos curtos de entrega;
lFalsa riqueza de funcionalidades = priorizado pelo negocio;
lRotatividade da equipe = estimativa pelo desenvolvedor.
Guardou este slide??

36. Analogia

37. Analogia
lDirigir não é manter-se sempre na mesma direção;
lDirigir é prestar atenção constantemente, fazendo uma
pequena correção para um lado, outra pequena correção
para o outro
lMesmo que as coisas pareçam perfeitamente bem,
nunca tirar o olho da estrada.

38. Moral da História
lEm um projeto de software, se o software não faz o que
o cliente quer, você falhou;
lNosso trabalho, como desenvolvedor ágil, é fornecer
feedbacks constantes sobre a nossa posição na estrada;
l Você deve observar a estrada e fazer correções
contínuas para se manter no caminho.

39. Principais Certificações

40. /felizardocharles
/charlessoftwares
www.charles.esy.es
felizardocharles@hotmail.com