Introduo ao Scrum

Veja neste artigo uma apresentao do framework de

gerenciamento de projetos Scrum com seus papis,
cerimnias e artefatos, no contexto de projetos de
software baseada no Guia do Scrum.

Como tudo comeou

Durante muito tempo, empresas de desenvolvimento de software conviveram com uma srie de
problemas relacionados ao gerenciamento de projetos, como prazos no cumpridos, custos
estourados, baixa qualidade nos recursos entregues para o cliente e, consequentemente,
descrdito por parte do cliente em relao s equipes de desenvolvimento.

O manifesto gil
Diante desse cenrio, um grupo de profissionais veteranos no desenvolvimento de software se
reuniu e, em 2001, criou o Manifesto para o Desenvolvimento gil de Software (frequentemente
chamado apenas de Manifesto gil), que compilava um conjunto de princpios que, de acordo
com a experincia de todos, sempre pareciam ter sido respeitados quando um projeto de
software alcanava o sucesso.

O Scrum
Dentre os profissionais que criaram o manifesto gil, estavam Ken Schwaber e Jeff Sutherland
que desenvolveram o Scrum. So eles tambm quem escrevem e fornecem o Guia do Scrum.

Segundo os autores, o Scrum um framework para desenvolver e manter produtos complexos.

O Scrum trabalha com ciclos curtos de desenvolvimento e entrega de software. Dessa maneira, o
feedback sobre o resultado obtido rapidamente, o que garante a qualidade do produto e a
satisfao do cliente, que passa a fazer parte do processo e a perceber os resultados rapidamente.

O Scrum se apoia em 3 pilares fundamentais: Transparncia, Inspeo e Adaptao.

Transparncia
Todos os responsveis pelo resultado devem ter a viso de tudo o que est acontecendo, alm de
um mesmo entendimento do que est sendo visto.

Inspeo
Os artefatos e o progresso em direo ao objetivo devem ser inspecionados frequentemente por
todos os usurios do Scrum, de maneira a detectar desvios indesejveis.

Adaptao
As coisas mudam. O Scrum aceita essa verdade e prega a adaptao a mudanas no lugar de
tentar evit-las. Trabalhando com ciclos curtos, as mudanas so melhor aceitas e menos
dolorosas, uma vez que no existem planos extensos que devero ser mudados para adequar-se a
elas.

Papis
Um time Scrum apresenta 3 papis distintos, que sero melhor explicados a seguir: Scrum
Master, Product Owner e Time de Desenvolvimento.

Aqui uma curiosidade: O nome Scrum refere-se a uma jogada do Rugby, na qual os jogadores
dos dois times entram em uma formao para disputar a bola. Caso um dos jogadores caia, o
time inteiro prejudicado, pois a formao perde a sustentao. Esse o conceito principal por
trs do Scrum, a interdependncia entre todos os componentes do time.

Scrum Master
O Scrum Master ou SM o Mestre do time Scrum. No entanto, ele no um gerente ou coisa
que o valha, uma vez que o time Scrum autogerencivel.

As principais tarefas do Scrum Master so:

Garantir que os membros do time entendam e apliquem as regras do Scrum;

Remover todos os impedimentos que possam atrapalhar o bom andamento do time;
Realizar o treinamento de pessoas / equipes que no sejam familiarizadas com o Scrum;
Ser o facilitador de todos os eventos do Scrum.
O Scrum Master deve ser uma pessoa capaz de inspirar os demais membros do time a serem
autogerenciveis e interdisciplinares, alm de mostrar a importncia dos valores geis. Deve ser
uma pessoa com influncia na organizao e apoio da alta gerncia, uma vez que caber a ele
resolver os impedimentos.

Product Owner
O Product Owner ou PO representa o cliente dentro do time Scrum. sabido que um alto grau
de envolvimento do cliente representa mais assertividade nos resultados. No entanto,
normalmente o cliente no pode estar disponvel para o Time de Desenvolvimento toda vez que
seja necessrio tirar uma dvida ou validar um requisito, por exemplo. Por isso esse papel no
Scrum cabe ao Product Owner.

O Product Owner o responsvel por priorizar os requisitos a serem desenvolvidos, aceitar os

requisitos entregues e fazer a interface entre o Time de Desenvolvimento e o cliente.

O foco do Product Owner maximizar o valor do produto entregue, visando sempre o

desenvolvimento dos requisitos mais importantes para o negcio.

As principais tarefas do Product Owner so:

Manter o Product Backlog;

Aceitar ou rejeitar o trabalho realizado pelo Time de Desenvolvimento;
Priorizar os requisitos a serem implementados;
Estar presente para auxiliar o Time de Desenvolvimento durante a execuo do
trabalho;
Auxiliar o cliente na descoberta de novos requisitos;
Ser o centralizador de demandas que chegaro ao Time de Desenvolvimento;

Caso o Product Owner no possua alguma informao necessria, papel dele realizar esse
levantamento junto ao cliente.

Time de Desenvolvimento
O Time de Desenvolvimento composto por todos os responsveis pelo desenvolvimento dos
requisitos (programadores, testers, DBA's, etc.). Dentro do time, independente de seu cargo na
organizao, todos so conhecidos como Desenvolvedor.

O Time de Desenvolvimento auto gerencivel, ou seja, ningum pode dizer ao time o que
fazer, exceto o prprio time.

De acordo com o Guia do Scrum, o Time de Desenvolvimento idealmente deve ter entre 3 e 9
membros.
Artefatos
O Scrum possui alguns artefatos definidos que tm como principal objetivo possibilitar a
sustentao dos trs pilares do Scrum durante o trabalho, fornecendo transparncia e
oportunidades para inspeo e adaptao durante todo o processo.

A seguir, uma definio dos artefatos definidos no Guia do Scrum

Product Backlog
uma lista priorizada de todos os requisitos necessrios no produto.

O Product Backlog a origem nica de todos os requisitos para qualquer mudana a ser feita no
produto, e mantido pelo Product Owner.

Os primeiros itens do Product Backlog, que so os prioritrios, sero os primeiros a serem

desenvolvidos. Por isso, precisam estar em um nvel tal de detalhe que possibilite o seu
entendimento por todos os envolvidos.

J os itens menos imediatos tm um nvel de detalhe menor, uma vez que no sero
desenvolvidos imediatamente.

A medida que um item vai subindo no backlog, seu nvel de detalhe aumenta.

O Product Backlog nunca est pronto. Uma vez que o Scrum aceita as mudanas, a cada ciclo de
desenvolvimento, novos requisitos so descobertos, e esses devem ser includos no backlog de
acordo com sua prioridade.

Da mesma maneira, durante o ciclo de vida de um produto pode-se perceber que determinados
itens do backlog deixaram de fazer sentido, no sendo mais necessrios. Esses itens devem ser
removidos do Product Backlog to logo se perceba essa necessidade.

Sprint Backlog
uma lista priorizada de tudo que ser desenvolvido na Sprint atual.

Durante toda a Sprint, o Time de Desenvolvimento modifica o backlog, adequando-o as

mudanas ocorridas durante o desenvolvimento.

Somente o Time de Desenvolvimento pode alterar o Sprint Backlog.

Incremento
Ao final de uma sprint, todos os itens que foram finalizados formam um incremento do produto.
Esse incremento deve ser entregvel e utilizvel, de maneira que o cliente perceba valor no
produto a cada final de sprint.

A deciso de liberar ou no o incremento pertence ao Product Owner.

Definio de Pronto
Todos os itens que sero implementados devem possuir uma definio de pronto clara e que faa
sentido para todos os envolvidos.

atravs da definio de pronto que se assegura a transparncia de quando determinada parte do

trabalho estar realmente finalizada.

Somente itens com definio de pronto clara so considerados aptos para terem sua estimativa
realizada e seu desenvolvimento iniciado, uma vez que sem essa informao impossvel para o
Time de Desenvolvimento estimar e realizar o trabalho.

Eventos
O Guia do Scrum descreve alguns eventos, usados para criar uma rotina e diminuir a ocorrncia
de reunies no planejadas.

Os eventos no Scrum so time-boxed, ou seja, possuem um tempo pr-determinado. Isso fora

que o evento seja realizado no tempo estabelecido, evitando desperdcios.

Todos os eventos do Scrum so oportunidades para inspecionar e adaptar algo. A ocorrncia dos
eventos aumenta a transparncia do processo para todos os envolvidos.

Sprint
Com um time-box que varia entre duas e quatro semanas, a sprint o corao do Scrum.
durante a sprint que o trabalho efetivamente realizado pelo Time de Desenvolvimento e, ao seu
final, espera-se obter um incremento potencialmente utilizvel do produto.
A sprint serve como container para todos os outros eventos (como apresentado na Figura 1).

Figura 1: Ciclo da Sprint

Toda sprint possui uma meta. A meta definida pelo Product Owner e deve refletir um objetivo
do negcio. Durante a sprint, o Time de Desenvolvimento se guia pela meta, para saber qual
tarefa mais importante de ser concluda. A meta a grande responsvel por manter todos os
membros do time em sintonia, uma vez que guia o trabalho de todos durante a sprint.

Sprints no podem durar mais do que quatro semanas. Isso porque em quatro semanas as coisas
podem mudar e a meta da sprint deixar de fazer sentido.

Scrum aceita muito bem mudanas, no entanto, durante uma sprint certas coisas no podem ser
alteradas:

A composio do Time de Desenvolvimento;

Critrios de qualidade;
A meta da Sprint.

Caso o aprendizado durante a sprint force alguma alterao no escopo combinado previamente,
isso deve ser negociado entre o Product Owner e o Time de Desenvolvimento.

Durante a sprint, papel do Scrum Master manter o Time de Desenvolvimento isolado de

problemas externos, eliminando todos os impedimentos realizao do trabalho que possam
surgir.

O Product Owner deve estar disponvel durante a sprint o maior tempo possvel. Um Product
Owner ausente costuma ser um grande problema, uma vez que algumas dvidas relacionadas a
regras de negcio s podem ser esclarecidas por ele.
Reunio de Planejamento da Sprint
Com um time-box que varia entre quatro e oito horas, a reunio de planejamento o evento
onde so definidos e discutidos os itens que faro parte da sprint.

Basicamente a reunio de planejamento deve responder duas questes:

O que ser entregue como incremento ao fim da prxima sprint?

Como o trabalho ser realizado para que esse incremento seja entregue?

A reunio de planejamento dividida em duas partes, cada uma com metade do time-box da
reunio, dedicada a responder uma das questes.

O que ser entregue ao fim da sprint?

A entrada para essa parte da reunio o Product Backlog. O Product Owner apresenta ao Time
de Desenvolvimento os itens ordenados, que so entendidos com a colaborao de todos.

Com base em seu desempenho passado, o Time de Desenvolvimento projeta sua capacidade
durante a sprint e avalia quais os itens do backlog podem ser completados durante a sprint. Essa
avaliao preliminar nesse momento, e cabe somente ao Time de Desenvolvimento.

Aps a definio dos itens que sero completados na sprint define-se a meta da sprint. A meta
definida pelo Product Owner, no entanto o time colabora para sua elaborao.

Como o trabalho ser realizado?

Aps selecionar os itens que sero completados na sprint, o Time de Desenvolvimento passa a
discutir como construir as funcionalidades durante a sprint, de maneira que sejam consideradas
completadas (de acordo com a definio de pronto).

Os itens que sero realizados na sprint, junto com seu plano de entrega, compem o Sprint
Backlog.

Feito isso, o Time de Desenvolvimento estima todos os itens do backlog da sprint. Nesse
momento, o Product Owner pode estar presente, para esclarecer alguma dvida que possa surgir
ou mesmo realizar algum ajuste no escopo da sprint, caso o Time de Desenvolvimento julgue
esse ajuste necessrio.

Se sentir necessidade, o Time de Desenvolvimento tambm pode convidar outras pessoas a

participarem da reunio, como especialistas tcnicos, por exemplo.
As estimativas so feitas sempre por todos os membros do Time de Desenvolvimento. Existem
diversas tcnicas de estimativa, mas o mais importante nesse momento que os itens sejam
discutidos por todos at que o Time se sinta confortvel a se comprometer com uma estimativa.

Ao final da reunio, o Time de Desenvolvimento possui o Sprint Backlog e metas definidos,

alm de um plano de trabalho determinado para a entrega dos requisitos.

Reunio diria
Com um time-box de quinze minutos, a reunio diria deve ser realizada sempre no mesmo
local e horrio, contando com a presena de todos os membros do Time de Desenvolvimento.

Somente os membros do Time de Desenvolvimento participam dessa reunio.

Alguns sustentam que essa reunio seja feita com os participantes em p, de maneira a evitar
que o time-box seja desrespeitado.

Nessa reunio, cada membro do Time de Desenvolvimento deve responder trs questes:

O que foi feito desde a ltima reunio?

O que ser feito at a prxima reunio?
Existe algum impedimento para a concluso das tarefas?

A reunio diria uma reunio chave para inspeo e adaptao, uma vez que, a cada 24 horas,
todos os membros do Time de Desenvolvimento tem oportunidade de se reunir, inspecionar o
andamento do trabalho e adapt-lo a alguma necessidade que tenha surgido.

Com a reunio diria, todos os membros do Time de Desenvolvimento so capazes de reportar o

andamento da sprint para o Scrum Master ou Product Owner, por exemplo.

O Scrum Master deve ficar atento aos impedimentos levantados durante a reunio diria, uma
vez que ser sua responsabilidade remov-los para que o trabalho do time possa ser executado.

Reviso da Sprint
Com um time-box entre duas e quatro horas, a reunio de reviso da sprint realizada ao final
da sprint e tem o propsito de inspecionar o incremento e atualizar o Product Backlog, se
necessrio.

Nessa reunio, o Time de Desenvolvimento e as partes interessadas discutem sobre o que foi
feito na sprint e tambm sobre os prximos itens a serem entregues.

Essa reunio tem o intuito de promover ao Time de Desenvolvimento um feedback sobre o

trabalho realizado durante a sprint, motivando-o e promovendo a colaborao.
Durante essa reunio, o Product Owner identifica o que foi pronto e o que no foi pronto, de
acordo com a definio estabelecida. Alm disso, discute e revisa o Product Backlog, projetando
as provveis datas de concluso de acordo com o andamento at o momento.

O Time de Desenvolvimento levanta o que foi bem durante a sprint, alm dos problemas
ocorridos e como foram resolvidos. Alm disso, o Time de Desenvolvimento apresenta o que
est pronto e tambm responde questes sobre o incremento.

Retrospectiva da Sprint
Com um time-box entre uma e trs horas, a reunio de retrospectiva da sprint serve para o Time
de Desenvolvimento promover sua melhoria contnua.

Nessa reunio o Scrum Master, como facilitador, deve incentivar o Time de Desenvolvimento a
levantar os seguintes pontos:

Como a sprint transcorreu em relao s pessoas, aos processos, s ferramentas, etc;

Levantar os pontos positivos da sprint e os pontos a melhorar;
Montar um plano para implementar melhorias no trabalho do Time de
Desenvolvimento.

Ao final dessa reunio, o time possui uma lista de melhorias a serem realizadas para a prxima
sprint, alm de uma lista do que deu certo e deve ser repetido.

Encerro aqui esse artigo introdutrio sobre Scrum. Espero que ele tenha sido claro o bastante.
Abraos e at prxima.

Leia mais em: Introduo ao Scrum http://www.devmedia.com.br/introducao-ao-

scrum/27887#ixzz3yPokyoam