[apostila]guia scrum - br

8/4/2019 [Apostila]Guia Scrum - BR

1/22

Novembro de 2009

Scrum: Desenvolvido e mantido por Ken Schwaber e Jeff Sutherland


2/22

2008-2009 Ken Schwaber e Jeff Sutherland, Todos os Direitos Reservados P gina | 2

TraduoHeitor Roriz Filho

Michel GoldenbergRafael Sabbagh

Reviso

Anderson Marcondesnderson Quadros

Ari do Amaral Torres FilhoMarcos Garrido

Rafael FuchsRafael PrikladnickiRodrigo de Toledo

Rafael Sabbagh (coordenao)


3/22


AGRADECIMENTOS

GERALScrum 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 oJeff, Todos iro gostar de Scrum; ele o que j fazemos quandoestamos pressionados contra a parede.

PESSOASDas milhares de pessoas que contribuiram para o Scrum, devemosdestacar aquelas que contribuiram em seus primeiros dez anos.Primeiro havia o Jeff Sutherland, trabalhando com o Jeff McKenna, eKen Schwaber com Mike Smith e Chris Martin. Scrum foi formalmenteapresentado e publicado no OOPSLA 1995. Durante os cinco anosseguintes, Mike Beadle e Martine Devos fizeram contribuiessignificativas. E ento todos os outros, que sem a sua ajuda o Scrumno teria sido aprimorado no que atualmente.

HISTRIA

A histria do Scrum j pode ser considerada longa no mundo dedesenvolvimento de software. Para honrar os primeiros lugares onde foitestado e aprimorado, honramos a Individual, Inc., Fidelity Investments eIDX (hoje GE Medial).


4/22


PROPSITOScrum vem sendo utilizado para o desenvolvimento de produtoscomplexos desde o incio dos anos 90. Este guia descreve como usar oScrum para desenvolver produtos. Scrum no um processo ou uma

tcnica para o desenvolvimento de produtos. Ao invs disso, umframework dentro do qual voc pode empregar diversos processos etcnicas. O papel do Scrum fazer transparecer a eficcia relativa dassuas prticas de desenvolvimento para que voc possa melhor-las,enquanto prov um frameworkdentro do qual produtos complexospodem ser desenvolvidos.

TEORIA DO SCRUM

Scrum, que fundamentado na teoria de controle de processosempricos, emprega uma abordagem iterativa e incremental paraotimizar a previsibilidade e controlar riscos. Trs pilares sustentamqualquer implementao de controle de processos empricos.

O PRIMEIRO PILAR A TRANSPARNCIA

A transparncia garante que aspectos do processo que afetam oresultado devem ser visveis para aqueles que gerenciam os resultados.Esses aspectos no apenas devem ser transparentes, mas tambm oque est sendo visto deve ser conhecido. Isto , quando algum queinspeciona um processo acredita que algo est pronto, isso deve serequivalente definio de pronto utilizada.

O SEGUNDO PILAR A INSPEO

Os diversos aspectos do processo devem ser inspecionados com umafrequncia suficiente para que variaes inaceitveis no processopossam ser detectadas. A frequncia da inspeo deve levar emconsiderao que qualquer processo modificado pelo prprio ato dainspeo. O problema acontece quando a frequncia de inspeonecessria excede a tolerncia do processo inspeo. Os outros


5/22


fatores so a habilidade e a aplicao das pessoas em inspecionar osresultados do trabalho.

O TERCEIRO PILAR A ADAPTAOSe o inspetor determinar, a partir da inspeo, que um ou mais aspectosdo processo esto fora dos limites aceitveis e que o produto resultanteser inaceitvel, ele dever ajustar o processo ou o material sendoprocessado. Esse ajuste deve ser feito o mais rpido possvel paraminimizar desvios posteriores.

Existem trs pontos para inspeo e adaptao em Scrum. A ReunioDiria utilizada para inspecionar o progresso em direo Meta da

Sprint e para realizar adaptaes que otimizem o valor do prximo diade trabalho. Alm disso, as reunies de Reviso da Sprint e dePlanejamento da Sprint so utilizadas para inspecionar o progresso emdireo Meta da Release e para fazer as adaptaes que otimizem ovalor da prxima Sprint. Finalmente, a Retrospectiva da Sprint utilizada para revisar a Sprint passada e definir que adaptaes tornaroa prxima Sprint mais produtiva, recompensadora e gratificante.

CONTEDO DO SCRUMO framework Scrum consiste em um conjunto formado por TimesScrum e seus papis associados, Eventos com Durao Fixa (Time-Boxes), Artefatos e Regras.

Times Scrum so projetados para otimizar flexibilidade e produtividade.Para esse fim, eles so auto-organizveis, interdisciplinares e trabalhamem iteraes. Cada Time Scrum possui trs papis: 1) o ScrumMaster,que responsvel por garantir que o processo seja compreendido eseguido; 2) o Product Owner, que responsvel por maximizar o valordo trabalho que o Time Scrum faz; e 3) o Time, que executa o trabalhopropriamente dito. O Time consiste em desenvolvedores com todas ashabilidades necessrias para transformar os requisitos do ProductOwner em um pedao potencialmente entregvel do produto ao final daSprint.


6/22


Scrum emprega os eventos com durao fixa (time-boxes) para criarregularidade. Entre os elementos do Scrum que tm durao fixa, temosa Reunio dePlanejamento da Release, a Reunio de Planejamentoda Sprint, a Sprint, a Reunio Diria, a Reviso da Sprint e aRetrospectiva da Sprint. O corao do Scrum a Sprint, que uma

iterao de um ms ou menos, de durao consistente com o esforode desenvolvimento. Todas as Sprints utilizam o mesmo modelo deScrum e todas as Sprints tm como resultado um incremento do produtofinal que potencialmente entregvel. Cada Sprint comeaimediatamente aps a anterior.

Scrum utiliza quatro artefatos principais. O Backlog do Produto umalista priorizada de tudo que pode ser necessrio no produto. O Backlogda Sprint uma lista de tarefas para transformar o Backlog do Produto,por uma Sprint, em um incremento do produto potencialmente

entregvel. Um burndown uma medida do backlog restante pelotempo. Um Burndown de Release mede o Backlog do Produtorestante ao longo do tempo de um plano de release. Um Burndown deSprint mede os itens do Backlog da Sprint restantes ao longo do tempode uma Sprint.

As Regras fazem o elo entre oseventos com durao fixa (time-boxes), os papis e os artefatos doScrum. Suas regras so descritas aolongo deste documento. Por exemplo,uma regra do Scrum diz que somentemembros do Time - as pessoascomprometidas em transformar oBacklog do Produto em umincremento - podem falar durante umaReunio Diria. Modos deimplementar Scrum que no soregras, mas sim sugestes, estodescritas nas sees de "Dicas".

PAPIS NO SCRUM

O Time Scrum composto pelo ScrumMaster, pelo Product Owner epelo Time. Os membros do Time Scrum so chamados porcos.Qualquer outra pessoa chamada de galinha. Galinhas no podem

DICA

Quando as regras no sodeclaradas, espera-se que os

usurios de Scrum descubram oque devem fazer. No tentedescobrir uma soluo perfeita,porque geralmente o problemamuda rapidamente. Ao invs disso,tente algo e veja como se sai. Osmecanismos de inspeo-e-adaptao inerentes naturezaemprica de Scrum iro lhe guiar.


7/22


dizer aos porcos como eles devem fazer seu trabalho. Galinhas eporcos vm da seguinte histria:

Uma galinha e um porco esto juntos quando a galinha diz: Vamosabrir 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 estariaapenas envolvida!

O SCRUMMASTER

O ScrumMaster responsvel porgarantir que o Time Scrum estejaaderindo aos valores do Scrum, sprticas e s regras. O ScrumMasterajuda o Time Scrum e a organizaoa adotarem o Scrum. OScrumMaster educa o Time Scrumtreinando-o e levando-o a ser maisprodutivo e a desenvolver produtos

de maior qualidade. O ScrumMasterajuda o Time Scrum a entender eusar autogerenciamento einterdisciplinaridade. O ScrumMastertambm ajuda o Time Scrum a fazero seu melhor em um ambienteorganizacional que pode ainda noser otimizado para odesenvolvimento de produtoscomplexos. Quando o ScrumMaster

ajuda a realizar essas mudanas,isso chamado de remoo deimpedimentos. No entanto, oScrumMaster no gerencia o TimeScrum; o Time Scrum auto-organizvel.

DICA

O ScrumMaster trabalha com osclientes e a gerncia para identificare designar um Product Owner. OScrumMaster ensina ao ProductOwner como fazer seu trabalho.Espera-se dos Product Owners queeles saibam como conseguir otimizar

valor atravs do Scrum. Se eles nosouberem, consideramos oScrumMaster responsvel.

DICA

O ScrumMaster pode ser ummembro do Time; por exemplo, umdesenvolvedor realizando tarefas da

Sprint. No entanto, issofrequentemente leva a conflitosquando o ScrumMaster deveescolher entre removerimpedimentos e realizar tarefas. OScrumMaster nunca deve ser oProduct Owner.


8/22


O PRODUCT OWNER

O Product Owner a nicapessoa responsvel pelogerenciamento do Backlog do

Produto e por garantir o valor dotrabalho realizado pelo Time.Essa pessoa mantm o Backlogdo Produto e garante que eleest visvel para todos. Todossabem quais itens tm a maiorprioridade, de forma que todossabem em que se ir trabalhar.

O Product Owner uma pessoa,

e no um comit. Podem existircomits que aconselhem ouinfluenciem essa pessoa, masquem quiser mudar a prioridadede um item, ter que convencer oProduct Owner. Empresas queadotam Scrum podem perceberque isso influencia seus mtodos para definir prioridades e requisitos aolongo do tempo.

Para que o Product Owner obtenha sucesso, todos na organizaoprecisam respeitar suas decises. Ningum tem a permisso de dizerao Time para trabalhar em um outro conjunto de prioridades, e os Timesno podem dar ouvidos a ningum que diga o contrrio. As decises doProduct Owner so visveis no contedo e na priorizao do Backlog doProduto. Essa visibilidade requer que o Product Owner faa seu melhor,o que faz o papel de Product Owner exigente e recompensador aomesmo tempo.

O TIME

Times de desenvolvedores transformam o Backlog do Produto emincrementos de funcionalidades potencialmente entregveis em cadaSprint. Times tambm so interdisciplinares: membros do Time devempossuir todo o conhecimento necessrio para criar um incremento notrabalho. Membros do Time frequentemente possuem conhecimentos

DICA

Para desenvolvimento comercial, oProduct Owner pode ser o Gerente deProduto. Para esforos internos dedesenvolvimento, o Product Ownerpoderia ser o gerente da funo denegcios em que se est trabalhando.

DICA

O Product Owner pode ser um membrodo Time, trabalhando tambm emdesenvolvimento. Mas essaresponsabilidade adicional pode reduzir asua habilidade de lidar com as partesinteressadas. No entanto, o ProductOwner nunca pode ser o ScrumMaster.


9/22


especializados, como programao, controle de qualidade, anlise denegcios, arquitetura, projeto de interface de usurio ou projeto debanco de dados. No entanto, o conhecimento que os membros do Timedevem compartilhar - isto , a habilidade de trabalhar um requisito etransform-lo em um produto utilizvel - tendem a ser mais importantes

do que aqueles que eles no dividem. As pessoas que se recusam aprogramar porque so arquitetas ou designers no se adaptam bem aTimes. Todos contribuem, mesmo que isso exija aprender novashabilidades ou lembrar-se de antigas. No h ttulos em Times, e no hexcees a essa regra. Os Times tambm no contm subtimesdedicados a reas particulares como testes ou anlise de negcios.

Times tambm so auto-organizveis. Ningum - nem mesmo oScrumMaster - diz ao time como transformar o Backlog do Produto emincrementos de funcionalidades entregveis. O Time descobre por si s.

Cada membro do Time aplica sua especialidade a todos os problemas.A sinergia que resulta disso melhora a eficincia e eficcia geral doTime como um todo.

O tamanho timo para um Time de sete pessoas, mais ou menosduas pessoas. Quando h menos do que cinco membros em um Time,h menor interao e, como resultado, h menor ganho deprodutividade. Mais do que isso, o time poder encontrar limitaes deconhecimento durante partes da Sprint e no ser capaz de entregar umaparte pronta do produto. Se h mais do que nove membros, hsimplesmente a necessidade de muita coordenao. Times grandesgeram muita complexidade para que um processo emprico consigagerenciar. No entanto, temos encontrado alguns Times bem-sucedidosque excederam os limites superior e inferior dessa faixa de tamanhos. OProduct Owner e o ScrumMaster no esto includos nessa conta, amenos que tambm sejam porcos.

A composio do Time pode mudar ao final da Sprint. Toda vez que oTime 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 Reuniode Planejamento da Release, a Sprint, a Reunio de Planejamento


10/22


da Sprint, a Reviso da Sprint, a Retrospectiva da Sprint e aReunio Diria.

REUNIO DE PLANEJAMENTO DA RELEASEO propsito do planejamento da release o de estabelecer um plano emetas que o Time Scrum e o resto da organizao possam entender ecomunicar. O planejamento da release responde s questes: Comopodemos transformar a viso em um produto vencedor da melhormaneira possvel? Como podemos alcanar ou exceder a satisfao docliente e o Retorno sobre Investimento (ROI) desejados? O plano darelease estabelece a meta da release, as maiores prioridades doBacklog do Produto, os principais riscos e as caractersticas gerais e

funcionalidades que estaro contidas na release. Ele estabelecetambm uma data de entrega e custo provveis que devem se manterse nada mudar. A organizao pode ento inspecionar o progresso efazer mudanas nesse plano da release a cada Sprint.

O planejamento da release inteiramente opcional. Se um Time Scruminiciar o trabalho sem essa reunio, a ausncia de seus artefatosaparecer como um impedimento que dever ser resolvido. O trabalhopara resolver o impedimento se tornar um item no Backlog do Produto.

Ao se utilizar Scrum, os produtos so construdos iterativamente, demodo que cada Sprint cria um incremento do produto, iniciando pelo demaior valor e maior risco. Mais e mais Sprints vo adicionandoincrementos ao produto. Cada incremento um pedao potencialmenteentregvel do produto completo. Quando j tiverem sido criadosincrementos suficientes para que o produto tenha valor e uso para seusinvestidores, o produto entregue.

Muitas organizaes j possuem um processo de planejamento derelease, e na maior parte desses processos o planejamento feito noincio do trabalho da release e no modificado com o passar dotempo. No planejamento de release do Scrum, so definidos uma metageral e resultados provveis. Esse planejamento geralmente no requermais do que 15-20% do tempo que uma organizao costumava utilizarpara produzir um plano de release tradicional. No entanto, uma releasecom Scrum realiza planejamento no momento da execuo de cadareunio de Reviso de Sprint e de Planejamento de Sprint, da mesmaforma que realiza um planejamento dirio no momento da execuo de


11/22


cada Reunio Diria. De forma geral, os esforos para uma release comScrum provavelmente consomem ligeiramente mais esforo do que osesforos para um planejamento de release tradicional.

O planejamento da release requer estimar e priorizar o Backlog do

Produto para a release. H diversas tcnicas para faz-lo que esto forado alcance do Scrum, mas que apesar disso so teis quando usadascom ele.

A SPRINT

A Sprint uma iterao. Sprints soeventos com durao fixa. Durante a

Sprint, o ScrumMaster garante queno ser feita nenhuma mudana quepossa afetar a Meta da Sprint. Tanto acomposio do time quanto as metasde qualidade devem permanecerconstantes durante a Sprint. AsSprints contm e consistem nareunio de Planejamento de Sprint, otrabalho de desenvolvimento, aReviso da Sprint e a Retrospectiva

da Sprint. As Sprints ocorrem uma aps a outra, sem intervalos entreelas.

Um projeto serve para cumprir algumafuno. Em desenvolvimento desoftware, o projeto utilizado paradesenvolver um produto ou sistema.Cada projeto consiste em umadefinio do que ser desenvolvido,um plano para desenvolv-lo, otrabalho realizado de acordo com oplano e o produto resultante. Cadaprojeto possui um horizonte, que operodo de tempo para o qual o plano vlido. Se o horizonte for longodemais, a definio poder ter mudado, variveis demais podero tersurgido, o risco poder ser grande demais etc. Scrum um frameworkpara projetos cujo horizonte no superior ao perodo de um ms, onde j h complexidade suficiente tal que um horizonte mais longo seria

DICA

Se o time sentir que secomprometeu com mais do quepodia, ele se encontra com oProduct Owner para remover oureduzir o escopo do Backlog doProduto selecionado para a Sprint.Se o time sentir que sobrar tempo,ele pode trabalhar junto ao ProductOwner para selecionar mais doBacklog do Produto.

DICA

Quando um Time comea com oScrum, Sprints de duas semanas opermite aprender sem se afundarna incerteza. Sprints dessetamanho podem ser sincronizadascom outros Times adicionando-se

dois incrementos juntos.


12/22


arriscado demais. A previsibilidade do projeto deve ser controlada pelomenos a cada ms, e o risco de que o projeto saia de controle ou setorne 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 para cancelar aSprint, embora ele possa faz-lo sob influncia das partes interessadas,do Time ou do ScrumMaster. Sob que tipo de circunstncias pode sernecessrio cancelar uma Sprint? A gerncia pode precisar cancelar umaSprint se a Meta da Sprint se tornar obsoleta. Isso pode ocorrer se aempresa mudar de direo ou se as condies do mercado outecnologia mudarem. Em geral, uma Sprint deve ser cancelada se elano fizer mais sentido dadas as circunstncias atuais. Porm, por causada curta durao das Sprints, raramente isso faz sentido.

Quando uma Sprint cancelada, todos os itens do Backlog do Produtoque estejam completados e "feitos" so revisados. Eles so aceitos serepresentarem um incremento potencialmente entregvel. Todos osoutros itens do Backlog do Produto so devolvidos ao Backlog doProduto com suas estimativas iniciais. Assume-se que qualquer trabalhorealizado nesses itens perdido. Cancelamentos de Sprints consomemrecursos, j que todos tm que se reagrupar em outra reunio dePlanejamento de Sprint para iniciar uma nova Sprint. Cancelamentos deSprints so frequentemente traumticos para o Time e so muitoincomuns.

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 umms. Para Sprints mais curtas, aloca-se para essa reunioaproximadamente 5% do tamanho total da Sprint, e ela consiste de duaspartes. A primeira parte, um evento com durao fixa de quatro horas, o momento no qual decidido o que ser feito na Sprint. A segundaparte, outro evento com durao fixa de quatro horas, o momento noqual o Time entende como desenvolver essa funcionalidade em umincremento do produto durante a Sprint.

H duas partes na Reunio de Planejamento da Sprint: a parte do oqu? e a parte do como?. Alguns Times Scrum juntam as duas. Naprimeira parte, o Time Scrum trata da questo do o qu?. Aqui, o


13/22


Product Owner apresenta ao Time o que mais prioritrio no Backlogdo Produto. Eles trabalham em conjunto para definir qual funcionalidadedever ser desenvolvida durante a prxima Sprint. As entradas paraessa reunio so o Backlog do Produto, o incremento mais recente aoproduto, a capacidade do Time e o histrico de desempenho do Time.

Cabe somente ao Time a deciso de quanto do Backlog ele deveselecionar. Somente o Time pode avaliar o que ele capaz de realizarna prxima Sprint.

Uma vez selecionado o Backlog do Produto, a Meta da Sprint delineada. A Meta da Sprint o objetivo que ser atingido atravs daimplementao do Backlog do Produto. Ela uma descrio quefornece orientao ao Time sobre a razo pela qual ele estdesenvolvendo o incremento. A Meta da Sprint um subconjunto daMeta da Release.

O motivo para se ter uma Meta da Sprint dar ao time alguma margemcom relao funcionalidade. Por exemplo, a meta para a Sprint acimapoderia tambm ser: Automatizar a funcionalidade de modificao deconta de clientes atravs de um middleware seguro capaz de recuperartransaes. 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 timeento ir colaborar com o Product Owner e implementar afuncionalidade apenas parcialmente.

Na segunda parte da Reunio de Planejamento da Sprint, o Time trata aquesto do como?. Durante as quatro horas seguintes da Reunio dePlanejamento da Sprint, o Time define como transformar o Backlog doProduto selecionado durante a Reunio de Planejamento (o qu) em umincremento pronto. O Time geralmente comea projetando o trabalho.Enquanto projeta, o time identifica tarefas. Essas tarefas so pedaosdetalhados do trabalho necessrio para converter o Backlog do Produtoem software funcional. As tarefas devem ser decompostas para quepossam ser feitas em menos de um dia. Essa lista de tarefas chamadade Backlog da Sprint. O time se auto-organiza para se encarregar e seresponsabilizar pelo trabalho contido no Backlog da Sprint, tanto durantea Reunio de Planejamento da Sprint quanto no prprio momento daexecuo da Sprint.


14/22


O Product Owner est presentedurante a segunda parte da Reuniode Planejamento da Sprint paraesclarecer o Backlog do Produto epara ajudar a efetuar trocas. Se o

Time concluir que ele tem trabalhodemais ou de menos, ele poderenegociar o Backlog do Produtoescolhido com o Product Owner. OTime tambm pode convidar outraspessoas a participarem da reuniopara 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 Timepercebe que deve contar consigo mesmo. Conforme ele percebe isso,

ele comea a se auto-organizar para assumir as caractersticas ecomportamento de um verdadeiro Time.

REVISO DA SPRINT

Ao final da Sprint, feita a reunio de Reviso da Sprint. Para Sprintsde um ms, essa uma reunio com durao fixa de quatro horas. ParaSprints 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 eas partes interessadas colaboram sobre o que acabou de ser feito.Baseados nisso e em mudanas no Backlog do Produto feitas durante aSprint, eles colaboram sobre quais so as prximas coisas que podemser feitas. Essa uma reunio informal, com a apresentao dafuncionalidade, que tem a inteno de promover a colaborao sobre oque fazer em seguida.

A reunio inclui ao menos os seguintes elementos. O Product Owneridentifica o que foi feito e o que no foi feito. O Time discute sobre o que

correu bem durante a Sprint e quais problemas foram enfrentados, almde como esses problemas foram resolvidos. O Time ento demonstra otrabalho que est pronto e responde a questionamentos. O ProductOwner ento discute o Backlog do Produto da maneira como esse seencontra. Ele faz projees de datas de concluso provveis a partir devrias hipteses de velocidade. Em seguida, o grupo inteiro colaborasobre o que foi visto e o que isso significa com relao ao que fazer em

DICA

Geralmente, somente 60-70% dototal do Backlog da Sprint serdefinido na Reunio de

Planejamento da Sprint. O restante deixado para ser detalhado maistarde ou so dadas estimativasgrandes que sero decompostasmais tarde na Sprint.


15/22


seguida. A Reviso da Sprint fornece entradas valiosas para asreunies de Planejamento de Sprints seguintes.

RETROSPECTIVA DA SPRINTAps a Reviso da Sprint e antes da prxima reunio de Planejamentoda Sprint, o Time Scrum tem a reunio de Retrospectiva da Sprint.Nessa reunio, com durao fixa de trs horas, o ScrumMaster encorajao Time a revisar, dentro do modelo de trabalho e das prticas doprocesso do Scrum, seu processo de desenvolvimento, de forma atorn-lo mais eficaz e gratificante para a prxima Sprint. Muitos livrosdocumentam tcnicas que so teis em Retrospectivas.

A finalidade da Retrospectiva inspecionar como correu a ltima Sprintem se tratando de pessoas, das relaes entre elas, dos processos edas ferramentas. A inspeo deve identificar e priorizar os principaisitens que correram bem e aqueles que, se feitos de modo diferente,poderiam ter deixado as coisas ainda melhores. Isso inclui acomposio do time, preparativos para reunies, ferramentas, definiode pronto, mtodos de comunicao e processos para transformaritens do Backlog do Produto em alguma coisa pronta. No final daRetrospectiva da Sprint, o Time Scrum deve ter identificado medidas demelhoria factveis que ele implementar na prxima Sprint. Essas

mudanas se tornam a adaptao para a inspeo emprica.

REUNIO DIRIA

Cada time se encontra diariamente para uma reunio de 15 minutoschamada Reunio Diria. Essa reunio sempre feita no mesmohorrio e no mesmo local durante as Sprints. Durante a reunio, cadamembro explica:

1. O que ele realizou desde a ltima reunio diria;

2. O que ele vai fazer antes da prxima reunio diria; e

3. Quais obstculos esto em seu caminho.

As Reunies Dirias melhoram a comunicao, eliminam outrasreunies, identificam e removem impedimentos para o


16/22


desenvolvimento, ressaltam e promovem a tomada rpida de decisese 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 Reunio Diria. O ScrumMaster ensina o time

a manter a Reunio Diria com curta durao, reforando as regras egarantido que as pessoas falem brevemente. O ScrumMaster tambmenfatiza a regra de que galinhas no esto autorizadas a falar e nem ainterferir de modo algum na Reunio Diria.

A Reunio Diria no uma reunio de status. Ela s para aspessoas que esto transformando os itens do Backlog do Produto emum incremento (o Time), e para mais ningum. O Time se comprometeucom uma Meta da Sprint, e a esses itens do Backlog do Produto. AReunio Diria uma inspeo do progresso na direo da Meta da

Sprint (as trs perguntas). Geralmente acontecem reuniessubsequentes para realizar adaptaes ao trabalho que est por vir naSprint. A inteno otimizar a probabilidade de que o Time alcance suaMeta. Essa uma reunio fundamental de inspeo e adaptao noprocesso emprico do Scrum.

ARTEFATOS DO SCRUM

Os artefatos do Scrum incluem o Backlog do Produto, o Burndown daRelease, o Backlog da Sprint e o Burndown da Sprint.

BACKLOG DO PRODUTO E BURNDOWN DARELEASE

Os requisitos para o produto que o(s) Time(s) est(o) desenvolvendoesto listados no Backlog do Produto. O Product Owner o responsvel

pelo Backlog do Produto, por seu contedo, por sua disponibilidade epor sua priorizao. O Backlog do Produto nunca est completo. Aseleo inicial para o seu desenvolvimento somente mostra osrequisitos inicialmente conhecidos e melhor entendidos. O Backlog doProduto evolui medida que o produto e o ambiente em que ele serusado evoluem. O Backlog dinmico, no sentido de que ele estconstantemente mudando para identificar o que o produto necessita


17/22


para ser apropriado, competitivo e til. Enquanto existir um produto, oBacklog de Produto tambm existir.

O Backlog do Produto representa tudoque necessrio para desenvolver e

lanar um produto de sucesso. umalista de todas as caractersticas,funes, tecnologias, melhorias ecorrees de defeitos que constituemas mudanas que sero efetuadas noproduto para releases futuras. Ositens do Backlog do Produto possuemos atributos de descrio, prioridade eestimativa. A prioridade determinadapor risco, valor e necessidade. H diversas tcnicas para dar valor a

esses atributos.O Backlog do Produto ordenado por prioridade. O Backlog do Produtode mais alta prioridade leva a atividades de desenvolvimento imediatas.Quanto mais alta sua prioridade, mais urgente ele , mais se pensousobre ele e h mais consenso no que diz respeito ao seu valor. OBacklog de mais alta prioridade mais claro e possui mais informaesdetalhadas do que o Backlog de prioridade mais baixa. Fazem-semelhores estimativas quando baseadas em uma maior clareza e emmais detalhes. Quanto mais baixa a prioridade, menor o nvel dedetalhe, at que mal se consiga entender o item.

medida que um produto utilizado, que seu valor aumentae que o mercado fornecefeedback, o Backlog do Produtotorna-se uma lista maior e maisaprofundada. Os requisitosnunca param de mudar. OBacklog do Produto umdocumento vivo. Mudanas nosrequisitos de negcios,condies do mercado,tecnologia e equipe causammudanas no Backlog doProduto. Para minimizar oretrabalho, apenas os itens demaior prioridade precisam ser

DICA

Os itens do Backlog do Produto sogeralmente representados comoEstrias de Usurio. Casos de Usotambm so apropriados, mas somais adequados paradesenvolvimento de softwarescrticos em termos de vidas ou dedesempenho.

DICA

Os Times Scrum geralmente gastam 10%de cada Sprint preparando o Backlog doProduto para adequ-lo definio deBacklog do Produto feita acima. Quandoestiverem adequados a esse nvel degranularidade, os itens no topo do Backlogdo Produto (de maior prioridade e de

maior valor) so decompostos de formaque caibam em um Sprint. Eles foramanalisados e se refletiu sobre eles duranteesse processo de preparao. Quandoocorre a reunio de Planejamento deSprint, esses itens de maior prioridade doBacklog do Produto esto bem entendidose so facilmente selecionados.


18/22


mais detalhados. Os itens do Backlog do Produto que ocuparo osTimes Scrum pelas vrias Sprints seguintes devero ter granularidademais fina, tendo sido decompostos de forma tal que cada um dos itenspossa ser feito dentro da durao da Sprint.

Frequentemente, mltiplos TimesScrum trabalham juntos no mesmoproduto. Um nico Backlog do Produto usado para descrever o trabalho aser realizado no produto. Ento, umatributo que agrupe os itens aplicado no Backlog do Produto. Oagrupamento pode ocorrer porconjuntos de caractersticas, portecnologia ou por arquitetura, e ele

frequentemente utilizado como umaforma de se organizar o trabalho porTime Scrum.

O grfico de Burndown da Release registra a soma das estimativas dosesforos restantes do Backlog do Produto ao longo do tempo. O esforoestimado deve estar em qualquer unidade de medida de trabalho que oTime Scrum e a organizao tenham decidido usar. As unidades detempo geralmente so Sprints.

DICA

Testes de aceitao sofrequentemente utilizados como umoutro atributo para o item doBacklog do Produto. Eles podemfrequentemente substituirdescries textuais maisdetalhadas com uma descriotestvel do que o item do Backlogdo Produto deve fazer uma vez que

esteja completo.


19/22


As estimativas dos itens do Backlog doProduto so inicialmente calculadasdurante o Planejamento da Release, e

posteriormente medida que itensforem sendo criados. Durante apreparao do Backlog de Produto, ositens so revistos e revisados.Entretanto, eles podem ser atualizadosem qualquer momento. O Time responsvel por todas as estimativas. OProduct Owner pode influenciar o Time,ajudando-o a entender e a escolher asmudanas, mas a estimativa final feita

pelo Time. O Product Owner mantm oBacklog do Produto e o Burndown doBacklog da Release atualizados epublicados todo o tempo. Uma linha detendncia pode ser traada baseada namudana do trabalho restante.

BACKLOG DA SPRINT E

BURNDOWN DA SPRINTO Backlog da Sprint consiste nas tarefasque o time executa para transformaritens do Backlog do Produto em um incremento pronto. Muitas delasso elaboradas durante a Reunio de Planejamento da Sprint. OBacklog da Sprint todo trabalho que o Time identifica como necessriopara alcanar a Meta da Sprint. Os itens do Backlog da Sprint devemser decompostos. A decomposio deve ser suficiente para quemudanas no progresso possam ser entendidas na Reunio Diria.

O Time modifica o Backlog da Sprint no decorrer da Sprint, bem comosurge Backlog da Sprint durante a Sprint. Quando chega s tarefasindividuais, o Time pode descobrir que mais ou menos tarefas seronecessrias, ou que uma determinada tarefa levar mais ou menostempo do que era esperado. medida que novo trabalho surge, o Timeo adiciona ao Backlog da Sprint. medida que se trabalha nas tarefasou que elas so completadas, as horas estimadas de trabalho restantes

DICA

Em 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 subtraitrabalho. O piso deve adicionarou remover somente mudanassignificativas e deve ser bemdocumentado.

DICA

A linha de tendncia pode noser confivel pelas duas ou trsprimeiras Sprints de umarelease, a menos que os times jtenham trabalhado juntos

anteriormente, conheam bem oproduto e entendam a tecnologiaenvolvida.


20/22


para cada tarefa so atualizadas. Quando se verifica que determinadastarefas so desnecessrias, elas so removidas. Somente o Time podemodificar o seu Backlog da Sprint durante uma Sprint. Somente o Timepode mudar o seu contedo ou as suas estimativas. O Backlog daSprint um retrato em tempo real altamente visvel do trabalho que o

Time planeja efetuar durante a Sprint, e ele pertence unicamente aoTime.

O Burndown do Backlog da Sprint um grfico da quantidade restante detrabalho do Backlog da Sprint emuma determinada Sprint ao longo dotempo da Sprint. Para criar essegrfico, determine quanto trabalhoresta somando as estimativas do

Backlog a cada dia da Sprint. Aquantidade de trabalho restante parauma Sprint a soma do trabalhorestante para tudo do Backlog daSprint. Acompanhe essas somas diariamente e utilize-as para criar umgrfico que mostre o trabalho restante ao longo do tempo. Traandouma linha atravs dos pontos no grfico, o Time pode gerenciar seuprogresso em completar o trabalho de uma Sprint. A durao no considerada em Scrum. O trabalho restante e a data so as nicasvariveis de interesse.

Uma das regras do Scrum est ligada ao objetivo de cada Sprint, que ter como resultado incrementos de funcionalidade potencialmenteentregveis que estejam de acordo com uma definio de prontooperacional.

DICA

Sempre que possvel, desenhe ogrfico de burndown mo emuma folha grande de papel exibidana rea de trabalho do Time. mais provvel que o Time veja umgrfico grande e visvel do que umgrfico de Burndown da Sprint noExcel ou em alguma ferramenta.


21/22


PRONTO

Scrum exige que os Timesdesenvolvam um incremento defuncionalidade do produto a cada

Sprint. Esse incremento deve serpotencialmente entregvel, pois oProduct Owner pode optar porimplantar a funcionalidadeimediatamente. Para isso ser possvel,o incremento deve ser um pedaocompleto do produto. Ele deve estarpronto. Cada incremento deve seradicionado a 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 bemcodificada, refatorada, que tenha passado por testes unitrios, quetenha 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 docontrole de processos empricos no funcionam. Quando algumdescreve algo como pronto, todos devem entender o que prontosignifica.

Pronto define o que o Time quer dizer quando se compromete aaprontar um item de Backlog do Produto em uma Sprint. Algunsprodutos no contm documentao, de forma que sua definio depronto no inclui documentao. Um incremento completamentepronto inclui toda a anlise, projeto, refatoramento, programao,documentao e testes para o incremento e todos os itens do Backlogdo Produto no incremento. Os testes incluem testes de unidade, desistema, de usurio e de regresso, bem como testes no-funcionaiscomo de performance, de estabilidade, de segurana e de integrao.

Pronto inclui tambm qualquer internacionalizao necessria. AlgunsTimes ainda no so capazes de incluir em sua definio de prontotudo o que necessrio para a implantao. Isto deve estar claro para oProduct Owner. Esse trabalho restante dever ser feito antes que oproduto possa ser implantado e utilizado.

DICA

Trabalho "no pronto" geralmenteacumulado em um item do Backlogdo Produto chamado "Trabalho NoPronto" ou "Trabalho deImplantao". medida que essetrabalho acumula, o Burndown doBacklog do Produto se mantmmais preciso do que se essetrabalho no fosse acumulado.


22/22

CONSIDERAES FINAIS

Algumas organizaes so incapazes de desenvolver um incrementocompleto dentro de uma Sprint. Elas podem ainda no ter infraestruturaautomatizada de testes para completar todos os testes. Nesse caso,

duas categorias so criadas para cada incremento: o trabalho pronto eo trabalho no pronto. O trabalho no pronto a poro de cadaincremento que ter que ser completada mais tarde. O Product Ownersabe exatamente o que ele est inspecionando ao final da Sprint,porque o incremento atende definio de pronto e o Product Ownerentende essa definio. O trabalho no pronto adicionado a um itemdo Backlog do Produto chamado trabalho no pronto, de forma que elese acumula e isso refletido corretamente no grfico de Burndown daRelease. 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 deperformance, regresso, estabilidade, segurana e integrao paracada item do Backlog do Produto, a proporo desse trabalho emrelao 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 prontoe quatro peas de no pronto. Se o Time terminar um item de Backlogde Produto de seis unidades de trabalho (o Time est estimando

baseado no que ele sabe como aprontar), quatro unidades seroacrescidas ao item do Backlog do Produto denominado trabalho nopronto quando eles tiverem terminado.

Sprint a Sprint, o trabalho no pronto de cada incremento vai seacumulando e deve ser tratado antes da entrega do produto. Essetrabalho acumulado linearmente, embora haja algum tipo de acmuloexponencial que dependente das caractersticas de cada organizao.Sprints de Release so adicionados ao final de cada release paracompletar o trabalho no pronto. O nmero de Sprints imprevisvel,

visto que o acmulo de trabalho no pronto no linear.

[apostila]guia scrum - br

Documents