Nome da Revista ESTUDO DE CASO DE APLICAÇÃO DE SCRUM

Vol. 1, Nº. 1, Ano 2011 PARA UMA EMPRESA DE SOFTWARE

RESUMO
José Luiz Bergamo
afiliação autor 1 O gerenciamento de projetos de software sempre foi um desafio para os
gerentes de projetos , pelo fato de que o desenvolvimento do projeto poderá
bergamo@agenciaja.com
ter grande chance de não atingir o prazo estipulado e o resultado esperado
não seja atendido. Além disso, os aspectos técnicos e humanos envolvidos no
projeto, como por exemplo: tamanho funcional, complexidade, linguagem
de implementação, arquitetura, relacionamento com usuários e o modelo de
gestão podem sofrer alterações no decorrer do caminhar do projeto. As
metodologias de desenvolvimento ágil de projetos (AGILE) propõem
técnicas para maximização de resultados e a redução do tempo gasto com a
estimativa, visando obter um prazo mais realista para entrega do projeto.
Este estudo teve como principal objetivo pesquisar, entender e aplicar
técnicas de metodologias ágeis em uma empresa de desenvolvimento de
software, mais precisamente o SCRUM, tentando obter melhor qualidade
nos trabalhos e minimizar e/ou afastar as chances de não se atingir o tempo
estimado para o desenvolvimento de projetos.

Palavras-Chave: Gestão de Projetos, SCRUM, Software, Agile,

Desenvolvimento Agil

ABSTRACT

Project management software has always been a challenge for project

managers, the fact that the development of the project may have a great
chance of not meeting the deadline and expected outcome is not met. In
addition, technical and human aspects involved in the project, for example,
functional size, complexity, implementation language, architecture,
relationships with users and management model may change during the
project path. The methodologies for agile projects (AGILE) propose
techniques to maximize results and reduce time spent on the estimate, to
obtain a more realistic deadline for delivery of the project. This study aimed
to research, understand and apply Agile techniques in a software
development company, specifically SCRUM, trying to get better quality in
the work and minimize and / or eliminate the chances of not achieving the
estimated time to development projects.

Keywords: Project Management, SCRUM, Software, Agile, Agile

development

Anhanguera Educacional Ltda.

Correspondência/Contato
Alameda Maria Tereza, 2000
Valinhos, São Paulo
CEP 13.278-181
rc.ipade@unianhanguera.edu.br
Coordenação
Instituto de Pesquisas Aplicadas e
Desenvolvimento Educacional - IPADE
<tipo manuscrito>
Recebido em: 30/12/1899
Avaliado em: 30/12/1899
Publicação: 22 de setembro de 2011
1
2 TÍTULO DO TRABALHO TODAS EM MAIÚSCULAS ESTILO <TITULO ARTIGO>

1. INTRODUÇÃO

É comum em desenvolvimento de software ocorrer falhas geradas por falta de

informações de requisitos e apresentação da estimativa de prazo mal calculada, além
disso, muitas vezes não se possuem recursos ou inclinação para elaboração de projetos de
softwares. Por esta razão, muitas organizações, particularmente as pequenas, acabam por
não usar nenhum recurso para gestão de projetos, o que pode levar a efeitos desastrosos
em termos de qualidade de software. Torna-se necessário, então, utilizar metodologias
ágeis, que não são apenas embasadas em documentação nem tampouco se preocupam
apenas com a codificação.

A metodologia ágil SCRUM propõe o uso da organização das tarefas para

realizar o desenvolvimento ágil do projeto de software. A metodologia ágil possibilita não
só a estimativa de prazo, mas também o planejamento da quantidade necessária de
iterações do projeto e também priorização dos requisitos mais importantes para os
usuários. Em um projeto ágil o Product Backlog substitui uma descrição formal de
requisitos ou então um caso de uso. Já a Sprint Planning Meeting é uma reunião realizada
entre os membros da equipe para estimar as Product Backlog do projeto. Neste artigo
serão apresentados os conceitos de Product Backlog e Sprint Planning Meeting bem como
a sua utilização para realização da gestão ágil de projetos de software.

Segundo Mike Cohn “Não existe, e nunca existirá uma lista de

melhores práticas em SCRUM, porque o contexto dos projetos e equipes
descarta todas as outras considerações. Ao invés de melhores práticas, o que
precisamos conhecer são as boas práticas e o contexto onde foram bem
sucedidas” (KNIBERG, 2006).

2. DEFINIÇÃO DO TEMA

Este estudo de caso visa demonstrar processos e ferramentas utilizados em

projetos de desenvolvimento de software. E a partir deste estudo propor soluções para o
auxilio de equipes de desenvolvimento de software que optam por metodologias ágeis.
Esta contribuição sugere o armazenamento e administração dos conhecimentos
adquiridos e aprendidos ao longo do ciclo de vida de desenvolvimento do software,
mantendo uma maior proximidade e comunicação com o cliente.

Nome da Revista • Vol. 1, Nº. 1, Ano 2011 • p. 1-10

 autor 1, autor 2 3

3. OBJETIVO

Como objetivo principal este trabalho visa apresentar o método de

gerenciamento de projeto conhecido como SCRUM a ser implementado na análise, no
desenvolvimento do software e na comunicação com o cliente e aplicar a metodologia
proposta em uma empresa.

4. ESCOPO DO TRABALHO

Apresentar a implantação de processos ágeis na empresa em questão,

diferente de pesquisar e apresentar metodologias tradicionais para desenvolvimento de
software, nem o de determinar qual o melhor modelo para desenvolvimento.

5. JUSTIFICATIVA

A metodologia SCRUM é simples e fácil de ser aplicada. O que a diferencia das

metodologias tradicionais é o enfoque e os valores.

A idéia principal do SCRUM é que o desenvolvimento de

softwares envolve muitas variáveis técnicas e de ambiente, como requisitos,
recursos e tecnologia, que podem mudar durante o processo . Isto torna o
processo de desenvolvimento imprevisível e complexo, requerendo
flexibilidade para acompanhar as mudanças. O resultado do processo deve ser
um software que é realmente útil para o cliente (SCHWABER, 1996).

Com isso, ela se adapta a novos fatores decorrentes do

desenvolvimento do projeto, ao invés de procurar analisar previamente tudo o
que pode acontecer no decorrer do desenvolvimento (COCKBURN, 2001).

Achei sua justificativa com cara de contexto ou introdução.

6. CONTEXTO

6.1. O que é SCRUM

SCRUM é um processo interativo e incremental que visa divisa

dividir um projeto em uma serie de Sprint (requisitos) formando um Product
Backlog (lista de requisitos) (MOUNTAIN GOAT, 2011).

Nome da Revista • Vol. 1, Nº. 1, Ano 2011 • p. 1-10

4 TÍTULO DO TRABALHO TODAS EM MAIÚSCULAS ESTILO <TITULO ARTIGO>

SCRUM depende de uma auto-organização da equipe de desenvolvimento. A

equipe de SCRUM se organizando não necessita de um líder para delegar tarefas ou
explicar como um problema será resolvido. Essas são questões que são decididas pela
equipe como um todo. A equipe é multifuncional para que todos se envolvam na idéia a
ser implementada e executada.

As equipes de desenvolvimento ágil recebem suporte de dois indivíduos

específicos: um ScrumMaster e um Product Owner . O ScrumMaster não chega a ser um
gerente de projetos como nas metodologias tradicionais e sim um mediador da equipe,
ajudando os membros da equipe a usar as melhores técnicas do SCRUM para atingir seu
mais alto objetivo e desempenho. O Product Owner (Proprietário do Produto) representa
a empresa, clientes ou usuários e orienta a equipe sobre quais as prioridades a serem
atendidas na construção do produto.

Projetos SCRUM progridem em uma série de Sprints, que são iterações

realizadas de 2 a 6 semanas. No início de um Sprint, os membros da equipe se
comprometem a entregar certo número de itens que foram listados no Product Backlog .
No final do Sprint, esses recursos feitos são testados e integrados no produto em
desenvolvimento. No final do Sprint uma Sprint Review (revisão do Sprint) é realizada
onde a equipe demonstra a nova funcionalidade para o Product Owner e outras partes
interessadas que fornecem feedback que podem influenciar o próximo Sprint.

6.2. Quais são as principais atividades em SCRUM?

O Sprint em si é a atividade principal de um projeto SCRUM. Uma

pesquisa recente descobriu que o tamanho mais comum do sprint é de duas
semanas. Durante esse tempo, a equipe faz de tudo para tornar um pequeno
conjunto de características do item funcional (MOUNTAIN GOAT, 2011).

A primeira atividade de cada Sprint é uma reunião de planejamento do Sprint.

Durante essa reunião, o Product Owner fala à equipe sobre os itens de maior prioridade
no Product Backlog. Os membros da equipe identificam quantos itens eles podem
comprometer-se e, em seguida, criam um Sprint Backlog, que é uma lista das tarefas a
realizar durante o Sprint.

Em cada dia do Sprint, um Daily Scrum (reunião diária) é realizada com a

participação de todos os membros da equipe, incluindo o ScrumMaster e o Product
Owner. Esta reunião é rápida e não deve durar mais que 15 minutos. Durante esse tempo,
cada membro da equipe compartilha o que trabalhou no dia anterior, o que vai trabalhar

Nome da Revista • Vol. 1, Nº. 1, Ano 2011 • p. 1-10

 autor 1, autor 2 5

hoje, e identifica qualquer problema que o impeça de realizar o progresso. Daily Scrum
serve para sincronizar o trabalho dos membros da equipe e discutir a Sprint.

No final de um Sprint, a equipe realiza uma Sprint Review (revisão de Sprint).

Durante a Sprint Review, a equipe demonstra o resultado obtido durante o Sprint. O
objetivo deste encontro é obter feedback do Product Owner ou qualquer usuários ou
outras partes interessadas que foram convidados para a revisão. Esse feedback pode
resultar em alterações nas funcionalidades recém-entregues. Mas pode resultar também
numa provável revisão ou a adição de itens para no Product Backlog.

Outra atividade realizada no final de cada Sprint é a retrospectiva do sprint.

Toda a equipe participa nesta reunião, incluindo o ScrumMaster e o Product Owner. Essa
reunião é uma oportunidade para refletir sobre o Sprint que está terminando e identificar
oportunidades de melhoria no próximo Sprint.

6.3. Quais são os principais componentes de um projeto SCRUM?

O componente principal de um projeto SCRUM é, naturalmente, o

próprio produto. A equipe deverá trazer o produto ou o sistema para um
estado potencialmente utilizável no final de cada Sprint (MOUNTAIN GOAT,
2011).

O Product Backlog é uma lista completa das funcionalidades do produto. O

Product Backlog é priorizada pelo Product Owner para que a equipe trabalhe sempre
sobre as características mais importantes primeiro. A forma mais popular e bem sucedida
para criar um Product Backlog é preenchê-lo com histórias de usuários, que são breves
descrições das funcionalidades necessárias a partir da perspectiva de um usuário ou
cliente.

No primeiro dia de um Sprint e durante a Sprint Planning Meeting (reunião

de planejamento do sprint), os membros da equipe criam o Sprint Backlog. O Sprint
Backlog pode ser pensado como a lista de afazeres da equipe durante o Sprint.
Considerando que um Product Backlog é uma lista de itens a serem construídos, o Sprint
Backlog é a lista de tarefas que a equipe precisa realizar para oferecer a funcionalidade
que comprometeram a entregar durante o Sprint.

Dois outros componentes primários são o gráfico de Sprint Burndown e a

carta de liberação de manejo. Burndown charts mostra a quantidade de trabalho restante a
ser realizado. Eles são uma ferramenta muito eficaz para determinar rapidamente se um

Nome da Revista • Vol. 1, Nº. 1, Ano 2011 • p. 1-10

6 TÍTULO DO TRABALHO TODAS EM MAIÚSCULAS ESTILO <TITULO ARTIGO>

Sprint ou liberação está no cronograma para que todo o trabalho planejado termine até a
data desejada.

6.4. Quais são os papéis principais em uma equipe SCRUM?

Mesmo se você é novo no SCRUM, você pode ter ouvido falar

sobre o ScrumMaster. O ScrumMaster é o mediador da equipe e ajuda os
membros da equipe alcançar seu mais alto nível de desempenho. Um
ScrumMaster difere de um gerente de projeto tradicional em muitas maneiras
importantes, incluindo que o ScrumMaster não orienta o dia-a-dia da equipe e
não atribui tarefas a indivíduos. Um bom ScrumMaster protege a equipe de
distrações externas, permitindo que os membros da equipe se concentrem no
objetivo selecionado durante o desenvolvimento do Sprint (MOUNTAIN
GOAT, 2011).

Enquanto o ScrumMaster se concentra em ajudar a equipe a ser o melhor que

pode ser, o Product Owner trabalha para dirigir a equipe na meta certa. O Product Owner
faz isso criando uma visão convincente do produto e, em seguida, transmitir essa visão
para a equipe através do Product Backlog.

Uma maneira interessante de exemplificar o SCRUM seria como a de um carro

de corrida. A equipe seria o próprio carro, pronto para acelerar em qualquer direção. O
Product Owner seria o piloto, certificando-se que o carro está sempre indo na direção
correta. O ScrumMaster seria o mecânico-chefe, responsável por manter o carro bem
alinhado e executar sua melhor performance.

7. METODOLOGIA

Para realização deste estudo foram utilizadas pesquisas bibliográficas em

livros e internet. As pesquisas mostraram a falta de literatura em língua portuguesa sobre
o assunto, fato que motivou o uso no estudo de livros e sites em língua inglesa.

A realização do estudo de caso foi baseada na implantação da metodologia

SCRUM em uma empresa de desenvolvimento de software em que não havia
conhecimento algum sobre o assunto e que enfrentava problemas com estimativas e
cumprimentos de metas.

Nome da Revista • Vol. 1, Nº. 1, Ano 2011 • p. 1-10

 autor 1, autor 2 7

8. ESTUDO DE CASO

8.1. Introdução

No início como na maioria das pequenas empresas, sem um gestor de

projetos, tudo era bem parecido com as histórias tradicionais, empresas pequenas não tem
orçamento dedicado para uma consultoria para desenhar um processo de
desenvolvimento de software. Os projetos não cumpriam prazos e algumas vezes era
necessário realizarem muitos ajustes e retrabalho para satisfazerem as necessidades dos
clientes. Aplicar modelos e normas específicos para desenvolvimento de software como
CMMI (Capability Maturity Model Integration), poderia ser uma alternativa para resolver
os problemas, mas o resultado do trabalho seria uma documentação descrevendo cada
processo com varias páginas explicando paço a paço o que deveria ser feito. A solução era
encontrar outra maneira que se adaptasse as reais necessidades da empresa estudada.

8.2. Inicio da Implementação

A implantação de metodologias ágeis na empresa em questão vieram a partir

de uma especialização que um dos sócios da empresa estava realizando na área de Gestão
de Projetos. Tudo começou como sugestões deste sócio em aplicar práticas de
desenvolvimento ágil como o SCRUM em alguns projetos. A iniciativa partiu junto com à
oportunidade de melhorar a qualidade dos seus produtos e sistemas, pois havia uma
grande incidência de problemas e poucas aplicações eram testadas adequadamente.

No inicio da implantação a empresa encontrou dificuldades para se

organizar e alterou-se a periodicidade das entregas para duas semanas.

Diante de todas as dificuldades encontradas para ser organizarem, o sócio

propôs aos desenvolvedores a entregarem tarefas de duas em duas semanas, e dentro
desse período não haveria mudanças no planejamento, o planejamento seria feito no início
de cada período. Antes de iniciar cada tarefa de desenvolvimento, os clientes
selecionavam quais seriam as prioridades a serem entregues pela equipe de
desenvolvimento nas duas semanas seguintes. Antes que percebessem já haviam aceitado
a idéia de desenvolvimento ágil e a empresa a partir disso passaria a ter um inicio de
organização para fazer o trabalho.

Nome da Revista • Vol. 1, Nº. 1, Ano 2011 • p. 1-10

8 TÍTULO DO TRABALHO TODAS EM MAIÚSCULAS ESTILO <TITULO ARTIGO>

A partir deste momento passaram a aplicar SCRUM em toda empresa. O

primeiro problema que encontraram é que estavam no meio de um projeto feito da forma
tradicional e toda a fase de análise e especificação já tinha sido concluída. Chegaram a
cogitar a idéia de que seria melhor aguardarem um novo projeto, só que tinha a
consciência de que a hora era aquela e que não poderiam mais esperar e então iniciaram o
desenvolvimento do principal projeto utilizando técnicas do SCRUM.

Para toda equipe desenvolvimento ágil era uma novidade, para não terem
problemas acharem melhor não falar de SCRUM ou usar os termos técnicos.
Simplesmente começaram a aplicar durante o desenvolvimento e a equipe foi se
adaptando às práticas e à forma de trabalhar. As regras são muito simples e por isso foi
muito fácil de adotá-las. Ao longo dos primeiros Sprints o time foi amadurecendo,
entendendo a forma de trabalhar e também sugerindo adaptações para um melhor
funcionamento do projeto dentro da empresa.

8.3. O resultado atual

Após seis meses utilizando metodologias ágeis a empresa se tornou bem mais
madura usando SCRUM. Hoje, é possível perceber diferenças entre alguns projetos, que
por terem problemas acabaram se adaptando de forma diferente.

Com relação ao tempo dos Sprints, a empresa adotou prazos de duas semanas
ao invés de quatro, pois perceberam que com este tempo poderiam acabar se tornando
lentos na resposta às mudanças. Já vinham adotando iteração de duas semanas desde o
inicio de o desenvolvimento iterativo continuar com este tempo de ciclo seria mais fácil.

Utilizando metade do tempo indicado para SCRUM, optaram por usar metade
do tempo de planejamento. A recomendação é que o Sprint Planning tenha 8 horas para
um Sprint de 4 semanas, e como o Sprint seria de 2 semanas optaram por fazer um
planning de 4 horas. As Sprint Review, Retrospective e Daily SCRUM continuaram com a
mesma duração.

Os Sprint Plannings melhoravam constantemente. No início ultrapassavam o

tempo das reuniões discutindo assuntos que não eram necessários, atualmente já estão
mais focados e as reuniões tem resultados melhores.

Por último, as retrospectivas se tornaram uma aliada forte para adaptações

nos processos e melhora da forma de trabalhar, após a entrega dos primeiros projetos,
obtiveram bons resultados junto com a evolução da equipe que conseguiram solucionar a

Nome da Revista • Vol. 1, Nº. 1, Ano 2011 • p. 1-10

 autor 1, autor 2 9

maioria dos problemas. A empresa está evoluindo devagar e obtendo como resultado um
bom nível de maturidade.

9. CONSIDERAÇÕES FINAIS

Metodologias ágeis como quais quer outra dependem de pessoas. Na empresa

em estudo não foi diferente e as pessoas certas fizeram toda a diferença. Também existe
casos onde algumas pessoas simplesmente não se adaptam a essa maneira de trabalhar.
Devido a isso, novas contratações da empresa deveram passar por um critério a mais na
seleção de pessoas a partir deste ambiente criado dentro da empresa.

Para um bom resultado desta metodologia dentro da empresa é essencial que

a mesma esteja disposta a melhorar e fornecer apoio as mudanças, as equipes de
desenvolvimento precisam de autonomia para levar o projeto de forma correta. Como os
processos ágeis são diferentes dos tradicionais, algumas empresas sentem medo de
fazerem modificações, por falta de conhecimento, e acabam prejudicando a adoção de
uma metodologia ágil. Durante o processo é essencial que o líder de equipe (Scrum
Masters) esteja muito bem capacitado e que conheça as práticas, regras e princípios do
SCRUM, não só para que tenham argumentação com a empresa, mas também para que
não façam adaptações que violem os princípios básicos das metodologias ágeis.

Por fim, a empresa ainda está muito longe do ideal, mas já visualiza muitas
oportunidades de melhoria na forma de trabalhar, acreditando que estão no caminho
certo para o crescimento e evolução dos negócios.

REFERÊNCIAS

MOUNTAIN GOAT Software, http://www.mountaingoatsoftware.com/topics/scrum, acessado

em 10 de setembro de 2011.
KNIBERG, Henrik. SCRUM e XP direto das Trincheiras. C4Media, Publisher of InfoQ.com, 2006.
PEREIRA, Everson José de Freitas e BORDIGNON, Leandro Luiz Costa. Gerenciamento de
projetos com utilização de SCRUM. POLICAMP – Faculdade Politécnica de Campinas, 2009.
SCHUWABER, K., SCRUM Development Process. Burlington, MA, USA, 1996.
http://www.inf.pucrs.br/~rafael/Scrumming/Scrumming.pdf acessado em 05 de novembro de
2011.
COCKBURN, A. and Highsmith, J., Agile Software Development: The Business of Innovation, IEEE
Computer, Sept, 2001. http://www.inf.pucrs.br/~rafael/Scrumming/Scrumming.pdf acessado
em 05 de novembro de 2011.
BARBOSA, Marcelo Bataglini. Estimando Projetos de Software Utilizando User Stories e Planning
Poker. Origem desconhecida.

Nome da Revista • Vol. 1, Nº. 1, Ano 2011 • p. 1-10

10 TÍTULO DO TRABALHO TODAS EM MAIÚSCULAS ESTILO <TITULO ARTIGO>

REVISTA ELETRÔNICA DE SISTEMAS DE INFORMAÇÃO,

http://revistas.facecla.com.br/index.php/reinfo/article/viewArticle/146, acessado em 16 de
outubro de 2010
SOARES, Michel dos Santos. Metodologias Ágeis Extreme Programming e SCRUM para o
Desenvolvimento de Software. Revista Eletrônica de Sistemas de Informação, 16 out. 2010.
Disponível em: <http://revistas.facecla.com.br/index.php/reinfo/article/viewArticle/146>.
Acesso em: 16 de outubro 2010.
CAELUM, http://www.caelum.com.br/curso/pm-83-agile-scrum/, acessado em 18 de novembro
de 2010.
IMPROBE IT, http://improveit.com.br/scrum/ acessado em 02 de dezembro de 2010.
ROCHA Bruno, http://rochacbruno.com.br/blog/wp-
content/uploads/2010/01/PortugueseScrum.pdf, acessado em 08 de dezembro de 2010

Nome da Revista • Vol. 1, Nº. 1, Ano 2011 • p. 1-10