SERVIO PBLICO FEDERAL - MINISTRIO DA EDUCAO

INSTITUTO FEDERAL DE EDUCAO, CINCIA E TECNOLOGIA TRINGULO

MINEIRO
GESTO COMERCIAL SISTEMAS DE INFORMAO APLICADOS AO COMRCIO
PROF. ESP. DNIS HENRIQUE DE DEUS LIMA

Mtodos geis - SCRUM

1 MTODOS GEIS

At o incio da dcada de 1990, acreditava-se que a melhor maneira de obter

sucesso no desenvolvimento de software era com um planejamento completo e detalhado,
elaborado antes do incio do projeto. Essa abordagem pesada, baseada em planos e em
documentao macia, foi aplicada em pequenos e mdios projetos, sendo constatado que o
tempo gasto para determinar como o sistema deveria ser desenvolvido era maior do que o
gasto na criao e teste do software. A insatisfao com essa abordagem levou alguns
especialistas a proporem mtodos geis de desenvolvimento. (SOMMERVILLE, 2011)
Em 2001, Kent Beck e outros renomados autores, consultores e desenvolvedores
da rea de software, assinaram o Manifesto para o Desenvolvimento gil de Software. O
mesmo tem como finalidade sanar as fraquezas reais e perceptveis da engenharia de software
convencional. (BECK et al., 2001)
As condies de mercado e as ideias das pessoas esto em constante mutao. Em
muitas situaes no possvel definir com clareza todos os requisitos antes do incio do
projeto. A agilidade veio com a finalidade de fornecer uma resposta rpida e consistente ao
ambiente fluido de negcios.
Fluidez implica diretamente mudanas, e mudanas so relativamente caras,
principalmente se forem sem controle e mal coordenadas. Uma das grandes vantagens
reconhecidas pelo emprego de metodologias geis a reduo do custo de mudana ao longo
do processo de desenvolvimento de software. (PRESSMAN, 2011)
De acordo com Pressman (2011, p. 81),
a engenharia de software gil combina filosofia com um conjunto de
princpios de desenvolvimento. A filosofia defende a satisfao do cliente e
a entrega de incremental prvio; equipes de projetos pequenas e altamente
motivadas; mtodos informais; artefatos de engenharia de software mnimos
e, acima de tudo, simplicidade no desenvolvimento geral. Os princpios de
desenvolvimento priorizam a entrega mais que a anlise e projeto (embora
essas atividades no sejam desencorajadas); tambm priorizam a
comunicao ativa e contnua entre desenvolvedores e clientes.

Perante os desafios impostos pela moderna realidade e o uso de metodologias

geis, em consonncia com Pressman (2001), no podemos descartar os importantes

SERVIO PBLICO FEDERAL - MINISTRIO DA EDUCAO

INSTITUTO FEDERAL DE EDUCAO, CINCIA E TECNOLOGIA TRINGULO
MINEIRO
GESTO COMERCIAL SISTEMAS DE INFORMAO APLICADOS AO COMRCIO
PROF. ESP. DNIS HENRIQUE DE DEUS LIMA

princpios pregados pela engenharia de software, pois os mesmos continuam em constante

processo de evoluo e podendo ser empregados com facilidades em ambientes geis.
Ainda segundo o autor, o desenvolvimento gil apresenta benefcios bem
notveis. No entanto, no designado a todos os produtos, projetos, situaes e pessoas.

2.1 SCRUM

O Scrum um framework voltado para desenvolvimento gil de software criado

por Jeff Shuterland e sua equipe em meados da dcada de 1990. Este nome pertence a uma
atividade que executada durante uma partida de rugby1 (PRESSMAN, 2011). O mtodo gil
utiliza uma abordagem iterativa e incremental, com a finalidade de construir um software
gradativamente, possibilitando melhorias, provises de riscos e medidas de controle. (COHN,
2011)
Os fundamentos do Scrum foram criados condizentes com o manifesto gil e so
utilizados para guiar o desenvolvimento dentro de um processo que tem como base as
seguintes atividades estruturais: requisitos, anlise, projeto, evoluo e entrega. Estas
atividades so desenvolvidas dentro de um padro definido como Sprint, como pode ser visto
na Figura 1. O nmero de Sprints pode variar de acordo com o tamanho e a complexidade do
produto que venha a ser desenvolvido. (PRESSMAN, 2011)

Figura 1 Ciclo de vida do SCRUM

FONTE: http://blog.concretesolutions.com.br/
1

Um grupo de jogadores faz uma formao em torno da bola e seus companheiros de equipe
trabalham juntos para avanar com a bola sentido ao fundo do campo.

SERVIO PBLICO FEDERAL - MINISTRIO DA EDUCAO

INSTITUTO FEDERAL DE EDUCAO, CINCIA E TECNOLOGIA TRINGULO
MINEIRO
GESTO COMERCIAL SISTEMAS DE INFORMAO APLICADOS AO COMRCIO
PROF. ESP. DNIS HENRIQUE DE DEUS LIMA

O Scrum provou ser eficaz atravs de um conjunto de padres de processo de

software utilizados em projetos com prazos de entregas pequenos, de vrios tamanhos e com
requisitos crticos com grande chance de alterao. Cada um desses padres caracteriza um
conjunto de papis, cerimnias e artefatos de desenvolvimento que ser apresentada nos
prximos pargrafos. (COHN, 2011)

2.1.1 Papis

O Product Owner, ou dono do produto, um dos papis mais desafiadores de um

projeto Scrum. Segundo Cohn (2011), o dono do produto fica exposto a necessidades internas
e externas coexistentes, como a participao em reunies de planejamento ou a captura de
requisitos junto aos usurios finais. parte integral da equipe, sendo responsvel pela viso
do produto, pelos itens e tambm pela priorizao do backlog no ponto de vista empresarial,
levando em considerao aspectos como valor, risco, prioridade e necessidade. O cliente deve
ser disponvel, comunicativo e determinado, deve responder com autoridade e ter uma boa
viso no negcio.
O Scrum Master o responsvel por controlar e auxiliar toda equipe. Ele
especialista em Scrum, e dentre as suas principais atividades esto ajuda ao time na criao e
gerenciamento do backlog, treinar membros e remover impedimentos. (PHAM, A.; PHAM,
P., 2012)
A Equipe de Desenvolvimento (Team) responsvel pela construo do produto,
desde os levantamentos de requisitos at a codificao e testes. A Equipe de Desenvolvimento
definida como auto-organizvel e multifuncional.
O Time Scrum (Scrum Team) constitudo pelo Product Owner, pelo Scrum
Master e pela Equipe de Desenvolvimento (Team). Alm dos papeis j apresentados, o Scrum
tambm baseados em artefatos e cerimonias. (SCHWABER; SUTHERLAND, 2013)

2.1.2 Cerimnias

Os eventos definidos pelo Scrum tem a finalidade de criar uma rotina de trabalho
e minimizar a necessidade de reunies no previstas pelo mesmo. Todas essas cerimnias so
time-boxed, ou seja, o evento possui uma durao mxima definida. Esses eventos so

SERVIO PBLICO FEDERAL - MINISTRIO DA EDUCAO

INSTITUTO FEDERAL DE EDUCAO, CINCIA E TECNOLOGIA TRINGULO
MINEIRO
GESTO COMERCIAL SISTEMAS DE INFORMAO APLICADOS AO COMRCIO
PROF. ESP. DNIS HENRIQUE DE DEUS LIMA

planejados a fim de garantir uma transparncia e uma inspeo detalhada. A no utilizao

destes ocasiona perca de transparncia e reduo da possibilidade de inspecionar e adaptar.
(SCHWABER; SUTHERLAND, 2013)

2.1.2.1 Sprint

Visto como um dos itens mais importantes do Scrum, o Sprint possui uma durao
de uma a quatro semanas, visando gerar uma verso incremental utilizvel do produto. Ao
termino de uma Sprint se inicia uma nova, isso acontece at a finalizao do software.
(SCHWABER; SUTHERLAND, 2013)
Aps a Sprint ser iniciada devemos nos atentar para alguns detalhes, como:

No devem ser feitas alteraes que possam colocar em risco os objetivos da mesma;

As metas de qualidade permanecem inalteradas; e,

O escopo pode ser renegociado entre o Produtc Owner e o Team.

Uma Sprint tem como principal finalidade a execuo das features priorizadas
pelo Produtc Owner e revisadas pelo Team. Essas features so as funes do produto a ser
desenvolvido. O conjunto delas definido como Sprint Backlog que est definido logo
frente no item 2.1.3. (SCHWABER; SUTHERLAND, 2013) A Sprint um plano descrito e
flexvel que dever ser seguido orientando o trabalho em prol do resultado do produto.
(PHAM, A.; PHAM, P., 2012)

2.1.2.2 Sprint Planning

A Sprint Planning a reunio que realiza o planejamento da Sprint. Esse plano

criado juntamente com todo o Team Scrum. uma reunio com no mximo oito horas de
durao quando a Sprint tem um tempo estipulado de um ms. Este tempo pode ser reduzido
proporcionalmente durao da Sprint. (SCHWABER; SUTHERLAND, 2013)
Essa reunio tem como prioridade definir o que pode ser entregue do incremento
at o final da Sprint e como o trabalho ser realizado. O Product Backlog, descrito mais a
frente, onde so armazenadas todas as features do produto. O Product Owner avalia quais
atividades so mais importantes e o Team fica responsvel para avaliar se essas podem ou no

SERVIO PBLICO FEDERAL - MINISTRIO DA EDUCAO

INSTITUTO FEDERAL DE EDUCAO, CINCIA E TECNOLOGIA TRINGULO
MINEIRO
GESTO COMERCIAL SISTEMAS DE INFORMAO APLICADOS AO COMRCIO
PROF. ESP. DNIS HENRIQUE DE DEUS LIMA

ser implementadas durante a Sprint que ser iniciada. O Scrum Master possui um papel
importante em todas as reunies, sendo ele o responsvel pelo andamento e a garantia que a
mesma seja realizada na durao prevista e garantindo o foco no assunto proposto. (PHAM,
A.; PHAM, P., 2012)

2.1.2.3 Daily Scrum

A Daily Scrum, conhecida popularmente como reunio diria, possui uma durao
de quinze minutos, devendo ser repedida todos os dias de preferncia no mesmo horrio e
local. A mesma tem como finalidade inspecionar o que foi feito desde a ltima reunio e
definir o que pretende ser feito para a prxima. (SCHWABER; SUTHERLAND, 2013)
Durante essa reunio, o Team responde trs perguntas, sendo elas:

O que foi feito desde a ltima reunio;

O que ser feito para a prxima reunio; e,

Se houve algum obstculo ou empecilho que atrapalhou ou que ainda est presente
dificultando a finalizao do que foi proposto e qual .

O Team utiliza essa reunio para verificar se o processo em direo ao objetivo da

Sprint est ocorrendo dentro do planejado, a fim de chegar ao final da mesma com todos os
itens priorizados pelo PO concludos e entregues.
O Scrum Master ensina o Team a realizar a reunio dentro da durao proposta.
Porm, essa reunio de responsabilidade do time, sendo assegurado que somente membros
dele, como o Product Owner, o Scrum Master e a equipe de desenvolvimento, devem
participar dessa reunio. (SCHWABER; SUTHERLAND, 2013)

2.1.2.4 Sprint Review

A Sprint Review uma reunio realizada ao final de cada Sprint. Sua finalidade
avaliar o incremento e ajustar o Backlog, se necessrio. uma reunio informal, com
finalidade de prover motivao, obter opinies e promover a colaborao. Tambm se trata de
uma reunio com tempo definido, sendo ele de quatro horas para uma Sprint de um ms,

SERVIO PBLICO FEDERAL - MINISTRIO DA EDUCAO

INSTITUTO FEDERAL DE EDUCAO, CINCIA E TECNOLOGIA TRINGULO
MINEIRO
GESTO COMERCIAL SISTEMAS DE INFORMAO APLICADOS AO COMRCIO
PROF. ESP. DNIS HENRIQUE DE DEUS LIMA

podendo ser reduzida proporcionalmente de acordo com o tamanho da Sprint. (SCHWABER;

SUTHERLAND, 2013)
Itens importantes referentes a esta cerimnia:

Participa todo o Team Scrum e mais os interessados no projeto, convidados pelo

Product Owner;

O Product Owner define os itens prontos e os no prontos;

O Team avalia o que foi bem, os problemas e como foram resolvidos ao longo da
Sprint; e,

Essa reunio funciona como entrada para a prxima Sprint Planning.

O resultado dessa reunio se resume previamente em um Sprint Backlog revisado

e inicialmente pr-definido para a prxima Sprint. (PHAM, A.; PHAM, P., 2012)

2.1.2.5 Sprint Retrospective

A Sprint Retrospective a chance do time se avaliar, identificar itens a serem

melhorados e traar metas para a prxima Sprint. Essa reunio deve ocorrer logo aps a Sprint
Review e antes da Sprint Planning, com durao fixa de trs horas para Sprints de um ms,
tambm podendo ser reduzida proporcionalmente ao nmero de semanas definido para a
Sprint. (SCHWABER; SUTHERLAND, 2013)
uma reunio com foco nas pessoas, com finalidade de verificar processos,
ferramentas e os relacionamentos, relacionar os itens que se destacaram e apontar as
melhorias a fim de melhorar o trabalho de todo o time Scrum. (KNINBERG, 2007)
O Scrum Master encoraja o time a sempre buscar melhorias nos seus processos
internos, em busca de aes que tragam um maior efeito, visando o aumento da qualidade do
produto e melhorando a definio de pronto. (PHAM, A.; PHAM, P., 2012)

2.1.3 Artefatos

O Scrum tambm utiliza artefatos para auxiliar no processo. Esses artefatos so

projetados para aumentar a transparncia e garantir que todos tenham o mesmo entendimento

SERVIO PBLICO FEDERAL - MINISTRIO DA EDUCAO

INSTITUTO FEDERAL DE EDUCAO, CINCIA E TECNOLOGIA TRINGULO
MINEIRO
GESTO COMERCIAL SISTEMAS DE INFORMAO APLICADOS AO COMRCIO
PROF. ESP. DNIS HENRIQUE DE DEUS LIMA

dos itens. Esses artefatos so o Product Backlog, o Sprint Backlog e o grfico BurnDown.
(SCHWABER; SUTHERLAND, 2013)

2.1.3.1 Product Backlog

O Product Backlog uma lista nica onde consta tudo que ser necessrio para o
produto e onde esto armazenados todos os requisitos para uma eventual mudana feita no
artefato final. O Product Backlog nunca est completo, os primeiros itens a serem
desenvolvidos representam os requisitos j conhecidos e melhor entendidos. (KNINBERG,
2007)
O Backlog do produto contm tudo que deve ser feito para verses futuras do
mesmo, desde requisitos, novas funes, melhorias e at correes. Os itens do Backlog
possuem os seguintes atributos: descrio, ordem, estimativa e valor. Este artefato tambm
pode ser refinado, ou seja, podem ocorrer adio de detalhes, estimativas e alterao na ordem
dos itens. Essa anlise deve ser expandida a todos os itens do Product Backlog.
A priorizao desses itens de responsabilidade do Product Owner, j o time fica
responsvel por todas as estimativas. No entanto, o Product Owner deve auxiliar o time
ajudando no entendimento e em decises que podem gerar conflitos, porm isso no muda a
responsabilidade do time quanto a real estimativa dos itens. (SCHWABER; SUTHERLAND,
2013)

2.1.3.2 Sprint Backlog

O Sprint Backlog so os itens que foram selecionados do Product Backlog para

serem entregues durante determinada Sprint. O Backlog da Sprint uma previso do time de
desenvolvimento, o mesmo acredita que todos os itens priorizados estaro prontos ao final da
mesma, estando presente por completo no incremento.
Sempre que um novo trabalho necessrio, o time adiciona este ao Sprint
Backlog, e se o trabalho realizado ou completado, a estimativa restante utilizada. Quando
algum item considerado desnecessrio, este removido. Somente o time Scrum pode alterar
o Sprint Backlog durante a Sprint. O Backlog da Sprint pertence exclusivamente ao time, se
tratando de uma viso em tempo real do trabalho a ser feito. (SCHWABER; SUTHERLAND,
2013)

SERVIO PBLICO FEDERAL - MINISTRIO DA EDUCAO

INSTITUTO FEDERAL DE EDUCAO, CINCIA E TECNOLOGIA TRINGULO
MINEIRO
GESTO COMERCIAL SISTEMAS DE INFORMAO APLICADOS AO COMRCIO
PROF. ESP. DNIS HENRIQUE DE DEUS LIMA

Caso o time encontre alguns problemas ou empecilhos que impeam a entrega do

incremento, os itens restantes do Sprint Backlog devem ser negociados com o Product Owner
a fim de garantir que o ao final da Sprint os itens previstos considerados prontos sejam
entregues. (PHAM, A.; PHAM, P., 2012)

2.1.3.3 Grfico BurnDown

O grfico BurnDown considerado muito importante no processo de

monitoramento do times geis. O eixo Y pode ser expresso em horas, dias ou semanas, sendo
o eixo X apresentado em horas de trabalho ou em pontos. A escolha das unidades de medida
devem-se adequar s necessidades das empresas, projetos ou aos objetivos a serem
alcanados. (HAZRATI, 2010)
As empresas utilizam este grfico para auxiliar no gerenciamento da Sprint, sendo
possvel visualizar em tempo real se o que foi proposto realmente vai ser entregue. Este
grfico tambm serve como base para a reunio de retrospectiva, mostrando como o time
evoluiu ao longo da Sprint. (KNINBERG, 2007)
Como pode ser visto na Figura 2, temos a linha ideal (Ideal Line) que apresenta
como o grfico teoricamente deveria seguir. Trabalhar em cima dessa linha praticamente
impossvel, sendo que estamos falando sobre pessoas e processos. O ideal que se ande o
mais prximo a essa, representada pela linha 3 (Line 3).
Em casos como o apresentado pela linha 1 (Line 1), indica que o time est fora do
prazo e no conseguir entregar tudo que foi proposto durante a Sprint. Com base nesses
dados deve-se avaliar o que aconteceu. Se possvel, renegociar os itens do Sprint Backlog ou
at mesmo abortar a Sprint.
Outro caso comumente encontrado representado pela linha 2 (Line 2), onde o
time nos primeiros dias encontram dificuldade em entender, integrar e entregar as tarefas.
Porm nos ltimos dias o time consegue efetuar as entregas com mais frequncia, assim
finalizando o incremento. (HAZRATI, 2010)

SERVIO PBLICO FEDERAL - MINISTRIO DA EDUCAO

INSTITUTO FEDERAL DE EDUCAO, CINCIA E TECNOLOGIA TRINGULO
MINEIRO
GESTO COMERCIAL SISTEMAS DE INFORMAO APLICADOS AO COMRCIO
PROF. ESP. DNIS HENRIQUE DE DEUS LIMA

Figura 2 GrficoBurnDown

FONTE: http://www.infoq.com

O grfico deve ser encarado como um avaliador do time gil, sendo possvel
extrair do mesmo uma gama de informaes bem abrangentes, dentre elas, a velocidade do
time, se o planejamento foi seguido e se efetivo e identificar se o objetivo da Sprint vai ser
alcanado. (FERNANDES, 2011)