Livro-Texto Unidade III elaboração e analise de projetos codigo 96312

Prévia do material em texto

185
ELABORAÇÃO E ANÁLISE DE PROJETOS
Unidade III
7 ANÁLISE DE VIABILIDADE DE PROJETOS
7.1 Análise de alternativas de projetos: fatores a serem considerados
Segundo Madureira (2010), em um contexto organizado de condução de projetos, o estudo da 
viabilidade segue uma fase inicial de planejamento do projeto na qual objetivos técnicos, econômicos e 
financeiros terão sido consensualmente estabelecidos pela empresa.
O estudo completo da viabilidade inicia‑se pela explicitação das funções a serem exercidas pelo 
produto (ou processo, serviço ou sistema) e a correspondente nomeação dos subsistemas que as 
exercerão. Para mostrar como essas duas etapas estão dispostas, apresenta‑se a seguir um roteiro para 
a condução metódica da análise técnica da viabilidade (MADUREIRA, 2014, p. 2):
1 – Em um contexto organizado de condução de projetos, o estudo da viabilidade se segue a uma 
fase inicial de planejamento do projeto na qual objetivos técnicos, econômicos e financeiros terão sido 
consensualmente estabelecidos pela empresa.
2 – O estudo completo da viabilidade inicia‑se pela explicitação das funções a serem exercidas pelo 
produto (ou processo, serviço ou sistema) e a correspondente nomeação dos subsistemas que as exercerão.
3 – A seguir, serão propostas soluções possíveis para cada uma dessas funções, em sessões de 
“palpitagem” coletiva (brainstorming ou brainwriting). É nessa etapa que as inovações poderão surgir, 
como respostas diretas à liberdade de expressão e estímulo à criatividade que a empresa proporcione 
aos seus colaboradores.
4 – A organização das soluções propostas para cada função permitirá a montagem em uma matriz 
de síntese, formando um conjunto de possíveis soluções técnicas para o produto.
5 – A análise técnica começará pela avaliação da capacidade de cada uma das soluções possíveis 
em atender os requisitos técnicos funcionais e operacionais estabelecidos no planejamento. Essa 
tarefa consiste em verificar se cada solução proposta poderá atender a requisitos como desempenho, 
segurança, confiabilidade e todos os outros. Cada análise produzirá conclusões positivas ou negativas, a 
serem completamente documentadas. Essa função será mais simples em projetos evolutivos, mas exigirá 
empenho, competência e poderosos recursos técnicos no caso de soluções inovadoras. Os relatórios terão 
portes bem diferentes: desde uma simples nota sobre pesquisa bibliográfica até extensos conteúdos 
baseados nos resultados de testes e simulações. O produto desse trabalho será um conjunto de soluções 
viáveis em termos de atendimento aos requisitos técnicos. Nessa etapa, ocorrerá a pesquisa de patentes 
e, muito importante, o envio ao INPI (Instituto Nacional da Propriedade Industrial) dos pedidos de 
registro de patentes de eventuais soluções inovadoras.
186
Unidade III
6 – Entretanto, a viabilidade técnica ainda não está assegurada. É preciso também verificar a 
viabilidade de projeto, fabricação (e/ou implantação) e fornecimento, na qualidade, no prazo e no 
volume necessários para o projeto.
7 – A viabilidade de projeto verificará a capacidade técnica da empresa de projetar, prototipar, testar 
e certificar a solução. A equipe técnica da empresa pode ou não deter ou desenvolver a tecnologia; 
a contratação de novos técnicos ou, ainda, a terceirização de parte do projeto podem ou não ser 
possíveis pela existência de competência externa disponível no prazo previsto para o desenvolvimento. 
Nessa verificação, será imprescindível a participação ativa das áreas de suprimentos e recursos 
humanos da empresa.
8 – A viabilidade de fabricação e fornecimento será verificada pelas áreas de processos e suprimentos 
da empresa sobre as soluções sobreviventes à etapa anterior. Nesse momento do projeto impõe‑se 
fortemente a chamada Engenharia Simultânea, pela qual as áreas de projeto transferem à manufatura 
todas as informações necessárias para a síntese de soluções de fabricação e suprimento. Nessa fase, 
repetem‑se de forma análoga às etapas 2, 3, 4 e 5 anteriores, incluindo a geração de inovações, para 
os processos de fabricação. A participação e o comprometimento de todas as áreas, em especial dos 
fornecedores mais importantes, é mandatória. As soluções sobreviventes são consideradas viáveis em 
termos de fabricação e fornecimento.
9 – O estudo da viabilidade técnica aqui terminado fornece as soluções tecnicamente viáveis, as 
quais (e somente elas) passarão à análise de viabilidade econômica e financeira do projeto.
10 – Assim, fica claro que não há sentido algum em executar análises econômica e financeira de 
soluções ainda não viáveis tecnicamente.
Agora é preciso entender quem será responsável por essa análise, pois diferentes entendimentos 
sobre fracasso ou sucesso levam a várias conclusões. Assim, ao analisar os fatores de fracasso ou sucesso 
de um projeto, passa‑se, obrigatoriamente, pelo entendimento de quem será responsável por essa 
análise. Isso porque pessoas distintas têm diferentes visões sobre o mesmo assunto, e devemos levá‑las 
em consideração em respeito à natureza do entendimento do que é fracasso e do que é sucesso.
Em gestão de projetos devem ser usados indicadores que mostrem se o que foi pensado foi atendido 
(ainda que parcial ou plenamente), e assim será possível garantir que o investimento de tempo, dinheiro 
e mão de obra trará os resultados esperados.
Dois pontos merecem atenção na busca pelo sucesso, em quaisquer que sejam os procedimentos e 
áreas de atividades: 
• Foco: significa a visão de um objetivo bem definido para as pessoas, em qualquer área de atuação, 
seja profissional, seja pessoal. Não será possível entender qualquer ponto de vista de sucesso em 
uma atividade se ela não for conduzida com o maior foco possível.
187
ELABORAÇÃO E ANÁLISE DE PROJETOS
• Planejamento: é um conceito comum no âmbito da administração, o qual significa o ato de 
pensar e fazer planos de uma maneira estratégica. Nenhuma ação deve ser dirigida sem um 
mínimo de planejamento anterior. Tenha em mente a Observação de que o planejamento anterior 
não é algo que não possa ser mudado, mas sim que deve ser adequado às mudanças que vão 
surgir no decorrer das ações. Quanto mais o gerente de determinado projeto entender o conceito 
de estratégia, mais conhecimento ele terá de suas responsabilidades para tomar decisão.
Em um projeto, a atuação do gerente de projetos, assim como a comunicação, tanto interna como 
externa, deve ser objetiva, com a descrição das definições, do cronograma e seu tempo para execução, 
posicionamento do projeto em relação aos propósitos do cliente e respeito às normas da organização 
incumbida pela realização.
Para Jorge (2015), alguns dos fatores considerados críticos para o sucesso de um projeto podem ser 
vistos a seguir:
– Apoio da alta gerência: no sentido de fornecer recursos, diretrizes 
e autoridade (poder) necessários para a execução do projeto.
– Plano e cronograma do projeto: deve conter as especificações, 
de forma detalhada, dos passos e das ações para a execução e 
implantação do projeto.
– Envolvimento do cliente: comunicação, de forma periódica, clara 
e objetiva, e participação de todos os envolvidos.
– Pessoal: recrutamento e capacitação da equipe envolvida no projeto.
– Recursos tecnológicos: ter à disposição os recursos tecnológicos 
necessários, e os conhecimentos necessários para sua utilização, e 
que sejam necessários para a execução do projeto.
– Acompanhamento (feedback): fornecer, de forma periódica, as 
informações referentes aos progressos alcançados e adequação do 
planejamento de acordo com as eventuais alterações no escopo. 
Importante destacar que a documentação completa é essencial 
para evitar futuros problemas de entendimento.
– Comunicação: frequente entre todos os envolvidos, interna e 
externamente, na execução de cada uma das etapas.
– Solução de problemas: demonstrar habilidade na solução de 
problemas e conflitos que podem ocorrer durante a execução 
do projeto.
188
Unidade III
De certomodo, pode‑se entender que a não execução de um dos tópicos tratados no item anterior pode 
levar um projeto ao fracasso, ou contribuir, de forma considerável, para que os produtos obtidos fiquem 
muito aquém do esperado, considerando que os projetos incluem as restrições: escopo, prazo e custo.
Ainda de acordo com Jorge (2015):
Contudo, vale ressaltar que há questões complementares diretamente 
ligadas ao insucesso dos projetos, entre elas vale destacar:
– Ausência ou deficiência de planejamento: um planejamento 
incompleto ou falho pode causar os mesmos problemas caso 
não se tenha um.
– Dimensionamento equivocado: principalmente no que diz respeito 
à questão de prazos e custos de elaboração do projeto.
– Falta de apoio da direção: esse ponto pode ser considerado 
crucial para o insucesso de um projeto. Caso não exista o apoio 
da maioria do corpo diretivo da organização, o gerente de projeto 
não terá condições de executar suas atividades com a efetividade 
necessária (autoridade, comunicação, gerenciar mudanças, 
conflitos, custos etc.).
– Comunicação: a falta de uma comunicação clara e objetiva 
com todos os envolvidos (dentro e fora da organização) poderá 
comprometer severamente a execução do projeto.
– Capacitação profissional: caso os profissionais destacados, nas 
diferentes áreas do projeto, não possuírem a capacitação necessária, 
a probabilidade de erros de especificação e execução será muito 
maior, o que resultará no insucesso.
A vivência de profissionais, principalmente do gerente responsável de projetos, será de notável 
importância, já que serão identificáveis alguns sinais que indiquem falhas na criação do projeto e que devem 
ser retificados. A teimosia em seguir em frente, mesmo com esses indicativos, resultará no fracasso do projeto.
É possível perceber que o sucesso, ou fracasso, de um projeto não são causados por um ou mais 
fatores isolados, mas que, de forma simultânea, resultarão na solução final, favorável ou desfavorável.
De acordo com Vargas (2005, p. 7),
Os projetos são atividades caracterizadas por uma sequência clara e lógica 
de eventos para atingir objetivos dentro de um tempo, custo e recursos 
prévios definidos, combinam recursos organizacionais e necessitam de uma 
189
ELABORAÇÃO E ANÁLISE DE PROJETOS
coordenação para controle de prazos, custos e desempenho, pois atingem 
todos os níveis de uma organização e as partes interessadas externas à 
instituição assim como os clientes, fornecedores, parceiros, governo etc.
O principal responsável pelo ajuste das variáveis implicadas é o gerente de projetos, que deverá atuar 
como um maestro regendo os integrantes da equipe no sentido de obter ações planejadas, as quais 
resultem na perfeita execução da música escolhida: projeto entregue no prazo, dentro do custo previsto 
e que atenda aos critérios originais. No fracasso acontece o inverso, ou seja, os objetivos previstos não 
foram obtidos.
Dessa forma, para definir o fracasso ou o sucesso de um projeto, depende‑se do estabelecimento 
de modelos de desempenho que permitam confrontar os resultados obtidos com as metas planejadas.
7.2 Fatores a serem considerados: viabilidade econômica e financeira
A análise de viabilidade econômica e financeira é um estudo que visa verificar se um investimento é 
viável ou não. Ela comparará os retornos que poderão ser conseguidos com os investimentos pretendidos 
para decidir se vale ou não investir, e é muito importante porque mede se um investimento trará retorno 
ou não para o investidor.
Com isso, o investidor consegue deixar de lado projetos em que não compensa investir e direcionar 
seu dinheiro para aqueles mais favoráveis, principalmente quando é necessário decidir entre dois ou 
mais projetos e se há dinheiro para investir em apenas um.
Para fazer uma análise de viabilidade econômica é necessário seguir algumas fases, sendo 
as principais:
• projeção de receitas do projeto;
• projeção de custos e despesas;
• quais os investimentos necessários;
• análise de indicadores calculados em cima dos dados de receitas, despesas, custos e investimentos.
7.3 Projeção de receitas
A projeção de receitas deve seguir alguns elementos, como conhecer muito bem o mercado para 
evitar traçar números que sejam difíceis de atingir. Outro princípio importante é o de nunca começar 
a projeção de receitas com a capacidade total de produção, ou seja, deve‑se começar a criação com 
números mais racionais, como 40% da capacidade ou até menos, sempre conforme o mercado e os 
investimentos que serão feitos.
190
Unidade III
E o último princípio importante é pensar no crescimento das receitas, e isso é válido também 
para esboçar custos, despesas e aplicações, pois tanto eles como a receita dificilmente permanecerão 
na mesma escala. Na tabela que se segue, verifique um exemplo da projeção de receitas baseado na 
estimativa de vendas de quatro produtos:
Tabela 1 – Exemplo de projeção de receitas
Receitas de vendas Jan Fev Mar Abr Mai Jun Jul Ago Set Out Nov Dez
Produto A 100 100 120 125 130 140 142 145 160 170 180 200
Produto B 50 55 60 65 70 65 68 70 75 80 90 100
Produto C 20 23 25 27 28 29 32 35 40 42 44 50
Produto D 45 50 52 55 60 70 72 75 80 85 90 95
Receita total 215 228 257 272 288 304 314 325 355 377 404 445
7.4 Projeção de custos e despesas
Quando do estudo da viabilidade econômica e financeira, a projeção de custos, despesas e 
investimentos deve seguir algumas premissas, sendo a principal delas a de que devem existir custos, 
despesas e investimentos que justifiquem a projeção de receitas.
Por exemplo, a possibilidade de você projetar uma grande participação de mercado. É necessário 
que sejam realizados gastos elevados com propaganda, valendo avisar também sobre a relevância de 
se projetar os reinvestimentos. Um erro muito comum é considerar apenas um investimento inicial e 
assumir que a estrutura da empresa não irá se alterar.
Veja na tabela que se segue o exemplo de projeção de despesas para os mesmos quatro produtos da 
tabela anterior.
Tabela 2 – Exemplo de projeção de custos e despesas
Despesas Jan Fev Mar Abr Mai Jun Jul Ago Set Out Nov Dez
Produto A 50 50 60 60 62 67 68 65 70 75 79 84
Produto B 20 22 24 26 28 26 27 29 29 30 34 38
Produto C 7 8,1 8,8 9,5 9,8 9,9 11 12 14 14 15 17
Produto D 20,3 21 22 23 25 29 30 32 32 34 36 38
Despesa total 97,3 101 115 119 125 132 136 138 145 153 164 177
7.5 Projeção dos fluxos de caixa e indicadores
O fluxo de caixa é a verificação da performance das entradas e saídas de dinheiro que já aconteceram 
na organização, sendo um instrumento muito útil para realizar a gestão financeira da empresa. O fluxo 
de caixa será obtido pela diferença entre os lançamentos das receitas e das despesas. Como exemplo, o 
gráfico a seguir mostra como fica o fluxo de caixa para as projeções de receitas e despesas que foram 
apresentadas nas tabelas anteriores.
191
ELABORAÇÃO E ANÁLISE DE PROJETOS
Receita Despesa Fluxo de caixa
900 
800
700
600
500
400
300
200
100
0
Jan Fev Mar Abr Mai Jun Jul Ago Set Out Nov Dez
Figura 39 –Projeção de fluxo de caixa
• Valor presente líquido (VPL): o valor presente líquido (VPL) de um projeto de investimento 
pode ser definido como a soma algébrica dos valores descontados do fluxo de caixa, bem como 
o valor presente de pagamentos futuros, descontada uma taxa de custo de capital. O projeto que 
apresenta o VPL maior que zero (positivo) é economicamente viável, sendo considerado o melhor 
aquele que apresentar maior VPL. Caso seu valor seja nulo (zero), significa que o projeto se paga 
ao longo dos anos, mas sem gerar lucro. E, finalmente, se o resultado for negativo, significa que o 
projeto gera prejuízo, ou seja, não há rentabilidade alguma.
• Taxa interna de retorno (TIR): a taxa interna de retorno (em inglês internal rate of return – IRR) 
representa a rentabilidade de um investimento. Ela é usada para avaliar qualo percentual de 
retorno de um projeto para a empresa, seguindo a periodicidade dos fluxos de caixa, podendo ser 
em semanas, meses, bimestres, semestres ou mesmo anual.
• Payback: (que em português significa retorno) é uma técnica muito utilizada nas empresas 
para análise do prazo de retorno do investimento em um projeto. É o indicador que mede 
quanto tempo um projeto levará para gerar os retornos financeiros que justifiquem o 
investimento. Existem duas formas de calcular o payback; a primeira é o payback tradicional, 
também chamado de payback simples, que não leva em consideração o valor do dinheiro 
no tempo. Por exemplo, se você investiu R$ 200 mil em uma empresa e ela gera retornos 
mensais de R$10 mil, o payback será de 20 meses. Caso deseje calcular o retorno em anos, 
é só dividir o valor do investimento inicial pela quantidade de anos que deseja o retorno. 
PB  = R$ 200.000,00/24 meses (dois anos) = R$ 8.333,33 (ou seja, você precisará de um 
retorno, por aproximação, de R$ 8.334,00 por mês).
192
Unidade III
7.6 Ciclo de vida de um projeto
É preciso saber como identificar as suas reais necessidades, pois isso é o que vai gerar o projeto. O 
fluxograma que veremos a seguir mostra a situação perfeita quando há uma necessidade que deve ser 
atendida com um projeto. Todo projeto é como uma entidade viva e apresenta um ciclo de vida. Veja o 
fluxograma a seguir:
Necessidades Seleção do projeto
Planejamento 
do projeto
Avaliação do projeto Controle do projeto
Implementação 
do projeto
Conclusão do projeto
Figura 40 – Fluxograma do ciclo de vida de um projeto
O ideal é ter alternativas para atender à necessidade, e, entre estas, poder escolher a que melhor 
atende aos objetivos.
Muitas vezes, o grande desafio é identificar qual seria a melhor solução para os problemas que se 
apresentam. Há momentos em que há tantas alternativas para resolver problemas que acabamos ficando 
na dúvida de qual seria a melhor solução para realizar o projeto. Como isso é comum, é necessário 
dominar as técnicas que vão ajudá‑lo a se decidir quando tiver várias alternativas de projeto a escolher.
A análise do ambiente da empresa auxilia na definição das necessidades do cliente. Ela deve considerar 
os ambientes interno e externo na busca de informações sobre o mercado fornecedor, composto pelos 
fornecedores que ofertam matéria‑prima, equipamentos, embalagens e outras mercadorias necessárias 
para o funcionamento da empresa, governo e concorrentes, que é formado pelas organizações que 
oferecem produtos ou serviços idênticos ou similares aos seus.
Essas informações ajudam no reconhecimento das pressões e restrições para a condução do projeto. 
Além disso, revelam as pressões internas dos objetivos da organização, da alta administração, das chefias, 
da limitação de recursos e dos usuários internos.
Um bom início consiste em estabelecer uma adequada correlação entre as necessidades existentes e 
as possibilidades de projetos. Veja como esse ciclo se realiza na figura a seguir.
193
ELABORAÇÃO E ANÁLISE DE PROJETOS
Emergência da necessidade
Reconhecer a necessidade
Articular a necessidade
Estabelecer os 
requisitos funcionais
Articular 
os requisitos 
técnicos
Figura 41 – Identificação de necessidades e requisitos
Todo projeto possui um ou mais clientes, sejam eles internos, sejam eles externos. Na prática, a 
coleta dos requisitos estabelece os produtos e serviços que serão gerados e entregues ao cliente, o que 
chamamos de “escopo do cliente”. Vejamos uma exemplificação:
• Do cliente emerge a necessidade, como o conserto de seu automóvel.
• Os especialistas reconhecem a sua necessidade, assim como um mecânico faz perguntas ao seu 
cliente para poder identificar a causa do problema e dos sintomas apresentados pelo automóvel.
• Os especialistas articulam as necessidades, assim como um mecânico gera possibilidades para 
atender às demandas funcionais, estéticas e orçamentárias de seu cliente.
• Os especialistas também estabelecem os requisitos funcionais para que os clientes entendam o 
resultado do projeto, que estará pronto e quando, tais como: velocidade máxima, segurança e 
conforto podem ser entendidos num carro.
• Os especialistas dividem os requisitos funcionais em requisitos técnicos, mais quantificáveis e 
melhor controláveis para eles, durante o progresso do projeto. É o caso da tradução de “conforto” 
com a especificação da densidade da espuma dos bancos, da ergonomia banco‑volante e da 
variação de temperatura no interior do veículo.
194
Unidade III
Lembre‑se que na identificação das necessidades evidencia‑se a importância de dois procedimentos 
adicionais: o primeiro é certificar‑se de que foi corretamente compreendida a real necessidade do cliente. 
O segundo é gerar várias alternativas de soluções para resolver o mesmo desafio. Feito isso, temos uma 
série de alternativas em que é preciso avaliar e selecionar a que melhor nos atende.
A seleção entre as alternativas
No processo de entendimento e na geração de possibilidades, além de desenvolver a melhor solução, 
permite que os futuros envolvidos na construção do projeto criem comprometimento. A motivação 
gerada por um trabalho prévio como este será sentida durante a implementação e após a conclusão do 
projeto. Existem vários fatores que interferem na seleção do projeto:
• Produção: capacidade, know‑how.
• Financeiros: disponibilidade de capital, custos.
• Humanos: existência dos recursos humanos com competência para execução, disponibilidade e 
conhecimento.
• Administrativos: como suporte, comunicação e controle.
• Econômico: como a taxa de retorno do investimento, o valor presente do capital e o tempo de 
retorno do investimento.
• Tempo: disponibilidade para a implantação.
Análise de custo‑benefício
Pode ser utilizada para comparar projetos por meio de um ranking. É através deste conceito que 
as pessoas ou empresas compram ou realizam algo cujo benefício é maior que o custo de comprar 
ou produzir.
Custo de oportunidade
Custo de oportunidade é um conceito teórico que mensura o custo daquilo que se deixa de fazer 
quando é preciso fazer uma escolha de qualquer tipo (também conhecido como trade‑off). Por exemplo, 
supondo que queiramos fazer com que um produto de consumo chegue mais rápido nas mãos do 
consumidor final. Várias alternativas são viáveis: entrega direta da fábrica ao consumidor, entrega através 
de distribuidores próprios, entrega através de distribuidores terceirizados. Se esta última alternativa 
apresentar o menor custo de oportunidade por ter exigido o menor investimento da empresa em relação 
ao que seria feito nas outras alternativas, deverá ser a escolhida.
195
ELABORAÇÃO E ANÁLISE DE PROJETOS
7.7 Técnicas de orçamento de investimento
Monta‑se uma tabela em que é possível verificar os vários critérios para as diversas alternativas de 
projetos existentes, seus custos e retorno a cada período de investimento.
• Ranking de projetos: o grau de contribuição para objetivos, estratégia e prioridades de negócios 
da empresa; o retorno de cada projeto; e, por fim, a disponibilidade de recursos e capacidade de 
realização são as principais formas de elaborar o ranking de projetos.
• Técnicas de parametrização: consiste em um grupo de técnicas que estabelece, previamente, 
parâmetros que devem ser utilizados para selecionar os projetos, sendo o processo de decisão 
e definição dos parâmetros necessários para uma especificação completa ou relevante de um 
modelo. Alguns desses parâmetros são mandatórios e devem ser obedecidos pela solução para 
que ela possa ser considerada, outros são parâmetros que apenas auxiliam na diferenciação entre 
as soluções. Esses últimos parâmetros podem receber pesos e notas diferentes para auxiliar a 
escolha do projeto a ser desenvolvido.
1º Passo: selecione os critérios de decisão
Uma empresa familiar cresceu muito nos últimos anos e deseja contratar um profissional que 
gerencie seu escritório de projetos, que deve ser experiente na área,disponível e apresentar algumas 
outras características. Para evitar que se escolhesse ao acaso este profissional, os executivos reuniram‑se 
e identificaram os critérios que deveriam ser empregados para buscar este candidato. Para avaliação dos 
candidatos, deveriam ser respeitados os seguintes critérios:
• salário máximo de R$ 20 mil mensais;
• morar na cidade;
• possuir veículo próprio.
Atendidos esses critérios, os candidatos seriam diferenciados pelos seguintes fatores:
• ter fluência numa segunda língua, com preferência pelo inglês;
• disponibilidade para iniciar as atividades o mais rapidamente possível;
• experiência em gerenciamento de projetos;
• experiência administrativa;
• conhecimento de ferramentas para o gerenciamento;
• conhecimento das metodologias de gerenciamento de projetos.
196
Unidade III
2º Passo: dê pesos aos desejos
Entre os desejos da direção da empresa, o mais importante é que o candidato tenha muita experiência em 
gerenciamento de projetos, razão pela qual o peso que lhe foi conferido foi de 10 pontos. O conhecimento 
de uma metodologia para gerenciamento de projetos também era um critério importante, porém não 
tão importante quanto o anterior, e recebeu então 9 pontos. E assim todos os critérios receberam pontos. 
Identificados e pontuados os padrões, foi preenchido o formulário, e a empresa foi ao mercado buscar os 
candidatos. Quatro candidatos surgiram: Wilson, Otávio, Gabriel e Bernardo.
3º Passo: avalie alternativas que atendam às obrigações
Ao serem analisadas as possibilidades para cumprimento da função, Gabriel e Bernardo não 
atendiam a dois critérios, sendo preteridos da análise. Wilson e Otávio atendiam a todos os critérios e 
passaram, assim, para a segunda fase da análise, quando as medidas empregadas deveriam diferenciá‑los.
4º Passo: pontue os desejos das alternativas que atenderam às obrigações
O candidato Wilson foi avaliado segundo os fatores. Ele possuía inglês básico, no prazo de dois 
meses poderia desligar‑se de sua atual empresa, possuía experiência profissional de oito anos e há 
quatro atuava como gerente de projetos. Já na experiência administrativa, tinha três anos em empresa 
multinacional e conhecia as metodologias para o gerenciamento de projetos, o software MS Project e 
alguns outros de documentação.
Já o candidato Otávio era fluente em inglês e em um mês poderia assumir o projeto. Sua experiência 
administrativa era de quatro anos numa empresa familiar – seu primeiro emprego depois de formado 
na universidade –, sendo que destes, dois anos foram no gerenciamento de projetos. Seu conhecimento 
sobre software era apenas do MS Project e também não possuía conhecimento de qualquer metodologia 
para o gerenciamento de projetos.
5º Passo: compute as pontuações e selecione a alternativa vencedora
O passo seguinte foi iniciar a comparação entre eles no atendimento a cada ponto desejado. O melhor 
em cada quesito ganhava a nota 10, e o outro, uma nota que refletisse o quão distante estaria da nota 
10 do seu concorrente. Como exemplo, o fato de Otávio ter inglês fluente lhe conferiu a nota 10 naquele 
quesito. Wilson, com seu inglês básico, ganhou uma pontuação 7, por estar distante do conhecimento no 
idioma que Otávio possuía. E assim todos os outros quesitos foram avaliados e pontuados no formulário.
Ao serem totalizados os pontos de cada candidato, Wilson foi o vencedor, por atingir um número 
maior de pontos. Poderíamos deixar a escolha ainda melhor se admitíssemos que a pontuação de ambos 
havia ficado muito próxima. Para tanto, faríamos uma análise de riscos associada a cada alternativa, a cada 
candidato: suas consequências, probabilidades, gravidades e ações corretivas prováveis. Incorporaríamos 
estas ações corretivas e reavaliaríamos as alternativas sob esta nova ótica.
Você pode imaginar outra forma de seleção de pessoas para um projeto?
197
ELABORAÇÃO E ANÁLISE DE PROJETOS
8 PROJETOS ÁGEIS: NOVAS SOLUÇÕES NO GERENCIAMENTO DE PROJETOS
Com a maturação da indústria de software, problemas com uma possível demora entre as 
necessidades do cliente e as entregas começaram a surgir, e a necessidade de encontrar novas 
soluções se tornou óbvia. Foi então criada a Metodologia Ágil, que tem a função de agilizar o processo 
de desenvolvimento, principalmente no que diz respeito à utilização do software pelo cliente.
Assim, em 2001, um grupo de programadores lançou o Manifesto Ágil, pregando uma metodologia 
que tem como objetivo satisfazer os clientes entregando com maior rapidez e com maior frequência 
versões do software conforme as necessidades. Ou seja, a partir de uma versão lançada, embora não 
absolutamente completa, pode‑se modificar o software de acordo com as necessidades do cliente. 
Do contrário, o software final demoraria tanto para ficar pronto que poderia se tornar ultrapassado. 
Afinal, é melhor ter um software para entregar – e com a possibilidade de ele ser melhorado com o 
tempo – do que passar todo o processo sem qualquer entrega, e, depois de pronto, ser ultrapassado 
pela versão de um concorrente.
A Metodologia Ágil viabilizou como elaborar um projeto com intensa interatividade. Toda a equipe 
deve trabalhar de um jeito consistente para obter bons resultados, devendo acontecer colaboração 
e tomada de decisões em conjunto, fazendo com que todos sejam um só em busca de um objetivo. 
Também é fundamental que o cliente faça parte dessa abordagem interativa, garantindo que suas 
expectativas sejam atendidas.
As entregas aos clientes são feitas com mais rapidez, por serem entregas incrementais, e não a 
entrega de todo o projeto, o que, teoricamente, seria mais rápido, já que muitos pensam que por meio 
da Metodologia Ágil a entrega total é mais rápida, e isso não é necessariamente verdade.
Basicamente, a Metodologia Ágil foi criada para o desenvolvimento de softwares, mas, com o tempo, 
outras áreas começaram a perceber a possibilidade de êxito dos projetos ao adotar essa forma de gestão 
de projetos. E por que isso? Porque, atualmente, não há mais tempo para ficar esperando pela conclusão de 
um projeto inteiro. As empresas querem otimização do tempo e recursos, e, principalmente, dos resultados. 
Por isso, se houver uma forma de entregar uma parte e já conseguir algum feedback com essa parte, 
experimenta‑se a aceitação do cliente e adequam‑se as próximas entregas baseando‑se nos feedbacks.
No mundo, as mudanças chegam em uma velocidade incrível; assim, na fase atual, quem não for 
ágil, principalmente em épocas de instabilidades econômicas e políticas, o que pode fazer para mudar 
cenários inteiros? Aqui está o grande ganho nos métodos ágeis. Por isso, a Metodologia Ágil ganhou 
força em vários setores e deu uma nova opção aos profissionais ao arquitetarem um projeto.
Um pensamento incorreto de muitos: “Vou para o método Ágil porque não é preciso planejar nem 
deixar nada documentado”. Trata‑se do indivíduo que gosta de sair fazendo. Na realidade, por vezes dá 
até mais trabalho, pois frequentemente a pessoa começa um projeto sem ter clara a visão do todo no 
final, por visualizar apenas a parte que será feita no sprint que está por iniciar. Então, ouve‑se: “Puxa 
vida, se eu tivesse essa visão do todo desde o início, teria feito de forma diferente”.
198
Unidade III
Pense que a ideia é gerar valor ao cliente, pelas entregas incrementais, e não pensar como um 
preguiçoso, do que é mais fácil para si mesmo.
8.1 O que é o Manifesto Ágil?
O que é o Scrum?
Segundo a consultoria Atlassian, Scrum é uma estrutura que ajuda as equipes a trabalharem juntas. 
Semelhante a uma equipe de rugby (de onde vem o nome) treinando para o grande jogo, o Scrum 
estimula as equipes a aprenderem com as experiências, a se organizarem enquanto resolvem um 
problema e a refletirem sobre os êxitos e fracassos para melhorarem sempre.
Embora o Scrum sobre o qual estou falando seja mais usado pelas equipes de desenvolvimento de 
software, os princípios e as lições dessa estrutura podem ser aplicados a todosos tipos de trabalhos em 
equipe. Esse é um dos motivos de o Scrum ser tão popular. Muitas vezes considerado uma estrutura de 
gestão de projetos de agilidade, o Scrum descreve um conjunto de reuniões, ferramentas e cargos 
que atuam juntos para ajudar as equipes a organizarem e gerenciarem o trabalho.
Muitas pessoas usam o termo metodologia Ágil e metodologia Ágil Scrum como se fossem a mesma 
coisa, e não são. Na realidade, o Scrum é um dos meios para aplicar os métodos ágeis. Dizemos que 
é um dos frameworks ágeis. Existem outros, mas o Scrum é o mais conhecido, sendo o método Ágil 
mais usado na atualidade. Focado na gestão do projeto, o Scrum tem foco nas pessoas e garante mais 
dinâmica ao envolver o cliente diretamente com o desenvolvimento dos produtos do projeto. Tem 
como base o desenvolvimento iterativo incremental (de melhorias), que se dá por etapas de tempo fixo, 
denominadas sprints.
 Observação
Iteração é o processo que se repete diversas vezes para chegar a um 
resultado, e a cada vez gera um resultado parcial que será usado na 
vez seguinte.
O Scrum tem três papéis muito importantes e definidos para garantir o sucesso da empreitada. 
São eles: scrum master, que é o líder da equipe; o PO (project owner), que é a pessoa de negócio do 
projeto, que faz a interface entre o cliente e a equipe; e o scrum team, que é a equipe responsável pelo 
desenvolvimento do projeto.
Existem outras formas de aplicar os métodos ágeis, entre eles, a Metodologia Ágil XP (Extreme 
Programming), que é dirigida ao desenvolvimento de softwares, realizada a partir de três suportes: 
agilidade no desenvolvimento da solução, economia de recursos e qualidade do produto final. Para 
chegar à excelência dos serviços, esse método também é focado em valores como a comunicação, a 
simplicidade, o feedback, a coragem e o respeito.
199
ELABORAÇÃO E ANÁLISE DE PROJETOS
No entanto, também poderíamos citar outros: o FDD (Feature Driven Development), que engloba 
as melhores práticas dos outros métodos, focando na funcionalidade, com planejamento de entregas 
incremental e que pode ser integrado ao Scrum, buscando sempre o método mais vantajoso para o 
desenvolvimento do projeto em questão. Outro método Ágil é o MSF (Microsoft Solutions Framework), 
que é muito utilizado para o desenvolvimento de soluções tecnológicas por equipes reduzidas, focando 
na redução dos riscos e aumento da qualidade final.
Outra ferramenta da metodologia ágil é o DSDM (Dynamic System Development Model), que é um 
dos métodos ágeis mais antigos para desenvolvimento de projetos. É destinado ao desenvolvimento 
de projetos com orçamento fixo e prazos reduzidos e também tem desenvolvimento incremental 
e frequente.
8.2 Visão geral do Scrum
O Scrum é uma metodologia usada para a gestão dinâmica de projetos, sendo muitas vezes aplicada 
para o desenvolvimento ágil de projetos, no qual as pessoas podem lidar com problemas adaptativos 
complexos enquanto fornecem produtos de maneira mais produtiva e criativa possível.
No Scrum, os projetos acontecem em uma série de iterações, com um mês de duração, chamadas 
sprints. Ele é ideal para projetos cujos requisitos mudam rapidamente ou são altamente emergentes.
O trabalho a ser feito em um projeto Scrum é registrado nas pendências do produto (product 
backlog), que é uma lista de todos os desejos de mudança no produto. No início de cada incremento é 
feita uma reunião de planejamento de incremento (sprint planning meeting), na qual o PO prioriza as 
pendências do produto (product backlog), e a equipe Scrum (Scrum team) seleciona as tarefas que pode 
completar durante o próximo incremento.
 Lembrete
No Scrum, os projetos são divididos em ciclos (tipicamente mensais) 
chamados de sprints. O sprint representa um time box dentro do qual um 
conjunto de atividades deve ser executado.
Essas tarefas são, então, movidas das pendências do produto para as pendências do incremento. 
Durante um incremento, são conduzidas curtas reuniões diárias chamadas de Scrum diário (daily scrum), 
que ajudam a equipe a manter‑se no rumo.
Scrum e planejamento estratégico
Desde a quinta Edição do Guia PMBOK, as metodologias ágil e adaptativa têm sido mais adotadas 
no gerenciamento de projetos. A sexta edição incluiu uma subseção chamada “Considerações para 
Ambientes Adaptativos”, no início das seções 4 a 13. Algumas ferramentas e técnicas específicas da 
Metodologia Ágil foram introduzidas no Guia PMBOK, como sprint e planejamento de iteração.
200
Unidade III
8.2.1 O que é a Metodologia Scrum
É um método para intensificar o trabalho da equipe de projetos e controlar a evolução do produto 
de forma eficaz, mantendo a visão na qualidade e nos prazos. Ela é composta por ciclos de atividades 
programadas – os sprints –, com planejamento de tarefas e datas de início e fim determinados.
Scrum é, portanto, uma alternativa para otimizar e organizar a equipe de desenvolvimento. Com 
a estruturação das demandas e etapas do projeto, pode‑se melhorar o rendimento e entregar mais 
resultados, sempre de forma rápida, escalável e organizada.
 Observação
A palavra scrum não tem tradução para o português. Esta palavra é uma 
referência a um tipo de jogada do rugby, em que todo o time se reúne em 
uma única jogada com um único objetivo.
8.2.2 Visão geral da Metodologia Ágil Scrum
O Scrum não é um processo padronizado no qual o indivíduo segue uma série de etapas sequenciais 
e que vão garantir a produção no prazo e no orçamento, um produto de alta qualidade e que encanta 
os seus clientes. Ao contrário, o Scrum é um framework (estrutura) para organizar e gerenciar trabalhos 
complexos, tal como projetos de desenvolvimento de software.
No cenário atual, as organizações buscam soluções de software para aperfeiçoar seus processos e, 
principalmente, reduzir seus custos de produção. Para adaptar‑se a essa necessidade, as software house, 
responsáveis por projetar, desenvolver, fazer manutenção e, ainda, comercializar softwares que atendam 
às necessidades dos clientes, estão buscando diversas soluções para entregar seus produtos em menor 
tempo e com mais qualidade.
No caso de aplicações a projetos, existe um grande debate sobre o que é o Scrum. Alguns dizem que 
é uma metodologia; outros, que é um modelo, porém a Scrum Alliance, organização sem fins lucrativos 
que regulamenta o Scrum e suas certificações, o classifica como um framework que baseou‑se no 
Manifesto Ágil, sendo o Scrum um conjunto de valores, princípios e práticas leves, mas incrivelmente 
poderosos, que trabalha dividindo grandes produtos e serviços em pequenas partes que podem ser 
concluídas (e liberadas) por uma equipe multifuncional em um curto espaço de tempo, promovendo 
mais produtividade e flexibilidade na entrega do produto.
 Observação
A Agile Alliance Brazil, ou AAB, é uma associação sem fins lucrativos 
criada com o objetivo de desenvolver a comunidade através da disseminação 
da cultura ágil.
201
ELABORAÇÃO E ANÁLISE DE PROJETOS
Ainda que o Scrum seja muito utilizado no setor de tecnologia da informação, devido a sua 
flexibilidade, ele pode ser aplicado em diversos segmentos como marketing, logística, negócios etc., 
porque funciona de forma frequente e incremental com o objetivo de entregar um produto funcional 
ao final de cada fase. Devido a essa flexibilidade e produtividade, o Scrum vem sendo a ferramenta ideal 
para organizações que têm como seus principais funcionários a geração Y.
 Observação
A geração Y é aquela de nascidos entre o início de 1980 até o final 
dos anos 1990, superexposta ao novo nível de informação, afastada dos 
trabalhos braçais e sobrecarregada de prêmios e facilidades materiais em 
troca de pouco ou nenhum esforço físico.
Conforme Pinheiro (2012), a seguir serão vistos quais são os papéis desempenhados por cada 
componente da equipe:
– Product owner é o responsável pelo ROI (return on investment), por 
traduzir as necessidades do cliente para o time de desenvolvimento, 
priorizando e definindo o productbacklog, sempre de olho na visão 
 da empresa.
– Time é a equipe multidisciplinar que vai atuar efetivamente no 
projeto.
Ela é composta por 5 até 9 participantes.
– Scrum master é responsável por garantir a perfeita utilização do 
Scrum pelos participantes do projeto, removendo as possíveis 
objeções.
De acordo com Pinheiro (2012), vejamos outros significados do Scrum:
– Visão (View) é aonde queremos chegar com esse produto, por que 
precisamos dele, qual o nosso objetivo, qual nosso real propósito? 
Depois da visão definida, passamos para a definição do nosso 
product backlog.
– Product backlog é uma lista de tarefas e suas prioridades, 
como também de resultados esperados para o projeto e suas 
características.
– Sprint backlog é o conjunto de tarefas retiradas a partir do product 
backlog que a equipe se compromete a completar em um sprint.
202
Unidade III
– Burndown é um gráfico para que todos os envolvidos (stakeholders) 
no projeto possam acompanhar o andamento das atividades. 
Algumas empresas utilizam dois gráficos, um para o sprint atual e 
outro para o projeto total.
Restante Estimado
180
160
140
120
100
80
60
40
20
0
1 2 3 4 5 6 7 8 9 10
Figura 42 – Exemplo de gráfico burndown
– O gráfico de burnup oferece informações do progresso do projeto 
como um todo, e não apenas de um sprint, como no caso do gráfico 
de burndown. Ele mostra claramente em que ponto a equipe está 
(Entregas) e onde ela deve chegar.
Sobre a fase de planejamento, temos a seguinte posição, segundo Pinheiro (2012):
– Sprint planning: reunião de planejamento do sprint em que a 
equipe se reúne com o product owner para escolher um conjunto 
de tarefas para entregar no próximo sprint, definindo assim 
o sprint backlog.
– Daily scrum: reunião que a equipe faz diariamente para compartilhar 
suas dificuldades e sucessos. As dificuldades apresentadas devem 
ser resolvidas pela própria equipe ou com a ajuda do scrum 
master. Essas reuniões devem ser objetivas e não ter duração 
maior que 15 minutos.
– Sprint review: a equipe deverá demonstrar ao product owner o que 
foi concluído durante o sprint.
203
ELABORAÇÃO E ANÁLISE DE PROJETOS
– Retrospective: reunião de retrospectiva em que a equipe procura 
formas de melhorar o produto e o processo.
Você deve estar pensando: “Se o Scrum é tão bom, vamos utilizá‑lo em tudo”. Na prática, podemos, 
sim, utilizá‑lo em quase todos os projetos, mas se você tiver uma equipe que não é dinâmica, nem 
participativa, talvez o Scrum seja uma ferramenta inadequada. A despeito de todos os recursos que 
o Scrum oferece para você administrar seus projetos, cada projeto deve ser tratado como um projeto 
único, e as ferramentas empregadas devem retratar a sua conveniência.
8.2.3 Scrum e planejamento estratégico
Em diversas organizações com consultorias, o planejamento estratégico é elaborado com um 
enorme uso de horas nobres, com o envolvimento de diretores e alta gerência, até que uma lista de 
ações estratégicas são publicadas tendo como essência a transformação da empresa para seus novos 
objetivos estratégicos ou recuperação do foco para realizar os seus objetivos reais. Encontramos aí 
a aplicação de duas ferramentas para a gestão de projetos: o Excel e o correio eletrônico.
Após a reunião do planejamento, o Excel vira anexo obrigatório, e membros da alta, média e baixa 
gerência são convidados a tomar parte das ações necessárias à efetivação do planejamento estratégico. 
Em muitos casos, profissionais recebem apenas um resumo das ações e não têm a noção do vínculo de 
suas atividades com outras que serão necessárias para o atingimento das metas.
Seguramente, há boas opções no mercado de softwares que podem contribuir para o detalhamento 
e acompanhamento de um planejamento estratégico, e um deles é o Project Builder.
No entanto, o que precisamos entender é que independentemente da ferramenta (Excel, e‑mail, 
Project Builder etc.), poderemos nos encontrar em uma próxima reunião com a alta diretoria para 
descobrir que a grande parte das ações estratégicas não aconteceram em função de urgências, rotinas 
de trabalho, reuniões, compromissos com fornecedores ou cliente etc.
Em uma abordagem tradicional para o planejamento estratégico, os envolvidos realizarão um 
detalhamento das atividades através da ferramenta 5W2H, em que são descritos o que será feito (what), 
quando será feito (when), como será feito (how), por quanto financeiramente será feito (how much), por 
que será feito (why), onde será feito (where) e por quem será feito (who).
A listagem de o quê/quando será feito/e por quem será feito dará origem a um cronograma em 
que cada item tem uma data final, não necessariamente coordenada em entregas específicas para a 
empresa, definindo o prazo final.
Em uma abordagem com princípios ágeis e que no Scrum vamos chamar de sprints, nós temos a criação 
de time box (literalmente caixa de tempo) ou períodos pré‑definidos de tempo em que os participantes 
terão objetivos claros para um conjunto de entregas. Em outras palavras, a partir de prazos pré‑estipulados 
(datas de entregas de pacotes), os participantes definirão o trabalho que será encaixado.
204
Unidade III
No Scrum, os projetos são divididos em ciclos chamados de sprints, que correspondem a cada uma das 
fases de um projeto. O sprint representa um time box dentro do qual um conjunto de atividades deve 
ser executado, sendo o conceito principal do método Scrum. Nele, os projetos são divididos em ciclos, 
normalmente mensais, chamados de sprints. Metodologias ágeis de desenvolvimento de software são 
iterativas, ou seja, o trabalho é dividido em iterações, que são chamadas de sprints.
Definição do backlog 
da sprint e delegação 
das atividades ao time 
de desenvolvimento
Equipe realiza 
reunião do sprint
Fim
Início
Equipe define os 
papéis scrum
Equipe finaliza 
o sprint
Scrum master, 
product owner 
e time de 
desenvolvimento
Time box
PO define o 
backlog do produto
Equipe realiza 
1a reunião do sprint
Equipe apresenta 
o sistema resultante 
do sprint ao PO
Equipe finaliza 
o sprint
Produto 
finalizado
Figura 43 – Time box e passos a serem seguidos
Conforme o site Desenvolvimento Ágil (SCRUM, [s.d.], p. 2):
As funcionalidades a serem implementadas em um projeto são mantidas em 
uma lista que é conhecida como product backlog. No início de cada sprint, 
faz‑se um sprint planning meeting, ou seja, uma reunião de planejamento 
na qual o product owner prioriza os itens do product backlog e a equipe 
seleciona as atividades que ela será capaz de implementar durante o sprint 
que se inicia. As tarefas alocadas em um sprint são transferidas do product 
backlog para o sprint backlog.
A cada dia de uma sprint, a equipe faz uma breve reunião (normalmente 
de manhã), chamada daily scrum. O objetivo é disseminar conhecimento 
sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o 
trabalho do dia que se inicia. Ao final de um sprint, a equipe apresenta as 
funcionalidades implementadas em uma sprint review meeting. Finalmente, 
faz‑se uma sprint retrospective, e a equipe parte para o planejamento do 
próximo sprint. Assim reinicia‑se o ciclo.
205
ELABORAÇÃO E ANÁLISE DE PROJETOS
Quem já fez gerenciamento de projetos sabe que há desafios a serem vencidos todos os dias, pois são 
muitos os elementos envolvidos para conseguir produzir um item de qualidade que atenda aos requisitos, 
prazos e custos definidos inicialmente. Para melhorar esse processo, foram criadas metodologias, 
conjuntos de melhores práticas para otimizá‑lo e manter a empresa competitiva no mercado. Uma delas 
é a metodologia Scrum, muito usada por desenvolvedores de software.
Ela tem ganhado espaço e se mostrado capaz para a entrega de projetos com qualidade e altos níveis 
de satisfação. A implantação dessa metodologia ágil está diretamente relacionada à necessidade de 
oferecer respostas rápidas eentregas que liberem produtos funcionando, com mais agilidade e índices 
de qualidade excelentes.
Em um planejamento estratégico, a definição dos princípios é extremamente importante, pois 
estabelece os pilares do caráter da empresa. Os princípios jamais serão feridos, independentemente da 
razão que possa tentar a empresa a comprometê‑los. Tipicamente, são definidos por palavras simples, mas 
fortes, carregadas de sentido: liberdade, inovação, cooperação, democracia. Se necessário, no exercício 
do planejamento estratégico, tais palavras podem ser definidas e interpretadas de comum acordo com 
todos os participantes. Os princípios da empresa devem ser também parte integral dos princípios de cada 
indivíduo que dela participa. Mas como o Scrum pode nos ajudar a definir estes princípios? Pela função 
do scrum master, que deve ser a de remover obstáculos. Aqueles que tiveram a curiosidade, e que já 
tiveram alguma experiência com planejamento estratégico, captaram o ponto em que queremos chegar. 
Devemos ter um formato de reunião que se dá em três dias:
• um dia para o planejamento;
• um dia para a execução do que foi planejado;
• um último dia para a entrega do produto.
No planejamento, cria‑se um product backlog que terá cada uma de suas tarefas definida, iniciada, 
concluída e verificada (o que pode ser feito com o acompanhamento de um sprint backlog simplificado). 
Vamos usar esta sequência para dar início ao nosso próprio planejamento.
No primeiro dia, faremos uma reunião de nivelamento, conduzida por alguém que terá a função de 
scrum master. Nesta reunião, serão apresentados todos os aspectos necessários ao nosso planejamento 
estratégico e será passada à equipe presente uma lista de tarefas a ser concluída até a próxima reunião, 
assim como as ferramentas necessárias para o acompanhamento da lista de tarefas, para as quais será 
negociado o prazo devido e com o qual todos se comprometerão.
A primeira tarefa será a definição dos princípios da empresa. O scrum master deverá ser duro 
no questionamento destes, e qualquer princípio que corra o risco de não ser seguido será, grosso 
modo, eliminado!
206
Unidade III
Os valores de uma empresa são o seu alicerce, e em cima deles é que tudo é construído. Uma 
empresa deve ter seus princípios bem definidos e jamais deve abrir mão deles. Em sua primeira reunião 
de planejamento estratégico com o auxílio do Scrum, caberá ao scrum master apresentar a metodologia 
e as ferramentas que serão utilizadas. Os que leram sobre Scrum notarão que as ferramentas que 
utilizaremos serão apenas versões do product backlog e sprint backlog.
Você notará que uma planilha é composta de uma folha para o product backlog, uma ou mais para os 
sprint backlogs e uma para o material de leitura que será entregue à equipe de planejamento. O product 
backlog acompanha as três fases e as três principais reuniões que comporão o método do planejamento 
estratégico. Aqui é importante destacar que o produto de um planejamento estratégico não é um 
plano estático a ser impresso. O produto deste planejamento é um conjunto de processos dinâmicos 
e contínuos que preparam a organização para atingir seus objetivos e para melhor reagir a mudanças 
em seu ambiente. Dessa forma, a ideia é que, ao final deste processo, o Scrum esteja efetivado, com a 
metodologia para o acompanhamento dos planos de ação definidos pela empresa, servindo como seu 
instrumento de melhoria contínua. Todos os funcionários terão direito de edição desta planilha para que 
possam contribuir com suas ideias na medida em que elas também surgirem e terão a oportunidade de 
defendê‑las presencialmente nas reuniões.
Feita a apresentação da metodologia, que pode incluir um resumo dos planejamentos anteriores, 
faz‑se uma rápida apresentação da equipe e tudo o mais que se julgar necessário para que todas as 
pessoas tenham a informação devidamente nivelada, e, assim, passa‑se para a primeira atividade 
do planejamento.
O scrum master deverá motivar as pessoas para que definam seus princípios pessoais e que 
preparem‑se para defendê‑los se interrogadas. Cada pessoa deve definir entre três e cinco princípios, 
e, se quiser, deixar preparada uma explicação para cada um deles. Todos os colaboradores terão 
15 minutos para pensar e escrever e, no máximo, cinco minutos para apresentá‑los. Para cada 
princípio que for questionado por outros colaboradores (inclusive pelo scrum master), o autor 
terá direito a uma argumentação de, no máximo, um minuto e meio, e, ao final, haverá uma 
votação aceitando a defesa ou não. Em caso de a defesa não ser aceita, o princípio será descartado. 
Princípios devem ser fortes o suficiente, pois devem ser indiscutíveis para todos os colaboradores 
que fazem parte da empresa.
Esse rápido exercício servirá de base para o próximo, que segue a mesma metodologia, mas que 
agora definirá os princípios da empresa, os quais serão escritos por todos em uma folha à parte, na 
mesma planilha que já estamos utilizando. O scrum master ainda motivará a equipe a elaborar a missão 
e a visão da empresa e a pensar também em quais objetivos ela deverá atingir no curto, médio e longo 
prazo. Evidentemente, isso será colocado na próxima reunião, sob os princípios da empresa, garantindo 
que tudo o que for feito não prejudicará nenhum deles.
Em vez de definir o que é a missão e a visão de uma empresa, o scrum master passará mais 
uma tarefa à equipe: coletar e transcrever para o documento coletivo a missão e a visão de outras 
empresas que estejam ou não no mesmo mercado da organização, o que é um bom exercício para 
os colaboradores. Para a próxima reunião, antes de definir o que cada um quer como objetivo da 
207
ELABORAÇÃO E ANÁLISE DE PROJETOS
empresa, todos devem trazer uma lista de coisas que esperam que a empresa possa lhes assegurar, 
junto com ideias sobre o meio pelo qual isso possa acontecer no curto, médio e longo prazo.
Algo que se recomenda em exercícios de planejamento estratégico é que, na pesquisa de missão, 
visão e princípios de outras empresas, busquem‑se organizações do mesmo ramo de negócios, empresas 
concorrentes e aquelas que não tenham nada a ver com o que a organização faz. Pede‑se que os envolvidos 
no planejamento se imaginem trabalhando em uma área diferente de onde estão e em uma empresa 
que não tem nada a ver com a sua, buscando descobrir os valores dessas empresas. Esse é um exercício 
bem eficaz e estimulante. Somente depois dele, e com base nos exemplos, a equipe de planejamento 
busca explicar, com suas próprias palavras, o que é missão e visão.
Em resumo, define‑se a visão como a resposta para a pergunta “O que a empresa quer se tornar?”, 
ou “Onde queremos chegar?”. Para trazer inspiração na definição da visão, devemos imaginar a empresa 
dos sonhos e como ela deverá ser. As perguntas a seguir nos ajudam nesta reflexão:
• Por que vim trabalhar nesta empresa?
• Se ou quando eu sair daqui, o que vou deixar como a minha marca?
• O que eu estou fornecendo para os meus clientes além de produtos e serviços?
• Se esta empresa pudesse ser tudo o que eu sonhei, como ela seria?
A missão descreve o que a empresa faz e propõe mais algumas questões que auxiliam na criação da 
declaração de missão da empresa:
• Qual o propósito de sua empresa?
• Por que ela está no mercado?
• O que faz a empresa?
• Quais os seus produtos e serviços?
• O que é importante para o seu negócio?
• Quais são os princípios que regem o seu negócio?
Mas o que o Scrum tem a ver com isso? Até agora usamos conceitos do Scrum para a divisão dos 
trabalhos do planejamento estratégico em fases de planejamento, execução e entrega. Colocamos 
essas fases em um product backlog. Após a primeira reunião, montamos um primeiro sprint backlog 
com a equipe, em que foram definidas as tarefas de preparação para uma segunda reunião na qual 
os conceitos serão revistos e os princípios, missão e visão serão escritos. Nesse tempo, em que 
nosso sprint tem três dias úteis, o scrum master buscou, nas reuniõesdiárias de 15 a 20 minutos, 
208
Unidade III
saber o que cada pessoa fez no dia anterior, suas tarefas para o dia atual e quais as dificuldades a 
serem eliminadas, principalmente sobre os conceitos de planejamento estratégico.
Nessa segunda reunião, o scrum master buscará saber também como as pessoas transformariam a 
organização na empresa dos sonhos, com a base sólida dos princípios definidos e cumprindo sua missão 
através da definição de objetivos estratégicos.
Lembra‑se do Manifesto Ágil e seus princípios? O Scrum também os segue. Além disso, ele possui 
cinco valores que dão personalidade aos papéis (scrum master, product ower e developer team). 
Os valores são crenças e atitudes que se esperam do time Scrum, a fim de que sejam obtidos resultados 
saudáveis e de sucesso para a adoção. São eles:
• Foco: você já esteve em um projeto em que você ou seu grupo de trabalho retalha um produto 
para cada um fazer uma parte, e, no final, não resulta em nada? Ser multitarefa é desperdício de 
energia, já que na era da multitarefa produz mais quem faz uma coisa de cada vez. Para ampliar 
a importância das atividades, o time deve manter o foco em pequenas partes por vez, o que 
aumenta a produtividade e a autoestima do time, possibilitando entregas de valores mais rápidos. 
Essas pequenas partes devem estar alinhadas com o negócio. O PO deve manter o foco nas 
necessidades mais urgentes do negócio. Para manter o foco, o scrum master auxilia na remoção 
de impedimentos.
• Coragem: você já trabalhou em projeto de propósito fechado, e no meio do projeto foram 
necessárias diversas mudanças, gerando muito conflito entre as partes envolvidas? A coragem 
envolve aceitar mudanças como parte do processo de desenvolvimento do produto, confiar 
no time para que ele trabalhe o necessário para atingir metas acordadas. Coragem em errar, 
falhar, expor as falhas e aprender com elas o quanto antes. Ter coragem de entregar as partes do 
produto dentro do tempo acordado. Ter atitude em executar as ações necessárias para remover 
impedimentos com o objetivo de melhorar a produtividade da equipe.
• Franqueza: você já teve dificuldade de expressar sua opinião para o grupo? A franqueza 
envolve oferecer e receber feedback dentro do time, do time para o PO ou cliente, assim como 
scrum master, o que cria visibilidade sobre os problemas e estimula a busca por soluções.
• Comprometimento: quantas vezes você disse que ia começar a parar de fumar depois do 
último cigarro? Quando a equipe se compromete a realizar algo, deve fazer sua parte para 
garantir que isso ocorra, ou seja, planejar, monitorar, executar, controlar e encerrar suas 
atividades, sendo responsável pelos seus resultados. Como também o PO, que se compromete 
a priorizar as necessidades do negócio, bem como a fazer com que o Scrum ocorra conforme 
recomenda o framework.
• Respeito: você já se sentiu constrangido em uma equipe, na qual qualquer crítica construtiva 
é vista como destrutiva? O valor do respeito engloba as ações e permitir realizá‑las por meio 
de diálogo, consentindo com a criação de possibilidades. O respeito se trata de reconhecer as 
diferenças entre as pessoas da equipe, preservando o diálogo, sabendo ouvir e respeitar as opiniões 
209
ELABORAÇÃO E ANÁLISE DE PROJETOS
dos demais. A equipe também respeita as decisões do PO, e este, por sua vez, deve respeitar 
os julgamentos técnicos da equipe. E, finalmente, são considerados o bem‑estar e o direito das 
pessoas que trabalham no projeto a uma vida privada.
Percebam que os valores são voltados à parte humana da gestão de projeto. Quanto mais você 
entender e praticar esses valores como time, mais auxiliará na adoção do Scrum. Lembre‑se de que a 
aprendizagem sobre os valores pode ser lenta ou rápida para algumas equipes, dependendo das pessoas, 
da cultura organizacional da empresa e do quão elas estão preparadas para as mudanças.
 Saiba mais
Para conhecer mais sobre o Scrum, inclusive sobre as certificações 
profissionais, acesse o link a seguir:
Scrum Alliance. Disponível em: https://www.scrumalliance.org. Acesso 
em: 12 jan. 2023.
A recomendação é começar o Scrum com passos pequenos, pois ele sempre estará em uma contínua 
mutação, devendo ser usado para ajudar a organização a chegar a uma forma melhor no que tange à 
configuração da mente e aos processos de gestão de projetos e de produtos.
8.2.4 Quando usar Scrum
A metodologia Scrum é bastante flexível e pode ser adaptada a vários tipos de negócios ou 
projetos. É fundamental ter um bom profissional da área para determinar como implantar a estratégia 
de negócio com o auxílio do método, sendo esse um dos fatores que determinam o sucesso ou o 
fracasso da iniciativa.
Para quem está inseguro quanto à adoção dessa metodologia ágil, vale implantá‑la inicialmente 
em um único projeto, talvez de baixo risco, para comparar seu desempenho com o método tradicional. 
É essencial que seja demonstrada a agilidade das entregas e o foco em qualidade.
Os integrantes da equipe devem ter 100% das habilidades necessárias para que possam alcançar 
os objetivos. É preciso que sejam capazes de entregar os resultados no prazo estipulado, sem atrasos. 
As diversas partes do projeto devem ser cumpridas por eles de forma satisfatória para que a visão do 
PO se torne possível.
A motivação desses profissionais deve ser constante, para garantir o nível de entrega e compromisso 
necessários. Afinal, eles são os responsáveis por construir o produto.
210
Unidade III
8.2.5 Como funcionam os sprints
Quando se usa Scrum, todas as atividades são feitas dentro de sprints, que são os ciclos de 
desenvolvimento. A duração de cada sprint depende do projeto, mas sua principal característica é a 
curta duração. O resultado deve ser a entrega de algo tangível para o cliente.
Outro ponto fundamental é a definição das datas de início e fim de cada sprint. Durante o sprint, 
todos os dias, deve haver uma reunião pela manhã – chamada de daily scrum –, para garantir que todos 
os envolvidos no projeto tenham conhecimento das atividades do dia anterior. Isso ajuda a identificar 
impeditivos e problemas.
Já a sprint review meeting é o momento em que os integrantes da equipe apresentam as 
funcionalidades implementadas. Ao final de cada ciclo, é feita uma sprint retrospective para que a equipe, 
com base nos aprendizados e no que foi feito anteriormente, faça o planejamento do próximo sprint.
Os participantes da equipe devem estar bem integrados em relação aos objetivos do projeto e da 
organização, com a ideia de manter o foco na solução ideal para as necessidades levantadas no escopo. 
Se não houver essa integração, o andamento e o resultado podem ser prejudicados.
8.2.6 Etapas
A implementação do Scrum não ocorre de um dia para o outro, pois uma mudança cultural radical 
é incômoda. Uma boa forma de mitigar riscos é começando com um projeto em determinado setor, 
aprender com os erros e somente depois expandir a metodologia para outras equipes.
Conforme Duarte (2015, p. 1), diversos são os benefícios em se utilizar o Scrum, entre eles,
– entregas frequentes de retorno ao investimento dos clientes;
– redução dos riscos do projeto;
– maior qualidade no produto gerado;
– mudanças utilizadas como vantagem competitiva;
– visibilidade do progresso do projeto;
– aumento de produtividade.
O maior benefício que pode ser evidenciado é a redução do desperdício.
Dentro do framework Scrum, o product owner é o responsável pela manutenção do produto através 
do product backlog ou backlog de histórias.
211
ELABORAÇÃO E ANÁLISE DE PROJETOS
Esse backlog é uma lista de requisitos (conhecidos no mundo ágil como histórias, as quais descrevem 
uma necessidade ou situação futura) funcionais e não funcionais escritos com uma ou duas frases que 
retratam as funções a serem desenvolvidas. Lembre‑se que o backlog nunca estará completo, ou seja, 
histórias podem ser adicionadas ou removidas conforme necessário.
O product owner, dentro do framework Scrum, é o facilitadore único para um time de Scrum, pois 
é importante haver apenas um foco de decisões sobre o produto para o time de desenvolvimento; deve 
ficar disponível para esclarecer itens do product backlog para o time de desenvolvimento, estar 
presente nas reuniões de sprint planning, sprint review e sprint retrospective, para interagir com os 
clientes e demais partes interessadas e para manter e priorizar o product backlog.
8.2.7 Kanban
Kanban é um termo de origem japonesa e significa literalmente “cartão” ou “sinalização” para indicar 
o andamento dos fluxos de produção em empresas de fabricação em série.
O Kanban não é parte do framework Scrum, mas é uma excelente ferramenta de planejamento e 
funciona em conjunto com o framework, dependendo das circunstâncias e do contexto.
Basicamente, é um quadro com quatro lista de tarefas: “para executar ou fazer”, “em andamento 
ou em progresso”, “esperando verificação” e “finalizado ou feito”. Essa é uma ótima maneira de 
visualizar rapidamente o status de um projeto, independentemente do uso do Scrum. A empresa 
japonesa de automóveis Toyota foi a responsável pela introdução desse método devido à necessidade 
de manter um eficaz funcionamento do sistema de produção em série. Atualmente, o Kanban é 
muitas vezes usado em conjunto com o Scrum, pois são duas metodologias do desenvolvimento 
ágil de software.
 Lembrete
Kanban é um conceito relacionado com a utilização de cartões (post‑it 
e outros) para indicar o andamento dos fluxos de produção em empresas 
de fabricação em série.
O Sistema Toyota de Produção (em inglês Toyota Production System – TPS) foi desenvolvido pela 
Toyota Motor Corporation para fornecer a melhor qualidade, o menor custo e o lead time mais curto 
por meio da eliminação do desperdício. O TPS é formado sobre dois pilares, just‑in‑time e jidoka. O TPS é 
mantido por interações entre o trabalho padronizado e o kaizen (melhorias do tipo uma etapa por vez), 
e visam ao aperfeiçoamento das pessoas e dos processos dentro da organização, seguidos de PDCA (do 
inglês: plan ou “planejar”; do ou “fazer”; check ou “checar”; act ou “agir”), também chamado de ciclo de 
Deming ou ciclo de Shewhart.
212
Unidade III
O desenvolvimento do TPS é creditado a Taiichi Ohno, chefe de produção da Toyota no 
período após a Segunda Guerra Mundial. Começando nas operações de usinagem, Ohno liderou 
o desenvolvimento do TPS ao longo das décadas de 1950 e 1960, e sua divulgação à cadeia de 
fornecedores nas décadas de 1960 e 1970.
Esse trabalho foi trazido para o ocidente por James Womack e Daniel Jones no livro Mentalidade 
enxuta, em 1996, criando a cultura lean nos anos 2000 (lean development, lean enterprise etc.), outra 
tendência muito forte que influenciou e foi influenciada pela cultura ágil, sendo focada na eliminação 
dos sete desperdícios da cadeia produtiva:
• defeitos;
• superprodução;
• espera;
• transporte;
• movimentação;
• processamento errado;
• estoque.
Quanto mais se trabalha na eliminação de desperdícios, mais próximos estaremos de produtos lean 
(enxutos), com baixo custo, mais qualidade e tempo de entrega bem menor.
O conceito de Kaizen garante a melhoria contínua dos processos em uma busca pela perfeição, 
algo mais tarde levado pelos “agilistas” através de cerimônias como as retrospectivas. E, finalmente, as 
ferramentas de gestão do chão de fábrica japonês, como o Kanban, foram adaptadas para o mundo dos 
projetos pelo americano David Anderson.
Lembre‑se de que os princípios da agilidade são universais e aplicáveis a qualquer grupo de pessoas 
que tenham de empreender em projetos complexos e adaptativos. E se você leu o que foi escrito 
anteriormente sobre a origem da agilidade, deve ter entendido que uma equipe ágil:
• Trabalha como uma verdadeira equipe, que além de ser pequena (tem de seis a dez pessoas) é 
auto‑organizada, compartilhando suas responsabilidades.
• Colabora e comunica‑se constantemente entre si, com clientes e stakeholders, através de comunicação 
direta.
• Foca na entrega de valor contínua e incremental, aprendendo a cada entrega.
213
ELABORAÇÃO E ANÁLISE DE PROJETOS
• Elimina desperdícios e ganha mais agilidade através de melhoria contínua.
• Divide os seus aprendizados, tanto interna como externamente à equipe.
Note que não estamos depreciando os frameworks populares, já que possuir todas essas características 
em um time não é uma tarefa fácil, exige pessoas maduras, organizadas, com desenvolvimento orientado a 
valor e foco no cliente, e que, muito provavelmente, usar um método vai lhe ajudar a criar determinação 
para se chegar a um time ágil.
Então, sim, usar o Scrum e outros métodos pode ser um caminho para chegar a times ágeis e de 
alto desempenho, mas eles são um meio, e não o fim. Ser ágil não é executar uma receita, mas reagir 
às mudanças entregando valor de maneira contínua e progressiva, em um ciclo de melhoria contínua. 
Ninguém disse que seria fácil, certo?
8.2.8 Os três pilares da metodologia Scrum
O Scrum é sustentado por três pilares:
• Transparência: absolutamente todos os documentos e dados importantes para o sucesso do 
projeto devem estar visíveis para todos aqueles que fazem parte do projeto.
• Inspeção: periodicamente, é necessário fazer uma inspeção para verificar se o processo está 
andando conforme as regras, atendendo aos padrões de qualidade. No Scrum, a inspeção acontece 
em uma reunião diária (daily scrum). Nas reuniões, as pessoas envolvidas no projeto compartilham 
informações e discutem assuntos como:
— o que está sendo feito;
— o que se pretende fazer;
— identificam impedimentos;
— definem prioridades conforme o que foi discutido e acordado em equipe.
• Adaptação: ocorre após o momento em que a inspeção é feita, em que as ações são criadas e 
estabelecidas no processo para melhorá‑lo. Qualquer adversidade deve ser ajustada o mais rápido 
possível para que não haja falhas e sejam atendidas as necessidades do cliente final.
8.2.9 Ferramentas para o Scrum
Ficar pendurando post‑its em um mural não está com nada, não é mesmo? Inicialmente, era assim 
que se gerenciavam projetos Scrum, e, em alguns lugares, muitas pessoas gostam disso. Porém, se bater 
um vento, se alguém simplesmente esbarrar nos post‑its, ninguém saberá mais o que estava sendo feito, 
por fazer etc. Assim, informações importantes podem ser perdidas por estarem explanadas dessa maneira.
214
Unidade III
E já que estamos vivendo a transformação digital, com a versão virtual da metodologia Scrum fica 
muito mais fácil e prática de organizar tarefas e trabalhar em equipe com mais eficiência. Para ajudar os 
profissionais, muitas ferramentas para Scrum, gratuitas ou pagas, estão disponíveis no mercado. Vejamos 
algumas listadas por Vieira (2014):
Ferramentas gratuitas:
– O Scrum Half é uma ferramenta brasileira que facilita muito o 
uso do Scrum. Foi pensada por um pessoal que conhece muito 
bem o framework, o que faz toda a diferença. O seu quadro de 
Kanban virtual facilita muito a colaboração e o acompanhamento 
do trabalho da equipe. Permite também que a equipe trabalhe 
distribuída de forma simples. Outro ponto forte nesta ferramenta 
é a facilidade de manutenção e priorização do product backlog. 
Além disso, ela também gera automaticamente o burndown chart e 
vários outros gráficos de controle. Possui uma versão gratuita para 
uso em um único projeto.
– O Pango Scrum é mais uma ferramenta brasileira que cumpre 
muito bem o seu papel. Nela, é possível fazer todo o gerenciamento 
do product backlog, planejamento de sprints e monitoramento 
de progresso. [...] Um ponto interessante desta ferramenta é o 
calendário de eventos do projeto. Facilita bastante a visualização 
das datas das reuniões de planejamento de sprint, retrospectivas 
etc. Um ponto interessante desta ferramenta é o calendário de 
eventos do projeto. Facilita bastante a visualização das datas das 
reuniões de planejamento de sprint, retrospectivas etc.
– O Trello não é uma ferramenta propriamente de Scrum,ela somente 
automatiza o quadro de Kanban. Mas sua usabilidade é tão boa 
(inclusive você consegue sincronizar seus quadros com o iPhone e 
iPad), que faz dela uma das referências no mercado. É muito simples 
de usar, de criar quadros e compartilhar.
Ferramentas pagas:
– O SrumWize é talvez a melhor e mais completa ferramenta Scrum 
do mercado. Infelizmente, ela é toda em inglês, mas como os termos 
principais do Scrum não são normalmente traduzidos, mesmo que 
você não domine o inglês vai conseguir se achar na ferramenta 
desde que conheça o básico do Scrum. Nesta ferramenta você 
consegue fazer toda a gestão do time scrum, products backlogs 
(com priorização drag‑and‑drop), release e sprint planning, kanban, 
215
ELABORAÇÃO E ANÁLISE DE PROJETOS
burndown chart, time tracking etc. E tudo isso com um visual muito 
bonito e intuitivo.
– O Jira Agile (antigo Greehopper) é outra ferramenta que podemos 
chamar de completa. É também uma das referências do mercado 
e traz consigo toda a segurança, robustez e flexibilidade do Jira e 
todas as demais ferramentas da Atlassian junto dela. Para equipes 
pequenas, ela fica um pouco mais barata que o Scrum Wize e 
pode‑se dizer que é tão boa quanto no que tange ao Scrum. Mas 
se for considerar todo o arcabouço de ferramentas e plugins da 
Atlassian que você leva junto, a ferramenta vale muito a pena.
Agora se você quer uma ferramenta completa de Scrum, não pode 
deixar de conferir a AxoSoft. Ela foi criada pelo Hamid Shojaee, 
criador do mais famoso vídeo de Scrum do mundo, o Scrum em 
Menos de 10 Minutos (versão em português aqui). Nela, você 
encontra as seguintes funcionalidades: Bug tracking, Gerenciamento 
de Requisitos, Quadro Scrum, Burndown Charts, Team wiki, Help 
desk/incident tracking, Automação de Workflow e muito mais.
8.3 Outras ferramentas agéis
8.3.1 XP Extreme Programming
Segundo Tebet (2021), na busca pela eficácia nos projetos e pela eficiência dentro das equipes, foi 
idealizado na década de 1990 um método de desenvolver software, o Extreme Programming, mais 
conhecido como XP (em português, programação extrema).
Vamos lá: o que é o XP? Conforme Tebet (2021), entre diversas metodologias ágeis, o XP foi uma das 
primeiras e ainda hoje é popular, junto com Kanban e Scrum. Isso ocorreu porque o foco dessa metodologia 
é desenvolver menos esses aspectos e focar mais em boas práticas de engenharia de software.
O XP foi criado na década de 1990 por Kent Beck, Ward Cunningham e Ron Jeffries, e ainda é um 
método bastante utilizado. Ele é um dos que focam na satisfação do cliente e na entrega incremental. 
Seu objetivo é desenvolver sistemas rápidos e corretos, priorizando principalmente o desenvolvimento 
do software sobre a análise e o projeto do sistema.
Ainda de acordo com Tebet (2021), pode‑se dizer que o XP é uma metodologia ágil para equipes 
que desenvolvem software baseado em requisitos vagos e que se modificam rapidamente, conforme 
acontece nos dias de hoje. A ideia é que, em vez de entregar tudo o que o cliente possa querer em alguma 
data no futuro, esse método possibilita a entrega do projeto – no caso, o software – no momento em 
que o cliente precisa, com sistemas de melhor qualidade para determinado período de tempo, além da 
redução de custos e transtornos causados às pessoas envolvidas no projeto.
216
Unidade III
Aqui, separamos os cinco valores que são a base do XP, de acordo com o site oficial da metodologia 
(EXTREME PROGRAMMING, 2009):
• Simplicidade: faremos o que for necessário e solicitado, mas nada mais. Isso maximizará o valor 
criado para o investimento feito até o momento. Daremos pequenos passos simples para alcançar 
nosso objetivo e mitigaremos as falhas conforme elas acontecerem. Vamos criar algo de que nos 
orgulhamos e mantê‑lo a longo prazo por custos razoáveis.
• Comunicação: todos fazem parte da equipe e nos comunicamos cara a cara diariamente. 
Trabalharemos juntos em tudo, desde requisitos até código. Vamos criar a melhor solução que 
pudermos para o nosso problema juntos. 
• Feedback: levaremos cada compromisso de iteração a sério, entregando um software funcional. 
Demonstramos nosso software cedo e frequentemente, então ouvimos com atenção e fazemos 
as alterações necessárias. Vamos conversar sobre o projeto e adaptar nosso processo a ele, não 
o contrário.
• Respeito: todos dão e sentem o respeito que merecem como um membro valioso da equipe. 
Todos contribuem com valor, mesmo que seja simplesmente entusiasmo. Os desenvolvedores 
respeitam a experiência dos clientes e vice‑versa. A administração respeita nosso direito de aceitar 
responsabilidades e receber autoridade sobre nosso próprio trabalho.
• Coragem: diremos a verdade sobre o progresso e as estimativas. Não documentamos desculpas 
para o fracasso porque planejamos ter sucesso. Não tememos nada porque ninguém trabalha 
sozinho. Vamos nos adaptar às mudanças sempre que elas acontecerem.
Extreme programming × outras metodologias
Segundo Tebet (2021), o XP entrega conceitos bem semelhantes em relação às outras metodologias, 
como:
• abordagem incremental;
• encorajamento de comunicação face a face;
• feedback constante.
Também conta com procedimentos exclusivos da metodologia, como a orientação para boas 
práticas de engenharia de software e a utilização do Pair Programming. Esses dois pontos citados são 
o que determinam que o Extreme Programming foi desenvolvido para times de desenvolvimento de 
software e não é possível replicar suas práticas em diversas áreas, como vemos acontecer com o Scrum 
ou o Kanban.
217
ELABORAÇÃO E ANÁLISE DE PROJETOS
8.3.2 Feature Driven Development
Segundo a Devmedia (s.d.), o Feature Driven Developement (FDD) é uma entre as metodologias 
ágeis que existiam antes do Manifesto Ágil. Concebido originalmente por Jeff de Luca, o FDD surgiu em 
Singapura, entre os anos de 1997 e 1999, com base no método Coad (criado por Peter Coad entre 1980 
e 1990) e nos processos interativos e lean já utilizados por Jeff de Luca.
O FDD busca o desenvolvimento por funcionalidade, ou seja, por um requisito funcional do sistema. 
É pratico para o trabalho com projetos iniciais ou projetos com codificações existentes. Apesar de ter 
algumas diferenças entre o FDD e o XP, é possível utilizar as melhores práticas de cada metodologia. 
O FDD atua muito bem em conjunto com o Scrum, pois o Scrum atua no foco do gerenciamento do 
projeto e o FDD atua no processo de desenvolvimento.
O FDD possui cinco processos básicos, de acordo com a Devmedia (s.d.):
• desenvolvimento de modelo abrangente (análise orientada por objetos);
• construção de lista de funcionalidades (decomposição funcional);
• planejar por funcionalidade (planejamento incremental);
• detalhe por funcionalidade (desenho orientado a objetos);
• construção por funcionalidade (programação e teste orientado a objetos).
Ainda segundo a Devmedia (s.d.), o FDD, assim como a Teoria de Sistemas afirma, entende que a 
soma das partes é maior do que o todo. Desta forma, apesar de criar um modelo abrangente baseado no 
todo que será desenvolvido, esta fase inicia‑se com o detalhamento do domínio do negócio com divisão 
de áreas que serão modeladas. O modelo só está pronto quando todos da equipe estiverem de acordo, 
e o planejamento é feito com base na lista de funcionalidades. Se fossemos trabalhar com FDD em 
conjunto com o Scrum, a lista de funcionalidades seria utilizada no backlog de produtos, como histórias 
de usuários a serem desenvolvidas.
Com base na lista de funcionalidades, deve‑se planejar por funcionalidade, mas este planejamento 
é incremental. Isto, em conjunto com o Scrum, deve ser analisado como etapa de desenvolvimento do 
incremento, então esse planejamento é feito com base no que será desenvolvido naquele incremento.
Complementando, de acordo a Devmedia (s.d.), vamos novamente ao Scrum, separando o que será 
feito na Sprint, e colocamos no backlog do sprint. O que está no backlog do sprint são funcionalidades 
que serão desenvolvidas