Escolar Documentos
Profissional Documentos
Cultura Documentos
Scrum Guide PDF
Scrum Guide PDF
Outubro de 2011
Leve
Simples de entender
Extremamente difcil de dominar
Scrum um framework estrutural que est sendo usada para gerenciar o desenvolvimento de
produtos complexos desde o incio de 1990. Scrum no um processo ou uma tcnica para
construir produtos; em vez disso, um framework dentro do qual voc pode empregar vrios
processos ou tcnicas. O Scrum deixa claro a eficcia relativa das prticas de gerenciamento e
desenvolvimento de produtos, de modo que voc possa melhor-las.
Framework Scrum
O framework Scrum consiste nas equipes do Scrum associadas a papis, eventos, artefatos e
regras. Cada componente dentro do framework serve a um propsito especfico e essencial
para o uso e sucesso do Scrum.
Transparncia
Aspectos significativos do processo devem estar visveis aos responsveis pelos resultados.
Esta transparncia requer aspectos definidos por um padro comum para que os observadores
compartilharem um mesmo entendimento do que est sendo visto.
Por exemplo:
Uma linguagem comum referindo-se ao processo deve ser compartilhada por todos os
participantes; e,
Uma definio comum de Pronto1 deve ser compartilhada por aqueles que realizam o
trabalho e por aqueles que aceitam o resultado do trabalho.
Inspeo
Os usurios Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso em
direo ao objetivo, para detectar indesejveis variaes. Esta inspeo,no deve no entanto,
ser to freqente que atrapalhe a prpria execuo das tarefas. As inspees so mais
benficas quando realizadas de forma diligente por inspetores especializados no trabalho a se
verificar.
Adaptao
Se um inspetor determina que um ou mais aspectos de um processo desviou para fora dos
limites aceitveis, e que o produto resultado ser inaceitvel, o processo ou o material sendo
produzido deve ser ajustado. O ajuste deve ser realizado o mais breve possvel para minimizar
mais desvios.
O Scrum prescreve quatro oportunidades formais para inspeo e adaptao, como descrito
na seo Eventos do Scrum deste documento.
1
Veja definio de Pronto, p. 15
O Time Scrum
O Time Scrum composto pelo Product Owner, a Equipe de Desenvolvimento e o Scrum
Master. Times Scrum so auto-organizveis e multifuncionais. Equipes auto-organizveis
escolhem qual a melhor forma para completarem seu trabalho, em vez de serem dirigidos por
outros de fora da equipe. Equipes multifuncionais possuem todas as competncias necessrias
para completar o trabalho sem depender de outros que no fazem parte da equipe. O modelo
de equipe no Scrum projetado para aperfeioar a flexibilidade, criatividade e produtividade.
O Product Owner
O Product Owner, ou dono do produto, o responsvel por maximizar o valor do produto e do
trabalho da equipe de Desenvolvimento. Como isso feito pode variar amplamente atravs
das organizaes, Times Scrum e indivduos.
O Product Owner pode fazer o trabalho acima, ou delegar para a Equipe de Desenvolvimento
faz-lo. No entanto, o Product Owner continua sendo o responsvel pelos trabalhos.
O Product Owner uma pessoa e no um comit. O Product Owner pode representar o desejo
de um comit no Backlog do Produto, mas aqueles que quiserem uma alterao nas
prioridades dos itens de Backlog devem convencer o Product Owner.
Equipe de Desenvolvimento
A Equipe de Desenvolvimento consiste de profissionais que realizam o trabalho de entregar
uma verso usvel que potencialmente incrementa o produto Pronto ao final de cada Sprint.
Somente integrantes da Equipe de Desenvolvimento criam incrementos.
O Scrum Master ajuda aqueles que esto fora do Time Scrum a entender quais as suas
interaes com o Time Scrum so teis e quais no so. O Scrum Master ajuda todos a
mudarem estas interaes para maximizar o valor criado pelo Time Scrum.
Alm da Sprint, que um container para outros eventos, cada evento no Scrum uma
oportunidade de inspecionar e adaptar alguma coisa. Estes eventos so especificamente
projetados para permitir uma transparncia e inspeo criteriosa. A no incluso de qualquer
um dos eventos resultar na reduo da transparncia e da perda de oportunidade para
inspecionar e adaptar.
Sprint
O corao do Scrum a Sprint, um time-box de um ms ou menos, durante o qual um
Pronto, verso incremental potencialmente utilizvel do produto, criado. Sprints tem
duraes coerentes em todo o esforo de desenvolvimento. Uma nova Sprint inicia
imediatamente aps a concluso da Sprint anterior.
Durante a Sprint:
Cada Sprint pode ser considerada um projeto com horizonte no maior que um ms. Como os
projetos, as Sprints so utilizadas para realizar algo. Cada Sprint tem a definio do que para
ser construdo, um plano projetado e flexvel que ir guiar a construo, o trabalho e o
resultado do produto.
Cancelamento da Sprint
Uma Sprint pode ser cancelada antes do time-box da Sprint terminar. Somente o Product
Owner tem a autoridade para cancelar a Sprint, embora ele (ou ela) possa fazer isso sob
influncia das partes interessadas, da Equipe de Desenvolvimento ou do Scrum Master.
O cancelamentos de Sprints consome recursos, j que todos tem que se reagrupar em outra
reunio de planejamento da Sprint para iniciar outra Sprint. Cancelamentos de Sprints so
frequentemente traumticos para o Time Scrum, e so muito incomuns.
A reunio de planejamento da Sprint uma time-box de oito horas para uma Sprint de um ms
de durao. Para Sprints menores, este evento deve ser proporcionalmente menor. Por
exemplo, uma Sprint de duas semanas ter uma reunio de planejamento de Sprint de quatro
horas.
A reunio de planejamento da Sprint consiste em duas partes, cada uma sendo uma time-box
de metade do tempo de durao da reunio de planejamento da Sprint. As duas partes da
reunio de planejamento da Sprint respondem as seguintes questes, respectivamente:
O Product Owner pode estar presente durante a segunda parte da reunio de planejamento
da Sprint, para clarificar os itens do Backlog do Produto selecionados e para ajudar nas
decises conflituosas de troca. Se a Equipe de Desenvolvimento determina que tem excesso
ou falta de trabalho, os itens do Backlog da Sprint pode ser renegociados com o Product
Owner. A Equipe de Desenvolvimento tambm pode convidar outras pessoas para participar
desta reunio de forma a fornecer opinio tcnica ou de domnios especficos.
O objetivo da Sprint pode ser um marco contido no propsito maior no roteiro do produto.
Reunio Diria
A Reunio Diria do Scrum um evento time-boxed de 15 minutos, para que a Equipe de
Desenvolvimento possa sincronizar as atividades e criar um plano para as prximas 24 horas.
A Reunio Diria mantida no mesmo horrio e local todo dia para reduzir a complexidade.
Durante a reunio cada integrante da Equipe de Desenvolvimento esclarece:
O Scrum Master assegura que a Equipe de Desenvolvimento tenha a reunio, mas a Equipe de
Desenvolvimento responsvel por conduzir a Reunio Diria. O Scrum Master ensina a
Equipe de Desenvolvimento a manter a Reunio Diria dentro da time-box de 15 minutos.
Reviso da Sprint
A Reviso da Sprint executada no final da Sprint para inspecionar o incremento e adaptar o
Backlog do Produto se necessrio. Durante a reunio de Reviso da Sprint o Time Scrum e as
partes interessadas colaboram sobre o que foi feito na Sprint. Com base nisso e em qualquer
mudana no Backlog do Produto durante a Sprint, os participantes colaboram nas prximas
coisas que precisam ser prontas. Esta uma reunio informal, e a apresentao do incremento
destina-se a motivar e obter comentrios e promover a colaborao.
Esta uma reunio time-boxed de 4 horas de durao para uma Sprint de um ms.
Proporcionalmente um tempo menor alocado para Sprints menores. Por exemplo, uma
Sprint de duas semanas tem Reunies de Reviso de duas horas.
Retrospectiva da Sprint
A Retrospectiva da Sprint uma oportunidade para o Time Scrum inspecionar a si prprio e
criar um plano para melhorias a serem aplicadas na prxima Sprint.
Ao final da Retrospectiva da Sprint, o Time Scrum dever ter identificado melhorias que sero
implementadas na prxima Sprint. A implementao destas melhorias na prxima Sprint a
forma de adaptao inspeo que o Time Scrum faz a si prprio. A Retrospectiva da Sprint
fornece um evento dedicado e focado na inspeo e adaptao, no entanto, as melhorias
podem ser adotadas a qualquer momento.
Artefatos do Scrum
Os artefatos do Scrum representam o trabalho ou o valor das vrias maneiras que so teis no
fornecimento de transparncia e oportunidades para inspeo e adaptao. Os artefatos
definidos para o Scrum so especificamente projetados para maximizar a transparncia das
informaes chave necessrias para assegurar que o Time Scrum tenha sucesso na entrega do
incremento Pronto.
Os itens do Backlog do Produto de ordem mais alta (topo da lista) devem ser mais claros e
mais detalhados que os itens de ordem mais baixa. Estimativas mais precisas so feitas com
base na maior clareza e maior detalhe; Quanto menor a ordem na lista, menor so os detalhes.
Os itens do Backlog do Produto que iro ocupar o desenvolvimento na prxima Sprint so mais
refinados, tendo sido decompostos de modo que todos os itens possam ser Prontos dentro
do time-box da Sprint. Os itens do Backlog do Produto que podem ser Prontos pela Equipe
de Desenvolvimento dentro da Sprint so considerados como disponveis ou executveis
para seleo na Reunio de Planejamento da Sprint.
Preparar o Backlog do Produto uma atividade de tempo parcial, durante a Sprint, entre o
Product Owner e a Equipe de Desenvolvimento. Geralmente a Equipe de Desenvolvimento
tem o domnio do conhecimento para realizar a preparao por si prpria. Como e quando a
preparao considerada pronta uma deciso do Time Scrum. Esta preparao usualmente
no consome mais de 10% da capacidade da Equipe de Desenvolvimento.
Vrias prticas como burndown, burnup e outras prticas de estimativa tem sido usadas para
prever o progresso. Estas tem se provado teis. Contudo, no substituem a importncia do
empirismo. Em ambientes complexos, o que acontecer desconhecido. Somente o que tem
acontecido pode ser usado para uma tomada de deciso a respeito do que vir.
Backlog da Sprint
O Backlog da Sprint um conjunto de itens do Backlog do Produto selecionados para a Sprint,
juntamente com o plano de entrega do incremento do produto e atingir o objetivo da Sprint. O
Backlog da Sprint a previso da Equipe de Desenvolvimento sobre qual funcionalidade estar
no prximo incremento e do trabalho necessrio para entregar a funcionalidade.
O Backlog da Sprint define qual trabalho a Equipe de Desenvolvimento realizar para converter
os itens do Backlog do Produto em um incremento Pronto. O Backlog do Produto torna
visvel todo o trabalho que a Equipe de Desenvolvimento identifica como necessrio para
atingir o objetivo da Sprint.
O Backlog da Sprint um plano com detalhes suficientes que as mudanas em progresso sejam
entendidas durante a Reunio Diria. A Equipe de Desenvolvimento modifica o Backlog da
Sprint ao longo de toda a Sprint, e o Backlog da Sprint vai surgindo durante a Sprint. Este
surgimento ocorre quando a Equipe de Desenvolvimento trabalha segundo o plano e aprende
mais sobre o trabalho necessrio para alcanar o objetivo da Sprint.
O Scrum no considera o tempo gasto trabalhando nos itens do Backlog da Sprint. O trabalho
restante e a data so as nicas variveis que interessam.
Incremento
O incremento a soma de todos os itens do Backlog do Produto completados durante a Sprint
e tudo das Sprints anteriores. Ao final da Sprint um novo incremento deve estar Pronto, o
que significa que deve estar na condio utilizvel e atender a definio de Pronto do Time
Scrum. Este deve estar na condio utilizvel independente do Product Owner decidir por
liber-lo realmente ou no.
Definio de Pronto
Quando o item do Backlog do Produto ou um incremento descrito como Pronto, todos
devem entender o que o Pronto significa. Embora, isso varie significativamente de um
extremo ao outro para cada Time Scrum, os integrantes devem ter um entendimento
compartilhado do que significa o trabalho estar completo, assegurando a transparncia. Esta
a Definio de Pronto para o Time Scrum e usado para assegurar quando o trabalho esta
completado no incremento do produto.
Com um Time Scrum maduro, esperado que a sua definio de Pronto seja expandida para
incluir critrios mais rigorosos de alta qualidade.
Histria
Ken Schwaber e Jeff Sutherland fizeram a primeira co-apresentao do Scrum na conferncia
OOPSLA de 1995. Esta apresentao essencialmente documentou o aprendizado que Ken e Jeff
tiveram ao longo dos anos anteriores na aplicao do Scrum.
A histria do Scrum j considerada longa. Para homenagear os primeiros lugares onde ele foi
experimentado e refinado, ns reconhecemos a Individual, Inc., Fidelity Investments, and IDX
(atual GE Medical).
Traduo
Este guia foi traduzido da verso original em ingls, fornecido por Ken Schwaber e Jeff
Sutherland. Os colaboradores desta traduo incluem Fbio Rodrigues Cruz, e Rafael Sabbagh.
O Guia do Scrum documenta o Scrum como foi desenvolvido e mantido por mais de vinte anos
por Jeff Sutherland e Ken Schwaber. Outras fontes fornecem padres, processos, e percepes
sobre como as prticas, facilitadores e ferramentas complementam o framework do Scrum.
Estes aperfeioam a produtividade, valor, criatividade e orgulho.