Breve descrição do método SCRUM de gerenciamento de

projetos
Alexandre Almeida da Silva¹, Camila Soares¹,Cláudio Moura Teixeira¹, Danilo
Gomes Moreira¹, João Sérgio da Silva Costa¹, Marcus Vinícius Souza Costa¹,
Ronaldo Louro Meneguite¹
1Faculdades Integradas Doctum de Cataguases Avenida Cel Antônio

Augusto de Souza, 442 Vila Tereza Cataguases-MG

doctumale@hotmail.com, millalsr@yahoo.com.br, cmt1771@hotmail.com,
dan_moreira50@yahoo.com.br, j_silvacosta@yahoo.com.br,
marquimsc@yahoo.com.br, ronaldolouro@yahoo.com.br

Abstract. This paper is a quick description of Scrum project management

method. Created by auto industry, Scrum gets its name from rugby’s
Scrum(play where eight players of each team fight for ball possession) and
may be used to manage many kinds of project. In software engineering, it’s
considered one of the most important agile methods, beside eXtreme
Programming(XP).

Resumo. Este artigo é uma breve descrição da metodologia Scrum de

gerenciamento de projeto. Originalmente criado pela indústria
automobilística, o Scrum teve seu nome baseado no SCRUM do Rugby (lance
no qual oito jogadores de cada time lutam pela posse da bola) e pode ser
utilizado para gerir projetos em várias áreas. Na área de software é
classificado como um dos principais métodos ágeis ao lado eXtreme
Programming.

1. Introdução
Scrum é um método ágil para gestão de projeto de software, assim como o eXtreme
Programming e outras metodologias ágeis, compatível com requisitos do CMMI e
ISO9001. Não é apenas um método para desenvolvimento de software, é um método de
gestão de projetos em geral, podendo ser utilizado para este fim. Ele foi concebido
como um estilo de gerenciamento de projetos em empresas de fabricação de automóveis
e produtos de consumo, por Takeuchi e Nonaka no livro "The New New Product
Development Game". Segundo estes autores, projetos com equipes pequenas e
multidisciplinares produzem melhores resultados. Estas equipes são associadas à
formação do Scrum no jogo de Rugby, daí a origem do nome Scrum.

“Scrum é um processo Ágil ou framework para gerenciamento de projetos ágeis.

Ele é enquadrado como um processo para gerenciamento de projetos e certamente não é
uma metodologia, se o fosse, seria muito pesado.” KEN SCHWABER (2004)

Ele é um processo que permite manter o foco na entrega no menor tempo

possível, onde as equipes se auto-organizam para definir as prioridades. Por ser um
processo ágil, ele não abrange todos os procedimentos a serem seguidos no
desenvolvimento do projeto. “O Scrum não é um processo previsível, ele não define o
que fazer em toda circunstância” KEN SCHWABER (2004)

O ciclo do Scrum é baseado numa série de iterações bem definidas, cada uma
com duração de 2 a 4 semanas, chamadas Sprints. Reuniões rápidas são feitas para o
acompanhamento das tarefas, sempre focando a agilidade nos processos.

Figura 1. Logotipo da Scrum Alliance

1.1 - Onde e como é aplicado

O Scrum é usado nas seguintes empresas: Microsoft, Yahoo, Google, Electronic Arts,
High Moon Studios, Lockheed Martin, Philips, Siemens, Nokia, Capital One, BBC,
Intuit, Nielsen Media, First American Real Estate, BMC Software, Ipswitch, John
Deere, Lexis Nexis, Sabre, Salesforce.com, Time Warner, Turner Broadcasting, Oce
entre outras.
Dentre os inúmeros propósitos, o Scrum tem sido usado para softwares
comerciais, desenvolvimento interno, desenvolvimento contratado(terceirização),
aplicações financeiras, aplicações certificadas pela ISO 9001, hackers solitários, vídeo
games, websites, telefones celulares, sistemas de controle de satélites, sistemas para
suporte à vida, dentre outras.
Para se obter algumas certicações scrum, temos várias opções, dentre elas a
Certified Scrum Master, Certified Scrum Product Ower, Certified Scrum Practioner,
Certified Scrum Trainer, Certified Scrum Coach, onde os valores estão em média 900
euros.
 Figura 2. Certificado de Scrum Master

1.2 - Características
A principal característica do Scrum é a sua agilidade na gerencia e no controle de
desenvolvimento de projetos, conseguida através da maximização da comunicação e a
cooperação da equipe de forma ágil e empírica. Ao se tratar os desafios de um projeto
de forma empírica e ágil, onde a habilidade da equipe de responder de forma ágil aos
desafios emergentes é o que mais conta, torna o Scrum mais flexível para atuar em
projetos mais complexos, o que já não acontece quando se usa processos definidos. O
Scrum é escalável tanto para projetos de alta complexidade como também para projetos
menores.
Na utilização do Scrum os requisitos do projeto são listados em um Backlog de
produto provindo das necessidades ou requisitos do cliente e transferidos para o backlog
de sprints onde são feitas as prioridades dos sprints e a ordem. Sprints são as partes ou o
projeto a ser desenvolvido pela equipe em um curto prazo de tempo, de no máximo 30
dias. São feitas reuniões diárias, de no máximo 15 minutos, para o Scrum Master e os
integrantes da equipe, onde geralmente eles ficam de pé. Essas reuniões têm como
objetivo aumentar a comunicação da equipe onde se vê o andamento de cada sprint, as
dificuldades encontradas e possíveis problemas que impedem a conclusão dos mesmos.
Ao se concluir um sprint a equipe reflete sobre como é possível melhorar o processo
para atingir um grau eficiência maior. Na equipe temos o integrante que atua como
Scrum Master, sua função não é a de executar o sprint, mas de atuar na forma a resolver
qualquer problema que impeça a equipe de progredir ou concluir o sprint e acima de
tudo assegurar que a equipe esteja utilizando as técnicas de Scrum para realizar o
projeto, como também, motivar a equipe para o uso das mesmas. O Scrum master não
pode ser visto como um líder já que as equipes são auto- organizadas, ele atua mais
como um firewall.
 Como já foi dito, o porquê de se usar o Scrum para o desenvolvimento de
projetos de software é sua flexibilidade e o seu poder de adaptação, conseguida através
do uso de métodos empíricos para a gestão dos processos, como também, para
problemas emergentes. Além da maior transparência de todo o processo obtida através
do uso de reuniões diárias, o que ajuda não só na obtenção de informação das metas
alcançadas como também na detecção de problemas, erros ou falhas aumentando assim
a comunicação e a motivação da equipe.

2. Personagens no Scrum
Existem apenas três papéis no Scrum os quais são:
· Dono do Produto (Product Owner)
· Scrum Master
· Time (Desenvolvedores)

2.1 Dono do Produto (Product Owner)

O dono do produto é de preferência uma única pessoa a qual não necessariamente tem
por obrigação ser um funcionário do cliente, apesar de ser muito recomendado, visto
que essa pessoa devera ter um ótimo conhecimento das necessidades da empresa, de
maneira a expressar pontualmente as prioridades dentro do projeto, é ele quem ira
elencar as funcionalidades pretendidas, bem como um grau de importância para essas
funcionalidades dentro do processo. É também atribuído a esse personagem o poder de
aceitar ou rejeitar o resultado do trabalho efetuado em cada Sprint.

2.2 Scrum Master

O Scrum Master é como um coordenador do projeto, e tem como principal objetivo
remover os empecilhos levantados durante as reuniões diárias, e mediar as mesmas
durante a Sprint.
É um papel que muitos autores defendem que seja exclusivo, porém outros mais
flexíveis descrevem que o mesmo pode sim exercer outros papeis no processo, porém
esses papéis devem ser elencados a ele de maneira a fazer com que o mesmo tenha
disponibilidade de voltar as suas atribuições de Scrum Master quando necessário.

2.3 Time (Desenvolvedores)

O time normalmente é formado de 5 a 10 pessoas, e é quem de fato desenvolve as
aplicações, normalmente é uma equipe multifuncional, composta por programadores,
testadores, desenvolvedores de interface, etc. É altamente recomendado que esse time
seja auto-organizável e auto-gerenciável, de maneira a suprir necessidades e resolver
seus problemas internamente sem uma interferência externa. Um erro comum é associar
uma dependência funcional do sistema a uma responsabilidade do Scrum Master o que
não é verdade, o mesmo tem como objetivo apenas remover empecilhos externos não
internos.
3. Práticas adotadas no Scrum
3.1. Product Backlog
A partir de uma reunião inicial com todos os envolvidos e interessados do projeto, são
levantadas todas as implementações a serem desenvolvidas a partir da necessidade do
negócio do cliente, contém uma lista de requisitos a serem desenvolvidos durante o
projeto. É visível a todos, e regularmente atualizado. É apresentado na primeira reunião
de Planejamento do Sprint, uma vez aprovado, temos os itens necessários para compor
o Sprint Backlog.
3.2. Reunião de Planejamento do Sprint
A reunião de planejamento se divide em duas partes:
3.2.1. Primeira Reunião de Planejamento do Sprint
Com duração de no máximo quatro horas, é nessa reunião em que o dono do produto
juntamente com a Equipe discutem os itens do Product Backlog, é neste momento que
selecionam as tarefas as quais possuem maior prioridade para o cliente.
3.2.2. Segunda Reunião de Planejamento do Sprint
Com duração de quatro horas, é a reunião a qual a Equipe define as tarefas necessárias,
estima o esforço das tarefas, e de preferência a própria equipe faz a distribuição das
tarefas entre os membros da mesma, o Dono do Produto deve está presente para
esclarecimento de dúvidas e por fim a Equipe compromete-se em concluir as tarefas.

Figura 3. Reunião de planejamento do sprint

3.3. Sprint Backlog

São as tarefas que foram selecionadas na reunião de planejamento do Sprint pela
Equipe junto com o Dono do Produto e Scrum Master, é o ponto inicial de cada Sprint.
3.4. Sprint

São pequenas séries de interações que podem ter uma duração de duas a quatro
semanas, no final da interação a equipe tem que ter alcançado o objetivo inicial do
Sprint, onde a equipe está focada em não como fazer, mas sim em vamos fazer. A
equipe executa as tarefas compõem o Sprint Backlog. O objetivo final de cada Sprint é
ter um produto incremental e funcional para o cliente. É a fase principal do Scrum, pois
é nesta hora que ocorre a execução das tarefas, depois de todo o planejamento inicial. É
importante que os restantes das Sprint tenham o mesmo tamanho da inicial para que não
causem perda de ritmo da Equipe. É imprescindível que no primeiro Sprint alcance o
sucesso, pois é um período delicado, pois as partes envolvidas e interessadas estão com
expectativa muito grande em cima do resultado (produto incremental).
3.5. Reunião Diária do Sprint
São reuniões as quais ocorrem todos os dias durante a execução do Sprint, com duração
em média de 15 minutos. O grande objetivo dessa reunião é que todos os envolvidos
tenham conhecimento de como está o andamento do projeto e também fazer com que
cada um relate os impedimentos que estão enfrentando ao executarem as suas
respectivas tarefas.
O Scrum Master é o responsável pela condução da reunião, é muito importante
que todos envolvidos no projeto estão participando principalmente a equipe,
basicamente a equipe responde com clareza a três perguntas durante a reunião:
·O que foi concluído desde a última reunião? (Neste momento o Scrum Master
registra as tarefas que foram concluídas e as que ainda estão pendentes).
· Quais impedimentos estão tendo durante a tarefa? (O Scrum Master registra os
impedimentos relados por cada membro da equipe, e após o termino da reunião irá
propor solução para os problemas citados).
Qual será a próxima tarefa a ser executada? (Neste momento todos ficam
sabendo quais tarefas cada membro da equipe está executando).
O Scrum Master tem como objetivo nessa reunião não deixar com que a reunião perca
seu foco, basicamente responder as três perguntas, ter uma visão que a equipe não
perdeu o objetivo final do Sprint, e gerenciar os impedimentos que vão acontecendo
durante a execução da Sprint. O ponto forma desta reunião é responder apenas as
perguntas feitas pelo Scrum Master e ponto.

Figura 4. Reunião diária do sprint

3.6. Produto Incremental
No final de cada Sprint há uma entrega parcial do produto. O principal resultado de um
Sprint é a entrega incremental e funcional de um produto, os impedimentos para entrega
dessa etapa e os novos requisitos adicionado durante o desenvolvimento deste Sprint.
3.7. Reunião de Revisão da Sprint 1
Esta reunião é realizada no último dia do Sprint com duração de 4 horas e deve ser
conduzida sob a responsabilidade do Scrum Master, a Equipe não deve gastar mais de
uma hora na preparação da reunião. Neste momento é apresentado o resultado da Sprint
que é o produto incremental com suas funcionalidades pela Equipe e o Scrum Master
para Dono do Produto e os envolvidos do projeto (cliente). Analisaram junto se foi
alcançado o objetivo inicial do Sprint, e já discutem novas funcionalidades para
atualizar os itens do Product Backlog que vão sendo identificada ao final de cada
Sprint.
3.8. Reunião de Revisão da Sprint 2
É realizada logo após a reunião de revisão do Sprint com duração de no máximo 3
horas com a participação da Equipe, Scrum Master, Product Owner e os envolvidos e
interessados. Os membros da Equipe devem responder a duas perguntas?
· O que aconteceu de bom durante o último Sprint?
· O que pode ser melhorado para o próximo Sprint?
O Scrum Master registra as respostas e prioriza na ordem que deseja discutir as
melhorias e tem como papel também facilitar ao time melhores formas de aplicar as
práticas do Scrum. Por ser uma reunião de lavagem de roupa suja, deve se ter cuidado
para não levar pontos pessoais, pois podem ser fundamentais para prejudicar a aplicação
das práticas do Scrum. Essa reunião é fundamental para o progresso e sucesso do
projeto, é fundamental a clareza e objetividade para que os participantes alcancem o
sucesso da reunião.
 Figura 5. Reunião de revisão do sprint

3.9 Resumo do Funcionamento do Scrum

Figura 6. Representação do ciclo do Scrum

4 – Conclusão
O Scrum é um ferramenta de gerenciamento de projetos totalmente confiável e eficaz,
tendo como peso o número de profissionais que a cada dia mais adotam essa ferramenta
e a relevância das inúmeras multinacionais que aderiram ao mesmo.
Outro fator importante é a união entre os times de programação que o Scrum propicia,
onde há compromisso com a alta administração para o efetivo funcionamento do
Scrum, que acompanhe debates e debates entre as equipes. O Scrum combate a “corrida
de revezamento” dos programadores, que acaba atrapalhando no desenvolvimento do
produto, causando assim softwares de baixa qualidade, por um estilo holístico, onde as
equipes priorizam as maiores necessidades.
Sem dúvida o Scrum é excelente, tanto que não se limita somente à produção de
software.

5-Referências
CAVALCANTI, Eric. Scrum: uma abordagem prática. Jun, 2008. Fortaleza-CE.
Palestra disponível em <http://tinyurl.com/3p4aqd> . Acesso em 15 set. 2008

KEN ,S. Agile Project Management with Scrum. Microsoft Press, Redmond, WA, 2004
Scrum Alliance. Site oficial . Disponível em < http://www.scrumalliance.org/ >. Acesso
em 18 set.2008

TAKEUCHI, H. & NONAKA, I. The New New Product Development Game. Harvard
Business Review, 1986