Diferenciando as abordagens tradicional e ágil de gerenciamento de projetos

Differentiating traditional and agile project management approaches

Resumos

As críticas recentes à teoria tradicional de gerenciamento de projetos resultaram em uma nova abordagem, denominada Gerenciamento Ágil (GAP). A dificuldade em investiga-la é que não há instrumentos de pesquisa capazes de distinguir sua aplicação em organização ou projeto, o que impede correlação com desempenho. Esta pesquisa teve como objetivo identificar diferenças críticas capazes de caracterizar o uso do GAP. Iniciou-se com uma revisão bibliográfica sistemática para identificar práticas recomendadas em cada abordagem, decompostas em ações, técnicas e ferramentas. Elas foram comparadas entre si e com ações observadas in loco em dois estudos de caso, incorporados, de empresas com excelência reconhecida no uso de cada abordagem: ágil e tradicional. O resultado foi a identificação de seis características críticas que diferenciam o uso de uma ou outra abordagem. Elas podem ser utilizadas para a elaboração de instrumentos de pesquisa, aumentando a precisão da identificação das abordagens em campo: uma contribuição para que o desempenho do GAP possa ser cientificamente verificado.

Administração de projetos; Metodologia do projeto de produtos; Gerenciamento ágil de projetos; Práticas de gerenciamento de projetos

The project management (PM) theory has been criticized, resulting in a new approach known as the Agile Project Management (APM) approach. The assessment of these two approaches is challenging due to the lack of parameters that are available to aid in distinguishing them from one another. The objective of this paper is to identify critical differences between project management practices that are capable of revealing the appropriate project management approach to be adopted by a company. First, a project management practices list was developed and classified according to each approach. Comparing practices that have originated from each approach made it possible to identify the difference regarding how the actions are performed, instead of what tools or techniques are used. Additionally, six main characteristics of project management actions were identified that make it possible to differentiate between the traditional or agile approach in use. This result can be very useful in future research as a guide in the development of more confident approach assessment instruments.

Project management; Product design methodology; Agile project management; Project management practices

1. Introdução

Os problemas com a aplicação de métodos de gerenciamento de projetos em produtos inovadores fizeram parte da agenda de profissionais e pesquisadores no início dos anos 2000 (Dawson & Dawson, 1998; Williams, 1999; Perminova et al., 2008). A busca por soluções levou ao desenvolvimento de abordagens alternativas, isso é, teorias com princípios, técnicas e ferramentas, mais tarde rotuladas por Gerenciamento Ágil de Projetos – GAP (Amaral et al., 2011).

O desafio atual é verificar os benefícios e restrições dessa abordagem e os estudos comparativos são o meio mais confiável para a verificação. A estratégia é identificar empresas que utilizam a abordagem, o GAP, e empresas que não a utilizam, para, em seguida, comparar desempenho, vantagens e desvantagens.

Os estudos que empregam tal estratégia, porém, apresentam uma limitação recorrente e fundamental: imprecisão na caracterização da adoção, ou não, das práticas ágeis por parte de uma organização ou equipe de projeto. Eles falham na avaliação do nível de uso da abordagem GAP e, portanto, não garantem se a empresa em questão utiliza ou não tais práticas; o que invalida os resultados. Por exemplo, Mafakheri et al. (2008) definiram agilidade de projeto e a avaliaram utilizando termos imprecisos e abstratos como "dinamismo". Qumer & Henreson-Sellers (2008) e Ganguly et al. (2009) utilizaram princípios gerais, avaliados segundo percepções dos gerentes de projeto. Como os gerentes podem estar influenciados pela novidade, não é possível saber se as empresas analisadas estavam utilizando as práticas (ações, métodos e ferramentas) e, em essência, a abordagem.

Se o uso da abordagem GAP não pode ser comprovado de maneira isenta e categórica, a relação entre a sua aplicação e o desempenho não pode ser considerada válida, e a nova teoria não pode, consequentemente, ser comprovada. É o que argumentam Sauser et al. (2009): não é possível avaliar precisamente a contribuição das teorias de gerenciamento de projetos sem antes identificar e categorizar precisamente as práticas adotadas. Segundo esses autores, as pesquisas na área falham ao não estabelecerem a relação entre tipo de projeto, prática e desempenho. No caso específico da teoria do Gerenciamento Ágil de Projetos, a causa é a ausência de instrumentos de pesquisa capazes de gerar evidências e realizar a identificação precisa da sua adoção por uma organização.

Uma possível solução para esse problema seria a criação de um instrumento de pesquisa que pudesse identificar com precisão a abordagem de gerenciamento de projetos em uso por uma determinada organização, e que o fizesse de forma a empregar o menor esforço possível por parte do pesquisador. Isso é possível por meio da identificação do menor conjunto de "características observáveis", que, uma vez descritas, permitam identificar se a abordagem utilizada é ou não a do gerenciamento ágil.

Essa pesquisa procurou solucionar esse problema combinando revisão bibliográfica sistemática e estudos de caso incorporados. A revisão foi utilizada para extrair do corpus, ou conjunto de textos da área, as práticas identificadas nas duas literaturas: GAP e tradicional. Em seguida foram observadas as práticas de gerenciamento utilizadas em duas empresas reconhecidas por sua experiência no uso de cada abordagem. Ambas desenvolvedoras de produtos complexos, mas que adotavam gerenciamento ágil e tradicional, respectivamente. A análise das práticas reais com as práticas previstas na teoria, de ambas as abordagens, foi realizada de forma a detectar características observáveis que poderiam distinguir o tipo de abordagem utilizada.

O artigo está estruturado em oito seções. As primeiras três seções apresentam as definições básicas e o método de pesquisa. A seção 4 apresenta o modelo conceitual, desenvolvido a partir da análise da literatura. As seções 5 e 6 descrevem os resultados dos estudos de caso. A seção 7 contém a análise completa dos dados, isso é, a comparação entre os resultados observados nos estudos de caso e o modelo teórico. Por fim, a conclusão final, na seção 8.

2. Práticas e abordagens para o gerenciamento de projetos

A expressão "prática de GP" é utilizada amplamente na literatura da área e há vários estudos que buscam identificá-la. Eder et al. (2012) definiram prática de GP considerando 15 definições existentes. Segundo os autores, uma prática é uma atividade, composta por três elementos: a ação em si (algo que gera resultado) e que pode utilizar uma ou mais técnicas (um procedimento sistemático) e uma ou mais ferramentas (artefatos que apoiam a realização da ação, no contexto da técnica). A Figura 1 representa esquematicamente esse conceito e reforça o fato de uma prática poder conter mais de uma técnica e ferramenta.

Figura 1
Ilustração do conceito de prática e seus elementos constitutivos.

As práticas de GP foram disseminadas no decorrer dos anos por meio da sistematização de "guias de conhecimento" (Kioppenborg & Opfer, 2002; Kolltveit et al., 2007;Shenhar & Dvir, 2007). Tais guias apresentam um conjunto de ações, técnicas e ferramentas para gerir projetos de qualquer natureza.

As guias são rotuladas atualmente como "teoria tradicional" devido ao surgimento de novas teorias, que propõem princípios, ações, técnicas e ferramentas ditos novos. Há vários autores e eles empregam diferentes denominações (Thomke & Reinersten, 1998; Smith, 2007; Shenhar & Dvir, 2007; Wysocki & McGary, 2007;Decarlo, 2004; Chin, 2004; Highsmith, 2004; Schwaber, 2004). Em comum, utilizam o rótulo de métodos ágeis de gerenciamento de projetos, ou simplesmente Gerenciamento Ágil de Projetos – GAP.

O uso dessas abordagens está crescendo e estão surgindo os primeiros trabalhos empíricos que buscam adaptá-las para diferentes tipos de projetos (Conforto & Amaral, 2009, 2010a, b), que descrevem casos de implantação (Carvalho & Mello, 2012) e, também, trabalhos que buscam avaliá-los em condições reais, segundo as práticas, técnicas e ferramentas do GAP (Mafakheri et al., 2008; Qumer & Henderson-Sellers, 2008; Ganguly et al., 2009).

Por exemplo, o trabalho de Mafakheri et al. (2008) avalia a agilidade do projeto. Os autores propõem um indicador de agilidade com base em seis dimensões: dinamismo (habilidade nas alterações dos requisitos e entregas rápidas de partes do software funcionando); tamanho da equipe (equipes menores); comunicação (proximidade com cliente, simplificação da documentação); teste (ser capaz de testar os resultados frequentemente); conhecimento e habilidades dos desenvolvedores (pessoas habilitadas e com conhecimento suficiente para adaptar o processo); e cultura (liberdade para que os envolvidos no projeto possam adaptar o processo e propor soluções). Embora apresente um indicador de agilidade composto por tais variáveis, os construtos e dimensões utilizados são amplos e indefinidos. O resultado, portanto, não é confiável.

A proposta de Qumer & Henderson-Sellers (2008) é avaliar os métodos ágeis segundo quatro dimensões: 1) escopo do método (tamanho da equipe; tamanho do projeto; tipo de desenvolvimento – iterativo ou linear); 2) características da agilidade (flexibilidade; velocidade; simplicidade; e prontidão para respostas rápidas, do inglêsresponsiveness); 3) valores ágeis (baseado no manifesto ágil); e 4) processo. São atribuídas notas para cada item através de perguntas diretas. Exemplo, qual o estilo de desenvolvimento (uso de escalas como iterativo, rápido)? Além da imprecisão devida à ausência de definição, o questionamento é subjetivo e há viés na escala, pois nenhum respondente iria mencionar "lento", que remete à juízo de valor negativo. No final é realizada a análise para identificar o método mais "ágil" segundo essas quatro dimensões e as fases e práticas propostas.

Ganguly et al. (2009) consideram quatro métricas para avaliar as práticas de gerenciamento de projetos: qualidade (do produto do projeto); lucratividade (indica a fatia de mercado que a empresa representa); velocidade (avalia a capacidade de resposta por meio do indicador "média de tempo do ciclo de desenvolvimento de produtos da indústria", dividida pela média da empresa); e custo (mensurado através da medida do custo do ciclo de desenvolvimento da indústria pela média da empresa avaliada). A limitação está na abrangência de tais variáveis, que não medem práticas adotadas, apenas resultados. A avaliação de uma empresa como ágil, segundo tais critérios, não é garantia da aplicação da abordagem.

Um primeiro esforço no sentido de identificar se empresas estão usando práticas ágeis surgiu como uma iniciativa na Nokia e foi aprimorado e popularizado por Jeff Sutherland. Trata-se de um instrumento para autodiagnóstico, disponível em umsite aberto, denominado Nokia Test (Nokia Test, 2009). O instrumento indica se uma equipe utiliza práticas do Scrum, uma das abordagens teóricas do GAP. A análise desse instrumento demonstra que se trata de pesquisa exploratória, sem rigor científico. A forma como o questionário foi obtido e sua validação não são apresentadas pelos autores. O próprio criador menciona que é um teste "simples", em uma escala de 1 a 10. Detalhes das perguntas podem ser vistos no endereço: <http://jeffsutherland.com/nokiatest.pdf>.

Em suma, há um conjunto de práticas de gerenciamento de projetos mais bem estabelecido nos corpos padronizados de conhecimento, denominado abordagem tradicional. Um outro conjunto de práticas sugeridas em literatura mais recente e que ainda não se encontra bem estabelecida é rotulada de Gerenciamento Ágil de Projetos – GAP. E não há modelos consistentes e capazes de diferenciar práticas gerenciais das duas teorias, ou mesmo avaliar de modo preciso e confiável qual delas está sendo adotada em uma determinada organização ou equipe de projeto.

3. Método

A primeira parte (etapa 1) constituiu-se da revisão bibliográfica sistemática (RBS), compreendendo o período de 2000 até 2011. A escolha deveu-se ao ano de lançamento do manifesto para gerenciamento ágil de projetos (Beck et al., 2001).

Essa parte foi dividida em três fases, conforme proposta de Conforto et al. (2011). Na etapa 1.1 foi realizado um levantamento das práticas, isso é, ações, técnicas e ferramentas, em um conjunto de referências primárias, livros e artigos mais citados na área. Essa fase resultou em um conjunto de palavraschave, revistas, autores e bases mais significativas. A segunda etapa (etapa 1.2) teve uma busca semelhante, aplicada nesse momento em bases de dados (Web of Science, Portal Capes e Scopus) e revistas principais (87 periódicos) com strings de busca. O resultado final foi uma base de artigos no Mendeley. Por fim, na etapa 1.3 foi realizada uma classificação e síntese das práticas, técnicas e ferramentas encontradas nas fases anteriores. Os detalhes de cada uma das etapas da primeira parte da pesquisa são descritos na seção 4, juntamente com a apresentação do resultado final, para permitir que o leitor acompanhe as escolhas e procedimentos realizados durante a revisão.

A segunda parte da pesquisa (etapa 2) envolveu a análise de casos. O objetivo foi descrever as práticas em detalhes, por meio de observação, e comparar tais observações com o modelo teórico elaborado na fase anterior.

A amostragem dos casos foi intencional: analisaram-se grupos de projetos em duas empresas distintas e sabidamente experientes em gerenciamento de projetos, mas que utilizavam abordagens de gestão distintas: tradicional e ágil. As indicações de experiência no uso das abordagens foram feitas de forma a verificar se o modelo permitiria diferenciá-las. Trata-se de um artifício para que as práticas das duas teorias pudessem ser observadas e verificadas, seguindo a proposta de Eisenhardt (1989) para a construção de teorias utilizando estudos de caso.

Existem fatores relacionados ao tipo de projeto (nível de inovação, produto final do projeto, tamanho da empresa e outros) que sabidamente poderiam influenciar na adoção das práticas. Optou-se por equiparar esses fatores empregando projetos com características comuns nos dois casos. Por isso restringiu-se para projetos com maior grau de inovação e cujo resultado fossem novos produtos e empresas de médio ou grande porte. A explicação é que a teoria de gerenciamento ágil de projetos é indicada para projetos inovadores ou desenvolvimento de novos produtos. Empresas médias e grandes seriam mais adequadas pelo maior nível de complexidade a se esperar nesses projetos, permitindo verificar o maior número de práticas.

Portanto, foram definidos cinco critérios para escolha das empresas: C1) Possuir um processo definido de gerenciamento de projetos; C2) Identificar-se como usuária da teoria tradicional ou ágil como guia para o processo de gerenciamento de projetos, sendo necessariamente uma delas ágil e a outra tradicional; C3) Desenvolver projetos de produtos inovadores; C4) Desenvolver tecnologia ou produto (hardware, software, ou ambos); C5) Ser empresa de médio ou grande porte.

A segunda parte da pesquisa foi realizada em cinco etapas, seguindo as orientações deYin (2001), Voss et al. (2002) e Miguel (2010).

Os roteiros utilizados nas entrevistas foram desenvolvidos na etapa 2.1, três ao todo, denominados de instrumento A, B e C. Iniciou-se então a etapa 2.2, com a aplicação do instrumento A junto ao responsável pela área de desenvolvimento de produtos da empresa, com dois objetivos: primeiro, verificar a adequação do caso aos critérios estabelecidos; segundo, gerar informações para a escolha dos projetos a serem estudados na segunda etapa, caso a empresa atendesse aos requisitos. Esse instrumento (roteiro de entrevista) continha quatro partes: descrição geral (tamanho, número de colaboradores, tempo no mercado e outros), dados do entrevistado (posição, função e experiência), dados das unidades de negócio (estrutura organizacional da empresa e linhas de produto), dados de inovação (indicadores de inovação, classificação dos tipos de inovação dos projetos por linha de produto e parcerias tecnológicas), cultura de gerenciamento de projetos (início da experiência com técnicas de gerenciamento de projetos, existência ou não de PMO, técnicas utilizadas e datas de início de sua utilização e a abordagem utilizada pela empresa).

Na etapa 2.3 foram realizadas entrevistas com múltiplos respondentes para levantamento dos dados de cada projeto, de forma a obter diferentes percepções acerca do fenômeno (Voss et al., 2002). O levantamento iniciava-se com os líderes do projeto, para descrever as características de cada projeto. Foi utilizado o segundo roteiro de pesquisa previamente elaborado, denominado de instrumento B, contendo quatro partes: dados do entrevistado (nome, função, experiência na função, nível de educação e certificação ou treinamento em gerenciamento de projetos), características do projeto (tempo de duração, esforço, urgência e grau de inovação), descrição da equipe (tamanho, competências, experiência, localização e experiência em gerenciamento de projetos) e desempenho do projeto (desempenho em prazo, em orçamento e em qualidade dos resultados alcançados).

Em seguida realizou-se um levantamento das práticas empregadas em cada projeto, etapa 2.4. Empregou-se um terceiro roteiro previamente estabelecido, denominado instrumento C, voltado para os líderes e membros da equipe. Esse roteiro continha duas partes. A primeira solicitava que o respondente descrevesse de maneira livre como o projeto havia sido gerenciado. As perguntas eram abertas e do tipo: conte como o projeto foi iniciado, conte como os participantes foram identificados e assim por diante. Os pesquisadores utilizaram a técnica de modelagem de processo BPMN para descrever as ações, técnicas e ferramentas empregadas, documentando como o projeto aconteceu. Empregou-se também análise documental como assessório (Voss et al., 2002). Os entrevistados apresentaram modelos de documentos e formulários utilizados para ilustrar as ações tomadas.

Em um segundo momento, os mesmos entrevistados foram solicitados a classificar o projeto segundo as listas de ações, técnicas e ferramentas, em conjunto com os pesquisadores, identificando quais foram utilizadas. O foco da análise foi a comparação entre o que foi narrado espontaneamente, durante a primeira parte do levantamento, e a identificação realizada com auxílio da lista, modelo teórico.

Os estudos em cada empresa tiveram uma duração média de dois meses, entre entrevistas, análise documental e análise dos dados. Cada entrevista de projeto durou em média três horas. Para cada projeto foram entrevistados o gerente de projetos e membros que participaram da execução do projeto, conforme dados da Tabela 1.

Tabela 1
Quantidade de pessoas entrevistadas.

Projeto	Duração do projeto (meses)	Tamanho da equipe do projeto	Entrevistados		Total de entrevistados por projeto (grupo 1 + grupo 2)
			Grupo 1 (envolvidos na gestão)	Grupo 2 (participantes na execução)
A1	15 meses	12 pessoas	2	3	5
A2	24 meses	5 pessoas	2	3	5
B1	26 meses	11 pessoas	3	8	11
B2	10 meses	12 pessoas	3	9	12
	TOTAL GERAL		10	23	33

A etapa 2.5 foi realizada em duas fases. A primeira foi a transcrição das entrevistas e organização dos dados coletados. Em seguida foi realizada uma análise qualitativa (Silva & Menezes, 2005) individual de cada projeto e entre os projetos estudados, conforme sugerido por Eisenhardt (1989). Esses resultados foram apresentados em uma reunião com todos os membros das equipes de projeto que participaram do estudo bem como com os líderes das empresas. Houve consenso de que os resultados espelhavam a realidade da empresa.

4. Construção do modelo conceitual de práticas de gerenciamento de projetos

Conforme descrito no método, a primeira parte da pesquisa teve como objetivo construir um modelo conceitual que descrevesse as práticas de gerenciamento de projetos segundo as duas teorias, tradicional e ágil. Isso foi feito por meio de uma revisão bibliográfica sistemática (Conforto et al., 2011) e da definição de prática como o conjunto de: ação, técnicas e ferramentas; explicado na seção 2. O período considerado na revisão sistemática foi dezembro de 2010 até fevereiro de 2011.

A revisão iniciou com a identificação de fontes primárias da literatura de GP, considerando artigos e livros mais citados da gestão de projetos tradicional (Project Management Institute, 2008; Wysocki & McGary, 2007) e de gerenciamento ágil de projetos (Highsmith, 2004; Schwaber, 2004; Murch, 2001; Cohn, 2005; Smith, 2007). Essa análise de textos clássicos permitiu identificar um total de 86 ações, 128 técnicas e 98 ferramentas, consistindo na etapa 1.1.

Essa primeira etapa permitiu identificar também um conjunto de palavras-chave, autores e periódicos importantes. Eles foram utilizados na definição destrings e estratégias de busca que, uma vez aplicadas nas bases de dados, resultaram em 8.159 artigos identificados.

Esses artigos foram analisados segundo o passo denominado filtro preliminar, que compreende a leitura do título, resumo e palavras-chave, tendo como critério de aceitação: conter uma lista de uma ou mais ações, técnicas ou ferramentas para o gerenciamento de projetos. Essa análise resultou em um total de 141 artigos.

Esses artigos foram analisados sob o mesmo critério de aceitação, empregando, porém, uma leitura mais detalhada, envolvendo a introdução, conclusão e outras partes, quando necessário. Restaram 59 artigos. Isso foi chamado de filtro 2. Por fim, esses artigos foram lidos na íntegra e foram eliminados aqueles que apresentavam problemas que invalidavam os resultados. Esse foi chamado de filtro 3 e o resultado foram 12 artigos selecionados. Essa foi a etapa 1.2 e os artigos selecionados foram adicionados em um repositório utilizando uma ferramenta de gerenciamento de referências bibliográficas, Mendeley.

O estudo desses trabalhos permitiu a identificação de mais 11 trabalhos, por meio de referência cruzada (referências citadas nos artigos), que também foram lidos completamente, e que, após filtragem, resultaram em mais sete trabalhos adicionados ao repositório; totalizando 19 artigos.

A análise detalhada do conteúdo desses 19 artigos resultou em um total de 120 ações, 161 técnicas e 102 ferramentas (etapa 1.3). Essa lista consolida diversas fontes de práticas tradicionais (Project Management Institute, 2008; Murch, 2001; Wysocki & McGary, 2007; Besner & Hobbs, 2006, 2008; Chicarino, 2005;Turner & Ledwith, 2010; Thieme et al., 2003; Rigby, 2001; Hodgson, 2002; Blindenbach-Driessen & Van Den Ende, 2010; Blair, 1993; White & Fortune, 2002; Carden & Egan, 2008) e de práticas da literatura ágil (Highsmith, 2004; Schwaber, 2004; Cohn, 2005; Smith, 2007; Salomo et al., 2007; Berggren et al., 2008; Qumer & Henderson-Sellers, 2008; Fitsilis, 2008; Hass, 2009; Fernandez & Fernandez, 2009; Petersen & Wohlin, 2010).

Um dos desafios foi classificar as práticas segundo as duas abordagens: ágil e tradicional. Empregou-se o critério de menção da abordagem pelo autor. Isso é, os trabalhos que mencionaram explicitamente o uso da abordagem ágil foram assim considerados. As práticas identificadas nesses trabalhos recebiam, portanto, o rótulo de práticas ágeis. Foram agrupados sob esse rótulo todas as variações do nome ágil encontradas na literatura: Lean Product Development, Scrum, Flexible, XP eiterative planning, ligados aos teóricos do GAP.

Os trabalhos que mencionavam seguir padrões estabelecidos na teoria, como PMBoK, ISO, IPMA e outros ligados aos livros textos consagrados, como Kerzner (2006), tiveram suas práticas classificadas como tradicionais. Os trabalhos que não mencionaram a abordagem foram identificados pelas referências chave, isso é, aqueles cujas referências principais eram de teóricos ligados a uma das correntes do GAP, por exemplo, Scrum e XP, foram classificados como abordagem ágil. Os trabalhos cuja referência principal eram autores clássicos ou de associações mencionadas foram classificados como tradicionais.

Poucos trabalhos não apresentavam classificação segundo o autor e pela utilização de alguma referência da abordagem ágil ou tradicional. Foram eles: Sibbet (2010), Evans & Jukes (2000) e Carden & Egan (2008). Esses apresentavam principalmente técnicas que já haviam sido citadas segundo as duas abordagens e foram inicialmente classificadas como "ambas".

O resultado foi uma lista inicial de elementos, ações, técnicas e ferramentas armazenada em um banco de dados, conforme o exemplo da Tabela 2. O primeiro número do código (antes do ponto) indica o elemento: ação (1), técnica (2) ou ferramenta (3), seguido de um ponto, indicando o número de identificação do elemento. As tabelas contêm seis colunas, com descritores. Essa tabela contém um total de 88 ações, 126 técnicas e 93 ferramentas. (critério 1).

Tabela 2
Exemplo da lista de ações.

Código	Ação	Definição	Similaridade	Alterações	Referência
1.1	Adding Detail to User Stories Sooner.	Adicionar mais detalhes às histórias antes de iniciar a iteração.	1.69		Cohn, M. (2005).Agile Estimating and Planning. New York: Prentice hall PTR. (1.69) Smith, P. G. (2007). Flexible Product Development - building agility for changing markets. San Francisco: Jossey-Bass.

Essa tabela inicial continha informações extraídas de cada trabalho, indicando conflitos, redundância e termos com descrições inadequadas ou ausentes. Precisava, portanto, ser refinada. O primeiro passo, chamado de critério 1, foi excluir termos empregados pelos autores e cuja definição não se encontrava no texto, impedindo o reconhecimento do elemento. Nessa mesma etapa realizou-se um agrupamento de termos semelhantes ou redundantes. Procurou-se por elementos (ações, técnicas e ferramentas) com mesmo significado e nomes distintos. O resultado foi uma nova versão com 72 ações, 93 técnicas e 93 ferramentas, facilitando o emprego dos outros critérios.

O passo seguinte, chamado de critério 2, foi a eliminação da distorção da classificação. Notou-se que havia divergência quanto à citação de ações, técnicas e ferramentas, pois na construção da tabela inicial os elementos foram classificados conforme a citação do trabalho. Isso é, se o trabalho citou como técnica, era classificado como tal, mesmo se tal definição fosse diferente da empregada na pesquisa. O mesmo para ferramentas e ações. Tais classificações por vezes não foram compatíveis com as definições adotadas na pesquisa, seção 2. Para garantir coerência, os termos foram realocados de forma a se ajustarem ao significado específico descrito neste trabalho. Cada um dos itens da tabela foi avaliado e, quando necessário, reclassificado. O resultado final foram 64 ações, 86 técnicas e 87 ferramentas, agora coerentes com a definição de prática adotada, conforme o exemplo na Tabela 3.

Tabela 3
Exemplo de sistemática utilizada para classificar os termos.

Classificação	Ação	Técnica	Ferramenta
Definição	Que gera resultado	Procedimento sistemático	Algo tangível
Exemplo	- Definir atividades	- WBS - Sprint Backlog	- Quadro - Folha A4

O critério 3, próximo passo, teve como objetivo analisar o conteúdo das definições e descrições das práticas. Por exemplo, adjust priorities e priorizar o trabalho necessário foram somadas por apresentarem o mesmo objetivo e sentido: priorizar os requisitos do Product Backlog. A sua aplicação resultou em uma lista com 37 ações, 56 técnicas e 73 ferramentas. A Tabela 4 resume a evolução das práticas segundo os passos realizados.

Tabela 4
Evolução da quantidade de elementos nas listas sobre práticas.

Passos da pesquisa	Número total de elementos na lista
	Ações	Técnicas	Ferramentas
Análise dos textos clássicos sobre práticas	86	128	98
Primeiro levantamento em bases de dados (19 artigos)	120	161	102
Critério 1 – agrupamento de elementos idênticos, isso é, mesma definição idêntica	88	126	93
Organização da lista: eliminação de redundantes	72	93	93
Critério 2 – divergência quanto à citação de ações, técnicas e ferramentas usadas para outros contextos que não o GP	64	86	87
Critério 3 – síntese de elementos com definições similares, a partir de análise de conteúdo	37	56	73

Cada uma das listas foi denominada de lista simplificada de prática, seguida do nome do elemento: elemento ação, elemento técnica e elemento ferramenta. Novos agrupamentos por similaridade de conteúdo foram realizados e o resultado final foram três listas, de 23 ações, 54 técnicas e 21 ferramentas, classificadas conforme aTabela 5.

Tabela 5
Quantidade de elementos por teoria.

	Ações	Técnicas	Ferramentas
Fontes de gerenciamento tradicional de projetos	9	31	4
Fontes de gerenciamento ágil de projetos	8	17	1
Citadas em ambas as fontes	6	6	16
Total	23	54	21

Para que o leitor tenha uma visão sintética, a Tabela 6 apresenta um resumo dos títulos dos elementos contidos em cada lista.

Tabela 6
Elementos das listas simplificadas de práticas.

Ação	Fonte
Adding detail to user stories sooner	Ágil
Ask for a time commitment	Ágil
Coletar requisitos	Tradicional
Controlar escopo	Tradicional
Controlar o plano do projeto	Ambas
Controlar mudanças de escopo	Ágil
Termo de abertura do projeto	Ágil
Identificar o trabalho necessário para o projeto (produto, entregas etc.)	Ambas
Declarar o problema/Oportunidade	Ambas
Definir as atividades	Tradicional
Definir escopo do projeto	Ambas
Desenvolver o cronograma	Tradicional
Determine target velocity/Estimating velocity/Velocity	Ágil
Estimar a duração das atividades	Ambas
Estimar os recursos das atividades	Ambas
Identificar e dimensionar folgas	Ágil
Finalizar o plano do projeto	Tradicional
Priorizar requisitos	Ágil
Priorizar o trabalho necessário	Ágil
Sequenciar as atividades	Tradicional
Medir a complexidade	Ágil
Verificar escopo	Tradicional
Definir escopo do produto	Tradicional
Ferramenta	Fonte
Apresentação de slides	Ambas
Ata de reunião	Ambas
Banco de dados	Tradicional
Cartão/Recados autoadesivos (sticky notes)	Ambas
Cartaz	Ambas
Checklist	Ambas
Contrato	Tradicional
Desenho/Esboço	Ambas
Diagrama/Apresentação gráfica/Gráfico	Ambas
Roteiros	Ambas
E-mail	Ambas
Lista	Ambas
Manual de qualidade	Tradicional
Maquetes	Ágil
Mental models/Mandala/Process maps	Ambas
Modelos/Protótipos/Templates	Ambas
Planilha/Tabela	Ambas
Quadro/Mural	Ambas
Relatório	Tradicional
Questionário	Ambas
Software de gerenciamento de projetos	Ambas
Técnicas	Fonte
Planning poker	Ágil
Ajuste de antecipações e esperas	Tradicional
Análise de alternativas	Tradicional
Análise de produto	Tradicional
Análise de reservas	Tradicional
Análise do desempenho	Tradicional
Árvore de decisão	Tradicional
Balanced scorecard	Ambas
Business problem definition	Tradicional
Case point estimates	Ágil
Chartering	Tradicional
Compressão de cronograma	Tradicional
Critical Path Method	Tradicional
Delphi Technique	Tradicional
Dinâmica de grupo	Tradicional
Duration and total work effort	Tradicional
Earned Value Analysis	Tradicional
Entrevista	Tradicional
Estimar por analogia	Tradicional
Estimar por comparação	Ágil
Estimativa paramétrica	Tradicional
Bill of Material	Ágil
Experimento	Ágil
Feature cards	Ágil
Estimativa análoga	Tradicional
Inspeção/Observação	Tradicional
Método da corrente crítica	Tradicional
Event on node diagram	Tradicional
Modelo/Template	Tradicional
Nivelamento de recursos	Tradicional
Opinião especializada/Oficina	Tradicional
Planejamento em ondas sucessivas	Ambas
Product Backlog	Ágil
Program Evaluation and Review Technique	Tradicional
Reunião	Ambas
Simulação	Tradicional
Stoplight reports	Tradicional
Técnica de estimativa dos três pontos	Tradicional
Técnicas de criatividade em grupo	Tradicional
Customer Focus Groups	Ágil
Daily Scrum Meeting	Ágil
Product architecture	Ágil
Product feature list	Ágil
Product Vision Box	Ágil
Project Data Sheet	Ágil

Essas listas formam um modelo conceitual de práticas. A hipótese é que em conjunto seriam um instrumento de pesquisa capaz de descrever uma prática utilizada por uma empresa e, a partir dessa descrição, capaz de identificar de maneira objetiva se a empresa poderia ser classificada como usuária da teoria do gerenciamento ágil ou do gerenciamento tradicional.

Por exemplo, dada uma empresa cuja prática observada seja "coletar requisitos" por meio da técnica de "entrevista" e utilizando uma ferramenta do tipo "planilha". Todas são identificadas na tabela como literatura tradicional. Conclui-se, portanto, que há indício de uso da abordagem tradicional.

Um destaque é para a lista de ações. Há seis ações que são apresentadas como ambas. Uma análise pormenorizada delas, resumida na Tabela 7 indicou que embora apresentem o mesmo objetivo nas duas abordagens, pode haver diferenças em etapas e abrangência de detalhe das atividades; conforme são descritas pelos diferentes teóricos.

Tabela 7
Lista de ações classificadas segundo diferença fundamental.

Cód.	Ação	Definição	Diferença fundamental	Referência	Fonte
1.6	Controlar o plano do projeto	Processo de monitoramento do andamento do projeto para atualização do seu progresso e gerenciamento das mudanças feitas na linha base do cronograma.	Baseadas em custo, tempo e % de progresso. Identifica desvios e corrige para seguir o plano. Atualizações informadas formalmente (reuniões, gates etc.).	PMBoK (Project Management Institute, 2008)	Trad.
			Baseada em protótipos, demonstrações, desenhos e artefatos visuais. Mudanças constantemente absorvidas. Atualizações informadas informalmente (face a face).	Cohn (2005)	Ágil
1.10	Identificar o trabalho necessário para o projeto (produto, entregas etc.)	Processo de identificação do trabalho total necessário para o projeto por meio da identificação de elementos como o produto do projeto, componentes, módulos, entregas atividades etc.	O trabalho é orientado para as atividades, marcos e entregas documentais.	PMBoK (Project Management Institute, 2008), Wysocki & McGary (2007)	Trad.
			O trabalho é orientado para resultados como protótipos em funcionamento ou o produto final.	Schwaber (2004)	Ágil
1.14	Declarar o problema/Oportunidade	Descrição dos problemas e das oportunidades do projeto.	O conteúdo do projeto é detalhado ao máximo na declaração de escopo, "ditando as regras do jogo".	Wysocki & McGary (2007),Berggren et al. (2008)	Trad.
			O projeto é descrito pela visão, de forma ampla e genérica, abrindo possibilidades de interpretação.	Schwaber (2004), Murch (2001)	Ágil
1.17	Definir escopo do projeto	Processo de desenvolvimento da descrição do conteúdo do projeto, resultado final esperado.	O projeto é descrito formalmente. O produto é descrito de forma clara e a mais detalhada possível e sem ambiguidade. São utilizadas listas de materiais e descrições de funcionalidades do produto para indicar como é o produto do projeto.	PMBoK (Project Management Institute, 2008)	Trad.
			O projeto é descrito de forma desafiadora, procurando motivar a equipe. O produto é descrito de forma metafórica, ambígua e com artefatos visuais. O objetivo não é mostrar o resultado final do projeto mas direcionar a equipe para um conjunto possível de soluções.	Cohn (2005)	Ágil
1.24	Estimar a duração das atividades	Processo de estimar, o mais próximo possível, o número de períodos de trabalho que serão necessários para terminar atividades específicas com os recursos estimados.	É de mais longo prazo, com um planejamento macro mais detalhado e geralmente observando todo o período que o projeto compreende.	PMBoK (Project Management Institute, 2008)	Trad.
			É de mais curto prazo (poucos dias ou semanas), com foco em entregas e resultados rápidos.	Hass (2009)	Ágil
1.26	Estimar os recursos das atividades	Processo de estimativa dos tipos e quantidades de materiais, pessoas, equipamentos ou suprimentos que serão necessários para realizar cada atividade.	Estima-se baseado em quantidade de atividades e horas/homem.	PMBoK (Project Management Institute, 2008)	Trad.
			Estima-se baseado em pessoas que serão necessárias para se alcançar determinada velocidade para cumprir as story points.	Hass (2009)	Ágil

Assim, apesar de possuírem um mesmo nome, a hipótese é que seria possível classificá-las segundo cada uma das teorias, de acordo com os detalhes de implementação. Essa construção teórica, o modelo conceitual de listas de práticas apresentado, precisaria ser investigada. Optou-se por estudos de casos em profundidade, em empresas usuárias de cada uma das abordagens.

5. Estudo de caso na empresa A – abordagem tradicional

A lista de práticas foi primeiramente avaliada em uma empresa de grande porte da área de bens de capital do estado de São Paulo que conta com mais de 500 funcionários. Atua há mais de 80 anos e adota práticas da abordagem tradicional de gerenciamento de projetos há mais de cinco anos. A empresa possui um escritório de projetos,softwares de gerenciamento de projetos integrados e acompanha os projetos por indicadores de desempenho. Preenche, portanto, os critérios apresentados na seção 3: adota assumidamente a abordagem tradicional, é de grande porte, desenvolve projetos que envolvem hardware esoftware e possui projetos inovadores.

A seleção dos projetos seguiu os critérios: (1) ter sido concluído recentemente ou estar em fase de conclusão; e (2) resultar em processo, componente, subsistema ou sistema inovador do ponto de vista da empresa. Foram considerados dois projetos: A1 e A2.

A descrição das práticas em cada projeto foi realizada em dois momentos, conforme explicado na seção 3: primeiro de forma espontânea, isso é, com os respondentes discorrendo livremente sobre o que foi realizado em cada projeto; segundo, de maneira específica, com os respondentes identificando as práticas segundo a lista de práticas.

A Tabela 8 resume as práticas citadas de maneira espontânea, de acordo com os dados coletados com os entrevistados (cinco entrevistados por projeto). As práticas não sofreram alteração em seu nome de origem e objetivos, relatados pelos próprios entrevistados.

Tabela 8
Análise das práticas de planejamento da empresa A.

Prática segundo a lista	Atividade de planejamento segundo a empresa	Projeto A1	Projeto A2	Gestão adotada
Ações		5	5
Desenvolver o cronograma	Elaborar plano diretor	X	X	Tradicional
Definir escopo do produto	Definir escopo do produto (macro)	X	X	Tradicional
Finalizar o plano do projeto	Estimar custos do produto (macro)	X	X	Tradicional
Estimar os recursos das atividades	Estimar tempo do projeto (macro)	X	X	Tradicional
Declarar o problema/Oportunidade	Detalhar escopo do produto	X	X	Trad./Ágil
Técnicas		5	3
Reunião	Reunião com equipe	X		Trad./Ágil
Não mensurável (intangível)	Conversas informais com cada membro da equipe	X	X	-
Estimar por comparação	Estimativa por comparação	X	X	Ágil
Delphi Technique	Estimativa independente	X	X	Tradicional
WBS/Decomposição	Decomposição	X		Trad./Ágil
Ferramentas		4	4
Software de gerenciamento de projetos	Microsoft Project (gráfico de Gantt)	X	X	Trad./Ágil
Modelos/Protótipo/Template	Template (Excel)	X	X	Trad./Ágil
Planilha/Tabela	Planilha eletrônica (Excel)	X	X	Trad./Ágil
Checklist	Folha de papel tamanho A2	X		Trad./Ágil
Modelos/Protótipo/Template	Template (Word)			Trad./Ágil
Ata de reunião	Documento texto (Word)		X	Trad./Ágil

Por exemplo, nota-se que a ação citada pela empresa (Elaborar plano diretor) é diferente do nome da ação segundo a lista de práticas (Desenvolver o cronograma). Segundo relato dos entrevistados e análise documental, o plano diretor é desenvolvido pela alta gerência e pelo departamento de inteligência de mercado, com revisões trimestrais. O documento é registrado na forma de cronograma (gráfico de Gantt) e indica o plano para desenvolvimento de produtos.

Com relação às técnicas, observa-se uma diferença entre a técnica Estimativa independente e o termo contido na lista Delphi Technique. São, portanto, idênticas. Sobre as ferramentas, nota-se o uso de uma folha de papel tamanho A2, conforme citado pelos entrevistados, e foi identificado pelos pesquisadores comochecklist, conforme descrito na lista de práticas. A ferramenta era utilizada pelo líder do projeto para registrar as atividades da equipe, o que corrobora a definição de checklist: "lista de coisas em que você deve pensar, ou que você deve se lembrar de fazer". Outra observação é quanto à ferramenta documento texto (Word), que segundo relatos dos entrevistados era gerada na forma de uma ata de reunião.

A análise da lista indicou cinco ações, conforme a Tabela 8. Três delas já identificadas na teoria como tradicionais. A empresa pode ser identificada como usuária da abordagem tradicional, confirmando a escolha intencional. Outras duas, Estimar os recursos das atividades e Declarar o problema, constam da Tabela 5 e precisaram ser classificadas segundo o conteúdo.

Em relação a Estimar os recursos das atividades ficou evidente que a empresa se baseia em número de atividades por horas-homem, caracterizando a abordagem tradicional de estimativas. Para Declarar o problema/Oportunidade era descrito o conteúdo do projeto em um nível alto de detalhes, descrevendo-se, inclusive, características de desempenho que as maquinas deveriam possuir, o que também caracteriza o uso de uma abordagem tradicional, preditiva e baseada na antecipação da solução de projeto.

Em relação às técnicas, apenas uma é exclusiva da teoria tradicional, outras duas podem ser enquadradas em ambas as teorias e apenas uma foi considerada exclusiva da abordagem ágil: estimar por comparação. As ferramentas utilizadas podem ser todas consideradas de ambas as teorias. Predominância, portanto, da abordagem tradicional.

O processo de gerenciamento de projetos pode ser caracterizado, portanto, como aderente à teoria tradicional, devido ao fato de utilizar essa mesma abordagem na maioria dos seus projetos de desenvolvimento de produtos.

A análise das práticas de controle está na Tabela 9 e seguiu o mesmo procedimento, mas nesse caso não foi necessário um estudo mais aprofundado, pois todas as práticas eram claramente pertencentes à abordagem tradicional e foram identificadas como tal segundo a lista de práticas.

Tabela 9
Análise das práticas de controle da empresa A.

Prática segundo a lista	Atividades de controle observadas na empresa	Projeto A1	Projeto A2	Gestão adotada
Ações		5	3
Controlar escopo	Monitorar e controlar escopo (nível macro) – RANP	X	X	Tradicional
Controlar escopo	Monitorar e controlar escopo (nível detalhado) – equipe	X		Tradicional
Controlar o plano do projeto	Monitorar e controlar tempo (nível macro) – RANP	X	X	Tradicional
Controlar o plano do projeto	Monitorar e controlar tempo (nível detalhado) – equipe	X		Tradicional
Controlar mudanças de escopo	Controlar mudanças – análise crítica	X	X	Tradicional
Técnicas		5	4
Reunião	Reunião com alta gerência (RANP)	X	X	Trad./Ágil
Reunião	Reunião com a equipe de projeto	X		Trad./Ágil
Não mensurável (intangível)	Conversas informais com cada membro da equipe	X	X	-
Reunião	Reunião de análise crítica – com membros de outras áreas	X	X	Trad./Ágil
Não mensurável (intangível)	Apresentação/Discussão	X	X	-
Ferramentas		5	5
Software de gerenciamento de projetos	Microsoft Project (gráfico de Gantt)	X	X	Trad./Ágil
Modelos/Protótipo/Template	Template (Excel)	X	X	Trad./Ágil
Planilha/Tabela	Planilha eletrônica (Excel)			Trad./Ágil
Checklist	Folha de papel tamanho A2	X		Trad./Ágil
Modelos/Protótipo/Template	Template (Word)	X	X	Trad./Ágil
Ata de reunião	Documento texto (Word)		X	Trad./Ágil
Apresentação de slides	Apresentação (PowerPoint)	X	X	Trad./Ágil

6. Estudo de caso na empresa B – abordagem ágil

O segundo caso de aplicação da lista de práticas é uma empresa de grande porte da área de desenvolvimento de software do estado de São Paulo com mais de 500 funcionários e que atua no mercado há quase 20 anos. Trata-se de uma empresa que adotou a abordagem do gerenciamento ágil a partir de 2006 e a utiliza como uma estratégia de vendas, declarando aos clientes abertamente o uso desse conceito. Dois projetos foram considerados, chamados B1 e B2. Foram entrevistadas 11 pessoas para o projeto B1 e 12 pessoas para o projeto B2. Para aplicação do estudo, foram adotados os mesmos critérios para seleção dos projetos e a mesma sistemática para análise do caso anterior. O resultado está na Tabela 10.

Tabela 10
Análise das práticas de planejamento e controle da empresa.

Prática segundo a lista	Atividades de planejamento e controle observadas na empresa estudada	Projeto B1	Projeto B2	Gestão adotada
Ações		9	6
Coletar requisitos	Levantamento da curva de valor	X		Tradicional
Priorizar requisitos	Sprint N	X	X	Ágil
Priorizar o trabalho necessário	Backlog	X		Ágil
Estimar os recursos das atividades	Definir equipe	X		Ágil
Definir as atividades	Inception	X	X	Ágil
Velocity	Sprint 0	X	X	Ágil
Declarar o problema/Oportunidade	Detalhar visão	X		Ágil
Identificar o trabalho necessário	Kick-off do projeto		X	Ágil
Controlar o plano do projeto	Execução		X	Ágil
Detalhando users stories	Sprint Ready	X		Ágil
Medir a complexidade	Homologação	X	X	Ágil
Técnicas		8	7
Reunião	Reunião com time	X	X	Tradicional
Product Backlog	Criar curva de valor	X	X	Ágil
Sprint Backlog	Planning	X	X	Ágil
Gráfico de Gantt	Burndown	X		Tradicional
Planning Poker	Planning Poker	X	X	Ágil
Daily Scrum Meeting	Daily	X	X	Ágil
Reunião de retrospectiva do Sprint	Retrospectiva	X	X	Ágil
Revisão do Sprint	Review	X	X	Ágil
Ferramentas		6	4
Lista	Template (Excel)	X		Trad./Ágil
Planilha	Planilha Excel	X	X	Trad./Ágil
Diagramas/Gráficos	Gráfico	X	X	Trad./Ágil
Software de GP	J1RA	X	X	Trad./Ágil
Banco de dados	Banco de dados	X		Tradicional
Quadro	Situation Wall	X	X	Trad./Ágil

Nota-se que a ação citada pela empresa (Levantamento da curva de valor) é diferente do nome da ação segundo a lista de práticas (Coletar requisitos). Segundo os entrevistados e dados da análise documental, tal curva de valor representa os requisitos que são de maior importância para o cliente e que foram priorizados pelo cliente segundo critérios específicos do negócio. Outra observação relevante é com relação à ação Sprint ready. De acordo com os entrevistados essa ação é o acréscimo de mais informações (detalhes) às estórias antes do início cada iteração (Detalhando users stories).

Outra adaptação realizada pela empresa ocorre com a técnica Criar curva de valor, que difere do termo descrito na lista (Product Backlog). Entretanto, os relatos dos entrevistados indicaram que essa técnica é adotada para criar uma lista de requisitos funcionais do projeto priorizados, semelhante, portanto, ao Product Backlog.

A análise indicou seis ações puramente ágeis e uma ação claramente tradicional. Quatro ações faziam parte da Tabela 5 e tiveram que ser avaliadas segundo o contexto de aplicação. Em relação a Estimar os recursos das atividades, a empresa se baseava no número de pessoas necessário para alcançar determinada velocidade no desenvolvimento, logo caracterizamos essa ação como gestão ágil segundo o modelo de lista de práticas. Para Declarar o problema/Oportunidade, a empresa deixava em aberto algumas possibilidades de interpretação, caracterizando assim a gestão ágil. Na ação Identificar o trabalho necessário, a empresa assumia orientar-se por entregas, conforme preconizado na abordagem ágil. Por último, em Controlar o plano do projeto, as atualizações eram absorvidas constantemente segundo as necessidades do cliente e tais mudanças eram comunicadas de maneira informal, novamente classificando-se como gestão ágil.

Em termos de técnicas, apenas duas são exclusivas da teoria tradicional, outras seis foram consideradas pertencentes à teoria ágil, segundo o levantamento. Apenas uma ferramenta foi considerada tradicional, sendo as demais consideradas de ambas as teorias. Ao analisarem-se as ações, percebe-se que o monitoramento é realizado de maneira mais informal e com poucos registros, o que está em consonância com a abordagem ágil.

Ao considerar-se a avaliação segundo a lista de práticas, a empresa se enquadraria no gerenciamento ágil e o mesmo resultado foi verificado na análise detalhada das práticas. A lista funcionou e confirma a escolha intencional. Em suma, a empresa adota gerenciamento ágil de projetos, tanto para o planejamento quanto para o controle dos projetos estudados, e a lista apresentou resultado compatível com as observações in loco.

7. Análise dos resultados

Os resultados demonstraram que a avaliação realizada por meio da lista foi similar ao resultado encontrado a partir dos relatos da descrição dos projetos e à autoidentificação da empresa. Assim, a lista tem coerência, considerando-se os casos apresentados.

Trata-se de uma hipótese interessante que, se comprovada em um maior número de casos ou surveys, traz implicações para a teoria. A primeira constatação é sobre as principais diferenças entre as abordagens ágil e tradicional. O modelo conceitual que resultou da pesquisa indica que a diferença principal está nas técnicas empregadas. Isso é, as ações de planejamento e controle são semelhantes, mas a forma como são feitas (técnicas e ferramentas) é que distingue as duas abordagens. Portanto, é na forma de execução, caracterizada pelas técnicas, que concentram-se as diferenças fundamentais entre as abordagens e não sobre o que é feito.

A segunda constatação importante foi a identificação de diferenças em seis ações específicas que distinguem as abordagens, apresentadas na Tabela 5. É possível observar nos casos que as seis diferenças nas técnicas foram mais facilmente observáveis e classificáveis entre os polos ágil e tradicional. As demais práticas da lista podiam não ocorrer em todos os projetos. A hipótese, portanto, é que essas seis ações específicas permitem diferenciar uma prática da outra.

A primeira distinção está na forma de elaboração do plano do projeto. As características no plano do GAP são: é realizado sucessivas vezes e com um grau menor de detalhe por vez, buscando sempre as entregas mais importantes segundo o cliente/mercado por meio de iteração. Seguindo a abordagem tradicional, o plano é realizado de uma só vez e com grande nível de detalhe no início do projeto ou em ondas sucessivas (fases), sendo refeito completamente quando é necessário. Tal evidência é comprovada pela ação Declarar problema/Oportunidade (Tabela 5) e pelas técnicas Product Backlog, Análise de alternativas e Modelo/template (Tabela 6).

A segunda diferença consiste na ação de definição do escopo do projeto. Segundo a análise das práticas encontradas na teoria, no GAP busca-se elaborar a visão do produto contendo uma descrição abrangente do projeto de forma macro e desafiadora, ambígua e metafórica (Benassi et al., 2011). A descrição do produto nesse caso é orientada para a resolução de problemas e geralmente contém artefatos visuais. Na abordagem tradicional, o escopo demonstra a solução a que se quer chegar, ditando regras, orientando para as atividades de execução do projeto (voltada para solução). Pode-se visualizar tal diferença na ação Definir escopo do projeto (Tabela 5) e pelas técnicas Opinião especializada/Oficina", Bill of Material e Product Vision Box. No caso da empresa que utiliza GAP isso era feito por meio da descrição do que eles denominavam análise do valor para o cliente. Uma lista geral dos produtos do cliente. Na empresa que adotava o tradicional, o escopo era descrito da maneira mais precisa possível, com números e dimensões que procuravam descrever de maneira inequívoca o produto final.

A terceira diferença está na forma como se definem as atividades. No gerenciamento ágil é realizada uma lista de atividades, inicialmente sem definição de datas e sequenciamento. Mais, não há rigor no formato. No tradicional, as atividades precisam ser organizadas em forma hierárquica (WBS) e são sequenciadas no projeto como um todo (organizado na forma hierárquica – produto, entrega e atividade). Evidência comprovada pela ação Identificar o trabalho necessário para o projeto e Estimar recursos das atividades (Tabela 5) e nas técnicas WBS, Product Backlog e Sprint Backlog.

A quarta diferença significativa consiste no horizonte de tempo empregado no cronograma do projeto. No GAP, o plano é detalhado em horizonte curto de tempo, denominado iteração (semanal, quinzenal ou mensal), que é necessariamente criado conjuntamente com os membros da equipe de projeto, incluindo-se nela os clientes. Para a abordagem tradicional, o plano aborda o projeto como um todo e não precisa ser necessariamente elaborado pela equipe. Pode ser criado pelo gerente de projeto. E não inclui o cliente, que valida resultados nas reuniões de transição de fases(gates), realizadas durante a execução do projeto. Tal evidência pode ser visualizada nas ações: Desenvolver o cronograma, Priorizar o trabalho necessário e Estimar a duração das atividades. E também nas técnicas: Program Evaluation and Review Technique, Técnica de estimativa dos três pontos, Gantt; Comparing Pairs e Estimar por comparação.

A quinta diferença está na estratégia utilizada para o controle do tempo do projeto. No GAP, as mudanças devem ser identificadas por meio do ambiente físico, empregando-se a troca de informações por meio de controles visuais e reuniões diárias, face a face, entre os profissionais envolvidos no projeto, conforme observado na empresa B. A medição de progresso é orientada para resultados tangíveis (protótipos, demonstrações, desenhos ou artefatos visuais) e orientada pela frequência de feedback da equipe para com o gerente de projeto. Na abordagem tradicional, o foco são o plano do projeto e os relatórios de acompanhamento. O progresso é avaliado por indicadores de tempo, custo e porcentagem do escopo realizado, ou atividades concluídas. Evidência comprovada pelas ações Controlar o plano do projeto, Controlar mudanças de escopo, Identificar e dimensionar folgas. Nas técnicas Stoplight Reports, Daily Scrum Meeting, Sprint Review Meeting, Reunião, Ajuste de antecipações e esperas e Customer Focus Groups.

Por fim, a sexta diferença está na estratégia utilizada para a verificação e controle do escopo do projeto. No GAP, isso acontece por meio de priorizações determinadas pelo cliente. O nível de formalidade é baixo (reuniões diárias com menor tempo de duração, participação do cliente nas discussões dos resultados bem como no desenvolvimento do projeto). No tradicional, o cliente não participa ativamente. Ele assume um papel passivo, sendo comunicado do andamento pelo escritório ou gerente de projetos. Evidência dessas diferenças estão na ação Controlar o plano do projeto e nas técnicas Business Case e Sprint Backlog.

Essas diferenças são as mais significativas. Para facilitar para o leitor, elas podem ser resumidas na Tabela 11, que indica o valor que cada característica assume conforme a abordagem utilizada pela organização.

Tabela 11
Características para identificação da abordagem de gerenciamento de projeto utilizada por uma organização.

Característica	Abordagem de gerenciamento de projetos tradicional	Abordagem de gerenciamento ágil de projetos
1) A forma de elaboração do plano do projeto	Há um único plano de projeto, que abrange o tempo total do projeto e contém os produtos, entregas, pacotes de trabalho e atividades.	Há dois planos de projeto: a) um plano geral que considera o tempo total de duração do projeto, mas que contém apenas os produtos principais do projeto; b) um plano de curto prazo (iteração) que contém apenas as entregas e atividades referentes a uma fração de tempo do projeto.
2) A forma como se descreve o escopo do projeto	Descrição exata do resultado final por meio de texto, com normas do tipo contratuais, números objetivos e indicadores de desempenho.	Descrição do resultado final de maneira abrangente, desafiadora, ambígua e metafórica.
3) O nível de detalhe e padronização com que cada atividade do projeto é definida	As atividades são descritas de maneira padronizada e organizadas em listas do tipo WBS. Contêm códigos e são classificadas em conjuntos de pacotes de trabalho, entregas e produtos do projeto.	Não há um padrão para a descrição das atividades, que podem ser escritas na forma de estórias, problemas, ações ou entregas. E não há uma tentativa de organização, apenas a priorização do que deve ser executado no momento.
4) O horizonte de planejamento das atividades da equipe de projeto	As listas de atividades são válidas para o horizonte total do projeto.	As listas de atividades são válidas para uma iteração, que é definida como uma fração do tempo total do projeto.
5) A estratégia utilizada para o controle do tempo do projeto	Empregam-se relatórios com indicadores de desempenho, documentos escritos, auditorias e análises de transições de fase. As reuniões da equipe não são frequentes.	Empregam-se dispositivos visuais que indicam entregas físicas do resultado final (cartazes, autoadesivos etc.). As reuniões são curtas e frequentes.
6) A estratégia utilizada para a garantia do atingimento do escopo do projeto	O gerente de projeto avalia, prioriza, adiciona ou altera as atividades do projeto para que os resultados estejam em conformidade com o escopo do projeto assinado com o cliente.	O cliente avalia, prioriza, adiciona ou altera o produto final do projeto, conforme a experiência com os resultados alcançados. A equipe altera as atividades para obter os resultados propostos pelo cliente.

8. Conclusões

A pesquisa contribui para a solução de um problema teórico na área de gerenciamento de projetos: como identificar o uso ou não da abordagem de gerenciamento ágil por uma organização? A comparação das práticas descritas na teoria, por meio de uma revisão sistemática, permitiu identificar seis ações com diferenças significativas entre as duas abordagens. Investigando-as em projetos reais de duas empresas, essas diferenças foram confirmadas. As empresas com abordagens de gestão distintas apresentaram formas de proceder também significativamente distintas quanto a cada uma das seis ações. A análise dos casos permitiu compreender detalhes dessas diferenças.

A conclusão do estudo, portanto, é que é possível identificar o uso, ou não uso, da abordagem do gerenciamento ágil de projetos por meio da observação de seis características específicas, dentre as práticas adotadas pela organização: 1) A forma de elaboração do plano do projeto; 2) A forma como se descreve o escopo do projeto; 3) O nível de detalhe e padronização com que cada atividade do projeto é definida; 4) O horizonte de planejamento das atividades da equipe de projeto; 5) A estratégia utilizada para o controle do tempo do projeto; e 6) A estratégia utilizada para a garantia do atingimento do escopo do projeto. Os valores que cada uma assume, conforme a abordagem, estão na Tabela 11.

As características apontadas podem ser úteis na construção de instrumentos para pesquisas do tipo survey, em que um reduzido número de dimensões é importante. A implicação mais importante desses resultados é a hipótese de que investigando esses seis aspectos apenas é possível caracterizar a adoção ou não da abordagem do gerenciamento ágil de projetos. Ela significa que outros pesquisadores não precisariam mais recorrer aos procedimentos dos estudos atuais, como descrever totalmente as práticas realizadas por uma empresa ou confiar nos rótulos adotados em cada organização, autodeclaração dos profissionais. O primeiro é trabalhoso e não pode ser utilizado em pesquisas tipo survey. O segundo é impreciso, pois a autodeclaração é enviesada.

É natural e evidente que a eficácia e eficiência no uso dessas características como instrumentos de pesquisa precisa ainda ser verificada e testada em um número maior de condições (outros tipos de organização, populações maiores e outros métodos de pesquisa que possam verificar a validade externa com surveys com variáveis mais controladas). Como trabalho futuro, sugere-se o desenvolvimento de instrumentos de coleta de dados a partir dessas características e a sua aplicação e validação.

Apesar das limitações, este estudo traz uma importante contribuição, pois a identificação das diferenças principais é o primeiro passo para o desenvolvimento de instrumentos. E as características identificadas podem e devem ser utilizadas em estudos da área, dada a inexistência de estudo similar. O alerta é que, devido ao número restrito de projetos investigados, tais diferenças devam ser tratadas ainda como uma hipótese a ser testada.

Agradecimentos

Os autores agradecem o apoio recebido da FAPESP (2009/18267-8) e da CAPES-CNPq e o apoio da pesquisadora Juliana Schnetzler. Agradecemos também aos editores ereferees da Revista Production, que ofereceram críticas e sugestões decisivas para o aperfeiçoamento do trabalho.

Referências

• Amaral, D. C., Conforto, E. C., Benassi, J. L. G., & Araujo, C. (2011). Gerenciamento ágil de projetos: aplicação em produtos inovadores São Paulo: Saraiva.
• Beck, K., Beedle, M., Bennekum, A. V., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Mellor, S., Schwaber, K., Sutherland, J., & Thomas, D. (2001). Manifesto for agile software development Retrieved from http://www.agilemanifesto.org.
  » http://www.agilemanifesto.org
• Benassi, J. L. G., Ferreira Junior, L. D., & Amaral, D. C. (2011). Identificação das propriedades da visão do produto no gerenciamento ágil de projetos de produtos manufaturados. Produto & Produção, 13(1), 59-74.
• Berggren, C., Järkvik, J., & Söderlund, J. (2008). Lagomizing, organic integration, and systems emergency wards: innovative practices in managing complex systems development projects. Project Management Journal, 39(1), 111-122. http://dx.doi.org/10.1002/pmj.20065
  » http://dx.doi.org/10.1002/pmj.20065
• Besner, C., & Hobbs, B. (2006). The perceived value and potential contribution of project management practices to project success.Project Management Journal, 37(3), 37-49.
• Besner, C., & Hobbs, B. (2008). Project Management Practice, Generic or Contextual : A Reality Check. Project Management Journal, 39(1), 16-33. http://dx.doi.org/10.1002/pmj.20033
  » http://dx.doi.org/10.1002/pmj.20033
• Blair, G. M. (1993). Planning a project. Engineering Management Journal, 3(1), 15-21.
• Blindenbach-Driessen, F., & Van Den Ende, J. (2010). Innovation management practices compared: the example of project-based firms.Journal of Product Innovation Management,27(5), 705-724. http://dx.doi.org/10.1111/j.1540-5885.2010.00746.x
  » http://dx.doi.org/10.1111/j.1540-5885.2010.00746.x
• Carden, L., & Egan, T. (2008). Does our literature support sectors newer to project management? The search for quality publications relevant to nontraditional industries. Project Management Journal, 39(3), 6-27. http://dx.doi.org/10.1002/pmj.20068
  » http://dx.doi.org/10.1002/pmj.20068
• Carvalho, B. V., & Mello, C. H. P. (2012). Aplicação do método ágil scrum no desenvolvimento de produtos de software em uma pequena empresa de base tecnológica. Gestão & Produção,19(3). http://dx.doi.org/10.1590/S0104-530X2012000300009
  » http://dx.doi.org/10.1590/S0104-530X2012000300009
• Chicarino, G. Z. (2005). O uso do Mind Map como ferramenta de gestão de projetos em áreas de consultoria e desenvolvimento de negócios e produtos (Dissertação de mestrado). Faculdade de Economia, Administração e Contabilidade, Universidade de São Paulo, São Paulo.
• Chin, G. (2004). Agile Project Management: how to succeed in the face of changing project requirements New York: Amacom.
• Cohn, M. (2005). Agile Estimating and Planning New York: Prentice Hall PTR.
• Conforto, E. C., & Amaral, D. C. (2009). Applying agile project management approach to NDP: the case of a small technology-based enterprise In Proceedings of the 16th International Product Development Management Conference, Enschede.
• Conforto, E. C., & Amaral, D. C. (2010a). Evaluating an agile method for planning and controlling innovative projects. Project Management Journal, 41(2), 73-80. http://dx.doi.org/10.1002/pmj.20089
  » http://dx.doi.org/10.1002/pmj.20089
• Conforto, E. C., & Amaral, D. C. (2010b). Agile project management and innovative product development: benefits and challenges of two companies from the Sao Carlos Tech Pole. In Proceedings of the POMS Annuals Conference, Vancouver.
• Conforto, E. C., Amaral, D. C., & Silva, S. L. (2011). Roteiro para revisão bibliográfica sistemática: aplicação no desenvolvimento de produtos e gerenciamento de projetos. In Anais Congresso Brasileiro de Gestão de Desenvolvimento de Produtos, Porto Alegre.
• Dawson, R., & Dawson, C. (1998). Practical proposals for managing uncertainty and risk in project planning. International Journal of Project Management, 16(5), 299-310. http://dx.doi.org/10.1016/S0263-7863(97)00059-8
  » http://dx.doi.org/10.1016/S0263-7863(97)00059-8
• Decarlo, D. (2004). Extreme Project Management: using leadership, principles, and tools to deliver value in the face of volatility San Francisco: Jossey Bass.
• Eder, S., Conforto, E. C., Schneltzler, J. P., Amaral, D. C., & Silva, S. L. (2012). Estudo das práticas de gerenciamento de projetos voltadas para desenvolvimento de produtos inovadores. Revista Produto & Produção, 13(1). Edição Especial CBGDP 2011.
• Eisenhardt, K. M. (1989). Building theories from case study research. Academy of Management Review, 14(4), 532-550.
• Evans, S., & Jukes, S. (2000). Improving co-development through process alignment. International Journal of Operations & Production Management, 20(8), 979-988. http://dx.doi.org/10.1108/01443570010332980
  » http://dx.doi.org/10.1108/01443570010332980
• Fernandez, D. J., & Fernandez, J. D. (2009). Agile project management - agilism versus traditional approaches. Journal of Computer Information Systems
• Fitsilis, P. (2008). Comparing PMBOK and agile project management software development processes. In S. Tarek (Org.), Advances in Computer and Information Sciences and Engineering (pp. 378-383). Neetherlands: Springer Science. http://dx.doi.org/10.1007/978-1-4020-8741-7_68
  » http://dx.doi.org/10.1007/978-1-4020-8741-7_68
• Ganguly, A., Nilchiani, R., & Farr, J. V. (2009). Evaluating agility in corporate enterprises. International Journal Production Economics, 118(2), 410-423. http://dx.doi.org/10.1016/j.ijpe.2008.12.009
  » http://dx.doi.org/10.1016/j.ijpe.2008.12.009
• Hass, K. B. (2009). Managing complex projects: a new model - A New ModelVienna: Managementconcepts.
• Highsmith, J. (2004). Agile project management: creating innovative products Boston: Addison-Wesley.
• Hodgson, D. (2002). Disciplining the professional: the case of project management. Journal of Management Studies, 39(6), 803-821. http://dx.doi.org/10.1111/1467-6486.00312
  » http://dx.doi.org/10.1111/1467-6486.00312
• Kerzner, H. (2006). Gestão de Projetos: as melhores práticas (Tradução de Lene Belon Ribeiro). Porto Alegre: Bookman. PMCid:PMC2569293.
• Kioppenborg, T., & Opfer, W. (2002). The current state of project management research: trends, interpretations and predictions.Project Management Journal, 33(2), 5-18.
• Kolltveit, B., Karlsen, J., & Gronhaug, K. (2007). Perspectives on project management. International Journal of Project Management, 25(1), 3-9. http://dx.doi.org/10.1016/j.ijproman.2005.12.002
  » http://dx.doi.org/10.1016/j.ijproman.2005.12.002
• Mafakheri, F., Nasiri, F., & Mousavi, M. (2008). Project Agility assessment: an integrated decision analysis approach. Production & Planning Control, 19(6), 567-576. http://dx.doi.org/10.1080/09537280802360884
  » http://dx.doi.org/10.1080/09537280802360884
• Miguel, P. A. C. (Org.). (2010). Metodologia de pesquisa em engenharia de produção e gestão de operações Rio de Janeiro: Elsevier.
• Murch, R. (2001). Project management: best practices for IT professionals New York: Prentice Hall Professional.
• Perminova, O., Gustafsson, M., & Wikström, K. (2008). Defining uncertainty in projects - a new perspective. International Journal of Project Management, 26(1), 73-79. http://dx.doi.org/10.1016/j.ijproman.2007.08.005
  » http://dx.doi.org/10.1016/j.ijproman.2007.08.005
• Petersen, K., & Wohlin, C. (2010). The effect of moving from a plan-driven to an incremental software development approach with agile practices. Empirical Software Engineering,15(6), 654-693. http://dx.doi.org/10.1007/s10664-010-9136-6
  » http://dx.doi.org/10.1007/s10664-010-9136-6
• Project Management Institute - PMI. (2008). Guia PMBOK: um guia do conjunto de conhecimentos do gerenciamento de projetos (4. ed.). Pennsylvania: Project Management Institute.
• Qumer, A., & Henderson-Sellers, B. (2008). An evaluation of the degree of agility in six agile methods and its applicability for method engineering. Information and Software Technology, 50(3), 280-295. http://dx.doi.org/10.1016/j.infsof.2007.02.002
  » http://dx.doi.org/10.1016/j.infsof.2007.02.002
• Rigby, D. (2001). Management tools and techniques: a survey.California Management Review, 43, 139-160. http://dx.doi.org/10.2307/41166079
  » http://dx.doi.org/10.2307/41166079
• Salomo, S., Weise, J., & Gemunden, H. G. (2007). NPD planning activities and innovation performance: the mediating role of process management and the moderating effect of product innovativeness. Journal of Product Innovation Management, 24(4), 285-302. http://dx.doi.org/10.1111/j.1540-5885.2007.00252.x
  » http://dx.doi.org/10.1111/j.1540-5885.2007.00252.x
• Sauser, B. J., Reilly, R. R., & Shenhar, A. J. (2009). Why projects fail? How contingency theory can provide new insights - a comparative analysis of NASA's Mars Climate Orbiter loss. International Journal of Project Management, 27, 665-679. http://dx.doi.org/10.1016/j.ijproman.2009.01.004
  » http://dx.doi.org/10.1016/j.ijproman.2009.01.004
• Schwaber, K. (2004). Agile Project Management with Scrum Washington: Microsoft Press.
• Shenhar, A., & Dvir, D. (2007). Reinventing Project Management: the diamond approach to successful growth and innovation Boston: Harvard Business School Press. PMCid:PMC1951820.
• Sibbet, D. (2010). Visual Meetings - How Graphics, sticky notes & ildea mapping can transform group productivity New Jersey: John Wiley and Sons. PMid:20197545.
• Silva, E. L., & Menezes, E. M. (2005). Metodologia da pesquisa e elaboração de dissertação (4. ed.). Florianopolis: UFSC.
• Smith, P. G. (2007). Flexible Product Development -building agility for changing markets San Francisco: Jossey-Bass.
• Thieme, R. J., Song, X. M., & Shin, G. C. (2003). Project management characteristics and new product survival. Journal of Product Innovation Management, 20(2), 104-119. http://dx.doi.org/10.1111/1540-5885.2002004
  » http://dx.doi.org/10.1111/1540-5885.2002004
• Thomke, S., & Reinertsen, D. (1998). Agile product development: managing development flexibility in uncertain environments. California Management Review, 41(1), 8-30. http://dx.doi.org/10.2307/41165973
  » http://dx.doi.org/10.2307/41165973
• Turner, R., & Ledwith, A. (2010). Project management in small to medium-sized enterprises: Matching processes to the nature of the firm.International Journal of Project Management, 28(8), 744-755. http://dx.doi.org/10.1016/j.ijproman.2010.06.005
  » http://dx.doi.org/10.1016/j.ijproman.2010.06.005
• Voss, C., Tsikriktsis, N., & Frohlich, M. (2002). Case research in operation management. International Journal of Operation & Production Management, 22(2), 195-219. http://dx.doi.org/10.1108/01443570210414329
  » http://dx.doi.org/10.1108/01443570210414329
• Williams, T. (1999). The need for new paradigms for complex projects. International Journal of Project Management, 17(5), 269-273. http://dx.doi.org/10.1016/S0263-7863(98)00047-7
  » http://dx.doi.org/10.1016/S0263-7863(98)00047-7
• White, D., & Fortune, J. (2002). Current practice in project management—An empirical study. International journal of project management, 20(1), 1-11. http://dx.doi.org/10.1016/S0263-7863(00)00029-6
  » http://dx.doi.org/10.1016/S0263-7863(00)00029-6
• Wysocki, R., & McGary, R. (2007). Effective Project Management: traditional, adaptive, extreme Indiana: Wiley Publishing.
• Yin, R. K. (2001). Estudo de caso: planejamento e métodos (Tradução de Daniel Grassi, 2nd ed.). Porto Alegre: Bookman.

Datas de Publicação

• Publicação nesta coleção
  18 Abr 2014
• Data do Fascículo
  July-Sep 2015

Histórico

• Recebido
  07 Maio 2012
• Aceito
  07 Out 2013