scrum guide - ptbr
TRANSCRIPT
-
8/7/2019 Scrum Guide - PTBR
1/23
Fevereiro 2010
Scrum: Desenvolvido e mantido por Ken Schwaber e Jeff Sutherland
-
8/7/2019 Scrum Guide - PTBR
2/23
2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 2
Agradecimentos
Geral
Scrum baseado nas melhores prticas aceitas pelo mercado,
utilizadas e provadas por dcadas. Ele definido ento em uma teoriade processos empricos. Como Jim Coplien certa vez observou para o
Jeff, Todos iro gostar de Scrum; isso o que j fazemos quando nos
pressionam contra a parede.
Pessoas
Das milhares de pessoas que contribuiram para o Scrum, devemos
destacar aquelas que contribuiram em seus primeiros dez anos.
Primeiro havia o Jeff Sutherland, trabalhando com o Jeff McKenna, e
Ken Schwaber com Mike Smith e Chris Martin. Scrum foi formalmente
apresentado e publicado no OOPSLA 1995. Durante os cinco anos
seguintes, Mike Beadle e Martine Devos fizeram contribuies
significativas. E ento todos os outros, que sem a sua ajuda o Scrum
no teria sido aprimorado no que atualmente.
HistriaA histria do Scrum j pode ser considerada longa no mundo de
desenvolvimento de software. Para honrar os primeiros lugares onde
foi testado e aprimorado, honramos a Individual, Inc., Fidelity
Investments e IDX (hoje GE Medical).
Traduo
Este guia foi traduzido da verso original em ingls, fornecida por Ken
Schwaber e Jeff Sutherland. Em ordem alfabtica, realizaram atraduo: Heitor Roriz Filho, Michel Goldenberg e Rafael Sabbagh.
Realizaram a reviso os integrantes do grupo scrumguide_br,
inicialmente formado por: Anderson Marcondes, nderson Quadros, Ari
do Amaral Torres Filho, Marcos Garrido, Rafael Fuchs, Rafael
Prikladnicki, Rodrigo de Toledo e Rafael Sabbagh (coordenao).
-
8/7/2019 Scrum Guide - PTBR
3/23
-
8/7/2019 Scrum Guide - PTBR
4/23
2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 4
outros fatores so a habilidade e a aplicao das pessoas em
inspecionar os resultados do trabalho.
O terceiro pilar a adaptao
Se o inspetor determinar, a partir da inspeo, que um ou maisaspectos do processo esto fora dos limites aceitveis e que o produto
resultante ser inaceitvel, ele dever ajustar o processo ou o material
sendo processado. Esse ajuste deve ser feito o mais rpido possvel
para minimizar desvios posteriores.
Existem trs pontos para inspeo e adaptao em Scrum. A Daily
Scrum uma reunio utilizada para inspecionar o progresso em
direo Meta da Sprint e para realizar adaptaes que otimizem o
valor do prximo dia de trabalho. Alm disso, as reunies de Revisoda Sprint e de Planejamento da Sprint so utilizadas para inspecionaro progresso em direo Meta da Release e para fazer as adaptaes
que otimizem o valor da prxima Sprint. Finalmente, a Retrospectiva
da Sprint utilizada para revisar a Sprint passada e definir que
adaptaes tornaro a prxima Sprint mais produtiva,
recompensadora e gratificante.
Contedo do ScrumO frameworkScrum consiste em um conjunto formado por Times de
Scrum e seus papis associados, Time-Boxes (eventos com durao
fixa), Artefatos e Regras.
Times de Scrum so projetados para otimizar flexibilidade e
produtividade. Para esse fim, eles so auto-organizveis,
multidisciplinares e trabalham em iteraes. Cada Time de Scrum
possui trs papis: 1) o ScrumMaster, que responsvel por garantir
que o processo seja compreendido e seguido; 2) o Product Owner,que responsvel por maximizar o valor do trabalho que o Time de
Scrum faz; e 3) o Time, que executa o trabalho propriamente dito. O
Time consiste em desenvolvedores com todas as habilidades
necessrias para transformar os requisitos do Product Owner em um
pedao potencialmente entregvel do produto ao final da Sprint.
-
8/7/2019 Scrum Guide - PTBR
5/23
2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 5
Scrum emprega eventos com durao fixa os time-boxes para criar
regularidade. Entre os elementos do Scrum que tm durao fixa,
temos a Reunio de Planejamento da Release, a Reunio de
Planejamento da Sprint, a Sprint, a Daily Scrum, a Reviso da
Sprint e a Retrospectiva da Sprint. O corao do Scrum a Sprint,que uma iterao de um ms ou menos, de durao consistente com
o esforo de desenvolvimento. Todas as Sprints utilizam o mesmo
modelo de Scrum e todas as Sprints tm como resultado um
incremento do produto final que potencialmente entregvel. Cada
Sprint comea imediatamente aps a anterior.
Scrum utiliza quatro artefatos principais. O Product Backlog uma
lista priorizada de tudo que pode ser necessrio no produto. O Sprint
Backlog uma lista de tarefas para transformar o Product Backlog,por uma Sprint, em um incremento do produto potencialmente
entregvel. Um burndown uma medida do backlog restante pelo
tempo. Um Burndown de Release mede o Product Backlog restante
ao longo do tempo de um plano de release. Um Burndown de Sprint
mede os itens do Sprint Backlog restantes ao longo do tempo de umaSprint.
As Regras fazem o elo entre os
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
Product Backlog em um
incremento - podem falar duranteuma Daily Scrum. Modos de
implementar Scrum que no so
regras, mas sim sugestes, esto descritas nas sees de "Dicas".
Dica
Quando as regras no sodeclaradas, espera-se que osusurios de Scrum descubramo que devem fazer. No tentedescobrir uma soluoperfeita, porque geralmente oproblema muda rapidamente.Ao invs disso, tente algo eveja como se sai. Osmecanismos de inspeo-e-adaptao inerentes natureza emprica de Scrumiro lhe guiar.
-
8/7/2019 Scrum Guide - PTBR
6/23
2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 6
Papis no Scrum
O Time de Scrum composto pelo ScrumMaster, pelo Product Owner e
pelo Time. Os membros do Time de Scrum so chamados porcos. O
Product Owner o porco do Product Backlog. O Time o porco do
trabalho da Sprint. O ScrumMaster o porco do processo do Scrum.
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 reflete e ento diz:Como seria o nome desse
restaurante?
A galinha diz: Presunto com
Ovos!
O porco diz: No, obrigado, eu
estaria comprometido, mas voc
estaria apenas envolvida!
O ScrumMaster
O ScrumMaster responsvel por
garantir que o Time de Scrum
esteja aderindo aos valores do
Scrum, s prticas e s regras. O
ScrumMaster ajuda o Time de
Scrum e a organizao a adotaremo Scrum. O ScrumMaster educa o
Time de Scrum treinando-o e
levando-o a ser mais produtivo e a
desenvolver produtos de maior
qualidade. O ScrumMaster ajuda o
Dica
O ScrumMaster trabalha comos clientes e a gerncia para
identificar e designar umProduct Owner. OScrumMaster ensina aoProduct Owner como fazerseu trabalho. Espera-se dosProduct Owners que elessaibam como conseguirotimizar valor atravs doScrum. Se eles nosouberem, consideramos oScrumMaster responsvel.
Dica
O ScrumMaster pode ser ummembro do Time; porexemplo, um desenvolvedorrealizando tarefas da Sprint.No entanto, issofrequentemente leva a
conflitos quando oScrumMaster deve escolherentre remover impedimentose realizar tarefas. OScrumMaster nunca deve sero Product Owner.
-
8/7/2019 Scrum Guide - PTBR
7/23
2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 7
Time de Scrum a entender e usar auto-organizao e
multidisciplinaridade. O ScrumMaster tambm ajuda o Time de Scrum
a fazer o seu melhor em um ambiente organizacional que pode ainda
no ser otimizado para o desenvolvimento de produtos complexos.
Quando o ScrumMaster ajuda a realizar essas mudanas, isso chamado de remoo de impedimentos. O papel de ScrumMaster o
de lder-servidor para o Time de Scrum.
O Product Owner
O Product Owner a nica pessoa
responsvel pelo gerenciamento
do Product Backlog e por garantir
o valor do trabalho realizado peloTime. Essa pessoa mantm o
Product Backlog 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 existircomits que aconselhem ou
influenciem essa pessoa, mas
quem quiser mudar a prioridade
de um item, ter que convencer o
Product Owner. Empresas queadotam Scrum podem perceber
que isso influencia seus mtodos
para definir prioridades e
requisitos ao longo do tempo.
Para que o Product Owner obtenha sucesso, todos na organizao
precisam respeitar suas decises. Ningum tem a permisso de dizer
ao Time para trabalhar em um outro conjunto de prioridades, e os
Times no podem dar ouvidos a ningum que diga o contrrio. As
Dica
Para desenvolvimento
comercial, o Product Ownerpode ser o Gerente de Produto.Para esforos internos dedesenvolvimento, o ProductOwner poderia ser o gerente dafuno de negcios em que seest trabalhando.
Dica
O Product Owner pode ser ummembro do Time, trabalhandotambm em desenvolvimento.Mas essa responsabilidadeadicional pode reduzir a suahabilidade de lidar com aspartes interessadas. Noentanto, o Product Ownernunca pode ser o ScrumMaster.
-
8/7/2019 Scrum Guide - PTBR
8/23
2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 8
decises do Product Owner so visveis no contedo e na priorizao
do Product Backlog. Essa visibilidade requer que o Product Owner faa
seu melhor, o que faz o papel de Product Owner exigente e
recompensador ao mesmo tempo.
O Time
Times de desenvolvedores transformam o Product Backlog em
incrementos de funcionalidades potencialmente entregveis em cada
Sprint. Times tambm so multidisciplinares: 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 deusurio ou projeto de banco de dados. No entanto, o conhecimento
que os membros do Time devem compartilhar - isto , a habilidade de
trabalhar 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 comotestes ou anlise de negcios.
Times tambm so auto-organizveis. Ningum nem mesmo o
ScrumMaster diz ao time como transformar o Product Backlog em
incrementos de funcionalidades entregveis. O Time descobre por sis. Cada membro do Time aplica sua especialidade a todos os
problemas. A sinergia que resulta disso melhora a eficincia e eficcia
geral do Time como um todo.
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
-
8/7/2019 Scrum Guide - PTBR
9/23
2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 9
uma parte pronta do produto. Se h mais do que nove 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, trabalhando em tarefas do Sprint
Backlog.
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-BoxesOs time-boxes no Scrum so a Reunio de Planejamento daRelease, a Sprint, a Reunio de Planejamento da Sprint, a
Reviso da Sprint, a Retrospectiva da Sprint e a Daily Scrum.
Reunio de Planejamento da Release
O propsito do planejamento da release o de estabelecer um plano e
metas que o Time de Scrum e o resto da organizao possam
entender e comunicar. O planejamento da release responde squestes: Como podemos transformar a viso em um produtovencedor da melhor maneira possvel? Como podemos alcanar ou
exceder a satisfao do cliente e o Retorno sobre Investimento (ROI)
desejados? O plano da release estabelece a meta da release, as
maiores prioridades do Product Backlog, os principais riscos e as
caractersticas gerais e funcionalidades que estaro contidas na
release. Ele estabelece tambm uma data de entrega e custo
provveis que devem se manter se nada mudar. A organizao podeento inspecionar o progresso e fazer mudanas nesse plano da
release a cada Sprint.
O planejamento da release inteiramente opcional. Se um Time de
Scrum iniciar o trabalho sem essa reunio, a ausncia de seus
artefatos aparecer como um impedimento que dever ser resolvido.
-
8/7/2019 Scrum Guide - PTBR
10/23
2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 10
O trabalho para resolver o impedimento se tornar um item no Product
Backlog.
Ao se utilizar Scrum, os produtos so construdos iterativamente, de
modo que cada Sprint cria um incremento do produto, iniciando pelode 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.
Muitas organizaes j possuem um processo de planejamento de
release, e na maior parte desses processos o planejamento feito no
incio do trabalho da release e no modificado com o passar dotempo. No planejamento de release do Scrum, so definidos uma meta
geral e resultados provveis. Esse planejamento geralmente no
requer mais do que 15-20% do tempo que uma organizao
costumava utilizar para produzir um plano de release tradicional. No
entanto, uma release com Scrum realiza planejamento no momento da
execuo de cada reunio de Reviso de Sprint e de Planejamento deSprint, da mesma forma que realiza um planejamento dirio no
momento da execuo de cada Daily Scrum. De forma geral, os
esforos para uma release com Scrum provavelmente consomem
ligeiramente mais esforo do que os esforos para um planejamento
de release tradicional.
O planejamento da release requer estimar e priorizar o Product
Backlog para a release. H diversas tcnicas para faz-lo que esto
fora do alcance do Scrum, mas que apesar disso so teis quando
usadas com ele.
-
8/7/2019 Scrum Guide - PTBR
11/23
2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 11
A Sprint
A Sprint uma iterao. Sprints
tm 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 dedesenvolvimento, a Reviso da Sprint e a Retrospectiva da Sprint. As
Sprints ocorrem uma aps a outra, sem intervalos entre elas.
Um projeto serve para cumprir
alguma funo. Em
desenvolvimento de software, o
projeto utilizado para
desenvolver um produto ou
sistema. Cada projeto consiste emuma 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 sergrande 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
Dica
Quando um Time comea com oScrum, Sprints de duas
semanas o permite aprendersem se afundar na incerteza.Sprints desse tamanho podemser sincronizadas com outrosTimes adicionando-se doisincrementos juntos.
Dica
Se o time sentir que secomprometeu com mais do quepodia, ele se encontra com oProduct Owner para remover oureduzir o escopo do ProductBacklog selecionado para aSprint. Se o time sentir quesobrar tempo, ele podetrabalhar junto ao ProductOwner para selecionar mais doProduct Backlog.
-
8/7/2019 Scrum Guide - PTBR
12/23
2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 12
menos a cada ms, e o risco de que o projeto saia de controle ou se
torne imprevisvel contido pelo menos a cada ms.
As Sprints podem ser canceladas antes que o prazo fixo da Sprint
tenha acabado. Somente o Product Owner tem a autoridade paracancelar 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.
Quando uma Sprint cancelada, todos os itens do Product Backlog
que estejam completados e "feitos" so revisados. Eles so aceitos se
representarem um incremento potencialmente entregvel. Todos os
outros itens do Product Backlog so devolvidos ao Product Backlog
com suas estimativas iniciais. Assume-se que qualquer trabalhorealizado 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.
Reunio de Planejamento da Sprint
A Reunio de Planejamento da Sprint o momento no qual a iterao
planejada. fixada em oito horas de durao para uma Sprint de um
ms. Para Sprints mais curtas, deve-se alocar proporcionalmente ao
tamanho total da Sprint para essa reunio (por exemplo, para duassemanas teramos uma Reunio de Planejamento da Sprint de quatro
horas). A Reunio de Planejamento da Sprint consiste de duas partes.
A primeira parte o momento no qual decidido o que ser feito na
Sprint. A segunda parte (com durao fixa de quatro horas para uma
Sprint de um ms) o momento no qual o Time entende como
-
8/7/2019 Scrum Guide - PTBR
13/23
2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 13
desenvolver essa funcionalidade em um incremento do produto
durante a Sprint.
H duas partes na Reunio de Planejamento da Sprint: a parte do o
qu? e a parte do como?. Alguns Times de Scrum juntam as duas.Na primeira parte, o Time de Scrum trata da questo do o qu?.
Aqui, o Product Owner apresenta ao Time o que mais prioritrio no
Product Backlog. Eles trabalham em conjunto para definir qual
funcionalidade dever ser desenvolvida durante a prxima Sprint. As
entradas para essa reunio so o Product Backlog, o incremento mais
recente ao produto, a capacidade do Time e o histrico de
desempenho do Time. Cabe somente ao Time a deciso de quanto do
Backlog ele deve selecionar. Somente o Time pode avaliar o que ele
capaz de realizar na prxima Sprint.
Uma vez selecionado o Product Backlog, a Meta da Sprint delineada.
A Meta da Sprint o objetivo que ser atingido atravs da
implementao do Product Backlog. Ela uma descrio que fornece
orientao ao Time sobre a razo pela qual ele est desenvolvendo o
incremento. A Meta da Sprint um subconjunto da Meta da Release.
O motivo para se ter uma Meta da Sprint dar ao time alguma
margem com relao funcionalidade. Por exemplo, a meta para aSprint 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 trabalhar em conjunto com o
Product Owner e implementar a funcionalidade apenas parcialmente.
Na segunda parte da Reunio de Planejamento da Sprint, o Time trata
a questo do como?. Durante a segunda parte da Reunio de
Planejamento da Sprint (com durao fixa de quatro horas paraSprints de um ms), o Time define como transformar o Product
Backlog selecionado durante a Reunio de Planejamento (o qu) em
um incremento pronto. O Time geralmente comea projetando o
-
8/7/2019 Scrum Guide - PTBR
14/23
2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 14
trabalho. Enquanto projeta, o time identifica tarefas. Essas tarefas so
pedaos detalhados do trabalho necessrio para converter o Product
Backlog em software funcional. As tarefas devem ser decompostas
para que possam ser feitas em menos de um dia. Essa lista de tarefas
chamada de Sprint Backlog. O time se auto-organiza para seresponsabilizar pelo trabalho contido no Sprint Backlog, tanto durante
a Reunio de Planejamento da Sprint quanto no prprio momento da
execuo da Sprint.
O Product Owner est presente
durante a segunda parte da
Reunio de Planejamento da
Sprint para esclarecer o Product
Backlog e para ajudar a efetuartrocas. Se o Time concluir que
ele tem trabalho demais ou de
menos, ele pode renegociar o
Product Backlog escolhido com o
Product Owner. O Time tambmpode convidar outras pessoas a participarem da reunio para
fornecerem conselhos tcnicos ou sobre o domnio em questo.
Geralmente, um Time novo percebe pela primeira vez se ir ganhar ouperder 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 a reunio de Reviso da Sprint. Para Sprints
de um ms, essa uma reunio com durao fixa de quatro horas.
Para Sprints de duraes mais curtas, deve-se alocar
proporcionalmente menos do tamanho total da Sprint para essa
reunio (por exemplo, para duas semanas deve-se ter uma Reviso da
Sprint de duas horas). Durante a Reviso da Sprint, o Time de Scrum
e as partes interessadas colaboram sobre o que acabou de ser feito.
Dica
Geralmente, somente 60-70%do total do Sprint Backlog serdefinido na Reunio de
Planejamento da Sprint. Orestante deixado para serdetalhado mais tarde ou sodadas estimativas grandes quesero decompostas mais tardena Sprint
-
8/7/2019 Scrum Guide - PTBR
15/23
-
8/7/2019 Scrum Guide - PTBR
16/23
2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 16
ferramentas, definio de pronto, mtodos de comunicao e
processos para transformar itens do Product Backlog em alguma coisa
pronta. No final da Retrospectiva da Sprint, o Time de Scrum deve
ter identificado medidas de factveis melhoria que ele implementar na
prxima Sprint. Essas mudanas se tornam a adaptao para ainspeo emprica.
Daily Scrum
Cada time se encontra diariamente para uma reunio de 15 minutos
chamada Daily Scrum. Essa reunio sempre feita no mesmo horrio
e no mesmo local durante as Sprints. Durante a reunio, cada membro
explica:
1. O que ele realizou desde a ltima reunio;
2. O que ele vai fazer antes da prxima reunio; e
3. Quais obstculos esto em seu caminho.
As Daily Scrums melhoram a comunicao, eliminam outras reunies,
identificam e removem impedimentos para o desenvolvimento,
ressaltam e promovem a tomada rpida de decises e melhoram o
nvel de conhecimento de todos acerca do projeto.
O ScrumMaster garante que o Time realize essa reunio. O Time
resposvel por conduzir a Daily Scrum. O ScrumMaster ensina o time a
manter a Daily Scrum 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 Daily Scrum.
A Daily Scrum no uma reunio de status. Ela s para as pessoasque esto transformando os itens do Product Backlog em um
incremento (o Time), e para mais ningum. O Time se comprometeu
com uma Meta da Sprint, e a esses itens do Product Backlog. A Daily
Scrum uma inspeo do progresso na direo da Meta da Sprint (as
trs perguntas). Geralmente acontecem reunies subsequentes para
-
8/7/2019 Scrum Guide - PTBR
17/23
2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 17
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 Product Backlog, o Burndown da
Release, o Sprint Backlog e o Burndown da Sprint.
Product Backlog e Burndown da Release
Os requisitos para o produto que o(s) Time(s) est(o) desenvolvendo
esto listados no Product Backlog. O Product Owner o responsvel
pelo Product Backlog, por seu contedo, por sua disponibilidade e porsua priorizao. O Product Backlog nunca est completo. A seleo
inicial para o seu desenvolvimento somente mostra os requisitos
inicialmente conhecidos e melhor entendidos. O Product Backlog evolui
medida que o produto e o ambiente em que ele ser usado evoluem.
O Backlog dinmico, no sentido de que ele est constantemente
mudando para identificar o que o
produto necessita para ser
apropriado, competitivo e til.
Enquanto existir um produto, o
Backlog de Produto tambm
existir.
O Product Backlog representa tudo
que necessrio para desenvolver
e lanar um produto de sucesso.
uma lista de todas as
caractersticas, funes,tecnologias, melhorias e correes de defeitos que constituem as
mudanas que sero efetuadas no produto para releases futuras. Os
itens do Product Backlog possuem os atributos de descrio, prioridade
e estimativa. A prioridade determinada por risco, valor e
necessidade. H diversas tcnicas para dar valor a esses atributos.
Dica
Os itens do Product Backlog sogeralmente representadoscomo Estrias de Usurio.Casos de Uso tambm soapropriados, mas so maisadequados paradesenvolvimento de softwarescrticos em termos de vidas oude desempenho.
-
8/7/2019 Scrum Guide - PTBR
18/23
2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 18
O Product Backlog ordenado por prioridade. O Product Backlog de
mais alta prioridade leva a atividades de desenvolvimento imediatas.
Quanto mais alta sua prioridade, mais urgente ele , mais se pensou
sobre ele e h mais consenso no
que diz respeito ao seu valor. OBacklog de mais alta prioridade
mais claro e possui mais
informaes detalhadas do que o
Backlog de prioridade mais baixa.
Fazem-se melhores estimativas
quando baseadas em uma maior
clareza e em mais detalhes.
Quanto mais baixa a prioridade,
menor o nvel detalhe, at que
mal se consiga entender o item.
medida que um produto
utilizado, que seu valor aumenta
e que o mercado fornecefeedback, o Product Backlog
torna-se uma lista maior e mais
aprofundada. Os requisitos nuncaparam de mudar. O Product
Backlog um documento vivo.
Mudanas nos requisitos de
negcios, condies do mercado,
tecnologia e equipe causam
mudanas no Product Backlog.
Para minimizar o retrabalho,
apenas os itens de maior
prioridade precisam ser maisdetalhados. Os itens do Product
Backlog que ocuparo os Times
de Scrum pelas vrias Sprints
seguintes devero ter
Dica
Os Times Scrum geralmentegastam 10% de cada Sprintpreparando o Product Backlogpara adequ-lo definio deProduct Backlog feita acima.Quando estiverem adequados aesse nvel de granularidade, ositens no topo do Product
Backlog (de maior prioridade ede maior valor) sodecompostos de forma quecaibam em um Sprint. Elesforam analisados e se refletiusobre eles durante esseprocesso de preparao.Quando ocorre a reunio dePlanejamento de Sprint, essesitens de maior prioridade doProduct Backlog esto bementendidos e so facilmente
selecionados.
Dica
Testes de aceitao sofrequentemente utilizados comoum outro atributo para o itemdo Product Backlog. Eles podemfrequentemente substituir
descries textuais maisdetalhadas com uma descriotestvel do que o item doProduct Backlog deve fazer umavez que esteja completo.
-
8/7/2019 Scrum Guide - PTBR
19/23
2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 19
granularidade mais fina, tendo sido decompostos de forma tal que
cada um dos itens possa ser feito dentro da durao da Sprint.
Frequentemente, mltiplos Times de Scrum trabalham juntos no
mesmo produto. Um nico Product Backlog usado para descrever otrabalho a ser realizado no produto. Ento, um atributo que agrupe os
itens aplicado no Product Backlog. O agrupamento pode ocorrer por
conjuntos de caractersticas, por tecnologia ou por arquitetura, e ele
frequentemente utilizado como uma forma de se organizar o trabalho
por Time de Scrum.
O grfico de Burndown da
Release registra a soma das
estimativas dos esforosrestantes do Product Backlog ao
longo do tempo. O esforo
estimado deve estar em qualquer
unidade de medida de trabalho
que o Time de Scrum e a
organizao tenham decididousar. As unidades de tempo
geralmente so Sprints.
As estimativas dos itens do
Product Backlog so inicialmente
calculadas durante o
Planejamento da Release, e
posteriormente medida que
itens forem sendo criados.
Durante a preparao do Backlog
de Produto, os itens so revistose revisados. Entretanto, eles
podem ser atualizados em
qualquer momento. O Time
responsvel por todas as
estimativas. O Product Owner
DicaEm algumas organizaes,acrescenta-se mais trabalho aoBacklog do que se realiza. Issopode criar uma linha detendncia plana ou at cominclinao crescente. Paracompensar isso e manter atransparncia, um novo pisopode ser criado quando seadiciona ou quando se subtrai
trabalho. O piso deve adicionarou remover somentemudanas significativas e deveser bem documentado.
Dica
A linha de tendncia pode noser confivel pelas duas ou trs
primeiras Sprints de umarelease, a menos que os timesj tenham trabalhado juntosanteriormente, conheam bemo produto e entendam atecnologia envolvida.
-
8/7/2019 Scrum Guide - PTBR
20/23
2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 20
pode influenciar o Time, ajudando-o a entender e a escolher as
mudanas, mas a estimativa final feita pelo Time. O Product Owner
mantm o Product Backlog e o Burndown do Backlog da Release
atualizados e publicados todo o tempo. Uma linha de tendncia pode
ser traada baseada na mudana do trabalho restante.
Sprint Backlog e Burndown da Sprint
O Sprint Backlog consiste nas tarefas que o time executa para
transformar itens do Product Backlog em um incremento pronto.
Muitas delas so elaboradas durante a Reunio de Planejamento da
Sprint. O Sprint Backlog todo trabalho que o Time identifica como
necessrio para alcanar a Meta da Sprint. Os itens do Sprint Backlogdevem ser decompostos. A decomposio deve ser suficiente para que
mudanas no progresso possam ser entendidas na Daily Scrum. Um
dia ou menos um tamanho comum para um item do Sprint Backlog
no qual se est trabalhando.
O Time modifica o Sprint Backlog no decorrer da Sprint, bem como
surge Sprint Backlog durante a Sprint. Quando chega s tarefas
individuais, o Time pode descobrir que mais ou menos tarefas sero
necessrias, ou que uma determinada tarefa levar mais ou menos
tempo do que era esperado. medida que novo trabalho surge, o
Time o adiciona ao Sprint Backlog. medida que se trabalha nastarefas ou que elas so completadas, o trabalho restante para cada
tarefa atualizado. Quando se verifica que determinadas tarefas so
desnecessrias, elas so removidas. Somente o Time pode modificar o
seu Sprint Backlog durante uma Sprint. Somente o Time pode mudar o
seu contedo ou as suas estimativas. O Sprint Backlog um retrato
em tempo real altamente visvel do trabalho que o Time planejaefetuar durante a Sprint, e ele pertence unicamente ao Time.
O Burndown do Sprint Backlog um grfico da quantidade restante de
trabalho do Sprint Backlog em uma determinada Sprint ao longo do
tempo da Sprint. Para criar esse grfico, determine quanto trabalho
-
8/7/2019 Scrum Guide - PTBR
21/23
2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 21
resta somando as estimativas do
Backlog a cada dia da Sprint. A
quantidade de trabalho restante
para uma Sprint a soma do
trabalho restante para tudo doSprint Backlog. Acompanhe essas
somas diariamente e utilize-as
para criar um grfico que mostre
o trabalho restante ao longo do
tempo. Traando uma linha
atravs dos pontos no grfico, o Time pode gerenciar seu progresso
em completar o trabalho de uma Sprint. A durao no considerada
em Scrum. O trabalho restante e a data so as nicas variveis de
interesse.
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 defuncionalidade 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 completo do produto. Ele deve estar
pronto (ou done, em ingls). Cada incremento deve ser adicionadoa todos os incrementos anteriores e exaustivamente testado,
garantindo que todos os incrementos funcionem juntos.
No desenvolvimento de produtos, afirmar que a funcionalidade estpronta pode levar algum a presumir que ela est pelo menos bem
codificada, refatorada, que tenha passado por testes unitrios, que
tenha sido feito o builde que tenha passado por testes de aceitao.
Outros podem presumir que apenas o cdigo tenha sido desenvolvido.
Se ningum sabe qual a definio de pronto, os outros dois pilares
Dica
Sempre que possvel, desenheo grfico de burndown moem uma folha grande de papel
exibida na rea de trabalho doTime. mais provvel que oTime veja um grfico grande evisvel do que um grfico deBurndown da Sprint no Excel ouem alguma ferramenta.
-
8/7/2019 Scrum Guide - PTBR
22/23
2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 22
do controle de processos empricos no funcionam. Quando algum
descreve algo como pronto, todos devem entender o que pronto
significa.
Pronto define o que o Time quer dizer quando se compromete aaprontar um item de Product Backlog em uma Sprint. Alguns
produtos no contm documentao, de forma que sua definio de
pronto no inclui documentao. Um incremento completamente
pronto inclui toda a anlise, projeto, refatoramento, programao,
documentao e testes para o incremento e todos os itens do Product
Backlog no incremento. Os testes incluem testes de unidade, de
sistema, de usurio e de regresso, bem como testes no-funcionais
como de performance, de estabilidade, de segurana e de integrao.
Pronto inclui tambm qualquer internacionalizao necessria.Alguns Times ainda no so
capazes de incluir em sua
definio de pronto tudo o que
necessrio para a implantao.
Isto deve estar claro para oProduct Owner. Esse trabalho
restante dever ser feito antes
que o produto possa serimplantado e utilizado.
Consideraes Finais
Algumas organizaes so incapazes de desenvolver um incremento
completo dentro de uma Sprint. Elas podem ainda no terinfraestrutura automatizada de testes para completar todos os testes.
Nesse caso, duas categorias 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 Product Backlog
Dica
Trabalho "no pronto" geralmente acumulado em umitem do Product Backlogchamado "Trabalho No Pronto"ou "Trabalho de Implantao". medida que esse trabalho
acumula, o Burndown doProduct Backlog se mantmmais preciso do que se essetrabalho no fosse acumulado.
-
8/7/2019 Scrum Guide - PTBR
23/23
2008-2010 Ken Schwaber e Jeff Sutherland todos os direitos reservados Pg | 23
chamado trabalho no pronto, de forma que ele se acumula e isso
refletido corretamente no grfico de Burndown da Release. 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 Product Backlog, 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 estestimando baseado no que ele sabe como aprontar), quatro unidades
sero acrescidas ao item do Product Backlog 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. Essetrabalho acumulado linearmente, embora haja algum tipo de
acmulo exponencial que dependente das caractersticas de cada
organizao. Sprints de Release so adicionados ao final de cada
release para completar o trabalho no pronto. O nmero de Sprints
imprevisvel, visto que o acmulo de trabalho no pronto no
linear.