VII Convibra Administrao Congresso Virtual Brasileiro de Administrao www.convibra.com.

br
Anlise da Aplicao de Mtodos geis na Gesto de
Projetos em Empresas Desenvolvedoras de Software
SandraLaisPedroso,LeonardoRochadeOliveira,JosIgncioJaeger
Resumo
O atual cenrio globalizado e competitivo do ambiente de negcios tm oferecido diversos
desafios gesto empresarial, com reflexo sobre a velocidade em desenvolver projetos para
melhorias nas diversas atividades de trabalho. Empresas desenvolvedoras de software se
inserem neste contexto, onde rege a necessidade de ser gil em relao ao atendimento das
demandas de seus clientes. Mtodos geis (MA) para gesto de projetos de software tm sido
indicados como alternativa para promover melhorias em diversos aspectos do processo de
desenvolvimento de software. O objetivo deste trabalho de analisar a aplicao de MA na
gesto de projetos de empresas desenvolvedoras de software. O trabalho apresenta uma
reviso de literatura em assuntos relacionados a MA para gesto de projetos, bem como uma
pesquisa exploratria e qualitativa elaborada com base em entrevistas a profissionais
envolvidos em projetos de desenvolvimento de software. A anlise de contedo das respostas
indica que as principais barreiras para adoo de MA so: a forma atual de relacionamento
entre clientes e empresas desenvolvedoras, bem como o desconhecimento sobre as vantagens
que podem ser obtidas. A pesquisa mostra que existe um reconhecimento das vantagens que
podem ser obtidas com o uso de MA, mas sugerido seu uso de forma a complementar os
mtodos tradicionais de gesto de projetos de software. As concluses do trabalho indicam
que MA ainda so pouco usados nas empresas estudadas, embora o valor de sua aplicao
seja reconhecido como potencial melhoria na gesto de projetos de software.
Palavras chave: Mtodos geis para gesto de projetos; Gesto de projetos de
desenvolvimento de software; Mtodos geis para gesto de projetos de software.

Abstract
The current globalized and competitive business market has offered many challenges to
managers and it includes the speed for developing corporative projects. Software development
companies are also facing challenges regarding the need to be agile on attending demands
from their clients. Agile methods (MA) for managing software development projects have
been suggested as an alternative to improve the relationship between software development
companies and their clients. This work aims at analyzing the application of MA for project
management in software development companies. To achieve this aim, a literature review was
carried out on issues related to agile methods for project management, as well as an
exploratory and qualitative research based on interviews with professionals from software
development companies. The content analysis taking from the interviews allowed identifying
the main barriers for adopting MA in software development companies, which are: the current
demands regarding the form of relationship demanded by their clients, and the lack of
knowledge about the advantages that MA could offer. However, the research also shows that
the interviewers recognize the advantages that could be offered by using MA as a complement
for traditional software project management models. Conclusions taken from this research
work show that MA are still not widely used by software development companies, while the
benefits of its application are acknowledged for improving software development projects.
Keywords: Agile methods for project management; Software development project
management; Agile methods for software development process management.

VII Convibra Administrao Congresso Virtual Brasileiro de Administrao www.convibra.com.br
1Introduo
A globalizao da economia mundial tem sido crescente nas ltimas dcadas, tal como a sua
influncia sobre os negcios. No poderia ser diferente em empresas de Tecnologia de
Informao (TI), onde essa influncia dita exigncias por redues de custos, melhorias de
resultados, treinamentos, segurana, e planos de contingncia. Isso tem tornado o cotidiano de
trabalho das empresas desenvolvedoras de software significativamente mais complexo.
As exigncias do mercado por entregveis cada vez mais rpidos em projetos de
desenvolvimento de software levam empresas a buscar novas alternativas para resolver
problemas antigos, tais como atendimento ao prazo, com custo que atenda o oramento e
garantindo a qualidade esperada dos servios contratados. Segundo Laurindo et al. (2001),
devido a intangibilidade do produto gerado e complexidade da rea, a avaliao de eficincia
em projetos de software problemtica no que tange a qualidade, atendimento a prazos,
manter-se dentro dos custos e seguir um modelo de gesto. Essas variveis fazem parte do
contexto de projetos de desenvolvimento de software e o equilbrio na relao com clientes
um dos desafios enfrentados por empresas de desenvolvimento de software.
Esto disponveis na literatura indicaes de que a maioria dos projetos de software acaba
falhando e por diversos motivos. Por exemplo, relatrios publicados pelo STANDISH
GROUP (2006) apresentam um amplo levantamento envolvendo milhares de projetos na rea
de TI e indicam que a maioria dos projetos de software falha. Dentre as principais falhas
apontadas destacam-se: no cumprimento do oramento; atrasos no cronograma;
funcionalidades que no atendem necessidades dos usurios, ou ainda; todos estes fatores
podem estar presentes em conjunto (STANDISH GROUP, 2006).
O objetivo deste trabalho analisar a aplicao de MA na gesto de projetos no cotidiano das
empresas de desenvolvimento de software e como isto tem sido percebido por profissionais
do setor. Para isso so apresentados detalhes sobre as caractersticas da utilizao de MA nas
atividades de trabalho, considerando as variveis de controle indicadas para aplicao do
mtodo na gesto de projetos de empresas desenvolvedoras de software. Para isso foram
analisadas caractersticas da aplicao de MA frente aos mtodos de gesto atualmente
utilizados pelas empresas de software. Os resultados dessa anlise e as concluses referentes
realidade atual das prticas de gesto em empresas desenvolvedoras de software so
apresentados ao final do trabalho.

2Mtodosgeis(MA)paraGestodeProjetos
Os mtodos seqenciais para gesto de projetos de software se baseiam na premissa de que
existe um encadeamento temporal entre as atividades do projeto. O mtodo conhecido como
Cascata um dos mtodos seqenciais mais conhecidos mais utilizados em projetos de
software. Sem poder relacionar diretamente ao uso de mtodos seqenciais, a realidade que
projetos de software geralmente tm obtido resultados insatisfatrios, especialmente nos de
grande porte (STANDISH GROUP, 2006). Os mtodos seqenciais aplicados a projetos de
engenharia colocam nfase maior nas etapas iniciais de projetos, ou seja, em planejar antes de
construir. Por outro lado, MA enfatizam que as etapas de construo so mais importantes e
devem considerar a relao de confiana entre contratante e contratado (BECK, 1999). O
paradoxo de tentar evitar mudanas, que so geralmente intrnsecas ao ciclo de vida de
projetos de software, um desafio permanente para empresas desenvolvedoras de software,
bem como para seus contratantes. Tal como em diversas reas de negcios, existe a
necessidade por mtodos que permitam alterar detalhes de seus projetos, sem comprometer a

VII Convibra Administrao Congresso Virtual Brasileiro de Administrao www.convibra.com.br
qualidade do produto final. Os MA para gesto de projetos se apresentam como uma
alternativa a esses problemas de constantes alteraes (BECK, 1999).
Tal como os diversos setores industriais, empresas desenvolvedoras de software vm
buscando tcnicas de gesto que possam reduzir os riscos dos seus projetos e tornar suas
atividades de trabalho mais produtivas. Um marco neste sentido a criao da disciplina de
Engenharia de Software. A reviso de literatura indica que diversas propostas tm sido
apresentadas para melhorar o desempenho nos projetos, com destaque a uma tendncia de
processos com desenvolvimento iterativo e incremental, com as atividades definidas por
pacotes de trabalho, sendo planejadas e executadas em paralelo (HIGHSMITH e
COCKBURN, 2001). Mais recentemente, os MA com sua proposta de entrega e gerao de
produto a cada pacote de trabalho (tambm conhecido como sprint) vem tomando fora em
vrias atividades produtivas que envolvem a elaborao de projetos.
Um dos modelos de maior destaque na literatura como processo linear e seqencial de
desenvolvimento conhecido como Cascata (BROOKS, 1995). O modelo organiza os
projetos de software em quatro grandes etapas, a serem realizadas seqencialmente, que so:
anlise, projeto, codificao e testes. Ainda hoje, este o modelo de desenvolvimento mais
conhecido e amplamente utilizado por empresas desenvolvedoras de software (PRESSMAN,
2006). O Rational Unified Process (RUP) um exemplo de modelo para gesto de projetos de
software que oferece alguns avanos ao em relao ao modelo em Cascata, embora mantenha
conceitos herdados do Taylorismo (HIGHSMITH, 2002). Ele um framework de processo
abrangente que, como tal, pode ser instanciado para atender s necessidades dos mais diversos
tipos de projetos de software (BOOCH, RUMBAUGH e J ACOBSON, 1999).
possvel observar na Figura 1 a evoluo na abordagem de gesto do ciclo de vida de
projetos de desenvolvimento de software presente em diferentes modelos. Inicialmente a
execuo do ciclo de vida dos projetos proposta em processos encadeados, conhecidos como
Cascata, passando para processos mais Iterativos, e com desenvolvimento incremental, at os
atuais processos geis. A Figura 1 mostra em [a] o processo em Cascata, onde cada etapa do
ciclo realizada por completo antes de iniciar a prxima, possuindo assim longos ciclos para
a execuo de cada etapa e entregando produtos de desenvolvimento somente aps a
concluso de todas essas etapas. Em [b] as etapas do ciclo de vida dos projetos de
desenvolvimento de software acontecem de forma Iterativa, com alguns ciclos se repetindo
com as suas quatro etapas possuindo entregas incrementais para os produtos (exemplos so
modelos conhecidos como Espiral ou Incremental). Em [c] apresentado o processo gil,
com pequenos e mltiplos ciclos repetitivos nas quatro etapas, sendo capaz de gerar produtos
mais cedo, visto que os ciclos so menores e sua execuo mais rpida.
Na dcada de 1990, profissionais da indstria de software comearam a propor novos
processos de desenvolvimento que fossem mais adequados para lidar com os aspectos
humanos dos projetos de software. Em fevereiro de 2001 um grupo de profissionais se reuniu
em torno de um objetivo comum, o de auxiliar os profissionais a pensar sobre
desenvolvimento de software, propondo metodologias e organizaes de forma mais gil. Este
grupo foi identificado como The Agile Alliance e constitudo por profissionais
independentes, concorrentes e que assinaram o Manifesto for Agile Software Development
(BECK, 2001). Este documento contm a proposta que passou a identificar como Mtodos
geis (MA) todas as abordagens de desenvolvimento de software que seguem suas
orientaes (BECK, 2001).

VII Convibra Administrao Congresso Virtual Brasileiro de Administrao www.convibra.com.br

Figura 1 Evoluo na forma de execuo de projetos de desenvolvimento de software.
Fonte: Adaptada de Beck (1999).

Segundo Beck (2001) o Movimento gil no anti-metodologia, mas um desejo de recuperar
a credibilidade da palavra metodologia, tal como destacado a seguir:

Buscamos restaurar o equilbrio. Valorizamos a modelagem, mas no na forma de
arquivar todos os diagramas em um repositrio corporativo como se fosse uma
lixeira. Valorizamos a documentao, mas no como centenas de pginas que no
sero atualizadas ou raramente utilizadas. Fazemos planos, mas reconhecemos os
limites do planejamento em um ambiente turbulento. Todos aqueles que rotulam de
hackers os proponentes de XP, SCRUM, ou qualquer outra Metodologia gil,
desconhecem no apenas o significado de uma metodologia ou da definio original
do termo hacker. (BECK, 2001).

Os MA descrevem a essncia de um conjunto de abordagens para desenvolvimento de
software, sendo encontrados na literatura exemplos como: Scrum, Extreme Programming
(XP), Adaptive Software Development (ASD), Feature Driven Development (FDD) e
Dynamic Systems Development Method (DSDM) (BECK, 2000). Os mais difundidos
comercialmente so: (i) o Extreme Programming (tambm conhecido pela abreviao XP),
que especialmente indicado para equipes pequenas e mdias que desenvolvem software com
requisitos no muito claros e em constante mudana (BECK, 2000) e; (ii) o Scrum, que uma
abordagem de planejamento no linear para gesto de projetos geis (SCHWABER e
BEEDLE, 2001). Estes mtodos so usados para formar um conjunto de prticas em MA.
Alguns enfatizam descries tcnicas e prticas para operacionalizar a execuo dos projetos,
como o caso do XP. Por outro lado, outros colocam mais nfase na gesto das atividades do
projeto de software, tal como o Scrum (ABRAHAMSSON et al., 2002).
caracterstica dos MA a aplicabilidade em projetos de software onde no esto muito
claros aspectos como requisitos e exigncias por qualidade. Isto pode ser decorrente de
aspectos como falta de conhecimento do pessoal de negcios sobre tecnologias e sistemas de
informao, processos de negcios novos com equipes em formao, baixo conhecimento
sobre o escopo, adoo de novas tecnologias, novas ferramentas e at mesmo alteraes
bruscas do negcio, causadas por legislao ou fuses empresariais (BOEHM, 2003). De
acordo com Highsmith e Cockburn (2001), MA so aplicados para se obter um processo de
desenvolvimento de software mais adequado ao ambiente turbulento dos negcios, que exige
mudanas rpidas e freqentes.

VII Convibra Administrao Congresso Virtual Brasileiro de Administrao www.convibra.com.br
Um engano comum na aplicao de MA a viso de que a melhoria contnua visa apenas
aumentar a produtividade do time. Toda e qualquer ao de resoluo de problemas
executada por meio do entendimento de suas influncias nos elementos de avaliao
primrios (LIKER e MEIER, 2007). Em seu modelo de melhoria contnua (conhecida como
Kaizen), a Toyota considera cinco elementos primrios de avaliao, que so: (i) qualidade,
(ii) produtividade, (iii) custo, (iv) segurana e (v) atendimento ao cliente (SHARMA, 2003).
Estes so conceitos que esto permeados nos MA e sero considerados para anlise de sua
aplicabilidade, conforme os objetivos do trabalho. Mais detalhes sobre a forma de avaliao da
aplicabilidade dos MA esto descritos a seguir.

2.1MAnaGestodeProjetosdeSoftware
Os MA diferem dos mtodos tradicionais principalmente na forma como so gerenciados em
relao s variveis de controle (VC). A abordagem tradicional de projetos de software
considera fixos os itens de controle, que so: (i) escopo (VC1); (ii) custo (VC2); (iii) prazo
(VC3) e; (iv) tratando de forma varivel a qualidade (VC4). Enquanto isso, os MA tratam
como fixos os itens de controle qualidade, custo e prazo, considerando como varivel somente
o escopo do projeto. A Figura 2 destaca as diferenas entre estas duas abordagens.


Figura 2 Abordagens tradicionais X MA.
Fonte: Elaborado pelos autores.

Nas abordagens tradicionais (ou seqenciais) de gesto de projetos necessrio determinar
um escopo bem definido para que se tenha um prazo especificado e um custo estimado. Esta
tripla restrio indica que as trs principais variveis de controle do projeto devem ser
estabelecidas e equilibradas de forma adequada. A nica varivel de controle que geralmente
fica aberta (ou flexvel) nesta situao a qualidade (COCKBURN, 2002).
Por outro lado, nos MA deve ser estabelecido o prazo, custo e metas de qualidade, mas o
escopo a varivel de controle em aberto. Assim, com um escopo varivel, no se tem como
regra buscar cumprir todos os requisitos do softwareque est sendo desenvolvido. Isso fora a
equipe de desenvolvimento, junto com o cliente, a priorizar os itens de software que so mais
importantes. As priorizaes dos itens de escopo do software a serem implementados podem
mudar completamente o resultado final do produto de software (HIGHSMITH e
COCKBURN, 2001). Portanto, pode-se considerar que, software construdo com uso de MA,
teria grandes chances de ser diferente do mesmo produto final se construdo com abordagens

VII Convibra Administrao Congresso Virtual Brasileiro de Administrao www.convibra.com.br
tradicionais (HIGHSMITH, 2002). Por exemplo, as premissas do XP em relao s variveis
de controle dos projetos so:
escopo - quanto maior, pior a qualidade e pior ser a condio de atendimento ao prazo
e custo;
custo - quanto mais recursos humanos, maior a carga adicional de trabalho, pior a
produtividade e pior ser a comunicao;
tempo (prazo) - se for muito curto, pior a produtividade e a qualidade e, se for muito
longo, aumenta o escopo e dificulta a comunicao; e
qualidade - quando as exigncias so altas, melhor a produtividade e o cumprimento dos
prazos, mas se forem baixas, todas as variveis podem piorar e comprometer o sucesso do
projeto.
Abordagens tradicionais levam equipes de projetos a desenvolver produtos que atendam a
todos os requisitos do cliente, muitas vezes com atrasos no prazo e custo superior s
expectativas iniciais. O resultado geralmente leva a software com problemas de qualidade,
muitas vezes complexos e inadequados s necessidades dos usurios (HIGHSMITH e
COCKBURN, 2001). Por outro lado, MA com prazos de entregas peridicas e contnuas,
custos controlados e qualidade garantida, preocupam-se apenas em definir e redefinir, a cada
ciclo de entregas, quais seriam os prximos itens de escopo a serem priorizados, quais devem
ser melhorados e quais devem ser descartados. O resultado final so produtos de software com
escopo mais adequado as reais necessidades dos usurios e, por vezes mais simples e
funcionais do que produtos complexos e inadequados (HIGHSMITH, 2002).
A essncia do funcionamento de um projeto gil est na sua capacidade de aprender e se
adaptar com esse aprendizado. Para os MA as correes sistemticas de pequenos erros
cometidos devido a falsas suposies so a chave para o funcionamento dos seus ciclos de
especulao, colaborao e aprendizado (HIGHSMITH, 2002). Estes so fatores que
freqentemente influenciam no sucesso de projetos de software, especialmente quando so
contratadas empresas desenvolvedoras cuja responsabilidade sobre as dificuldades dos
projetos de software no so compartilhadas com as contratantes.

2.2AnlisedaAplicabilidadedosMA
MA podem ser considerados como uma coleo de metodologias baseadas nas prticas para
modelagem efetiva de projetos de software. uma filosofia onde diferentes metodologias se
encaixam para aplicar uma coleo de prticas, guiadas por princpios e valores que podem
ser usados no dia a dia para gesto de projetos de software (AGILE ALLIANCE, 2001a).
Podem tambm ser considerados como guias para trabalhar em equipe, com foco em atender
s partes interessadas, contemplando suas reais necessidades na gesto de projetos. Tm como
premissa bsica que o cliente faa parte da equipe, com abordagem interativa e incremental.
No devem ser considerados como divergentes, mas complementares a outras metodologias
para gesto de projetos. Tampouco so contrrios ao uso de documentao dos resultados de
projetos, embora prezem pelo mnimo necessrio (COHEN, LINDVALL e COSTA, 2004).
O pensamento gil reconhece cinco obstculos na gesto de projetos de software (AGILE
ALLIANCE, 2001a), que so: (i) pessoas, (ii) tempo, (iii) funcionalidades, (iv) oramento e
(v) demais recursos, tais como tecnologia, instalaes, comunicao e aprendizado (excluindo
pessoas). Para gerir estes obstculos o Manifesto gil indica quatro Valores Fundamentais
(VF) para definir prioridades sobre situaes como: (VF1) indivduos e interaes so mais
importantes que processos e ferramentas; (VF2) software funcionando mais importante do

VII Convibra Administrao Congresso Virtual Brasileiro de Administrao www.convibra.com.br
que documentao detalhada; (VF3) colaborao dos clientes mais importante do que
negociao de contratos e; (VF4) adaptao s mudanas mais importante do que seguir
um plano. Cabe destacar que, embora estes quatro VF sejam mais importantes que seus
complementares, no existe a afirmao de que todos no sejam tambm importantes. Para
aplicao dos VF na gesto de projetos de software, o Manifesto gil considera 12 princpios
(P1 a P12) a serem seguidos por praticantes (AGILE ALLIANCE, 2001b).
P1. A maior prioridade garantir a satisfao do cliente, entregando rapidamente e
continuamente softwares funcionais.
P2. At mesmo mudanas tardias de escopo no projeto so bem-vindas. Processos geis
encaram as mudanas como vantagens competitivas para o cliente.
P3. Softwares funcionais so entregues freqentemente, desde poucas semanas at
poucos meses, preferencialmente da forma mais rpida possvel.
P4. Deve haver cooperao constante entre as pessoas que entendem do negcio e os
desenvolvedores.
P5. Projetos surgem atravs de indivduos motivados. Fornea a eles um ambiente e d
apoio as suas necessidades e voc poder ter confiana de que o trabalho ser feito.
P6. O mtodo mais eficiente e efetivo de transmitir e receber informao entre
membros da equipe de desenvolvimento atravs de uma conversao direta e
pessoal.
P7. Software funcional a principal medida de progresso do projeto.
P8. Processos geis promovem um ambiente sustentvel. Os patrocinadores,
desenvolvedores e usurios devem ter a capacidade de manter um ritmo constante
por tempo indeterminado.
P9. Ateno contnua com a excelncia tcnica e o design aumentam a agilidade.
P10. Simplicidade como uma arte de maximizar a quantidade de trabalho no realizado
essencial.
P11. As melhores arquiteturas, requisitos e design emergem a partir de uma equipe
auto-organizada.
P12. Atravs de intervalos regulares a equipe avalia formas de aumentar sua
efetividade, e ento muda e ajusta de forma adequada o seu comportamento.
Para a anlise da aplicabilidade dos MA na gesto de projetos e como so percebidas por
empresas desenvolvedoras de software, neste trabalho sero considerados como os VFs e os
Ps esto sendo aplicados nas empresas entrevistadas, considerando-se as dimenses das
quatro VCs de projetos de desenvolvimento de software (escopo, tempo, custo e qualidade).
Mais detalhes sobre o mtodo de pesquisa e as entrevistas aplicadas para desenvolver este
trabalho so apresentadas a seguir.

3MtododePesquisa
O mtodo de pesquisa apresenta um conjunto de regras para que o pesquisador possa
desenvolver um trabalho de investigao e produzir conhecimento, garantindo que as etapas
de trabalho e resultados obtidos possam ser planejadas, interpretados e at repetidos por
terceiros, se praticados em condies similares original (MALHOTRA, 2006). Portanto, a
opo pelo mtodo para desenvolver um trabalho de pesquisa deve ser feita considerando o
propsito de viabilizar o alcance dos objetivos propostos na investigao.
Neste trabalho foi utilizada uma pesquisa qualitativa de carter exploratrio, elaborada por
meio de entrevistas semi-estruturadas, aplicadas presencialmente a especialistas na rea de
gesto de projetos de software. Com isso, se buscava coletar percepes capazes de oferecer a

VII Convibra Administrao Congresso Virtual Brasileiro de Administrao www.convibra.com.br
compreenso do contexto do problema (MALHOTRA, 2006). O carter exploratrio do
trabalho est relacionado com a forma como est sendo proposto o entendimento da
aplicabilidade dos MA nas empresas desenvolvedoras de software. Malhotra (2006) cita que o
objetivo principal da pesquisa exploratria demonstrar o problema com preciso, identificar
caminhos alternativos de ao, prover o desenvolvimento de hipteses, isolar e classificar
variveis para identificao e anlise de critrios que ajudem no desenvolvimento de
interpretaes, e possveis solues a problemas.
Para atender aos objetivos do trabalho foram utilizadas entrevistas em profundidade, aplicadas
a cinco profissionais de equipes de projetos de empresas desenvolvedoras de software. Como
parte da pesquisa exploratria, onde no se conhecia o assunto em profundidade, as
entrevistas foram baseadas em um roteiro semi-estruturado, o qual permitia aos entrevistados
inserir comentrios diversos sobre os temas pesquisados (McCRACKEN, 2003). As perguntas
do roteiro foram inicialmente elaboradas com base na reviso de literatura. Esse roteiro
passou por uma etapa de pr-teste e, para isso, contou com a opinio de dois especialistas que
atuam como consultores em MA, bem como por um profissional de gesto de projetos com
atuao na rea empresarial e acadmica.
As entrevistas foram gravadas e transcritas para a anlise de contedo. Como apontado na
reviso de literatura, as entrevistas serviram para complementar umas s outras, permitindo
que o pesquisador fosse capaz de identificar categorias e caractersticas dos resultados que
pudessem ser mais bem avaliadas na entrevista subseqente (BARDIN, 1994).
Para interpretao dos resultados foi utilizada a tcnica de anlise de contedo, que pode ser
definida como um mtodo de tratamento e anlise de informaes para coleta de dados em
textos (CHIZZOTTI, 1991, p.98). A anlise de contedo contempla iniciativas de
explicao, sistematizao e expresso do contedo das entrevistas, com a finalidade de
permitir o entendimento a partir da origem das mensagens (BARDIN, 1994).

4AnlisedeResultados
Para seleo dos entrevistados foi adotada a amostragem no probabilstica, com seleo por
convenincia. O perfil dos entrevistados est resumido na Tabela 1.

Entrevistado Funo Experincia Empresa Porte
AplicaMAna
empresa
Entrevistado1 Gerentedoprojeto
11anosemTI,
5anosemMA
1 Grande
Namaioria
dosprojetos
Entrevistado2 Gerentedeprojeto
10anosemTI,
jutilizouMA
2 Mdio
Emalguns
projetos
Entrevistado3
Coordenadordarea
dedesenvolvimento
15anos,utiliza
MAh4anos
3 Pequeno
Emtodosos
projetos
Entrevistado4 Gerentedeprojeto
20anos,no
utilizaMA,
masconhece
4 Grande Noaplicado
Entrevistado5 Consultor
15anosemTI,
5anosemMA
5 Pequeno
Emtodosos
projetos
Tabela 1 Perfil dos entrevistados, empresa e uso de MA.
Fonte: Elaborado pelos autores.

VII Convibra Administrao Congresso Virtual Brasileiro de Administrao www.convibra.com.br
As categorias utilizadas para a investigao so oriundas da reviso de literatura e do pr-teste
de validao do roteiro de pesquisa. Essas categorias esto apresentadas como variveis de
controle de projetos, e so: (i) Escopo; (ii) Tempo (ou Prazo), (iii) Custo e; (iv) Qualidade.
Nas entrevistas foram identificados aspectos com caractersticas similares a essas categorias,
mas tambm foi indicada a presena de uma quinta, levando a que fosse includa a categoria
(v) Pessoas. As anlises de resultados das entrevistas, segundo as categorias indicadas no
trabalho, esto apresentadas na Tabela 1.

4.1Escopo
A tratativa que envolve a negociao de escopo um ponto central nas dificuldades
enfrentadas na rotina dos projetos de empresas desenvolvedoras de software (PRESSMAN,
2006). A falta e a dificuldade de formalizao no escopo de um projeto e suas constantes
mudanas so agravantes na negociao de contratos de desenvolvimento de software. Isso
pode ser comprovado nas transcries a seguir.

Em relao ao escopo, a gente acaba atendendo, mas muitas vezes no da forma
inicialmente planejada ou mais certa. s vezes so necessrias vrias rodadas de
renegociao com o cliente e o desgaste inevitvel na gerncia de cada mudana.
(Entrevistado 1)

(...) o ponto crucial da formalizao dos compromissos que d garantias ao cliente
de que ele ir receber o que est contratando, e tambm que nossa empresa ir
entregar aquilo para a qual foi contratada, e no prazo definido. Porm, isso no
garante que o que o cliente quer realmente o que foi contratado. A temos de volta
as discordncias em relao ao escopo contratado e o necessrio (Entrevistado 2).

Os MA prezam pelo mnimo de documentao. Por vezes isso se torna um argumento
utilizado como barreira sua adoo, que pode ter como origem a resistncia das empresas
desenvolvedoras de software, a partir da necessidade de formalizaes com o cliente. Porm,
quando se trata de escopo, mesmo os MA tm sua forma de registrar os resultados das rodadas
de negociaes, embora sendo encarado com mais flexibilidade (COHEN, LINDVALL e
COSTA, 2004).

... uma coisa que eu acho interessante de colocar e reforar que a adoo de MA
para facilitar a vida das pessoas, sem gerar muita documentao, e com alto nvel de
satisfao das expectativas do cliente em relao ao produto final. No d pra achar
que tudo uma baguna. A disciplina um dos valores fortes para quem implementa
MA. (Entrevistado 5).

... quando usamos MA o escopo formalizado. Usamos um backlog que se mantm
priorizado, mas dando certa agilidade ao time. Por exemplo, quando se termina o
escopo do sprint antes do previsto, a lista de funcionalidades j esta priorizada.
Assim s verificar quem a prxima. Quando se fala em documentao, primamos
pelo mnimo necessrio, mas o necessrio realizado. (Entrevistado 1).

Durante o levantamento do escopo inicial do projeto com MA executado um
processo formal de Anlise Crtica de Projeto (Situao Presente x Situao Desejada

VII Convibra Administrao Congresso Virtual Brasileiro de Administrao www.convibra.com.br
x Impactos x ROI) seguido por uma Anlise de Escopo (Processo x Temas x User
Stories), conduzidos sob a responsabilidade de um Analista de Negcios, o qual
utiliza como padro o modelo de User Stories. (Entrevistado 3).

Mudanas de escopo tambm so aceitas em empresas que no utilizam MA, porm o
formalismo na documentao maior (COHEN, LINDVALL e COSTA, 2004).

Mudanas podem ser includas, desde que respeitem o processo de gesto de
mudanas, onde feita a validao do impacto das mesmas sobre o projeto.
Dependendo da mudana, pode-se adequar rapidamente, desde que no mude o
caminho crtico da aplicao, ou que afete a arquitetura do projeto. (Entrevistado 2).

Por outro lado, empresas que aplicam MA parecem encarar as mudanas como
rotina.

Mudanas so bem vindas. O time de negcio pode mudar com freqncia o backlog.
Existem mtricas pra isso no backlog. (Entrevistado 1).

muito raro que os projetos iniciem e terminem sem alteraes nas suas
especificaes iniciais. As necessidades de alterao so freqentes e influenciadas
por diversos motivos, como por exemplo mudanas de legislao, de interpretao do
usurio e assim por diante. (Entrevistado 3).

No contexto de escopo, um fator que contribui positivamente para adoo de MA a
participao do cliente na equipe do projeto, com vistas a alinhar sua expectativa de forma
continua em relao aos entregveis (BECK et al., 2001). No entanto, isso pode ser difcil de
ser alcanado em projetos que no so desenvolvidos em conjunto com equipes internas da
empresa cliente.

... no conseguimos ter o cliente disponvel 100% para acompanhar o projeto. Ns
conseguimos isso somente com o estabelecimento de cronogramas de dependncia,
onde esto planejadas as obrigaes do cliente, conforme descrito na nossa
metodologia. (Entrevistado 2).

... a elaborao do escopo baseada no processo de negcio e visando o retorno do
investimento a cada verso de produto ao longo do projeto. Precisamos trabalhar
forte com a mudana da cultura tradicional impregnada na mente dos clientes, que
espera somente uma nica entrega de produto ao final do projeto. (Entrevistado 3).

Outro aspecto importante relacionado ao escopo a estimativa. Todos os entrevistados,
utilizando ou no MA, usam algum mtodo de estimativa. Independe de como feita a
estimativa, o importante que exista um mtodo e que seja adequado a realidade da empresa.

Aps a aprovao do documento de escopo, feita a estimativa usando a mtrica
UCP (Use Case Point), que leva em considerao a quantidade de cenrios em cada
caso de uso. Os casos de uso so classificados como simples, mdio ou complexo e,
ao final do trabalho, gerado um documento que representa a soma dos casos de uso

VII Convibra Administrao Congresso Virtual Brasileiro de Administrao www.convibra.com.br
categorizados por sua complexidade. Portanto, a produtividade analisada por caso
de uso. (Entrevistado 2).

Baseado na anlise do processo de negcios a ser aprimorado pelo projeto de
software, as User Stories identificadas tm suas complexidades estimadas em escala
pr-definida de Story Points (problemas pequenos: 1,2,3; problemas mdios: 5,8,13;
problemas grandes: 20,40,80). As estimativas so adimensionais (independentes de
fator tempo ou competncia do estimador), e feitas de forma comparativa.
Estimativas de tempo de execuo so realizadas com base na complexidade total
estimada para o projeto e velocidade mdia (ou baixa) de uma equipe em produo
de software (Story Points entregues por Sprint). (Entrevistado 3).

As estimativas so baseadas no escopo preliminar e utilizam o histrico de projetos
anteriores. O escopo refinado utilizado depois para mostrar a estimativa para cada
etapa do projeto, na medida em que ele vai sendo detalhado no plano do projeto.
(Entrevistado 4).

Criamos o backlog usando uma escala de relatividade de tamanho entre os itens do
escopo. Usamos uma escala numrica (1,2, 5,8 e 13) onde o 1 o mais simples e o
13 o mais complexo. O time classifica os itens de escopo dentro dessa escala e
aplicamos a produtividade mdia daquele time no tempo de sprint estipulado. As
estimativas valem somente para cada time. (Entrevisado 1) .

Usando Story Points, escala numrica para relativizao de complexidade,
experincia de especialista, histrico de projetos anteriores a estimativa emprica.
Em UCP, acaba no sendo muito diferente, (...) pois tm-se questes subjetivas sobre
o entendimento do que um caso de uso, do que um cenrio e o problema acaba
sendo contextual, independente do mtodo aplicado. (Entrevistado 5).

As respostas indicam que o problema no est no mtodo empregado, mas na forma como o
tamanho e complexidade do escopo negociado com o cliente, visto que est sujeito a
mudanas pelo amadurecimento do entendimento das suas necessidades. Tambm cabe
observar que, problemas de atendimento s expectativas em relao ao produto final,
poderiam ser resolvidos pelas equipes (cliente-fornecedor), caso o escopo, lista de demandas
ou a lista de requisitos fossem freqentemente reavaliadas, tal como indicado nos MA.

4.2Tempo
De acordo com Sommerville (2007), na dinmica constante de evoluo nas exigncias por
competitividade, fundamental que produtos de software sejam desenvolvidos o mais rpido
possvel para aproveitar o mximo das oportunidades oferecidas.

A previso inicial feita com base num princpio da teoria das filas, onde o tempo
mdio de durao numa fila igual ao total de elementos da fila dividido pela
velocidade com que a fila se move. No caso do software, o tamanho da fila igual ao
total de complexidade estimado em pontos (Story Points) e a velocidade o valor
mdio (ou uma meta da equipe) de produo de pontos entregues por iterao
(Sprint). (Entrevistado 3).

VII Convibra Administrao Congresso Virtual Brasileiro de Administrao www.convibra.com.br

Os prazos so validados de acordo com a priorizao dos requisitos e tempo de
construo de cada requisito. Assim cria-se um documento de planejamento de
projeto, no qual os requisitos tm data de incio e de finalizao. Este documento
tambm apresenta a data de entrega de cada fase do projeto (conjunto de requisitos a
ser entregues). (Entrevistado 2).

interessante observar que, nas empresas que utilizam MA, a entrega de software funcional
usada como medida de controle da evoluo do projeto, enquanto nas outras se trabalha com o
conceito de entregas planejadas.

Em caso de atraso de entrega ou mudana de requisitos, o mesmo replanejado e
acordado com o cliente. As entregas so oficializadas por meio de um documento
que o cliente tambm assina. (Entrevistado 2).

Apresentamos uma estimativa inicial de prazo necessrio para atender o escopo em
questo, sendo que todos os nossos projetos so limitados a 3 meses de durao.
Caso seja maior do que esse perodo, seu gestor obrigado a fracionar o escopo para
realiz-lo dentro deste prazo. Este prazo calculado em funo do tamanho da
equipe necessria para garantir a velocidade de produo para entregar o escopo
previsto. (Entrevistado 3).

Os prazos geralmente so negociados com o cliente com base no tempo limite que a
gente tem para realizar o projeto. (Entrevistado 4).

Em relao varivel de controle tempo, os mtodos de planejamento so bem diferentes para
quem usa e quem no usa MA, tal como apresentado acima. Pode-se observar que existe uma
preocupao unnime entre quem aplica MA e quem no aplica, ou seja, todos prezam pelo
atendimento do prazo buscando o comprometimento do cliente, tanto nas entregas, como nas
mudanas, e tambm no escopo.

4.3Custo
A existncia de processos de planejamento e acompanhamento baseados no MPS.BR
(SOFTEX, 2007) ou no PMBOK (PMI, 2009) foram observadas como prticas em relao
gerencia de custo nas empresas entrevistadas. Medidas de avaliao de retorno do
investimento (ROI) no inicio e ao longo da execuo do projeto, tambm foram verificadas,
conforme as transcries a seguir.

... na empresa temos um processo de planejamento e acompanhamento dos projetos
baseado no MPS.BR. Cada gerente de projeto responsvel pelo planejamento do
oramento do projeto e pela execuo do mesmo. Conforme a periodicidade
registrada no planejamento as apuraes so executadas. (Entrevistado 2).

Antes de decidirmos pela realizao do escopo de um determinado projeto de
software, calculamos um ROI mnimo com a anlise de reduo de tempos, custos, e
riscos do processo de negcio envolvido na melhoria. A cada final de Sprint, todas as

VII Convibra Administrao Congresso Virtual Brasileiro de Administrao www.convibra.com.br
despesas (fixas e variveis) so computadas a fim de mantermos uma avaliao das
projees de gastos. (Entrevistado 3).

A nica varivel o escopo. A qualidade, o prazo e custo so fixos. Tu sabes quanto
custa cada interao. (...) enquanto o ROI no alcanou a viso, o cliente busca
aquela viso. (Entrevistado 1).

Para Boehm (2003) o gerenciamento mau feito pode incrementar os custos de um projeto de
software mais rapidamente do que qualquer outro fator. Dessa forma, cabe ressaltar que nas
empresas entrevistadas foi notada uma preocupao com a utilizao de modelos para
suportar o processo de desenvolvimento de software e permitir controlar os resultados dos
projetos.

4.4Qualidade
Existem esforos a fim de oferecer um equilbrio entre a qualidade, requisitos de software,
produo e entregas rpidas. Essa uma tarefa difcil e talvez a mais desafiadora no contexto
dos projetos de software (PMI, 2009; SOMMERVILLE, 2007). Nas entrevistas, surgiram
questes como investimento em pessoal, ressaltando a necessidade de investimento no capital
humano, aplicao da simplicidade nas solues, utilizao de processos de avaliao de
qualidade e preocupao com a melhoria contnua, aplicada em todo o ciclo de vida do
projeto.

O fato das empresas no investirem na busca de autoridade moral, baseado na
competncia e liderana de seus colaboradores, faz com que suas organizaes sejam
improdutivas diante dos arranjos altamente produtivos dos sistemas dinmicos
baseados em auto-aprendizado e melhoria contnua. (Entrevistado 3).

Outro aspecto importante a capacitao das pessoas. preciso compartilhar o
conhecimento entre a equipe e o uso de artefatos deve ser restrito apenas aquilo que
vai agregar valor para o cliente final, com garantia da qualidade. (Entrevistado 4).

Para os MA a qualidade se aplica em todo ciclo de desenvolvimento e as prticas comuns so:

A qualidade no nosso contexto so prticas intrnsecas de nossos processos de gesto
de projetos para desenvolvimento e manuteno de Software. Isso inclui desde a
validao de escopo, a anlise preliminar para constituio do Sprint a partir do
Backlog com objetivo de melhorar o contedo descritivo do requisito funcional,
inspees de cdigo, testes de unidade, testes de integrao, testes de sistema, testes
funcionais, verificao com revises conjuntas por membros da equipe e validao
com revises conjuntas com a participao do cliente. (Entrevistado 5).

Independentemente do mtodo aplicado, foi identificado que nas empresas existem processos
de verificao de qualidade, denotando que a qualidade tambm transversal, e deve
abranger todo o ciclo de vida do projeto.

Temos um processo de Qualidade baseado no MPS.BR que prev verificaes e
revises em diversas etapas do processo e do ciclo de vida do projeto. (...) Para mim

VII Convibra Administrao Congresso Virtual Brasileiro de Administrao www.convibra.com.br
o ponto mais importante desse processo a reviso feita pelo gerente de projetos ao
final do processo de levantamento de requisitos, onde fecha-se o escopo do projeto.
(Entrevistado 2).

No existe uma etapa especifica para qualidade, pois MA buscam a qualidade ao
longo de cada etapa, tipo: quando terminei de fazer est pronto. No falta testar como
nos mtodos tradicionais onde h uma etapa especfica para testes. (Entrevistado 4).

4.5Pessoas
Dentre os aspectos mais importantes que possam caracterizar uma nova categoria, nas
entrevistas surgiram citaes diretamente relacionadas ao papel das pessoas. Sejam elas
equipe interna, cliente ou fornecedor. Por isso, neste trabalho foi considerada a anlise da
varivel de controle Pessoas como uma categoria especfica, e os resultados esto a seguir.
Segundo Larman (2004), se a organizao no der suporte e orientao ao time gerencial, os
princpios geis so postos de lado e os projetos so executados e gerenciados segundo os
mtodos tradicionais. Brooks (1995) ainda comenta que, adicionar pessoas em um projeto
atrasado pode atras-lo ainda mais.

A meu ver usamos o processo como artifcio para defender as partes, porque falta
maturidade na relao cliente/fornecedor. (Entrevistado 2).

Quanto menor a colaborao com o cliente/usurio, maior o risco de no
desenvolvermos algo que realmente esteja alinhado com as reais necessidades do
negcio. (Entrevistado 3).

A capacitao a maior exigncia, pois as pessoas precisam ser constantemente
treinadas em tecnologias e ferramentas necessrias ao seu trabalho, devido a rpida
evoluo da tecnologia com que trabalham. A excelncia tcnica o resultado de
todos estes estudos e trabalhos desenvolvidos ao longo do tempo. (Entrevistado 4).

Aspectos como a maturidade e capacitao das pessoas afetam o relacionamento entre as
partes, tal como transcrito a seguir por usurios que no utilizam MA.

O ponto crucial da formalizao dos compromissos de cada um d garantias aos
clientes de que ele ir receber o que esta contratando, e para a empresa que ir
entregar aquilo para qual foi contratada, no prazo definido. Porm no garante que o
que o cliente quer realmente o que foi contratado. Da temos discordncias em
relao ao escopo contratado e o escopo necessrio. (Entrevistado 2).

Com relao s equipes de MA o que se procura poucas pessoas com amplo
conhecimento de tudo que est sendo feito, utilizando tcnicas de programao em
pares, entre outras. Estas prticas permitem rapidamente nivelar o conhecimento da
equipe. (Entrevistado 4).

Por outro lado, quem usa MA diz:

VII Convibra Administrao Congresso Virtual Brasileiro de Administrao www.convibra.com.br
Eu tenho o time ao meu dispor, mas o cliente nem sempre (o que eu chamo de
disponibilidade email, telefone). O salrio do cara vem de outra coisa, s vezes
fundamental pra ele, mas nem ele entende isso. Da que entra a brincadeira dos MA,
de entregar valor cedo ao cliente para tornar ele consciente de que aquilo um
diferencial para ele. preciso maturidade tambm nas equipes do cliente.
(Entrevistado 1).

Basear-se somente na especificao de um contrato pode implicar no
desenvolvimento de requisitos funcionais e tcnicos desnecessrios (desperdcio) ou
no entregar algo no contemplado no escopo inicial, mas que se descobriu que era
de alto valor para o negcio. A falta de maturidade entre as partes gera a necessidade
de formalizao. (Entrevistado 3).

No necessariamente atender aos desejos do cliente implica resolver o problema de
um projeto. s vezes, pode at aumentar os problemas como um todo. A nica
dificuldade que tenho observado nos analistas de sistemas ou desenvolvedores de
uma equipe que as pessoas em TI no so educadas para resolverem problemas de
forma simplificada, mas sim aplicar tecnologia da forma mais complexa possvel.
necessrio capacitao nesse sentido para manter um certo nvel de empregabilidade
em ambientes complexos. (Entrevistado 5).

Outros fatores relevantes no contexto de desenvolvimento de software que se apresentam na
fala dos entrevistados so o comprometimento e a motivao das pessoas envolvidas no
processo de desenvolvimento. A motivao considerada fundamental num ambiente onde a
necessidade criativa da equipe demandada constantemente.

A motivao resultante do alinhamento da identidade desejada para uma equipe
gil e a identidade vivenciada por um membro da equipe ao longo de sua vida. Em
muitos casos, o desalinhamento de identidades pode representar uma violao da
prpria natureza de uma pessoa, exigindo que ela assuma determinados valores que
no fazem parte de sua vida. (Entrevistado 3).

Quanto motivao das pessoas envolvidas, a gente considera no apenas a nossa
equipe, mas tambm os clientes usurios daquilo que est sendo desenvolvido, alm
das equipes de apoio de rede, hardware e software, que tem papel importante nos
resultados. (...) Nossa equipe de desenvolvimento constituda por pessoas que j
trabalham juntas, sentam prximas e se conhecem. Cada um sabe qual a
especialidade do outro. Ento podemos compartilhar o trabalho de acordo com o
perfil de cada pessoa da equipe. Tem muita confiana baseada em histrico de
trabalhos em conjunto anteriores e grande confiana no grupo. (Entrevistado 4).

Dentre os assuntos abordados, cabe citar a possibilidade de potencializar a aplicao dos MA
nas empresas, atravs de uma abordagem de complementaridade, como pode ser visto abaixo:

Aplicamos um conjunto de tcnicas na empresas. Por exemplo, o XP eu utilizo mais
em nvel operacional. O pensamento Lean (Enxuto) eu utilizo mais no nvel
estratgico e o SCRUM no nvel ttico e gerencial. Dessa forma podemos combinar
vrias tcnicas e melhores prticas com aquilo que a empresa j utiliza, tais como

VII Convibra Administrao Congresso Virtual Brasileiro de Administrao www.convibra.com.br
prticas do PMI ou outro processo. A idia ir ao encontro do que a empresa utiliza
e ser complementar. (Entrevistado 5).

Nos projetos de software se lida diariamente com pessoas e processos. Dessa forma,
independentemente das prticas que sejam utilizadas, se no forem levados em conta aspectos
importantes como a habilidade de gerenciar, a necessidade de motivar e fazer as pessoas se
sentirem parte de uma equipe com um objetivo comum, dificilmente se obter xito.

5Concluses
O trabalho apresenta uma anlise dos principais aspectos que envolvem a adoo de MA em
empresas desenvolvedoras de software, considerando a forma como so gerenciadas as
atividades de trabalho. As anlises foram elaboradas considerando as principais variveis de
controle indicadas pelos principais modelos de gesto de projetos, segundo a reviso de
literatura, que so: escopo, tempo, custo, qualidade e pessoas.
A principal semelhana entre a proposta gil e modelos tradicionais de gesto de projetos est
em compatibilizar sua aplicao com as atuais prticas de processos de desenvolvimento de
software praticadas por empresas desenvolvedoras de software na relao com seus clientes.
A identificao da compatibilidade dessas prticas serve como fator que potencializa o uso de
MA como complementar aos mtodos tradicionais. A diferena fundamental, em um primeiro
momento, est em como os MA encaram o escopo de um projeto. A orientao em MA de
que o escopo a nica varivel a ser alterada, inclusive com a obrigao de ser reavaliada
pelo cliente a cada trmino de sprint. Em mtodos tradicionais de gesto de projetos o escopo
contratado deve ser fixo, embora a realidade encontrada nas empresas analisadas tenha
mostrado que isso no ocorre com freqncia. Por exemplo, o escopo no foi indicado
propriamente como fixo, embora exista uma tendncia sobre o engessamento do mesmo,
dado que alteraes normalmente implicam em aumentos nos oramentos e/ou nos prazos dos
projetos. Tambm foi percebido que nem sempre existe maturidade na relao entre as partes
(cliente e fornecedor) para tratar essas questes, o que tambm recomendado por MA. As
prticas mais comuns encontradas nas empresas entrevistadas para resolver essas questes
so: (i) criao de processos de gesto de mudanas para formalizar como deve funcionar o
projeto em caso de alteraes e; (ii) presena de clusulas contratuais para proteo de ambas
as partes, as quais podem ser alteradas para registrar as mudanas nos projetos.
Algumas questes podem no resistir ao conflito entre desenvolver um produto de forma
rpida e, ao mesmo tempo, garantir a qualidade do mesmo. Para isso existem esforos para a
adoo de modelos de maturidade, tal como MPS-BR e CMMI, os quais so dotados de um
maior formalismo nos documentos para gesto de projetos. Estes modelos podem ser usados
em conjunto com MA, de forma a agregar valor na qualidade do processo do produto a ser
desenvolvido.
A grande maioria dos modelos para gesto de projetos possui em comum grande parte dos
princpios e valores indicados para MA. Na verdade, todos so bastante simples e focados no
objetivo de gerenciar processos de software, com a entrega de um produto funcional,
adequado a necessidades dos clientes e possibilitanto o aprimoramento das tarefas realizadas
durante o ciclo do desenvolvimento. A diferena na aplicao de MA est apenas em relevar o
papel da documentao em relao a importncia da qualidade do produto final e
relacionamento entre clientes e desenvolvedores. Para isso destacada a importncia de
trabalhar com profissionais capacitados, tanto pelo lado do contratante como do contratado.
Portanto, fatores como a falta de conhecimento em relao aos MA podem oferecer uma

VII Convibra Administrao Congresso Virtual Brasileiro de Administrao www.convibra.com.br
barreira a sua adoo. A capacitao das pessoas um dos elementos chave em projetos. Os
profissionais envolvidos devem se sentir motivados, comprometidos e imbudos com os
propsitos do projeto. Portanto, esse fator merece ateno especial, a fim de maximizar as
chances de sucesso e evitando que ocorram problemas nas diversas atividades de projetos.
Os resultados da pesquisa no podem ser generalizados, mas considerados para o atual
contexto de gesto de projetos em empresas de desenvolvimento de software. A pesquisa tem
ainda limitaes como o nmero de entrevistados e as entrevistas terem sido feitas apenas em
empresas da cidade de Porto Alegre, Rio Grande do Sul. Para estudos futuros, sugere-se que
as variveis analisadas nesta pesquisa sejam investigadas a partir de diferentes pontos de
vista, considerando aspectos como: (i) identificar quais so as melhores combinaes em
termos de complementaridade dos MA com forma atual de gesto de projetos e; (ii) estender a
aplicao da pesquisa para um nmero maior de respondentes. Dessa forma, novos estudos
podem contribuir para ampliar ainda mais a compreenso do presente tema.

6Referncias
ABRAHAMSSON, P. et al. (2002). Agile software development methods Review and
analysis. VTT Electronics, p. 112.
AGILE ALLIANCE (2001a). Manifesto for Agile software Development. Disponvel em
<www.agileallieance.org>. Acessado em: 01/02/2009.
AGILE ALLIANCE (2001b). Principles: The Agile Alliance. Disponvel em
<www.agileallieance.org/principles.html>. Acessado em: 01/02/2009.
BARDIN, L. (1994). Anlise de contedo. Lisboa Edies 70.
BECK, K. (1999). Embracing Change with Extreme Programming. IEEE 1999. Disponvel
em <http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/extreme.pdf>. Acesso em:
11/2008.
BECK, K. (2000). Extreme Programming explained: embrace change. Addison-Wesley:
Reading, MA, 1. Ed., 190 p.
BECK, K. et all. (2001). Manifesto for Agile Software Development. Disponvel em
<http://agilemanifesto.org/>. Acesso em: 01/11/2008
BOEHM, B. e TURNER, R. (2003). Balancing agility and discipline: a guide for the
perplexed. Addison-Wesley: Boston, 1. ed., 266 p.
BOOCH, G., RUMBAUGH, J . e J ACOBSON, I. (1999). The Unified Modeling Language
User Guide, Addison-Wesley: Reading, MA, 236 p.
BROOKS, F. P. (1995). The Mythical Man-Month: Essays on Software Engineering, 20th
Anniversary Edition. Addison-Wesley: Reading, MA, 322 p.
COCKBURN, A. (2002). Agile software development. Addison-Wesley:Boston, 278 p.
COHEN, D., LINDVALL, M. e COSTA, P. (2004). An introduction to agile methods. In:
Advances in Computers. Elsevier Science: New York, p. 1-66.
CHIZZOTTI, A. (1991). Pesquisa em cincias humanas e sociais. Cortez: Rio de J aneiro.

VII Convibra Administrao Congresso Virtual Brasileiro de Administrao www.convibra.com.br
HIGHSMITH, J . A. (2002). Agile software development ecosystems. Addison-Wesley:
Boston.
HIGHSMITH, J . A. e COCKBURN, A. (2001). Agile Software Development: The Business
of Innovation. IEEE Computer, p.120-122, November.
LARMAN, G. (2004). Agile & Iterative Development: Managers Guide. Addison-Wesley.
LAURINDO, F. J . B. ET al. (2001). O papel da Tecnologia da Informao na estratgia das
Organizaes. Revista Gesto e Produo, v. 8, n. 2, p. 160-179.
LIKER, J . K. e MEIER. R. (2007). O Modelo Toyota: manual de aplicao. Bookman: Porto
Alegre.
MALHOTRA, N. K. (2006). Pesquisa de Marketing: uma orientao aplicada. Bookman:
Porto Alegre, 4 ed.
McCRACKEN, G. (2003). Cultura e Consumo: novas abordagens ao carter simblico dos
bens e das atividades de consumo. MAUAD: Rio de J aneiro.
PMI (2009). PMBOK 4 Edio: Guia do Conjunto de Conhecimentos em Gerenciamento
de Projetos. Project Management Institute, Newton Square, PA, USA, 4
th
edition.
PRESSMAN, R. S. (2006). Engenharia de Software. MacGraw-Hill Interamericana, 6 ed.
SCHWABER, K. e BEEDLE, M. (2001). Agile Software Development with Scrum. Prentice
Hall.
STANDISH GROUP (2006). Extreme Chaos Report 2006. The Standish Group International
Inc. Disponvel em: <http://www.standishgroup.com>. Acesso em: 23/10/2008.
SHARMA, A., e MOODY, P. E. A Mquina Perfeita; Como vencer na nova economia
produzindo com menos recursos. Prentice Hall: So Paulo: 1.ed. 255 p.
SOFTEX (2007). MPS-BR Melhoria de Processo do Software Brasileiro: Guia Geral.
Verso 1.2. Disponvel em: <http://www.softex.br/cgi/cgilua.exe/sys/start.htm?sid=211>.
Acesso em 10/11/2008.
SOMMERVILLE, I. (2007). Engenharia de Software. Pearson Education do Brasil: Rio de
J aneiro, 568 p.