Scrum e XP direto das Trincheiras - Como nós fazemos Scrum

FREE ONLINE EDITION
(non-printable free online version)

Trazido para você como

Cortesia de

Este livro é distribuído gratuitamente no portal
InfoQ.com. Se você recebeu este livro de
qualquer outra fonte, por favor, suporte o autor e
o editor cadastrando-se em InfoQ.com.

Visite a página deste livro em:
http://infoq.com/br/minibooks/scrum-xp-from-
the-trenches

Scrum e XP direto das
Trincheiras

Como fazemos Scrum

Escrito Por:
Henrik Kniberg

© 2007 C4Media Inc
All rights reserved.

C4Media, Publisher of InfoQ.com.

Este livro é parte da série InfoQ de livros sobre Desenvolvimento
de Software Corporativo.

Para informações sobre compra desse ou outros livros InfoQ, entre
em contato com books@c4media.com.

Nenhuma parte dessa publicação pode ser reproduzida, gravada
em um sistema de busca e recuperação de dados ou transmitida
sob qualquer forma ou por quaisquer meios, eletrônicos,
mecânicos, fotocopiado, gravado, escaneado ou qualquer outro,
sem prévia permissão do Publicador, exceto se autorizado pelas
Seções 107 ou 108 da Lei de Copyright dos Estados Unidos de
1976.

Designações usadas por companhias para distinguir seus produtos
são frequentemente conhecidas como marcas registradas. Em
todos os locais onde a C4Media Inc. tem conhecimento desse fato,
os nomes dos produtos aparecem com a letra inicial Maiúscula ou
TODAS AS LETRAS MAIÚSCULAS. Os leitores, entretanto,
devem contactar as respectivas empresas para informações mais
completas sobre suas marcas registradas.

Editor: Diana Plesa / Felipe Rodrigues

Tradutores: Vários voluntários gerenciados pela SEA Tecnologia

Dados de Publicação-em-Catálogo da Biblioteca do Congresso
Norte-Americano:

ISBN: 978-1-4303-2264-1

Dedicatória
O primeiro rascunho desse livro demorou apenas um final de semana para
ser digitado, mas com certeza foi um final de semana intenso! Fator de
foco de 150% :o)

Obrigado à minha esposa Sophia e aos meus filhos Dave e Jenny por
agüentar minha falta de sociabilidade naquele fim de semana. E obrigado
também aos pais de Sophia, Eva e Jörgen por virem ajudar a tomar conta
da família.

Obrigado também aos meus colegas da Crisp, em Estocolmo, e às pessoas
do grupo de discussão do yahoo scrumdevelopment por revisarem e me
ajudarem a melhorar este trabalho.

E, finalmente, obrigado a todos os leitores que forneceram um canal
constante de feedback bastante útil. Eu estou particularmente satisfeito
por ouvir que esse trabalho tem impactado tantos de vocês a ponto de
darem uma chance ao desenvolvimento ágil de software.

Conteúdo

3

PREFÁCIO POR JEFF SUTHERLAND I

PREFÁCIO POR MIKE COHN III

PREFÁCIO – EI, SCRUM FUNCIONOU! V

INTRODUÇÃO 6
Termo de Responsabilidade 7
Porque eu escrevi isso 7
Mas o que é Scrum? 8

COMO FAZEMOS PRODUCT BACKLOGS 9
Campos adicionais da estória 11

COMO NÓS MANTEMOS O PRODUCT BACKLOG A NÍVEL DE
NEGÓCIO 12

COMO NOS PREPARAMOS PARA O PLANEJAMENTO DO
SPRINT 13

COMO PLANEJAMOS SPRINT 15

POR QUE O PRODUCT OWNER DEVE PARTICIPAR 15

POR QUE QUALIDADE NÃO É NEGOCIÁVEL 17
Reuniões de planejamento do sprint que se arrastam sem fim 18
Agenda da reunião de planejamento do sprint 19
Definindo o tamanho do sprint 20
Definindo o objetivo do sprint 21
Decidindo quais estórias incluir no sprint 22
Como o product owner afeta quais estórias estarão neste Sprint? 23
Como a equipe decide que estórias incluir no sprint? 25
Definição de “pronto” 33
Estimativa de tempo usando planning poker 34
Esclarecendo Estórias 36
Quebrando estórias em estórias menores 37
Dividindo estórias em tarefas 38
Definindo a hora e lugar da reunião diária 39

Onde traçar a linha 39
Estórias técnicas 40
Sistema de acompanhamento de bugs vs. product backlog 43
A reunião de planejamento do sprint está finalmente terminada! 44

COMO COMUNICAMOS SPRINTS 45

COMO FAZEMOS OS SPRINT BACKLOGS 46
Formato do sprint backlog 46
Como funciona o quadro de tarefas 48
Exemplo 1 – depois da primeira reunião diária 48
Exemplo 2 – poucos dias depois 49
Como funciona o gráfico de burndown 50
Sinais de alarme do quadro de tarefas 51
Ei, e a rastreabilidade?! 52
Estimando dias vs horas 52

COMO ARRUMAMOS A SALA DA EQUIPE 53
O canto do design 53
Sente a equipe junta! 54
Mantenha o product owner por perto 55
Mantenha os gerentes e coaches por perto 55

COMO FAZEMOS AS REUNIÕES DIÁRIAS 57
Como atualizamos o quadro de tarefas 57
Lidando com atrasados 58
Lidando com o “não sei o que fazer hoje” 58

COMO FAZEMOS APRESENTAÇÕES DE SPRINT 61
Por que insistimos que todos os sprints terminem com uma apresentação 61
Checklist para as apresentações de sprint 62
Lidando com coisas “não demonstráveis” 62

COMO FAZEMOS RETROSPECTIVAS DE SPRINTS 64
Por que insistimos que todas as equipes façam retrospectivas 64
Como organizamos retrospectivas 64
Divulgando lições aprendidas entre equipes 66
Mudar ou não mudar 67
Exemplos de coisas que podem aparecer durante as retrospectivas 67

INTERVALO ENTRE SPRINTS 70

COMO FAZEMOS O PLANEJAMENTO DE RELEASE E
CONTRATOS COM PREÇO FIXO 72
Defina seus critérios de aceitação 72

Faça estimativas de tempo para os itens mais importantes 73
Estime velocidade 75
Junte tudo num plano de release 76
Adaptação do plano de release 77

COMO COMBINAMOS SCRUM E XP 78
Programação em par 78
Desenvolvimento Orientado a Testes (TDD) 79
Design incremental 82
Integração contínua 82
Propriedade coletiva do código 83
Ambiente de trabalho informativo 83
Padrão de codificação 83
Ritmo Sustentável / Trabalho energizado 84
Como fazemos testes 86
Você provavelmente não vai conseguir eliminar a fase dos testes de aceitação86
Minimize a fase de testes de aceitação 87
Aumente a qualidade colocando os testadores na equipe Scrum 87
Aumentar a qualidade fazendo menos por Sprint 90
O teste de aceitação deveria fazer parte do sprint? 90
Ciclos de sprint vs. ciclos de testes de aceitação 91
Não exponha o elo mais fraco de sua corrente 95
De volta à realidade 96

COMO LIDAMOS COM VÁRIAS EQUIPES 97
Quantas equipes criar 97
Sincronizar sprints – ou não? 100
Por que criamos o papel de “Líder de Equipe” 101
Como alocamos pessoas às equipes 102
Equipes especializadas – ou não? 104
Reorganizar as equipes entre os sprints – ou não? 106
Membros de equipe em tempo parcial 107
Como fazemos Scrum-de-Scrums 108
Intercalando as reuniões diárias 110
Equipes de bombeiros 111
Dividir o product backlog – ou não? 113
Fazendo Branching de código 117
Retrospectivas com várias equipes 118

COMO LIDAMOS COM EQUIPES DISTRIBUÍDAS
GEOGRAFICAMENTE 121
Equipes em outro país 122
Membros da equipe trabalhando em casa. 124

CHECKLIST DO SCRUM MASTER 125
Começando o sprint 125
Todo dia 125
Fim do Sprint 126

ÚLTIMAS PALAVRAS 127
Leituras recomendadas 128
Sobre o autor 130
Sobre a Tradução 131

Prefácio por Jeff Sutherland
As equipes precisam conhecer o básico do Scrum. Como você cria e
estima um product backlog? Como você o transforma num sprint
backlog? Como você gerencia um gráfico burndown e calcula a
velocidade de sua equipe? O livro do Henrik é um kit para iniciantes com
práticas básicas que ajudam equipes a irem além de apenas tentativas de
praticar o Scrum para executá-lo bem.

Uma boa execução do Scrum está se tornando mais importante para as
equipes que buscam investimento de fundos externos. Como um mentor
Ágil para um grupo de capital de risco, eu os ajudo a investirem em
empresas que executam as práticas Ágeis com eficiência. O Parceiro
Sênior do grupo tem perguntado a todas as empresas do portfólio se elas
conhecem a velocidade de suas equipes. Elas têm dificuldade em
responder a essa questão de imediato. Oportunidades futuras de
investimento irão exigir que as equipes de desenvolvimento saibam sua
velocidade de produção.

Por que isso é tão importante? Se as equipes não conhecem sua própria
velocidade, o product owner não pode criar um guia de produto com datas
de releases com credibilidade. E sem datas de release interdependentes, a
empresa poderá falhar e os investidores poderão perder seu dinheiro!

Esse problema é enfrentado por companhias grandes e pequenas, novas ou
antigas, com investimento próprio ou externo. Numa discussão recente
sobre a implantação do Scrum no Google, numa conferência em Londres,
eu perguntei às 135 pessoas presentes quantos deles estavam praticando
Scrum, e 30 responderam positivamente. Então eu perguntei se eles
estavam fazendo o desenvolvimento iterativo usando os padrões da Nokia.
Desenvolvimento iterativo é fundamental no Manifesto Ágil – entregue
software funcionando cedo e com freqüência. Depois de anos de
retrospectivas com centenas de equipes de Scrum, a Nokia desenvolveu
alguns requisitos básicos para o desenvolvimento iterativo:
• As iterações devem ter um tempo fixo com menos de seis
semanas de duração.
• Ao final da iteração, o código deve ser testado pelo CQ e
funcionar corretamente.

Das 30 pessoas que responderam estar usando o Scrum, apenas metade
disse que estava atendendo o primeiro princípio do Manifesto Ágil pelos
padrões da Nokia. Então eu perguntei se eles atendiam aos padrões da
Nokia para o Scrum:

ii | SCRUM E XP DIRETO DAS TRINCHEIRAS
• Uma equipe de Scrum deve ter um product owner e saber quem
ele é.
• O product owner deve ter um product backlog com estimativas
criadas pela equipe.
• A equipe deve ter um gráfico burndown e saber sua velocidade.
• Não deve haver nenhuma interferência externa sobre a equipe
durante um sprint.

Das 30 pessoas praticantes do Scrum, apenas 3 atendiam o teste da Nokia
para identificar uma equipe de Scrum. Essas seriam as únicas que
receberiam futuros investimentos dos meus parceiros.

O valor do livro do Henrik é que se você seguir as práticas que ele
recomenda, você terá um product backlog, estimativas para o product
backlog, um gráfico burndown, e saberá a velocidade de sua equipe, além
de outras práticas fundamentais para um Scrum altamente funcional. Você
passará no teste da Nokia e estará apto a receber investimento no seu
trabalho. Se você for uma empresa iniciante, poderia até receber
investimento de um grupo de capital de risco. Você pode ser o futuro do
desenvolvimento de software e o criador da próxima geração dos produtos
líderes de mercado.

Jeff Sutherland,
Ph.D., Co-Criador do Scrum

Prefácio por Mike Cohn

Ambos Scrum e Extreme Programming (XP) pregam que a equipe
complete alguma parte palpável de trabalho que seja entregável ao fim de
cada iteração. Essas iterações são pensadas para serem curtas e com
espaço de tempo definido. Este foco em entregas de código funcionando
em um curto espaço de tempo significa que equipes Scrum e XP não têm
tempo para teorias. Eles não perseguem o desenho do diagrama UML
perfeito em ferramentas case, a escrita do documento de requsitos
perfeito, ou a escrita do código que poderá acomodar todas as mudanças
futuras imagináveis. Ao invés disso, equipes Scrum e XP focam em ter as
coisas prontas. Essas equipes aceitam que cometem erros ao longo do
caminho, mas também compreendem que o melhor modo de identificar
esses erros é parar de pensar sobre o software em um nível teórico de
análise e design e mergulhar fundo, sujar as mãos e começar a construir o
produto.
É esse mesmo foco em fazer ao invés de teorizar que distingue esse livro.
E aparentemente Henrik Kniberg entende isso direito, desde o princípio.
Ele não oferece uma longa descrição sobre o que é Scrum; ele nos remete
a alguns sites simples para isso. Ao invés disso, Henrik dá um salto e
começa imediatamente descrevendo como suas equipes gerenciam e
trabalham com seu product backlog. Daí, ele parte para todos os outros
elementos e práticas de um projeto ágil bem executado. Sem teorias, sem
referências. Sem notas de rodapé. Nada disso é necessário. O livro de
Henrik não é uma explanação filosófica sobre por que Scrum funciona ou
por que você poderia querer experimentá-lo. É uma descrição de como
uma boa equipe ágil funciona.
Eis o porquê do subtítulo do livro, “Como fazemos Scrum”, ser tão
apropriado. Pode não ser o modo como você faz Scrum, mas é o modo
como as equipes do Henrik fazem Scrum. Você pode perguntar por que
deveria se importar com a forma como outra equipe faz Scrum. Você
deveria se importar porque todos podemos aprender como fazer melhor
Scrum ouvindo histórias de como foi feito por outros, especialmente
aqueles que estão fazendo direito. Não existe, e nunca existirá uma lista
de “melhores práticas em Scrum”, porque o contexto dos projetos e
equipes descarta todas as outras considerações. Ao invés de melhores
práticas, o que precisamos conhecer são boas práticas e o contexto onde
foram bem sucedidas. Leia histórias suficientes de equipes bem sucedidas
e como elas fizeram as coisas e você estará preparado para os obstáculos
que se apresentarem a você e ao seu uso de Scrum e XP.

iv | SCRUM E XP DIRETO DAS TRINCHEIRAS
Henrik provê as boas práticas e o contexto necessário para nos ajudar a
aprender melhor como fazer Scrum e XP, nas trincheiras dos seus
projetos.

Mike Cohn
Autor de Agile Estimating and Planning e User Stories Applied for
Agile Software Development.

Prefácio – Ei, Scrum funcionou!
Scrum funcionou! Pelo menos para nós (me refiro ao meu cliente atual em
Stockholm, cujo nome não pretendo mencionar aqui). Espero que ele
funcione pra você também. Talvez esse livro te ajude ao longo do
caminho.

Esta é a primeira vez que vi uma metodologia de desenvolvimento
(desculpe Ken, um framework) funcionar diretamente de um livro. Plug ‘n
Play. Todos estamos felizes com isso – desenvolvedores, testadores,
gerentes. Nos ajudou a sair de situações difíceis e nos permitiu manter o
foco e momentum, apesar das severas turbulências de mercado e reduções
de pessoal.

Eu não deveria dizer que estava surpreso, mas estava. Após digerir
inicialmente alguns livros sobre Scrum, me parecia bom, mas quase tão
bom para ser verdade (e todos nós conhecemos o ditado “quando alguma
coisa parece muito boa para ser verdade...”). Então eu estava
justificadamente um pouco cético. Mas após fazer Scrum por um ano,
estou suficientemente impressionado (e a maioria das pessoas nas minhas
equipes também) que continuarei a usar Scrum como padrão em novos
projetos sempre que não haja uma forte razão para não usá-lo.

1
Introdução
Você está para começar a utilizar Scrum em sua empresa. Ou talvez você
esteja usando Scrum há alguns meses. Conhece os princípios, leu alguns
livros, ou talvez até já tenha feito a certificação de scrum master.
Parabéns!

Mas ainda se sente confuso.

Como disse Ken Schwaber, Scrum não é uma metodologia, é um
framework. O que significa que Scrum não vai te dizer exatamente o que
fazer.

A boa notícia é que vou te dizer exatamente como faço Scrum, em um
nível de detalhes excruciantemente doloroso. A má noticia é, bem, esta é a
maneira como EU faço Scrum. E isto não significa que Você deva fazê-lo
exatamente da mesma maneira. De fato, eu também faria de maneira
diferente, se encontrasse situações diferentes.

O melhor e o pior do Scrum é que você é forçado a adaptar o processo
para sua situação especifica.

Minha abordagem atual para o Scrum é o resultado de um ano de
experiências numa equipe de desenvolvimento de aproximadamente 40
pessoas. A empresa estava em uma situação difícil com tarefas levando
mais tempo que o previsto, problemas de qualidade severos, constantes
incêndios, deadlines estourados, etc. A empresa decidiu utilizar Scrum
mas não completou a implantação, o que foi como minha tarefa. Para a
maioria das pessoas na equipe de desenvolvimento naquela época, Scrum
era uma buzzword que escutavam de vez em quando nos corredores, mas
que não tinha nenhuma implicação para o trabalho diário.

Após um ano, implementamos Scrum em todas as camadas da empresa,
tentamos diferentes tamanhos de equipes (3-12 pessoas), diferentes
tamanhos de sprint (2-6 semanas), diferentes formas de definir “pronto”,
diferentes formatos para os product backlog e de sprint backlogs (Excel,
Jira, cartões), diferentes estratégias de testes, diferentes formas de realizar

apresentações de sprint, diferentes formas de sincronização de múltiplas
equipes Scrum, etc. Também fizemos experimentos com práticas de XP –
diferentes formas de realizar a build contínua, programação em pares,
desenvolvimento orientado a testes, etc, e como combiná-los com Scrum.

Este é um processo de aprendizado contínuo, de modo que a estória não
termina aqui. Estou convencido que esta empresa continuará aprendendo
(se continuarem a realizar as retrospectivas dos sprints) e terem novos
insights sobre como melhor implementar Scrum em seus contextos
particulares.

Termo de Responsabilidade
Este documento não assume representar a “forma correta” de usar Scrum!
Ele apenas representa uma forma de usar Scrum, o resultado da melhoria
contínua ao longo de um ano. Você pode até mesmo decidir que nós
entendemos tudo errado.

Tudo o que há neste documento reflete minhas próprias opiniões pessoais
e subjetivas e não é de forma alguma uma declaração oficial da Crisp ou
do meu cliente atual. Por esta razão eu intencionalmente evitei mencionar
quaisquer produtos ou pessoas específicas.

Porque eu escrevi isso
Quando estava aprendendo Scrum, li os livros relevantes sobre Scrum e
agile, acessei muitos sites e fóruns sobre Scrum, fiz a certificação do Ken
Schwaber, perturbei-o com perguntas e passei muito tempo conversando
com meus colegas. Uma das mais valiosas fontes de informação,
entretanto, foram as histórias de guerra. As histórias de guerra
transformam princípios e práticas em... bem... Como você realmente faz
isso. Elas também me ajudaram a identificar (e algumas vezes evitar)
erros comuns de iniciantes em Scrum.

Logo, essa é minha chance de devolver algo. Aqui está minha história de
guerra.

Eu espero que este documento provoque algum retorno útil daqueles que
estejam na mesma situação. Por favor, me iluminem!

Mas o que é Scrum?
Oh, me desculpe. Você é completamente novo no Scrum ou XP? Neste
caso talvez você queira dar uma olhada nos seguintes links:

8 | SCRUM E XP DIRETO DAS TRINCHEIRAS
• http://agilemanifesto.org/
• http://www.mountaingoatsoftware.com/scrum
• http://www.xprogramming.com/xpmag/whatisxp.htm

Se você é impaciente demais para fazer isso, sinta-se livre para continuar
lendo. Muito do jargão do Scrum é explicado conforme avançamos, logo
ainda assim você poderá achar isso interessante.

2
Como fazemos product backlogs
O product backlog é o coração do Scrum. É aqui que tudo começa. O
product backlog é basicamente uma lista de requisitos, estórias, Coisas
que o cliente deseja, descritas utilizando a terminologia do cliente.

Nós as chamamos de estórias, ou algumas vezes apenas de itens do
backlog.

Nossas estórias incluem os seguintes campos:
ID – Uma identificação única, apenas um número com auto-
incremento. Isso é para evitar que percamos o controle sobre as
estórias quando nós mudamos seus nomes.
Nome – Um nome curto e descritivo para a estória. Por exemplo,
“Ver o histórico de transações”. Suficientemente claro para que
os desenvolvedores e o product owner entendam mais ou menos
sobre o que estamos falando, e claro o bastante para distingui-la
das demais estórias. Normalmente de 2 a 10 palavras.
Importância – a pontuação de importância dessa estória para o
product owner. Por exemplo 10. Ou 150. Mais pontos = mais
importante.
o Eu tento evitar o termo “prioridade” já que prioridade 1 é
tipicamente interpretado como “prioridade mais alta”, o
que fica feio se mais tarde você decidir que algo é ainda
mais importante. Qual pontuação de prioridade esse item
deveria receber? Prioridade 0? Prioridade -1?
Estimativa inicial – As estimativas iniciais da equipe sobre
quanto tempo é necessário para implementar aquela estória, se
comparada a outras estórias. A unidade é pontos por estória e
geralmente corresponde mais ou menos a “relação homem/dias”
ideal.
1. Pergunte à equipe “se vocês puderem ter o número
ideal de pessoas para esta estória (nem muitas, nem
poucas, normalmnte duas), e se trancarem em uma
sala cheia de comida e trabalharem sem distúrbio

algum, após quantos dias vocês apresentarão uma
implementação pronta, demonstrável e testada? Se a
resposta for “com 3 pessoas trancados em uma sala
levará aproximadamente 4 dias” então a estimativa
inicial é de 12 pontos por estória.
2. O importante não é ter estimativas absolutamente
precisas (por exemplo, dizer que uma estória com 2
pontos deverá gastar 2 dias), mas sim obter
estimativas relativas corretas (por exemplo, dizer
que uma estória com 2 pontos gastará cerca da
metade de uma estória com 4 pontos).
Como demonstrar – Uma descrição em alto nível de como a
estória será demonstrada na apresentação do sprint. Isso é
simplesmente uma simples especificação de teste. “Faça isso,
então faça aquilo e então isso deverá acontecer.”
o Se você pratica TDD (desenvolvimento orientado a
testes) essa descrição pode ser usada como pseudo-
código para o seu código de teste de aceitação.
Notas – quaisquer outras informações, esclarecimentos,
referências a outras fontes de informação, etc. Normalmente ágil
bem breve.

PRODUCT BACKLOG (exemplo)
ID Nome Imp Est Como demonstrar Notas
1 Depósito 30 5 Logar-se, abrir a Precisa de uma
página de depósito, diagrama
depositar R$ 10,00, UML de
ir para a página do sequência. Não
meu saldo e é necessário se
verificar que este preocupar com
aumentou em R$ criptografia
10,00. por enquanto.
2 Verificar 10 8 Logar-se, clicar em Usar
seu próprio “transações”. Fazer paginação para
histórico de um depósito. Voltar evitar
transações para transações, consultas
verificar se o novo muito grandes
depósito é listado. ao banco de
dados. Projetar
de forma
similar à
página de
visualização de
usuários.

Nós experimentamos com muitos outros campos, mas ao final do dia os
seis campos acima eram os únicos realmente utilizados sprint após sprint.

Nós normalmente fazemos isso em um documento do Excel com
compartilhamento habilitado (isso é, múltiplos usuários podem editá-lo
simultaneamente). Oficialmente o product owner é o dono do documento,
mas nós não queremos deixar os outros usuários de fora. Várias vezes um
desenvolvedor desejará abrir o documento para esclarecer algo ou alterar
uma estimativa.

Pela mesma razão, nós não mantemos este documento no repositório de
controle de versões, nós o colocamos em um drive compartilhado na rede.
Essa é a forma mais simples de permitir múltiplos editores simultâneos
sem causar conflitos de lock ou merge.

Quase todos os outros artefatos, entretanto, são colocados no repositório
de controle de versões.

Campos adicionais da estória
Algumas vezes nós usamos campos adicionais no product backlog,
principalmente como conveniência para ajudar o product owner na hora
de decidir as priorizações.
Track (Tilha/Rastro) – uma categorização básica dessa estória,
por exemplo, “back office” ou “otimização”. Dessa forma, o
product owner pode facilmente filtrar por todos os itens de
“otimização” e definir sua prioridade para baixa, etc.
Componentes – Geralmente são incluídos campos na forma de
“checkboxes” em um documento no Excel, por exemplo “base de
dados, servidor, cliente”. Aqui a equipe ou o product owner
podem identificar quais componentes técnicos estão envolvidos
na implementação dessa história. Isto é útil quando se tem várias
equipes de Scrum, como por exemplo uma equipe de back office
e outra de cliente, assim facilitando a decisão de cada equipe na
escolha das estórias.
Solicitante – o product owner pode querer manter o rastro de
qual cliente ou o stakeholder que solicitou o item, para poder
fornecer um feedback sobre o progresso desse item.
ID do bug – se houver um sistema separado para registro de
erros (bug tracking), como nós fazemos com o Jira, é útil manter
a rastreabilidade da estória com um ou mais erros reportados
sobre ela.

Como nós mantemos o product backlog
a nível de negócio
Se o product owner tem uma formação técnica, ele pode adicionar estórias
como “Adicionar índice na tabela de eventos”. Por que ele quer algo
assim? O verdadeiro objetivo implícito é provavelmente algo como
“acelerar o formulário de pesquisa de eventos no back office”.

Pode ocorrer que os índices não sejam os gargalos que causam a lentidão
no formulário. Pode ser algo completamente diferente. A equipe é
normalmente melhor adaptada para descobrir como resolver algo, assim o
product owner deveria focar-se nos objetivos de negócio.

Quando vejo estórias com orientação técnica como essa, normalmente eu
pergunto ao product owner uma série de questões de “mas por quê”, até
encontrar o objetivo subjacente. Então nós reformulamos a estória nos
termos do objetivo subjacente (“acelerar o formulário de pesquisa de
eventos no back office”). A descrição técnica original acaba virando uma
nota (“Indexar a tabela de eventos poderia resolver isso”).

3
Como nos preparamos para o
planejamento do sprint
Está bem, o dia de planejamento do sprint está chegando rápido. Uma
lição que aprendemos sempre é:

Lição: Tenha certeza de que o product backlog está organizado e fechado
antes da reunião de planejamento do sprint.

E o que isso significa? Que todas as estórias estão perfeitamente bem
definidas? Que todas as estimativas estão corretas? Que todas as
prioridades devem permanecer fixas? Não, não e não! O que isso significa
é:
O product backlog deveria existir! (já pensou nisso?)
Deveria haver apenas um product backlog e apenas um product
owner (por produto).
Todos os itens importantes deveriam ter uma escala de
importância associada a eles. Cada um com a sua escala diferente
da dos outros.
o Na verdade, não há problema se todos os itens de pouca
importância tiverem a mesma escala, já que eles não
serão o foco da reunião de planejamento.
o Qualquer estória que o product owner acredite ter a mais
remota possibilidade de ser incluída no próximo sprint,
deve ter uma escala única de importância.
o O nível de importância só é usado para classificar os
itens por importância. Assim, se o item A tem
importância de 20 e o item B 100, significa apenas que B
é mais importante que A. Não significa que B é cinco
vezes mais importante do que A. Se B tivesse com a
escala 21, significaria a mesma coisa!
o É útil deixar espaços vazios entre as numerações para
poder inserir novos itens. Supondo que o item C seja
descoberto como mais importante do que A, mas menos
importante do que B, ele poderia ganhar a escala 30, ao


invés de 20,5. Assim, deixe os espaços. É bem mais
prático.
O product owner deveria entender cada estória (normalmente ele
é o autor, mas em alguns casos outras pessoas adicionam
requisitos, mas o product owner ainda precisa priorizá-los). Ele
não precisa conhecer exatamente o que é necessário para
implementar, mas ele deveria entender o porquê dessa estória
estar ali.

Nota: Outras pessoas além do product owner podem adicionar estórias ao
product backlog. Mas elas não podem associar uma escala de importância.
Esse é um papel exclusivo do product owner. Eles também não podem
estimar prazos. Essa é uma tarefa exclusiva da equipe.

A seguir, outras abordagens que nós tentamos ou avaliamos:
Usar Jira (nosso sistema de bug tracking) para hospedar o
product backlog. A maioria de nossos product owners acharam
que era preciso dar muitos cliques para realizar as tarefas. Excel é
bom e fácil de manusear. Você pode usar cores facilmente,
reordenar os itens, adicionar novas colunas quando necessário,
adicionar notas, importar e exportar dados, etc.
Usar uma ferramenta de suporte a processos ágeis, como
VersionOne, ScrumWorks, XPlanner, etc. Ainda não testamos
nenhuma delas, mas provavelmente faremos isso no futuro.

4
Como planejamos sprint
O planejamento de sprint é uma reunião crítica, provavelmente o evento
mais importante no Scrum (na minha opinião, claro). Um encontro de
planejamento de sprint mal feito pode bagunçar totalmente um sprint.

O propósito da reunião de planejamento do sprint é dar à equipe
informação suficiente para trabalharem em paz por algumas semanas, e
para dar ao product owner confiança suficiente para deixá-los fazerem
isto.

OK, isto foi confuso. O resultado concreto do encontro de planejamento
de sprint é:
Um objetivo de sprint.
Uma lista de membros da equipe (e seus níveis de
comprometimento, se não 100%).
Um sprint backlog (= uma lista de estórias inclusas no sprint).
Uma data definida para a apresentação do sprint.
Data e local definidos para a reunião diária.

Por que o product owner deve participar
Às vezes, os product owners relutam em despender horas com a equipe
fazendo planejamento do sprint. “Pessoal, eu já listei o que eu quero. Eu
não tenho tempo para estar na sua reunião de planejamento”. Isto é um
problema muito grave.

A razão pela qual toda equipe e o product owner devam estar na reunião
de planejamento do sprint é porque cada estória contém três variáveis que
são muito dependentes umas das outras.


Escopo e importância são definidos pelo product owner. Estimativa é
definida pela equipe. Durante uma reunião de planejamento do sprint,
estas três variáveis são refinadas continuamente por diálogo cara-a-cara
entre equipe e product owner.

Normalmente, o product owner inicia a reunião resumindo seu objetivo
para o sprint e as estórias mais importantes. Em seguida, a equipe toma a
frente e estima o tempo de cada estória, começando pela mais importante.
Ao fazer isto, eles vão se deparar com questões de escopo importantes –
“esta estória ‘apagar usuário’ inclui passar por cada transação pendente
para o usuário e cancelar cada uma?” Em alguns casos, as respostas serão
surpreendentes para a equipe, fazendo com que eles mudem suas
estimativas.

Em alguns casos, a estimativa de tempo para uma estória não será aquela
que o product owner esperava. Isto poderá fazê-lo mudar a importância da
estória. Ou mudar o escopo da estória, que por sua vez fará a equipe re-
estimar, etc., etc.

Este tipo de colaboração direta é fundamental para o Scrum e, de fato,
todo o desenvolvimento ágil de software.

E se o product owner ainda insistir que ele não tem tempo para tomar
parte das reuniões de planejamento do sprint? Eu normalmente tento uma
das estratégias, na seguinte ordem:

Tento ajudar o product owner a entender por que a sua
participação direta é crucial e espero que ele mude de idéia.
Tento fazer com que alguém da equipe se voluntarize a ser o
intermediador do product owner. Diga ao product owner “Como
você não pode participar de nossa reunião, nós deixaremos Jeff
representá-lo como um intermediador. Ele terá plenos poderes
para mudar as prioridades e escopo das estórias na sua ausência
durante a reunião. Eu sugiro que você sincronize com ele o
máximo possível antes da reunião. Se você não quiser que Jeff
seja o seu intermediador, por favor sugira alguma outra pessoa,

COMO PLANEJAMOS SPRINT | 17

que possa se juntar a nós durante toda a duração da reunião.”
Tente convencer a equipe de gerenciamento a designar um novo
product owner.
Adie o lançamento do sprint até que o product owner ache tempo
para se juntar à reunião. Enquanto isto, se recuse a entregar
qualquer coisa. Deixe a equipe passar cada dia fazendo aquilo
que sentir ser mais importante para o dia.

Por que qualidade não é negociável
No triângulo acima, eu intencionamente evitei a quarta variável
qualidade.

Eu tento distinguir entre qualidade interna e qualidade externa:

Qualidade externa é o que é percebido pelos usuários do sistema.
Uma interface de usuário lenta e não intuitiva é um exemplo de
baixa qualidade externa.
Qualidade interna refere-se a questões que normalmente não são
visíveis ao usuário, mas que têm profundos efeitos na
manutenibilidade do sistema. Coisas como consistência do
projeto do sistema, cobertura dos testes, facilidade de leitura do
código, refactoring etc.

No geral, um sistema com alta qualidade interna pode ainda ter uma baixa
qualidade externa. Entretanto, um sistema com baixa qualidade interna
raramente terá uma qualidade externa alta. É difícil construir algo legal a
partir de fundações podres.

Eu trato qualidade externa como parte do escopo. Em alguns casos pode
fazer perfeito sentido, negocialmente, lançar uma versão do sistema que
tenha uma interface deselegante e lenta, e lançar uma versão melhorada
posteriormente. Eu deixo o dilema para o product owner, uma vez que ele
é responsável por determinar o escopo.
Qualidade interna, porém, não está em discussão. É responsabilidade da
equipe manter a qualidade do sistema sob todas as circunstâncias e isso
simplesmente não é negociável. Nunca.

(Bem, OK, quase nunca)


Então, como mostramos a diferença entre problemas de qualidade interna
e problemas de qualidade externa?

Digamos que o product owner diga “OK pessoal, eu respeito sua
estimativa de tempo de seis pontos de estória, mas eu tenho certeza de que
vocês podem fazer algum tipo de quebra-galho para isso na metade do
tempo se vocês se concentrarem nisso.”

A-ha! Ele está tentando usar qualidade interna como uma variável. Como
eu sei? Porque ele quer que nós reduzamos a estimativa da estória sem
“pagar o preço” de reduzir o escopo.. A palavra “quebra-galho” deve
ativar um alarme na sua cabeça...

E por que nós não permitimos isso?

Minha experiência é que sacrificar qualidade interna é quase sempre uma
idéia muito, muito ruim. O tempo economizado é largamente superado
pelo custo, tanto em curto quanto em longo prazo. Uma vez que se
permita que uma base de código se deteriore, é muito difícil recuperar a
qualidade mais tarde.

Ao invés disso, eu tento levar a discussão para o escopo. “Já que
conseguir essa feature mais cedo é importante para você, podemos reduzir
o escopo de modo que seja mais rápido implementá-la. Talvez possamos
simplificar o tratamento de erros e fazer 'Tratamentos de erros avançados'
numa estória separada, que reservamos para o futuro. Ou podemos reduzir
a prioridade das outras estórias, de modo que possamos focar nessa. Que
tal?”

Uma vez que o product owner tenha aprendido que qualidade interna não
é negociável, ele geralmente se especializa em manipuar as outras
variáveis.

Reuniões de planejamento do sprint que se
arrastam sem fim
O mais difícil em reuniões de planejamento de sprint é o fato de:
1) As pessoas pensarem que elas não irão demorar tanto…
2) ... mas elas demoram!

Tudo no Scrum é delimitado pelo tempo. Eu amo essa regra, simples e
consistente. Tentamos nos ater a ela.


Então, o que devemos fazer quando o prazo estipulado para a reunião de
planejamento do sprint está prestes a se esgotar e ainda não temos nem
sinal de um objetivo do ou de um sprint backlog? Interrompemos a
reunião?? Ou melhor estendermos a discussão por mais uma hora? Ou
suspendemos temporiamente e continuamos no dia seguinte?

Isso acontece várias vezes, especialmente em equipes novatas no
framework. Então, o que você faz? Eu não sei. Mas o que podemos fazer?
Bem, geralmente eu interrompo a reunião abruptamente. Finalizo-a. Deixa
o sprint sofrer as consequências. Mais especificamente, eu digo à equipe e
ao product owner: “então, esta reunião terminará em 10 minutos. Nós não
temos ainda o planejamento do sprint. Vamos trabalhar com o que temos
ou vamos agendar outra reunião de 4 horas para amanhã, a partir das 8
horas da manhã?”. Adivinha o que irão escolher… :o)

Já tentei deixar a reunião rolar solta, extrapolando o prazo previsto.
Geralmente, não resolve nada, pois as pessoas já estão cansadas. Se a
equipe não conseguiu produzir um planejamento decente para o sprint em
2 ou 8 horas (ou seja lá qual for a duração escolhida para sua reunião),
provavelmente 1 hora a mais não irá resolver em nada o problema. A
proposta de agendar uma nova reunião para o dia seguinte, seria bem
razoável, se não fosse o fato de as pessoas geralmente já estarem
impacientes para iniciar logo o sprint e não quererem perder mais tempo
com horas de planejamento.

Por isso, minha decisão é de interromper mesmo a reunião. Deixa o sprint
sofrer com isso. O lado bom disso é que a equipe aprende uma boa lição,
e a próxima reunião de planejamento do sprint será bem mais eficiente.
Além disso, as pessoas serão menos resistentes quando você propor um
prazo para a reunião que outrora teria sido considerado muito longo.

Aprenda a respeitar a delimitação do tempo e aprenda a defini-la de forma
realística. Isso se aplica tanto para prazos de reuniões quanto para prazos
de sprints.

Agenda da reunião de planejamento do sprint
Possuir algum tipo de cronograma para a reunião de planejamento do
sprint reduzirá o risco de ultrapassar o espaço de tempo previsto.

Eis um exemplo de um cronograma típico.


Reunião de planejamento do sprint: 13:00 – 17:00 (10 minutos de
intervalo a cada hora)

• 13:00 – 13:30. O product owner repassa o objetivo do sprint e
sumariza o product backlog. Definir lugar, data e hora da
demonstração.
• 13:30 – 15:00. A equipe estima o tempo e quebra os itens
conforme necessário. O product owner atualiza as taxas de
importância conforme necessário. Os itens são esclarecidos.
“Como demonstrar” é preenchido para todos os itens de maior
importância.
• 15:00 – 16:00. A equipe escolhe as estórias a serem incluídas no
sprint. Calculam a velocidade para verificar se o planejamento
ficou realista.
• 16:00 – 17:00. Escolher data e lugar para a reunião diária (se não
forem os mesmo do último sprint). Complementar a quebra de
estórias em tarefas.

Esse cronograma não precisa, de forma alguma, ser seguido à risca. O
scrum master pode aumentar ou diminuir os tempos conforme necessário,
ao longo da reunião.

Definindo o tamanho do sprint
Uma das saídas da reunião de planejamento do sprint é uma data definida
para a apresentação. Isso significa que vocês precisam definir o tamanho
do sprint.

Então, qual seria um bom tamanho de sprint?

Bem, sprints curtos são bons. Eles permitem que a equipe seja “ágil”, isto
é, mude de direção freqüentemente. Sprints curtos = ciclo curto de
feedback = entregas mais freqüentes = feedback mais freqüente do cliente
= menos tempo perdido, indo na direção errada = aprender e melhorar
rápido, etc.

Entretanto, sprints longos são bons também. A equipe tem mais tempo
para ganhar ritmo, ela tem mais espaço para se recuperar dos problemas, e
conseguir atingir o objetivo do sprint, você tem menos overhead em
termos de reuniões de planejamento, apresentações, etc.

No geral, product owners gostam de sprints curtos e desenvolvedores
preferem os longos. Então o tamanho do sprint representa um


compromisso. Nós experimentamos bastante isso, e chegamos ao nosso
tamanho favorito: 3 semanas. A maioria das nossas equipes (mas não
todas) faz sprints de 3 semanas. Curtas o bastante para nos dar agilidade
corporativa adequada, longas o bastante para a equipe conseguir fluidez e
se recuperar de eventuais problemas durante o sprint.

Uma coisa que concluímos foi: faça experimentos com o tamanho do
sprint, no início. Não perca muito tempo analisando, apenas escolha um
tamanho decente, e dê-lhe uma chance por um sprint ou dois, então mude
o tamanho.

No entanto, uma vez que vocês decidiram o tamanho que mais gostam,
mantenham ele por um bom tempo. Depois de alguns meses de
experimentação, nós achamos que 3 semanas estava bom. Então nós
fazemos sprints de 3 semanas, ponto. Algumas vezes parecerá um pouco
longo demais, outras vezes parecerá um pouco curto demais. Mas,
mantendo o mesmo tamanho, isso se torna como um batimento cardíaco
corporativo, com que todos se identificam confortavelmente. Não há
discussão quanto às datas de entregas ou coisas do tipo, porque todos
sabem que a cada três semanas haverá uma entrega, ponto.

Definindo o objetivo do sprint
Acontece quase toda vez. Em algum momento durante o planejamento do
sprint, eu pergunto “então, qual é o objetivo deste sprint?” e todo mundo
fica parado me olhando e o product owner franze a sobrancelha e coça o
queixo.

Por algum motivo é difícil definir um objetivo para o sprint. Mas ainda
sim eu percebi que compensa se esforçar para espremer um. Melhor um
objetivo meia-boca do que nenhum objetivo. O objetivo poderia ser
“ganhar mais dinheiro” ou “completar as 3 estórias mais importantes” ou
“impressionar o CEO” ou “tornar o sistema bom o suficiente para
distribuir uma versão beta” ou “adicionar funcionalidades básicas de
retaguarda” ou qualquer coisa. O importante é que seja em termos de
negócio, não termos técnicos. Isto quer dizer, em termos que as pessoas
de fora da equipe possam entender.

O objetivo do sprint deve responder a pergunta fundamental “Por que nós
estamos fazendo este sprint? Porque não saímos de férias ao invés de
fazê-lo?”. De fato, uma maneira de extrair o objetivo de um sprint do
product owner é literalmente fazer esta pergunta.


O objetivo deve ser algo que já não tenha sido atingido. “Impressionar o
CEO” pode ser um objetivo ótimo, mas não se ele já está impressionado
com o sistema atualmente. Neste caso, todos poderiam ir embora para a
casa que mesmo assim o objetivo seria atingido.

O objetivo do sprint pode parecer bobo e artificial durante o planejamento
do sprint, mas freqüentemente se torna útil no meio dele, que é quando as
pessoas começam a ficar confusas sobre o que elas deveriam estar
fazendo. Se você tem várias equipes Scrum (como nós temos) trabalhando
em produtos diferentes, é muito útil poder listar os objetivos de todas as
equipes em uma única página wiki (ou o que seja) e colocá-la em um local
evidente para que todos na companhia (não somente a gerência) saibam o
que a empresa está fazendo – e por quê!

Decidindo quais estórias incluir no sprint
Uma das principais atividades da reunião de planejamento do sprint é
decidir quais estórias incluir no sprint. Mais especificamente, quais
estórias do product backlog copiar para o sprint backlog.

Observe a figura acima. Cada retângulo representa uma estória, ordenado
pela importância. A estória mais importante está no topo da lista. O
tamanho de cada retângulo representa o tamanho daquela estória (ou seja,
o tempo estimado nos pontos de estória). A altura do braço azul
representa a velocidade estimada da equipe, ou seja, quantos pontos de
estória a equipe acredita poder completar durante o próximo sprint.


O sprint backlog da direita é um snapshot das estórias do product
backlog. Ele representa a lista de estórias que a equipe executará para o
sprint.

A equipe decide como as muitas estórias serão incluídas no sprint. Não o
product owner ou qualquer outra pessoa.

Isso levanta duas questões:
1. Como fazer a equipe decidir quais estórias incluir no sprint?
2. Como pode o product owner afetar a decisão dela?

Eu começarei com a segunda questão.

Como o product owner afeta quais estórias
estarão neste Sprint?
Digamos que nós tenhamos a seguinte situação durante uma reunião de
planejamento de sprint.

O product owner está desapontado com o fato de que a estória D não será
incluída no sprint. Quais são as suas opções durante a reunião de
planejamento do sprint?

Uma opção é reordenar a priorização. Se ele der à estória D a maior
prioridade, a equipe será obrigada a adicioná-la ao sprint (neste caso
tirando a estória C).


Uma segunda opção é mudar o escopo – reduzir o escopo da estória A até
que a equipe acredite que a estória D caberá no sprint.

Uma terceira opção é dividir uma estória. O product owner pode decidir
que existem aspectos na estória A que não são realmente importantes,
então ele divide a estória A em A1 e A2 separando-as em prioridades
diferentes.

Como vê, mesmo que o product owner não possa alterar a velocidade
estimada, há várias formas como este pode influenciar quais estórias
estarão presentes num sprint.


Como a equipe decide que estórias incluir no
sprint?
Utilizamos duas técnicas para isso:
1. No sentimento/instinto
2. Cálculo da Velocidade

Estimativa usando o sentimento ou instinto
Scrum master: “Olá pessoal, podemos terminar a estória A neste
Sprint? (apontando para o item mais importante no backlog de
produtos)
Lisa: “Dã. Claro que podemos. Temos 3 semanas, e é uma
funcionalidade bastante trivial”
Scrum master: “OK, e se incluirmos a estória B também?
(apontando para o Segundo item mais importante)
Tom & Lisa em uníssono: “Continua fácil”
Scrum master: “OK, e que tal as estórias A, B e C?
Sam (ao cliente): “a estória C inclui os tratamentos avançados de
erros?
Cliente: “não, podemos ignorar por enquanto, somente
implemente o tratamento de erros básicos”
Sam: “então C pode entrar também?
Scrum master: “OK, e se incluirmos a estoria D?
Lisa: “Hmm....”
Tom: “acredito que podemos fazê-lo”
Scrum master: “90% certo? 50%?”
Lisa & Tom: “Mais pra 90%”.
Scrum master: “OK, então D entra também. Que acham de
incluirmos a estória E?
Sam: “Talvez.”
Scrum master: “90%? 50%?”
Sam: “Perto de 50%”.
Lisa: “Estou na dúvida.”
Scrum master: “OK, então vai ficar de fora. Nos
comprometemos com A, B, C e D. Se pudermos, terminaremos E
também, mas ninguém poderá contar com isso, assim deixaremos
fora do plano do sprint. Que acham disso?
Todos: “OK!”

O sentimento ou instinto funciona muito bem para pequenas equipes e
sprint curtos.


Estimativas usando cálculos de velocidade
Essa técnica envolve dois passos:
1. Defina a velocidade estimada.
2. Calcular quantas estórias você pode adicionar sem exceder a
velocidade estimada.

Velocidade é uma medida da “quantidade trabalho realizado”, onde cada
item é medido com base na sua estimativa inicial.

A figura abaixo mostra um exemplo de velocidade estimada no início de
um sprint e a velocidade real no final do sprint. Cada retângulo é uma
estória, e o número dentro dele é a estimativa inicial dela.

Note que a velocidade real é baseada na estimativa inicial de cada estória.
Quaisquer modificações na estimativa de tempo da estória durante o sprint
devem ser ignoradas.

Já posso ouvir você dizendo: “Como isso é útil? Maior ou menor
velocidade depende de uma série de fatores! Programadores
inexperientes, estimativas iniciais incorretas, diminuição de escopo,
problemas não previstos durante o sprint, etc.!”

Eu concordo, esse é um número cru mesmo. Mas ainda assim é uma
medida útil, especialmente quando não for comparado com nada mais. Ele
te fornece alguns fatos fixos. “Independentemente dos motivos, aqui está
uma diferença aproximada de o quanto nós achávamos que gastaríamos na
atividade e o quanto realmente gastamos”.

E o que dizer sobre uma estória que ficou quase completa durante o
sprint? Por que não pegamos medidas parciais em nossa velocidade real?
Bem, é para tirar proveito do fato de que Scrum (e de fato o
desenvolvimento ágil de software e os processos lean de fabricação em
geral) trata de ter as tarefas realizadas, prontas para serem entregues! O
valor de uma coisa feita pela metade é zero (de fato, é até negativo). Leia


o livro “Managing the Design Factory” de Donald Reinertsen ou algum
dos livros de Poppendieck para saber mais sobre o assunto.

Então, com que varinha mágica estimamos velocidade?

Uma maneira muito simples de fazer isso é olhar para o histórico da
equipe. Qual foi a velocidade dela nos sprints mais recentes? Então
assuma que a velocidade nesse sprint será equivalente.

Essa técnica é conhecida como tempo de ontem. Isso só é possível para
equipes que já tenham terminado alguns sprints (com as estatísticas
disponíveis) e farão o próximo praticamente da mesma forma com o
mesmo número de membros e mesmas condições de trabalho, etc.
Obviamente, nem sempre esse é o caso.

Uma variante mais sofisticada é fazer um cálculo simples de recursos.
Vamos supor que estamos planejando um sprint de 3 semanas (15 dias de
trabalho) com uma equipe de 4 pessoas. Lisa estará de folga por 2 dias.
Dave está disponível somente 50% e estará de folga por 1 dia. Colocando
tudo isso junto...

... resulta em 50 homem-dias disponíveis para este sprint.

Será esta a nossa velocidade estimada? Não! Porque nossa unidade de
estimativa é pontos por estória, os quais, no nosso caso, correspondem a
uma aproximação de “homens-dia ideal”. Um homem-dia ideal é um dia
perfeitamente efetivo, sem distúrbios, o que é raro. Além disso, temos que
levar em consideração coisas como o trabalho não planejado que é
adicionado ao sprint, pessoas que ficam doentes, etc.

Portanto, nossa velocidade estimada será certamente menor que 50. Mas o
quanto menor? Utilizamos para isso o termo “fator de foco”.


O fator de foco é uma estimativa de como a equipe é focada. Um fator de
foco baixo, pode significar que a equipe espera ter muitas interferências
ou percebe que suas próprias estimativas de tempo são otimistas.

A melhor maneira para determinar um fator de foco razoável é considerar
o último sprint (ou melhor ainda, a média de alguns sprints anteriores).

A velocidade atual é a soma das estimativas iniciais de todas as estórias
que foram finalizadas no último sprint.

Vamos supor que o último sprint terminou 18 pontos por estória
utilizando uma equipe de 3 pessoas, com Tom, Lisa e Sam trabalhando 3
semanas, resultando em um total de 45 homens-dia. E agora nós estamos
tentando calcular nossa velocidade estimada para o próximo sprint. Para
complicar as coisas, um cara novo, o Dave, está se juntando à equipe para
esse sprint. Levando em consideração as folgas e as obstruções nós temos
50 homem-dias para o próximo sprint.

Portanto, nossa velocidade estimada para o próximo sprint é de 20 pontos
por estória. O que significa que a equipe deveria adicionar estórias ao
sprint até atingir uma soma de aproximadamente 20.


Neste caso, a equipe talvez escolha as 4 primeiras estórias para obter um
total de 19 pontos por estória, ou as 5 primeiras totalizando 24 pontos por
estória. Vamos supor que eles escolham 4 estórias, visto que é o mais
próximo de 20 pontos por estória que se chega. Na dúvida, selecione
menos estórias.

Como estas 4 estórias adicionaram 19 pontos por estória, a velocidade
estimada final para este sprint é 19.

Tempo de ontem é uma técnica acessível, mas use-a com uma dose de
bom senso. Se o último sprint foi excepcionalmente ruim porque a maior
parte da equipe esteve doente por uma semana, então pode ser seguro
assumir que você não terá esta falta de sorte de novo e você pode estimar
um fator de foco alto para o próximo sprint. Se a equipe instalou
recentemente um novo e rápido sistema de build contínuo você pode,
provavelmente, aumentar o fator de foco devido a isto também. Se uma
pessoa nova está se juntando a este sprint você precisa reduzir o fator de
foco para considerar seu treinamento. Etc.

Sempre que possível olhe para os sprints passados e faça a média dos
números para obter uma estimativa mais confiável.

E se a equipe for completamente nova e você não tiver nenhuma
estatística? Olhe para o fator de foco de outras equipes em circunstâncias
similares.

E se você não tiver nenhuma outra equipe para olhar? Suponha um fator
de foco. A boa notícia é que o seu chute será usando somente no primeiro
sprint. Depois disto você terá estatísticas e pode medir e melhorar
continuamente seu fator de foco e a velocidade estimada.


O fator de foco “padrão” que eu uso para novas equipes é usualmente
70%, porque este é o ponto onde muitos de nossas outras equipes
chegaram com o tempo.

Qual técnica de estimativa nós usamos ?
Eu mencionei diversas técnicas acima – instinto/sentimento, cálculo de
velocidade baseado no tempo de ontem, e cálculo de velocidade baseada
no homens-dia disponíveis e fator de foco.

Então, qual técnica nós usamos ?

Geralmente combinamos estas técnicas em certas medidas. Realmente não
toma muito tempo.

Olhamos para o fator de foco e na velocidade atual do último sprint.
Olhamos para a disponibilidade total de nossos recursos disponíveis e
estimamos o fator de foco. Discutimos quaisquer diferenças entre estes
fatores de foco e fazemos os ajustes necessários.

Uma vez que temos a listagem preliminar das estórias a serem incluídas
no sprint, eu faço uma revisão baseada no meu sentimento. Eu peço a
equipe para ignorar os números por um momento e pensar apenas em suas
percepções sobre a parte em questão do sprint. Se acham que levará
bastante tempo então removemos uma ou duas estórias. E vice-versa.

Ao final do dia, o objetivo é simplesmente decidir quais estórias nós
incluiremos no sprint. Fator de foco, disponibilidade de recursos e
velocidade estimada são apenas meios de atingir o objetivo.

Por que nós usamos cartões
A maior parte da reunião de planejamento do sprint é gasto lidando com
as estórias no product backlog. Estimando-as, repriorizando-as,
esclarecendo-as, quebrando-as, etc.

Como fazemos isso na prática ?

Bem, normalmente, as equipes ligam o projetor e mostram um backlog
feito em Excel, então um cara (tipicamente o product owner ou o scrum
master) pega o teclado, esboça cada estória e estimula uma discussão. A
medida que as prioridades e detalhes são discutidas pela equipe e pelo
product owner, a pessoa ao teclado atualiza a estória direto no Excel.


Parece bom? Bem, não é. Normalmente é um saco. E o que é pior, a
equipe normalmente não avisa que é um saco até eles chegarem no fim da
reunião e perceberem que ainda não conseguiram passar para lista de
estórias!

Uma solução que funciona muito melhor é criar cartões e colocá-los na
parede (ou numa mesa grande).

Esta é uma interface de usuário superior comparada a computador &
projetor porque:
Pessoas ficam em pé e caminham => elas ficam acordadas e
alerta por mais tempo.
Todos se sentem mais pessoalmente envolvidos (ao invés de só o
cara com o teclado).
Múltiplas estórias podem ser editadas simultaneamente.
A repriorização é trivial - só trocar a posição dos cartões.
Após a reunião, os cartões podem ser levados para a sala da
equipe e ser usado como um quadro de tarefas na parede (veja pg
49 "Como nós fazemos o sprint backlog)

Você pode tanto escrevê-los à mão ou (como geralmente fazemos),
quanto usar um script simples para gerar cartões imprimíveis diretamente
do product backlog.


PS – o script está disponível no meu blog em
http://blog.crisp.se/henrikkniberg.

Importante: Depois da reunião de planejamento do sprint, nosso scrum
master atualiza manualmente o product backlog no Excel com respeito a
quaisquer mudanças que foram feitas aos cartões físicos de estórias. Sim,
isso é um pequeno inconveniente administrativo, mas nós achamos
perfeitamente aceitável considerando o quão mais eficiente é a reunião de
planejamento do sprint com cartões físicos.

Uma nota sobre o campo “Importância”. Essa é a importância como
especificado no product backlog do Excel no momento da impressão. Tê-
lo no cartão torna fácil ordenar os cartões fisicamente por importância
(normalmente colocamos os itens mais importantes à esquerda, e os
menos à direita). Entretanto, uma vez que os cartões estão na parede, você
pode ignorar a classificação de importância e usar a ordenação física na
parede para indicar importância relativa. Se o product owner troca dois
itens, não perca tempo atualizando a classificação de importância no
papel. Certifique-se de atualizar a classificação de importância no product
backlog do Excel somente depois da reunião.

Estimativas de tempo são mais fáceis (e mais precisas) de fazer se a
estória é quebrada em tarefas. Nós usamos o termo “atividade” pois a
palavra “tarefa” significa algo completamente diferente em sueco :o)
Isso também é bom e fácil de fazer com nossos cartões. Você pode dividir
a equipe em pares e cada um quebra uma estória, em paralelo.

Fisicamente nós fazemos isso adicionando pequenas notas em post-it
embaixo de cada estória, cada post-it refletindo uma tarefa dentro daquela
estória.


Nós não atualizamos o product backlog do Excel com respeito a nossas
quebras em tarefas por duas razões:
A quebra de tarefas é geralmente bastante volátil, i.e. elas são
freqüentemente alteradas e refinadas durante o sprint, então dá
muito trabalho manter product backlog do Excel sincronizado.
O product owner não precisa estar envolvido neste nível de
detalhes, mesmo.

Assim como com os cartões de estórias, os post-its de quebra de tarefas
podem ser reusados diretamente no sprint backlog (veja pág. 49 “Como
fazemos os sprint backlogs”).

Definição de “pronto”
É importante que o product owner e a equipe concordem com uma
definição clara de “pronto”. Uma estória está completa quando todo o
código está no repositório? Ou está completa apenas quando foi feito
deploy em um ambiente de teste e a estória foi verificada por uma equipe
de testes de integração? Sempre que possível nós usamos a definição
“pronto para deploy em produção”, mas algumas vezes precisamos usar a


definição “feito deploy em servidor de teste e pronto para os testes de
aceitação”.

No início costumávamos ter checklists detalhados para isso. Atualmente
nós frequentemente dizemos “uma estória está pronta quanto o tester da
equipe Scrum diz que está”. É responsabilidade do tester se certificar de
que a intenção do product owner foi compreendida pela equipe e que o
item está suficientemente “pronto” para que passe pela definição de
“pronto” acordada.

Nós percebemos que nem todas as estórias podem ser tratadas da mesma
forma. Uma estória com o nome “Formulário para pesquisa de usuários”
será tratada de forma muito diferente de uma estória com o nome “Manual
de operações”. No segundo caso, a definição de “pronto” pode
simplesmente significar “aceito pela equipe de operações”. É por isso que
o senso comum geralmente é melhor do que checklists formais.

Se você frequentemente se confunde quanto à definição de “pronto” (o
que ocorreu conosco no início) você provavelmente deveria ter um campo
“definição de pronto” para cada estória individual.

Estimativa de tempo usando planning poker
Estimar é uma atividade da equipe – cada membro é freqüentemente
envolvido pra estimar cada estória. Por que?

Quando vamos planejar, normalmente nós não sabemos
exatamente quem vai implementar quais partes de quais estórias.
Estórias normalmente envolvem diversas pessoas e diversos tipos
de expertise (design de interface de usuário, codificação, teste,
etc).
Para prover uma estimativa, o membro da equipe precisa de
algum tipo de entendimento do quê trata a estória. Pedindo para
todos estimarem cada item, nós nos certificamos que cada
membro da equipe compreende do que cada item se trata. Isso
aumenta a probabilidade de que os membros se ajudarão durante
o sprint. Isso também aumenta a probabilidade de que questões
importantes sobre a estória surjam cedo.
Quando pedimos que todos estimem uma estória, freqüentemente
descobrimos discrepâncias onde duas pessoas da equipe têm
estimativas bastante diferentes para a mesma estória. Esse tipo de
coisa é melhor ser descoberto e discutido o quanto antes.


Se você pedir à equipe para que gere uma estimativa, normalmente a
pessoa que melhor entende a estória será a primeira a revelar a sua.
Infelizmente, isso afetará fortemente as estimativas de todo o resto.

Há uma técnica excelente para evitar isso – ela é chamada planning poker
(cunhada por Mike Cohn, eu acho).

Cada membro da equipe recebe um baralho de 13 cartas como mostrado
acima. Sempre que uma estória deve ser estimada, cada membro escolhe
uma carta que representa a sua estimativa de tempo (em pontos por
estória) e coloca-a virada para baixo sobre a mesa. Quando todos os
membros da equipe tiverem feito sua estimativa, as cartas são reveladas
simultaneamente. Dessa forma, cada membro da equipe é forçado a
pensar por si próprio ao invés de basear-se na estimativa de outra pessoa.

Se houver uma grande divergência entre duas estimativas, a equipe
discute as diferenças e tenta chegar a uma visão comum do trabalho
envolvido na estória. Eles podem fazer algum tipo de decomposição de
tarefas. Depois disso, a equipe faz novamente a estimativa. Esse processo
é repetido até que as estimativas de tempo cheguem a uma convergência,
isto é, todas as estimativas sejam aproximadamente a mesma para cada
estória.

É importante lembrar aos membros da equipe que eles devem estimar a
quantidade total de esforço envolvido na estória. Não é somente “a sua”
parte do trabalho. O testador não deve somente estimar a quantidade de
esforço de teste.

Note que a seqüência de números não é linear. For exemplo, não há nada
entre 40 e 100. Por quê?

Assim evita-se a falsa sensação de precisão para grandes estimativas de
tempo. Se uma estória é estimada em aproximadamente 20 postos por
estória, não é relevante se ela deve ser 20 ou 18 ou 21. Todos sabemos
que é uma estória grande e que é difícil estimar. Portanto, 20 é o nosso
palpite aproximado.

Quer estimativas mais detalhadas? Então, quebre a estória em estórias
menores e estime-as!

E não, você não pode trapacear combinando um 5 e um 2 para fazer um 7.
Você deve escolher 5 ou 8. Não há um 7 nas cartas.


Existem algumas cartas especiais:
• 0 = “esta estória já está feita” ou “esta estória é tão pequena que
leva somente alguns minutos de trabalho”;
• ? = “Eu não faço idéia alguma”;
• Xícara de café = “Estou cansado demais para pensar. Vamos
fazer uma pequena pausa”.

Esclarecendo Estórias
O pior é quando uma equipe orgulhosamente demonstra uma nova
funcionalidade durante o sprint e o product owner franze as
sombrancelhas e diz: “Bem, está bonito, mas isso não é o que eu pedi!”

Como você assegura que a compreensão que o product owner tem, casa
com a compreensão que a equipe tem sobre a estória? Ou que cada
membro da equipe tem a mesma compreensão de cada estória? Bem, você
não tem como. Mas aqui vão algumas simples técnicas para identificar as
piores confusões.
A técnica mais simples é ter certeza que todos os campos foram
preenchidos em cada estória (ou mais especificamente, para cada estória
que for mais importante de ser considerada para essa reunião).

Exemplo 1:
A equipe e o product owner estão felizes com o sprint e prontos para
terminar o encontro. O scrum master diz “Esperem um segundo, na
estória chamada “adiciona usuário”, não há estimativa. Vamos estimar!”
Depois de algumas rodadas de planning poker a equipe concorda com 20
pontos por história enquanto o product owner levanta e enfaticamente diz:
-“O queeeee?!”. Depois de alguns minutos de discussão acalourada, ela se
transforma numa não compreensão, por parte da equipe, sobre o escopo
“adicionar usuário”, eles acreditaram ser “uma boa interface web para
adicionar, remover e proucurar por usuários”, enquanto o product owner
compreendeu “adicionar usuários” como uma chamada manual usando
SQL num banco de dados. Eles estimam novamente e concordam em 5
pontos por estória.

Exemplo 2:
A equipe e o product owner estão felizes com o plano do sprint e prontos
para terminar o encontro. O scrum master diz: “Esperem um segundo,
como a estória adicionar usuários será demonstrada?” algum murmurinho
depois e alguém se levanta e diz: “Bem, primeiro logamos no site e aí
então...” e o product owner interrompe: “Logamos no site?! Não, não,


não, essa funcionalidade não deverá ser parte do web site de forma
alguma, isso deverá ser apenas um script SQL para administradores
técnicos”.

A descrição de “como demonstrar” a estória pode e deve ser muito breve!
Ou você nunca vai encerrar a reunião de planejamento do sprint a tempo.
Isso basicamente é uma descrição por alto de como executar os mais
típicos testes de cenário manualmente. “Faça isso, faça aquilo, e verifique
isso”.

Eu descobri que essa simples descrição cobre freqüentes
desentendimentos sobre o escopo da estória. Bom descobri-las cedo,
certo?

Quebrando estórias em estórias menores
Estórias não deveriam ser muito pequenas nem muito grandes (em termos
de estimativas). Se você possui um grupo de estórias de 0.5 ponto, você
provavelmente será uma vítima do microgerenciamento. Da mesma
forma, uma estória de 40 pontos terá grande risco de terminar
parcialmente completa, o que não produz valor à sua empresa e apenas
amplia a administração. Ainda assim, se sua velocidade for 70 e as duas
estórias de maior prioridade possuirem o peso de 40 pontos por estória
cada, o planejamento torna-se um pouco difícil. Você deverá escolher
entre comprometer-se pouco (ex. produzir apenas um item) ou
comprometer-se demais (ex.produzir os dois itens).

Descobrimos que é quase sempre possível quebrar uma estória em
pedaços menores. Apenas tenha certeza de que as partes (estórias
menores) ainda representam entregas com valor de negócio.

Nós normalmente nos empenhamos para estórias estimadas em 2 - 8
homens-dia. Nossa velocidade é geralmente entre 40 e 60 para uma
equipe típica, e isso nos dá algo em torno de 10 estórias por sprint.
Algumas vezes serão tão poucas quanto 5 e outras vezes serão tantas
quanto 15. Este é um número gerenciável de cartões para se trabalhar.

Dividindo estórias em tarefas
Espere um momento, qual a diferença entre “tarefas” e “estórias”? Uma
pergunta muito apropriada.


A distinção é bem simples. Estórias são trabalhos que podem ser
entregues e que o product owner tem que se preocupar. Tarefas são
atividades que não podem ser entregues, ou atividades que o product
owner não precisa se preocupar.

Exemplo da divisão de uma estória em outras menores:

Exemplo da divisão de uma estória em tarefas:

Seguem aqui algumas observações importantes:
• Equipes novas no Scrum são relutantes em gastar tempo
dividindo um conjunto de estórias em tarefas como essas.
Algumas sentem que essa é uma abordagem em cascata.
• Para estórias que não foram claramente entendidas, é tão simples
fazer essa divisão logo, ou mais tarde.
• Esse tipo de divisão freqüentemente revela trabalho adicional que
faz com que a estimativa de tempo aumente, mas por outro lado
resulta em um planejamento do sprint mais realista.
• Esse tipo de divisão logo cedo torna as reuniões diárias do scrum
notavelmente mais eficientes (veja página 64 “Como fazemos as
reuniões diárias”).
• Mesmo que a divisão seja imprecisa e mude quando o trabalho
iniciar, as vantagens acima ainda aplicam-se.

Assim, nós tentamos fazer o espaço de tempo do planejamento do scrum
grande o bastante para acomodá-la, mas se o tempo esgota-se, deixemos
ela de lado (veja “Onde desenhar a linha” abaixo).

Nota – nós praticamos TDD (test driven development – desenvolvimento
orientado a testes) que na prática significa que a primeira tarefa para
quase todas as estórias é “escrever um teste de defeito” e a última tarefa é
“refazer” (= melhorar a legibilidade do código e remover duplicidades).

Definindo a hora e lugar da reunião diária
Uma saída frequentemente esquecida da reunião de planejamento de
sprint é “hora e local para a reunião diária do scrum definidos”. Sem isto,
seu sprint terá um mau início. A primeira reunião diária é essencial para o
lançamento onde todos decidem começar a trabalhar.


Eu prefiro reuniões matutinas. Mas, eu devo admitir, nós não tentamos
fazer reuniões diárias na tarde ou meio-dia..

Desvantagem de reuniões vespertinas: quando você for trabalhar de
manhã, você tem que tentar se lembrar do que falou ontem para as pessoas
sobre o que faria hoje.

Desvantagem de reuniões matutinas: quando você for trabalhar de
manhã, você tem que se lembrar do que fez ontem, pra que possa reportar
isto.

Na minha opinião, a primeira desvantagem é pior, porque o mais
importante é o que você vai fazer, não o que você fez.

Nosso procedimento padrão é selecionar o horário mais cedo sem que
ninguém reclame. Normalmente 9:00, 9:30 ou 10:00. O mais importante
é que seja uma hora que todos da equipe aceitem completamente, de
coração.

Onde traçar a linha
OK, então o tempo está acabando. De todas as coisas que queremos fazer
durante a reunião de planejamento do sprint, o que nós devemos cortar, se
o tempo acabar?

Bem, eu uso a seguinte lista de prioridades:

Prioridade 1: Um objetivo para o sprint e uma data para a realização da
demonstração. Isto é o mínimo que você precisa para iniciar um sprint. A
equipe tem um objetivo e uma data de término, e eles podem trabalhar a
partir do product backlog. É ruim, sim, e você deve seriamente considerar
o agendamento de uma nova reunião para planejamento do sprint para o
dia seguinte, mas se você realmente precisa iniciar o sprint, isto deverá
ajudar. Para ser honesto, eu nunca iniciei um sprint com esta pequena
informação.

Prioridade 2: Lista de estórias que a equipe aceitou trabalhar neste sprint.

Prioridade 3: Preencha a informação de estimativa para cada estória do
sprint.


Prioridade 4: A informação “Como demonstrar” deve ser preenchida em
cada estória do sprint.

Prioridade 5: Cálculos de velocidade e recursos, como uma verificação
de realidade para o seu plano de sprint. Inclui lista de membros da equipe
e o comprometimento deles (de outra forma não se consegue calcular
velocidade).

Prioridade 6: Hora e local específico para a reunião diária. Se decide isto
de forma muito rápida, mas se você não tiver tempo o scrum master pode
simplesmente decidir isto depois da reunião e pode avisar todos por e-
mail.

Prioridade 7: Estórias quebradas em tarefas. Esta quebra pode ser feita
diariamente, assim como as reuniões diárias, mas isto vai gerar uma leve
interrupção no fluxo do sprint.

Estórias técnicas
Eis aqui um problema complexo: Estórias técnicas. Ou itens não
funcionais. Ou como você preferir chamá-los.

Estou referindo-me àquelas coisas que precisam ser feitas mas que não
fazem parte das entregas, não estão relacionadas diretamente com
nenhuma estória específica e não agregam valor para o product owner.

Nós as chamamos de “estórias técnicas”.

Por exemplo:
Instalar um servidor de build
o Por que é necessário: porque economiza uma enorme
quantidade de tempo para os desenvolvedores e reduz o
risco dos problemas de integração ao fim da iteração.

Escrever um resumo do projeto do sistema
o Por que é necessário: Porque os desenvolvedores
insistem em esquecer-se do projeto geral e, em
conseqüência, de escrever um código consistente.
Precisam de um documento do tipo “resumão” para
manter todos na mesma linha de projeto.

Refazer a camada DAO


o Por que é necessário: Porque a camada DAO tem sido
uma total desordem e tem tomado tempo de todos devido
a essa confusão e aos bugs desnecessários. Limpar esse
código vai economizar tempo de todos e aumentar a
robustez do sistema.

Fazer o upgrade do Jira (bug tracker)
o Por que é necessário: A versão atual tem muitos bugs e é
lenta. Fazer o upgrade vai economizar tempo de todos.

Essas estórias fazem parte do senso comum? Ou elas estão conectadas
com alguma estória específica? Quem as prioriza? O product owner
deveria envolver-se com essas coisas?

Fizemos várias experiências com diferentes maneiras de lidar com
estórias técnicas. Tentamos tratá-las como estórias de primeira classe,
como todas as outras. Não funcionou bem. Quando o product owner
priorizou o backlog, foi como comparar maças com laranjas. De fato, por
razões obvias as estórias técnicas obtinham sempre prioridade menor
devido ao modo de pensar como: “ok, pessoal, Estou certo de que um
servidor de build contínuo é importante, mas vamos atacar primeiro
alguma coisa que possamos faturar! E então podemos adicionar o
brinquedo tecnológico mais tarde, OK?”

Em alguns casos o product owner tem razão, mas quase sempre não tem.
Concluímos que o product owner nem sempre esta qualificado para tomar
estas decisões. Assim, o que fazemos é:
1) Tentamos evitar as estórias técnicas. Procure transformar uma
estória técnica em uma estória normal, com valores de negócio
mensuráveis. Desse jeito o product owner vai ter uma chance
maior de tomar as decisões corretas.
2) Se não conseguirmos transformar uma estória técnica em uma
estória normal, veja se o trabalho pode ser feito como uma tarefa
dentro de outra estória. Por exemplo: “refatorar a camada DAO”
pode ser uma tarefa dentro da estória “editar usuário”, pois ela
envolve a camada DAO.
3) Se os dois itens anteriores falharem, defina-o como uma estória
técnica, e mantenha uma lista separada destas estórias. Deixe que
o product owner a veja, mas não permita que modifique-a.
Utilizamos o parâmetros “fator de foco” e “velocidade estimada”
para negociar com o product owner e separar algum tempo no
sprint para implementar as estórias técnicas.


Exemplo (um diálogo muito semelhante à este ocorreu durante uma de
nossas reuniões de planejamento do sprint.)

Equipe: "Nós temos trabalho técnico interno que precisa ser
feito. Gostaríamos de dedicar 10% do nosso tempo para fazê-lo,
por exemplo, reduzir o fator de foco de 75% para 65%. Tudo
bem?"
product owner: "De jeito nenhum! Nós não temos tempo!"
Equipe: : "Bem, olhe para o último sprint (todas as cabeças
viram pra curva de velocidade no quadro branco). Nossa
velocidade estimada era 80, a atual é 30, certo?"
PO: "Exatamente! Então nós não temos tempo pra serviço
interno! Precisamos de novas características!"
Equipe: "Bem, a razão de nossa velocidade ter se tornado tão
baixa foi que perdemos muito tempo tentando integrar versões
funcionais para testes".
PO: “Sim, e?”
Equipe: “Bem, nossa velocidade vai continuar sendo ruim se não
fizermos alguma coisa sobre isso.”
PO: “Sim, e?”
Equipe: "Então nós propomos subtrairmos aproximadamente
10% deste sprint para configurar um servidor de produção e para
cuidar de outras coisas que irão resolver os problemas de
integração. Isto provavelmente irá aumentar nossa velocidade de
sprint em pelo menos 20% para cada sprint subsequente. Pra
sempre!"
PO: "Verdade? Então por quê nós não fizemos isto no sprint
passado?"
Equipe: "Err… porque você não quis que fizéssemos."
PO: "Oh, hum, muito bem, parece uma boa idéia fazermos isto
agora então!"

É claro, a outra opção é só deixar o product owner desinformado ou dar-
lhe um fator de foco não negociável. Mas não tem desculpa para não
tentar chegar à um consenso primeiro.

Se o product owner for um companheiro competente e razoável (e nós
tivemos sorte aqui) sugiro mantê-lo tão informado quanto possível e
deixá-lo decidir sobre as prioridades. Transparência é um dos valores
centrais do Scrum, certo?


Sistema de acompanhamento de bugs vs.
product backlog
Eis aqui uma armadilha. Excel é um ótimo formato para o product
backlog. Mas você ainda precisa de um sistema de acompanhamento de
bugs, e o Excel provavelmente não lhe atenderá. Nós usamos Jira.

Então, como nós levamos os defeitos registrados no Jira para as reuniões
de planejamento do sprint? Eu quero dizer que não devemos apenas
ignorá-los e focarmos apenas nas estórias.

Nós tentamos várias estratégias:
1) O product owner imprime os bugs prioritários registrados no Jira,
leva-os à reunião de planejamento do sprint e afixa-os na parede
junto com as outras estórias (especificando, desse modo,
implicitamente, a prioridade desses itens em comparação com as
outras estórias).
2) O product owner cria estórias que fazem referência aos itens do
Jira. Por exemplo: “consertar os bugs mais críticos dos relatórios
do back office, Jira-124, Jira-126 e Jira-180”.
3) O concerto de bugs é considerado fora do sprint, p.ex., a equipe
mantém um fator de foco pequeno o suficiente (50%, por
exemplo) para garantir que tenham tempo para consertá-los.
Assim, assumem que gastarão um certo período de tempo de cada
sprint consertando os bugs.
4) Colocar o product backlog dentro do Jira (p.ex. descartar o
Excel). Trate os bugs como qualquer outra estória.

Nós ainda não concluímos qual dessas estratégias é a melhor para nós. De
fato, elas variam de equipe para equipe e de sprint para sprint. Eu sou
propenso a apostar na primeira estratégia. Ela é mais legal e mais simples.

A reunião de planejamento do sprint está
finalmente terminada!
Uau, Eu nunca imaginei que este capítulo sobre planejamento do sprint
fosse ser tão longo! Eu acho que isso reflete a minha opinião de que a
reunião de planejamento do sprint é a coisa mais importante que se faz no
Scrum. Empenhe-se bastante para fazê-la corretamente e todo o resto será
muito mais fácil.


A reunião de planejamento do sprint obteve sucesso se todos (os membros
da equipe e o product owner) sairem da reunião com um sorriso no rosto,
acordam na outra manhã com um sorriso e todos fazem a primeira reunião
diária com um sorriso.

Então, é claro, tudo pode dar errado no restante do projeto, mas pelo
menos você não poderá culpar o planejamento do sprint :o)

5
Como comunicamos sprints
É importante manter a empresa inteira informada sobre o que está
acontecendo. Embora as pessoas reclamem, ou mesmo pior, façam falsas
suposições sobre o que está acontecendo.

Nós usamos a “página de informações do sprint” para isso.

As vezes nós incluímos informações sobre como cada estória será
demonstrada também.

O mais cedo possível depois da reunião de planejamento do sprint, o
scrum master cria esta página, põe no ar no Wiki, e envia para a empresa
inteira.

Nós também temos a página ”dashboard” no nosso wiki, que junta tudo
que está acontecendo nos sprints.

Além disso, o scrum master imprime a página de informação do sprint e
coloca no mural do lado de fora da sala da equipe. Então todo mundo que
passa pode vê-la e descobrir o que a equipe fazendo. Desde que isso
inclua o tempo e o lugar da reunião diária e da apresentação do sprint, se
saberá onde ir para descobrir mais.

Quando o sprint está perto do fim, o scrum master lembra todo mundo
sobre a apresentação que ocorrerá em breve.

Feito tudo isso, ninguém tem desculpa pra não saber o que está
acontecendo.


6
Como fazemos os sprint backlogs
Você já fez isso alguma vez? Uau! Bom trabalho.

Bem, agora que já completamos a reunião de planejamento do sprint e
contamos ao mundo sobre nosso sprint novinho em folha, é hora do
Scrum master criar um sprint backlog. Ele precisa ser feito depois da
reunião de planejamento do sprint, mas antes da primeiro reunião diária
do Scrum.

Formato do sprint backlog
Nós já tentamos alguns formatos diferentes para o sprint backlog,
incluindo Jira, Excel e um quadro de tarefas pregado na parede. No
princípio nós usamos principalmente Excel. Existem vários modelos
prontos de sprint backlogs em Excel, incluindo gráficos de burndown
automáticos e coisas do gênero. Eu poderia falar bastante como nós
refinamos nossos sprint backlogs em Excel. Mas não farei isso. Não vou
nem incluir um exemplo aqui.

Ao invés disso, irei descrever em detalhes o que nós temos visto ser o
formato mais produtivo para o sprint backlog – um quadro de tarefas
pregado na parede!

Encontre uma parede grande que não é utilizada ou que tem coisas inúteis,
como o símbolo da empresa, diagramas velhos e quadros feios. Limpe a
parede (só peça permissão se for necessário). Cole uma folha de papel
bem grande, bem grande mesmo (pelo menos 2m de altura x 2m de
largura, ou 3x2m para uma equipe grande). Então faça assim:

É claro que você poderia usar um quadro branco. Mas seria um
desperdício. Se possível, use os quadros-brancos para rascunhos de
projeto e as outras paredes para os quadros de tarefas.

COMO FAZEMOS SPRINT BACKLOGS | 47

NOTA – se você usar post-its para tarefas, não esqueça de colá-los usando
durex ou fita crepe mesmo, ou você irá encontrar todos eles misturados no
chão no dia seguinte.


Como funciona o quadro de tarefas

Você pode, claro, adicionar todo tipo de colunas adicionais. “Esperando
pelo teste de integração” por exemplo. Ou “Cancelado”. Entretanto antes
de complicar as coisas, pense profundamente. Esta adição de coluna é
realmente necessária?

Eu descobri que simplicidade é extremamente válida para este tipo de
coisa, então eu apenas adiciono complicações quando o custo de não fazer
é muito alto.

Exemplo 1 – depois da primeira reunião diária
Depois da primeira reunião diária, o quadro de tarefas vai parecer como
este:

Como se pode ver, três tarefas foram selecionadas e colocadas em
produção. A equipe vai trabalhar nestas tarefas hoje.

Às vezes, para equipes grandes, uma tarefa fica presa na etapa de
produção pois ninguém lembra quem estava trabalhando nela. Se isto
acontecer de forma recorrente em uma equipe, normalmente se define
uma política como rotular as tarefas em produção com o nome da pessoa
que está trabalhando nela.


Exemplo 2 – poucos dias depois
Poucos dias depois, o quadro de tarefas pode se parecer com algo assim:

Como pode ver, completamos a estória “depósito” (i.e. foi integrada ao
repositório com o código fonte, testada, refatorada, etc). A ferramenta de
migração está parcialmente completa, a parte do login foi iniciada e a
parte de administração de usuários não começou.

Tivemos 3 itens não-planejados, como pode se ver na parte inferior
direita. Guardá-los é útil para que sejam lembrados quando você for fazer
a retrospectiva do sprint.

Eis um exemplo de um sprint backlog real perto do fim do sprint. Ele de
fato fica meio bagunçado com o andamento do sprint, mas isso está OK
pois sua vida é curta. A cada novo sprint, nós criamos um fresco, limpo e
novo sprint backlog.


Como funciona o gráfico de burndown
Vamos dar um zoom no gráfico de burndown:

Este gráfico mostra que:
No primeiro dia do sprint, 1 de agosto, a equipe estimou que
havia aproximadamente 70 pontos por estória de trabalho a serem
feitos. Isso foi na verdade a velocidade estimada de todo o sprint.
Em 16 de agosto a equipe estimou que havia aproximadamente
15 pontos por estória de trabalho a serem feitos. A linha de
tendência tracejada mostra que eles estão aproximadamente
dentro do prazo, isto é, neste ritmo eles completarão tudo até o
final do sprint

Nós pulamos os finais de semana no eixo-x, uma vez que o trabalho
raramente é executado aos finais de semana. Nós costumávamos incluir
finais de semana mas isso tornaria o gráfico de burndown um pouco
confuso, já que o mesmo ficaria “reto ” nos finais de semana e isso
poderia parecer um sinal de alarme.


Sinais de alarme do quadro de tarefas
Uma olhada rápida no quadro de tarefas daria a qualquer um uma
indicação de quão bem o sprint está progredindo. O scrum master é
responsável por garantir que a equipe haja quando surgirem sinais de
alarme como:


Ei, e a rastreabilidade?!
A melhor rastreabilidade que eu posso sugerir neste modelo é tirar uma
foto digital do quadro de tarefas todo dia. Eu faço isso às vezes, mas eu
nunca encontrei um motivo para vasculhar estas fotos.

Se rastreabilidade é muito importante para você, então o quadro de tarefas
talvez não seja uma boa solução para você.

Mas eu sugiro que você realmente tente estimar o valor real de ter uma
rastreabilidade detalhada do sprint. Uma vez que o sprint está pronto, o
software funcionando e a documentação entregue, alguém realmente se
preocupa com quantas estórias foram completadas no dia 5 de um sprint?
Alguém realmente se preocupa com qual era o tempo estimado para
“escrever um teste de falha para Depósito”?

Estimando dias vs horas
Na maioria dos livros e artigos sobre Scrum, você vai encontrar que as
tarefas são estimadas em horas, e não em dias. Costumávamos fazer isto.
Nossa formula geral era: 1 homem-dia = 6 horas-homem reais.

Atualmente deixamos de fazer assim, pelo menos na maior parte de nosso
grupo, pelas seguintes razões:
As estimativas em homem-hora eram muito granulares, e isto
provocava uma tendência a estimar muitas tarefas de 1-2 horas e
a conseqüente micro gerencia.
De qualquer forma, como todos estavam pensando em temos de
homens-dias, e simplesmente multiplicavam por 6 antes de
escrever homem-hora. “Hmmmm, esta tarefa deve gastar um dia.
Bom, tenho que escrever horas, então escrevo 6 horas”.
Duas unidades diferentes podem causar confusão. “Esta
estimativa é em homem-hora ou homem-dia?

Assim, atualmente usamos o homem-dia para todas as nossas estimativas
(embora continuemos chamando de pontos por estória - story points).
Nosso menor valor é 0,5, isto é, qualquer tarefa que é menor que 0,5 será
eliminada, combinada com outras tarefas ou receberá o valor de 0,5. (Não
tem problema superestimar um pouco). Simples e elegante.

7
Como arrumamos a sala da equipe

O canto do design

Eu notei que muitas das mais interessantes e valiosas discussões sobre
design acontecem espontaneamente na frente do quadro de tarefas.

Por esta razão, nós tentamos arrumar esta área explicitamente como um
“canto do design”.

Isto é realmente bem útil. Não há forma melhor de ter uma visão geral do
sistema do que ficar no canto do design e dar uma olhadela em ambas as
paredes, e então dar uma olhadela no computador e tentar o último build
do sistema (se você for sortudo o bastante para ter build contínuo, veja pg
81 “Como combinamos Scrum e XP”).

A “parede do design” é só um grande quadro-branco contendo os rabiscos
de design e esboços (printouts) da documentação de design mais
importante (gráficos de seqüências, protótipos de GUI, modelos de
domínio, etc).

Acima: uma reunião diária acontecendo no canto mencionado.

Hmmmm..... aquele burndown parece suspeitosamente legal e direto, não. Mas a
equipe insiste que é real :o)

Scrum e XP direto das Trincheiras - Como nós fazemos Scrum

Scrum e XP direto das Trincheiras - Como nós fazemos Scrum

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

Similar a Scrum e XP direto das Trincheiras - Como nós fazemos Scrum

Similar a Scrum e XP direto das Trincheiras - Como nós fazemos Scrum (20)

Más de MBA em Marketing Digital e Gestão de Projetos Web

Más de MBA em Marketing Digital e Gestão de Projetos Web (20)

Último

Último (20)

Scrum e XP direto das Trincheiras - Como nós fazemos Scrum