Engenharia de Software
Desenvolvimento Ágil
Capítulo 4
Engenharia de Software
Roger Pressman
6a. Edição – McGrawHill
Manifesto Ágil
“Estamos evidenciando maneiras melhores de desenvolver software
fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse
trabalho, passamos a valorizar:
• Interação entre pessoas MAIS QUE processos e ferramentas;
• Software em funcionamento MAIS QUE documentação abrangente;
• Colaboração com o cliente MAIS QUE negociação de contratos;
• Responder a mudanças MAIS QUE seguir um plano.
Ou seja, mesmo tendo valor os itens à direita, valorizamos mais os
itens à esquerda.” Aliança Ágil – 2001.
Kent Beck, Robert C. Martin, Scott Ambler, Alistair Cockburn, Ward Cunningham, Ron
Jeffries, Steve Mellor, Mike Beedle, Arie van Bennekum, Martin Fowler, James
Grenning, Jim Highsmith, Andrew Hunt, Brian Marick, Ken Schwaber, Jeff Shuterland,
Dave Thomas
Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I
2
O que é agilidade?
Segundo Ivar Jacobson a agilidade tornou-se uma palavra
mágica que descreve um processo moderno de software.
Tudo é ágil …
- Equipe ágil, capaz de responder adequadamente a
modificações.
- Sendo que modificações envolve todo o desenvolvimento
de software, ou seja, modificações nos requisitos, membros
da equipe, tecnologias.
Na visão de Ivar Jacobson o acolhimento de modificações é
o principal guia para a agilidade
Outras definições podem ser consideradas….
Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I
3
O que é agilidade?
Segundo a Aliança Ágil existem 12 princípios a serem considerados para
alcançar a agilidade.
1.
Nossa maior prioridade é satisfazer ao cliente desde o início por
meio de entregas contínua de software valioso.
2.
Modificações de requisitos são bem vindas, mesmo que tardias no
desenvolvimento .
3.
Entrega de software funcionando ferqüentemente, a cada duas
semanas até dois meses, de preferência no menor espaço de tempo.
4.
O pessoal de negócio e de desenvolvimento devem trabalhar juntos
diariamente durante todo o projeto
5.
Contrução de projetos em torno de indivíduos motivados.
6.
O método mais eficiente e efetivo de levar informação para dentro de
uma equipe de desenvolvimento e a conversa face a face
Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I
4
O que é agilidade?
7.
Software funcionando é a principal medida de progresso.
8.
Processos ágeis promovem desenvolvimento sustentável.
9.
Atenção contínua a excelência técnica e ao bom projeto facilitam a
agilidade
10. Simplicidade
11. As melhores arquiteturas, requisitos e projetos surgem de equipes
auto-organizadas.
12. Em intervalos regulares, a equipe reflete sobre como se torna mais
efetiva, então sintoniza e ajusta adequadamente seu comportamento.
Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I
5
Modelos Ágeis de Processo







Extreme Programming(XP)
Desenvolvimento Adaptativo de Software
Desenvolvimento Dinâmico de Sistemas
SCRUM
Família Crystal
Desenvolvimento Guiado por
Características
Modelagem Ágil
Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I
6
XP (eXtreme Programming)
XP - Extreme Programming
• “O XP (eXtreme Programming) é uma
metodologia ágil para equipes pequenas e
médias desenvolvendo software com
requisitos vagos e em constante mudança“.
Kent Beck, criador da XP.
• É baseado em 4 valores e 12 práticas.
Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I
8
Valores do XP

Comunicação;

Simplicidade;

Realimentação;

Coragem.
Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I
9
Valores do XP

Comunicação: A comunicação não é limitada a
procedimentos formais, há preferência por uma comunicação
mais ágil. Como um telefonema pode ser melhor que um email, a presença física melhor que a comunicação remota ou
um código auto-explicativo melhor que uma documentação
escrita;

Simplicidade: A solução adotada deve ser sempre a mais
simples possível que alcance os objetivos esperados. São
utilizadas tecnologias, projetos, algoritmos e técnicas simples,
que permitirão atender aos requerimentos do usuário final.
Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I
10
Valores do XP

Realimentação (Feedback): Garante que todos entendam
como os resultados estão satisfazendo o cliente. Permite maior
agilidade: erros detectados e corrigidos imediatamente,
requisitos e prazos reavaliados mais cedo, facilidade na
tomada de decisão, permitem estimativas mais precisas, maior
segurança e menos riscos para investidores.

Coragem: É preciso ter coragem para tomar as decisões certas
nas horas certas.
Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I
11
Práticas do XP






Cliente “on-site”
Jogo de planejamento
Metáfora
Releases Curtos
Projeto Simples
Testes antes da
Codificação






Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I
Padrões
Refactoring
Programação em pares
Propriedade coletiva
Integração Contínua
Semana de 40 horas
12
Práticas do XP
Cliente “on site” (sempre presente): O cliente fica junto
com o time de desenvolvimento, escreve cartões de estória,
faz realimentação diariamente, fornece exemplos para testes
de integração razoáveis, gerencia testes de aceite, etc..;

Jogo do planejamento: Conhecedores de negócio e de
software decidem conjuntamente em que ordem o sistema
deve ser implementado;

Metáfora: Explicação de alto nível, facilmente entendida que
usa convenções de nomenclatura.

Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I
13
Práticas do XP
Releases Curtos: As funcionalidades devem ser entregues
tão cedo e tão freqüentemente quanto possível (tipicamente 3
semanas);

Projeto
Simples:
Toda
funcionalidade
deve
ser
implementada da forma mais simples possível. Considerações
sobre projeto arquitetônico devem ser postergadas, tudo que
pode ser postergado deve ser postergado;

Testes antes da codificação: Ênfase em código livre de
defeitos, os testes de unidade são escritos para validar a
implementação dos cartões de estória. Apenas após o primeiro
teste estiver pronto é que se faz a codificação.

Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I
14
Práticas do XP
Padrões: São definidos pela equipe e permitem que
qualquer membro entenda qualquer código.

Refactoring (Refabricação): Abordagem disciplinada para
reestruturação de código.

Programação em pares: Pares de desenvolvedores em uma
máquina desenvolvem todo o código de produção. Revisão
acontece enquanto o código é escrito, uma pessoa lidera com
teclado e mouse e a outra analisa. Os papéis são trocados
periodicamente.


Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I
15
Práticas do XP
Propriedade Coletiva: Qualquer um pode mudar código, e
todos são responsáveis por todo o código.

Integração Contínua: medida em que cada cartão de
estórias é implementado e o código passa pelos testes de
unidade, ele é imediatamente integrado e os testes de
integração são executados. Os resultados podem ser
visualizados por toda a equipe e pelo cliente.

Semana de 40 horas: Pequenos incrementos de trabalho
possibilitam que a maioria dos dias termine com a finalização
de uma tarefa.

Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I
16
XP - Extreme Programming sob o ponto
de vista de processo de desenvolvimento
Sob o ponto de vista das fases clássicas de processo de desenvolvimento as
atividades chaves do XP estão distribuídas da seguinte forma:
Planejamento:
• Criação dos cartões de estórias, escritas pelos clientes, que descrevem as
características e funcionalidades do software (várias estórias devem ser
contadas;
• O cliente atribui uma prioridade para cada estória;
• Equipe de desenvolvimento (líder) avaliam cada estória e atribuem prazo e
custo. Se a estória precisar de mais de 3 semanas, geralmente pede-se ao
cliente que divida a estória em estórias menores;
• Cliente e equipe de desenvolvimento (líder) decidem a ordem de
implementação de cada estória (versões a serem entregues).
Obs: A qualquer momento o cliente pode adicionar, mudar a prioridade, alterar ou
eliminar estórias. A equipe de desenvolvimento (líder) reconsidera todas as
versões remanescentes e modifica os planos.
Enfoque: Comunicação e Coragem.
Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I
17
XP - Extreme Programming sob o ponto
de vista de processo de desenvolvimento
Projeto:
• Enfoque na simplicidade;
• É projetado pela equipe de desenvolvimento (programadores) o que foi
descrito (nada mais, nada menos);
• Pode-se utilizar cartões CRC (Class Responsability Colaboration);
• Se um problema difícil é encontrado, o XP recomenda a criação de um
protótipo pela equipe de desenvolvimento (programadores) para avaliação
do cliente, visando diminuir riscos;
• Encoraja a refabricação;
Refabricação é um processo de modificar um sistema de software de tal
modo que ele não altere comportamento externo, mas aperfeiçoe a estrutura
interna. É um modo adequado de limpar, alterar e simplificar o projeto interno
visando minimizar defeitos, ou seja, aperfeiçoar o projeto de código depois
que foi escrito.
Obs: O XP praticamente não possui nenhuma metodologia, notação e
documentação.
Enfoque: Simplicidade e Realimentação (Feedback).
Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I
18
XP - Extreme Programming sob o ponto
de vista de processo de desenvolvimento
Codificação:
• Cria-se uma série de testes unitários, pela equipe de
desenvolvimento (programadores), que exercitarão cada
uma das estórias antes da implementação;
• Programação em pares.
Enfoque: Simplicidade e Realimentação (Feedback).
Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I
19
XP - Extreme Programming sob o ponto
de vista de processo de desenvolvimento
Teste:
• Elaboração e execução de testes unitários, integração e
validação, pela equipe de desenvolvimento (Quality
Assurance);
• Testes de aceitação, pelos clientes.
Enfoque: Comunicação e Realimentação (Feedback).
Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I
20
“Conclusões” do XP

As propostas de XP são bastante heterodoxas;

Há uma grande quantidade de experiências sendo
realizadas no mundo todo;

A definição de orçamento ainda não está resolvida;

O nível de qualidade é duvidoso no XP. E possível
obter uma certificação?

A manutenção do sistema por outras equipes de
desenvolvimento pode ser complicada;

Para projetos curtos e com equipes pequenas,
parece funcionar muito bem.
Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I
21
SCRUM
O que é Scrum?
 O Scrum (o nome é derivado de uma atividade do jogo
de rugby) é um modelo ágil de processo que foi
desenvolvido por Jeff Sutherland e por sua equipe no início
da década de 1990.
 Nos últimos anos foi realizado desenvolvimento
adicional de métodos Scrum por Scwaber e Beedle.
 É um processo ágil que permite manter o foco na
entrega do maior valor do negócio, no menor tempo
possível.
Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I
23
Características do Scrum
O Scrum é consistente com o manifesto ágil:
 Pequenas equipes de trabalho são organizadas de
modo a “maximizar a comunicação, minimizar a supervisão
e maximizar o compartilhamento de conhecimento tácito
informal”;
 O processo precisa ser adaptável tanto a modificações
técnicas quanto de negócios “para garantir que o melhor
produto possível seja produzido”;
 O processo produz frequentes incrementos de software
“que podem ser inspecionados, ajustados, testados,
documentados e expandidos”;
Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I
24
Características do Scrum
 O trabalho de desenvolvimento e o pessoal que o
realiza é divido “partições claras, de baixo acoplamento, ou
em pacotes”;
 Testes e documentação constantes são realizados à
medida que o produto é construído;
 O processo Scrum fornece “habilidade de declarar o
produto ´pronto´ sempre que necessário (porque a
concorrência acabou de entregar, porque a empresa
precisa de dinheiro, porque o usuário/cliente precisa das
funções, porque foi para essa data que foi prometido ...)”.
Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I
25
Forma de trabalho do Scrum
A figura 9 representa o fluxo de processo Scrum.
15 minutos de reunião diária.
Sprint Backlog
Registro de Pendências
Características associadas a
um sprint
a cada
24 horas
2a4
semanas
Product Backlog
Pendência de Produtos:
Características priorizadas
do produto desejado pelo cliente
Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I
Nova funcionalidade
Ao final do sprint
26
Forma de trabalho do Scrum
 Pendência de Produtos (Product Backlog): uma lista
priorizada de requisitos ou características do projeto que
fornecem valor de negócio para o cliente. Itens podem ser
adicionados à pendência a qualquer momento (é assim que
as modificações são introduzidas). O gerente de produto
avalia a pendência e atualiza as prioridades quando
necessário;
Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I
27
Forma de trabalho do Scrum
 Registro de Pendências (Sprints Backlog): Consiste
de unidades de trabalho que são necessárias para
satisfazer a um requisito definido na pendência que precisa
ser cumprido em um intervalo de tempo pré-definido
(tipicamnete de 2 a 4 semanas). Durante o sprint, os itens
em pendência a que as unidades de trabalho do sprint se
destinam são congeladas, ou seja não são introduzidas
modificações durante o sprint. Assim, os membros da
equipe trabalham em um ambiente de curto prazo, mas
estável;
Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I
28
Forma de trabalho do Scrum
 Reuniões Scrum: são reuniões curtas (normalmente de
15 minutos) feitas diariamente pela equipe Scrum. Três
questões chaves são formuladas e respondidas por todos
os membros da equipe.
O que você fez desde a última reunião de
equipe?
Que obstáculos você está encontrando?
O que você planeja realizar até a próxima
reunião de equipe?
Essas reuniões diárias ajudam a equipe a descobrir
problemas potenciais tão cedo quanto possível, e
promovem uma equipe auto-organizada e a socialização do
conhecimento.
Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I
29
Forma de trabalho do Scrum
 Novas funcionalidades: entrega o incremento de
software ao cliente de modo que a funcionalidade
implementada possa ser demonstrada e avaliada pelo
cliente.
Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I
30
Equipe do Scrum
Equipe padrão de trabalho do Scrum
 Scrum Master: Auxilia no desenvolvimento da equipe,
resolvendo impedimentos e assegurando que tudo está de
acordo para que o objetivo estabelecido no sprint seja
alcançado e lidera a reunião diária;
 Product Owner: Representa a voz do cliente/usuário e
muitas vezes é o próprio. É responsável por criar o Product
Backlog;
 Scrum Time: Grupo de desenvolvimento do sprint
(programadores, testadores e etc...).
Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I
31
Copyright © 2007 - 2014 Profa. Ana Paula Gonçalves Serra.
Todos direitos reservados. Reprodução ou divulgação total ou parcial
deste documento é expressamente proibido sem o consentimento
formal, por escrito, da Profa. Ana Paula Gonçalves Serra.
Profa. Dra. Ana Paula Gonçalves Serra - Engenharia de Software I
32