16 66 2 PB

Prévia do material em texto

Departamento de Computação – Universidade Federal de São Carlos (UFSCar)
Caixa Postal 676 – 13.565-905 – São Carlos – SP – Brasil
Autor para correspondência: fzenaro@yahoo.com.br
ISSN 2316-2872
T.I.S. São Carlos, v. 1, n. 1, p. 76-81, jul. 2012
©Tecnologias, Infraestrutura e Software
A utilização do Scrum em um sistema web: 
um estudo de caso
Flávia dos Santos Zenaro
Abstract: This paper aims to address the question about software development using the Scrum agile development methodology in a web 
system that support decision making, called the Decision Support System or Sistema de Apoio a Decisão (SAD), based in Regency, Frequency 
and Monetary Value (RFV), which shows the evolution of customer of a company. Will be reported in this article what are the advantages of 
developing a web system using the Scrum agile methodology, indicating the gains from its use compared to traditional methodologies. The 
the professionals can prioritize project development gains in production areas and teams in applying the methodology scrum at the expense 
of traditional methodology.
Keywords: agile, Scrum, web application
Resumo: Este artigo tem como objetivo abordar a questão sobre desenvolvimento de software utilizando a metodologia de desenvolvimen-
to ágil Scrum em um sistema Web de apoio a tomada de decisão, chamado Sistema de Apoio a Decisão (SAD), baseado em Regência, Fre-
qüência e Valor Monetário (RFV), que demonstra a evolução da carteira de clientes de uma empresa. Neste artigo serão relatados os processos 
Como resultado deste estudo temos os benefícios que a metodologia ágil Scrum tem no desenvolvimento de software em pequenas equipes. 
aplicarem a metodologia Scrum em detrimento da metodologia tradicional.
Palavras-chave: metodologia ágil, Scrum, aplicação web
I. INTRODUÇÃO
A escolha de uma metodologia de desenvolvimento é uma 
das etapas no inicio do desenvolvimento de um novo software, 
assim como a escolha da linguagem de programação e o banco 
metodologia a ser utilizada para o software em questão reper-
cute, sem dúvida, em benefícios ao longo de todo o processo de 
fabricação de um software.
-
ração no momento da escolha, como: a quantidade de integran-
tes da equipe de desenvolvimento, o tamanho do software que 
será desenvolvido, o conhecimento da metodologia por parte 
dos integrantes e o prazo de entrega.
Com prazos cada vez mais apertados, recursos mais enxutos e 
-
senvolvimento de software e as empresas são obrigados a traba-
lharem, são necessários métodos que ajudem a atingir todos es-
ses objetivos minimizando gastos e maximizando os resultados.
Assim, o sucesso de um software não está somente na escolha 
se enquadra com o cenário e o ambiente em que esse software 
será desenvolvido. Conhecer as vantagens e desvantagens e os 
pontos fortes e fracos da metodologia são a chave para uma 
escolha mais acertada e, com isso, aumentar a probabilidade de 
software, tenha mais qualidade, atenda 
as necessidades reais do cliente, seja desenvolvido em menos 
tempo e com menos esforço de desenvolvimento. 
O restante do artigo está organizado da seguinte maneira: 
Na seção II é apresentado o objetivo do artigo. Na seção III 
é apresentada a fundamentação teórica em que a pesquisa foi 
baseada. Na seção IV são detalhadas as pesquisas realizadas 
anteriormente sobre o assunto. Na seção V é exibida a possí-
vel abordagem e metodologia de pesquisa, enquanto que na 
práticos encontrados.
II. OBJETIVO
Nesse contexto, este trabalho terá como maior objetivo des-
crever as vantagens que a metodologia ágil Scrum trouxe ao 
A utilização do Scrum em um sistema web: um estudo de caso
 77 T.I.S. 2012; 1 (1): 76-81
longo do desenvolvimento do software para Web chamado 
SAD.
As vantagens são visíveis desde a etapa de planejamento on- 
de é estabelecida a visão do projeto e a primeira versão do Pro-
duct backlog até a fase releasing, auxiliando assim, futuros pro- 
gramadores a entenderem como esta metodologia deve ser em-
pregada em cada fase do desenvolvimento de software e em quais 
fases essa metodologia trará mais benefícios para o projeto.
III. METODOLOGIA ÁGIL
Pelo motivo das metodologias tradicionais serem as mais 
estudadas e aplicadas e pelo fato que as metodologias de de-
senvolvimentos ágeis serem relativamente novas em compa-
ração à primeira, uma discussão mais aprofundada sobre esse 
assunto se faz necessário. Isso é válido para que equipes de 
projetos poderão aplicá-las. 
uma revolução dos métodos tradicionais de desenvolvimento 
de software. Alguns dos pontos chaves destas metodologias são 
a de eliminar gastos com documentação, documentando só o 
estritamente necessário, dando mais valor à comunicação e co-
laboração com o cliente, criando atividades que tragam valor à 
produção de software com qualidade.
Os aspectos humanos do desenvolvimento de software são 
mais enfatizados nas metodologias ágeis do que os aspectos de 
Engenharia de Software propriamente dito. O grande diferen-
cial nas metodologias ágeis é o reconhecimento de que as pes-
soas são uma fonte importante de conhecimento e condutores 
do sucesso do projeto.
Outra diferença marcante desta metodologia em comparação 
requisitos chamado na metologia ágil como Product Backlog 
sprint. 
O Scrum faz parte dessas metodologias. Outras podem ser 
citadas também: XP (Extreme Programming), FDD (Feature 
Driven Development), Crystal, Adaptative Software Develop-
ment, DSDM (Dynamic System Development Method) e LD 
(Agile Lean Development). 
Com a criação do “Manifesto Ágil” os seus conceitos ganha-
ram conhecimento. São eles formados por 4 propostas:
2º Software executável no lugar de desenvolvimento de docu-
mentação.
3º Colaboração do cliente ao invés de negociação de contratos.
4º Respostas rápidas a mudanças no lugar de seguir planos.
A metodologia ágil Scrum foi criada como um tipo de pro-
cesso de desenvolvimento inicialmente aplicado no gerencia-
mento de projetos em empresas de fabricação de automóveis e 
produtos de consumo em que se prioriza utilização de equipes 
pequenas para a operação das tarefas que envolvem o desenvol-
vimento de software.
processo para projeto e desenvolvimento de software orientado 
a objeto, que seja focado nas pessoas e que seja indicado para 
ambientes em que os requisitos surgem e mudam rapidamente. 
para o gerenciamento do processo de desenvolvimento de sof-
tware.
O primeiro desenvolvimento de software com Scrum foi 
realizado em 1993 por Jeff Sutherland na Easel Corporation 
(Sutherland 2004), e, junto com Ken Schwaber, formalizaram 
o Scrum (Sutherland e Schwaber 2007) como processo de de-
senvolvimento na OOPSLA.
IV. UTILIZAÇÃO DO SCRUM EM PROCESSO DE DESENVOLVIMENTO 
DE SOFTWARE
O Scrum possui um ciclo de vida composto de 4 fases a sa-
ber: planejamento, stagging, desenvolvimento e releasing. 
Na fase de planejamento é estabelecida a visão do projeto e 
expectativas garantindo recursos para a sua execução. São cria-
Product backlog e o plano 
de release que são as datas de entrega do sistema. 
O Product backlog é o ponto inicial do Scrum, sendo con-
siderada a prática responsável pela coleta dos requisitos, con-
forme aponta Schwaber (2004, p.33). Nesta prática, através de 
com todas as necessidades do negócio e os requisitos técnicos 
a serem desenvolvidos, ou seja, o Product backlog é uma lista 
de atividades que provavelmente serão desenvolvidas durante 
o projeto.
Na fase stagging
criando itens adicionais ao Product backlog relacionados com 
o tipo do sistema, time, ambiente de desenvolvimento e tipo de 
aplicação. Nesta fase os times são formados e são construídos 
os métodos de comunicação e coordenação entre eles.
É na fase de desenvolvimento que os sprints são realizados 
para o desenvolvimento dos incrementos de funcionalidades dosistema.
A fase de releasing é para efetuar a entrega do sistema ao 
cliente. 
As práticas gerenciais do Scrum são: Product backlog, Dai-
ly Scrum, Sprint, Sprint Planning Meeting, Sprint Backlog e 
Sprint Review Meeting.
Daily Scrum) são efetuadas pela equi-
pe de desenvolvimento, cliente, se possível, e Scrum Master a 
cada dia de duração do sprint. Tem como objetivo disseminar 
impedimentos e priorizar o trabalho a ser realizado no dia que 
se inicia. 
Os Daily Scrums normalmente são realizados no mesmo lo-
cal e no mesmo horário do dia. Idealmente são realizados na 
parte da manhã, para ajudar a equipe a estabelecer as priorida-
des do novo dia de trabalho.
discutidas durante o Daily Scrum, mas sim por algumas pesso-
as em um momento após a reunião. Neste período o objetivo é 
fundamentais: O que você fez ontem?, O que fará hoje? e Exis-
te algum impedimento no seu caminho?.
Flávia dos Santos Zenaro
T.I.S. 2012; 1 (1): 76-81 78
Concentrando-se no que cada pessoa fez ontem e no que ela 
fará hoje, a equipe ganha uma excelente compreensão sobre 
qual trabalho foi feito e qual trabalho ainda precisa ser feito. 
Nesta reunião os membros da equipe assumem compromissos 
uns para com os outros, fortalecendo os laços de comprometi-
mento e engajamento no projeto.
A reunião Sprint Planning é realizada com a presença do 
Product Owner, Scrum Master e de todo Scrum Team. Durante 
a reunião Sprint Planning, o Product Owner explica as funcio-
nalidades de maior prioridade para o Scrum Team, nesta reu-
nião o Scrum Team
eles irão mover do Product backlog para o Sprint Backlog.
Juntos, o Scrum Team e o Product Owner -
tivo para o Sprint (Sprint Goal), que é uma breve descrição do 
que pretende-se atingir no Sprint. O sucesso do Sprint será veri-
Sprint Review, baseado 
no Sprint Goal Sprint Backlog.
Depois da reunião Sprint Planning, o Scrum Team reúne-
-se separadamente para discutir o que foi proposto e decidir o 
quanto eles se comprometem a fazer durante o próximo Sprint. 
Product Owner, 
mas será sempre prerrogativa do Scrum Team determinar o 
quanto eles podem se comprometer.
A metodologia ágil Scrum utiliza o desenvolvimento atra-
vés de ciclos geralmente de duas semanas a 30 dias (chamados 
Sprint -
rias. Assim, como resultado, um produto independente e acaba-
e controle do desenvolvimento de software de maneira intera-
tiva e incremental, tem o objetivo de ser aplicado em pequenas 
o funcionamento do Scrum.
Um projeto se inicia com uma visão do produto que será 
desenvolvido, ou seja, pelos requisitos e funcionalidades que o 
software deverá conter. Estes requisitos e funcionalidades são 
Product Owner (PO) ou Dono do Projeto. Após 
isso, é criado o Sprint Backlog que nada mais é do que a escolha 
dos requisitos que deverão ser implantados no próximo Sprint.
O Sprint é o tempo de desenvolvimento das funcionalidades 
cada Sprint, é entregue um incremento do produto, um sistema 
acabado e funcionando, após ter passado por todo o processo 
de desenvolvimento, auditoria e teste. O Scrum implementa um 
esqueleto iterativo e incremental, através de três papéis princi-
pais [Schwaber 2004]. São eles: Scrum Master, Product Owner 
e o Time, que serão descritos a seguir.
A. O Papel do ScrumMaster
Em um projeto tradicional, o gerente de projeto é o respon-
Scrum 
Master tem o papel de gerir a equipe, mantendo-a unida e no 
caminho certo, e é também a pessoa que tem um bom conhe-
cimento dos processos que envolvem o desenvolvimento com 
Scrum para poder cobrá-los de sua equipe. O Scrum Master 
também é o responsável por proteger o time de interferências 
externas, removendo os impedimentos levantados pelo time e 
apoiando-o no uso do Scrum.
B. O Papel do Time
Conhecida como Team Members ou Equipe Scrum, é a equipe 
ou as várias equipes que podem trabalhar em paralelo na execu-
ção de um projeto de software. É responsável pelo desenvolvi-
mento dos itens de backlog product 
backlog em incremento de funcionalidades, gerenciando seu 
próprio trabalho. O time é responsável coletivamente pelo suces-
so da iteração e conseqüentemente pelo projeto como um todo. 
C. O Papel do Product Owner
Na metodologia Scrum, o Product Owner é o dono do pro-
jeto, ou seja, é a pessoa para quem está sendo desenvolvido o 
projeto. O Product Owner é quem estabelece os objetivos do 
Figura 1. Visão Geral do Processo Scrum 
(adaptado de Schwaber, 2004)
Dias de 
Trabalho 
Restantes
Figura 2. O avanço do desenvolvimento ao longo do Sprint. 
(adaptado de Schwaber, 2004)
A utilização do Scrum em um sistema web: um estudo de caso
 79 T.I.S. 2012; 1 (1): 76-81
-
cklogs, como são conhecidas, e participa ativamente de todo 
o desenvolvimento do software, validando o produto de cada 
sprint.
A cada iteração, o time controla o andamento do projeto re-
Sprint Burndown -
tra o trabalho restante estimado no Sprint. O eixo na vertical 
apresenta os dias de esforço restantes no Sprint. O eixo na ho-
rizontal representa os dias do Sprint.
-
dro de trabalho”, no qual as tarefas são dispostas segundo seus 
status [Schwaber 2004]. Esse quadro oferece maior clareza das 
tarefas, pois, como o Burndown, basta olhar para ele para reali-
zar a leitura do progresso do Sprint.
Product backlog
-
sprint a equipe demonstra as 
funcionalidades de trabalho para o Product Owner.
V. UTILIZAÇÃO DO SCRUM NO PROCESSO DE DESENVOLVIMENTO 
DO SISTEMA SAD
-
vimento de software pelo método ágil Scrum utilizando um sis-
tema web chamado Sistema de Apoio a Decisão (SAD) como 
estudo de caso.
Para isso, será detalhado como esse sistema foi desenvol-
vido e quais foram os resultados obtidos com a utilização da 
metodologia Scrum.
Nesse sentido, a aplicação da metodologia Scrum resultou 
na demonstração dos resultados do desenvolvimento do siste-
ma SAD nos requisitos funcionais: logar no sistema, cadastrar 
Para o desenvolvimento do sistema SAD foi criado o pro-
duct backlog, como ilustra a tabela 1, onde “ID” é um número 
-
portância do item de backlog podendo variar de 0 à 10 sendo 
o número 10 o mais importante, no campo “Est” coloca-se a 
estimativa em horas para a implementação do item de backlog, 
em “Como demonstrar” uma descrição em alto nível ou um 
pseudo-código do que deve acontecer durante o sprint e em 
“Notas” coloca-se qualquer informação que seja importante 
para o entendimento do item a ser desenvolvido.
A partir da criação da tabela de product backlog foi possível 
-
ção de quais itens do product backlog entrariam no primeiro 
sprint. 
VI. DESCRIÇÃO DOS SPRINTS REALIZADOS
Dentro deste contexto, descreve-se a seguir os detalhes dos 
sprints para os itens 1, 3 e 4 do product backlog: Logar no sis-
tema, Incluir usuário e Alterar usuário respectivamente.
Tabela 1. Product backlog do sistema SAD
Product backlog
ID Nome Imp Est Como demonstrar Notas
1
Logar no 
sistema
5 5
Usuários técnicos operacionais e estratégicos fazem o login no sistema 
informando email e senha já pré cadastradas pelo usuário técnico.
2
 
banco de 
dados
8 8
a conexão do banco do cliente com o banco SAD.
3
Incluir 
usuário
5 7
Logar-se, entrar na tela de cadastro de usuário, digitar os dados de 
4
Alterar 
usuário
5 5
Logar-se, entrar na tela de alterar usuário. Se o usuário for do tipo téc-
nico poderá alterar todos os dados. Para os outros tipos será permitida 
somente a alteração da senha.
Utilizar o mesmo 
arquivo CSS do 
ID 3.
5
Excluir 
usuário
5 5
Logar-se, acionar o item excluir. Somente o usuário técnico poderá 
realizar a exclusão dos usuários. Informar nome e email do usuário a 
ser excluído. 
Utilizar o mesmo 
arquivo CSS do 
ID 3.
6
dados
8 8
com o banco de dados do sistema.
7
RFV
10 10 - RFV de r1 a r5 e 
f1 a f5.
Flávia dos SantosZenaro
T.I.S. 2012; 1 (1): 76-81 80
product backlog foi escolhido pelo 
Scrum Master, para o primeiro sprint, o desenvolvimento do 
item 1 Logar no sistema. 
Foi utilizado um sprint de 7 dias com uma equipe de 3 pes-
-
ponsável pelo layout e os outros pela programação do módulo. 
Neste caso, pelo fato da equipe ter um número de integrantes 
reduzido, cada integrante desempenhou mais de um papel. 
O Product Owner além de estabelecer os itens do product 
backlog e determinar as prioridades de programação também 
participou do time, auxiliando no desenvolvimento. O Scrum 
Master desempenhou o papel de programador junto ao time, 
Scrum Master
sprint Login do sistema.
Figura 3. Tela de Login do sistema SAD
Para o segundo sprint foi escolhido o item 3 “Incluir Usuá-
rio” do Product Backlog. Para este sprint foram gastos 15 dias 
e tempo aproximado de 7 horas. 
Para este sprint os acompanhamentos diários que a metodo-
logia Scrum utiliza foram adaptados pela equipe, ao invés de 
serem diários, foram feitos conforme a necessidade. Quando 
cada membro do time encerrava a sua parte no desenvolvimen-
to, comunicava-a aos outros integrantes por email enviando os 
arquivos e um resumo do desenvolvimento. 
Quando algum integrante precisava de ajuda, este solicita-
tentava avançar no sprint. Quando julgávamos necessário era 
marcado um encontro para realizar o desenvolvimento em gru-
sprint.
Para o terceiro sprint foi escolhido o item Alterar usuário para 
dar continuidade ao sistema que já possuía a funcionalidade de 
Incluir usuário. Neste sprint foi estimado o tempo de 5 (cinco) 
horas de programação para a sua conclusão, mas devido a alguns 
impedimentos como a falta de experiência na linguagem java e 
problemas na programação que enfrentamos, foram necessárias 
8 (oito) horas de desenvolvimento e um encontro para desenvol-
vimento em conjunto. Os acompanhamentos foram com interva-
los de 1 (um) dia com envio por email do projeto e dos proble-
mas que estavam sendo enfrentados por cada programador. 
no terceiro sprint.
Figura 5. Tela de Inclusão de Usuário do sistema SAD
VII. CONCLUSÃO
A partir deste estudo de caso conclui-se que com a utilização 
do Scrum no desenvolvimento do sistema SAD a agilidade no 
processo de fabricação do software foi satisfatória mesmo com 
um número pequeno de integrantes. Evidenciamos assim, que 
a quantidade de pessoas envolvidas na elaboração de um sof-
tware
só o sucesso ou fracasso de um sistema, mas sim a utilização de 
uma metodologia que se enquadre com o cenário que envolve 
seu desenvolvimento.
Durante as etapas da utilização da metodologia Scrum no 
desenvolvimento do sistema SAD, percebeu-se a necessidade 
dos sprints de 30 dias para 7 ou 15 dias, conforme o calendário 
-
volvido por cada um, e saber quais os principais impedimentos 
sprint como tirar 
-
ximo item do product backlog a ser desenvolvido. 
Daily Scrum foram 
feitas de 1 a 3 vezes na semana, dependendo da complexidade 
do sprint, assim cada um do time enviava por email informa-
de um encontro para desenvolver algum item mais complexo 
em conjunto. 
Figura 4. Tela de Inclusão de Usuário do sistema SAD
A utilização do Scrum em um sistema web: um estudo de caso
 81 T.I.S. 2012; 1 (1): 76-81
Dessa forma, como a metodologia Scrum nunca fora antes 
utilizada por nenhum dos integrantes do grupo, podemos con-
cluir que foi uma experiência que acrescentou ganhos a todos 
e uma grande oportunidade de obtenção de conhecimento e vi-
vência no desenvolvimento de software utilizando uma meto-
dologia ágil. 
Evidenciamos que o Scrum agiliza e torna o processo de de-
senvolvimento de software mais direto pela ausência de criação 
de uma documentação detalhada, como nos modelos tradicio-
nais de desenvolvimento de software -
vamente no tempo total do projeto. Através dos sprints é pos-
sível desenvolver um produto acabado a cada ciclo de tempo 
fazendo com que o cliente possa utilizar o software
suas utilidades logo no início do desenvolvimento do sistema e 
ao longo do projeto em períodos curtos de tempo, propiciando 
oportunidades de ajustes e melhorias contínuas durante todo o 
desenvolvimento. 
REFERÊNCIAS 
BECK, K AT ALL. (2001) Manifesto for Agile Software Devel-
opment. Disponível em: <http://www.agilemanifesto.org>. 
Acesso em: 25/04/2010.
Cavalcanti, Eric at all. Ferramenta OpenSource para Apoio ao 
Uso do scrum por Equipes Distribuídas. Disponível em: 
<http://www.lbd.dcc.ufmg.br:8080/colecoes/wdds/2009/ 
006.pdf>. Acesso em: 26/05/2010
Cohn, Mike. Introduction to Scrum - An Agile Process. Dis-
ponível em: <http://www.mountaingoatsoftware.com/top-
ics/scrum>. Acesso em: 23/10/2010.
Highsmith, J. Agile Project Management – Creating Innovative 
Products, AddisonWesley, 2004.
Kniberg, Henrik. Scrum e XP direto das Trincheiras Como nós 
fazemos Scrum. InfoQ, 2007.
Schwaber, K. Agile Project Management With scrum. Micro-
soft Pr, 2004.
Sutherland, Jeff. Agile Development: Lessons Learned from the 
First scrum. Cutter Agile Project Management Advisory 
Service: Executive Update, vol.5, 2004.
Sutherland, Jeff, Schwaber, Ken. The Scrum Papers: Nuts, 
Bolts, and Origins of an Agile Process, Draft 14/10/2007.