ES1 Aula06 Desenvolvimento Ágil parte 2 Banco de Dado

Prévia do material em texto

PROF. HENRIQUE LEITÃO
E-mail: henriqueleitao@gmail.com
©Marcus Vinícius
ENGENHARIA DE
SOFTWARE I
Desenvolvimento Ágil (parte 2)
06
2/24Engenharia de Software I
EXTREME PROGRAMMING – XP
 É a abordagem mais amplamente utilizada para 
desenvolvimento de software ágil proposta por Kent Beck.
 Valores XP: conjunto de cinco valores que estabelecem as 
bases para todo trabalho realizado.
 Comunicação;
 Simplicidade;
 Feedback;
 Coragem;
 Respeito.
3/24Engenharia de Software I
EXTREME PROGRAMMING – XP
Processo
4/24Engenharia de Software I
EXTREME PROGRAMMING – XP
Processo: planejamento
 Inicia com a criação de “histórias de usuário”;
 A equipe ágil avalia cada “história” e atribui um custo;
 “Histórias” são agrupadas em incrementos de entrega;
 Um compromisso básico é feito sobre a data da entrega;
 Após o primeiro incremento a “velocidade do projeto” é 
medida para ajudar a ajustar as entregas subsequentes e as 
suas respectivas datas;
5/24Engenharia de Software I
EXTREME PROGRAMMING – XP
Processo: projeto
 O projeto XP segue rigorosamente o princípio KIS (keep it 
simple);
 Encoraja o uso de cartões como um mecanismo eficaz para 
pensar sobre software em um contexto orientado a objetos;
 Se um problema difícil de projeto for encontrado como parte 
do projeto de uma história, é recomendado a criação imediata 
de um protótipo operacional dessa parte do projeto;
 XP encoraja a refatoração – uma técnica de construção que 
também é um método para otimização de projetos.
6/24Engenharia de Software I
EXTREME PROGRAMMING – XP
Processo: projeto
 Fowler descreve a refatoração como sendo “o 
processo de alteração de um sistema de software 
de tal forma que não se altere o comportamento 
externo do código, mas se aprimore a estrutura 
interna”.
7/24Engenharia de Software I
EXTREME PROGRAMMING – XP
Processo: codificação
 Recomenda que sejam desenvolvidas uma série de testes de 
unidades que exercitarão cada uma das histórias do 
incremento atual;
 Um conceito-chave na atividade de codificação é a 
programação em dupla (pair programming).
8/24Engenharia de Software I
EXTREME PROGRAMMING – XP
Processo: teste
 Todas as unidades de teste são executadas 
diariamente;
 Testes de aceitação são especificados pelo 
cliente e mantêm o foco nas características e na 
funcionalidade do sistema total que são visíveis e 
que podem ser revistas pelo cliente.
9/24Engenharia de Software I
SCRUM
Introdução
 Scrum é um processo iterativo
e incremental para o 
desenvolvimento de qualquer 
produto e gerenciamento de 
qualquer projeto.
 Scrum não é um método de Engenharia de Software, ele não 
vai te dizer como programar ou fazer testes.
 Scrum é um framework para gerenciamento de projetos 
iterativos.
 Scrum é uma abordagem para desenvolvimento de sistemas 
e produtos onde os requisitos sofrem constantes mudanças
10/33Engenharia de Software I
Fique Ligado!
Scrum é simples de entender e difícil 
de adotar e praticar.
11/24Engenharia de Software I
SCRUM
Ciclo
Adaptado de: http://improveit.com.br/scrum
Sprint
Backlog
Product
Backlog
Daily Scrum
Meeting
Potentialy Shippable
Product Increment
Sprint Review
Sprint RetrospectiveSprint
Planning
12/33Engenharia de Software I
• É um período de tempo entre 2 
a 4 semanas;
• Sempre deve ter um objetivo a 
ser atingido pela equipe;
• É normal que o tempo de 
duração dos sprints possam 
variar no início do projeto, mas 
o ideal é que se chegue num 
tempo único para todos os 
sprints;
• Todos os sprints devem possuir 
uma estrutura exatamente igual.
13/24Engenharia de Software I
CONE DA INCERTEZA
14/24Engenharia de Software I
SCRUM
Artefatos
 Product Backlog
 Sprint Backlog
 Burndown Chart
15/24Engenharia de Software I
SCRUM
Product Backlog
Requisitos do Produto
Dinâmicamente Repriorizado
Sempre Mudando...
Lista do que fazer
16/24Engenharia de Software I
SCRUM
Product Backlog
17/24Engenharia de Software I
O ICEBERG DO PRODUCT BACKLOG
18/24Engenharia de Software I
SCRUM
Sprint Backlog
 Parte do Product Backlog que vai ser feita numa iteração 
(Sprint).
 Montado a partir das funcionalidade que estão no topo do 
Product Backlog.
19/33Engenharia de Software I
Todos os post-its de tarefas andam nesta direção
Depois o item do backlog (em branco) vai para Pronto
Ninguém está 
trabalhando 
hoje.
Alguém está 
trabalhando 
hoje.
Ninguém 
trabalhará 
mais!
Se todos os itens do backlog
forem concluídos antes da 
sprint, adicione novos aqui.
20/33Engenharia de Software I
21/24Engenharia de Software I
DINÂMICA DO PRODUCT BACKLOG
P
ri
o
ri
d
a
d
e
Alta
Baixa
P
ro
d
u
c
t
B
a
c
k
lo
g
A
B
C
D
E
F
G
H
I
J
Sprint
O que está dentro da sprint
não pode ser alterado.
O que está fora da sprint
pode ser alterado de 
acordo com a necessidade 
do cliente.
O cliente pode alterar 
prioridades, inserir novas 
tarefas ou retirar tarefas 
existentes.
22/24Engenharia de Software I
PAPÉIS DO SCRUM
 Scrum Master
 Product Owner
 Time
23/24Engenharia de Software I
PAPÉIS DO SCRUM
Scrum Master
 Garantir o Uso do Scrum;
 Responsável pela aplicação dos valores e práticas do Scrum;
 Remove barreiras entre o desenvolvimento e o cliente;
 Auxilia o Product Owner
com o product backlog;
 Facilita reuniões.
24/24Engenharia de Software I
PAPÉIS DO SCRUM
Product Owner
 Define a visão do produto;
 Define as funcionalidades do produto;
 Prioriza cada requisito de acordo com seu valor para o 
negócio/cliente.(gerência o product backlog);
 Responsável pela rentabilidade (ROI);
 Garantir que os especialistas de domínio estejam disponíveis 
para o time;
 Aceita ou rejeita o resultado dos trabalhos.
25/24Engenharia de Software I
PAPÉIS DO SCRUM
Time
 Auto organizados e auto gerenciáveis;
 Comprometidos com o trabalho;
 Composto por no máximo 9 integrantes;
 Comunicativos;
 Organizados em um 
espaço físico apropriado 
para o trabalho.
26/24Engenharia de Software I
TIME FUNCIONAL
27/24Engenharia de Software I
TIME COMPROMETIDO
No Scrum busca-se MAIS comprometimento 
e MENOS envolvimento!
28/24Engenharia de Software I
CERIMÔNIAS NO SCRUM
 Planejamento do Sprint
 Daily Scrum Meeting (Reunião diária)
 Sprint Review
 Sprint Retrospective (Retrospectiva do Sprint)
29/24Engenharia de Software I
CERIMÔNIAS NO SCRUM
Planejamento do Sprint
PO Apresenta as histórias
de maior prioridade
Time seleciona histórias
para compor Sprint e as
quebra em Tarefas
PO + Time definem Sprint Goal
e o Sprint Backlog é criado
30/24Engenharia de Software I
CERIMÔNIAS NO SCRUM
Planejamento do Sprint
15 minutos!!!
O que fez ontem?
O que fará hoje?
Tem algum obstáculo?
As respostas são 
compromissos!
31/24Engenharia de Software I
CERIMÔNIAS NO SCRUM
Sprint Review
Apresentação dos Resultados do Sprint
Demo de novas funcionalidades
Informal (“no slides”)
32/24Engenharia de Software I
CERIMÔNIAS NO SCRUM
Sprint Retrospective
33/33Engenharia de Software I