Sei sulla pagina 1di 9

AVALIAO DO IMPACTO DO SCRUM

NO DESENVOLVIMENTO DE
SOFTWARE UTILIZANDO A ANLISE
SWOT

Mariana de Azevedo Santos (DCC/UFLA)
marianaazsantos@yahoo.com.br
Juliana Galvani Greghi (DCC/UFLA)
juliana@dcc.ufla.br
Paulo Henrique de Souza Bermejo (DCC/UFLA)
bermejo@stela.ufsc.br



Esse artigo relata um estudo de caso de carter exploratrio e
qualitativo, sobre a adoo da metodologia de desenvolvimento gil de
software Scrum em um laboratrio de pesquisa e desenvolvimento de
software para o setor florestal. O objetiivo da pesquisa avaliar o
impacto que a adoo do Scrum traz para a organizao, utilizando
como mtodo de anlise qualitativa, o framework de anlise de gesto
e posicionamento estratgico SWOT. O resultado exibido em uma
matriz, denominada matriz SWOT, que contempla os pontos fracos e
fortes da adoo do Scrum, bem como as oportunidades a serem
aproveitadas no mercado de software e as ameaas enfrentadas.

Palavras-chaves: Scrum, SWOT, metodologias geis, desenvolvimento
de software, gesto de projetos
XXX ENCONTRO NACIONAL DE ENGENHARIA DE PRODUO
Maturidade e desafios da Engenharia de Produo: competitividade das empresas, condies de trabalho, meio ambiente.
So Carlos, SP, Brasil, 12 a15 de outubro de 2010.






2

1 Introduo
O desenvolvimento de software um processo complexo (SCHWABER, 2004). Neste
contexto, a importncia das metodologias geis de desenvolvimento de software tem sido
destacada nos estudos de (DYB & DINGSYR, 2008), (MANN & MAURER, 2005),
(ERICKSSON et al., 2005), (ABRAHAMSSON et al., 2002), (WILLIAMS & COCKBURN,
2003), pois elas detm um paradigma, uma conceituao mais simples e objetiva que a
abordagem tradicional, buscando focar em menos documentao, resposta rpida a mudanas
de requisitos, uma ativa colaborao do cliente, alm de permitir a minimizao de riscos de
desenvolvimento (AGILE MANIFESTO, 2009).
Uma dessas metodologias geis de desenvolvimento de software, em particular, o
Scrum, vem tornando-se popular entre as empresas nos ltimos anos por atender dois fatores:
satisfao do cliente e rapidez nas entregas em relao s metodologias tradicionais (MANN
& MAURER, 2005).
A grande motivao do estudo insuficincia de uma reviso detalhada das
capacidades e limitaes que podem ser usados como base para identificar reas de melhoria
nas metodologias geis (SHAHIR et. al, 2008) e principalmente, uma reviso detalhada das
capacidades e limitaes do Scrum.
A segunda seo descreve a metodologia de anlise. A terceira seo apresenta uma
pesquisa da metodologia Scrum e a quarta, uma pesquisa sobre anlise SWOT. A quinta seo
descreve o estudo de caso realizado e a ltima seo apresenta e discute o resultado do estudo,
resumindo as propostas futuras concepo da pesquisa.

2 Metodologia
O presente estudo de carter exploratrio, de abordagem qualitativa. O meio de
obteno de dados foi o uso de entrevistas com os membros da equipe de TI do laboratrio em
pesquisa.
Para chegar aos resultados foi utilizada a ferramenta de anlise estratgica SWOT
(tambm conhecida como anlise FOFA). O objetivo da aplicao do SWOT no estudo
conseguir entender o impacto que a aderncia da metodologia Scrum traz organizao e, a
partir da anlise, definir quais aspectos culturais da organizao em estudo, que produz
softwares na rea de engenharia florestal, podem ser mudados ao aplicar o Scrum, trazendo
para a organizao um melhor aproveitamento e aprendizado em desenvolvimento de
software utilizando tal metodologia.
3 Scrum
Scrum uma metodologia gil e tambm definida como um framework interativo e
incremental de desenvolvimento de projetos de software. A princpio, ela foi idealizada como
um modelo de gerenciamento de projetos em indstrias automobilsticas e de produtos de
consumo (TAKEUCHI & NONAKA, 1986).
O nome Scrum deriva-se de uma estratgia usada no rgbi para o reincio do jogo, com
caractersticas similares ao mtodo de desenvolvimento proposto. Em 1993, a metodologia foi






3
concebida e implementada por Jeff Sutherland, John Scumniotales e Jeff McKenna, sendo
formalmente definida e documentada em 1995 por Ken Schwaber e Jeff Sutherland. Segundo
Schwaber e Beedle (2002), o Scrum tem como objetivo gerenciar e controlar processos de
desenvolvimento de software, focado em pessoas e que seja indicado para ambientes com
frequente mudana de requisitos.
De acordo com Beedle et al. (2000), todo o funcionamento do Scrum estruturado em
ciclos chamados Sprints, que so iteraes de trabalho que duram de duas a quatro semanas.
A metodologia estabelece tambm um conjunto de prticas e regras que devem ser cumpridas
pela equipe, em seus respectivos papis, para que o projeto seja bem sucedido.
Schwaber e Beedle (2002) definem que o Scrum possui trs papis: o Product Owner
representa o cliente no projeto. Define funcionalidades de acordo com o valor de mercado,
planeja e faz a lista de prioridades, conhecido Product Backlog, que devero ser cumpridas no
projeto dependendo da durao do mesmo; o Scrum Master, moderador entre os interesses do
time de desenvolvimento e do cliente. Sua responsabilidade manter a equipe funcional e
produtiva, resolver qualquer tipo de impedimento entre o Team e garantir que o processo
esteja no andamento adequado, incluindo a abertura das cerimnias, tambm chamadas de
prticas Scrum: o Daily Meeting (reunio diria do projeto), Sprint Review (reunio de
balano ao final de cada Sprint) e dos Sprint Planning Meetings (reunio onde define as
atividades que devero ser cumpridas no projeto por completo); e o Team, que o time
responsvel pelo desenvolvimento do projeto. Ele multidisciplinar e composto por um
grupo de cinco a nove integrantes. delegada a ele qualquer funo dentro do Sprint desde
que cumpra o prazo limite. Deve mostrar os resultados do projeto em andamento para o
Product Owner durante as formalidades.
O trabalho dentro do Sprint monitorado pelo Burndown Chart, que um grfico que
estima o tempo gasto no andamento do trabalho dentro do Sprint.
Um termo que vem se tornando comum dentro das organizaes que adotam a
metodologia o Scrumbut. Segundo Schwaber e Aguanno (2009), Scrumbut quando a
organizao adota o Scrum, mas o modifica, usando a lgica Ns usamos Scrum, mas
tivemos que mud-lo porque na nossa empresa.... E essas customizaes inapropriadas
podem causar riscos para a organizao.
Na Figura 1, pode-se visualizar o funcionamento geral do mtodo. Em primeiro lugar,
o Product Owner e o cliente definem o backlog. A partir dele, so determinados quais so os
requisitos que devem ser priorizados no Sprint. Durante os Sprints so realizados os Daily
Meetings, reunies dirias onde o time compartilha uns com os outros o andamento do
projeto. Ao final do Sprint, o Scrum Team entrega um incremento funcional do projeto ao
cliente que junto ao Product Owner, redefine os requisitos, a priori, de acordo com os seus
interesses.






4

Figura 1 Viso geral da metodologia Scrum (adaptado de MARAL et al., 2008)
4 SWOT
A anlise SWOT uma ferramenta de anlise de cenrio ou anlise de ambiente
utilizado para definir o posicionamento estratgico de uma empresa (ARMSTRONG, 1996).
Geralmente, utilizada no marketing e no planejamento estratgico, mas pode ser utilizada
para analisar qualquer tipo de cenrio empresarial (SHAHIR et. al, 2008). O termo SWOT
tem origem no ingls e uma sigla de strengths, wakeness, opportunities e threats (Shahir et.
al, 2008), que em portugus significam foras, fraquezas, oportunidades e ameaas,
respectivamente.
A origem e concepo da tcnica datada nos anos 60 (LEARNED et al., 1965).
Porm, Tarapanoff (2001, p. 209) afirma que SWOT j era utilizada h mais de trs mil anos
pelo estrategista militar chins Sun Tzu, na epgrafe: Concentre-se nos pontos fortes,
reconhea as fraquezas, agarre as oportunidades e proteja-se contra as ameaas.
O termo SWOT estuda o ambiente e a competitividade de uma organizao, baseada
nos seguintes aspectos (OLIVEIRA, 2001):
Ponto forte: a diferenciao conseguida pela empresa (varivel controlvel) que
lhe proporciona uma vantagem operacional no ambiente empresarial.
Ponto fraco: a situao inadequada da empresa (varivel controlvel) que lhe
proporciona uma desvantagem operacional no ambiente empresarial.
Oportunidade: a fora ambiental incontrolvel pela empresa, que pode favorecer
a sua ao estratgica, desde que conhecida e aproveitada satisfatoriamente
enquanto perdura.






5
Ameaa: a fora ambiental incontrolvel pela empresa, que cria obstculo sua
ao estratgica, mas que poder ou no ser evitada, desde que conhecida em
tempo hbil.
O resultado da anlise disposto em uma matriz chamada Matriz SWOT. Ela
fundamental na anlise de uma situao e o desenvolvimento de estratgias e tticas, de
acordo com o cenrio identificado.
5 Estudo de Caso
Como objetivo de coletar informaes relevantes sobre o assunto estudado, foi
realizado um estudo de caso de carter exploratrio em um laboratrio de pesquisa localizado
em Lavras, Minas Gerais. O objetivo da pesquisa analisar o impacto que a adoo da
metodologia Scrum trouxe para o laboratrio, atravs de dados qualitativos obtidos em
entrevistas com a equipe de TI do laboratrio em pesquisa.
A organizao estudada um laboratrio de pesquisa e desenvolvimento de software
no setor florestal. Inicialmente, adotava-se a metodologia de desenvolvimento em cascata, que
uma abordagem clssica, sistemtica e sequencial, que se inicia na especificao dos
requisitos pelo cliente, planejamento do projeto, modelagem, desenvolvimento e implantao
do software e culminando na manuteno progressiva do software (Sommerville, 2006),
usando como suporte algumas noes de gerncia de projetos do PMBOK (2008), que um
guia de referncia contendo um conjunto de boas prticas a serem seguidas ao gerenciar
projetos.
A proposta de adoo do Scrum surgiu no incio de 2009, perodo em que o laboratrio
enviou seus funcionrios para treinamento, prtica adotada anualmente. Apresentados
metodologia, o chefe de TI, acompanhado de um funcionrio fizeram os treinamentos oficias
da SCRUM ALLIANCE de Scrum Master e Product Owner, respectivamente. Aps o
treinamento, o conhecimento adquirido foi repassado para os demais membros do laboratrio
atravs de palestras. O cliente, que uma empresa pblica, tambm foi treinado e capacitado
em Scrum.
Houve resistncia na aceitao do mtodo pela falsa impresso de que metodologias
geis so desorganizadas. Entretanto, vencida a resistncia, a adoo foi positiva.
Outro ponto importante que o chefe de TI levantou foi a dificuldade de cobrar dos
funcionrios os deveres dirios do Scrum e viu a necessidade de formar Scrum Masters
dentro do laboratrio, pois ele viaja com bastante freqncia, o que torna difcil o
monitoramento das prticas do Scrum pela equipe. Ainda segundo o chefe de TI, o Scrum
melhorou o desempenho do laboratrio no desenvolvimento de projetos. Alm de
conquistarem a confiana do cliente, comearam a receber mais propostas em relao ao
concorrente que ainda adota o modelo cascata.
Outros aspectos do Scrum no laboratrio foram abordados atravs das entrevistas
concedidas pelos membros das equipes dos projetos da empresa. Os membros foram divididos
em duas equipes A e B, que trabalham nos projetos que sero chamados de projeto A, projeto
B e projeto C. Porm, deve ser esclarecido que o laboratrio trabalha com multi-equipes, ou
seja, os integrantes esto escalados em uma ou mais equipes, trabalhando em um ou vrios
projetos. A equipe A ficou encarregada dos projetos A e B e a equipe B ficou encarregada do
projeto C.






6
5.1 Projeto A
O projeto A foi um software sobre inventrio de resduos industriais. Esse projeto
possui uma peculiaridade. A princpio no foi utilizado nada especfico como metodologia,
mas de acordo com o Scrum Master 1, aplicou-se Scrum ao final do projeto. O Scrum Master
1 relatou que neste projeto inicialmente a equipe no utilizou nenhuma metodologia de
desenvolvimento. Percebeu-se que o projeto estava 60% concludo e nem todos os requisitos
prometidos cumpridos. Essa necessidade do laboratrio coincidiu com a volta dos
funcionrios do treinamento oficial.
Ento, o projeto foi finalizado com o uma adaptao do Scrum nos moldes do
laboratrio, j que a equipe ainda no havia sido treinada. Nessa fase de implantao, segundo
o Product Owner do projeto, os Sprints no eram bem sucedidos, sempre ultrapassavam o
tempo estimado nas tarefas.
Um ponto importante a ser levantado nesse projeto, que a partir das mudanas
ocasionadas nesse projeto, o laboratrio passou a adotar Scrum como metodologia de
desenvolvimento de software e gesto de projetos, alguns projetos seguindo as
recomendaes, outros com vrias adaptaes. Mesmo adaptado, o Scrum denotou uma
melhora em relao ao processo de produo do software e a equipe insiste que no deixa
essas diversas adaptaes transformarem o Scrum em Scrumbut.
5.2 Projeto B
O projeto B, sobre gases do efeito estufa, foi planejado e implementado utilizando
Scrum. Os Sprints comearam a sofrer variaes no tempo estimado para cumprir tarefas.
Essas variaes podem ser explicadas pela falta de experincia da equipe, j que o projeto B
foi um dos primeiros projetos com Scrum.
Os problemas enfrentados foram relacionados a este primeiro contato dos membros da
equipe com a metodologia e a dificuldade dos mesmos de abandonar velhos conceitos. O
Scrum Master 1 relatou a dificuldade de cumprir vrios papis dentro do Scrum e que mesmo
possuindo horrios bem delimitados para alternar-se nas funes, a mudana acaba afetando
sua produtividade.
Apesar dos problemas enfrentados, foram observados benefcios. O resultado do
Scrum, que o software, o produto final, mais rpido, o que garante uma melhor
transparncia frente ao cliente. O Scrum melhora a comunicao entre os membros do time,
faz com que a rotina de trabalho seja mais organizada e esteja mais atenta aos prazos,
obrigaes e expectativas dos clientes. Desenvolver em fatias e alter-las muito mais prtico
e eficiente que desenvolver o sistema por completo e tentar encaixar as vrias alteraes no
produto final. O Scrum ocasionou uma melhora significativa no desempenho do laboratrio.
5.3 Projeto C
O projeto C um sistema de controle de qualidade de gua. O Scrum Master do
projeto, identificado como Scrum Master 2, no possui certificao em Scrum. Ele comentou
que ao planejar os Sprints houve muitos problemas em relao comunicao, o que afetava
gradativamente na estimativa de tempo para cumprir os requisitos. Mas depois, a equipe
conseguiu alcanar as metas medida que entendia melhor o funcionamento do Scrum.
O Scrum Master 2 relatou que a adoo de Scrum pelo laboratrio foi interessante,
porque a organizao comeou com poucas pessoas na parte de TI, o que fortaleceu a cultura






7
organizacional no processo de desenvolvimento. Muitos dos grandes projetos que o
laboratrio desenvolveu, ou seja, projetos legados so considerados carros-chefes e deve-se
dar continuidade. A questo que, uma vez que h a necessidade de prestar servios ligados a
esses softwares, as atividades que envolvem Scrum param por completo.
Apesar desses problemas, o Scrum Master 2, que no adepto s prticas de
Engenharia de Software, relatou que o Scrum flexvel, o que facilita a sua adequao ao
mtodo de trabalho.
Houve um progresso na melhoria dos processos em relao aos projetos A e B, as
prticas do Scrum, principalmente as reunies em que o Team participa, comearam a ser
cumpridas mais formalmente.
O chefe de TI e o Product Owner 2 levantaram a possibilidade de adotar alguma outra
metodologia ou modelo de melhoria na qualidade de processos, como CMMI e MPS-BR,
juntamente com o Scrum. O objetivo seria organizar melhor os processos, trazendo maior
robustez ao laboratrio e uma documentao mais consistente.
6 Resultados e discusso
A partir das entrevistas foram identificados alguns pontos a serem analisados.
Organizando os fatores na Matriz SWOT, pode-se obter o seguinte resultado:
Matriz
SWOT
Ambiente Interno
Pontos Fortes

Pontos Fracos
A
m
b
i
e
n
t
e

E
x
t
e
r
n
o

O
p
o
r
t
u
n
i
d
a
d
e
s

A satisfao dos clientes;
Scrum traz rapidez nos
processos, ento a demanda
com o cliente aumentou;
Scrum melhorou o canal de
comunicao do Team;
Os desenvolvedores possuem
maior controle de suas tarefas;
Por ser incremental, o
progresso dos projetos fica
mais visvel para os clientes;
Falta de maturidade no processo;
O laboratrio se capacitar em CMMI
ou MPS-BR para atingir o nvel de
maturidade, mnimo necessrio;
Investimento na capacitao dos
funcionrios com competncias
sociais notveis, nos treinamentos
oficiais de Scrum Master e Product
Owner;
A
m
e
a

a
s

Scrum foi uma tentativa por
parte do laboratrio de deixar
uma metodologia informal e de
baixa maturidade;
Mesmo com o treinamento em Scrum,
o laboratrio ainda possui o vcio em
velhas prticas, apoiadas pela forte
cultura organizacional;
Uso excessivo de Scrumbut;
Se o concorrente adotar alguma
metodologia gil e j tiver maturidade
nos processos, pode conquistar o
mercado e o laboratrio perder;







8
Tabela 1 - Matriz SWOT
O resultado esperado pelo estudo era a avaliao do impacto da adoo do Scrum,
sendo ele positivo ou negativo. Diante da anlise apresentada na matriz SWOT, percebe-se
que a adoo trouxe como benefcios (pontos fortes) ao laboratrio em pesquisa:
Transparncia das atividades do projeto perante o cliente;
Maior rapidez em seus processos;
Melhoria na comunicao entre os membros da equipe.
Aumento da produtividade;
Entretanto, o laboratrio falha nas perspectivas internas, ao utilizar em excesso o
Scrumbut e no o Scrum em sua essncia. Schwaber (2008) afirma que o Scrum expe as
disfunes do produto e das prticas de desenvolvimento para que estas possam ser
corrigidas. A postura do laboratrio oposta.
Assim, pode-se concluir que o impacto gerado pela adoo do Scrum foi positivo
quanto aos fatores gesto de pessoas, produtividade e dinmica nas atividades do projeto.
Porm, a imaturidade e ineficincia em seus processos de planejamento e desenvolvimento de
software sugerem dificuldade em atingir a excelncia e robustez dos processos do laboratrio,
ameaando a qualidade do produto final.
Pode-se avaliar como impacto negativo o uso do Scrumbut, postura que deriva de uma
forte cultura organizacional, onde o laboratrio impe seus valores s prticas do Scrum e,
alguns deles, no produtivos. A flexibilidade na adaptao do Scrum deve ser coerente e com
limites.
Adotar um modelo de referncia ou melhoria na qualidade de processos como CMMI
ou MPS-BR, juntamente com o Scrum, pode ser uma oportunidade vivel para alcanar
maturidade e eficincia em seus processos. Porm, esta anlise pode ser feita em estudos
futuros.

7 Concluso
Os resultados obtidos do estudo de caso e da anlise SWOT confirmam a proposta
inicial da pesquisa, ao mostrar avaliao dos impactos tanto positivos e quanto negativos da
adoo do Scrum como metodologia de desenvolvimento de software no laboratrio em
estudo.
Em sntese, o presente estudo de caso contribuiu para rea de Engenharia de Software
identificando o impacto da adoo da metodologia Scrum no desenvolvimento de produtos de
software e os benefcios alcanados para a organizao, se esta aplicar a metodologia
adequadamente. Para a rea de Engenharia da Produo os resultados do estudo contriburam
para a anlise do desempenho de um produto de software e quais impactos sofrem o produto
final, se no h um comprometimento com a metodologia Scrum. Essencialmente, para a rea
de Gesto de Projetos, o estudo contribuiu mostrando que a adoo de Scrum pode
proporcionar um gerenciamento mais dinmico e transparente de projetos de software.
Entretanto, para que a pesquisa e os resultados desse estudo de caso comprovem um
valor de uso da metodologia Scrum, prope-se a elaborao de uma anlise mais aprofundada,
utilizando uma combinao de mtodos qualitativos e quantitativos, aplicados a uma






9
amostragem de organizaes nacionais e internacionais que utilizam a Scrum como
metodologia de desenvolvimento de produtos de software.
8 Referncias
ABRAHAMSSON, P.; SALO, O.;RONKAINEN, J.; WARSTA, J.; Agile software development methods:
review and analysis, VTT Technical report, 2002.
AGILE MANIFESTO. http://www.agilemanifesto.org/, disponvel em 10/10/09.
ARMSTRONG, M., Management Processes and Functions, CIPD, London, 1996.
BEEDLE, M. , DEVOS, M. , SHARON, Y. , SCHWABER, K., SUTHERLAND, J., SCRUM: An extension
pattern language for hyperproductive software development, Pattern Languages of Software Design 4, 2000.
DYBA, T.; DINGSYR, T. Empirical studies of agile software development: A systematic review. AGILE
08. Volume 50, Issue 9-10, Aug. 2008. Page(s): 833-859. AGILE Conference, 2008.
ERICKSON, J.; LYYTINEN, K.; SIAU, K. Agile Modeling, Agile software development, and extreme
programming: the state of research, Journal of Database Management 16 (4) (2005) 88100.
JAKOBSEN, C.R.; SUTHERLAND, J. Scrum and CMMI Going from Good to Great. AGILE 09. Volume,
Issue 24-28, Aug. 2009. Page(s):333 337. Agile Conference, 2009.
LEARNED, E.P., CHRISTENSEN, C.R., ANDREWS, K.E., GUTH, W.D. Business Policy: Text and Cases.
Irwin, Homewood, II, 1965.
MANN, C., MAURER, F. A case study on the impact of scrum on overtime and customer satisfaction. Agile
Development Conference, p. 70-79. IEEE Computer Society. 2005.
MARAL, A.S.C.; DE FREITAS, B.C.C.; FURTADO SOARES, F.S.; MACIEL, T.M.; BELCHIOR, A.D.
Blending Scrum practices and CMMI project management process areas. Innovations Syst Softw Eng (2008)
4:1729.
MOUNTAIN GOAT SOFTWARE. http://www.mountaingoatsoftware.com/ - disponvel em 24/09/09.
OLIVEIRA, D.P.R. Planejamento estratgico Conceitos, metodologia e prticas. Editora Atlas, 15 edio,
2001.
PMBOK Guide. Project Management Body of Knowledge (PMBOK Guide). 4 Edition, 2008.
SCHWABER,K. Agile Project Management with Scrum. Microsoft Press, 2004;
SCHWABER, K., BEEDLE, M. Agile Software Development with Scrum. Prentice Hall, 2002.
SCHWABER,K. Interview with Ken Schwaber: depoimento [19 de fevereiro de 2008]. AGILECOLLAB:
http://www.agilecollab.com/interview-with-ken-schwaber - disponvel em 03/11/09. Entrevista concedida a
AGILECOLLAB.
SCHAWABER,K., AGUANNO, K. ScrumButs: The Dangers of Customizing Scrum. Audio CD, 60 min. 2009.
SCRUM ALLIANCE. What is Scrum? http://www.scrumalliance.org/ - disponvel em 24/09/09.
SHAHIR, H. Y.; DANESHPAJOUH, S.; RAMSIN, R.: Improvement Strategies or Agile Processes: A SWOT
Analysis Approach, Proc. of the SERA Conference 2008, pp. 221-227
SOMMERVILLE, I. Engenharia de Software. Pearson, 8 edio, 2006.
TAKEUCHI, H.; NONAKA, I. The New New Product Development Game, Harvard Business Review,
1986.
TARAPANOFF, K. Inteligncia organizacional e competitiva. Braslia: Editora Universidade de Braslia, 2001;
TURNER, R.; JAIN, A. Agile Meets CMMI: Culture clash or common cause. P.153-165. XP/Agile Universe.
2002.
WILLIAMS, L. ; COCKBURN, A. Agile software development: its about feedback and change, IEEE
Computer 36 (6) (2003) 3943.

Potrebbero piacerti anche