Introdução ao Scrum

 Alan Braz
 Mestre - IC-Unicamp
 Pesquisador em Eng. Software Ágil - IBM
 Email: alanbraz@gmail.com
 Twitter: @alanbraz
 Blog: alanbraz.com.br
 Este arquivo: alanbraz.com.br/ic/scrum.pdf
Chaos report

2
 Maglev Chinês (MAGnetic LEVitation)
 Projeto: contrução do primeiro
maglev para ligar o centro
empresarial de Shanghai e
imediações para o aeroporto
(30km em 8m)
 Orçamento: US$ 1.08bi
 Prazo: Jun01 – Dez03
(2 anos e 7 meses)
 Resultados técnicos: finalizado no
tempo, orçamento e escopo.
 Resultados de negócio:
inicialmente o trem rodava
praticamente vazio: ROI não foi
como esperado.

3
Titanic (filme de 1997)
 Orçamento inicial:
US$ 200 mi
 Total gasto:
US$ 400 mi
 Data de entrega:
1 ano após o previsto
 Resultado:
Ganhador de 11 Oscars
 Receita:
mais de US$ 1.8 bi

4
5
Modelo Tradicional (Cascata)
•Por que ele é tão popular?

6
Modelo Tradicional (Cascata)
•Por que ele é tão popular?
•É fácil de explicar e lembrar
•Dá a ilusão de algo ordenado, contável e
mensurável com marcos orientados à
documentos
•Foi altamente promovido e ensinado nos
cursos de Engenharia de Software

7
Características de Projetos Ágeis

8
Características de Projetos Ágeis

•Todo ano você vai

visitar seus sogros
em Salvador.
•Você tem:
• 2 filhos
adolescentes
(13 e 17)
• 1 criança de 10
anos
• 1 bebê de 2 meses

9
Características de Projetos Ágeis
• Planejar apenas o necessário
• Iterações Time-boxed
(intervalos fixos)
• Velocidade
• Rotas alternativas
• Lidar com surpresas
• Motivar o time
• Lidar com a diferença de
objetivos dos envolvidos
• Iterações repetidas e
sustentáveis
• Infraestrutura

10
O que não é Ágil
PRECISAMOS DE USE DESENVOLVIMENTO ÁGIL
ENCONTRE OUTRAS
MAIS 3 PROGRA- MÉTODOS NÃO SIGNIFICA FAZER
PALAVRAS QUE
MADORES ÁGEIS DE MAIS COISAS COM
SIGNIFIQUEM ISSO E ME
PROGRA- MENOS PESSOAS.
PERGUNTE DENOVO.
MAÇÃO

OU SEJA, NÃO HÁ MAIS

NÓS VAMOS TENTAR PLANEJAMENTO E NEM QUE BOM
ESTE FOI
USAR ALGO CHAMADO DOCUMENTAÇÃO. QUE ISSO
O SEU
DESENVOLVIMENTO APENAS COMECEM A TEM UM
TREINA-
ÁGIL. ESCREVER CÓDIGO E NOME.
MENTO.
RECLAMAR.

11
Ágil
•Inicialmente, métodos ágeis eram conhecidos como
métodos leves.
•Em 2001, membros proeminentes da comunidade se
reuniram em Snowbird e adotaram o nome métodos ágeis
Manifesto ágil - www.manifestoagil.com.br
•4 valores
•12 princípios e práticas
•Os métodos ágeis iniciais:
• Scrum (1986)
• XP (1996)
• Crystal Clear
• Feature Driven Development
• Entre outras...
The Agile Manifesto 10th Anniversary Reunion
12
 Manifesto para o desenvolvimento Ágil de software
Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e
ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar:

Indivíduos e
mais que Processos e ferramentas
interação entre eles

Software em
mais que Documentação abrangente
funcionamento

Colaboração com
mais que Negociação de contratos
o cliente

Responder a
mais que Seguir um plano
mudanças
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.
Fonte: http://manifestoagil.com.br/ 13
12 Princípios (1/3)
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.

14
12 Princípios (2/3)
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 face a face.

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.

15
12 Princípios (3/3)
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.

16
Em poucas palavras...
Usar feedback contínuo dos
envolvidos para desenvolver
código funcional com alta-
qualidade através de “Histórias de
Usuários” (user stories) em uma
série de iterações curtas e bem
delimitadas.
17
Quem são Stakeholders (envolvidos)??

•Usuários finais (quem usa)

•Financiadores (quem paga)
•Parceiros (quem ajuda)
•Time interno (quem executa)

Usar feedback contínuo dos envolvidos para desenvolver código funcional com alta-
qualidade através de “Histórias de Usuários” (user stories) em uma série de iterações curtas
e bem delimitadas.
18
Histórias de usuários?! (user stories)

Usar feedback contínuo dos envolvidos para desenvolver código funcional com alta-
qualidade através de “Histórias de Usuários” (user stories) em uma série de iterações curtas
e bem delimitadas.
19
Iterações curtas e bem delimitadas?

SW usado em Jeff Southerland (CTO)

hospitais e disse que levaram 4
consultórios para anos para chegar no
manter o histórico ponto de “pronto, pronto,
dos pacientes. pronto, pronto”.

Novo Release a cada 60 membros

3 meses Pronto, pronto, no time
Iterações de 1
semana pronto, pronto
toda semana!!!

http://www.patientkeeper.com/
Usar feedback contínuo dos envolvidos para desenvolver código funcional com alta-
qualidade através de “Histórias de Usuários” (user stories) em uma série de iterações curtas
e bem delimitadas.
20
Visão Geral
Lean
Otimizar o todo
Eliminar o desperdício

Ágil
Testes Unitários Automatizados /
TDD, Melhorias contínuas, …

Iterativo
Ágil é uma rede de práticas que se completam.
Práticas que não adicionam valor, são excluídas.

Ágil é como uma Classe Abstrata

Scrum, FDD, XP, DSDM, etc são metodologias que implementam Ágil
21
Lean Software Development
•Ágil
• Uma filosofia que se concentra na entrega de
coisas que tem valor para o cliente
• Evita tudo que não agrega valor ao cliente levou
• Não acredita no Grande Plano (Big Plan) LEAN
para
•Lean Design
• Iniciado como uma forma de gerenciamento
para linha de produção
• Elimina TODA forma de desperdício
• Envolver o cliente o mais cedo possível

22
Os princípios chave
• Eliminar Desperdício • Entrega rápida
• Mapear cadeias de valor • Teoria das Filas
• Solução Completa
• Foco no aprendizado
• Qualidade constante • Produto & Processo
• Disciplinas Fundamentais
• Validação Contínua • Respeitar as Pessoas
• Times
• Postergar Comprometimento • Parceiros
(Defer Commitment)
• Manter opções em aberto • Otimizar o todo
• Set-Based Design • Systems Thinking
• Roadmap

Leia mais em: http://pt.wikipedia.org/wiki/Lean

23
Se coloque no lugar do cliente

Controle de
Papelada interna Tempo em Espera = mudanças
Perda de $$$$

Backlog = Entregas

as
atrasadas

r
Custo

xt
.E
nc
Fu
rio
Necessá
Mínimo

Tempo
Complexidade Funcionalidades Extra elevam os
custos exponencialmente
Defeitos
24
Mito: especificar tudo no início reduz o desperdício

25
Código custa dinheiro para ser escrito e mantido

“Every line of code costs money to write and

more money to support. It is better for the
developers to be surfing than writing code
that won't be needed. If they write code that
ultimately is not used, I will be paying for
that code for the life of the system, which is
typically longer than my professional life. If
they went surfing, they would have fun, and
I would have a less expensive system and
fewer headaches to maintain.”
-- Jeff Sutherland, CTO PatientKeeper
26
 Fluxo do Processo Ágil

Pré-Concepção Concepção
Product Modelo de Arquitetura User Confirmar Release
Questionário
Backlog Negócio Alto Nível Stories Requisitos Estimate
de decisão

Planejar, Desenvolver, Qualidade

2-4
Semanas
Produto
potencialmente
Iteration Teste
entregável
Backlog

Daily
Scrum
March 2009
27
 Agile Framework

Extreme Programming SCRUM: Crystal: Dynamic Systems

(XP):
•Baseado nos valores de
simplicidade, comunicação,
feedback, coragem e respeito
•Comece com uma solução
simples e adicione
complexidade através de
“refatoração” (refactoring)
•Equipes pequenas entre 6 e 8
pessoas
•“Backlog” define os requisitos
que serão enderessados em
cada Sprint
•Reunião diária de 15min.
(Scrum) para discutir o trabalho
do dia
Unified Process:
•Versão simplificada do Rational
Unified Process – redução no
número de disciplinas
•Entregas frequêntes
•Melhorias reflectivas
(Reflective improvement)
Adaptive:
•Repetição dos ciclos de
Especular, Colaborar e
Aprender
•Aprendizagem contínua e
adaptações para alterar o
estado do projeto
Development Method
(DSDM):
•3 fases primárias: Pré-Projeto,
Ciclo de vida do Projeto, Pós-
Projeto
Feature Driven Dev.:
•Listar funcionalidades
•Planejamento, Design,
Construção por
Funcionalidade

Técnicas ágeis: os métodos acima envolvem diferentes técnicas, entre elas:

Test-driven development Continuous integration Static Analysis

Planning game Design improvement Coding standard
Pair Programming Small releases Sustainable pace
Refactoring Simple design Whole team
28
Scrum

Image owned by Teivovo, Fiji Rugby, 2007

29
Origem do Scrum

30
 Origem do Scrum

http://www.infoq.com/presentations/The-Roots-of-Scrum
31
The New New Product Development Game

32
Rugby?!

33
Scrum
• Foi criado também nos anos 80 e 90, primeiramente em
círculos de desenvolvimento OO como uma metodologia
altamente iterativa de desenvolvimento.

• Os colaboradores mais conhecidos são Ken Schwaber, Jeff

Sutherland, e Mike Beedle

• Concentra mais os aspectos da gerência de desenvolvimento

de software, dividindo o desenvolvimento em iterações de 2 a 4
semanas (chamadas “sprints”) e aplicando uma monitoração
mais próxima e um controle baseado em reuniões diárias

• Coloca muito menos ênfase em práticas de engenharia e

muitos combinam suas práticas de gerência de projeto com
as práticas de XP
34
Resumindo
 Processo empírico de gerenciamento e
controle
 Inspeção e adaptação em loops de feedback
 Usado para gerenciar projetos desde 1990
 Entrega frequente de funcionalidades com
valor para o cliente
 Escalável a projetos distribuídos, grandes e
largos
 Compatível com CMMI Nível 3 e ISO9001
 Extremamente simples, mas resistente
35
Pilares
 Tranparência
 qualquer tipo de informação pertinente ao negócio,
tecnologia, ou andamento do projeto deve estar visível
 Inspeção
 monitorar o progresso dos artefatos para detectar
possíveis variações
 frequência não deve ser alta a ponto de burocratizar o
fluxo de trabalho
 Adaptação
 detectado desvios inaceitáveis, ajustes devem ser feitos
para se retomar o fluxo planejado
36
Scrum framework
Nota: se tornou a
metodologia Ágil mais
utilizada pelo mercado

Sprint = Iteração

37
Personagens

38
39
 Scrum
Entradas dos Executivos, Gráfico
Equipe, Clientes, Usuários Burndown2
e outros Envolvidos
Scrum
Scrum Diário3
Master1
Cada
24 horas

Sprint
2-4
Dono do Produto1 Equipe de
Semanas Revisão do Sprint3
(Product Owner) Desenvolvimento1
Time seleciona
as de maior Tarefas
Hitórias de prioridade que
Usuários podem se
ou comprometer a Data de Entrega e Backlog do
Casos de entregar no final Backlog do Sprint não sofrem alterações Incremento Pronto2
Uso do Sprint Sprint2 após o início do Sprint
Reunião de
Planejamento
Backlog do
do Sprint3
Produto2
Lista ordenada Retrospectiva
dos requisistos 1
Papel, 2Artefato, 3Evento do Sprint3
40
Papel dos Personagens
 Define os requisitos, datas e conteúdo das releases
 Responsável pelo ROI do produto
 Responsável pela manutenção e priorização do Backlog
 Aceita ou rejeita os resultados das Sprints

 Garante que o time está funcional e produzindo

 Remove os impedimentos e promove a comunicação
 Protege time de interferências externas
 Garante que todos os envolvidos estão aplicando as práticas Scrum
 Participa das reuniões diárias, revisão e planejamento

 Configuração multi-funcional
 Equipe de 5 a 10 participantes
 Seleciona os itens prioritários para o sprint backlog
 Tem o direito de fazer o que for preciso, dentro dos limites do projeto, para atingir os
objetivos comprometidos
 Participa das reuniões diárias, revisão e planejamento

41
Artefatos

42
 Reuniões
Planejamento da Iteração Daily Scrum Revisão da Iteração
Coordenada pelo ScrumMaster Coordenada pelo ScrumMaster Coordenada pelo ScrumMaster
Todos participam (Porcos e Frangos) O time participa (frangos são opcionais) Todos participam (Porcos e Frangos)
Entradas: Product backlog, produto atual, Mesmo lugar e horário, todos os dias, Informal, 4 horas, informativa
condições técnicas e de negócio 15 mins max
Time demonstra o incremento
1. Seleciona-se os itens de maior Responder
prioridade do Backlog; declara-se o Todos discutem
1. O que você fez ontem?
Objetivo da Iteração Considera-se candidatos à componentes
2. O que vai fazer hoje?
2.Time transformas os itens selecionados Realiza-se a reflexão
3. Tem algum impedimento?
no Iteration Backlog
Time atualiza o Iteration Backlog Anuncia-se a próxima reunião de
Saída: Objetivo da Iteração, Iteration planejamento
Backlog Scrum Master atualiza Blocks List
 Reflexão
 Perguntar a
cada iteração:
Não se passa status o que devemos…
para o ScrumMaster
1. PARAR ?
Mas se compromete
com seus colegas 2. COMEÇAR ?
3. CONTINUAR ?

43
Scrum Development Process
•Começa quando:
•A fase de Concepção
está concluída

•As histórias de alta

prioridade estão
quebradas ao ponto de
serem possíveis de
implementar em uma
iteração

44
Done, done, done, done!

45
Você está Pronto, Pronto, Pronto, Pronto?
Tom “Oi, Frank! – Você já terminou aquela funcionalidade nova?”
“Humm um segundo ……
Frank
Pronto. E eu só levei meio dia para terminar”
TOM “Wow, impressionante! Nós estimamos que levaria no mínimo 1 dia,
Gerente de Projetos Tom
2 provavelmente. Posso dar uma olhada??”
Frank “Bem, ainda não. Eu não integrei o novo código ainda.”
“OK – Mas quando você tiver feito isso, eu poderei dar uma olhada
certo? Estou ansioso para mostrar aos clientes. Eles nos contrataram
Tom especialmente por causa desta funcionalidade. Eu vou instalar a nova
build no ambiente de testes deles assim eles podem dar uma
brincada.”
“Bem, eu não mostraria isso a ninguém. Eu não testei ainda e você
Frank não conseguirá instalar em lugar algum. Eu não atualizei o instalador
e nem os scripts de atualização do banco de dados.”
FRANK
Desenvolvedor “Não estou entendendo. Pensei ter ouvido você dizer que estava
Tom
pronto!”
“E esta! ….Eu terminei de codificar no exato momento que você ligou.
Frank
Veja, eu vou te mostrar.”
“Não, não, eu não quero ver código... Eu preciso ter a capacidade
Tom de mostrar isso pro cliente. Eu preciso dela terminada,
realmente terminada!”
“Ahhh bom, por que você não disse logo? O código está pronto,
Frank mas não está pronto, pronto, pronto, pronto! Me dê mais alguns
dias que eu finalizo isso.”
46
Dívida Técnico (Technical Debit)

B u g B a c k lo g
Time

Iterative Waterfall

Dívida Técnico é uma

metáfora para nos ajudar
a pensar sobre o
problema de empurrar
código não terminado de
uma iteração para a
próxima.

Copyright 1996-2007, ADM, All Rights Reserved v8.0

47
 Scrum
Entradas dos Executivos, Gráfico
Equipe, Clientes, Usuários Burndown2
e outros Envolvidos
Scrum
Scrum Diário3
Master1
Cada
24 horas

Sprint
2-4
Dono do Produto1 Equipe de
Semanas Revisão do Sprint3
(Product Owner) Desenvolvimento1
Time seleciona
as de maior Tarefas
Hitórias de prioridade que
Usuários podem se
ou comprometer a Data de Entrega e Backlog do
Casos de entregar no final Backlog do Sprint não sofrem alterações Incremento Pronto2
Uso do Sprint Sprint2 após o início do Sprint
Reunião de
Planejamento
Backlog do
do Sprint3
Produto2
Lista ordenada Retrospectiva
dos requisistos 1
Papel, 2Artefato, 3Evento do Sprint3
48
49
Product Backlog
•O Backlog do Produto é um repositório das
Histórias de Usuários que estão prontas
para ser implementadas em uma iteração

User Story

Product Backlog

50
User Stories
•Uma User Story descreve uma
funcionalidade que tem alguma utilidade
para um stakeholder do sistema.

•User Stories são compostas por:

•Uma breve descrição
•Conversação sobre a história
•Testes de aceitação e
alguns detalhes
51
User Story – os 3 Cs

52
User Stories:
Cartão: Descrição breve

Como um <Papel>, eu quero <Objetivo> para

que eu <valor de negócio>.
• Com um DBA do Wal*Mart, eu quero reduzir o consumo de
armazenamento para que eu gerencie um menor número de
dispositivos.

• Como um administrador, eu quero que provar que apenas os

clientes pré-cadastrados possam usar um determinado
serviço para que eu possa controlar a segurança dos
dados.

53
User Stories: Conversação
•Atenção: é aqui que o real valor da
história aparecerá

•Inclua o máximo de pessoas possíveis.

•Garanta que representantes de todas as
disciplinas estejam presentes:
desenvolvedores, analistas, testes,
gerentes de projetos, arquitetos, DBAs, etc

54
User Stories: Confirmação
•As condições de satisfação do Product Owner devem
ser adicionadas na história.
•Devem ser facilmente testadas e de resultado binário Sim ou
Não.
•Vão determinar se a história foi concluída com sucesso.
•Não existe parcialmente finalizado ou terminado mas...

Com um DBA do Wal*Mart, •Taxa de compressão > 50%

eu quero reduzir o consumo
de armazenamento para •Compressão de todos os tipos
que eu gerencie um menor de tabelas
número de dispositivos. •Compressão online

Lembre-se: isso não é uma história interna do time

55
Quebrando histórias em outras menores
Como um usuário gold, eu quero poder
cancelar uma reserva no último
minuto sem pagamento de multa para
que eu não seja penalizado por uma
viagem não mais necessária.

Como um usuário, eu Como um usuário cadastrado, eu

quero poder cancelar
uma reserva, para que
eu não seja
penalizado com multa
em uma viagem não
mais necessária.
quero poder cancelar uma reserva
com 24h de antecedência para que
eu não seja penalizado por uma
viagem não mais necessária.
Como um visitante, eu
quero receber a
confirmação de
qualquer cancelamento
para que eu possa
guardar um
comprovante
56
O que faz uma boa história?

•Independente
•Negociável
•Com Valor
•Estimável
•Tamanho apropriado
•Testável
57
User Stories em tarefas
•Durante o planejamento da iteração as
histórias devem ser quebradas em tarefas

• Tarefa #1 (X horas) Máximo de 16

User Story
• Tarefa #2 (Y horas) horas ideais por
tarefa
• Tarefa #3 (Z horas)

58
Product Backlog é do Product Owner
•Lista a histórias a serem implementadas
• Priorizadas de Alta para Baixa
• Utiliza conhecimento técnico para ajudar na priorização
• Esta sempre uma iteração à frente dos desenvolvedores
•Foca no top 20%, apesar que deve ser revista
inteiramente de tempos em tempos
•Itens de baixa prioridade devem ser
consolidados
•Itens de muito baixa prioridade devem
ser descartados
• Se for importante, elas voltam naturalmente

59
Aprender a priorizar - MoSCoW

•M – MUST HAVE
• Highest priority

•S – SHOULD HAVE
• Desirable to have

•C – COULD HAVE
• Nice-to-have

•W – WON’T HAVE
• Out of scope for this release

60
Priorizar de 1 a N

61
Resumindo
•O Product backlog é a lista de trabalho a
ser implementado
•Pertence e é priorizado pelo Product
Owner
•Priorização na forma MoSCoW seguindo
ordem numérica

62
Por que os planos dão errado?
Assume-se que tarefas
são independentes

Atrasos impactam o cronograma,

adiantamentos não

A síndrome do estudante

Multi-tarefas está implícito

e é necessário

6363
1. Assumimos que as tarefas são
independentes

Muitas tarefas tem dependências entre si.
•Estimativas erradas geram uma cadeia de
atrasos em outras tarefas

Conforme temos mais conhecimento
sobre os requisitos, voltamos e
atualizamos nossas estimativas

Estimativas de Software não seguem
uma distribuição normal

6464
2. Atrasos impactam o cronograma

 Tarefa 3 inicia:
ATRASADO se 1, 2 ou 4 estiver atrasada
ANTES apenas se 2 e 4 terminar antes e tiver recurso
disponível

6565
3. Síndrome do Estudante

Definição

Iniciar uma tarefa no
último momento
possível que não
prejudicará a data de
entrega 
Exemplo:

Começar a fazer o
trabalho da pós na
sexta à noite :D

6666
O que ocorre?

Fonte: http://www.heptagon.com.br/5dgp-3 6767

6868
4. Multitasking – Multi-tarefas
 Multi-tarefas causam atrasos

 Ao invés de multi-tarefar, use unidades de trabalho menores

Deixar o fluxo de trabalho acontecer o mais rápido possível
Transferências mais eficientes para outra pessoa

6969
O efeito das multi-tarefas

7070
A cebola do planejamento

7171
Planejando o Produto, as releases, e as
iterações

7272
Medidas

7373
Story Points

É a “grandeza” de uma tarefa

Influenciada por
•Quão difícil ela é
•O quanto dela já temos

Valores são relativos
•Tela de login é 2
•Funcionalidade de busca é 8

Isentos de unidade

7474
Tempo Ideal

Quanto tempo demoraria se...
•Você trabalhasse exclusivamente nisto
•Não houvessem interrupções
•E tudo que você precisa estiver disponível

O Tempo Ideal de uma partida de
Basquete é 48 minutos
•12 minutos por quarto

Mas o tempo corrido é muito maior
•Normalmente 3 horas
7575
3 níveis de planejamento...

7676
...com 3 níveis de precisão
Story Horas
Points Ideais

Comprometimento
diário

7777
Estimar por analogia

•Comparando uma User Story com

outras
•“Esta história é parecida com aquela
outra, então suas estimativas serão
as mesmas.”
•Não use um único padrão
•Usar Triangulação
•Comparar a história a ser estimada
com todas as outras, já estimadas,
três a três 7878
Triangulação

•Confirmar as estimativas comparando com

múltiplas histórias
•Agrupar histórias parecidas em uma tabela ou
quadro
13

7979
Desagregações

•Quebrar um história grande em menores

•Como saber se uma história está pequena o
suficiente?
•É mais fácil de estimar coisas menores

•Mas quebrar muito pode gerar problemas

•Histórias se perdem no caminho
(muitas histórias para gerenciar)

8080
Investigar quanto esforço?

•Um pouco de esforço ajuda muito

•Muito esforço apenas ajuda um
pouco mais Precisão

Esforço

8181
Usar as unidades corretas

•Conseguimos distinguir 1 story point de um 2?

•Conseguimos distinguir um 17 de um 18?
•Use unidade que façam sentido, como:
• 1, 2, 3, 5, 8, 13 - Fibonacci Incluir o 0
e ½ se
• 1, 2, 4, 8, 16, 32 - potência de 2 desejar

•Se a história cabe em uma iteração ela “pesa” de 1

a 13
•Maiores que uma iteração: 20, 40, 100 or ∞
•Preciso de mais informações: ?

8282
Planning Poker

• Processo Iterativos de Estimativas

• Passos:
1. Cada estimador tem um conjunto de
cartas, cada carta tem um valor de
estimativa válido
2. Cliente/Product Owner lê a História e
ocorre uma breve discussão
3. Cada estimador seleciona uma carta que
será a sua estimativa particular
4. Todos viram as cartas ao mesmo tempo
5. Estimadores com valores no extremos
(mais baixo e mais alto) apresentam
brevemente seus pontos de vista
6. Repete-se os passos até convergir a um
único valor
8383
Quadro de Tarefas

8484
Kanban

8585
http://taskboard.agilar.org

8686
kunagi.org
Burndown charts

•Método primário de monitorar o progresso

•Um Burndown chart mostra o quanto de
trabalho falta ser realizado
•Dois tipos
•Release burndown
•Sprint burndown

Lembre-se: Iteration = Sprint

8888
Iteration/Sprint burndown chart

8989
Apenas o que falta para trabalhar

Nota: no máximo 16 horas ideias por tarefa

9090
Quando o projeto será entregue?

4 lições:
1. Mostra progresso
2. Levanta questões, e não
as responde
Story Points

3. Antecipa discussões
4. Impossibilita a mentira

Iteration = Sprint
9191
Resumindo

•Velocidade e burndown charts são pontos

cruciais para monitorar as releases e
iterações

•Monitorar iterações com um quadro de

tarefas (real ou virtual)

•Manter a monitoração simples e acessível

ao time, para que cada um possa fazer as
atualizações
9292
 Scrum
Entradas dos Executivos, Gráfico
Equipe, Clientes, Usuários Burndown2
e outros Envolvidos
Scrum
Scrum Diário3
Master1
Cada
24 horas

Sprint
2-4
Dono do Produto1 Equipe de
Semanas Revisão do Sprint3
(Product Owner) Desenvolvimento1
Time seleciona
as de maior Tarefas
Hitórias de prioridade que
Usuários podem se
ou comprometer a Data de Entrega e Backlog do
Casos de entregar no final Backlog do Sprint não sofrem alterações Incremento Pronto2
Uso do Sprint Sprint2 após o início do Sprint
Reunião de
Planejamento
Backlog do
do Sprint3
Produto2
Lista ordenada Retrospectiva
dos requisistos 1
Papel, 2Artefato, 3Evento do Sprint3
93
Referências
 Takeuchi, Hirotaka; Nonaka, Ikujiro.
"The New New Product Development Game". Harvard Business
Review. 1986
 Ken Schwaber and Mike Beedle. Agile Software Development with
Scrum. Prentice Hall, Upper Saddle River, New Jersey, 2002.
 Ken Schwaber. SCRUM Development Process. OOPSLA’95
Workshop on Business Object Design and Implementation, 1995.
 Mary Poppendieck and Tom Poppendieck. Lean Software
Development: An Agile Toolkit. Addison-Wesley, 2003.
 Agile Manifesto – http://agilemanifesto.org/iso/ptbr/
 Scrum Guide - versão de 2011 em português
 Video: Scrum Master in Under 10 Minutes
 NEW Scrum Master in Under 10 Minutes video
94
Referências
 Scrum from the Trenches – livro com
exemplo de implantação de Scrum (
Português – Inglês)
 Coletânea de Papers acadêmicos de Jeff Sutherl
 State of Agile Development Survey Results
 Disciplined Agile Delivery
 Ferramenta para gerenciamento usando
Scrum – Rational Team Concert,
grátis para 10 usuários no jazz.net 95