projetos, especialmente na área de desenvolvimento de software. Em primeiro lugar, o próprio nome “gerenciamento ágil”, indica, de forma intencional ou não, que haja “agilidade”. Inclusive, é comumente citado nos textos sobre gerenciamento ágil de projetos. Porém, conforme discutido na seção anterior, a agilidade per si não tem sido bem definida pelos autores das áreas precursoras no uso de tal conceito.
Do mesmo modo, esta evidência se confirma em gerenciamento de projetos. Há inúmeras publicações na área de projetos de desenvolvimento de software que adotaram o termo para descrever a abordagem do “Gerenciamento Ágil de Projetos” – GAP (BOEHM, 2002; BOEHM; TURNER, 2004; DECARLO, 2004; SANJIV; WOODCOCK, 2003; CHIN, 2004; HIGHSMITH, 2004; SCHWABER, 2004; AUGUSTINE, 2005; COHN, 2005; HODGETTS, 2005; GRIFFITHS, 2005; SALO; ABRAHAMSSON, 2007).
A maioria dos textos argumentam que o objetivo do gerenciamento ágil de projetos é levar à “agilidade”. Porém, o termo agilidade em si não é discutido em detalhe. O principal foco recai sobre as práticas, técnicas e ferramentas dessa abordagem voltadas para a gestão do projeto, em um discurso prescritivo, que visa a aplicação da abordagem e seus princípios. O
argumento é de que as “práticas ágeis” levam a maior agilidade de modo incondicional. Se o projeto é gerenciado segundo esta abordagem, ele é “ágil”.
Isso pode ser uma explicação para ausência de estudos que exploram o conceito segundo a perspectiva do gerenciamento de projetos. Este problema pode ter como causa provável a fundamentação teórica utilizada nesses textos, pois não consideram trabalhos da área de manufatura e desenvolvimento de produtos, que apresentam histórico de aplicação do conceito agilidade. Além disso, boa parte dos textos foram concebidos por profissionais e consultores que descrevem as experiências com empresas.
Outra explicação plausível pode ter origem no fato dessa teoria ser mais recente, conforme evidenciado na Figura 7. A Figura ilustra a evolução da frequência de uso dos termos (bi-grams) representados pelas palavras-chave “agile manufacturing”, “agile method”, e “agile project management” encontradas em livros digitalizados na ferramenta Google Books26.
Figura 7. Ngram Viewer Google Books com as palavras “agile manufacturing”, “agile method”, e “agile project
management” – consulta realizada em 28 de Novembro de 2012.
Fonte: elaborado pelo autor com base na ferramenta Ngram Viewer do Google .
A ferramenta Google Ngram Viewer27 faz este levantamento de frequência baseado em livros clássicos, de domínio público, digitalizados pela empresa Google ou identificados
26 Para consultar o Google Books veja o sítio: http://books.google.com/.
27 A ferramenta Ngram Viewer do Google possibilita a visualização da evolução do uso de palavras,
termos ou assuntos publicados em livros registrados no Google Books (livros clássicos na íntegra e partes de livros publicados ou obtidos em catálogos de livros vendidos). Não se pode confirmar os resultados demonstrados pela ferramenta. Trata-se apenas de mais um indício utilizado na argumentação deste trabalho. A ferramenta pode ser consultada em: http://books.google.com/ngrams.
na internet. Nota-se a evolução do termo “agile manufacturing” a partir do final da década de 80. Os termos “agile method” e “agile project management” aparecem na pesquisa somente no final da década de 90.
No decorrer dos anos, o termo “agilidade”, quando aplicado ao gerenciamento de projetos assumiria diferentes interpretações. Uma delas é a de habilidade. Citam-se como exemplos: a) “ habilidade para criar e responder às mudanças para ser lucrativo em um ambiente turbulento de negócios” (HIGHSMITH, 2004); b) “aplicar conhecimentos e experiências para se adaptar a novos ambientes, reagir e aproveitar oportunidades inesperadas” (BOEHM; TURNER, 2004); e c) “habilidade para entregar valor para o cliente, se ajustando ao dinamismo e imprevisibilidade do projeto, por meio da identificação e adaptação às mudanças” (AUGUSTINE, 2005).
Outra interpretação possível associa agilidade com o método ou prática. Por exemplo, a definição proposta por Ericksson et al. (2005), na qual a agilidade significa reduzir o máximo possível de burocracia (“peso”), comumente associada com as metodologias tradicionais de projeto de desenvolvimento de software, para promover a capacidade de prover respostas rápidas às mudanças ambientais, mudanças nos requisitos dos usuários, e acelerar a entrega dos projetos28. A mesma conotação, com foco específico no método, pode ser encontrada na definição de Conboy (2009, p. 340)29:
“A disponibilidade contínua de um método de desenvolvimento de software para rapidamente ou inerentemente criar a mudança, absorver a mudança de forma proativa ou reativa, e aprender com a mudança enquanto se contribui para o valor percebido pelo cliente".
Existem trabalhos cujo foco é avaliar o gerenciamento ágil de projetos considerando o conceito agilidade como um aspecto de comparação entre diferentes métodos. Por exemplo, Qumer e Henderson-Sellers (2008) avaliaram alguns dos principais métodos ágeis para desenvolvimento de software. Consideraram dimensões como: (i) escopo do método, descrito
28 Interpretação e tradução livre da definição proposta por Ericksson et al. (2005). 29 Tradução livre da definição proposta por Conboy (2009, p. 340).
pelo tamanho da equipe, tamanho do projeto, desenvolvimento iterativo ou linear; (ii) características da agilidade, descritas como flexibilidade; velocidade; simplicidade; e prontidão30 para respostas rápidas; (iii) valores ágeis, baseados no manifesto para desenvolvimento ágil de software, e por fim, (iv) processo.
Para realizar a análise os entrevistados por Qumer e Henderson-Sellers (2008) atribuiram notas para cada dimensão por meio de perguntas diretas. As escalas possuem limitações, por exemplo, a escala apresenta um viés, pois traz alternativas que podem induzir ao juízo de valor. Por exemplo, nenhum respondente iria dizer que seu desenvolvimento é “lento”. Outro problema está na dimensão (ii) características da agilidade. Os autores propuseram medir a agilidade por meio da flexibilidade, velocidade, simplicidade e prontidão. No entanto, tais variáveis podem ser consideradas complexas, pois estão no nível de construtos, e não são explicadas pelos autores do estudo. O termo “flexibilidade”, por exemplo, pode ser considerado por si só um conceito, conforme discutido na seção 2.3.
Qumer e Henderson-Sellers (2008) também não fazem distinção entre práticas gerenciais e fatores ambientais. Por exemplo, o “desenvolvimento iterativo” pode ser considerado uma prática gerencial. Já o “tamanho da equipe” e “tamanho do projeto”, podem ser classificados como fatores ambientais, ou seja, características inerentes do tipo de projeto. Ambos são analisados como dimensões de um mesmo construto.
Há também trabalhos que avaliaram a agilidade no nível de projeto. É o caso de Mafakheri, Nasiri e Mousavi (2008). Os autores avaliaram a agilidade segundo seis dimensões: dinamismo (habilidade para alterar os requisitos e realizar entregas rápidas de partes do software funcionando); tamanho da equipe de projeto (equipes com poucos integrantes); comunicação (proximidade com o cliente do projeto, simplicidade na documentação); teste (capacidade para testar os resultados frequentemente); conhecimento e
habilidades dos desenvolvedores (profissionais com competência e conhecimento para adaptar o processo sempre que necessário); e por fim, cultura (autonomia dos membros da equipe para que possam sugerir melhorias no processo e propor soluções).
A proposta de Mafakheri, Nasiri e Mousavi (2008) é limitada. Ela considera apenas variáveis relacionadas com fatores ambientais do projeto para explicar o construto agilidade. A proposta não oferece uma definição operacional e a medição das variáveis torna-se um processo pouco confiável e de difícil replicação. Além disso, os autores não consideraram em seu modelo conceitual o relacionamento entre agilidade e as práticas gerenciais da teoria de gerenciamento ágil de projetos.
Mais recentemente, o trabalho de Sheffield e Lemétayer (2012) mostrou um levantamento com 106 respondentes em nível internacional, com as comunidades de desenvolvimento de software chamadas PRINCE231, PMI e Agile. Os autores utilizaram como variáveis de medida os “valores” conforme texto do manifesto ágil32 e adicionaram o
construto “flexibilidade do ciclo de desenvolvimento”, como medidas de agilidade no desenvolvimento de software. Os autores analisaram 7 fatores do ambiente de projeto (como apoio da alta gerência, treinamento, cultura para absorver riscos, etc.), com 13 fatores relacionados com o projeto (como co-localização, colaboração e comprometimento do cliente, tamanho do time, etc.).
O estudo de Sheffield e Lemétayer (2012) traz contribuições relevantes para esta pesquisa, tais como a identificação de fatores ambientais que apresentaram relacionamento com a “agilidade no desenvolvimento de software”, como por exemplo: a colaboração e envolvimento do cliente no projeto e a co-localização dos membros da equipe. Entretanto, os próprios autores recomendam o aprofundamento da investigação e estudo sobre os “indicadores de agilidade” no desenvolvimento de software. Além disso, há o viés de se
31 Projects In Controlled Environments version 2. Informações adicionais sobre o método estão
disponíveis no sítio: http://en.wikipedia.org/wiki/PRINCE2
utilizar os valores do manifesto ágil (BECK et al., 2001), o que pode induzir os respondentes em fornecerem respostas tendenciosas, pois a amostra trata de profissionais da área de desenvolvimento de software que possivelmente estão familiarizados com os valores do manifesto.
Uma análise dos estudos apresentados indica que, uma prática de gerenciamento de projetos, técnica ou ferramenta não pode ser considerada “ágil” de modo incondicional, sem considerar os efeitos e resultados no projeto, ou a relação com fatores ambientais ou aspectos específicos de cada projeto em particular. As indagações são pertinentes. Como diferenciar o uso de práticas do gerenciamento ágil evitando-se respostas tendenciosas? Como se certificar de que a prática ou método é realmente ágil? Será que a “prática ágil” realmente confere “agilidade” ao projeto? Em sua maioria, os autores não discutem tais questionamentos, tão pouco definem o conceito “agilidade” de forma que seja possível verificá-lo sem o viés da abordagem de gerenciamento ágil de projetos.
Conboy (2009) é um dos poucos autores que discute os problemas de ordem teórica relacionados com o conceito “agilidade” na área de desenvolvimento de software. Dentre os principais, o autor cita a ausência de uma definição clara e concisa do termo agilidade e a falta de consistência (fundamentação) teórica. Por exemplo, existem definições que apresentam elementos comuns, encontrados na definição proposta por Highsmith (2004), e nas definições da área de manufatura e gestão de organizações (GOLDMAN; NAGEL; PREISS, 1995; SHARIFI; ZHANG, 2001).
Isso indica, portanto, que pode existir uma correlação entre as definições, uma tentativa de adaptação do conceito, ou mesmo a necessidade de se construir o conceito com foco específico em gerenciamento de projetos. Conboy (2009) também destaca problemas relacionados com a fundamentação teórica dos trabalhos, visto que os métodos ágeis surgiram como resultado da experiência prática de consultores e profissionais da área.
Dessa forma, os trabalhos não apresentam o devido rigor científico necessário para a construção do conceito “agilidade”, que em tese, daria sustentação teórica para a evolução da abordagem do gerenciamento ágil de projetos, e poderia ser uma contribuição teórica fundamental para a teoria geral de gerenciamento de projetos.