3. Manifesto
• Ano: 2001;
• 17 Pessoas: desenvolvedores, consultores e
autores;
• Agile Alliance: Aliança dos Ágeis;
• Manifesto for Agile Software Development:
Manifesto para o Desenvolvimento Ágil de
Software.
4. Manifesto
• Declaração do Manifesto Ágil:
• Por meio deste trabalho passamos a valorizar:
1. Indivíduos e interações acima de processos e
ferramentas;
2. Software operacional acima de
documentação completa;
3. Colaboração dos clientes acima de
negociação contratual;
4. Respostas a mudanças acima de seguir um
plano.
5. Manifesto
Processos, ferramentas, documentação,
contratos e planos
terão mais sentido e mais valor depois que
indivíduos, interações, software funcional,
colaboração do cliente e resposta às mudanças
também foram considerados importantes.
6. Manifesto
• De nada adianta:
• Um processo bem estruturado se as
pessoas não o seguem.
• Um software bem documentado se não
satisfaz os requisitos (ou não funciona).
• Etc.
7. Manifesto
• Aceita o cliente como parte da equipe;
• Tenta eliminar a atitude de “NÓS” e “ELES”;
• Incentiva a estruturação e as atitudes em
equipe tornando a comunicação mais fácil;
• Reconhece que o planejamento em um
mundo incerto tem seus limites;
• O plano de projeto deve ser flexível.
8. Manifesto
• Enfatiza a entrega rápida do software
operacional;
• Solicita aos usuários envolvidos que forneçam
feedback constante;
• Gerar somente a documentação necessária;
• Manter comunicação constante informalmente;
• Os requisitos e o ambiente mudarão
inevitavelmente.
9. Manifesto
• Desenvolver software em interações
menores;
• Garantir que haja sempre um produto
acabado;
• Exigir apenas um nível normal de esforço dos
desenvolvedores;
• Requisitos não precisam estar
completamente especificados desde o inicio.
10. Manifesto
• Um manifesto ataca a velha guarda e sugere
uma mudança revolucionária para melhor (mas
nem sempre é isso o que ocorre).
• Motivação:
• Esforço para sanar fraquezas reais e
perceptíveis da engenharia de software
convencional.
11. Manifesto
• Problemas do Desenvolvimento Tradicional:
• Prazos de desenvolvimento muito longos;
• Incapacidade de lidar coma mudança de
requisitos;
• Presunção de que os requisitos estejam
completamente entendidos antes do inicio do
projeto.
12. Manifesto
• Problemas do Desenvolvimento Tradicional:
• Confiança excessiva no esforço heroico do
desenvolvedor;
• Metodologia complexa;
• Desperdício (duplicação/retrabalho) de
esforço.
13. Manifesto
• Princípios:
1. Prioridade: Satisfazer o cliente através da
entrega rápida e contínua de software com
valor.
2. Mudanças nos requisitos:
✓São bem vindas, mesmo em etapas finais
do projeto.
✓Mudança é um diferencial competitivo
para o cliente.
14. Manifesto
• Princípios:
3. Entrega de software frequente:
✓Intervalos que variam de 2 semanas a
2 meses.
✓Intervalo mais curto é o preferível.
4. Administradores e Desenvolvedores
devem trabalhar juntos diariamente.
15. Manifesto
• Princípios:
5. Construir projetos em torno de
INDIVÍDUOS MOTIVADOS:
✓Dar aos indivíduos o ambiente e o
suporte.
✓Confiar que farão o trabalho.
6. Conversa cara a cara:
✓Meio mais eficiente e efetivo para tratar
a comunicação entre e para a equipe de
desenvolvimento.
16. Manifesto
• Princípios:
7. Software funcionando é medida primordial
de progresso.
8. Processos Ágeis:
✓Promovem desenvolvimento sustentável.
✓Financiadores, usuários e
desenvolvedores devem ser capazes de
manter o ritmo indefinidamente.
17. Manifesto
• Princípios:
9. Atenção contínua à excelência técnica e
bom design melhoram a agilidade.
10.Simplicidade é essencial:
✓Arte de maximizar a quantidade de
um trabalho não feito.
18. Manifesto
• Princípios:
11.Equipes auto organizadas constroem as
melhores arquiteturas, requisitos e
projetos.
12.Em intervalos regulares:
✓A equipe reflete sobre como se tornar
mais efetiva.
✓Ajusta seu comportamento de acordo
com esta meta.
19. Métodos Ágeis: Introdução
• Modelos e Métodos Prescritivos:
• Receita de bolo (fases e/ou tarefas a executar)
• Modelos e Métodos Ágeis:
• Ênfase nos fatores humanos do
desenvolvimento;
• Focam nos valores humanos e sociais;
• São mais leves, mas não menos complexos ou
simplistas que os tradicionais.
20. Métodos Ágeis: Introdução
• Nem todas as características são novas e
revolucionárias.
• Algumas são o resultado de anos de pesquisa
e experiências.
• Muitos conceitos são apenas adaptações de
bons conceitos dos modelos tradicionais.
• Similares ao processo iterativo e incremental.
21. Métodos Ágeis: Introdução
• Filosofia de Desenvolvimento:
• Satisfação do cliente;
• Entrega incremental antecipada;
• Equipes de projeto pequenas;
• Equipes de projeto altamente motivadas;
• Métodos informais;
• Simplicidade no desenvolvimento geral;
22. Métodos Ágeis: Introdução
• A Engenharia de Software Ágil:
• Combina a FILOSOFIA com os PRINCÍPIOS DE
DESENVOLVIMENTO.
• Constitui uma alternativa para a Engenharia de
Software Convencional.
• É voltada para certas classes de Software e para
certos tipos de Projetos.
• É capaz de entregar sistemas corretos
rapidamente.
23. Métodos Ágeis: Introdução
• Equipe Ágil:
• Engenheiros de
Software
• Gerentes
• Clientes
• Usuários
• Etc.
• Equipe Ágil:
• Auto-organização
• Autocontrole
• Acelerar a
comunicação e a
colaboração entre
todos os
participantes
24. Métodos Ágeis: Introdução
• Uma equipe ágil reconhece que:
• O Software é desenvolvido por indivíduos
trabalhando em equipes;
• As habilidades dessas pessoas, suas
capacidades em colaborar, estão no centro
do sucesso do projeto.
25. Métodos Ágeis: Introdução
• Também pode ser denominada de:
• Métodos Light;
• Métodos Enxutos (lean methods);
• Engenharia de Software Flexível;
• Processos Leves.
26. Métodos Ágeis: Introdução
• Atividades metodológicas básicas são as
mesmas dos modelos Tradicionais:
• Comunicação
• Planejamento
• Modelagem
• Construção
• Entrega
27. Métodos Ágeis: Introdução
• Na Metodologia Ágil as Atividades
Metodológicas básicas se transformam em
um CONJUNTO DE TAREFAS MÍNIMAS que
impulsiona a equipe para o desenvolvimento
e para a entrega.
• Um incremento de software operacional deve
ser entregue adequadamente na data
combinada.
28. Métodos Ágeis: Introdução
• Pode ser aplicado como uma FILOSOFIA
geral para todos os trabalhos de software.
• Não é indicado para todos os projetos,
produtos pessoas e/ou situações.
• Softwares de pequeno e médio porte.
29. Métodos Ágeis: Introdução
• Contexto da Economia Moderna:
• Difícil prever como um sistema evoluirá com o
tempo;
• Mercado muda rapidamente;
• Necessidades dos usuários mudam rapidamente;
• Ameaças competitivas surgem a todo instante;
• Requisitos não serão definidos completamente antes
do inicio do projeto;
• Agilidade para responder ao ambiente de negócios.
30. Métodos Ágeis: Introdução
• Mudanças são caras;
• Mudanças sem controle são muito caras;
• Mudanças mal gerenciadas são muito caras.
• Solução:
• Metodologia ágil:
• Habilidade de reduzir os custos da
mudança no processo de software.
31. Métodos Ágeis: Introdução
• Reflexão:
• Os princípios, conceitos, métodos e
ferramentas de ENGENHARIA DE SOFTWARE
são descartados por conta do novo cenário
de negócios e mercado?
32. Métodos Ágeis: Introdução
• Falha grave nos
modelos prescritivos:
• Fraquezas das
pessoas que
desenvolvem
software.
• Pessoas não são
robôs.
• Diferenças de nível em:
• Habilidades
• Capacidades
• Criatividade
• Organização
• Consistência
• Espontaneidade
• Etc.
33. Métodos Ágeis: Introdução
• Maioria dos modelos de processo de produção de
software prescritivos exigem DISCIPLINA.
• A coerência nas ações é uma fraqueza humana, por este
motivo, os modelos e métodos que exigem DISCIPLINA
ELEVADA são frágeis.
• Modelos e Métodos devem fornecer MECANISMOS
REALISTAS para estimular a disciplina NECESSÁRIA
34. Métodos Ágeis: Definição
• Palavra-chave: MUDANÇA
• Mudanças na criação do software;
• Mudanças nos membros da equipe;
• Mudanças devido a novas tecnologias;
• Mudanças que impactarão no
produto/projeto que está em construção.
35. Métodos Ágeis: Introdução
• Examinar as razões para as mudanças é importante
(não é descartado na metodologia).
• Engenheiros de Software devem ASSIMILAR,
rapidamente, as rápidas mudanças.
• Agilidade também é uma resposta à mudança.
36. Métodos Ágeis: Introdução
• Metodologia ágil não significa:
• Abreviar soluções de software;
• Nenhum documento seja criado;
• Esquecer da qualidade (confiabilidade,
usabilidade, facilidade de manutenção,
etc.)
37. Métodos Ágeis: Introdução
• Algumas críticas:
• Falta estrutura e documentação
necessárias;
• Requer desenvolvedores muito
experientes e disciplinados;
• Resulta em projeto insuficiente;
• Mostra dificuldade de tratamento de
requisitos não-funcionais.
38. Métodos Ágeis: Introdução
• Algumas críticas:
• Requer mudança cultural muito grande;
• Dificulta negociações contratuais;
• Pode ser ineficiente se as alterações de
requisitos forem frequentes;
• Dificulta estimativas de esforços, custos e
prazos;
39. Métodos Ágeis: Introdução
• Um método ágil permite:
• Que uma equipe de software assimile as
alterações, sem um impacto significativo nos
custos ou no tempo.
• Reduzir custos das alterações:
• O software é entregue incrementalmente;
• As alterações são melhor controladas em
incrementais.
40. Métodos Ágeis: Introdução
• Para alcançar a agilidade, o processo de
software deve ser projetado de forma que a
equipe possa:
• Adaptar e alinhar tarefas;
• Conduzir o planejamento;
• Compreender a fluidez de uma metodologia
ágil;
41. Métodos Ágeis: Introdução
• Para alcançar a agilidade, o processo de
software deve ser projetado de forma que a
equipe possa:
• Eliminar tudo (menos o essencial);
• Conservar o que é essencial de forma enxuta;
• Enfatizar a estratégia de entrega incremental;
• Entregar o mais rápido possível o incremento
de software operacional.
42. Processos Ágeis
• Preceitos chave acerca da maioria dos
projetos de software:
• Requisitos de software:
• Quais vão persistir?
• Quais sofrerão alterações?
• Prioridades do cliente:
• De que maneira sofrerão alterações?
43. Processos Ágeis
• Preceitos chave acerca da maioria dos
projetos de software:
• Projeto e construção de software são
realizadas em conjunto:
• Quanto de trabalho será necessário
antes que a construção seja
implementada para avaliar o projeto?
44. Processos Ágeis
• Preceitos chave acerca da maioria dos
projetos de software:
• Análise, projeto, construção e testes NÃO
SÃO TÃO previsíveis quanto gostaríamos
que fossem
46. Processos Ágeis
• REFLEXÃO:
• RESPOSTA:
• Adaptabilidade do processo = Alterar
rapidamente o projeto e as condições
técnicas.
47. Processos Ágeis
• Um processo ágil deve ser:
• Adaptável:
• Trata a imprevisibilidade
• Adaptável de modo incremental:
• Adaptação contínua com progressos;
• Necessário feedback do cliente.
48. Processos Ágeis
• Estratégia de Desenvolvimento Incremental
• Incrementos de software devem ser entregues
em curtos prazos de tempo;
• Adaptações devem acompanhar o ritmo das
mudanças;
• Cliente avalia e dá o feedback regularmente
• Equipe inclui adequadamente as modificações
49. Exemplos
• FDD
• Desenvolvimento Dirigido por
Funcionalidade
• Tem certo grau de prescrição
• Detalhamento de Atividades não comum a
outros métodos ágeis
50. Exemplos
• DSDM
• Dynamic Systems Development Method;
• Método de Desenvolvimento Dinâmico de
Sistemas;
• Oferece metodologia para construir e
manter sistemas que satisfaçam restrições
de prazo apertado usando prototipação
incremental em ambiente controlado.
51. Exemplos
• SCRUM
• É um modelo ágil para gestão de projetos
de software
• Conceito mais importante: SPRINT
• SPRINT: consiste em um ciclo de
desenvolvimento que vai de duas semanas
a um mês
52. Exemplos
•XP
• Programação Extrema
• Pouco baseado em prescrição de atividades
• Regras bem definidas sobre como a equipe deve se
organizar
• Regras sobre como as iterações e reuniões devem
ocorrer
• Regras sobre como o ambiente de trabalho deve
ser organizado para maximizar a produtividade e
sucesso pessoal e empresarial.
55. Exemplos
• AM
• Modelagem Ágil
• Metodologia prática voltada para a
modelagem e documentação de sistemas.
56. Exemplos
• AUP
• Agile Unified Process
• Processo Unificado Ágil
• Fornece uma sequencia linear de atividades
que permite a equipe visualizar o fluxo do
processo geral
• Dentro de cada atividade é usada a
agilidade
57. Comparação Tradicional X Ágil
Área Característica Ágil Tradicional
Desenvolve
dores
Cultura
Mais
informal
Mais formal
Tamanho da
equipe
Menor Maior
Experiência Maior Menor
Localização Única Espalhada
58. Comparação Tradicional X Ágil
Área Característica Ágil Tradicional
Clientes
Relacionamen
to
Mais
cooperativo
Mais formal
Localização Próxima Distante
Requisitos
Natureza Emergente
Bem
conhecidos
Variabilidade Alta Baixa
59. Comparação Tradicional X Ágil
Área Característica Ágil Tradicional
Arquitetura
Foco
Solução
imediata
Expansibilid
ade
Refatoramento Fácil Difícil
Requisitos
Tamanho Menor Maior
Objetivo
Valor
rápido
Alta garantia
60. REFERÊNCIAS
1. TSUI, Frank; KARAM, Orlando. Fundamentos
da Engenharia de Software. Tradução e
Revisão Técnica de Edson Tanaka. 2.ª Edição.
Rio de Janeiro: LTC, 2013.
2. WAZLAWICK, Raul Sidnei. Engenharia de
Software: Conceitos e Práticas. 1.ª edição.
Rio de Janeiro: Elsevier, 2013.
61. REFERÊNCIAS
3. PRESSMAN, R. S.; MAXIM, B. R. Engenharia de
Software: Uma Abordagem Profissional. Tradução:
João Eduardo Nóbrega Tortello. Revisão Técnica:
Reginaldo Arakaki, Julio Arakaki, Renato Manzan de
Andrade. 8.ª Edição. Porto Alegre: AMGH, 2016.
4.FILHO, W. P. P. Engenharia de Software:
Fundamentos, Métodos e Padrões. 3.ª Edição.Rio
de Janeiro: LTC, 2015