Prévia do material em texto

Metodologias Ágeis
Disciplina: Engenharia de Software
Capítulo 04
Universidade Federal da Paraíba
Centro de Ciências Aplicadas e Educação
Departamento de Ciência Exatas
Juliana Saraiva 
julianajags@dcx.ufpb.br
mailto:julianajags@dce.ufpb.br
Sumário
1. Introdução
1.1. Manifesto Ágil
2. Princípios
3. Práticas Compartilhadas
4. Metodologias
4.1 eXtreme Programming (XP)
4.2 Scrum
4.3 FDD
4.4 DSDM
4.5 TDD
4.6 Kaban
5. Tecnologias e Ferramentas
6. Dificuldades em Implantar Metodologia Ágil
7. Considerações Finais
8. Bibliografia Recomendada
2
1. Introdução 
• Desenvolvimento Ágil como filosofia:
– “Desenvolvimento simples-mas-eficiente usando regras orientadas à 
comunicação contínua” (Cockburn, 2001).
• Não é um processo específico (Warden & Shore, 2007)
– Existem métodos que dão suporte a esta filosofia.
• Inicialmente conhecido como Métodos Leves
– “Ligth-but-sufficient” (Cockburn, 2001)
• Manifesto Ágil (Utah - 2001)
– Encontro de 17 pesquisadores para discutir similaridades e diferenças de 
metodologias leves de desenvolvimento.
3
1.1 Manifesto Ágil
Processos e 
FerramentasIndivíduos e Interações
Seguir um PlanoResposta às Mudanças
Documentação 
AbrangenteSoftware em Funcionamento
Negociação de 
ContratoColaboração com o Cliente
4
Desenvolvimento Ágil 
• Uma abordagem baseada no desenvolvimento e na entrega de 
incrementos de funcionalidade muito pequenos.
• Baseia-se no aprimoramento constante do código, em testes 
automatizados, no envolvimento do usuário na equipe e no 
desenvolvimento em pares.
• Exemplos: XP, Scrum, DSDM, FDD, TDD, Crystal Clear, 
Adaptive Software Development, etc.
5
2. Princípios (Parte 01)
1. Satisfação do Consumidor
2. Mudança Constante de Requisitos
3. Entregas de Softwares Funcionais
4. Todos os Stakeholders envolvidos
5. Motivação nos projetos
6. Conversas cara-a-cara incentivadas
6
2. Princípios (Parte 02)
7. Software em Funcionamento 🡪 Medida Progresso
8. Desenvolvimento Sustentável
9. Atenção Contínua
10. Simplicidade é essencial
11. Arquiteturas e Decisões emergem de equipes 
auto-organizáveis
12. Necessidade de intervalos regulares
7
3. Práticas Compartilhadas (01)
• Desenvolvimento Iterativo
• Foco na Comunicação Iterativa
• Redução de esforços para construção de artefatos
• Aplicabilidade 
 Cultura, Pessoal e Comunicação
8
3. Práticas Compartilhadas (02)
• Ciclo PDCA
9
4. METODOLOGIAS ÁGEIS
4.1 eXtreme Programming (XP)
• Uma das mais proeminentes metodologias
• FUNCIONAMENTO (Fases):
– Planejamento
– Análise e Projeto
– Codificação
– Teste
– Implantação
11
EXtreming Programming (XP)
XP é um processo de desenvolvimento de 
softwares voltado para:
• Projetos cujos requisitos são vagos e mudam com 
frequência;
• Desenvolvimento de sistemas orientados a objetos;
• Desenvolvimento incremental.
12
Estrutura da Equipe
• Gerente de projeto – assuntos administrativos
• Coach - técnico do projeto
• Analista de testes – ajuda o cliente a escrever os testes 
de aceitação, detecta defeitos no sistema
• Redator técnico – ajuda na documentação do sistema
• Desenvolvedor – analisa, projeta e codifica o sistema
13
Os 5 Valores da XP
• São as diretrizes da XP
• Define as atitudes da equipe XP
– Feedback
– Comunicação
– Simplicidade
– Coragem
– Respeito
14
Princípios da XP
• Feedback rápido
– Os participantes devem estar sempre se comunicando para facilitar o 
aprendizado coletivo.
• Assumir simplicidade
– Deixe o seu modelo tão simples quanto possível e assuma que a solução 
mais simples é a melhor.
• Mudança incremental
– O modelo não será perfeito na primeira tentativa, ele irá mudar de 
acordo com o desenvolvimento do projeto.
15
Princípios da XP
• Abraçando mudanças
– XP procura facilitar o ato de incluir alterações através do uso 
de vários princípios e práticas.
– Mudanças devem ser sempre bem vindas.
– Independentemente do estágio de evolução do projeto.
• Trabalho de qualidade
– Qualidade não é um critério opcional, mas sim obrigatório.
– Sistema que atenda aos requisitos do cliente.
16
Práticas da XP
• Processo de planejamento 
(Planning Game)
• Releases curtos
• Metáfora
• Projeto simples
• Testes
• Refactoring
• Stand up meeting
• Programação em pares
• Propriedade coletiva do 
código
• Integração contínua
• Semana de 40 horas
• On-site customer (Cliente 
sempre presente)
• Padrões de codificação
17
4.1 PLANEJAMENTO
• Estórias de Usuário
• Cartões de Indexação
• Cliente contribui a cada estória
• Desenvolvedores atribuem um custo a cada estória
18
4.1 PROJETO
• Segue rigorosamente o KIS (Keep it Simple)
• Encoraja Refatoração
• Estimula o uso de cartões CRC (Classe, Responsabilidade 
e Colaboração)
19
4.1 CODIFICAÇÃO
• Iniciar programação depois do Projeto das Estórias do 
Usuário
• Testes Unitários (testar antes)
• Programação em Par
20
4.1 TESTE
• Testes Unitários
• Teste de Aceitação 
21
4.1 PRÁTICAS de XP
• Pequenas versões
• Design Simples
• Programação em Par
• Desenvolvimento orientado a testes
• Refatoração
• Testes do Cliente
• Time coeso
• Código padronizado
• Código coletivo e Integração contínua
• Ritmo sustentável
• Jogo de planejamento
22
4.1 Empresas que Adotam XP
• Objective Solutions
• Improve It
• Paggo
• Caelum
• LocaWeb
• Neurobox
23
4.2 Scrum
• Foco no gerenciamento de projetos
• Baseia-se na formação Scrum do Rugby
• Artefatos Principais:
– Backlog de Produto
– Backlog de Sprint
24
Scrum
• Não tem a figura do gerente de projetos;
• Os times são auto-gerenciáveis;
• Possui características do modelo iterativo e incremental;
• É composto por papéis bem definidos;
• Possui valores, práticas e regras;
• É considerado um framework para gerência de projetos.
25
4.2 Scrum - PAPÉIS
• PRODUCT OWNER
– Intermédio entre cliente e equipe
– Atualiza e produz Backlog de Produto
– Decide as datas de lançamento
– Prioriza funcionalidades
– Aceita ou rejeita os resultados dos 
trabalhos
• SCRUM MASTER
– Líder, mediador
– Assegura práticas SCRUM no processo
– Garante a colaboração entre os diversos 
papéis e funções
– Escudo para interferências externas
– Mantém a produtividade do time
26
• TEAM
– 5 a 9 pessoas
– Multidisciplinar
– Comprometido com a meta até o fim da 
Sprint
4.2 Scrum - FUNCIONAMENTO
• Definição de Backlogs
• Sprints
• Reuniões
• Revisões
27
Sprint
• É uma iteração no Scrum
• Tem duração fixa
– Normalmente de 2 a 4 semanas
• Durante a Sprint, o Scrum Master garante que não será feita nenhuma 
mudança que possa afetar a Meta da Sprint
• A definição de “Pronto” deve ser estabelecida
– Quando um item do PB pode ser apresentado na Sprint Review
• A definição de “Preparado” deve ser estabelecida
– Quando um item do PB pode ser estimado na reunião de planejamento
28
Planejamento da Sprint
• Dividida em 2 partes:
– Primeira: A equipe seleciona itens do Product Backlog com os 
quais compromete-se a concluir
• O Sprint Backlog é criado
– Segunda: Tarefas são identificadas e estimadas para cada 
item do backlog
• Utiliza-se a técnica de estimativa Planning Poker
• O time inteiro planeja!
29
Planning Poker
• Técnica para estimar esforço
• Utilizado no Scrum para estimar esforço das 
estórias de usuários (user story)
30
Reunião de Scrum Diário (Daily Scrum Meeting)
• Todos em pé!
• Não é para solução de problemas
• As respostas não são um relatório para o ScrumMaster
• Três questões são respondidas:
– O que foi feito?
– O que será feito?
– Há algum impedimento?
• Melhora o nível de conhecimento e a comunicação da equipe
• Promove a tomada rápida de decisão
31
Sprint Review Meeting (Revisão da Sprint)
• Realizada após cada Sprint
• Todos participam
• O time apresenta o que foi realizado na sprint
• O Product Owner identifica o que foi feito e o que não 
foi feito.
• É verificado se o objetivo da Sprint foi alcançado
32
Sprint Retrospective (Retrospectiva da Sprint)
• Acontece após a Revisão da Sprint e antes da próxima reunião de 
Planejamentoda Sprint.
• A finalidade é inspecionar como correu a última Sprint em se tratando de 
pessoas, das relações entre elas, dos processos e das ferramentas.
• O Time discute sobre o que correu bem durante a Sprint e quais problemas 
foram enfrentados, além de como esses problemas foram resolvidos.
– Serve como entrada para o próximo planejamento da Sprint
• A equipe discute o que gostaria de:
– Iniciar a fazer
– Parar de fazer
– Continuar fazendo
33
Artefatos no Scrum
• Sprint Burndown e Project Burndown
34
Artefatos no Scrum
• Quadro Scrum
35
Artefatos no Scrum
36
4.2 Empresas que Adotam Scrum
• Microsoft
• Yahoo
• Google
• Rede Globo (Globo.com)
• Electronic Arts
• High Moon Studios
• Lockheed Martin
• Phillips
• Siemens
• Nokia
• Capital One
• BBC
37
4.3 FDD (Feature Driven Development)
• Desenvolvimento direcionado à função/funcionalidade
– Funcionalidade “é uma função valorizada pelo cliente passível de 
ser implementada em duas semanas ou menos” (Pressman, 2011)
• Filosofia segue o seguinte modelo:
• Exemplos:
– Adicione o produto ao carrinho
– Mostre as especicações técnicas do produto 
– Armazene as informações de remessa para o cliente
• Está intermediária entre ágeis e tradicionais.
38
4.3 FDD PAPÉIS
• Principais
– Gerentes de Projeto e de 
Desenvolvimento
– Programador Chefe
– Proprietário da Classe
– Arquiteto Chefe
• Apoios
– Gerente de Domínio e de Versão
– Especialista de Linguagem
– Administrador do Sistema
– Construtor de ferramentas CASE
39
• Adicionais
– Testador
– Desenvolvedor
– Escritor Técnico
4.3 FDD FUNCIONAMENTO
40
4.3 FDD BOAS PRÁTICAS
• Desenvolvimento por funcionalidade
• Classe proprietária
• Equipes de recursos
• Inspeção é realizada constantemente
• Gerenciamento de configuração
• Integração contínua
• Visibilidade de progressos e resultados
41
4.4 DSDM (Dynamic System Development Method)
• Dedicados a projetos com cronograma e custos apertados (Pressman, 
2010)
• Tempos fixos de entrega
• Estabelece recursos para o desenvolvimento
• Usa técnica Timeboxing
• “Pouca formalidade e prazos curtos”
42
4.4 DSDM FUNCIONAMENTO
• FASE 1:
– Estudo de Viabilidade
– Estudo de Negócio
• FASE 2:
– Modelo de Iteração Funcional
• FASE 3:
– Construção da Iteração
• FASE 4:
– Implementação
43
4.4 DSDM PRINCÍPIOS
• Envolvimento
• Autonomia
• Foco nas entregas
• Eficácia
• Feedback
• Reversibilidade
• Previsibilidade
• Comunicação
44
4.4 DSDM EQUIPE
• Arquiteto
• Desenvolvedor Sênior
• Analista
• Programador
• Designer
• Usuários: embaixador, visionário e conselheiro
• Administrador de Banco de Dados
• Configurador
• Suporte Técnico
45
4.4 DSDM Empresas que Adotam DSDM
• Sema Group
• Boston Globe
• Scottish Natural Heritage
46
4.5 TDD (Test Driven Development)
• Técnica de desenvolvimento voltada à validação e 
verificação.
• O teste vem primeiro, depois o código é produzido.
• Originalmente veio como uma boa prática de XP.
• Depuração de código é uma grande característica nesse 
modelo.
• Testes são “Assertivas”.
47
4.5 TDD Fases
48
4.5 TDD Vantagens
• Com TDD raramente precisam usar depurador depois 
que o código está pronto.
• Quando bem adotado, todo o código é coberto por 
testes.
• Código modularizado e flexível.
• Identifica falhas de funcionalidades cedo.
49
4.5 TDD Limitações
• Difícil adotar em testes funcionais.
– Exs.: Interface, Banco de dados - carga, etc.
• Testes são parte da MANUTENÇÃO do sistema;
• Alto número de testes pode dar uma falsa sensação de 
segurança.
– Não se pode esquecer de teste de integração, de sistema, de 
usabilidade, etc.
50
4.6 BDD (Behavior Driven Development)
• Técnica que encoraja colaboração entre 
desenvolvedores, setor de qualidade e stakeholders 
não técnicos.
• Foco em linguagem e interação da equipe.
• Analisa o comportamento do sistema e 
consequentemente das funcionalidades.
51
4.6 BDD Boas Práticas
• Envolver as partes interessadas no processo através de Outside-in 
Development;
• Usar exemplos para descrever o comportamento do sistema;
• Automatizar os exemplos para prover um feedback rápido;
• Usar deve (should em inglês) na hora de descrever o comportamento de 
software para ajudar esclarecer responsabilidades e permitir que 
funcionalidades do software sejam questionadas;
• Usar simuladores de teste para auxiliar na colaboração entre módulos e 
códigos que ainda não foram escritos.
52
4.6 BDD Desenvolvimento de fora pra dentro
• 1o desenvolvem a interface gráfica
• Cada elemento de código possui um comportamento
53
4.6 BDD Cenários BDD
54
4.6 BDD Cenários BDD - Exemplo 01
55
5. Dificuldades em Implantar Metodologia Ágil
• Empresa que não aceita mudanças.
• Locais de trabalhos não adequados à prática.
• Clientes que fazem questão de muitos artefatos.
• Sistema baseado em premiação individual.
• Contratos de escopo fechado.
• OBS.:
– Técnica de Kanban adotada no modelo Scrum.
– Lean startup e ágeis → MVP (Mínimo Produto Viável)
56
6. Considerações Finais
• Com Ágil...
– Capacita a organização a responder facilmente às mudanças.
– Entrega o código funcionando mais rapidamente e de alta 
qualidade.
– Aumenta a produtividade e a satisfação do cliente.
– Fornece ambiente de satisfação na equipe de 
desenvolvimento.
57
Bibliografia Recomendada
• Básica:
– Cockburn, A. (2002). Agile software development. Agile software 
development series. Addison-Wesley.
– Pressman, R. (2010). Software engineering: a practitioner’s approach. 
McGraw-Hill higher education. McGraw-Hill Higher Education.
– Shore, J. and Warden, S. (2007). The Art of Agile Development. O’Reilly, 
first edition.
• Complementar:
– Henrik Kniberg, Scrum e XP Direto das Trincheiras
– Manifesto Ágil (http://manifestoagil.com.br/index.html )
58
Tecnologias e Ferramentas
PARA GERENCIAMENTO DE PROJETO
• XPlannerPlus (http://xplanner-plus.sourceforge.net/):
– OpenSource
– Web
– Controle de Estórias do Usuário
– Exportação de Dados XML e PDF
59
Tecnologias e Ferramentas
PARA GERENCIAMENTO DE PROJETO
• AgileFant (http://agilefant.com/):
– OpenSource
– Gestão de Backlog de Produto
– Planejamento e Controle de Iterações
– Relatórios, Gráfico e métricas
– Visualização de Daily Work da equipe
60
Tecnologias e Ferramentas
PARA GERENCIAMENTO DE PROJETO
61
Tecnologias e Ferramentas
PARA GERENCIAMENTO DE PROJETO
• Trello (https://trello.com/):
– Gerenciamento de Projeto
– Facilidade em mover tarefas entre quadros para as 
reorganizar
– Integrado a serviços externos como horas
62
Tecnologias e Ferramentas
PARA GERENCIAMENTO DE PROJETO
Tecnologias e Ferramentas
PARA TESTES - JUnit
• JUnit
– Permite a escrita de código rapidamente
– É elegante e simples. 
– Uma vez escritos, os testes serão executados rapidamente 
– O próprio framework checa os resultados dos testes e 
fornece uma resposta imediata; 
– Tudo criado no JUnit é escrito puramente em Java; 
– JUnit é uma ferramenta livre.
64
Tecnologias e Ferramentas
PARA TESTES - JUnit
65
Tecnologias e Ferramentas
PARA TESTES - JMeter
• JMeter
– Usado para testes de carga e de aceitação
– Ferramenta Web
– Simula diversos acessos simultâneos
66
Tecnologias e Ferramentas
PARA TESTES - JMeter
Tecnologias e Ferramentas
PARA PROGRAMAÇÃO EM PAR - PEP
• PEP (Pair Eclipse Programming)
– Sincronismo de Código
– Chats
– Concepção de novos requisitos
– Compartilhamento automatizado de projetos
68
Tecnologias e Ferramentas
PARA PROGRAMAÇÃO EM PAR - PEP
69