Logo Passei Direto
Buscar
Material
páginas com resultados encontrados.
páginas com resultados encontrados.

Prévia do material em texto

Metodologias Ágeis de 
Desenvolvimento de Software
Prof. Dr. Anderson De Bona
1
Referências Bibliográficas
• SOMMERVILLE, Ian Engenharia de software 9 ed. São Paulo, SP: Pearson Prentice Hall 2011 568 p. ISBN: 9788579361081
• PRESSMAN, R. S Engenharia de Software - Uma abordagem Profissional - 8 ed. Porto Alegre, RS: Bookman/Amgh Editora 
2016 968 p. ISBN: 9788580555332 
• PRIKLADNICKI, R.; WILLI, R.; MILANI, F . Métodos Ágeis Para Desenvolvimento de Software 1 ed. Porto Alegre, RS: 
Bookman. 2014 312 p. ISBN: 8582602073 
• BROD, C. Scrum Guia Prático para Projetos Ágeis 2 ed. São Paulo, SP: Editora Novatec 2015 200 p. ISBN: 9788575224410 
• TELES, V. M. Extreme Programming. 2 ed. São Paulo, SP: Novatec 2014 200 p. ISBN: 857522400X 
• BECK, K. Programação Extrema (XP) Explicada. 1 ed. Porto Alegre, RS: Bookman 2004 182 p. ISBN: 8536303956
• http://agilemanifesto.org/ 
2
Objetivos
• Compreenderá a logica dos métodos ágeis de desenvolvimento de 
software
• O que é o manifesto ágil ?
• Diferenças entre: 
• Desenvolvimento ágil e Desenvolvimento dirigido a planos;
• Gerencimento de Projetos ágeis com Scrum
• Programação Extrema (XP)
3
Plano de Aula
• Histórico e Motivação
• Métodos ágeis
• Manifesto ágil
• Desenvolvimento dirigido a planos e ágil
• Programação Extrema - XP
• Scrum
• Lista de Exercícios
4
Histórico / Motivação
Por que Metodologias Ágeis ?
5
Histórico e Motivação 
• 1960s/1970s: crise do software
• Problemas com orçamento
• Problemas com prazos
• Problemas com qualidade
• Problemas com requisitos
• Problemas com manutenibilidade
6
Histórico e Motivação 
• 1980s/1990s: Engenharia de Software Tradicional
• Planejamento detalhado
• Qualidade acordada / formalizada
• Utilização de métodos de análise e projeto de SW.
• Processo desenvolvimento prescritivo 
• (rigoroso e controlado)
• Longos períodos de desenvolvimento (3, 5, 10 anos)
• Desenvolvimento de grandes SW (aeroespaciais, governo)
7
Histórico e Motivação 
• Final de 1990s Início de 2000s: Engenharia de Software Ágil
• Novas oportunidades, novos: mercados, produtos, concorrentes
• Mercado, Negócios necessitam responder a mudanças rapidamente
• As regras de negócio mudam em uma frequência muito rápida
• Não se pode esperar anos para ter uma funcionalidade ou um SW.
• Software precisam ser desenvolvidos com velocidade
• A entrega rápida pode ser mais desejada que a qualidade (pois é intrisseca)
• Processo Tradicionais de desenvolvimento não são aderentes a mudanças rápidas
8
 Métodos Ágeis
9
Métodos Ágeis
• Problemas da Engenharia de Software Trandicional
• Décadas de 1980 e 1990
• Surgimento das Metodologias ágeis. 
• Onde estes:
1. Concentre-se no código e não na Documentação / Modelagem detalhada
2. Abordagem iterativa para desenvolvimento de software
3. Entrega de software rápida
4. Evolução para atender as mudanças dos requisitos constantemente.
• Objetivo
• Reduzir os custos indiretos no processo de software
1. (por exemplo, limitando a documentação) 
2. Capaz de responder rapidamente às mudanças de requisitos sem retrabalho excessivo.
10
Métodos Ágeis - Desafios
1. Clientes deve estar disposto e capaz de passar o tempo com a 
equipe de desenvolvimento.
2. Membros individuais da equipe podem não interagir bem com 
outros membros da equipe.
3. Priorizar as mudanças pode ser extremamente difícil.
4. Manter a simplicidade pode ser muito complexo.
5. A organização pode não ter a cultura adequada.
6. Organização investiram muito em definição e organização de 
processos
11
Métodos Ágeis - Motivação
12
Métodos Ágeis
•
13PRESSMANN (2016)
Métodos Ágeis – Manifesto Ágil
• Reunião em Fevereiro de 2001, UTAH – E.U.A. – 17 grandes pensadores de SW.
14
Métodos Ágeis – Manifesto Ágil
15
Métodos Ágeis
“….O desenvolvimento ágil foca talentos e habilidades de indivíduos, 
moldando o procesos de acordo com as pessoas e as equips 
específicas…” (COCKBURN e HIGHSMITH, 2001).
“….O ponto-chave dos dos métodos ágeis é que o processo se amolda 
as necessidades das pessoas e equips, e não o caminho inverso…” 
(PRESSMAN, 2016)
16
Desenvolvimento: Ágil vs Dirigido a Planos
• Desenvolvimento orientado a planos
• É baseada em estágios de desenvolvimento separados, com as saídas a serem 
produzidas em cada um desses estágios planejados antecipadamente.
• Iteração incremental é possível no modelo cascata – dirigido a planos
• A iteração ocorre dentro das atividades.
• Desenvolvimento ágil
• Especificação, projeto, implementação e teste são intercalados e 
• As saídas do processo de desenvolvimento são decididas através de um 
processo de negociação durante o processo de desenvolvimento de software.
• Foca nos fatores humanos
• Competência, Foco comum, Colaboração, Habilidade na tomada de decisão, 
• Confiança mútua, Respeito e Auto-organização
17
Desenvolvimento: Ágil vs Dirigido a Planos
18
Métodos Ágeis
• Especificação, projeto, implementação e teste são intercalados e os 
produtos do processo de desenvolvimento são decididos através de 
um processo de negociação, durante o processo de desenvolvimento 
dos software
19
Desenvolvimento: Ágil vs Dirigido a Planos
20
Desenvolvimento: Ágil vs Dirigido a Planos
21
Desenvolvimento: Ágil vs Dirigido a Planos
22
Quando utililizar os métodos ágeis ?
• A análise mais simples e básica indica, em geral, para:
• Produtos novos.
• Pequeno/médio porte. 
• Existe o compromisso do cliente se envolver no processo de desenvolvimento.
• Não há muitas regras/regulamentos externos que afetam o software.
• Equipes pequenas/integradas
• (preferencialmente todos localizados no mesmo espaço físico
23
Quando EVITAR os métodos ágeis ?
• A análise mais simples e básica indica, em geral, para:
• Sistemas grandes e/ou complexos.
• Sistemas críticos
• Os requisitos devem ser completamente especificado.
• Equipes grandes e/ou distribuídas geograficamente.
• Cliente
• Não está comprometido
• Entrega uma especificação e apenas quer receber o software completo depois de um 
tempo
24
Mas quais são os principais métodos ágeis ?
25
Por que SCRUM e XP ?
26
XP – Programação extrema
• Proposta por KENT BACK, no projeto da Chrysler (C3) folha de pagamento
• 1999 - notoriedade na OOPSLA2000 - (Object-Oriented Programming, Systems, 
Languages & Applications)
• Novas versões podem ser construídas várias vezes por dia;
• Incrementos são entregues aos clientes a cada 2 semanas;
• Todos os testes devem ser executados para cada compilação e a compilação só é 
aceita se os testes forem executados com êxito.
• Segue o conceito KIS (Keep it Simple)
27
XP – Valores do XP
1. Comunicação
2. Feedback
3. Coragem
4. Simplicidade
5. Respeito
28
XP – Princípios básicos
• Feedback rápido
• Presumir simplicidade
• Mudanças incrementais
• Abraçar mudanças
• Trabalho de alta qualidade
29
XP – 12 Práticas do XP
1. Planejamento
2. Fases pequenas
3. Metáforas
4. Projeto (Design) simples
5. Test-first
6. Refatoração
7. Programação pareada
8. Propriedade Coletiva
9. Integração Contínua
10. Semana de 40 horas
11. Cliente junto aos desenvolvedores
12. Padronização do código
30
XP - Testes
• As principais características dos testes em XP são:
• Desenvolvimento test-first
• Desenvolvimento de teste incremental a partir do cenários;
• Envolvimento dos usuários no desenvolvimento de testes e validação;
• Uso de frameworks de testes automatizados.
31
XP – Programação pareada
• Trabalham juntos na mesma estação
• É criada de maneira dinâmica, todos os membros da equipe trabalham uns 
com os outros
• Propriedade e responsabilidade coletiva
• Programação sem ego
• Processo informal de revisão
• Processo de inspeção mais barato do que inspeções formais de programa
• Apoio à refatoração
• Processo de melhoria de código
• Mais ganho para programadores menos experientes
32
XP – Programação extrema
33
SCRUM
• Formailzado por Jeff Sutherland e Ken Schwaber – OOPSLA 96,
• Seu focoé na gerência de desenvolvimento iterativo ao invés de 
práticas ágeis específicas.
34
Scrum - Pilares
• Transparência 
• Todos os processos devem estar visiveis a todos
• Inspeção
• Verificação para detecar variações indesejadas
• Adaptação
• Inspeção frequente para minimizar desvios
35
Scrum - Valores
36
Scrum – Práticas
37
Metodologias Ágeis – O que é ser agil afinal ?
• Escrever Código de qualidade
• Mudar de ideia 
• Ir em frente sem saber tudo sobre o futuro
• Confiar em outras pessoas
• Mudar arquiteutra de um Sistema em funcionamento
• Escrever testes antes do Código – TDD.
38
Métodos Ágeis - Quando não é recomendado
• Grupos grandes (>10 [>20] programadores).
• Quando feedback rápido não é possível:
• sistema demora 6h para compilar.
• testes demoram 12h para rodar.
• exigência de certificação que demora meses
• Quando o custo de mudanças é essencialmente exponencial
• Quando o cliente não aceita as regras do jogo
• Quando o cliente quer uma especificação detalhada do sistema antes de começar.
• Quando os programadores não estão dispostos a seguir (todas) as regras.
• Se (quase) todos os programadores do time são medíocres.
• Não é recomendado – Mas já se tem obtido muito sucesso em grandes projetos
• (já existe grandes implementações de SUCESSO (SUTHERLAND, 2016)
39
Rapidez ≠ Agilidade
• Lembrando 
• “...Agilidade está em garantir a qualidade do método de se adaptar e 
solucionar problemas durante o desenvolvimento...” (SOMMERVILLE, 2011).
40
 Metodologias Ágeis de 
Desenvolvimento de Software
41

Mais conteúdos dessa disciplina