Escolar Documentos
Profissional Documentos
Cultura Documentos
557-573, 2012
Abstract: This study presents the result of an action research that was carried out in a small technology-based
company, in which the Scrum agile methodology was applied in software product project. The company object of
this research operates in Itajub/MG, and its main products are software systems. Studies have shown that the
software industry is inefficient and ineffective. Micro and small technology-based companies have an even greater
challenge, considering their limited resources. Furthermore, traditional methods of software product development
are expensive. Considering that the strategic importance of micro and small technology-based companies in regional
development, Scrum should be compatible with their processes, so that they could become more competitive and reap
its benefits The objective of this paper is to monitor and assist the implementation of Scrum agile methodology in
new software product development in a small technology-based company to understand and measure the impact of
the use of this methodology in the company. The final results of the research show that this methodology increased
the teams motivation, reduced the cost, time, and risk of the project, and increased productivity. Therefore, with
these results, the organization tends to be more competitive since a successful product development management is
crucial to the success of a technology-based company.
Keywords: Scrum. Agile product development. Software product development. Software project management.
1Introduo
No atual ambiente de desenvolvimento de software,
os requisitos esto sujeitos a frequentes alteraes
durante o ciclo de desenvolvimento do produto para
atender s alteraes da demanda (RISING; JANOFF,
2000). Este fato torna o desenvolvimento de software
1
Ncleo de Otimizao da Manufatura e de Tecnologia da Inovao NOMATI, Instituto de Engenharia de Produo e Gesto IEPG,
Universidade Federal de Itajub UNIFEI, Av. BPS, 1303, Pinheirinho, CEP 37500-903, Itajub, MG, Brasil,
e-mail: bernardo@b2ml.com.br; carlos.mello@unifei.edu.br
559
3Mtodos geis
Ao longo dos anos, vrios mtodos de
desenvolvimento de produtos foram apresentados.
Entre eles, existem os chamados mtodos geis
(AMBLER, 2002), tambm chamados de mtodos
leves (FOWLER, 2000). Estes mtodos so mais
adaptativos e flexveis em relao aos tradicionais.
Alm disso, eles so indicados para cenrios em que
existe constante mudana de requisitos e os resultados
devem ser entregues em pequenos espaos de tempo.
Geralmente, esses mtodos dividem o
desenvolvimento em diversas iteraes de ciclos mais
curtos (no caso do Scrum e para o presente trabalho,
estes ciclos so chamados de Sprints) e realizam
entregas ao final de cada uma delas, de forma que [...]
o cliente (interno ou externo) receba uma verso que
4Scrum
4.1 Histria
O mtodo Scrum segue os princpios do Manifesto
gil (MANIFESTO GIL, 2001) e tem como pai
trs de seus signatrios: Mike Beedle, Ken Schwaber
e Jeff Sutherland. Segundo Schwaber e Beedle
(2002), ele tem como objetivo definir um processo
de desenvolvimento de projetos focado nas pessoas
da equipe.
O nome Scrum surgiu da comparao entre
desenvolvedores e jogadores de Rugby. Scrum a
denominao da rpida reunio que ocorre quando
os jogadores de Rugby vo iniciar um lance. A
primeira utilizao deste termo surgiu em um estudo
de Takeuchi e Nonaka (1986), no qual os autores
4.2 Benefcios
A literatura pesquisada mostra que a utilizao
deste mtodo pode gerar benefcios como aumento
da satisfao de clientes, por meio da diminuio
das reclamaes (MANN; MAURER, 2005; SALO;
ABRAHAMSSON, 2008); melhoria na comunicao
e aumento da colaborao entre envolvidos nos
projetos (BERCZUK, 2007); aumento do retorno
do investimento em projetos de novos produtos
(SULAIMAN; BARTON; BLACKBURN, 2006;
SUTHERLAND, 2005); aumento da motivao da
equipe de desenvolvimento de produtos (KNIBERG;
FARHANG, 2008; PAASIVAARA; DURASIEWICZ;
LASSENIUS, 2008); melhoria da qualidade do produto
produzido (SUTHERLAND et al., 2008; BARTON;
CAMPBELL, 2007); diminuio dos custos de
produo (SUTHERLAND et al., 2007; BRUEGGE;
SCHILLER, 2008); aumento de produtividade da equipe
de desenvolvimento (SUTHERLAND et al., 2008;
MARAL et al., 2007); diminuio no tempo gasto para
terminar projetos de desenvolvimento de novos produtos
(SUTHERLAND et al., 2008; SANDERS, 2007); e
diminuio do risco em projetos de desenvolvimento
de novos produtos (EDWARDS, 2008).
561
4.4 Crticas
Apesar de bem aceito na indstria de software,
o Scrum tambm sofre grandes crticas e
questionado quanto ao seu domnio de aplicao.
Segundo alguns acadmicos mais tradicionais
(GREGRIO et al., 2007), ele tem como principais
pontos fracos a falta de escalabilidade para equipes
grandes e geograficamente dispersas e a necessidade
da mudana de cultura da instituio.
Entretanto, a primeira crtica foi negada
empiricamente por Paasivaara, Durasiewicz e
Lassenius (2008), que mostrou que o Scrum foi
usado com sucesso em diversos projetos de grandes
dimenses e cujos times estavam distribudos em
diversas plantas empresariais. A segunda crtica
procede, j que uma das grandes barreiras para a
5Mtodo da pesquisa
Pode-se classificar o presente trabalho como
de natureza aplicada, devido ao interesse prtico
na aplicao de seus resultados na resoluo de
problemas reais. Quanto aos seus objetivos, a
presente pesquisa descritiva, pois visou descrever
as caractersticas do objeto de estudo e estabelecer
relaes entre as variveis. Sua abordagem , em
sua maior parte, qualitativa, pois a maioria dos
resultados da pesquisa-ao no pode ser mensurada
numericamente e h uma relao dinmica, entre o
objeto de estudo e o pesquisador, que no pode ser
traduzida em nmeros.
Neste estudo, utilizou-se a estratgia de
pesquisa-ao. Trata-se de uma sistemtica de
pesquisa social com base emprica concebida e
realizada em associao com uma ao ou com
a resoluo de um problema coletivo no qual os
pesquisadores e os participantes representativos
da situao ou do problema esto envolvidos de
modo participativo (THIOLLENT, 2005). A fase
exploratria da pesquisa durou de janeiro a abril de
2008. A fase de planejamento, de abril a junho de
2008. A primeira iterao foi de junho a novembro
1. Time
(membros
do time)
2. Scrum
Master
3. Dono do
produto
(Product
owner)
4. Backlog do
produto
(Product
backlog)
5. Estimativas
6. Reunio de
planejamento
do Sprint
7. Sprint
1.1. Trabalham lado a lado. Este aspecto importante para melhorar a comunicao e aumentar a
sinergia no time.
1.2. Colaboram entre si para implementar os requisitos do backlog do Sprint.
1.3. Tm capacidade de desempenhar vrias funes. Deve-se evitar uma superespecializao do
time, de modo que um componente no saiba realizar a tarefa de outros.
1.4. Admitem quando tm problemas e pedem ajuda ao Scrum Master quando isto acontece.
1.5. Ajudam-se mutuamente. Eles precisam entender que as metas do projeto so todas coletivas:
no h vitria ou derrota individual.
1.6. Aceitam responsabilidades e se comprometem. O time deve se autogerenciar, o que torna esta
caracterstica fundamental.
1.7. No necessitam fazer hora extra sistematicamente, permitindo que tenham uma vida social
agradvel e menos estressante.
2.1. Todos os times tm um.
2.2. Trabalha ao lado de seu time e est presente quando solicitado.
2.3. Tem como prioridade mxima resolver os impedimentos da equipe (ele trabalha para resolver
os itens do backlog dos impedimentos).
3.1. Todos os times tm um. Est sempre disponvel para o time tirar dvidas quanto s regras de
negcio.
3.2. Entende o produto e as necessidades do cliente (ou do pblico alvo do produto) a ponto de tirar
dvidas da equipe sobre seu funcionamento esperado em cada situao.
3.3. Entende o produto e as necessidades do cliente (ou do pblico alvo do produto) a ponto de
saber quais so as funcionalidades prioritrias e, portanto, que devem ser implementadas primeiro.
3.4. Tem o poder de fazer o time trabalhar primeiramente para implementar as funcionalidades
prioritrias.
4.1. O dono do produto tem total controle sobre o Backlog do Produto, podendo alterar prioridades
e colocar novos itens.
4.2. Ele est facilmente acessvel e visvel para todo o time em qualquer momento.
4.3. Ele atualizado aps cada Sprint, durante a reunio de reviso do Sprint.
4.4. Contm somente funcionalidades do produto e nada mais. O Backlog do Produto no contm
nenhuma tarefa para o time.
4.5. Cada funcionalidade do Backlog do Produto contm uma definio prpria, de modo que no
haver dvidas sobre consider-la ou no implementada.
5.1. O dono do produto recebe da equipe estimativas de quantidade de trabalho de cada
funcionalidade.
5.2. O time tem liberdade de estimar e no sofre presses externas para alterar estimativas.
5.3. Todos os membros do time participam das estimativas.
6.1. Todos os membros do time participam dela.
6.2. Ela resulta em um plano do Sprint, com um Backlog do Sprint. Este Backlog do Sprint est
corretamente priorizado de acordo com o dono do produto.
6.3. Todos os membros do time devem concordar que o planejamento ficou realista. Caso contrrio,
a reunio deve continuar at se chegar a um consenso.
6.4. Todos os membros do time se comprometem com o planejado.
7.1. O time entrega um produto (ou prottipo) funcionando no final de cada Sprint.
7.2. O time segue rigorosamente as prioridades do Backlog do Sprint.
7.3. O time age corretivamente quando est atrasado.
7.4. O time alerta o Scrum Master e o dono do produto quando h problemas.
7.5. O time sabe quando encontrar informaes detalhadas que sejam teis para implementar cada
funcionalidade.
7.6. Os problemas so discutidos e resolvidos no momento em que ocorrem.
7.7. A durao de cada Sprint sempre a mesma durante um projeto.
7.8. O intervalo entre dois Sprints de, no mximo, um dia.
7.9. Todos os envolvidos (incluindo clientes e outros times de outros projetos da empresa) sabem
sobre o Sprint, seus prazos e quais so seus produtos finais.
7.10. As funcionalidades que comeam a ser implementadas num Sprint terminam no mesmo Sprint.
563
Quadro 1. Continuao...
8. Reunio
diria
(Daily
scrum)
9. Reunio
retrospectiva
10. Backlog de
impedimentos
(Impediment
backlog)
11. Velocidade
12. Grfico
burndown
13. Backlog
do sprint
6Descrio da pesquisa-ao
6.1 Fase exploratria: identificao da
situao-problema
Nesta fase, foi divulgada a proposta desta pesquisa
empresa e foi obtido o comprometimento dos
participantes e interessados.
Foram realizadas entrevistas semiestruturadas
com pessoas-chave que participam do processo de
desenvolvimento de produtos da empresa. O objetivo
destas entrevistas foi de complementar a anlise de
dados secundrios disponibilizados pela empresa com
a opinio e o depoimento dos indivduos envolvidos
sobre as prticas de desenvolvimento.
interessante explorar o contexto histrico da
empresa. Algumas semanas aps sua fundao, a
empresa havia feito, em parceria com um consultor
independente, um processo de desenvolvimento de
software baseado no desenvolvimento em cascata.
Esta tentativa se mostrou um completo fracasso,
j que os processos desenhados nunca saram do
papel. Esses processos se mostraram muito pesados e
tornaram-se inviveis as tentativas de sua implantao.
Em entrevista, um dos colaboradores da empresa na
poca (que hoje trabalha em uma multinacional em
So Jos dos Campos/SP) disse que:
Aqueles processos eram burocrticos demais. No
havia a menor necessidade de termos aquilo tudo
naquele momento. Como o consultor era muito focado
em qualidade de software, aquilo poderia at servir
para empresas com grandes equipes e certificadas
em CMMI e MPS.br. Mas se ns implementssemos
aquele processo, iramos ficar fazendo muita atividade
burocrtica e nenhum produto. (Antigo colaborador
da B2ML).
Pelas outras entrevistas realizadas, o colaborador
expressa o sentimento da maioria em relao aos
primeiros processos definidos. Esta situao levou a
empresa a ir para um outro extremo: a total falta de
processos. O diretor de tecnologia comenta a situao:
Sabamos que estvamos errados, mas no
sabamos que direo tomar e como melhorar. Os
projetos estavam cada vez mais atrasados e os prazos
565
567
Item
1
2
3
4
Mdia
4,67
4,00
4,17
4,17
Desvio padro
0,52
0,63
0,75
0,41
Item
1
2
3
4
Afirmaes
O mtodo Scrum melhorou a comunicao e a colaborao entre os envolvidos.
O mtodo Scrum aumentou nossa motivao.
O mtodo Scrum facilitou para que o projeto terminasse mais rpido.
O mtodo Scrum diminuiu os riscos do projeto e as possibilidades de insucesso.
569
Item
Vantagens/Facilidades
Desvantagens/Dificuldades
O time sentiu dificuldade para elaborar sua
Backlog do produto Sua adoo melhorou o planejamento do time. primeira verso que geralmente muito
extensa.
Houve algumas falhas de periodicidade
Sua utilizao aumentou muito o controle do
Reunio diria
devido a desencontros de horrios dos
projeto. Os riscos foram minimizados.
membros da equipe.
A diviso do projeto em Sprints aumentou a Devido inexperincia da equipe, alguns
Sprint
motivao do time.
Sprints tiveram durao muito longa.
Planejamento do Sua realizao melhorou o planejamento do
As primeiras reunies foram pouco
sprint
Sprint.
produtivas devido inexperincia da equipe.
Sua boa elaborao crucial para o sucesso
Seu superdimensionamento causou um atraso
Backlog do sprint
ou fracasso do Sprint.
nos primeiros Sprints.
Tende a no ser executado pela equipe
Importante reunio para o recolhimento das
quando o time est ansioso para o
Reviso do sprint
lies aprendidas.
planejamento do prximo Sprint.
uma boa ferramenta para cobrar a resoluo Tende a ser negligenciado pelo prprio
Backlog de
de problemas conhecidos, diminuindo os
Scrum Master, para evitar maiores
impedimentos
riscos do projeto.
responsabilidades.
Foi o item mais complexo de ser
Velocidade e
Muito importante para o controle do projeto e
implementado e que exigiu mais treinamento
estimativas
para o planejamento de custos da empresa.
e novos conhecimentos.
uma ferramenta visual interessante, que
Tende a ser abandonado, pois, primeira
Grfico burndown
deixa claro o que os nmeros j mostravam. vista, parece informao redundante.
No foi o caso do projeto estudado, mas
Facilita para o time, que passa a ter um
provavelmente difcil encontrar uma pessoa
Dono do produto representante do cliente dentro da prpria
que entenda realmente o negcio do cliente a
empresa.
ponto de fazer bem este papel.
imprescindvel para tirar dvidas quanto
Muitas vezes o time o v como um gerente
Scrum master
ao processo de desenvolvimento e liderar as do projeto, deixando para ele atribuies que
cerimnias do Scrum.
deveriam ser do prprio time.
7Concluso
Pode-se afirmar que a contribuio principal da
presente pesquisa mostrar de forma cientfica o
impacto da implantao do mtodo gil Scrum nos
projetos de desenvolvimento de novos produtos de
software de uma empresa de base tecnolgica. O
foco da anlise foi o impacto do mtodo sobre o
ponto de vista dos benefcios que a literatura lhe
atribua. A equipe participante da pesquisa sentiu
diretamente quatro dos benefcios do Scrum: melhoria
na comunicao e aumento da colaborao entre
envolvidos; aumento da motivao da equipe de
desenvolvimento; diminuio no tempo gasto para
terminar o projeto (prazo); diminuio do risco do
projeto (menor possibilidade de insucesso).
Outros dois benefcios presentes na literatura
foram medidos e notados pelos dados quantitativos
do projeto piloto e de outros projetos da empresa:
diminuio dos custos de produo (mo de obra) e
aumento de produtividade da equipe.
Entretanto, no foi possvel investigar se houve
aumento da qualidade do produto, da satisfao de
clientes (pela diminuio das reclamaes) e do
retorno do investimento do projeto. Seria interessante
que, posteriormente, aps o produto ser de fato
comercializado, se investigue sobre esses trs fatores,
sendo esta uma proposta para um futuro trabalho.
Com isso, se completaria a anlise dos benefcios
mapeados na pesquisa bibliogrfica. Alm disso, uma
outra proposta de futuro trabalho seria a mensurao
quantitativa de certos itens como os custos de produo,
o tempo gasto no projeto e o ndice de reclamaes.
Para isso, seria necessrio conhecer dados confiveis
de histrico de projetos da empresa e compar-los
com dados aps a implantao do Scrum.
Concluiu-se que o mtodo Scrum foi condizente
com a realidade da empresa, pois se mostrou um
processo focado em resultados, na comunicao da
equipe e interao com os clientes sem desrespeitar
as restries enfrentadas por uma pequena empresa.
Isso corrobora a pesquisa realizada, mostrando que o
Scrum pode ser empregado como um mtodo adequado
para a gesto de projetos de software.
571
Item
Antes
Cada time tinha um gerente. Ele tinha como
responsabilidades o controle do projeto, o
contato com o cliente e assumia seus riscos.
Depois
O time se autogerencia. Todos os membros
Gerncia do projeto
do time assumem os riscos do projeto e tm
comprometimento com seu sucesso.
Criou-se a figura do dono do produto, o qual
Somente o gerente do projeto interagia com
Contato com o cliente
tem grande interao com o cliente e conhece
o cliente.
suas regras de negcio.
A velocidade do projeto medida e um grfico
No havia medio formal da velocidade do
Velocidade
de controle visual de toda a equipe atualizado
projeto. O nico controle eram os prazos.
diariamente.
O projeto rapidamente planejado no incio
Planejamento do
O projeto era inteiramente planejado em seu
e so realizados replanejamentos em cada
projeto
incio em detalhes.
Sprint.
Os itens de maior prioridade so
implementados antes, de modo que o retorno
As funcionalidades eram implementadas
Funcionalidades
do investimento ocorra mais rapidamente e
sem uma ordem especfica.
funcionalidades opcionais so implementadas
se o tempo permitir.
No havia mtodo formal para documentar O time realiza reunies de reviso para
Lies Aprendidas
as lies aprendidas
documentar as lies aprendidadas.
Existe o Backlog de Impedimentos, que uma
A gesto de riscos no era uma tarefa formal
boa ferramenta para todo o time conhecer
Riscos
e ficava sempre a cargo do gerente do
os riscos e cobrar a mitigao de riscos
projeto.
conhecidos.
So definidas no incio do projeto.
As entregas so diversas durante todo o projeto,
Entregas
Geralmente feita apenas uma entrega,
sempre com um produto com melhorias
j com o produto final.
incrementais em relao ao anterior.
Agradecimentos
Os autores gostariam de agradecer o apoio dado
para o desenvolvimento da presente pesquisa pela
FAPEMIG na forma da bolsa de produtividade,
do Programa Pesquisador Mineiro, do processo
TEC-PPM-00043/08.
Referncias
ABRAHAMSSON, P. et al. Agile software development
methods review and analysis. Espoo: VTT
Publications, 2002.
AMBLER, S. Agile modeling. New York: Wiley Computer
Publishing, 2002.
ASSOCIAO BRASILEIRA DAS EMPRESAS DE
SOFTWARE ABES. Disponvel em: <http://www.
abes.org.br/templ2.aspx?id=305&sub=305>. Acesso
em: mar. 2008.
BARTON, B.; CAMPBELL, E. Implementing a professional
services organization using type C Scrum. In: HAWAII
INTERNATIONAL CONFERENCE ON SYSTEM
SCIENCES HICSS, 40., 2007, Maui. Proceedings...
Maui, 2007. p. 275a.
BERCZUK, S. Back to basics: the role of agile principles
in success with an distributed scrum team. In: AGILE
CONFERENCE, 2007, Washington. Proceedings...
Washington, 2007. p. 382-388.
BRASIL. Congresso Nacional. Lei complementar n 123,
de 14 de dezembro de 2006. Institui o Estatuto Nacional
da Microempresa e da Empresa de Pequeno Porte.
Dirio Oficial da Repblica Federativa do Brasil,
Braslia, DF, 14 dez. 2006. Disponvel em: <http://
www.planalto.gov.br/ccivil_03/Leis/LCP/Lcp123.htm>.
Acesso em: ago. 2008.
BRUEGGE, B.; SCHILLER, J. Word spotting in scrum
meetings. In: INTERNATIONAL CONFERENCE ON
DATABASE AND EXPERT SYSTEMS APPLICATION
DEXA, 19. 2008, Turin. Proceedings... IEEE Comuter
Society, 2008. p. 125-129.
CARVALHO, B. V.; MELLO, C. H. P. Reviso, anlise
e classificao da literatura sobre o mtodo de
desenvolvimento de produtos gil Scrum. In: SIMPSIO
DE ADMINISTRAO DA PRODUO, LOGSTICA E
OPERAES INTERNACIONAIS SIMPOI, 12., 2009,
So Paulo. Anais... So Paulo, 2009.
CARVALHO, M. M. et al. Fatores crticos de sucesso em
empresas de base tecnolgica. Produto & Produo,
v. 4, n. especial, p. 47-59, 2000.
CRISTAL, M.; WILDT, D.; PRIKLADNICKI, R. Usage
of SCRUM: practices within a global company. Global
Software Engineering, p. 222-226, 2008.
573