1. Engenharia de Software
Unidade III – Desenvolvimento Ágil
de Projetos de Software
Objetivo: Enfatizar o modelo e as práticas ágeis de
desenvolvimento de software
Prof. Nécio de Lima Veras
2. Roteiro...
Manifesto Ágil
Agilidade e Processos Ágeis
Frameworks
TDD
BDD
User Stories
Velocity
Modelos Ágeis
SCRUM e XP;
3. Manifesto Ágil
Um grupo em fevereiro de 2001, chamado de Agile
Alliance, começou a descobrir maneiras melhores e mais
leves de desenvolver software valorizando:
pessoas e interações ao invés de processos e
ferramentas;
softwares funcionando no lugar de documentações
abrangentes;
colaborações com clientes do que negociações de
contratos e respostas à mudanças por planos fechados.
4. Manifesto Ágil
O modelo é baseado em mudanças
abrangentes;
O desenvolvedor deve melhorar
continuamente um protótipo
incompleto até que o cliente fique feliz com o
resultado;
O Manifesto Ágil está reforçado com outros DOZE
princípios que regem a filosofia de criar softwares com
agilidade [BECK, 2001].
5. Os doze princípios
1. Nossa maior prioridade é satisfazer o cliente através da entrega contínua e
adiantada de software com valor agregado.
2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no
desenvolvimento. Processos ágeis tiram vantagem das mudanças visando
vantagem competitiva para o cliente.
3. Entregar frequentemente software funcionando, de poucas semanas a
poucos meses, com preferência à menor escala de tempo.
4. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em
conjunto por todo o projeto.
6. Os doze princípios
5. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o
suporte necessário e confie neles para fazer o trabalho.
6. O método mais eficiente e eficaz de transmitir informações para e entre uma
equipe de desenvolvimento é através de conversa face a face.
7. Software funcionando é a medida primária de progresso.
8. Os processos ágeis promovem desenvolvimento sustentável. Os
patrocinadores, desenvolvedores e usuários devem ser capazes de manter um
ritmo constante indefinidamente.
7. Os doze princípios
9. Contínua atenção à excelência técnica e bom design aumenta a
agilidade.
10.Simplicidade (a arte de maximizar a quantidade de trabalho não
realizado) é essencial.
11.As melhores arquiteturas, requisitos e designs emergem de
equipes auto-organizáveis.
12.Em intervalos regulares, a equipe reflete sobre como se tornar
mais eficaz e então refina e ajusta seu comportamento de acordo.
8. Agilidade e Processos Ágeis
Frameworks
TDD
BDD
User Stories
Velocity
9. Agilidade
Você não tem que escolher entre
agilidade e engenharia de software.
Em vez disso, defina uma abordagem de
engenharia de software que seja ágil.
10. Test Driven Development
“A grande maioria das pessoas já teve alguma
experiência com um software que não funcionou como
esperado. Softwares que não funcionam corretamente
podem levar a muitos problemas, incluindo financeiro,
tempo e reputação das empresas. Podendo, inclusive,
chegar a influenciar na integridade das pessoas”
[ISTQB 2011].
11. Test Driven Development
Podemos associar a qualidade de um software à
quantidade de falhas percebidas no mesmo;
O teste de software ajuda a medir e/ou garantir essa
qualidade;
Níveis de Teste:
Unidade (componente)
Integração (interface entre componentes)
Sistema (comportamento)
Aceitação (apropriado para uso).
12. Test Driven Development
Modos de Testar:
Manual
Ex.: Inspeção manual de Código
Automático
Ex.: Asserção com JUnit
No contexto de testes automáticos se sobressaem duas
abordagens:
TDD (Testing-Driven Development) ou Desenvolvimento dirigido por
testes
BDD (Behavior-Driven Design) ou Projeto guiado por comportamento
13. TDD
TDD se apoia nos passos:
Escreva o teste, para a funcionalidade, antes de
estar implementada (os testes irão falhar)
Escreva o código de modo a fazer os teste
passar
Refatore o código
Repita o processo
15. Behavior Driven Development
Sobre BDD podemos fazer as seguintes considerações
[Fox e Patterson 2012]:
BDD faz perguntas sobre comportamentos antes e
durante o desenvolvimento, visando reduzir falhas na
comunicação dentro do projeto.
Requisitos são escritos como estórias de usuários. São
criadas descrições simples de como a aplicação deve
ser utilizada.
BDD se concentra no comportamento da aplicação
versus a implementação da aplicação e os testes são
conduzidos utilizando TDD.
16. Behavior Driven Development
Um exemplo simples considerando a seguinte
narrativa:
Como um usuário
Eu quero comprar produtos em promoção
E então receber um email de confirmação
Scenario: Verificar produtos em promoção
Given Que uma loja possui 10 produtos
and Que 5 estão em promoção
When Eu verifico quais estão em promoção
Then Preencho minha sacola apenas com produtos
em promoção
17. Behavior Driven Development
public class PromocaoSteps extends PtBRSteps {
Loja loja = new Loja();
Sacola sacola = new Sacola();
List<Produto> listaProdutoPromocao;
int quantidadeProdutoPromocao;
@Given("Que uma loja possui $quant produtos")
public void populaLoja(Integer quantidade) {
loja.inicializaProdutos(quantidade);
}
@Given("Que $quant estão em promoção")
public void informaProdutosPromocao(Integer quantidade) {
loja.colocaProdutosPromocao(quantidade);
quantidadeProdutoPromocao = quantidade;
}
@When("Eu verifico quais estão em promoção")
public void verificaProdutosPromocao() {
listaProdutoPromocao = loja.retornaProdutosPromocao();
}
@Then("Preencho minha sacola apenas com produtos em promoção")
public void populaSacola() {
sacola.populaSacola(listaProdutoPromocao);
Assert.assertEquals(listaProdutoPromocao.size(),
quantidadeProdutoPromocao);
}
}
18. Behavior Driven Development
Assim temos:
“Given” é a condição inicial
“When” é a ação realizada para a obtenção do
resultado
“Then” a conclusão/comportamento esperado
19. User Story
Story vem de conto (estória) e não de história (relato de fatos);
É basicamente uma lista de requisitos, funções que o dono do
negócio solicita e que espera que elas sejam entregues, descritas
em linguagem coloquial.
Aspectos críticos:
Deve ser escrita em cartões (ou post-its), pois devem ser pequenas;
Deve identificar uma funcionalidade;
Deve ser definida uma forma de validação.
Devem ser independentes umas das outras;
Não são contratos, mas sim lembretes. Por isso devem ser
informais;
Devem agregar valor ao cliente;
Devem ser estimáveis;
Devem ser testáveis.
21. Velocity
Uma das mais importantes métricas para um time Ágil;
Em termos de gerenciamento de projetos, Velocity é o “valor
de trabalho” que um time precisa completar em um dado
período de tempo (entre 1 e 4 semanas);
Este “valor de trabalho” é número total de estórias que o
time estimou;
Assim, Velocity é simplesmente o trabalho dividido pelo
time;
Para isso é feito um cálculo de produtividade baseado no
total de funcionalidades codificadas, seu grau de
importância e o tempo gasto;
23. Scrum
É um modo á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 Sewaber e
Beedle.
24. Scrum
Princípios:
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 do
software “que podem ser inspecionados,
ajustados, testados, documentados e
expandidos”.
25. Scrum
Princípios:
O trabalho de desenvolvimento e o pessoal que o
realiza é dividido “em 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 a “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.)”
27. eXtreme Programming
O XP usa uma abordagem orientada a objetos
como seu paradigma de desenvolvimento
predileto.
Inclui um conjunto de regras e práticas que
ocorrem no contexto de quatro atividades:
planejamento,
projeto,
codificação e
teste.
28. Extreme Programming (XP)
Planejamento:
Começa com a criação de
um conjunto de histórias
(histórias do usuário) que
descrevem as
características e
funcionalidades
requeridas para o
software a ser construído.
Cada história é escrita
pelo cliente e é colocada
em um cartão de
indexação.
29. Extreme Programming (XP)
Planejamento:
O cliente atribui um
valor (prioridade) para a
história, com base no
valor de negócio global
da característica ou da
função.
Membros da equipe XP
avaliam então cada
história e lhe atribuem
um custo – medido em
semanas de
desenvolvimento.
30. Extreme Programming (XP)
Planejamento:
Se a história precisar
mais do que três
semanas de
desenvolvimento, pede-
se ao cliente para
dividir a história em
histórias menores e a
atribuição de valor e
custo ocorre
novamente.
Novas histórias podem
ser escritas a qualquer
momento.
32. Extreme Programming (XP)
Projeto:
O projeto XP segue rigorosamente o princípio KIS
(keep it simple – mantenha a simplicidade).
Um projeto simples é sempre preferível em
relação a uma representação mais complexa.
Além disso, o projeto fornece diretrizes de
implementação para uma história como ela está
escrita – nada mais e nada menos.
O XP encoraja o uso de cartões CRC (Class
Responsability Colaborator) como um mecanismo
efetivo para raciocinar sobre o software no
contexto orientado a objetos.
33. Extreme Programming (XP)
Características:
Encoraja a refatoração;
A Programação em par;
Desenvolvimento incremental;
A integração contínua;
Testes!!!
36. Referências
Beck, K., et al. (2001). "Manifesto for Agile
Software Development". Agile Alliance.
http://agilemanifesto.org/. Acessado em 18 de
agosto de 2012.
Fox, A., Patterson, D. (2012). “Engineering
Long-Lasting Software: An Agile Approach
Using SaaS and Cloud Computing”, Alpha
Edition. Strawberry Canyon LLC, 2012.
