SlideShare uma empresa Scribd logo
A síndrome da ‘Bala de Prata’ na gestão de projetos de TI
                                 Autoria: Flávia Cruz Pereira
                                   flav_cp@yahoo.com.br

Resumo
       Tendo em vista a situação do mercado atual onde o foco está cada vez mais voltado
para minimizar os custos, as organizações buscam de forma incessante formas para viabilizar
esse objetivo e, em contrapartida, alcançar mais e mais o seu Return of Investiment (ROI).
Para que isso seja possível na prática, faz-se necessária a utilização de práticas de gestão de
projetos para garantir que essa engrenagem funcione devidamente. Com isso a pesquisa
procura desmistificar o mito da ‘Bala de Prata’ demonstrando que a prática de gestão de
projetos a ser utilizada deve estar bem vinculada com a estratégica da organização e em
conformidade com a necessidade do cliente para garantir uma maior agilidade na sua
execução com eficiência e eficácia, atrelada à restrição tripla do projeto: prazo, custo e
escopo, não deixando de manter o padrão de qualidade necessário para garantir a sua
competitividade.
Palavras-chave: Gestão de Projetos, Agilidade, Qualidade.
1 Introdução
       Na Engenharia de Software, o termo ‘Bala de Prata’ vem sendo utilizado como
direcionamento para uma solução definitiva do problema: método ou forma capaz de resolver
um problema independente de qual seja a sua natureza. Assim como na Engenharia de
Software, na Gestão de Projetos, o termo também vem sendo muito utilizado e discutido.
        Com o cenário mercadológico em constante mudança devido às inovações
tecnológicas que nos bombardeiam quase que diariamente, as organizações precisam mais do
que nunca se adequar para garantir a sua competitividade com o foco cada vez mais voltado
para o Return on investiment (ROI) e com isso vêm empregando grandes esforços para a
melhoria de seus resultados agregados aos resultados dos seus clientes. Para isso, faz-se mais
que necessário investir para desenvolver produtos e/ou serviços com qualidade respeitando a
restrição tripla do projeto: prazo, custo e escopo. Com isso, acredita-se que com um bom
processo a chance de se obter o sucesso dos projetos é claramente maior. A síndrome da ‘Bala
de Prata’ em gestão de projetos - metodologia que garanta o sucesso de um projeto faz com
que especialistas discutam qual é a melhor prática a ser usada com base nesse contexto. De
acordo com o Project Management Institute (PMI, 2008), o nível estratégico (alta
administração) das organizações vem percebendo os benefícios do uso de boas
práticas/metodologias para gerir seus projetos. Estudos comprovam a viabilidade do uso
atrelada ao alinhamento estratégico para maximizar o ROI:




                                                                                              1
Figura 1 – % de Sucesso e Insucesso de projetos conforme aderência/resistência
                             Fonte: Desenvolvido pelo autor.
         As práticas mais utilizadas no mercado atualmente são: Guide to the Project
Management Body of Knowledge (PMBOK® Guide) desenvolvido pelo Project Management
Institute (PMI) - um framework de padrões de boas práticas de gestão de projetos que
descreve normas, métodos, processos e práticas estabelecidas e o SCRUM - um processo ágil
que permite manter o foco na entrega do maior valor de negócio, no menor tempo possível
(AMBLER, 2008).
        Com base nessa premissa, esta pesquisa pretende traçar um comparativo entre essas
boas práticas mais difundidas para que seja possível verificar suas características em comum o
que possibilita a convivência de ambas em um mesmo ambiente organizacional,
demonstrando que não existe uma receita de sucesso para o projeto baseado apenas em uma
boa prática utilizada. Sendo assim, o objetivo deste artigo é demonstrar a relação entre as
práticas do PMBOK® Guide e SCRUM na gestão de projetos em TI, descrevendo suas
características predominantes e traçando um paralelo entre elas - apresentando os benefícios
com a sua aderência e perspectivas.
2 Referencial Teórico
2.1 Porque aplicar a gestão de projetos
        Projetos existem para viabilizar as estratégias da organização traduzidas através de
seus objetivos. Com isso, as organizações buscam a aplicação de metodologias ou práticas
para atingirem as expectativas de todos os envolvidos/interessados no projeto. Essa aplicação
nada mais é do que criar um processo de padronização da forma de trabalhar para alcançar os
objetivos propostos respeitando a restrição tripla do projeto: prazo, custo e escopo –
garantindo a qualidade (CARNEIRO, 2006 e KING, 1992). Com base nessas premissas, a
organização deve aplicar uma prática/metodologia de gestão de projetos que seja alinhada
com a sua estrutura: funcional, matricial ou projetizada bem como a sua cultura, em
conformidade com o seu planejamento estratégico.
        Gestão de Projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas
às atividades do projeto a fim de atender seus requisitos. (PMBOK® Guide, 2008)
        Segundo o Standish Group (2006), organizações americanas gastam mais de US$ 275
bilhões a cada ano em projetos de desenvolvimento de software. Muitos desses projetos irão
falhar, e o caos se deve na maioria das vezes à falta ou mal uso de uma gestão de projetos. Em
conseqüência disso, produzem-se softwares em estoque com um escopo mal planejado, onde
na maioria das vezes todas as funcionalidades levantadas não são utilizadas (CHAIRMAN,
2006).

                                                                                            2
Figura 2 – Funcionalidades desenvolvidas X % Uso
                             Fonte: Standish Group, 2006.
2.1.1 PMI e o PMBOK® Guide
        O Project Management Institute (PMI), fundado em 1969 e sediado na Pensilvânia -
USA, é a mais importante organização internacional sem fins lucrativos que reúne
profissionais que trabalham com gestão de projetos de diversas áreas. Com o intuito de
documentar e padronizar todo o processo de gestão de projetos, o instituto publicou o Guide to
the Project Management Body of Knowledge (PMBOK® Guide), que vêm sofrendo
adequações a fim de se obter uma melhoria contínua na forma de gerir projetos. O PMBOK®
Guide nada mais é do que um guia com um conjunto de boas práticas para gestão de projetos.
Na versão mais atualizada – 2008, estão integrados 42 processos de gestão agrupados em 5
grupos de processos/fases envolvendo 9 áreas de conhecimento.
       Os processos são agrupados em 5 categorias – ou grupo de processos:
           1. Iniciação
           2. Planejamento
           3. Execução
           4. Monitoramento e controle
           5. Encerramento
        Segundo D’ÁVILA (2010), os grupos de processos de gestão de projetos têm relação
com o conceito do Ciclo PDCA (Plan – Planejar, Do – Fazer, Check – Verificar e Act – Agir).
O grupo de Planejamento corresponde ao Planejar; Execução, ao Fazer; e Monitoramento e
Controle englobam Verificar e Agir. Além desses processos, o PMBOK® Guide ainda
caracteriza os grupos de processos de Iniciação e Encerramento, pois o projeto apresenta um
ciclo finito.




                             Figura 3 – Overlap dos processos em um projeto
                             Fonte: PMBOK® Guide, 2008.




                                                                                            3
Ainda conforme D’ÁVILA (2010), o PMBOK® Guide aborda 9 áreas de
conhecimento. É uma descrição das entradas, ferramentas e técnicas; e saídas geradas
conforme os processos que abrangem cada área. São elas:
       1. Gestão do Escopo: Inclui os processos necessários para assegurar que o projeto
          inclui todo o trabalho necessário, e somente o trabalho necessário, para completar
          o projeto com sucesso.
       2. Gestão do Tempo: Inclui os processos necessários para assegurar o planejamento e
          execução do projeto em um prazo adequado.
       3. Gestão de Custos: Inclui os processos necessários para assegurar que o projeto
          possa ser executado dentro do orçamento aprovado.
       4. Gestão da Qualidade: Inclui os processos necessários para assegurar que o projeto
          vai satisfazer as necessidades para as quais foi concebido.
       5. Gestão de Integração: Inclui os processos necessários para assegurar a unificação,
          consolidação, articulação e ações integradoras que são essenciais para o término do
          projeto, para atender com sucesso às necessidades do cliente e de outras partes
          interessadas e para gerenciar as expectativas.
       6. Gestão de Comunicações: Inclui os processos necessários para assegurar a
          adequada geração, disseminação e armazenamento de informações do projeto.
       7. Gestão de Riscos: Inclui os processos relacionados com a identificação, análise e
          estabelecimento de contramedidas para os riscos do projeto.
       8. Gestão de Recursos Humanos: Inclui os processos necessários para que se faça o
          melhor uso dos recursos humanos envolvidos no projeto.
       9. Gestão de Aquisições: Inclui os processos necessários para a aquisição de bens e
          serviços fora da organização executora do projeto.
        Cada processo se caracteriza por suas entradas, técnicas e ferramentas e saídas que são
retroalimentados em um ciclo contínuo – onde saídas podem alimentar a entradas do próximo
processo. Além disso, as áreas de conhecimento abrangem diversos processos, onde o escopo,
tempo, custo e qualidade são os principais focos para o objetivo do projeto. Essas premissas
são necessárias para garantir a qualidade e recursos humanos, aquisições, comunicações e
riscos são elementos aos quais deve haver constante atenção em um projeto. E Integração
abrange a sincronização com todas as outras áreas.




                             Figura 4 – Sinergia das áreas de conhecimento
                             Fonte: Márcio D'Ávila, 2010.
2.1.2 Metodologia ágil e o manifesto ágil
      É indiscutível o fato de que as organizações estão buscando todas as formas para
minimizar seus custos. O cenário mercadológico atual faz com que cada vez mais as

                                                                                             4
organizações invistam em práticas que minimizem seus custos e maximizem o ROI para se
manterem competitivas. Nesse contexto, as metodologias ágeis – como o próprio nome já diz,
pregam a agilidade, estão ganhando mais e mais espaço dentro das organizações (AMBLER,
2008). A metodologia ágil prevê iterações contínuas em prazos curtos ao decorrer de todo o
projeto, visando garantir maior controle e previsibilidade.
       Em fevereiro de 2001, dezessete agilistas se reuniram e discutiram uma alternativa
para a e melhoria de processos que já existiam até então. Com a colaboração de todos, foram
levantados alguns princípios relacionados à agilidade (SCHWABER, Ken et al., 2001):
       •   Maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de
           software de valor;
       •   Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos
           ágeis se adequam a mudanças, para que o cliente possa tirar vantagens
           competitivas;
       •   Entregar software funcionando com freqüência, na escala de semanas até meses,
           com preferência aos períodos mais curtos;
       •   Pessoas relacionadas a negócios e desenvolvedores devem trabalhar em conjunto e
           diariamente, durante todo o curso do projeto;
       •   Construir projetos ao redor de indivíduos motivados, dando a eles o ambiente e
           suporte necessário confiando que farão seu trabalho;
       •   O método mais eficiente e eficaz de transmitir informações para, e por dentro de
           um time de desenvolvimento, é através de uma conversa cara a cara;
       •   Software funcional é a medida primária de progresso;
       •   Processos ágeis promovem um ambiente sustentável. Os patrocinadores,
           desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos
           constantes;
       •   Contínua atenção a excelência técnica e bom design aumentam a agilidade;
       •   Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser
           feito;
       •   As melhores arquiteturas, requisitos e designs emergem de times auto-
           gerenciáveis; e
       •   Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se
           ajustam e otimizam seu comportamento de acordo.
       A partir daí, nasceu o manifesto ágil, que prega que:
       •   Indivíduos e interação entre eles mais que processos e ferramentas;
       •   Software em funcionamento mais que documentação abrangente;
       •   Colaboração com o cliente mais que negociação de contratos; e
       •   Responder a mudanças mais que seguir um plano.
       Ou seja, mesmo havendo valor nos itens à direita, os itens à esquerda são mais
valorizados.



                                                                                            5
Segundo a Scrum Alliance (organização para promover, apoiar e gerar recursos aos
‘agilistas’ - termo usado para designar os adeptos da metodologia), existem várias
metodologias no mercado atualmente, mas a mais utilizada vem sendo o Scrum.
2.1.2.1 Scrum
       Em 1993, Jeff Sutherland, Ken Schwaber e John Scumniotales usaram o Scrum pela
primeira vez na organização Easel Corporation, incorporando os conceitos da metodologia
ágil Lean. A partir disso, fundaram a Scrum Alliance. Após dois anos, Ken Schwaber
formalizou a nova metodologia e ajudou a divulgá-la para as organizações voltadas,
principalmente, para o desenvolvimento de software.
        Segundo SCHWABER (2004), o nome Scrum vem da prática esportiva Rugby que
significa uma jogada envolvendo todos para que façam força simultaneamente para que
possam pegar a bola do time adversário.
        Abstraindo o conceito para o mundo dos softwares, o Scrum é um processo empírico
de gestão e controle de projetos. De acordo com COHN (2010), a metodologia crê que devido
à complexidade, escopo, mudanças de requisitos, urgência e necessidade de demonstrar valor
(ROI) mais rápido, fica quase inconcebível desenvolver software utilizado o modelo cascata,
ou seja, desenvolver todo o software de uma única vez. Com isso, o desenvolvimento iterativo
e incremental é uma estratégia de planejamento (que segue alinha dividir para conquistar),
onde o software é construído em partes, ou seja, em Sprints (iterações), onde a cada Sprint tem
como meta a entrega de valor (parte do software funcional) até completar o software.
       Ainda segundo COHN (2010), para garantir o controle e previsibilidade desse
processo, existem as cerimônias:
       1. Reunião Diária: é um encontro entre o Scrum Master, o Time e qualquer pessoa
          interessada no projeto com o timebox (tempo) de 15 minutos onde cada membro do
          time dará as suas impressões a respeito do projeto, respondendo a três perguntas
          importantes:
                  a. O que eu fiz desde a última reunião diária?
                  b. O que eu pretendo fazer até amanhã?
                  c. Tem alguma coisa impedindo o meu trabalho?
       2. Planejamento da Sprint: esta reunião ocorre no primeiro dia de cada Sprint. É
          dividida em duas partes: no primeiro momento o Product Owner, o Scrum Master
          e o Time discutem sobre as funcionalidades potencialmente designadas para a
          determinada Sprint e no segundo momento, o Scrum Master e o Time estimam o
          tempo para o desenvolvimento de cada funcionalidade através da Planning Poker
          (prática que auxilia na estimativa das funcionalidades pontuando o seu tamanho
          conforme a série de Fibonacci).
       3. Revisão da Sprint: esta reunião ocorre no último dia da Sprint e representa o
          momento que o Time e o Scrum Master demonstram o seu desempenho através do
          Burndown Chart e as funcionalidades potencialmente entregáveis executadas para
          o Product Owner e demais interessados, se houver.
       4. Retrospectiva da Sprint: é uma reunião entre Scrum Master e o Time onde duas
          perguntas são feitas:
                  a. O que foi bom durante a Sprint? (Interno: Time/ Externo: Product
                     Owner)

                                                                                             6
b. O que pode ser melhorado? (Interno: Time/ Externo: Product Owner)
          A partir daí é elaborado um plano de ação para atacar o que pode ser melhorado
          na próxima Sprint.
   Contemplam os artefatos:
   1. Product Backlog: lista de funcionalidades a serem desenvolvidas ao longo do
      projeto distribuídas em Sprints.
   2. Sprint Backlog: lista de funcionalidades detalhadas no dia de planejamento
      envolvendo o Product Owner, o Scrum Master, o Time e demais interessados, a
      serem desenvolvidas ao longo da Sprint. O mundo ideal seria ter o maior nível de
      detalhes para poder mensurar a complexidade das atividades para que se possa
      fazer estimativas mais assertivas e garantir uma boa velocity do Time – garantindo
      a boa produtividade e uma boa previsibilidade das entregas.
   3. Burndown: gráfico demonstrativo do andamento das atividades da Sprint
      (Planejado X Realizado) a ser acompanhado durante todo o projeto e exibido na
      Revisão da Sprint. O andamento do projeto estará diretamente relacionado à boa
      gestão do controle da produtividade do Time.
   Existem os papéis:
1. Product Owner (PO): pode ser o financiador ou um importante interessado no projeto.
   Suas principais responsabilidades são: definir as funcionalidades do produto;
   concentrar as informações vindas de usuários, stakeholders ou do mercado de maneira
   que se obtenha uma visão única dos requisitos do sistema; priorizador do Product
   Backlog; ter autonomia para alterar as prioridades fora da Sprint.
2. Scrum Master (SM): desempenha o papel de líder, gerenciando os interesses do
   Product Owner mediante o Time. Numa abordagem tradicional, o Scrum Master seria
   um Gerente de Projetos, porém, essa nomenclatura foi substituída para diferenciar o
   foco de liderança necessário para que um processo empírico funcione. Suas principais
   responsabilidades são: Atuar como facilitador; Remover Impedimentos; Garantir que o
   processo está sendo respeitado; Auxiliar o Product Owner a maximizar o ROI a cada
   entrega ao fim das Sprints.
3. Equipe Scrum (Time): Grupo de profissionais especialistas diretamente ligados ao
   trabalho a ser feito para garantir a entrega do projeto com todas as suas
   funcionalidades necessárias. Suas principais características são: Multifuncional;
   Formado por até 7 pessoas; Auto-gerenciável.




                                                                                      7
Figura 8 – A engrenagem Scrum
                                Fonte: Mike Cohn, 2010.
3 Paralelo PMBOK® Guide X Scrum
3.1 Procedimentos Metodológicos
       Através de uma leitura, análise e interpretação do material bibliográfico estudado
relacionado às duas metodológicas abordadas, esta pesquisa pretende dar uma resposta para
uma questão que vêm sendo abordada em vários fóruns relacionados à gestão de projetos.
Baseando no conteúdo abordado, a idéia é agregar o conhecimento voltado para a
possibilidade de gerar uma discussão para se chegar a um discernimento para a construção de
fundamentos e opiniões próprias. O estudo comparativo entre as práticas do PMBOK® Guide
e do Scrum permite que se faça uma análise aberta das diferenças, semelhanças, aderências e
perspectivas através das informações analisadas e propostas.
4 Análise de Dados
       No cenário de mercado atual, é possível perceber que as organizações de diversas áreas
de negócio vêm investindo cada vez mais na gestão de projetos. Mas ainda sim, podemos
perceber que os adeptos de metodologias ágeis estão mais concentrados em um nicho de
mercado: TI. Levando em consideração estruturas organizacionais projetizadas – onde a
autonomia de tomada de decisões dos responsáveis está diretamente relacionada aos projetos,
mas acima de tudo respeitando as estratégias da organização, podemos perceber que ainda sim
existem algumas semelhanças entre as formas de gestão descritas anteriormente apesar de
terem um direcionamento e origem distintos:
         Características                     PMBOK® Guide                           Scrum
Ter definido a priori                 Escopo.                             Tempo (Sprints).
Responsável pela organização          Gerente de Projetos.                Scrum Master.
executora para atingir os objetivos
do projeto
Principais artefatos                  WBS (Work Breakdown Structure)      Product Backlog e Sprint
                                      e Plano do Projeto.                 Backlog.
Grupo de Programa/ Projetos           Programa/ Portifólio de Projetos.   Scrum of Scrums.
Freqüência de Reuniões de status      Dependendo da complexidade/         Diárias.
                                      necessidade do projeto, alinhar a
                                      freqüência.
Start-Up do projeto                   Reunião de Kick-off.                Planejamento da Sprint.


                                                                                                     8
Entrega do produto              No encerramento do projeto.         Entregáveis Parciais
                                                                    conforme priorização (por
                                                                    Sprints).
Encerramento do Projeto         Lições aprendidas.                  Retrospectiva da Sprint.
Principais Ferramentas de       EVA (Estimated Value                Burndown Chart.
Indicadores de Desempenho       Agregated), Gráficos e Relatórios
                                via MSProject, Curva S, Status
                                Report.
Escopo                          Definido na fase de Início do       Definido de forma macro na
                                projeto e formalizado através da    fase de Início do projeto.
                                WBS (Work Breakdown                 No Planejamento da Sprint
                                Structure).                         os requisitos são detalhados
                                                                    e priorizados.
Tempo                           Detalhado para a realização do      Detalhado e orientado a
                                projeto como um todo.               entregas (por Sprints).
Custo                           Monitoração constante para não      Maior controle em função
                                aferir o custo planejado.           da agilidade de se
                                                                    incorporar mudanças.
Qualidade                       Constante verificação e validação   Constante verificação e
                                das saídas dos processos.           validação das atividades
                                                                    durante a Sprint.
Riscos                          Análise e controle dos riscos em    Análise e controle dos
                                todo o ciclo de vida do projeto.    riscos em todo o ciclo de
                                                                    vida do projeto.
Comunicação                     Formal e documentada.               Colaborativa.
Recursos Humanos                Papéis bem definidos.               Equipe multidisciplinar e
                                                                    auto-gerenciável.
Aquisição                       Controle por contrato bem           Informal e volátil.
                                definido e documentado.
Integração                      Plano do Projeto detalhado e       Facilitação.
                                monitorado durante todo o projeto.
                           Tabela 1 – PMBOK® Guide X Scrum.
                              Fonte: Desenvolvido pelo autor.
       Com base no levantamento das informações supracitadas, é possível perceber que
ambas as metodologias possuem características muito semelhantes – pois metodologias
nascem para melhorar as que já existem. Nesse caso, porém, cada uma possui um
direcionamento: enquanto as práticas do PMBOK® Guide pregam a interação da organização
em um nível mais estratégico e formal, o Scrum norteia a operacionalização do processo da
gestão de projetos de maneira informal e colaborativa. Sendo assim, é possível dizer que,
diante dessa análise, o Scrum é indiretamente uma forma customizada das boas práticas
abordadas no PMBOK® Guide – mesmo que o Scrum não seja originada diretamente do
PMBOK® Guide. As práticas podem ser complementares, onde pontos falhos de uma podem
ser supridos por pontos fortes da outra. Ainda sim, ao passo que o Scrum prega que sua
aplicação tenha que necessariamente estar em conformidade com a forma que é proposta, ou
seja, by the book, o PMBOK® Guide dá o livre arbítrio ao gerente de projetos com a
colaboração da equipe, definir os processos apropriados a serem utilizados no projeto de
acordo com sua visibilidade e complexidade.
5 Considerações Finais
      A gestão de projetos é definitivamente um dos caminhos mais indicados para se obter
melhores resultados, mas é preciso utilizá-lo de maneira adequada às necessidades de cada

                                                                                                9
projeto. O processo não deve ser engessado, deve ser um apoio para garantir que seja
intrínseco às atividades que irão ser desenvolvidas ao longo do projeto e esse suporte dará
condições efetivas para que as organizações conquistem seus objetivos estratégicos. Para isso,
é preciso também considerar as características próprias de capa projeto: o escopo, o custo, o
prazo, a natureza, a complexidade e a importância do projeto respeitando a cultura, o processo
e a estratégia de negócios da organização. Além disso, é de extrema importância selecionar as
ferramentas, métodos e técnicas mais adequadas para cada situação. As organizações não
devem se deixar levar pelo modismo ou pensar que pode dar certo se já existe outra
organização trabalhando de determinada maneira. Esse é um processo de constante
aprendizagem e entendimento da necessidade e estrutura da organização, seus clientes e o
mercado. Não há uma fórmula de sucesso, ou seja, a síndrome da bala de prata da melhor
metodologia em gestão de projetos não passa de uma lenda. Cabe às pessoas abstraírem o
melhor de cada uma em benefício da organização e em conseqüência de seus projetos. Esse é
um caminho a ser seguido que visa sinergizar a melhoria contínua com o uso de ferramentas,
métodos e técnicas que envolvem um processo de gestão de projetos com qualidade para
garantir o diferencial competitivo – envolvendo o nível estratégico, tático e operacional da
organização, para alinhar as necessidades/ expectativas – Planejamento Estratégico, com a
operacionalização das ações estratégicas como meio de alcançar os objetivos para se atingir os
resultados com o ROI esperado.
Referências bibliográficas
- AMBLER, S. W., “Has Agile Peaked?”. Disponível em: <http://www.drdobbs.com/>.
Acesso em: 26/04/2010.
- CARNEIRO, Margareth F.S., “Metodologia de Gerenciamento de Projetos”. Disponível em:
<http://www.pmkb.com.br>. Acesso em: 26/04/2010.
- CHAIRMAN, J. J. Standish Group Study                        Reported.    Disponível     em:
<http://www.standishgroup.com>. Acesso em: 26/04/2010.
-    COHN,     Mike.,     “Uma      introdução   ao     Scrum”.           Disponível      em:
<http://www.mountaingoatsoftware.com>. Acesso em 26/04/2010.
- D’ÁVILA, Márcio. “PMBOK® Guide e Gerenciamento de Projetos”.
Disponível em:     <http://www.mhavila.com.br/topicos/gestao/pmbok.html>.       Acesso    em:
26/04/2010.
- KING, David., “PROJECT MANAGEMENT MADE SIMPLE - A Guide to Successful
Management of Computer Systems Projects”. ISBN: 0137177291, Prentice Hall, 1992.
- PMI – Project Management Institute, “Um Guia do Conhecimento em Gerenciamento de
Projetos – PMBOK® Guide – Quarta Edição”. ISBN: 9781933890708., PMI, 2008.
- PMI – Project Management Institute. Disponível em: <http://www.pmi.org>. Acesso em
18/05/2010.
- SCHWABER, Ken et al., “O manifesto ágil”. Disponível em: <http://agilemanifesto.org/>.
Acesso em: 26/04/2010.
- SCHWABER, Ken., “Agile Project Management with Scrum”. ISBN: 073561993x.,
Microsoft Press, 2004.
- SCRUM – Scrum Alliance. Disponível em: <http://www.scrumalliance.org>. Acesso em
26/04/2010.


                                                                                           10

Mais conteúdo relacionado

Mais procurados

Artigo - Implantação do escritório de projetos - Aragon salvador
Artigo - Implantação do escritório de projetos - Aragon salvadorArtigo - Implantação do escritório de projetos - Aragon salvador
Artigo - Implantação do escritório de projetos - Aragon salvador
Aragon Vieira
 
00 apresentação (1)ukjghnsdgvr
00   apresentação (1)ukjghnsdgvr00   apresentação (1)ukjghnsdgvr
00 apresentação (1)ukjghnsdgvr
Wagner Santiago
 
Gestão do Conhecimento aplicada à Gestão de Projetos
Gestão do Conhecimento aplicada à Gestão de ProjetosGestão do Conhecimento aplicada à Gestão de Projetos
Gestão do Conhecimento aplicada à Gestão de Projetos
Beatriz Benezra Dehtear, MBA
 
Palestra Gerenciamento de Projetos sempre agrega, seja qual for o seu negócio
Palestra Gerenciamento de Projetos sempre agrega, seja qual for o seu negócioPalestra Gerenciamento de Projetos sempre agrega, seja qual for o seu negócio
Palestra Gerenciamento de Projetos sempre agrega, seja qual for o seu negócio
CRA - MG
 
Webinar gestão de mudanças organizacionais - o fator humano na liderança de ...
Webinar  gestão de mudanças organizacionais - o fator humano na liderança de ...Webinar  gestão de mudanças organizacionais - o fator humano na liderança de ...
Webinar gestão de mudanças organizacionais - o fator humano na liderança de ...
Projetos e TI
 
Passo a passo_gerente_projeto
Passo a passo_gerente_projetoPasso a passo_gerente_projeto
Passo a passo_gerente_projeto
gtiprotec
 
Winning.catálogo.formação
Winning.catálogo.formaçãoWinning.catálogo.formação
Winning.catálogo.formação
carla_madeira
 
Palestra perspectivas para 2011 - Aula inaugural IBEC/INPG 2011
Palestra perspectivas para 2011 - Aula inaugural IBEC/INPG 2011Palestra perspectivas para 2011 - Aula inaugural IBEC/INPG 2011
Palestra perspectivas para 2011 - Aula inaugural IBEC/INPG 2011
Vitor Vargas
 
Macrosolutions Consultoria: Otimização de Recursos e Investimentos através do...
Macrosolutions Consultoria: Otimização de Recursos e Investimentos através do...Macrosolutions Consultoria: Otimização de Recursos e Investimentos através do...
Macrosolutions Consultoria: Otimização de Recursos e Investimentos através do...
Macrosolutions SA
 
Manual gerenciamentodeprojetos
Manual gerenciamentodeprojetosManual gerenciamentodeprojetos
Manual gerenciamentodeprojetos
Ilton Prandi
 
Gerenciamento De Projeto Para Slideshare
Gerenciamento De Projeto Para SlideshareGerenciamento De Projeto Para Slideshare
Gerenciamento De Projeto Para Slideshare
Leila Oliva
 
Macrosolutions Consultoria: Avaliação, Otimização e Reestruturação de Escritó...
Macrosolutions Consultoria: Avaliação, Otimização e Reestruturação de Escritó...Macrosolutions Consultoria: Avaliação, Otimização e Reestruturação de Escritó...
Macrosolutions Consultoria: Avaliação, Otimização e Reestruturação de Escritó...
Macrosolutions SA
 
Aula 01
Aula 01Aula 01
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
Ivo M Michalick Vasconcelos, PMP, PMI-SP, CPCC
 
Apresentação fatec inteiro
Apresentação fatec   inteiroApresentação fatec   inteiro
Apresentação fatec inteiro
Paulo Bandeira
 
Como gerenciar o planejamento de projetos utilizando a abordagem apresentada ...
Como gerenciar o planejamento de projetos utilizando a abordagem apresentada ...Como gerenciar o planejamento de projetos utilizando a abordagem apresentada ...
Como gerenciar o planejamento de projetos utilizando a abordagem apresentada ...
José Vieira
 
Macrosolutions Consultoria: Avaliação e Diagnóstico de Maturidade em Projetos
Macrosolutions Consultoria: Avaliação e Diagnóstico de Maturidade em ProjetosMacrosolutions Consultoria: Avaliação e Diagnóstico de Maturidade em Projetos
Macrosolutions Consultoria: Avaliação e Diagnóstico de Maturidade em Projetos
Macrosolutions SA
 
Apostila Lean Six Sigma para iniciantes
Apostila Lean Six Sigma para iniciantesApostila Lean Six Sigma para iniciantes
Apostila Lean Six Sigma para iniciantes
eadsigma1
 
Erika questionario pt 2 (Eng Software III).
Erika questionario pt  2 (Eng Software III).Erika questionario pt  2 (Eng Software III).
Erika questionario pt 2 (Eng Software III).
Érika Santos
 

Mais procurados (19)

Artigo - Implantação do escritório de projetos - Aragon salvador
Artigo - Implantação do escritório de projetos - Aragon salvadorArtigo - Implantação do escritório de projetos - Aragon salvador
Artigo - Implantação do escritório de projetos - Aragon salvador
 
00 apresentação (1)ukjghnsdgvr
00   apresentação (1)ukjghnsdgvr00   apresentação (1)ukjghnsdgvr
00 apresentação (1)ukjghnsdgvr
 
Gestão do Conhecimento aplicada à Gestão de Projetos
Gestão do Conhecimento aplicada à Gestão de ProjetosGestão do Conhecimento aplicada à Gestão de Projetos
Gestão do Conhecimento aplicada à Gestão de Projetos
 
Palestra Gerenciamento de Projetos sempre agrega, seja qual for o seu negócio
Palestra Gerenciamento de Projetos sempre agrega, seja qual for o seu negócioPalestra Gerenciamento de Projetos sempre agrega, seja qual for o seu negócio
Palestra Gerenciamento de Projetos sempre agrega, seja qual for o seu negócio
 
Webinar gestão de mudanças organizacionais - o fator humano na liderança de ...
Webinar  gestão de mudanças organizacionais - o fator humano na liderança de ...Webinar  gestão de mudanças organizacionais - o fator humano na liderança de ...
Webinar gestão de mudanças organizacionais - o fator humano na liderança de ...
 
Passo a passo_gerente_projeto
Passo a passo_gerente_projetoPasso a passo_gerente_projeto
Passo a passo_gerente_projeto
 
Winning.catálogo.formação
Winning.catálogo.formaçãoWinning.catálogo.formação
Winning.catálogo.formação
 
Palestra perspectivas para 2011 - Aula inaugural IBEC/INPG 2011
Palestra perspectivas para 2011 - Aula inaugural IBEC/INPG 2011Palestra perspectivas para 2011 - Aula inaugural IBEC/INPG 2011
Palestra perspectivas para 2011 - Aula inaugural IBEC/INPG 2011
 
Macrosolutions Consultoria: Otimização de Recursos e Investimentos através do...
Macrosolutions Consultoria: Otimização de Recursos e Investimentos através do...Macrosolutions Consultoria: Otimização de Recursos e Investimentos através do...
Macrosolutions Consultoria: Otimização de Recursos e Investimentos através do...
 
Manual gerenciamentodeprojetos
Manual gerenciamentodeprojetosManual gerenciamentodeprojetos
Manual gerenciamentodeprojetos
 
Gerenciamento De Projeto Para Slideshare
Gerenciamento De Projeto Para SlideshareGerenciamento De Projeto Para Slideshare
Gerenciamento De Projeto Para Slideshare
 
Macrosolutions Consultoria: Avaliação, Otimização e Reestruturação de Escritó...
Macrosolutions Consultoria: Avaliação, Otimização e Reestruturação de Escritó...Macrosolutions Consultoria: Avaliação, Otimização e Reestruturação de Escritó...
Macrosolutions Consultoria: Avaliação, Otimização e Reestruturação de Escritó...
 
Aula 01
Aula 01Aula 01
Aula 01
 
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
 
Apresentação fatec inteiro
Apresentação fatec   inteiroApresentação fatec   inteiro
Apresentação fatec inteiro
 
Como gerenciar o planejamento de projetos utilizando a abordagem apresentada ...
Como gerenciar o planejamento de projetos utilizando a abordagem apresentada ...Como gerenciar o planejamento de projetos utilizando a abordagem apresentada ...
Como gerenciar o planejamento de projetos utilizando a abordagem apresentada ...
 
Macrosolutions Consultoria: Avaliação e Diagnóstico de Maturidade em Projetos
Macrosolutions Consultoria: Avaliação e Diagnóstico de Maturidade em ProjetosMacrosolutions Consultoria: Avaliação e Diagnóstico de Maturidade em Projetos
Macrosolutions Consultoria: Avaliação e Diagnóstico de Maturidade em Projetos
 
Apostila Lean Six Sigma para iniciantes
Apostila Lean Six Sigma para iniciantesApostila Lean Six Sigma para iniciantes
Apostila Lean Six Sigma para iniciantes
 
Erika questionario pt 2 (Eng Software III).
Erika questionario pt  2 (Eng Software III).Erika questionario pt  2 (Eng Software III).
Erika questionario pt 2 (Eng Software III).
 

Destaque

Obesidade
ObesidadeObesidade
Obesidade
L1S1
 
Artigo gp
Artigo gpArtigo gp
Metodologia de Gerenciamento De Projetos
Metodologia de Gerenciamento De ProjetosMetodologia de Gerenciamento De Projetos
Metodologia de Gerenciamento De Projetos
TI Infnet
 
TCC_Artigo_A informacao como fator motivacional em gerenciamento de projetos
TCC_Artigo_A informacao como fator motivacional em gerenciamento de projetosTCC_Artigo_A informacao como fator motivacional em gerenciamento de projetos
TCC_Artigo_A informacao como fator motivacional em gerenciamento de projetos
Valeria Souza
 
Metodologias ágeis de desenvolvimento trabalho
Metodologias ágeis de desenvolvimento   trabalhoMetodologias ágeis de desenvolvimento   trabalho
Metodologias ágeis de desenvolvimento trabalho
Ruan Pozzebon
 
Alexandre Artigo Cientifico
Alexandre Artigo CientificoAlexandre Artigo Cientifico
Alexandre Artigo Cientifico
Helson Costa, PMP
 
A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...
A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...
A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...
Marcelo Dieder
 
Artigo gestao-em-projetos-aftermarket
Artigo gestao-em-projetos-aftermarketArtigo gestao-em-projetos-aftermarket
Artigo gestao-em-projetos-aftermarket
Itamar Rolisola
 
Agil - artigo cientifico
Agil - artigo cientificoAgil - artigo cientifico
Agil - artigo cientifico
Klaus Fischer Gomes Santana
 
Modelo de artigo científico básico - com normas ABNT
Modelo de artigo científico básico - com normas ABNTModelo de artigo científico básico - com normas ABNT
Modelo de artigo científico básico - com normas ABNT
Rosineia Oliveira dos Santos
 
Designing Teams for Emerging Challenges
Designing Teams for Emerging ChallengesDesigning Teams for Emerging Challenges
Designing Teams for Emerging Challenges
Aaron Irizarry
 
Visual Design with Data
Visual Design with DataVisual Design with Data
Visual Design with Data
Seth Familian
 
3 Things Every Sales Team Needs to Be Thinking About in 2017
3 Things Every Sales Team Needs to Be Thinking About in 20173 Things Every Sales Team Needs to Be Thinking About in 2017
3 Things Every Sales Team Needs to Be Thinking About in 2017
Drift
 
How to Become a Thought Leader in Your Niche
How to Become a Thought Leader in Your NicheHow to Become a Thought Leader in Your Niche
How to Become a Thought Leader in Your Niche
Leslie Samuel
 

Destaque (14)

Obesidade
ObesidadeObesidade
Obesidade
 
Artigo gp
Artigo gpArtigo gp
Artigo gp
 
Metodologia de Gerenciamento De Projetos
Metodologia de Gerenciamento De ProjetosMetodologia de Gerenciamento De Projetos
Metodologia de Gerenciamento De Projetos
 
TCC_Artigo_A informacao como fator motivacional em gerenciamento de projetos
TCC_Artigo_A informacao como fator motivacional em gerenciamento de projetosTCC_Artigo_A informacao como fator motivacional em gerenciamento de projetos
TCC_Artigo_A informacao como fator motivacional em gerenciamento de projetos
 
Metodologias ágeis de desenvolvimento trabalho
Metodologias ágeis de desenvolvimento   trabalhoMetodologias ágeis de desenvolvimento   trabalho
Metodologias ágeis de desenvolvimento trabalho
 
Alexandre Artigo Cientifico
Alexandre Artigo CientificoAlexandre Artigo Cientifico
Alexandre Artigo Cientifico
 
A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...
A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...
A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...
 
Artigo gestao-em-projetos-aftermarket
Artigo gestao-em-projetos-aftermarketArtigo gestao-em-projetos-aftermarket
Artigo gestao-em-projetos-aftermarket
 
Agil - artigo cientifico
Agil - artigo cientificoAgil - artigo cientifico
Agil - artigo cientifico
 
Modelo de artigo científico básico - com normas ABNT
Modelo de artigo científico básico - com normas ABNTModelo de artigo científico básico - com normas ABNT
Modelo de artigo científico básico - com normas ABNT
 
Designing Teams for Emerging Challenges
Designing Teams for Emerging ChallengesDesigning Teams for Emerging Challenges
Designing Teams for Emerging Challenges
 
Visual Design with Data
Visual Design with DataVisual Design with Data
Visual Design with Data
 
3 Things Every Sales Team Needs to Be Thinking About in 2017
3 Things Every Sales Team Needs to Be Thinking About in 20173 Things Every Sales Team Needs to Be Thinking About in 2017
3 Things Every Sales Team Needs to Be Thinking About in 2017
 
How to Become a Thought Leader in Your Niche
How to Become a Thought Leader in Your NicheHow to Become a Thought Leader in Your Niche
How to Become a Thought Leader in Your Niche
 

Semelhante a Artigo sobre práticas de gerenciamento de projetos

Tcc -aplicação de metodologias de gerenciamento de projetos em empresas de d...
Tcc  -aplicação de metodologias de gerenciamento de projetos em empresas de d...Tcc  -aplicação de metodologias de gerenciamento de projetos em empresas de d...
Tcc -aplicação de metodologias de gerenciamento de projetos em empresas de d...
Hiram Costa-Silva
 
Estudo De Caso Pmbok
Estudo De Caso PmbokEstudo De Caso Pmbok
Estudo De Caso Pmbok
Luiz Neto
 
TCC - Pós Graduação - Gerencia de Projetos - PMI
TCC - Pós Graduação - Gerencia de Projetos - PMITCC - Pós Graduação - Gerencia de Projetos - PMI
TCC - Pós Graduação - Gerencia de Projetos - PMI
Eduardo Paiossin
 
GERENCIAMENTO DE PROJETOS EM AGÊNCIAS WEB BASEADO NO PMI E METODOLOGIAS ÁGEIS
GERENCIAMENTO DE PROJETOS EM AGÊNCIAS WEB BASEADO NO PMI E METODOLOGIAS ÁGEISGERENCIAMENTO DE PROJETOS EM AGÊNCIAS WEB BASEADO NO PMI E METODOLOGIAS ÁGEIS
GERENCIAMENTO DE PROJETOS EM AGÊNCIAS WEB BASEADO NO PMI E METODOLOGIAS ÁGEIS
Peter Rizzon
 
Ebook Gestão de projetos
Ebook Gestão de projetosEbook Gestão de projetos
Ebook Gestão de projetos
Liliane Farias
 
Gestão de projetos em empresas no brasil
Gestão de projetos em empresas no brasilGestão de projetos em empresas no brasil
Gestão de projetos em empresas no brasil
Paulo Junior
 
Mba gestão de projetos montanha russa 2011 - veris
Mba gestão de projetos   montanha russa 2011 - verisMba gestão de projetos   montanha russa 2011 - veris
Mba gestão de projetos montanha russa 2011 - veris
Marco De Souza
 
Gerenciamento de projetos
Gerenciamento de projetos Gerenciamento de projetos
Gerenciamento de projetos
Benedito Leão
 
Gerenciando Projetos De Software De Forma áGil Utilizando Scrum
Gerenciando Projetos De Software De Forma áGil Utilizando ScrumGerenciando Projetos De Software De Forma áGil Utilizando Scrum
Gerenciando Projetos De Software De Forma áGil Utilizando Scrum
Raphael Donaire Albino
 
A Gerencia Intuitiva
A Gerencia IntuitivaA Gerencia Intuitiva
A Gerencia Intuitiva
Abraao Dahis
 
A Gerencia Intuitiva
A Gerencia IntuitivaA Gerencia Intuitiva
A Gerencia Intuitiva
guest576a1e
 
Unificando PMBOK e SCRUM no gerenciamento de projetos
Unificando PMBOK e SCRUM no gerenciamento de projetosUnificando PMBOK e SCRUM no gerenciamento de projetos
Unificando PMBOK e SCRUM no gerenciamento de projetos
Alexander Correia Marques - MBA/CSM/ITIL
 
Project Value - Criação de PMO - aspectos a considerar
Project Value - Criação de PMO - aspectos a considerarProject Value - Criação de PMO - aspectos a considerar
Project Value - Criação de PMO - aspectos a considerar
Alcides Cabral PMP
 
04 sintese2
04  sintese204  sintese2
04 sintese2
Felipe Carneiro
 
Como usar o Guia PMBOK® na engenharia de softwares Aplicando os grupos de pr...
Como usar o Guia PMBOK® na engenharia de softwares  Aplicando os grupos de pr...Como usar o Guia PMBOK® na engenharia de softwares  Aplicando os grupos de pr...
Como usar o Guia PMBOK® na engenharia de softwares Aplicando os grupos de pr...
Robson Veiga Roy
 
Tb Escopo Mario e Claudio
Tb Escopo Mario e ClaudioTb Escopo Mario e Claudio
Tb Escopo Mario e Claudio
Helson Costa, PMP
 
A importância de gerenciar projetos
A importância de gerenciar projetosA importância de gerenciar projetos
A importância de gerenciar projetos
Amauri Damasceno
 
Gerenciamento_de_Projetos_de_Software.ppt
Gerenciamento_de_Projetos_de_Software.pptGerenciamento_de_Projetos_de_Software.ppt
Gerenciamento_de_Projetos_de_Software.ppt
ssuser064821
 
Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...
Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...
Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...
Diógenes Almeida
 
Aula 5 semana
Aula 5 semanaAula 5 semana
Aula 5 semana
Jorge Ávila Miranda
 

Semelhante a Artigo sobre práticas de gerenciamento de projetos (20)

Tcc -aplicação de metodologias de gerenciamento de projetos em empresas de d...
Tcc  -aplicação de metodologias de gerenciamento de projetos em empresas de d...Tcc  -aplicação de metodologias de gerenciamento de projetos em empresas de d...
Tcc -aplicação de metodologias de gerenciamento de projetos em empresas de d...
 
Estudo De Caso Pmbok
Estudo De Caso PmbokEstudo De Caso Pmbok
Estudo De Caso Pmbok
 
TCC - Pós Graduação - Gerencia de Projetos - PMI
TCC - Pós Graduação - Gerencia de Projetos - PMITCC - Pós Graduação - Gerencia de Projetos - PMI
TCC - Pós Graduação - Gerencia de Projetos - PMI
 
GERENCIAMENTO DE PROJETOS EM AGÊNCIAS WEB BASEADO NO PMI E METODOLOGIAS ÁGEIS
GERENCIAMENTO DE PROJETOS EM AGÊNCIAS WEB BASEADO NO PMI E METODOLOGIAS ÁGEISGERENCIAMENTO DE PROJETOS EM AGÊNCIAS WEB BASEADO NO PMI E METODOLOGIAS ÁGEIS
GERENCIAMENTO DE PROJETOS EM AGÊNCIAS WEB BASEADO NO PMI E METODOLOGIAS ÁGEIS
 
Ebook Gestão de projetos
Ebook Gestão de projetosEbook Gestão de projetos
Ebook Gestão de projetos
 
Gestão de projetos em empresas no brasil
Gestão de projetos em empresas no brasilGestão de projetos em empresas no brasil
Gestão de projetos em empresas no brasil
 
Mba gestão de projetos montanha russa 2011 - veris
Mba gestão de projetos   montanha russa 2011 - verisMba gestão de projetos   montanha russa 2011 - veris
Mba gestão de projetos montanha russa 2011 - veris
 
Gerenciamento de projetos
Gerenciamento de projetos Gerenciamento de projetos
Gerenciamento de projetos
 
Gerenciando Projetos De Software De Forma áGil Utilizando Scrum
Gerenciando Projetos De Software De Forma áGil Utilizando ScrumGerenciando Projetos De Software De Forma áGil Utilizando Scrum
Gerenciando Projetos De Software De Forma áGil Utilizando Scrum
 
A Gerencia Intuitiva
A Gerencia IntuitivaA Gerencia Intuitiva
A Gerencia Intuitiva
 
A Gerencia Intuitiva
A Gerencia IntuitivaA Gerencia Intuitiva
A Gerencia Intuitiva
 
Unificando PMBOK e SCRUM no gerenciamento de projetos
Unificando PMBOK e SCRUM no gerenciamento de projetosUnificando PMBOK e SCRUM no gerenciamento de projetos
Unificando PMBOK e SCRUM no gerenciamento de projetos
 
Project Value - Criação de PMO - aspectos a considerar
Project Value - Criação de PMO - aspectos a considerarProject Value - Criação de PMO - aspectos a considerar
Project Value - Criação de PMO - aspectos a considerar
 
04 sintese2
04  sintese204  sintese2
04 sintese2
 
Como usar o Guia PMBOK® na engenharia de softwares Aplicando os grupos de pr...
Como usar o Guia PMBOK® na engenharia de softwares  Aplicando os grupos de pr...Como usar o Guia PMBOK® na engenharia de softwares  Aplicando os grupos de pr...
Como usar o Guia PMBOK® na engenharia de softwares Aplicando os grupos de pr...
 
Tb Escopo Mario e Claudio
Tb Escopo Mario e ClaudioTb Escopo Mario e Claudio
Tb Escopo Mario e Claudio
 
A importância de gerenciar projetos
A importância de gerenciar projetosA importância de gerenciar projetos
A importância de gerenciar projetos
 
Gerenciamento_de_Projetos_de_Software.ppt
Gerenciamento_de_Projetos_de_Software.pptGerenciamento_de_Projetos_de_Software.ppt
Gerenciamento_de_Projetos_de_Software.ppt
 
Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...
Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...
Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...
 
Aula 5 semana
Aula 5 semanaAula 5 semana
Aula 5 semana
 

Artigo sobre práticas de gerenciamento de projetos

  • 1. A síndrome da ‘Bala de Prata’ na gestão de projetos de TI Autoria: Flávia Cruz Pereira flav_cp@yahoo.com.br Resumo Tendo em vista a situação do mercado atual onde o foco está cada vez mais voltado para minimizar os custos, as organizações buscam de forma incessante formas para viabilizar esse objetivo e, em contrapartida, alcançar mais e mais o seu Return of Investiment (ROI). Para que isso seja possível na prática, faz-se necessária a utilização de práticas de gestão de projetos para garantir que essa engrenagem funcione devidamente. Com isso a pesquisa procura desmistificar o mito da ‘Bala de Prata’ demonstrando que a prática de gestão de projetos a ser utilizada deve estar bem vinculada com a estratégica da organização e em conformidade com a necessidade do cliente para garantir uma maior agilidade na sua execução com eficiência e eficácia, atrelada à restrição tripla do projeto: prazo, custo e escopo, não deixando de manter o padrão de qualidade necessário para garantir a sua competitividade. Palavras-chave: Gestão de Projetos, Agilidade, Qualidade. 1 Introdução Na Engenharia de Software, o termo ‘Bala de Prata’ vem sendo utilizado como direcionamento para uma solução definitiva do problema: método ou forma capaz de resolver um problema independente de qual seja a sua natureza. Assim como na Engenharia de Software, na Gestão de Projetos, o termo também vem sendo muito utilizado e discutido. Com o cenário mercadológico em constante mudança devido às inovações tecnológicas que nos bombardeiam quase que diariamente, as organizações precisam mais do que nunca se adequar para garantir a sua competitividade com o foco cada vez mais voltado para o Return on investiment (ROI) e com isso vêm empregando grandes esforços para a melhoria de seus resultados agregados aos resultados dos seus clientes. Para isso, faz-se mais que necessário investir para desenvolver produtos e/ou serviços com qualidade respeitando a restrição tripla do projeto: prazo, custo e escopo. Com isso, acredita-se que com um bom processo a chance de se obter o sucesso dos projetos é claramente maior. A síndrome da ‘Bala de Prata’ em gestão de projetos - metodologia que garanta o sucesso de um projeto faz com que especialistas discutam qual é a melhor prática a ser usada com base nesse contexto. De acordo com o Project Management Institute (PMI, 2008), o nível estratégico (alta administração) das organizações vem percebendo os benefícios do uso de boas práticas/metodologias para gerir seus projetos. Estudos comprovam a viabilidade do uso atrelada ao alinhamento estratégico para maximizar o ROI: 1
  • 2. Figura 1 – % de Sucesso e Insucesso de projetos conforme aderência/resistência Fonte: Desenvolvido pelo autor. As práticas mais utilizadas no mercado atualmente são: Guide to the Project Management Body of Knowledge (PMBOK® Guide) desenvolvido pelo Project Management Institute (PMI) - um framework de padrões de boas práticas de gestão de projetos que descreve normas, métodos, processos e práticas estabelecidas e o SCRUM - um processo ágil que permite manter o foco na entrega do maior valor de negócio, no menor tempo possível (AMBLER, 2008). Com base nessa premissa, esta pesquisa pretende traçar um comparativo entre essas boas práticas mais difundidas para que seja possível verificar suas características em comum o que possibilita a convivência de ambas em um mesmo ambiente organizacional, demonstrando que não existe uma receita de sucesso para o projeto baseado apenas em uma boa prática utilizada. Sendo assim, o objetivo deste artigo é demonstrar a relação entre as práticas do PMBOK® Guide e SCRUM na gestão de projetos em TI, descrevendo suas características predominantes e traçando um paralelo entre elas - apresentando os benefícios com a sua aderência e perspectivas. 2 Referencial Teórico 2.1 Porque aplicar a gestão de projetos Projetos existem para viabilizar as estratégias da organização traduzidas através de seus objetivos. Com isso, as organizações buscam a aplicação de metodologias ou práticas para atingirem as expectativas de todos os envolvidos/interessados no projeto. Essa aplicação nada mais é do que criar um processo de padronização da forma de trabalhar para alcançar os objetivos propostos respeitando a restrição tripla do projeto: prazo, custo e escopo – garantindo a qualidade (CARNEIRO, 2006 e KING, 1992). Com base nessas premissas, a organização deve aplicar uma prática/metodologia de gestão de projetos que seja alinhada com a sua estrutura: funcional, matricial ou projetizada bem como a sua cultura, em conformidade com o seu planejamento estratégico. Gestão de Projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender seus requisitos. (PMBOK® Guide, 2008) Segundo o Standish Group (2006), organizações americanas gastam mais de US$ 275 bilhões a cada ano em projetos de desenvolvimento de software. Muitos desses projetos irão falhar, e o caos se deve na maioria das vezes à falta ou mal uso de uma gestão de projetos. Em conseqüência disso, produzem-se softwares em estoque com um escopo mal planejado, onde na maioria das vezes todas as funcionalidades levantadas não são utilizadas (CHAIRMAN, 2006). 2
  • 3. Figura 2 – Funcionalidades desenvolvidas X % Uso Fonte: Standish Group, 2006. 2.1.1 PMI e o PMBOK® Guide O Project Management Institute (PMI), fundado em 1969 e sediado na Pensilvânia - USA, é a mais importante organização internacional sem fins lucrativos que reúne profissionais que trabalham com gestão de projetos de diversas áreas. Com o intuito de documentar e padronizar todo o processo de gestão de projetos, o instituto publicou o Guide to the Project Management Body of Knowledge (PMBOK® Guide), que vêm sofrendo adequações a fim de se obter uma melhoria contínua na forma de gerir projetos. O PMBOK® Guide nada mais é do que um guia com um conjunto de boas práticas para gestão de projetos. Na versão mais atualizada – 2008, estão integrados 42 processos de gestão agrupados em 5 grupos de processos/fases envolvendo 9 áreas de conhecimento. Os processos são agrupados em 5 categorias – ou grupo de processos: 1. Iniciação 2. Planejamento 3. Execução 4. Monitoramento e controle 5. Encerramento Segundo D’ÁVILA (2010), os grupos de processos de gestão de projetos têm relação com o conceito do Ciclo PDCA (Plan – Planejar, Do – Fazer, Check – Verificar e Act – Agir). O grupo de Planejamento corresponde ao Planejar; Execução, ao Fazer; e Monitoramento e Controle englobam Verificar e Agir. Além desses processos, o PMBOK® Guide ainda caracteriza os grupos de processos de Iniciação e Encerramento, pois o projeto apresenta um ciclo finito. Figura 3 – Overlap dos processos em um projeto Fonte: PMBOK® Guide, 2008. 3
  • 4. Ainda conforme D’ÁVILA (2010), o PMBOK® Guide aborda 9 áreas de conhecimento. É uma descrição das entradas, ferramentas e técnicas; e saídas geradas conforme os processos que abrangem cada área. São elas: 1. Gestão do Escopo: Inclui os processos necessários para assegurar que o projeto inclui todo o trabalho necessário, e somente o trabalho necessário, para completar o projeto com sucesso. 2. Gestão do Tempo: Inclui os processos necessários para assegurar o planejamento e execução do projeto em um prazo adequado. 3. Gestão de Custos: Inclui os processos necessários para assegurar que o projeto possa ser executado dentro do orçamento aprovado. 4. Gestão da Qualidade: Inclui os processos necessários para assegurar que o projeto vai satisfazer as necessidades para as quais foi concebido. 5. Gestão de Integração: Inclui os processos necessários para assegurar a unificação, consolidação, articulação e ações integradoras que são essenciais para o término do projeto, para atender com sucesso às necessidades do cliente e de outras partes interessadas e para gerenciar as expectativas. 6. Gestão de Comunicações: Inclui os processos necessários para assegurar a adequada geração, disseminação e armazenamento de informações do projeto. 7. Gestão de Riscos: Inclui os processos relacionados com a identificação, análise e estabelecimento de contramedidas para os riscos do projeto. 8. Gestão de Recursos Humanos: Inclui os processos necessários para que se faça o melhor uso dos recursos humanos envolvidos no projeto. 9. Gestão de Aquisições: Inclui os processos necessários para a aquisição de bens e serviços fora da organização executora do projeto. Cada processo se caracteriza por suas entradas, técnicas e ferramentas e saídas que são retroalimentados em um ciclo contínuo – onde saídas podem alimentar a entradas do próximo processo. Além disso, as áreas de conhecimento abrangem diversos processos, onde o escopo, tempo, custo e qualidade são os principais focos para o objetivo do projeto. Essas premissas são necessárias para garantir a qualidade e recursos humanos, aquisições, comunicações e riscos são elementos aos quais deve haver constante atenção em um projeto. E Integração abrange a sincronização com todas as outras áreas. Figura 4 – Sinergia das áreas de conhecimento Fonte: Márcio D'Ávila, 2010. 2.1.2 Metodologia ágil e o manifesto ágil É indiscutível o fato de que as organizações estão buscando todas as formas para minimizar seus custos. O cenário mercadológico atual faz com que cada vez mais as 4
  • 5. organizações invistam em práticas que minimizem seus custos e maximizem o ROI para se manterem competitivas. Nesse contexto, as metodologias ágeis – como o próprio nome já diz, pregam a agilidade, estão ganhando mais e mais espaço dentro das organizações (AMBLER, 2008). A metodologia ágil prevê iterações contínuas em prazos curtos ao decorrer de todo o projeto, visando garantir maior controle e previsibilidade. Em fevereiro de 2001, dezessete agilistas se reuniram e discutiram uma alternativa para a e melhoria de processos que já existiam até então. Com a colaboração de todos, foram levantados alguns princípios relacionados à agilidade (SCHWABER, Ken et al., 2001): • Maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor; • Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas; • Entregar software funcionando com freqüência, na escala de semanas até meses, com preferência aos períodos mais curtos; • Pessoas relacionadas a negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto; • Construir projetos ao redor de indivíduos motivados, dando a eles o ambiente e suporte necessário confiando que farão seu trabalho; • O método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara; • Software funcional é a medida primária de progresso; • Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes; • Contínua atenção a excelência técnica e bom design aumentam a agilidade; • Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito; • As melhores arquiteturas, requisitos e designs emergem de times auto- gerenciáveis; e • Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo. A partir daí, nasceu o manifesto ágil, que prega que: • Indivíduos e interação entre eles mais que processos e ferramentas; • Software em funcionamento mais que documentação abrangente; • Colaboração com o cliente mais que negociação de contratos; e • Responder a mudanças mais que seguir um plano. Ou seja, mesmo havendo valor nos itens à direita, os itens à esquerda são mais valorizados. 5
  • 6. Segundo a Scrum Alliance (organização para promover, apoiar e gerar recursos aos ‘agilistas’ - termo usado para designar os adeptos da metodologia), existem várias metodologias no mercado atualmente, mas a mais utilizada vem sendo o Scrum. 2.1.2.1 Scrum Em 1993, Jeff Sutherland, Ken Schwaber e John Scumniotales usaram o Scrum pela primeira vez na organização Easel Corporation, incorporando os conceitos da metodologia ágil Lean. A partir disso, fundaram a Scrum Alliance. Após dois anos, Ken Schwaber formalizou a nova metodologia e ajudou a divulgá-la para as organizações voltadas, principalmente, para o desenvolvimento de software. Segundo SCHWABER (2004), o nome Scrum vem da prática esportiva Rugby que significa uma jogada envolvendo todos para que façam força simultaneamente para que possam pegar a bola do time adversário. Abstraindo o conceito para o mundo dos softwares, o Scrum é um processo empírico de gestão e controle de projetos. De acordo com COHN (2010), a metodologia crê que devido à complexidade, escopo, mudanças de requisitos, urgência e necessidade de demonstrar valor (ROI) mais rápido, fica quase inconcebível desenvolver software utilizado o modelo cascata, ou seja, desenvolver todo o software de uma única vez. Com isso, o desenvolvimento iterativo e incremental é uma estratégia de planejamento (que segue alinha dividir para conquistar), onde o software é construído em partes, ou seja, em Sprints (iterações), onde a cada Sprint tem como meta a entrega de valor (parte do software funcional) até completar o software. Ainda segundo COHN (2010), para garantir o controle e previsibilidade desse processo, existem as cerimônias: 1. Reunião Diária: é um encontro entre o Scrum Master, o Time e qualquer pessoa interessada no projeto com o timebox (tempo) de 15 minutos onde cada membro do time dará as suas impressões a respeito do projeto, respondendo a três perguntas importantes: a. O que eu fiz desde a última reunião diária? b. O que eu pretendo fazer até amanhã? c. Tem alguma coisa impedindo o meu trabalho? 2. Planejamento da Sprint: esta reunião ocorre no primeiro dia de cada Sprint. É dividida em duas partes: no primeiro momento o Product Owner, o Scrum Master e o Time discutem sobre as funcionalidades potencialmente designadas para a determinada Sprint e no segundo momento, o Scrum Master e o Time estimam o tempo para o desenvolvimento de cada funcionalidade através da Planning Poker (prática que auxilia na estimativa das funcionalidades pontuando o seu tamanho conforme a série de Fibonacci). 3. Revisão da Sprint: esta reunião ocorre no último dia da Sprint e representa o momento que o Time e o Scrum Master demonstram o seu desempenho através do Burndown Chart e as funcionalidades potencialmente entregáveis executadas para o Product Owner e demais interessados, se houver. 4. Retrospectiva da Sprint: é uma reunião entre Scrum Master e o Time onde duas perguntas são feitas: a. O que foi bom durante a Sprint? (Interno: Time/ Externo: Product Owner) 6
  • 7. b. O que pode ser melhorado? (Interno: Time/ Externo: Product Owner) A partir daí é elaborado um plano de ação para atacar o que pode ser melhorado na próxima Sprint. Contemplam os artefatos: 1. Product Backlog: lista de funcionalidades a serem desenvolvidas ao longo do projeto distribuídas em Sprints. 2. Sprint Backlog: lista de funcionalidades detalhadas no dia de planejamento envolvendo o Product Owner, o Scrum Master, o Time e demais interessados, a serem desenvolvidas ao longo da Sprint. O mundo ideal seria ter o maior nível de detalhes para poder mensurar a complexidade das atividades para que se possa fazer estimativas mais assertivas e garantir uma boa velocity do Time – garantindo a boa produtividade e uma boa previsibilidade das entregas. 3. Burndown: gráfico demonstrativo do andamento das atividades da Sprint (Planejado X Realizado) a ser acompanhado durante todo o projeto e exibido na Revisão da Sprint. O andamento do projeto estará diretamente relacionado à boa gestão do controle da produtividade do Time. Existem os papéis: 1. Product Owner (PO): pode ser o financiador ou um importante interessado no projeto. Suas principais responsabilidades são: definir as funcionalidades do produto; concentrar as informações vindas de usuários, stakeholders ou do mercado de maneira que se obtenha uma visão única dos requisitos do sistema; priorizador do Product Backlog; ter autonomia para alterar as prioridades fora da Sprint. 2. Scrum Master (SM): desempenha o papel de líder, gerenciando os interesses do Product Owner mediante o Time. Numa abordagem tradicional, o Scrum Master seria um Gerente de Projetos, porém, essa nomenclatura foi substituída para diferenciar o foco de liderança necessário para que um processo empírico funcione. Suas principais responsabilidades são: Atuar como facilitador; Remover Impedimentos; Garantir que o processo está sendo respeitado; Auxiliar o Product Owner a maximizar o ROI a cada entrega ao fim das Sprints. 3. Equipe Scrum (Time): Grupo de profissionais especialistas diretamente ligados ao trabalho a ser feito para garantir a entrega do projeto com todas as suas funcionalidades necessárias. Suas principais características são: Multifuncional; Formado por até 7 pessoas; Auto-gerenciável. 7
  • 8. Figura 8 – A engrenagem Scrum Fonte: Mike Cohn, 2010. 3 Paralelo PMBOK® Guide X Scrum 3.1 Procedimentos Metodológicos Através de uma leitura, análise e interpretação do material bibliográfico estudado relacionado às duas metodológicas abordadas, esta pesquisa pretende dar uma resposta para uma questão que vêm sendo abordada em vários fóruns relacionados à gestão de projetos. Baseando no conteúdo abordado, a idéia é agregar o conhecimento voltado para a possibilidade de gerar uma discussão para se chegar a um discernimento para a construção de fundamentos e opiniões próprias. O estudo comparativo entre as práticas do PMBOK® Guide e do Scrum permite que se faça uma análise aberta das diferenças, semelhanças, aderências e perspectivas através das informações analisadas e propostas. 4 Análise de Dados No cenário de mercado atual, é possível perceber que as organizações de diversas áreas de negócio vêm investindo cada vez mais na gestão de projetos. Mas ainda sim, podemos perceber que os adeptos de metodologias ágeis estão mais concentrados em um nicho de mercado: TI. Levando em consideração estruturas organizacionais projetizadas – onde a autonomia de tomada de decisões dos responsáveis está diretamente relacionada aos projetos, mas acima de tudo respeitando as estratégias da organização, podemos perceber que ainda sim existem algumas semelhanças entre as formas de gestão descritas anteriormente apesar de terem um direcionamento e origem distintos: Características PMBOK® Guide Scrum Ter definido a priori Escopo. Tempo (Sprints). Responsável pela organização Gerente de Projetos. Scrum Master. executora para atingir os objetivos do projeto Principais artefatos WBS (Work Breakdown Structure) Product Backlog e Sprint e Plano do Projeto. Backlog. Grupo de Programa/ Projetos Programa/ Portifólio de Projetos. Scrum of Scrums. Freqüência de Reuniões de status Dependendo da complexidade/ Diárias. necessidade do projeto, alinhar a freqüência. Start-Up do projeto Reunião de Kick-off. Planejamento da Sprint. 8
  • 9. Entrega do produto No encerramento do projeto. Entregáveis Parciais conforme priorização (por Sprints). Encerramento do Projeto Lições aprendidas. Retrospectiva da Sprint. Principais Ferramentas de EVA (Estimated Value Burndown Chart. Indicadores de Desempenho Agregated), Gráficos e Relatórios via MSProject, Curva S, Status Report. Escopo Definido na fase de Início do Definido de forma macro na projeto e formalizado através da fase de Início do projeto. WBS (Work Breakdown No Planejamento da Sprint Structure). os requisitos são detalhados e priorizados. Tempo Detalhado para a realização do Detalhado e orientado a projeto como um todo. entregas (por Sprints). Custo Monitoração constante para não Maior controle em função aferir o custo planejado. da agilidade de se incorporar mudanças. Qualidade Constante verificação e validação Constante verificação e das saídas dos processos. validação das atividades durante a Sprint. Riscos Análise e controle dos riscos em Análise e controle dos todo o ciclo de vida do projeto. riscos em todo o ciclo de vida do projeto. Comunicação Formal e documentada. Colaborativa. Recursos Humanos Papéis bem definidos. Equipe multidisciplinar e auto-gerenciável. Aquisição Controle por contrato bem Informal e volátil. definido e documentado. Integração Plano do Projeto detalhado e Facilitação. monitorado durante todo o projeto. Tabela 1 – PMBOK® Guide X Scrum. Fonte: Desenvolvido pelo autor. Com base no levantamento das informações supracitadas, é possível perceber que ambas as metodologias possuem características muito semelhantes – pois metodologias nascem para melhorar as que já existem. Nesse caso, porém, cada uma possui um direcionamento: enquanto as práticas do PMBOK® Guide pregam a interação da organização em um nível mais estratégico e formal, o Scrum norteia a operacionalização do processo da gestão de projetos de maneira informal e colaborativa. Sendo assim, é possível dizer que, diante dessa análise, o Scrum é indiretamente uma forma customizada das boas práticas abordadas no PMBOK® Guide – mesmo que o Scrum não seja originada diretamente do PMBOK® Guide. As práticas podem ser complementares, onde pontos falhos de uma podem ser supridos por pontos fortes da outra. Ainda sim, ao passo que o Scrum prega que sua aplicação tenha que necessariamente estar em conformidade com a forma que é proposta, ou seja, by the book, o PMBOK® Guide dá o livre arbítrio ao gerente de projetos com a colaboração da equipe, definir os processos apropriados a serem utilizados no projeto de acordo com sua visibilidade e complexidade. 5 Considerações Finais A gestão de projetos é definitivamente um dos caminhos mais indicados para se obter melhores resultados, mas é preciso utilizá-lo de maneira adequada às necessidades de cada 9
  • 10. projeto. O processo não deve ser engessado, deve ser um apoio para garantir que seja intrínseco às atividades que irão ser desenvolvidas ao longo do projeto e esse suporte dará condições efetivas para que as organizações conquistem seus objetivos estratégicos. Para isso, é preciso também considerar as características próprias de capa projeto: o escopo, o custo, o prazo, a natureza, a complexidade e a importância do projeto respeitando a cultura, o processo e a estratégia de negócios da organização. Além disso, é de extrema importância selecionar as ferramentas, métodos e técnicas mais adequadas para cada situação. As organizações não devem se deixar levar pelo modismo ou pensar que pode dar certo se já existe outra organização trabalhando de determinada maneira. Esse é um processo de constante aprendizagem e entendimento da necessidade e estrutura da organização, seus clientes e o mercado. Não há uma fórmula de sucesso, ou seja, a síndrome da bala de prata da melhor metodologia em gestão de projetos não passa de uma lenda. Cabe às pessoas abstraírem o melhor de cada uma em benefício da organização e em conseqüência de seus projetos. Esse é um caminho a ser seguido que visa sinergizar a melhoria contínua com o uso de ferramentas, métodos e técnicas que envolvem um processo de gestão de projetos com qualidade para garantir o diferencial competitivo – envolvendo o nível estratégico, tático e operacional da organização, para alinhar as necessidades/ expectativas – Planejamento Estratégico, com a operacionalização das ações estratégicas como meio de alcançar os objetivos para se atingir os resultados com o ROI esperado. Referências bibliográficas - AMBLER, S. W., “Has Agile Peaked?”. Disponível em: <http://www.drdobbs.com/>. Acesso em: 26/04/2010. - CARNEIRO, Margareth F.S., “Metodologia de Gerenciamento de Projetos”. Disponível em: <http://www.pmkb.com.br>. Acesso em: 26/04/2010. - CHAIRMAN, J. J. Standish Group Study Reported. Disponível em: <http://www.standishgroup.com>. Acesso em: 26/04/2010. - COHN, Mike., “Uma introdução ao Scrum”. Disponível em: <http://www.mountaingoatsoftware.com>. Acesso em 26/04/2010. - D’ÁVILA, Márcio. “PMBOK® Guide e Gerenciamento de Projetos”. Disponível em: <http://www.mhavila.com.br/topicos/gestao/pmbok.html>. Acesso em: 26/04/2010. - KING, David., “PROJECT MANAGEMENT MADE SIMPLE - A Guide to Successful Management of Computer Systems Projects”. ISBN: 0137177291, Prentice Hall, 1992. - PMI – Project Management Institute, “Um Guia do Conhecimento em Gerenciamento de Projetos – PMBOK® Guide – Quarta Edição”. ISBN: 9781933890708., PMI, 2008. - PMI – Project Management Institute. Disponível em: <http://www.pmi.org>. Acesso em 18/05/2010. - SCHWABER, Ken et al., “O manifesto ágil”. Disponível em: <http://agilemanifesto.org/>. Acesso em: 26/04/2010. - SCHWABER, Ken., “Agile Project Management with Scrum”. ISBN: 073561993x., Microsoft Press, 2004. - SCRUM – Scrum Alliance. Disponível em: <http://www.scrumalliance.org>. Acesso em 26/04/2010. 10