Download - 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.


Top Related