Artigo feito para o VII Seminário de Gerenciamento de Projetos do PMI-RS (21-24 de Setembro de 2010) em Porto Alegre, RS

1. Usando os princípios dos métodos ágeis de
desenvolvimento de software para elevar a qualidade do
Gerenciamento de Projetos
Luiz Henrique Rauber Rodrigues¹, Vitor Garcia Jordan¹
¹Faculdade de Informática – Pontifícia Universidade Católica do Rio Grande do Sul
(PUCRS)
CEP 90619-900 – Porto Alegre – RS – Brasil
{luizrauber,vitorjordan}@gmail.com
Abstract. Agile Methods in Software Development, also known as Agile, is a
collection of practices, values and principles. This article describes the
applicability of these twelve agile principles in the PMBOK’s nine areas of
knowledge, in order to add quality to the Project Manager work,
independently of its area.
Resumo. Os Métodos Ágeis de Desenvolvimento de Software, ou,
simplesmente Agile, são compostos de uma coletânea de práticas, valores e
princípios. Descreve-se neste artigo a aplicabilidade dos doze princípios
ágeis nas nove áreas de Conhecimento do PMBOK em sua quarta edição,
com o intuito de acrescentar qualidade e eficácia ao papel de Gerente de
Projetos, independentemente da sua área de atuação.
1. Introdução
Constata-se através de relatórios como o Chaos Report [Standish 2009] que os projetos
de desenvolvimento de softwares falham na ordem de 24%, sendo os 76% restantes em
projetos encerrados com sucesso e os que foram finalizados, mas em termos de
gerenciamento de projeto fracassaram, e o relatório The State of Agile Development,
publicado no 3rd Annual Survey [VersionOne 2008], apresenta que 55% dos projetos
que usam métodos ágeis estão entre 90% e 100% de sucesso.
Com tais números, é possível salientar porque 76% das empresas consultadas no
relatório IT Governance and Project Management Survey [Dr Doob's 2009] adotaram
técnicas dos métodos ágeis em 1 ou mais projetos.
Os Métodos Ágeis são uma coleção positiva de valores, princípios e práticas, ou
técnicas, de metodologias usadas desde a década de 90 para desenvolvimento de
software, época na qual projetos de TI (Tecnologia da Informação) sofriam duras
críticas e eram considerados sempre falhos, pois havia um maior desenvolvimento do
hardware em relação aos softwares que os mesmos teriam que utilizar, [Cohen 2004].
Inúmeros livros e artigos surgem constantemente com comparações, avaliações,
pontos de vista favoráveis ou não, a aplicabilidade dos Métodos Ágeis em relação ao

2. Guia PMBOK [PMBOK 2008], sendo em [Sliger 2006] afirmado, “que apesar das
diferenças de filosofias entre PMI e Agile, muitas das práticas do [PMBOK 2008] são
compatíveis com as práticas ágeis”.
Em [Koch 2004] há uma comparação completa dos processos do [PMBOK
2008] com as práticas dos Métodos Ágeis, concluindo que “Nada nas Metodologias
Ágeis é incompatível com os processos do PMBOK” e que “pode ser oportuno reforçar
as Metodologias Ágeis com processos do PMBOK, porém somente onde realmente
necessário e sem comprometer a agilidade”.
Os métodos ágeis possuem embasamento em 12 recomendações, denominadas
Princípios para o Desenvolvimento Ágil de Software [Princípios Ágeis 2001]. Estes
essencialmente ressaltando valores ao qual ajudam não apenas projetos para
desenvolvimento de software, mas acredita-se que todo e qualquer tipo de projeto.
O objetivo deste artigo não é comparar as Práticas dos Métodos Ágeis com o
Guia PMBOK, mas sim apresentar estes 12 Princípios e aplicá-los nas áreas de
conhecimento apresentadas no Guia PMBOK com intuito de enriquecer o
Gerenciamento de Projetos e não somente a parte proposta pela Declaração da
Interdependência [DOI 2005] para o Gerente de Projetos.
2. Onda Ágil em Software
Os Métodos Ágeis, ou também nominados de Agile, surgiram com o intuito de
desenvolvimento mais rápido e eficaz de softwares, proporcionando entregas mais
rápidas em detrimento de menos processos da Engenharia de Software [Magela 2006].
O desenvolvimento de software, orientado por práticas ágeis de forma
fortemente organizada como há atualmente, data do ano 2001 [História Manifesto
2001], onde 17 profissionais da TI, representantes das metodologias ágeis Extreme
Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-
Driven Development, Pragmatic Programming e outros simpáticos à causa, observaram
a necessidade de uma documentação formal que guiasse o desenvolvimento ágil,
criando assim o manifesto ágil [Manifesto 2001] e os 12 princípios [Princípios Ágeis
2001].
Os marcos iniciais, e mais conhecidos, que levaram a criação deste consórcio de
profissionais e da [Agile Alliance 2010], foram o projeto gerido por Kent Beck no qual
criou o XP (Extreme Programming), o Chrysler Comprehensive Compensation System,
comumente chamado de C3 [C3 1995] e o do United Overseas Bank, no qual Peter
Coad e Jeff de Luca implementaram o FDD (Feature-Driven Development) publicado
pela primeira vez em [Coad 1998].
A Onda Ágil é facilmente perceptível na quantidade crescente de eventos sobre
o assunto, exemplificando-se 2 deles do ano 2010, o ocorrido em Junho, Agile Brazil
2010 em Porto Alegre – RS, que teve mais de 700 inscritos [Agile 2010] e em Maio
ocorreu o Maré de Agilidade em Belo Horizonte – MG, com mais de 300 inscritos
[Maré 2010], havendo ainda grupos de usuários como o Guma-RS, [Guma 2010], que
planejou 10 eventos gratuitos para 2010.
3. Os 12 Princípios Ágeis aplicados ao PMBOK
Os 12 Princípios para o Desenvolvimento Ágil de Software [Princípios Ágeis 2001] é
uma coletânea dos autores do Manifesto Ágil [Manifesto 2001] sobre o que melhor

3. define outros métodos e processos como [Lean 2010], Espiral [Boehm 1988], RAD
[Martin 1991] dentre outros, somado a suas experiências pessoais.
Reiterando-se de conceitos básicos para o bem entendimento, como a definição
de projeto sendo “um esforço temporário empreendido para criar um produto, serviço
ou resultado exclusivo. A sua natureza temporária indica um início e um término
definidos.” afirma-se a importância do Guia PMBOK [PMBOK 2008] para o
Gerenciamento de Projetos, que é a aplicação de conhecimento, habilidades,
ferramentas e práticas às atividades do projeto a fim de atender aos seus requisitos.
O Gerenciamento de Projetos é a atividade do Gerente de Projetos, que por sua
vez o [PMBOK 2008] define em “a pessoa designada pela organização executora para
atingir os objetivos do projeto.”
O quadro abaixo referencia o Príncipio Ágil e a Área de Conhecimento com o
qual se faz a sua aplicação apresentado neste artigo.
Princípio dos Métodos Ágeis Área de Conhecimento do PMBOK
Nossa maior prioridade é satisfazer o Gerenciamentos de Integração,
cliente através da entrega contínua e Gerenciamentos de Escopo,
adiantada de software com valor agregado Gerenciamentos de Tempo,
Gerenciamentos de Custos,
Gerenciamentos de Qualidade,
Gerenciamentos de Recursos Humanos,
Gerenciamentos de Comunicações,
Gerenciamentos de Riscos e
Gerenciamento das Aquisições
Mudanças nos requisitos são bem-vindas, Gerenciamento de Integração,
mesmo tardiamente no desenvolvimento. Gerenciamento de Escopo,
Processos ágeis tiram vantagem das Gerenciamento de Mudanças,
mudanças visando vantagem competitiva Gerenciamento da Qualidade
para o cliente
Entregar frequentemente software Gerenciamento de Riscos,
funcionando, de poucas semanas a poucos Gerenciamento de Tempo
meses, com preferência à menor escala de
tempo
Pessoas de negócio e desenvolvedores Gerenciamento de Comunicações,
devem trabalhar diariamente em conjunto Gerenciamento de Riscos
por todo o projeto
Construa projetos em torno de indivíduos Gerenciamento de Recursos Humanos
motivados. Dê a eles o ambiente e o
suporte necessário e confie neles para
fazer o trabalho
O método mais eficiente e eficaz de Gerenciamento de Comunicações
transmitir informações para e, entre, uma

4. equipe de desenvolvimento é através de
conversa face a face
Software funcionando é a medida primária Gerenciamento de Tempo
de progresso
Os processos ágeis promovem Gerenciamento de Integração,
desenvolvimento sustentável. Os Gerenciamento da Qualidade
patrocinadores, desenvolvedores e
usuários devem ser capazes de manter um
ritmo constante indefinidamente
Contínua atenção à excelência técnica e Gerenciamento da Qualidade,
bom design aumenta a agilidade Gerenciamento de Recursos Humanos
Simplicidade – a arte de maximizar a Gerenciamento de Escopo,
quantidade de trabalho não realizado – é Gerenciamento de Tempo
essencial
As melhores arquiteturas, requisitos e Gerenciamento de Comunicações
designs emergem de equipes auto-
organizáveis
Em intervalos regulares, a equipe reflete Gerenciamento de Comunicações
sobre como se tornar mais eficaz e então
refina e ajusta seu comportamento de
acordo
Quadro 1 – Princípios Ágeis nas Áreas de Conhecimento
O Gerente de Projetos deve cercar-se de todos os meios que possam ajudá-lo em
sua tarefa, assim sendo, trazendo os 12 Princípios Ágeis para dentro do Gerenciamento
de Projetos. Pode-se definir que o 1º Princípio, “Nossa maior prioridade é satisfazer o
cliente através da entrega contínua e adiantada de software com valor agregado”
[Princípios Ágeis 2001], resulta em ter-se uma possível diminuição de um grande
projeto, para vários subprojetos, para assim, como ocorre no desenvolvimento de
software, tornar mais fácil conseguir mensurar erros que possam estar acontecendo,
assim como o principal, ir fomentando o patrocinador dos recursos financeiros já
aplicados no projeto.
A aplicabilidade deste princípio ao [PMBOK 2008] está em todas as áreas de
conhecimento como o Gerenciamentos de Integração, Gerenciamentos de Escopo,
Gerenciamentos de Tempo, Gerenciamentos de Custos, Gerenciamentos de Qualidade,
Gerenciamentos de Recursos Humanos, Gerenciamentos de Comunicações,
Gerenciamentos de Riscos e Gerenciamento das Aquisições. É o uso da antiga frase de
origem romana, “dividir para conquistar”.
O 2º Princípio, “Mudanças nos requisitos são bem-vindas, mesmo tardiamente
no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem
competitiva para o cliente” [Princípios Ágeis 2001], pode tornar-se o mais lucrativo em

5. sua aplicação ao Gerenciamento de Integração, Gerenciamento de Escopo,
Gerenciamento de Mudanças, e também ao Gerenciamento da Qualidade, [PMBOK
2008], fazendo a aplicação deste princípio no pressuposto de que todas as mudanças de
requisitos sugeridas são benéficas, algumas inaplicáveis no projeto atual, no entanto,
passíveis em uma extensão do projeto. Deixa, portanto, precedentes para um novo
contrato, somando-se ainda a questão a visão de mudanças estar alinhada a geração de
novos conhecimentos que sempre são reutilizáveis, referenciando-se a Gestão de
Conhecimento [Bukowitz 2002].
O 3º Princípio, “Entregar frequentemente software funcionando, de poucas
semanas a poucos meses, com preferência à menor escala de tempo”, [Princípios Ágeis
2001], é facilmente confundível com o 1º Princípio citado em termos de Gerenciamento
de Projeto, mas conceitualmente encara-se como ser mais fácil achar problemas em um
pequeno pedaço de um subprojeto do que no projeto inteiro, facilitando o
Gerenciamento de Riscos do Projeto, assim como a área de Gerenciamento de Tempo,
[PMBOK 2008], convergindo no grupo de processos do Gerenciamento de Cronograma
visando maior controle sobre o Gerenciamento do Projeto.
O 4º Princípio, “Pessoas de negócio e desenvolvedores devem trabalhar
diariamente em conjunto por todo o projeto”, [Princípios Ágeis 2001], reforça o uso de
comunicação constante entre Stakeholders e/ou Patrocinador com a equipe do projeto,
especialmente o Gerente de Projetos, [PMBOK 2008], tendo pelo Gerenciamento de
Comunicações, [PMBOK 2008], sua organização, facilitando as partes interessadas
identificadas nos processos de iniciação, o repasse de conhecimento sobre aquilo que
realmente necessitam e querem, facilitando o Gerenciamento de Riscos, [PMBOK
2008].
O 5º Princípio, “Construa projetos em torno de indivíduos motivados. Dê a eles
o ambiente e o suporte necessário e confie neles para fazer o trabalho”, [Princípios
Ágeis 2001], deve ser parte do Gerenciamento de Recursos Humanos do [PMBOK
2008], mas também presente em todos os demais, o trabalho deve ser motivado e pode
ser por ações de união entre os colaboradores, benefícios, ou simplesmente evitando
horas extras desnecessárias. É fazer com que o colaborador trabalhe gostando do que
está fazendo, sendo tal princípio diretamente presente em grandes empresas da área de
TI, como em [Google 2010] que informa que "No Google, sabemos que cada
funcionário tem algo importante a dizer e que cada um deles é parte integrante de nosso
sucesso".
O Princípio 6, “O método mais eficiente e eficaz de transmitir informações para
e, entre, uma equipe de desenvolvimento é através de conversa face a face”, [Princípios
Ágeis 2001], pelo [PMBOK 2008], trata sobre o Gerenciamento de Comunicações do
Projeto, sobre dar mais atenção a transferência de informações pessoalmente do que via
outra meio, assim contribuindo para inúmeras ferramentas importantes para um Gerente
de Projetos, como Marketing de Relacionamento [McKenna 1997].
O 7º Princípio, “Software funcionando é a medida primária de progresso”,
[Princípios Ágeis 2001], atua como um milestone, marco, para o Gerenciamento de
Tempo do [PMBOK 2008] em termos de software, e em termos de projeto pode ser
considerado como a correta realização de uma atividade de um pacote de processos.
O 8º Princípio, “Os processos ágeis promovem desenvolvimento sustentável. Os
patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo
constante indefinidamente”, [Princípios Ágeis 2001], vem claramente do processo Lean

6. [Lean 2010], onde o objetivo é a produção contínua e com isso gerenciável pelo
Gerenciamento de Integração [PMBOK 2008] e mensurável pelo Gerenciamento da
Qualidade, [PMBOK 2008].
O 9º Princípio, “Contínua atenção à excelência técnica e bom design aumenta a
agilidade”, [Princípios Ágeis 2001], é adaptável ao Gerenciamento da Qualidade do
[PMBOK 2008], onde tendo-se atividades bem realizadas haverá menor retrabalho,
consequentemente um projeto de melhor qualidade e ainda uma equipe menos
desmotivada por erros, portanto tendo satisfação em trabalhar, contribuindo para o
Gerenciamento de Recursos Humanos [PMBOK 2008].
O 10º Princípio, “Simplicidade – a arte de maximizar a quantidade de trabalho
não realizado – é essencial”, [Princípios Ágeis 2001], em comparação ao [PMBOK
2008] é considerado por muitos autores o mais conflitante, tendo em consideração que
profissionais atacam os Métodos Ágeis [Pacheco 2010] em defesa de práticas
difundidas pelo PMBOK e outros acreditam que ambas podem trabalhar juntas, como
[Tavares 2008], onde pode-se afirmar que o Princípio Ágil é a recomendação de não
perder muito tempo planejando o que não vai ser necessário fazer, realizando-se uma
reanálise sobre o escopo do Gerenciamento de Escopo, [PMBOK 2008], mas também
pode ser aplicado tal princípio no quesito de otimização do Gerenciamento de Tempo,
[PMBOK 2008], reajustando atividades e criando-se um perfil de Gerente de Projetos
mais audaz.
O 11º Princípio, “As melhores arquiteturas, requisitos e designs emergem de
equipes auto-organizáveis”, [Princípios Ágeis 2001], está na mesma área do 8º
Princípio, onde tendo um bom relacionamento no Gerenciamento de Comunicações,
[PMBOK 2008], a equipe trabalha como um todo melhor, tendo o Gerente de Projetos a
real função de gerenciar o projeto, aplicando maior atenção ao projeto e não em
comandar a equipe de trabalho do projeto.
Finalizando, o 12º Princípio, “Em intervalos regulares, a equipe reflete sobre
como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo”,
[Princípios Ágeis 2001], acrescenta novamente a importância do Gerenciamento de
Comunicações para o bom andamento de um projeto, uma das práticas comuns em
Métodos Ágeis para Desenvolvimento de Software são as stand-up meeting, ou reuniões
em pé, [Teles 2004], onde os membros da equipe, conversam rapidamente fazendo um
retrospectiva breve do que vem ocorrendo de forma satisfatória, ou não, sendo
conveniente a aplicabilidade deste princípio em todos os 5 grupos de processos:
Iniciação, Planejamento, Execução, Monitoramento e Controle, Encerramento,
[PMBOK 2008].
Conclusão
A crescente aceitação e uso dos Métodos Ágeis vem da busca por soluções que
demandem melhores resultados e menores prazos em projetos de softwares, porém as
mesmas trazem valores e princípios que não são novos, mas que ressurgiram fazendo
uma enorme diferença nas empresas que é o recurso humano, ações como o Manifesto
2.0 [Manifesto 2009] reforçam tal conceito.
Observar os Métodos Ágeis de Desenvolvimento de Software, por outra ótica,
focando-se em seus Princípios Ágeis e não em suas Práticas, pode ser uma solução sem
maiores alterações conceituais para o bom Gerenciamento de Projetos por parte de um
Gerente de Projetos, tornando mais ameno os problemas básicos de comunicação e

7. tornando-o, mais atento a áreas como Gerenciamento de Mudanças, Tempo, Qualidade
e Comunicações.
Referências
Agile Brazil. (2010) “Conferência Brasileira sobre Métodos Ágeis de Desenvolvimento
de Software”, http://www.agilebrazil.com, Junho.
Agile Alliance (2010) “Agile Alliance”, http://www.agilealliance.org/, Junho.
Bukowitz, W., Willians, R.L. (2002). “Manual da Gestão do Conhecimento:
Ferramentas que criam valor para a empresa” Porto Alegre: Bookman.
Boehm, Barry W. (1988) "A Spiral Model of Software Development and Enhancement"
Los Alamitos: IEEE Computer Society Press, vol. 21, no. 5
C3 (1995) “Chrysler Comprehensive Compensation System”,
http://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System,
Junho
Coad, Peter et al (1998) “Java Modeling In Color With UML: Enterprise Components
and Process”. Upper Saddle River: Prentice Hall
Cohen, D., Lindvall, M., & Costa, P. (2004). “An introduction to agile methods. In
Advances in Computers.” New York: Elsevier Science.
DOI (2005) “Declaration of Interdependence”, http://pmdoi.org/, Junho.
Dr. Doob's Journal. (2009) “State of the IT Union Survey”,
http://www.ambysoft.com/surveys/stateOfITUnion200907.html, Junho.
Google. (2010) “Vida no Google”,
http://www.google.com.br/support/jobs/bin/static.py?page=about-br.html, Junho.
Guma-RS. (2010) “Grupo de Usuários de Metodos Ágeis”, http://www.guma-rs.org,
Junho.
História Manifesto. (2001) “History: The Agile Manifesto”,
http://agilemanifesto.org/history.html, Junho.
Koch, Alan S. (2004) “Are Agile Methods Compatible with the PMBOK?”,
http://www.smartlogicsystems.com/pmbokweb/AgileManifesto-PMBOK.pdf, Junho.
Lean. (2010) “Lean Insitute Brasil”, http://www.lean.org.br, Junho.
Martin, James (1991) “Rapid Application Development”, New York: Macmillan Coll
Div.
Magela, Rogerio. (2006) “Engenharia de Software Aplicada: Princípios (volume 1).”
Rio de Janeiro: Alta Books.
Manifesto Ágil. (2001) “History: The Agile Manifesto”,
http://agilemanifesto.org/iso/ptbr/, Junho.
Maré de Agilidade. (2010) “Maré de Agilidade, Metodos Ágeis”,
http://www.maredeagilidade.com.br, Junho.
McKenna, R. (1997) “Marketing de Relacionamento”, tradução: Outras Palavras. Rio
de Janeiro. Elseiver

8. Pacheco, Diego. (2009) “Seja Inteligente e não use Agile”,
http://imasters.uol.com.br/artigo/14565/desenvolvimento/seja_inteligente_e_nao_use
_agile/, Junho.
PMBOK. (2008) “Um guia do conhecimento em Gerenciamento de Projetos: Quarta
Edição”, www.pmi.org, Junho.
Princípios Ágeis. (2001) “Princípios por trás do Manifesto Ágil”,
http://agilemanifesto.org/iso/ptbr/principles.html, Junho.
Sliger, Michele. (2006) “Relating PMBOK Practices to Agile Practices.”
http://www.stickyminds.com/s.asp?F=S10365_COL_2, Junho.
Standish Group. (2009) “The Chaos Report”, http://www.pmhut.com/the-chaos-report-
2009-on-it-project-failure, Junho.
Tavares, Aleckssandro. (2008) “Gerência de Projeto com PMBOK e SCRUM: Um
Estudo de Caso”, http://pessoal.facensa.com.br/sidnei/files/TCCI-
EmAndamento/aleckssandrotavares.pdf, Junho.
Teles, Vinícius Manhães. (2004) “Extreme Programming: Aprenda como encantar seus
usuários desenvolvendo software com agilidade e alta qualidade.” São Paulo:
Novatec.
VersionOne. (2008) “3rd Annual Survey: The State of Agile Development”,
http://www.versionone.com/pdf/3rdAnnualStateOfAgile_FullDataReport.pdf, Junho.
Bukowitz, W., Willians, R.L. (2002). “Manual da Gestão do Conhecimento:
Ferramentas que criam valor para a empresa” Porto Alegre: Bookman.