12. XP e Scrum

Prévia do material em texto

1 
Processos de Desenvolvimento 
de Software 
• Os processos de desenvolvimento rápido de 
software: 
– Geralmente são iterativos e incrementais 
– As fases de especificação, projeto e 
implementação são concorrentes 
– Utilizam prototipação para compor o projeto de 
interface 
 
 
 
Introdução 
3 
• As principais vantagens de uma abordagem 
incremental: 
– Entrega acelerada dos serviços ao cliente 
– Engajamento do usuário com o sistema 
 
 
Introdução 
4 
• As principais dificuldades com o modelo 
iterativo e seus incrementos: 
– Problemas de gerenciamento 
– Problemas de contrato 
– Problemas de validação 
– Problemas de manutenção 
 
 
Introdução 
5 
• O desenvolvimento rápido de software melhor 
se encaixa em sistemas: 
– De médio e pequeno porte 
– Não críticos 
– Com equipes geograficamente não distribuídas 
 
 
 
Introdução 
6 
• Os métodos ágeis: 
– Apoiam projetos onde requisitos mudam 
rapidamente 
– Destinam-se a entregar o software de forma 
rápida aos clientes 
 
 
 
 
Métodos Ágeis 
7 
• Princípios dos métodos ágeis: 
– Envolvimento do cliente 
– Entrega incremental 
– Pessoas, não processo 
– Aceite as mudanças 
– Mantenha a simplicidade 
 
 
 
Métodos Ágeis 
8 
• Dificuldades dos princípios dos métodos ágeis: 
– Nem sempre o cliente está disponível 
– Membros da equipe podem ter dificuldade em 
interagir com a equipe 
– A priorização de mudanças pode ser 
extremamente difícil 
– Manter a simplicidade requer trabalho extra 
 
 
 
Métodos Ágeis 
9 
• Em geral... 
– Modelos de processo tradicionais mantêm o foco 
na geração de documentação e no cumprimento 
rígido de fases/etapas. 
• XP... 
– Propõe-se a concentrar as atenções na produção 
de código e no relacionamento/comunicação 
entre os participantes do projeto. 
 
 
 
Extreme Programming 
10 
• Valores: 
– Comunicação 
• O sucesso do projeto depende: 
– da interação entre os membros da equipe, programadores, 
cliente, etc. 
– Da qualidade dos canais de comunicação utilizados. Conversas 
cara-a-cara são sempre melhores do que telefonemas, e-
mails, cartas ou fax. 
– Feedback 
• As respostas às decisões tomadas devem ser rápidas e 
visíveis. 
 
 
Extreme Programming 
11 
• Valores: 
– Coragem 
• Alterar um código em produção, sem causar efeitos 
colaterais, com agilidade, exige muita coragem e 
responsabilidade. 
– Simplicidade 
• Para atender rapidamente às necessidades do cliente; 
• Em geral, o que o cliente quer é muito mais simples do 
que aquilo que os programadores constroem. 
 
 
 
Extreme Programming 
12 
• Valores: 
– Respeito 
• Todos têm sua importância dentro da equipe; 
• Todos devem ser respeitados e valorizados. 
 
 
 
Extreme Programming 
13 
• Práticas de desenvolvimento 
– Planejamento 
• Prioridades do negócio e contexto/opinião dos 
desenvolvedores são consideradas na definição do 
escopo e no cronograma das iterações. 
– Pequenas entregas 
• Versões incrementais do software são entregues ao 
cliente em ciclos curtos de tempo; 
• Redução de riscos para o projeto; 
• Acompanhamento da mudança de requisitos. 
 
 
Extreme Programming 
14 
• Práticas de desenvolvimento 
– Metáfora 
• A definição das user stories deve usar termos do negócio 
para que os desenvolvedores se comuniquem melhor com o 
cliente. 
– Projeto simples 
• O sistema construído deve ser o mais simples possível; 
• Não devem ser acrescentados recursos que não foram 
solicitados pelo cliente (gold-plating); 
• Código menos complexo favorece entendimento fácil pelos 
programadores. 
Extreme Programming 
15 
• Práticas de desenvolvimento 
– Testes 
• Devem ser escritos antes mesmo do código; 
• Devem ser automatizados para garantir a verificação 
das versões anteriores; 
• Servem como documentação; 
• Os clientes ajudam na definição de testes funcionais 
para o sistema. 
Extreme Programming 
16 
• Práticas de desenvolvimento 
– Refactoring 
• O código é revisado à medida que novas 
funcionalidades vão sendo acrescentadas para remover 
redundâncias e complexidade; 
• Funcionamento do sistema não deve ser é afetado, 
apenas a qualidade do código. 
Extreme Programming 
17 
• Práticas de desenvolvimento 
– Programação em pares 
• Desenvolvedores trabalham em duplas; 
• Enquanto um escreve o código, o outro faz a revisão e 
discute modificações, garantindo uma maior qualidade; 
• Os papéis deve ser alternados; 
• Favorece o entrosamento da equipe. 
Extreme Programming 
18 
• Práticas de desenvolvimento 
– Propriedade coletiva 
• Todos os desenvolvedores são responsáveis pelo 
código; 
• Todos os desenvolvedores possuem permissão para 
alterar qualquer trecho; 
• Os testes automatizados ajudam a identificar 
problemas decorrentes de alterações. 
Extreme Programming 
19 
• Práticas de desenvolvimento 
– Integração contínua 
• As funcionalidades vão sendo integradas ao código à 
medida em que vão sendo produzidas; 
• Os testes automatizados garantem a integração sem 
erros; 
• Sempre há uma versão executável e atualizada da 
aplicação disponível. 
Extreme Programming 
20 
• Práticas de desenvolvimento 
– 40 horas semanais 
• Jornadas extras de trabalho devem ser evitadas; 
• Não comprometer a produtividade e a motivação dos 
desenvolvedores. 
– Presença do cliente 
• Cliente trabalha junto com os desenvolvedores ao 
longo de todo o projeto escolhendo funcionalidades, 
esclarecendo dúvidas e definindo testes funcionais; 
• Não há intermediários na comunicação; 
• O cliente se sente parte do processo. 
Extreme Programming 
21 
• Práticas de desenvolvimento 
– Padrões de codificação 
• Devem ser adotados por toda a equipe para facilitar a 
compreensão do código e a comunicação entre 
desenvolvedores; 
• O código deve ser o mais claro possível para minimizar 
a necessidade de documentação adicional. 
Extreme Programming 
22 
• Etapas: 
– Definição de user-stories do sistema 
– Desenvolvimento 
– Integração 
Extreme Programming 
23 
• Vantagens: 
– Processo mais simples em relação à quantidade 
de fases a serem seguidas e aos artefatos gerados 
– Processo com ênfase na produção de código, e 
não na produção de documentação 
Extreme Programming 
24 
• Desvantagens: 
– Indicado para times pequenos; 
– Indicado para times que trabalham juntos; 
– Mas... 
• ...ainda há poucos resultados que comprovem sua 
eficácia em projetos maiores, onde a comunicação não 
seja tão eficiente. 
Extreme Programming 
25 
• Scrum é um processo para construir software 
incrementalmente em ambientes complexos, 
onde os requisitos não são claros ou mudam 
com muita freqüência. 
Scrum 
26 
 
Scrum 
27 
• Em Rugby, Scrum é um time de oito 
integrantes que trabalham em conjunto para 
levar a bola adiante no campo. 
– Times trabalhando como uma unidade altamente 
integrada 
– Cada membro desempenhando um papel bem 
definido 
– Time inteiro focando num único objetivo. 
 
Scrum 
28 
• O objetivo do Scrum é fornecer um processo 
conveniente para projetos e desenvolvimento 
orientado a objetos. 
• A metodologia é baseada em princípios 
semelhantes aos de XP: 
– equipes pequenas, requisitos pouco estáveis ou 
desconhecidos, e iterações curtas para promover 
visibilidade para o desenvolvimento. 
 
Scrum 
29 
• Scrum divide o desenvolvimento em Sprints 
de 30 dias. 
• Equipes pequenas,de até 7 pessoas, são 
formadas por projetistas, programadores, 
engenheiros e gerentes de qualidade. 
• Estas equipes trabalham em cima de 
funcionalidade (os requisitos, em outras 
palavras) definidas no início de cada Sprint. 
 
Scrum 
30 
• A equipe toda é responsável pelo 
desenvolvimento desta funcionalidade 
• Todo dia, é feita uma reunião de 15 minutos 
onde o time expões à gerência o que será feito 
no próximo dia 
• Nestas reuniões os gerentes podem levantar 
os fatores de impedimento, e o progresso 
geral do desenvolvimento. 
 
Scrum 
31 
• Nas reuniões diárias: 
– Todos respondem às perguntas: 
– O que você realizou desde a última reunião? 
– Quais problemas você enfrentou? 
– Em que você trabalhará até a próxima reunião? 
 
Scrum 
32 
• Nas reuniões diárias: 
– Benefícios: 
– Maior integração entre os membros da equipe 
– Rápida solução de problemas 
– Promovem o compartilhamento de conhecimento 
– Progresso medido continuamente 
– Minimização de riscos 
Scrum 
33 
• Scrum é interessante porque fornece um 
mecanismo de informação de status que é 
atualizado continuamente, e porque utiliza a 
divisão de tarefas dentro da equipe de forma 
explicita. 
 
Scrum 
34 
• Fases 
 
Scrum 
35 
• Fase de encerramento: 
– Iniciada quando todos os aspectos são satisfatórios 
(tempo, competitividade, requisitos, qualidade, custo) 
– Atividades: 
– Testes de integração 
– Testes de sistema 
– Documentação do usuário 
– Preparação de material de treinamento 
– Preparação de material de marketing 
Scrum 
36 
• Dúvidas? 
 
 
 
37 
• SOMMERVILLE, I. Engenharia de Software. Editora Pearson, 2008; 
• PRESSMAN, R. S. Engenharia de Software. McGraw Hill, 2006. 
 
 
 
 
 
38 
Referências