[05] EngSW - Métodos Ágeis - XP v1 6

Prévia do material em texto

1
Teoria de Engenharia de 
Software
Aula 5
Metodologias Ágeis - XP
Prof. Rafael Targino
rtargino@unicarioca.edu.br
2
Conteúdo da Aula
• Metodologias Ágeis
– Motivação
– Manifesto Ágil
– Princípios Ágeis
• Extreme Programming (XP)
– Valores
– Práticas
Engenharia de Software
2
3
Casos Comuns em Projetos
Cliente não presente 
e não explica direito 
suas necessidades
Equipe culpa o 
cliente por não 
conseguir entregar
Patrocinador do 
projeto exige que o 
projeto entre em 
produção
4
Alguns outros problemas no 
desenvolvimento de projetos...
• Escopo do projeto muda com frequência...
• O prazo não é cumprido...
• Equipe do projeto desmotivada...
• Equipe do projeto com baixa produtividade...
• Orçamento estourado..
• Cliente não satisfeito...
3
Planejamento x Realidade
6
Mas Mudanças no Projeto Sempre 
Ocorrem
• Usuários tem baixa percepção do problema no início 
do projeto
• Nossa capacidade de planejar mais do que 2 ou 3 
meses do projeto é muito limitada
– Frequentes estouros de prazos e orçamentos...
• O negócio muda muito rápido
• As equipe não sabem a melhor maneira de 
executar o projeto no início
4
7
Manifesto Ágil
• No início dos anos 2000, um grupo de 17 
profissionais veteranos da ares de 
desenvolvimento de software decidiram se 
reunir em uma estação de esqui nos EUA, 
para discutir novas formas de melhorar o 
desempenho de seus projetos
Manifesto Ágil
Indivíduos e Iterações entre eles mais do que 
processos e ferramentas 
(Pessoas)
Software em funcionamento mais do que 
documentação abrangente 
(Valor)
Colaboração com o cliente mais do que negociação 
de contratos 
(Confiança)
Responder a mudança mais que seguir um Plano
(Complexidade)
5
9
Métodos Ágeis
AnarquiaGovernança
Ordem Complexidade Caos
Métodos Ágeis
10
Concepção do Ágil
Á g i l ≠ R á p i d o
Á g i l = A d a p t a t i v o
6
11
• Quando o cliente aprende com o produto 
que está sendo entregue e reavalia as suas 
necessidades, gerando feedback para a 
equipe do projeto.
• É o mecanismo fundamental que permite 
que o cliente conduza o desenvolvimento do 
projeto diariamente.
• Garante que a equipe direcione as 
suas atenções para aquilo 
que irá gerar mais valor.
A Importância do Feedback
12
Abordagem Iterativa
Ciclos Iterativos e Incrementais
Versão 1
Versão 2
Versão 3
tempo
abrangência 
Feedback
Feedback
Feedback
Aprendizado
7
13
Visibilidade do Progresso do Projeto
• Os clientes e demais partes interessadas vem o 
progresso do projeto – incrementos do produto 
– a cada final de iteração, ou seja, em 
semanas.
Engenharia de Software
• Estabelece um senso de 
progresso do projeto
• Constrói a confiança entre o 
cliente e a equipe de 
desenvolvimento
Redução do Desperdício
• Produzir apenas o que é necessário e 
suficiente
– Produzir apenas o que os usuários irão utilizar
– Planejar apenas com o nível de detalhe possível
– Utilizar apenas os artefatos necessários e suficientes
Engenharia de Software
8
15
Iterações e Releases
• Os métodos Ágeis estão centrados nas 
utilizações de Iterações e Releases
Engenharia de Software
16
Exemplo de uma Iteração de 1 
Semana
Engenharia de Software
Definição com o cliente
Desenvolvimento
Teste
Avaliação pelo cliente
Validação parcial com o cliente
9
17
Conteúdo da Aula
• Metodologias Ágeis
– Motivação
– Manifesto Ágil
– Princípios Ágeis
• Extreme Programming (XP)
– Valores
– Práticas
Engenharia de Software
18
Extreme Programming (XP)
• Principal Criador: Kent Beck 
• Projeto C3 (Chrysler Comprehensive 
Compensation System) obteve sucesso com 
uso de XP
– Sistema Ficou pronto bem antes do tempo 
estimado
–O projeto C3 teve diversos problemas 
antes de XP
• Metodologias Ágeis passaram a se destacar
• Composta de 4 valores e 12 práticas
Engenharia de Software
10
19
Práticas do XP
1. Jogo do Planejamento
2. Cliente Presente
3. Reuniões de Pé (Stand Up Meeting)
4. Programação por Pares
5. Desenvolvimento guiado pelos Testes
6. Refatoração
7. Código Coletivo
8. Código Padronizado
9. Design Simples
10.Ritmo Sustentável
11.Integração Contínua
12.Releases Curtos
Engenharia de Software
20
Prática 1 - O jogo do planejamento
• Planejamento da Release: geralmente de 2 a 
3 meses. Uma release possui diversas 
iterações curtas (1 a 3 semanas). 
– 1ª Etapa: Histórias dos Usuários
– 2ª Etapa: Estimativas
– 3ª Etapa: Priorização de Histórias e definição do 
conteúdo da Iteração
– 4ª Etapa: Avaliação da Iteração
11
21
1º Etapa: Histórias de Usuários
• Presença constante do cliente.
• Histórias dos usuários em torno dos 
requisitos.
• História definida a partir de um pedaço de 
negócio que possa ser testada, executada e 
entregue.
• Divisão de histórias em tarefas caso 
necessário.
Engenharia de Software
22
Requisitos dos Usuários são 
definidos em Histórias
• Cartões de Histórias dos Usuários
Como um <tipo_de_usuário>, eu gostaria de 
<funcionalidade> para <benefício>
Engenharia de Software
12
23
Quadro de Histórias
Engenharia de Software
24
Épico: Histórias de mais alto nível
Engenharia de Software
13
25
2º Etapa: Estimativas
• Os programadores estimam qual o 
esforço gasto para implementar cada 
estória. 
–Story Points - baseadas em pontos 
–Dias ideais
• Técnicas para atingir um consenso
–Planning Poker
Engenharia de Software
26
Estimativas baseadas em pontos –
Story Points
• Pontos indicam a “grandeza” de uma história 
a ser implementada
• Técnica baseada em comparação com outras 
histórias
• Define as histórias mais simples como 1 
ponto
• Vai comparando as histórias uma com as 
outras. As demais histórias são derivadas a 
partir das mais simples
• Não possui unidade. São apenas “pontos”.
Engenharia de Software
14
Exercício: Zoo Points
• Determinar os “zoo points” para os seguintes animais
Engenharia de Software
Urso Girafa Gorila Hipopótamo
Canguru Leão Tigre Rinoceronte
28
Estimativas baseadas em Dias Ideais
• 1 ponto = dia de trabalho ideal
• Dia de trabalho ideal
–Tudo funciona bem
–Você não tem nenhuma interrupção
–Tudo o que você precisa está disponível
• Analogia: partida de futebol ideal
– A bola nunca sai na lateral e no escanteio
– Não há faltas (e nem o tempo perdido com elas)
– Ao sair um gol, a bola é imediatamente 
reposicionada no jogo (sem comemorações...)
– Padrão Fifa de bola rolando: 60 mintos
Engenharia de Software
15
29
Planning Poker
• Abordagem interativa de estimativas para 
ajudar um time a chegar a um consenso.
– Cada membro possui um conjunto de cartas 
com as estimativas válidas
• Sequência de Fibonacci: 1, 2, 3, 5, 8, 13, 20
–A equipe joga cartas com quantos pontos 
cada um estima para determinada 
história. 
–As pessoas que indicaram os menores e 
maiores valores explicam o motivo da 
decisão
–Uma nova rodada de cartas é jogada
Engenharia de Software
30
Planning Poker - Exemplo
Engenharia de Software
Equipe Rodada 1 Rodada 2
João 3 5
Maria 8 5
José 2 5
Carlos 5 8
Usando o exercício anterior 
do Zoo Points, estime 
utilizando a técnica de 
Planning Poker o tamanho 
de uma baleia
Planning Poker – Exercício
16
31
3º Etapa: Priorização do Cliente e 
Definição do conteúdo da Iteração
• O cliente atribui as prioridades para as 
histórias.
• Em uma iteração várias histórias são 
implementadas.
• As histórias mais prioritáriasentram na 
iteração até o limite de pontos que a equipe 
tem disponível
– Exemplo: Uma equipe consegue implementar 40 
pontos em uma iteração de 2 semanas.
– O Usuário pode escolher histórias até no máximo 
esses 40 pontos.
Engenharia de Software
32
Execução da 
Iteração
17
33
Não iniciado Em andamento Finalizado
• Acompanhamento Visual
34
4ª Etapa: Avaliação da Iteração
• Novas histórias de usuários podem surgir 
durante a execução de uma iteração e serão 
incorporadas no projeto
• Velocidade da Equipe - Dependendo da 
produtividade da equipe durante um 
iteração, a média de pontos pode ser 
ajustada para as próximas iterações
– Exemplo: A equipe anterior planeja 40 pontos por 
iteração mas constantemente está entregando 48 
pontos ao cliente. Em uma próxima iteração a 
produtividade da equipe pode ser ajustada pela 
médias das últimas iterações
Engenharia de Software
18
352004
Prática 2 - Cliente Presente
• Deve ser incluído alguém da parte do cliente 
ou que o represente junto à equipe XP
• O cliente deve esclarecer dúvidas sobre os 
requisitos do sistema, ajudar na confecção 
dos casos de teste funcionais
• As histórias são escritas e priorizadas com 
auxílio do cliente
36
Prática 3 – Reuniões de Pé (Stand Up 
Meeting)
• Reunião rápida que a equipe de 
desenvolvimento faz a cada manhã para 
avaliar o trabalho do dia anterior e priorizar 
aquilo que será implementado no dia.
• Três perguntas devem ser respondidas por 
cada desenvolvedor:
– O que foi feito no dia anterior?
– O que vai ser feito hoje?
– Tem algo atrapalhando ou necessário para o 
trabalho a ser realizado?
• Os problemas relatados devem ser tratados 
fora da reunião!
Engenharia de Software
19
372004
Prática 4 - Programação em pares
 Todo o código produzido em XP é escrito por um par 
de programadores, que possuem papéis distintos, 
sentados lado-a-lado e olhando para o computador 
 As duplas devem ser constantemente trocadas, assim 
como os papéis e as funcionalidades implementadas
38
Prática 4 - Programação em pares
• Polêmica
–Por que usar 2 pessoas para fazer o 
trabalho de 1?
–Usando 2 pessoas dobrará o custo de 
desenvolvimento
–Não tenho mesas suficientes...
Engenharia de Software
20
39
Prática 4 - Programação em pares
• Argumentos:
– Menos Erros
– Velocidade em codificação
– Transferência de Conhecimento
– Conhecimento Global do Sistema
– Mais produtividade (sem e-mail, etc.)
– Promove maior integração entre a equipe 
Engenharia de Software
40
Prática 4 - Programação em pares
Engenharia de Software
21
41
Prática 5 - Desenvolvimento guiado 
pelos Testes
• Os desenvolvedores escrevem testes para 
cada funcionalidade antes de implementá-
las.
– melhoram o entendimento sobre as necessidades 
do cliente,
– projetam melhor as interfaces externas dos 
métodos e classes e 
– limitam até onde codificar cada funcionalidades.
Engenharia de Software
42
Tipos de Testes
• Testes de Unidade sobre cada classe, criado 
e executado pelo Desenvolvedor
– São utilizadas Classes de Testes para cada Classe 
de Domínio. Para cada método
– Escreva um teste que falhe
– Escreva o código mais simples possível que faça o 
teste passar
– Refatore (refaça o código com mais qualidade)
Engenharia de Software
22
43
Prática 6 – Refatoração
 São constantes melhorias sugeridas 
para o projeto do código sem alterar sua 
funcionalidade
 Minimizam problemas que poderiam advir da 
prática de projeto simples visto que se 
mudanças devem ser incorporadas e o 
código é bem estruturado, então isso não 
será um problema 
 Também chamado de Refactoring
44
Prática 7 - Código Coletivo
• Procura evitar “ilhas de conhecimento”.
• Quando só uma pessoa conhece uma 
solução, pode ser um gargalho no 
desenvolvimento.
• Com a programação em pares, os 
desenvolvedores passam a ser conhecedores 
de todas as funcionalidades.
• Eles têm acesso a todas as funcionalidades, 
podendo alterá-las sem necessitar de 
autorização, inclusive fazendo refactoring.
Engenharia de Software
23
45
Prática 8 - Código Padronizado
• A equipe deve estabelecer padrões de 
implementação que devem ser seguidos por todos.
• Isto agiliza as manutenções e torna o código mais 
homogêneo. Exemplos:
– Code Conventions for the Java Programming Language da 
SUN
– Writting Robust Java Code de Scott Ambler
• Características de um padrão:
– Indentação
– Letras maiúsculas e minúsculas
– Comentários
– Nome
Engenharia de Software
46
Prática 8 - Código Padronizado
• Quando alguém encontra algo fora do padrão deve-
se:
– Alertar a equipe o que está fora do padrão e forma correta 
de fazer.
– Fazer refactoring do código, colocando-o no padrão.
• Dificuldades
– Ter um padrão. Se não tiver, utilize um pronto!
– Mudança de hábito.
Engenharia de Software
24
47
Prática 9 - Design Simples
• Para ser ágil, a equipe deve optar por um código 
que seja suficiente para atender as 
necessidades atuais do cliente.
• Necessidades futuras serão atendidas quando elas 
forem requisitadas, fazendo-se uso do refactoring e 
testes, por exemplo.
• A única coisa constante em um projeto de software 
é a mudança (Beck, 2000. In: Teles, 2006): 
– Os requisitos mudam
– O design muda
– A tecnologia muda
– A equipe muda
– Os membros da equipe mudam
Engenharia de Software
48
Prática 10 - Ritmo Sustentável
• Os desenvolvedores devem trabalhar apenas 
8 horas por dia.
• As horas-extras devem ser evitadas.
• Isto para permitir que os desenvolvedores se 
mantenham atentos, criativos e dispostos a 
solucionar os problemas.
Engenharia de Software
25
49
Prática 11 - Integração Contínua
• Consiste da equipe integrarem seus códigos com 
o restante do sistema várias vezes ao dia. 
• Para garantir que o sistema esteja funcionando 
corretamente após uma integração, é necessário 
realizar todos os testes (testes de regressão).
• Utilize uma máquina em separado para a 
integração: backup e “ritual”.
Engenharia de Software
50
Prática 12 - Releases Curtos
• A equipe deve produzir um conjunto pequeno de 
funcionalidades (release)
• Colocar a release em produção rapidamente
para que o cliente possa fazer uso das 
funcionalidades o mais cedo possível.
• Durante o projeto, a equipe colocará diversas 
versões do sistema em produção, gerando um fluxo 
contínuo de valor para o cliente.
• Aumenta Feedback
• Aumenta o Retorno do Investimento
Engenharia de Software
26
51
Quando não usar XP
• Sistemas de premiação individuais
• Contratos de escopo fechado
• Clientes que fazem questão de um grande número 
de artefatos
• Empresas onde os layouts de escritórios são fixos
• Quando não se tem apoio das pessoas que decidem
• Equipes grandes e espalhadas geograficamente
• Situações onde o feedback é demorado
Engenharia de Software
52
Resumo Métodos Ágeis
27
53
Exercício Práticas Ágeis
• Você foi contratado como consultor em metodologias ágeis 
por uma empresa. Sabendo que é difícil implementar toda a 
metodologia de uma vez, quais práticas ágeis você sugeriria 
que pudessem dar um retorno o mais rápido possível?
Engenharia de Software
1. Jogo do Planejamento
2. Cliente Presente
3. Stand Up Meeting
4. Programação por Pares
5. Desenvolvimento guiado 
pelos Testes
6. Refatoração
7. Código Coletivo
8. Código Padronizado
9. Design Simples
10.Ritmo Sustentável
11. Integração Contínua
12.Releases Curtos
Exercício Práticas Ágeis
• Uma empresa que desenvolve um software internamente com uma 
equipe pequena ouviu falar muito bem dos métodos ágeis e decidiu 
incorporá-lono seu dia a dia.
• A empresa possui dois usuários de negócio que passam os requisitos 
para um analista de sistemas, que define as especificações e repassa 
para dois programadores que desenvolvem e testam o programa.
• Os usuários possuem tempo para explicar os requisitos para a equipe e 
também tirar dúvidas (toda a empresa fica no mesmo andar de um 
prédio comercial) mas normalmente eles não testam o sistema antes 
de ele entrar em produção.
• Além disso, os usuários de negocio reclamam muito de diversos bugs 
no sistema, principalmente uns que vão e voltam. Por outro lado, os 
programadores reclamam que recebem a especificação e depois 
trabalham praticamente sozinhos até colocar a nova funcionalidade em 
produção.
• As novas versões do sistema costumam demorar de 2 a 4 meses para 
ficaram prontas. Na verdade não há um tempo bem definido. O usuário 
pede, o analista diz o prazo que vai demorar, e em muitos casos, ainda 
ocorrem atrasos.
Engenharia de Software