Escolar Documentos
Profissional Documentos
Cultura Documentos
Unidade III
7 ANÁLISE DE VIABILIDADE DE PROJETOS
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):
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.
185
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.
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.
186
ELABORAÇÃO E ANÁLISE DE PROJETOS
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:
187
Unidade III
De certo modo, 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.
É 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.
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.
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:
• análise de indicadores calculados em cima dos dados de receitas, despesas, custos e investimentos.
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.
189
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:
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
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.
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
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.
190
ELABORAÇÃO E ANÁLISE DE PROJETOS
900
800
700
600
500
400
300
200
100
0
Jan Fev Mar Abr Mai Jun Jul Ago Set Out Nov Dez
• 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 qual o 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).
191
Unidade III
É 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:
Planejamento
Necessidades Seleção do projeto
do projeto
Implementação
Avaliação do projeto Controle do projeto
do projeto
Conclusão do 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.
192
ELABORAÇÃO E ANÁLISE DE PROJETOS
Articular
os requisitos
técnicos
Estabelecer os
requisitos funcionais
Articular a necessidade
Reconhecer a necessidade
Emergência da necessidade
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:
• 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.
193
Unidade III
• Humanos: existência dos recursos humanos com competência para execução, disponibilidade e
conhecimento.
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.
194
ELABORAÇÃO E ANÁLISE DE PROJETOS
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.
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:
• morar na cidade;
• experiência administrativa;
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.
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.
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.
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”.
197
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.
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 todos os 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
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.
198
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.
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
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.
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.
199
Unidade III
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.
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
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
Conforme Pinheiro (2012), a seguir serão vistos quais são os papéis desempenhados por cada
componente da equipe:
– 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.
180
160
140
120
100
80
60
40
20
0
1 2 3 4 5 6 7 8 9 10
Restante Estimado
202
ELABORAÇÃO E ANÁLISE DE PROJETOS
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.
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.
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.
203
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.
PO define o
backlog do produto
Equipe apresenta
o sistema resultante
Equipe realiza do sprint ao PO
1a reunião do sprint
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.
204
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 e entregas que liberem produtos funcionando, com mais agilidade e índices
de qualidade excelentes.
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!
205
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
206
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.
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:
• 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:
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ões diárias de 15 a 20 minutos,
207
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.
• 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
208
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
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.
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.
209
Unidade III
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.
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,
– aumento de produtividade.
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.
210
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 facilitador e ú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
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.
211
Unidade III
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.
212
ELABORAÇÃO E ANÁLISE DE PROJETOS
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?
• 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:
— identificam impedimentos;
• 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.
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.
213
Unidade III
E já que estamos vivendo a transformação digital, com a versão virtual da metodologia Scrum fica
muitomais 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:
Ferramentas pagas:
214
ELABORAÇÃO E ANÁLISE DE PROJETOS
burndown chart, time tracking etc. E tudo isso com um visual muito
bonito e intuitivo.
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.
215
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.
• 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.
Segundo Tebet (2021), o XP entrega conceitos bem semelhantes em relação às outras metodologias,
como:
• abordagem incremental;
• 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.
216
ELABORAÇÃO E ANÁLISE DE PROJETOS
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.
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 durante o sprint (que pode ser de duas a quatro semanas). Essas tarefas são
planejadas com maior rigor neste ponto, e temos então o planejamento incremental, ou seja, planejamos
apenas o que vamos desenvolver. Nesta etapa, os envolvidos no processo resumem‑se apenas à equipe,
ou seja, os desenvolvedores, analistas, testadores etc., que vão atuar no processo. Eles devem selecionar
os itens com base no tempo que eles possuem e nas qualificações atuais da equipe.
217
Unidade III
Após o planejamento, é feito o detalhamento. Nesta fase, é de extrema importância que o desenho
esteja de acordo com o que o cliente deseja, então é mantido contato constante com o cliente, como
em todas as metodologias ágeis.
Esta documentação é a base para o desenvolvimento. Não se deve perder tempo com documentação
que não será utilizada, mas é necessário documentar.
Um ponto que diverge do XP é que no FDD incentiva-se o desenvolvedor como único responsável
pelo módulo que este desenvolve. Já no XP o código é comunitário.
A utilização da integração contínua permite que a equipe esteja em contato constante com o cliente,
tornando o processo ágil e com entregas constantes.
Como cada fase apresentada é específica e curta, e as fases se completam, são necessários relatórios
para manter o controle, para analisar a quantidade de recursos que estão sendo desenvolvidos.
Além disso, o FDD possui as chamadas melhores práticas que indicam boas práticas ao desenvolver
com o FDD. São elas:
• classe proprietária, ou seja, a unidade é feita individualmente, evitando‑se assim conflitos na equipe;
• equipes de recursos, que são equipes pequenas, destinadas a desenvolver recursos necessários ao
projeto, de forma secundária;
• gerenciamento de configuração;
218
ELABORAÇÃO E ANÁLISE DE PROJETOS
Conclusão
Segundo a Devmedia (s.d.), é possível notar como o FDD pode atuar em conjunto com outras
metodologias, principalmente com o Scrum, encaixando‑se perfeitamente como metodologia de
engenharia ágil de software com projeto ágil de software.
Além disso, é possível notar que as boas práticas do FDD podem entrar em embate com o XP, na forma
em que o código é tratado por cada uma das metodologias. Lembrando que as metodologias possuem
características que podem ser adaptadas à necessidade de cada empresa, se notarmos o foco principal
em todas as metodologias, temos o desenvolvimento por incremento, a comunicação constante com o
cliente e a integração contínua.
A gestão Lean é uma metodologia ágil que tem como foco a eliminação de desperdícios. Então,
quando consideramos o Lean Manufacturing, falamos dessa metodologia aplicada à manufatura.
Segundo Santos (2016), a Lean Manufacturing, pela frequente e esmagadora cultura popular,
consiste em um grupo de técnicas que, quando combinadas e amadurecidas, permitirão a você reduzir
e depois eliminar os sete desperdícios (eu sei que já falam em oito há um bom tempo, mas vamos lá).
Ainda segundo Santos (2016), a ideia central é maximizar o valor do cliente e minimizar o desperdício.
Lean significa criar mais valor para clientes com menos recursos. O sistema do Lean não irá somente
tornar seu ambiente de trabalho para ter uma mentalidade enxuta, mas também a tornará mais flexível
e mais responsiva por meio da redução dos desperdícios.
Santos (2016) afirma que o termo “Lean Manufacturing” tem origem no Japão pós‑guerra. Nesse
período, surge a necessidade de se criar um processo produtivo que não necessitasse de altos estoques,
mantivesse um fluxo de caixa mais ágil e atendesse às diversas demandas, produzindo com eficiência
produtos personalizados.
Segundo Santos (2016), este processo mais tarde se chamaria de Sistema Toyota de Produção.
Na definição, percebemos que os termos japoneses usados pela Toyota também estão fortemente
difundidos, principalmente no que tange às ferramentas. Entre elas destacam‑se a melhoria contínua
de processos (kaizen), os 5 porquês e o sistema à prova de erros (poka‑yoke). Dessa maneira, a técnica
pode ser considerada muito similar a outras existentes cujo objetivo é melhorar processos.
O lean maximiza o valor do cliente e minimiza o desperdício. Ou seja, lean significa criar mais valor
para clientes com menos recursos. Uma organização enxuta entende o valor do cliente e concentra seus
principais processos para aumentá‑lo continuamente.
219
Unidade III
Para conseguir isso, o pensamento enxuto – ou filosofia lean – muda o foco do gerenciamento de
otimizar tecnologias separadas, ativos e departamentos verticais para otimizar o fluxo de produtos e
serviços por meio de fluxos de valor inteiros que fluem horizontalmente entre tecnologias, ativos e
departamentos até os clientes.
O termo lean, em sua tradução literal, é entendido como “enxuto”, ou seja, produção enxuta. Logo,
trata‑se de uma estratégia que envolve apenas o uso dos recursos necessários, impedindo que sejam
criados excessos. Assim, podemos afirmar que Lean é uma filosofia de gestão que elimina excessos
de produção.
Segundo Santos (2016), eliminar o desperdício ao longo de todo o fluxo de valor, em vez de pontos
isolados, cria processos que exigem menos esforço humano, menos espaço, menos capital e menos tempo
para fabricar produtos e serviços. Isso significa custos muito menores e com muito menos defeitos, em
comparação com sistemas tradicionais de negócios.
As empresas, então, se tornam responsivas às mudanças nos desejos dos clientes com alta variedade,
alta qualidade, baixo custo e processamento muito rápido. Além disso, o gerenciamento de informações
se torna muito mais simples e preciso.
Conforme Santos (2016), desperdício é definido como qualquer atividade que não agrega valor do
ponto de vista do cliente. O autor afirma que, de acordo com uma pesquisa conduzida pelo Centro
de Pesquisas Lean Enterprise (LERC), 60% das atividades de produção em uma operação típica de
manufatura são desperdícios e não agregam nenhum valor para o cliente.
Tipos de desperdício
• transporte;
• inventário;
• movimentação;
220
ELABORAÇÃO E ANÁLISE DE PROJETOS
• espera;
• produção excessiva;
• processamento excessivo;
• defeitos.
A boa notícia é que praticamente toda empresa tem a oportunidade de melhorar, usando técnicas de
manufatura enxuta e outras práticas recomendadas de manufatura, assim como técnicas que permitem
oferecer produtos de maior qualidade a custos significativamente mais baixos.
Ainda segundo Santos (2016), o objetivo do Lean Manufacturing se distingue por um tempo de troca
de ferramenta (setup) mínimo, produção Just‑In‑Time (JIT), sistemas Kanban, um mínimo de estoque e
por último, mas não menos importante, uma atitude de “desperdício zero” de cada funcionário através de:
• implementação one‑piece‑flow;
• eliminação de defeitos;
Conforme Santos (2016), para entender mais a fundo sobre o Lean Manufacturing, vamos conferir
os seus cinco princípios:
• Especificação de valor sob a ótica dos clientes: especificar valor na ótica do cliente é um
dos princípios que inclusive ajudam a conquistá‑los, afinal, é uma das formas de demonstrar
qualidade nos produtos e/ou serviços onde a metodologia Lean atua.
• Otimização dos fluxos de valor: fluxo de valor é o que inclui todo o processo produtivo, de
ponta a ponta, e as atividades que aprimoram e conferem valor ao seu produto/serviço. Ou seja,
você deve realizar uma boa gestão da sua cadeia de suprimentos. O VSM é uma ferramenta que
ajuda muito a entender como as atividades realizadas agregam valor ao produto final.
221
Unidade III
• Fluxo contínuo: o fluxo contínuo basicamente se refere à não interrupção dessas atividades que
agregam valor, assim você otimiza não apenas a sua produção, como também o seu tempo.
• Produção puxada: eis um modo de controle da produção que consiste em produzir mediante a
demanda, ou seja, a demanda é quem “puxa” a produção. A produção em grande quantidade e
com altos estoques é considerada um desperdício pelo Lean, uma vez que se trata de recursos e
dinheiro “parados”.
• Perfeição: o sistema Lean, além de reduzir os seus desperdícios, busca também um melhor
aproveitamento de recursos, conferindo valor ao cliente. Essas atividades são importantes para
que você obtenha cada vez mais qualidade nos seus produtos, desenvolvendo uma política de
melhoria contínua.
Ao implementar a Lean Manufacturing, usamos uma série de etapas, mas sempre focando na
melhoria da percepção de valor por parte do cliente. Sobretudo durante o processo de implementação,
é importante conhecer as demandas e desejos que o cliente tem em relação ao produto.
Santos (2016) afirma que o mapeamento de fluxo de valor (VSM) é uma prática enxuta fundamental
que envolve a diagramação de um fluxo de valor, tornando‑se então possível documentar o processo
de adição de valor para um produto. Entre outras coisas, isso pode ser feito com a ajuda de um mapa de
fluxo de valor VSM. Nós nos esforçamos para eliminar todas as perdas da atual cadeia de processos;
portanto, isso realmente implica que o fluxo de materiais e informações do processo anterior para o
próximo ocorra sem demora e com armazenamento intermediário.
Ainda segundo Santos (2016), exige‑se uma produção muito confiável e efetiva com a medição do
OEE (taxa de disponibilidade, taxa de desempenho e taxa de qualidade). Isso pode ser alcançado, por
exemplo, implementando a Manutenção Produtiva Total. Ao ter um processo de produção confiável e
eficaz, o intervalo de tempo entre a colocação de um pedido e a entrega torna‑se consideravelmente
mais curto. Por conseguinte, não é mais necessário produzir com base no que se tem em estoque e
pode‑se produzir uma quantidade que o cliente quer e no momento em que quiser.
Um equívoco popular é que o lean é adequado apenas para a fabricação. Não é verdade. Lean
aplica‑se a todos os negócios e processos. Não é uma tática ou um programa de redução de custos, mas
uma maneira de pensar e agir para uma organização inteira.
222
ELABORAÇÃO E ANÁLISE DE PROJETOS
Empresas em todos os setores e serviços, incluindo saúde e governos, estão usando os princípios
enxutos na maneira como pensam e agem. Muitas organizações optam por não usar a palavra lean,
mas rotular o que fazem como seu próprio sistema, como o Toyota Production System ou o Danaher
Business System.
Encare a questão de que o Lean não é um programa de redução de custos de curto prazo, mas uma
maneira como a empresa opera, por isso requer uma transformação completa sobre como uma empresa
conduz os negócios, criando uma perspectiva de longo prazo e perseverança.
Segundo Santos (2016), gerentes e executivos envolvidos nas transformações lean pensam em três
questões fundamentais de negócios do Lean Manufacturing que devem guiar a transformação de toda
organização:
• Propósito: afinal, quais problemas do cliente a empresa resolverá para alcançar seu próprio
propósito de prosperar?
• Processo: como a organização avaliará cada grande fluxo de valor para garantir que cada etapa
seja valiosa, capaz, disponível, adequada e flexível e que todas as etapas estejam ligadas por fluxo,
atração e nivelamento?
• Pessoas: como a organização pode garantir que todo processo importante tenha alguém
responsável por avaliar continuamente esse fluxo de valor em termos de propósito comercial e
processo enxuto? Além disso, como todos que tocam o fluxo de valor podem se engajar ativamente
em operá‑lo corretamente e continuamente melhorando‑o?
Saiba mais
Para saber mais sobre a filosofia lean, acesse o site do Lean Institute
Brasil no link a seguir:
Essas são as principais ferramentas, mas com certeza você poderá encontrar outras que se adptem
à sua necessidade.
223
Unidade III
Resumo
224
ELABORAÇÃO E ANÁLISE DE PROJETOS
225
Unidade III
Exercícios
Questão 1. Um dos indicadores de viabilidade financeira que pode subsidiar a decisão de investimento
em determinado projeto é o payback. Esse indicador permite o cálculo do tempo necessário para que o
projeto retorne o valor investido.
Com base no exposto e nos seus conhecimentos sobre o tema, avalie as afirmativas:
II – Não há relação entre o fluxo de caixa da empresa e o payback. Este refere‑se ao tempo para recuperação
do investimento, e o fluxo de caixa registra o movimento de entradas e de saídas de recursos financeiros.
III – O payback pode ser utilizado para analisar se é viável realizar um investimento. No entanto, não
é o único indicador financeiro a ser levado em conta na decisão de investir.
A) I, apenas.
B) III, apenas.
C) I e II, apenas.
D) II e III, apenas.
E) I, II e III.
I – Afirmativa incorreta.
Justificativa: o cálculo do tempo de retorno do investimento por meio do método do payback pode
ser aplicado a qualquer novo empreendimento ou novos projetos de uma empresa.
II – Afirmativa incorreta.
Justificativa: existe uma relação direta entre o payback e o fluxo de caixa, uma vez que para se obter
o payback simples basta dividir o valor do investimento inicial pelo fluxo de caixa médio, ou seja, os
ganhos no período.
226
ELABORAÇÃO E ANÁLISE DE PROJETOS
Justificativa: o payback é um dos indicadores de viabilidade financeira que pode ser empregado para
verificar a viabilidade de um investimento, uma vez que ele indica o tempo de retorno do valor a ser
investido. No entanto, ele deve ser utilizado em conjunto com outros indicadores, como o Valor Presente
Líquido – VPL, que consiste em trazer o fluxo de caixa do projeto para a data zero, a Taxa Interna de
Retorno – TIR, que é a taxa de desconto que iguala o VPL a zero etc.
Metodologias ágeis
As metodologias ágeis são conjuntos de práticas que visam à entrega rápida e de alta qualidade do
produto ou serviço e que promove um processo de gerenciamento de projetos que incentiva a inspeção
e adaptação frequente. Assim, as equipes conseguem lidar com imprevistos e podem realizar alterações
antes da conclusão do projeto.
I – As metodologias ágeis surgiram a partir da maturação da indústria de software, por isso seu
emprego é circunscrito ao desenvolvimento de projetos de sistemas de informação.
III – Apesar de intitulados “ágeis”, projetos que utilizam métodos dessa abordagem não dispensam
planejamento e nem documentação.
A) I, apenas.
B) III, apenas.
C) I e II, apenas.
D) II e III, apenas.
E) I, II e III.
227
Unidade III
I – Afirmativa incorreta.
Justificativa: as metodologias ágeis foram desenvolvidas para entregar com mais rapidez e
mais frequência versões de software aos clientes. Com isso, outras áreas começaram a utilizar essas
metodologias para outros tipos de projetos, como uma maneira de otimizar tempo e recursos e alcançar
os resultados com mais celeridade.
II – Afirmativa incorreta.
Justificativa: o emprego da metodologia Scrum não garante que um projeto será entregue no prazo
e no orçamento planejados, ou seja, não se trata de um processo padronizado, mas de uma estrutura
para gerenciar projetos complexos, como o desenvolvimento de software.
228
REFERÊNCIAS
Audiovisuais
JOHNSON, S. Where good ideas come from. Publicado por TedTalk, 2017. 1 vídeo (17 min). Disponível
em: https://cutt.ly/t1PIyYG. Acesso em: 9 dez. 2022.
NOVO Guia PMBOK 7 vs PMBOK 6 – O que mudou? 2020. 1 vídeo (14 min). Publicado por Mario
Trentim – Gestão de Projetos. Disponível em: https://www.youtube.com/watch?v=1b7bvaF207o.
Acesso em: 10 nov. 2022.
Textuais
ABNT. NBR ISO 9000:2015: sistemas de gestão da qualidade – fundamentos e vocabulário. Rio de
Janeiro: ABNT, 2015.
ATSIT CONSULTORIA. PMBOK 7 vs PMBOK 6: principais diferenças que você precisa saber – Simplilearn.
2021. Disponível em: https://cutt.ly/g1O7J8l. Acesso em: 15 nov. 2022.
BRASILEIRO, R. Manifesto ágil, o que é e qual a sua história. Método Ágil, [s.d]. Disponível em:
https://cutt.ly/V1O70PY. Acesso em: 6 set. 2019.
BROD, C. Scrum: guia prático para projetos ágeis. 2. ed. São Paulo: Novatec, 2015.
CAMARGO, R. O que realmente é a metodologia ágil? Robson Camargo, 8 nov. 2019. Disponível em:
https://cutt.ly/G0wTUml. Acesso em: 6 set. 2019.
CARVALHO, M. M.; RABECHINI JR., R. Construindo competências para gerenciar projetos: teoria e casos.
3. ed. São Paulo: Atlas, 2011.
229
COMO fazer um fluxograma: guia completo passo a passo. Bloxs, 28 jun. 2022. Disponível em:
https://cutt.ly/q0wRWZs. Acesso em: 8 dez. 2022.
DEVMEDIA. Introdução ao FDD ‑ Feature Driven Development. [s.d.]. Disponível em: https://cutt.ly/519XaSL.
Acesso em: 6 dez. 2022.
DUARTE, J. Framework scrum: o que é como aplicar. GP4US, 22 nov. 2015. Disponível em: https://cutt.
ly/s1PvWi7. Acesso em: 7 dez. 2022.
JORGE, J. Análise dos fatores responsáveis pelo sucesso ou pelo fracasso de um projeto.
Administradores.com, 17 jul. 2015. Disponível em: https://cutt.ly/X1PvOan. Acesso em: 4 dez. 2022.
KOTLER, P. Administração de marketing: análise, planejamento e controle. São Paulo: Atlas, 1991.
LEAN Institute Brasil. Disponível em: https://www.lean.org.br. Acesso em: 12 jan. 2023.
MADUREIRA, O. M. de. A viabilidade de projetos em dez lições. Fundação Vanzolini, 16 out. 2014.
METODOLOGIA ágil: o que é e como implementar. Totvs, 12 jul. 2021. Disponível em: https://cutt.ly/81Pbacn.
Acesso em: 6 set. 2019.
230
MILES, R. E.; SNOW, C. C. Organizational strategy, structure, and process. Nova York: Stanford Business, 2003.
PINHEIRO, R. Uma visão geral sobre o scrum. DevMedia, 2012. Disponível em: https://cutt.ly/q1Pnhja.
Acesso em: 7 set. 2019.
PMI. Código de Ética e Conduta Profissional. PMI, [s.d.]a. Disponível em: https://cutt.ly/G1FjPME.
Acesso em: 4 dez. 2022.
PMI. A Guide to the Project Management Body of Knowledge (PMBOK Guide). Seventh edition and
standard for project management. Pensilvânia: Project Management Institute, 2021.
PMI. Manual dos requisitos de certificação continuada (CCR). PMI, 11 jan. 2016.
PMI. PMBOK Guide 7th Edition vs 6th Edition. PMI, [s.d.]b. Disponível em: https://cutt.ly/W1PR484.
Acesso em: 1º dez. 2022.
SANTOS, V. Lean Manufacturing: O que é? Qual o objetivo? FM2S, 25 fev. 2016. Disponível em:
https://cutt.ly/a1PYsg6. Acesso em: 1º dez. 2022.
SCRUM. Desenvolvimento Ágil, [s.d.]. Disponível em: https://cutt.ly/K1PY0fo. Acesso em: 7 dez. 2022.
SEBRAE. Entenda o que é uma pesquisa de mercado. 20 mar. 2015. Disponível em: https://cutt.ly/B1PUuvT.
Acesso em: 3 dez. 2015.
SILVA FILHO, J. B. da. Como aplicar o gerenciamento da qualidade no seu projeto. BSBr, 29 mar. 2018.
Disponível em: https://cutt.ly/Z1PUHCK. Acesso em: 6 set. 2019.
SOTILLE, M. A. et al. Gerenciamento do escopo em projetos. 2. ed. Rio de Janeiro: FGV, 2010.
231
TEBET, I. Extreme Programming (XP): o que é, valores e benefícios. Objective, 3 fev. 2021. Disponível em:
https://cutt.ly/D19G7eZ. Acesso em: 6 dez. 2022.
VALERIANO, D. L. Gerenciamento estratégico e administração por projetos. São Paulo: Makron, 2000.
VIEIRA, D. Ferramentas scrum: um dossiê completo. MindMaster, 19 ago. 2014. Disponível em:
https://cutt.ly/E1PP8cZ. Acesso em: 9 dez. 2019.
WHAT’S new with PMI Standards & Publications. PMI, [s.d.]. Disponível em: https://cutt.ly/w1PbGHb.
Acesso em: 18 jul. 2022.
232
Informações:
www.sepi.unip.br ou 0800 010 9000