i

INSTITUTO TECNOLÓGICO DE AERONÁUTICA

PRÓ-REITORIA DE PÓS-GRADUAÇÃO E PESQUISA

PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA

AERONÁUTICA E MECÂNICA

RAFAEL NACIFE CARNEIRO

GESTÃO ÁGIL APLICADA AO DESENVOLVIMENTO

TECNOLÓGICO PRÉ-COMPETITIVO

CAMPO MONTENEGRO

SÃO JOSÉ DOS CAMPOS, SP – BRASIL.

2015
 iii

Dados Internacionais de Catalogação-na-Publicação (CIP)

Divisão de Informação e Documentação
CARNEIRO, Rafael Nacife.
Gestão Ágil Aplicada ao Desenvolvimento Tecnológico Pré-Competitivo / Rafael Nacife Carneiro.
São José dos Campos, 2015.
Número de folhas134 f.

Dissertação de Mestrado Profissional – Curso de Pós- Graduação em Engenharia Aeronáutica e

Mecânica – Instituto Tecnológico de Aeronáutica, 2015. Orientadores: Prof. Dr. Luís Gonzaga
Trabasso; Prof. Dr. Claudiano Sales de Araújo Junior.

1. Administração de projetos. 2. Melhoria continua. 3. Controle de processos; Desenvolvimento de

produto. 4. Engenharia de produção. I. Instituto Tecnológico de Aeronáutica. II. Gestão Ágil Aplicada ao
Desenvolvimento Tecnológico Pré-Competitivo.

REFERÊNCIA BIBLIOGRÁFICA
CARNEIRO, Rafael Nacife. Gestão Ágil Aplicada ao Desenvolvimento Tecnológico Pré-
Competitivo. 2015. 134 f. Dissertação de Mestrado em Engenharia Aeronáutica – Instituto
Tecnológico de Aeronáutica, São José dos Campos.

CESSÃO DE DIREITOS

NOME DO AUTOR: Rafael Nacife Carneiro

TÍTULO DO TRABALHO: Gestão Ágil Aplicada ao Desenvolvimento Tecnológico Pré-Competitivo.
TIPO DE TRABALHO: Dissertação/ 2015

É concedida ao Instituto Tecnológico de Aeronáutica permissão para reproduzir cópias desta

dissertação e para emprestar ou vender cópias somente para propósitos acadêmicos e
científicos. O autor reserva outros direitos de publicação e nenhuma parte desta dissertação
pode ser reproduzida sem a sua autorização (do autor).

__________________________________
Rafael Nacife Carneiro
Av. Jorge Zarur, 471, Apto 1003 B.Vila Ema.
CEP:12243-081, São José dos Campos - SP
 iv

GESTÃO ÁGIL APLICADA AO DESENVOLVIMENTO

TECNOLÓGICO PRÉ-COMPETITIVO

Rafael Nacife Carneiro

Composição da Banca Examinadora:

Prof. PhD. Luís Gonzaga Trabasso Presidente/Orientador – ITA

Prof. PhD. Claudiano Sales de Araújo Junior Co-Orientador – EMBRAER
Prof. M.C. Manoel de Queiroz Cordova Santos – EMBRAER
Prof. PhD. Marcus Vinícius Pereira Pessôa – ITA

ITA
 v

Dedico este trabalho a toda minha família

A minha namorada e àqueles que me apoiaram
E tornaram possível esta realização.
 vi

AGRADECIMENTOS

Em primeiro lugar, agradeço a minha família, aos amigos e parceiros nesta caminhada
até aqui. Nada nesta vida se conquista sozinho e ninguém cresce na vida sem o apoio de outras
pessoas.
Sou muito grato a vocês meus caros: Orientador Luís Gonzaga e Co-Orientador
Claudiano Sales, por me darem um voto de confiança e por todo o apoio até aqui.
Agradeço à Embraer pela oportunidade de participar do programa PEE, que tem
conduzido muitos jovens engenheiros como eu por uma trilha de desenvolvimento e sucesso
profissional.
Meu muito obrigado também a cada um dos engenheiros do desenvolvimento
tecnológico da Embraer, que participaram desta pesquisa ação e contribuíram de alguma forma
para a realização do trabalho.
 vii

“Não existe maior sinal de insanidade do que

fazer as coisas do mesmo jeito e esperar
que os resultados sejam diferentes.”
(Albert Einstein)
 viii

RESUMO

A execução com sucesso de projetos de inovação pré-competitiva, onde se inclui o

desenvolvimento tecnológico, é ainda um grande desafio para as equipes envolvidas. A correta
escolha das metodologias e processos a serem adotados na gestão destes projetos é crucial para
o sucesso dos mesmos. Neste trabalho é apresentada e avaliada uma proposta integrada de
gestão híbrida de projetos, tradicional e ágil, em três níveis: gestão estratégica (utilizando-se
uma abordagem tradicional de gestão de projetos, suportada pelo ambiente PS-SAP), gestão
tática (onde adota-se a corrente crítica) e gestão operacional (baseado numa derivação do
Scrum), para suportar o desenvolvimento deste tipo de projeto de desenvolvimento tecnológico
pré-competitivo. Este modelo, chamado de MGADT, foi o resultado de um processo de
melhoria contínua (kaizen), que contou com a participação de 17 membros seniores do
desenvolvimento tecnológico pré-competitivo de uma grande empresa aeronáutica brasileira e
também do autor. A avaliação do MGADT se deu a partir de sua aplicação em dois projetos
tecnológicos em desenvolvimento nesta empresa. Estas experiências foram comparadas entre
si, com a literatura e em relação às práticas até então adotadas para gerir os demais projetos. As
evidências coletadas deram indícios de que é possível aplicar os princípios ágeis para gerir
projetos de desenvolvimento tecnológico, apesar do ambiente altamente dinâmico, e que está
aplicação traz benefícios ao monitoramento e controle dos mesmos. Entretanto, o estudo aponta
que há a necessidade de aprimorar as análises conduzidas, abordando o lado qualitativo, e
aprimorar o próprio modelo MGADT, com aplicação e validação em outros projetos e outras
empresas.

Palavras-chave: Gestão de Projetos; Gestão Ágil; Scrum; Desenvolvimento Tecnológico Pré-

Competitivo.
 ix

ABSTRACT

The success on execution of pre-competitive innovation projects, which includes

technology development, is a great challenge for the teams involved. The right choice of
methodology and process applied on the management of these projects is crucial to its success.
This work presents and evaluates an integrated hybrid project management model, traditional
and agile, based on three levels: strategic management (using a traditional approach project
management, supported by PS-SAP environment), tactical management (which takes up the
theory of constraints) and operational management (based on a derivation of Scrum), for
support the development of pre-competitive technological projects. This model, called
MGADT, was the result of a continuous improvement process (Kaizen) which counted with a
participation of 17 senior members from the technological department of a great Brazilian
aeronautical company and of the author. The evaluation of MGADT was taken from its
application on two technological development projects of this company. These experiences
were compared between themselves, with the literature and the practices that were used to
manage the other projects. The evidences collected during this research have indicated that is
possible to apply the Agile Principles to manage this type of project, developed in highly
dynamic environment, and it could bring benefits on monitoring and control management.
However, this study indicates the stills need to improve the conducted analyzes, addressing a
qualitative side, and improve own MGADT model with application and validation in other
projects and other business enterprises.

Keywords: Project Management; Agile Management; Scrum; Pre Competitive Technological

Development.
 x

LISTA DE FIGURAS

Figura 1 – Ciclo de vida do projeto (PMI, 2013) ..................................................................... 25

Figura 2 – Exemplo de projeto de fase única (PMI, 2013)....................................................... 26
Figura 3 – Dependência temporal das dimensões de sucesso (SHENHAR et al., 1997). ........ 27
Figura 4- Divisão das principais metodologias de gestão de projetos (BECK, 1999). ............ 33
Figura 5- Exemplo do conflito de gerenciamento de tempo em projetos (BARCAUI;
QUELLHAS, 2004). ................................................................................................................. 37
Figura 6- Fever Chart (ATREYA, 2012). ................................................................................ 38
Figura 7- Abordagem tradicional x ágil (FARIA, 2013). ......................................................... 42
Figura 8- Abordagem tradicional x ágil (HIGHSMITH, 2004). .............................................. 42
Figura 9- Porcentagem de utilização dos diferentes métodos ágeis (VERSIONONE.COM,
2013). ........................................................................................................................................ 46
Figura 10- Visão geral do Scrum (BRAZ, 2013). .................................................................... 48
Figura 11- Quadro Scrum (DE CASTRO, 2009). .................................................................... 51
Figura 12- Fases de um projeto XP (FAGUNDES, 2005). ...................................................... 54
Figura 13- Fases de um projeto FDD (SSPECTER, 2011). ..................................................... 58
Figura 14- Fluxo lean (WOMACK; JONES e DANIEL, 1996). ............................................. 60
Figura 15 – Os treze princípios do sistema Toyota de desenvolvimento de produto (MORGAN;
LIKER, 2006). .......................................................................................................................... 62
Figura 16 – Princípios e práticas LPD derivadas da revisão literária por domínio de
conhecimento (LEON; FARRIS, 2011). .................................................................................. 64
Figura 17- Exemplo de um sinalizador virtual kanban (MARIOTTI, 2012). .......................... 66
Figura 18- Modelo do ciclo P&D na indústria aeronáutica (Adaptado de MATSUO, 2010). . 75
Figura 19- Technology Readiness Levels (Traduzido de ALOPEX, 2013). ............................ 76
Figura 20- Exemplo da evolução de uma tecnologia (Adaptado de NASA e WERRIES, 2010).
.................................................................................................................................................. 77
Figura 21- Technology development Stage-Gate® (COOPER, 2007). .................................... 78
Figura 22- Building blocks test approach (MATSUMURA, HAFTKA e KIM, 2011). .......... 80
Figura 23 – Modelo Referencial (AMARAL et al., 2011) ....................................................... 81
Figura 24 – Método para gerenciamento ágil de projetos – IVPM2 (CONFORTO, 2009) ..... 82
Figura 25 – Modelo de fases e entregas (AMARAL et al., 2011) ............................................ 83
 xi

Figura 26- Esquema utilizado nesta dissertação (O autor). ...................................................... 85

Figura 27- Desenvolvimento Tecnológico (EMPRESA ANALISADA, 2014). ...................... 90
Figura 28- Modelo de Gestão Ágil para Desenvolvimento Tecnológico (MGADT) (DT
EMPRESA ANALISADA, 2014). ........................................................................................... 93
Figura 29- Primeiro nível do MGADT (DT EMPRESA ANALISADA, 2014). ..................... 94
Figura 30- Segundo nível do MGADT (DT EMPRESA ANALISADA, 2014). ..................... 95
Figura 31- Terceiro nível do MGADT (DT EMPRESA ANALISADA, 2014). ..................... 95
Figura 32- Modelo de Gestão Ágil para Desenvolvimento Tecnológico (MGADT) (DT
EMPRESA ANALISADA, 2014). ........................................................................................... 96
Figura 33- Integração do Modelo de Gestão Ágil para Desenvolvimento Tecnológico
(MGADT) (O Autor). ............................................................................................................... 98
Figura 34- Nível 1 MGADT x Modelo de fases e entregas IVPM2 (O Autor). ....................... 99
Figura 35- Nível 2 MGADT x Painel visual de planejamento e controle de projetos IVPM2 (O
Autor). .................................................................................................................................... 100
Figura 36- Nível 3 MGADT x Quadro de planejamento fino semanal IVPM2 (O Autor). ... 100
 xii

LISTA DE TABELAS

Tabela 1-Diferenças entre o tradicional e o ágil. ...................................................................... 19

Tabela 2 – Recursos e Métodos utilizados para atender os objetivos específicos .................... 22
Tabela 3 - Resultado de sucesso, falha e desafio em projetos. ................................................. 29
Tabela 4 – Problemas que ocorrem com mais frequência nos projetos da Organização.......... 29
Tabela 5-Diferenças entre o tradicional e o ágil. ...................................................................... 43
Tabela 6- Comparação entre métodos ágeis ............................................................................. 69
Tabela 7 – Respostas do questionário para o projeto ............................................................. 107
Tabela 8 – Respostas do questionário para o projeto B .......................................................... 113
 xiii

LISTA DE ABREVIATURAS E SIGLAS

APM Agile Project Management

AIPM Australian Institute of Project Management
BAC Budget at Completion
CAD Computer-Aided Design
CAE Computer-Aided Engineering
CEO Chief Executive Officer
COMBOL Common Business-Oriented Language
CPI Cost Performance Index
CCPM Critical Chain Project Management
DIP Desenvolvimento Integrado de Produto
DoD Department of Defense
DT Desenvolvimento tecnológico
EMPRESA Empresa Brasileira de Aeronáutica
ANALISADA
ERP Enterprise Resource Planning
EVM Earned Value Management
FDD Feature Driven Development
GP Gerenciamento de Projetos
GVA Gestão do Valor Agregado
IID Iterative and Incremental Development
IPMA International Project Management Association
ITA Instituto Tecnológico de Aeronáutica
IVPM2 Iterative and Visual Project Management Method
LSD Lean Software Development
LPD Lean Product Development
NASA National Aeronautics and Space Administration
NPD New Product Development
MAP Memorando de Ativação de Projeto
MGADT Modelo de Gestão Ágil para Desenvolvimento Tecnológico
OOPSLA Object-oriented Programming, Systems, Languages, and
Applications
PD Product Development
PDI Product Development Introduction
P&D Pesquisa e Desenvolvimento
P&T Pesquisa e Tecnologia
PMBOK Project Management Body Of Know
PMI Project Management Institute
RAD Rapid Application Development
ROI Return on Investment
 xiv

RUP Rational Unified Process

SAP Systeme, Anwendungen und Produkte
SPI Schedule Performance Index
TOC Theory of Constrains
TRL Technology Readiness Level
XP Extreme Programming
WBS Work Breakdown Structure
WIP Work in Process
 xv

SUMÁRIO

1 INTRODUÇÃO 18
2 FUNDAMENTAÇÃO TEÓRICA 24
2.1 PROJETO 24
2.1.1 Ciclo de Vida e Fases de um Projeto 25
2.1.2 Sucesso em Projetos 26
2.1.3 Fracasso em Projetos 28
2.2 PROJETOS DE DESENVOLVIMENTO DE PRODUTO X PROJETOS DE
DESENVOLVIMENTO TECNOLÓGICO (INOVAÇÃO PRÉ-COMPETITIVA) 30
2.3 GESTÃO DE PROJETOS 32
2.4 GESTÃO TRADICIONAL DE PROJETOS 34
2.5 TEORIA DAS RESTRIÇÕES 35
2.5.1 Corrente Crítica (CCPM) 36
2.6 GESTÃO ÁGIL DE PROJETOS 38
2.7 DIFERENÇAS ENTRE GESTÃO ÁGIL E TRADICIONAL 41
2.8 LIMITES DA GESTÃO ÁGIL 44
2.9 DIFERENTES MÉTODOS DE GESTÃO DE PROJETOS ÁGEIS 46
2.9.1 SCRUM 47
2.9.1.1 Framework SCRUM 48
2.9.1.2 Equipe Scrum 48
2.9.1.3 Eventos do Scrum 49
2.9.1.4 Artefatos do Scrum 50
2.9.2 Extreme Programming (XP) 51
2.9.2.1 Práticas do XP 52
2.9.2.2 Ciclo de vida de um projeto XP 53
2.9.2.3 A equipe XP 55
2.9.3 Feature Driven Development (FDD) 56
2.9.3.1 Práticas do FDD 56
2.9.3.2 As fases do FDD 57
2.9.3.3 A equipe FDD 59
2.9.4 Lean 60
 xvi

2.9.4.1 Lean Product Development (LPD) 61

2.9.4.2 Lean Software Development (LSD) 65
2.9.5 Kanban 66
2.9.5.1 Processos Kanban 67
2.10 COMPARAÇÃO ENTRE OS MÉTODOS ÁGEIS EM ESTUDO 67
2.11 O ÁGIL APLICADO FORA DO AMBIENTE INICIALMENTE PROPOSTO 71
2.12 DESENVOLVIMENTO TECNOLÓGICO NA INDÚSTRIA AERONÁUTICA 73
2.12.1 Technology Readyness Level (TLR) 76
2.13 DESENVOLVIMENTO DE PROJETOS TECNOLÓGICOS 78
2.14 GERENCIAMENTO ÁGIL APLICADO A PRODUTOS INOVADORES 80
3 CASO INDUSTRIAL DE APLICAÇÃO 84
3.1 METODOLOGIA 84
3.2 PRIMEIRA ETAPA 85
3.2.1 Análise do Problema 86
3.2.2 Revisão da Literatura 87
3.2.3 Método Ágil na Empresa Analisada 88
3.2.4 Cenário Atual do Desenvolvimento Tecnológico da Empresa Analisada 89
3.2.4.1 Portfólio de Projetos do DT da Empresa Analisada 89
3.2.4.2 Gestão Atual dos Projetos no DT da Empresa Analisada 91
3.3 KAIZEN SOBRE GESTÃO DE PROJETOS DO DT DA EMPRESA ANALISADA 93
3.4 MODELO DE GESTÃO ÁGIL PARA DESENVOLVIMENTO TECNOLÓGICO (MGADT)
94
3.5 INTEGRAÇÃO ENTRE OS TRÊS NÍVEIS DE GESTÃO 96
3.6 COMPARATIVO ENTRE O MGADT E O IVPM2 99
3.7 PESQUISA SURVEY 101
4 APLICAÇÃO, RESULTADOS E DISCUSSÕES 103
4.1 PROJETO A 104
4.1.1 Modelo de Gestão Ágil para Desenvolvimento Tecnológico (Projeto A) 104
4.1.2 Questionário Projeto A 107
4.2 PROJETO B 109
4.2.1 Scrum Projeto B 110
4.2.2 Questionário Projeto B 112
4.3 MODELOS DE GESTÃO APLICADOS AOS: PROJETO A X PROJETO B X MODELO DE
GESTÃO ANTERIOR 114
 xvii

4.4 DIFERENÇAS ENTRE A APLICAÇÃO DO SCRUM NA EMPRESA ANALISADA E A

LITERATURA 115
4.5 VISÃO/CRÍTICA DO AUTOR 118
5 CONCLUSÕES 121
5.1 LIMITAÇÕES DO TRABALHO 124
5.2 PROPOSTAS FUTURAS DE TRABALHO 125
REFERÊNCIAS 126
APÊNDICE 132
ANEXO 133
 18

1 INTRODUÇÃO

Pesquisas realizadas por institutos dedicados ao estudo do conjunto de processos

conhecido por gestão de projetos, como exemplo o grupo Standish (THE STANDISH GROUP,
2013), mostram que entregar um projeto no tempo, no custo, e com todas as funções e
características acordadas inicialmente ainda é um grande desafio para a maioria das empresas.
No ano de 2012, por exemplo, este grupo em questão revelou, em uma pesquisa de âmbito
internacional, que apenas 39% dos projetos pesquisados obtiveram êxito. Os 61% restantes, ou
se demonstraram um desafio para as empresas, ou até mesmo foram cancelados e nunca tiveram
seus resultados utilizados (THE STANDISH GROUP, 2013).
Paralelamente, segundo a pesquisa promovida pelo PMI (PMI’S PULSE OF THE
PROFESSION, 2013), menos de dois terços dos projetos atendem a seus objetivos e intenções
de negócio, e 17% falham completamente. Estima-se que a cada 1 bilhão de dólares gastos
nestes projetos, 135 milhões de dólares são perdidos para sempre.
Não muito diferente, uma pesquisa realizada pelo instituto PMI Brasil, no âmbito
nacional, analisou 460 empresas brasileiras de diferentes ramos de atuação e tamanho,
mostrando que 78% das organizações, confirmam ter problemas no cumprimento dos prazos,
61% no comprimento dos custos acordados e 44% julgaram ter problemas de qualidade em seus
projetos (PMSURVEY.ORG, 2010).
Isto nos leva a refletir sobre a real eficácia dos métodos que estão sendo utilizados para
gerir projetos dentro das empresas.
As práticas de gestão de projetos mais comuns, difundidas e utilizadas atualmente, estão
contidas no “Guia PMBoK”, desenvolvido e atualizado a cada quatro anos pelo instituto PMI
(SOTILLE, 2014). Este guia contempla uma coletânea de práticas, conceitos e ferramentas
padronizadas, que são descritas como úteis para qualquer tipo de projeto, em qualquer área de
conhecimento (AMARAL et al., 2011).
Apesar das técnicas e métodos provenientes do PMBoK serem amplamente conhecidas
e terem sua eficácia demonstrada em vários estudos de caso sobre o tema, ao longo das últimas
décadas começaram a aparecer críticas à sua aplicação generalizada e à singularidade dos
conhecimentos contidos no BoK (CONFORTO, 2009).
Shenhar e Dvir (2007) ilustraram estas críticas no trabalho Project management
research – the challenge and opportunity (Tabela 1), onde compararam as diferentes
 19

características entre a gestão de projetos tradicional e gestão dita pelos autores adaptável. Neste
estudo, os autores deixam claro que a gestão adaptável é a melhor opção para gerir projetos que
segundo Highsmith (2004) são desenvolvidos em ambientes “turbulentos”, ou seja, envolvem
muitas mudanças durante o seu desenvolvimento.

Tabela 1-Diferenças entre o tradicional e o ágil.

Abordagem Tradicional Adaptável

Metas do Enfoque na finalização do projeto Enfoque nos resultados do negócio,
Projeto no tempo, custo e requisito de atingir múltiplos critérios de
qualidade. sucesso.
Plano do Uma coleção de atividades Uma organização e processo para
Projeto executadas como planejamento atingir as metas esperadas e os
para atender à restrição tripla resultados para o negócio.
(tempo, custo e qualidade).
Planejamento Realizado uma vez no início do Realizado no início e reavaliado
projeto. sempre que necessário
Abordagem Rígida, com foco no plano inicial. Flexível, variável, adaptável.
Gerencial
Trabalho/ Previsível, mensurável, linear, Imprevisível, não mensurável, não
Execução simples. linear, complexo.
Influência da Mínima, imparcial a partir do kick- Afeta o projeto ao longo de sua
Organização off do projeto. execução.
Controle do Identificar desvios do plano inicial Identificar mudanças no ambiente e
Projeto e corrigir, o trabalho, para seguir o ajustar o plano adequadamente.
plano.
Aplicação da Aplicação genérica e igualitária em Adaptação do processo,
Metodologia todos os projetos. dependendo do tipo de projeto.
Estilo de Um modelo atende a todos os tipos Abordagem adaptativa, um único
Gerenciamento de projetos. modelo não atende a todos os tipos
de projetos.
Fonte: Adaptado de SHENHAR; DVIR, 2007 (Apud AMARAL et al., 2011).

Autores como Williams (1999), Dawson e Dawson (1998), e Perminova et al. (2008),
assim como Shenhar e Dvir (2007), também corroboram com a afirmativa de que as técnicas e
ferramentas tradicionais de gestão de projetos não são adequadas a projetos que envolvam alta
complexidade e elevado nível de incerteza.
Essas críticas deram origem a um movimento, no campo de pesquisa científico, de
formulação de novas teorias de gestão de projetos para suportar o desenvolvimento neste tipo
de ambiente. Estas teorias foram denominadas genericamente de gerenciamento ágil de
projetos, desenvolvimento flexível, adaptativo, iterativo, projetos extremos e gerenciamento
enxuto (AMARAL et al., 2011).
 20

De acordo com Amaral et al. (2011) um ponto em comum a todas essas novas técnicas
é que buscam maior autonomia da equipe de projeto, através do que chamam de autogestão,
pregando o planejamento incremental e iterativo, e elevando a interação entre os membros da
equipe. Procuram a flexibilidade, simplicidade e agilidade aplicadas no ambiente de projeto,
com equipes enxutas e altamente eficazes.
Neste mesmo caminho tem-se buscado complementar as práticas de gestão tradicional,
com conceitos de agilidade e flexibilidade, principalmente quando se refere a projetos de
produtos inovadores (AMARAL et al., 2011; CONFORTO, 2009). Em geral trata-se de projetos
de alta complexidade e elevado nível de incerteza, envolvendo sempre algo novo, diferente e,
sobretudo, imprevisível. As soluções são pouco conhecidas, e muitas vezes podem se mostrar
impossíveis durante a execução do projeto.
Compartilhando também de um ambiente de desenvolvimento bastante “turbulento”,
está o desenvolvimento tecnológico (DT). Apesar de características semelhantes ao projeto de
produto inovador, como incerteza, dificuldade de criar estratégias, definir o escopo e gerar
soluções, o desenvolvimento tecnológico não visa um produto final, mas sim a obtenção do
domínio em uma determinada tecnologia, quase sempre a partir de uma prova de conceito.
Como resultado, espera-se que a tecnologia seja desenvolvida, até certo nível de
maturidade, para que possa ser incorporada em algum projeto futuro de produto da empresa. E
só então passará a gerar receitas. Daí esse tipo de projeto ser também conhecido na literatura
como desenvolvimento pré-competitivo (ARAUJO, 2012), ou mesmo inovação pré-
competitiva (MATSUO, 2010).
Via de regra este tipo de projeto possui muitos riscos e muitas incógnitas, maiores do
que os envolvidos em produtos inovadores, mas ao mesmo tempo é crucial para o crescimento
no longo prazo das empresas, para sua prosperidade e sua sobrevivência (MATSUO, 2010).
Principalmente no cenário atual, no qual há uma necessidade das empresas se reinventarem para
se manter no mercado, altamente competitivo.
Apesar das muitas críticas ao modelo de gestão tradicional para aplicação em todo e
qualquer tipo de projeto, quando se refere a projetos altamente técnicos, com alto risco e alto
grau de incerteza, a literatura sobre gestão de projetos ágil e sua aplicação no desenvolvimento
tecnológico pré-competitivo ainda é limitada, principalmente quando se refere à aplicação real
e avaliação desses modelos. Faz-se assim necessário que, além da proposição de métodos e
técnicas baseados na abordagem ágil, os mesmos sejam testados empiricamente, para verificar
sua viabilidade quando aplicados no ambiente de desenvolvimento tecnológico de grandes
empresas.
 21

Diante deste contexto, formulou-se a hipótese de que a aplicação dos conceitos ágeis,
em complemento às teorias tradicionais, traria benefícios ao desenvolvimento de projetos
tecnológicos pré-competitivos. Foi definido o ambiente de pesquisa como sendo o
departamento de desenvolvimento tecnológico de uma grande fabricante de aviões brasileira, a
empresa analisada, que não havia tido experiência anterior com a aplicação dos princípios ágeis
na área analisada em questão (DT).
As questões centrais da pesquisa são:
Q1) Seria possível aplicar os princípios ágeis em projetos de desenvolvimento
tecnológicos pré-competitivo de uma grande corporação?
Q2) Há benefícios na aplicação de princípios ágeis em projetos de desenvolvimento
tecnológico pré-competitivo?
Q3) É possível aplicar os conceitos ágeis em complemento às teorias tradicionais de
gestão de projetos, no ambiente de desenvolvimento tecnológico pré-competitivo?
Para responder a estas questões, foi definido o seguinte objetivo geral: desenvolver,
aplicar e avaliar, em projetos de desenvolvimento tecnológicos da empresa estudada, um
modelo e processo baseado nos princípios ágeis para o processo de planejamento e controle de
tempo e escopo.
Como objetivos específicos têm-se:
1. Desenvolver um estudo bibliográfico para suportar a confecção de um novo modelo de
gestão a ser aplicado no desenvolvimento tecnológico da empresa analisada.
2. Consultar como se deu a aplicação de conceitos ágeis em outras áreas (DIP) da empresa
analisada, e quais os modelos estão realmente funcionando nestas áreas.
3. Criar um modelo de gestão de projetos, baseado nos conceitos ágeis, que seja
complementar ao modelo atual, em uso, no departamento de desenvolvimento
tecnológico da empresa analisada;
4. Aplicar o modelo proposto em projetos de diferentes áreas de estudo;
5. Avaliar o modelo proposto por meio de entrevistas e questionários respondidos pelo
time de desenvolvimento de projeto.
A justificativa deste estudo é pautada em dois grandes cenários: geral e no departamento
de desenvolvimento tecnológico da empresa analisada. Conforme apontado no início desse
capítulo, no cenário geral há uma crítica na literatura sobre a aplicabilidade dos métodos
tradicionais a todo e qualquer tipo de projeto, principalmente em projetos de elevada incerteza.
Por outro lado, há um gap na literatura quando se trata de métodos demonstrados para a gestão
de projetos de desenvolvimento tecnológico pré-competitivo. Especificamente no cenário da
 22

empresa analisada observou-se uma falta de uniformidade em relação ao método utilizado para
gerir os projetos, excesso de tempo gasto com atividades administrativas, sobretudo na
manutenção dos projetos no sistema empresarial SAP (Modulo PS) (DOWLING, 2008),
dificuldade de integrar o sistema empresarial PS-SAP com a metodologia corrente crítica,
recentemente implementada, e consequentemente, dificuldade na utilização da metodologia
corrente crítica (DETTMER, 1997).
Para atender ao objetivo geral do estudo em questão, utilizou-se da pesquisa
bibliográfica sistemática e o método de pesquisa ação. Para cada um dos objetivos específicos
foram definidos os seguintes recursos e métodos (Tabela 2):

Tabela 2 – Recursos e Métodos utilizados para atender os objetivos específicos

Objetivo
Recursos Métodos
Específico
Internet 1) Foi realizada uma pesquisa literária extensiva
Livros envolvendo os principais assuntos, para dar
1
Periódicos embasamento teórico ao novo modelo de gestão
Revistas proposto.
1) Foram realizadas apresentações por partes das
equipes que já haviam utilizado metodologias híbridas
2 N/A na empresa analisada, onde foi possível verificar a
forma como foi aplicado o ágil e quais aspectos deram
certo.
Aplicativos de
Software: 1) Foi realizado um Kaizen1, envolvendo os principais
3 JIRA responsáveis pelo desenvolvimento de projetos no
CCPM ambiente tecnológico empresa analisada e o autor.
PS-SAP
1) Foram definidos dois projetos, nas áreas de estudo de
4 N/A software e ruídos respectivamente, para aplicar os
conceitos ágeis.
Questionário 1) Foram realizadas entrevistas e preenchido um
5 utilizando a escala questionário com os membros participantes dos projetos
Likert2 em que os conceitos ágeis foram aplicados.
Fonte: O Autor

O presente trabalho restringiu-se à análise comparativa dos principais modelos ágeis de

gestão, à diferenciação entre abordagem ágil e tradicional, e à utilização de modelos híbridos
de gestão de projetos desenvolvidos em ambiente “turbulento”.

1
Segundo IMAI (1994) Kaizen é um processo de melhoria continua com o objetivo de busca da redução de gastos em todas as
etapas de manufatura e também eliminação das diferenças entre o custo-alvo e o custo-estimado.
2
A escala Likert é um tipo de escala de resposta psicométrica usada habitualmente em questionários. Foi desenvolvida pelo
sociólogo Dr. Rensis Likert e publicada no estudo “A Technique for the Measurement of Attitudes” (Likert, 1932).
 23

Este estudo, referenciado na fundamentação teórica, serviu de suporte à elaboração de

um modelo híbrido de gestão de projetos, denominado de MGADT – Modelo de Gestão Ágil
para Desenvolvimento Tecnológico –, para o processo de planejamento e controle de tempo e
escopo, concebido de forma conjunta entre o autor e uma equipe técnica da empresa analisada.
Como limitação deste trabalho verificou-se a falta na literatura exemplos de modelos
teóricos ou mesmo aplicação prática, de conceitos ágeis de gestão destinados a projetos de
desenvolvimento de tecnologia. Os projetos que mais se aproximaram do ambiente tecnológico
foram: o desenvolvimento de produtos inovadores abordado na forma do modelo IVPM2
descrito em Amaral et al. (2011) e Conforto (2009) e o desenvolvimento de produtos altamente
complexos como em SANTOS (2013).
A organização do trabalho se deu da seguinte forma:
• Capítulo 2 – Fundamentação Teórica: apresenta a teoria sobre gerenciamento de
projetos, focada na gestão ágil, sua definição, princípios e principais modelos. Descreve e
diferencia desenvolvimento tecnológico, em relação ao desenvolvimento de produtos.
• Capítulo 3 – Caso de Aplicação: apresenta o desenvolvimento tecnológico pré-
competitivo na empresa analisada, descrevendo a forma como os projetos são geridos, as
mudanças propostas e a aplicação do modelo proposto em dois projetos do portfólio da empresa
analisada. Por fim é comparada a aplicação real com a literatura.
• Capítulo 4 – Discussões: é avaliado o modelo proposto, tomando como base as
práticas de gestão de projetos, utilizadas anteriormente no DT da empresa analisada.
• Capítulo 5 - Conclusões: são apresentadas as conclusões do trabalho, de forma a
mostrar como foram atingidos os objetivos propostos, responde-se às questões de pesquisa, e
propõe-se os próximos passos, relativos a melhorias que podem ser implementadas em uma
nova aplicação do modelo inicialmente proposto.
 24

2 FUNDAMENTAÇÃO TEÓRICA

Este capítulo apresenta a fundação teórica, na qual foi baseada a hipótese de que a
aplicação dos conceitos ágeis, em complemento às teorias tradicionais, traria benefícios aos
projetos de desenvolvimento tecnológico pré-competitivo.
A seção se inicia com as definições de projeto, faz-se uma comparação entre o
desenvolvimento de produtos e desenvolvimento tecnológico e são descritas as principais
metodologias para o gerenciamento de projetos. Apresentam-se então as principais críticas aos
modelos ditos “tradicionais”, descrevendo a seguir a abordagem ágil, suas contribuições,
limites, principais métodos e modelos em que é aplicado de forma complementar às boas
práticas do guia PMBOK. Ao final do capítulo é apresentado o cenário do desenvolvimento de
projetos tecnológicos, com suas dificuldades e o ambiente mencionado anteriormente como
“turbulento”.

2.1 Projeto

Projeto é uma palavra que tem origem no latim, projectum, e significa “algo lançado a
frente”. A literatura o define como um empreendimento temporário, executado para gerar um
produto, serviço ou atingir um resultado, com objetivos claros e bem definidos (PMI, 2013).
Ainda de acordo com o PMI, um projeto deve gerar algo único, ou seja, não se trata de
uma operação rotineira, com processos contínuos ou repetitivos, como ocorre em uma linha de
montagem. É um esforço nunca realizado no passado, pelo menos para quem está executando
esse esforço, e que talvez não se repita no futuro. Possui começo, meio e fim bem definidos,
além de restrições de tempo, custos, recursos e também de qualidade.
Nas empresas, os projetos surgem quando ocorre uma demanda de ações que não podem
ser executadas dentro de seus limites operacionais normais (PMI, 2013). O projeto pode surgir
de uma demanda legal, como uma mudança da legislação, pela necessidade de avanço
tecnológico, uma demanda ou oportunidade de mercado, um novo requisito de clientes etc.
No mundo atual, altamente competitivo, os projetos têm se tornado cada vez mais
importantes, maiores e mais complexos, principalmente dentro das empresas que querem se
manter competitivas (TAKEUCHI; NONAKA, 1986). Como consequência o desafio de
gerenciar estes projetos tem se tornado mais difícil e, com isto, diversas metodologias de gestão
 25

de projetos foram surgindo e se consolidando ao longo dos anos (CRUZ, 2013). Note que para
o escopo deste trabalho definimos uma metodologia de gestão de projetos como um conjunto
estruturado de conhecimentos, habilidades, ferramentas e técnicas que, quando aplicadas de
forma organizada a um projeto, aumentará a probabilidade de que o mesmo atinja seus
objetivos.

2.1.1 Ciclo de Vida e Fases de um Projeto

De acordo com o PMI (2013) todos os projetos podem ser mapeados por uma estrutura
genérica de ciclo de vida, contendo: início do projeto, organização e preparação, execução do
trabalho e encerramento do projeto.
Pode-se inferir que os custos e a quantidade de pessoas envolvidas nos projetos
(engajamento) têm um aumento significativo à medida que o projeto está sendo desenvolvido.
Atinge-se o pico durante execução e cai rapidamente, quando o projeto caminha para o fim
(Figura 1). Por outro lado, os riscos e incertezas, decaem ao longo do tempo, enquanto os custos
relacionados às mudanças aumentam exponencialmente.

Figura 1 – Ciclo de vida do projeto (PMI, 2013)

 26

Um projeto também pode ser divido em fases. Cada fase é um conjunto de atividades
que tem como resultado uma ou mais entregas. Em projetos mais complexos, ocorre a
necessidade de um maior controle das entregas por parte dos gerentes, sendo recomendada a
divisão do projeto em várias fases, que podem estar relacionadas de forma sequencial,
sobrepostas ou de forma paralela. Cada fase é composta por cinco grupos de processos:
iniciação, planejamento, execução, monitoramento e controle, e encerramento como mostrado
na Figura 2.

Figura 2 – Exemplo de projeto de fase única (PMI, 2013).

2.1.2 Sucesso em Projetos

A definição do significado de sucesso em um projeto não é um consenso, nem na

literatura e tampouco no dia a dia das empresas (SHENHAR et al., 1997). Na história, já houve
diversos casos em que projetos foram tidos como triunfos, em questão de prazo e orçamento
atingidos, ou por representarem marcos na humanidade, mas que não foram bem recebidos
pelos possíveis clientes. Um destes exemplos foi uma aeronave turbo-propelida desenvolvida
pela empresa analisada, considerada uma das aeronaves mais modernas de seu tempo, com
tecnologia de ponta e que foi um fracasso comercial, sendo o projeto cancelado com a
fabricação de apenas dois protótipos. Note que mesmo nesse último caso, de aparente fracasso,
todo o aprendizado construído no desenvolvimento dessa aeronave foi fundamental para os
projetos que a sucederam, esses sim, grandes sucessos de engenharia e comercial. Da mesma
forma, já houve casos, em que projetos ultrapassaram o orçamento e os prazos, mas foram muito
bem sucedidos comercialmente. Pode-se ver que a questão do que é sucesso ou não, não é
trivial.
Diversos autores, como por exemplo, De Cotiis e Dyer (1979), Cooper e Kleinschimidt
(1987), Pinto e Slevin (1988) e Dvir e Shenhar (1992), buscam sumarizar os principais fatores
responsáveis pelo sucesso de um projeto. O resultado desta vasta literatura foi a definição
 27

moderna de sucesso, abordada no artigo “Mapping the dimensions of project success”

(SHENHAR et al.,1997).
Shenhar et al. (1997), a partir de uma revisão teórica extensiva, levantaram os fatores
que impactam o sucesso de um projeto e realizaram uma análise estatística. A análise trouxe
como resultado quatro principais dimensões responsáveis pelo sucesso de um projeto. São elas:
(1) eficiência do projeto, (2) impacto no consumidor, (3) sucesso no negócio e (4) preparação
para o futuro. A definição destas quatro dimensões é descrita nas linhas a seguir.
A eficiência do projeto é uma dimensão imediata, retrata o projeto durante sua execução
e logo após seu término, indicando a eficácia da gestão. Tem o propósito de indicar se o projeto
foi finalizado no tempo e no orçamento planejado. É a visão mais largamente adotada na
indústria.
Já o impacto no consumidor busca avaliar o sucesso do projeto a partir da medição
satisfação do cliente com o produto do projeto. O quanto ele realmente utiliza o produto e se as
vantagens percebidas pelo cliente o levariam a comprar novos produtos ou projetos daquela
empresa.
O sucesso no negócio retrata as margens de lucro, a entrada de receita, o número de
vendas, entre outros valores ligados à parte financeira.
Finalmente, a preparação para o futuro envolve o longo prazo. O que o projeto pode
contribuir com futuras oportunidades na empresa. Como exemplo: Se ele possui alguma
inovação que poderá ser utilizada pela empresa, em outros projetos, no futuro? Projetos como
o da aeronave que fracassou no mercado, mencionado na seção anterior, poderiam ser
entendidos como sucesso sob essa ótica, justamente por sua contribuição na preparação da
empresa para o futuro, mesmo não sendo a intensão inicial do projeto.
Cada uma das dimensões possui um grau de importância variável ao longo da vida tanto
do projeto, como de seus resultados. Esta variação temporal é demonstrada na Figura 3.

Figura 3 – Dependência temporal das dimensões de sucesso (SHENHAR et al., 1997).

 28

Kezner (2006), indo de encontro à abordagem de sucesso em projetos de Shenhar et al.

(1997), refere-se como melhor explicação de sucesso aquela que mensura o projeto em fatores
primários e secundários. Segundo o autor, os fatores primários são: prazo, orçamento e
qualidade e os fatores secundários são: aceitação do cliente e se o cliente tem a empresa como
referência. Inclui ainda como fatores secundários o sucesso financeiro, alinhamento estratégico,
conduta ética, reputação da empresa, saúde e segurança etc.
Para o autor, a definição absoluta de sucesso de um projeto será visualizada quando o
cliente estiver tão satisfeito com os resultados que permitirá a utilização de seu nome como
referência.
Jugdev e Müller (2005), através de uma análise retrospectiva sobre o tema sucesso em
projetos, retomando os últimos quarenta anos de literatura a respeito do assunto, também
apresentam, no artigo “A retrospective look at our evolving understanding of project success”,
que houveram mudanças nesta definição ao longo dos anos. O sucesso, antes limitado à fase de
implementação do ciclo de vida do projeto, passou a ser definido como um reflexo do sucesso
do ciclo de vida do projeto e do produto. Definições que eram focadas na restrição tripla, ou
seja, nas variáveis: tempo, custo e escopo, foram substituídas pela medida do sucesso através
do impacto do projeto na empresa como um todo.
Como exemplo, para afirmar a necessidade de mensurar o sucesso do projeto além da
restrição tripla, os autores citam a construção da casa de opera Sydney Opera House que levou
15 anos para ser construída, ultrapassou o orçamento em 14 vezes, mas, no entanto, é
orgulhosamente tida como uma obra-prima da engenharia.

2.1.3 Fracasso em Projetos

Conforme discutido brevemente na Introdução dessa dissertação, o fracasso em projetos

é algo ainda mais comum do que se imagina. De acordo com o PMSURVEY.ORG (2010), por
exemplo, um estudo de benchmark em gestão de projetos realizado com 460 empresas
brasileiras de diferentes ramos e tamanhos 78% das organizações em pesquisa, confirmaram ter
problemas no cumprimento dos prazos, 61% disseram não cumprir os custos acordados e 44%
julgaram ter problemas de qualidade em seus projetos.
Em uma pesquisa mais abrangente, no âmbito mundial, o grupo The Standish Group
International documenta a cada dois anos a porcentagem de projetos que foram bem sucedidos
(entregues no tempo, no custo, e com todas as funções e características acordadas), fracassados
(projetos cancelados durante a execução, ou que nunca tiveram seus resultados utilizados) ou
 29

foram desafiados (projetos que sofreram atraso, tiveram os custos acima do acordado, ou menos
características e funções do que contemplava o escopo) nas empresas pesquisadas. Na Tabela
3 é possível verificar os resultados obtidos pelo grupo no período que contempla o ano de 2004
a 2012.

Tabela 3 - Resultado de sucesso, falha e desafio em projetos.

Fonte: THE STANDISH GROUP, 2013.

Não muito diferente, a pesquisa PMI’S PULSE OF THE PROFESSION (2013),

divulgou que menos de dois terços dos projetos atendem seus objetivos e intenções de negócio,
e 17% falham completamente. Estes projetos fracassados geram gastos às empresas, sendo que
a cada 1 bilhão de dólares gastos nestes projetos, 135 milhões de dólares são perdidos para
sempre.
Dentre os principais problemas enfrentados pelas organizações, durante a execução de
um projeto, levantadas pela pesquisa PMSURVEY.ORG (2010) estão: o não cumprimento dos
prazos, mudanças não controladas de escopo ("scope creeping") e problemas de comunicação.
Na Tabela 4 são vistos os dezoito principais problemas elencados pela pesquisa, com a
porcentagem de empresas que os apresentaram no decorrer de seus projetos.

Tabela 4 – Problemas que ocorrem com mais frequência nos projetos da Organização.
Empresas que
Problemas elencados detectaram os
problemas (%)
Não cumprimento dos prazos 60,2
Mudanças de escopo constante 43,0
Problemas de comunicação 40,1
Escopo não definido adequadamente 39,5
Não cumprimento do orçamento 28,3
Recursos humanos insuficientes 28,3
Concorrência entre o dia-a-dia e o projeto na utilização de recursos 27,6
Riscos não avaliados corretamente 22,9
Mudanças de prioridade constante ou falta de prioridade 19,8
Problemas com fornecedores 17,7
 30

Empresas que
Problemas elencados detectaram os
problemas (%)
Estimativas incorretas ou sem fundamento 15,6
Retrabalho em função de falta de qualidade do produto 11,7
Falta de definição de responsabilidades 10,2
Falta de uma metodologia de apoio 7,5
Falta de apoio da alta administração/sponsor 7,3
Falta de competência para administrar projetos 6,9
Falta de uma ferramenta de apoio 6,7
Falta de conhecimento técnico sobre a área de atuação 2,1
Não temos problemas 1,3
Fonte: PMSURVEY.ORG, 2010.

No desenvolvimento tecnológico da empresa analisada, onde foi feito o caso de

aplicação reportado nessa dissertação, a situação não é muito diferente. Além de todas as
dificuldades envolvidas nos projetos comuns, os projetos de desenvolvimento de tecnologia
apresentam muitas incertezas, dificuldades de se obter um escopo, times pequenos e altamente
técnicos.
Isto nos leva a refletir sobre os métodos e ferramentas que estão sendo utilizados no
desenvolvimento de projetos. A maior parte deles, originários da década de 50, e desenvolvidos
pelo Departamento de Defesa norte-americano (DoD) (TAKEUCHI; NONAKA, 1986). Vários
pesquisadores entendem que os mesmos muitas vezes não são adequados à empresa, ao tipo de
projeto, ou mesmo ao mundo atual, onde as mudanças fazem parte do dia a dia de qualquer
negócio (TAKEUCHI; NONAKA, 1986; AMARAL et al., 2011; HIGHSMITH, 2004).

2.2 Projetos de Desenvolvimento de Produto x Projetos de Desenvolvimento

Tecnológico (Inovação Pré-Competitiva)

A diferenciação entre projetos de desenvolvimento de produtos e projetos de

desenvolvimento tecnológico pré-competitiva é relevante e descrita, por exemplo, em Araújo
(2012), Cooper (2007), e Ajamian e Koen (2002).
O desenvolvimento de produto pode ser entendido como um processo que irá
transformar uma ideia em um bem material, manufaturado, que será comercializado no mercado
ao qual se destina. Pugh (1996) divide o desenvolvimento de produtos em duas categorias,
design estático e design dinâmico.
 31

O design estático se refere a produtos convencionais, que possui conceitos já

consagrados e muitas vezes dominados, pela empresa ou parceiros responsáveis pelo projeto,
envolvendo um baixo grau de incerteza. Utilizam-se soluções que permanecem fixas no
decorrer do tempo, não sendo incomum, as empresas utilizarem partes de antigos projetos, em
um novo produto, ou até mesmo só realizam a atualização de um produto já consolidado no
mercado.
À medida que a empresa se firma neste mercado, ela cria um histórico de lições
aprendidas, que torna os projetos cada vez mais robustos. Quanto maior o aprendizado da
empresa, melhor será o processo de desenvolvimento futuro, pelo menos em teoria.
O design dinâmico se refere a produtos inovadores ou que envolvam alta tecnologia.
Estes projetos possuem alta complexidade, com elevado nível de incertezas e desafios.
Segundo Amaral et al. (2011), em projetos de produtos inovadores, “não há parâmetros
comparativos, e a equipe necessariamente será formada por pessoas inexperientes com o
produto. O problema a ser solucionado é pouco conhecido, dificultando a antecipação e o
estabelecimento prévio de estratégias, recursos e atividades necessários ao empreendimento”.
Soluções que parecem simples à primeira vista, podem se tornar muito complexas no decorrer
do projeto.
Na maioria das empresas modernas, projetos de novos produtos requerem uma análise
financeira e um business case para que seja analisada a viabilidade dos mesmos. É possível, na
maior parte dos casos, prever um mercado, calcular o valor percebido pelo cliente, como
também prever as vendas e as margens de lucro da empresa, assim servindo como subsidio para
a alta gerência tomar a decisão de investir no projeto.
O desenvolvimento tecnológico pré-competitivo se aproxima do conceito de produtos
inovadores, sendo, sempre, algo novo, diferente, inovador e imprevisível. Uma diferença
importante é que seu resultado não necessita ser um produto físico ou um sistema. Pode ser a
demonstração de uma possível tecnologia, uma capacidade técnica, ou até mesmo prova de um
conceito para um processo de manufatura.
Podemos fazer uma analogia à tecnologia touchscreen. Esta foi uma tecnologia
desenvolvida para atender a uma demanda de mercado. O resultado, do desenvolvimento
tecnológico, foi uma tela sensível ao toque do usuário. Mas a tecnologia só tem sentido quando
aplicada a um produto, como telefone celular, dispositivos de música, GPS, entre outros, sendo
que a interface entre a tecnologia e o produto é especifica para o caso em que foi aplicada.
Projetos de desenvolvimento de novas tecnologias são, por natureza, projetos de risco
elevado, incluindo, na maior parte das vezes, mais incógnitas e incertezas do projeto de
 32

produtos inovadores. Ainda assim são cruciais para o crescimento no longo prazo da empresa,
para sua prosperidade e sua sobrevivência (MATSUO, 2010).
As incertezas são principalmente provenientes da dificuldade de se constituir um escopo
de projeto bem definido no seu início. Isto se dá devido ao universo de uma nova tecnologia ser
imenso, e definir onde tal tecnologia poderá ser aplicada de maneira eficiente, sem deter certo
conhecimento sobre a mesma, é geralmente muito difícil.
Estas incertezas geram riscos técnicos a esses projetos, muitas vezes, maiores do que os
riscos aceitáveis pela empresa, principalmente considerando-se que a descoberta prometida pela
tecnologia pode nunca ocorrer. As características requeridas podem não ser encontradas, o
projeto pode esbarrar em barreiras científicas, limitações tecnológicas e descobertas
inesperadas podem mudar todo o escopo planejado. Consequentemente, mostrar a alta gerência
o retorno financeiro do investimento no início do projeto, quando as decisões são tomadas, não
é algo trivial.
Neste ambiente a gestão de projetos se torna complexa. Utilizar as ferramentas
destinadas a projetos de desenvolvimento de produto, nem sempre parece se mostrar adequado,
exatamente em função das características desses projetos, conforme descritas acima. Ao mesmo
tempo, é bastante escassa a literatura que aborde a gestão de projetos altamente técnicos, com
alto risco e alta incerteza como os projetos de desenvolvimento tecnológico.

2.3 Gestão de Projetos

O que é hoje entendido como Gerenciamento de Projetos (GP), segundo Kerzner (2009),
surgiu nos anos 50, principalmente para suportar projetos na área de defesa e espaço dos Estados
Unidos. Esta iniciativa culminou em um conjunto significativo de regras, processos e conceitos,
que passaram a fazer parte do dia a dia dos projetos em desenvolvimento.
Após décadas de evolução, duas teorias de gestão de projetos se destacam na atualidade:
a abordagem tradicional, também conhecida pelos processos bem definidos e as metodologias
empíricas ou ágeis, essas últimas bem mais recentes. Há também autores que destacam um
terceiro grupo, chamado de abordagem iterativa que corresponde à interface entre o ágil e o
tradicional (BECK, 1999).
Na abordagem tradicional todos os requisitos de projeto são definidos logo na etapa
inicial. A partir desses requisitos bem definidos é então formulado o escopo do projeto, e, na
sequência, os demais planos (comunicação, riscos etc.) que irão compor o plano integrado do
 33

projeto (PMI, 2013). Toda a gestão do projeto será guiada por esse conjunto de planos. Pela sua
natureza, essa abordagem é mais adequada a projetos em que os requisitos e as etapas
necessárias ao desenvolvimento do projeto são bem conhecidos desde o seu início, e não
sofrerão muita variação ao longo da sua vida (AMARAL et al., 2011). Entre os representantes
da teoria tradicional, o mais utilizado é o PMBOK, uma coletânea de práticas, técnicas e
ferramentas, resumidas em textos normativos sobre gestão de projetos (PMSURVEY.ORG,
2010; AMARAL et al., 2011).
A abordagem ágil, busca no dinamismo uma melhor forma de se adaptar às mudanças
necessárias durante o projeto, principalmente projetos que envolvem inovação. Segundo
Highsmith (2004), a agilidade é a “habilidade de criar e responder a mudanças, a fim de obter
lucro em ambiente de negócio turbulento. ” Essa abordagem é fundamentada na ideia de que, a
partir de pequenos ciclos iterativos e incrementais, é possível entregar uma função de produto
a cada etapa, e, sobretudo, alterar requisitos em iterações que ainda serão desenvolvidas. O
scrum é ainda o framework mais utilizado quando se fala em ágil (VERSIONONE.COM,
2013).
Os métodos ditos “iterativos” procuram dividir o projeto em várias etapas, porém mais
longas se comparado às iterações ágeis. O planejamento e desenvolvimento do projeto ocorrem
em ondas, onde somente a etapa atual é planejada no detalhe. Sobre as demais etapas tem-se
apenas uma visão macro (BECK, 1999).
Na Figura 4 demonstra-se, em resumo, estas diferentes metodologias.

Figura 4- Divisão das principais metodologias de gestão de projetos (BECK, 1999).

Cabe às empresas definirem a melhor abordagem, ágil, tradicional, iterativa, ou até

mesmo uma mistura das mesmas, que melhor se encaixe ao tipo de projeto em desenvolvimento.
 34

Nesta parte vale ressaltar, que mesmo definida a abordagem e o método a serem utilizados, é
necessário adequá-los às necessidades específicas do projeto.

2.4 Gestão Tradicional de Projetos

A teoria que vem sendo rotulada na literatura como teoria tradicional de gestão de
projetos é fundamentada nos “corpos de conhecimento” (BOKs – Body of knowlodge), que
surgiram ao final da década de 1990 (AMARAL et al., 2011; CONFORTO, 2009;
CARVALHO, 2011).
Estes BOKs são documentos, resumidos em textos normativos, que apresentam um
conjunto de práticas, técnicas e ferramentas, suportadas e revisadas continuamente por
associações de gerenciamento de projetos em todo o mundo (como exemplo PMI – Project
Management Institute, APM – Association for Project Management, AIPM – Australian
Institute of Project Management, IPMA - International Project Management Association)
(CONFORTO, 2009).
O guia mais conhecido é o PMBOK guide, desenvolvido pelo PMI. Ele aborda cinco
grupos de processos: iniciação, planejamento, execução, monitoramento e controle, e
encerramento (PMI, 2013), que totaliza o ciclo de vida do projeto, assim como explicitado na
Seção 2.1.1. Cada um destes grupos abrange dez áreas de conhecimento: integração, escopo,
tempo, custos, qualidade, recursos humanos, comunicações, riscos, aquisições e partes
interessadas (steakholders).
Apesar de sugerirem “o que deve ser feito”, os BOKs não descrevem o “como deve ser
feito”, ou seja, não são métodos. O gerente de projetos é o responsável por escolher a
metodologia de gestão que servirá como base para seu projeto e aplicar as boas práticas
conforme sua necessidade. A escolha do “como fazer” e quais práticas seguir poderá tornar a
gestão mais engessada ou flexível, ágil ou pesada.
Segundo Carvalho (2011) a ênfase da abordagem tradicional está no planejamento
cauteloso, disciplinado e em métodos de controle. Existe uma tendência a manter os requisitos
congelados até o final do projeto, sendo que alterações só podem ser realizadas mediante a
processos formais.
As fases do projeto são bem delineadas, a divisão de atividades é bem clara e as tarefas
são completadas de forma ordenada e sequencial, o que requer um planejamento antecipado e
detalhado. A comunicação é baseada em documentação, gerada durante todo o projeto.
 35

A participação do cliente se dá principalmente nas fases iniciais e de levantamento de

requisitos para auxiliar na concepção do cronograma de atividades, pontos de controle e
procedimentos que auxiliem os desenvolvedores a cumprir com resultado esperado.
O gerente de projetos possui um papel de grande importância na equipe, centraliza as
grandes decisões e é o responsável por garantir o sucesso do projeto.
Em resumo, gestão tradicional possui foco nas práticas e procedimentos para alcançar
os objetivos inicialmente acordados no projeto. O projeto só faz sentido quando é entregue em
sua totalidade, ou seja, o cliente só percebe algum valor, quando 100% do projeto estão
concluídos.

2.5 Teoria das Restrições

Partindo do mesmo princípio da gestão de projetos tradicional, onde os requisitos são

estabelecidos na fase inicial do projeto, com a forte participação do cliente, Goldratt foi além e
propôs uma teoria, chamada de teoria das restrições (TOC - Theory of Constraints), com o
objetivo de visualizar a empresa não em partes isoladas, mas como um sistema integrado
(BARCAUI; QUELLHAS, 2004).
O autor foi de encontro com o modelo tradicional utilizado pelas empresas no mundo,
onde a otimização da produção se dava, considerando o aumento da eficiência local (máquinas
e/ou setores isoladamente) e propôs que: “... a soma dos ótimos locais não é igual ao ótimo
total. ” (GOLDRATT apud GUERREIRO et al., 1996 P.11).
Segundo Goldratt, a organização vive e morre como um sistema e qualquer sistema é
análogo a uma corrente, ou uma rede de correntes. Assim, o desempenho do sistema será sempre
limitado pelo elo mais fraco. Isso significa que não importa a quantidade de esforços e/ou
recursos despendidos numa organização para melhoria dos processos, somente uma melhoria
do seu elo mais fraco poderá proporcionar uma melhoria ao sistema. O elo fraco é a restrição
do sistema (DETTMER, 1997).
Guerreiro et al. (1996, p. 11) concatena os nove princípios relativos a teoria das
restrições, que foram estabelecidos por Goldratt inicialmente, são eles:

1) “Balancear o fluxo e não a capacidade;

2) O nível de utilização de um recurso não gargalo não é determinado pelo seu
próprio potencial e sim por outra restrição de sistema;
3) A utilização e ativação de recurso não são sinônimos;
 36

4) Uma hora perdida no gargalo é uma hora perdida no sistema inteiro;

5) Uma hora economizada onde não é gargalo é apenas uma ilusão;
6) Os gargalos governam o ganho e o inventário;
7) O lote de transferência não pode e muitas vezes não deve ser igual ao lote de
processamento.
8) O lote de processamento deve ser variável e não fixo.
9) Os programas devem ser estabelecidos considerando todos as restrições
simultaneamente”.
A teoria das restrições, segundo Barcaui e Quellhas (2004), pode ser aplicada para as
mais diversas soluções, entre elas: desenvolvimento de produtos, gerenciamento de projetos,
cadeia de suprimentos e contabilidade.
Quando aplicada ao ambiente de gestão de projetos, a TOC passa a ser conhecida por
corrente crítica ou CCPM (Critical Chain Project Management).

2.5.1 Corrente Crítica (CCPM)

A corrente crítica é uma abordagem gerencial que se utiliza do gráfico sequencial e

priorizado de entregas que devem ser realizadas para que o projeto como um todo seja
concluído. Neste gráfico, também conhecido como gráfico Gantt3, são mapeadas todas as
entregas e precedências, a duração estimada de cada atividade resumindo-se em um cronograma
de projeto.
Após a confecção do cronograma do projeto é mapeado o caminho crítico, ou seja, a
sequência de atividades que se não for realizada conforme acordado, impactará no prazo de
entrega do projeto como um todo. Vale salientar que o caminho crítico pode variar ao longo do
projeto devido aos desvios ocorridos durante sua execução, sendo que atividades antes críticas
podem mais não estar na corrente crítica geral do projeto.
Com a corrente crítica mapeada, o foco passa a ser na melhoria de desempenho do
projeto, para tanto a teoria CCPM propõe soluções para os principais conflitos em gestão de
projetos, de forma a otimizar o cronograma inicialmente proposto. Como exemplo de conflito
em gerenciamento do tempo nos projetos, segue a Figura 5.

3
O diagrama de Gantt é uma representação gráfica do cronograma. Nele é possível verificar a duração das atividades, a precedência, além do
início e do término de cada atividade atividades. Seu intuito inicial era controlar a produção tendo um planejamento da atividade e quando elas
aconteceriam (WILSON, 2003).
 37

Figura 5- Exemplo do conflito de gerenciamento de tempo em projetos (BARCAUI;

QUELLHAS, 2004).

Como é possível verificar na Figura 5 para diminuir a duração de um projeto é

necessário manter o compromisso das entregas, o que nos leva a incluir em cada uma das tarefas
um tempo maior do que o necessário para sua realização, no sentido de garantir que a mesma
será realizada no tempo acordado. Por outro lado, para reduzir o tempo total dos projetos, ou
seja, reduzir a duração do caminho crítico, é necessário estimar de forma correta a duração de
cada tarefa, assim o tempo total estimado do projeto será um tempo mais compatível com a
realidade.
A corrente crítica quebra este paradigma de que o melhor lugar para inserir uma margem
de segurança de tempo, em um projeto, seja em cada tarefa de forma individual e propõe a
utilização de buffer, “pulmões”, ao final do projeto para absorver todos os possíveis desvios.
Paralelamente, partindo do princípio que existe uma tendência de as pessoas superestimam o
tempo real necessário para executar as tarefas, os tempos estimados inicialmente são reduzidos
em quase 50%, chegando ao ponto onde as pessoas acreditam que seja uma estimativa agressiva
da tarefa.
Em geral, metade da diferença entre o tempo inicialmente estimado e o tempo reduzido
após a aplicação da corrente crítica é igual ao tempo de buffer inserido ao final do projeto. O
consumo deste pulmão, realizado por atrasos no caminho crítico do projeto, passa a ser
acompanhado pelo gráfico chamado de fever chart (Figura 6) onde a faixa verde indica que o
projeto está indo de acordo com o planejado, o faixa amarela mostra que o projeto tem tendência
a atraso e a faixa vermelha aponta para atraso do projeto.
 38

Figura 6- Fever Chart (ATREYA, 2012).

A partir da análise deste gráfico, o gerente de projetos pode atuar de forma a corrigir os
desvios do caminho crítico e voltar com o projeto para a faixa verde, assim cumprindo o
cronograma inicialmente proposto.
Ainda, para diminuir os desperdícios de tempo, a corrente crítica busca reduzir de forma
significativa a execução de multitarefas durante o projeto, que gastam maior tempo se
comparada à execução sequencial. Para todo caminho não crítico do projeto, é considerado o
início da atividade na data mais tarde de início (late start date), o que reduz impactos de
mudanças realizadas nos trabalhos já executado, diminui o WIP e evita multitarefas.
Esta teoria tem sido cada vez mais utilizada dentro das organizações para otimizar
processos, minimizar seus custos, aumentar sua produtividade e se tornarem mais competitivas
no mercado cada vez mais competitivo e sem fronteiras (BARCAUI; QUELLHAS, 2004).

2.6 Gestão Ágil de Projetos

A história do surgimento do desenvolvimento ágil é tratada por Larman e Basili (2003).

Segundo o artigo publicado pelos autores, a base das metodologias ágeis é o desenvolvimento
de projetos iterativo e incremental IID aplicado à engenharia de hardware desde a década de
30. Seu precursor foi Walter Shewhart, um especialista de qualidade dos laboratórios Bell,
 39

seguido de Edward Deming, um estatístico, que começou a promover o Plan-Do-Study-Act

como componente vital da engenharia empírica. Entre os primeiros adeptos do método de
Deming estiveram o DoD, NASA e a indústria japonesa.
Na década de 50, diversos desenvolvedores de software passaram a utilizar o IID
empregando alguns dos conceitos que hoje são aplicados nas metodologias ágeis. Mas esta
iniciativa não foi vista como um possível padrão a ser seguido devido ao contexto da época.
Um mundo de sistemas dominados pela linguagem COBOL, por projetos complexos e grandes
arquivos que seguiam como regra o desenvolvimento tradicional. Desenvolvimento este,
utilizado como padão pelo DoD e influênciado principalmente pelos contratos a preço fixo
(LARMAN; BASILI, 2003).
No dercorrer dos anos foi visto que a busca pelo detalhamento de todo o escopo logo na
etapa inicial era muito difícil, devido a grande incerteza que se tem a respeito do projeto. A
necessidade de mudanças durante a execução resultava em atrasos de entrega, maior custo e
resultados muitas vezes desastrosos.
O autor Brooks Jr. (2010, p. 30), no livro “O projeto do projeto”, cita um texto de G.
Pahl e W. Beitz, dois especialistas em projetos de engenharia: “Qualquer tentativa de formular
todos os requisitos possíveis no início de um projeto falhará e causará atrasos consideráveis. ”
E conclui:
“A pressão por um conjunto de requisitos completo e acordado, em última instância,
do desejo - com frequência, uma demanda institucional – por um contrato de preço
fixo para uma entrega específica. Ainda assim, esta demanda está baseada
frontalmente na evidência concreta de que é essencialmente impossível especificar
qualquer conjunto completo e preciso de requisitos para qualquer sistema complexo,
a não ser através da iteração iterativa com o processo de modelagem. ”
Outro exemplo é descrito por um dos desenvolvedores da metodologia scrum, Jeff
Sutherland: “Um processo rígido ou resistente a mudanças produz produtos medíocres. Os
clientes podem até receber o que eles solicitaram primeiramente, mas é esse o produto que eles
realmente querem logo quando eles o recebem? Coletando todos os requisitos no início e
escrevendo-os sobre pedra, o produto é condenado a ser tão bom quanto a ideia inicial, ao invés
de ser o melhor uma vez que as pessoas aprendem ou descobrem como fazer melhor. ”
Nesta mesma linha, em 1976, Tom Gilb, lançou a idéia de um método de
desenvolvimento de software iterativo, em seu livro “Software Metrics”. Segundo ele, este
método era mais ágil, mais leve, mais adaptativo e mostrava o produto mais rapidamente ao
cliente, sugerindo a entrega de um software superior aos que utilizavam o modelo tradicional
(LARMAN; BASILI, 2003).
 40

À medida que o tempo passou, o grau de maturidade da engenharia de software foi

crescendo e o IID passou a ter uma maior aceitação, ganhando algumas variantes como: a
prototipagem rápida, o RAD (Rapid Application Development) e o RUP (Rational Unified
Process).
Na década de 90 várias empresas grandes começaram a desenvolver, dentro do
departamento de tecnologia da informação, os seus próprios métodos baseados no IID e assim
começaram a proliferar os métodos ágeis, desenvolvidos especialmente para o desenvolvimento
de software. Como por exemplo, a Crysler Corporation em 1996 desenvolveu o XP (Extreme
Programming) e o United Overseas Bank de Sigrapura desenvolveu o FDD (Feature Driven
Development).
Com todas as derivações do IID que foram surgindo, verificou-se a necessidade de
comparação e cooperação entre os desenvolvedores para a evolução da metodologia ágil como
um todo. Assim sendo, em fevereiro de 2001, dezessete pessoas, que trabalhavam com os até
então chamados métodos leves de desenvolvimento de software, se reuniram em uma estação
de esqui no estado norte americano de Utah para conversarem sobre o que estavam fazendo e
encontrarem pontos em comum (BROAD, 2013).
Deste encontro surgiu o termo ágil, sugerido por Martin Fowler, para descrever aquilo
que estavam discutindo. Formou-se a Agile Alliance, uma organização sem fins lucrativos com
o objetivo de promover a adoção de métodos ágeis e também surgiu o Manifesto Ágil que
documentou os princípios, os valores e firmou os conceitos para o desenvolvimento ágil.
Os quatro principais valores descritos no Manifesto são (BECK et al., 2001):
 Indivíduos e iterações são mais importantes que processos e ferramentas.
 Software em funcionamento é mais importante que documentação abrangente.
 Colaboração com o cliente é mais importante que negociação de contratos.
 Responder a mudanças é mais importante que seguir um plano.
Os doze princípios pregados no Manifesto para auxiliar as pessoas a seguirem os
conceitos ágeis (BECK et al., 2001), são descritos a seguir:
1. Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de
software com valor agregado.
2. 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.
 41

3. Entregar frequentemente software funcionando, de poucas semanas a poucos meses,

com preferência à menor escala de tempo.
4. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por
todo o projeto.
5. 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.
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.
7. Software funcionando é a medida primária de progresso.
8. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores,
desenvolvedores e usuários devem ser capazes de manter um ritmo constante
indefinidamente.
9. Contínua atenção a excelência técnica e bom design aumenta a agilidade.
10. Simplicidade--a arte de maximizar a quantidade de trabalho não realizado--é essencial.
11. As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.
12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina
e ajusta seu comportamento de acordo.
Basicamente, os autores afirmam a importância de valorizar os indivíduos, interações,
produtos funcionais, equipes auto-organizadas e colaborativas em detrimento de processos,
planos e controles burocráticos.

2.7 Diferenças entre Gestão Ágil e Tradicional

A literatura de gestão de projetos, como exemplo descrito em Faria (2013), aborda a

existência da restrição tripla no gerenciamento de projeto, ou seja, as restrições de recurso,
tempo e escopo. Segundo o autor, existe um equilíbrio entre estas três necessidades conflitantes
dentro do projeto. Este equilíbrio é estabelecido no momento em que as partes envolvidas no
projeto chegam a um acordo sobre o tempo necessário, o escopo a ser seguido e o custo do
projeto. A partir deste ponto, qualquer mudança em uma das dimensões, afeta pelo menos uma
das outras duas dimensões (MARTINS, 2007).
Na metodologia tradicional, o escopo é fixado logo no início do projeto e acordados
entre as partes. Sendo o tempo e o custo um reflexo deste escopo. A partir do momento em que
o escopo muda durante o projeto, tem-se a alteração do tempo, ou do custo, ou de ambos.
 42

Os métodos ágeis, diferentemente, fixam, no início do projeto, os recursos e o tempo, e

consequentemente obtêm-se o escopo do projeto. A vantagem que esta abordagem traz é poder
alterar o escopo, desde que sejam mantidos os recursos e o tempo, sem que o custo do projeto
seja alterado. O custo passa a ser influenciado somente pelos recursos e pelo tempo, e não mais
pelo escopo (Figura 7).

Figura 7- Abordagem tradicional x ágil (FARIA, 2013).

Highsmith (2004) aborda o triângulo de ferro ágil de forma que o tempo é fixo, e o custo
e/ou escopo do projeto podem variar. Ele vai além, e propõe um terceiro triângulo, o triângulo
ágil (Figura 8). Segundo o autor, quando se fala em ágil, não faz sentido atrelar simplesmente
o escopo como resultado de sucesso do projeto.
O triangulo ágil utiliza como referência o valor (valor entregue ao cliente), qualidade
(requerida para entregar, constantemente, valor ao cliente), e as restrições (escopo, tempo e
custo). Para o autor, as restrições ainda são importantes para o projeto, mas não devem ser o
foco, que seria sempre a entrega de valor ao cliente.

Figura 8- Abordagem tradicional x ágil (HIGHSMITH, 2004).

 43

Para resumir o triângulo ágil:

 Objetivo do Valor: desenvolver um produto que será utilizado.
 Objetivo da Qualidade: desenvolver um produto adaptável confiável.
 Objetivo da Restrição: atingir o valor e metas de qualidade, dentro das restrições
aceitáveis.
Amaral et al. (2011), somando ao estudo realizado por Faria (2013), Highsmith (2004)
e Martins (2007), propõe quatro diferenciais, que segundo os autores, são os mais significativos,
em relação à teoria de gerenciamento ágil. São eles: autogestão, visão, iteração e envolvimento
com o cliente.
A autogestão está ligada ao envolvimento dos membros da equipe nas atividades de
controle e planejamento do projeto. A visão tem o papel de descrever o contorno, ou seja, os
resultados que o projeto precisa atingir, para satisfazer os stakeholders. A iteração é relativa a
ciclos rápidos de construção, teste e validação. Por fim, o envolvimento com o cliente, que
participa de forma enérgica, do desenvolvimento do projeto.
Assim como os autores destacados, tantos outros buscam definir as principais diferenças
entre as duas abordagens, ágil e tradicional. Shenhar e Devir (2007) conseguem definir de forma
bastante clara, na Tabela 5, esta diferença abordando o modelo tradicional e o chamado de
adaptável, pelos autores, enfatizando principalmente, a participação do cliente durante o
desenvolvimento do projeto. Segundo Amaral et al. (2011): “estamos assistindo ao surgimento
da ideia do cliente como “projetista”, liderando o desenvolvimento por meio de técnicas de
iteração via web e toolkits.”

Tabela 5-Diferenças entre o tradicional e o ágil.

Abordagem Tradicional Adaptável

Enfoque na finalização do projeto Enfoque nos resultados do negócio,
Metas do no tempo, custo e requisito de atingir múltiplos critérios de sucesso.
Projeto qualidade.
Uma coleção de atividades Uma organização e processo para
Plano do executadas como planejamento atingir as metas esperadas e os
Projeto para atender à restrição tripla resultados para o negócio.
(tempo, custo e qualidade).
Realizado uma vez no início do Realizado no início e reavaliado
Planejamento
projeto. sempre que necessário
Abordagem Rígida, com foco no plano inicial. Flexível, variável, adaptável.
Gerencial
Trabalho/ Previsível, mensurável, linear, Imprevisível, não mensurável, não
Execução simples. linear, complexo.
 44

Abordagem Tradicional Adaptável

Identificar desvios do plano inicial Identificar mudanças no ambiente e
Controle do
e corrigir, o trabalho, para seguir o ajustar o plano adequadamente.
Projeto
plano.
Influência da Mínima, imparcial a partir do kick- Afeta o projeto ao longo de sua
Organização off do projeto. execução.
Aplicação da Aplicação genérica e igualitária em Adaptação do processo, dependendo
Metodologia todos os projetos. do tipo de projeto.
Um modelo atende a todos os tipos Abordagem adaptativa, um único
Estilo de
de projetos. modelo não atende a todos os tipos de
Gerenciamento
projetos.
Fonte: Adaptado de SHENHAR; DVIR, 2007 (Apud AMARAL et al., 2011).

2.8 Limites da Gestão Ágil

“A gestão ágil preza por seus princípios e valores que devem ser seguidos à risca para
tirar o maior proveito dos métodos. Por isto é de extrema importância que a filosofia ágil seja
adotada e compreendida por todos na empresa, e principalmente suportadas pela alta gerência”
(BROAD,2013).
Adotar os conceitos ágeis significa deixar de lado algumas características do
desenvolvimento de projetos tradicional, o que muitas vezes pode entrar em frontal conflito
com o que é praticado na maior parte das empresas.
Não ter um prazo, ou mesmo um custo pré-estabelecido, para o projeto como um todo,
pode trazer um grande desconforto para os clientes, uma vez que há a necessidade de se planejar
financeiramente. Ao mesmo tempo se levarmos em conta que 60,2% dos projetos extrapolam
o prazo, 28% os custos (PMSURVEY.ORG, 2010) e a taxa de falha é de 18% (THE
STANDISH GROUP, 2013), verificamos a dificuldade, que existe, em prever o tempo e o custo
de um projeto, mesmo prevendo, inicialmente, um buffer.
A vantagem que o desenvolvimento ágil leva para o cliente neste cenário é a visibilidade
do projeto a cada mês a partir dos feedbacks. Caso o cliente não esteja satisfeito com o
desenvolvimento da equipe pode facilmente cancelar o projeto. O cliente também pode fechar
um contrato no qual paga somente pelo trabalho realizado pela equipe e não por um valor
resultante de uma projeção de custos, realizada no início do projeto.
Outra característica do desenvolvimento de projetos tradicional é a tentativa de se obter
todas as funcionalidades do projeto especificadas no contrato firmado, assim sendo respaldados
pela lei, caso algo fuja do controle. Esta vontade se torna equivocada se levarmos em conta o
estudo publicado pelo Standish Group (2013) que mostra que, apenas 20% dos requisitos
 45

iniciais de um sistema são utilizados com frequência e que 50% destes requisitos nunca, ou
quase nunca, serão utilizados pelos consumidores. Mas, para se ter um contrato aberto, a
confiança entre cliente e fornecedor tem que ser muito forte e baseada em um histórico positivo.
Outro fato relevante é a participação do cliente durante o desenvolvimento do projeto.
O ágil fala em um cliente participativo e ativo no projeto, sendo igualmente responsável pelos
resultados obtidos. Isto pode ser um empecilho, uma vez que ele necessitará se deslocar e
participar das reuniões. Muitos projetos ocorrem em parcerias com empresas internacionais, o
que dificulta esta mobilidade frequente. Ao mesmo tempo na indústria, se vê a necessidade de
acompanhamento dos projetos, para se certificar de que tudo esteja sendo feito conforme o
contrato e não haja surpresas no final.
A mudança frequente de membros da equipe também pode ser um desafio enfrentado
pela empresa. O desenvolvimento ágil pressupõe equipes de alto desempenho, que realizam um
trabalho cooperado, integrado e priorizado. A sincronia da equipe e principalmente as lições
aprendidas durante as interações é primordial para que o time atinja o alto desemprenho.
Vale salientar que os métodos ágeis não são antagônicos aos modelos tradicionais de
gestão e desenvolvimento de projetos. Eles apenas buscam uma melhoria de processo através
da agilidade, com execução iterativa e incremental, com maior colaboração do time de
desenvolvimento e foco no valor entregue ao cliente.
Segundo Amaral et al. (2011), a abordagem ágil não rompe totalmente com a teoria
tradicional. Os autores defendem que a filosofia ágil se soma ao modelo tradicional, e deve ser
utilizado de forma a manter um equilíbrio entre os diferentes tipos de práticas, conforme as
características intrínsecas do projeto. Esta opção também é corroborada por Boehm e Turner
(2004), Chin (2004) e Shenhar E Dvir (2007).
Cruz (2013) vai mais além, não só defende um equilíbrio entre o ágil e o tradicional,
mas sim uma união entre as duas teorias. O autor propõe um modelo de gestão de projetos em
que framework scrum é a base da gestão e os grupos de processos sugeridos no guia PMBOK,
são inseridos no ciclo de vida scrum do projeto. O motivo que levou o autor a realizar esta união
foi “tirar vantagem dos pontos positivos de ambos os modelos, e balancear os pontos negativos
de um com as qualidades do outro”, a fim de proporcionar maior possibilidade de obter sucesso
ao projeto.
 46

2.9 Diferentes Métodos de Gestão de Projetos Ágeis

No decorrer dos anos, diversos métodos classificados como ágeis foram surgindo e
ficaram à disposição das equipes de desenvolvimento. Todos partem do princípio de que é
impossível seguir um plano de projetos à risca. Mudanças acontecem o tempo todo durante a
execução, e a melhor forma de atacar este problema, diminuindo os custos e aumentando a
qualidade, é a partir de ciclos iterativos curtos, feedbacks constantes, interação forte com o
cliente e equipe (HIGHSMITH; COCKBURN, 2001).
Dentre as teorias, mais desenvolvidas e aplicadas, estão aquelas ligadas ao
desenvolvimento de software. Estas teorias são bastante objetivas e direcionam sua aplicação
ao projeto de tais produtos. Possuem precisas especificações e recomendações para o
desenvolvimento do projeto. Alguns autores, às denominam como “Programação Ágil” numa
alusão à engenharia de software e à gestão de projetos (AMARAL et al., 2011).
Na Figura 9 é possível verificar o resultado de uma pesquisa realizada pela
VERSIONONE.COM (2013), sobre a utilização destes diferentes métodos ágeis nas diversas
empresas pesquisadas. Os métodos mais utilizados são o scrum e suas variantes, seguidos pelo
kanban e suas variantes.

Figura 9- Porcentagem de utilização dos diferentes métodos ágeis (VERSIONONE.COM,

2013).
 47

Baseado nesta pesquisa, este trabalho em questão irá abordar os cinco principais
métodos ágeis, não híbridos ou customizados, utilizados na atualidade, SCRUM, XP, LEAN,
FDD e KANBAN. Excluiu-se da lista, de forma proposital, os métodos SCRUM/XP HYBRID,
CUSTOM HYBRID e SCRUMBAN para que fosse analisado cada método atuando de forma
separada.
Apesar de estes métodos serem desenvolvidos para aplicação no ambiente de software,
eles são uma boa referência, inicial, para aplicação dos conceitos ágeis na prática. Com este
intuito, o objetivo é verificar os pontos em comum e as especificidades de cada um deles,
compará-los e utilizar estes conceitos no desenvolvimento tecnológico.
Nas próximas seções, serão detalhadas as peculiaridades de cada um destes métodos,
finalizando com uma tabela comparativa.

2.9.1 SCRUM

A metodologia scrum foi abordada pela primeira vez em um estudo, realizado por
Takeuchi e Nonaka (1986) intitulado “The New New Product Development Game”, no qual os
autores abordaram a necessidade, já naquela época, de um desenvolvimento de produtos mais
flexível, onde os times de desenvolvimento deveriam atuar como uma unidade a fim de atingir
um objetivo comum.
Os autores pesquisaram empresas americanas e japonesas que obtiveram sucesso ao
mudar a forma de desenvolver produtos, e correlacionaram o estudo com jogadas de rúgbi,
mostrando que para se atingir o objetivo é necessária a participação de todos do time atuando
em conjunto.
Baseado neste estudo, Jeff Sutherland, juntamente com seu time, deu início a utilização
do scrum em 1993 na empresa Easel Corporation. Neste mesmo período, Sutherland começou
a trabalhar com Ken Schwaber, CEO da Advanced Development Methods, para formalizar uma
metodologia de gestão de projetos (SUTHERLAND, 2004).
Em 1995, na OOPSLA’95, Schwaber e Sutherland fizeram a primeira apresentação do
scrum a público, o que culminou na publicação do artigo “Scrum Development Process” em
1997 (SCHWABER, 1997). Desde então o framework vem sendo aprimorado por diversos
autores e utilizado por várias pessoas no mundo.
 48

2.9.1.1 Framework SCRUM

O scrum é tratado na literatura por diversos autores, porém, neste trabalho será tomado
como base o guia scrum, desenvolvido e atualizado por seus criadores, Schwaber e Sutherland
(2013), principais nomes relativos ao framework.
O scrum é uma estrutura processual (framework), dentro da qual, pessoas podem tratar
e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam
produtos com o mais alto valor possível (SCHWABER e SUTHERLAND, 2013).
Ele é sustentado por três pilares: transparência, inspeção e adaptação. A transparência
garante que os aspectos que afetam o resultado sejam visíveis e conhecidos por aqueles que
controlam o resultado. A inspeção determina que os processos devam ser inspecionados com
frequência, para que variações sejam detectadas. E a adaptação sugere ajustes rápidos, a
qualquer variação fora dos limites aceitáveis, que forem detectadas nas inspeções.
O framework consiste em Equipes Scrum associadas a seus papeis, eventos, artefatos e
regras. Cada um deles tem um propósito e são vitais para o sucesso do modelo. Na Figura 10
tem-se uma visão geral do mesmo.

Figura 10- Visão geral do Scrum (BRAZ, 2013).

2.9.1.2 Equipe Scrum

A Equipe Scrum é constituída pelo time de desenvolvimento, o Scrum Master e o

Product Owner.
 49

O time de desenvolvimento é a parte responsável por transformar o backlog do produto,

ou seja, lista de entregas a realizar, em incremento de funcionalidades a cada iteração. O scrum
preza por um time auto-gerenciável, auto-organizado e multidisciplinar. O próprio time é
responsável por transformar os requisitos em um produto utilizável. Não há hierarquia e nem
especialização em uma Equipe Scrum, todos são responsáveis pelo produto final.
O time de desenvolvimento deve ter um tamanho tal, que seja pequeno o suficiente para
manter a agilidade e grande o suficiente para realização do trabalho. Na literatura fala-se em
um número de três a nove pessoas (SCHWABER; SUTHERLAND, 2103).
O Scrum Master tem um papel fundamental no time de desenvolvimento, sendo o
responsável por garantir que os valores do scrum sejam seguidos por todo o time. É ele quem
assegura os eventos, artefatos e regras do framework, além de remover qualquer obstáculo que
impeça o trabalho da equipe de desenvolvimento.
O Product Owner, ou dono do produto, é a voz do cliente na equipe. Ele é responsável
pela gestão do backlog do Produto, e por garantir o valor do trabalho realizado. É ele quem
deve priorizar os itens na lista de entregas a realizar, além de defender, o time de
desenvolvimento, de influências externas ao produto.

2.9.1.3 Eventos do Scrum

O scrum possui como evento principal o sprint, e como eventos secundários, as

cerimônias que são realizadas durante o sprint. Estas cerimônias são representadas pelas
reuniões: de planejamento, diária, de revisão e de retrospectiva. Todos estes eventos são time-
boxed, ou seja, possuem uma duração máxima e fixa, para garantir que não seja gasto tempo
excessivo com o planejamento.
O sprint é o ciclo incremental de trabalho do scrum. Possui a duração de uma iteração,
com metas e objetivos claros, e bem definidos. É durante o sprint que a equipe de projetos
trabalha transformando o backlog em funcionalidades, a ser anexada no produto final. Os
sprints devem ter uma mesma duração, limitados a um mês corrido. A cada final de um sprint,
outro é iniciado, e durante o sprint não são realizadas mudanças de objetivo e nem na
composição da equipe.
A reunião de planejamento é executada no começo de cada sprint, e é responsável pelo
planejamento de toda a iteração. Para um sprint de quatro semanas, estima-se uma duração
máxima de 8 horas de reunião. Para sprints menores, a duração deve ser proporcional a
2h/semana.
 50

Nesta reunião, com a presença do Product Owner, Scrum Master e do time de

desenvolvimento, devem ser discutidos e avaliados os resultados disponíveis, e quais os pontos
do backlog do produto serão atendidos no sprint corrente. Como resultado ter-se-á o objetivo
do sprint e o sprintbacklog, lista de entregas a serem realizadas dentro de uma mesma interação.
A cada entrega, do backlog, será elencada a definição de “pronto”, acordada por todos
da equipe. Vale ressaltar que a equipe é fundamental na hora da definição de quais entregas
farão parte do sprint, e o que se espera de cada uma delas.
A reunião diária tem o objetivo de deixar todos os membros da equipe a par do
andamento das atividades. Ela deve ter uma duração de 15 a 30 minutos e abordar três
perguntas:
 O que você fez ontem?
 O que fará hoje?
 Quais os obstáculos impedem ou podem impedir o seu trabalho?
A revisão do sprint é executada ao final de cada sprint. Tem como objetivo inspecionar
o incremento e adaptar o backlog do produto se necessário. O Product Owner confere as
atividades dando o aceite final. Estima-se duração, de reunião, máxima de 4 horas, para um
sprint de quatro semanas, ou seja, 1h/semana.
A retrospectiva do sprint é a atividade que encerra o Sprint. É uma oportunidade de o
time scrum inspecionar como foi o andamento daquele ciclo e propor possíveis melhoras para
a próxima interação.

2.9.1.4 Artefatos do Scrum

Os artefatos do scrum têm a função de transparecer as informações para que o time

scrum tenha sucesso nas suas entregas. Serve para o monitoramento e controle das atividades,
durante as interações, e também para futura análise de desempenho da equipe. São eles: O
backlog de produto e de sprint, o burndownchart, e o monitoramento do processo da sprint
(quadro scrum) (BROAD, 2013). Todos eles ficam visíveis em um quadro como mostrado na
Figura 11.
O backlog de produto é uma lista com todas as funções, características, requisitos,
melhorias e correções que se deseja no produto. Ele nunca está completo, evolui à medida que
se conhece o produto e verificam-se novas necessidades para torna-lo mais aprimorado,
competitivo e útil. É de responsabilidade do Product Owner, manter o backlog estruturado,
organizado e definir a prioridade de cada elemento na lista.
 51

Figura 11- Quadro Scrum (DE CASTRO, 2009).

O backlog do sprint é um conjunto de itens do backlog do produto selecionados para o

sprint corrente. O time juntamente com o Product Owner seleciona as funções a serem
desenvolvidas e às dividem em entregas. Estas entregas, juntamente com a definição de
“pronto” de cada uma delas, irá compor o backlog, e no quadro do scrum ocuparão a coluna
“to do”.
O gráfico burndown chart é utilizado para acompanhar as entregas realizadas pela
equipe. Nele é possível verificar a linha idealizada de entregas, comparada à linha real de
entregas realizadas, em um gráfico que correlaciona o número de entregas faltantes, com o
tempo.
O quadro scrum contempla o acompanhamento das entregas durante a iteração. Nele é
possível verificar quais entregas faltam realizar, as que estão em andamento e as entregas que
já foram concluídas. Há também um espaço para itens não planejados e para itens impedidos,
que devem ser gerenciados pelo Scrum Master.

2.9.2 Extreme Programming (XP)

O Extreme Programming, ou programação extrema, surgiu a partir de um estudo

realizado por Kent Beck em 1990. Ele observou que o custo de desenvolvimento de software
 52

estava mais ligado ao custo das pessoas do que do hardware, ou das licenças empregadas
(BROAD, 2013). Percebeu que era necessário envolver o cliente final (usuário) no processo de
desenvolvimento, e fazer os programas tão claros quanto possível para que qualquer pessoa
pudesse ler.
Beck então desenvolveu a metodologia XP baseado em quatro valores básicos:
comunicação, simplicidade, realimentação e coragem. Em 1996 aplicou pela primeira vez o
método em um projeto chamado Chrysler Comprehensive Compesation (C3), na empresa
Daimler Crysler (LARMAN; BASILI 2003).
Desde então, o XP vem se desenvolvendo e ganhando vários adeptos pelo mundo. Entre
as grandes empresas que adotaram este método no desenvolvimento de software e obtiveram
sucesso estão a Ford, BMW, Borland e a Symantec.

2.9.2.1 Práticas do XP

O XP possui doze práticas baseadas nos valores e princípios que permeiam o método.
Todas as práticas devem ser utilizadas coletivamente, de forma a reduzir as fraquezas umas das
outras, e trazer os benefícios do XP. As doze práticas serão descritas em sequência de forma
resumida (BECK, 2000).
O jogo do planejamento consiste na formulação de user stories, breves descrições das
funcionalidades requeridas, pelo cliente, no produto final. A partir da priorização, realizada pelo
próprio usuário, o programador, baseado nas descrições, estima a duração de cada estória e
planeja a iteração corrente. Um conjunto de funcionalidades, que representa uma pequena
versão do sistema, com recursos relevantes para o cliente, é chamado de release.
Segundo Beck os releases devem ser tão pequenos quanto possíveis, contendo os
requisitos mais importantes para o cliente. É sugerida pelo autor uma duração de dois a três
meses (BECK, 2000).
A metáfora é uma forma de fazer uma analogia daquilo que está sendo desenvolvido.
O objetivo é utilizar algo que seja do entendimento de todos, um “vocabulário em comum”
entre clientes e programadores, de forma a melhorar a interação entre os mesmos.
O projeto simples é o meio pelo qual são executadas somente as funcionalidades já
definidas, de forma a ter o melhor projeto que represente tais funcionalidades. Não se deve
investir tempo em soluções genéricas e nem em possíveis futuras funcionalidades. Num cenário
de grandes mudanças, dificilmente é possível prever qual será sua futura necessidade.
 53

Os testes constantes asseguraram que o sistema está sempre rodando, livre de erros, e
resulta em uma realimentação aos programadores e clientes a respeito das falhas encontradas.
O refatoramento consiste em uma melhoria de software, realizada por uma série de
passos, no qual não se altera a funcionalidade, mas há um ganho computacional. Um código
mais simples e melhor estruturado.
A programação em pares, onde cada um dos programadores possui um papel diferente.
Um dos programadores tem o papel de pensar e escrever a lógica de programação, enquanto o
outro tenta pensar de forma mais estratégica em como melhorar o código, apontando possíveis
erros e pontos de falha. As duplas podem ser trocadas e os papéis também, para que todos
possam ter conhecimento geral do sistema.
A propriedade coletiva do código é uma prática assegurada pela programação em
pares, com o objetivo de que todos os envolvidos se sintam donos do projeto, buscando, sempre,
um melhor resultado. A equipe inteira trabalha na busca de melhor qualidade para o código,
realizando constantes melhorias.
A integração contínua é uma prática pela qual cada funcionalidade pode ser integrada
na versão corrente do sistema, várias vezes ao dia. Os programadores implementam sua
funcionalidade no programa e rodam até que não haja mais erros e todos os testes consigam
rodar. Assim surge a nova versão do programa.
Semana de quarenta horas para garantir o descanso da equipe e a qualidade do código
gerado.
Cliente no local: Deve ser incluída alguma pessoa que represente o cliente no local para
esclarecer possíveis duvidas e participar do planejamento.
Padrões de codificação: Para garantir um código homogêneo e que todos possam
alterar e realizar o refatoramento, é necessária uma padronização do código. O que facilita o
entendimento de todos.

2.9.2.2 Ciclo de vida de um projeto XP

Um projeto XP passa pelas seguintes fases durante o seu ciclo de vida: exploração,
planejamento inicial, iterações para a entrega, produção, manutenção e fim de projeto, como é
demonstrado na Figura 12 (FAGUNDES, 2005). Cada uma destas fases é composta de diversas
tarefas que devem ser executadas ao longo do tempo.
 54

Figura 12- Fases de um projeto XP (FAGUNDES, 2005).

A fase de exploração, segundo Beck (2000), tem o objetivo de evidenciar e se fazer

entender o real escopo do sistema, até o ponto em que o conhecimento seja suficiente para que
possa ser estimado o esforço.
Nesta fase os clientes começam a escrever as user stories. Em paralelo os programadores
investigam possíveis soluções e verificam a viabilidade das mesmas. São elaboradas algumas
arquiteturas e já é possível visualizar como o sistema funcionará.
À medida que os clientes e os programadores ganham confiança, e já há estórias
suficientes, é possível começar a construir o primeiro release do projeto. Esta fase, é uma fase
de aprendizado e não deve durar mais do que duas semanas Beck (2000).
Na fase de planejamento são definidas quais serão as entregas da próxima iteração. O
programador estima a dificuldade de cada uma das estórias escritas, baseado no seu tempo de
implementação, e o cliente prioriza as estórias de acordo com sua necessidade. Definido o
tempo das iterações, são então escolhidas as user stories que farão parte da próxima entrega.
Esse processo se repete até que não se tenha mais nenhuma estória a ser implementada.
A fase de iteração é onde ocorre o maior trabalho de desenvolvimento. Ela inclui a
modelagem, programação, a escrita e execução dos testes de unidade, aceitação e pôr fim a
integração da funcionalidade ao programa geral. No final de cada iteração uma nova versão
funcional do sistema é liberada e está pronta para ser utilizada pelo cliente. Com o
desenvolvimento das iterações, maior conhecimento se tem em relação à eficiência do time, às
estimativas e o desenvolvimento do XP como um todo.
 55

A fase de produção marca a entrada do sistema no ambiente real de trabalho do cliente.

É verificado o desempenho do sistema, são feitos novos testes para garantir o seu
funcionamento e também é a fase onde o cliente pode verificar quais outras funcionalidades
seriam relevantes para seu sistema.
A fase de manutenção é descrita por Beck (2000) como inerente ao projeto XP, ela
contempla as fases de planejamento, iterações para a entrega e produção a partir da segunda
iteração até o final do projeto. O programa está sempre sendo atualizado e melhorado ao longo
do tempo.
O fim do projeto se dá quando o cliente está satisfeito e não deseja mais nenhuma
funcionalidade adicionada ao seu sistema, ou seja, não existem mais estórias. Para finalizar o
projeto deve-se escrever um documento sobre as principais funcionalidades do sistema, para
que, caso no futuro seja adicionado algo, servirá de auxílio para a equipe de projeto. Deve-se
também analisar junto à equipe quais fatores contribuíram ou prejudicaram o andamento do
projeto, para que os erros não sejam repetidos e os acertos sejam disseminados.

2.9.2.3 A equipe XP

Beck (2000) apresenta os diferentes papéis do Extreme Programming, necessários na

execução de um projeto. Estes papéis são descritos a seguir:
O Programador é a pessoa que ocupa a principal função do XP. Ele é o responsável
por estimar os prazos das user stories, por analisar, projetar, codificar, integrar e testar o
sistema. Também é responsável por realizar o refactoring quando necessário e tirar eventuais
dúvidas com o cliente.
O Cliente é o responsável por determinar o que será programado. É ele quem sabe o
que agrega valor ao seu negócio. Ele deve escrever e priorizar as user stories e com a ajuda dos
testadores deve também escrever e executar os testes funcionais, que mostrarão se o sistema
está cumprindo aquilo que ele deseja.
O Testador é quem executa os testes funcionais e publica os resultados para a equipe.
Ele tem o papel fundamental de auxiliar o cliente na definição e escrita destes testes.
O Rastreador tem a função de coletar dados sobre o andamento do projeto e manter a
equipe sempre informada dos fatos através de métricas. Sempre que algo não está em
conformidade, deve atuar para que o projeto siga o que foi planejado.
 56

O Treinador é o responsável por facilitar o processo de desenvolvimento. Por manter

a visão de projeto e ajudar com o que for necessário, para que o projeto caminhe em ritmo
extremo. Ele deve ter um bom conhecimento técnico para ajudar a equipe a tomar boas decisões.
O Consultor é um membro externo à equipe que possui um conhecimento técnico
específico. Ele auxilia a equipe na resolução de problemas pontuais.
O Gerente é o responsável por fazer fluir o jogo do planejamento, coletar e tornar visível
as métricas, buscar recursos, gerir a equipe e eventuais problemas, planejar e garantir a
efetividade das reuniões.

2.9.3 Feature Driven Development (FDD)

O Feature Driven Development (Desenvolvimento dirigido a características) nasceu no

departamento de tecnologia da informação do United Overseas Bank, em 1997, a partir da
experiência de análise e modelagem orientada a objetos de Peter Coad e do gerenciamento de
projetos de Jeff De Luca. Foi utilizado, pela primeira vez, neste mesmo ano, durante o grande
e complexo projeto de desenvolvimento do sistema bancário, na linguagem Java, realizado pelo
banco de Singapura (LARMAN; BASILI 2003).
Assim como os outros métodos ágeis já descritos, o FDD foca em iterações de curta
duração. Ao fim de cada iteração, uma característica definida pelo cliente é adicionada ao
produto. A cada etapa do projeto, tem-se um sistema operacional contendo todas as
funcionalidades adicionadas pelas iterações anteriores.
Em 1999 ocorreu a primeira publicação do método, realizada no livro “Java Modeling
in Color with UML”, escrito por Coad, De Luca e por Eric Lefebvres (1999). Na sequência,
outros autores, que também participaram do projeto em Singapura, disseminaram amplamente
o método, que hoje é mantido, discutido e atualizado pelo site featuredrivendevelopment.com
(FAGUNDES, 2005).
Será utilizado como base para descrever o FDD, nas subseções seguintes, o trabalho
publicado por Fagundes (2005).

2.9.3.1 Práticas do FDD

A modelagem dos objetos de domínio é uma prática que consiste na construção dos
diagramas de classes UML e de sequência UML. Esses diagramas servem para orientar o
programador a respeito de quais classes são importantes na sua programação e qual a relação
 57

entre elas. Um exemplo de uma classe, na linguagem de programação, pode ser o cliente do
banco, juntamente com suas características (endereço, CPF, RG etc) e as ações que ele pode
realizar (solicitar extrato, sacar dinheiro etc.).
Desenvolvimento através de características é a prática para identificar, descrever e
priorizar as características requeridas pelo cliente. Cada uma delas deve ter um esforço máximo,
de trabalho, de duas semanas, tempo limite da iteração. Qualquer método pode ser utilizado
para retratar as funcionalidades requeridas, como por exemplo, as user stories do XP.
Propriedade individual da classe: o FDD, diferente de outros métodos, propõe que
exista um responsável por cada classe a ser implementada ou por um conjunto de classes. O
que se busca com essa prática é trazer para a equipe o “instinto de dono”, ou seja, a segurança
de que o objetivo da classe será garantido pelo seu dono, que será responsável por realizar
possíveis correções, toda vez que o software sofrer modificações.
Equipe de características: Como dito anteriormente cada classe é de responsabilidade
de um indivíduo, mas como as iterações são realizadas por características, formam-se grupos
de pessoas responsáveis por diferentes classes, porem relacionados a uma mesma característica,
ou conjunto de características, para compor a equipe de características. Cada equipe deve ter
no máximo 6 membros e um líder. Os membros podem trabalhar em duas ou mais equipes, de
acordo com as classes que estiverem em sua responsabilidade, por um período curto de tempo.
As inspeções no FDD possuem o objetivo de detectar e eliminar defeitos, além de gerar
um aprendizado para a equipe. Elas devem ser realizadas durante e ao final das iterações, para
garantir que não haja erros na característica entregue ao cliente.
A construção regular tem o objetivo de detectar erros de integração do produto durante
as iterações. Ela assegura que sempre haverá uma versão atual e executável para ser entregue
ao cliente.
A administração de configuração garante o controle de versões do programa,
mantendo um histórico das alterações realizadas nas classes.
Por fim, o relatório de resultados tem o objetivo de disseminar todos os resultados
obtidos durante o decorrer do projeto para os membros da equipe e também para os clientes.

2.9.3.2 As fases do FDD

O FDD possui cinco fases bem definidas: desenvolver um modelo abrangente, construir
uma lista de características, planejar por características, projetar por características e construir
por características. Sendo que as três primeiras pertencem ao início e desenvolvimento do
 58

projeto, enquanto as duas últimas são realizadas dentro de cada iteração. Como é mostrado na
Figura 13.

Figura 13- Fases de um projeto FDD (SSPECTER, 2011).

A fase de desenvolver um modelo abrangente é a etapa inicial, onde são definidos os

requisitos do software. É nessa etapa que são construídos os diagramas de classe UML e
sequência UML, além de uma lista informal contendo as características requeridas pelo cliente.
A fase de construir uma lista de características consiste na construção de uma lista
completa, contendo todas as características do produto a ser desenvolvido. A cada característica
é relacionado uma estimativa de tempo de desenvolvimento e prioridade. Nesta etapa também
é levado em conta o vínculo das características entre si. A partir desta lista principal são então
divididos conjuntos de características com duração não superior a uma iteração.
Na etapa de planejamento são distribuídas as classes aos seus proprietários e é
estabelecido o plano de execução das características. São determinados os riscos,
complexidade, balanceados os trabalhos etc.
A fase de projetar por característica é a etapa em que a equipe, juntamente com o
programador chefe, visita toda a documentação já escrita, atualiza o diagrama de classes e
desenvolve o diagrama de sequência detalhado para o conjunto de características a ser
implementado.
A última etapa da iteração é a construção por característica, onde ocorre a
implementação, inspeção, teste, integração e testes de integração no código. Ao final desta etapa
é entregue o incremento ao cliente, um produto em pleno funcionamento.
 59

2.9.3.3 A equipe FDD

A equipe FDD é composta por três diferentes categorias de papeis, são eles: chave,
suporte e adicional. Cada qual possui suas funções e responsabilidades, sendo essencial para o
bom funcionamento do método.
Os papéis chaves são seis no total, conforme descrito a seguir.
O Gerente de projeto é o responsável administrativo e financeiro do projeto. Deve
oferecer todas as condições para que a equipe desenvolva seu trabalho, além de garantir a
viabilidade do projeto.
O Arquiteto principal é o responsável pelo projeto geral do sistema. É a pessoa que
guia o projeto através dos obstáculos técnicos e é quem dá a última palavra em relação aos
problemas de desenvolvimento encontrados.
O Gerente de desenvolvimento é o responsável por gerenciar as atividades do dia-a-
dia, resolvendo pequenos problemas que possam eventualmente ocorrer em relação aos
recursos para os desenvolvedores.
O Programador chefe é um programador com mais experiência. Ele deve ter
participado de vários projetos de desenvolvimento de software, passando por todas as etapas do
desenvolvimento. Ele está presente na análise e planejamento dos requisitos de alto nível, além
de atuar como líder de equipe durante as iterações.
O Proprietário de classe é subordinado ao programador chefe. Ele é responsável por
todo o desenvolvimento das classes a ele pertencentes.
O Especialista no domínio é qualquer pessoa que conheça bem o problema a ser
resolvido. Ele é o responsável por informar as funcionalidades que deverão conter no software.
Pode ser um cliente, patrocinador, analista etc.
Entre os papeis de suporte tem-se também seis papeis: gerente de domínio, gerente de
versão, especialista na linguagem, coordenador de configuração, toolsmith e o administrador de
sistemas. Já os papeis adicionais são: testadores, desenvolvedores e escritório técnico. Palmer
e Felsing (2002) deixam claro que estes papéis de suporte e adicionais são os papeis mais
evidentes e requeridos para qualquer desenvolvimento de software, mas não há necessidade de
se restringir a estes papeis, sendo que cada projeto deve encontrar suas necessidades específicas.
 60

2.9.4 Lean

O termo lean está diretamente ligado ao sistema Toyota de produção que surgiu no Japão
logo após a Segunda Guerra Mundial. Criado por Taiichi Ohno, engenheiro da Toyota, a
filosofia lean, como ficou conhecida, inicialmente buscava suprir a baixa produtividade e falta
de recursos, que havia na empresa, a partir de um modelo de produção enxuta (LEAN
INSTITUTE BRASIL, 2014). A popularização do lean manufacturing se deu com a publicação
do livro “A máquina que mudou o mundo” (WOMACK; JONES e ROSS, 1992), que ilustrava
a diferença significativa de desempenho entre as indústrias japonesas e ocidentais.
Com o passar dos anos a filosofia lean foi se aprimorando e passou a ser utilizada não
apenas no chão de fábrica, mas por diferentes áreas da empresa se tornando uma efetiva
ferramenta de gestão. O foco de sua aplicação é para controlar os recursos, reduzir os
desperdícios e aumentar a eficiência (LEAN INSTITUTE BRASIL, 2014).
De acordo com o Lean Institute Brasil (LEAN, 2014, Lean Thinking):
“Lean é uma estratégia de negócios para aumentar a satisfação dos clientes através da
melhor utilização dos recursos. A Gestão Lean procura fornecer consistentemente
valor aos clientes com os custos mais baixos (Propósito) através da identificação de
melhoria dos fluxos de valor primários e de suporte (Processos) por meio do
envolvimento das pessoas qualificadas, motivadas e com iniciativa (Pessoas). O foco
da implementação deve estar nas reais necessidades dos negócios e não na simples
aplicação das ferramentas lean.”
Em resumo, o lean segue o fluxo demonstrado na Figura 14.

Figura 14- Fluxo lean (WOMACK; JONES e DANIEL, 1996).

 61

2.9.4.1 Lean Product Development (LPD)

O Lean Product Development é a tradução dos princípios lean para o desenvolvimento

de produtos e foi primeiramente utilizado para descrever o processo de desenvolvimento de
produto adotado pela Toyota, com seus princípios e práticas. Há autores que se referem a esta
nova forma de desenvolver produtos como New Product Development (NPD) e também como
Product Development Introduction (PDI) (LEON; FARRIS, 2011).
Apesar do LPD ter sido historicamente ligado à Toyota, o conceito atual vai além da
descrição das práticas adotadas pela indústria automobilística e incorpora outras técnicas que
auxiliam no desenvolvimento de produto de forma rápida, com menos desperdício e menor
quantidade de erros (KARLSSON; AHLSTRÖM, 1996).
Leon e Farris (2011, p. 1) definem o LPD como:
“[...] práticas (técnicas e ferramentas) de desenvolvimento multifuncionais
que são governadas pelos fundamentos filosóficos do pensamento lean: valor, fluxo
de valor, fluxo contínuo, sistema puxado e perfeição, e podem ser usados (mas não
limitados) para maximizar o valor e eliminar o desperdício no desenvolvimento de
produtos. ”
Morgan e Liker (2006) descrevem o LPD como um sistema integrado de pessoas,
processos e ferramentas, e descrevem cada subsistema como segue o texto.
Pessoas: O LPD utiliza a figura do engenheiro chefe como um integrador de sistemas,
desde a concepção até o lançamento do produto. O sistema de gestão é matricial, onde cada
unidade funcional é liderada por gerentes capacitados e focados em treinar e desenvolver
especialistas altamente capacitados. Há um aculturamento baseado na relação cliente-
consumidor e uma busca continua de aprendizado e melhorias.
Processos: O LPD utiliza a abordagem conhecida como Set Based Concurrent
Engineering pela qual várias ideias são desenvolvidas de forma cooperativa e depois passam
por um processo de filtro à medida que o projeto evolui. Esta abordagem tem o objetivo de
retardar tomadas de decisões e proporcionar que as funções do produto sejam desenvolvidas de
forma integrada entre processo e produto.
Ferramentas e Tecnologia: O LPD, assim como o desenvolvimento de produto comum,
utiliza as principais ferramentas de desenvolvimento como CAD e CAE (Computer-Aided
Desing e Computer-Aided Engineering), a grande diferença se dá na ênfase em padronização e
visualização. Uma das ferramentas que suporta o desenvolvimento integrado e multidisciplinar
é o obeya, uma sala em que as paredes são utilizadas para gerir o desenvolvimento do produto,
 62

sendo possível visualizar os problemas, o status do projeto, os objetivos e realizar reuniões

envolvendo todas as áreas para integrar o desenvolvimento de produto.
Na Figura 15 é possível verificar a definição de cada um destes subsistemas segundo os
autores.

Figura 15 – Os treze princípios do sistema Toyota de desenvolvimento de produto

(MORGAN; LIKER, 2006).

Leon e Farris (2011), a partir de uma revisão literária sistemática dos últimos 21 anos
sobre o Lean Product Development, apresentam uma tabela sumarizada dos princípios
conceituais do LPD, identificados por cada um dos domínios de conhecimento e associados às
ferramentas LPD (tradicional e não tradicional). Este sumário pode ser visto na Figura 16.
Com esses princípios, a filosofia lean se propõe a uma melhoria contínua, elevando a
qualidade e diminuindo os custos do projeto. Entrega ao cliente aquilo que ele realmente
enxerga como valor.
63
 64

Figura 16 – Princípios e práticas LPD derivadas da revisão literária por domínio de conhecimento (LEON; FARRIS, 2011).
 65

2.9.4.2 Lean Software Development (LSD)

O Lean Software Development é inspirado na filosofia lean, e traduz os princípios e

práticas do lean manufacturing para o ambiente de desenvolvimento de software. Mary e Tom
Poppendieck foram os primeiros a publicarem sobre o LSD, no livro “Lean software
development” de 2003, onde apresentaram os princípios do lean de forma modificada para o
ambiente de software, ressaltando como esses princípios podem ser utilizados como base para
um ambiente ágil.
Ele não trata, na teoria, as fases de projeto e nem mesmo a divisão da equipe. Mas fala
em princípios que se seguidos levam à melhoria dos processos e consequentemente do projeto.
No livro, “Lean Software Development”, o casal Poppendieck (2003) elenca sete
princípios do lean para o desenvolvimento de software, são eles: eliminar o desperdício,
amplificar o aprendizado, adiar comprometimentos e manter a flexibilidade, entregar rápido,
tornar a equipe responsável, construir integridade, visualizar o todo. O conjunto destes
princípios tem o objetivo de oferecer entregas rápidas, com alta qualidade e baixo custo. No
decorrer deste capítulo serão descritos cada princípio de forma sucinta.
Os desperdícios podem ocorrer durante todas as etapas do processo de desenvolvimento,
e conseguir evita-los em cada uma das etapas, contribui para um produto final com mais
qualidade e menor custo. Funcionalidades e códigos incompletos não geram valor ao cliente.
Excesso de processos, documentação em excesso e processos complexos demandam muitos
recursos, o que aumenta o custo do projeto. Troca de tarefas, defeitos e esperas por requisitos
só aumentam o prazo. O trabalho destinado à gestão deve ser o mais simples e objetivo possível
para que a equipe possa gastar a maior parte do seu tempo no desenvolvimento, gerando valor
ao cliente.
Amplificar o aprendizado significa incorporar as experiências vividas pela equipe ao
processo de desenvolvimento, trazendo as dificuldades a conhecimento de todos, para que,
suportadas pelo ciclo de melhorias, contribua para o amadurecimento da equipe.
Adiar comprometimentos e manter a flexibilidade leva a decisões com um maior
conhecimento e experiência do projeto. É possível diminuir o número de mudanças e acertar
mais nas escolhas.
Entregar rápido a partir de ciclos incrementais e iterativos de desenvolvimento.
Iterações curtas aumentam a segurança na tomada de decisões, eleva a experiência da equipe, e
possibilita o cliente refinar suas necessidades, obtendo resultados já no próximo ciclo.
 66

Tornar a equipe responsável é um princípio que transfere responsabilidade para a equipe

de desenvolvimento do produto, que segundo o lean, é a mais qualificada para tomar decisões
técnicas e de processos que influencie seu trabalho.
Construir a integridade é uma prática para garantir a qualidade do produto através de
constantes testes de prevenção a fim de corrigir possíveis defeitos. Isto traz segurança e
motivação para a equipe alcançar níveis elevados de qualidade.
Por último, o principio visualizar o todo tem o objetivo também de garantir a integridade
do produto, de forma que o produto integrado seja utilizável e represente o valor requerido para
o cliente.

2.9.5 Kanban

Segundo Mariotti (2012) apalavra kanban é de origem Japonesa, que traduzida para o
português significa “cartão” ou “sinal”. Ela, assim como o lean¸ também surgiu no sistema
Toyota de produção, onde cartões eram utilizados com a finalidade de gerenciar o fluxo de
trabalho no modelo de produção puxada.
Neste modelo, ao invés da equipe de desenvolvimento receber as atividades, conforme
a demanda ocorre, as entregas são adicionadas numa lista, um backlog, e são “puxadas” pelos
membros, assim que fiquem disponíveis para realizar uma nova tarefa. Neste contexto, uma
nova funcionalidade só é desenvolvida para o sistema, assim que a anterior tiver acabado por
completo.
A grande diferença que o kanban propõe, em relação a outros métodos ágeis, é o
desenvolvimento em um fluxo contínuo. Enquanto houver atividades no backlog, novas
funcionalidades são adicionadas ao produto, passando pelas fases de análise, desenvolvimento,
teste, aprovação e finalização, como mostrado na Figura 17. Não há iterações, toda tarefa inicia
de um lado do quadro e termina do outro lado, até acabar todo o projeto.

Figura 17- Exemplo de um sinalizador virtual kanban (MARIOTTI, 2012).

 67

2.9.5.1 Processos Kanban

O kanban é um método altamente adaptativo, possui somente três processos: limitar o

WIP, garantir o lead-time e visualização dos processos (MARIOTTI 2012).
A limitação do working in process (WIP) ocorre de forma natural, uma vez que a equipe,
durante todo o desenvolvimento, está com a carga de trabalho adequada e acordada. Não
existem tarefas “empurradas” que poderiam causar uma sobrecarga no time de
desenvolvimento.
O lead-time tem que ser garantido para que as entregas fluam de maneira homogênea
pelas diferentes etapas, e não ocorram “congestionamentos” ou mesmo interrupção de fluxo.
A utilização de recursos visuais serve para acompanhar o fluxo de desenvolvimento e
permite verificar e atuar em problemas de uma forma mais rápida. Além de todos estarem
cientes do andamento do projeto.
A grande vantagem de se ter poucos processos e pouca burocracia é que o modelo se
torna mais “amigável” e de mais fácil adoção. Além disso, o kanban é uma evolução gradual
dos métodos cascatas para o desenvolvimento ágil, o que facilita a transição para o ágil, por
parte das empresas que trabalham com os métodos tradicionais.

2.10 Comparação Entre os Métodos Ágeis em Estudo

Os métodos SCRUM, XP, FDD, LSD e KANBAN, seja de forma incremental ou por
fluxo continuo, têm o objetivo de adicionar valor ao cliente com simplicidade.
Todos estes métodos procuram dividir o trabalho em pequenas partes, entregas parciais,
que passam a ser monitoradas através de controles visuais. Proporcionam uma maior interação
entre os membros da equipe de desenvolvimento, gestor e o cliente final. É possível avaliar
constantemente as entregas, e obter feedbacks de forma rápida, principalmente do cliente,
podendo alterar os planos futuros, com poucos impactos no desenvolvimento do projeto. Estas
características se traduzem nos processos de gestão de escopo e dos stakeholders.
Buscam também desenvolver o time envolvido no projeto, através da autogestão e auto-
organização. A equipe passa a ser dona no projeto, definindo as entregas que conseguem
realizar em um determinado tempo, ajudando o cliente a entender suas necessidades, sendo
encorajados a inovar, tomar decisões participativas, comunicar e interagir com os demais
membros da equipe, no processo conhecido por gestão de pessoas.
 68

A visibilidade do projeto é aumentada, uma vez que as tarefas percorrem quadros

visuais, com entregas iniciando e terminando por completo como um incremento ao cliente.
Desta forma evita-se, como em muitos projetos, de se ter várias tarefas iniciadas, mas nenhuma
terminada.
Na Tabela 6 é realizada uma comparação entre os métodos destacados, abordando as
principais questões que os diferenciam entre si.
 69

Tabela 6- Comparação entre métodos ágeis

. Scrum XP FDD LSD Kanban
Precursores das Ken Schwaber Peter Coad Mary Poppendieck Tom
Kent Beck Taichi Ohno
metodologias Jeff Sutherland Jeff De Luca Poppendieck
Limitar o WIP,
Comunicação, Identificação de melhoria dos
Transparência, inspeção e Planejamento por garantir o lead-time
Foco simplicidade, fluxos de valor primários e de
adaptação características e visualização dos
realimentação e coragem suporte
processos
Metodologia Ágil Ágil Ágil Ágil Iterativo
Utilização Qualquer ambiente Software Software Qualquer ambiente Qualquer ambiente
Funcionalidades
Adicionada de forma Adicionada de forma Adicionada de forma Adicionada de forma
adicionadas ao Por fluxo Contínuo
Incremental Incremental Incremental Incremental
sistema
Longa o bastante para conter os
Duração das ciclos de desenvolvimento,
iterações 2 a 4 semanas 1 a 4 semanas 2 semanas construção e teste, e curta o N/A
(Time-Box) suficiente para ter feedbacks
rápidos. (Sugestão 4 semanas)
Não adota uma forma, pode ser
Definição do esboço Diagramas de Classe e
Product Backlog User Stories um backlog, user stories, etc. Backlog
das funcionalidades Sequência UML
Depende do cliente.
Definidas as
Definidas as prioridades, a Definidas as prioridades, Definidas as prioridades, a
Atribuição das Definidas as prioridades, a prioridades, a
equipe determina a a equipe determina a equipe determina a
funcionalidades à equipe determina a quantidade equipe inicia uma
quantidade de trabalho que quantidade de trabalho quantidade de trabalho que
iteração de trabalho que cabe na iteração atividade, assim que
cabe na iteração que cabe na iteração cabe na iteração
terminou a última
Dá-se pela implementação Dá-se pela execução das do
Desenvolvimento das Dá-se pela execução do Dá-se pela execução das
das características backlog proposto para a Não há iteração
iterações Sprint backlog user stories
vinculadas à iteração iteração.
Validadas por testes de Validadas por testes e Validadas por testes de Validação se dá por
Validação das Validadas pelo cliente no
aceitação, do cliente e inspeções dos próprios aceitação, do cliente e dos testes realizados
funcionalidades sprint review
dos programadores programadores programadores pela própria equipe
Ferramentas de Burndown chart Quadro de Pode utilizar qualquer
Parking Lot Diagram Sinalizador Kanban
acompanhamento Quadro Scrum acompanhamento XP ferramenta de acompanhamento.
Aborda a metáfora para
Metáfora Não aborda criar um “vocabulário em Não aborda Não aborda Não aborda
comum”
 70

. Scrum XP FDD LSD Kanban

Desenvolvimento em
Não aborda Aborda Não aborda Abordado no LPD Não aborda
pares
Definição de padrões
Não aborda Aborda Não aborda Abordado no LPD Não aborda
no desenvolvimento
Propriedade
Não aborda Não aborda Aborda Não aborda Não aborda
individual da classe
Administração de
Não aborda Não aborda Aborda Abordado no LPD Não aborda
configuração
Adiar
Não aborda Não aborda Não aborda Abordado no LPD Não aborda
comprometimentos

Visão do Produto Não aborda Aborda Não aborda Abordado no LPD Não aborda
Não aborda este papel. Os
processos, as cerimônias e
os artefatos seguidos de
Gerente de Projeto Aborda Aborda Aborda Não aborda
forma certa, auto
gerenciam o projeto

Papel executado pelo Papel realizado pelo Papel realizado pelo gerente
Gerente de Produto Abordado no LPD Não aborda
Product Owner treinador de desenvolvimento
Composto por vários papeis,
Não aborda um time específico.
Auto-gerenciável, auto- Composto pelo entre eles: desenvolvedor,
Mas este time deve ser Não aborda um time
Time organizado e programador, testador e testador, coordenador de
altamente capacitado e seguir a específico
multidisciplinar rastreador configuração, programador
filosofia lean.
chefe etc.
Fonte: O Autor
 71

2.11 O Ágil aplicado fora do ambiente inicialmente proposto

Os conceitos ágeis surgiram inicialmente para apoiar os projetos desenvolvidos em

ambientes ditos “turbulentos”, em que há alteração frequente do escopo do projeto, com equipes
pequenas, co-localizadas, multidisciplinares e autogeridas (HIGHSMITH, 2004).
Desde o início as ferramentas e os frameworks foram surgindo e se desenvolvendo na
maior parte dos casos voltados para a engenharia e desenvolvimento de software, o que
culminou na formação da Agile Alliance como descrito na Seção 2.6.
O fato dos conceitos ágeis terem se desenvolvido no ambiente de programação se deve
primeiramente pelas características intrínsecas deste ambiente: custos concentrados no trabalho
de engenharia, projetos feitos sob medida para atender aos clientes, toda falha indica um erro
no projeto ou processo por meio do qual o projeto foi traduzido em código executável por
máquina (AMARAL; BENASSI, 2007), utilização de uma linguagem comum de programação,
pelo menos aos executantes do projeto, possibilidade de desenvolver códigos em partes que se
integram de forma a aumentar as funcionalidades do software, maior flexibilidade de mudança
se comparado a um hardware, e normalmente envolvem times pequenos, co-localizados e
projetos não críticos, que possuem pouca regulamentação (ABRAHAMSSON et al., 2009;
WILLIAMS; COCKBURN, 2003).
Em segundo plano, mas não menos importante, a disseminação dos frameworks ágeis
pelas empresas e áreas de desenvolvimento de software ocorreu como uma reação aos métodos
de gestão em cascata, até então utilizados pela maior parte dos desenvolvedores, tidos como
métodos "pesados", rígidos e caracterizados por uma pesada regulamentação e micro
gerenciamento (MENDONZA, 2011).
Como uma alternativa a este desenvolvimento em cascata, os métodos ágeis surgiram
com uma abordagem simples, leve e flexível, seguindo a lógica do fluxo PDCA (Plan-Do-
Study-Act), pela qual uma entrega é planejada e executada, os resultados são analisados e
adaptações são realizadas para melhorar o processo e corrigir eventuais problemas
(FITZGERALD et al., 2013).
Os resultados obtidos com a utilização dos frameworks ágeis nas diversas empresas que
os aplicaram se demonstraram bastante satisfatórios, principalmente quando comparados a
empresas que ainda continuavam a desenvolver softwares utilizando o modelo em cascata
(como exemplo o estudo de TAKEUCHI e NONAKA, 1986).
 72

Os conceitos ágeis ficaram cada vez mais populares com o passar dos anos e autores de
fora do desenvolvimento de software começaram a utilizar o ágil em outras áreas de
conhecimento, como: desenvolvimento de produto (AMARAL; BENASSI, 2007),
desenvolvimento de produtos inovadores (AMARAL et al., 2011), desenvolvimento de
produtos complexos (SANTOS, 2013), projetos de grande porte (FLORES, 2012) etc. Os
conceitos também foram expandidos para projetos envolvendo grandes equipes (CAO et al.,
2004) e projetos realizados com interface de forma distribuída, sem que o time estivesse no
mesmo local de trabalho (BOLAND; FITZGERALD, 2004).
Ao aplicar o ágil em outros ambientes de desenvolvimentos de projetos, verificou-se a
necessidade de adaptar tanto os frameworks já existentes, quanto a cultura das empresas, para
priorizar o valor entregue ao cliente, de forma a obter um melhor resultado.
Para os autores AMARAL et al. (2011), Chin (2004) e Shenhar E Dvir (2007), o ágil
quando aplicado ao desenvolvimento de produtos é melhor se não utilizado de forma isolada,
mas sim de forma integrada à gestão de projetos tradicional, baseada nos BOK`s, no sentido de
obter o melhor dos dois universos.
Boehm e Turner (2004) também corroboram com esta afirmativa e explicam que para
projetos cujas características são ao mesmo tempo ágeis e tradicionais, deve-se pensar em uma
metodologia híbrida. Segundo os autores uma análise de risco e das características do projeto
auxilia no balanceamento dos conceitos ágeis e tradicionais utilizados para gestão.
AMARAL et al. (2011) ao aplicar os conceitos ágeis ao desenvolvimento de produtos
inovadores não utiliza nenhum framework pré-concebido em seu modelo, mas mescla diversas
características de diferentes métodos ágeis, como exemplo: artefatos visuais, painel de controle,
planejamento semanal, utilização de cartões, sistema de indicadores de desempenho etc. Todos
os documentos e artefatos são personalizados pelos autores para o ambiente de projeto inovador,
de acordo com as necessidades que os mesmos identificaram com anos de prática.
Neste contexto, as iterações não são vistas como entregas de produtos funcionais, assim
como abordado no ágil, mas sim de partes essenciais que irão compor o produto no futuro. Esta
é uma grande diferença entre software e hardware.
FITZGERALD et al. (2013) abordam a utilização dos conceitos ágeis em ambientes
altamente regulamentados, como automotivo, farmacêutico, nuclear, alimentício e aviação.
Este tipo de ambiente requer o cumprimento de padrões, regulamentos e orientações que são
auditadas por pessoas externas à empresa.
Neste artigo, os autores, apresentam um estudo de caso referente à aplicação do
framework scrum, com a utilização do software JIRA, a uma empresa de softwares, que fornece
 73

soluções para a indústria de ciências biológicas, e que desde seu início utilizou a abordagem de
desenvolvimento de projetos em cascata.
Como alterações à proposta do scrum além da equipe scrum definida pelo framework,
foi adotado as figuras do patrocinador do produto, do controle de qualidade, vice-presidente de
qualidade e vice-presidente de desenvolvimento e suporte.
Cada um dos sprints é auditado pelo responsável pelo controle de qualidade, garantindo
o correto cumprimento dos procedimentos. As tarefas são estimadas em horas de trabalho e
atualizadas pelos membros da equipe. Não há um cliente no ambiente de trabalho, sendo que
este papel é executado pelo Product Owner. A documentação é extensa e há uma preocupação
com a rastreabilidade para garantir transparência durante o desenvolvimento do projeto.
A partir desta aplicação, os autores concluem que o ágil é adequado a ambientes
regulamentados desde que aplicado de forma a suportar as necessidades deste ambiente, como
qualidade, segurança, rastreabilidade, com as ferramentas adequadas.
O que se pôde verificar nestes dois exemplos é que na prática, o ágil fora do ambiente
proposto inicialmente, é utilizado para um maior acompanhamento do projeto, permitindo que
mudanças sejam antecipadas, desvios sejam verificados com maior frequência e que haja um
aumento de interação/comunicação entre os membros da equipe.
Na maioria das vezes, não há a figura do cliente projetista, que é representado por um
membro experiente da equipe, a documentação ainda é indispensável e o produto é entregue
somente quando o projeto acaba.
Mesmo com a adaptação dos conceitos ao ambiente de desenvolvimento do projeto, sem
contemplar tudo que foi desenvolvido pela Agile Alliance, verifica-se ganhos positivos na
aplicação do ágil fora do ambiente de software como em Santos (2013).

2.12 Desenvolvimento Tecnológico na Indústria Aeronáutica

Historicamente o que determina a liderança na indústria aeronáutica é a introdução de

novas aeronaves e produtos na hora certa, para atender as necessidades bem endereçadas das
companhias aéreas (SHERRY e SARSFIELD, 2002). O sustento desta liderança se dá por
continuas inovações, principalmente as inovações de caráter tecnológico (PHILLIPS, 1972).
A empresa analisada já vivenciou esta experiência na prática com os projetos de diversas
aeronaves ao longo das décadas de 70, 80 e 90, e que levaram a empresa a ocupar lugar de
 74

grande destaque entre os fabricantes de aeronaves no mundo, e líder de mercado no seu

segmento.
Entretanto existem diversas peculiaridades ligadas à indústria aeronáutica e que servem
como barreiras à introdução de novas tecnologias (MATSUO, 2010). Dentre elas pode citar-se
a forte regulamentação imposta pelas agências reguladoras, o alto valor envolvido no
desenvolvimento de projetos aeronáuticos, geralmente na casa de bilhão de dólar, que faz com
que as empresas busquem assumir os menores riscos possíveis, além da própria complexidade
dos projetos.
Quanto ao risco envolvido na introdução prematura de novas tecnologias nesse setor,
Ajamian e Koen (2002, p. 1) argumentam que:
“A introdução prematura de uma tecnologia no processo de desenvolvimento de
produto, quando ainda se tem uma grande incerteza se a tecnologia irá atingir as
especificações desejadas, geralmente leva atrasos, incertezas e até mesmo
cancelamento dos projetos. ”
Devido a estas peculiaridades, a indústria aeronáutica aborda de maneira diferenciada o
desenvolvimento e a introdução de novas tecnologias nos seus projetos. Em geral, para que uma
determinada tecnologia seja incorporada a um produto em desenvolvimento, ela passa por um
prévio processo de amadurecimento, até que se atinja um nível de maturidade suficiente para
minimizar os riscos de sua utilização (MATSUO, 2010). Esta etapa é conhecida como pesquisa
e desenvolvimento pré-competitivo, possui um longo ciclo e demanda elevados investimentos,
sem gerar nenhum retorno financeiro à empresa. Na empresa analisada essa etapa recebe o
nome genérico de desenvolvimento tecnológico.
Na Figura 18 é mostrado um esquema genérico das fases de desenvolvimento de uma
tecnologia até o emprego e serialização em um produto.
Como se pode ver na Figura 18, até que um produto seja completamente desenvolvido,
e inicia a sua comercialização, todo o processo gera apenas custos à empresa. Nota-se também
que volume do investimento aumenta à medida que se percorre a escala de Technology
Readness Level (TRL), explicada na Seção 2.12.1.
Uma grande fatia destes investimentos é referente ao alto valor gasto na produção de
corpos de prova, demonstradores tecnológicos, e dos testes para avaliar e garantir a maturidade
da(s) tecnologia(s) sendo incorporada(s) ao novo produto. Por este motivo é de grande interesse
das indústrias formarem parcerias com instituições de pesquisa, governos e até mesmo outras
indústrias, do ramo ou não, para dividirem os riscos e os custos associados à etapa do
desenvolvimento tecnológico, buscando, contudo, não deixar de lado a estratégia global do
 75

negócio e os segredos industriais. Esse fenômeno é geralmente conhecido como inovação

aberta, mas um aprofundamento sobre o tema fugiria do escopo e objetivos do presente trabalho
(veja, por exemplo, ARAUJO, 2012).

Figura 18- Modelo do ciclo P&D na indústria aeronáutica (Adaptado de MATSUO, 2010).

O setor de desenvolvimento tecnológico das empresas aeronáuticas procura trabalhar

com tecnologias situadas na faixa de TRL 3 a 7, partindo da pesquisa aplicada até a
demonstração avançada do conceito. Esta faixa corresponde à área de P&D, destacada no
gráfico de investimento x tempo acima. Entretanto, ao longo dos anos, foi verificada a
necessidade de criar um “colchão” de possíveis tecnologias a serem estudadas no futuro, e hoje
há também um investimento, mesmo que bem menor, em tecnologias de baixo TRL que compõe
a faixa de pesquisa e tecnologia (P&T) no gráfico de investimento x tempo (MATSUO, 2010).
No momento em que a tecnologia já é considerada desenvolvida (madura) o suficiente,
atinge-se um TRL igual a 7, onde considera-se que houve a demonstração da mesma por meio
de protótipos, considerando as condições de uso real. A partir desse momento a tecnologia é
considerada apta de ser adotada por novos projetos de produto da empresa, dependendo das
 76

necessidades e estratégias específicas do novo produto. Mas isto não quer dizer que a tecnologia
está pronta e chegou ao topo de maturidade.
Para que a tecnologia seja de fato incorporada ao produto, sendo industrializada e
posteriormente comercializada, são necessários ainda vários testes e a confirmação, no produto
real, de que o conceito estudado realmente funciona como o esperado. Isso acontece no escopo
do desenvolvimento do produto, e não mais do desenvolvimento tecnológico.
A grande vantagem de se ter o desenvolvimento da tecnologia separado do
desenvolvimento de produto é a diminuição dos riscos envolvidos quando a tecnologia for
utilizada. A empresa passa a conhecer melhor a tecnologia, suas aplicações, os desafios
envolvidos e sana possíveis dificuldades, antes mesmo de aplica-la em um novo produto.

2.12.1 Technology Readyness Level (TLR)

O TRL, ou Technology Readness Level, é um método desenvolvido pela NASA para

quantificar a maturidade de uma tecnologia. O primeiro artigo publicado sobre o assunto data
de 1989 e foi escrito por Stanley Sadin (NOLTE, 2008).
Segundo este método a maturidade de uma tecnologia começa com “ciência” e termina
com “engenharia”. A escala TRL demonstra este processo de amadurecimento em nove níveis
de maturidade. Os três primeiros níveis representam a ciência enquanto os três últimos se
referem à engenharia. Os níveis intermediários representam uma “nuvem negra” uma fronteira
difusa entre pesquisa científica e engenharia aplicada (NOLTE, 2008).
A escala TRL comumente é apresentada na forma de um termômetro, como segue na
Figura 19. O termômetro em si mostra os avanços dos níveis da escala, ao lado direito dele tem-
se a definição de cada nível.

Figura 19- Technology Readiness Levels (Traduzido de ALOPEX, 2013).

 77

Para auxiliar as pessoas na definição de qual nível se encontra cada tecnologia, foram
criadas breves descrições e informações de suporte, que definem o nível e o resultado que se
espera de uma tecnologia que está neste nível (ver anexo). Como exemplo segue a definição
adotada pelo departamento de defesa americano (DoD):

“TRL 2 - Conceito e/ou aplicação de tecnologia formulado (s).

Descrição: Começo da invenção. Onde os princípios básicos são observados e aplicações
práticas podem ser inventadas. As possíveis aplicações são especuladas e podem não ser
provadas ou ter análises detalhadas que suportem as premissas adotadas. Os exemplos são
limitados a estudos analíticos.
Informação de suporte: Publicações e outras referências que dão um esboço da aplicação
tecnológica começam a aparecer e servem como suporte ao conceito observado. ” (NOLTE,
2008)
Na Figura 20 pode-se verificar a evolução da tecnologia de escapamento dos motores
turbofan, para diminuir a emissão de ruídos, desenvolvido pela empresa aeronáutica Boeing.

Figura 20- Exemplo da evolução de uma tecnologia (Adaptado de NASA e WERRIES, 2010).
 78

Na Figura 20 pode-se verificar que entre as primeiras pesquisas e a utilização de fato da

tecnologia em um produto passaram-se quase 25 anos. Outro fato relevante é a diferença visual
entre o misturador de ar, em teste, para o TRL 7 e o misturador de ar utilizado na aeronave
Boeing 787 (TRL 8-9). Isto confirma que a tecnologia, após completar o ciclo do
desenvolvimento tecnológico, ainda sofre mudanças, necessita ser integrada e ganhar
maturidade para que seja incorporada no produto final real.
Com o passar do tempo surgiu também uma escala para classificar tecnologias aplicadas
a processos. Estas tecnologias de suporte a processos não agregam valor de forma direta ao
produto, mas podem contribuir na melhoria de qualidade, na diminuição dos custos e no
relacionamento com o cliente. Esta escala se assemelha a escala de produtos e por este motivo
não será mostrada neste trabalho.

2.13 Desenvolvimento de Projetos Tecnológicos

Entre as abordagens mais conhecidas de desenvolvimento de projetos tecnológicos está

a metodologia conhecida como technology development Stage-Gate® (COOPER, 2007). Esta
metodologia propõe o desenvolvimento do projeto em estágios e barreiras, onde os estágios
(stage) consistem em uma serie de boas práticas a serem realizadas pelo time de
desenvolvimento, com o objetivo de adquirir informações vitais, reduzindo incertezas e os
riscos envolvidos no projeto. As barreiras (gates), por outro lado, são pontos de decisão de
continuidade ou cancelamento do projeto, onde uma comissão decide se o projeto deve receber
investimento adicional para seguir até o próximo estágio, ou não. A Figura 21 exemplifica este
processo.

Figura 21- Technology development Stage-Gate® (COOPER, 2007).

 79

O objetivo desta metodologia é gerar conhecimento para que as decisões de avanço do

projeto sejam tomadas com um maior embasamento. O fato do desenvolvimento se dar em
etapas reduz o risco financeiro no projeto, e aumenta a probabilidade de sucesso no final, já
que, a cada etapa, o plano do projeto é revisto e reavaliado por uma comissão julgadora que
será a responsável pela sobrevivência do projeto.
Os autores Ajamian e Koen (2002) também abordam o desenvolvimento tecnológico
por estágios e barreiras. Segundo esses autores, o processo, designado por eles de technology
stage gate (TechSG), é composto por uma série de barreiras ou revisões, onde apenas a próxima
barreira é conhecida de forma detalhada. Entretanto tem-se desde o início uma visão
rudimentar, macro, sobre o plano global do projeto.
A cada barreira o projeto é revisto e novas entregas são acordadas por uma comissão
técnica. Metas tecnológicas são estabelecidas e alinhadas à estratégia de produto. Desta forma
é possível lidar com descobertas inesperadas e mudanças necessárias, típicas do
desenvolvimento tecnológico, sem que o projeto sofra grandes impactos.
É possível fazer um paralelo entre os métodos ágeis e o desenvolvimento por barreiras
e estágios proposto pelas duas metodologias mencionadas anteriormente. Por exemplo, ambos
fazem uso do artifício do planejamento do projeto em curtos ciclos de tempo, para se beneficiar
de maior conhecimento adquirido, a fim de aumentar a probabilidade de sucesso ao final do
projeto.
Outra abordagem, utilizada principalmente no desenvolvimento e teste de estruturas
complexas, é o building blocks test approach (MATSUMURA, HAFTKA e KIM, 2011). Esta
abordagem pode ser expandida para o ambiente tecnológico e ajudar no desenvolvimento de
novas tecnologias. Segundo o building blocks test approach, o desenvolvimento ocorre em
múltiplos estágios, representados por uma pirâmide. À medida que se percorre os estágios, a
complexidade do item em pesquisa aumenta, até que no último estágio, tem-se o produto
integrado e ensaiado no seu ambiente de trabalho (Figura 22).
Os estágios do building blocks tests approach de certa forma equivalem ao aumento de
maturidade tecnológica. Cada nível pode ser equiparado a um determinado TRL e, com o
avanço dos estágios, a tecnologia ganha maturidade, aumentando o TRL, até ser provada a sua
eficácia no ambiente real. Os estágios iniciais, coupons e elementos correspondem à pesquisa
fundamental e os demais estágios correspondem a pesquisa aplicada em diversos níveis de
complexidade e maturidade.
 80

Figura 22- Building blocks test approach (MATSUMURA, HAFTKA e KIM, 2011).

Deve-se tomar o cuidado para não avançar os estágios sem que todos os conhecimentos
necessários (essential blocks) em cada estágio sejam adquiridos. Um estágio só deve começar
após o termino do anterior, diminuindo a possibilidade de se ter surpresas que afetem o projeto.

2.14 Gerenciamento Ágil Aplicado a Produtos Inovadores

Um exemplo de um modelo para gestão de projetos de produtos inovadores, baseado

nos conceitos ágeis, pode ser encontrado em Amaral et al. (2011). Como abordado na Seção
2.2, apesar de não serem iguais, o desenvolvimento tecnológico e o desenvolvimento de
produtos inovadores possuem características em comum, como exemplo o ambiente turbulento
do projeto e a complexidade da tecnologia em desenvolvimento.
Os autores partem do princípio que o grupo de teorias ágeis, dentre elas as apresentadas
nesta dissertação, SCRUM, XP, FDD, LSD e KANBAN, foram criadas especialmente para o
desenvolvimento de software, trazendo no seu bojo requisitos e especificações que somente são
aplicadas diretamente a esse tipo de projeto. Sendo assim, puramente aplicar uma metodologia
ágil em um projeto de produto manufaturado, algo físico, não retorna os mesmos benefícios, de
quando aplicado ao desenvolvimento de software (AMARAL, 2011).
Ao mesmo tempo, utilizar somente os conceitos tradicionais, apresentados pelo guia
PMBOK, também não parece ser é a melhor opção. Preenchendo este vazio que há na literatura,
Amaral et al. (2011) apresentam no livro “Gerenciamento ágil de projetos”, um modelo
referencial (Figura 23), que mescla conceitos ágeis e tradicionais para ser aplicado a produtos
inovadores.
 81

Figura 23 – Modelo Referencial (AMARAL et al., 2011)

Este modelo é apresentado como um complemento à teoria tradicional. Não pretende,

portanto, ser um substituto à metodologia tradicional, mas sim um complemento à mesma. “O
profissional de gestão de projetos terá de fazer uso: a) das demais práticas de gerenciamento de
projetos previstas nos corpos de área; e b) de um modelo referencial de desenvolvimento de
produto adequado, conforme a característica do produto, da empresa e contexto. ” (AMARAL
et al., 2011).
Os autores suprem os cinco grupos de processos: iniciação, planejamento, execução,
monitoramento e controle e encerramento, de projeto. Detalham no livro cada parte,
justificando sua necessidade, e misturando a literatura com a aplicação em caso real.
Apresentam os documentos utilizados, a forma como foi realizada a implementação do modelo
referencial e citam alguns resultados.
Para esta dissertação em si, devido às restrições de tempo, escopo e o cenário em que os
estudos de caso foram realizados, a principal contribuição, não desprezando todo o resto do
conteúdo abordado, do estudo realizado por Amaral et al. (2011), se dá no método para
planejamento e controle no APM, intitulado pelos autores de IVPM2 (Iterative and Visual
Project Management Method) e apresentado na Figura 24.
 82

Figura 24 – Método para gerenciamento ágil de projetos – IVPM2 (CONFORTO, 2009)

O IVPM2 utiliza o modelo de fases e entregas no qual a visão do produto é desdobrada

em entregas, que são espaçadas no tempo, de acordo necessidade de realização. O projeto é
dividido em fases, que podem ser compostas por uma ou mais entregas. Ao final de cada fase
do projeto ocorre um gate de avaliação. Nesta etapa o autor utiliza os conceitos de estágio e
barreiras, abordados por Cooper (2007), na metodologia technology development Stage-Gate®,
descrita na seção anterior.
Um conjunto de entregas, definidos pela equipe juntamente com o gestor funcional do
projeto e o cliente, compõe uma iteração, que pode ocorrer dentro de uma fase, ou por várias
fases. Na Figura 25 é possível ver o detalhe do o modelo de fases e entregas.
 83

Figura 25 – Modelo de fases e entregas (AMARAL et al., 2011)

Cada entrega é desdobrada em pacotes de trabalho, menores que uma semana, que serão
controlados pelo quadro de planejamento fino semanal (QPFS). Faz-se todo o controle do
projeto, através de indicadores de desempenho, que realimenta o planejamento inicial.
Pode-se dizer que o modelo referencial aborda conceitos de diferentes métodos ágeis. É
possível citar a título de exemplo: o estabelecimento de padrões no desenvolvimento, a visão
do produto e a utilização de metáforas abordadas pelo XP, a administração de configurações do
FDD, a gestão visual do KANBAN, a interação, proporcionada pelo SCRUM e pelo LSD.
Além do ágil Amaral et al. (2011) colocam em prática as metodologias tradicionais e
Stage-Gates, de forma complementar, obtendo bons resultados em aplicações reais realizadas
com pequenas empresas de base tecnológica. Os autores deixam claro que o modelo não foi
elaborado ou testado em projetos de inovação pura, em serviços, ou em inovação
organizacional.
Esta seção encerra o capítulo 2, referente à fundamentação teórica, mostrando um
trabalho que une todos os conceitos, anteriormente abordados, em um modelo referencial. Este
trabalho é a base para iniciar o capítulo 3 desta dissertação, que possui o objetivo de apresentar
uma metodologia de gestão de projetos a ser aplicada no desenvolvimento tecnológico da
empresa analisada.
 84

3 CASO INDUSTRIAL DE APLICAÇÃO

Este capítulo descreve o caso industrial de aplicação realizado no departamento de

desenvolvimento tecnológico de uma empresa brasileira de manufatura do setor aeronáutico.
Inicialmente é apresenta a metodologia utilizada para conceber o modelo de gestão, baseado
nos conceitos ágeis, proposto. Este modelo é então comparado ao método de gestão atual, e
aplicado em dois projetos já em andamento no departamento tecnológico desta empresa
analisada. Encerrando o capítulo, faz-se uma comparação entre a aplicação real do modelo
MGADT e os conceitos ágeis descritos na literatura.

3.1 Metodologia

A metodologia utilizada neste trabalho seguiu o esquema sumarizado na Figura 26, com
passos numerados de 1 a 9, divididos em quatro etapas.
A primeira etapa teve o objetivo de entender o problema e verificar possíveis soluções.
Foi realizada uma análise do problema (1), seguida da revisão da literatura (2), do levantamento
das experiências da empresa analisada com a implementação da metodologia scrum no
desenvolvimento de produtos (SANTOS, 2013) (3), do levantamento de experiências anteriores
com outros modelos de gestão e também do cenário atual no desenvolvimento tecnológico (4).
A segunda etapa teve o objetivo de discutir as informações capturadas na etapa anterior
(5) e propor um novo modelo de gestão de projetos baseado nos conceitos ágeis (6). Para tanto
foi escolhida a metodologia kaizen4 como forma de promover uma melhoria ao processo de
gestão que estava sendo utilizado para gerir os projetos desenvolvimento tecnológico.
A terceira etapa consistiu na aplicação e acompanhamento do modelo proposto a dois
projetos de diferentes áreas do DT da empresa analisada (7).
Por fim na quarta etapa foram realizadas as análises qualitativas a respeito do método
implementado, comparando o mesmo com a literatura e com o modelo anterior, que estava em
utilizo no DT da empresa analisada (8).
A partir destas comparações, verificou-se os pontos de melhoria (9), os quais servirão
como feedback para uma nova aplicação do modelo inicialmente proposto.

4
Segundo IMAI (1994) kaizen é um processo de melhoria contínua com o objetivo de busca da redução de gastos em todas as etapas
de manufatura e também eliminação das diferenças entre o custo-alvo e o custo-estimado.
 85

Desta forma, pretende-se que cada nova aplicação do modelo proposto possa contribuir
com melhorias que devem ser incorporadas nas discussões, a fim de revisar o modelo, até que
num tempo futuro um modelo referencial possa ser estabelecido e utilizado para os projetos de
desenvolvimento de tecnologia.

Figura 26- Esquema utilizado nesta dissertação (O autor).

3.2 Primeira Etapa

A etapa 1, como descrito na seção anterior teve o objetivo de entender os problemas e

desafios envolvidos no modelo de gestão de projetos que estava sendo utilizado no
desenvolvimento tecnológico da empresa analisa, e buscar possíveis alternativas para melhorar
a eficácia e eficiência do mesmo.
Assim como mostrado nas pesquisas PMSURVEY.ORG (2010), The Standish Group
(2013) e PMI’S PULSE OF THE PROFESSION (2013), os projetos desenvolvidos no âmbito
do desenvolvimento tecnológico da empresa analisada também apresentam grandes desafios
em atingir custos, tempo e escopo acordados na fase inicial. Os valores, em porcentagem, de
projetos que tiveram sucesso, falha e ou foram desafios nos últimos anos, se assemelham aos
valores apresentados nas pesquisas em questão, de acordo com membros seniores do DT da
empresa analisada.
 86

Baseado nos estudos realizados pelo autor para gestão de projetos desenvolvidos em
ambientes ditos “turbulentos” formulou-se a hipótese de que a adoção de princípios ágeis
poderia trazer benefícios para se alcançar o sucesso em projetos de desenvolvimento de
tecnologia.

3.2.1 Análise do Problema

A fase de concepção do problema se deu com a participação de 17 membros seniores,

desenvolvedores e gestores de projetos de diferentes áreas do DT, que se juntaram em uma sala
para levantar aspectos que dificultavam a gestão de projetos no departamento. Esta parte não
contou com a participação do autor e o resultado é apresentado na lista em sequência:
(i) Falta de homogeneidade na gestão de projetos nos níveis intermediário e
operacional, dos projetos. Cada equipe gere seus projetos de uma forma, não
havendo um único padrão a ser seguido;
(ii) Excesso de tempo gasto na manutenção dos projetos no sistema PS-SAP (Project
System - Sistema de gestão empresarial SAP);
(iii) Dificuldade de integração entre o PS-SAP e a metodologia corrente crítica;
(iv) Necessidade de diminuir a carga da equipe com atividades administrativas;
(v) Dificuldade de aderência integral, por parte das equipes, da metodologia
corrente crítica.
Foi levantada também, por parte da equipe, a falta de visibilidade do andamento do
projeto no ambiente operacional. A equipe não tinha clara a visão do projeto, suas entregas,
prioridades e o impacto do atraso destas entregas no projeto como um todo. Quando se
verificava o atraso das entregas, o impacto no projeto já havia ocorrido, o que ajuda a explicar
o baixo desempenho global desses projetos em termos de prazo e custo.
Identificados os problemas, foram estabelecidas as necessidades para que um novo
modelo de gestão de projetos pudesse ser proposto. Esta etapa se deu com a participação de
todo o grupo anteriormente descrito e também do autor.
Entre as necessidades identificadas estavam um estudo da literatura relativo à gestão
ágil de projetos, parte que coube ao autor, consultoria com outras áreas da empresa analisada
que já estavam utilizando o ágil na gestão de seus projetos e o detalhamento do modelo de
gestão que estava sendo utilizado no DT para identificar as oportunidades de melhoria.
 87

3.2.2 Revisão da Literatura

Nesta etapa se deu a contribuição do autor para a confecção do novo modelo de gestão
de projetos para o desenvolvimento tecnológico da empresa analisada.
Foi realizada uma análise extensiva da literatura a respeito da gestão ágil de projetos,
sua utilização fora do contexto inicialmente proposto e também o uso de metodologias hibridas
para a gestão de projetos tanto de produtos, quanto de produtos inovadores. O resumo desta
análise da literatura é descrito no Capítulo 2 deste trabalho, cujo título é Fundamentação
Teórica.
O autor, munido do conhecimento adquirido na literatura, realizou uma apresentação
para os 17 membros seniores do desenvolvimento tecnológico da empresa analisada a fim de
mostrar as diferenças entre as metodologias tradicionais e ágeis, os limites da teoria ágil, os
principais métodos ágeis utilizados na atualidade, como eles estavam sendo empregados no
desenvolvimento de produto e também a utilização de metodologias híbridas.
Esta apresentação culminou em uma discussão de toda a equipe presente a respeito de
como os princípios ágeis poderiam ser inseridos no ambiente de desenvolvimento tecnológico
da empresa analisada a fim de trazer ganhos para a gestão dos projetos.
Nesta etapa, vale ressaltar que o ambiente de desenvolvimento de projetos de uma
grande empresa apresenta restrições que muitas vezes não se encontra em empresas menores,
como exemplo: um sistema integrado de gestão, normalmente suportado por um software ERP,
que envolve altos custos de modificação, caso seja necessária, questões de necessidade de
padronização de gestão em áreas envolvendo diferentes tipos de projetos, sistema de gestão
matricial, divisão do time em células5, utilização dos conceitos lean etc. Isto muitas vezes
restringe a simples aplicação de uma metodologia na forma como ela é descrita na literatura,
mas ao mesmo tempo dá a liberdade do gestor escolher as ferramentas que melhor se adequam
ao seu ambiente de trabalho.
Na empresa analisada, foram levantados, como restrições, o monitoramento global do
projeto via sistema empresarial ERP SAP-PS e a necessidade de aplicação da metodologia
corrente crítica, utilizada em todos os projetos de desenvolvimento da empresa, para
estabelecimento de escopo e controle de prazos no projeto. Também ficou decidido que os

5
Células são áreas de tamanho e formato variáveis dedicadas ao desenvolvimento/fabricação de um
produto ou família de produtos que tenham o mesmo processo, ou um processo muito próximo de
desenvolvimento/fabricação (ROSSETTI et al., 2008)
 88

indicadores macros do projeto não seriam alterados, mantendo-se o CPI, SPI, BAC, TAC e o
pulmão do projeto para manter o padrão já utilizado.
Optou-se então por uma abordagem de metodologia híbrida, que de forma escalonada
pudesse dar suporte para o desenvolvimento dos projetos no nível operacional, gerencial e
também da alta gerência. Algo que já estava sendo praticado por outros autores como exemplo
Amaral et al. (2011) e Conforto (2009).

3.2.3 Método Ágil na Empresa Analisada

Definido que o novo modelo de gestão de projetos, a ser aplicado no desenvolvimento

tecnológico da empresa analisada, teria uma abordagem híbrida seguindo as restrições
impostas, buscou-se dentro do ambiente de desenvolvimento do produto equipes da própria
empresa que já estavam utilizando algo parecido para gerir seus projetos.
Entre as áreas que haviam aplicado modelos híbridos de gestão de projetos estava o
desenvolvimento integrado de produto (DIP) de uma aeronave cargueiro 6, que havia usado de
forma bem sucedida, uma versão escalonada de gestão de projetos em quatro níveis, cada qual
com sua respectiva função.
Os três primeiros níveis eram suportados pelas metodologias tradicionais e tinham o
objetivo de levar a informação necessária para que a gerência responsável pudesse realizar o
acompanhamento do projeto.
Os milestones, acordados contratualmente com o cliente, eram controlados no nível
primário e então desdobrados em entregas intermediárias nos demais níveis até as entregas de
nível operacional (quarto nível), que eram geridas por uma versão do framework scrum
(SANTOS, 2013).
Algumas dessas equipes, que estavam aplicando o modelo de gestão híbrido em
questão, foram convidadas para apresentar a forma como estavam trabalhando. Nesta etapa foi
possível verificar como se dava a integração do framework ágil com os demais níveis de gestão,
quais as técnicas ágeis que estas equipes estavam utilizando, o que havia dado certo, quais os
empecilhos haviam sido encontrados e como de fato estava rodando a gestão operacional dos
projetos.

6
A aeronave em questão é um cargueiro para transporte tático/logístico e reabastecimento, desenvolvido e
fabricado pela empresa estudada nesse trabalho.
 89

Durante estas apresentações notou-se que sempre quando se falava em aplicação do

framework scrum na empresa analisada, devia tomar-se um cuidado especial no sentido de que
apenas algumas das práticas desse framework de fato eram adotadas pelas equipes da empresa.
A base de gestão de todos os projetos dessa empresa é, e continua sendo, o PMI, através
das boas práticas do PMBOK. Nesse cenário, as ferramentas ágeis são utilizadas apenas na
gestão operacional dos projetos, em modelos híbridos de gestão, sempre com o objetivo de
auxiliar as equipes de desenvolvimento no trabalho diário.
Entre as práticas ágeis adotadas encontraram-se o planejamento e feedback constantes,
divididos em iterações de curta duração (duas semanas), divisão do projeto em entregas
priorizadas e não mais em atividades, maior envolvimento dos principais clientes na definição
das entregas, utilização do quadro scrum, equipe com maior autonomia, utilização do
burndownchart para o monitoramento da equipe, entre outros.
Com a adoção crescente da aplicação das práticas ágeis por várias áreas da empresa, foi
disponibilizado um software coorporativo para a utilização das equipes. Este software, chamado
de JIRA, possui uma estrutura, baseada nos conceitos ágeis do scrum, que auxiliam a equipe no
planejamento e monitoramento dos trabalhos diariamente.

3.2.4 Cenário Atual do Desenvolvimento Tecnológico da Empresa Analisada

Para descrever como se dá a gestão de projetos no desenvolvimento tecnológico da

empresa analisada, ou seja, o modelo atual que é utilizado para gerir os projetos, identificou-se
a necessidade de primeiramente contextualizar adequadamente este ambiente de
desenvolvimento de projetos.
Para tal contextualização, que segue na subseção seguinte, foram conduzidas entrevistas
com membros sêniores do departamento de desenvolvimento tecnológico da empresa analisada,
de diferentes áreas de expertise, entre elas: prospecção tecnológica, gestão de portfólio,
administração de projetos e inteligência tecnológica.

3.2.4.1 Portfólio de Projetos do DT da Empresa Analisada

A composição do portfólio de projetos do desenvolvimento tecnológico da empresa

analisada se dá a partir da verificação da necessidade de uma tecnologia para emprego futuro
no desenvolvimento de produto.
 90

Existem duas formas distintas para que uma tecnologia possa ser estudada pela empresa,
tecnologias “puxadas” e tecnologias “empurradas”.
As tecnologias ditas puxadas provem em geral como consequência dos estudos
realizados pelo departamento de inteligência de mercado, sobre as tendências futuras em
diferentes setores: ambiental, mercado, governo, sociedade etc.
Já as tecnologias “empurradas” são aquelas que se originam de estudos, em âmbito
mundial, de tecnologias já adotadas, ou que estão sendo estudadas, por outras empresas,
universidades ou centros de pesquisa e que podem agregar algum valor ao produto ou ao cliente
final, mas que ainda não estão sendo contempladas no radar da inteligência de mercado da
empresa.
Realizados os estudos, e alinhado com a estratégia empresarial, são formados grupos de
características a serem incorporadas aos novos produtos, como exemplo: redução de ruído,
redução dos custos operacionais, maior conforto ao passageiro etc.
Partindo destes grupos tecnológicos-chave são verificadas quais as tecnologias que
podem agregar a característica requerida ao produto. São levantadas diversas tecnologias, seu
TRL atual, o impacto potencial no cliente, em qual TRL se pretende elevar a tecnologia etc.
Para cada proposta de desenvolvimento tecnológico é elaborado um Project Charter para
auxiliar a equipe na descrição dos projetos.
Após uma análise, as tecnologias são priorizadas. Dentro do processo denominado
Roadmap Tecnológico são definidas as tecnologias a serem estudadas, de acordo com o
investimento destinado pela empresa ao setor tecnológico em cada ano. Assim é formado o
portfólio do desenvolvimento tecnológico, como mostrado na Figura 27.

Figura 27- Desenvolvimento Tecnológico (EMPRESA ANALISADA, 2014).

 91

3.2.4.2 Gestão Atual dos Projetos no DT da Empresa Analisada

A empresa analisada, assim como a maioria das empresas de manufatura atuais, opta,
como base para a gestão de seus projetos, pelas boas práticas propostas pelo PMI. Nesse caso,
após os projetos terem sido priorizados, eles irão caminhar ao longo de uma fase inicial de
planejamento (conforme práticas do PMBOK), onde são definidos: o escopo, prazo,
investimento, estratégia de execução, estratégias de contratação, plano de riscos etc., do projeto.
O projeto, que pode envolver desde o desenvolvimento de um software, até a construção
física de protótipo, é organizado em forma de um Work Breakdown Structure7 (WBS), que é
então desdobrado com o apoio de uma ferramenta ERP de gestão corporativa, modulo PS do
SAP8. É estabelecido um cronograma de atividades que contempla todas as entregas necessárias
durante o projeto. A partir de softwares de gestão, são definidas: a curva de carga/capacidade,
as precedências e é gerado o diagrama Gantt.
Nesta parte já podemos identificar o uso de uma prática que é criticada nas metodologias
ágeis, a definição de todo o escopo do projeto logo na etapa inicial. Como já evidenciado por
G. Pahl e W. Beitz (BROOKS JR, 2010), essa prática decorre em geral de uma demanda
institucional por um conjunto de requisitos completo e acordado, em última instância, para que
se estabeleça um contrato de preço fixo, desde o início do projeto.
Nas entrevistas realizadas com os membros seniores do DT, foi verificada uma grande
dificuldade de se estabelecer o escopo dos projetos tecnológicos nessa etapa inicial, cuja
incerteza tem um grau muito elevado. Isso reforça a conclusão de G. Pahl e W. Beitz (BROOKS
JR, 2010), que afirmam ser impossível especificar qualquer conjunto completo e preciso de
requisitos, para qualquer sistema complexo, no momento inicial do projeto.
Após esta fase inicial de planejamento, e antes de iniciar as atividades de execução,
todos os projetos da diretoria necessitam de uma aprovação, que ocorre via um documento
chamado MAP (Memorando de Ativação de Projeto), para assim dar início ao desenvolvimento.
Esse documento nada mais é que um plano detalhado de projeto, incluindo introdução, contexto,
escopo, premissas etc., conforme práticas do PMBOK.
O monitoramento e controle da evolução física e financeira do projeto são realizados
através do modulo PS do SAP. É utilizada como base a metodologia EVM9 (Earned Value

7
WBS ou EAP é o processo de subdivisão das entregas e do trabalho do projeto em componentes menores e mais facilmente gerenciáveis.
(PMI, 2013)
8
Software de gestão empresarial utilizado na empresa estudada, criado pela empresa alemã SAP (Systeme, Anwendungen und Produkte in der
Datenverarbeitung).
9EVM ou em português Gestão do Valor Agregado (GVA) é uma metodologia que combina escopo, cronograma, e medições de recursos para
avaliar o desempenho e progresso do projeto. Ele integra a linha de base do escopo à linha de base dos custos e à linha de base do cronograma
 92

Management) e são controlados especialmente os índices de Desempenho de Custo (CPI) e de

Desempenho de Prazos (SPI). Nota-se, porém, que em função da alta complexidade e incerteza
desses projetos, é muito comum serem observados desvios razoáveis de prazo e custos. Esses
desvios causam grande transtorno para as equipes envolvidas, que necessitam constantemente
se explicarem junto à liderança do departamento, revisarem e re-aprovarem o planejamento dos
seus projetos, o que acaba por desviar recursos escassos, essenciais para a tarefa técnica, em
tarefas administrativas e de gestão.
Visando a redução de desvios de prazo, há algum tempo o departamento de
desenvolvimento tecnológico da empresa analisada aderiu aos conceitos da metodologia
corrente crítica, voltada para a administração de prazos e atividades, baseado na teoria das
restrições (TOC – Abordada na Seção 2.5). Segundo esta teoria, um sistema é tão forte quanto
o mais fraco de seus elos. Para tanto, é detectado o caminho crítico do projeto, que passa a ser
prioridade na sequência de tarefas. É atribuído um “pulmão”, reservas de recurso e de tempo,
para o caminho crítico, que é então monitorado de perto para diminuir a possibilidade de atrasos
no projeto como um todo.
Esta adesão, da metodologia de corrente crítica proposta pela empresa analisada, gerou
um novo desafio à equipe: o desafio de conciliar os dois métodos de gestão não integrados, de
origem e com objetivos distintos, sem que se gastasse muito tempo com os processos
administrativos. Os funcionários entrevistados nesse estudo possuem visões antagônicas sobre
a aplicabilidade e utilidade da metodologia de corrente crítica aos projetos de desenvolvimento
tecnológico. Para alguns dos entrevistados o método não se encaixou adequadamente à
metodologia tradicional já adotada, gerando grande dispêndio de horas pelas equipes ao
tentarem amarrar os planejamentos do mesmo projeto em duas plataformas metodológicas
diferentes.
Em paralelo a estes acontecimentos, propagava-se pela empresa a adoção do framework
scrum, em função dos bons resultados obtidos na gestão operacional dos projetos de
desenvolvimento de produto (SANTOS, 2013).

para formar a linha de base de medição do desempenho, que ajuda a equipe de gerenciamento do projeto a avaliar e medir o desempenho e
progresso do projeto. (PMI, 2013). Na empresa estudada são utilizados principalmente o Índice de Desempenho de Custo (CPI) e o Índice de
Desempenho de Prazos (SPI).
 93

3.3 Kaizen Sobre Gestão de Projetos do DT da Empresa Analisada

A metodologia kaizen, como descrito na Seção 3.1, foi a escolhida para facilitar as
discussões a respeito da gestão de projetos no desenvolvimento tecnológico da empresa
analisada e foi a principal responsável por suportar a criação de um novo modelo de gestão,
baseado nos conceitos ágeis.
O kaizen foi presidido por um membro do time de administração de projetos do
desenvolvimento tecnológico e teve a participação de 17 membros seniores, desenvolvedores e
gestores de projetos de diferentes áreas do DT, e também do autor em questão.
A equipe kaizen, se reuniu durante uma semana, discutindo os desafios levantados na
fase de análise de problemas, as possíveis soluções disponíveis na literatura, de acordo com a
revisão realizada pelo autor, as lições aprendidas com a utilização de modelos híbridos de
gestão por outras áreas da empresa analisada e o cenário atual de gestão de projetos do
departamento tecnológico.
O resultado de toda esta discussão envolvendo a equipe kaizen foi a proposta de um
novo modelo de gestão de projetos, que englobou as boas práticas do guia PMBOK, gerenciadas
no sistema ERP PS-SAP, a corrente crítica, gerenciada no software CCPM e também o “scrum”
gerenciado no software JIRA, chamado de Modelo de Gestão Ágil para Desenvolvimento
Tecnológico (MGADT). O sumário dessa visão é apresentado na Figura 28.

Figura 28- Modelo de Gestão Ágil para Desenvolvimento Tecnológico (MGADT) (DT
EMPRESA ANALISADA, 2014).

A escolha do scrum, para representar os conceitos ágeis neste modelo proposto, se deu
pelo fato de ser um framework já utilizado na empresa analisada, com bons resultados,
aprovação das equipes e suporte de um software. Sendo assim entendeu-se que haveria uma
maior adesão ao modelo proposto se fossem adotadas ferramentas já amplamente divulgadas e
utilizadas pela empresa no desenvolvimento de produto (DIP).
 94

Foi tomado o devido cuidado para garantir a correta integração entre os três níveis de
gestão de projetos, sem que ocorressem sobreposições de informações. Para cada patamar uma
determinada metodologia foi adotada, e para cada metodologia, objetivo principal,
responsabilidades e resultados foram bem definidos.

3.4 Modelo de Gestão Ágil para Desenvolvimento Tecnológico (MGADT)

O modelo de gestão ágil para projetos de desenvolvimento tecnológico é um modelo

híbrido de gestão de projetos, escalonado em três níveis de gestão.
O primeiro nível do modelo é suportado pelas boas práticas do guia PMBOK e tem
como foco principal gerar visibilidade macro do andamento do projeto para a alta gerência.
Pode-se dizer que o centro de gravidade deste nível gira em torno dos custos do projeto, com o
controle de contratos, avançamento físico, milestones, gastos envolvidos, entre outros, e
permite a visibilidade dos indicadores CPI, SPI, TAC e BAC da metodologia EVM. O controle
é realizado dentro do SAP PS (software ERP utilizado pela empresa) e serve como base para a
tomada de decisão gerencial a respeito do projeto. A responsabilidade deste nível é da equipe
de gestão do projeto, não havendo envolvimento direto da equipe técnica neste nível. A Figura
29 mostra um esquema do primeiro nível de gestão do MGADT.

Figura 29- Primeiro nível do MGADT (DT EMPRESA ANALISADA, 2014).

O segundo nível é suportado pela metodologia corrente crítica e tem como objetivo
principal gerar visibilidade do andamento do projeto no nível de supervisão. O centro de
gravidade está no controle de prazos.
 95

Nesse nível é possível controlar a prioridade das entregas intermediárias, gerir o

andamento das mesmas, através da visualização do consumo do pulmão, e também os recursos
envolvidos. O ambiente CCPM, um software de corrente crítica corporativo, dá todo o suporte
para que esta gestão ocorra. A Figura 30 mostra o esquema do nível dois.

Figura 30- Segundo nível do MGADT (DT EMPRESA ANALISADA, 2014).

O terceiro nível é suportado pelo framework scrum e tem o foco nas entregas
operacionais do projeto. É possível fazer a gestão das entregas, estabelecer metas, verificar a
velocidade do projeto, gerar visibilidade e comunicação de curto prazo.
Como base para esse nível é utilizado o JIRA, um software coorporativo para métodos
ágeis, que já estava sendo utilizado pelo desenvolvimento integrado de produto da empresa
analisada (SANTOS, 2013). Na Figura 31 mostra-se o esquema do nível três.

Figura 31- Terceiro nível do MGADT (DT EMPRESA ANALISADA, 2014).

 96

A Figura 32 mostra o Modelo de Gestão Ágil para Desenvolvimento Tecnológico

(MGADT) em sua forma integrada, com os níveis interdependentes.

Figura 32- Modelo de Gestão Ágil para Desenvolvimento Tecnológico (MGADT) (DT
EMPRESA ANALISADA, 2014).

3.5 Integração Entre os Três Níveis de Gestão

A integração entre diferentes modelos de gestão de projetos é tema relevante na área, e

é tratada por diversos autores na literatura, como por exemplo, Cruz (2013), Conforto (2009) e
Amaral et al. (2011). Para que ela ocorra de forma eficiente é necessário que as informações
tenham fluência entre os diferentes métodos e que cada qual contribua de forma satisfatória
para compor o modelo global de gestão pretendido.
A melhor forma encontrada para integrar as diferentes metodologias utilizadas no
MGADT foi definir as funções e responsabilidades de cada metodologia, conforme mencionado
na Seção 3.3. A cada metodologia utilizada, foi dado um foco específico, para atender um grupo
específico de stakeholders do projeto. As entregas foram estruturadas e desdobradas de forma
que cada nível tivesse somente as informações necessárias para que o controle e monitoramento
do projeto fossem realizados.
 97

No primeiro nível são apresentadas as entregas acordadas contratualmente, ou seja, os

milestones principais do projeto e uma ou mais entregas globais correspondentes a todo o
projeto. Isto proporciona a alta gerência o acompanhamento do projeto em relação ao escopo
inicialmente definido, e também a visibilidade dos principais marcos e entregas do projeto.
No nível intermediário os milestones do projeto são desdobrados em entregas
intermediárias, de menor duração. São estabelecidas a duração, priorização e precedência de
cada uma das entregas, formando assim o cronograma de nível intermediário, disposto na forma
de um diagrama Gantt. Nesta etapa é aplicada a metodologia corrente crítica, evitando o
superdimensionamento do esforço necessário a cada entrega, estabelecendo o caminho crítico,
e também o pulmão do projeto.
Ainda no nível intermediário utilizou-se duas ferramentas da metodologia ágil: o
backlog e as user stories. Todas as entregas, mapeadas na corrente crítica, são transferidas para
o backlog do projeto no nível operacional, o que se equipara ao backlog de produto do
framework scrum. Para cada uma destas entregas tem-se uma breve descrição das
funcionalidades, características e objetivos. Esta fase é realizada juntamente com o gestor do
projeto e a equipe de desenvolvimento técnico, que dirime as dúvidas sobre o que deve ser feito.
Pode-se dizer que o gestor funcional ou um engenheiro experiente do projeto, no
desenvolvimento tecnológico da empresa analisada, atua como Product Owner, passando para
a equipe a visão do que agregará valor ao futuro cliente do projeto. Normalmente esta é uma
pessoa muito experiente que atuou na área técnica por diversos programas da empresa
analisada.
A partir do backlog de projeto, gerado no segundo nível, a cada iteração é criado um
sprintbacklog. As entregas intermediárias são desdobradas em atividades, com duração menor
do que duas semanas, que farão parte da iteração correspondente, no terceiro nível.
A atualização do tempo de duração real de cada entrega segue o caminho bottom-up, ou
seja, quando uma atividade é finalizada na iteração corrente, o tempo gasto para a execução
desta atividade é computado no gráfico de Gantt, tornando possível a análise do fever chart, e
também é computado no avançamento físico do projeto, no primeiro nível.
Na Figura 33 ilustra a integração entre os três níveis de gestão no modelo MGADT.
 98

Figura 33- Integração do Modelo de Gestão Ágil para Desenvolvimento Tecnológico (MGADT) (O Autor).
 99

3.6 Comparativo entre o MGADT e o IVPM2

Assim como o conceito abordado pelo método IVPM2 descrito em Amaral et al. (2011),
o modelo MGADT propõe uma gestão escalonada que aborda três níveis de controle e
acompanhamento do projeto. Este fato se dá principalmente por serem ambientes de
desenvolvimento de projetos similares, apesar do desenvolvimento de tecnologia envolver
incertezas bem maiores se comparadas ao desenvolvimento de produto inovador.
Pode-se assimilar o primeiro nível do MGADT ao modelo de fases e entregas do
IVPM2. Apesar de no método IVPM2 ser mais explicito a divisão entre as fases do projeto (Pré,
Desenvolvimento e Pós), a lógica dos milestones acordados contratualmente e representados
pelos WBEs (WBE 1, WBE 2.1, WBE 2.3 etc) no MGADT também segue a mesma linha
temporal de divisão. A diferença se dá quando o IVPM2 propõe gates de avaliação ao término
de cada sub-fase de desenvolvimento, o que não ocorre no MGADT. Outra diferença é que já
no modelo de fases e entregas, o IVPM2 propõe o desdobramento das atividades em entregas
intermediárias, enquanto no MGADT, esta fase só ocorre no nível 2, por se identificar que não
há necessidade de acompanhamento de todas as entregas por parte da alta gerência (Figura 34).

Figura 34- Nível 1 MGADT x Modelo de fases e entregas IVPM2 (O Autor).

No nível 2 do modelo MGADT ocorre o desdobramento dos milestones acordados

contratualmente em entregas intermediárias, que são priorizadas, planejadas com a aplicação
da metodologia corrente crítica, e dispostas em um diagrama Gantt. No método IVPM2 as
entregas intermediárias, já disponíveis no modelo de fases e entregas, são dispostas em um
quadro temporal (Painel visual de planejamento e controle de projetos) de acordo com sua
prioridade e planejamento (Figura 35). O objetivo é o mesmo, controle e acompanhamento das
 100

entregas intermediárias, porem realizado de maneira diferente sendo que no MGADT é

realizado via software e no IVPM2 via painel físico.

Figura 35- Nível 2 MGADT x Painel visual de planejamento e controle de projetos IVPM2 (O
Autor).

No nível 3 do modelo MGADT, propõe-se o acompanhamento das entregas diárias da

equipe com a utilização do framework scrum e uma interação de 2 semanas de duração. As
entregas intermediárias são desdobradas em trabalhos de menor espaço de tempo, a ser
executado pela equipe. Da mesma forma ocorre no IVPM2, mas nesse método não há nenhum
framework suportando esta gestão operacional, é utilizado o quadro de planejamento semanal
(Figura 36).

Figura 36- Nível 3 MGADT x Quadro de planejamento fino semanal IVPM2 (O Autor).
 101

Por fim, tanto o MGADT quanto o IVPM2 utilizam indicadores para realizar o
acompanhamento do projeto e também software para realizar um controle e histórico das
entregas realizadas durante a execução do projeto.

3.7 Pesquisa Survey

A aplicação da pesquisa tipo survey se deu através de um questionário baseado na escala

Likert, com cinco pontos e com ponto médio, para avaliar a percepção da equipe de projeto
relativa à aplicação do framework scrum, da metodologia corrente crítica e também da
integração entre as duas abordagens (Apêndice).
As afirmativas contidas no questionário foram concebidas de forma a cobrir os três
pilares: transparência, inspeção e adaptação (SCHWABER e SUTHERLAND, 2013), que
sustentam o scrum, e também a visibilidade de longo prazo gerada pelo acompanhamento do
fever chart da metodologia corrente crítica (ATREYA, 2012).
Para tratar o scrum foram abordados seguintes temas:
 Aumento da visibilidade do projeto: devido a utilização do quadro scrum, onde
é possível verificar o que toda a equipe está fazendo, a realização das reuniões
de planejamento, retrospectiva, diária e de revisão da iteração (Transparência).
 Aumento da comunicação e interação entre a equipe de projeto: devido
principalmente à realização frequente das reuniões previstas no scrum
(Transparência, inspeção e adaptação).
 Aumento da autonomia no projeto e facilidade na maneira de trabalhar: devido
a aplicação da auto-gestão, auto-organização e cobrança por entregas
intermediárias (Adaptação).
 Utilização do scrum conforme a literatura: devido as peculiaridades que existem
no ambiente de software e que não são encontradas no desenvolvimento
tecnológico, como tratado na Seção 2.11 (Transparência, inspeção e adaptação).
 Gestão visual: inspeção através da utilização de ambientes físicos para realizar
a gestão das entregas (Inspeção e adaptação).
Para tratar a metodologia corrente crítica foram abordados seguintes temas:
 Controle de prazos: gerados pela utilização tanto do pulmão do projeto, como
do acompanhamento das entregas intermediárias via gráfico Gantt.
 Visão das entregas do projeto: gerada pelo acompanhamento do gráfico Gantt.
 102

Com este questionário foi possível comparar: as diferentes visões entre os envolvidos
nos projetos, o novo modelo de gestão proposto neste trabalho em relação ao antigo e à simples
adoção do scrum. Também foi realizada uma comparação entre a aplicação do scrum, nos
projetos descritos, e a literatura, que serão apresentados no próximo capítulo.
 103

4 APLICAÇÃO, RESULTADOS E DISCUSSÕES

O caso de aplicação descrito nesta dissertação contempla a aplicação do Modelo de

Gestão Ágil para Desenvolvimento Tecnológico (MGADT) ao desenvolvimento tecnológico
da empresa analisada.
Para este estudo foram escolhidos projetos do portfólio do DT do ano de 2014, seguindo
os seguintes critérios:
 Projetos de baixo orçamento.
 Projetos de baixa complexidade.
 Equipes propensas a adoção dos conceitos ágeis.
 Projetos de curta duração.
 Projetos não críticos para a empresa.
 Projetos de diferentes áreas da engenharia.
Estes critérios foram criados para que novo modelo de gestão empregado no
desenvolvimento de projetos não afetasse a estratégia macro da empresa. Inicialmente quatro
diferentes projetos do portfólio tecnológico da empresa analisada satisfaziam todos os critérios,
sendo que dois projetos já estavam em andamento e outros dois estavam em fase inicial. Devido
a mudanças no portfólio da empresa, os dois projetos em fase inicial foram postergados sendo
que para o estudo em questão foram utilizados os projetos já em andamento, como será
apresentado a seguir.
Para questões de confidencialidade os projetos são sempre tratados com os respectivos
nomes Projeto A e Projeto B. Sendo que no Projeto A foi aplicado o modelo ágil MGADT,
enquanto que no Projeto B aplicou-se o scrum como complemento às práticas já existentes na
empresa. Vale salientar, que na empresa analisada, como explicitado na Seção 3.2.3, o scrum
só havia sido aplicado até então no desenvolvimento integrado de produtos (SANTOS, 2013),
sendo que a aplicação ao desenvolvimento tecnológico se deu de forma inicial.
Nas subseções seguintes são analisados e detalhados todos os aspectos da aplicação,
acompanhada pelo autor durante 4 meses, em cada um dos projetos, a partir da percepção da
equipe, do gestor funcional do projeto, do autor e também a comparação da realidade com a
literatura.
 104

4.1 Projeto A

O projeto A era um projeto com duração prevista de três anos e com a participação de
duas pessoas na equipe de desenvolvimento técnico. O projeto possuía interface com três outros
projetos em andamento, também do portfólio de desenvolvimento tecnológico da empresa
analisada, não possuindo, porém, demandas para aquisições ou participações externas ao
departamento de desenvolvimento tecnológico.
O projeto em questão foi basicamente orçado em homens-hora, e tinha como objetivo o
desenvolvimento de um código computacional (software) para ser aplicado em todo o ciclo do
desenvolvimento de produtos da empresa, na área de sistemas eletroeletrônicos. Não havia
nenhum projeto de desenvolvimento de nova aeronave na empresa analisada que pudesse ser
definido como cliente para os resultados desse projeto. O objetivo era atender a engenharia de
sistemas da empresa analisada em um desenvolvimento integrado de produto futuro.
Na prática o papel do cliente é representado pelo gestor funcional do projeto, um
membro sênior do desenvolvimento tecnológico da empresa analisada, com vasta experiência
no desenvolvimento de produto e responsável por garantir o andamento do projeto, e por
engenheiros, da engenharia de sistemas, envolvidos nos principais programas em
desenvolvimento na empresa analisada.
O desejo de aplicar o Modelo de Gestão Ágil para Desenvolvimento Tecnológico no
Projeto A partiu da própria equipe e se deu pela familiarização que o time de desenvolvimento
já possuía com as metodologias ágeis, sobretudo com o scrum, devido à utilização em projetos
anteriores, em outras empresas.
Este desejo foi aprovado e incentivado pelo gestor funcional do projeto, que tinha a
expectativa de elevar a motivação da equipe, conferir à equipe maior autonomia, aflorar o
sentimento de propriedade do projeto, e utilizar uma maneira de gerir o projeto, que, segundo
o próprio gestor, está sendo muito aceita pelo mercado atual.
Dentre as principais dúvidas, estava a compatibilidade do scrum com o método corrente
crítica e o sistema SAP-PS.
.
4.1.1 Modelo de Gestão Ágil para Desenvolvimento Tecnológico (Projeto A)

O Modelo de Gestão Ágil para Desenvolvimento Tecnológico, conforme descrito na

Seção 4.1, foi aplicado no Projeto A quando o mesmo já estava em desenvolvimento, acerca de
 105

4 meses após seu início. Nesta etapa, o projeto já tinha um escopo definido e já havia sido
desdobrado até o nível de atividades, que deveriam ser realizadas pela equipe de
desenvolvimento técnico.
Este escopo havia sido definido em reuniões durante a fase inicial do projeto, com a
participação dos principais stakeholders identificados, incluindo a equipe que realizaria o
desenvolvimento do projeto.
Devido a mudanças internas na empresa, esta equipe de desenvolvimento inicial foi
transferida de área e novas pessoas assumiram o projeto. Como resultado, os novos
desenvolvedores tiveram dificuldades em entender o que se esperava de cada atividade definida
pela equipe anterior. Não existia um sentimento de propriedade dessa nova equipe pelo projeto,
uma vez que a equipe atual não havia participado do planejamento, e o andamento se dava de
forma considerada confusa.
Inicialmente, o controle do projeto era concentrado no sistema empresarial SAP
(modulo PS), com o emprego das boas práticas para a gestão de projetos sugerida pelo guia
PMBOK, acompanhamento mensal dos índices SPI, CPI e também do cronograma do projeto.
A alta gerência tinha o acompanhamento de cada pequena entrega do projeto. Sendo
possível visualizar o tempo gasto para realizar cada uma das atividades previstas, a comparação
entre o tempo estimado e o real executado, os custos envolvidos e o responsável pela entrega
de cada atividade.
A cada uma destas pequenas entregas também havia sido aplicada na fase de
planejamento do projeto, a metodologia corrente crítica. Fazia-se o controle do fever chart, ou
pulmão, no software empresarial CCPM, o que duplicava a informação já disponível no PS-
SAP.
Tomando como base o MGADT, proposto para a empresa analisada, resultante do
kaizen realizado no desenvolvimento tecnológico (Seção 3.3), a primeira grande mudança na
forma de gerir o Projeto A se deu nas informações disponibilizadas para a alta gerência, via
sistema PS-SAP.
Com o objetivo de simplificar a visibilidade do projeto, gerada para a alta gerência,
foram substituídas as pequenas entregas controladas no PS-SAP por apenas uma entrega geral
principal, responsável por mostrar o avançamento do projeto através da porcentagem de
trabalho realizado em relação ao escopo. Foram definidos também milestones, para se ter o
controle das principais entregas acordadas no contrato (MAP do projeto). Continuou-se com o
monitoramento global dos projetos via indicadores SPI, CPI e com o controle e monitoramento
 106

das diversas áreas de conhecimento do guia PMBOK (Por exemplo: custos, riscos, qualidade,
aquisições etc.). A equipe de desenvolvimento tem pouca atuação neste nível de gestão.
O escopo do projeto foi o replanejado excluindo-se o último nível do WBS antigo,
aquele que definia as atividades micro necessárias para cumprir o escopo total do projeto.
Elevou-se o escopo inicial ao nível de entregas intermediárias, ou seja, entregas com duração
superior a uma semana de trabalho. Como exemplo de entrega intermediária está a revisão e
estudo bibliográfico.
À essas entregas intermediárias o método foi aplicado corrente crítica. Estabelecida as
prioridades e precedência, o monitoramento e controle passaram a ser realizado através do
acompanhamento do feverchart, utilizando-se o software CCPM. A equipe de desenvolvimento
técnico ficou responsável por atualizar o tempo gasto em cada entrega realizada, sendo possível
assim a comparação com o tempo previsto inicialmente.
A cada uma das entregas intermediárias foi atribuída uma estória do que se esperava
como resultado da entrega. Isso deu uma direção ao trabalho operacional, assim como proposto
por Kent Beck no Extreme Programming (BECK, 2000). A equipe passou a ser cobrada pelas
entregas intermediárias, não importando o como chegariam àquelas entregas. Isto trouxe maior
confiança e autonomia no trabalho operacional diário.
A implantação do aspecto de agilidade se deu na próxima etapa. Foi definida pela equipe
uma iteração com duração de dez dias úteis, ou seja, duas semanas de trabalho. Sendo que as
reuniões de retrospectiva, revisão e planejamento do sprint ocorreriam de forma sequencial no
mesmo dia e teriam uma duração de cerca de duas horas, com a participação da equipe técnica,
do gestor do projeto e do gestor funcional.
Foi estabelecida também uma reunião semanal técnica em que seriam tratados todos os
assuntos do projeto. Nesta reunião, muitas das vezes, estariam presentes os engenheiros de
sistemas da empresa analisada que, nesse caso, fazem o papel de cliente, e cujo objetivo é
criticar os resultados e discutir soluções a fim de criar um software que fosse realmente
operacional para os novos projetos. Vale salientar que a cada sprint deverão ocorrer duas
reuniões técnicas.
A reunião diária não foi adotada pela equipe, uma vez que o projeto possui somente dois
desenvolvedores que sentam lado a lado, e a conversa sobre o trabalho, segundo os mesmos,
flui de forma natural, não demandando qualquer instrumento extra para esse fim.
Dentre os artefatos do scrum a equipe adotou o quadro kanban e burndown chart, ambos
disponíveis no software corporativo JIRA. É neste software que um dos desenvolvedores
realizaria toda a atualização da iteração com a corrente crítica. Ainda não é utilizada pela equipe
 107

uma ferramenta que integre o software JIRA ao CCPM, sendo que ficam a cargo da equipe
atualizar os dois ambientes de forma manual.
Tomando como base a equipe scrum, foi definido que o product owner seria
representado pelo próprio gerente do projeto, e nas reuniões técnicas, pelos engenheiros dos
diversos programas da empresa analisada. O papel do scrummaster não é realizado por
nenhuma pessoa em específico no projeto, ou mesmo no DT.
Um dos desenvolvedores, que ocupa a função de gerente de projeto seria o responsável
pelas atualizações por garantir que as reuniões sejam realizadas e pela gestão operacional do
trabalho, mas os impedimentos são tratados por cada um dos desenvolvedores de forma
separada, ficando a cargo dos mesmos buscar as informações e dar sequência ao trabalho. Note-
se que equipe, no caso desse projeto, era composta pelos dois desenvolvedores já descritos
anteriormente.
A formação do sprint backlog (conjunto de entregas da iteração correspondente) se daria
a partir das entregas monitoradas pelo feverchart. Cada uma das entregas intermediárias seria
desdobrada pela equipe em entregas menores, de menor duração, entre 2 e 5 dias. Fixada a
duração da iteração, o conjunto de entregas, cujo tempo estimado somado seria igual a duas
semanas, compõe então o sprint backlog. A priorização seria resultante da corrente crítica e
qualquer eventual ajuste seria realizado pela equipe durante o planejamento.

4.1.2 Questionário Projeto A

Na Tabela 7 são apresentadas as respostas do supervisor funcional (Representado pela

inicial do nome: M) e também dos integrantes do time de desenvolvimento (Cada qual
representado pela inicial do nome: V e E, respectivamente) ao questionário aplicado conforme
descrito na Seção 3.6.
Tabela 7 – Respostas do questionário para o projeto
 108

Fonte: O Autor

A partir da Tabela 7, é possível perceber que dois integrantes do time de projeto apontam
para o aumento da interação e comunicação entre a equipe de desenvolvimento, maior
autonomia na execução das atividades diárias, com a implementação do framework scrum no
terceiro nível de gestão.
Ambos também concordam que o scrum não foi aplicado no projeto seguindo a
descrição contida na literatura, e que não há necessidade para utilizar quadros físicos para
monitoramento e controle complementando o software JIRA.
Em relação à metodologia da corrente crítica no segundo nível de gestão do modelo
proposto, o time de desenvolvimento destaca que a aplicação se deu de forma satisfatória,
ajudando a equipe a controlar melhor os prazos durante a execução, e proporcionando uma
melhor visão das entregas relativas ao escopo do projeto.
Todas estas características descritas foram destacadas pelos membros, concordando e
concordando fortemente com as afirmativas realizadas no questionário.
Apesar disso os dois integrantes discordaram quanto ao aumento da visibilidade,
melhoria no cumprimento do escopo e melhoria da divisão das atividades entre os membros do
time do projeto sendo que, enquanto um apontava de forma neutra, ou mesmo discordando, o
outro apontava no caminho inverso concordando com a afirmativa.
Pôde-se verificar que o scrum impactou de forma positiva o time de desenvolvimento,
quando comparado à utilização da corrente crítica, sendo que a integração entre os dois níveis
se deu de forma bastante satisfatória.
 109

Também ficou evidente no questionário a posição do time no que diz respeito à

necessidade de continuidade da aplicação em níveis do scrum e da corrente crítica,
aprimorando-se para o ambiente de desenvolvimento tecnológico.
O gestor funcional do projeto demonstrou uma visão mais conservadora quando
questionado sobre os benéficos gerados pela implementação do MGADT. Segundo ele, o scrum
não aumentou ou melhorou a comunicação entre a equipe de desenvolvimento, a visibilidade e
o cumprimento do escopo do projeto, e a forma de trabalhar do time de execução. Se mantendo
neutro em relação a estas características.
Apesar disso afirma que o framework aumentou a interação, deu maior autonomia à
equipe do projeto e melhorou a divisão das atividades entre os membros. A corrente crítica, e
consequentemente o acompanhamento do pulmão do projeto, proporcionou controlar melhor
os prazos, e integrou de forma satisfatória com o terceiro nível de gestão.
O gestor partilha da afirmativa de que o scrum não foi aplicado no projeto seguindo a
descrição e formalização contida na literatura, e que não há necessidade de utilizar quadros
físicos, para monitoramento e controle, complementando o software JIRA. Na sua visão a
manutenção e os ganhos proporcionados pela metodologia corrente crítica foram maiores e mais
importantes do que aquelas produzidas pela introdução do framework scrum. O que fica claro
quando concorda em preservar a corrente crítica e se sente neutro em relação ao framework.
Comparando a visão da equipe em relação à visão do gestor do projeto, o que se percebe
é que a equipe se sentiu mais confortável utilizando o scrum, e o gestor viu mais resultado na
aplicação da metodologia corrente crítica.
Como melhoria, a equipe sugere a utilização do framework de forma amplificada, sendo
adotado para o planejamento de todo o projeto, tornando o escopo mais flexível e o
planejamento, de alto nível, de forma incremental. Já o gestor se preocupa com uma integração
automática entre os softwares JIRA e CCPM no sentido de diminuir a carga administrativa.

4.2 Projeto B

O Projeto B é um projeto com duração prevista de dois anos, e com a participação de

três pessoas dedicadas na equipe de desenvolvimento. O orçamento do projeto previa a
aquisições de softwares, custos com homem hora para execução de atividades internas do
projeto, acompanhamento de atividades com parceiros, e também execução e acompanhamento
de atividades relacionadas a ensaios.
 110

Esse projeto envolve parceria externa com um instituto de ciência e tecnologia de uma
universidade brasileira, uma empresa de consultoria e com parceiros dentro da própria empresa
analisada.
O objetivo do Projeto B é o estudo de ruído de cabine de aeronaves, para atender a uma
demanda da aviação executiva da empresa analisada. O estudo parte de uma demanda do
mercado executivo, mas os resultados deste projeto não necessitam se restringir apenas a este
nicho da aviação, podendo ser utilizados nas demais aeronaves, caso a relação entre o valor
percebido pelo cliente e os custos envolvidos seja positiva.
Na empresa analisada a área responsável por ruídos não está vinculada a nenhum
programa de desenvolvimento de forma direta. Ela é diretamente ligada à área central de
engenharia (internamente chamada Engenheiro Chefe) e tem a função de suprir toda a demanda
da empresa em qualquer projeto em andamento. Desta forma, o Projeto B tem como cliente a
própria engenharia da empresa, que será a responsável por aplicar as novas tecnologias em
novos produtos.
Diferentemente do Projeto A, no Projeto B não foi aplicado o MGADT. Durante o
primeiro ano de execução do projeto o líder da área funcional de ruídos teve a ideia de
implementar o scrum em todos os projetos da célula, de forma independente. Sendo assim a
equipe do Projeto B, baseada em artigos sobre o assunto, buscas na internet e conversas com
outras áreas da empresa analisada, implementou o scrum de forma espontânea nos seus projetos.
Vale salientar que nenhum dos três membros da equipe havia tido alguma experiência anterior
com métodos ágeis, e que não ocorreu nenhum treinamento para direcionamento da equipe.
Esta implementação também não envolveu nenhuma mudança na forma como a gestão
global do projeto era conduzida. Foi apenas adicionado o scrum no nível operacional,
mantendo-se o sistema PS-SAP gerando visibilidade de todas as entregas do projeto, assim
como o CCPM, no nível intermediário, com foco no controle de prazos.

4.2.1 Scrum Projeto B

No processo de planejamento do Projeto B, a equipe também utilizou como referência

as boas práticas do guia PMBOK. Definido os milestones a equipe, juntamente com o gestor
funcional do projeto e todos os stakeholders identificados, desdobrou o escopo do projeto até o
nível de entregas intermediárias, formando-se o WBS. Foi tomado o devido cuidado para que
não houvesse excesso de detalhamento nas entregas.
 111

Estas entregas foram priorizadas e sequenciadas em um diagrama Gantt e aplicando o

método corrente crítica. Foi mapeado o caminho crítico e gerado o pulmão, que passou a ser
monitorado no programa empresarial CCPM.
As entregas monitoradas pelo método corrente crítica, também foram inseridas no
ambiente PS-SAP. Assim como também as informações contendo os índices SPI, CPI, TAC e
BAC, gestão de riscos, parceiros, orçamentos, entre outros, compunham a visibilidade do
projeto para a alta gestão do departamento de desenvolvimento tecnológico.
Diferentemente do projeto A, foram estabelecidos três gates durante o projeto,
internamente chamados de REFAP (Revisão de Fase de Projeto). O objetivo destes gates era
passar, juntamente com todos os stakeholders envolvidos, uma visão global do projeto relativa
ao que já tinha sido realizado e quais as aspirações futuras (das próximas fases), deixando todos
os envolvidos alinhados com o rumo do projeto. Estas reuniões envolveram um maior número
de especialistas, de diferentes áreas, para que as grandes decisões do projeto fossem realizadas.
O scrum foi inserido de forma a não alterar o planejamento e o WBS já acordados e
priorizados inicialmente. Assim como no Projeto A, o Projeto B utilizou as entregas, já
monitoradas no método corrente crítica, como product backlog. A priorização, e também a
estimativa de horas, não foi revista, permanecendo a mesma já acordada anteriormente durante
a fase de planejamento.
Os parceiros externos do projeto não foram inseridos no scrum do projeto B. Seu
monitoramento ficou a cargo do gerente de projeto, que realiza uma reunião semanal com o
parceiro prioritário (aquele que afeta diretamente o dia-a-dia do trabalho), a fim de tratar o
andamento do projeto, os custos, prazo, entraves, entrega etc. Nesta reunião é revisto todo o
cronograma acordado com o parceiro e, caso haja necessidade de alguma alteração, ela é
realizada em comum acordo com a equipe de desenvolvimento. As entregas realizadas pelos
parceiros normalmente afetam bastante o andamento da equipe de projeto.
Assim como no projeto A, para o projeto B a duração do sprint também foi definida
como duas semanas corridas de trabalho. Sendo que as reuniões de retrospectiva, revisão e
planejamento do sprint ocorrem de forma sequencial no mesmo dia, com a participação da
equipe do projeto e do gestor funcional do projeto. A reunião diária também não foi adotada
pela equipe, igualmente pelo motivo da equipe já estar co-localizada.
Excluindo-se as reuniões de REFAP, das demais reuniões só participam: o gestor do
projeto, o gestor funcional e a equipe de desenvolvimento.
Dentre os artefatos do scrum, a equipe utiliza o quadro kanban e burndown chart.
Inicialmente o controle destes dois artefatos era realizado direto na parede com post-its e
 112

quadros desenhados. Ali também se davam todas as reuniões. Com o decorrer do projeto houve
uma desmotivação por parte da equipe com esse método manual, que acabou por adotar o
software corporativo JIRA.
Toda a atualização da iteração corrente, o monitoramento e controle do backlog
passaram a ser realizados através do software JIRA, por um dos membros da equipe. A
atualização do CCPM e também do PS-SAP é realizada pela própria equipe, sendo que o projeto
B, assim como o projeto A, também não se utiliza nenhuma ferramenta que integre os
aplicativos de software JIRA, PS-SAP e CCPM.
Com base na equipe scrum, o product owner é representado pelo gestor funcional do
projeto, e nas reuniões de REFAP, por todos os especialistas envolvidos. Assim como no caso
do projeto A, no projeto B o papel do scrummaster também não é realizado por nenhuma pessoa
em específico no projeto, ou mesmo no DT.
Um dos desenvolvedores, que ocupa a função de gerente de projeto, é o responsável
pelas atualizações do projeto nos sistemas corporativos utilizados, por garantir que as reuniões
sejam realizadas e pela gestão global e operacional do trabalho. Já os impedimentos detectados
são tratados por cada um dos desenvolvedores de forma separada, ficando a cargo dos mesmos
buscar a informação e dar sequência ao trabalho. A equipe é composta pelos três
desenvolvedores dedicados, conforme já descritos.
A formação do sprint backlog (conjunto de entregas da iteração correspondente) se dá
a partir das entregas monitoradas pelo CCPM e também pelo PS-SAP. Cada uma das entregas
intermediárias é desdobrada pela equipe em entregas menores, de duração variável. Fixada a
duração da iteração, o conjunto de entregas, cujo tempo estimado somado é igual a duas
semanas, irão compor o sprint backlog. A priorização, conforme já explicado, é resultante da
corrente crítica e qualquer eventual ajuste é realizado pela equipe durante o planejamento.

4.2.2 Questionário Projeto B

Na Tabela 8 são apresentadas as respostas dos integrantes do time de desenvolvimento

(Cada qual representado pela inicial do nome: D, I e S, respectivamente) ao questionário
aplicado conforme descrito na Seção 3.6. Para este projeto em questão optou-se por não
submeter o questionário ao gestor funcional, pois diferentemente do gestor do projeto A, a
atuação do mesmo no projeto se dá de forma mais distante.
 113

Tabela 8 – Respostas do questionário para o projeto B

Fonte: O Autor

Na Tabela 8 observa-se que um dos membros do time se sentiu neutro em relação a

maior parte das afirmativas realizadas. Destacou que discorda da utilização de quadros físicos,
visuais, e que o projeto seguiu o scrum conforme descrito na literatura. Porém concorda que
tanto o scrum quanto a metodologia corrente crítica levou resultados satisfatórios ao projeto
devendo ser mantidos e aprimorados para o ambiente de projetos de desenvolvimento
tecnológico da empresa analisada.
Já os outros dois membros do time destacaram que a implementação do framework
scrum proporcionou aumento na interação e comunicação do time, contribuiu para o
cumprimento do escopo do projeto e melhorou a divisão de atividades no projeto, o que trouxe
resultados satisfatórios durante a execução do projeto.
Por outro lado, discordaram quanto ao scrum simplificar a maneira de trabalhar,
proporcionar maior autonomia na execução do trabalho e em relação a utilização de quadros
físicos, sendo que enquanto um concordou com a afirmativa, o outro se sentiu neutro.
 114

Para ambos os membros não foram verificados o aumento da visibilidade no projeto e

aplicação do framework como descrito na literatura.
A equipe foi unânime em ressaltar a necessidade de continuidade da aplicação do scrum
nos projetos, mas com adequação ao ambiente de desenvolvimento tecnológico da empresa
analisada.
Em relação à metodologia corrente crítica foi verificado que a equipe de projetos não
sente a necessidade ou percebe ganho algum com a utilização da mesma. Todas as afirmativas
que a envolviam, ou foram discordadas, ou interpretadas como neutro.
No projeto B, diferentemente do projeto A, o gestor do projeto é um próprio membro da
equipe de projetos. Logo sua visão já foi retratada no questionário respondido.
Finalmente a equipe do projeto B sugere como melhoria, a utilização do CCPM,
aplicado ao portfólio de projetos e não diretamente a um projeto em si, mantendo o scrum para
a gestão diária das atividades.

4.3 Modelos de Gestão Aplicados aos: Projeto A x Projeto B x Modelo de

Gestão Anterior

Comparando-se os resultados e as discussões relativas à gestão dos projetos A e B com

a forma de gerir projetos até então utilizada no desenvolvimento tecnológico da empresa
analisada, percebe-se que a incorporação de aspectos associados a metodologias ágeis
proporcionou uma maior flexibilidade à equipe de projeto, que passou a ser cobrada por
entregas e não mais por atividades, como era realizado anteriormente.
O escopo passou a ser desdobrado até um nível superior àquele no qual se costumava
definir o dia-a-dia da equipe de projeto. Isto proporcionou uma melhor divisão de tarefas entre
o time, um maior senso de propriedade do projeto e o desenvolvimento da autogestão.
O scrum possibilitou ainda uma melhoria da integração e comunicação entre o time de
projeto, e foi de forma unânime aprovado pelas equipes de desenvolvimento. Apesar de o gestor
do projeto A, não concordar com esta visão, conforme mostrado na seção anterior.
O aumento da visibilidade, e autonomia de trabalho foi vista de forma divergente entre
os dois projetos, não apontando para ganhos nesta área devidos somente à introdução do scrum.
Ambas as equipes destacaram que estão longe de cumprir à risca o framework, assim
como ele é descrito por Schwaber e Sutherland (2013), principalmente devido ao ambiente onde
 115

os projetos estão inseridos na empresa analisada, mas que os ganhos gerados pelos scrum devem
ser mantidos, aprimorando-se o framework para o dia-a-dia do desenvolvimento tecnológico.
Comparando mais especificamente o MGADT proposto na empresa analisada, em
relação à simples aplicação do scrum, complementando o modelo de gestão antigo, verificou-
se um maior ganho, ou melhor, contribuição para o sucesso do projeto, com a nova maneira de
gerir, proposta no kaizen, discutido na Seção 3.3.
Trabalhar em níveis de gestão proporcionou individualizar as informações contidas em
cada camada, de forma a atingir um determinado grupo de pessoas envolvidas no projeto.
As informações passaram a ser desdobradas entre os níveis de gestão, sendo que não
havia cópia, ou mesmo sobreposição de informações. Isto resultou em uma maior aprovação do
segundo nível (corrente crítica) pela equipe do projeto A, uma melhor integração entre os níveis
e o próprio fluxo de informações ficou mais simples e prático.
No primeiro nível, PS-SAP, a equipe passou a ter pouca influência, sendo que a
atualização, deste ambiente, ficou a cargo dos administradores do projeto, somente com
informações chaves para a alta gerência realizar o seu trabalho.
Por fim, foi verificada nos dois projetos, uma necessidade maior de flexibilidade no
escopo de projeto, inicialmente acordado. Uma característica da gestão ágil que é enfraquecida,
quando se utiliza o PMI e a corrente crítica.

4.4 Diferenças entre a Aplicação do Scrum na Empresa Analisada e a

Literatura

O manifesto ágil, assim como as principais publicações referentes aos conceitos ágeis,
nos mostra que a colaboração com o cliente é mais importante do que negociação de contratos,
e é central para o sucesso dessa abordagem. Na visão ágil surge a ideia do cliente como
“projetista” (AMARAL et al., 2011), presente e atuante no desenvolvimento do projeto, em
todas as suas etapas.
Nessa nova filosofia o cliente é a peça fundamental para o planejamento e revisão das
iterações. É ele quem recebe um produto funcional a cada final de iteração, faz os testes e com
auxílio da equipe ágil, entende suas reais necessidades. Só assim, os apoiadores do manifesto
ágil acreditam, é possível agregar e entregar valor ao usuário, chegando-se ao melhor resultado
de projeto, para um determinado prazo de execução.
 116

No desenvolvimento tecnológico da empresa analisada o representante do cliente,

sobretudo os engenheiros dos diversos programas de desenvolvimento da empresa, nem sempre
puderam estar presentes nas reuniões de alinhamento do projeto, em especial devido a
competição existente entre a demanda imposta pelos vários produtos em desenvolvimento, e o
desenvolvimento tecnológico. O desenvolvimento de um novo produto resulta em lucro direto
para a empresa, sendo, portanto, sempre tratado de forma prioritária em relação aos projetos de
desenvolvimento tecnológico. Uma consequência dessa realidade é que a mesma acaba por
elevar a taxa de retrabalho e desvios cometidos durante os projetos de desenvolvimento
tecnológico pré-competitivo.
No projeto A, a falta de disponibilidade de especialistas da engenharia de sistemas em
algumas das reuniões técnicas, ou mesmo da presença nas reuniões que compõe os eventos do
scrum, devido principalmente à concorrência com os programas em desenvolvimento na
empresa, culminou em retrabalho, desperdício de tempo e atrasos no projeto.
Já no projeto B, como os três desenvolvedores fazem parte da equipe de ruídos que
presta serviços aos programas da empresa, equipe esta pequena se comparada a outras equipes
do desenvolvimento, este problema foi mitigado. Houve uma melhor e maior interação com o
cliente final do projeto, se comparado ao projeto A.
Apesar disto em nenhum dos dois projetos foi visto um cliente “projetista”, conforme
suposto pela teoria ágil, que acompanhasse todo o desenvolvimento do projeto, de forma
atuante. Sabe-se que esta prática pode levar ao uso parcial da tecnologia em projetos futuros, a
adição de funcionalidades que não agregam valor ao cliente, e mesmo retrabalhos durante o
desenvolvimento tecnológico.
Tomando como referência o framewok scrum, o scrummaster tem um dos principais
papeis na ferramenta. Ele é o responsável por garantir uma equipe focada no trabalho e seguindo
à risca toda a estrutura processual do scrum. A falta desta pessoa, responsável por tratar os
impedimentos, acarreta uma sobrecarga na equipe, que além de realizar as atividades para
cumprir as entregas deve, sempre que houver algum entrave, parar e buscar todas as
informações necessárias para dar continuidade ao trabalho.
Segundo o Guia do Scrum (SCHWABER; SUTHERLAND, 2013) o scrummaster é
fundamental para que a equipe técnica mantenha o foco sempre no trabalho. As distrações
levam a perda de rendimento da equipe, que poderá não entregar o que prometeu no
planejamento.
Tanto no projeto A, como no projeto B, parte do atraso observado pode ser justificado
por dois pontos principais, inerentes à implementação incompleta do scrum no
 117

desenvolvimento tecnológico, a falta do scrummaster e a necessidade de um especialista

executar determinada atividade.
No projeto B, a falta do scrummaster foi ainda mais prejudicial, principalmente na
interface com os parceiros. Toda esta interface é realizada pela equipe técnica, que necessita
parar o desenvolvimento para discutir o andamento do projeto com os parceiros, alinhar
objetivos e datas.
O fato de se ter uma equipe altamente técnica vai de encontro ao conceito ágil de equipes
multifuncionais, que possuem todas as habilidades necessárias, enquanto equipe, para criar o
incremento do produto (SCHWABER e SUTHERLAND, 2013).
No ambiente de projetos técnicos como o da empresa analisada é difícil ter uma equipe
onde os membros sejam polivalentes. Normalmente cada projeto é composto por especialistas
em diferentes áreas, formação e foco de trabalho, não cabendo, portanto, o conceito de que
todos os membros sejam capazes de pegar novas tarefas à medida que sejam liberados da
anterior.
De fato, tanto no projeto A quanto no B verificou-se que cada um dos membros da
equipe tinha familiaridade com um determinado assunto, sendo que as entregas, durante o
planejamento, já eram direcionadas para um, ou para o outro membro do time. Apesar dos
membros poderem se ajudar mutuamente não era algo comum, se um membro acabasse todas
as suas entregas de um sprint, uma entrega da iteração posterior era puxada, mesmo que o
backlog não estivesse completo, indo de encontro com os princípios ágeis.
A característica técnica da equipe também resulta no fato de não sentirem a necessidade
de realizar as reuniões diárias cruciais para aumentar a integração e comunicação entre os
membros da equipe. Cada pessoa se sente responsável por uma parte do projeto, aquela na qual
é especialista, muitas vezes não querendo opinar e nem mesmo se informar sobre as outras áreas
técnicas do projeto. Isto afeta consideravelmente a comunicação no projeto, consequentemente
os resultados, mesmo com a equipe estando co-localizada no mesmo ambiente de trabalho.
Outra restrição intrínseca ao desenvolvimento tecnológico da empresa analisada é o
tamanho das equipes de desenvolvimentos. No scrum como exemplo fala-se de três a nove
pessoas, enquanto no Projeto A temos apenas dois desenvolvedores e no projeto B temos três.
Segundo Schwaber e Sutherland (2013) menos de três integrantes na equipe diminui a iteração,
resulta em um menor ganho de produtividade e podem ser encontradas restrições de habilidades
durante a iteração, exatamente o que foi observado nos projetos analisados.
Em relação às entregas acordadas para fazerem parte do sprint, segundo Broad (2013),
elas devem ter a duração máxima de um dia de trabalho, para uma pessoa. Desta forma,
 118

controla-se o andamento da equipe pelas entregas realizadas dia-a-dia. E este resultado é

apresentado no burndownchart da iteração.
O que se viu na aplicação real, tanto no projeto A quanto no B foi certa dificuldade, ou
mesmo barreira por parte da equipe, para desdobrar as entregas em um dia de duração. Elas
foram desdobradas em unidades de dois a cinco dias, o que dificulta o monitoramento via
burndownchart dentro da iteração.
Este gráfico, burndownchart, passou a ser meramente um resultado automático do
software JIRA, perdendo sua função de monitoramento e controle. O decaimento do gráfico,
por vezes, se encontrava estável durante a interação, com declínios acentuados, principalmente
ao fim dos sprints. Não foi possível calcular a velocidade da equipe, comparar os gráficos de
diferentes iterações e nem tampouco tirar conclusões a respeito do mesmo.
O burndownchart também ficou muito dependente da forma como a equipe atualizava
o software JIRA. Como as atividades duravam mais de um dia, a atualização da iteração não
era diária, o que impactava na visibilidade gerada, tanto pelo gráfico, quanto pelo CCPM, via
pulmão de projeto.
No projeto B houve também certa dificuldade da equipe em lidar com os três níveis de
gestão em três ambientes diferentes, PS-SAP, CCPM e JIRA. Pelo fato das informações
contidas no ambiente CCPM, no caso desse projeto, ser uma cópia das informações mantidas
no PS-SAP, a equipe não viu motivo em utilizar as duas plataformas, pelo trabalho e pela
ineficiência. O fever chart passou a ser atualizado mais por uma formalidade do que para
melhorar ou mesmo monitorar o andamento do projeto.
Por último temos a parte da documentação. Segundo um dos princípios ágeis, software
(produto) em funcionamento é mais importante que documentação abrangente. Por sua vez, em
função da empresa analisada ser uma empresa aeronáutica, pautada por documentações
detalhadas e controle rígido de documentação, devido às exigências de órgãos reguladores, ela
preza tradicionalmente por uma boa e árdua documentação em seus projetos. Os
desenvolvedores são os responsáveis pela execução desta atividade o que acaba por elevar as
horas demandadas de trabalho administrativo no projeto.

4.5 Visão/Crítica do Autor

O questionamento que pode ser feito ao abordar conceitos ágeis em uma empresa como
a que foi foco de estudo nessa dissertação é a necessidade de se ter espoco, prazo e orçamento
 119

na sua totalidade definidos para que o projeto possa ser aprovado para a execução. Esta prática,
sugerida pelos métodos tradicionais, e adotada pela empresa analisada como um todo, é
contraditória ao manifesto ágil, que destaca a resposta às mudanças, como sendo mais
importantes do que seguir um plano pré-estabelecido e congelado desde o início.
O estudo realizado pelo Standish Group (2013) detectou que apenas 20% dos requisitos,
acordados na fase inicial de um projeto são utilizados com frequência, e que 50% dos atributos
do produto, desenvolvidos a partir desses requisitos nunca, ou quase nunca, serão utilizados
pelos consumidores.
No sentido de diminuir riscos e incertezas, e consequentemente o escopo, envolvidos
nos projetos tecnológicos da empresa analisada, há uma tendência do departamento de
desenvolvimento tecnológico em dividir uma determinada tecnologia em diversos projetos de
curta duração, de um a dois anos, que abordam diferentes níveis de maturidade, aspectos ou
partes da tecnologia em questão, assim como proposto no desenvolvimento por stage-gates
descrito na Seção 2.13.
Desta forma a cada estágio completo, faz-se um gate onde é verificado o que foi
realizado, as dificuldades encontradas, onde se pretende chegar com a tecnologia estudada, a
viabilidade econômica do projeto e é definido se o projeto passará, ou não, para o próximo
estágio de desenvolvimento.
Mesmo trabalhando em projetos de curta duração, as incertezas ainda predominam na
fase inicial dos projetos, dificultando a definição de um escopo completo e detalhado. Assim
como destacado na Seção 2.2, no início do projeto não se tem uma visão clara sobre o que a
tecnologia estudada pode proporcionar a um novo produto na empresa.
A falta de um cliente final para a tecnologia a ser desenvolvida torna essa definição
ainda mais complexa nesse tipo de projeto. Pode haver casos em que a tecnologia, quando de
fato utilizada no desenvolvimento de uma aeronave, esteja desenvolvida além do necessário,
ou também o caso contrário em que ainda falta desenvolvimento, o que pode nos remeter a
sensação de dinheiro perdido.
Trabalhar com o escopo variável, em que inicialmente tem-se uma visão geral sobre as
entregas do projeto e que à medida que o projeto se desenvolve em cada iteração, há um maior
detalhamento das entregas, pode ser a solução para diminuir o reflexo das incertezas no escopo
inicial proposto, assim como abordado pelos princípios ágeis (BROAD, 2013; SCHWABER,
1997; TAKEUCHI; NONAKA, 1986).
O fato dos projetos de desenvolvimento tecnológico envolverem principalmente, mas
não exclusivamente, gastos com mão de obra e consultoria, pode facilitar esta forma de
 120

trabalho, uma vez que se um projeto não faz mais sentido econômico para a empresa, a mão de
obra pode ser realocada e o projeto finalizado.
Broad (2013) afirma que para esta forma de trabalho, com escopo variável, funcionar
de forma satisfatória é necessário que exista uma relação de absoluta confiança entre o cliente
e o fornecedor, no caso específico entre o desenvolvimento tecnológico e desenvolvimento de
produtos. Há de haver uma mudança de filosofia de trabalho da empresa.
Fato é que quanto maior for o envolvimento da área, programa ou departamento ao qual
a tecnologia se destina, não só na parte inicial do projeto, mas, sobretudo, no decorrer do
desenvolvimento, seguindo a ideia de cliente projetista proposta pelos autores ágeis (AMARAL
et al., 2011), mais rico será o resultado e valor entregue pelo projeto.
Finalizando o capítulo 4, os resultados e as discussões retiradas do caso de aplicação
foram positivos em relação à utilização de ferramentas ágeis na gestão de projetos de
desenvolvimento tecnológico pré-competitivo. Como se pôde perceber, ainda existem muitos
gaps importantes para serem trabalhados a fim de se ter um modelo que possa ser disseminado
por todo o desenvolvimento tecnológico da empresa analisada. Abre-se então no capítulo 5, as
conclusões deste trabalho.
 121

5 CONCLUSÕES

A presente pesquisa abordou um estudo sobre gestão ágil de projetos em suas principais
vertentes presentes na literatura, a formulação de metodologias híbridas, mesclando conceitos
ágeis e tradicionais e sua aplicação em projetos de elevado grau de incerteza (AMARAL et al.,
2011), projetos altamente regulamentados (FITZGERALD et al., 2013) e projetos de produtos
complexos (SANTOS, 2013).
Dentre as diversas abordagens dos conceitos ágeis existentes, observou-se que em
comum essas teorias pretendem trazer maior autonomia à equipe de projeto, através da
autogestão, do planejamento incremental e iterativo, e da maior interação entre os membros da
equipe. Elas buscam a flexibilidade, simplicidade e agilidade aplicadas no ambiente de projeto,
com equipes enxutas e altamente eficazes (AMARAL et al., 2011).
Apesar de ser consenso entre os autores (como exemplo: WILLIAMS, 1999;
DANWSON; DANWSON, 1998; PERMINOVA et al., 2008; HIGHSMITH 2004) de que os
conceitos ágeis são mais adequados, se comparados aos tradicionais, para gestão de projetos
que envolvem alta complexidade, elevado nível de incerteza e ambientes “turbulentos”, onde
as mudanças são frequentes, sua aplicação ocorre com uma frequência muito maior na área de
software se comparada a outras áreas do conhecimento, ainda que compartilhando das mesmas
características.
Faltam, na literatura, estudos de caso, fora do ambiente de software, e aplicações reais
destes conceitos ágeis em grandes empresas, e principalmente em projetos de desenvolvimento
de tecnologia.
Neste sentido, o trabalho descrito nesta dissertação, se soma à literatura de gestão ágil
de projetos com a formulação e aplicação real de um modelo híbrido de gestão no
desenvolvimento tecnológico pré-competitivo de uma grande empresa brasileira.
Adotou-se a estratégia de criar o modelo por meio de um kaizen (procedimento de
melhoria contínua), com foco no processo de planejamento e controle de tempo e escopo de
projetos.
Este modelo, intitulado de Modelo de Gestão Ágil para Desenvolvimento Tecnológico
(MGADT), foi baseado nos princípios da literatura ágil, nas metodologias híbridas aplicadas a
ambientes de desenvolvimento “turbulentos” e nas aplicações de frameworks ágeis já realizadas
no desenvolvimento de produto (DIP) da empresa analisada (SANTOS, 2013).
 122

O MGADT, assim como descrito na Seção 3.6, se aproxima do conceito adotado por
Amaral et al. (2011) no método IVPM2. Uma gestão híbrida e escalonada, mesclando princípios
tradicionais e ágeis.
Isto se deve em virtude de o ambiente de desenvolvimento de produtos inovadores ter
similaridade ao desenvolvimento de tecnologia. Como já dito anteriormente, ambos envolvem
incertezas, mudanças frequentes, difícil detalhamento do escopo etc.
A diferença entre os dois métodos se dá principalmente nas restrições que envolvem
uma grande corporação, em que há necessidade de manter softwares de gestão corporativos,
adotando os recursos oferecidos pelo mesmo e também modelos de gestão padronizados pela
empresa como um todo. A modificação de algo já existente neste tipo de empresa leva muito
mais tempo se comparada a pequenas empresas de base tecnológica utilizadas como exemplo
em Amaral et al. (2011).
Para exemplificar a aplicação prática do MGADT foram escolhidos dois projetos,
estrategicamente não críticos, do desenvolvimento tecnológico da empresa analisada (Projeto
A e Projeto B).
Esses projetos foram avaliados de forma qualitativa, por meio de uma pesquisa ação,
levantando os benefícios e os desafios identificados durante esta implementação.
A aplicação do modelo no Projeto A foi realizada de forma completa, sem nenhuma
limitação ou restrição imposta ao modelo, enquanto no Projeto B o modelo foi aplicado de
forma não integrada, diferentemente do proposto na Seção 3.5.
Esses dois casos de aplicação real puderam ser comparados: entre si, com modelo de
gestão atualmente em prática no ambiente do desenvolvimento tecnológico da empresa
analisada e também em relação à literatura.
Esta primeira implementação do MGADT no desenvolvimento tecnológico indícios de
que é possível aplicar os princípios ágeis em projetos deste tipo em uma grande corporação,
mesmo com toda a impedância que uma empresa de grande porte tipicamente oferece (Q1).
Esta afirmação vai de encontro ao à conclusão dos trabalhos realizados por Amaral et al. (2011)
e também Conforto (2009) ao aplicar um modelo semelhante em pequenas empresas de base
tecnológica.
Apesar dos desafios encontrados para a implementação de uma nova metodologia de
gestão no DT da empresa analisada como: a utilização de um sistema coorporativo para
gerenciamento global da empresa, pessoas de diferentes idades e com diferentes reações à
mudança de procedimento, e a recente introdução do modelo corrente crítica, pode-se verificar
 123

que a aplicação dos conceitos ágeis, de forma híbrida (Q3), apresentou tendências de beneficiar
o desenvolvimento/gestão dos projetos (Q2).
Não houve, nos dois casos de aplicação, uma análise quantitativa, através da verificação
de indicadores de sucesso do projeto, dos benefícios gerados pelo modelo proposto, que é então
sugerida como trabalho futuro.
Toda a tendência verificada nesta dissertação se baseou na percepção da equipe em
resposta ao questionário apresentado na Seção 3.7 e do autor, durante o acompanhamento do
projeto. Está percepção é pautada por outros trabalhos (WILLIAMS, 1999; DANWSON;
DANWSON, 1998; PERMINOVA et al., 2008; HIGHSMITH 2004; AMARAL et al.; 2011,
CONFORTO, 2009, SANTOS, 2013) que indicam ser melhor a utilização de conceitos ágeis,
se comparados ao tradicionais para projetos que envolvem elevados níveis de incertezas, como
os projetos de desenvolvimento tecnológico.
A utilização de modelos híbridos de gestão, como já dito anteriormente, também tem
sido uma tendência tratada por diversos autores na literatura, como Amaral et al. (2011),
Highsmith (2004) e Conforto (2009). Assim como os casos de aplicação real analisados pelos
autores aqui descritos, este tipo de modelo se mostrou um possível caminho para a gestão de
projetos de desenvolvimento de tecnologia, uma vez que foi possível separar as informações
disponíveis para acompanhamento e monitoramento de acordo com o nível de gestão requerido,
mantendo-se as boas práticas do PMBOK e apoiando a parte operacional com técnicas ágeis.
Pode-se dizer que o modelo MGADT atendeu ao objetivo inicialmente proposto de
implementar conceitos ágeis, de forma a complementar ao modelo de gestão já em uso no
desenvolvimento tecnológico de uma grande empresa.
Não foi possível aplicar este modelo, de modo completo, utilizando os três níveis de
gestão de forma integrada, em projetos de diferentes áreas de estudo devido a conjuntura de
projetos em desenvolvimento durante a realização deste estudo. Para não confundir o leitor,
vale salientar que no Projeto B, apesar de ser de área de conhecimento diferente do Projeto A,
o MGADT foi aplicado com restrições.
Atendendo-se ao objetivo específico 3, o modelo foi avaliado qualitativamente através
de entrevistas e também de um questionário respondido pela equipe de projeto. A partir disto,
foi então possível discutir os principais indícios de ganhos e desafios que se teve com a
aplicação do novo modelo.
De forma a diminuir o impacto, no time de projeto, relativo à mudança de conceitos de
gestão de projetos, foi utilizado no terceiro nível de gestão, ou seja, o operacional, o framework
scrum, devido a adoção prévia, com resultados positivos, em outras áreas da empresa,
 124

principalmente no desenvolvimento de produto. Esse fato proporcionou a troca de experiências,

o patrocínio da alta gerência e também uma motivação, por utilizar aquilo que está sendo
amplamente difundido na empresa.
O principal resultado de todo este trabalho foi a percepção da equipe de que é necessária
uma gestão no nível operacional, para facilitar o desenvolvimento desses projetos, e que se está
gestão é baseada nos conceitos ágeis, há uma tendência de aumento da comunicação e
integração entre a equipe.
Isto nos permite realizar as mudanças necessárias no modelo, envolvendo a equipe de
desenvolvimento, e aplica-lo novamente, em um ciclo continuo de melhorias.
Se a equipe não visse nenhum ganho, o modelo estaria fadado ao insucesso. A equipe
não teria motivação para manter a gestão e as atualizações da maneira correta, e o modelo de
nada serviria, a não ser gerar mais trabalho administrativo.
A partir desta primeira implementação do modelo MGADT agora é possível
realimentar as discussões a fim de melhorar o modelo proposto, diversificar os casos de
aplicação, aumentar o número de pessoas envolvidas no modelo para num futuro mais distante
estabelecer um padrão de gestão para todos os projetos do desenvolvimento tecnológico da
empresa analisada.

5.1 Limitações do Trabalho

É importante salientar que este trabalho em questão apresenta algumas limitações e

restrições, resultantes da metodologia utilizada para sua concepção, bem como da
disponibilidade de tempo para acompanhamento dos projetos piloto por um maior tempo.
A primeira questão a ser analisada é a utilização de uma grande empresa como exemplo
para a confecção e aplicação prática do modelo proposto. Esta escolha restringiu o modelo a
utilizar como padrão a metodologia da corrente crítica e softwares disponíveis para a gestão de
projetos desta empresa.
Em termos de pesquisa, o MGADT se limitou a abordar apenas processos de controle
de escopo e tempo da gestão de projetos, conforme abordado no guia PMBOK (PMI, 2013). A
fim de se obter um modelo referencial, os demais processos devem ser analisados e também
adotadas ferramentas que possibilitem sua gestão.
A primeira aplicação do MGADT não ocorreu da melhor forma, sendo que, no projeto
A foi aplicado todo o modelo proposto após quatro meses do início de seu desenvolvimento, e
 125

no projeto B aplicou-se apenas o scrum, no nível operacional, não modificando a gestão de

projetos nos demais níveis, da forma integrada como mostrado na Seção 3.5.
Apesar disto, do ponto de vista prático, o estudo se mostrou uma alternativa para
explorar novas técnicas de gestão e apontou melhorias identificadas pelos usuários, como:
integração automática entre os níveis de gestão, utilizando um algoritmo que realize a interface
entre os softwares utilizados na gestão, a implementação dos conceitos ágeis de forma ampla
no projeto e planejamento alto nível em ondas, proporcionando maior flexibilidade no escopo
do projeto.
Por fim para se ter melhores resultados com a utilização dos conceitos ágeis há a
necessidade de aumentar a interação entre os desenvolvedores de tecnologia e os de produto,
beneficiando o resultado final. Os engenheiros de produto devem estar presentes durante a
construção do escopo e as revisões das interações, acompanhando o andamento do projeto e
participando do desenvolvimento, assim como o proposto por Amaral et al. (2011) um cliente
“projetista”.

5.2 Propostas Futuras de Trabalho

Há a necessidade de avaliar o MGADT em projetos de diferentes áreas de atuação com

diferentes demandas, e por um maior tempo. Como proposta futura de trabalho, o autor sugere
a aplicação do MGADT em projetos desde sua fase inicial. Utilizando, já no planejamento,
conceitos ágeis e de gestão em ondas. O autor também sugere a utilização de quadros visuais
como foco principal, utilizando software somente para se ter um back-up do projeto.
Afim de complementar o modelo é necessário abordar outras áreas relativas ao
gerenciamento de projetos. Realizar um estudo que contemple a fase de iniciação, planejamento
e encerramento, estabelecendo a forma e conceito de cada uma destas fases, assim como
realizado com o modelo proposto.
Outra proposta é o desenvolvimento de um sistema de indicadores, baseados no
gerenciamento de projetos ágeis, que possa auxiliar a equipe no trabalho diário. Algo que seja
funcional e se adapte ao ambiente do desenvolvimento tecnológico da empresa analisada.
Por último, criar mecanismos para que possa ser avaliado o sucesso do projeto como um
todo. Sendo assim seria possível sempre guiar o projeto para o caminho mais correto, não
desperdiçando o dinheiro investido.
 126

REFERÊNCIAS

ABRAHAMSSON, P.; CONBOY, K.; WANG, X. ‘Lots done, more to do’: the current state
of agile systems development research, European Journal of Information Systems, vol.
18, 2009.

AMARAL, D.; CONFORTO, E.; BENASSI, J.; ARAUJO, C. Gerenciamento ágil de

projetos: aplicação em produtos inovadores. São Paulo: Saraiva, 2011. 240 p.

AMARAL, D.; BENASSI, J. Gerenciamento ágil de projetos aplicado ao desenvolvimento

de produto físico. In: XIV Simpósio de engenharia de produção (SIMPEP), Anais... Bauru:
UNESP, 2007. Artigos, p.1-11. ISSN 1809-7189

AJAMIAN, G.; KOEN P. Technology stage-gatetm: a structured process for managing

high-risk, new technology projects. PDMA toolbox for new product development.
Editado por P. Beliveau, A. Griffin e S. Somermeyer. Nova York: John Wiley & Sons,
2002. p. 267-295.

ALOPEX ON INNOVATION. TRL Scale. [S.l.: s.n.], 2013. Disponível em

<http://alopexoninnovation.com/2013/06/>. Acesso em: 20 Apr. 2014.

ARAUJO, C. S. Lessons learned on technology innovation projects with academic

partnership: Aerospace industry case study. Product: Management & Development. V.
10, n. 1, p. 41-51, June 2012.

ATREYA, C. How to implement critical chain project management across the

enterprise. [S.l.: s.n.], 2012. Disponível em < http://www.kanbanway.com/how-to-
implement-critical-chain-project-management-across-the-enterprise#.VdoSXpcj6ah>.
Acesso em: 23 Ago. 2015.

BARCAUI, A.; QUELLHAS, O. Corrente crítica: uma alternativa à gerência de projetos

tradicional. Revista Pesquisa e Desenvolvimento Engenharia de Produção. n.2, p. 1 –
21, Jul 2004.

BECK, K. et al. Agile Manifesto. [S.l.: s.n.], 2001. Disponível em

<http://www.agilemanifesto.org/>. Acesso em: 20 Apr. 2014.

BECK, K. Embracing change with extreme programming. IEEE Computer Science.

Review, v. 32, n.10, p. 70-77, Oct. 1999.

BECK, K. Extreme Programming Explained: Embrace change. Reading, Massachusetts:

Ed Addison-Wesley, 2000. 224 p.

BOEHM, B; TURNER, R. Balancing agility and discipline. Boston: Pearson Education,

2004.
 127

BOLAND, D.; FITZGERALD, B. Transitioning from a co-located to a globally-distributed

software development team: A case study at Analog Devices, Inc. In: 3rd Workshop on
Global Software Development. Anais... [S.l.: s.n.], 2004.

BRAZ, A. Método Ágil aplicado ao desenvolvimento de software confiável baseado em

componentes. 2005, 126 f. Dissertação (Mestrado em Ciência da Computação),
Universidade Estadual de Campinas, Campinas, SP: [s.n.], 2013

BROAD, C. Scrum: guia prático para projetos ágeis. São Paulo: Novatec, 2013. 188 p.

BROOKS JR, F. O projeto do projeto – da modelagem à realização. 1. ed. Rio de Janeiro:

Campus-Elsevier, 2010. 432 p.

CAO, L.; MOHAN, K.; XU, P.; RAMESH, B. How extreme does extreme programming
have to be? adapting xp practices to large-scale projects. In: 37th Hawaii Int’l Conf. System
Sci. Anais... [S.l.: s.n.], 2004.

CARVALHO, F. Aplicação e avaliação de desempenho de método para representação

da visão no Gerenciamento Ágil de Projetos em uma empresa de bens de consumo.
São Carlos, 2011. Dissertação (Mestrado). Escola de Engenharia de São Carlos,
Universidade de São Paulo.

CHIN, G. Agile project management: how to succeed in the face of changing project
requirements. New York: Amacom, 2004.

COAD, P; LEFEBVRE, E; DE LUCA, J. Java modeling in colo with UML. California:

Prentice Hall PTR, 1999. 218 p.

CONFORTO, E. Gerenciamento ágil de projetos: proposta e avaliação de método para o

gerenciamento de escopo e tempo. São Carlos, 2009. Dissertação (Mestrado). Escola de
Engenharia de São Carlos, Universidade de São Paulo.

COOPER, R. Managing technology development projects. IEEE Engineering

management. Review, v. 35, n.1, p. 67-76, first quarter 2007.

COOPER, R. KLEINSCHMIDT, E. Success factors in product innovation. Industrial

Marketing Management, v.16, n. 3, p. 215 – 223, 1987.

CRUZ, F. Scrum e PMBOK - Unidos no gerenciamento de projetos. Rio de Janeiro:

Brasport, 2013. 382 p.

DAWSON, R.; DAWSON, C. Practical proposals for managing uncertainty and risk in
project planning. International Journal of Project Management, v.16, n.5, p. 299-310,
1998.

DE CASTRO, F. S. Quadro Scrum. [S.l.: s.n.], 2009. Disponível em

<http://www.agileway.com.br/2009/08/18/grafico-burndown-sugestao-de-uso/>. Acesso
em: 15 jul. 2014.
 128

DE COTIIS, T. DYER, L. Defining and measuring Project performance. Research

Management, v. 16, p. 17-22, 1979.

DETTMER, H. William. Goldratt’s Theory of Constraints: a systems approach to

continuous improvement. Milwaukee, Wisconsin: ASQS Quality Press, 1997. 378 p.

DOWLING, Kieron N. SAP – Manual do Sistema de Projetos. Rio de Janeiro: Editora

Ciência Moderna Ltda., 2008. 392 p.

DT EMPRESA ANALISADA. Apresentação resultante do kaizen de gestão de projetos do

desenvolvimento tecnológico empresa analisada. EMPRESA ANALISADA, Set. 2014.

DVIR, D. SHENHAR, A. Measuring project success of technology-based strategic business

units. Engineering Management Journal, v.4, n.4, p. 33 – 38, 1992.

EMPRESA ANALISADA. Desenvolvimento Tecnológico. In: Visita P&D: Brasil. 2014.

Anais... [S.l.: s.n.], 2014. Disponível em <http://www.pedbrasil.org.br/ped/imagensUpload/
C20409642CFE4472.pdf >. Acesso em: 16 out. 2014.

ESTADOS UNIDOS DA AMÉRICA. Department of Defense. Technology Readiness

Assessment (TRA) Deskbook, Washington, D.C., 2005

FAGUNDES, P. B. Framework para computação e análise de métodos ágeis. 2005, 134

f. Dissertação (Mestrado em Ciência da Computação), Universidade Federal de Santa
Catarina, Florianópolis. 2005.

FARIA, L. Gerenciamento ágil de projetos. Uma nova abordagem para os desafios de

sempre. [S.l.: s.n.], 2013. Disponível em <http://www.decom.ufop.br/workshop/
images/arquivos/palestra_LeandroFaria.pdf>. Acesso em: 19 dez. 2014.

FITZGERALD, B.; STOL, K.; O’SULLIVAN, R.; O’BRIEN, D. Scaling agile methods to
regulated environments: an industry case study. IEEE Software Engineering in Practice,
v. 13, p. 863-872, 2013.

FLORES, E. Uma análise de práticas na aplicação de scrum em projetos de grande

porte. 2012, 79 f. (Departamento de Informática do Centro Técnico Científico da PUC-
Rio.), Pontifícia Universidade Católica do Rio de Janeiro, Rio de Janeiro. 2012.

GUERREIRO, R.; CATELLI, A.; SANTOS, R. As críticas da teoria das restrições à

contabilidade de custos: uma resposta. In: XV Congresso Brasileiro de Contabilidade,
Anais... [S.l.: s.n.], 1996, p. 45-64.

HIGHSMITH, J. Agile project management: creating innovative products. Boston:

Addison-Wesley, 2004.

HIGHSMITH, J.; COCKBURN, A. Agile software development: the business of

innovation. IEEE Computer Science, v. 34, n. 9, p. 120-122, Sept. 2001.

IMAI, Masaaki. Kaizen, A estratégia para o sucesso competitivo. São Paulo: Editora Imam,
1994. 236p.
 129

JUGDEV, K. MÜLLER, R. A retrospective look at our evolving understanding of project

success. Project Management Institute, v. 36, n. 4, p. 19-31, Dec. 2005.

KARLSSON, C.; AHLSTRÖM, P. The Difficulty Path to Lean Product Development,

Journal of Product Innovation Management, v.13, p. 283-295, 1996.1996

KERZNER, H. Gestão de projetos: as melhores práticas. Tradução Lene Belon Ribeiro.

2. ed. Porto Alegre: Bookman, 2006. 824 p.

KERZNER, H. Project management: a systems approach to planning, scheduling, and

controlling. 10th ed. Hoboken, New Jersey: John Wiley & Sons, Inc, 2009. 1094p.

LARMAN, C.; BASILI, V. R. Iterative and Incremental Development: a brief history.

IEEE Computer Science, v. 36, n. 6, p. 47-56, Jun. 2003.

LEAN INSTITUTE BRASIL. Lean Thinking (Mentalidade Enxuta). [S.l.: s.n.], [entre
1998 e 2014]. Disponível em < http://www.lean.org.br/>. Acesso em: 08 set. 2014.

LEÓN, H.; FARRIS, J. Lean Product Development Research: Current State and Futures
Directions. Engineering Management Journal, v. 23, n. 1,p. 29-51 , March 2011

MARIOTTI, F. Kanban: o ágil adaptativo. Engenharia de Software Magazine, ed. 45, p.

6-16, fev. 2012. 400p.

MENDOZA, D. Gerenciamento e planejamento de projetos de software usando

metodologias ágeis. Rio de Janeiro, 2011. Dissertação (Mestrado). Departamento de
Engenharia Industrial, Pontifícia Universidade Católica do Rio de Janeiro.

MORGAN, J.; LIKER, J. The Toyota Product Development System: integrating People,
Process and Technology. Nova York: Productivity Press, 2006.

LIKERT, R. A technique for the measurement of attitudes. Archives of Psychology 140:

(1932), pp. 1-55.

MARTINS, J. C. C. Técnicas para gerenciamento de projetos de software. Rio de

Janeiro: Brasport, 2007. 456 p.

MATSUMURA, T., HAFTKA, R.T., and KIM, N.H. "The contribution of Building-Block
Test to Discover Unexpected Failure Modes" In: 52TH AIAA/ASME/ASCE/AHS/ASC
STRUCTURES, STRUCTURAL DYNAMICS, AND MATERIALS CONFERENCE,
Proceedings…Denver, [S.l.: s.n.], Apr. 2011.

MATSUO, E. Inovação tecnológica e indústria aeronáutica. In: INOVAÇÃO NA

EMPRESA. INTRODUTORES DE INVESTIMENTO PARA INOVAÇÃO, Anais...
Brasília-DF: Parc. Estrat. Ed. Esp., 2010. v. 15, n. 31, p. 83-94.

NASA; WERRIES, M. Chevron nozzles moved through the TRL scale. [S.l.: s.n.],
[2010?]. Disponível em <http://www.nasa.gov/topics/aeronautics/features/
trl_demystified.html#.VHuTI_ldURp>. Acesso em: 16 Oct. 2014.
 130

NOLTE, W. L. Did I ever tell you about the whale? , or, Measuring Technology Maturity.
Charlotte, North Carolina: Information Age Publishing, Inc., 2008. 193 p.

PALMER, S. R.; FELSING, J.M. A practical guide to Feature-Driven Development.

Upper Saddle Rever, NJ: Prentice Hall PTR, 2002. 304 p.

PERMINOVA, O.; GUSTAFSSON, M. WIKSTRÖM, K. Defining uncertainty in projects

– a new perspective. International Journal of Project Management, v.26, n.1, p. 73-79,
2008.

PHILLIPS, A. Technology & Market Structure: A Study of the Aircraft Industry. Journal
of Economic Literature, v. 10, n. 4, p. 1253-1255, Dec. 1972.

PINTO, J. SLEVIN, D. Project success: Definitions and measurement techniques. Project

Management Journal, v.19, n. 3, p. 67 – 73, 1988.

PMI - PROJECT MANAGEMENT INSTITUTE. Um guia do conhecimento em

gerenciamento de projetos (guia PMBOK). 5. ed. Newton Square, Pennsylvania: Project
Management Institute, Inc., 2013. 568 p.

PMI’S PULSE OF THE PROFESSION. The high cost of low performance. [S.l.: s.n.],
2013. Disponível em <http://www.pmi.org/~/media/PDF/Business-Solutions/PMI-
Pulse%20Report-2013Mar4.ashx>. Acesso em: 09 Jul. 2014.

PMSURVEY.ORG. Estudo de benchmarking em gerenciamento de projetos Brasil

2010. Project Management Institute – Chapters Brasileiros. [S.l.: s.n.], 2010. Disponível em
<http://www.mp.go.gov.br/portalweb/hp/33/docs/benchmarking_gp_2010_geral.pdf>
Acesso em: 30 dez. 2014.

POPPENDIECK, M.; POPPENDIECK, T. Lean software development: an agile toolkit.

1 ed. Boston: Addison-Wesley Professional, 2003. 240 p.

PUGH, S. Creating innovative products using total design: the living legacy of Stuart
Pugh. 1. Ed. Reading, MA: Addison Wesley, 1996. 544p.

ROSSETTI, E; BARROS, M.; TÓDERO, M.; DENICOL, S.; CAMARGO, M. Sistema just
in time: conceitos imprescindíveis. Revista Qualita@s, v.7, n. 2, p. 1 – 6, 2008.

SANTOS, M. J. dos. Adaptação do Método Scrum ao Desenvolvimento de Produtos

Altamente Complexos. Dissertação de Mestrado. São José dos Campos, 2013. 134 f.

SCHWABER, K. Scrum Development Process, In: OOPSLA BUSINESS OBJECT

DESIGN AND IMPLEMENTATION WORKSHOP. Proceedings…Springer: London J.
Sutherland, et al., Editors. 1997.

SCHWABER, K.; SUTHERLAND, J. Guia do Scrum. Um guia definitivo para o Scrum:

As regras do jogo. [S.l.: s.n.], 2013. Disponível em
<https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum%20Guide%20-
%20Portuguese%20 BR.pdf >. Acesso em: 13 jul. 2014.
 131

SHENHAR, A. J.; DVIR, D. Project management research – the challenge and opportunity.
Project Management Journal, v. 38, n. 2, p. 93-99, Jun. 2007.

SHENHAR, A. J.; DVIR, D. Reinventing Project management: the Diamond approach

to successful growth and innovation. Boston: Harvard Business School Press, 2007.

SHENHAR, A. J.; LEVY, O.; DVIR, D. Mapping the dimensions of project success.
Project Management Journal, v. 28, n. 2, p. 5-13, Jun. 1997.

SOTILLE, M.; A certificação PMP completa 30 anos. [S.l.: s.n.], 2014. Disponível em
http://blog.pmtech.com.br/pmp-30-anos/. Acesso em: 17 jul. 2015.

SHERRY, L; SARSFIELD, L. Redirecting R&D in the Commercial Aircraft Supply

Chain. Rand Issue Paper: Mimeo, 2002.

SSPECTER. Fases de um projeto FDD. [S.l.: s.n.], 2011. Disponível

em<http://www.sspecter.com.br/wiki/index.php/Feature_Driven_Development>. Acesso
em: 19 ago. 2014.

SUTHERLAND, J. Agile development: Lessons learned from the first scrum. Cutter Agile
Project Management Advisory Service: Executive Update, v. 5, n. 20, p. 1-4, Oct. 2004.

TAKEUCHI, H.; NONAKA, I. The New New Product Development Game. Harvard
Business Review, 1986. 10 p.

THE STANDISH GROUP. CHAOS manifesto 2013. [S.l.: s.n.], 2013. Disponível em
<http://www.versionone.com/assets/img/files/CHAOSManifesto2013.pdf>. Acesso em: 09
Jul. 2014.

VERSIONONE.COM. 7th annual state of agile development survey. [S.l.: s.n.],2013.

Disponível em <http://www.versionone.com/pdf/7th-Annual-State-of-Agile-Development-
Survey.pdf >. Acesso em: 09 Jul. 2014.

WILLIAMS, L.; COCKBURN, A. “It’s about feedback and change,” IEEE Computing,
vol. 36, no. 6, 2003.

WILLIAMS, T. The need for new paradigms for complex projects. International Journal
of Project Management, v.17, n.5, p. 269-273,1999.

WILSON J. M. Gantt Charts: A centenary appreciation. European Journal of Operational

Research, v. 149, n. 2, p. 430-437, Sept. 2003.

WOMACK, J. E JONES, D., DANIEL, T. Lean Thinking: Banish Waste and Create
Wealth in Your Corporation. New York: Simon & Schuster, 1996.

WOMACK, J. E JONES, D., ROOS, D. A máquina que mudou o mundo. 14. ed. Rio de
Janeiro: Campus, 1992.
 132

APÊNDICE

A.1 - Questionários da Pesquisa Tipo Survey Enviados ao time de projeto

 133

ANEXO

O Anexo A2 ilustra a definição, descrição e informações de suportes de TRL

(Technology readiness level) para hardware, segundo o DoD (Departament of Defense)
americano.
 134

A2.- Descrição dos níveis de maturidade tecnológica do Indicador TRL do DoD para
hardware. (ESTADOS UNIDOS DA AMÉRICA, 2005, Apêndice J)
 FOLHA DE REGISTRO DO DOCUMENTO
1. 2. 3. 4.
CLASSIFICAÇÃO/TIPO DATA REGISTRO N° N° DE PÁGINAS

DP 23 de outubro de 2015 DCTA/ITA/DP-084/2015 134

5.
TÍTULO E SUBTÍTULO:

Gestão ágil aplicada ao desenvolvimento tecnológico pré-competitivo.

6.
AUTOR(ES):

Rafael Nacife Carneiro

7. INSTITUIÇÃO(ÕES)/ÓRGÃO(S) INTERNO(S)/DIVISÃO(ÕES):

Instituto Tecnológico de Aeronáutica – ITA

8.
PALAVRAS-CHAVE SUGERIDAS PELO AUTOR:

Gestão de Projetos; Gestão Ágil; Scrum; Desenvolvimento Tecnológico Pré-Competitivo.

9.PALAVRAS-CHAVE RESULTANTES DE INDEXAÇÃO:
Administração de projetos; Melhoria continua; Controle de processos; Desenvolvimento de produto;
Engenharia de produção.
10.
APRESENTAÇÃO: X Nacional Internacional
ITA, São José dos Campos. Curso de Mestrado Profissional em Engenharia Aeronáutica. Programa de Pós-
Graduação em Engenharia Aeronáutica e Mecânica. Orientador: Prof. Dr. Luís Gonzaga Trabasso;
coorientador: Claudiano Sales de Araújo Júnior. Defesa em 10/08/2015. Publicada em 2015.
11.
RESUMO:

A execução com sucesso de projetos de inovação pré-competitiva, onde se inclui o desenvolvimento

tecnológico, é ainda um grande desafio para as equipes envolvidas. A correta escolha das metodologias e
processos a serem adotados na gestão destes projetos é crucial para o sucesso dos mesmos. Neste trabalho
é apresentada e avaliada uma proposta integrada de gestão híbrida de projetos, tradicional e ágil, em três
níveis: gestão estratégica (utilizando-se uma abordagem tradicional de gestão de projetos, suportada pelo
ambiente PS-SAP), gestão tática (onde adota-se a corrente crítica) e gestão operacional (baseado numa
derivação do Scrum), para suportar o desenvolvimento deste tipo de projeto de desenvolvimento
tecnológico pré-competitivo. Este modelo, chamado de MGADT, foi o resultado de um processo de
melhoria contínua (kaizen), que contou com a participação de 17 membros seniores do desenvolvimento
tecnológico pré-competitivo de uma grande empresa aeronáutica brasileira e também do autor. A avaliação
do MGADT se deu a partir de sua aplicação em dois projetos tecnológicos em desenvolvimento nesta
empresa. Estas experiências foram comparadas entre si, com a literatura e em relação às práticas até então
adotadas para gerir os demais projetos. As evidências coletadas deram indícios de que é possível aplicar os
princípios ágeis para gerir projetos de desenvolvimento tecnológico, apesar do ambiente altamente
dinâmico, e que está aplicação traz benefícios ao monitoramento e controle dos mesmos. Entretanto, o
estudo aponta que há a necessidade de aprimorar as análises conduzidas, abordando o lado qualitativo, e
aprimorar o próprio modelo MGADT, com aplicação e validação em outros projetos e outras empresas.

12.
GRAU DE SIGILO:

(X ) OSTENSIVO ( ) RESERVADO ( ) SECRETO