Gerenciamento ágil de projetos aplicado ao desenvolvimento de

produto físico

João Luís Guilherme Benassi. (USP) jbenassi@bol.com.br

Daniel Capaldo Amaral. (USP) amaral@sc.usp.br

Resumo: Apesar da crescente utilização das metodologias de gerenciamento ágil de

desenvolvimento de software pode-se notar que até o presente momento, poucos são os
indícios na literatura da utilização do Gerenciamento Ágil de Projetos no desenvolvimento de
produtos físicos. Tais princípios podem ser de extremo valor, principalmente em projetos de
alto conteúdo inovador e aonde haja restrições de tempo de desenvolvimento. Será que as
características diferenciais dos produtos físicos em relação aos softwares impedem a
aplicação de práticas ágeis de gerenciamento de projetos? Analisa-se a questão por meio de
uma revisão bibliográfica. Como resultado, demonstra-se a viabilidade e apresentam-se os
temas de pesquisa que devem ser desenvolvidos para o avanço da área e, conseqüentemente,
a aplicação de princípios ágeis em projetos de desenvolvimento de novos produtos do tipo
físico. A contribuição principal, portanto, é a identificação do tema de pesquisa e a
proposição de temas para os pesquisadores interessados.
Palavras-Chave: Desenvolvimento de produtos, Gestão de projetos, Gerenciamento ágil de
projetos, Métodos ágeis de desenvolvimento de software.

1. Introdução
O ambiente empresarial dinâmico e turbulento impede posturas reativas. As empresas
precisam sofrer mudanças e se reinventarem para permanecerem competitivas. Esse nível de
mudanças, segundo Chin (2004, p.viii), não inclui somente o desenvolvimento de novos
produtos e serviços, mas deve também criar novas práticas de recursos humanos, marketing,
parcerias e reorganizações que as manterão na competição. De acordo com o mesmo autor,
projetos são os impulsionadores que movimentam essas transformações e que proporcionam a
flexibilidade necessária para deixarem de lado antigas posturas e assim, conseguirem
sobreviver no atual ambiente competitivo.
Nos últimos anos diversos autores têm se dedicado ao desenvolvimento de uma nova
abordagem de gestão de projetos que busca maior velocidade que as técnicas tradicionais, é o
Gerenciamento Ágil de Projetos (BECK, 1998; CHIN, 2004; FOWLER, 2000; HIGHSMITH,
2004; SANJIV; WOODCOCK, 2003).
Essa abordagem que possui foco na geração de valor ao cliente oferece às empresas
uma nova opção para a gestão do desenvolvimento de seus produtos em ambientes
turbulentos. O início dessas abordagens se deu na área de tecnologia de informação. Um
marco foi a criação do manifesto ágil (BECK, et al. 2001). Passados alguns anos há indícios
de resultados positivos destas aplicações. Reifer (2002) aponta reduções de custos e
incrementos na produtividade em empresas que adotaram os métodos ágeis de
desenvolvimento de software.
Deve-se notar, porém, que as aplicações relatadas restringem-se ao universo da
tecnologia de informação. Exemplos e resultados de aplicação das práticas ágeis para
desenvolvimento de produtos físicos não são encontrados na literatura, apesar de autores

1
como Highsmith (2004) e Chin (2004) afirmarem ser possível tal aplicação. Estes autores
enfatizam ainda que tais práticas seriam particularmente úteis para projetos de produtos que
envolvam altos níveis de inovação.
O artigo apresenta o resultado de uma análise das práticas utilizadas no Gerenciamento
Ágil de Projetos de desenvolvimento de software e aponta possíveis questões de pesquisa que
precisam ser respondidas para aplicar essa metodologia no gerenciamento do
desenvolvimento de produtos físicos.
Um dos principais diferenciais entre as técnicas de gestão ágil e a tradicional está na
definição do projeto (visão ao invés de declaração do escopo) e planejamento. A análise deste
estudo se limita à categoria “Visão do produto”, devido a limitações de espaço.
2. Gerenciamento Ágil de Projetos
O Gerenciamento Ágil de Projetos (APM)1 surgiu em 2001 devido a um movimento
iniciado pela comunidade internacional de desenvolvimento de sistemas de informação com o
intuito de responder às crescentes pressões por inovação, necessidade de reduzir ciclos de
desenvolvimento de produtos, concorrência acirrada e de adaptação a um contexto dinâmico
que cada vez mais revelavam a diminuição da eficiência da gestão clássica de projetos quando
deparada a esse novo cenário.
A essência desse movimento é a definição do novo enfoque de desenvolvimento de
software, calcado na agilidade, na flexibilidade, nas habilidades de comunicação e na
capacidade de oferecer novos produtos e serviços de valor ao mercado em curtos períodos de
tempo (HIGHSMITH, 2004, p. xix). Por agilidade entende-se “habilidade de criar e responder
a mudanças, a fim de obter lucro em um ambiente de negócio turbulento” (HIGHSMITH,
2004, p.16). Ainda, segundo Chin (2004) e Highsmith (2004), a descrição da gestão clássica
de projetos vista como um conjunto de processos com foco no planejamento detalhado e
resistente a mudanças, não colabora mais com as demandas desse novo contexto de forma que
uma nova plataforma para o gerenciamento deve ser criada.
Dadas essas circunstâncias e conseqüente diminuição da eficiência dos métodos
tradicionais de desenvolvimento, muitos especialistas criaram métodos próprios para o
desenvolvimento de software como, por exemplo, Extremming Programing (XP), Scrum,
Crystal Methods, DynamicSystems Development Method (DSDM) e Feature-Driven
Development (FDD), que serviriam como base para o Gerenciamento Ágil de Projetos.
Através de uma reunião realizada entre os criadores e representantes dos chamados
Métodos Ágeis de Desenvolvimento de Software para discutir alternativas aos processos
tradicionais, houve a criação da Agile Alliance2 que por sua vez publicou o Manifesto para
Desenvolvimento Ágil de Software ou o Manifesto for Agile Software Development (BECK, et
al. 2001), cujo conteúdo contempla:
“Nós estamos descobrindo melhores maneiras para desenvolver software
(produtos3), praticando e ajudando outras pessoas a fazê-lo. Por meio desse trabalho nós
valorizamos:
- Os indivíduos e suas interações acima dos processos e ferramentas
- Software (produtos) funcionando acima de documentação detalhada (excessiva)
- Colaboração de clientes acima da negociação de contratos

1
Tradução do termo em inglês Agile Project Management (APM).
2
Agille Alliance – Organização sem fins lucrativos criada para auxiliar indivíduos e organizações que utilizam
os Métodos Ágeis para o desenvolvimento de software (www.agilealliance.org).
3
Highsmith (2004, p.9-10) utiliza a palavra produto por se tratar de um termo mais geral.

2
 - Resposta a mudanças acima da execução de um plano
Ou seja, enquanto há valor nos itens da direita, nós damos mais valor aos itens da
esquerda”.
Enquanto que essas declarações dos valores essenciais foram originalmente escritas
para o desenvolvimento ágil de software, com um pouco de interpretação e reordenamento
elas podem também ser aplicadas ao Gerenciamento Ágil de Projeto (HIGHSMITH, 2004, p.
10).
Dessa maneira, Highsmith (2004, p.16) define o APM como “[...] um conjunto de
valores, princípios e práticas que auxiliam a equipe de projeto a entregar produtos ou serviços
de valor em um ambiente complexo, instável e desafiador”. Conforme essa definição, os
valores e princípios referem-se ao porquê do Gerenciamento Ágil de Projetos, já as práticas
são voltadas para como realizá-lo.
Por fim, do Manifesto Ágil alguns princípios que servem como guia para as práticas
do Gerenciamento Ágil de Projetos foram definidos. Esses princípios, de acordo com
Highsmith (2004, p.27), são divididos em duas categorias: uma relacionada ao produto e
clientes e a outra relacionada ao gerenciamento (vide tabela 1).

Tabela 1 - Princípios do APM

Categoria Princípio
Entregar valor ao cliente
Cliente/Produto Empregar entregas iterativas e baseadas em características
Buscar excelência técnica
Encorajar a exploração
Gerenciamento Formar times adaptativos (auto-organizados e autodisciplinados)
Simplificar
Fonte: adaptado de HIGHSMITH, 2004, p.27.

Ainda, segundo Chin (2004) e Highsmith (2004), o Gerenciamento Ágil de Projetos

(APM) muda da postura antecipatória, fortemente calcada no planejamento prévio de ações e
atividades típicas do gerenciamento de projetos tradicional, e busca o desenvolvimento da
visão do futuro e da capacidade de exploração. Ou seja, para Highsmith (2004, p. 11), “[...]
planejar o trabalho e executar o plano” não é um lema adequado a uma grande variedade de
projetos, em especial para os projetos de desenvolvimento de novos produtos (ou software) ou
àqueles relacionados a qualquer tipo de inovação tecnológica.
Com relação à capacidade de exploração Highsmith (2004, p.6) salienta que são cinco
os objetivos principais para um bom processo de exploração. Esses objetivos são: inovação
contínua, adaptabilidade do produto, tempos de entregas reduzidos, capacidade de adaptação
do processo e das pessoas e resultados confiáveis. De acordo com os objetivos citados acima
podemos afirmar que estes estão alinhados com o processo de desenvolvimento de produtos,
uma vez que este é gerenciado por projetos e visa, segundo Rozenfeld, et al (2006, p. 14), não
só o custo e desempenho técnico, mas sim a qualidade do produto no atendimento aos
diferentes requisitos dos clientes; colocação do produto no mercado o mais rápido possível,
para aproveitamento adequado da janela de oportunidades, antecipando-se à concorrência;
manufaturabilidade do produto e o fortalecimento, a cada projeto, das capacitações requeridas
para o desenvolvimento de produto no futuro.

3
 Sendo assim, dados os valores do Manifesto para Desenvolvimento Ágil de Software e
os princípios que norteiam o APM, faremos uma breve explicação das fases que compõem o
modelo de APM de Highsmith.
Esse modelo (figura 1) foca nas entregas (execução) e adaptação e é composto das
seguintes fases:
1. Visão: determina a visão e o escopo do produto, a identificação da comunidade do projeto e
a definição de como a equipe de projeto trabalhará em conjunto;
2. Especulação: nessa fase há a identificação dos requisitos iniciais do produto, a definição
das atividades como uma lista de características do produto, criação de um plano de entregas
que inclui cronograma e alocação de recursos às características e um planejamento preliminar
seguido por planejamentos específicos a cada iteração;
3. Exploração: compreende a entrega de componentes de produtos em curto prazo e que foram
planejadas na fase anterior;
4. Adaptação: revisão dos resultados entregues, da situação atual e do desempenho do time e
adaptação conforme o necessário;
5. Encerramento: o objetivo dessa fase é o aprendizado, ou seja, incorporá-lo ao trabalho da
próxima iteração ou transferi-lo para a próxima equipe de projeto.
Com o objetivo de melhorar o produto do projeto, as fases de Especulação, Exploração
e Adaptação perpetuam um ciclo iterativo. Udo & Koppensteiner (2003, p. 5) e Highsmith
(2004, p.81) asseveram que em cada ciclo iterativo é feito um novo planejamento de escopo,
prazo, custo e qualidade, visando a entrega de produtos ou resultados e possibilitando
incrementos de funcionalidades conforme a necessidade do negócio.

Visão

Visão
Escopo
Comunidade do Plano de entregas
projeto
Especulação Exploração
Equipe do projeto
Funcionalidades
Ações de
complementares
adaptação Adaptação

Produto
final Encerramento
Lista de funcionalidades
Figura 1 - Fases do Gerenciamento Ágil de Projetos.
Fonte: Adaptado de HIGHSMITH, 2004, p. 81.

Com relação à aplicabilidade do APM, autores como Chin, 2004 e Highsmith, 2004
discutem sobre o seu potencial. Esses autores sugerem a aplicação do APM em projetos de
desenvolvimentos de novos produtos ou outros que requeiram alto grau de inovação,
criatividade, que envolvam tecnologia de ponta, equipes de alto desempenho, que estejam
sujeitos a incertezas ou inseridos em ambientes de negócio dinâmicos.
Chin, (2004, p.13-21) ainda ressalta que a aplicabilidade do Gerenciamento Ágil de
Projetos deve estar relacionada aos tipos de projeto e organizações envolvidas. Dessa forma, o
Gerenciamento Clássico de Projetos é recomendado pelo autor em projetos com baixo grau de

4
incerteza (ambiente operacional) e relacionados a várias ou poucas organizações interessadas,
por outro lado, projetos com alto grau de incerteza (ambiente de desenvolvimento de
tecnologia e novos produtos/processos), atrelados a poucas ou várias organizações
interessadas, requerem uma análise mais rigorosa de seu contexto interno e externo
considerando aspectos culturais e a prontidão da organização e dos principais interessados no
projeto para a adoção de um enfoque ágil antes da definição da melhor abordagem. De acordo
com essa mesma linha de raciocínio, Highsmith, (2004, p.85), sugere que os princípios e
valores do APM são aplicáveis a projetos de qualquer tamanho, porém para equipes com mais
de 50 participantes algumas práticas adicionais são necessárias.
A partir da apresentação do modelo acima proposto por Highsmith faremos uma breve
explanação das práticas da fase Visão.
3. Práticas ágeis da fase “Visão”
O propósito dessa fase é criar uma visão clara para os clientes e membros do time de
projeto de “o que” será feito, “quem” fará e “como” será realizado o trabalho, ou seja,
identificar o escopo do projeto e a visão do produto, identificar pessoas que estarão
envolvidas no projeto (consumidores, membros do time de projeto, gerentes de produto e
stakeholders) e finalmente, a visualização por parte dos membros do time de projeto de como
atuarão em conjunto. Com relação às práticas dessa fase, Highsmith as divide em quatro
categorias (tabela 2).

Tabela 2 – Práticas da fase “Visão” do Gerenciamento Ágil de Projetos

Categoria Prática Objetivo
Visa focar a visão dispare dos membros do time do
produto em uma forma textual curta, visual e concisa.
Visão do produto e
4 Essas práticas fornecem uma visão de alto nível do
Declaração de elevador
Visão produto para os desenvolvedores, gerentes e pessoal de
do marketing.
produto Desenvolvimento da arquitetura técnica do produto,
que facilita a exploração e assegure um direcionamento
Arquitetura do produto
à condução dos trabalhos e à organização da equipe do
projeto.
Escopo Tem por objetivo “fazer saber a essência” em termos
do Folha de dados do projeto de escopo, cronograma, e recursos de como o projeto
projeto fará as entregas.
Montagem da equipe do projeto buscando sempre atrair
Escolha das pessoas certas
e selecionar os melhores talentos.
Comunidade Identificar todos os participantes do projeto, de forma
Identificação dos
do que as expectativas possam ser entendidas e
participantes
projeto gerenciadas.
Interface entre equipe do Definir a interface de colaboração entre a equipe do
cliente e equipe de projeto cliente e a equipe do projeto.
Adaptar uma estrutura de processo e prática guiada em
Adaptação de processos e parte por uma estratégia auto-organizada que defina a
Abordagem
práticas abordagem que a equipe de projeto terá no trabalho em
conjunto
Fonte: Adaptado de HIGHSMITH, 2004, p. 92.-125.

Para uma melhor delimitação do escopo e compreensão desse trabalho é importante

lembrar que estamos tratando de dois tipos diferentes de produtos, ou seja, software e
produtos físicos.

4
Adaptação do termo em inglês Elevator test statement

5
 Sendo assim, no tópico seguinte serão apresentadas algumas características que os
diferem e que conseqüentemente influem no modo como o Gerenciamento Ágil de Projetos
atua no desenvolvimento de produtos físicos.
4. Diferenças entre software e produto físico
Segundo Pressman, (1995, p. 13-16), para que se possa obter uma compreensão do que
é software é importante examinar as características que o tornam diferentes das outras coisas
que os seres humanos constroem. De acordo com o mesmo autor, software é um elemento de
sistema lógico e não físico. Portanto, ele possui características que são consideravelmente
diferentes do hardware (produto físico).
Essas características são apresentadas na tabela 3, a seguir.

Tabela 3 – Características de Software e Produtos Físicos

Tipos de Produto
Observações
Software Produto físico
Os custos do software estão concentrados no trabalho de
Desenvolvido ou Manufaturado
engenharia. Isso significa que os projetos de software não
projetado por no sentido
podem ser geridos como se fossem projetos de
engenharia clássico
manufatura
Quando se desgasta um componente de hardware é
substituído por uma “peça de reposição”. Não existem
peças de reposição para software. Toda falha de software
Não se indica um erro no projeto ou no processo por meio do
Características

Há desgaste
desgasta qual o projeto foi traduzido em código executável por
máquina. Portanto a manutenção de software envolve
consideravelmente maior complexidade do que a
manutenção de hardware.
Por exemplo, na construção do hardware cada circuito
integrado possui uma numeração de peça, uma função
validada e definida, uma interface bem definida e um
Feito
Feito conjunto padrão de diretrizes de integração. Depois que
em
sob cada componente é escolhido, o hardware pode ser
escala
medida montado. No caso de software isso não acontece, ou seja,
não existem catálogos ou “peças” pré-existentes que os
projetistas podem consultar ou utilizar para a construção
do software.
Fonte: Adaptado de Pressman 1995, p. 13-16

Dadas às características apresentadas acima entre os dois tipos de produtos se observa

que uma das principais diferenças é que nos produtos físicos, incluindo ou não software
embarcado, o processo de criação vai além da geração de informações. A única forma de
eliminar totalmente a ambigüidade do projeto é quando ele se materializa, isto é, quando há a
criação de protótipos, mock-ups e outros tipos de modelos, que sejam o mais próximo
possível da realidade concreta. Ao contrário de softwares onde descrições ou informações dos
produtos são menos ambíguas.
Outra diferença que podemos citar é a fase de manufatura. Ela pode introduzir
problemas de qualidade que inexistem ou que podem ser rapidamente corrigidos no
desenvolvimento de software, mas precisa estar eminentemente integrada com o processo
produtivo.
Portanto, através da observação das características e diferenças entre os dois tipos de
produtos citados por este artigo e a adoção das práticas do APM para o desenvolvimento de
produtos físicos, algumas questões são levantadas. Essas questões serão apresentadas e
discutidas nos tópicos seguintes.

6
5. Método de pesquisa
O método empregado foi o da revisão bibliográfica. Iniciou-se com a análise dos
trabalhos clássicos, entre estes, os livros de Highsmith e Chin e os artigos de Abrahamsson,
Beck, Cockburn, Dias, Fowler, Reifer e Sanjiv. Em seguida, foram analisados artigos do
período de 2001 até 2007, dos seguintes periódicos: International Journal of Project
Management; Journal of Product Innovation Management, Brazilian Journal of Product
Development Management, Project Management Journal, escolhidos pela reconhecida
representatividade na área de gestão de projetos e análise das referências contidas nos textos
básicos.
Outras fontes de pesquisas foram utilizadas como, bancos de dissertações e teses (
USP5 e UFSCar6) que disponibilizam versões para download e sites com informações sobre o
Gerenciamento Ágil de projetos como: www.agilejournal.com; www.martinfowler.com;
www.agilemanifesto.org e www.agilealliance.org.
6. Análise dos trabalhos
A partir da análise preliminar do material levantado por este trabalho pode-se concluir
que há um número significativo de trabalhos sobre a aplicação de metodologias ágeis para o
desenvolvimento de software. O site www.agilealliance.org registrou cerca de 56 artigos em
2000 contra 225 artigos em 2007, um crescimento significativo. A exemplo disso podemos
citar: Beck (1998); Cockburn (2002); Fowler (2000) e Sanjiv & Woodcock, (2003) entre os
principais trabalhos encontrados.
A seguir a tabela 4 apresenta uma lista com o ano de publicação, autor e título dos
trabalhos encontrados nas revistas avaliadas.

Tabela 4 – Trabalhos pesquisados

Ano Autor
1998 BECK, K.et al.
2000 FOWLER, M.
2002 COCKBURN, A.
2002 REIFER, J. et al.
2003 ABRAHAMSSON, P. et al.
2003 SANJIV, A. et al.
2003 UDO, N. et al.
2004 LINDSTRON, L. et al.
2004 RAWSTHORNE, D. et al.
2005 DIAS, M. V. B. et al.
2005 DIAS, M. V. B. et al
2005 MORIEN, R.
2005 TORRES, J. A. P et al.
2005 KARLSTRÖM, D. et al.
2005 AUGUSTINE, S. et al.
2006 MILLS, D. et al.
2006 KANE, D. W. et al.
2006 AMBLER, S. W.
2006 HANSSON, C. et al.
Título
Chrysler goes to “extremes”.
The new methodology
Agile software development joins the “would-be” crowd.
How good are agile methods?
New directions on agile methods: a comparative analysis
Agile project management: emergent order through visionary leadership.
Will agile change the way we manage software projects? Agile from a
PMBoK guide perspective.
Extreme programming and agile software development methodologies
Managing the work in an agile project
Agile project manajement: um novo enfoque para o gerenciamento de
projetos de desenvolvimento de sistemas de tecnologia de informação
Um novo enfoque para o gerenciamento de projetos de desenvolvimento de
software
Agile management and the Toyota way for software project management
Software development using agile methodologies: an airline case
Combining agile methods with gtage-gate project management
Agile project management: steering from the edges
Experiences using agile software development for a marketing simulation
Agile methods in biomedical software development: a multi-site experience
report
Initiating an agile project
How agile are industrial software development practices?

5
http://www.teses.usp.br
6
http://www.bco.ufscar.br

7
2006 OWEN, R et al. Is agile project management applicable to construction?
2007 BERTEIG, M. et al. Stories of agile work
2007 BARNETT, Liz. Why use agile processes outside of IT?
2007 POLLACK, J. The changing paradigms of project management

Nota-se que a totalidade dos trabalhos versa sobre a utilização do APM para o
desenvolvimento de software. Como única exceção podemos citar Owen (2006), que analisa a
aplicação do APM na indústria da construção.
Ainda, dentre os trabalhos identificados sobre as práticas ágeis em software foi
encontrada apenas uma dissertação de mestrado (DIAS, M. V. B. 2005) que aborda o enfoque
ágil para o desenvolvimento de sistemas de tecnologia de informação. Essa dissertação
constata que apesar dos trabalhos identificados pela autora, poucos são os que analisam a
eficácia ou fornecem indícios de resultados positivos ou negativos da aplicação do APM
(DIAS, 2005, p. 106).
Isso demonstra a relevância do tema especialmente na área de software. Porém, faz
surgir a questão: Será que tais práticas são igualmente relevantes na área de desenvolvimento
de produtos físicos, isto é, que envolvem também hardware ?
Uma forma de responder a esta pergunta pode ser por meio da comparação das
características diferenciais dos produtos físicos em relação aos princípios dos métodos ágeis.
O objetivo dessa análise foi identificar possíveis incompatibilidades ou aspectos que precisam
ser estudados para adaptar tais técnicas a essa área de aplicação.
Dessa forma, a formação da visão do produto no modelo de gerenciamento ágil de
projetos conta com as práticas e princípios que as norteiam conforme descrito anteriormente.
Essas práticas são adotadas com o intuito de atingir o objetivo dessa fase, ou seja,
fazer com que todos os envolvidos no projeto possuam uma visão comum do produto a ser
desenvolvido. Porém, tais práticas que visam, junto ao modelo de APM, entregar
características do produto aos clientes de forma incremental e cíclica, podem requerer
algumas adaptações em projetos de desenvolvimento de produtos físicos.
O diferencial entre o Gerenciamento Clássico de Projetos e o APM está nas equipes
adaptativas (auto-organizadas e autodisciplinadas) que devem formar, através das práticas,
uma visão em conjunto do produto a ser desenvolvido. Essa visão é a base para a criação do
escopo e planejamento do projeto. Porém, diferentemente do Gerenciamento Clássico de
Projetos, no APM o escopo do projeto não é fixo e pode variar conforme as mudanças
requisitadas pelos clientes durante as iterações do projeto.
Assim, com a adaptação das práticas do enfoque ágil para o desenvolvimento de
produtos físicos, alguns problemas podem surgir como: falta de metodologias adequadas para
descrição de interfaces do produto, falta de sistemas de informação capazes de fornecer dados
com qualidade e no tempo certo, dificuldades em atingir a auto-organizacão e
autodisciplinaridade em equipes compostas por vários integrantes, dificuldades em se saber
qual é o nível mínimo de documentação em produtos complexos de forma que todos os
envolvidos tenham em mente a mesma visão do produto ou ainda, problemas em favorecer a
exploração no desenvolvimento de produtos físicos cuja característica é o aumento do custo
de mudanças durante o projeto.
Por fim, através dos problemas levantados, algumas questões surgem com a utilização
do APM no desenvolvimento de produtos físicos. Essas questões são apresentadas na tabela 5
e serão discutidas no tópico Considerações Finais.

8
Tabela 5 – Adoção do APM para produtos físicos
Categoria Prática Questões relevantes
Qual o nível de detalhamento necessário?
Como compartilhar informações?
Visão do produto
Como utilizar modelos computacionais 3D para
estabelecimento da visão do produto?
Como trabalhar com equipes compostas por
Visão
especialidades distintas como hidráulica, elétrica,
do “Declaração de elevador”
eletrônica e mecânica, que utilizam diagramas e formas
produto
de especificação dos produtos distintos?
Até que ponto do projeto deve haver a definição da
arquitetura?
Arquitetura do produto
Como criar metodologias para descrever interfaces
entre equipes de projeto?

7. Considerações finais
Em face ao novo contexto vivido pelas empresas, que demandam novos produtos em
curtos períodos de tempo, o APM emerge como uma alternativa que se mostra potencialmente
capaz de superar essas barreiras.
Devido ao seu recente surgimento, ainda não se encontram casos de aplicações do
APM para o desenvolvimento de produtos físicos na literatura, porém como esse enfoque é
regido por valores e princípios, seu emprego pode ser extrapolado e cobrir uma ampla gama
de produtos, sejam eles físicos ou não.
Em seu livro, Highsmith, 2004 argumenta que na prática “Visão do produto e
declaração de elevador” deve haver a descrição das características do produto, essas
características são identificadas com a ajuda do time de projeto e clientes e gera a visão do
produto. Segundo o mesmo autor, essa visão para produtos grandes como, por exemplo,
automóveis ou equipamentos médico-eletrônicos, pode ser condensada em uma ou duas
páginas de papel ou ainda em uma ou duas páginas da Web. No entanto essa limitação de
espaço para a descrição da visão de produto tão complexo deve ser questionada. Conforme a
análise realizada neste trabalho, produtos grandes e complexos como, por exemplo,
automóveis, exigem maior detalhamento e participação de equipes multidisciplinares para que
os times tenham em mente os conceitos essenciais do produto e conseqüentemente possam
contribuir para o sucesso do projeto.
Outro ponto em questão e citado pelo autor seria o uso de ferramentas como
CAD/CAM para a criação da visão do produto. O uso de CAD/CAM com certeza auxilia os
projetistas, porém o compartilhamento de informações oriundas dessas ferramentas com todos
os membros dos times seria um problema, pois existem pessoas que não possuem o devido
domínio para a manipulação dos programas. Ao contrário da área de software onde descrições
de requisitos e diagramas de classe são padronizadas e podem ser compreendidas por todas as
partes da empresa.
A “declaração de elevador” por sua vez faz uma breve indicação do posicionamento
do produto, ou seja, o time escreve algumas sentenças que indicam os consumidores alvo, os
principais benefícios e as vantagens competitivas. No entanto, contrário a projetos de
desenvolvimento de software, os projetos de desenvolvimento de produtos físicos contam
com times maiores o que conseqüentemente ocasionaria a formação de equipes compostas de
pessoas com as mais variadas especialidades, dificultando assim a comunicação e o
entendimento mútuo durante essa prática.
Em projetos de desenvolvimento de produtos físicos utilizando-se metodologias ágeis,
a prática Arquitetura do Produto deve contar com a interfuncionalidade entre os times para a

9
definição exata das interfaces do produto bem como a mensuração dos impactos das
mudanças no projeto.
A interdisciplinaridade exigida por essa prática pode ser dificultada em equipes muito
grandes e compostas de especialistas de áreas distintas que não compartilham o mesmo local
de trabalho ou linguagem. Da mesma forma, a FBS7 que tem por objetivo representar a
arquitetura do produto e servir como instrumento de comunicação entre o time de
desenvolvimento e os clientes, pode ser de difícil compreensão em projetos complexos e de
grande porte. Um desafio identificado neste artigo é como desenvolver métodos e técnicas
que permitam construir esta visão.
Outro ponto obscuro apresentado por Highsmith seria o conceito de co-evolução entre
a organização de pessoas e a arquitetura do produto através do ciclo de vida do projeto. Essa
evolução da arquitetura técnica para produtos físicos deve ser bem discutida e acordada entre
times de desenvolvimento e cliente, pois caso haja uma evolução constante até o fim do
projeto pode haver problemas como, por exemplo, a produção de produtos que apesar de
possuírem várias características, não cumprem seu propósito. Ou seja, para isso deve existir
um consenso entre as equipes de até que ponto, a partir do início do projeto, a arquitetura
técnica deve ser discutida e definida.
Por fim, devido à constatação da inexistência de estudos que relacionam as
metodologias ágeis de projeto com o desenvolvimento de produtos físicos, o artigo identifica
que há um amplo campo de pesquisa surgindo nesta área. Sugere-se o desenvolvimento de
trabalhos que objetivem avaliar a aplicação dessas práticas bem como sua eficácia para o
desenvolvimento dos diversos tipos de produtos.
Dentre estes, podemos citar temas como: a influência de outras metodologias como o
Desdobramento da Função Qualidade (QFD) junto ao APM para a melhora da qualidade
resultante do projeto, desenvolver metodologias para descrever a interface entre equipes do
projeto, estudar ferramentas e criar metodologias que possam auxiliar o compartilhamento da
visão do produto entre os integrantes dos times envolvidos no projeto ou ainda, como utilizar
as ferramentas CAD e de prototipação virtual para criar visões do produto.
8. Referências
ABRAHAMSSON, P et al. New directions on agile method: a comparative analyses. In:
Proccedings of the 25th International Conference of Software Engineering. (S.1). IEE
Software Society, 2003. p. 244-254.
AGILE ALLIANCE. Manifesto for agile software development. Disponível em
<http://www.agilemanifesto.org/>. Acesso em: 05 Jun. 2007.
AMBLER, S. W. Initiating an Agile Project. Jun. 2006. Disponível em
<http://www.ddj.com/architect/188700850?cid=Ambysoft> Acesso em: 16 jun. 2007.
AUGUSTINE, S et al. Agile project management: steering from the edges. Communications
of ACM, December 2005/Vol. 48, No. 12.
BARNETT, Liz. Why Use Agile Processes Outside of IT? Jun. 2007. Disponível em
<http://www.agilejournal.com/articles/from-the-editor/why-use-agile-processes-outside-of-
it?.html> Acesso em: 19 julho 2007.
BECK, Kent et al. Manifesto for agile software development. Feb. 2001. Disponível em
<http://www.agilemanifesto.org/>. Acesso em: 05 Jun 2007.
BECK, K.et al. Chrysler goes to “extremes”. Out., 1998. Disponível em
<http://www.xprogramming.com/publications/dc9810cs.pdf > Acesso em: 08 jun 2007.

7
FBS – Feature Breakdown Structure

10
BERTEIG, M et al. Stories of Agile Work. Jun. 2007. Disponível em
<http://www.agilejournal.com/articles/articles/stories-of-agile-work.html> Acesso em: 10 jul
2007.
CHIN, G. Agile Project Management: how to succeed in the face of changing project
requirements. NY: Amacon, 2004. 229 p.
COCKBURN, A. Agile software development joins the “would-be” crowd. Jan.2002.
Disponível em: <http://www.agilealliance.org/system/article/file/782/file.pdf> Acesso em: 15
jun. 2007.
DIAS, M.V.B. Um novo enfoque para o gerenciamento de projetos de desenvolvimento
de software. Dissertação (Mestrado em Administração) – Faculdade de Economia,
Administração e Contabilidade da Universidade de São Paulo, 2005. 201 p.
DIAS, M.V.B.; SOLER, A. M. Agile project management: um novo enfoque para o
gerenciamento de projetos de desenvolvimento de sistemas de tecnologia de informação.
Disponível em <http://www.j2da.com.br/Download/Agile.pdf/>. Acesso em 05 jun 2007.
FOWLER, M. The new methodology. Jul., 2000. Disponível em
<http://www.martinfowler.com/articles/newMethodologyOriginal.html> Acesso em: 10 jun.
2007.
HIGHSMITH, J. Agile Project Management: creating innovative products. Boston:
Addisson - Wesley, 2004. 277 p.
KARLSTROM, D.; RUNESON, P. Combining agile methods with stage-gate project
management. IEEE Software, 2005.
MORIEN, R. Agile management and the Toyota way for software project management.
IEEE International Conference on Industrial Informatics, 2005.
OWEN, R.; KOSKELA, l.; HENRICH, G.; CODINHOTO, R. Is agile project management
applicable to construction?. Proceedings IGLC-14, July 2006, Santiago, Chile.
PEREZ, J. A et al. Software Development Using Agile Methodologies: An Airline Case.
In: Proceedings of the Sixth Mexican International Conference on Computer Science. IEEE,
2005.
POLLACK, J. The changing paradigms of project management. International Journal of
Project Management. Elsevier, n.25, 2007. p. 266-274.
PRESMAN, R.S. Engenharia de Software. São Paulo, Makron books, 1995.
PROJECT MANAGEMENT INSTITUTE – PMI. Guia PMBok: Um guia do conjunto de
conhecimentos do gerenciamento de projetos. Pennsylvania: Project Managemnt Institute, 3.
ed, 2004.
RAWSTHORNE, D et al. Managing the Work in an Agile Project. 2004. Disponível em:
<http://www.netobjectives.com/files/resources/downloads/ManagingTheWork.pdf>. Acesso
em: 15 jun. 2007.
REIFER, J. F.; DONALD, J. How good are agile methods? IEE Software, [SI], p. 14-17, jul-
ago, 2002.
ROZENFELD, H et al. Gestão de desenvolvimento de produtos: uma referência para a
melhoria do processo. São Paulo, Saraiva, 2006.
SANJIV, A.; WOODCOCK, S. Agile project management: emergent order through
visionary leadership. May, 2003. Disponível em:
<http:ccpace.com/resources/AgileProjectManagement.pdf>. Acesso em: 10 jun 2007.
UDO, N.; KOPPENSTEINER, S. Will agile change the way we manage software projects?
Agile from a PMBoK guide perspective. Projectway, [S.1.], 2003.
VERZUH, E. MBA Compacto, Gestão de Projetos. Rio de janeiro: Campus, 2000. 398 p.

11