Greick Roger de Carvalho Lima 10814317 PDF

Benefícios das metodologias ágeis no gerenciamento de projetos de Tecnologia da Informação (TI)
dezembro/2015
1
Benefícios das metodologias ágeis no gerenciamento de projetos de

Tecnologia da Informação (TI)
Greick Roger de Carvalho Lima - greickroger@yahoo.com.br

MBA Governança nas Tecnologias da Informação
Instituto de Pós-Graduação e Graduação – IPOG
Goiânia, Goiás, 17 de abril de 2015
Resumo
A Tecnologia de Informação (TI) tem sido considerada um dos componentes mais
importantes na atualidade, oferecendo grandes oportunidades para as empresas que têm
sucesso no aproveitamento dos benefícios oferecidos por este uso no desempenho
empresarial. A problemática a ser refere-se à relação entre os benefícios oferecidos pelo uso
de metodologias ágeis ao desempenho empresarial, e a sua aplicação no gerenciamento de
projetos de TI. O artigo objetiva explorar os conceitos de metodologias ágeis, seu
surgimento, aplicação, conceitos e principais métodos. Serão discutidas as metodologias
Scrum, que abrange gerenciamento de projetos de software, e Extreme Programming, no
âmbito de desenvolvimento. A partir dessa avaliação preliminar, busca-se identificar na
literatura algumas evidências de aplicação dessas metodologias, de forma a entender como a
teoria está sendo aplicada. Este estudo é considerado descritivo e exploratório, realizado
mediante revisão bibliográfica. Os resultados destacam que metodologias ágeis têm sido bem
aceitas pela indústria de software e por pesquisadores da Engenharia de Software, quando
comparadas com as metodologias tradicionais, devido aos resultados satisfatórios. A
conclusão deste estudo evidencia indícios da forma como o mercado utiliza e encara as
metodologias ágeis nos dias atuais. Com isso, favorece a revisão constante dos conceitos da
teoria, possibilitando maior ênfase aos que são largamente utilizados com resultados
satisfatórios, de modo a filtrar e propor transformações aos que estão tornando-se arcaicos
por falta de aplicação.
Palavras-chave: Metodologias ágeis. Gerenciamento de projetos. Software. Scrum.
1. Introdução
Um ambiente de crescentes mudanças exige das organizações inovações constantes e
criativas. As disputas, cada vez mais acirradas por uma fatia do mercado, exigem decisões
estratégicas rápidas e inovadoras, conduzindo as empresas a abandonarem modelos
tradicionais de gestão. Um componente indispensável neste processo é o Sistema Integrado de
Gestão, capaz de alimentar a empresa com informações necessárias para avaliar a situação
financeira, como também permitir que estas informações possam ser comparadas e
trabalhadas de maneira rápida, de modo a auxiliar a empresa nas suas tomadas de decisão.
ISSN 2179-5568 – Revista Especialize On-line IPOG - Goiânia - Edição nº 10 Vol. 01/ 2015 dezembro/2015
dezembro/2015
2
Na atualidade, muitas empresas, de diversos segmentos, reconhecendo a importância da

competência estratégica para o sucesso de seus negócios, vêm utilizando o gerenciamento de
Projetos de Tecnologia da Informação (TI), caracterizado pela aplicação de conhecimentos,
habilidades e técnicas para a execução de projetos de forma eficaz (RABECHINI JR.;
CARVALHO, 2008).
De fato, o gerenciamento de projetos de TI tem alcançado níveis consideráveis de importância
nas empresas, sobretudo para aquelas que necessitam passar por processos de transformação,
organizando-se para poder dar respostas eficazes e ágeis às solicitações ambientais e
organizacionais. A aplicação desta prática é bastante utilizada no desenvolvimento de
projetos, sejam eles de pequeno, médio ou grande porte, com forte referência no Project
Management Institute, (PMI), que utiliza as melhores práticas de Gerenciamento de Projetos.
Este vem se tornando um grande diferencial competitivo para as empresas que almejam obter
sucesso nos serviços prestados em um mercado cada vez mais exigente (SILVA, 2008).
Neste contexto, as empresas e a sociedade, de modo geral, encontram-se cada vez mais
dependentes da indústria de desenvolvimento de software. Porém, devido aos diversos
problemas que esta área possui, como alto custo de implementação, alta complexidade e falta
de manutenção, não conseguem atender a demanda do mercado.
Segundo Sommerville (2003:147), “[...] a melhoria no processo de desenvolvimento de
software aperfeiçoa a qualidade do produto final”; e como destacam Côrtes e Chiossi
(2001:20), “[...] a preocupação com a qualidade deixou de ser um diferencial competitivo e
passou a ser um pré-requisito básico para participação no mercado”.
Existem duas linhas distintas de metodologia: tradicionais e ágeis. Enquanto as tradicionais
primam por quantidade excessiva de documentação, as ágeis prezam por ter o software
funcionando com o mínimo de documentação necessária (LUDVIG; REINERT, 2007).
Portanto, adotar processos mais simplificados, como as metodologias ágeis tem despertado
um grande interesse entre as comunidades de desenvolvimento de software.
Coloca-se em discussão a seguinte pergunta: Quais as relações existentes entre os benefícios
oferecidos pelo uso de metodologias ágeis ao desempenho empresarial e a sua aplicação no
gerenciamento de projetos de TI? Em resposta a esta questão, considera-se a hipótese de que o
uso de metodologias ágeis nos projetos ajuda a construir somente o que o cliente valoriza,
criando produtos melhor adaptados à realidade do cliente.
Neste contexto, o objetivo do artigo é estudar as metodologias ágeis em seus conceitos gerais
e em especial os dois métodos mais largamente utilizados no presente momento: Scrum e
Extreme Programing, ou XP. O primeiro é uma metodologia de gerenciamento, enquanto que
o segundo é uma metodologia de desenvolvimento. Será feita uma identificação da forma
como as metodologias ágeis estão sendo aplicadas em empresas, envolvendo um
levantamento de quais pontos estão sendo utilizados conforme a teoria e quais são
descartados, verificando assim a importância de especialização e o impacto dessa na rotina de
profissionais e equipes.
Com base nas proposições de Gil (2010), o presente estudo caracteriza-se como pesquisa
bibliográfica, por incorporar uma revisão de literatura associada à experiência dos autores, no
campo de investigação sobre o tema em estudo. O levantamento bibliográfico foi realizado
dezembro/2015
3
mediante consultas em material já existente, constituído de livros e artigos científicos,

publicações periódicas, dissertações e teses de conteúdos similares.
A justificativa para investigar um assunto dessa natureza está na oportunidade de aumentar os
conhecimentos sobre a aplicação das metodologias ágeis no desenvolvimento de software, por
se tratar de um assunto da atualidade e que vem despertando o interesse de vários
pesquisadores sobre o tema.
2. Gerenciamento de projetos
Projeto é um esforço empreendido para criar um produto, serviço ou resultado exclusivo,
diferindo das operações de rotina, que são contínuas e repetitivas, pelas seguintes
características principais: são temporários, possuindo um início e um fim claramente
definidos; são planejados, executados e controlados; entregam produtos, serviços ou
resultados exclusivos; são desenvolvidos em etapas e continuam por incremento com uma
elaboração progressiva; são realizados por pessoas; são executados com recursos limitados
(SALLES JÚNIOR et al., 2006).
Vargas (2006) definiu projeto como um empreendimento não repetitivo, caracterizado por
uma sequência clara e lógica de eventos, com início, meio e fim, que se destina a atingir um
objetivo claro e definido, sendo conduzido por pessoas dentro de parâmetros predefinidos de
tempo, custo, recursos envolvidos e qualidade.
Um aspecto crítico para o sucesso dos projetos é o da sua gestão, definida como a aplicação
de conhecimentos, habilidades e técnicas para iniciar, planejar, executar, controlar e encerrar
as atividades que visam atingir as necessidades ou expectativas das partes envolvidas com
relação ao projeto (SILVA, 2008).
Gerenciar projetos significa apropriar-se de um conjunto de atividades para a definição e a
busca do alcance dos objetivos e resultados, por meio da otimização dos recursos disponíveis
e do tempo (SILVA, 2008). Para o autor, o gerenciamento de projetos desenvolve-se nas
etapas de definição e organização, planejamento e acompanhamento, contemplando cinco
grupos de processos - iniciação, planejamento, execução, controle e encerramento – que
utilizam técnicas ou áreas de conhecimento para gerência de integração, escopo, tempo,
custo, qualidade, recursos humanos, comunicações, aquisições e riscos.
O termo “Gerenciamento de Projetos” às vezes é usado para descrever uma abordagem
organizacional ou gerencial do gerenciamento de projetos e de algumas operações já em
andamento, que podem ser redefinidas como projetos, o que também é chamado
“gerenciamento por projetos” (PMBOK, 2012).
O Project Management Body of Knowledge (PMBOK) não pode ser definido como uma
metodologia, pois não distingue os diferentes tipos de projetos e sim como um guia de boas
práticas de gerenciamento de projetos criado e mantido pela Project Management Institute
(PMI). O guia formaliza os conceitos em gerenciamento de projetos, como a própria definição
de projeto reconhecendo cinco grupos de processo e nove áreas de conhecimento.
Os cinco grupos de processo reconhecidos pelo PMI são: Iniciação, Planejamento, Execução,
Monitoramento e Controle, Encerramento. Esses grupos possuem dependências claras e são
dezembro/2015
4
executadas na mesma sequência em todos os projetos. As dez áreas de conhecimento abordam

o gerenciamento dos seguintes processos listados abaixo:
 Integração: Processos e atividades para identificar, definir, combinar, unificar e coordenar
os vários processos e atividades dentro dos grupos de processos de gerenciamento do
projeto.
 Escopo: Processos que verificam apenas o trabalho necessário para que o projeto seja
concluído com sucesso.
 Tempo: Processos relativos ao prazo de término do projeto.
 Custos: Processos que envolvem planejamento e controle de custos de modo que o projeto
termine dentro do orçamento aprovado.
 Qualidade: Processos que asseguram que o projeto irá cumprir os objetivos para os quais
foi empreendido.
 Recursos Humanos: Processos que organizam e gerenciam a equipe do projeto.
 Comunicações: Processos que disseminam as informações relacionadas ao projeto.
 Riscos: Processos de planejamento, identificação, análise, planejamento de respostas e
controle de riscos de um projeto.
 Aquisições: Processos que compram ou adquirem bens, produtos, serviços ou resultados
externos à equipe do projeto. Engloba também os processos de gerenciamento de
contratos e controle de mudanças.
 Partes Interessadas: Processos que identificam todas as pessoas, grupos ou organizações

que podem impactar ou serem impactados pelo projeto. Além disso, analisam suas
expectativas e desenvolvem estratégias de engajamento nas decisões e execução do
projeto.
Projetos de desenvolvimento em grande parte possuem quatro fases comuns como análise,
projeto, construção e teste. Mas no caso de projetos de migração de dados, por exemplo, é
comum termos as fases de análise, extração e transformação, validação, carga e testes
(PMBOK, 2013).
3. Metodologias de desenvolvimento de Software

O desenvolvimento de software precisa ser reconhecido como um processo imprevisível e
complicado. Reconhecer que um software nunca foi construído da mesma forma, com a
mesma equipe, sob as mesmas circunstâncias antes é a grande mudança do pensamento
tradicional de desenvolvimento de software (BALLE, 2011). Mas, o mais importante é
reconhecê-lo como um processo empírico: que aceita a imprevisibilidade e tem mecanismos
de ação corretiva.
dezembro/2015
5
Metodologias de desenvolvimento de Software (ou Processo de Software) é o conjunto de

atividades, ordenadas ou não, com a finalidade de produzir um software de qualidade. O
resultado do processo é um produto que reflete a forma como o processo foi realizado.
O modelo de processo de software é uma representação abstrata de um processo de software.
Cada modelo é representado sob determinada perspectiva e fornece somente informações
parciais. Embora existam vários processos de desenvolvimento de software, Sommerville
(2007) apresenta as atividades comuns a todos eles:
 Especificação do software: definição do que o sistema deve fazer; definição dos requisitos
e das restrições do software;
 Desenvolvimento do software: projeto e implementação do software, o sistema é

desenvolvido conforme sua especificação;
 Validação do software: o software é validado para garantir que as funcionalidades

implementadas estejam de acordo com o que especificado;
 Evolução do software: evolução do software conforme a necessidade de cliente.
O desafio mais comum do Desenvolvimento de Software é entregar um produto que atenda as

reais necessidades do cliente, dentro do prazo e orçamento previsto. (LUDVIG; REINERT,
2007). Porém, muitas organizações desenvolvem software sem usar nenhum Processo de
Desenvolvimento. Geralmente porque os Processos Tradicionais não são adequados às
realidades das organizações.
3.1 Metodologias tradicionais

Na década de 1970, a atividade de “desenvolvimento de software” era executada de forma
desorganizada, desestruturada e sem planejamento, gerando um produto final de má
qualidade, que não correspondia com as reais necessidades do cliente (PRESSMAN, 2007). A
partir deste cenário surgiu a necessidade de tornar o desenvolvimento de software como um
processo estruturado, planejado e padronizado (NETO, 2004).
As metodologias consideradas tradicionais também são conhecidas como “pesadas” ou
orientadas a documentação. Têm como característica marcante dividir o processo de
desenvolvimento em etapas e/ou fases bem definidas. Segundo Soares (2004), essas
metodologias surgiram em um contexto de desenvolvimento de software muito diferente do
atual, baseado apenas em um mainframe e terminais burros.
Na época, o custo de fazer alterações era muito alto, uma vez que o acesso aos computadores
era limitado e não existiam modernas ferramentas de apoio ao desenvolvimento do software,
como depuradores e analisadores de código. Por isso, o software era todo planejado e
documentado antes de ser implementado (LUDVIG; REINERT, 2007).
Muitas metodologias pesadas são desenvolvidas em cima do Modelo em Cascata
(SOMMERVILLE, 2003). É um modelo em que as fases definidas são seguidas de maneira
dezembro/2015
6
linear (LUDVIG; REINERT, 2007). Cada fase tem associado ao seu término uma
documentação padrão que deve ser aprovada para que se inicie a etapa imediatamente
posterior. Cada fase concluída gera um marco, que geralmente é algum documento, protótipo
do software ou mesmo uma versão do sistema (NETO, 2004). De uma forma geral fazem
deste modelo as etapas de análise de requisitos, projeto do software, geração de código e
testes.
Nos anos 80, surgiu outro processo para desenvolvimento de software, o processo em espiral,
que apareceu como a solução para os problemas existentes no modelo em cascata, a exemplo
do “ciclo de Demming” (ciclo PDCA) (MARQUES, 2012). Esse modelo surgia com apenas
quatro fases (Planejamento, Avaliação, Análise de Risco e Engenharia), o processo inicia no
planejamento, vai para a avaliação, análise de risco, engenharia e, seguindo a ideia do espiral,
volta para o planejamento fazendo todo o ciclo novamente, idealizando assim um modelo
iterativo e incremental, permitindo que os erros ocorridos em uma fase possam ser revistos.
Conforme Sommerville (2003), a principal diferença entre o modelo em espiral e outros
modelos de processo de software é o reconhecimento explícito do risco no modelo em espiral,
pois riscos podem causar problemas no projeto, tal como ultrapassar o cronograma e os
custos.
Com o passar do tempo, a complexidade dos sistemas tem aumentado ainda mais, os
sistemas possuem mais usuários e tornam-se cada vez mais importantes, podendo,
em muitas vezes, gerenciar a vida ou a morte de pessoas, como é o caso de softwares
que calculam quantidades de medicamentos a serem aplicados em pacientes ou que
monitoram o estado de saúde dos pacientes, os sistemas também controlam a
economia e as armas do mundo, é possível ver isso através do pânico que foi
causado pela possibilidade do “bug” do milênio no final dos anos 90 (MARQUES,
2012:11).
Unindo-se aos problemas até então encontrados e à importância atual dos sistemas
informatizados, surgiram alguns teóricos discordando da ideia de tratar o desenvolvimento de
software como uma fábrica de produção em série. Um exemplo citado por Marques (2012) é
Cockburn que compara o desenvolvimento de software ao ato de escrever uma poesia épica
em conjunto com diversas pessoas: seriam diversas pessoas, com diversos argumentos,
tentando dar seu melhor sem talento, tempo ou recursos suficientes.
3.2 Metodologias ágeis

As metodologias ágeis constituem parte da Engenharia de Software, a área de conhecimento
voltada para a especificação, desenvolvimento e manutenção de sistemas de software
(PRESSMAN, 2007). De acordo com este autor, a Engenharia de Software abarca três
componentes básicos: métodos, que proporcionam os detalhes de como construir um
software, tratando do planejamento, estimativas, análises de requisitos e arquitetura, entre
outros; ferramentas, que sustentam cada um dos métodos; e procedimentos, que definem a
sequência em que os métodos são aplicados, e fazem o elo entre os métodos e as ferramentas.
A popularidade do termo “Metodologias Ágeis” data de 2001, a partir de uma reunião nos
Estados Unidos da América (EUA), em que um grupo de dezessete especialistas em processos
dezembro/2015
7
de desenvolvimento de software colocou em discussão a proposta de como melhorar o

desempenho de seus projetos (BALLE, 2011).
Os resultados dessa discussão deram origem à criação da Aliança Ágil e o estabelecimento do
Manifesto Ágil, contendo os conceitos e princípios comuns compartilhados por todos os
métodos já utilizados pelos participantes da reunião, haja vista que eles suas próprias práticas
e teorias sobre como fazer um projeto de software ter sucesso. Embora cada um dos
envolvidos apresentasse as suas particularidades, havia um consenso entre eles de que, em
suas experiências prévias, alguns princípios pareciam ter sido respeitados quando os projetos
davam certo (BECK et al., 2001 apud BALLE, 2011).
Desde então o termo Desenvolvimento Ágil passou a descrever abordagens de
desenvolvimento que seguissem estes conceitos que, segundo Libordi e Barbosa (2010),
implicam em valorizar:
 Indivíduos e interação entre eles são mais que processos e ferramentas;

 Software em funcionamento mais que documentação abrangente;
 Colaboração com o cliente mais que negociação de contratos;
 Responder a mudanças mais que seguir um plano.
Com o intuito de auxiliar as pessoas a compreenderem melhor o desenvolvimento de software
ágil, foram definidos doze princípios aos quais, conforme Beck et al. (2001 apud LIBORDI;
BARBOSA, 2010), as metodologias de desenvolvimento software ágeis estão adequadas. São
eles:
1. Nossa maior prioridade é satisfazer o cliente, através de entregas rápidas e contínuas
gerando valor ao software.
2. Recebendo bem as mudanças dos requisitos, mesmo em estágios tardios do
desenvolvimento. Processos ágeis devem admitir mudanças que trazem vantagens
competitivas para o cliente.
3. Trabalhando para entregar software, em intervalos de 2 semanas até 2 meses, com
preferência para que tenha uma curta escala de tempo.
4. Empresários e desenvolvedores devem trabalhar juntos diariamente durante todo o projeto.
5. Construa projetos com indivíduos motivados, dê-lhes o ambiente e o suporte que precisam,
e confie neles para ter o trabalho realizado.
6. O método mais eficiente e efetivo de transmitir informação para a equipe de
desenvolvimento está na conversa face a face.
7. Software funcionando é a principal medida para o progresso.
8. Processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, os
desenvolvedores, e os usuários devem ser capazes de manter um ritmo constante
indefinidamente.
dezembro/2015
8
9. Atenção contínua para uma excelência técnica e um bom design aumentam a agilidade.
10. Simplicidade – a arte de maximizar o valor do trabalho não feito – é essencial.
11. As melhores arquiteturas, requisitos, e design surgem a partir de equipes auto-
organizadas.
12. Em intervalos regulares, as equipes devem refletir sobre como se tornaram mais efetivas.
Em seguida, devem se aprimorar e ajustar de acordo com seu comportamento. Para isso,
cada metodologia conta seus ciclos específicos e pode se apoiar em artefatos que
auxiliam na avaliação do trabalho realizado e programação do que deverá ser realizado,
seguido ou melhorado para os ciclos seguintes.
Em síntese, o Manifesto Ágil não abandona os processos e ferramentas, a documentação, a
negociação de contratos ou o planejamento, mas simplesmente mostra que eles têm
importância secundária, quando comparado com os indivíduos e interações, com o software
funcionando, com a colaboração com o cliente e as respostas rápidas a mudanças e alterações
(LIBORDI; BARBOSA, 2010).
Na opinião de Balle (2011), da mesma forma que existe várias metodologias ágeis, também
há conjuntos de práticas ágeis que são aceitas por quaisquer das metodologias, podendo ser
adotadas pelos times ágeis ou não. Essas práticas muitas vezes são uma reunião de conceitos
de diversas metodologias, organizados de forma neutra para que possam viver
simultaneamente com qualquer uma, ou nenhuma. Agile Modeling é um processo baseado em
práticas que descreve como ser um modelador efetivo. Essas práticas são muito baseadas em
metodologias ágeis diversas, mas aplicadas à modelagem e vistas de forma mais ampla
(AMBLER, 2002 apud BALLE, 2011).
Agile Modeling ajuda a encontrar o meio-termo entre os extremos em que as formas

de modelar podem cair, seja não existindo nenhum modelo, o que acaba significando
retrabalho, como na modelagem excessiva, quando documentos e modelos demais
são criados, o que atrasa o desenvolvimento. A proposta do Agile Modeling é
modelar o suficiente para explorar e documentar o sistema de forma eficiente, mas
não a ponto de diminuir a velocidade do projeto (BALLE, 2011:15).
Conforme a autora supracitada, a Agile Modeling pode ser aplicada por times que utilizam
metodologias ágeis, mesmo que se trate simplesmente de uma técnica e não uma metodologia,
haja vista que seus princípios e técnicas são partilhados por várias metodologias ágeis, como
XP, Scrum, entre outras. No entanto, a técnica pode ser também aplicada por projetos que não
utilizam métodos ágeis e desejam melhorar e simplificar seus modelos.
Em um contexto de mercado, as metodologias ágeis são consideradas como Freemium
(ANDERSON, 2009). No caso, as metodologias foram desenvolvidas por empresas ou
pessoas físicas, que não cobram nada pela sua utilização, em uma primeira análise, o que
poderia caracterizar um Mercado Não-Monetário. Não há como negar que se pode
simplesmente procurar informações na Web, onde milhares de sites e materiais de apoio são
mantidos, inclusive por alguns dos participantes do Manifesto Ágil.
dezembro/2015
9
Pode-se, inclusive, simplesmente seguir as diretrizes do próprio Manifesto,

aplicando os princípios ágeis em qualquer setor. Essa gratuidade das metodologias,
que também não impõe uma ferramenta específica para a caracterização dos seus
conceitos, vem atraindo diversas empresas, da mesma forma que uma conta gratuita
(mas limitada) de um serviço na Web atrai muitos usuários (BALLE, 2011:17).
É observável, neste contexto, toda uma economia girando em torno das metodologias ágeis, a
exemplo das certificações oficiais, livros das mais diversas metodologias e práticas, cursos,
workshops e palestras, em especial dos autores chave das metodologias em questão e, como se
pode verificar com a análise de relatos de aplicação de metodologias ágeis. Também é comum
que sejam contratados consultores para o auxílio da implantação da metodologia escolhida
(ANDERSON, 2009).
Dessa forma, a gratuidade das metodologias atrai mais consumidores, mas estes, sem uma
orientação mais profunda e correta, acabarão muitas vezes aplicando a metodologia com uma
interpretação errada. Assim, alguns desses consumidores procurarão orientação, seja em
cursos, livros, consultorias, muitas vezes encabeçadas por autores consagrados, os mesmos
que mantém materiais gratuitos que são a porta de entrada para o mundo de metodologias
ágeis, o que caracteriza um mercado Freemium (LIBORDI; BARBOSA, 2010).
O Manifesto Ágil diz que software funcional é mais valorizado que uma documentação
extensa. Isso acaba por gerar confusão, sendo que um dos erros básicos dos que estão
começando a trabalhar com metodologias ágeis é acreditar que não devem manter
documentação nenhuma. Metodologias ágeis podem comportar documentação, porém, sob de
forma que não deixe de lado as características que definem o trabalho ágil.
Um documento é ágil se seguir uma série de critérios. Primeiramente, os documentos ágeis
maximizam o investimento dos stakeholders, ou seja, o benefício que deles provêm é maior
que o investimento em sua criação e manutenção. Por isso, descrevem somente informações
que não mudam com facilidade, pois quanto maior a chance de uma informação mudar,
menor o valor de um documento escrito sobre a mesma. Da mesma forma, um documento ágil
deve capturar informações críticas e que não são facilmente deduzíveis (AMBLER, 2004
apud LIBORDI; BARBOSA, 2010).
Um documento ágil contém somente as informações para atingir o seu objetivo, ou seja, é o
mais simples possível. E, mais do que isso, precisa ter um objetivo simples e facilmente
identificável. Precisa ter um público específico e facilitar o trabalho do mesmo, sendo
suficientemente precisa e detalhada (e não mais que isso). E, por fim, documentos ágeis são
indexados de forma eficiente e precisa, pensando em seu público-alvo.
Tendo como objetivo principal do artigo a interpretação, análise e classificação de pontos
comuns na aplicação de metodologias ágeis, é importante saber quais são os conceitos mais
relevantes e aos quais deve nos prender para um entendimento pleno, maior abrangência e
acuidade no que tange ao cenário atual da aplicação dos métodos e seus conceitos. Como o
domínio de metodologias ágeis é muito amplo, são tratados os termos de mais relevância e
abrangência, ou com foco específico em Scrum e Extreme Programming, por serem as
metodologias mais amplamente utilizadas, muitas vezes conjuntamente.
dezembro/2015
10
4. SCRUM
Scrum trabalha com a complexidade de desenvolvimento de softwares através do controle de
inspeção, adaptação e visibilidade de requisitos de um processo empírico fazendo uso de uma
série de regras e práticas, onde controle não significa controle para criar o que foi previsto e
sim controlar o processo para orientar o trabalho em direção a um produto com o maior valor
agregado possível (BARROS et al., 2009).
Para atingir esses objetivos o Scrum emprega uma estrutura iterativa e incremental da
seguinte maneira: no início de cada iteração, a equipe analisa o que deve ser feito e então
seleciona aquilo que acreditam poder se tornar um incremento de valor ao produto ao final da
iteração. A equipe então faz o seu melhor para realizar o desenvolvimento daquela iteração e
ao final apresenta o incremento de funcionalidade construído para que os stakeholders possam
verificar e requisitar alterações no momento apropriado (BARROS et al., 2009).
Segundo a Scrum Alliance (DUNCAN et al., 2005), Scrum é um framework ágil para a
realização de projetos complexos. Scrum originalmente foi formalizado para projetos de
desenvolvimento de software, mas funciona bem para qualquer escopo, complexo e inovador
de trabalho. Um dos motivos para a abrangência de campos é a simplicidade do framework
Scrum.
O Scrum destaca-se dos demais métodos ágeis pela maior ênfase dada ao gerenciamento do
projeto. Reúne atividades de monitoramento e feedback, em geral, reuniões rápidas e diárias
com toda a equipe, visando à identificação e correção de quaisquer deficiências e/ou
impedimentos no processo de desenvolvimento (SCHWABER, 2004). O método baseia-se
ainda em princípios como: equipes pequenas de, no máximo, sete pessoas; requisitos que são
pouco estáveis ou desconhecidos; e iterações curtas. Divide o desenvolvimento em intervalos
de tempos de no máximo, trinta dias, também chamados de Sprints.
O Scrum implementa um esqueleto iterativo e incremental através de três papéis principais
(SCHWABER, 2004): Product Owner: representa os interesses de todos no projeto; Time:
desenvolve as funcionalidades do produto; ScrumMaster: garante que todos sigam as regras e
práticas do Scrum, além de ser o responsável por remover os impedimentos do projeto.
Um projeto no Scrum se inicia com uma visão do produto que será desenvolvido
(SCHWABER, 2004). A visão contém a lista das características do produto estabelecidas pelo
cliente, além de algumas premissas e restrições. Em seguida, o Product Backlog é criado
contendo a lista de todos os requisitos conhecidos. O Product Backlog é então priorizado e
dividido em releases.
dezembro/2015
11
Figura 1 - Esqueleto Scrum

Fonte: Scrum Alliance (DUNCAN et al., 2005 apud BALLE, 2011:18)
Observa-se na Figura 1 que, no Scrum, um projeto se inicia com uma visão simples do
produto que será desenvolvido. A visão pode ser vaga a principio e ir tornando-se clara aos
poucos. O Product Owner (PO) então, transforma essa visão em uma lista de requisitos
funcionais e não-funcionais que quando forem desenvolvidos reflitam essa visão. Essa lista,
chamada de Product Backlog é priorizada pelo PO de forma que os itens que gerem maior
valor ao produto tenham maior prioridade.
Projetos Scrum progridem em uma série de Sprints, que são iterações não maiores do que um
mês. No início de um Sprint, os membros da equipe se comprometem a entregar um número
de características que foram listadas no Product Backlog. No final do Sprint, esses recursos
estão feitos - estão codificados, analisados e integrados no produto em desenvolvimento ou
sistema. No final do Sprint há uma revisão durante a qual a equipe demonstra a nova
funcionalidade para o Product Owner e outras partes interessadas que fornecem feedback que
possa influenciar o próximo Sprint (COHN, 2002).
Schwaber (2004) explica que cada Sprint inicia-se com uma reunião de planejamento (Sprint
Planning Meeting), na qual o Product Owner e o Time decidem em conjunto o que deverá ser
implementado (Selected Product Backlog). A reunião é dividida em duas partes. Na primeira
parte (Sprint Planning 1) o Product Owner apresenta os requisitos de maior valor e prioriza
aqueles que devem ser implementados.
O Time então define, colaborativamente, o que poderá entrar no desenvolvimento da próxima
Sprint, considerando sua capacidade de produção. Na segunda parte (Sprint Planning 2), o
time planeja seu trabalho, definindo o Sprint Backlog, que são as tarefas necessárias para
implementar as funcionalidades selecionadas no Product Backlog. Nas primeiras Sprints, é
realizada a maioria dos trabalhos de arquitetura e de infraestrutura. A lista de tarefas pode ser
modificada pelo Time ao longo da Sprint, e as tarefas podem variar entre quatro e dezesseis
horas para a sua conclusão (BARROS et al., 2009).
dezembro/2015
12
Figura 2 - Fluxo do Sprint

Fonte: Libordi; Barbosa (2010, p. 18)
No final da Sprint é realizada a reunião de revisão (Sprint Review Meeting) para que o Time
apresente o resultado alcançado na iteração ao Product Owner. Nesse momento, as
funcionalidades são inspecionadas e adaptações do projeto podem ser realizadas. Em seguida,
o ScrumMaster conduz a reunião de retrospectiva (Sprint Retrospective Meeting), a fim de
melhorar o processo/time e/ou produto para a próxima Sprint (SCHWABER, 2004).
Depois da Sprint Review Meeting e antes do próximo Sprint o Scrum Master se reúne com o
Scrum Team numa última reunião: a Retrospective Meeting. O Scrum Master encoraja o
Scrum Team a revisar as práticas do Scrum e refletir sobre o que precisa ser feito para
melhorar no próximo Sprint.
Juntas, a Sprint Planning Meeting, a Daily Scrum Meeting, a Sprint Review Meeting e a
Sprint Retrospective Meeting implementam as práticas de inspeção e adaptação empíricas
(SCHWABER, 2004).
A finalidade do Scrum é permitir manter o foco na entrega do maior valor de negócio, no
menor tempo possível. Isto permite a rápida e contínua inspeção do software em produção. As
necessidades do negócio é que determinam as prioridades do desenvolvimento de um sistema.
Todos podem ver o software real em produção, decidindo se o mesmo deve ser liberado ou
continuar a ser aprimorado por mais um Sprint.
A equipe Scrum é auto-organizável, e não há nenhum líder geral da equipe que vai
decidir qual pessoa vai fazer qual tarefa ou como um problema será resolvido. Essas
são questões que são decididas pela equipe como um todo. A equipe é
multifuncional e apoiada por dois indivíduos específicos: um Scrum Master e um
Product Owner. O ScrumMaster pode ser visto como um treinador para a equipe,
ajudando os membros da equipe a utilizar o framework Scrum. O Product Owner é
o proprietário do produto e representa a empresa, clientes ou usuários, orientando a
equipe de desenvolvimento na construção do produto correto (BALLE, 2011:31).
O ambiente de trabalho de Scrum é extremamente importante. Ele deve ser aberto, para
facilitar o diálogo da equipe e a auto-organização. O Time deve ter à mão sempre as melhores
dezembro/2015
13
ferramentas possíveis para a realização do trabalho e há mais sucesso se todo o Time ocupar o
mesmo espaço físico, ou seja, se trabalhar na mesma sala (BALLE, 2011).
As práticas de Scrum evoluíram ao longo da sua aplicação em milhares de projetos. É
recomendado que essas práticas sejam aplicadas estritamente, até que seja entendida a forma
como Scrum funciona com a experiência. Quando Scrum estiver funcionando bem, podem ser
feitos ajustes (SCHWABER, 2004).
4.1 Papéis Scrum

O Scrum implementa sua estrutura iterativa e incremental através de três papéis: o Product
Owner, o Team, e o ScrumMaster. Toda responsabilidade no projeto é dividida entre esses
três papéis (SCHWABER, 2004).
O Scrum Master é responsável pelo processo Scrum, por ensiná-lo a todas as pessoas
envolvidas no projeto, por implementá-lo, fazendo dele uma cultura na organização e ainda
por garantir que toda a equipe siga as regras e as práticas do Scrum (SCHWABER, 2004).
Ele também protege a equipe assegurando que ela não se comprometa excessivamente com
relação àquilo que é capaz de realizar durante um Sprint.
O Scrum Master atua como facilitador na Daily Scrum Meeting e torna-se responsável por
remover quaisquer obstáculos que sejam levantados pela equipe durante essas reuniões
(BARROS et al., 2009).
O papel de Scrum Master pode ser exercido por qualquer pessoa da equipe, entretanto é
tipicamente exercido por um gerente de projeto ou um líder técnico.
O Scrum Team é a equipe de desenvolvimento.
Um Scrum Team típico tem de 6 a 10 pessoas auto-organizáveis, autogerenciáveis e
multifuncional (BALLI, 2011). Nela, não existe necessariamente uma divisão funcional
através de papéis tradicionais, tais como programador, designer, analista de testes ou
arquiteto. Todos no projeto trabalham juntos e são responsáveis por completar o conjunto de
trabalho com o qual se comprometem a cada iteração. A equipe não pode ser alterada durante
o Sprint.
Quando é necessário uma equipe maior no Scrum é usando o conceito de Scrum of Scrums.
Cada Scrum Team trabalha normalmente, mas cada equipe também contribui com uma pessoa
que deverá frequentar o Scrum of Scrums Meeting para coordenar o trabalho de múltiplas
equipes Scrum. Esses encontros são análogos aos Daily Scrum, mas não acontecem
necessariamente todos os dias. Fazer essa reunião duas ou três vezes por semana tende a ser
suficiente na maioria das organizações (LIBORDI; BARBOSA, 2010).
O Product Owner é responsável por representar os interesses dos stakeholders no projeto. O
Product Owner é a pessoa que define todos os itens de requisito do projeto numa lista
chamada Product Backlog. Utilizando essa lista ele é responsável por garantir que as
funcionalidades que agreguem maior valor ao produto sejam desenvolvidas primeiro. Isto é
feito através da frequente priorização do Product Backlog para que os itens de maior valor
agregado sejam entregues a cada iteração (SCHWABER, 2004).
dezembro/2015
14
4.3 Artefatos
Dentre os artefatos do Scrum, o Product Backlog é uma lista contendo todas as
funcionalidades desejadas para um produto. O conteúdo desta lista é definido e priorizado
pelo Product Owner. O Product Backlog é totalmente dinâmico, ele é modificado toda vez
que se identifica algo que o produto precisa para ser mais apropriado, competitivo ou
proveitoso (SCHWABER, 2004). Por isso ele nunca está completo, ele sempre contém os
requisitos mais conhecidos e melhores entendidos.
O Sprint Backlog é uma lista de tarefas que o Scrum Team se compromete a fazer em um
Sprint como um potencial incremento de produto entregável (LIBORDI; BARBOSA, 2010).
Os itens do Sprint Backlog são extraídos do Product Backlog, pela equipe, com base nas
prioridades definidas pelo Product Owner e a percepção da equipe sobre o tempo que será
necessário para completar as várias funcionalidades. A quantidade de itens do Product
Backlog que serão trazidos para o Sprint Backlog é definida pelo Scrum Team que se
compromete a implementá-los durante o Sprint. Os itens do Sprint Backlog são divididos em
tarefas com detalhes suficientes para que possam ser executadas em até 16 horas (LIBORDI;
BARBOSA, 2010).
Durante um Sprint, o Scrum Master mantém o Sprint Backlog atualizando-o para refletir que
tarefas são completadas e quanto tempo a equipe acredita que será necessário para completar
aquelas que ainda não estão prontas. A estimativa do trabalho que ainda resta a ser feito no
Sprint é calculada diariamente e colocada em um gráfico, resultando em um Sprint Burndown
Chart (MARQUES, 2012).
O monitoramento do progresso do projeto é realizado através de dois gráficos principais:
Product Burndown Chart e Sprint Burndown Chart. Estes gráficos mostram ao longo do
tempo a quantidade de trabalho que ainda resta ser feito, sendo um excelente mecanismo para
visualizar a correlação entre a quantidade de trabalho que falta ser feita (em qualquer ponto) e
o progresso do time do projeto em reduzir este trabalho.
4.4 Cerimônias
A Sprint Planning Meeting é uma reunião na qual estão presentes o PO, o Scrum Master e o
Scrum Team. Durante esta reunião o PO descreve as funcionalidades de maior prioridade para
a equipe (MARQUES , 2012).
Essa reunião, que deve ser de 8 horas, é dividida em duas partes (SCHWABER, 2004):
 nas primeiras 4 horas o PO apresenta os itens de maior prioridade do Product Backlog para
a equipe. O Scrum Team faz perguntas para entender melhor as funcionalidades e ser capaz
de quebrar as funcionalidades em tarefas técnicas que irão dar origem ao Sprint Backlog e
então definem colaborativamente o que poderá entrar no desenvolvimento do próximo
Sprint, considerando o tamanho da equipe, a quantidade de horas disponíveis e a
produtividade do Scrum Team.
 durante as próximas 4 horas o Scrum Team planeja seu trabalho, definindo o Sprint
Backlog, que são as tarefas necessárias para implementar as funcionalidades selecionadas
no Product Backlog
dezembro/2015
15
A cada dia do Sprint o Scrum Master realiza uma reunião de 15 minutos com o Scrum Team.
Essa reunião, chamada Daily Scrum Meeting, tem como objetivo disseminar informações
sobre o estado do projeto
As Daily Scrum Meetings devem ser realizadas no mesmo lugar, na mesma hora do dia.
Idealmente são realizados na parte da manhã, para ajudar a estabelecer as prioridades do novo
dia de trabalho (MARQUES , 2012). Embora qualquer pessoa possa participar da reunião,
somente os membros do Scrum Team estão autorizados a falar
Cada membro do Scrum Team deve então responder cada uma destas três perguntas: O que
você fez ontem? O que você fará hoje? Há algum impedimento no seu caminho?
Concentrando-se no que cada pessoa fez ontem e no que ela irá fazer hoje, a equipe ganha
uma excelente compreensão sobre que trabalho foi feito e que trabalho ainda precisa ser feito.
A Daily Scrum Meeting não é uma reunião de status na qual um chefe fica coletando
informações sobre quem está atrasado. Ao invés disso, é uma reunião na qual os membros da
equipe assumem compromissos perante os demais.
Os impedimentos identificados na Daily Scrum Meeting devem ser tratados pelo Scrum
Master o mais rapidamente possível.
O Daily Scrum não deve ser usado como uma reunião para resolução de problemas. Questões
levantadas devem ser levadas para fora da reunião e normalmente tratadas por um grupo
menor de pessoas que tenham a ver diretamente com o problema ou possam contribuir para
solucioná-lo.
No final do Sprint a Sprint Review Meeting é realizada. Essa reunião é planejada para ser
realizada em no máximo 4 horas. Nesta reunião o Scrum Team mostra o que foi desenvolvido
durante o Sprint. Tipicamente, isso tem o formato de uma demonstração das novas
funcionalidades.
Durante a Sprint Review Meeting, o projeto é avaliado em relação aos objetivos do Sprint,
determinados durante a Sprint Planning Meeting. Idealmente, a equipe completou cada um
dos itens do Sprint Backlog.
A Sprint Retrospective Meeting é uma reunião de 3 horas [4] que ocorre ao final de um Sprint
depois da Sprint Review Meeting e serve para identificar o que funcionou bem, o que pode ser
melhorado e que ações serão tomadas para melhorar.
5. Extreme Programming
De acordo com Don Wells em sua página de referência sobre XP (Extreme Programming)
(WELLS, 2009), Extreme Programming é um dos vários processos ágeis populares; já foi
provado ser muito bem sucedido em muitas empresas de todos os tamanhos e indústrias do
mundo inteiro.
Extreme Programming enfatiza o trabalho em equipe. Os gerentes, clientes e desenvolvedores
são todos parceiros iguais em uma equipe colaborativa. Extreme Programming implementa
um ambiente simples, mas eficaz, que permite as equipes tornam-se altamente produtivas. A
equipe se auto-organiza em torno do problema para resolvê-lo o mais eficientemente possível.
dezembro/2015
16
Extreme Programming melhora um projeto de software em quatro formas essenciais:

comunicação, simplicidade, feedback e respeito. Esses são os pilares sobre os quais a
metodologia XP é sustentada (BECK, 1999 apud BALLE, 2011):
 Comunicação: A maioria dos problemas que ocorrem nos projetos invariavelmente tem sua
causa associada ao fato de alguém não ter informado alguma coisa muito importante para
umapessoa que precisava saber. Dessa forma, a comunicação é o valor de maior
importância no XP;
 Simplicidade: A simplicidade não é fácil. Uma das coisas mais difíceis de se fazer é não
olhar para as coisas que serão necessárias implementar no dia seguinte, na semana seguinte
e no mês seguinte. Deve ser implementado apenas aquilo que é necessário e realmente
importa ser construído. Isto significa dizer que as pessoas só devem se preocupar em
solucionar hoje os problemas de hoje. A complexidade custa muito caro e tentar prever o
futuro é muito difícil. É necessário aguardar o futuro para ver se está certo ou não.
 Feedback: A veracidade dos relatórios do estado atual das atividades é extremamente
importante em XP. Feedback significa perguntar e aprender com as respostas. A única
forma de saber a necessidade do cliente é perguntando a ele. O único modo de saber se um
código faz o que ele se destina fazer é testando-o. Quanto mais cedo se obter o feedback,
mais tempo se terá disponível para reagir. A metodologia XP fornece um feedback rápido e
frequente por parte dos seus seguidores.
 Coragem: Depois de se falar nos três valores, comunicação, simplicidade e feedback, é
hora de se esforçar como nunca antes. Se o trabalho não for desempenhado na sua
velocidade mais rápida possível, alguém mais o irá fazer, e ele vai lucrar no lugar. A
coragem significa tomar as decisões na hora em que elas precisam ser tomadas. Se uma
funcionalidade não está funcionando, ela deve ser consertada. Se algum código não parece
estar bem escrito, ele deve ser refatorado. Se não será possível entregar tudo o que se havia
prometido dentro do prazo acordado, o cliente deve ser informado. A coragem é uma
virtude difícil de se aplicar. Ninguém gosta de estar errado ou quebrar um acordo. O único
modo de consertar um engano é admitir que houve um engano e consertá-lo.
Programadores de um time que implementa Extreme Programming constantemente se
comunicam com seus clientes e colegas programadores (BECK, 1999 apud BALLE, 2011).
Eles mantêm seu design simples e limpo, entregam o sistema para os clientes o mais cedo
possível e implementam mudanças. Cada pequeno sucesso aprofunda seu respeito para as
contribuições únicas de cada membro da equipe. Com essa fundação, programadores Extreme
são capazes de responder com coragem a novos requisitos e tecnologia (WELLS, 2009).
Extreme Programming (XP) é apoiado em práticas que formam a metodologia. A maioria das
práticas XP também pode ser adotada por desenvolvedores individualmente. Devido ao fato
da metodologia XP ser muito bem detalhada e explicada, e não existir grandes dificuldades
em seguir suas práticas, entretanto, é extremamente difícil e arriscado seguir todas as práticas
rigorosamente e ao pé da letra de uma única vez (CARVALHO; RABCHINI JR 2007).
Cada prática pode desempenhar vários papéis. Por exemplo, o teste influencia o projeto da
solução e encoraja a execução de pequenos experimentos controlados.
dezembro/2015
17
Apenas escolher algumas práticas XP ao acaso, sem antes entender a relação existente entre
elas, pode levar a resultados desastrosos. Por exemplo, um refinamento de código sem que
tenha sido realizada uma rigorosa fase de testes anteriormente poderá resultar na introdução
de defeitos tão sutis dentro do código que poderiam levar a extensas sessões de depuração
para sua correção.
6. Critérios utilizados
Os critérios adotados para servirem de base para a identificação das atividades propostas pelos
Métodos Ágeis são as atividades sugeridas pelo Desenvolvimento Incremental. Sommerville
(2003) afirma que os métodos ágeis são fundamentados no Desenvolvimento Incremental. E
conforme puderam ser observado, as atividades sugeridas durante o seu processo de
desenvolvimento são bastante semelhantes aos Princípios Ágeis. No Desenvolvimento
Incremental (Figura 4) os clientes inicialmente identificam, em um esboço, os requisitos do
sistema e selecionam quais são os mais e os menos importantes. Em seguida é definida uma
série de iterações de entrega, onde em cada uma é fornecido um subconjunto de
funcionalidades executáveis, dependendo das suas prioridades.
Figura 4 – Desenvolvimento Incremental

Fonte: Adaptado de Sommerville (2003)
Após a identificação dos incrementos, as funcionalidades a serem entregues na primeira

iteração são detalhadas e desenvolvidas. Paralelamente a este desenvolvimento, outras
funcionalidades podem ser analisadas para fazerem parte dos outros incrementos. Uma vez
que cada incremento é concluído e entregue, os clientes podem colocá-lo em operação. O fato
dos clientes poderem experimentar o sistema gradualmente facilita o esclarecimento das
funcionalidades para os incrementos subsequentes e à medida que novos incrementos são
concluídos, eles são integrados às iterações existentes, de modo que o sistema melhora a cada
novo incremento entregue (SOMMERVILLE, 2003).
7. Metodologia
dezembro/2015
18
A metodologia em um projeto de pesquisa se refere ao “[...] procedimento em que se explora

a realidade, por meio de uma atividade que se volte para soluções de problemas práticos ou
teóricos com base de esclarecimentos dos processos científicos” (GIL, 2010:19).
Segundo Vergara (2009), as principais finalidades de uma pesquisa são as seguintes:
descrição, explicação e exploração. A autora comenta que a maioria dos estudos tem mais de
um objetivo e às vezes todos os três. O presente estudo foi realizado por meio de um
levantamento bibliográfico, com características de uma pesquisa descritiva e exploratória.
Segundo Gil (2010), uma pesquisa descritiva analisa aspectos de grupos relevantes. Por sua
vez, o estudo exploratório suscita novas possibilidades que mais tarde serão exploradas em
pesquisas mais controladas.
A pesquisa bibliográfica, de caráter exploratório-descritivo foi abordada com a finalidade de
incorporar uma revisão de literatura para subsidiar teoricamente este artigo. Este tipo de
pesquisa nada mais é do que saber quais os métodos utilizados em investigações similares e
averiguar o melhor para ser aplicado através da busca de uma problematização de um projeto
de pesquisa (VERGARA, 2009).
Esta foi realizada a partir de referências publicadas, analisando e discutindo as contribuições
culturais e cientificas. A consulta de fontes consiste na identificação das fontes documentais
(documentos audiovisuais, documentos cartográficos e documentos textuais), na análise das
fontes e no levantamento de informações (reconhecimento das ideias que dão conteúdo ao
documento). Para tanto, utilizou-se de livros, artigos científicos, revistas especializadas e
periódicos, dentre outras fontes de pesquisa, como a Internet.
8. Conclusão
Buscou-se, ao longo deste estudo, fazer um levantamento bibliográfico dos benefícios das
metodologias ágeis no gerenciamento de projetos. A partir do posicionamento dos autores
pesquisados foi possível identificar que as práticas apontadas pelas metodologias ágeis
apresentadas são eficientes para desenvolver sistemas, desde que usadas corretamente.
As metodologias ágeis surgem de uma mesma motivação e apresentam as principais ideias em
comum. O que identifica cada uma de forma unívoca é a forma de implementar as ideias através
de práticas para o dia a dia. Cada conjunto de práticas deve ser examinado de maneira isolada,
conforme feito neste trabalho, para verificar sua eficiência.
De uma maneira geral, pelo levantamento bibliográfico apresentado neste artigo, pode-se entender
que, para o desenvolvimento de software, as metodologias baseadas em processos adaptativos têm
potencial de apresentar resultados melhores que os resultados apresentados pelas metodologias
baseadas em processos preditivos. Para as pessoas que desenvolvem o sistema, as metodologias
orientadas a pessoas apresentam melhores condições de trabalho e melhores resultados que as
metodologias orientadas a processos.
Os resultados destacam que metodologias ágeis têm sido bem aceitas pela indústria de
software e por pesquisadores da Engenharia de Software, quando comparadas com as
metodologias tradicionais, devido aos resultados satisfatórios. Dentre seus benefícios,
constatou-se que os métodos utilizados para desenvolvimento de software podem ser
considerados um diferencial que promete aumentar a satisfação do cliente agregando maior
dezembro/2015
19
valor ao produto final, produzindo software alta qualidade e acelerando os prazos de

desenvolvimento de projetos.
A conclusão deste estudo evidencia indícios da forma como o mercado utiliza e encara as
metodologias ágeis nos dias atuais. Com isso, favorece a revisão constante dos conceitos da
teoria, possibilitando maior ênfase aos que são largamente utilizados com resultados
satisfatórios,de modo a filtrar e propor transformações aos que estão tornando-se arcaicos por
falta de aplicação.
Diante disso, considera-se que o objetivo a que se propôs este estudo foi alcançado, embora,
caiba ressaltar que o assunto não se esgota no tempo. Ao contrário, a sensação que se tem no
encerramento do artigo é de que a mesmo foi apenas um primeiro passo onde tantos outros
poderão ser dados.
Referências
ANDERSON, C. Free: Grátis – O futuro dos preços. 1. ed. Rio de Janeiro: Ed. Campus,
2009.
BALLE, A. R. Análise de Metodologias Ágeis: Conceitos, Aplicações e Relatos sobre XP e

Scrum. 2011. 79f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)
– Instituto de Informática, Universidade Federal do Rio Grande do Sul (UFRS), Porto Alegre,
2011.
BARROS, P. V. A. et al. SCRUM: Uma metodologia ágil para projetos WEB com pequenas
equipes. In: IX Jornada de Ensino, Pesquisa e Extensão (JEPEX 2009). IX Jornada de
Ensino, Pesquisa e Extensão, Universidade Federal Rural de Pernambuco, Serra Talhada,
2009.
COHN, Mike. Introduction to Scrum - An Agile Process. Mountain Goat, Lafayette, 2002.
Disponível em: <http://www.mountaingoatsoftware.com/topics/scrum>. Acesso em: 13 abr.
2015.
CÔRTES, M. L.; CHIOSSI, T.C. S.. Modelos de Qualidade de Software. Campinas:

Unicamp, Instituto de Computação, 2001.
DUNCAN, S. et al. Scrum Is An Inovattive Approach to Make Things Done. Scrum Alliance,
Indianapolis, 2005. Disponível em: <http://www.scrumalliance.org/learn_about_ scrum>.
Acesso em: 11 abr. 2015.
GIL, A. C. Métodos e técnicas de pesquisa social. 5. ed. São Paulo: Atlas, 2010.
HARVARD BUSSINESS SCHOOL. Implementando a inovação. Tradução de Carlos

Cordeiro de Mello. Rio de Janeiro: Elsevier/Campus, 2007.
dezembro/2015
20
LIBORDI, P. L. O.; BARBOSA, V. Métodos Ágeis. 2010. 35f. Artigo (Especialização em

TI) - Faculdade de Tecnologia – FT, Universidades Estadual de Campinas, 2010.
LUDVIG, D.; REINERT, J. D. Estudo do uso de metodologias ágeis no desenvolvimento de

uma aplicação de Governo Eletrônico. 2007. 157fl. Trabalho de Conclusão de Curso
(Bacharelado em Sistema de Informação) - Departamento de Informática e Estatística,
Universidade Federal de Santa Catarina (UFSC), Florianópolis, 2007.
MARQUES, A. N. Metodologias ágeis de desenvolvimento: processos e comparações.

2012. Monografia (Graduação em Tecnologia da Informação) – Faculdade de Tecnologia de
São Paulo, São Paulo, 2012.
NETO, O. N. S. Análise comparativa das metodologias de desenvolvimento de softwares

tradicionais e ágeis. Trabalho de Conclusão de Curso. Universidade da Amazônia. Belém:
2004.
PMBOK. Um Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK®) –

4. ed. Newtown Square: Project Management Institute, 2012.
PMBOK. Um Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK®) –

5. ed. Newtown Square: Project Management Institute, 2013.
PMI. Integração Nacional, Programa dos Capítulos do PMI. Disponível em: . Acesso em:
15 nov. 2010.
PRESSMAN, R. S. Engenharia de Software. 6. ed. São Paulo: Ed.Mc Graw Hill, 2007.
RABECHINI, R.; CARVALHO, M. M. Construindo competências para gerenciamento de

projetos. 2. ed. São Paulo: Atlas, 2008.
SCHWABER, K. Agile Project Management With Scrum. Microsoft Press, 2004.

disponível em: < <http://www.scrum.org/>. Acessado em 27 mar. 2015.
SALLES JÚNIOR., C. A. C.; SOLER, A. M.; VALLE, J. A. S.; RABECHINI JR., R.

Gerenciamento de riscos em projetos. Rio de Janeiro: Editora FGV, 2006.
SILVA, W. S. Gestão de risco nas organizações de base tecnológica. 2008. 117f.

Dissertação (Mestrado em Gestão, Pesquisa e Desenvolvimento em Tecnologia Farmacêutica) -
associação entre a Universidade Católica de Goiás, Universidade Estadual de Goiás e o Centro
Universitário de Anápolis. Goiânia, 2008.
SOARES, M. S. Comparação entre metodologias ágeis e tradicionais para o

desenvolvimento de software. 2004. Disponível em: <http://www.dcc.ufla.br/
infocomp/artigos/v3.2/art02.pdf> . Acessado em 29 mar. 2015.
dezembro/2015
21
SOMMERVILLE, I. Engenharia de software. São Paulo: Addison-Wesley, 2003.
VARGAS, R. V. Gerenciamento de projetos: estabelecendo diferenciais competitivos. Rio

de Janeiro: Brasport, 2006.
WELLS, D. Extreme Programming: A Gentle Introduction. Extreme Programming. 2009.

Disponível em: <http://www.extremeprogramming.org/>. Acesso em: 12 abr. 2013.
VERGARA, S. C. Projeto e relatório de pesquisa em administração. São Paulo: Atlas,

2009.

Greick Roger de Carvalho Lima 10814317 PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Greick Roger de Carvalho Lima 10814317 PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Benefícios das metodologias ágeis no gerenciamento de projetos de Tecnologia da Informação (TI)

Benefícios das metodologias ágeis no gerenciamento de projetos de

Greick Roger de Carvalho Lima - greickroger@yahoo.com.br

Na atualidade, muitas empresas, de diversos segmentos, reconhecendo a importância da

mediante consultas em material já existente, constituído de livros e artigos científicos,

executadas na mesma sequência em todos os projetos. As dez áreas de conhecimento abordam

 Partes Interessadas: Processos que identificam todas as pessoas, grupos ou organizações

3. Metodologias de desenvolvimento de Software

Metodologias de desenvolvimento de Software (ou Processo de Software) é o conjunto de

 Desenvolvimento do software: projeto e implementação do software, o sistema é

 Validação do software: o software é validado para garantir que as funcionalidades

 Evolução do software: evolução do software conforme a necessidade de cliente.

O desafio mais comum do Desenvolvimento de Software é entregar um produto que atenda as

3.1 Metodologias tradicionais

3.2 Metodologias ágeis

de desenvolvimento de software colocou em discussão a proposta de como melhorar o

 Indivíduos e interação entre eles são mais que processos e ferramentas;

Agile Modeling ajuda a encontrar o meio-termo entre os extremos em que as formas

Pode-se, inclusive, simplesmente seguir as diretrizes do próprio Manifesto,

Figura 1 - Esqueleto Scrum

Figura 2 - Fluxo do Sprint

4.1 Papéis Scrum

Extreme Programming melhora um projeto de software em quatro formas essenciais:

Figura 4 – Desenvolvimento Incremental

Após a identificação dos incrementos, as funcionalidades a serem entregues na primeira

A metodologia em um projeto de pesquisa se refere ao “[...] procedimento em que se explora

valor ao produto final, produzindo software alta qualidade e acelerando os prazos de

BALLE, A. R. Análise de Metodologias Ágeis: Conceitos, Aplicações e Relatos sobre XP e

CÔRTES, M. L.; CHIOSSI, T.C. S.. Modelos de Qualidade de Software. Campinas:

HARVARD BUSSINESS SCHOOL. Implementando a inovação. Tradução de Carlos

LIBORDI, P. L. O.; BARBOSA, V. Métodos Ágeis. 2010. 35f. Artigo (Especialização em

LUDVIG, D.; REINERT, J. D. Estudo do uso de metodologias ágeis no desenvolvimento de

MARQUES, A. N. Metodologias ágeis de desenvolvimento: processos e comparações.

NETO, O. N. S. Análise comparativa das metodologias de desenvolvimento de softwares

PMBOK. Um Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK®) –

PMBOK. Um Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK®) –

RABECHINI, R.; CARVALHO, M. M. Construindo competências para gerenciamento de

SCHWABER, K. Agile Project Management With Scrum. Microsoft Press, 2004.

SALLES JÚNIOR., C. A. C.; SOLER, A. M.; VALLE, J. A. S.; RABECHINI JR., R.

SILVA, W. S. Gestão de risco nas organizações de base tecnológica. 2008. 117f.

SOARES, M. S. Comparação entre metodologias ágeis e tradicionais para o

SOMMERVILLE, I. Engenharia de software. São Paulo: Addison-Wesley, 2003.

VARGAS, R. V. Gerenciamento de projetos: estabelecendo diferenciais competitivos. Rio

WELLS, D. Extreme Programming: A Gentle Introduction. Extreme Programming. 2009.

VERGARA, S. C. Projeto e relatório de pesquisa em administração. São Paulo: Atlas,

Você também pode gostar