SISTEMA DE ENSINO A DISTNCIA

PROGRAMADOR WEB

SCRUM:
METODOLOGIA DE DESENVOLVIMENTO GIL

Matheus Costa Barbosa.

Bacharelado em Cincia da Computao UFPI.

Palmas-TO
2016

SUMRIO
1 INTRODUO...........................................................................................................3
2 DESENVOLVIMENTO...............................................................................................5
3 CONCLUSO..........................................................................................................11
REFERNCIAS...........................................................................................................12

1 INTRODUO
O Scrum um framework (caixa de ferramentas) de desenvolvimento iterativo e
incremental utilizado no gerenciamento de projetos e desenvolvimento de software
gil.
Scrum possui seu foco no gerenciamento e projeto da organizao onde difcil
planejar frente. Mecanismos do Controle de Processo Emprico, onde ciclos de
feedback constituem o ncleo da tcnica de gerenciamento que so usadas em
oposio ao tradicional gerenciamento de comando e controle. uma forma de
planejar e gerenciar projetos trazendo a autoridade da tomada de deciso a nveis
de propriedade de operao e certeza.
Apesar da palavra no ser um acrnimo, algumas empresas que implementam o
processo a soletram com letras maisculas como SCRUM. Isto pode ser devido aos
primeiros artigos de Ken Schwaber, que capitalizava SCRUM no ttulo.
Scrum no um processo prescribente, ou seja, ele no descreve o que fazer em
cada situao. Ele usado para trabalhos complexos nos quais impossvel
predizer tudo o que ir ocorrer.
Alm disso, o Scrum um conjunto de valores, princpios e prticas que fornecem a
base para que a sua organizao adicione suas prticas particulares de engenharia
e gesto e que sejam relevantes para a realidade da sua empresa. O resultado ser
uma verso de Scrum que exclusivamente sua.
Apesar de Scrum ter sido destinado para gerenciamento de projetos de software, ele
pode ser utilizado em equipes de manuteno de software ou como uma abordagem
geral de gerenciamento de projetos/programas.
Inicialmente, o Scrum foi concebido como um estilo de gerenciamento de projetos
em empresas de fabricao de automveis e produtos de consumo, por Takeuchi e
Nonaka no artigo "The New Product Development Game" (Harvard Business
Review, Janeiro-Fevereiro 1986). Eles notaram que projetos usando equipes
pequenas e multidisciplinares (cross-functional) produziram os melhores resultados,
e associaram estas equipes altamente eficazes formao Scrum do Rugby
(utilizada para reincio do jogo em certos casos). Jeff Sutherland[4] , John
Scumniotales e Jeff McKenna conceberam, documentaram e implementaram o
Scrum, conforme descrito abaixo, na empresa Easel Corporation em 1993,
incorporando os estilos de gerenciamento observados por Takeuchi e Nonaka. Em
1995, Ken Schwaber formalizou a definio de Scrum e ajudou a implant-lo no
desenvolvimento de softwares em todo o mundo.
Scrum junta conceitos de Lean, desenvolvimento iterativo e do estudo de Hirotaka
Takeuchi e Ikujiro Nonaka.
A funo primria do Scrum ser utilizado para o gerenciamento de projetos de
desenvolvimento de software. Ele tem sido usado com sucesso para isso, assim
como Extreme Programming e outras metodologias de desenvolvimento. Porm,
teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoas
necessitem trabalhar juntas para atingir um objetivo comum, como iniciar uma escola

pequena, projetos de pesquisa cientfica, ou at mesmo o planejamento de um

casamento.
Mesmo que idealizado para ser utilizado em gesto de projetos de desenvolvimento
de software ele tambm pode ser usado para a gerncia de equipes de manuteno,
ou como uma abordagem para gesto de programas: Scrum de ScrumsS.

2 DESENVOLVIMENTO
Scrum no s reforou o interesse em gerenciamento de projetos de
software, mas tambm desafiou as ideias convencionais sobre essa gesto. Scrum
voltado para instituies de gerenciamento de projetos, onde difcil planejar o
futuro com mecanismos de controle de processos empricos, como loops de
feedback, onde constituem o elemento central do desenvolvimento do produto em
comparao com a gesto de comando e controle tradicionais orientado. Ela
representa uma abordagem radicalmente nova para o planejamento e
gerenciamento de projetos de software, trazendo poder de deciso ao nvel das
propriedades operao e certezas. Scrum reduz defeitos e torna o processo de
desenvolvimento mais eficiente, bem como reduzindo os custos de manuteno a
longo prazo.
O Scrum tem como caractersticas:
Clientes se tornam parte da equipe de desenvolvimento (os clientes devem
estar genuinamente interessados na sada);
Entregas frequentes e intermedirias de funcionalidades 100% desenvolvidas;
Planos frequentes de mitigao de riscos desenvolvidos pela equipe;
Discusses dirias de status com a equipe;
A discusso diria na qual cada membro da equipe responde s seguintes
perguntas:
O que fiz desde ontem em direo a meta?
O que estou planejando fazer at amanh em direo?
Existe algo me impedindo de atingir meta?
Transparncia no planejamento e desenvolvimento;
Reunies frequentes com os stakeholders (todos os envolvidos no processo)
para monitorar o progresso;
Problemas no so ignorados e ningum penalizado por reconhecer ou
descrever qualquer problema no visto;
Locais e horas de trabalho devem ser energizadas, no sentido de que
"trabalhar horas extras" no necessariamente significa "produzir mais".
2.1 Sprint (corrida, tiro)
Um sprint a unidade bsica de desenvolvimento em Scrum. Sprints tendem
a durar entre uma semana e um ms, e so um esforo dentro de uma faixa de
tempo (ou seja, restrito a uma durao especfica) de comprimento constante.
Cada sprint precedido por uma reunio de planejamento (Sprint Planning),
onde as tarefas para o sprint so identificadas e um compromisso estimado para o
objetivo do sprint definido e seguido por uma reunio de reviso ou de
retrospectiva, onde o progresso revisto e lies para os prximos sprints so
identificadas.
Durante cada sprint, a equipe cria um incremento de produto potencialmente
entregvel (por exemplo, software funcional e testado). O conjunto de
funcionalidades que entram em um sprint vm do Product Backlog, que um

conjunto de prioridades de requisitos de alto nvel definidos pelo Product Owner.

Quais itens do backlog que entram para o sprint so determinados durante a
reunio de planejamento do sprint (Sprint Planning). Durante esta reunio, o
Product Owner informa a equipe dos itens no backlog do produto que ele ou ela
quer concludos.
A equipe ento determina quantos eles podem se comprometer a concluir
durante o prximo sprint, e registram isso no backlog do sprint. Durante um sprint,
ningum est autorizado a alterar o backlog do sprint, o que significa que os
requisitos so congelados para esse sprint.
O desenvolvimento de cada sprint deve terminar na "caixa de tempo" prevista.
Se os requisitos no so completados por qualquer motivo, eles so deixados de
fora e voltam para o backlog do produto. Depois que um sprint completado, a
equipe demonstra como usar o software.
O Scrum permite a criao de equipes auto-organizadas, encorajando a colocalizao de todos os membros da equipe e a comunicao verbal entre todos os
membros e disciplinas da equipe no projeto.
Um princpio chave do Scrum o reconhecimento de que, durante um projeto,
os clientes podem mudar de idia sobre o que eles querem e precisam (muitas
vezes chamados requisitos churn), e que os desafios imprevisveis no podem ser
facilmente tratados de uma maneira preditiva ou planejada tradicional. Como tal, o
Scrum adota uma abordagem emprica, aceitando que o problema no pode ser
totalmente entendido ou definido, focando na maximizao da habilidade da equipe
para entregar rapidamente e responder s necessidades emergentes.
Como outras metodologias de desenvolvimento gil, o Scrum pode ser
implementado atravs de uma ampla gama de ferramentas. Muitas empresas
utilizam ferramentas de software universais, como planilhas para construir e manter
artefatos como o backlog do sprint. H tambm pacotes de software open-source e
proprietrios dedicados gesto de produtos no mbito do processo Scrum. Outras
organizaes implementam o Scrum sem o uso de quaisquer ferramentas de
software, e mantm seus artefatos na forma de cpias impressas, como papel,
quadros e notas.
Cada sprint uma iterao que segue um ciclo (PDCA) e entrega incremento
de software pronto.
Um backlog conjunto de requisitos, priorizado pelo Product Owner
(responsvel pelo ROI e por conhecer as necessidades do cliente);
H entrega de conjunto fixo de itens do backlog em srie de interaes curtas
ou sprints;
Breve reunio diria, ou daily scrum, em que cada participante fala sobre o
progresso conseguido, o trabalho a ser realizado e/ou o que o impede de
seguir avanando (tambm chamado de Standup Meeting ou Daily Meeting, j
que os membros da equipe geralmente ficam em p para no prolongar a
reunio).
Breve sesso de planejamento, na qual os itens do backlog para uma sprint

(iterao) so definidos;
Retrospectiva, na qual todos os membros da equipe refletem sobre a sprint
passada.
O Scrum facilitado por um Scrum Master, que tem como funo primria
remover qualquer impedimento habilidade de uma equipe de entregar o objetivo do
sprint. O Scrum Master no o lder da equipe (j que as equipes so autoorganizadas), mas atua como um mediador entre a equipe e qualquer influncia
desestabilizadora. Outra funo extremamente importante de um Scrum Master o
de assegurar que a equipe esteja utilizando corretamente as prticas de Scrum,
motivando-os e mantendo o foco na meta da Sprint.
2.2 Papis
Scrum um esqueleto de processos que contm grupos de prticas e papis
pr-definidos. Os principais papis so:
1. o ScrumMaster, que mantm os processos (normalmente no lugar de um
gerente de projeto);
2. o Proprietrio do Produto, ou Product Owner, que representa os
stakeholders e o negcio;
3. a Equipe, ou Team, um grupo multifuncional com cerca de 7 pessoas e que
fazem a anlise, projeto, implementao, teste etc.
Equipes Scrum consistem de trs papis principais e uma srie de papis
auxiliares - papis principais so frequentemente referidos como porcos e papis
auxiliares como galinhas (aps a histria A Galinha e o Porco).
2.1.1
2.1.2 2.2.1 Papis principais
Os papis principais em equipes Scrum so aqueles comprometidos com o
projeto no processo do Scrum - so os que produzem o produto (objetivo do projeto).
Product Owner (dono do produto)
O Product Owner representa a voz do cliente e responsvel por
garantir que a equipe agregue valor ao negcio. O Product Owner
escreve centrado nos itens do cliente (histrias tipicamente do usurio),
os prioriza e os adiciona para o product backlog. Equipes de Scrum
devem ter um Product Owner, e, embora esse possa tambm ser um
membro da equipe de desenvolvimento, recomenda-se que este papel
no seja combinado com o de ScrumMaster.
Equipe (Development Team)
A equipe responsvel pela entrega do produto. A equipe tipicamente
composta de 5-9 pessoas com habilidades multifuncionais que fazem o
trabalho real (analisar, projetar, desenvolver, testar tcnicas de
comunicao, documentos, etc.) Recomenda-se que a equipe seja autoorganizada e auto-conduzida, mas que muitas vezes trabalhem com
alguma forma de projeto ou gesto de equipe.
Scrum Master
Scrum facilitado por um Scrum Master, que responsvel pela
remoo de impedimentos capacidade da equipe para entregar o

objetivo do sprint / entregas. O Scrum Master no o lder da equipe,

mas age como um tampo entre a equipe e qualquer influncia ou
distrao. O Scrum Master garante que o processo Scrum seja usado
como pretendido. O Scrum Master o responsvel pela aplicao das
regras. Uma parte fundamental do papel do Scrum Master proteger a
equipe e mant-la focada nas tarefas em mos. O papel tambm tem
sido referido como um lder-servo para reforar essa dupla perspectiva.
2.1.3
2.1.4 2.2.2 Papis auxiliares
Os papis auxiliares em equipes Scrum so aqueles com nenhum papel
formal e envolvimento frequente no processo de Scrum, mas, ainda assim, devem
ser levados em conta.
Partes interessadas (clientes, fornecedores)
Estas so as pessoas que permitem o projeto e para quem o projeto vai
produzir o acordado benefcio, que justifica a sua produo. Eles s esto
diretamente envolvidos no processo durante as revises sprint.
Gerentes (incluindo gerentes de projeto)
Pessoas que iro configurar o ambiente para desenvolvimento de produtos.
2.3 Artefatos
2.1.5 2.3.1 Backlog
Um backlog uma lista de itens priorizados a serem desenvolvidos para um
software. Este artefato a principal fonte de informao para o Planejamento de
sprint (Sprint Planning). No decorrer do sprint, o Product Owner, o Scrum Master e a
Equipe decidem no que a equipe ir trabalhar. O Product Owner mantm uma lista
priorizada de itens de backlog, o backlog do produto, o que pode ser repriorizado
durante o planejamento do sprint. A Equipe seleciona itens do topo do backlog do
produto. Eles selecionam somente o quanto de trabalho eles podem executar para
terminar. A Equipe ento planeja a arquitetura e o design de como o backlog do
produto pode ser implementado. Os itens do backlog do produto so ento
destrinchados em tarefas que se tornam o backlog do sprint.
2.1.5.1 2.3.2 Product Backlog
O Product Backlog mantido pelo Product Owner e uma lista de requisitos
que tipicamente vm do cliente. O Product Backlog pode ser alterado a qualquer
momento pelo Product Owner ou por deciso deste.
2.1.5.2
2.1.5.3 2.3.3 Sprint Backlog
O Sprint Backlog uma lista de itens selecionados do Product backlog e
contm tarefas concretas que sero realizadas durante o prximo sprint para
implementar tais itens selecionados. O Sprint Backlog uma representao em
tempo real do trabalho que o Development Team planeja concluir na sprint corrente,
e ele pertence unicamente ao Development Team.

2.1.6
2.1.7 2.3.4 Burndown Chart
O Burndown um simples grfico, com dois eixos X e Y, baseado nas
atividades que no ultrapassem um dia de trabalho. O eixo Y indica o nmero de
tarefas existentes no Sprint e o eixo X os dias que representam o tamanho do Sprint.
2.4 Reunies Scrum
Um momento bom para as discusses dirias depois do almoo. Durante a
manh pode ser complicado. Estas discusses de status no demoram e uma
forma eficiente de fazer estas reunies seria ficar em p e em frente a um quadro
negro. Como as pessoas tendem a ficar cansadas depois do almoo, ter uma viva
reunio em p nessa hora permite que a equipe mantenha a sua energia alta. Como
todos estiveram trabalhando durante a manh, suas mentes esto focadas no
trabalho e no em questes pessoais. Grandes usurios do processo so enfticos
na necessidade de os membros da equipe estarem em p durante a reunio, para
permitir maior agilidade e evitar perdas no foco. Recomenda-se inclusive evitar
lugares onde as pessoas possam se apoiar.
2.4.1 Daily Scrum Meeting
Cada dia durante o sprint, uma reunio de status do projeto ocorre. Isso
chamado de "scrum dirio", ou "de p o dia". Esta reunio tem diretrizes especficas:
A reunio comea precisamente no horrio marcado.
Todos so bem-vindos, mas apenas "poucos" podem falar.
O encontro tem durao determinada (Time-Box) e dura no mximo 15
minutos.
A reunio deve acontecer no mesmo local e mesma hora todos os dias
Durante a reunio, cada membro da equipe responde a trs perguntas:
O que voc tem feito desde ontem em direo a meta?
O que voc est planejando fazer hoje em direo a meta?
Voc tem algum problema impedindo voc de realizar seu objetivo em
direo a meta?
papel do Scrum Master para facilitar a resoluo desses impedimentos.
Normalmente, isso deve ocorrer fora do contexto do Daily Scrum para que a
reunio possa durar menos de 15 minutos.
2.4.2 Reunio de Planejamento da Sprint (Sprint Planning Meeting)
No incio do ciclo de sprint (a cada 7-30 dias), um Sprint Planning Meeting
realizado.
Selecione o trabalho que est a ser feito.
Prepare o Sprint Backlog que detalha o tempo que levar para fazer
esse trabalho, com toda a equipe.
Identificar e comunicar o quanto o trabalho susceptvel de ser feito
durante o sprint atual.
Dividida em duas partes:
Parte 1 (Primeiras quatro horas): Team Product Owner: dilogo
para priorizar o Product Backlog.

 Parte 2 (Prximas quatro horas): Team apenas: hash de um plano

para a Sprint, resultando na Sprint Backlog.
No final de um ciclo de sprint, so realizadas duas reunies: a "Sprint
Review" e do "Sprint Retrospective".
2.4.3 Reunio de Reviso da Sprint (Sprint Review)
Rever o trabalho que foi concludo e no concludo.
Apresentar o trabalho realizado para os stakeholders (ou "a demo"). Um
trabalho incompleto no pode ser demonstrado.
2.4.4 Retrospectiva da Sprint (Sprint Retrospective)
Todos os membros da equipe refletem sobre a sprint passada.
Faa melhorias contnuas de processos.
Duas questes principais so feitas na retrospectiva do sprint: O que correu
bem durante a corrida? O que poderia ser melhorado na prxima sprint?

3 CONCLUSO
O Scrum um framework estrutural para gesto de projetos baseado no
empirismo, que afirma que o conhecimento vem de experincias anteriores e de
decises tomadas. Isso significa que um framework iterativo e incremental, pois
usa experincias anteriores para aperfeioar controle de riscos e decises futuras.
Alm disso, possui uma ideia de que o desenvolvimento do produto algo que tem
um grande grau de incerteza, por isso deve ser construdo de forma emprica.
O produto de software deve estar suficientemente bem direcionado e definido
no incio do planejamento e na elicitao de requisitos, embora a documentao
excessiva seja dispensvel. A ideia justamente partir para a etapa "mais
importante" do projeto, evitando grande detalhamento no incio do mesmo e codificar
o mais rpido possvel.
nessa etapa que o cliente deve estar presente, dando feedback constante a
cada ciclo ou at mesmo definindo novos requisitos. Para isso o time de
desenvolvimento deve estar apto a adequar o produto s novas mudanas.

REFERNCIAS
COHEN, D., LINDVALL, M., & COSTA, P. An introduction to agile methods. In
Advances in Computers(pp. 1-66). New York: Elsevier Science, 2004.
PRESSMAN,R. Software Engineering (A practitioner's approach). 5th edition,
2000.Mc Graw - Hill Education.
AMBLER , S. (April 2008). Scaling Scrum - Meeting Real World Development Needs.
Acessado
em:
07
de
Abril
de
2009.
Disponvel
em:
http://www.ddj.com/architect/207100381.
Agile Manifesto: Acesso
http://agilemanifesto.org/

em:

07

de

Abril

de

2009.

Disponvel

em:

Agile Manifesto History: Acesso em: 07 de Abril de 2009. Disponvel em:

http://agilemanifesto.org/history.
SCHWABER, K. SCRUM Development Process. In Advanced Development
Methods.