Ser o Scrum suficiente?

Jonath Rodrigues Igncio, Maurcio Fritsch, Rafael Descio Trineto

Pontifcia Universidade Catlica do Paran (PUC-PR)
Caixa Postal 15.064 91.501-970 Curitiba PR Brasil
rafael@descio.com.br, mauricionik@gmail.com, jonath.mestre@gmail.com
Abstract. Scrum is an agile software development framework, and is growing
worldwide because it is simple to deploy, adaptable and integrable. The
purpose of this article is to describe the adherence level of Scrum, assessing
its completeness to manage the software development cycle. This research
describes points that make Scrum, even being an excellent agile framework,
emerge as failure in some software projects, because it does not cover all
areas of need. Is also identified cases in which Scrum has proven inefficient
and which are most used tools integrated to mitigate obstacles.
Resumo. Scrum um framework gil de desenvolvimento de software, e vem
crescendo mundialmente porque simples de ser implantado, adaptvel e
integrvel. O propsito deste artigo descrever o nvel de aderncia do
Scrum, avaliando sua completude para gerenciar o ciclo de desenvolvimento
de software. Nesta pesquisa esto descritos os pontos que fazem com que o
Scrum, mesmo sendo um excelente framework gil, desponte como insucesso
em alguns projetos de software, pois no abrange todas as suas reas
necessrias. Tambm identificado em quais casos Scrum tem se mostrado
ineficiente e quais as ferramentas mais usadas integradas para mitigar os
obstculos.
1. Introduo
Com a crescente demanda de projetos de software ao final do sculo XX, e
consequentemente uma necessidade de projetos mais rpidos e assertivos, surgiram na
dcada de 80 novos conceitos de desenvolvimento de software, com equipes reduzidas,
nmero de entregveis subdivididos em pequenos milestones e vrias partes do ciclo de
desenvolvimento tradicional removidas, como por exemplo, a documentao extensiva,
escopo esttico e pouca participao do cliente durante o desenvolvimento. Essas
mudanas tinham como foco as pessoas envolvidas no projeto e a comunicao,
realizando o levantamento de requisitos atravs de iteraes dinmicas, acelerando o
processo de mudanas durante o projeto. (Raty P. et al., 2013).
Quando Takeuchi e Nonaka (1986) no artigo intitulado The New New Product
Development Game descreveram um novo estilo de gerenciamento para equipes
multidisciplinares na fabricao de automveis e produtos de consumo, no tinham
ideia de como isso ganharia fora no gerenciamento de projetos. Em 1993, Sutherland,
Scumniotales e McKenna criaram o Scrum (Schwaber e Sutherland, 2011). Para
Carvalho e Mello (2006), o Scrum destaca-se dentre os mtodos geis, pela abordagem
enxuta de desenvolvimento, e foi Ken Schwaber quem formalizou a definio de
Scrum, apresentando um primeiro documento, intitulado Scrum Development Process,
em 1995 no OOPSLA (Object-Oriented Programming, Systems, Languages &
Applications). (Schwaber e Sutherland , 2011).
O termo 'Scrum' deriva de uma estratgia do jogo de Rugby aonde denota "pegar
uma bola fora de jogo e recoloc-la" com trabalho de equipe. (Schwaber e Beedle,
2002).
O guia do Scrum (Schwaber e Sutherland, 2011), diretriz mxima para sua



utilizao, expe que papis de trabalho, artefatos, eventos e regras so componentes do
Scrum e devem ser imutveis. Seu conceito prega que, se aplicado parcialmente, o
resultado final no ser Scrum. Ento, teoricamente s possvel afirmar e atestar sua
utilizao, se feita na integra. Havendo descaracterizao dos seus componentes, aliado
ao fato de subutilizao dos seus conceitos, formar-se- uma distoro do que seria seu
uso correto, o que interfere na eficincia de sua prtica, podendo haver perdas no
alcance dos resultados.
Muitas vezes confundido com Mtodos de Desenvolvimentos de Sistemas de
Informao (MDSI), o Scrum um dos frameworks de desenvolvimento gil mais
difundidos do mundo. Equipes de profissionais adotam esta ferramenta por alguns
fatores como facilidade de implantao e tempo de adaptao, pois outros modelos
burocratizam demais o processo de desenvolvimento. No entanto, ainda assim, este
modelo no se mostra suficiente para gerenciamento de projetos, e observou-se que
notoriamente uma excelente opo para servir de estrutura para outras tcnicas,
metodologias e prticas. (Schwaber e Sutherland, 2011). Para Kane et al. (2006) o
Scrum no especifica prticas de engenharia a serem utilizadas, tais como definies
para testes ou padres de codificao, j que por conceito ele no um modelo ou
metodologia, j que no prov orientaes claras, prticas de implementao nem
tampouco regras para aplicao de tarefas. Portanto, a utilizao de tcnicas
complementares como XP so recomendveis, segundo o autor.
2. Objetivos
Os objetivos principais desse artigo so: avaliar o uso do Scrum em diversos cenrios,
identificando seu nvel de aderncia (ser suficiente ou no para gerenciar projetos de
software), assim como identificar ferramentas auxiliares, modelos e metodologias
comumente utilizados integrados ao Scrum. Desta forma, estratificam-se os seguintes
objetivos especficos:
! Realizar uma srie de pesquisas bibliogrficas e documentais onde sero
levantados dados de pesquisas, dissertaes, peridicos, artigos cientficos,
internet ou jornais publicados pela comunidade gil, e posteriormente, atravs
de tcnicas de anlise de contedo, discorrer sobre o uso do Scrum de forma
complementada.
! Testar as seguintes hipteses sobre o contedo levantado:
! O Scrum ser suficiente como framework de desenvolvimento de
software;
! O Scrum no ser autossuficiente e depender de um framework
complementar;
! O Scrum ter um desempenho ou aceite melhor com determinada
metodologia;
! A insuficincia do Scrum ocorrer por m utilizao de suas prticas ou
por utilizao incompleta de suas regras.
! Identificar pontos positivos e negativos citados pelos usurios e comunidade
Scrum.
! Avaliar o Scrum como ferramenta suficiente para o gerenciamento das
atividades de projetos de software, atravs dos resultados encontrados.
3. Estado da arte
Scrum um framework estrutural que est sendo usado para gerenciar o
desenvolvimento de produtos complexos desde o incio dos anos 90. Scrum no um
processo ou uma tcnica para construir produtos; em vez disso, um framework dentro
do qual voc pode empregar vrios processos ou tcnicas. O Scrum deixa claro a
eficcia relativa das prticas de gerenciamento e desenvolvimento de produtos, de modo



que voc possa melhor-las. (Schwaber e Sutherland, 2011).
Scrum fundamentado nas teorias empricas de controle de processo, ou
empirismo. O empirismo afirma que o conhecimento vem da experincia e de tomada
de decises baseadas no que conhecido. O Scrum emprega uma abordagem iterativa e
incremental para aperfeioar a previsibilidade e o controle de riscos. (Schwaber e
Sutherland, 2011)
Rational Unified Process (RUP) um processo de engenharia de software que
fornece uma abordagem disciplinada para assumir tarefas e responsabilidades dentro de
uma organizao de desenvolvimento, cujo objetivo assegurar a produo de software
de alta qualidade dentro de prazos e oramentos previsveis (Kruchten, 2003).
Segundo Aydin et al. (2004) o uso eficaz dos Mtodos de Desenvolvimentos de
Sistemas de Informao (MDSI) tem permanecido como uma grande questo nas
agendas de acadmicos e profissionais. O MDSI tem sido interpretado como um
conjunto organizado de conceitos, crenas, valores, e princpios normativos suportados
por recursos materiais.
De acordo seus criadores em O Guia do Scrum (Schwaber, 2011), o Scrum
considerado um framework de prticas para desenvolvimento gil de projetos de
software. E conforme Booch, Rumbaugh e Jacobson (1998), framework um padro
arquitetural que prov um template extensvel para aplicaes dentro de um certo
domnio.
Modelo um resumo, uma construo conceitual que representa processos,
variveis e relacionamentos, sem prover orientaes especficas ou prticas para
implementao ou metodologia A metodologia um construto orientado que define
prticas, procedimentos e regras para a aplicao ou a execuo de uma tarefa ou funo
especfica (Tomhave, 2005).
Tomhave (2005) define framework como ...um construtor fundamental que
define pressupostos, conceitos, valores e prticas, e que incluem orientaes para a
execuo propriamente dita.
XP uma metodologia leve em desenvolvimento de software para times de
porte mdio ou pequeno em face de requisitos vagos ou em rpida mudana. [...] que
visa um rpido desenvolvimento, atende s reais necessidades do cliente e, ainda,
permite modificaes, medida que novas necessidades apaream. (Beck e Andres,
2004).
De acordo com o PMI (2004), o gerenciamento de projetos a aplicao de
conhecimento, habilidades, ferramentas e tcnicas s atividades do projeto a fim de
atender aos seus requisitos. O gerenciamento de projetos realizado atravs da
aplicao e da integrao dos seguintes processos de gerenciamento de projetos:
iniciao, planejamento, execuo, monitoramento e controle, e encerramento.
CMMI (Capability Maturity Model Integration-Modelo Integrado de
Maturidade e de Capacidade) um modelo de maturidade para melhoria de processo,
destinado ao desenvolvimento de produtos e servios, e composto pelas melhores
prticas associadas a atividades de desenvolvimento e de manuteno que cobrem o
ciclo de vida do produto da concepo at a entrega e manuteno (CMMI for
Development, Version 1.2, 2010).
Waterfall baseia-se na sequncia de atividades padronizadas cujos resultados
individuais so utilizados como pr-requisitos para a atividade subsequente,
graficamente descrito como uma cascata que comea com os requisitos do sistema e
termina com a operao (execuo) deste (Castillo e Souza, 2013).
Modelo Espiral assume que o processo de desenvolvimento ocorre em ciclos,



cada um contendo fases de avaliao e planeamento, onde a opo de abordagem para a
prxima fase (ou ciclo) determinada. (Santos e Rocha, 2010).
Modelo incremental, por Pressman (2010) combina elementos de fluxos de
processos lineares e paralelos. Ele aplica sequncias lineares de forma escalonada ao
longo do avano do cronograma. Cada sequncia linear produz "incrementos" liberados
do software de uma forma que semelhante dos produzidos por incrementos e fluxo
do processo evolucionrio.
O Scrum of Scrums Meeting uma tcnica importante na ampliao Scrum para
grandes equipes de projeto. Estas reunies permitem grupos de equipes para discutir o
seu trabalho, com especial destaque para as reas de sobreposio e integrao (Cohn,
2007).
Kanban uma metodologia just-in-time, que tem como filosofia que voc s
deve assumir o trabalho, tanto quanto voc tem a capacidade para realiz-lo (Technical
Communication Summit, 2011).
Em Scrum-Ban, cada membro da equipe mantm um trabalho em andamento
onde notas so dispostas no quadro em colunas para representar tarefas agendadas
(compromissos da Sprint), tarefas que no so planejadas, mas necessrias, o trabalho
em andamento, tarefas concludas e tarefas impedidas (Technical Communication
Summit, 2011).
4. Desenvolvimento
A crescente da Tecnologia da Informao, conforme apresentado pela Fundao Getlio
Vargas, em sua 24 edio, corrobora para o atendimento da demanda e expectativa de
uma sociedade emergente em utilizao de solues tecnolgicas ( Meirelles, 2013).
Divulgada em Abril de 2013, os dados trazem informaes de 2.220 empresas,
das quais 66% esto entre as 500 maiores do pas, e seu tema trata da utilizao da TI
(Tecnologia da Informao) nas empresas. Dos aspectos mais relevantes, podem-se
destacar os investimentos em TI por estas empresas, que ultrapassa os 7%, com
expectativa para ser maior que 8% no prximo ano. H dez anos este nmero no
superava os 5%. Outro ponto de representatividade desta pesquisa com relao ao
nmero de computadores em uso no Brasil, que supera os 118 milhes de unidades, e
estima-se que at 2016, haja um computador para cada pessoa. As novas tecnologias
como as dos tablets, so garantia de que estes nmeros continuem a crescer. Na esfera
pblica, o Ministrio do Planejamento fez um previso de mais de 7 bilhes com gastos
em TI para o ano de 2014.
A tendncia de crescimento pode ser confirmada por dados da Associao
Brasileira de Empresas de Desenvolvimento de Software, que registrou em 2011 e 2012
crescimentos de 12,6% e 26,7% respectivamente, garantindo ao Brasil 7 lugar no
ranking mundial de software, porm com singelos ainda 3% de participao do total
deste nicho.
Segundo (Sommerville, 2007) o Desenvolvimento de software pertence
disciplina de Engenharia de Software, com surgimento em 1968, no que foi chamada de
crise do software, poca em que projetos no cumpriam prazos nem oramentos, e
tinham baixa qualidade. Foi necessrio criar mtodos para controlar a complexidade dos
sistemas.
De acordo com Guantamukkala et al. (2006) desenvolvimento de software teve
evoluo conforme a seguinte sequncia: Code and fix (dcada de 60; codificar e
corrigir), depois cascata (waterfall) na dcada de 70, desenvolvimento em espiral
(dcada de 80, entrega incremental), e mais recentemente, nos anos 90, os mtodos
geis onde so destacados: XP, Crystal e o Scrum.



4.1. Mtodos de desenvolvimento
Tambm conhecidas como Metodologias orientadas a planejamento, as Metodologias
Clssicas dominaram a forma de desenvolvimento de softwares at o incio da dcada
de 90, entretanto, estas metodologias devem ser aplicadas apenas em situaes em que
os requisitos do sistema so estveis e os requisitos futuros so previsveis (Tomhave,
2005).
Metodologias ou Processos orientados a documentao so como barreiras
impostas ao desenvolvimento, pois muitas organizaes no possuem recursos para
processos pesados de produo de software. Por esta razo, as organizaes pequenas
acabam por no usar nenhum processo. Isto pode trazer efeitos negativos no que diz
respeito qualidade do produto final, alm de dificultar a entrega do software nos
prazos, custos e funcionalidades previamente definidas (Tomhave, 2005).
Ganhando fora nas ltimas dcadas, os mtodos geis mostraram como
responder ao ambiente turbulento das mudanas e das alteraes nos requisitos, bem
como a participao contnua do cliente melhora o feedback do projeto priorizando o
que deve realmente ser feito. Na dcada de 1990, os gestores tomaram conscincia de
que o desenvolvimento de software havia sido significativamente acelerado. Centenas
de literaturas promoviam o desenvolvimento gil como tema principal ou secundrio de
projetos de sucesso (Larman e Basilli, 2003).
Constatando que mais efetivo melhorar o processo de aceitao de mudanas
de requisitos ao invs de tentar evit-las, a final, as mudanas refletem em sua maioria
melhoras no sistema para atender s necessidades especficas do cliente, e isto por sua
vez agrega mais valor ao negcio. A comunidade gil tomou um novo rumo quando em
2001 em Utah, EUA, 17 pessoas que praticavam as ideias geis se reuniram para
discutir e trocar conhecimento acerca das metodologias geis e deram origem ao
documento intitulado Manifesto for Agile Software Development que traz em sua
composio os quatro valores e os doze princpios do desenvolvimento gil (Fowler e
Highsmith, 2001).
A publicao deste manifesto foi um divisor de guas para a comunidade, pois
trouxe uma luz acerca dessa filosofia que embora to falada fosse pouco entendida e
difcil de ser conceituada. Aps todo esse esforo, tomam-se duas linhas de pensamento
para definir gil: uma focada no desenvolvimento e outra na gesto, e isso se d porque
as ideias geis se misturaram s boas prticas de desenvolvimento e boas experincias
de gesto, por isso aceitvel e certo que seu conceito sofra adaptaes conforme a rea
em que aplicada.
Vrios modelos de gerenciamento como o Crystal, FDD, TDD, DSDM,
Pragmatic Programming e Scrum foram de encontro com as definies e muitas
prticas de desenvolvimento se encaixavam nas prerrogativas tcnicas, restava apontar
quais as melhores ou entender em que caso determinada ferramenta se adequaria melhor
ao projeto. Dentre tantas metodologias para gerenciamento das atividades do processo
de desenvolvimento de software o Scrum ganhou notria visibilidade e aceitao.
Scrum foi desenvolvido para gerenciar o processo de desenvolvimento em ambiente
instveis. Ele tem uma abordagem emprica baseada na flexibilidade, adaptabilidade e
produtividade, e deixa em aberto para os desenvolvedores escolherem as tcnicas de
desenvolvimento, mtodos e prticas. Ele envolve atividades de mudanas frequentes,
identificando quaisquer deficincias ou impedimentos no processo de desenvolvimento
e das prticas utilizadas (Pekka e Juhani, 2003).
O aparecimento dos mtodos geis tem sido a mudana mais visvel e
significativa para o processo de gerenciamento e de desenvolvimento de software nos
ltimos anos, mas na verdade muitas das "ideias geis" existem antes da dcada de 70.
Vrios estudos tm sido realizados sobre mtodos geis, e constatam que o seu



aparecimento e crescimento vm de uma reao contra os mtodos tradicionais (Abbas,
Andrew e Wills, 2008).
Empecilho com o uso dos mtodos geis pode ser visto na reviso de literatura
realizado por Dyba e Dingsoyr (2008) sobre estudos empricos de Desenvolvimento
gil at 2005. Os autores concluram que o mtodo gil mais adequado s equipes
reduzidas, que h dificuldade na presena do cliente a todo o momento, que h
dificuldade de interao entre as equipes e que os problemas de arquitetura so
ignorados. Assim, Scrum se encaixa como modelo que possibilita uma integrao
continuada com testes e integraes eficientes, sem contar a pouca rotatividade de uma
equipe, j que reduzida.
A dificuldade de aplicao pode ser delegada cultura da organizao. Isso
compreensvel, pois o modelo gil vem resolver uma situao que evidente, e talvez o
maior problema dos modelos tradicionais: previso plena dos requisitos. Empresas
dinmicas tendem a mudar constantemente o escopo, para tanto se faz desnecessrio o
levantamento pleno dos seus requisitos, sem considerar que estes podem ser levantados
pelos arquitetos no decorrer do desenvolvimento. Como os requisitos no so estveis e
os requisitos futuros no so todos previsveis, pela necessidade de mudanas, o modelo
convencional praticamente inviabiliza o desenvolvimento ou interfere em sua qualidade
(Soares, 2011).
Ora, se as empresas so dinmicas, e cada vez mais, por motivos externos como
demanda do cliente; se a cultura organizacional ponto de deciso na adoo de um
modelo; se os requisitos sero passiveis de alterao, refazer cdigo no pode ser uma
ao de impacto no custo. Com esse contexto de equipes pequenas e entregas rpidas
faz-se jus ao uso de metodologias geis, pois estas prezam pela auto gerencia das
equipes, com proteo do Scrum Master das interferncias externas (Soares, 2011).
Um carter de humanizao de criao de software pode ser mais um quesito
de adoo do modelo, pois Mangalaraj (2005) levam em considerao, alm da cultura
organizacional, fundamentais valores como o comprometimento, a confiana e o
respeito, sem contar a capacidade dos integrantes para a habilidade de trabalho em
equipe.
Projetos se diferenciam quanto ao tamanho da empresa, que quanto maior, maior
ser a abrangncia e diversidade, seja com relao ao tamanho do projeto, dos
requisitos, do seu escopo, dos seus custos e seus prazos. Os projetos, de grandes escalas
exigem no modelo tradicional uma estafante documentao e diversos artefatos. O
modelo gil aparece com uma soluo, porem um erro achar que ser gil ser
informal (Soares, 2011).
4.2. O Scrum
um framework estrutural que est sendo usado para gerenciar o desenvolvimento de
produtos complexos desde o incio dos anos 90. Scrum no um processo ou uma
tcnica para construir produtos, em vez disso, um framework dentro do qual voc pode
empregar vrios processos ou tcnicas. Ele deixa clara a eficcia relativa das prticas de
gerenciamento e desenvolvimento de produtos, de modo que voc possa melhor-las
(Schwaber, 2011).
Os pilares que apoiam a implementao do controle do processo no Scrum so:
transparncia, inspeo e adaptao. Sob estes trs pilares so disponibilizados papis,
eventos e artefatos que auxiliam seu uso. Seguem os principais componentes de acordo
com o Guia Do Scrum, 2011. Os papis so: Time Scrum, que composto Product
Owner, a Equipe de Desenvolvimento e o Scrum Master. Os eventos so: Reunio de
Planejamento da Sprint, Sprint, Reunio Diria, Reviso da Sprint. Os artefatos so:
Backlog do Produto, Backlog da Sprint e Incremento.



No quesito de organizao das empresas, um grande problema o
dimensionamento de horas de trabalho. Em projetos grandes, de 200 dias, por exemplo,
haver muito mais dificuldade de se planejar efetivamente do que em projetos de 20
dias. Como as metodologias geis preveem entregas semanais, quinzenais ou mensais, o
planejamento ser mais fcil de ser executado e um item como gasto com horas
extras, que encarecem muito um projeto, pode ser mitigado. (Soares, 2011) tambm
refora esta ideia em: "a XP assume que no se devem fazer horas extras
constantemente. Caso seja necessrio trabalhar mais de 40 horas pela segunda semana
consecutiva, existe um problema srio no projeto que deve ser resolvido no com
aumento de horas trabalhadas, mas com melhor planejamento, por exemplo. Esta prtica
procura ratificar o foco nas pessoas e no em processos e planejamentos. Caso seja
necessrio, os planos devem ser alterados, ao invs de sobrecarregar as pessoas."
Este enredo pode ser complementado pelo nico entregvel ao final do projeto
de mtodos tradicionais, que muito distante da etapa inicial, geralmente no atende
expectativa do cliente, e retornar equipe com um lamentvel: No foi isso que eu
pedi!. Quando h entregas frequentes o risco de isso ocorrer tende a zero, pois h um
feedback a cada entrega, facilitando uma convergncia em caso de necessidade. Para
prevenir a degradao da qualidade devido entregas muito curtas, d-se alta nfase a
testes do produto ao longo do ciclo de vida. Mtodos geis requerem testes de
integrao ao longo do processo de desenvolvimento. Automao dos testes
importante para que as builds dirias passem por testes de regresso." (Abrantes e
Travassos, 2011).
A Version One Inc., empresa americana que desenvolve ferramentas de apoio
aos mtodos geis, realiza anualmente pesquisa sobre o status dos mtodos geis
naquele cenrio. Em sua 7 verso, de 2013 (Version One, 2013) apresenta o uso do
framework Scrum por 54% das empresas relacionadas.
Analisando a sries de pesquisas iniciada no ano de 2007 (Version One, 2007),
notamos um crescente aumento no uso do framework Scrum. Na primeira pesquisa 40%
das empresas pesquisadas citavam utiliz-lo, esse nmero cresce para 58% na 5
pesquisa da srie divulgada em 2010 (Version One, 2010), com uma pequena retrao
para 52% no ano de 2011 (Version One, 2011). A Figura 1 ilustra o uso do Scrum ao
longo dos anos.

Figura 1 - Uso do Scrum
Notamos tambm uma significativa reduo do uso Scrum aliado ao XP, o qual
foi citado pela primeira vez na 2 edio das pesquisas (Version One, 2007),
apresentando um percentual de 23.3% de uso entre as empresas pesquisadas. Esse valor
foi reduzido para apenas 11% na pesquisa divulgada no ano de 2013. Esses nmeros
acompanham a reduo do uso do XP isolado, o qual apontou uma reduo de 21
nmeros percentuais nas 7 edies divulgadas, caindo de 23% para 2% ao longo de 7



anos (Version One, 2013).
Em 2010 notamos o surgimento de uma nova metodologia gil, denominada
Scrumban (Version One, 2010), o termo surgiu em um paper escrito por Ladas (2008),
o qual gerou um livro no ano seguinte intitulado Scrumban - Essays on Kanban
Systems for Lean Software Development (Ladas C., 2009). Esse mtodo sugere uma
unio do tradicional sistema Kanban com o framework Scrum, e segundo as pesquisas
da Version One seu uso entre as empresas tem crescido constantemente, passando de
3% em 2010 para 7% em 2012.
Considerando o uso de Scrum, Scrum/XP hbridos e Scrumban, em 2013, 72%
das empresas pesquisadas pela Version One usavam o framework Scrum de alguma
maneira. Esse nmero cresceu 32% nos 7 anos que a pesquisa realizada.
Um termo muito utilizado atualmente Global Software Development (GSD)
que remete ao desenvolvimento de software em empresas que possuem equipes situadas
em ambiente geograficamente distintos, formando um ambiente distribudo. Isso tem
colocado prova muitas metodologias e frameworks, que na maioria das vezes no so
estruturados para esse tipo de ambiente. Sendo o Scrum um framework com muitas
interaes pessoais, como nas Planning Meetings, um dos seus usos pouco provveis
seria neste tipo de ambiente. Um exemplo interessante deste uso o do artigo publicado
por Raty et al. (2013) resultado de uma parceria entre as Universidades Aalto
(Finlndia) e de Victoria (Canad), onde foi submetido um projeto de 3 meses que
envolvia 25 participantes distribudos nas duas universidades. Apesar dos resultados no
serem conclusivos, verificou-se a capacidade de adaptao do Scrum e como os
participantes assimilaram seu uso com o passar do tempo.
Em contrapartida ao resultado da Universidade Aalto, um estudo desenvolvido
por Paasivaara et al (2008) aponta uma srie de desafios encontrados em projetos GSD
com Scrum, como por exemplo, problemas de comunicao, falta de proximidade fsica,
falta de coeso no time, falta de compartilhamento de conhecimento e indisponibilidade
dos membros. Tambm apontam algumas prticas para lutar contra esses limitadores,
tais como utilizar visitas frequentes para manter o relacionamento entre os membros das
equipes distribudas, adoes de ferramentas e tecnologias, como videoconferncias, e-
mails, mensagens instantneas, teleconferncia, recursos estes necessrios para suprir a
efetiva utilizao do Scrum.
No artigo de Hossain, Babar e Paik (2009) feita uma reviso de literatura sobre
o GSD usando Scrum, objetivando tambm elucidar suas limitaes neste contexto.
Apesar de haver muita literatura reportando os problemas encontrados neste cenrio,
poucas so efetivas para explicar quais as melhores prticas nestes ambientes.
Os autores enfatizam o uso de gil neste tipo de projeto pela ampla colaborao
entre clientes e desenvolvedores, sendo os principais desafios: o estreitamento entre e a
equipe e a baixa frequncia de reunies de equipes distantes, mesmo assim vrios casos
de sucesso foram encontrados, apesar da citao de especialistas de que essa discusso
ainda imatura. O uso do Scrum para estes projetos foi justificado por ser o mais
difundido.
Paasivaara (2008) afirma que projetos distribudos com requisitos incertos
podem usar praticas geis para sua viabilizao. Apesar de Scrum ser eficaz para
projetos muito pequenos, Sutherland e Schwaber (2010) argumentam que Scrum podem
ser utilizado em equipes distribudas. O autor apresenta os riscos que restringem o uso
do Scrum e as contingncias adotadas, que em suma seriam: distncia temporal e
geogrfica, diferenas socioculturais e problemas de comunicao. Especificando mais,
as limitaes so de: ausncia de salas e horrios especficos para reunies, problemas
para planejar os sprints, reunies longas, sincronia de reunies, lnguas diferentes, etc.
As estratgias de mitigao, segundo Hossain et al (2009) so: sincronizar a



comunicao e a hora de trabalho, limitar tempo em reunies, planejar perguntas Scrum
previamente, equipes locais com reunies prprias, mediao para reunies entre as
equipes, equipes locais autnomas e independendo de arquitetura, modificaes do
modelo Scrum, criando um mini Scrum aps reunies, tempo determinado para
responder e-mails, membros chave para participar de reunio, reunies duas vezes na
semana ao invs de diariamente, reunies assncronas, visitas e intercmbios,
documentao atualizada, participao obrigatria, criao de subequipes, salas
individualizadas, entre outras prticas.
Assim como ocorre com ambientes de desenvolvimento distribudo, muitos
outros projetos possuem caractersticas e peculiaridades intrnsecas do projeto/empresa
e da equipe que o executa. Tais caractersticas, muitas vezes no mapeadas ou
explicitadas pelo framework Scrum, tornam seu uso um grande desafio, como citado por
Strauhs (2013). Nesse artigo, a autora realizou um estudo de caso de uso do Scrum em
uma grande empresa e atravs de uma lista de componentes que o formam, e elaborou
uma entrevista no formato Focus Group. Ela dividiu as prticas ditadas e as organizou
em dois nveis: critico ou no crtico. Entre as prticas listadas, cita-se: Correto uso de
mecanismos de testes e integrao, colocada como crtica, mas que os entrevistados
disseram no ter adotado, justificando assim: Data de entrega do produto arrojada e
Atividade montona.
Os pesquisadores Turk, France e Rumpe (2000) demonstram algumas outras
limitaes do uso de prticas geis e como isso diminui o nvel de aderncia da
metodologia em determinados projetos. Citamos aqui 6 limitadores do uso do Scrum:
desenvolvimento em ambiente distribudos; subcontrataes; construo de artefatos
reutilizveis; grandes times; softwares de segurana crtica e softwares grandes e
complexos;
Especificamente sobre a limitao quanto ao desenvolvimento de softwares
grandes e complexos, o Guia do Scrum se contrape citao do artigo, apontando o
Scrum como um framework para desenvolver e manter produtos complexos.
As anlises realizadas por Turk, France e Rumpe (2000) foram baseadas em XP,
Scrum, Agile Unified Process, Agile Modeling e os princpios estabelecidos pela Agile
Alliance. As concluses foram que a maioria dos processos prticos de desenvolvimento
de software possuem partes dos processos previsveis, nos quais os passos podem ser
definidos no incio do projeto e os objetivos do projeto se mantm relativamente
estveis ao longo do projeto, processos nos quais seriam melhores cobertos por
metodologias tradicionais.
Mann e Maurer (2005) realizaram um estudo de mais de 2 anos, com vrios
clientes e uma equipe de 7 desenvolvedores, em sua maioria situados no mesmo
prdio/andar. Os resultados demonstram grande aceitao do uso do Scrum pela equipe
e clientes, mas algumas observaes suscitaram em discusses, tais como: falta de
preparao do cliente para a adoo do Scrum ou falta de contato com o cliente durante
a sprint, para esclarecimentos
Projetos cientficos como o relatado por Berni et al (2009), apontam bons
resultados com o uso de metodologias geis, e sendo desenvolvido em um ambiente
controlado e com grande flexibilidade de mudanas de escopo, resultou positivamente
com Scrum. Algumas das citaes remetem s boas qualidades dos mtodos geis:
remoo da burocracia, flexibilidade e adaptao, fatores que tm inferncia direta no
aumento da produtividade.
Muitos entusiastas tm adotado mtodos hbridos combinando um ou mais
mtodos em conjunto com o framework. Moster (2013) realizou um projeto para a
Guarda Costeira Americana (USCG), que adotava um processo de desenvolvimento
chamado SDLC (Systems Development Life Cycle) baseado no modelo waterfall. Aps
algumas mudanas no processo foi possvel chegar a uma metodologia intermediaria e



alar resultados satisfatrios, mantendo o processo exigido pela USCG e utilizando
caractersticas do Scrum.
Experincia similar foi presenciada no artigo de Bashir e Qureshi (2012) no qual
os pesquisadores alcanaram bons resultados, mantendo o cronograma em dia, suprindo
as expectativas do cliente e aumentando a produtividade da equipe de desenvolvedores.
A proposta da metodologia se baseia em utilizar as caractersticas administrativas do
Scrum, como cerimoniais, papis e artefatos; em conjunto com os esqueletos, estruturas
e formalizaes SDLC oferecidos pelo RUP, tudo isso aliado filosofia do XP.
Sutherland et al. (2007b) realizaram um caso de estudo com 56 desenvolvedores
entre 3 cidades. O artigo analisa e recomenda prticas para times Agile distribudos
globalmente com subcontratao, com timos resultados. Neste caso foi adotada uma
prtica Scrum of Scrum. E deixa claro que o time subcontratado deve ser gil,
qualificado e integrado ao time principal. Ademais, faz meno hiper produtividade
com Scrum devido a 3 pilares: o Scrum em si, com reunies dirias e curtas; equipe
estimulada e rpida, e por fim o uso do XP. Com relao ao XP, os autores citam
projetos que aderiram ao XP com Scrum, pois o Scrum isoladamente no atendera s
expectativas.
Abrahamsson et al (2003) realiza um paralelo entre mtodos de desenvolvimento
gil baseado em 5 lentes analticas: Ciclos do desenvolvimento de Software,
Gerenciamento de Projeto, Princpios abstratos versus Direcionamento Completo,
Universalidade pr-definida versus Situao apropriada e Evidncia emprica. O
resultado apresentado na Figura 2, na qual so demonstradas as fases do ciclo de vida
do software que no so suportados pelo Scrum, sendo elas: Incio do Projeto,
Aceitao dos testes e Uso do Sistema (i.e. Manuteno). Tambm so apresentadas
quais fases o Scrum necessita de Descrio do Processo e Orientao Satisfatria, so
eles: Design, Cdigo e Testes unitrios.

Figura 2 - Fases no suportadas pelo Scrum
No artigo Framework for Agile Methods Classification (Iacovelli e Souveyet,
2008) foi realizada a classificao do impacto dos mtodos geis sobre processo de
engenharia de requisitos. Da citao "Atividades Contempladas pelo Mtodo", os
seguintes itens no foram cobertos pelo Scrum: Iniciao do Projeto, Teste de
Aceitao, Controle de Qualidade. Dos Nveis de Abstrao avaliados, o Scrum no
cobre: Descrio do Processo, Regras Concretas e Guia de Atividades e Produtos. Dos



Produtos das Atividades dos Mtodos o Scrum no contemplou: Teste de Aceitao,
Relatrio de Qualidade, Documentao do Usurio.
Outro modelo hbrido de uso do Scrum apresentado no artigo de Mushtaq e
Qureshi (2012) onde o XP assume as prticas de engenharia, e o Scrum as prticas de
gesto. Segundo o texto, XP e Scrum so ineficientes em reas opostas, e os autores
recomendaram esta combinao para projetos simples e pequenos, sendo seu uso
qualificado como indispensvel para prover um produto de qualidade e de valor para
o cliente. A pesquisa sugere a criao de um novo framework, para atender aos
propsitos citados, sendo este uma verso derivada e expressa do Scrum, testado atravs
de um estudo de caso. O uso do XP foi escolhido para ser utilizado com Scrum
(apresentado como o melhor modelo para gerenciamento) para prover maior qualidade e
satisfao dos stakeholders.
Mushtaq e Qureshi (2012) apontam: Scrum omisso em se tratando de
engenharia de software e exige equipe altamente capacitada para funcionar, j o XP
carente de prticas de gerenciamento de projetos, depende totalmente do cliente e no
adequado para projetos de mdio e grande porte. Com base nessas deficincias
apontadas, onde um modelo praticamente complementa o outro, explanada uma
necessidade desesperada de integrao mtua das prticas de gesto, e de engenharia
de respectivos os modelos. A concluso da pesquisa aponta para a criao de modelo
hbrido, aproveitando das potencialidades de Scrum e XP para suprir as deficincias de
ambos.
Outro caso de integrao o apresentado por Sutherland et al (2007) que
descrevem uma valiosa experincia na utilizao de Scrum com CMMI 5, afirmando
que juntos trazem uma poderosa combinao para o mercado de software, justificando
que clientes cada vez mais querem solues mais rpidas, melhores e mais rentveis e
coloca o CMMI como um processo que d disciplina ao Scrum, aumentando sua
adaptabilidade. O artigo demonstra que as reas do CMMI relacionadas gesto de
projetos podem ser tratadas com Scrum, assim como as reas relacionadas engenharia
podem ser abordadas com XP. Este uso apontado como uma mgica emergente,
pois Scrum garante a eficincia da implantao dos processos, enquanto CMMI garante
que todos os processos relevantes sejam considerados.
O paper posiciona Scrum como um reparador do CMMI, pelo seguinte:
CMMI reverencia processos e ignora pessoas, enquanto Scrum as prioriza; CMMI no
foca em problemas, enquanto a funo do Scrum Master gerir um rol de
impedimentos; CMMI ignora a qualidade, j o Product Owner corrobora continuamente
para agregar qualidade ao produto; CMMI subjuga o contexto organizacional enquanto
Scrum o prioriza e por fim, CMMI foca na eficincia interna enquanto Scrum foca na
entrega de valor de negcio.
A concluso do estudo, que a escolha do Scrum para se aliar ao CMMI foi pelo
fato de ele ter excelente ROI (return of investiment), reduzindo as etapas de
Desenvolvimento em at 50%, e deixa a recomendao de utilizao do CMMI para
potencializar os benefcios dos mtodos geis, conforme Figura 3.




Figura 3 - Comparao entre nveis do CMMI e do CMMI hbrido.
5. Discusso
A seguir so descritos e explanados os resultados encontrados atravs da anlise da
bibliografia pesquisada. Ser discutida agora a questo foco de nossa pesquisa: Ser o
Scrum suficiente para o gerenciamento das atividades de desenvolvimento de
software?. Com base nos dados pesquisados seguem as consideraes:
Antes da abordagem dos casos analisados, faz-se necessria a retomada do
conceito e diferenciao entre framework e metodologia. Scrum um framework, que
por definio deve ser imutvel, de acordo com Schwaber um de seus criadores. Casos
demonstram que ele d cobertura s prticas voltadas ao gerenciamento e no
engenharia do projeto, esta seria funo de uma metodologia. Por definio metodologia
aponta o que e como fazer, mas Scrum se limita a dizer o que fazer, o que gera
muita confuso. Ele considerado bom porqu fcil de usar, auto gerencivel, no
burocrtico e adaptvel a diversas necessidades. Seu objetivo servir de estrutura,
sendo assim, nos deixa claro que necessita do complemento de uma metodologia ou
modelo, estas sim preveem prticas e orientaes claras.
No que tange a sua aderncia, observa-se que mesmo no sendo to completo
como uma metodologia, ele cumpre de forma excelente ao que se prope: entregar de
forma incremental, focado na humanizao do desenvolvimento, um produto com
participao ativa do cliente, agregando qualidade, otimizando recursos de forma
rpida. Tudo isso pode ser melhorado utilizando outras tcnicas, haja vista a vasta
bibliografia de seu uso aliado a XP, CMMI, Kanban, entre outros. Sua misso de se
opor ao conceito engessado dos mtodos tradicionais, que tratam de requisitos estveis e
previsveis notria, e isso potencializado com a sua utilizao hbrida. Scrum aceita
a necessidade latente das mudanas de requisitos no escopo do projeto ao invs de
ignor-las.
admissvel que existam empecilhos para o uso do Scrum, pois h de ser
respeitado o rol de suas premissas. Uma delas seria a presena frequente do cliente, que
para sua eficcia imprescindvel.
Alguns estudos dizem que ele mais adequado a projetos pequenos, outros
dizem o contrrio. O fato que a virtude de se flexibilizar permite seu uso em micro
empresas, projetos grandes, complexos e tambm distribudos, pois ele admite o uso de
recursos adicionais para suprir as diferentes necessidades de diversos tipos de projetos



agregando valor ao gerenciamento do desenvolvimento.
O Scrum se mantm nos ltimos anos entre um dos frameworks geis mais
utilizados para desenvolvimento de software, e como foi visto nas pesquisas descritas da
Version One, sua hegemonia mantida com o auxlio de outros frameworks e
metodologias. Equipes tm criado novos mtodos hbridos, entre Scrum e outras
metodologias geis ou tradicionais, evidenciando carncias inerentes ao Scrum. Surgem
at novas tecnologias em funo disso, como o Scrumban. Quanto mais ele difundido,
mas fica evidente a sua necessidade de combinao para a sua aplicao eficaz. Para
ilustrar, a mesma pesquisa, analisada ao longo dos ltimos anos destaca que o Scrum
hibrido aumentou em mais de 30%.
Casos citados por Bern et al (2009) confirmam que as metodologias geis so
flexveis e sem burocracias, permitindo aumento de produtividade, pois em ambiente
controlado e com flexibilidade de escopo foram obtidos resultados satisfatrios.
Em ambientes distribudos h vrios casos de sucesso como o de Sutherland
(2007), onde constatou-se timos resultados desde que a equipe seja experiente em
geis e que sejam utilizadas prticas complementares, neste caso o Scrum of Scrum.
Isso demonstra o quanto o framework possui flexibilidade, mas tambm deixa explcito
que fatores como formar uma equipe experiente e utilizar tcnicas complementares
foram fundamentais. Paasivaara et al (2008) confirma isso quando observaram um
melhor desempenho do Scrum com o passar do tempo, e destacaram que o uso de
ferramentas tecnolgicas suprem alguns limitadores, deixando claro que o Scrum no
totalmente suficiente, ideia esta endossada por Sutherland. Outros autores como
Hossain, Babar e Paik (2009) tambm afirmam que h necessidade de adaptao do
framework para seu pleno funcionamento em ambientes distribudos, e como esta
adaptao pode ser vista como um complemento.
Sobre os ambientes distribudos, fica claro que mesmo com a complexidade, e os
pontos de problemas tpicos tais como distncias geogrficas, lnguas diferentes,
dificuldades em se estabelecer reunies, utilizao dos artefatos, todos desfavorveis de
certa forma ao uso do Scrum ele ainda aplicvel, ainda que adaptado. Mas em vrios
os casos foi observado uma tecnologia para auxiliar, ou algum recurso complementar
para mitigar os problemas. Scrum bom e adaptvel havendo muitos registros do seu
uso em GSD, no entanto, refora-se que existem problemas nas empresas que no o
Scrum quem diz como resolver. O determinante para usar Scrum neste contexto so
suas caractersticas de tratar a incerteza e ser focado nas atividades dos projetos.
Outro ponto a ser discutido o das funes e questes ligadas s equipes e
pessoas, onde o relato de Mann e Maurer (2005) deixa claro que precisa haver preparo e
principalmente disponibilidade do cliente nos sprints do projeto Scrum. Strauhs (2013)
confirma esse ponto relatando casos em seus estudos em que alguns participantes do
time Scrum de forma deliberada resolveram no cumprir com algumas etapas do
processo de desenvolvimentos, por a taxarem de montonas. Ademais, Strauhs (2013)
apresenta uma classificao dos itens que compem o Scrum citando itens classificados
como crticos e que podem interferir completamente na aderncia do Scrum, mas
mesmo assim no so realizados. A utilizao do Scrum exige pessoas comprometidas,
equipe capacitada e dedicada, pois a utilizao de uma metodologia complementar para
obteno de bons resultados exigir muito mais dessa equipe, e o conceito de teamwork
do time Scrum deve estar bem enfatizado, delegando funes s pessoas de
competncias compatveis.
Sobre os limitadores de uso do Scrum que foram estudados e elencados como
sendo alguns dos pontos que podem comprometer sua aderncia, eles so controversos.
Alguns deles seriam: uso em ambiente distribudo, que outros casos mostraram que
podem ser mitigados; as subcontrataes - j apresentadas como possveis em outro
caso; reutilizao de artefatos; grandes times, demonstrando que os Teams podem ser



adaptados, criando pequenos grupos Scrum; Projetos de segurana crtica, grandes e
complexos. Especificamente sobre o ltimo item o prprio Guia do Scrum cita Scrum
como propcio para projetos grandes e complexos. As limitaes podem ter sido
relacionadas de um projeto especfico em no endossam e nem vo contra as demais
literaturas de aderncia do Scrum neste artigo.
Existem bibliografias cujo objetivo detalhar quais so as partes do ciclo de
vida do projeto de software que no so cobertas pelo Scrum. Essa deficincia foi
identificada e citada por Abrahamsson et al (2003) como sendo: Incio do Projeto,
Aceitao dos Testes e Uso do Sistema (i.e. Manuteno) como sendo etapas totalmente
ausente no processo de uso do Scrum. Ademais, o autor aponta outras fases na quais o
Scrum insuficiente em Descrio do Processo e Orientao, so eles: Design, Cdigo,
Testes unitrio, deixando bvias necessidades de complementao por outras tcnicas.
Levando em conta estes aspectos, fica claro compreender como o Scrum no
suficiente para todas as etapas de construo de um software. Ilustrativamente, na etapa
Incio de Projeto, o RUP muito utilizado e estabelece diretrizes bem claras de como
isso deve ser feito. Scrum no est voltado para engenharia ou arquitetura, bem como
para reas supracitadas, e neste panorama, caso ele no de cobertura em todas as etapas,
ele pode ser rotulado como insuficiente.
Quando existe a necessidade de ser complementado, e de serem analisadas as
limitaes, os artigos de utilizao hbrida ou integrada do Scrum podem demonstrar
claramente que ele aderente ao gerenciamento de atividades do projeto, enfatizando
que Scrum suficiente no seu escopo, no entanto carece de tecnologias/metodologias
para atender reas que no so de sua competncia (design, testes, manuteno) e as
bibliografias demonstram de forma objetiva quais so as limitaes e de que reas, e por
que determinada tecnologia foi utilizada como complemento.
H casos de uso do Scrum combinados que resultaram na criao de novos
mtodos, como por exemplo, o Scrumban e o Scrum of Scrum. Isso so resultados de
adaptaes necessrias que se fizeram por conta de alguma carncia para se gerenciar o
projeto como um todo, comprovando a insuficincia, conforme o ponto de vista que se
analisa. Algumas pesquisas de mtodos prprios combinados com Scrum tm o mesmo
propsito de se otimizar resultados, como cita Emil Moster, 2013. Neste caso o mtodo
proprietrio era baseado em waterfall, comprovando toda maleabilidade do Scrum.
Um caso que deixa explcito as competncias de cada um o relato do Bashir e
Qureshi (2012) onde Scrum usado com RUP e XP. A combinao tratada de forma
que Scrum usado como estrutura administrativa e RUP como esqueleto e
formalizao, aliados filosofia do XP. Esta aplicao explica que metodologias e
modelos tratam do processo e no cuidam da gesto. Fica bvia a capacidade do Scrum
de se reinventar a cada necessidade. Em um de seus estudos, Sutherland conclui que
Scrum obteve hiper produtividade graas ao uso dos processos do XP, reforando esta
necessidade de integrao.
Existem mais menes de uso de Scrum com XP, como por exemplo dos autores
Mushtaq e Qureshi (2012), onde fica muito objetivo as deficincias de ambos pois
Scrum assumiu as prticas de gesto e XP as prticas de engenharia com a justificativa
que ambos so ineficientes em reas opostas. Esta pesquisa sugeriu a criao de um
novo framework, um derivado de Scrum e XP, o que sugere que de fato h esta
necessidade e esta parece ser uma parceria bastante promissora para gerenciamento.
Como ltima citao de utilizao hbrida cita-se um estudo de Scrum com
CMMI5, no menos interessante e eficiente que as apresentadas. Alis, o artigo chama
de mgica esta combinao. Cita que CMMI pode disciplinar melhor o Scrum em reas
de gesto, bem como pode fazer o mesmo com XP no aspecto da engenharia,
solidificando o que foi apresentado no pargrafo anterior. Nesse caso a nfase maior
no CMMI, e o Scrum colocado como agente reparador, pois trabalha exatamente os



aspectos que o CMMI falha, revelando assim mais uma bela faceta deste framework que
o Scrum, que poderia ser chamado de SScrum - Super Scrum!
6. Concluso
Para concluir este artigo, utilizamo-nos das hipteses construdas em etapa anterior
pesquisa, que foi construda atravs da leitura de 53 estudos para poder validar as
vertentes de conhecimento levantadas. A pesquisa no objetiva esgotar o tema, e sim
direcionar futuros estudos, aprofundando as teorias. As seguintes concluses esto
dispostas em face aos objetivos especficos apresentados:
6.1. Consideraes
Ser o Scrum suficiente? Sim! Porm, enquanto framework para gerenciar atividades de
projeto e no como nico modelo nem metodologia para gerenciar todos os ciclos de
desenvolvimento de software. Scrum mostrou-se suficiente quando aplicado
exclusivamente para atuar em pequenos projetos e com pequenas equipes. Em
ambientes que fujam desse padro como em grandes projetos e equipes,
desenvolvimento distribudo e projetos sem participao do cliente, existe a necessidade
de adaptao e complemento;
Scrum no diz como fazer e sim o que fazer, dando liberdade equipe para
que se seja faa o que melhor funcionar dentro das necessidades. Como ele no aponta
claramente como os procedimentos deve ser executados, a utilizao de metodologias
auxiliares novamente se mostram positivas;
Ainda que a utilizao de Scrum apresente vrios relatos de sucesso,
conseguimos identificar que existem limitaes no uso do framework que
comprometem sua aderncia. Foi sempre atravs do uso de outras tecnologias ou
tcnicas que isso foi superado;
Dos pontos positivos observados, os mais fortes so: sua facilidade de
compreenso, implantao e flexibilidade de adaptao. Dos pontos negativos,
destacam-se: no cobertura de determinadas fases do projeto, falta de definies em
como fazer determinados artefatos;
Observamos que nem todas as regras Scrum so respeitadas, tais como tamanho
da equipe, utilizao de desenvolvedores Seniors e Product Owner bem capacitado e
disponvel.
H grande incidncia de referncias do uso do Scrum com XP, e em todos os
casos ficou claro que ambos se complementam naturalmente, pois um se encaixa
exatamente na limitao do outro, havendo neste modelo hbrido o melhor desempenho
do Scrum. As diversas pesquisas de uso hibrido do Scrum para compensar suas falhas
deixam claro que ele no suficiente.
6.2. Trabalhos futuros
Atravs dos estudos realizados, conclumos que o Scrum no suficiente para gerenciar
projetos, pois no cobre todas as necessidades de desenvolvimento e ciclo de vida de
software, se atendo mais a aspectos de gerenciamento das atividades, e sem cobertura
para reas relacionadas engenharia.
Como trabalhos futuros podemos sugerir a criao de um novo framework a
partir do refinamento desta pesquisa, que seja, por exemplo, um merge do Scrum e XP,
por ser a integrao mais citada nesta pesquisa, pois ambos se complementam
perfeitamente.
Entendemos ainda que pode ser criada uma mtrica para avaliao da aderncia



do Scrum com outras tecnologias, haja visto que j ficou claro seu papel em
determinada fase do projeto, e mais claro ainda que precisa de complemento para a
plenitude de gerenciamento de etapas de um software. Esta mtrica possibilitaria
ponderar de forma quantitativa o nvel de aderncia que foi observado.
7. Referncias Bibliogrficas
Abbas, N., Gravell, A. M., Wills G. B., (2008) Historical roots of Agile methods:
where did Agile thinking come from?. Em Agile Processes and eXtreme
programming in Software Engineering, Limerick, IE, 10 - 14.
Abrahamsson, P., Warsta, J., Siponen, M. T., Ronkainen, J., New Directions on Agile
Methods: A Comparative Analysis. Em IEEE Proceedings of the International
Conference on Software Engineering, May 3-5, 2003.
Abrantes, J. F., Travassos, G. H., (2011) Caracterizao de Mtodos geis de
Desenvolvimento de Software. Em
http://reuse.cos.ufrj.br/wdra2007/images/artigos/30188.pdf, Fevereiro de 2014.
Aydin, M. N.; Harmsen, F.; Slooten, K. Van; Stegwee, R. A., (2004) An Agile
Information Systems Development Method in Use. Em Turk J Elec Engin, Vol.12,
P. 127-138.
Bashir, M. S., Qureshi M. R. J. (2012) Hybrid Software Development Approach for
Small to Medium Scale Projects: RUP, XP & Scrum. Em Sci.Int.(Lahore), ISSN
1013-5316.
Beck, K., Andres C., (2004) Extreme Programming Explained: Enbrance Change (2nd
Edition). Em Addison-Wesley Professional 2004, ISBN 0321278658.
Berni, J. C. A. ; D'ornellas, M. C. ; Ferreira, T. K., (2009) Produo de Software
Cientfico Atravs de Metodologias geis na Microempresa. In: XXIX Encontro
Nacional de Engenharia de Produo (ENEGEP), 2009, Salvador-BA. Anais do
XXIX Encontro Nacional de Engenharia de Produo (ENEGEP). Rio de Janeiro -
RJ : Editora da ABEPRO, 2009.
Booch, G.; Rumbaugh, J.; Jacobson, I. (1998) The Unified Modeling Language User
Guide. Em Addison Wesley First Edition October 20, 1998 ISBN: 0-201-57168-4,
512.
Carvalho B. V., Mello C. H. P., (2006) Reviso, Anlise e Classificao da Literatura
Sobre o Mtodo de Desenvolvimento de Produtos gil Scrum. So Paulo: Anais do
XII Simpsio de Administrao da Produo,Logstica e Operaes Internacionais -
SIMPOI.
Castillo M. A. R., Souza E. G. de,. (2013) A Comparative Analysis of the Traditional
Model (waterfall) for Systems Development Project Management and the agile
Model in Software Factories. Em 10th International Conference on Information
Systems and Technology Management.
CMMI for Development, Version 1.2, (2013). Em Software Engineering Process
Management Program, Carneige Mellon.
Cohn, M., (2007) Advice on Conducting the Scrum of Scrums Meeting, on
http://www.scrumalliance.org/. Em Fevereiro de 2014.
Dyba, T., Dingsoyr, T. (2008) Empirical studies of agile software development: A
systematic review. Em http://alarcos.inf-
cr.uclm.es/doc/MetoTecInfInf/Articulos/dyba.pdf.
Fowler, M., Highsmith, J. (2001) The Agile Manifesto. Em Software Development -
pmp-projects.org.



Guantamukkala, V., Wen, H. J., TARN, J.M., (2006) An empirical study of selecting
software development life cycle models. Em Human System Management, v .25, n.
4 p. 265-278.
Hossain, E., Babar, M, A., Paik, H. (2009) Using Scrum in Global Software
Development: A Systematic Literature Review, Em Global Software Engineering,
2009. Fourth IEEE International Conference, p 175 - 184.
Iacovelli A. e Souveyet C., (2008) Framework for Agile Methods Classification. Em
Universit Paris 1 - Panthon Sorbonne.
Kane, D. W., Hohman M. M., Cerami E. G., Mccormick M. W., Kuhlmman K. F., Byrd
J. A., (2006) Agile methods in biomedical software development: a multi-site
experience report. Em
http://download.springer.com/static/pdf/928/art%253A10.1186%252F1471-2105-7-
273.pdf?auth66=1380571209_825f5a36e9bb9ceea0dd90f99531a3df&ext=.pdf,
Setembro de 2013.
Kruchten, P. (2003) The Rational Unified Process: An Introduction 3 ed. Em
Massachusetts: Addison-Wesley, ISBN 0321197704.
Ladas, C., (2009) Scrumban - Essays on Kanban Systems for Lean Software
Development. Modus Cooperandi Press. ISBN: 0578002140.
Larman, C. Basilli, V. (2003) Iterative and Incremental Development: A Brief
History. Em IEEE Computer Society p.47-76, ISSN 0018-9162.
Mann, C., Maurer, F. (2005) A case study on the impact of Scrum on overtime and
customer satisfaction. Em
http://ase.cpsc.ucalgary.ca/uploads/Publications/MannMaurerAU2005.pdf. Janeiro
de 2014.
Meirelles, F. S., (2013) 24 Pesquisa Anual do Uso de TI. Em Fundao Getlio
Vargas.
Ministrio do Planejamento, Oramento e Gesto, (2013) Oramentos da Unio
Projeto de Lei Oramentria Exerccio Financeiro 2014. Em Depsito Legal na
Biblioteca Nacional.
Moster, E., (2013) Using Hybrd Scrum to Meet Waterfall Process Deliverables. Em
http://thescholarship.ecu.edu/bitstream/handle/10342/1756/Moster_ecu_0600M_109
34.pdf?sequence=1. Maro de 2013.
Mushtaq, Z., Qureshi, M. R. J., (2012) Novel Hybrid Model: Integrating Scrum and
XP. Em I.J. Information Technology and Computer Science 6, p 39-44.
Nonaka, I., Takeuchi, H., (1986) The new new product development game. Em
Journal of Havard Business Review, p.137-146, Boston: v. 64.
Paasivaara M., Durasiewicz S., Lassenius C., (2008) Using Scrum in a Globally
Distributed Project: A Case Study. Em Software Business and Engineering Institute,
Helsinki University of Technology, FIN-02015 TKK, Finland. In Softw. Process
Improve. Pract. 2008; 13: p 527544.
PMI - Project Management Institute. (2004) A Guide to the Project Management Body
of Knowledge (PMBoK). 3. ed.. Newtown Square: Project Management Institute
Inc.
Pressman, R. S., (2010) Engenharia de Software 7 ed. So Paulo, Ed. McGrawHill.
Raty, P., Behm B., Dikert K., Paasivaara M., Lassenius C., e Damian D., (2013)
Communication Pratices in a Distributed Scrum Project. Em University of
Victoria, Victoria, BC, Canada.



Santos M., Rocha V., (2010) Modelo em Espiral. Em Universidade do Algarve
Faculdade de Cincia e Tecnologia Engenharia de Programao.
Schwaber, K, Beedle. M., (2002) Agile software development with Scrum. Em
Prentice Hall, ISBN-10 0130676349.
Schwaber, K., Sutherland, J., (2011) Guia Do Scrum. Em:
https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum%20Guide%2
0-%20Portuguese%20BR.pdf. Agosto de 2013.
Soares, M. dos S., (2004) Comparao entre Metodologias geis e Tradicionais para o
Desenvolvimento de Software. Em
http://www.dcc.ufla.br/infocomp/artigos/v3.2/art02.pdf, Acesso em 29 de fevereiro
de 2013.
Sommerville, Ian. (2007) Engenharia de Software 8 ed. Em So Paulo: Pearson
Addison Wesley ISBN 8588639289.
Strauhs, E. P., (2013) Limitadores e Solues de Contorno na Adoo de Prticas
geis do Mtodo Scrum em Projetos de Desenvolvimento de Software. Em:
http://www.bdtd.ucb.br/tede/tde_arquivos/3/TDE-2013-09-20T130436Z-
1661/Publico/Elizabete%20Proenca%20Strauhs.pdf. Dezembro de 2013.
Sutherland, J., Viktorov, A. , Blount, J. , Puntikov, N. (2007) Distributed Scrum: Agile
Project Management with Outsourced Development Teams. Em 40th Annual Hawaii
International Conference B.
Sutherland, J., Jakobsen, C. R., Johnson, K., (2007) Scrum and CMMI Level 5: The
Magic Potion for Code Warriors A. Em
http://systematic.com/media/282221/scrum_and_cmmi_level_5___the_magic_potion
_for_code_warriors.pdf. Dezembro de 2013.
Sutherland, J., Schwaber, K., (2010) The Scrum Papers: Nut, Bolts, and Origins of an
Agile Framework.Em
http://scruminc.com/tl_files/scrum_inc/documents/ScrumPapers.pdf. Setembro de
2013.
Technical Communication Summit, (2011), Sacramento Convention Center,
Sacramento, CA, US. Em STC's 58th Annual Conference.
Tomhave B. L., (2005) Alphabet Soup: Making Sense of Models, Frameworks, and
Methodologies. Em http://www.secureconsulting.net/Papers/Alphabet_Soup.pdf,
Outubro de 2013.
Turk, D., France, R., e Rumpe, B., (2000) Limitations of Agile Software Process,
Agile Alliance. Em
http://cf.agilealliance.org/articles/system/article/file/1096/file.pdf. Dezembro de
2013.
Version One, (2007) The state of agile development. Em
http://www.versionone.com/pdf/stateofAgiledevelopmentsurvey.pdf, Setembro de
2013
Version One, (2008) The state of agile development. Em
http://www.versionone.com/pdf/3rdannualstateofagile_fulldatareport.pdf, Setembro
de 2013.
Version One, (2009) The state of agile development. Em
http://www.versionone.com/pdf/2009_state_of_agile_development_survey_results.p
df, Setembro de 2013.
Version One, (2010) The state of agile development. Em
http://www.versionone.com/pdf/2010_State_of_Agile_Development_Survey_Result



s.pdf, Setembro de 2013.
Version One, (2011) The state of agile development. Em
http://www.versionone.com/pdf/2011_State_of_Agile_Development_Survey_Result
s.pdf, Setembro de 2013.
Version One, (2012) The state of agile development. Em
http://www.versionone.com/pdf/7th-Annual-State-of-Agile-Development-
Survey.pdf, Setembro de 2013.
Version One, (2013) 7th Annual State of Agile Development Survey. Em:
http://www.versionone.com/pdf/7th-Annual-State-of-Agile-Development-
Survey.pdf. Setembro de 2013.