Post on 24-Jul-2015
1
© 2009-2011 Rafael Sabbagh
Rafael Sabbagh
• Certified Scrum Trainer (CST), Scrum Alliance
• ScrumMaster, Scrum Coach & Scrum Trainer
• Palestrante em eventos e congressos:
Participante:
Organizador:
@rsabbagh
© 2009-2011 Rafael Sabbagh
Um pouco de
história
2
© 2009-2011 Rafael Sabbagh
Um pouco de história...
• Década de 50: a gestão de projetos é reconhecida como disciplina, nascida a
partir da administração
• Henri Fayol:
– Seu trabalho é a base para a gestão de projetos tradicional
– O gestor possui 5 funções básicas:
• Ferramentas como o gráfico de Gantt são
adotadas para listar, acompanhar e controlar a
execução das tarefas contidas em um projeto
• Até então a gestão de projetos é voltada para grandes projetos de engenharia e
construção civil
Planejar Organizar Comandar Controlar Coordenar
© 2009-2011 Rafael Sabbagh
Um pouco de história...
• Década de 60: o desenvolvimento de software começa a ganhar
complexidade
• Projetos de software: uso de medotologias tradicionais então aplicadas
a projetos de engenharia e construção civil
• Problemas começam a surgir:
– desenvolvimento de software exige mudanças frequentes
– o cliente não sabe exatamente o que ele quer até ver partes do software pronto
• Porém, Meredith & Mantel acreditam que “problemas de comunicação e
entendimento do que deve ser feito são responsáveis por falhas nos
projetos”
3
© 2009-2011 Rafael Sabbagh
Um pouco de história...
Waterfall
1970: Winston Royce publica artigo
criticando a abordagem tradicional para
desenvolvimento de software
© 2009-2011 Rafael Sabbagh
Um pouco de história...
• Waterfall segue o conceito Big Design Up Front (BDUF).
• BDUF: “revisão exaustiva da especificação pode garantir a ausência de mudanças críticas na fase de execução”
• BDUF: adequado apenas para projetos estáveis, com pouca ou nenhuma mudança
– Mudanças devem ser evitadas a todo custo.
– Se não for possível evitá-las, o gerente de projetos deve gerenciá-las.
4
© 2009-2011 Rafael Sabbagh
Um pouco de história...
© 2009-2011 Rafael Sabbagh
Um pouco de história...
• 1990: DeGrace & Stahl listam fatores que tornam questionável o uso de BDUF para projetos de software:
– Requisitos não são completamente compreendidos no início do projeto;
– Usuários só sabem exatamente o que querem após ver uma versão inicial do produto;
– Requisitos mudam durante o processo de desenvolvimento;
– Novas ferramentas e tecnologias tornam a estratégia de desenvolvimento imprevisíveis
5
© 2009-2011 Rafael Sabbagh
Fonte: Agile Project Management with Scrum, Ken Schwaber, 2004
Gráfico de Complexidade para Projetos de Software
Anarquia
Complexo
Simples
Tecnologia
Req
uis
ito
s
Próximo à Certeza
Distante da Certeza
Próximo à Concordância
Distante da Concordância
Um pouco de história...
© 2009-2011 Rafael Sabbagh
Uso de Funcionalidades pelo Cliente
Fonte: Standish Group, 2002
6
© 2009-2011 Rafael Sabbagh
Agilidade
© 2009-2011 Rafael Sabbagh
Agilidade 2001: representantes de processos
leves de desenvolvimento de software
se reuniram para discutirem sobre o que
seus processos possuíam em comum
7
© 2009-2011 Rafael Sabbagh
Os 12 Princípios Ágeis
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.
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.
© 2009-2011 Rafael Sabbagh
Os 12 Princípios Ágeis
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.
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
© 2009-2011 Rafael Sabbagh
Entrega de Valor: Agile x Waterfall
Tempo
Entr
ega d
e V
alo
r
r e l e a s e s Á g e i s
release Waterfall
0
© 2009-2011 Rafael Sabbagh
Plan Driven x Value Driven
Fixo
Estimado
Plan
Driven
Value
Driven
Requisitos
Requisitos Custo Tempo
Custo Tempo
Waterfall Agile
9
© 2009-2011 Rafael Sabbagh
O que é
Scrum
© 2009-2011 Rafael Sabbagh
Scrum...
• ...é um framework ágil simples para desenvolvimento de produtos complexos em ambientes complexos;
• ...não é um processo ou técnica: dentro de Scrum podem-se empregar diversos processos e técnicas;
• ...utiliza a abordagem iterativa e incremental para melhorar a previsibilidade e o controle de riscos;
10
© 2009-2011 Rafael Sabbagh
Scrum...
• ...torna os problemas das práticas de desenvolvimento transparentes, para que se possa melhorá-las;
• ...gera entrega frequente de valor para o cliente;
• ...utiliza inspeção e adaptação para melhoria contínua do produto e dos processos de desenvolvimento;
© 2009-2011 Rafael Sabbagh
Scrum...
• ...é orientado a valor, e não a planos
• ...utiliza times auto-organizados, que definem as melhores formas de desenvolverem as funcionalidades de maior valor
...é focado na ordenação do trabalho baseada no maior valor de negócio para o cliente;
11
© 2009-2011 Rafael Sabbagh
O que é
Scrum As Origens
do Scrum
© 2009-2011 Rafael Sabbagh
Scrum: Origens
• Ken Schwaber, início dos anos 90: desenvolvimento em sua
empresa do que se tornaria o Scrum
• Jeff Suttherland, 1993: desenvolvimento
do Scrum na Easel Corporation
• Ken Schwaber : formalização do Scrum na OOPSLA’95
• Anos seguintes: Schwaber e Sutherland
colaboram para unificar seus trabalhos
• Publicação do livro “Agile Software
Development with Scrum”, por Ken
Schwaber e Mike Beedle
12
© 2009-2011 Rafael Sabbagh
Scrum: Origens
• “The New New Product Development
Game”, de Takeuchi e Nonaka (1986)
• Equipes de desenvolvimento de
novos produtos de empresas
americanas e japonesas
• Instabilidade embutida
• Equipes auto-organizadas
• Fases sobrepostas de desenvolvimento
• Múltiplo aprendizado
• Controle sutil
• Transferência organizacional de
aprendizado
© 2009-2011 Rafael Sabbagh
Scrum: Origens
O nome Scrum vem do Rugby!
• “The New New Product Development
Game”, de Takeuchi e Nonaka (1986)
13
© 2009-2011 Rafael Sabbagh
Scrum: Origens
• Sistema Toyota de Produção
e Produção Enxuta
– Produção “puxada” pelo cliente
– Produção de valor em fluxo estável e contínuo, sem
paradas, lotes, filas ou departamentos
– Qualidade embutida no processo: jidoka
– Melhoria contínua: kaizen
– Combate ao desperdício:
• muda: etapas sem valor
• muri: sobrecarga nas pessoas e equipamentos
• mura: desbalanços nos ritmos de produção
© 2009-2011 Rafael Sabbagh
O que é
Scrum Os Pilares
do Scrum
14
© 2009-2011 Rafael Sabbagh
Processos Definidos X Processos Empíricos
• Processos definidos:
– Ambientes controlados
• ex: linhas de produção
– Mesmas entradas, mesmas saídas
• Processos empíricos:
– Complexos e imprevisíveis
– Diferentes entradas, diferentes saídas
• Scrum é embasado na
Teoria de Controle de Processos Empíricos
– Pilares: Transparência, Inspeção e Adaptação
Os Pilares do Scrum
© 2009-2011 Rafael Sabbagh
Os Pilares do Scrum
• #1: Transparência
– Ver: aspectos que afetam o
resultado do projeto devem ser
visíveis para os que gerenciam
estes resultados
O que é visto deve ser compreendido: se
quem inspeciona o processo acredita que está
pronto, isso deve corresponder à definição de
pronto utilizada
15
© 2009-2011 Rafael Sabbagh
Os Pilares do Scrum
• #2: Inspeção
– Investigar: deve haver inspeção no
processo com frequência suficiente para se
detectar variações inaceitáveis
© 2009-2011 Rafael Sabbagh
Os Pilares do Scrum
• #3: Adaptação
– Melhorar: ao se detectar variações
inaceitáveis, o processo deverá ser ajustado
o tão rápido quanto possível para se
minimizar desvios ainda maiores
16
© 2009-2011 Rafael Sabbagh
Introdução ao Scrum
© 2009-2011 Rafael Sabbagh
Time de Scrum
• Product Owner
– Garante e maximiza o ROI do cliente a partir do
trabalho do Time
• Time de Desenvolvimento (o Time)
– Gera valor para o cliente construindo incrementos do
produto com alta qualidade
• ScrumMaster
– Garante que aos valores do Scrum, práticas e regras
estão sendo compreendidos e seguidos
17
© 2009-2011 Rafael Sabbagh
Introdução
ao Scrum Resumo do
Ciclo do Scrum
© 2009-2011 Rafael Sabbagh
A VISÃO DO PRODUTO e o
PRODUCT ROADMAP
devem ser criados antes do
início do desenvolvimento
Resumo do Ciclo do Scrum
18
© 2009-2011 Rafael Sabbagh
O representante do cliente, chamado de
PRODUCT OWNER, levanta com os
stakeholders os requisitos de maior
prioridade no momento
Resumo do Ciclo do Scrum
© 2009-2011 Rafael Sabbagh
Ele então insere esses
requisitos em uma lista
ordenada, chamada
PRODUCT BACKLOG
Resumo do Ciclo do Scrum
19
© 2009-2011 Rafael Sabbagh
Resumo do Ciclo do Scrum
O Product Owner e o Time se reúnem na
SPRINT PLANNING MEETING e geram o
SPRINT BACKLOG: o que será feito e
como será feito neste ciclo de
desenvolvimento (SPRINT)
© 2009-2011 Rafael Sabbagh
O Time faz o trabalho de
desenvolvimento do incremento
do produto que foi planejado,
buscando atingir a Meta da Sprint
Resumo do Ciclo do Scrum
20
© 2009-2011 Rafael Sabbagh
Em cada dia, o Time faz a DAILY
SCRUM, uma reunião de 15 minutos para
promover visibilidade e comunicação
entre os membros do Time
Resumo do Ciclo do Scrum
O que fiz
O que farei
Quais foram os
impedimentos
© 2009-2011 Rafael Sabbagh
Ao final do ciclo de desenvolvimento,
o Time terá produzido um
incremento no produto pronto, que
significa valor para o cliente
Resumo do Ciclo do Scrum
DEFINIÇÃO
DE DONE
__ ____ ____
________ __
_____ ___ __
21
© 2009-2011 Rafael Sabbagh
O Time então se reúne com o
Product Owner e stakeholders na
SPRINT REVIEW e apresenta o
que foi feito na Sprint
Resumo do Ciclo do Scrum
© 2009-2011 Rafael Sabbagh
E, em seguida, o Time se reúne para a
SPRINT RETROSPECTIVE, onde verifica
o que funcionou bem e o que pode
melhorar nas próximas Sprints
Resumo do Ciclo do Scrum
22
© 2009-2011 Rafael Sabbagh
...e o ciclo recomeça.
Resumo do Ciclo do Scrum
© 2009-2011 Rafael Sabbagh
Papéis:
Time de Scrum
23
© 2009-2011 Rafael Sabbagh
Product Owner: Atribuições
• Gerencia o Product Backlog: garante a visibilidade, insere, remove, modifica e ordena os itens
• Gerencia os stakeholders do projeto – identifica os stakeholders e seu nível de apoio
– comunica-se com eles para entender suas necessidades
– balanceia as diferentes necessidades dos stakeholders
– influencia os stakeholders
• Gerencia a Visão do Produto: estabelece, mantém e comunica
• Gerencia os Releases do produto para o cliente
Responsável por garantir e maximizar o ROI do cliente a partir do trabalho do Time
© 2009-2011 Rafael Sabbagh
Product Owner: Atribuições
• Participa ativamente das Sprints – Disponível para o Time
– Sprint Planning / Sprint Review (e Release Planning)
• Aceita ou rejeita na Sprint Review o trabalho realizado pelo Time
• Gerencia o orçamento: garante que há orçamento suficiente para o projeto durante todo seu desenvolvimento
Responsável por garantir e maximizar o ROI do cliente a partir do trabalho do Time
24
© 2009-2011 Rafael Sabbagh
Product Owner: Características
• Único (só pode haver um!) – Não é comitê, não há substitutos
– Influenciado por outros (Time, stakeholders e até mesmo um time de negócios)
– Tem a voz final sobre o Product Backlog
• Disponível – para tirar dúvidas do Time e tomar decisões sobre o produto
– para falar com os stakeholders e atualizar o Product Backlog frequentemente
• Representativo – com suficiente poder e conhecimento necessário para tomar decisões rápidas e
corretas sobre o produto
© 2009-2011 Rafael Sabbagh
Time de Desenvolvimento: Atribuições
• Trabalha sobre o Product Backlog, em direção à visão do produto
• Entrega valor frequentemente para o cliente
• Auto-organiza-se para realizar o trabalho – com poder para gerenciar seu trabalho de desenvolvimento, responsável por
seus resultados
– comunicação: melhores Times são pequenos (7 ± 2 membros) e co-localizados
• Comunica-se frequentemente com o P.O. – dúvidas e decisões sobre o produto
• Informa os impedimentos ao ScrumMaster assim que detectados
Gera valor para o cliente construindo incrementos do produto com alta qualidade
25
© 2009-2011 Rafael Sabbagh
Time de Desenvolvimento: Características
• Multidisciplinar – todo conhecimento e habilidades necessárias para gerar o trabalho pronto
(DoD), incluindo qualidade
– os melhores Times são Feature Teams
– não há títulos no Time
– fertilização cruzada: um aprendendo do outro
• Suficientemente pequeno (7 ± 2) para garantir comunicação
• Motivado, com a confiança e apoio necessários
• Tecnicamente excelente
• Comprometido a alcançar as metas da Sprint/Release – os
melhores Times são 100% dedicados ao projeto (sem multitasking)
© 2009-2011 Rafael Sabbagh
ScrumMaster: Atribuições
• Remove os impedimentos que atrapalham o trabalho do Time
• Facilita as reuniões do Scrum
• Facilita o trabalho do Time e sua relação com o P.O.
• Ensina (ou garante que aprenda) e encoraja o Time a melhorar seu trabalho, com qualidade e produtividade, e a se auto-organizar
• Alinha as necessidades do Time e as da organização
• Ajuda a escolher e ensina o P.O. (ou garante que aprenda)
Garante que aos valores do Scrum, práticas e regras estão sendo seguidos
26
© 2009-2011 Rafael Sabbagh
ScrumMaster: Características
• Competente em soft skills: facilitador, negociador, comunicador, gerência de conflitos etc.
• Corajoso para realizar as mudanças necessárias e remover os impedimentos
• presente durante todo o trabalho do Time
• isento o suficiente para garantir que não haja desvios no processo, para facilitar o consenso, para não interferir nas decisões do Time e para ajudar o Time a melhorar seu trabalho
© 2009-2011 Rafael Sabbagh
ScrumMaster
27
© 2009-2011 Rafael Sabbagh
Product Backlog
© 2009-2011 Rafael Sabbagh
• Lista de requisitos do produto – itens com desejos
de negócios do cliente, melhorias no produto,
correções de bugs, tarefas técnicas etc.
• Meio para se alcançar a visão do produto
• Itens ordenados por prioridade de desenvolvimento
– itens do alto: < granularidade, > detalhe
– itens de baixo: > granularidade, < detalhe
• Lista incompleta e dinâmica em constante evolução
– ambiente evolui e clientes e Time aprendem sobre o
produto
O que é o Product Backlog?
28
© 2009-2011 Rafael Sabbagh
• Product Owner é o único responsável por gerenciar o
Product Backlog – atualizar, ordenar e dar visibilidade
• Seus itens possuem descrição e estimativa
• A ordenação é determinada por: valor que gerará ao
cliente, risco e necessidade
O que é o Product Backlog?
© 2009-2011 Rafael Sabbagh
O que é o Product Backlog?
29
© 2009-2011 Rafael Sabbagh
• Ordenado: itens são ordenados de acordo com a
prioridade de sua implementação – de forma a
maximizar o ROI do cliente
• Estimável: julgar e formar uma opinião sobre o
tamanho do Product Backlog ou de uma parte
relevante dele (ex. próxima Sprint ou Release)
• Emergente: incompleto, dinâmico, em constante
evolução – mudança no ambiente e no produto
• Gradualmente refinado: de acordo com a ordenação
Product Backlog é...
© 2009-2011 Rafael Sabbagh
Ordenando o Product Backlog
Sprint
Release
Futuras Releases
Desenvolvidos
mais cedo
30
© 2009-2011 Rafael Sabbagh
• Estimar ajuda o Time a conhecer sua velocidade e ser capaz de se compromenter com itens de acordo
• Estimar ajuda o Product Owner a criar o Plano de Release, baseado na velocidade do Time
• Estimar ajuda a medir o progresso em uma release usando o Release Burndown
• Estimativas feitas pelo Time!
Estimando o Product Backlog
© 2009-2011 Rafael Sabbagh
• Acurácia é mais importante que precisão!
Estimando o Product Backlog
31
© 2009-2011 Rafael Sabbagh
• Story Points
– Unidade de medida para determinar o tamanho do
item do Product Backlog (geralmente User Stories)
– Story points significam o tamanho do esforço relativo necessário para desenvolver o item
– É uma medida relativa (entre os itens)
– Fibonacci: 0, 1, 2, 3, 5, 8, 13, 21, 34... (ou, adaptado: 0, 1, 2, 3, 5, 8, 13, 20, 40...)
Estimando o Product Backlog
© 2009-2011 Rafael Sabbagh
• Uma das técnicas para realizar a estimativa do Product Backlog é o PLANNING POKER
8
• Inicialmente, o Time escolhe o item de menor esforço e atribui o tamanho de 2
• O Time escolhe um item e joga o Planning Poker para estimá-lo, tendo como base o item de tamanho 2
• O Time escolhe mais um item e joga o Planning Poker para estimá-lo, tendo como base os itens já estimados - triangulação
STORY POINTS
Estimando o Product Backlog
32
© 2009-2011 Rafael Sabbagh
Jogando o PLANNING POKER
2
13 • Para um item, todos os membros do Time
escolhem uma estimativa nas cartas – não mostrar até que todos tenham escolhido
• Todos mostram as cartas ao mesmo tempo
• Os membros com a maior e a menor estimativa devem justificar
• Jogam-se novamente as cartas, até o consenso – ScrumMaster facilita!
Estimando o Product Backlog
© 2009-2011 Rafael Sabbagh
• T-Shirt Sizing
P M G GG
Estimando o Product Backlog
33
© 2009-2011 Rafael Sabbagh
• Ao final da Sprint, o trabalho desenvolvido deve estar
pronto
• Mas o que significa “pronto”?
• O Time e o Product Owner devem definir o que significa
pronto
• Quando alguém diz que algo está pronto, todos devem
entender o que isso significa
• Ex. de software: codificado, testado e documentado
Definição de Pronto
© 2009-2011 Rafael Sabbagh
• Product Backlog necessita atenção e cuidados constantes
• Grooming é um processo que assegura que o Product
Backlog seja Ordenado, Estimável, Emergente e
Gradualmente Refinado
– pré-requisito para uma Sprint Planning bem-sucedida
• Feito colaborativamente pelo Product Owner e pelo Time (Time geralmente dedica 10% de seu tempo)
• Cada Time Scrum tem seu próprio processo de grooming:
sessões diárias curtas, sessões semanais, workshop etc.
Product Backlog Grooming
por Roman Pichler
34
© 2009-2011 Rafael Sabbagh
Passos para Grooming:
• Descobrir e descrever novos itens; modificar ou remover os
existentes
• Ordenar – alto: mais importente baixo: menos importente;
quais itens na próxima release, ordem de implementação
• Itens de alta prioridade preparados (DoR): decompostos e
refinados; claros: entendimento comum; factíveis: pequenos o
suficiente para a sprint; testáveis: podem ser validados
• Time estima novos itens e corrige os antigos por Roman Pichler
Product Backlog Grooming
© 2009-2011 Rafael Sabbagh
• Preparado = item do Product Backlog está disponível e
preparado para discussão pelo Product Owner na
Sprint Planning
• DoR descreve um estado em que os itens do Product
Backlog devem estar para estarem qualificados para
discussão na Sprint Planning
• Objetivo claro para o Time, previne “estragar” a Sprint
• O quê, Como, estimado, pequeno o suficiente
Definição de Preparado (ready, DoR)
por Jeff Sutherland / Serge Beaumont
35
© 2009-2011 Rafael Sabbagh
User Stories para itens do Product Backlog
© 2009-2011 Rafael Sabbagh
User Stories
Quem?
O quê?
Por quê?
Como um <PERFIL>, eu
posso/gostaria/devo
<FUNÇÃO> para <VALOR>
Como um COMPRADOR, eu
posso PESQUISAR LIVROS
para ESCOLHER O QUE
VOU COMPRAR
36
© 2009-2011 Rafael Sabbagh
User Stories: os três C’s
CARD
(cartão)
CONVERSATION
(conversas)
CONFIRMATION
(confirmação)
Descrição da story
suficiente para
identificar o requisito
e para lembrar do que
se trata a story Conversas sobre a
story, por onde de
fato o requisito é
comunicado do
cliente aos
programadores Testes que documentam
os detalhes da story e
podem ser usados para
determinar quando ela
está completa
© 2009-2011 Rafael Sabbagh
User Stories: INVEST
Independent
Negotiable
Valuable
Estimable
Small
Testable
Independente das
outras stories
Negociável, detalhes
serão negociados
Valiosa para o cliente
Estimável pelos
desenvolvedores
Pequena em esforço
de implementação
Testável para permitir
a confirmação
Uma
User
Story
deve
ser:
37
© 2009-2011 Rafael Sabbagh
User Stories: Stories, Temas e Epics
ÉPICO
STORY
STORY
STORY
STORY
STORY
STORY
TEMA
STORY STORY
STORY
STORY STORY
STORY STORY STORY
© 2009-2011 Rafael Sabbagh
User Stories: Testes de Aceitação
Como um usuário,eu posso
exportar dados em XML para poder
integrar minhas informações com
outros sistemas
•Abrir no Excel o arquivo XML
exportado
•Confrontar campo a campo com o
modelo estabelecido
Testes de Aceitação
•Servem para verificar que as user
stories implementadas funcionam como
o cliente pediu
•São escritos pelo cliente, antes da
codificação, com a ajuda dos
desenvolvedores
38
© 2009-2011 Rafael Sabbagh
• Reunião que inclui desenvolvedores, usuários, cliente
e qualquer pessoa que possa contribuir na
descoberta de stories
• Os participantes escrevem quantas stories
conseguirem, sem se preocupar com priorização
• Uso de brainstorming e prototipação rápida, de
baixa fidelidade
User Stories: Story-Writing Workshop
© 2009-2011 Rafael Sabbagh
• Product Owner escreve os critérios de aceitação para
cada item desejado antes da Sprint Planning
• Durante a Sprint Planning, os critérios de aceitação
são discutidos e negociados com o Time
• Enunciados pequenos e
fáceis de se entender
• Definem os limites para um item
Adaptado de um artigo de Sandy Mamoli
Critérios de Aceitação
39
© 2009-2011 Rafael Sabbagh
• Ajudam o P.O. a responder o que ele precisa para que
essa funcionalidade propicie valor
• Ajuda o Time a ganhar uma compreensão compartilhada
sobre a Story/funcionalidade
• Ajudam programadores/testers a gerar os testes
• Ajudam programadores a saber quando devem parar de
adicionar mais funcionalidades a uma story
Critérios de Aceitação
Adaptado de um artigo de Sandy Mamoli
© 2009-2011 Rafael Sabbagh
• Exemplo: “como um aluno, quero me registrar
online, para não me deslocar ou enfrentar filas”
– Os campos obrigatórios do formulário devem estar
claramente indicados
– Caso o usuário submeta o formulário sem completar
todos os campos obrigatórios, esses campos devem
ser indicados e o formulário não é submetido
– Um email de confirmação deve ser enviado após
submeter o formulário
Critérios de Aceitação
40
© 2009-2011 Rafael Sabbagh
Ciclo do Scrum
© 2009-2011 Rafael Sabbagh
Sprint Planning Meeting
41
© 2009-2011 Rafael Sabbagh
O que é a Sprint Planning Meeting?
• Planejamento da iteração: – Time e Product Owner defininem que itens do Product
Backlog serão implementados na Sprint e os quebram em tarefas – Sprint Backlog
– Reunião de 8h (Sprints de 1 mês) ou 5% da Sprint
– Product Owner presente
• 1a. Parte: O quê? – Escolha de itens mais prioritários do Product Backlog a
serem implementados
– Definição da Meta da Sprint
• 2a. Parte: Como? – Time quebra itens em tarefas e estima o tempo (quando
usado) para realização de cada tarefa
© 2009-2011 Rafael Sabbagh
O que é a Sprint Planning Meeting?
• Resultado: Sprint Backlog inicial + Meta
Itens Tarefas
a fazer
Tarefas em
andamento Feito
Meta
42
© 2009-2011 Rafael Sabbagh
• A velocidade do Time é a media de story points
entregue pelo Time nas últimas Sprints
• É usado para ajudar o Time a decidir quantos com
pontos irá cometer na Sprint sendo planejada
• É uma medida relativa a cada Time, ou seja, não
pode ser usada para comparar diferentes Times
• Quão mais constante for a formação do
Time e a duração das Sprints, melhor
funciona
Medindo a Velocidade do Time
© 2009-2011 Rafael Sabbagh
Sprint Backlog
43
© 2009-2011 Rafael Sabbagh
O que é o Sprint Backlog?
• Composto por uma lista dos itens que serão desenvolvidos durante a Sprint, as tarefas correspondentes, o andamento e as estimativas
• Os itens são selecionados do Product Backlog na Sprint Planning Meeting
• Cada item é quebrado em tarefas. Parte das tarefas é definida no Planning, parte ao longo da Sprint
© 2009-2011 Rafael Sabbagh
O que é o Sprint Backlog?
• As tarefas podem ser estimadas ou não, mas deve-se traçar o Sprint Burndown
• O Sprint Backlog é modificado ao longo da Sprint – estimativas (quando há) são atualizadas
– tarefas podem surgir para os itens já existentes
• Deve ter alta visibilidade
• Pertence ao Time
44
© 2009-2011 Rafael Sabbagh
O que é o Sprint Backlog?
© 2009-2011 Rafael Sabbagh
• A velocidade de um Time é a média de pontos
entregues pelo Time nas últimas Sprints
• Deve ser usada para ajudar o Time a decidir quantos
pontos de itens conseguirá pegar na próxima Sprint
• É relativo a cada Time, ou seja, não é possível
comparar velocidade entre times diferentes
• Funciona bem quando o Time e a duração das Sprints
se mantêm constantes
Medindo a Velocidade do Time
45
© 2009-2011 Rafael Sabbagh
Estimar as Tarefas?
Estimativa por horas
• Na segunda parte da Sprint Planning, cada membro estima as tarefas que ele irá realizar pelo número de horas que acredita que levará
• De preferência, cada tarefa é < 1 dia e > 2 horas
• Devem ser atualizadas sempre que pertinente
• O Sprint Burndown reflete o número de horas restantes totais de todas as tarefas
• Desvantagens: – Diminui o senso de propriedade de grupo
– Dificuldade no trabalho em par eventual
– Cria mais uma escala além da usada para tarefas
© 2009-2011 Rafael Sabbagh
Traçando o Sprint Burndown
Estimativa por horas
• Sprint Burndown é um gráfico que mostra a soma das horas estimadas restantes das tarefas da Sprint pelo tempo
– Y: horas estimadas restantes das tarefas
– X: dias da Sprint
• Serve para acompanhar o progresso em direção ao final de um sprint
• É feito inicialmente no Sprint Planning Meeting e deve ser atualizado a cada dia da Sprint
46
© 2009-2011 Rafael Sabbagh
Traçando o Sprint Burndown
© 2009-2011 Rafael Sabbagh
Usando os pontos dos itens
• Sprint Burndown é um gráfico que mostra a soma dos pontos estimados restantes dos itens da Sprint (a partir das tarefas realizadas e restantes) pelo tempo
– Y: pontos estimados restantes
– X: dias da Sprint
• Serve para acompanhar o progresso em direção ao final de um sprint
• É feito inicialmente no Sprint Planning Meeting e deve ser atualizado a cada dia da Sprint
Traçando o Sprint Burndown
47
© 2009-2011 Rafael Sabbagh
A Sprint
© 2009-2011 Rafael Sabbagh
• Sprint é a iteração (ciclo) de desenvolvimento – Sprint Planning Meeting
– Trabalho de Desenvolvimento
– Sprint Review
– Sprint Retrospective
• Cada Sprint deve ter uma meta
• Têm duração fixa (de 2 semanas a 1 mês) e ocorrem uma atrás da outra
• Não deve haver nenhuma mudança que afete a meta da Sprint
O que é a Sprint?
48
© 2009-2011 Rafael Sabbagh
O que é a Sprint?
• Cada Sprint deve ter como saída
um incremento entregável do
produto que satisfaça à meta
• Ao final da Sprint, todo trabalho entregável deve estar
pronto
• O deadline não pode ser mudado. Somente o escopo
pode variar (desde que não afete a meta da Sprint)
© 2009-2011 Rafael Sabbagh
O que é a Sprint?
• A Sprint deve sempre produzir valor entregável,
mesmo que haja mais trabalho de arquitetura ou
infraestrutura
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5
Iten
s q
ue
ge
ram
va
lor v
isív
el p
ara
o c
lien
te
Ite
ns
de
arq
uit
etu
ra,
infr
ae
str
utu
ra e
tc.
49
© 2009-2011 Rafael Sabbagh
• A Sprint pode ser cancelada se a Meta da Sprint perder o sentido
• Somente o Product Owner pode decidir pelo cancelamento da Sprint
• É exceção, deve ser raro
• Inicia-se imediatamente uma nova Sprint
Cancelamento da Sprint
© 2009-2011 Rafael Sabbagh
O Tamanho da Sprint
• O tamanho da Sprint é fixo! (1-4 semanas) Só pode ser alterado se for detectada a necessidade na Sprint Retrospective
• Horizonte curto suficiente para que mudanças necessárias não alterem a meta da Sprint
• Sprints curtas: mudanças muito frequentes,
entregas mais frequentes, projetos curtos
• Sprints longas: mudanças menos frequentes, overhead de reuniões
50
© 2009-2011 Rafael Sabbagh
Daily Scrum
© 2009-2011 Rafael Sabbagh
O que é a Daily Scrum?
• Reunião de 15 minutos realizada todo dia no mesmo local, à mesma hora.
– Visibilidade
– Comunicação
– Decisão rápida
• Cada membro do Time detalha:
– O que ele completou desde a última Daily Scrum;
– O que ele vai fazer antes da próxima Daily Scrum;
– Quais obstáculos estão em seu caminho.
• O ScrumMaster deve remover os obstáculos encontrados
• O Sprint Burndown deve ser atualizado!
51
© 2009-2011 Rafael Sabbagh
Sprint Review
© 2009-2011 Rafael Sabbagh
O que é a Sprint Review?
• Reunião informal onde o Time mostra aos
stakeholders o que foi feito durante a Sprint
– Reunião de 4h (Sprints de 1 mês) ou 5% da Sprint
– Product Owner presente
• Time demonstra o que fez e responde a perguntas
• PO verifica o que foi e o que não foi feito na Sprint e
estabelece se a meta foi atingida
• Entrada para a Sprint Planning seguinte
52
© 2009-2011 Rafael Sabbagh
Sprint Retrospective
© 2009-2011 Rafael Sabbagh
O que é a Sprint Retrospective?
• Reunião para inspecionar como correu a Sprint com relação aos processos: – Reunião de 3h
– Em geral, Product Owner não deve estar presente
• Identificar e priorizar:
– O que foi bem?
– O que pode melhorar?
• Identificar ações para melhorias - adaptação
53
© 2009-2011 Rafael Sabbagh
• Cinco passos:
– Preparação
– Colher dados
– Gerar insights
– Decidir o que fazer
– Fechar a retrospectiva
O que é a Sprint Retrospective?
© 2009-2011 Rafael Sabbagh
O que foi bem? O que pode melhorar? Ações de melhoria
O que é a Sprint Retrospective?
54
© 2009-2011 Rafael Sabbagh
Gestão de
Releases
© 2009-2011 Rafael Sabbagh
• É a entrega para o cliente de um incremento no produto
• Deve ser decidida pelo Product Owner, de acordo com as necessidades do cliente
• A Release só pode ser feita quando incrementos no produto suficientes tiverem sido feitos para gerar valor para o cliente
Sprint 1 Sprint 2 Sprint 3 Sprint 4
Release 1
Sprint 5 Sprint 6
Release 2…
O que é uma Release?
Sprint 7 Sprint 8
55
© 2009-2011 Rafael Sabbagh
Cenário #1
• Sem Plano de Release
• Fazer releases cedo e frequentemente
• Product Owner decide fazer a Release quando incrementos suficientes do produto criaram valor para os clientes
Gestão de Release
© 2009-2011 Rafael Sabbagh
Cenário #2 – Plano de Release
• Itens do Product Backlog devem estar estimados pelo Time e ordenados pelo Product Owner
• Para cada Release, realizar a reunião de Release Planning Meeting para criar o Plano de Release
• Fazer releases cedo e frequentemente
• Acompanhar o progresso através do Release Burndown
• Atualizar o Plano de Release a cada Sprint
Gestão de Release
56
© 2009-2011 Rafael Sabbagh
• Reunião (não obrigatória) realizada para cada release para criar o Plano de Release:
– Meta da Release: caminho para a Visão do Produto
– data da entrega
– Itens ordenados do Product Backlog que, a princípio, serão entregues nas Sprints da Release
• Não é um compromisso
• Veja que itens cabem na Release usando o número calculado de Sprints, estimativas não refinadas do Time para os itens e a velocidade do Time
• Geralmente, distribua os itens apenas pelas duas primeiras Sprints
Reunião de Release Planning
© 2009-2011 Rafael Sabbagh
Sprint 1 Sprint 2 Sprints 3-6
Plano de Release
Reunião de Release Planning
57
© 2009-2011 Rafael Sabbagh
Traçando o Release Burndown
• Release Burndown é um gráfico que mostra a soma dos pontos de esforços estimados restantes dos itens da Release pelo tempo
– Y: pontos de esforços estimados restantes
– X: iterações (Sprints)
• Serve para acompanhar o progresso em direção a uma entrega
• É feito inicialmente no Release Planning Meeting e deve ser atualizado no final de cada Sprint
© 2009-2011 Rafael Sabbagh
Traçando o Release Burndown
58
© 2009-2011 Rafael Sabbagh
Escalando
Scrum
© 2009-2011 Rafael Sabbagh
Escalando Scrum
• Problema: projeto grande demais
• Time deve ter no máximo 9 membros
?
59
© 2009-2011 Rafael Sabbagh
Escalando Scrum
• Solução: diversos Times no mesmo projeto
© 2009-2011 Rafael Sabbagh
Escalando Scrum
• Scrum of Scrums
– Mecanismo para coordenação de diversos Times
trabalhando no mesmo projeto
– Daily Scrum adicional (Daily Scrum of Scrums), formada por um membro de cada Time do mesmo projeto, visando sincronizar o trabalho de todos os Times e tratar de problemas
– Foco em dependências, integração e sobreposições de trabalho
60
© 2009-2011 Rafael Sabbagh
Escalando Scrum
• Scrum of Scrums
– Mesmo Product Backlog para todos os itens
– Funciona quando não há grandes dependências entre o trabalho dos Times
• Minimizar dependências, ortogonalizar o trabalho dos Times
– Questões:
• O que o Time fez desde a última reunião?
• O que o Time pretende fazer até a próxima reunião?
• O que está/esteve atrapalhando o Time?
• O Time gerará impedimentos para outros Times?
© 2009-2011 Rafael Sabbagh
Escalando Scrum
• Extendendo: Scrum of Scrums of Scrums
© Mountain Goat Software
61
© 2009-2011 Rafael Sabbagh
© 2009-2011 Rafael Sabbagh
Scrum Alliance
http://www.scrumalliance.org
62
© 2009-2011 Rafael Sabbagh
Scrum Alliance
Certificações da Scrum Alliance
© 2009-2011 Rafael Sabbagh
Obrigado!
Rafael Sabbagh
sabbagh@gmail.com
rsabbagh
http://rsabbagh.com
http://facebook.com/SabbaghTC