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

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

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 cliente através da entrega contínua e

adiantada de software com valor agregado

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

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

Gerenciamento de Integração, Gerenciamento de Escopo,

Gerenciamento de Mudanças, Gerenciamento da Qualidade

Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de

tempo

Gerenciamento de Riscos,Gerenciamento de Tempo

Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto

por todo o projeto

Gerenciamento de Comunicações, Gerenciamento de Riscos

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

Gerenciamento de Recursos Humanos

O método mais eficiente e eficaz de transmitir informações para e, entre, uma

Gerenciamento de Comunicações

equipe de desenvolvimento é através de conversa face a face

Software funcionando é a medida primária de progresso

Gerenciamento de Tempo

Os processos ágeis promovem desenvolvimento sustentável. Os

patrocinadores, desenvolvedores e usuários devem ser capazes de manter um

ritmo constante indefinidamente

Gerenciamento de Integração, Gerenciamento da Qualidade

Contínua atenção à excelência técnica e bom design aumenta a agilidade

Gerenciamento da Qualidade, Gerenciamento de Recursos Humanos

Simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é

essencial

Gerenciamento de Escopo, Gerenciamento de Tempo

As melhores arquiteturas, requisitos e designs emergem de equipes auto-

organizáveis

Gerenciamento de Comunicações

Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então

refina e ajusta seu comportamento de acordo

Gerenciamento de Comunicações

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

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

[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

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

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.