FANESE – Faculdade de Administrações e Negócios de Sergipe
Núcleo de Pós-Graduação e Extensão – NPGE
MBA em GERENCIAMENTO DE PROJETOS
HIRAM DE OLIVEIRA COSTA-SILVA
APLICAÇÃO DE METODOLOGIAS DE GERENCIAMENTO DE
PROJETOS EM EMPRESAS DE DESENVOLVIMENTO DE
SOFTWARE
Aracaju/SE
6 de agosto de 2012

HIRAM DE OLIVEIRA COSTA-SILVA
APLICAÇÃO DE METODOLOGIAS DE GERENCIAMENTO DE
PROJETOS EM EMPRESAS DE DESENVOLVIMENTO DE
SOFTWARE
Artigo apresentado como pré-requisito parcial
para conclusão da disciplina Metodologia dos
Trabalhos Acadêmicos do Curso de Pós–
graduação em MBA em Gerenciamento de
Projetos da Faculdade de Administração e
Negócios de Sergipe - FANESE.
Avaliador:
Prof. M.Sc. Fernando Ferreira da Silva Júnior
Aracaju/SE
6 de agosto de 2012

APLICAÇÃO DE METODOLOGIAS DE GERENCIAMENTO DE
PROJETOS EM EMPRESAS DE DESENVOLVIMENTO DE
SOFTWARE
Hiram de Oliveira Costa-Silva1
RESUMO
A Gerência de Projetos é uma área que vem crescendo sobremaneira no dia-a-dia das
empresas e corporações que querem se manter no mercado, isso se deve à existência de
uma constante preocupação com prazos, custos, escopo e qualidade. Os altos custos,
prazos não cumpridos, produtos entregues fora do escopo definido e sem a qualidade
esperada pelos stakeholders são os maiores problemas encontrados pela maioria das
organizações no presente, com isso a entrega do produto final ao cliente obedecendo a
tríplice restrição(escopo, prazo e custo) e com a qualidade esperada pelos stakeholders
nem sempre é alcançada e o principal motivo por não atendermos as suas expectativas é a
falta de um planejamento adequado para fazermos com que as expectativas sejam supridas.
Pensando nisso e diante dos fatos apresentados, foram criadas diversas metodologias para
gerenciamento de projetos e demonstraremos como a metodologia de gerenciamento de
projetos PMBOK e a metodologia de gerenciamento ágil, SCRUM, podem auxiliar na
entrega dos produtos dentro dos prazos, custos, escopo e qualidade definidos no
planejamento. Apresentaremos também, suas características, vantagens e desvantagens,
aplicação prática, a importância e papel das partes interessadas do projeto, stakeholders, e
como o uso destas podem oferecer uma melhoria no processo de análise de sistemas.
Mostraremos ao final um estudo de caso com aplicações práticas das metodologias e a
utilização do PMBOK e SCRUM em conjunto em um projeto de desenvolvimento de
software.
Palavras-chave: Gerenciamento de Projetos. PMBOK. SCRUM.
ABSTRACT
The Project Management is an area that has grown enormously in day-to-day business and
corporations who want to stay in the market, this is due to the existence of a constant
preoccupation with deadlines, cost, scope and quality. The high costs, missed deadlines,
products delivered outside the defined scope and without the quality expected by
stakeholders are the major constraints faced by most organizations in the present, thereby
delivering the finished product to customers complying with the triple constraint (scope, time
and cost) and with the quality expected by stakeholders is not always achieved and the main
reason for not heed their expectations is the lack of adequate planning to do with that
expectations are met. Thinking about it and before the facts presented were created several
methodologies for project management and demonstrate how the methodology of project
management PMBOK and agile management methodology, SCRUM, can assist in delivering
products on time, cost, scope and quality defined planning. Also present, its characteristics,
advantages and disadvantages, practical application, the importance and role of project
stakeholders, stakeholders, and how the use of these may offer an improvement in the
process of systems analysis. Show the end a case study with practical applications of the
1
Hiram de Oliveira Costa-Silva é Graduado em Gestão da Tecnologia da Informação pela Faculdade
de Administração e Negócios de Sergipe e pós-graduando em MBA em Gerenciamento de Projetos
pela faculdade de Administração e Negócios de Sergipe

3
methodologies and the use of SCRUM and PMBOK together in a software development
project.
Keywords: Management of Projects. PMBOK. SCRUM.

4
1 INTRODUÇÃO
Em um mercado cada vez mais competitivo e globalizado, a crescente
preocupação com a entrega dos produtos com a qualidade esperada está cada vez
mais em evidência. Nenhuma organização conseguirá enfrentar as diversas
mudanças sem um planejamento eficiente. Para se manter no mercado com um
preço e qualidade competitivos não podemos mais entregar qualquer produto, sem
estimar custos e prazos, sem uma formalização de todo projeto, das
responsabilidades individuais, dos riscos e ativos necessários para executar os
projetos. Com isso precisou-se, principalmente no Brasil, que tem uma cultura de
“fazejamento” (fazer sem planejamento com isso a medida que vai fazendo irá se
planejando), uma busca contínua por metodologias de gerenciamento de projetos.
Segundo o Guia PMBOK 4ª Edição, gerenciamento de projetos é “[...] a
aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades do
projeto a fim de atender aos seus requisitos. [...]”.
A utilização das boas práticas no gerenciamento de projetos traz grandes
benefícios para a organização, entre eles a redução de custos, prazos mais
concretos para entregas de produtos, prevenindo a super alocação de recursos,
evitando esses desperdícios fazemos com que o produto seja mais confiável, os
stakeholders passam a acreditar mais no trabalho de toda a equipe e os entregáveis
são de qualidade, pois quando se há uma formalização de todos processos e o
escopo bem definido não teremos surpresas e descontentamentos ao entregarmos
os pacotes do produto, gerando maior participação, satisfação e fidelização por parte
do cliente.
O PMI, Project Management Institute (Instituto de Gerenciamento de
Projetos), traz em seu guia PMBOK que o projeto é “[...] um esforço temporário
empreendido para criar um produto, serviço ou resultado exclusivo. [...]”.
Por ter uma natureza temporária, o projeto indica início e fim definidos no
escopo do projeto. Ao se fazermos o Termo de Abertura do Projeto deixamos claro
as premissas e restrições existentes e que servirão de base para modelarmos todo
planejamento do projeto. Nenhum projeto é igual ao outro, por mais coincidências
que possam existir sempre haverá particularidades que devem ser consideradas

5
para não corrermos riscos desnecessários podendo até levar ao fracasso, frustrando
assim, as expectativas dos stakeholders.
Será que todas as empresas de desenvolvimento de software, sem a
utilização das metodologias de gerenciamento de projetos, conseguem entregar o
projeto – produto final - de acordo com a qualidade esperada, e superar as
expectativas dos stakeholders?
A resposta é muito pouco provável. Vemos no mundo atual que mesmo
com um planejamento eficaz, escopo, prazos e custos bem definidos nem sempre o
projeto chega ao final superando as expectativas dos stakes (chamaremos
simplesmente stakeholders de stakes, para identificar as partes interessadas no
projeto). O uso das metodologias de gerenciamento de projetos é de suma
importância no cotidiano e ciclo de vida dos produtos.
Nosso objetivo com esse trabalho é mostrar a utilização prática da
metodologia tradicional de gerenciamento de projetos, Guia PMBOK e a metodologia
ágil, apresentada com o Guia do SCRUM, apresentaremos também, suas
importâncias nas fases dos projetos, características, vantagens e desvantagens e
principalmente como podemos utilizar processos dos dois guias para planejarmos,
executarmos e entregarmos um projeto com a maior qualidade possível afim de,
atender as expectativas dos stakes.
Com uma abordagem diferenciada e texto de fácil compreensão,
esperamos prender a atenção dos profissionais para poderem absorver ao máximo
cada conceito e cada aplicação das metodologias afim de, após a leitura poder
desenvolver papéis importantes no gerenciamento de projetos das organizações em
que trabalham.

6
2 O GUIA PMBOK
Criado e desenvolvido pelo PMI (Project Management Institute), que fez a
sua primeira publicação em 1987, batizando-o como Guia PMBOK, A Guide to the
Project Management Body of Knowledge. Sua primeira tradução para o português foi
em 1996, chamado de Um Guia para o Conhecimento em Gerenciamento de
Projetos. O guia teve outras publicações e atualmente encontra-se na 4ª edição,
porém a 5ª edição está em desenvolvimento e em breve será lançada. A cada
edição, o PMI teve o cuidado de se adequar às atividades que ocorriam no mundo
dos projetos, fazendo com que ele se tornasse o mais próximo da realidade de
projetos.
Atualmente, a 4ª Edição do Guia PMBOK tem nove áreas de
conhecimentos e 42 processos divididos de acordo com sua área de conhecimento,
conforme a seguir:
 Gerenciamento de Integração: é responsável por integrar todas as
áreas relevantes para a organização do projeto;
 Gerenciamento do Escopo: é responsável por todas as informações
importantes e o trabalho necessário para que o projeto seja bem sucedido;
 Gerenciamento do Tempo: é a área responsável por gerenciar todos os
prazos, gerenciando com que o projeto termine dentro dos limites de tempos
acordados;
 Gerenciamento de Custos: é responsável por controlar e gerenciar a
parte financeira referente ao projeto, fazendo com que o projeto termine com os
custos conforme definido no termo de abertura;
 Gerenciamento de Qualidade: é a área que controla a qualidade do
produto/serviço final, utilizando ferramentas e técnicas para garantir o acordado;
 Gerenciamento de Recursos Humanos: é uma das áreas mais
importantes e mais difíceis de gerenciar, Cuida do gerenciamento das pessoas
envolvidas no projeto a fim de aperfeiçoar a gestão delas dentro do projeto;

7
 Gerenciamento de Comunicações: tem o papel importante dentro do
projeto, quanto melhor esse gerenciamento for, melhores serão os resultados ao
final de cada fase até a entrega do projeto final;
 Gerenciamento de Riscos: é responsável por identificar e gerenciar
todos os riscos, positivos e negativos, dentro do projeto. Ele identificará os riscos,
apontarão os responsáveis e ações para minimizar o impacto dos mesmos;
 Gerenciamento de Aquisições: é responsável pela aquisição de
produtos e serviços para execução do projeto e, ao final, deverá gerenciar e finalizar
os contratos.
[...] O principal objetivo do Guia PMBOK é identificar o subconjunto
do Conjunto de conhecimentos em gerenciamento de projetos que é
amplamente reconhecido como boa prática.
"Identificar" significa fornecer uma visão geral, e não uma descrição
completa. "Amplamente reconhecido" significa que o conhecimento e
as práticas descritas são aplicáveis à maioria dos projetos na maior
parte do tempo, e que existe um consenso geral em relação ao seu
valor e sua utilidade. "Boa prática" significa que existe acordo geral
de que a aplicação correta dessas habilidades, ferramentas e
técnicas podem aumentar as chances de sucesso em uma ampla
série de projetos diferentes. Uma boa prática não significa que o
conhecimento descrito deverá ser sempre aplicado uniformemente
em todos os projetos; a equipe de gerenciamento de projetos é
responsável por determinar o que é adequado para um projeto
específico. [...] (PMBOK, 2004, p. 3).
Para cada área de conhecimento existem diversas entradas e saídas.
Todas as áreas de conhecimento do Guia PMBOK geram documentos, formais, que
serão empregados conforme o andamento do projeto. Essas áreas são importantes
porque regulamentam todas as ações e dão um horizonte de como fazer para seguir
gerenciando um ou vários projetos, independente de tamanho, tipo ou área que esse
projeto se aplique. Atualmente, o guia mais seguido e respeitado na área de
gerenciamento de projetos é o Guia PMBOK. Porém, segui-lo não indica que seu
projeto terá 100% de eficiência e alcançará todas as expectativas descritas no
Termo de Abertura do Projeto, mas minimizará consideravelmente as chances de
fracasso se seguido corretamente.

8
3 METODOLOGIAS ÁGEIS
Segundo a Agile Alliance, as definições modernas de desenvolvimento de
software ágil evoluíram a partir da metade de 1990. Inicialmente, métodos ágeis
eram conhecidos como métodos leves. Em 2001, membros da comunidade se
reuniram e adotaram o nome de métodos ágeis, tendo publicado o Manifesto Ágil,
um documento que reúne os princípios e metodologia de desenvolvimento ágil.
O Agilemanifesto.org descreve o Manifesto para desenvolvimento de
software ágil sendo:
[...] Estamos descobrindo maneiras melhores de desenvolver
software, fazendo-o nós mesmos e ajudando outros a
fazerem o mesmo. Através deste trabalho, passamos a valorizar:
Indivíduos e interações 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
Ou seja, mesmo havendo valor nos itens à direita,
valorizamos mais os itens à esquerda. [...]
Hoje existem diversas metodologias ágeis de desenvolvimento de
software que tem por objetivo acelerar o processo de desenvolvimento do produto.
Essas metodologias tentam minimizar o risco pelo desenvolvimento de software em
períodos curtos de tempo, iteração, geralmente levam de uma até quatro semanas.
3.1 SCRUM
No Guia do SCRUM, Schwaber (2009) explica que o SCRUM não é uma
metodologia nem um processo e, sim, uma framework onde se podem empregar
diversos processos e técnicas. O SCRUM é baseado em processos empíricos, pois
sua abordagem é iterativa e incremental. O SCRUM é bastante utilizado no
desenvolvimento de projetos de software ágil que tem como objetivo entregar o
máximo de valor de negócio possível no menor tempo, focado no ROI (retorno de
investimento).
Ao utilizar o SCRUM, foca-se principalmente no produto, não na
documentação, e isso é um dos motivos que o diferencia tanto do Guia PMBOK. No

9
SCRUM, os projetos são divididos em ciclos – de uma a quatro semanas –
chamados de Sprints. Este é formado por um conjunto de atividades que serão
entregues ao final do sprint e todos do time têm responsabilidade pela entrega ou
não do sprint.
Uma grande vantagem na utilização desse framework é que caso surja
uma necessidade de modificação no produto que não foi planejado e não estava na
lista de atividades, pode-se fazer a alteração e implementação ao produto como um
todo sem grandes custos. Em outras metodologias tradicionais, quando se faz
qualquer modificação no projeto, a depender do estágio em que ele se encontre, fica
inviável implementar a nova necessidade, pois o foco dessas metodologias são o
planejamento, e conforme o projeto se desenvolve, cada modificação onera muito o
projeto inicial.
3.1.1 TERMOS E PAPÉIS COM SCRUM
Na utilização do framework SCRUM, têm-se diversos termos e papéis que
devem ser identificados e descritos para que se entenda todo o ciclo de
desenvolvimento.
Tudo que será implementado durante cada SPRINT são descritos e
fixados no PRODUCT BACKLOG, onde são descritos todos os itens que serão
implementados nesse sprint. Cada item receberá uma pontuação, que definirá o
tempo que a tarefa levará para ser executada e o grau de dificuldade da mesma.
Cada time trabalha de uma forma para pontuar essas atividades. Na reunião de
planejamento da Sprint, cada integrante do time dará uma nota para cada atividade
identificada no product backlog e, ao final, será feita uma média. Essa avaliação é
feita de maneira secreta, para que um profissional com mais qualidade e/ou
experiência não influencie em um com menor experiência e/ou qualidade. O Product
Owner (PO) é o responsável por fazer esse levantamento das atividades, e no
decorrer dos sprints, ele poderá ir modificando o product backlog; ele é o
responsável por priorizar os itens e a equipe que definirá quais itens caberão no
sprint. A cada ciclo do desenvolvimento do software essas atividades se repetem.

10
É feito diariamente uma reunião para alinhamento e acompanhamento do
desenvolvimento dos itens do Sprint Backlog. Essa reunião dura, no máximo, 15
minutos e tem por objetivo acompanhar o andamento das atividades de cada um do
time. Como diariamente se tem um Scrum Daily Meeting, monitora-se com maior
eficiência o andamento do cronograma e atividades para que não chegue ao final do
Sprint e o time não entregue o que foi prometido. Todos se monitoram e fiscalizam-
se em todas as fases do ciclo, com isso o empenho e responsabilidade sob o sprint
é por igual e naturalmente serão entregues os produtos em todos os sprints e será
alcançada as expectativas dos stakes.
Segundo o Scrum Guide, o time Scrum é composto pelo Product Owner,
a Equipe de Desenvolvimento e o Scrum Master. Os times são auto-organizáveis e
multifuncionais. Com isso, as equipes escolhem a melhor forma de trabalharem para
completarem seu trabalho da forma mais eficaz e possuem todas as competências
necessárias para concluírem os sprints sem a necessidade da ajuda de outras
pessoas que não fazem parte do time. A seguir, o papel de cada um do time:
Product Owner (PO) é um papel que sempre estará presente nos ciclos
do projeto. Ele é quem representa o cliente, quem cria o Product Backlog e quem
define as atividades de cada sprint e define as prioridades.
Scrum Master é o responsável pelo ambiente, responsável por garantir
que o Scrum seja aprendido e aplicado, responsável por fazer com que a teoria seja
aplicada na prática. Ele ajuda as partes interessadas a entenderem as iterações e os
ciclos para otimizar as ações do Time Scrum.
A Equipe de Desenvolvimento consiste nos melhores profissionais, aptos
a trabalharem com o framework Scrum, são auto-organizáveis, multifuncionais. São
compostas por 5 a 10 pessoas, são auto-gerenciáveis e tem habilidades suficientes
para não necessitarem de ajuda de outros profissionais e sabem da
responsabilidade que tem em todo o projeto e atuam em conjunto para entregarem o
produto em todos os ciclos do sprint dentro dos prazos acordados na Reunião de
Planejamento da Sprint.

11
4 CASE DE USO: INTERAÇÃO PMBOK X SCRUM
Este caso de uso tem objetivo mostrar como a Ágape Sistemas e
Tecnologia, desenvolve seus sistemas, aplicando as ferramentas e processos da
metodologia Pmbok e o framework Scrum.
4.1 AMBIENTE ENCONTRADO
A Ágape Sistemas e Tecnologia é uma empresa que atua no mercado
desde 1999, no segmento de software house. Seus principais clientes estão na área
pública e, em sua maioria, são prefeituras, fundos municipais de saúde, fundos de
assistência social e câmaras municipais. Com sede em Aracaju e negócios em
Sergipe, Bahia e Alagoas, a Ágape Sistemas e Tecnologia é reconhecida pelos
serviços prestados e pelo pacote de sistemas ofertado.
A empresa está inserida há mais de 10 anos, atua como uma Fábrica de
Software on demand, desenvolvendo softwares em Delphi e Java, banco de dados
Firebird e Postgress, sistema operacional Windows. Os sistemas da Ágape Sistemas
e Tecnologia atende toda a demanda do mercado com sistemas de Gerenciamento
de Almoxarifado, Gerenciamento de Patrimônio, Contabilidade, Folha de
Pagamento, Controle de Frota e Abastecimento, Sistema de Digitalização, Sistema
de Ordem de Pagamento, Sistema de Protocolo, Sistema de Licitação, Sistema de
Ação Social, Sistema Tributário Municipal, entre outros.
Como a área de tecnologia é uma área em constante atualização, fez-se
necessário atualizar alguns softwares desenvolvidos na linguagem de programação
Delphi, e os mesmo estão sendo convertidos para a linguagem web Java.
A empresa conta com analistas de suporte, analistas de desenvolvimento,
gestores de projetos, analista de negócio, gerente de desenvolvimento e suporte,
técnicos de helpdesk e suporte, além de diversos colaboradores nas áreas
administrativas.

12
4.2 SITUAÇÃO ATUAL E APLICAÇÃO DA TEORIA NA PRÁTICA
Hoje, a Ágape Sistemas e Tecnologia desenvolve sob demanda. Com a
necessidade de atualização e integração dos sistemas desktops, viu-se a
necessidade e oportunidade de se integrar os sistemas e fazer um grande sistema
com alguns módulos. Foi neste momento que surgiu o AgLogistica. O AgLogistica é
um sistema que fará a integração e atualização de dois sistemas desktops
desenvolvidos em Delphi para a linguagem Java. Os sistemas são AgPatri e
AgAlmox, Sistema de Controle de Patrimônio e Sistema de Controle de
Almoxarifado, respectivamente.
O AgLogistica, além de fazer a integração desses dois sistemas citados
acima, acrescenta um módulo de compras/licitação. Com isso, poderá vender o
sistema para atender diversas necessidades, entre elas do setor de compras e
licitação, do setor de patrimônio e do setor de almoxarifado.
Ao surgir essa oportunidade e necessidade, foi feita a primeira reunião
para formalização do Termo de Abertura e definiu-se as responsabilidades do
Gerente de Desenvolvimento e Gerente de Suporte, Scrum Master e Product Owner,
respectivamente, do Sponsor (no caso o gestor da empresa) e da Equipe de
Desenvolvimento. A partir desse primeiro Meeting, todos passaram a ter papéis
definidos e responsabilidades na entrega do produto, tudo formalizado no Termo de
Abertura do Projeto AgLogistica.
Foi feita, então, uma reunião para levantamentos das necessidades e
requisitos do sistema. Nesse momento, o Gerente de Suporte e o Gestor assumiram
o papel de cliente. Foi realizado um levantamento de requisitos, e o Gerente de
Desenvolvimento, com papel de Scrum Master, ficaria responsável por criar um
Plano de Gerenciamento do Projeto que incluiria o cronograma do projeto, escopo e
a EAP, determinaria os custos e os recursos humanos e materiais que o projeto
necessitaria para ser executado.
Após a aprovação do Plano de Gerenciamento do Projeto, o Scrum
Master, juntamente com a Equipe de Desenvolvimento, começou a colocar em
prática o cronograma desenvolvido. Foi feita uma Reunião Sprint Planning Meeting,
onde o Gerente de Suporte, no papel de Product Owner, juntamente com a Equipe

13
de Desenvolvimento, determinaram quais as atividades eram mais prioritárias e qual
o grau de dificuldade de cada uma. Para determinar o grau de dificuldade de cada
atividade do Product Backlog, foi realizado uma votação, onde cada um da equipe
de desenvolvimento colocaria uma pontuação (1, 3 ou 5, a depender do grau de
dificuldade que cada um achar que a atividade tem). Para não sofrer influência dos
mais experientes ou dos que tem mais conhecimento sobre a linguagem, cada um
dá uma nota para a atividade de maneira secreta e, ao final, é feita uma média para
se identificar qual atividade é mais complexa e demoraria mais. Com isso, seria
empregado o colaborador com mais experiência e/ou conhecimento para realizar
essa atividade. Quando o Backlog do Sprint está pronto, é colocado no Whiteboard
todas as atividades do Sprint com suas durações e os responsáveis para que seja
visto e executado no decorrer do Sprint.
O mais interessante de se utilizar o framework Scrum é que todos os
envolvidos se sentem responsáveis pelo projeto e, conforme é feito os Daily Meeting
e o Scrum Master escuta o andamento do Sprint, eles se sentem “donos do projeto”
e quem cobra para o produto ser entregue são os próprios colaboradores que
participam da equipe de desenvolvimento, pois todos sabem a importância de
entregarem o produto dentro do prazo estipulado e com a qualidade esperada para
suprir as expectativas dos stakes.
Mesmo utilizando o framework Scrum, também é utilizado alguns
processos da metodologia contida no Guia Pmbok, formalizando o projeto conforme
aconselhado nas boas práticas do Pmbok, e também tem-se uma equipe com alto
desempenho para entregar o produto conforme exposto no Guia Scrum.

14
5 CONSIDERAÇÕES FINAIS
Durante vários anos convivemos na área de projetos de softwares com as
metodologias tradicionais, até então as únicas alternativas para a prática do
gerenciamento de projetos. Com a necessidade e exigências cada vez maiores dos
clientes e as demanda atual não podemos fazer com que os projetos de
desenvolvimento “travem” nas burocracias das metodologias clássicas, com isso as
metodologias ágeis surgem para auxiliar e atuam, muitas vezes, em conjunto para
garantir que exista uma formalização e uma produção de alto desempenho,
garantindo a segurança e eficiência de todo processo de desenvolvimento de
software.
Devido esse ambiente de alta competitividade e complexidade as
empresas buscam melhorar seus processos e se tornar mais competitivas no
mercado. O framework SCRUM tem seus processos focado nas pessoas,
valorizando sempre o trabalho em equipe, comunicação, feedback e a metodologia
descrita no PMBOK tem seus processos voltado a um planejamento bem elaborado
utilizando as 9 (nove) áreas de conhecimento. O potencial encontrado adequando os
processos das duas metodologias é surpreendente e faz com que o processo de
desenvolvimento dos softwares ocorra de maneira simples, com qualidade, rapidez e
alinhado às necessidades reais de seus usuários. A organização do trabalho faz
com que as atividades ocorram de maneira interativa e sempre fará com que os
sistemas sejam reavaliados de acordo com as necessidades dos usuários,
aproximam as partes interessadas do processo de desenvolvimento e contam com
uma participação efetiva de todos envolvidos.
Por fim, utilização de cada metodologia depende muito do software e das
necessidades dos clientes, você poderá utilizar todos os processos de cada
metodologia ou somente os que mais adequarem ao projeto que será desenvolvido.
Qualquer metodologia, seja ágil ou tradicional, só será eficiente se empregada de
maneira correta de forma a atender as necessidades da equipe e superar as
expectativas de todos stakeholders.

15
6 REFERÊNCIAS
AGILE ALLIANCE. Manifesto para desenvolvimento Ágil. Disponível em:
<http://www.agilemanifesto.org/iso/ptbr/>. Acesso em: 03 abr. 2012.
PROJECT MANAGEMENT INSTITUTE - PMI. Um Guia do Conjunto de
Conhecimentos em Gerenciamento de Projetos (PMBOK). 4. ed. 2008.
SHWABER, Ken. O Guia do Scrum. 2011. Disponível em:
<http://www.scrum.org/storage/Scrum%20Guide%202011%20-%20PTBR.pdf>. Acesso
em: 19 mar. 2012.
SOARES, Michel dos Santos. Comparação entre Metodologias Ágeis e Tradicionais
para o Desenvolvimento de Software. UFBA: 2004. Disponível em:
<http://wiki.dcc.ufba.br/pub/Aside/ProjetoBitecIsaac/Met._Ageis.pdf>. Acesso em: 18
mar. 2012.