Novembro de 2009

Scrum: Desenvolvido e mantido por Ken Schwaber e Jeff Sutherland

Traduo Heitor Roriz Filho Michel Goldenberg Rafael Sabbagh Reviso Anderson Marcondes nderson Quadros Ari do Amaral Torres Filho Marcos Garrido Rafael Fuchs Rafael Prikladnicki Rodrigo de Toledo Rafael Sabbagh (coordenao)

2008-2009 Ken Schwaber e Jeff Sutherland, Todos os Direitos Reservados

Pgina | 2

AGRADECIMENTOS

GERAL
Scrum baseado nas melhores prticas aceitas pelo mercado, utilizadas e provadas por dcadas. Ele definido ento em uma teoria de processos empricos. Como Jim Coplien certa vez observou para o Jeff, Todos iro gostar de Scrum; ele o que j fazemos quando estamos pressionados 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.

HISTRIA
A 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 Medial).

2008-2009 Ken Schwaber e Jeff Sutherland, Todos os Direitos Reservados

Pgina | 3

PROPSITO
Scrum vem sendo utilizado para o desenvolvimento de produtos complexos desde o incio dos anos 90. Este guia descreve como usar o Scrum para desenvolver produtos. Scrum no um processo ou uma tcnica para o desenvolvimento de produtos. Ao invs disso, um framework dentro do qual voc pode empregar diversos processos e tcnicas. O papel do Scrum fazer transparecer a eficcia relativa das suas prticas de desenvolvimento para que voc possa melhor-las, enquanto prov um framework dentro do qual produtos complexos podem ser desenvolvidos.

TEORIA DO SCRUM
Scrum, que fundamentado na teoria de controle de processos empricos, emprega uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos. Trs pilares sustentam qualquer implementao de controle de processos empricos.

O PRIMEIRO PILAR A TRANSPARNCIA

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

O SEGUNDO PILAR A INSPEO

Os diversos aspectos do processo devem ser inspecionados com uma frequncia suficiente para que variaes inaceitveis no processo possam ser detectadas. A frequncia da inspeo deve levar em considerao que qualquer processo modificado pelo prprio ato da inspeo. O problema acontece quando a frequncia de inspeo necessria excede a tolerncia do processo inspeo. Os outros

2008-2009 Ken Schwaber e Jeff Sutherland, Todos os Direitos Reservados

Pgina | 4

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 mais aspectos 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 Reunio Diria 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 Reviso da Sprint e de Planejamento da Sprint so utilizadas para inspecionar o 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 SCRUM
O framework Scrum consiste em um conjunto formado por Times Scrum e seus papis associados, Eventos com Durao Fixa (TimeBoxes), Artefatos e Regras. Times Scrum so projetados para otimizar flexibilidade e produtividade. Para esse fim, eles so auto-organizveis, interdisciplinares e trabalham em iteraes. Cada Time 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 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.

2008-2009 Ken Schwaber e Jeff Sutherland, Todos os Direitos Reservados

Pgina | 5

Scrum emprega os eventos com durao fixa (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 Reunio Diria, 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 Backlog do Produto uma lista priorizada de tudo que pode ser necessrio no produto. O Backlog da 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 pelo tempo. Um Burndown de Release mede o Backlog do Produto restante ao longo do tempo de um plano de release. Um Burndown de Sprint mede os itens do Backlog da Sprint restantes ao longo do tempo de uma Sprint. As Regras fazem o elo entre os eventos com durao fixa (timeboxes), os papis e os artefatos do Scrum. Suas regras so descritas ao longo deste documento. Por exemplo, uma regra do Scrum diz que somente membros do Time - as pessoas comprometidas em transformar o Backlog do Produto em um incremento - podem falar durante uma Reunio Diria. Modos de implementar Scrum que no so regras, mas sim sugestes, esto descritas nas sees de "Dicas". DICA
Quando as regras no so declaradas, espera-se que os usurios de Scrum descubram o que devem fazer. No tente descobrir uma soluo perfeita, porque geralmente o problema muda rapidamente. Ao invs disso, tente algo e veja como se sai. Os mecanismos de inspeo-eadaptao inerentes natureza emprica de Scrum iro lhe guiar.

PAPIS NO SCRUM
O Time Scrum composto pelo ScrumMaster, pelo Product Owner e pelo Time. Os membros do Time Scrum so chamados porcos. Qualquer outra pessoa chamada de galinha. Galinhas no podem
Pgina | 6

2008-2009 Ken Schwaber e Jeff Sutherland, Todos os Direitos Reservados

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 Scrum esteja aderindo aos valores do Scrum, s prticas e s regras. O ScrumMaster ajuda o Time Scrum e a organizao a adotarem o Scrum. O ScrumMaster educa o Time Scrum treinando-o e levando-o a ser mais produtivo e a desenvolver produtos de maior qualidade. O ScrumMaster ajuda o Time Scrum a entender e usar autogerenciamento e interdisciplinaridade. O ScrumMaster tambm ajuda o Time 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. No entanto, o ScrumMaster no gerencia o Time Scrum; o Time Scrum autoorganizvel. DICA
O ScrumMaster trabalha com os clientes e a gerncia para identificar e designar um Product Owner. O ScrumMaster ensina ao Product Owner como fazer seu trabalho. Espera-se dos Product Owners que eles saibam como conseguir otimizar valor atravs do Scrum. Se eles no souberem, consideramos o ScrumMaster responsvel.

DICA
O ScrumMaster pode ser um membro do Time; por exemplo, um desenvolvedor realizando tarefas da Sprint. No entanto, isso frequentemente leva a conflitos quando o ScrumMaster deve escolher entre remover impedimentos e realizar tarefas. O ScrumMaster nunca deve ser o Product Owner.

2008-2009 Ken Schwaber e Jeff Sutherland, Todos os Direitos Reservados

Pgina | 7

O PRODUCT OWNER
O Product Owner a nica pessoa responsvel pelo gerenciamento do Backlog do Produto e por garantir o valor do trabalho realizado pelo Time. Essa pessoa mantm o Backlog do Produto e garante que ele est visvel para todos. Todos sabem quais itens tm a maior prioridade, de forma que todos sabem em que se ir trabalhar. DICA
Para desenvolvimento comercial, o Product Owner pode ser o Gerente de Produto. Para esforos internos de desenvolvimento, o Product Owner poderia ser o gerente da funo de negcios em que se est trabalhando.

DICA

O Product Owner uma pessoa, O Product Owner pode ser um membro e no um comit. Podem existir do Time, trabalhando tambm em comits que aconselhem ou desenvolvimento. Mas essa influenciem essa pessoa, mas responsabilidade adicional pode reduzir a quem quiser mudar a prioridade sua habilidade de lidar com as partes de um item, ter que convencer o interessadas. No entanto, o Product Product Owner. Empresas que Owner nunca pode ser o ScrumMaster. adotam 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 decises do Product Owner so visveis no contedo e na priorizao do Backlog do Produto. 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 Backlog do Produto em incrementos de funcionalidades potencialmente entregveis em cada Sprint. Times tambm so interdisciplinares: membros do Time devem possuir todo o conhecimento necessrio para criar um incremento no trabalho. Membros do Time frequentemente possuem conhecimentos
2008-2009 Ken Schwaber e Jeff Sutherland, Todos os Direitos Reservados
Pgina | 8

especializados, como programao, controle de qualidade, anlise de negcios, arquitetura, projeto de interface de usurio 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 como testes ou anlise de negcios. Times tambm so auto-organizveis. Ningum - nem mesmo o ScrumMaster - diz ao time como transformar o Backlog do Produto em incrementos 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 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 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. A composio do Time pode mudar ao final da Sprint. Toda vez que o Time muda, a produtividade ganha atravs da auto-organizao reduzida. Deve-se tomar cuidado ao mudar a composio do Time.

TIME-BOXES
Os Eventos com Durao Fixa (Time-Boxes) no Scrum so a Reunio de Planejamento da Release, a Sprint, a Reunio de Planejamento

2008-2009 Ken Schwaber e Jeff Sutherland, Todos os Direitos Reservados

Pgina | 9

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

REUNIO DE PLANEJAMENTO DA RELEASE

O propsito do planejamento da release o de estabelecer um plano e metas que o Time Scrum e o resto da organizao possam entender e comunicar. O planejamento da release responde s questes: Como podemos transformar a viso em um produto vencedor 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 Backlog do Produto, 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 pode ento inspecionar o progresso e fazer mudanas nesse plano da release a cada Sprint. O planejamento da release inteiramente opcional. Se um Time Scrum iniciar o trabalho sem essa reunio, a ausncia de seus artefatos aparecer como um impedimento que dever ser resolvido. O trabalho para resolver o impedimento se tornar um item no Backlog do Produto. Ao se utilizar Scrum, os produtos so construdos iterativamente, de modo que cada Sprint cria um incremento do produto, iniciando pelo de maior valor e maior risco. Mais e mais Sprints vo adicionando incrementos ao produto. Cada incremento um pedao potencialmente entregvel do produto completo. Quando j tiverem sido criados incrementos suficientes para que o produto tenha valor e uso para seus investidores, o produto entregue. 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 do tempo. 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 de Sprint, da mesma forma que realiza um planejamento dirio no momento da execuo de

2008-2009 Ken Schwaber e Jeff Sutherland, Todos os Direitos Reservados

Pgina | 10

cada Reunio Diria. 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 Backlog do Produto 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.

A SPRINT
A Sprint uma iterao. Sprints so eventos com durao fixa. Durante a DICA Sprint, o ScrumMaster garante que Se o time sentir que se no ser feita nenhuma mudana que comprometeu com mais do que possa afetar a Meta da Sprint. Tanto a podia, ele se encontra com o composio do time quanto as metas Product Owner para remover ou de qualidade devem permanecer reduzir o escopo do Backlog do constantes durante a Sprint. As Produto selecionado para a Sprint. sentir que sobrar tempo, Sprints contm e consistem na Se o timetrabalhar junto ao Product ele pode reunio de Planejamento de Sprint, o Owner para selecionar mais do trabalho de desenvolvimento, a Backlog do Produto. 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 DICA software, o projeto utilizado para Quando um Time comea com o desenvolver um produto ou sistema. Scrum, Sprints de duas semanas o Cada projeto consiste em uma permite aprender sem se afundar definio do que ser desenvolvido, na incerteza. Sprints desse um plano para desenvolv-lo, o tamanho podem ser sincronizadas trabalho realizado de acordo com o com outros Times adicionando-se plano e o produto resultante. Cada dois incrementos juntos. projeto possui um horizonte, que o perodo de tempo para o qual o plano vlido. Se o horizonte for longo demais, a definio poder ter mudado, variveis demais podero ter surgido, o risco poder ser grande demais etc. Scrum um framework para projetos cujo horizonte no superior ao perodo de um ms, onde j h complexidade suficiente tal que um horizonte mais longo seria
Pgina | 11

2008-2009 Ken Schwaber e Jeff Sutherland, Todos os Direitos Reservados

arriscado demais. A previsibilidade do projeto deve ser controlada pelo menos a cada ms, e o risco de que o projeto saia de controle ou se torne imprevisvel contido pelo menos a cada ms. As Sprints podem ser canceladas antes que o prazo fixo da Sprint tenha acabado. Somente o Product Owner tem a autoridade para cancelar a Sprint, embora ele possa faz-lo sob influncia das partes interessadas, do Time ou do ScrumMaster. Sob que tipo de circunstncias pode ser necessrio cancelar uma Sprint? A gerncia pode precisar cancelar uma Sprint se a Meta da Sprint se tornar obsoleta. Isso pode ocorrer se a empresa mudar de direo ou se as condies do mercado ou tecnologia mudarem. Em geral, uma Sprint deve ser cancelada se ela no fizer mais sentido dadas as circunstncias atuais. Porm, por causa da curta durao das Sprints, raramente isso faz sentido. Quando uma Sprint cancelada, todos os itens do Backlog do Produto que estejam completados e "feitos" so revisados. Eles so aceitos se representarem um incremento potencialmente entregvel. Todos os outros itens do Backlog do Produto so devolvidos ao Backlog do Produto com suas estimativas iniciais. Assume-se que qualquer trabalho realizado nesses itens perdido. Cancelamentos de Sprints consomem recursos, j que todos tm que se reagrupar em outra reunio de Planejamento de Sprint para iniciar uma nova Sprint. Cancelamentos de Sprints so frequentemente traumticos para o Time e so muito incomuns.

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, aloca-se para essa reunio aproximadamente 5% do tamanho total da Sprint, e ela consiste de duas partes. A primeira parte, um evento com durao fixa de quatro horas, o momento no qual decidido o que ser feito na Sprint. A segunda parte, outro evento com durao fixa de quatro horas, o momento no qual o Time entende como 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 Scrum juntam as duas. Na primeira parte, o Time Scrum trata da questo do o qu?. Aqui, o

2008-2009 Ken Schwaber e Jeff Sutherland, Todos os Direitos Reservados

Pgina | 12

Product Owner apresenta ao Time o que mais prioritrio no Backlog do Produto. Eles trabalham em conjunto para definir qual funcionalidade dever ser desenvolvida durante a prxima Sprint. As entradas para essa reunio so o Backlog do Produto, 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 Backlog do Produto, a Meta da Sprint delineada. A Meta da Sprint o objetivo que ser atingido atravs da implementao do Backlog do Produto. 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 a Sprint acima poderia tambm ser: Automatizar a funcionalidade de modificao de conta de clientes atravs de um middleware seguro capaz de recuperar transaes. Conforme o Time trabalha, ele mantm a meta em mente. Para satisfazer a meta, ele implementa a funcionalidade e a tecnologia. Se o trabalho se mostrar mais difcil do que o time esperava, o time ento ir colaborar com o Product Owner e implementar a funcionalidade apenas parcialmente. Na segunda parte da Reunio de Planejamento da Sprint, o Time trata a questo do como?. Durante as quatro horas seguintes da Reunio de Planejamento da Sprint, o Time define como transformar o Backlog do Produto selecionado durante a Reunio de Planejamento (o qu) em um incremento pronto. O Time geralmente comea projetando o trabalho. Enquanto projeta, o time identifica tarefas. Essas tarefas so pedaos detalhados do trabalho necessrio para converter o Backlog do Produto em software funcional. As tarefas devem ser decompostas para que possam ser feitas em menos de um dia. Essa lista de tarefas chamada de Backlog da Sprint. O time se auto-organiza para se encarregar e se responsabilizar pelo trabalho contido no Backlog da Sprint, tanto durante a Reunio de Planejamento da Sprint quanto no prprio momento da execuo da Sprint.

2008-2009 Ken Schwaber e Jeff Sutherland, Todos os Direitos Reservados

Pgina | 13

O Product Owner est presente durante a segunda parte da Reunio DICA de Planejamento da Sprint para Geralmente, somente 60-70% do esclarecer o Backlog do Produto e total do Backlog da Sprint ser para ajudar a efetuar trocas. Se o definido na Reunio de Time concluir que ele tem trabalho Planejamento da Sprint. O restante demais ou de menos, ele pode deixado para ser detalhado mais renegociar o Backlog do Produto tarde ou so dadas estimativas escolhido com o Product Owner. O grandes que sero decompostas mais tarde na Sprint. Time tambm pode 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 ou perder como um Time - no individualmente - nessa reunio. O Time percebe que deve contar consigo mesmo. Conforme ele percebe isso, ele comea a se auto-organizar para assumir as caractersticas e comportamento de um verdadeiro Time.

REVISO DA SPRINT
Ao final da Sprint, feita 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, essa reunio no deve tomar mais do que 5% do total da Sprint. Durante a Reviso da Sprint, o Time Scrum e as partes interessadas colaboram sobre o que acabou de ser feito. Baseados nisso e em mudanas no Backlog do Produto feitas durante a Sprint, eles colaboram sobre quais so as prximas coisas que podem ser feitas. Essa uma reunio informal, com a apresentao da funcionalidade, que tem a inteno de promover a colaborao sobre o que fazer em seguida. A reunio inclui ao menos os seguintes elementos. O Product Owner identifica 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, alm de como esses problemas foram resolvidos. O Time ento demonstra o trabalho que est pronto e responde a questionamentos. O Product Owner ento discute o Backlog do Produto da maneira como esse se encontra. Ele faz projees de datas de concluso provveis a partir de vrias hipteses de velocidade. Em seguida, o grupo inteiro colabora sobre o que foi visto e o que isso significa com relao ao que fazer em

2008-2009 Ken Schwaber e Jeff Sutherland, Todos os Direitos Reservados

Pgina | 14

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

RETROSPECTIVA DA SPRINT
Aps a Reviso da Sprint e antes da prxima reunio de Planejamento da Sprint, o Time Scrum tem a reunio de Retrospectiva da Sprint. Nessa reunio, com durao fixa de trs horas, o ScrumMaster encoraja o Time a revisar, dentro do modelo de trabalho e das prticas do processo do Scrum, seu processo de desenvolvimento, de forma a torn-lo mais eficaz e gratificante para a prxima Sprint. Muitos livros documentam tcnicas que so teis em Retrospectivas. A finalidade da Retrospectiva inspecionar como correu a ltima Sprint em se tratando de pessoas, das relaes entre elas, dos processos e das ferramentas. A inspeo deve identificar e priorizar os principais itens que correram bem e aqueles que, se feitos de modo diferente, poderiam ter deixado as coisas ainda melhores. Isso inclui a composio do time, preparativos para reunies, ferramentas, definio de pronto, mtodos de comunicao e processos para transformar itens do Backlog do Produto em alguma coisa pronta. No final da Retrospectiva da Sprint, o Time Scrum deve ter identificado medidas de melhoria 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 minutos chamada Reunio Diria. 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 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 outras reunies, identificam e removem impedimentos para o
2008-2009 Ken Schwaber e Jeff Sutherland, Todos os Direitos Reservados
Pgina | 15

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 Reunio Diria. O ScrumMaster ensina o time a manter a Reunio Diria com curta durao, reforando as regras e garantido que as pessoas falem brevemente. O ScrumMaster tambm enfatiza a regra de que galinhas no esto autorizadas a falar e nem a interferir de modo algum na Reunio Diria. A Reunio Diria no uma reunio de status. Ela s para as pessoas que esto transformando os itens do Backlog do Produto em um incremento (o Time), e para mais ningum. O Time se comprometeu com uma Meta da Sprint, e a esses itens do Backlog do Produto. A Reunio Diria uma inspeo do progresso na direo da Meta da Sprint (as trs perguntas). Geralmente acontecem reunies subsequentes para realizar adaptaes ao trabalho que est por vir na Sprint. A inteno otimizar a probabilidade de que o Time alcance sua Meta. Essa uma reunio fundamental de inspeo e adaptao no processo emprico do Scrum.

ARTEFATOS DO SCRUM
Os artefatos do Scrum incluem o Backlog do Produto, o Burndown da Release, o Backlog da Sprint e o Burndown da Sprint.

BACKLOG DO PRODUTO E BURNDOWN DA RELEASE

Os requisitos para o produto que o(s) Time(s) est(o) desenvolvendo esto listados no Backlog do Produto. O Product Owner o responsvel pelo Backlog do Produto, por seu contedo, por sua disponibilidade e por sua priorizao. O Backlog do Produto nunca est completo. A seleo inicial para o seu desenvolvimento somente mostra os requisitos inicialmente conhecidos e melhor entendidos. O Backlog do Produto 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

2008-2009 Ken Schwaber e Jeff Sutherland, Todos os Direitos Reservados

Pgina | 16

para ser apropriado, competitivo e til. Enquanto existir um produto, o Backlog de Produto tambm existir. O Backlog do Produto representa tudo que necessrio para desenvolver e DICA lanar um produto de sucesso. uma Os itens do Backlog do Produto so lista de todas as caractersticas, geralmente representados como funes, tecnologias, melhorias e Estrias de Usurio. Casos de Uso correes de defeitos que constituem tambm so apropriados, mas so as mudanas que sero efetuadas no mais adequados para produto para releases futuras. Os desenvolvimento de softwares itens do Backlog do Produto possuem crticos em termos de vidas ou de desempenho. os atributos de descrio, prioridade e estimativa. A prioridade determinada por risco, valor e necessidade. H diversas tcnicas para dar valor a esses atributos. O Backlog do Produto ordenado por prioridade. O Backlog do Produto 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. O Backlog 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 de detalhe, at que mal se consiga entender o item. medida que um produto utilizado, que seu valor aumenta e que o mercado fornece feedback, o Backlog do Produto torna-se uma lista maior e mais aprofundada. Os requisitos nunca param de mudar. O Backlog do Produto um documento vivo. Mudanas nos requisitos de negcios, condies do mercado, tecnologia e equipe causam mudanas no Backlog do Produto. Para minimizar o retrabalho, apenas os itens de maior prioridade precisam ser DICA
Os Times Scrum geralmente gastam 10% de cada Sprint preparando o Backlog do Produto para adequ-lo definio de Backlog do Produto feita acima. Quando estiverem adequados a esse nvel de granularidade, os itens no topo do Backlog do Produto (de maior prioridade e de maior valor) so decompostos de forma que caibam em um Sprint. Eles foram analisados e se refletiu sobre eles durante esse processo de preparao. Quando ocorre a reunio de Planejamento de Sprint, esses itens de maior prioridade do Backlog do Produto esto bem entendidos e so facilmente selecionados.

2008-2009 Ken Schwaber e Jeff Sutherland, Todos os Direitos Reservados

Pgina | 17

mais detalhados. Os itens do Backlog do Produto que ocuparo os Times Scrum pelas vrias Sprints seguintes devero ter granularidade mais fina, tendo sido decompostos de forma tal que cada um dos itens possa ser feito dentro da durao da Sprint. Frequentemente, mltiplos Times Scrum trabalham juntos no mesmo produto. Um nico Backlog do Produto usado para descrever o trabalho a ser realizado no produto. Ento, um atributo que agrupe os itens aplicado no Backlog do Produto. 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 Scrum. DICA
Testes de aceitao so frequentemente utilizados como um outro atributo para o item do Backlog do Produto. Eles podem frequentemente substituir descries textuais mais detalhadas com uma descrio testvel do que o item do Backlog do Produto deve fazer uma vez que esteja completo.

O grfico de Burndown da Release registra a soma das estimativas dos esforos restantes do Backlog do Produto ao longo do tempo. O esforo estimado deve estar em qualquer unidade de medida de trabalho que o Time Scrum e a organizao tenham decidido usar. As unidades de tempo geralmente so Sprints.

2008-2009 Ken Schwaber e Jeff Sutherland, Todos os Direitos Reservados

Pgina | 18

As estimativas dos itens do Backlog do Produto 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 revistos e revisados. Entretanto, eles podem ser atualizados em qualquer momento. O Time responsvel por todas as estimativas. O Product Owner 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 Backlog do Produto 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.

DICA
Em algumas organizaes, acrescenta-se mais trabalho ao Backlog do que se realiza. Isso pode criar uma linha de tendncia plana ou at com inclinao crescente. Para compensar isso e manter a transparncia, um novo piso pode ser criado quando se adiciona ou quando se subtrai trabalho. O piso deve adicionar ou remover somente mudanas significativas e deve ser bem documentado.

DICA
A linha de tendncia pode no ser confivel pelas duas ou trs primeiras Sprints de uma release, a menos que os times j tenham trabalhado juntos anteriormente, conheam bem o produto e entendam a tecnologia envolvida.

BACKLOG DA SPRINT E BURNDOWN DA SPRINT

O Backlog da Sprint consiste nas tarefas que o time executa para transformar itens do Backlog do Produto em um incremento pronto. Muitas delas so elaboradas durante a Reunio de Planejamento da Sprint. O Backlog da Sprint todo trabalho que o Time identifica como necessrio para alcanar a Meta da Sprint. Os itens do Backlog da Sprint devem ser decompostos. A decomposio deve ser suficiente para que mudanas no progresso possam ser entendidas na Reunio Diria. O Time modifica o Backlog da Sprint no decorrer da Sprint, bem como surge Backlog da Sprint 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 Backlog da Sprint. medida que se trabalha nas tarefas ou que elas so completadas, as horas estimadas de trabalho restantes
2008-2009 Ken Schwaber e Jeff Sutherland, Todos os Direitos Reservados
Pgina | 19

para cada tarefa so atualizadas. Quando se verifica que determinadas tarefas so desnecessrias, elas so removidas. Somente o Time pode modificar o seu Backlog da Sprint durante uma Sprint. Somente o Time pode mudar o seu contedo ou as suas estimativas. O Backlog da Sprint um retrato em tempo real altamente visvel do trabalho que o Time planeja efetuar durante a Sprint, e ele pertence unicamente ao Time. O Burndown do Backlog da Sprint um grfico da quantidade restante de DICA trabalho do Backlog da Sprint em Sempre que possvel, desenhe o uma determinada Sprint ao longo do grfico de burndown mo em tempo da Sprint. Para criar esse uma folha grande de papel exibida grfico, determine quanto trabalho na rea de trabalho do Time. resta somando as estimativas do mais provvel que o Time veja um Backlog a cada dia da Sprint. A grfico grande e visvel do que um da Sprint no quantidade de trabalho restante para grfico de Burndown ferramenta. Excel ou em alguma uma Sprint a soma do trabalho restante para tudo do Backlog da Sprint. 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.

2008-2009 Ken Schwaber e Jeff Sutherland, Todos os Direitos Reservados

Pgina | 20

PRONTO
Scrum exige que os Times desenvolvam um incremento de DICA funcionalidade do produto a cada Trabalho "no pronto" geralmente Sprint. Esse incremento deve ser acumulado em um item do Backlog potencialmente entregvel, pois o do Produto chamado "Trabalho No Product Owner pode optar por Pronto" ou "Trabalho de implantar a funcionalidade Implantao". medida que esse imediatamente. Para isso ser possvel, trabalho acumula, o Burndown do o incremento deve ser um pedao Backlog do Produto se mantm mais preciso do que se esse completo do produto. Ele deve estar trabalho no fosse acumulado. pronto. Cada incremento deve ser adicionado a todos os incrementos anteriores e exaustivamente testado, garantindo que todos os incrementos funcionem juntos. No desenvolvimento de produtos, afirmar que a funcionalidade est pronta pode levar algum a presumir que ela est pelo menos bem codificada, refatorada, que tenha passado por testes unitrios, que tenha sido feito o build e 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 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 a aprontar um item de Backlog do Produto 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 Backlog do Produto 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 o Product Owner. Esse trabalho restante dever ser feito antes que o produto possa ser implantado e utilizado.

2008-2009 Ken Schwaber e Jeff Sutherland, Todos os Direitos Reservados

Pgina | 21

CONSIDERAES FINAIS
Algumas organizaes so incapazes de desenvolver um incremento completo dentro de uma Sprint. Elas podem ainda no ter infraestrutura 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 Backlog do Produto 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 Backlog do Produto, a proporo desse trabalho em relao ao trabalho que pode ser pronto (anlise, projeto, refatoramento, programao, documentao, testes unitrio e testes de usurio) calculada. Vamos supor que essa proporo de seis peas de pronto e quatro peas de no pronto. Se o Time terminar um item de Backlog de Produto de seis unidades de trabalho (o Time est estimando baseado no que ele sabe como aprontar), quatro unidades sero acrescidas ao item do Backlog do Produto denominado trabalho no pronto quando eles tiverem terminado. Sprint a Sprint, o trabalho no pronto de cada incremento vai se acumulando e deve ser tratado antes da entrega do produto. Esse trabalho acumulado linearmente, embora haja algum tipo de acmulo exponencial que dependente das caractersticas de cada organizao. Sprints de 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.

2008-2009 Ken Schwaber e Jeff Sutherland, Todos os Direitos Reservados

Pgina | 22