[06] EngSW - Métodos Ágeis - SCRUM v1 6

Prévia do material em texto

1
Teoria de Engenharia de 
Software
Aula 6
Métodos Ágeis - SCRUM
Prof. Rafael Targino
rtargino@unicarioca.edu.br
Mas será que quebrar o projeto em entregas 
parciais é o suficiente?
Lista de 
Exercício 2
Entrega daqui a 
3 semanas
2
Por que precisamos de métodos iterativos?
Complexo
Anarquia
Complicado
Simples
Técnica / 
Como Fazer
E
s
c
o
p
o
 /
 
O
 q
u
e
 F
a
z
e
r
- certeza+ certeza
+ acordo
- acordo
Como fica o escopo do seu projeto?
3
Produto Mínimo Viável (MVP)
Importância de saber o momento de Parar
Não dá para ter certeza que a bicicleta elétrica atende ao negócio até você desenvolvê-la...
4
Usar métodos tradicionais ou ágeis?
• Ágil
• requisitos não conhecidos
• inovação
• usuários irão aprender 
durante o 
desenvolvimento
• documentação apenas do 
que é necessário
• planejamento apenas da 
próxima iteração
• Sistemas menores
• Tradicional
• requisitos estáveis
• migrar sistemas 
• usuários seguros do que 
querem
• documentação 
abrangente
• planejamento de um 
conjunto de iterações
• Sistemas muito grandes
É p r e c i s o o l h a r a n a t u r e z a d o p r o d u t o !
Resumo dos Métodos
Método Planejamento Entrega
Método
Sequencial
Planejamento do 
Todo
Tudo no final do 
projeto
Método Iterativo e 
Incremental
Planejamento do 
Todo
Parciais ao longo 
do Projeto
Métodos Ágeis
(também é 
iterativo e 
incremental)
Planejamento 
próximo de alguma 
coisa do todo, mas 
sem garantia do 
que será feito
Parciais ao longo 
do Projeto
5
Princípios Ágeis
1. Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de 
software de valor.
2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam 
a mudanças, para que o cliente possa tirar vantagens competitivas.
3. Entregar software funcionando com frequência, na escala de semanas até meses, com 
preferência aos períodos mais curtos.
4. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, 
durante todo o curso do projeto.
5. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte 
necessário, e confiar que farão seu trabalho.
6. O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de 
desenvolvimento, é através de uma conversa cara a cara.
7. Software funcional é a medida primária de progresso.
8. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e 
usuários, devem ser capazes de manter indefinidamente, passos constantes.
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 que não precisou ser feito.
11. As melhores arquiteturas, requisitos e designs emergem de times auto organizáveis.
12. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam 
seu comportamento de acordo.
Exercício Princípios Ágeis
Para cada situação abaixo, indique se a mesma está de 
acordo ou não aos Princípios Ágeis identificados na lista 
do slide anterior (informe o número do Princípio Ágil):
1. Provocar as pessoas para trabalharem horas extras 
pois o produto está atrasado
2. Equipes de trabalhos distribuídas geograficamente e 
membros de equipes trabalhando remotamente
3. A equipe decide aumentar a duração da iteração de 2 
para 4 semanas porque não estava conseguindo 
constantemente produzir os requisitos acordados.
4. O negócio precisa de uma nova funcionalidade que 
não estava acordada inicialmente no planejamento.
6
SCRUM
Scrum
Engenharia de Software
• Scrum é um processo ágil para gestão de projetos, 
comumente utilizado na comunidade de software, 
mas que também ganha força em outras áreas
• Em Scrum, o negócio define suas prioridades e a 
equipe se auto-organiza para determinar a melhor 
forma para entregar funcionalidades.
• Scrum é embasado no empirismo e utiliza uma 
abordagem iterativa e incremental para entregar 
valor com frequência e, assim, reduzir s riscos de 
projeto.
7
SCRUM
Planejamento por Iteração
Aprendizado a partir do que 
está sendo entregue
Interações inter e intra equipes 
rápidas e constantes
Framework Scrum
Framework Metodologia
Métodos Descritivos
8
Framework Scrum
3 Papéis 3 Artefatos
4 Cerimônias
Scrum
9
Scrum Master
• O Scrum Master garante que o processo do Scrum será 
seguido
• O Scrum master não é um gerente no sentido clássico. 
Ele não define as tarefas nem as prioriza.
• Possui diversos “soft skills”
– Facilitador
– Motivador
– Conciliador
– Bom ouvinte: ouve as ideias dos outros, sem interrupção e 
sem pré-julgamento
– Possui Iniciativa: vontade de fazer o que é preciso
• Remove impedimentos
Product Owner (PO)
• O PO tem papel predominante nas metodologias ágeis
• Ele que toma toda as decisões sobre o negócio (o que 
vai ser implementado, o que vai ficar de fora...)
• A escolha deste papel é muito importante para o 
sucesso da iniciativa
• Participa de Reuniões de Planejamento e Fechamento 
de cada iteração.
• Capacidade de priorização
10
Priorizando o que deve ser feito
• O Product Owner tem, entre outras atribuições, a de 
indicar quais são os requisitos mais importantes a 
serem tratados em cada sprint. 
– Análise de Pareto 20/80
Conjunto de possíveis requisitos para o projeto
Conjunto de requisitos 
que serão implantados 
pelo projeto
Novos 
requisitos 
que serão 
incorporados 
no projeto
Requisitos 
que 
deixarão o 
projeto
Time
• O Time Scrum é a equipe de desenvolvimento. 
• Essa equipe não é necessariamente dividida em papeis 
como analista, designer e programador, mas todos 
interagem para desenvolver o produto em conjunto. 
• Usualmente são recomendadas equipes de 5 a 10 
pessoas.
Engenharia de Software
11
E o Gerente de Projeto???
• O trabalho do Gerente de Projeto Tradicional é dividido 
pelos três papéis do Scrum
– Questões de Negócio: PO
– Questões Técnicas: Time
– Questões sobre o Processo: Scrum Master
Scrum – Backlog do Produto
12
1ª Etapa: Estabelecendo o 
Backlog do Produto
• As funcionalidades ou característica a 
serem implementadas ou produzidas em 
cada projeto (requisitos, casos de uso ou 
histórias de usuário) são mantidas em 
uma lista chamada de Backlog do 
Produto. 
• Cada funcionalidade é classificada 
genericamente como um item de backlog
Engenharia de Software
Topo do Backlog
Itens de 
menor 
granularidade
Engenharia de Software
• Cartões de Histórias dos Usuários
Como um <tipo_de_usuário>, eu gostaria de <funcionalidade> para 
<benefício>
Requisitos dos Usuários são definidos em 
Histórias
13
Engenharia de Software
Épico: Histórias de mais alto nível
Exercício Scrum – Parte 1
Estabelecendo o Product Backlog
2º Etapa: Estimativas
• A equipe Scrum estima 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
14
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
Exercício: Zoo Points
• Determinar os “zoo points” para os seguintes animais
Urso GirafaGorila Hipopótamo
Canguru Leão Tigre Rinoceronte
15
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
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
• Os números da sequencia ficam cada vez mais distantes 
para explicitar que quanto mais o esforço cresce, mais 
imprecisa é a estimativa
– 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
16
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
3º Etapa: Priorização das Histórias
• O cliente atribui as prioridades para as histórias.
• Em uma iteração várias histórias são implementadas.
• O principal é considerar a necessidade do negócio, mas 
alguns aspectos também podem influenciar a decisão 
de priorizar histórias para a próxima Sprint.
– Histórias que permitam lançamento de releases mais rápidos
– Histórias mais conhecidas
– Riscos e Incertezas
– Tamanho da História
– Dependência das Histórias
Exercício Scrum – Parte 2
Priorizando e Estimando
17
Scrum – Planejamento da Sprint
Planejamento da Sprint
• O Sprint é o ciclo de desenvolvimento de poucas 
semanas de duração sobre o qual se estrutura o 
Scrum.
• Normalmente tem duração de 2 a 4 semanas.
• No início de cada Sprint é feito uma reunião de 
planejamento da Sprint, no qual a equipe prioriza 
os itens de backlog de produto a serem 
implementados, e transfere estes elementos do 
backlog do produto para o backlog da Sprint, ou 
seja, a lista de funcionalidades a serem 
implementadas no ciclo que se inicia.
18
Planejamento da Sprint
• A equipe se compromete a desenvolver as tarefas, 
e o Product Owner (PO) se compromete a não 
trazer novas tarefas durante o mesmo Sprint. 
• Se novas tarefas ou requisitos forem descobertas, 
serão abordadas em sprints posteriores.
Engenharia de Software
Time Box
• “Time Box” na tradução literal significa "caixa de tempo". O 
termo é utilizado para ressaltar a importância que existe um 
tempo limitado para executar algum tipo de trabalho.
• O Time Box é aplicado as Reuniões e as Sprints.
Engenharia de Software
19
Velocidade do Time
• São a quantidade de pontos que um time consegue entregar durante 
uma Sprint
• As histórias mais prioritárias entram 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.
• Na primeira Sprint é difícil de estabelecer uma primeira velocidade do 
time
Exercício Scrum – Parte 3
Planejando a Primeira Sprint
Scrum – Execução de uma Sprint
20
Sprint Backlog – Quadro de Tarefas
Reunião Diária
• Reunião rápida que a equipe de desenvolvimento faz a cada dia 
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?
• Essas reuniões devem ser rápidas. Por isso, se sugere 
que sejam feitas com as pessoas em pé
• Os problemas relatados devem ser tratados fora da reunião!
Engenharia de Software
21
Trabalho em Pares / Pair Working
• Duas pessoas em trabalhando em conjunto 
para executar uma tarefa 
• Normalmente um pilota o computador e a 
outra acompanha e verifica o que está sendo 
feito.
• As duplas devem ser constantemente trocadas,
2004
Exercício 
Scrum 
Parte 4
Executando a 
Sprint
Revisão da Sprint / Retrospectiva da Sprint
22
Revisão da Sprint
• Na reunião de revisão da Sprint ocorre a demonstração e 
avaliação do produto desenvolvido na Sprint pelo PO.
• O PO tem a responsabilidade de aprovar ou não as histórias 
desenvolvidas.
• Será verificado o que foi feito e, a partir daí, partir para 
uma nova Sprint.
• Conta com a participação do Time, do PO, do Scrum Master 
e de qualquer outro interessado no projeto.
Engenharia de Software
Revisão da Sprint – Itens Reprovados
• Importante: 
– Se algum item for reprovado pelo PO, mesmo que parte dele 
esteja entregável, todo o item deve voltar ao Backlog de 
Produto e nenhum ponto será considerado na velocidade do 
time.
– Em uma próxima Sprint, de acordo com a necessidade do 
PO, esse item volta para o Backlog da Sprint, com a mesma 
estimativa, e aí, então, o trabalho que falta para finalizá-lo 
será realizado.
23
Revisão da Sprint – Itens Inacabados
• Se ao final da Sprint, ainda houverem itens inacabados, mesmo 
que sejam por muito pouco, a Sprint deve ser finalizada e nunca 
estendida por mais 1 ou 2 dias para que o item seja terminado.
• O conceito de Time Box deve ser respeitado.
• Esta história deve voltar para o Backlog para ser novamente 
priorizada em uma nova Sprint com o mesmo número de pontos 
estimados originalmente.
• 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
Revisão da Sprint - Realimentação
Exercício Scrum – Parte 5
Revisando a Sprint
24
Retrospectiva da Sprint
• A reunião de retrospectiva da Sprint tem como objetivo 
avaliar a equipe e os processos (impedimentos, problemas, 
dificuldades, ideias novas etc.).
• Ocorre após a revisão da Sprint, participando normalmente 
apenas o Time e o Scrum Master.
– O PO poderá ser convidado a participar da retrospectiva
• É o que permite o feedback e o ciclo de melhoria contínua 
no processo de desenvolvimento.
Engenharia de Software
Retrospectiva da Sprint – Principais Pontos
• Inspecionar como a última Sprint foi em relação as pessoas, 
relações, processos e ferramentas;
• Identificar e ordenar os principais itens que foram bem e as 
potenciais melhorias;
• Criar um plano para implementar melhorias no modo que o 
Time Scrum faz seu trabalho;
25
Happiness Board
Retrospectiva Starfish
Mais de
Começar a Fazer
Continuar a Fazer
Menos de
Parar de Fazer
26
Retrospectiva do Barco
Mais utilizada quando se quer receber o feedback do cliente
Exercício Scrum – Parte 6
Rodando a Sprint 2