Escolar Documentos
Profissional Documentos
Cultura Documentos
Traduo
Heitor Roriz Filho
Michel Goldenberg
Rafael Sabbagh
Reviso
Anderson Marcondes
nderson Quadros
Ari do Amaral Torres Filho
Marcos Garrido
Rafael Fuchs
Rafael Prikladnicki
Rodrigo de Toledo
Rafael Sabbagh (coordenao)
2
INTRODUO AO SCRUM
Scrum vem sendo utilizado para o desenvolvimento de produtos complexos
desde o incio dos anos 90. Este guia descreve como usar o Scrum para
desenvolver produtos. Scrum no um processo ou uma tcnica para o
desenvolvimento de produtos. Ao invs disso, um framework dentro do qual
voc pode empregar diversos processos e tcnicas. O papel do Scrum fazer
transparecer a eficcia relativa das suas prticas de desenvolvimento para que
voc possa melhor-las, enquanto prov um framework dentro do qual
produtos complexos podem ser desenvolvidos.
TEORIA DO SCRUM
Scrum, que fundamentado na teoria de controle de processos empricos,
emprega uma abordagem iterativa e incremental para otimizar a previsibilidade
e controlar riscos. Trs pilares sustentam qualquer implementao de controle
de processos empricos.
3
processo modificado pelo prprio ato da inspeo. O problema acontece
quando a frequncia de inspeo necessria excede a tolerncia do processo
inspeo. Os outros fatores so a habilidade e a aplicao das pessoas em
inspecionar os resultados do trabalho.
CONTEDO DO SCRUM
O framework Scrum consiste em um conjunto formado por Times Scrum e seus
papis associados, Eventos com Durao Fixa (Time-Boxes), Artefatos e
Regras.
4
desenvolvedores com todas as habilidades necessrias para transformar os
requisitos do Product Owner em um pedao potencialmente entregvel do
produto ao final da Sprint.
As Regras fazem o elo entre os eventos com durao fixa (time-boxes), os papis
e os artefatos do Scrum. Suas regras so descritas ao longo deste documento.
Por exemplo, uma regra do Scrum diz que somente membros do Time - as
pessoas comprometidas em transformar o Backlog do Produto em um
incremento - podem falar durante uma Reunio Diria. Modos de implementar
Scrum que no so regras, mas sim sugestes, esto descritas nas sees de
"Dicas".
5
PAPIS NO SCRUM
O Time Scrum composto pelo ScrumMaster, pelo Product Owner e pelo Time.
Os membros do Time Scrum so chamados porcos. Qualquer outra pessoa
chamada de galinha. Galinhas no podem dizer aos porcos como eles
devem fazer seu trabalho. Galinhas e porcos vm da seguinte histria:
Uma galinha e um porco esto juntos quando a galinha diz: Vamos abrir um
restaurante!
O porco diz: No, obrigado, eu estaria comprometido, mas voc estaria apenas
envolvida!
O SCRUMMASTER
O ScrumMaster responsvel por garantir que o Time Scrum esteja aderindo
aos valores do Scrum, s prticas e s regras. O ScrumMaster ajuda o Time
Scrum e a organizao a adotarem o Scrum. O ScrumMaster educa o Time
Scrum treinando-o e levando-o a ser mais produtivo e a desenvolver produtos
de maior qualidade. O ScrumMaster ajuda o Time Scrum a entender e usar
6
autogerenciamento e interdisciplinaridade. No entanto, o ScrumMaster no
gerencia o Time Scrum; o Time Scrum auto-organizvel.
O PRODUCT OWNER
O Product Owner a nica pessoa responsvel pelo gerenciamento do Backlog
do Produto e por garantir o valor do trabalho realizado pelo Time. Essa pessoa
mantm o Backlog do Produto e garante que ele est visvel para todos. Todos
sabem quais itens tm a maior prioridade, de forma que todos sabem em que se
ir trabalhar. O Product Owner uma pessoa, e no um comit. Podem existir
comits que aconselhem ou influenciem essa pessoa, mas quem quiser mudar a
prioridade de um item, ter que convencer o Product Owner. Empresas que
adotam Scrum podem perceber que isso influencia seus mtodos para definir
prioridades e requisitos ao longo do tempo.
7
Dica: O Product Owner pode ser um membro do Time, trabalhando tambm em
desenvolvimento. Mas essa responsabilidade adicional pode reduzir a sua
habilidade de lidar com as partes interessadas. No entanto, o Product Owner nunca
pode ser o ScrumMaster.
O TIME
Times de desenvolvedores transformam o Backlog do Produto em incrementos
de funcionalidades potencialmente entregveis em cada Sprint. Times tambm
so interdisciplinares: membros do Time devem possuir todo o conhecimento
necessrio para criar um incremento no trabalho. Membros do Time
frequentemente possuem conhecimentos especializados, como programao,
controle de qualidade, anlise de negcios, arquitetura, projeto de interface de
usurio ou projeto de banco de dados. No entanto, os conhecimentos que os
membros do Time devem compartilhar - isto , a habilidade de pegar um
requisito e transform-lo em um produto utilizvel - tendem a ser mais
importantes do que aqueles que eles no dividem. As pessoas que se recusam a
programar porque so arquitetas ou designers no se adaptam bem a Times.
Todos contribuem, mesmo que isso exija aprender novas habilidades ou
lembrar-se de antigas. No h ttulos em Times, e no h excees a essa regra.
Os Times tambm no contm subtimes dedicados a reas particulares como
testes ou anlise de negcios.
O tamanho timo para um Time de sete pessoas mais ou menos duas pessoas.
Quando h menos do que cinco membros em um Time, h menor interao e,
como resultado, h menor ganho de produtividade. Mais do que isso, o time
poder encontrar limitaes de conhecimento durante partes da Sprint e no
ser capaz de entregar uma parte pronta do produto. Se h mais do que nove
8
membros, h simplesmente a necessidade de muita coordenao. Times
grandes geram muita complexidade para que um processo emprico consiga
gerenciar. No entanto, temos encontrado alguns Times bem-sucedidos que
excederam os limites superior e inferior dessa faixa de tamanhos. O Product
Owner e o ScrumMaster no esto includos nessa conta, a menos que tambm
sejam porcos.
A composio do Time pode mudar ao final da Sprint. Toda vez que o Time
muda, a produtividade ganha atravs da auto-organizao reduzida. Deve-se
tomar cuidado ao mudar a composio do Time.
TIME-BOXES
Os Eventos com Durao Fixa (Time-Boxes) no Scrum so a Reunio de
Planejamento da Verso para Entrega, a Sprint, a Reunio de Planejamento
da Sprint, a Reviso da Sprint, a Retrospectiva da Sprint e a Reunio Diria.
9
Ao se utilizar Scrum, os produtos so construdos iterativamente, de modo que
cada Sprint cria um incremento do produto, iniciando pelo de maior valor e
maior risco. Mais e mais Sprints vo adicionando incrementos ao produto. Cada
incremento um pedao potencialmente entregvel do produto completo.
Quando j tiverem sido criados incrementos suficientes para que o produto
tenha valor e uso para seus investidores, o produto entregue.
A SPRINT
A Sprint uma iterao. Sprints so eventos com durao fixa. Durante a Sprint,
o ScrumMaster garante que no ser feita nenhuma mudana que possa afetar a
Meta da Sprint. Tanto a composio do time quanto as metas de qualidade
devem permanecer constantes durante a Sprint. As Sprints contm e consistem
na reunio de Planejamento de Sprint, o trabalho de desenvolvimento, a
Reviso da Sprint e a Retrospectiva da Sprint. As Sprints ocorrem uma aps a
outra, sem intervalos entre elas.
10
Um projeto serve para cumprir alguma funo. Em desenvolvimento de
software, o projeto utilizado para desenvolver um produto ou sistema. Cada
projeto consiste em uma definio do que ser desenvolvido, um plano para
desenvolv-lo, o trabalho realizado de acordo com o plano e o produto
resultante. Cada projeto possui um horizonte, que o perodo de tempo para o
qual o plano vlido. Se o horizonte for longo demais, a definio poder ter
mudado, variveis demais podero ter surgido, o risco poder ser grande
demais etc. Scrum um framework para projetos cujo horizonte no superior
ao perodo de um ms, onde j h complexidade suficiente tal que um
horizonte mais longo seria arriscado demais. A previsibilidade do projeto deve
ser controlada pelo menos a cada ms, e o risco de que o projeto saia de
controle ou se torne imprevisvel contido pelo menos a cada ms.
Dica: Se o time sentir que se comprometeu com mais do que podia, ele se encontra
com o Product Owner para remover ou reduzir o escopo do Backlog do Produto
selecionado para a Sprint. Se o time sentir que sobrar tempo, ele pode trabalhar
junto ao Product Owner para selecionar mais do Backlog do Produto.
Dica: Quando um Time comea com o Scrum, Sprints de duas semanas o permite
aprender sem se afundar na incerteza. Sprints desse tamanho podem ser
sincronizadas com outros Times adicionando-se dois incrementos juntos.
As Sprints podem ser canceladas antes que o prazo fixo da Sprint tenha
acabado. Somente o Product Owner tem a autoridade para cancelar a Sprint,
embora ele possa faz-lo sob influncia das partes interessadas, do Time ou do
ScrumMaster. Sob que tipo de circunstncias pode ser necessrio cancelar uma
Sprint? A gerncia pode precisar cancelar uma Sprint se a Meta da Sprint se
tornar obsoleta. Isso pode ocorrer se a empresa mudar de direo ou se as
condies do mercado ou tecnologia mudarem. Em geral, uma Sprint deve ser
cancelada se ela no fizer mais sentido dadas as circunstncias atuais. Porm,
por causa da curta durao das Sprints, raramente isso faz sentido.
11
Quando uma Sprint cancelada, todos os itens do Backlog do Produto que
estejam completados e "feitos" so revisados. Eles so aceitos se representarem
um incremento potencialmente entregvel. Todos os outros itens do Backlog do
Produto so devolvidos ao Backlog do Produto com suas estimativas iniciais.
Assume-se que qualquer trabalho realizado nesses itens perdido.
Cancelamentos de Sprints consomem recursos, j que todos tm que se
reagrupar em outra reunio de Planejamento de Sprint para iniciar uma nova
Sprint. Cancelamentos de Sprints so frequentemente traumticos para o Time,
e so muito incomuns.
12
a razo pela qual ele est desenvolvendo o incremento. A Meta da Sprint um
subconjunto da Meta da Verso para Entrega.
O motivo para se ter uma Meta da Sprint dar ao time alguma margem com
relao funcionalidade. Por exemplo, a meta para a Sprint acima poderia
tambm ser: Automatizar a funcionalidade de modificao de conta de clientes
atravs de um middleware seguro capaz de recuperar transaes. Conforme o
Time trabalha, ele mantm a meta em mente. Para satisfazer a meta, ele
implementa a funcionalidade e a tecnologia. Se o trabalho se mostrar mais difcil
do que o time esperava, o time ento ir colaborar com o Product Owner e
implementar a funcionalidade apenas parcialmente.
13
fornecerem conselhos tcnicos ou sobre o domnio em questo. Geralmente,
um Time novo percebe pela primeira vez se ir ganhar ou perder como um Time
- no individualmente - nessa reunio. O Time percebe que deve contar consigo
mesmo. Conforme ele percebe isso, ele comea a se auto-organizar para assumir
as caractersticas e comportamento de um verdadeiro Time.
REVISO DA SPRINT
Ao final da Sprint, feita uma reunio de Reviso da Sprint. Para Sprints de um
ms, essa uma reunio com durao fixa em quatro horas. Para Sprints de
duraes mais curtas, essa reunio no deve tomar mais do que 5% do total da
Sprint. Durante a Reviso da Sprint, o Time Scrum e as partes interessadas
colaboram sobre o que acabou de ser feito. Baseados nisso e em mudanas no
Backlog do Produto feitas durante a Sprint, eles colaboram sobre quais so as
prximas coisas que podem ser feitas. Essa uma reunio informal, com a
apresentao da funcionalidade, que tem a inteno de promover a
colaborao sobre o que fazer em seguida.
RETROSPECTIVA DA SPRINT
Aps a Reviso da Sprint e antes da prxima reunio de Planejamento da Sprint,
o Time Scrum tem uma reunio de Retrospectiva da Sprint. Nessa reunio, com
durao fixa em trs horas, o ScrumMaster encoraja o Time a revisar, dentro do
14
modelo de trabalho e das prticas do processo do Scrum, seu processo de
desenvolvimento, de forma a torn-lo mais eficaz e gratificante para a prxima
Sprint. Muitos livros documentam tcnicas que so teis em Retrospectivas.
REUNIO DIRIA
Cada time se encontra diariamente para uma reunio de 15 minutos chamada
Reunio Diria. Essa reunio sempre feita no mesmo horrio e no mesmo local
durante as Sprints. Durante a reunio, cada membro explica:
15
O ScrumMaster garante que o Time realize essa reunio. O Time resposvel
por conduzir a Reunio Diria. O ScrumMaster ensina o time a manter a Reunio
Diria com curta durao, reforando as regras e garantido que as pessoas falem
brevemente. O ScrumMaster tambm enfatiza a regra de que galinhas no esto
autorizadas a falar e nem a interferir de modo algum na Reunio Diria.
A Reunio Diria no uma reunio de status. Ela s para as pessoas que esto
transformando os itens do Backlog do Produto em um incremento (o Time), e
para mais ningum. O Time se comprometeu com uma Meta da Sprint, e a esses
itens do Backlog do Produto. A Reunio Diria uma inspeo do progresso na
direo da Meta da Sprint (as trs perguntas). Geralmente acontecem reunies
subsequentes para realizar adaptaes ao trabalho que est por vir na Sprint. A
inteno otimizar a probabilidade de que o Time alcance sua Meta. Essa
uma reunio fundamental de inspeo e adaptao no processo emprico do
Scrum.
ARTEFATOS DO SCRUM
Os artefatos do Scrum incluem o Backlog do Produto, o Burndown da Verso
para Entrega, o Backlog da Sprint e o Burndown da Sprint.
16
necessita para ser apropriado, competitivo e til. Enquanto existir um produto, o
Backlog de Produto tambm existir.
medida que um produto utilizado, que seu valor aumenta e que o mercado
fornece feedback, o Backlog do Produto torna-se uma lista maior e mais
aprofundada. Os requisitos nunca param de mudar. O Backlog do Produto um
documento vivo. Mudanas nos requisitos de negcios, condies do mercado,
tecnologia e equipe causam mudanas no Backlog do Produto. Para minimizar o
retrabalho, apenas os itens de maior prioridade precisam ser mais detalhados.
Os itens do Backlog do Produto que ocuparo os Times Scrum pelas vrias
Sprints seguintes devero ter granularidade mais fina, tendo sido decompostos
de forma tal que cada um dos itens possa ser feito dentro da durao da Sprint.
17
Dica: Os Times Scrum geralmente gastam 10% de cada Sprint preparando o
Backlog do Produto para adequ-lo definio de Backlog do Produto feita acima.
Quando estiverem adequados a esse nvel de granularidade, os itens no topo do
Backlog do Produto (de maior prioridade e de maior valor) so decompostos de
forma que caibam em um Sprint. Eles foram analisados e se refletiu sobre eles
durante esse processo de preparao. Quando ocorre a reunio de Planejamento de
Sprint, esses itens de maior prioridade do Backlog do Produto esto bem entendidos
e so facilmente selecionados.
18
mudanas, mas a estimativa final feita pelo Time. O Product Owner mantm o
Backlog do Produto e o Burndown do Backlog da Verso para Entrega
atualizados e publicados todo o tempo. Uma linha de tendncia pode ser
traada baseada na mudana do trabalho restante.
Dica: A linha de tendncia pode no ser confivel pelas duas ou trs primeiras
Sprints de uma verso, a menos que os times j tenham trabalhado juntos
anteriormente, conheam bem o produto e entendam a tecnologia envolvida.
19
estimadas de trabalho restantes para cada tarefa so atualizadas. Quando se
verifica que determinadas tarefas so desnecessrias, elas so removidas.
Somente o Time pode modificar o seu Backlog da Sprint durante uma Sprint.
Somente o Time pode mudar o seu contedo ou as suas estimativas. O Backlog
da Sprint um retrato em tempo real altamente visvel do trabalho que o Time
planeja efetuar durante a Sprint, e ele pertence unicamente ao Time.
Uma das regras do Scrum est ligada ao objetivo de cada Sprint, que ter como
resultado incrementos de funcionalidade potencialmente entregveis que
estejam de acordo com uma definio de pronto operacional.
PRONTO
Scrum exige que os Times desenvolvam um incremento de funcionalidade do
produto a cada Sprint. Esse incremento deve ser potencialmente entregvel,
pois o Product Owner pode optar por implantar a funcionalidade
imediatamente. Para isso ser possvel, o incremento deve ser um pedao
20
completo do produto. Ele deve estar pronto. Cada incremento deve ser
adicionado a todos os incrementos anteriores e exaustivamente testado,
garantindo que todos os incrementos funcionem juntos.
21
so criadas para cada incremento: o trabalho pronto e o trabalho no pronto. O
trabalho no pronto a poro de cada incremento que ter que ser completada
mais tarde. O Product Owner sabe exatamente o que ele est inspecionando ao
final da Sprint, porque o incremento atende definio de pronto e o Product
Owner entende essa definio. O trabalho no pronto adicionado a um item do
Backlog do Produto chamado trabalho no pronto, de forma que ele se acumula e
isso refletido corretamente no grfico de Burndown da Verso para Entrega. Essa
tcnica cria transparncia no progresso em direo entrega. A inspeo e a
adaptao na Reviso da Sprint sero to precisas quanto essa transparncia for.
Por exemplo, se um Time no capaz de realizar os testes de performance,
regresso, estabilidade, segurana e integrao para cada item do Backlog do
Produto, a proporo desse trabalho em relao ao trabalho que pode ser pronto
(anlise, projeto, refatoramento, programao, documentao, testes unitrio e
testes de usurio) calculada. Vamos supor que essa proporo de seis peas de
pronto e quatro peas de no pronto. Se o Time terminar um item de Backlog de
Produto de seis unidades de trabalho (o Time est estimando baseado no que ele
sabe como aprontar), quatro unidades sero acrescidas ao item do Backlog do
Produto denominado trabalho no pronto quando eles tiverem terminado. Sprint
a Sprint, o trabalho no pronto de cada incremento vai se acumulando e deve ser
tratado antes da entrega do produto. Esse trabalho acumulado linearmente,
embora haja algum tipo de acmulo exponencial que dependente das
caractersticas de cada organizao. Sprints de entrega so adicionados ao final de
cada verso para completar o trabalho no pronto. O nmero de Sprints
imprevisvel visto que o acmulo de trabalho no pronto no linear.
Algumas tcnicas teis para conduzir uma Retrospectiva em Scrum podem ser
encontradas em:
Agile Retrospectives: Making Good Teams Great, Esther Derby e Diana Larsen,
Pragmatic Bookshelf, 2006.
User Stories Applied: For Agile Software Development, Mike Cohn, Addison-Wesley,
2004.
22