Apostila Introdução às Metodologias Ágeis

Prévia do material em texto

INTRODUÇÃO ÀS 
METODOLOGIAS ÁGEIS
W
BA
07
25
_v
1.
2
22 
© 2019 POR EDITORA E DISTRIBUIDORA EDUCACIONAL S.A.
Todos os direitos reservados. Nenhuma parte desta publicação poderá ser reproduzida ou transmitida 
de qualquer modo ou por qualquer outro meio, eletrônico ou mecânico, incluindo fotocópia, gravação ou 
qualquer outro tipo de sistema de armazenamento e transmissão de informação, sem prévia autorização, 
por escrito, da Editora e Distribuidora Educacional S.A.
Presidente
Rodrigo Galindo
Vice-Presidente de Pós-Graduação e Educação Continuada
Paulo de Tarso Pires de Moraes
Conselho Acadêmico
Carlos Roberto Pagani Junior
Camila Braga de Oliveira Higa
Carolina Yaly
Giani Vendramel de Oliveira
Juliana Caramigo Gennarini
Nirse Ruscheinsky Breternitz
Priscila Pereira Silva
Tayra Carolina Nascimento Aleixo
Coordenador
Tayra Carolina Nascimento Aleixo
Revisor
Ana Carolina Greef 
Editorial
Alessandra Cristina Fahl
Beatriz Meloni Montefusco
Daniella Fernandes Haruze Manta
Hâmila Samai Franco dos Santos
Mariana de Campos Barroso
Paola Andressa Machado Leal
Dados Internacionais de Catalogação na Publicação (CIP)
 Lobo, Carlos Eduardo d’Araujo Vilaça
L799i Introdução às metodologias ágeis / Carlos Eduardo 
 d’Araujo Vilaça Lobo. – Londrina: Editora e Distribuidora 
 Educacional S.A., 2019.
 98 p.
 
 ISBN 978-85-522-1489-2
 
 1. Desenvolvimento ágil de software. 2. Scrum 
 (Desenvolvimento de software). I. Lobo, Carlos Eduardo 
 d’Araujo Vilaça. II. Título. 
 
 CDD 005 
Responsável pela ficha catalográfica: Thamiris Mantovani CRB-8/9491
2019
Editora e Distribuidora Educacional S.A.
Avenida Paris, 675 – Parque Residencial João Piza
CEP: 86041-100 — Londrina — PR
e-mail: editora.educacional@kroton.com.br
Homepage: http://www.kroton.com.br/
mailto:editora.educacional%40kroton.com.br?subject=
http://www.kroton.com.br/
3 3
INTRODUÇÃO ÀS METODOLOGIAS ÁGEIS
SUMÁRIO
Apresentação da disciplina 4
Origens dos Métodos Ágeis: Manifesto Ágil 6
Scrum, XP e Lean: Princípios comuns 24
Análise Comparativa 42
Balanceando Agilidade e Disciplina 61
Kanban aplicado aos Métodos Ágeis 85
Pessoas: Empoderamento e Energização 106
Pessoas: Gestão da Mudança 127
44 
Apresentação da disciplina
Ágil é usado como adjetivo para aquele que trabalha de maneira eficaz 
e rápida. Isso já indica o objetivo almejado: Simplificar os modelos de 
gestão e controle, garantindo a efetividade. Isso significa flexibilidade 
para atender um cliente em constante mudança – mesmo depois de 
fechado o escopo, e cada vez mais exigente em prazo, qualidade e custo.
Como forma de identificar os métodos ágeis – embora não exista 
consenso sobre o tema, serão chamados ágeis os métodos que 
permitam entregas em partes, defendam a interação e cooperação, 
admitam mudanças como normais e serem simples de ser assimiladas.
Dentre os diversos métodos ágeis, pode-se destacar três:
• O Lean, que se originou na Toyota, mas que não é exclusividade 
das fábricas de automóveis. Desde o início, o intuito, o objetivo do 
Lean foi tornar a operação rápida e flexível, além da alta qualidade. 
• O SCRUM é um método ágil que busca entregar o produto 
ou desenvolvimento, com a melhor qualidade possível, 
em sucessivos tiros curtos de trabalho que normalmente 
representam subconjuntos do produto – Sprints. 
• E o eXtreme Programming – XP, o método ágil mais utilizado no 
mundo para o desenvolvimento de software.
Tanta flexibilidade e agilidade sacrifica muito os controles. Até quando 
deve-se avançar sem correr riscos em excesso. Existe aqui um tradeoff 
entre disciplina e controle do risco. Quando vale o esforço do controle e 
quando investir em agilidade e flexibilidade. 
55 5
Ainda será abordado o uso do kanban em conjunto com as 
metodologias ágeis. O kanban é uma excelente ferramenta de controle 
dos processos. Tornando os controles visuais.
Dado que o Manifesto Ágil faz uma opção evidente por privilegiar 
as pessoas, é necessário discutir o fator humano. O método ágil é 
responsivo, nada melhor que operar com indivíduos e empresas 
responsivas também. Para isso será necessário organizar times de 
trabalho e garantir a motivação. E finalmente, o que se espera do gestor, 
o líder, dos times ágeis.
Finalmente será discutido processo de implementação da gestão ágil de 
projetos. Como evitar riscos e problemas na gestão da mudança. 
66 
Origens dos Métodos Ágeis: 
Manifesto Ágil 
Autor: Carlos Lobo
Objetivos
• Apresentar a origem dos Métodos Ágeis;
• Discutir os objetivos dos Métodos Ágeis;
• Explorar o Manifesto Ágil.
77 7
 1. Introdução
Segundo o dicionário Dicio, “ágil”, quando usado como adjetivo, indica 
movimento com excesso de facilidade ou que se move de maneira 
rápida; veloz. Ou ainda, que se comporta ou trabalha de maneira 
eficaz e rápida; diligente, expedito e trabalhador. Que acha uma 
solução rápida para; que se consegue desenrolar com facilidade; vivo e 
rápido. Valendo destacar que ágil é sinônimo de desembaraçado, veloz 
e diligente, dentre outros.
Deste modo, já se torna claro o fim último dos métodos ágeis. Por um 
lado, simplificar os modelos de gestão e controle, e, por outro, torná-los 
mais efetivos. De um modo muito geral, respondendo à demanda dos 
clientes cada vez mais exigentes em termos de prazo, qualidade e custo.
 2. Desafios em Serviços na Gestão de Projetos
A gestão de projetos pode ser uma área complexa e vasta. Os projetos 
podem ser pequenos e de curta duração. Entretanto, podem ser longos 
e ter custo elevado. Considere a extração de petróleo em alto mar. 
A gestão do projeto deve considerar, além da instalação e extração, 
os riscos envolvidos neste processo. A resposta para isso tem sido 
a utilização de sistemas de gestão e metodologias de projeto muito 
completas. Exemplos de sistemas de gestão são o Primavera, que hoje 
pertence a Oracle. Já como metodologias de gestão de projetos podem 
ser citadas a PMBoK - Project Management Body of Knowledge, do PMI, 
metodologia de domínio público com origem no Estados Unidos, ou o 
Prince2 – Método de gestão de projeto com raízes na Europa. 
Embora o valor destas ferramentas e métodos seja inegável, em dadas 
circunstâncias, como exemplo na organização da Olimpíada de Londres 
– feita com o Prince2, em alguns projetos o seu uso pode se tornar difícil 
ou burocrático. Assim surgiu a necessidade de se desenvolver métodos 
alternativos, mais adequados em alguns ambientes e/ou problemas.
88 
 PARA SABER MAIS
Você pode se aprofundar na revisão do PMBOK e Prince2 
consultando:
Manual prático do plano de projeto: utilizando o PMBOK 
Guide, de Ricardo Vargas (2009). Onde se aborda a gestão 
do projeto, utilizando-se o PMBoK. 
Prince2: a practical handbook de Colin Bentley (2012). 
Este texto é similar ao Guia do PMBoK, porém se utiliza 
do Prince2.
Como o Manifesto Ágil se baseia na crítica da gestão 
tradicional de projetos, é importante que você a conheça 
para melhor compreender as mudanças introduzidas.
2.1 Em Busca da Relevância Perdida
A maioria dos sistemas de gestão, e, em especial, quase todos os 
modelos de gestão de custos nas empresas, baseia-se na ultrapassada 
ideia de que o custo de um produto é fundamentalmente o custo da 
matéria-prima ou componentes e pouco mais. Isso já não é verdade na 
indústria, onde depreciação e outros itens são maiores que o custo da 
mão de obra direta.
Se considerarmos o setor de serviços, ou setores onde a inovação é 
rápida e determinante, gerir a empresa somente através da perspectiva 
financeira pode ser muito pouco eficaz.
Algumas alternativas foram desenvolvidas com o intuito de dar 
relevância ao sistema de gestão. E possivelmente a mais relevante na 
área de gestão estratégica e financeira tenha sido o BalancedScorecard 
(Kaplan e Norton, 1996).
99 9
2.2 Balanced Scorecard
O Balanced Scorecard (Kaplan e Norton, 1992) - apresentado na 
figura 1, acrescenta às medidas financeiras tradicionais para auferir 
desempenho três perspectivas adicionais - dos clientes, do processo 
interno do negócio e do crescimento e aprendizado da organização. 
Isto habilita que as empresas acompanhem seus resultados financeiros 
enquanto monitoram o progresso da construção de capacidade e 
obtenção das disponibilidades intangíveis que elas precisarão para 
crescer no futuro (LOBO, 2003).
Figura 1 | Integração das diferentes perspectivas para a Companhia
Fonte: Adaptada de Kaplan e Norton, 1992.
Assim, implementar o Balanced Scorecard requer estabelecer objetivos, 
metas, indicadores de desempenho e plano de ação para cada uma das 
perspectivas, e todas a partir do plano estratégico da companhia. 
A figura 2 traz essa visão integrada do modelo.
1010 
Figura 2 | Integração das Medidas de Desempenho 
via Balanced Scorecard
Fonte: Adaptada de Kaplan e Norton, 1992.
O Scorecard possibilita reunir medidas de desempenho e planejamento 
estratégico, e por consequência da estratégia da empresa. Assim, dada 
a visão estratégica, estabelecem-se objetivos e mede-se o desempenho 
da operação sob os pontos de vista financeiro, satisfação do cliente, 
aprendizado e crescimento da organização, e do processo interno. 
Note que ao invés de termos diversos e difusos indicadores de 
desempenho para suportar a gestão do negócio, o Balanced Scorecard 
propõe um conjunto mínimo de indicadores necessários para controlar 
o negócio em suas diversas perspectivas.
Para desdobrar o plano estratégico para toda a empresa, Kaplan e 
Norton (2000) propõem o mapa estratégico. Na figura 3 Kaplan e Norton 
apresentam um exemplo genérico.
1111 11
Fonte: Kaplan e Norton (2000).
Outros modelos similares também foram desenvolvidos e um exemplo é 
o Tableau de Bord. 
Mora Corral e Vivas Urieta (2001) propõem cinco etapas para 
implementação do Tableau de Bord. As etapas são: 
I. Visão e missão da organização; 
II. Definição dos objetivos estratégicos; 
III. Determinação de áreas-chave de resultado; 
IV. Definição de objetivos operacionais;
V. Seleção de indicadores. 
2.3 Sistema de Estratégia Minimalista
Este sistema tem como objetivo o abandono de excessos que 
prejudicam a agilidade. Ele busca uma gestão que evita excessos, 
desperdícios e foca na satisfação do cliente/consumidor. 
Figura 3 | Mapa Estratégico
1212 
Segundo Rocha, 2016, este sistema busca conquistar os 4 Es, são eles:
• Elegância;
• Eloquência;
• Eficiência;
• Êxito.
Nesse sentido, esta proposta de estrutura estratégica baseia-se nos 4Cs 
(LAUTERBORN, 1990):
• CLIENTE conhecido e cadastrado.
• CONVENIÊNCIA e entrega.
• COMUNICAÇÃO de mão dupla ou interativa com o cliente.
• CUSTO centrado na capacidade de pagamento do cliente.
Os 4Cs de Lauterborn surgiram em oposição aos tradicionais 4Ps do 
marketing: Preço, Produto, Praça e Promoção.
3. Visão e Valores dos Métodos Ágeis
Os Métodos Ágeis oficialmente tiveram origem em uma reunião de 
gestores de projetos da área de software que buscavam soluções mais 
rápidas e práticas para os desafios que enfrentavam. Essa reunião 
ocorreu nos Estados Unidos, em 2001, e deu origem ao que ficou 
conhecido como Manifesto Ágil. 
A visão buscada pelo grupo – explicitada na figura 4 – foi simplificar e 
tornar mais rápido e flexível o processo de desenvolvimento de soluções 
de software. Os valores definidos por eles foram:
• Valorizar os indivíduos e as interações entre estes – é sabido que 
são as interações que fomentam a inovação, em detrimento de 
procedimentos e ferramentas;
• Software funcional em detrimento de uma documentação 
mais completa;
1313 13
• Mais colaboração com o cliente e menos contratos e 
negociações; e
• Mais flexibilidade para se adaptar às mudanças e menos atenção 
ao planejamento detalhado.
E note que estes quatro valores buscados não querem dizer que se vá 
abandonar a prática tradicional, apenas que os primeiros serão mais 
valorizados que os outros.
Figura 4 | Valores dos Métodos Ágeis
Fonte: Adaptada de Fowler e Highsmith (2001).
3.1 Manifesto Ágil
Como se pode constatar no Manifesto Ágil, hoje em dia praticamente 
não há metodologia de gestão de projetos que não tenha incorporado 
alguns dos seus 12 princípios.
Os princípios do Manifesto Ágil, segundo Fowler e Highsmith (2001), são:
• A mais alta prioridade é satisfazer o cliente através da entrega 
antecipada e contínua de valor. 
1414 
O que se propôs entregar? Qual é o negócio? Definir quais são os 
compromissos primordiais de sua empresa traz clareza e mostra 
qual é a mensagem a ser veiculada tanto para consumidores como 
para parceiros e fornecedores.
• Acolher bem mudanças nos requisitos, mesmo quando já tivermos 
avançado desenvolvimento. Processos ágeis estão subordinados à 
mudança para a vantagem competitiva do cliente.
A imprevisibilidade nos negócios é o desafio atual. A proposta é 
usar a imprevisibilidade como uma oportunidade a ser explorada, 
ao contrário de uma ameaça. Tenha em vista que a comunicação 
contínua com o cliente, objetivo do manifesto ágil, gera feedbacks, 
e estes geram mudanças. 
• Faça entregas frequentes.
Embora este princípio esteja ligado ao desenvolvimento de 
software, sua aplicação em desenvolvimento de produto 
é imediata. O objetivo é fazer entregas frequentes em 
subconjuntos independentes, de modo incremental. Isso é 
essencial nas metodologias ágeis. Isso ajuda a reduzir tempo de 
ciclo total de desenvolvimento e aproxima o cliente do processo. 
Evidentemente, entrega não é sinônimo de lançamento. Em 
inglês são usados delivery e release. O primeiro indica o tipo de 
entrega que se busca aqui. Já o segundo indica lançamento do 
produto – versão final.
• Pessoal de negócios e desenvolvimento trabalham juntos 
diariamente durante o projeto.
Note que o Manifesto Ágil está focado no desenvolvimento de 
produtos ou serviços customizados. Não se trata de produtos 
padrão. O desenvolvimento é feito a partir de requisitos 
básicos e amplos. Apenas uma visão geral do produto 
1515 15
desejado. A comunicação frequente da área de negócios com 
o desenvolvimento é fundamental para que os requisitos 
funcionais sejam detalhados. 
• Desenvolva os projetos com pessoal motivado, dê-lhes o 
ambiente e o suporte que eles necessitam e acredite neles para 
entregar o projeto.
As ferramentas e tecnologias são importantes, mas são as 
pessoas que fazem a diferença. No fim, são elas que fazem 
a diferença entre sucesso e fracasso. O melhor gestor não 
consegue garantir a entrega de um projeto do produto. Mesmo 
usando processos ágeis. Ele irá precisar confiar que seu time 
tome as decisões corretas.
• O método mais eficiente e efetivo de prover informações para 
um time de desenvolvimento é conversando diretamente.
Uma grande preocupação dos críticos do Manifesto Ágil é sua 
pouca preocupação com a documentação. O objetivo aqui 
é resgatar a função inicial da documentação. Compartilhar 
informações com o intuito de compartilhar conhecimento e gerar 
inovação. Note que existe o conhecimento explícito e o tácito. 
ASSIMILE
Na visão de dois pensadores japoneses, Nonaka e Takeushi 
(1995), existe um ciclo de geração de conhecimento que 
se inicia na interiorização do conhecimento, passa por 
um processo de exteriorização até a socialização na 
organização. E por outro lado, migra de conhecimento 
implícito para o explícito. A figura 5 apresenta o modelo de 
Nonaka e Takeushi.
1616 
Figura 5 | Conhecimento Organizacional
Fonte: Adaptada de Nonaka e Takeushi (1995).
• O produto em desenvolvimento é o indicador básico de progresso.
É comum encontrar times de desenvolvimento de projeto que 
não perceberam que estavam atrasados até ser tarde demais. 
Até todos os prazos estarem perdidos. Por isso a entrega em 
1717 17
partes do projeto, subconjuntos, é tão importante. As entregasfracionadas funcionam tanto para o time quanto para o cliente, 
que dá feedback em tempo real com o desenvolvimento.
• Processos ágeis promovem o desenvolvimento sustentado. Os 
patrocinadores (Sponsors), projetistas e usuários devem ser 
capazes de manter o ritmo constante indefinidamente. 
Áreas de desenvolvimento costumam exigir muitas horas-extras 
e sobrecarga de trabalho. Como será discutido no curso de lean, 
uma forma de desperdício é a sobrecarga de trabalho (muri), 
que compromete a produtividade. Um processo ágil baseia-se 
em indivíduos que se mantêm alertas e criativos durante todo o 
desenvolvimento do projeto. Novamente, pode-se referenciar o 
lean que defende uma carga de trabalho nivelada com a demanda 
a fim de se manter o ritmo constante.
• Atenção contínua a excelência técnica e um bom projeto 
aumentam a agilidade.
No passado, durante a década de 1990, na área de 
desenvolvimento de sistemas foi usado o RAD (Rapid Application 
Development) como forma de acelerar o desenvolvimento. Isso 
era feito com algum sacrifício do desempenho e qualidade. 
Os métodos ágeis enfatizam a qualidade do projeto, pois sem 
qualidade é impossível manter a agilidade.
• Simplicidade – a arte de maximizar o trabalho não realizado – é 
essencial.
A simplicidade pode ser desdobrada em:
• Minimalismo;
• Qualidade do projeto;
• Regras geradoras.
Minimalismo no projeto e desenvolvimento de produtos e serviços 
significa incluir realmente e somente o necessário. 
1818 
Pense o iTunes da Apple como exemplo. Praticamente não existem 
controles e ajustes a serem feitos. E isso não faz o sistema ser pior que 
os outros. Por outro lado, qualidade no projeto 
• Os melhores projetos e requisitos emergem de times autônomos 
de trabalho.
Segundo Petroski (1994), os melhores projetos e especificações 
nascem mais do desenvolvimento e interações do time do que de 
especificações prévias.
• Em intervalos regulares o time analisa como ser mais efetivo, 
então sintoniza e ajusta seu comportamento de acordo.
 
TEORIA EM PRÁTICA
Considere um grande banco de varejo. Somente na sede 
da empresa trabalham aproximadamente 20.000 pessoas, 
todas em funções de backoffice.
Este banco decidiu pelo método ágil para a gestão da 
operação. Esta iniciativa foi capitaneada pela diretoria da 
empresa. Seu maior desejo era reduzir a burocracia e as 
atividades desnecessárias.
Tenha em vista que os bancos seguem uma série de regras 
estabelecidas pelo banco central e outras autoimpostas. 
A principal destas é o acordo de Basiléia, versões I, II e III. 
Basicamente estes acordos visam garantir a liquidez do 
sistema financeiro, definindo o mínimo de reservas internas 
que cada banco deve manter para desempenhar suas 
atividades dentro de um risco aceitável.
1919 19
Agora considere as seguintes questões que a direção deve 
resolver para que o método ágil de gestão se efetive:
1. O método ágil transfere poder de decisão da alta 
gerência para os indivíduos que estão na linha de frente, 
de quanto poder estamos dispostos a abrir mão? Se os 
executivos não cederem parte do status e poder, usar 
um método ágil não se encaixará.
2. Como preparar os stakeholders para a mudança? A 
diretoria do banco deverá de convencer o conselho 
da empresa, empregados e negociar com órgãos 
reguladores.
3. Como rever a estrutura do banco para focá-la no cliente 
– mas, ao mesmo tempo, mantê-la fluida, flexível? 
4. Qual é o ponto de equilíbrio entre supervisão e 
autonomia? Como estabelecer metas adequadas para os 
times e controlá-los?
5. Como suportar os indivíduos provendo a sua formação, 
já que eles não foram contratados para trabalhar dentro 
do método ágil de organização e gestão.
VERIFICAÇÃO DE LEITURA
1. Dentre as afirmativas a seguir, qual delas se baseia em 
um valor do Manifesto Ágil? 
a. A documentação e manuais não devem ser pesados.
b. As reuniões diárias, realizadas de pé, devem durar 15 
minutos ou menos.
2020 
c. Garantir que o software esteja funcionando é o 
melhor caminho para mitigar os riscos.
d. Seja receptivo a mudanças nos requisitos, mesmo já 
avançado no desenvolvimento.
e. As interações entre os indivíduos envolvidos no 
projeto podem provocar demoras e atrasos. Ao 
contrário do contato com o cliente, que é sempre 
bem-vindo.
2. Assinale a afirmativa correta: 
a. O Balanced Scorecard sempre tem 4 perspectivas.
b. A ideia básica no Balanced Scorecard é criar uma 
estratégia corporativa.
c. Uma ideia importante que o BSC traz é aumentar o 
número de KPIs utilizados para gerir o negócio, não se 
limitando apenas aos indicadores financeiros. 
d. Eventualmente as empresas utilizam sinalizadores 
de tráfego vermelho/verde para priorizar os 
planos de ação.
e. O BSC não pode ser usado em conjunto com sistemas 
de controle de orçamento.
3. Quando um especialista em métodos ágeis diz que a arte 
de dizer não é mais uma das mais importantes, ele se 
refere à: 
2121 21
a. Necessidade de limitar o escopo de um projeto.
b. Estrutura de gestão que busca manter um controle 
estrito da equipe de desenvolvimento.
c. Evitar o desenvolvimento de funcionalidades 
desnecessárias.
d. Natural necessidade que manter o desenvolvimento 
restrito, evitando extrapolar o orçamento inicial.
e. O desejo de manter a carga de trabalho equilibrada 
e constante ao longo de todo o desenvolvimento 
do projeto.
Referências Bibliográficas
ÁGIL. Dicionário online Dicio, 31 jan. 2018. Disponível em: https://www.dicio.com.br/
agil/. Acesso em: 31 jan. 2018.
BENTLEY, Colin. Prince2: a practical handbook. Routledge, 2012.
FOWLER, Martin; HIGHSMITH, Jim. The agile manifesto. Software Development, v. 9, 
n. 8, p. 28-35, 2001.
CORRAL, Antonio J. Mora; URIETA, Carlos Vivas; MONOGRAFIA, A. E. C. A. Nuevas 
herramientas de gestión pública: el cuadro de mando integral. Asociación Española 
de Contabilidad y Administración de Empresas, 2001.
KAPLAN, Robert S.; NORTON, David P. Using the balanced scorecard as a strategic 
management system. 1996.
KAPLAN, Robert S.; NORTON, David P. Having trouble with your strategy? Then map it. 
Focusing Your Organization on Strategy—with the Balanced Scorecard, v. 49, 2000.
LAUTERBORN, Bob. New marketing litany. Advertising age, v. 61, n. 41, p. 26-26, 1990.
LOBO, Carlos Eduardo d’Araujo Vilaça. Aplicação do projeto axiomático para o 
desenvolvimento de sistemas de medição de desempenho para manufatura. 2003. 
149p. Tese (doutorado) - Universidade Estadual de Campinas, Faculdade de 
Engenharia Mecânica, Campinas, SP.
https://www.dicio.com.br/agil/
https://www.dicio.com.br/agil/
2222 
NONAKA, Ikujiro; TAKEUCHI, Hirotaka. The knowledge creation company: how Japanese 
companies create the dynamics of innovation. Oxford University Press; 1 edition (May 
18, 1995).
PETROSKI, Henry. The evolution of useful things. Vintage, 1994.
ROCHA, Rodrigo. SEM – Sistema de Estratégia Minimalista: como 4 Es podem 
tornar a sua vida mais leve e levar a sua empresa ao sucesso. São Paulo: HSM, 
2016. 184 p.
VARGAS, Ricardo. Manual prático do plano de projeto: utilizando o PMBOK Guide. 
Brasport, 2009.
Gabarito
Questão 1 – Resposta: D
a) A documentação e manuais não devem ser pesados. 
Embora um valor do Manifesto Ágil seja priorizar o funcionamento 
do software em detrimento da documentação extensa, isso não 
significa que esta deva ser pobre.
b) As reuniões diárias, realizadas de pé, devem durar 15 
minutos ou menos.
Embora a afirmativa seja verdadeira, ela não é um valor direto do 
Manifesto Ágil. Esta ideia é sim um desdobramento da valorização 
do indivíduo e as interações dentre estes.
c) Garantir que o software esteja funcionando é o melhor caminho 
para mitigar os riscos.
Garantir que o software que o cliente irá testar esteja funcionando 
corretamente é um valor, mas não porque este mitigue os riscos.
d) Seja receptivo as mudanças nos requisitos, mesmo já avançado 
no desenvolvimento.
Verdadeira.
e) As interações entre os indivíduos envolvidos no projeto podem 
provocar demoras e atrasos. Ao contráriodo contato com o cliente, 
que é sempre bem-vindo.
2323 23
Questão 2 – Resposta: D
a) Falsa. O BSC não precisa ter obrigatoriamente 4 perspectivas. A 
estratégia da companhia deve definir as perspectivas. Entretanto, 
as 4 comumente utilizadas são as mais relevantes na maioria 
dos casos.
b) Falsa. O BSC não cria a estratégia da companhia. Ele suporta a 
sua implementação.
c) Falsa. O BSC não aumenta os KPIs de controle da companhia. 
Muito pelo contrário, ele limita sua quantidade e cada área ou setor 
da empresa passa a focar somente nos KPIs relevantes para eles.
d) Verdadeiro.
e) Falso. Na verdade, o plano orçamentário faz parte da perspectiva 
financeira do BSC.
Questão 3 – Resposta: C
a) Necessidade de limitar o escopo de um projeto. Falsa. Limitar o 
escopo é importante, mas o objetivo é evitar o desenvolvimento de 
funcionalidades desnecessárias.
b) Estrutura de gestão que busca manter um controle estrito da 
equipe de desenvolvimento. Falsa. A visão ágil busca dar maior 
autonomia à equipe de frente do projeto.
c) Verdadeira.
d) Natural necessidade de manter o desenvolvimento restrito, 
evitando extrapolar o orçamento inicial. Falsa. Embora este objetivo 
seja atingido, ele é buscado evitando-se o desenvolvimento de 
funcionalidades desnecessárias.
e) O desejo de manter a carga de trabalho equilibrada e constante 
ao longo de todo o desenvolvimento do projeto. Falsa. Novamente 
este desejo é verdadeiro, mas não está ligado à necessidade de o 
gestor dizer vários “nãos”.
2424 
Scrum, XP e Lean: 
Princípios comuns 
Autor: Carlos Lobo
Objetivos
• Apresentar as metodologias ágeis: Scrum, XP e Lean;
• Discutir suas visões e premissas;
• Explorar os pontos em comum e 
principais diferenças.
2525 25
 1. Introdução
O lean tem sua origem nos projetos de melhoria da eficiência 
desenvolvidos por Taiichi Ohno na fábrica Nagoya da Toyota, na 
segunda metade da década de 1950. Desde o início, o intuito foi 
tornar a operação rápida e flexível, além da alta qualidade (OHNO, 
1988). O Scrum é um método ágil que busca entregar o produto ou 
desenvolvimento com a melhor qualidade possível, em sucessivos tiros 
curtos de trabalho – Sprints. Já o eXtreme Programming – XP, segundo 
ANWER e AFTAB (2017), tem sido o método ágil mais utilizado no mundo 
para o desenvolvimento de software.
Neste tema serão comparados os princípios, características e práticas 
essenciais do Scrum XP e Lean. Incialmente será feita uma revisão das 
três metodologias e, na sequência, a comparação entre elas.
 2. Scrum
O Scrum data de 1993 e foi desenvolvido por Jeff Sutherland, sendo 
hoje o método ágil mais popular. Pode-se ver o Scrum sendo aplicado 
com sucesso em projeto de software, desenvolvimento de produtos e 
serviços, bancos, construção civil, etc.
Não obstante, o Scrum tem sido usado como uma alternativa simples 
e de fácil compreensão ao PMBoK, cuja estrutura é extremamente 
minuciosa e exige o planejamento detalhado antes do início do projeto. 
Pois o Scrum foca no controle do andamento do projeto. Para facilitar, o 
controle é realizado em subconjuntos, denominados sprints. Por meio de 
contínuos sprints, o projeto é desenvolvido de modo incremental. 
Como forma de manter o controle do escopo e objetivo do projeto, o 
Scrum faz uso de backlogs. Assim, existem o product backlog e o sprint 
backlog. O primeiro diz respeito ao produto final do projeto, enquanto 
o segundo aponta o objetivo de cada subconjunto – segmento ou 
sprint, do projeto. Assim, o product backlog se desdobra em diversos 
sprint backlogs.
2626 
Os sprints são definidos a partir dos requisitos funcionais estabelecidos 
com o cliente final, em que cada requisito corresponde a um sprint. E a 
partir do sprint backlog são definidas as atividades que serão atribuídas 
ao scrum team – time de desenvolvimento.
A duração de cada sprint não é pré-definida, por isso esta pode ser maior 
ou menor de acordo com a complexidade das atividades apontadas 
para o sprint. Entretanto, se busca definir sprints que não durem mais 
que quatro semanas. Sprints maiores devem ser divididos em conjuntos 
menores sempre que possível. No seu encerramento é feita uma 
reunião de fechamento, o sprint review meeting.
Ao contrário de outros métodos ágeis, o Scrum funciona com alguma 
hierarquia. Ou seja, existem papeis e funções claramente definidos. E o 
sucesso do Scrum depende da observância destas funções.
Na figura 1 é demonstrada a lógica de operação do Scrum em termos de 
gestão de entrega baseada em subconjuntos. 
Figura 1 | Lógica de Operação do Scrum
Fonte: Adaptada de CRUZ (2017).
 3. XP
Em 1997 foi desenvolvido o eXtreme Programming – XP, que defende a 
excelência do desenvolvimento de sistemas e se baseia em:
2727 27
• Agilidade.
• Economia.
• Qualidade.
Agilidade para entregar rapidamente as encomendas. Economia para 
não consumir mais recursos do que os necessários no desenvolvimento 
do sistema, e qualidade na entrega. Entretanto, o XP se diferencia de 
outros métodos ágeis de desenvolvimento de softwares, pois foca no 
processo em si. Ou seja, o XP parte de um compromisso de entrega 
e de um conjunto de comportamentos – valores, que garantam o 
resultado final.
Resumidamente, estes valores (compromissos) assumidos pelo time 
desenvolvimento do sistema são:
• Simplicidade nas soluções. 
• Comunicação constante. 
• Respeito.
De modo complementar aos valores ou compromissos assumidos pela 
equipe de desenvolvimento, temos as boas práticas de desenvolvimento 
indicadas na visão do XP:
• Comunicação constante com o cliente.
• Uso de metáforas no planejamento e estrutura do projeto.
• Reuniões de planejamento.
• Reuniões diárias de alinhamento.
• Desenvolvimento modular.
• Entregas e testes frequentes.
• Design simples.
• Refatoração (refactoring) ou melhoria contínua.
2828 
Como o próprio nome diz, “eXtreme” indica ações extremas. Assim, o 
resultado disso são as seguintes práticas:
• Já que testar o software, ou mesmo o produto, é fundamental, 
podemos testá-lo continuamente – o tempo todo.
• Fazer revisões do produto também é considerada uma boa 
prática, logo se deve revisá-lo sempre.
• A prática de refatorar o projeto, ou fazer melhorias, é também 
indicada. Então as melhorias devem ser contínuas.
• Os testes finais de integração também são importantes, logo 
devem ser feitos todo o tempo. A integração é um pré-requisito do 
desenvolvimento, devendo ser mantido ao longo deste.
• Como em outras metodologias de projeto, a simplicidade deve 
ser buscada. Então, na XP não basta o sistema funcionar, tem que 
ser simples.
• E por fim, como a interação rápida e curta é desejável, devemos 
fazê-la o mais curta possível.
A figura 2 apresenta de maneira geral as boas práticas do XP em 
funcionamento e os ciclos rápidos de desenvolvimento ao longo de 
todas as etapas.
2929 29
Figura 2 | Diagrama de planejamento e feedback
Fonte: Adaptada de WELLS (2001). 
ASSIMILE
No XP a proposta é controlar as entregas parciais – 
sempre com qualidade e eficiência, através de estórias. E 
estas estórias têm paralelo com os requisitos funcionais 
estabelecidos pelo cliente. 
Na figura 3 é feito o processo de transição do cronograma 
tradicional para o plano dentro da metodologia do XP.
3030 
Figura 3 | Planejamento na XP
Fonte: Adaptada de Wells (2009).
 4. Lean
Como apontado na introdução deste tema, o intuito aqui é explorar 
a visão e os princípios fundamentais do lean para ser possível sua 
comparação com o Scrum e o XP.
Um autor que fez uma análise dos fundamentos do lean – que estão 
muito além da fabricação de automóveis -, foi Steven Spear. 
3131 31
Note que os 5 princípios são usados em conjunto com o mapa de fluxo 
de valor. Estes não serão discutidos aqui. O foco são os fundamentos 
do lean, por isso o discutiremos segundo a visão de Spear. O artigo 
resultado desta pesquisa foi publicado como “Decodificando o DNA da 
Toyota” (SPEAR e BOWEN, 1999). Aqui é citado a Toyota, pois a origem do 
leanremete à montadora japonesa propriamente dita.
4.1 O DNA do Lean
O DNA da Toyota foi publicado pela primeira vez em 1999 por Steven 
Spear (SPEAR e BOWEN, 1999). Nesse artigo ele buscou apresentar o que 
efetivamente guia o pensamento das pessoas na Toyota a produzir as 
soluções que são vistas. Este modelo foi especificamente testado na área 
da saúde, dando origem ao que se conhece por Lean Healthcare (SPEAR e 
KENAGY, 2005) e (SPEAR, 2005).
A figura 4 apresenta o modelo desenvolvido por Steven Spear.
Figura 4 | Valores dos Métodos Ágeis
Fonte: Adaptada de Spear e Bowen (1999).
3232 
A regra 1 do DNA da Toyota diz respeito à atividade realizada. Ela define 
que toda atividade deve ser definida em termos de não só o que fazer e 
como fazer, mas qual deve ser o resultado esperado da atividade. Assim, 
é possível ao próprio indivíduo aferir se o resultado da atividade tem a 
qualidade esperada ou não. O melhor exemplo desta regra é o trabalho 
padronizado preenchido de acordo com estes requisitos.
Já a regra 2 diz respeito à comunicação. Ela prega a comunicação 
direta – sem intermediários, entre processos cliente e fornecedor. E 
estabelece que esta comunicação deve ser binária – sim ou não. O maior 
representante desta regra é o kanban – sistema de cartões usado para 
comunicar a necessidade ou não de reabastecimento.
A regra 3 é contra intuitiva. Ela indica que os fluxos de material e 
informação devem ser únicos – sem alternativas ou bifurcações, sem 
processos em paralelo. Isso simplifica muito a gestão e controle do 
sistema. E mesmo quando um problema ocorre e a regra 1 não é 
atendida, um fluxo de socorro é acionado para suportar e corrigir o 
problema – a cadeia de ajuda.
Por último, a regra 4 – na figura 5 -, estabelece o método científico de 
teste e introdução de melhorias. Fundamentalmente, seguindo o plano 
do PDSA (MOEN, 2009). Assim, através da regra 4, as outras 3 regras são 
melhoradas ao longo do tempo.
3333 33
Figura 5 | Objetivo da Regra 4
Fonte: Elaborada pelo autor.
Note que a Regra 4, diferentemente das 3 regras iniciais, estabelece 
o método científico para o desenvolvimento de melhorias no sistema 
– desenhado com as 3 regras iniciais. Por isso Spear chama a Toyota 
de uma comunidade de cientistas, pois as melhorias são sempre 
desenvolvidas segundo o método científico de experimentação.
A Regra estabelece critério, meta para as melhorias. Como estado ideal, 
o processo deve:
• Operar na velocidade da demanda do cliente - nem mais rápido, 
nem mais devagar.
• Livre de defeitos ou problemas de qualidade.
• Operar em fluxo unitário de trabalho. Ou seja, sem produção em 
lotes ou acúmulos de trabalho ao longo do processo.
• Sem desperdícios ou perdas – menor custo possível.
• Ser ágil e flexível, respondendo prontamente ao cliente e às 
oscilações da demanda.
• E seguro para o time de operação (física e mentalmente).
3434 
 PARA SABER MAIS
Você pode se aprofundar no método científico de 
experimentação em funcionamento na Toyota lendo a 
seção “The Experiments of Toyota Production System”, no 
artigo Decoding the DNA of The Toyota Production System.
 5. Pontos comuns e diferenças entre 
Scrum, XP e Lean
Note que Scrum e XP são declaradamente consideradas metodologias 
ágeis, enquanto o Lean, originário da Toyota e desenhado com propósito 
diverso, tem muitos pontos em comum com o Manifesto Ágil. Quando 
o Lean é aplicado no setor de serviços ou no desenvolvimento de 
produtos, os valores do Lean, especialmente as regras 2 e 3, encontram 
grande paralelo com o XP e Scrum. 
Veja a figura 6 a seguir.
Figura 6 | Paralelo entre Lean, Scrum e XP
Fonte: Elaborada pelo autor.
3535 35
Vários autores argumentam que o Lean pode e deve ser um modelo 
cultural para a empresa. David Mann (2014) argumenta que uma cultura 
de excelência, a cultura lean, somente é atingida através do sistema de 
gestão. As boas práticas de gestão devem reforçar o comportamento 
esperado pelo time. Assim, pode-se transformar boas práticas em 
hábito. E assim moldar uma cultura de excelência. Note como a cultura 
de excelência não pode ser atingida diretamente, muito menos medida. 
Por isso o autor faz a ligação entre o modelo de gestão e a cultura. 
Dentre Lean, XP e Scrum, Lean é a abordagem que mais pode influenciar 
a cultura da empresa.
Já a Scrum tem uma abordagem mais pragmática e voltada para o 
desenvolvimento de produtos e serviços em geral. O Scrum nasceu do 
Manifesto Ágil e rapidamente se tornou uma alternativa adequada ao 
PMBoK, como já foi discutido. Assim, o Scrum é um exemplo claro de 
metodologia de gestão.
A XP, por outro lado, é um representante claro do Manifesto Ágil na 
área de desenvolvimento de software – com certeza o mais utilizado 
atualmente, mas é praticamente sem sentido em outras áreas. Em 
outras palavras, o Scrum é mais adequado ao desenvolvimento de 
produtos e serviços.
TEORIA EM PRÁTICA
Um tradicional fabricante do setor metal mecânico, de 
conjuntos mecânicos feitos sob encomenda e a partir 
de projetos desenvolvidos para a realidade de cada 
cliente (engineer to order), decidiu investir em programa 
de desenvolvimento ágil em sua área de projetos. 
Tradicionalmente, neste setor, e em especial nesta empresa, 
a área de projetos é um diferencial e vantagem competitiva 
da empresa. Entretanto, a diretoria considera que depois 
de conseguir reduzir o prazo de fabricação dos conjuntos, 
chegou o momento de fazer o mesmo na área de projetos. 
3636 
Na fábrica foi aplicado o lean com grande sucesso e impacto 
positivo sobre todos os indicadores de interesse, embora 
a aplicação de lean na fábrica e PCP não tenha sido a 
convencional, dado que se trata de uma indústria típica de 
ETO. Mas isso não quer dizer que o mesmo possa ser feito 
em Projetos. É comum se ouvir comentários anônimos na 
área dizendo que eles não são uma fábrica. São diferentes.
Você foi indicado pelo Diretor responsável pela área de 
Projetos como líder da mudança. E agora precisa decidir 
como conduzir esse processo. A área funciona como 
um banco de projetistas – 60 pessoas que se organizam 
em times para cada projeto que entra na área. A área 
comercial, quando fecha um novo negócio, estabelece um 
líder para atender esse cliente, e este escolhe, segundo suas 
preferências, o time de projetistas que trabalharão com ele 
no atendimento do cliente.
Além de funcionar como um banco de projetistas, a 
área também se organizava por especialidade. Ou seja, 
os projetistas se dedicavam a determinados conjuntos 
mecânicos. Isso, em princípio, foi bom. Gerou um certo 
grau de especialidade, o que permitiu atender melhor 
aos clientes. Entretanto, dedicar os projetistas por 
especialidade gerou gargalos – falta de projetistas em 
algumas especialidades durantes alguns períodos e 
simultaneamente era comum se observar ociosidade em 
outras especialidades. Para piorar o cenário, o pessoal 
da área comercial começou a ter os seus projetistas 
preferidos. Assim era comum acelerar ou freiar projetos 
só para poder estar disponível quando o projeto/
comercial solicitasse.
3737 37
Vale ainda comentar que os projetos costumam levar de 3 
a 6 meses na área de engenharia. E embora os projetistas 
trabalhem para o líder da área comercial, para garantir o 
funcionamento da área ainda existe um gerente de projetos 
e 3 supervisores.
Agora considere as seguintes questões que você precisará 
responder durante a mudança para uma metodologia ágil:
1. Qual abordagem deve ser utilizada? Lean, Scrum ou 
XP? Poderia se pensar em uma abordagem mista? Se 
sim, como?
2. A estrutura hierárquica da futura área de engenharia 
deve repetir a estrutura atual? Por quê? E como 
a estrutura – qualquer que seja, deve operar 
concomitantemente com a área comercial e seu líder 
do projeto?
3. Como conduzir a mudança frente a equipe de projeto, 
dado que muitos projetistas têm mais de 10 anos de 
empresa e são inclusive reconhecidos pelos clientes?
4. Considerando-se uma matriz RACI, quem mereceatenção e cuidado para mitigar o risco de problemas e 
surpresas durante a implementação?
5. É possível usar alguns princípios do XP no plano de 
mudança? Quais e Por quê?
VERIFICAÇÃO DE LEITURA
1. Considerando-se a 4ª Regra do DNA da Toyota, descrita 
por Steven Spear, pode-se afirmar que: 
3838 
a. Envolve o mínimo de etapas possível.
b. Todas as atividades estão claras, óbvias, consistentes 
para o staff e clientes.
c. Toda melhoria se baseia no ciclo do PDSA.
d. Responsabilidade de todos é responsabilidade 
de nenhum.
e. Toda melhoria se baseia na observação direta.
2. Qual das afirmativas a seguir é verdadeira sobre o uso 
da estória no XP? 
a. A estória do cliente é o ponto de partida do XP.
b. A estória não pode ser descrita em mais de 
uma página.
c. Uma estória suscinta representa uma funcionalidade 
apontada pelo cliente. 
d. Cada estória deve representar uma funcionalidade 
completa solicitada pelo cliente.
e. As estórias são escritas pelo cliente.
3. Considerando-se o Scrum, devem fazer parte do backlog 
do produto ou serviço: 
a. Todos os subconjuntos planejados que compõem o 
produto ou serviço completo.
3939 39
b. As atividades pendentes dos sprints anteriores e os 
subconjuntos planejados que compõem o produto ou 
serviço completo.
c. As estórias de cada sprint.
d. O Scrum Master de cada sprint.
e. Todos os subconjuntos planejados que ainda não 
foram desenvolvidos e que compõem o produto ou 
serviço completo.
Referências Bibliográficas
ANWER, Faiza; AFTAB, Shabib. SXP: Simplified Extreme Programing Process 
Model. International Journal of Modern Education and Computer Science, v. 9, n. 6, 
p. 25, 2017.
CRUZ, Fábio. Scrum e PMBOK unidos no Gerenciamento de Projetos. 
Brasport, 2017.
MANN, David. Creating a lean culture: tools to sustain lean conversions. Productivity 
Press, 2014.
MOEN, Ronald. Foundation and History of the PDSA Cycle. In: Asian Network for 
Quality Conference, 2009. p. 18.
OHNO, Taiichi. Toyota production system: beyond large-scale production. crc 
Press, 1988.
SPEAR, Steven J. Fixing health care from the inside, today. Harvard business review, v. 
83, n. 9, p. 78, 2005.
SPEAR, Steven; BOWEN, H. Kent. Decodificando o DNA do Sistema Toyota de 
Produção. Harvard Business Review, p. 97-106, 1999.
SPEAR, Steven J.; KENAGY, John. Deaconess-Glover Hospital (C). Harvard Business 
School, 2005.
WELLS, Don. Extreme Programming: A gentle introduction, 2002. Disponível em: 
www.extremeprogramming.org. Acesso em: 18 mar. 2002.
___________ Extreme Programming: A gentle introduction, 2009. Disponível em: 
www.extremeprogramming.org. Acesso em: 23 fev. 2019. 
4040 
Gabarito
Questão 1 – Resposta: E
a) Envolve o mínimo de etapas possível. 
Verdadeira, mas se refere à 3ª regra.
b) Todas as atividades estão claras, óbvias, consistentes para o staff 
e clientes.
Verdadeira, mas se refere à 1ª regra.
c) Toda melhoria se baseia no ciclo do PDSA.
Não é obrigatório. A regra 4 indica o método científico, que, por 
exemplo, pode se basear no PDSA.
d) Responsabilidade de todos é responsabilidade de nenhum.
Verdadeira, mas se refere à regra 3.
e) Toda melhoria se baseia na observação direta.
Verdadeira. Esse é um princípio forte dentro do lean.
Questão 2 – Resposta: D
a) A estória do cliente é ponto de partida do XP.
Falsa. O ponto de partida do XP são os requisitos funcionais 
apontados pelo cliente.
b) A estória não pode ser descrita em mais de uma página.
Falsa. É desejável e muito recomendado, mas uma estória suscinta 
não é obrigatória.
c) Uma estória suscinta representa uma funcionalidade apontada 
pelo cliente. 
Verdadeira. As estórias suscintas correspondem às estórias.
4141 41
d) Cada estória deve representar uma funcionalidade completa 
solicitada pelo cliente.
Falsa. A estória pode representar um requisito para a 
funcionalidade desejada.
e) As estórias são escritas pelo cliente.
Falsa. As estórias devem ser redigidas pelo líder de projeto na XP.
Questão 3 – Resposta: E
a) Todos os subconjuntos planejados que compõem o produto ou 
serviço completo.
Falso. O backlog de produto indica somente o que resta ser 
desenvolvido do projeto do produto.
b) As atividades pendentes dos sprints anteriores e os subconjuntos 
planejados que compõem o produto ou serviço completo.
Falso. As atividades que ficarem pendentes, atrasadas, de um Sprint, 
não entram no backlog do produto.
c) As estórias de cada Sprint.
Falso. As estórias são criadas ao entrarem em desenvolvimento.
d) Scrum Master de cada sprint.
Falso. O Scrum Master do projeto, ou mesmo do Sprint, não faz parte 
da descrição do backlog do produto.
e) Todos os subconjuntos planejados que ainda não foram 
desenvolvidos e que compõem o produto ou serviço completo.
Verdadeiro.
 
4242 
Análise Comparativa
Autor: Carlos Lobo
Objetivos
• Comparar as principais metodologias ágeis;
• Explorar pontos fortes e fracos das metodologias 
ágeis abordadas;
• Traçar um perfil com recomendações para melhor 
usar das metodologias ágeis propriamente ditas.
4343 43
1. Introdução
A presente abordagem parte do pressuposto que você conhece o 
Manifesto Ágil e, também, os princípios do que se poderia chamar de 
os três mais relevantes representantes do Manifesto: Lean, Scrum e XP. 
Cabe destacar que o XP, e especialmente o Lean, não guardam uma 
ligação de causa-efeito com o Manifesto (BECK, 2001).
Agora, será feita uma análise comparativa de três métodos ágeis de 
gestão, não nos restringindo aos mais representativos. E já cabe reforçar 
que alguns destes métodos nasceram voltados para o desenvolvimento 
de software – dada a origem do Manifesto Ágil, e a sua aplicação em 
outras áreas necessita de revisão e adequação.
Por fim, para entender se há a possibilidade de indicar uma dada 
metodologia de gestão como sendo ágil ou não, será usado o rol de 
critérios indicados abaixo (ABRAHAMSSON et al., 2017):
1. Permitir o desenvolvimento incremental;
2. Ser cooperativo (tanto interno como com o cliente);
3. Adaptativo (admite mudanças em qualquer ponto do 
desenvolvimento); 
4. Ser direto (o método é fácil de ser entendido).
ASSIMILE
Pode ser difícil definir quais metodologias de projeto podem 
ser chamadas de ágeis e quais não. Muitos destes métodos 
foram desenvolvidos antes do Manifesto Ágil (BECK, 
2001). Assim, pode-se sintetizar os métodos ágeis como 
frameworks de trabalho que possibilitam a cooperação com 
o cliente e dentro da equipe de projeto, o desenvolvimento 
e entregas incrementais, possibilitar mudanças a qualquer 
tempo de projeto e, por fim, ser de fácil entendimento.
4444 
 2. Outras Metodologias
Algumas outras metodologias serão exploradas para ampliar o 
escopo de comparação. Embora o objetivo não seja elencar as mais 
importantes, ou fazer uma revisão completa do tema, podemos apontar 
as mais relevantes: Família Crystal de Metodologias, FDD (Feature Driven 
Development ou Desenvolvimento Guiado por Funcionalidades), DSDM 
(Dynamic Systems Development Method ou Método de Desenvolvimento 
de Sistemas Dinâmico).
2.1 Família Crystal de Metodologias 
A família de metodologias Crystal é um conjunto de boas práticas que 
tendem a se ajustar ao projeto em função da sua complexidade e 
impacto financeiro. Segundo o autor Cockburn (2004), o termo “Crystal” 
pretende caracterizar o projeto em duas diferentes dimensões: tamanho 
e criticidade; ainda sob a analogia, admitindo diferentes composições de 
“minerais”, “cores” e “dureza”.
A metodologia busca, por exemplo, simplificar as práticas 
de controle de projetos mais simples, que envolvem equipes 
menores, e cujo impacto financeiro em caso de falha for pequeno 
ou nulo. Assim, à medida que se avança para projetos maiores, 
com equipes maiores e impacto financeiro crescente, as práticas 
buscam ser mais rigorosas.
Veja a figura 1 a seguir. O nível de criticidade do projeto vai de 
confortável (uma falha aqui ainda deixa os envolvidos em situação 
confortável) até Vida ou Morte (falhas simplesmente não poderocorrer). 
Os níveis C, D, E, L vêm dos termos equivalentes em inglês: Comfort, 
Discretionary Money, Essencial Money e Life. E o tamanho do projeto 
– medido pelo tamanho da equipe -, vai de branco (6 pessoas) até 
vermelho (80 pessoas), ou mesmo além. 
4545 45
Figura 1 | Dimensões da Crystal
Fonte: Adaptado de Cockburn (2002).
Analisando-se a Figura 1, observa-se que existem 3 metodologias 
Crystal Clear distintas, e que devem ser aplicadas de acordo com o custo 
potencial da falha. Além disso, de acordo com a quantidade pessoas 
envolvidas no projeto, existem as famílias de metodologias Crystal 
Yellow, Orange e Red. 
De acordo com Abrahamsson et al. (2002), todas as famílias Crystal têm 
padrões para a gestão, produto em desenvolvimento, envolvimento, 
ferramentas, padrões e funções a serem usadas no processo de 
desenvolvimento. Além disso, as famílias Crystal têm alguma flexibilidade 
de uso quanto ao tamanho do time. Assim, a Crystal Clear, por exemplo, 
poderia ser aplicada em projetos E8/D10.
A figura 2 apresenta um ciclo de entrega utilizando-se a 
Crystal Orange.
4646 
Figura 2 | Um Ciclo de Desenvolvimento segundo a Crystal Orange
Fonte: Adaptada de ABRAHAMSSON et al. (2002).
A seguir são elencados os principais elementos que existem na 
família Crystal.
2.1.1 Políticas Padrão
Em termos de políticas predefinida, Cockburn (2002) identifica as 
seguintes características principais na família Crystal de metodologias:
• Entregas incrementais;
• Acompanhamento do projeto através de milestones que 
representem funcionalidades implementadas;
• Envolvimento direto do usuário final;
• Revisão de cada release com dois usuários; 
4747 47
• Teste automatizado das funcionalidades desenvolvidas;
• Workshop de alinhamento do produto e metodologia em cada 
ciclo de desenvolvimento – início e no meio do ciclo.
2.1.2 Produtos em Desenvolvimento
Para o desenvolvimento dos produtos, Cockburn (2002) identifica, dentre 
outras, as características:
• Documentação dos requisitos – Somente para a Crystal Orange;
• Na Crystal Clear o cronograma é fundamentalmente o plano de 
entrega dos releases, enquanto na Crystal Orange um cronograma 
formal é necessário;
• Sequência de releases pré-definida;
• Modelos comuns compartilhados;
• Manual do usuário;
• Testes (Crystal Clear pede a documentação destes testes);
• Migração do código final.
2.1.3 Ferramentas, Padrões e Atividades
Em termos de ferramentas, Abrahamsson et al. (2002) reforça que a 
Crystal Clear requer:
• Compilador;
• Ferramenta de controle de versões e configuração;
• Quadros brancos para substituir a documentação tradicional.
Já na Crystal Orange, as ferramentas mínimas são:
• Ferramentas de programação, controle de prazos, comunicação, 
testes, desenho e medição do desempenho.
4848 
Já em termos de padrões, o Crystal Orange sugere o uso de notação 
padrão, convenções de projeto, padrões de formatação e qualidade 
(Cockburn, 1998).
2.1.4 Práticas 
De acordo com a figura 2, as metodologias Crystal têm um conjunto 
de práticas recomendadas. Dentre outras, seguem as que mais 
se destacam:
• Staging;
• Paralelismo e fluxo;
• Estratégia de diversidade holística.
O staging é o sistema apresentado na figura 2. Implica em planejar cada 
ciclo de implementação – ou incremento, em intervalos de 1 a 3 meses. 
O time deve decidir o que consegue entregar a cada ciclo.
O paralelismo e fluxo guarda grande semelhança com o Lean. A 
proposta é estabelecer o máximo de atividade de desenvolvimento 
em paralelo que sejam possíveis manter. Para isso são importantes 
o monitoramento e o acompanhamento dos planos de trabalho, a 
estabilidade e a sincronização (Cockburn, 1998).
2.2 FDD – Feature Driven Development 
Criado em Cingapura entre 1997 e 1999 por Peter Coad (Chief Architect), 
Jeff De Luca (Project Manager) e Stephen Palmer (Development Manager), 
o FDD é um método ágil que reúne as melhores práticas de outros 
métodos, com técnicas orientadas por modelos que se adaptam às 
maiores equipes e projetos (Palmer, 2001).
A sua orientação básica é focar nas funcionalidades, o que permite à 
equipe de projeto realizar um planejamento incremental, isto é, por 
4949 49
fases. Esse tipo de atuação ajuda a dar agilidade ao desenvolvimento 
de soluções em ambientes de extrema incerteza, em que as mudanças 
são inevitáveis.
Na figura 3 é apresentado o processo fundamental de 5 etapas de 
desenvolvimento de projetos com o FDD. A programação por FDD 
começa com a visão global do negócio, já que esse método considera o 
todo mais importante que cada uma das partes separadamente. Passa-
se, então, para o detalhamento do produto com a subdivisão por áreas a 
serem modeladas, culminando na descrição de cada funcionalidade.
Por se tratar de uma ferramenta com foco no desenvolvimento, assim 
como o XP, o FDD pode ser perfeitamente integrado ao Scrum.
Figura 3 | Os 5 Processos da FDD
Fonte: Adaptada de Plamer e Felsing (2002).
Assim como todos os demais métodos ágeis, o FDD também recomenda 
as melhores práticas elencadas abaixo, que visam criar o ambiente 
propício para o desenvolvimento de projetos:
• Desenvolvimento por funcionalidades;
• Um único programador é responsável pela funcionalidade 
desenvolvida;
• Controle de qualidade em todas as fases do projeto;
• Gerenciamento de configurações;
• Integração contínua das funcionalidades;
• Planejamento incremental;
• Teste de software.
5050 
De modo similar ao modelo esquemático apresentado para as 
metodologias Crystal, pode-se apresentar o FDD. Veja a figura 4.
Figura 4 | Os Processos da FDD de Projetar e 
Construir o Produto por Funcionalidade
Fonte: Adaptado de de ABRAHAMSSON et al. (2002).
2.3 DSDM
O DSDM - Dynamic System Development Model, é um dos métodos 
ágeis mais antigos, de 1994, empregados não só no desenvolvimento 
de projetos como no meio tecnológico. Um tanto diverso dos demais 
métodos ágeis, ele é o framework mais usado quando se bsuca uma 
estrtura para desenvolvimento rápido de aplicação (RAD – Rapid 
Development Development) (Stapleton, 1997) 
O DSDM é um framework sem fins lucrativos e não-proprietário para 
desenvolvimento RAD, mantido pelo consórcio DSM. E o princípio 
5151 51
fundamental do DSDM é de, ao invés de fixar as funcionalidades do 
produto e depois ajustar o prazo e os recursos para executá-lo, é 
preferível fixar o prazo e recursos, e depois ajustar a quantidade de 
funcionalidades possível. 
Entre as suas melhores práticas estão o desenvolvimento incremental 
e iterativo, a colaboração entre cliente e equipe, além da integração 
de funcionalidades. Vale ressaltar que o DSDM diverge dos demais 
métodos ágeis tanto em sua estrutura, que é composta por processos 
interligados de modelagem, concepção, construção e implementação, 
como na gestão do tempo, que não é flexível, até permitindo que 
as funcionalidades mudem, mas desde que os prazos de execução 
continuem os mesmos.
Na figura 5 é apresentado o diagrama de processo do DSDM.
Figura 5 | Diagrama de Processo do DSDM
Fonte: Adaptada de STAPLETON (1997).
5252 
2.4 Conclusão
Existem muitas outras metodologias que se encaixam dentro dos 
princípios básicos dos métodos ágeis: Desenvolvimento incremental e 
colaborativo, ser adaptativo e direto.
 PARA SABER MAIS
Você pode se aprofundar nos diversos métodos ágeis 
consultando o artigo Agile software development methods: 
Review and analysis, de Abrahamsson, Pekka et al. (2017). 
Neste artigo, os autores fazer revisão dos métodos ágeis em 
busca das características comuns que os definem. E depois 
fazem uma revisão dos principais métodos. 
Um destes métodos é o RUP – Rational Unified Process. 
Método similiar as metodologias Crystal e a FDD.
 3. Análise Comparativa
Nesta seção é feita uma análise comparativa dos diversos métodos ágeis 
abordados aqui. Tenha em vista que esta é uma análise qualitativa, e de 
que todos atendem às principais necessidades buscadas nos métodos 
ágeis: simplicidade na gestão e desenvolvimento,e parceira com o 
cliente final.
5353 53
Tabela 1 | Análise Comparativa
Fonte: Elaborada pelo autor.
TEORIA EM PRÁTICA
Considere-se gestor de projetos da Green Future. A Green é 
uma startup do setor de mobilidade urbana. Sua proposta 
de valor é oferecer transporte simples e barato para os 
habitantes das grandes cidades do mundo. Para isso ela 
está desenvolvendo um projeto de aluguel de lambretas 
diretamente pela web. Assim, os usuários localizam as 
lambretas da Green através de um app, fazem o pagamento 
via app com o cartão de crédito e liberam a mesma para 
seu uso. Ao final, o usuário “fecha” a corrida e estaciona em 
local adequado. 
5454 
Para que o projeto seja lançado estão sendo desenvolvidos 
dois projetos simultaneamente. O primeiro é o projeto do 
app. Já o segundo é o projeto da própria lambreta, pois se 
busca um custo reduzido para mesma, e por outro lado um 
design inovador – e que limite seu uso em caso de furto.
Você foi indicado pelo Diretor responsável pela área de 
Projetos como líder dos mesmos. E como especialista 
cabe a você escolher as metodologias adequadas para a 
gestão e desenvolvimento dos projetos. Então seu desafio 
é apresentar para o Diretor responsável como serão 
estruturados e geridos os dois projetos. O Diretor marcou 
uma apresentação formal com ele e os demais diretores 
para que você apresente este plano.
Algumas informações importantes sobre o projeto e as 
equipes de desenvolvimento:
• O desenvolvimento do app será feito por uma pequena 
equipe interna, que futuramente fará as melhorias e 
manutenções no aplicativo, e por diferentes equipes 
geograficamente dispersas ao redor mundo. Estas 
equipes foram contratadas de acordo com suas 
competências específicas. Isso foi bom, porque garante 
a expertise, mas pode dificultar a integração final. E como 
dividir o trabalho pode não ser simples.
• Já o projeto da lambreta deve ser feito na Itália. 
Novamente na escolha pesou a expertise da empresa 
terceira. A Itália é conhecida pelas grandes empresas de 
design. A dificuldade é a distância do Brasil até lá. Além 
da comunicação e fuso horário.
Agora considere as seguintes questões que você precisará 
responder ao preparar o plano para apresentar na reunião 
de diretoria:
5555 55
1. Qual abordagem deve ser utilizada? A mesma para 
os dois projetos ou frameworks distintos? Qual será a 
sua proposta?
2. Devo fazer uma apresentação detalhada e rica nos 
pormenores da organização dos dois projetos ou ser 
mais conciso como apregoa os planos desenvolvidos 
com o Lean?
3. Como equacionar e gerir equipes geograficamente 
separadas?
4. Como garantir que a integração das partes? Como reter 
o conhecimento?
5. Quais são os riscos envolvidos? Como se poderia 
mitigar estes riscos
6. Prepare os slides para a reunião.
VERIFICAÇÃO DE LEITURA
1. De que modo se pode traçar um paralelo entre o 1º 
princípio do lean e a abordagem diferenciada da DSDM? 
a. O foco em estabelecer um fluxo contínuo do primeiro 
em paralelo ao pragmatismo da segunda.
b. O conceito de valor para o cliente do primeiro é 
similar à abordagem de projeto e desenvolvimento 
do segundo.
c. Ambas metodologias se baseiam no ciclo PDSA.
5656 
d. O lean parte do princípio de entender o que é 
importante para o cliente e aumentar continuamente 
este valor. E, de modo similar, a abordagem da DSDM 
foca nas funcionalidades acordadas com o cliente.
e. O DSDM buscou no lean o foco no cliente e por isso 
foca nas funcionalidades acordadas e factíveis.
2. Considerando-se a comunicação – verbal e escrita, qual é 
a grande diferença entre FDD e Scrum/XP? 
a. A comunicação com o cliente é priorizada nas três 
metodologias. Entretanto, Scrum e XP também 
priorizam a comunicação e interação dentro da 
equipe de desenvolvimento, enquanto a FDD não 
explicita esta prioridade.
b. A FDD segue a orientação de Beck no Manifesto Ágil, 
enquanto XP e Scrum não.
c. A comunicação é tratada de modo formal na 
FDD, pois esta prevê projetos de grande porte, 
que efetivamente necessitam de uma ferramenta 
estruturada para isso. Já Scrum e XP não priorizam a 
comunicação, pois os membros do time de projeto 
devem, obrigatoriamente, estar próximos fisicamente.
d. Como Scrum é mais focado na gestão do projeto e 
XP e FDD são voltadas para o desenvolvimento do 
produto, a comunicação é melhor desenvolvida e 
tratada no primeiro.
e. No Scrum e na XP a documentação é importante, mas 
não se dá uma grande ênfase a ela. Já a FDD acredita 
que a documentação deve ser desenvolvida com 
critério e revista regularmente.
5757 57
3. Como Scrum e Lean se opõem à XP, FDD e DSDM?
a. Os princípios do Scrum e Lean são aplicáveis ao 
desenvolvimento de projetos de produtos ou 
serviços, enquanto as demais somente se usam no 
desenvolvimento de software.
b. Scrum e Lean são claramente métodos de gestão, 
enquanto as demais são metodologias de 
desenvolvimento.
c. Scrum e Lean são derivados, inspirados no Manifeito 
Ágil de Beck, enquanto o segundo grupo é anterior ao 
Manifesto.
d. Lean e Scrum não têm uma estrutura clara de papéis e 
responsabilidades, enquanto as demais, sim.
e. Scrum e Lean podem ser combinados em um modelo 
de aplicação misto. Já a FDD, XP e DSDM, não. 
Entretanto, é impossível combinar metodologias do 
primeiro com as do segundo.
Referências Bibliográficas
ABRAHAMSSON, Pekka et al. Agile software development methods: Review and 
analysis. arXiv preprint arXiv:1709.08439, 2017.
ANWER, Faiza; AFTAB, Shabib. SXP: Simplified Extreme Programing Process 
Model. International Journal of Modern Education and Computer Science, v. 9, n. 6, 
p. 25, 2017.
BECK, Kent et al. The agile manifesto. 2001.
COCKBURN, A. Surviving Object-Oriented Projects. 1998.
_____________. Agile software development joins the” would-be” crowd. Cutter IT Journal, 
v. 15, n. 1, p. 6-12, 2002.
5858 
_____________. Crystal clear: a human-powered methodology for small teams. Pearson 
Education, 2004.
STAPLETON, Jennifer. DSDM, dynamic systems development method: the method in 
practice. Cambridge University Press, 1997.
Gabarito
Questão 1 – Resposta: B
a) O foco em estabelecer um fluxo contínuo do primeiro, em 
paralelo ao pragmatismo da segunda. 
O foco em fluxo do lean se refere ao 3º princípio. E este não guarda 
paralelo com o pragmatismo do DSDM.
b) O conceito de valor para o cliente do primeiro é similar à 
abordagem de projeto e desenvolvimento do segundo.
Verdadeiro, pois no DSDM a gestão e desenvolvimento do produto 
se dá pelas funcionalidades acordadas com o cliente.
c) Ambas metodologias se baseiam no ciclo PDSA.
Errado.
d) O lean parte do princípio de entender o que é importante para o 
cliente e aumentar continuamente este valor. E, de modo similar, 
a abordagem da DSDM foca nas funcionalidades acordadas com 
o cliente.
As descrições de ambos, Lean e DSDM, são verdadeiras. Entretanto, 
não existe um paralelo evidente.
e) O DSDM buscou no lean o foco no cliente e por isso foca nas 
funcionalidades acordadas e factíveis.
Errado.
5959 59
Questão 2 – Resposta: E
a) A comunicação com o cliente é priorizada nas três metodologias. 
Entretanto, Scrum e XP também priorizam a comunicação e 
interação dentro da equipe de desenvolvimento, enquanto a FDD 
não explicita esta prioridade.
Falsa. A FDD também indica a integração interna.
b) A FDD segue a orientação de Beck no Manifesto Ágil, enquanto 
XP e Scrum não.
Falsa. Na verdade, é justamente o contrário.
c) A comunicação é tratada de modo formal na FDD, pois esta 
prevê projetos de grande porte, que efetivamente necessitam de 
uma ferramenta estruturada para isso. Já Scrum e XP não priorizam 
a comunicação, pois os membros do time de projeto devem, 
obrigatoriamente, estar próximos fisicamente. 
Embora as afirmativas sejam verdadeiras, a razão para uma 
comunicação não estruturada no Scrum/XP é o fato de se priorizar a 
interação entre os indivíduos.
d) Como Scrum é mais focado na gestão do projeto e XP e FDD são 
voltadas para o desenvolvimentodo produto, a comunicação é 
melhor desenvolvida e tratada no primeiro.
Embora seja verdade, a conclusão sobre a comunicação 
está errada.
e) No Scrum e na XP a documentação é importante, mas não se dá 
uma grande ênfase a ela. Já a FDD acredita que a documentação 
deve ser desenvolvida com critério e revista regularmente.
Verdadeira.
6060 
Questão 3 – Resposta: B
a) Os princípios do Scrum e Lean são aplicáveis ao desenvolvimento 
de projetos de produtos ou serviços, enquanto as demais somente 
se usam no desenvolvimento de software.
Falso. Os princípios da XP, FDD e DSDM são aplicáveis em outros 
ambientes.
b) Scrum e Lean são claramente métodos de gestão, enquanto as 
demais são metodologias de desenvolvimento.
Verdadeiro.
c) Scrum e Lean são derivados, inspirados no Manifesto Ágil de Beck, 
enquanto o segundo grupo é anterior ao Manifesto.
Falso.
d) Lean e Scrum não têm uma estrutura clara de papéis e 
responsabilidades, enquanto as demais, sim.
 Falso. Na verdade, somente o Lean não traz consigo uma 
recomendação clara de organização.
e) Scrum e Lean podem ser combinados em um modelo de 
aplicação misto. Já a FDD, XP e DSDM, não. Entretanto, é impossível 
combinar metodologias do primeiro com as do segundo.
Falso. As combinações das metodologias do primeiro grupo com as 
do segundo são possíveis.
6161 61
Balanceando Agilidade e 
Disciplina
Autor: Carlos Lobo
Objetivos
• Entender o tradeoff existente entre controle e 
agilidade;
• Analisar os riscos intrínsecos aos métodos ágeis;
• Circunscrever a gestão de riscos na gestão de 
projetos, sob a ótica das metodologias ágeis;
• Discutir como mitigar ou quando aceitar o risco 
dentro da realidade de negócios. 
6262 
 1. Introdução
Segundo o dicionário Oxford (2018), a palavra de língua inglesa Tradeoff 
indica o equilíbrio alcançado entre dois diferentes recursos desejáveis, 
mas ao mesmo tempo incompatíveis. À título de ilustração, na área 
econômica a expressão tradeoff pode indicar a troca de um ativo 
por outro.
Ou seja, podem existir cenários onde seja muito difícil ou mesmo 
impossível maximizar duas variáveis dependentes, simultaneamente. 
Por exemplo, é sabido que a perda com alimentos perecíveis em 
supermercados é alta. Na área de hortifrúti, por exemplo, ela costuma 
ser especialmente alta. Neste caso, quanto maior for o volume total 
vendido, menor a perda – que não acompanha as vendas de forma 
linear. Por outro lado, se o supermercado reduzir o estoque de hortifrúti, 
poderá perder vendas e, por outro lado, a perda será muito reduzida. 
Na gestão de projetos existe um tradeoff evidente entre disciplina ou 
controle do risco, e agilidade. Como disse Aristóteles, a virtude está no 
meio. Ou seja, é preciso exercitar o balanceamento entre as vantagens 
e desvantagens – notadamente, o risco associado à falta de disciplina, 
das metodologias ágeis, e fazer o melhor uso delas de acordo com 
cada caso ou empresa.
2. Risco
O termo risco é aplicado sem demérito às mais diversas áreas de 
atuação do homem: Medicina, Operações, Projetos, Ambiental, Lazer, 
etc. Aqui o foco será o risco financeiro, consequência da não entrega no 
prazo de um projeto em desenvolvimento.
Comumente, acredita-se, empiricamente, que a gestão de risco se 
orienta pela total eliminação ou redução da exposição ao risco. 
6363 63
Existe um senso comum de que ao limitarmos ou eliminarmos os riscos, 
estamos agindo corretamente. Somente esse senso comum explica 
as centenas de bilhões de reais aplicados em poupança no Brasil. 
Justificado apenas pela garantia do “risco zero”.
Hoje, as empresas entendem que essa definição é uma limitação 
importante à sua atuação. O risco, se explorado com inteligência, é 
essencial ao sucesso de qualquer empresa. Ou seja, ter 100% de certeza 
e controle de um projeto certamente será mais custoso, eliminará 
qualquer flexibilidade e adaptatividade às demandas do cliente, e os 
benefícios alcançados podem não ser atingidos ou não há uma relação 
de custo/benefício atraente.
Para concluir, considere a inovação. Schumpeter definiu o empresário 
inovador como o responsável por novos produtos para o mercado, 
por meio de combinações mais eficientes dos fatores de produção 
(SARKAR, 2010). O empreendedor, independentemente do porte da 
empresa em que atua, é o agente da inovação e da “destruição criativa”, 
esta entendida como a força propulsora não só do capitalismo como 
também do progresso material. Quase todos os negócios, por mais 
fortes que pareçam em dado momento, acabam declinando e muitas 
vezes desaparecendo, e quase sempre porque não foram capazes de 
inovar. Assim temos um tradeoff entre o lucro, de um lado, e a limitação 
à exposição a certos tipos de riscos, do outro.
O gerenciamento dos riscos dentro de uma organização cabe à alta 
direção ou mesmo ao conselho de administração da mesma. No 
âmbito da gestão do projeto, esta gestão cabe ao líder do projeto. 
Independentemente do método de gestão, ágil ou convencional, o líder 
do projeto deve fazer a gestão do risco.
6464 
2.1 Definição de Risco
O risco é retratado na área financeira como sendo a variância ou o 
desvio em relação a uma média. Ou seja, existe um determinado 
resultado esperado e ocorre um desvio em relação ao mesmo. Na 
área de projetos o conceito de risco está associado à probabilidade 
de insucesso. Seja porque o prazo não foi cumprido, seja porque as 
funcionalidades desejadas pelo cliente não foram implementadas.
De acordo com o PMI (Project Management Institute), no PMBoK (Project 
Management Body of Knowledge), e sabendo que neste texto a questão 
do risco é abordada no contexto do projeto, pode-se então falar de uma 
gestão de risco dentro do escopo da gestão do projeto. 
Nesse sentido, ainda de acordo com Vieira (2003, p. 4): 
Toda gestão de projeto é um gerenciamento de riscos, alegando ainda 
que “o gerenciamento dos riscos é o trabalho principal de uma gestão 
de projetos, baseado na visão em que as técnicas de gestão são também 
técnicas de prevenção de riscos (algumas reduzem o risco de atrasos; 
outras reduzem o risco de estourar o orçamento, etc.). Na prática, os 
gerentes devem começar a identificar os riscos associados aos projetos 
desde a sua fase inicial. 
2.2 Gestão de Riscos no PMBoK
Para se fazer uma análise adequada da gestão de riscos nos projetos 
dentro das metodologias ágeis, será feita uma revisão desse processo 
segundo o PMBoK. Na figura 1 é apresentada a relação entre riscos e o 
impacto destes de acordo com o ciclo de vida do produto. Note que o 
risco está ligado à incerteza. Ou seja, no projeto o risco está ligado ao 
desconhecimento, ou seja, à falta de informações sobre o projeto.
6565 65
Figura 1 | Incertezas versus Impacto do Risco no 
Ciclo de Vida do Produto 
Fonte: Adaptada de Dinsmore e Cabanis-Brewin (2006).
Outras variáveis importantes para serem consideradas na mensuração 
do risco são o próprio cliente – e quanto ele conhece o projeto em 
elaboração, e o tipo de contrato firmado entre as partes –, fornecedor 
e cliente. Este contrato pode ser mais complexo e completo, ou mais 
simplista. A figura 2 ilustra o comportamento destas duas variáveis e seu 
impacto sobre o risco.
Figura 2 | Riscos futuros envolvidos no projeto do produto 
Fonte: Adaptado de Kerzner (2006, p. 336).
6666 
Segundo Scofano et al. (2013), a gestão de riscos busca mitigar as 
incertezas de projeto ao longo do ciclo de vida do projeto de forma 
estruturada. E esta gestão é fundamental para que as empresas 
desenvolvam seus projetos e implementem suas respectivas estratégias 
com os resultados planejados.
O PMBoK (2008) aponta seis processos para o controle e mitigação 
de riscos:
1. Planejamento do gerenciamento de riscos; 
2. Identificação de riscos; 
3. Análise qualitativa de riscos; 
4. Análise quantitativa de riscos; 
5. Planejamento de respostas a riscos; e,
6. Monitoramento de respostas a riscos. 
Naturalmente, como ocorre em qualquer processo, em cada um destes 
processossão necessárias entradas para o seu desenvolvimento, as 
ferramentas e técnicas usados no processamento propriamente dito, e 
as saídas do mesmo.
Na figura 3 é apresentada a gestão de riscos dentro deste modelo.
Figura 3 | Processos da Gestão de Riscos 
Fonte: PMBoK (2008).
6767 67
E será usado o modelo do SIPOC para analisar as recomendações em 
cada um dos processos recomendados – Figura 4. Mais à frente, a 
relação entre gestão de riscos e o modelo SIPOC ficará mais clara.
Figura 4 | SIPOC 
Fonte: Próprio Autor.
2.2.1 Planejar o Gerenciamento de Riscos
O planejamento da gestão dos riscos deve ser realizado ainda no início 
do projeto do produto. Pois nesta etapa é possível alocar recursos 
a tempo de suportar os processos posteriores. A figura 5 mostra os 
principais elementos envolvidos neste processo de planejamento.
Figura 5 | Planejamento do Gerenciamento de Riscos - SIPOC 
Fonte: Adaptada de PMBoK (2008).
6868 
ASSIMILE
A metodologia do PMBoK prevê duas ferramentas muito 
úteis na gestão dos riscos:
• Estrutura Analítica do Projeto (EAP);
• Estrutura Analítica dos Riscos (EAR).
A EAP é a versão condensada do projeto do produto: 
Escopo, cronograma, Recursos e Riscos, dentre outros. 
Já a EAR é focada na causas-raiz do risco, classificando e 
definindo os riscos aos quais o projeto está exposto. Na EAR 
também são discutidos possíveis riscos que podem ocorrer 
e suas respectivas fontes.
2.2.2 Identificar os Riscos
De acordo com o PMBoK (2008), neste segundo processo, 
determinam-se todos os possíveis riscos. Para isso a equipe é 
estimulada a cooperar para a identificação dos possíveis riscos. Este 
processo perdura por todo o projeto até a entrega final, dado que os 
riscos mudam ao longo do desenvolvimento. A figura 6 apresenta o 
SIPOC deste processo.
6969 69
Figura 6 | Identificação de Riscos - SIPOC 
Fonte: Adaptada de PMBoK (2008).
2.2.3 Realizar a análise qualitativa dos Riscos 
Segundo o PMBoK (2008), a análise qualitativa de riscos procura 
mensurar a chance de ocorrência de cada um dos riscos identificados e 
seus impactos. Assim, é possível priorizar ações de contenção de acordo 
com o impacto e probabilidade de cada um dos riscos. Na figura 7 é 
apresentado o SIPOC deste processo.
7070 
Figura 7 | Análise Qualitativa dos Riscos - SIPOC 
Fonte: Adaptada de PMBoK (2008).
2.2.4 Realizar a análise quantitativa dos Riscos
A análise quantitativa de riscos busca mensurar matematicamente 
os riscos para o cumprimento do projeto. Assim se focam somente 
os riscos com impacto substancial. Na figura 8 são apresentadas as 
entradas, processo e output do processo (PMBOK, 2008). 
7171 71
Figura 8 | Análise Quantitativa dos Riscos - SIPOC 
Fonte: PMBoK (2008).
 PARA SABER MAIS
Existe toda uma área de conhecimento voltada para 
mensuração de riscos. Para se aprofundar, sugere-se 
Scofano et al. (2013). O autor aponta três ferramentas para 
mensurar os riscos:
1. VME: Valor Monetário Esperado. Fundamentalmente é 
obtido pela multiplicação entre Probabilidade e Impacto.
2. Árvore de Decisão: Pode-se chegar ao VME através das 
probabilidades dos diferentes cenários, riscos e impactos 
previstos, usando-se uma árvore de decisão.
3. Simulação de Monte Carlo: Modelo de simulação para 
conversão dos riscos e incertezas, assim como impactos 
em potencial, no VME. 
7272 
2.2.5 Planejar as respostas aos Riscos
Segundo Scofano et al. (2013), o resultado deste processo de 
preparação de respostas aos riscos, ilustrado na figura 9, deve ter a:
• Identificação dos envolvidos – áreas ou indivíduos;
• Responsabilidade acordada para resposta ao risco. 
Assim, busca-se que os riscos identificados sejam encaminhados para os 
responsáveis adequados. 
Figura 9 | Planejamento de resposta aos Riscos - SIPOC 
Fonte: PMBoK (2008).
2.2.6 Monitorar e Controlar os Riscos
De acordo com o PMBoK (2008), neste último processo – apresentado 
na figura 10 - é feito o monitoramento e controle dos riscos 
identificados, eventuais riscos residuais e, por último, novos riscos que 
possam surgiram durante o projeto.
Segundo Scofano et al. (2013), o ponto-chave neste processo é a 
comunicação, assim é necessário estabelecer reuniões para revisão. E o 
plano de respostas aos riscos precisa ser monitorado para se certificar 
da sua execução.
7373 73
Figura 10 | Monitoramento e Controle dos Riscos - SIPOC
Fonte: PMBoK (2008).
3. Gestão de Riscos em Ambiente Ágil: 
Balanceando Agilidade e Controle
Como visto na seção 2, é evidente que o Manifesto Ágil e todas as 
metodologias que se balizaram diretamente ou não por ele, mas hoje 
incluídas no mesmo conjunto, não planejam guiar-se pelos processos 
tradicionais de gestão de riscos como os sugeridos no PMBoK. Muito 
pelo contrário, estas metodologias veem no risco uma oportunidade 
de melhor atender o cliente final. De acordo com NYFJORD (2008), e 
apresentado na tabela 1, ao se colocar as metodologias ágeis ao lado 
dos métodos de gestão de riscos comumente utilizados, vê-se que muito 
pouco é utilizado nos métodos ágeis. O que pode ser considerado um 
exagero da gestão tradicional é quase uma ausência nos métodos ágeis. 
7474 
Tabela 1 | Resposta dos Métodos Ágeis à Gestão de Riscos 
Fonte: Adaptada de NYFJORD (2008).
Ainda variando-se o nível de controle do projeto, pode-se chegar na 
figura 11, a seguir. Note que um projeto desenvolvido no menor tempo 
possível – Velocidade Máxima -, embora possa ser desejável, termina com 
um custo maior que o necessário. Enquanto um projeto desenvolvido 
com o mínimo de riscos – Certeza -, termina com um custo superior ao 
mínimo e tem um tempo de duração muito maior que o necessário. Ou 
seja, o excesso de controle acaba sendo contraproducente. Além disso, 
temos os estágios de controle intermediários – Flexibilidade e Vazão 
-, nestes existe um compromisso entre controle e flexibilidade. Assim 
quando se privilegia a adaptabilidade se entra no modelo Flexibilidade, 
cujo custo é ligeiramente maior. Quando, por outro lado, prioriza-se a 
entrega, termina-se no custo mínimo, com um pequeno acréscimo no 
tempo de desenvolvimento.
7575 75
Figura 11 | Tempo versus Custo de acordo com o controle 
Fonte: Elaborada pelo autor.
Como apontado em diversos artigos, não existem modelos “puros” 
de gestão ágil, especialmente quando se trata de projetos de alto 
impacto e escopo complexo. Assim alguns dos processos de gestão 
de risco aqui apresentadas se justificam. Evidentemente que o 
contrário também é verdadeiro. Projetos de pequeno porte realmente 
podem prescindir desta gestão dado que o custo não justifica o 
benefício almejado. Cabe ao gestor do projeto tomar a decisão de 
quanto e como controlar o processo de desenvolvimento do produto 
nas metodologias ágeis.
4. Conclusão
Como discutido ao longo desta aula, embora os métodos ágeis de 
desenvolvimento de projetos sejam muito valiosos e produzam muitos 
resultados em termos de gestão e simplificação desejados, ainda tem 
um gap em termos de gestão de riscos. Algumas das práticas de controle 
usadas no PMBoK poderiam ser adaptadas para os métodos ágeis como 
forma de balancear agilidade e disciplina. Até porque podem garantir 
custos menores de desenvolvimento.
7676 
TEORIA EM PRÁTICA
Uma empresa farmacêutica organiza eventos científicos 
para divulgação de seus produtos entre médicos 
convidados. Algumas vezes estes eventos são congressos 
de 2 ou 3 dias de duração. Em outros casos, são somente 
patrocínio – custo, para que um médico convidado participe 
de um congresso aberto onde será apresentado algum 
trabalho sobre um produto desta empresa farmacêutica.
A empresa organiza ou participa de 300 eventos por ano a 
um custo de 9 Mi US$ anuais. Para isso, ela tem uma equipe 
dedicada para fazer a gestão destes eventos. A equipe hoje 
tem 7 pessoas. Mas a parte logística do evento – passagens, 
translados e hospedagem, é terceirizada para um operador 
logístico de grande porte. Os serviços de organização 
do espaço do evento,recursos de multimídia, serviço de 
alimentação e outros, também é subcontratado via empresa 
de logística. 
Essa área de eventos é responsável pela contratação e 
pagamento aos prestadores de serviço, embora a verba 
pertença à área de negócios que solicitou o evento. A lista 
de médicos convidados para os eventos chega através dos 
representantes da empresa que os visitam regularmente. 
A área de eventos usa um sistema específico – workflow -, 
para aprovar os nomes dos médicos convidados para tais 
eventos. Por exemplo, o médico convidado precisa atuar na 
área específica do congresso. O médico também não pode 
desempenhar nenhuma atividade junto à ANVISA. Ambos os 
exemplos geram problemas com a área de compliance. E isso 
é um problema porque tanto médicos quanto representantes 
eventualmente se esquecem que existe esta restrição.
7777 77
Algumas informações importantes sobre o processo 
como um todo
• Toda comunicação e registro de informações sobre 
convidados e eventos é feita em “powerpoints” e circula 
entre os diversos atores via email.
• A empresa de logística usa um sistema de TI, e a 
farmacêutica outro, para controle dos eventos.
• Considerando-se email e sistemas de TI diferentes para 
controles, checagem e pagamentos que são feitos no 
SAP, são aproximadamente 15 sistemas de TI distintos 
envolvidos de alguma forma no processo. 
• A empresa farmacêutica tem 6 diferentes áreas de 
negócios demandando eventos para esta área. Os 
solicitantes dos eventos – os gerentes das áreas de 
negócio, que somam mais de 30 pessoas diferentes 
- costumam não dar a atenção às informações 
relevantes, como: existe verba para pagar o evento? 
Estou convidando os médicos certos? O local que estou 
pedindo é factível? As datas escolhidas para o evento 
são adequadas? Dentre outras. E focam por exemplo 
no cardápio, na decoração, na temperatura do ar 
condicionado etc.
• As falhas são comuns, e apesar do esforço e orçamento, 
a satisfação da área de negócios com a qualidade dos 
eventos e dos médicos com problemas logísticos e prazos 
é baixíssima. 
Você foi contratado com consultor de metodologias ágeis 
para, junto com o gestor da área de eventos, desenvolver 
um projeto para reestruturar a área e o processo como um 
todo a fim de eliminar as falhas e melhorar a satisfação dos 
clientes internos e externos.
7878 
Agora considere as seguintes questões:
1. Qual abordagem deve ser utilizada? Quais são os riscos 
do projeto?
2. Como desenvolver este projeto? Qual deve ser a equipe?
3. Qual é um plano mínimo de mitigação dos riscos?
4. Qual deve ser a meta deste projeto e como medi-la?
5. Como integrar matricialmente todos os envolvidos no 
processo de gestão de eventos?
6. Como garantir que os stakeholders do projeto sejam 
atendidos?
7. Como simplificar o processo sempre sacrificar as 
precauções com compliance?
8. Como balancear controle e padronização com agilidade 
na organização dos eventos?
VERIFICAÇÃO DE LEITURA
1. Quais são os métodos tradicionais de gestão de risco 
comumente aceitos? 
a. Plano de gestão dos riscos, Identificação de riscos; 
Análise qualitativa de riscos; Análise quantitativa 
de riscos; Planejamento de respostas a riscos; e 
Monitoramento de respostas a riscos.
7979 79
b. Planejamento do gerenciamento de riscos, 
Identificação de riscos; Análise qualitativa de 
riscos; Análise quantitativa de riscos; Planejamento 
de respostas a riscos; e Monitoramento de 
respostas a riscos.
c. Plano de gestão de riscos, Identificação de riscos; 
Análise dos riscos; Planejamento de respostas a 
riscos; e Monitoramento de respostas a riscos.
d. Análise preliminar dos riscos, Identificação de riscos; 
Análise qualitativa de riscos; Análise quantitativa 
de riscos; Planejamento de respostas a riscos; e 
Monitoramento de respostas a riscos.
e. Análise preliminar dos riscos, Identificação de riscos; 
Análise de riscos; Planejamento de respostas a riscos; 
e Monitoramento de respostas a riscos.
2. Quando se consideram as variáveis tempo de 
desenvolvimento dos projetos e o custo do mesmo, o 
que caracteriza um projeto dito “Velocidade Máxima”? 
a. O desenvolvimento de um projeto em Velocidade 
Máxima indica executar o projeto no menor prazo 
possível, o que assegura entregar o projeto no menor 
prazo e custo.
b. O desenvolvimento de projeto do produto em 
Velocidade Máxima indica sacrificar completamente 
as ações de controle para colocar todo o esforço no 
desenvolvimento. Isso assegura o desenvolvimento 
no menor prazo possível e minimiza o custo.
8080 
c. O projeto desenvolvido em velocidade máxima 
resulta na entrega do mesmo no menor tempo 
possível. Sacrificam-se todos os controles de risco 
para focar na entrega do produto propriamente dito. 
Normalmente implica em custos adicionais.
d. O projeto executado em velocidade máxima segue 
estritamente os princípios do Manifesto Ágil. O 
único controle relevante é a entrega do produto. 
Então nenhum controle é feito. Isso reduz esforços 
desnecessários, minimizando os custos e o tempo de 
desenvolvimento.
e. Velocidade máxima significa colocar recursos 
adicionais no desenvolvimento a fim de garantir o 
menor prazo de execução. Normalmente isso gera 
algum custo adicional.
3. Considerando-se a EAP, Estrutura Analítica do Projeto, 
pode-se afirmar que:
a. A EAP só é usada na gestão e controle tradicionais de 
projetos. Nos métodos ágeis não há equivalente.
b. A EAP é essencialmente uma declaração de 
escopo, o que todos os métodos ágeis de alguma 
forma possuem.
c. A EAP é composta do escopo do projeto e da análise 
dos riscos do projeto - EAR.
d. Nos métodos ágeis não existe uma EAP propriamente 
dita, mas existe um equivalente. Entretanto, nem 
todos os métodos ágeis têm na EAP uma análise de 
riscos como esta é conhecida (EAR)..
8181 81
e. A EAP existe, em forma e conteúdo, na gestão 
tradicional de projetos, a EAR somente nos 
métodos ágeis.
Referências Bibliográficas
BECK, Kent et al. The agile manifesto. 2001.
DINSMORE, Paul C.; CABANIS-BREWIN, Jeannette (Ed.). The AMA handbook of project 
management. Amacom Books, 2006.
KERZNER, H. Gestão de Projetos: as melhores práticas (LB Ribeiro, Trad.). 2006.
NYFJORD, Jaana. Towards integrating agile development and risk management. 
2008. Tese de Doutorado. Institutionen för data-och systemvetenskap (tills m KTH).
PROJECT MANAGEMENT INSTITUTE. Um Guia do Conhecimento em 
Gerenciamento de Projetos - Guia PMBOK. 4. ed. Newtown Square, Pennsylvania, 
USA: Project Management Institute, 2008.
RASMUSSON, David. SIPOC picture book: A visual guide to SIPOC/DMAIC relationship. 
Oriel Incorporated, 2006.
SARKAR, Soumodip. Empreendedorismo e inovação. Escolar Editora, 2010.
SCOFANO, C. R. F. et al. Gestão de risco em projetos: análise das etapas 
do PMI-PMBOK (Project Management Institute). In: XI Congresso Online de 
Administração. 2013.
TRADEOFF. Dicionário online do Oxford.
VIEIRA, Marconi. Gerenciamento de projetos de tecnologia da informação. 2. Ed. 
Elsevier Brasil, 2013.
Gabarito
Questão 1 – Resposta: B
a) Plano de gestão dos riscos, Identificação de riscos; Análise 
qualitativa de riscos; Análise quantitativa de riscos; Planejamento de 
respostas a riscos; e Monitoramento de respostas a riscos.
b) Planejamento do gerenciamento de riscos, Identificação 
de riscos; Análise qualitativa de riscos; Análise quantitativa de 
8282 
riscos; Planejamento de respostas a riscos; e Monitoramento de 
respostas a riscos.
c) Plano de gestão de riscos, Identificação de riscos; Análise dos 
riscos; Planejamento de respostas a riscos; e Monitoramento de 
respostas a riscos.
d) Análise preliminar dos riscos, Identificação de riscos; Análise 
qualitativa de riscos; Análise quantitativa de riscos; Planejamento de 
respostas a riscos; e Monitoramento de respostas a riscos.
e) Análise preliminar dos riscos, Identificação de riscos; Análise de 
riscos; Planejamento de respostas a riscos; e Monitoramento de 
respostas a riscos.
Os processos clássicos para a gestãode riscos apontados pelo 
PMBoK são seis:
I. Planejamento do gerenciamento de riscos; 
II. Identificação de riscos; 
III. Análise qualitativa de riscos; 
IV. Análise quantitativa de riscos; 
V. Planejamento de respostas a riscos; e 
VI. Monitoramento de respostas a riscos. 
Questão 2 – Resposta: C
a) O desenvolvimento de um projeto em Velocidade Máxima 
indica executar o projeto no menor prazo possível, o que assegura 
entregar o projeto no menor prazo e custo.
Falso. O custo costuma ser maior.
b) O desenvolvimento de projeto do produto em Velocidade 
Máxima indica sacrificar completamente as ações de controle 
para colocar todo o esforço no desenvolvimento. Isso assegura o 
desenvolvimento no menor prazo possível e minimiza o custo.
8383 83
Falso. O custo costuma ser maior.
c) O projeto desenvolvido em velocidade máxima resulta na entrega 
do mesmo no menor tempo possível. Sacrificam-se todos os 
controles de risco para focar na entrega do produto propriamente 
dito. Normalmente implica em custos adicionais.
Verdadeiro.
d) O projeto executado em velocidade máxima segue estritamente 
os princípios do Manifesto Ágil. O único controle relevante é a 
entrega do produto. Então nenhum controle é feito. Isso reduz 
esforços desnecessários, minimizando os custos e o tempo de 
desenvolvimento.
Falso. O custo se eleva.
e) Velocidade máxima significa colocar recursos adicionais no 
desenvolvimento a fim de garantir o menor prazo de execução. 
Normalmente isso gera algum custo adicional.
Falso. O custo aumenta, mas não obrigatoriamente por se usar 
recurso adicional.
Questão 3 – Resposta: B
a) A EAP só é usada na gestão e controle tradicionais de projetos. 
Nos métodos ágeis não há equivalente.
Falso. Nos métodos ágeis existe alguma declaração de escopo 
como a EAP.
b) A EAP é essencialmente uma declaração de escopo, o que todos 
os métodos ágeis de alguma forma possuem.
Verdadeiro.
c) A EAP é composta do escopo do projeto e da análise dos riscos 
do projeto - EAR.
8484 
Falso. EAP e EAR não são documentos independentes. A EAP é feita 
no início do projeto e a EAR passa por todo o projeto.
d) Nos métodos ágeis não existe uma EAP propriamente dita, mas 
existe um equivalente. Entretanto, nem todos os métodos ágeis têm 
na EAP uma análise de riscos, como esta é conhecida (EAR).
Falso. Nenhum método ágil tem documento similar à EAR.
e) A EAP existe, em forma e conteúdo, na gestão tradicional de 
projetos, a EAR somente nos métodos ágeis.
Falso. A EAR só existe na gestão tradicional de projetos. 
8585 85
Kanban aplicado aos 
Métodos Ágeis
Autor: Carlos Lobo
Objetivos
• Entender o princípio por trás do Kanban;
• Como funciona o Kanban como meio de controle;
• Como usar o Kanban em conjunto com as 
metodologias ágeis;
• Aplicação digital do Kanban. 
8686 
1. Introdução
Nesta aula será abordado o uso do kanban em conjunto com as 
metodologias ágeis. Note que não se trata de uma metodologia em si 
– uma alternativa às metodologias ágeis. O kanban é uma ferramenta. 
E como tal, deve ser utilizada quando os problemas para os quais este 
se aplique estiverem presentes. E aqui, trata-se de controle. O kanban é 
uma excelente ferramenta de controle dos processos.
Fora esta característica – o uso do kanban como mecanismo de controle 
–, seu uso e forma podem ser bastante amplos. Segundo Anderson 
(2010), na maioria das implementações do kanban foi possível se obter 
as seguintes melhorias no processo:
• Controle visual;
• Limitador do WIP (work in process);
• Feedback rápido;
• Política de controle explícita. 
Assim como o Scrum, o uso regular do Kanban é dependente da 
organização do time de trabalho e da liderança em estimular seu uso. 
2. Kanban
O termo kanban, termo japonês, indica quadro de sinalização usado 
para comunicação de ideias e informações. A partir da sua utilização 
pela Toyota, este passou a designar o sistema usado para controlar 
o estoque em processo, a produção ou o estoque de componentes 
comprados (ESPARRAGO, 1988).
Embora o conceito seja muito simples, a implementação é muito 
diversa. Podendo ir de cartões físicos circulando entre áreas ou 
empresas até versões digitais dos mesmos para controlar áreas de 
serviços e desenvolvimento de projetos. E o campo de aplicação deixou 
há muito a indústria automotiva, passou pela área de serviços – até bem 
pouco tempo a gestão de produção de sanduíches no McDonalds era 
feita via kanban - e chegou à gestão de projetos.
8787 87
2.1 Princípio do Kanban
Resgatando os princípios lean, mais especificamente a regra 2 diz: cada 
conexão cliente-fornecedor deve ser direta e deve haver uma maneira 
inequívoca de sim ou não para enviar solicitações e receber respostas 
(SPEAR e BOWEN, 1999). 
O kanban está ligado à 2ª regra. Esta diz respeito à comunicação. Ela 
especifica que a comunicação seja direta, sem intermediários entre 
os processos cliente e fornecedor. E fixa que esta comunicação deve 
ser binária – sim ou não, fez ou não fez. Assim, o maior representante 
desta regra é o kaban – sistema de cartões usado para comunicar a 
necessidade ou não de reabastecimento/ação.
Na figura 1 é mostrado o tipo de comunicação buscado com a segunda 
regra identificada por Spear. Comunicação direta e simples.
Figura 1 | Regra 2 do DNA da Toyota 
Fonte: Adaptada de SPEAR e BOWEN (1999).
PARA SABER MAIS
Para conhecer melhor o DNA da Toyota, leia o artigo de 
Steven Spear em: Decodificando o DNA do Sistema Toyota 
de Produção. Este artigo pode ser encontrado em:
Referência completa: SPEAR, Steven; BOWEN, H. Kent. 
Decoding the DNA of the Toyota Production System. Harvard 
Business Review, set./out. 1999, pp. 96-106.
http://apics-sgv.org/dnlds/20110622%20Toyota-%20DNA%20of%20TPS-Obara.pdf
8888 
O DNA da Toyota foi publicado a primeira vez em 1999 
por Steven Spear (SPEAR; BOWEN, 1999). Neste artigo, os 
autores buscaram apresentar o que efetivamente guiava o 
pensamento das pessoas na Toyota a produzir as soluções 
que são hoje vistas. Este modelo foi especificamente 
testado na área da saúde, dando origem ao que se conhece 
por Lean Healthcare (SPEAR e KENAGY, 2005; SPEAR, 2005).
2.2 Funcionamento do Kanban no Controle da Produção
De acordo com ESPARRAGO (1988), a Toyota acabou desenvolvendo o 
kanban para atender os objetivos de:
• Reduzir WIP;
• Manter o estoque total não maior que alguns dias, ao invés 
de semanas;
• Reduzir custos com estoque alto;
• Melhorar a qualidade.
Com o kanban, a Toyota pôde passar a “observar” os problemas 
acontecerem simplesmente retirando cartões do sistema. Isso permitiu 
a Toyota exercitar o sistema produtivo e tomar as contramedidas 
necessárias para sanar os problemas. Assim, o cartão kanban é, antes 
de tudo, um cartão de autorização. Ou seja, o fluxo de informação 
representado pelos cartões kanban autoriza a produção ou fluxo de 
material a prosseguir.
Para ilustrar o conceito melhor, observe a figura 2. Este era o esquema 
básico do McDonalds quando o modelo de produção era make-to-stock 
– Atualmente o McDonalds opera em um assembly-to-order. Note que o 
atendente do caixa entrega os sanduíches a partir de um supermercado 
– gôndola, de sanduíches. E a gôndola funciona como um quadro kanban 
para a cozinha, que decide o que, quando e quanto produzir, com base 
nas prateleiras, mais ou menos vazias, da gôndola.
8989 89
Figura 2 | Exemplo de sistema kanban de produção 
nas lojas do McDonalds 
Fonte: Elaborado pelo autor.
Ainda sobre a figura 2, pode-se dizer que o exemplo de kanban em 
questão é um kanban de produção. Ele autoriza a produção dos 
sanduíches. Somente a retirada de um destes da gôndola autoriza a 
cozinha a produzir para sua reposição.
Para completar os exemplos de uso do kanban na área de operações, 
cabe comentar sobre o kanban de retirada (withdraw kanban). Como 
exemplo do kanban de retirada será usado o sistema de reposição de 
cervejas nas gôndolas de um supermercado – conforme a figura 3.
Figura 3 | Exemplo de sistema kanban de retiradaem um supermercado. 
Fonte: Elaborada pelo autor.
9090 
Os dois modelos apresentados nas figuras 2 e 3 operam segundo o 
gráfico apresentado na figura 4. O perfil do estoque ao longo do tempo 
forma o dente de serra observado no gráfico. Assim, a posição de 
estoque fica oscilando entre um ponto de mínimo e máximo. O kanban 
faz o controle visual do estoque através do disparo da reposição no 
momento correto.
 Figura 4 | Gráfico da posição de estoque 
e sua representação visual - kanban 
Fonte: Elaborada pelo autor.
 PARA SABER MAIS
Para conhecer com maior profundidade o uso do kaban 
na indústria e serviços, consulte Tardin et al. (2001). Neste 
trabalho se explora o uso do kanban e da gestão visual 
do controle de processos. Assim como são demonstrados 
os cálculos.
Referência completa: TARDIN, Gustavo Guimarães et al. 
O sistema puxado e o nivelamento da produção. 2001.
9191 91
Estes exemplos das figuras 2 e 3 podem ser considerados casos típicos 
do uso do kanban para criar sistemas de reabastecimento ou produção 
puxada. Na seção a seguir será feita uma discussão do sistema kanban 
aplicado à área de serviços.
ASSIMILE
Uma ferramenta importante que o controle do processo 
via quadro kanban possibilita é o nivelamento da produção. 
O conceito de nivelamento da produção, por sua vez, 
indica: produzir todo o mix de produtos em quantidade 
proporcional à demanda, no prazo correto e com o mínimo 
de inventário (Coleman; Vaghefi, 1994). 
O nivelamento da produção associado ao quadro kanban 
é conhecido como Heijunka box. O termo Heijunka significa 
“mudança no horizonte de planejamento”. Neste quadro os 
cartões kanban são colocados em sequência em uma régua 
de tempo, e assim é possível determinar quando o produto 
ficará pronto.
2.3 Kanban na Área de Serviços
Os exemplos e conceitos e exemplos associados ao kanban podem ser 
transpostos para a área de serviços ou o desenvolvimento de projetos – 
área de atuação das metodologias ágeis. Deste modo, o controle visual 
proporcionado pelo kanban suporta de modo bastante complementar as 
metodologias ágeis.
Note que a aplicação tradicional do kanban foi desenvolvida para 
produtos padronizados e representam a quantidade de um determinado 
item. Quando se utiliza o kanban na gestão de projetos não se estará 
controlando a entrega de de uma dada quantidade de itens iguais. 
9292 
O kanban na gestão de projetos é usado para indicar a entrega de uma 
dada quantidade de trabalho.
Esta quantidade de trabalho representada por um cartão kanban 
deve ter uma representação física forte. Na fábrica ou na logística 
esta representação física é dada pela unidade de armazenamento – 
caixa, embalagem ou outro qualquer. Quando se associa o kanban 
às metodologias ágeis, este deve ser utilizado para representar os 
subconjuntos ou itens que as próprias metodologias usam para fazer 
a gestão do projeto através de entregas incrementais e plenamente 
funcionais.
2.4 CONWIP
CONWIP é a abreviação para a expressão “Constant Work-In-Process”. Ou 
seja, é um sistema desenhado para manter a quantidade de trabalho 
em processo constante. Em qualquer sistema onde o fluxo de trabalho 
seja volumoso e a variedade alta, ou seja, muitos projetos distintos 
simultaneamente, o COMWIP evita filas de espera ao longo processo 
excessivamente altas. A figura 6, a seguir, ilustra conceitualmente o 
CONWIP. Ao invés de controlar o fluxo de trabalho em cada etapa, 
como no Kanban, o CONWIP usa um único ponto do fluxo de trabalho 
para controlar a vazão. Este ponto pode ser a saída do processo ou a 
atividade gargalo do fluxo. O sistema empurrado, como já comentado, 
guia-se exclusivamente pela ocupação do próprio recurso, sem se 
orientar pelo sistema como um todo.
9393 93
Figura 6 | Sistemas de Controle de Fluxo: Kanban, CONWIP e Empurrado
 
Fonte: Elaborada pelo autor.
O controle visual baseado no conceito CONWIP apresenta uma 
possibilidade para o controle visual do estoque em processo em dada 
área. Com ele é possível monitorar e limitar o estoque em processo 
(WIP). De outro modo, pode-se observar como a quantidade de cartões 
kanban no quadro de controle servem para controlar o total de estoque – ou 
trabalho em processo (CONWIP). Este quadro também funciona como uma 
heijunka, dado que mostra o sequenciamento do trabalho.
2.5 Controles Visuais
Os controles visuais foram desenvolvidos com o objetivo de 
compartilhar o status do processo junto a todos os envolvidos. Ou seja, o 
controle visual tem o objetivo de monitorar um determinado processo, 
com recursos gráficos de visualização facilitada. 
Nesse sentido, o termo “gestão visual” está aplicado de forma 
equivocada, dado que gestão implica em tomar ações, governar, 
Kanban 
Puxado
CONWIP 
Puxado
Empurrado
9494 
dirigir ou administrar. Ou seja, a gestão é uma atividade muito mais 
ampla e complexa. Mas, evidentemente, a gestão faz uso dos controles 
visuais para tal.
Comumente o quadro kanban aplicado ao desenvolvimento de projetos 
refere-se a um time específico de projeto. E todos os quadros têm alguns 
elementos mínimos comuns:
• O fluxo do processo, usualmente representado por diferentes 
colunas do quadro;
• Itens em desenvolvimento – são os cartões que circulam 
pelo processo/quadro e representam itens, requisitos em 
desenvolvimento, subconjuntos, features ou outro elemento que 
tenha sentido físico;
• O modelo de gestão puxada – os responsáveis por realizar as 
atividades, puxam o próximo item do quadro ao terminarem o 
precedente. O sistema é autogerido e o status do projeto é visível 
para todo o time.
E os benefícios usuais buscados com os controles visuais são:
• Melhora a comunicação dentre os membros do time de projeto;
• Dá foco para o time de projeto;
• Ajuda a identificar desperdícios e gargalos;
• Garante o controle do processo.
A figura 8 apresenta um exemplo de quadro kanban de uma área de 
desenvolvimento de projetos de engenharia. Este quadro permite a 
visualização direta do status de todos os projetos em desenvolvimento. 
Além disso, também se controla a quantidade de trabalho em processo. 
O quadro representa o trabalho de um único engenheiro da área. Cada 
projetista da área tem seu próprio quadro de gestão.
Existem dois tipos de quadros de controle visual: o físico – ou off-line, e 
o quadro digital – ou on-line. Não existe uma recomendação sobre qual 
9595 95
usar. Esta decisão depende das condições. Quadros físicos são mais 
fáceis de desenhar e testar. A implementação pode ser muito rápida. 
Isso estimula a comunicação dentro do time. E mesmo atualmente, 
quando todos estão familiarizados com as ferramentas digitais, o quadro 
e cartão físico estimula o sentido de propriedade e responsabilidade 
pelo processo.
Uma desvantagem é a dificuldade em manter o histórico do ocorrido e 
sua atualização ser manual. Outra dificuldade, bem maior, é como usar 
o quadro físico quando a equipe de projeto não está no mesmo local de 
trabalho. Isso praticamente inviabiliza seu uso.
Já o controle visual via aplicação web – feito em tempo real, é cada vez 
mais robusto, intuitivo e muito produtivo. Uma vantagem importante é 
estar disponível em qualquer lugar, a qualquer momento.
Um ponto forte dos sistemas kanban online possibilidade a coleta de 
dados sobre o processo, o que pode ser de muita ajuda na identificação 
de gargalos, tempo de processo, e lead time, dentre outros.
3. Controles Visuais Digitais
Neste estágio se busca apresentar algumas soluções para 
implementação de quadros kanban digitais (on-line). O objetivo aqui 
não foi ser extensivo ou conclusivo. Apenas foram relacionados os 
mais comumente utilizados. Também se buscou relacionar soluções 
web que funcionem gratuitamente. Por isso foram selecionados o 
Trello e o Asana.
O primeiro sistema de controle visual é o Trello, um dos sistemas mais 
utilizados atualmente. A confiabilidade do sistema é alta e existem 
diversos plug-ins que permitem customizar os quadros e desenvolver 
aplicaçõespersonalizadas. A figura 9 traz um exemplo dele.
9696 
Figura 9 | Exemplo de quadro Kanban usando o Trello 
Fonte: www.trello.com.
Outro sistema muito robusto e simples de ser usado é o Asana. Ele tem 
um sistema de gestão de projetos que permite a visualização em gráfico 
de Gantt, por exemplo. Vide a figura 10.
Figura 10 | Quadro kanban feito no Asana 
Fonte: www.asana.com.
9797 97
4. Kanban como suporte para as 
metodologias ágeis
Ao longo de toda esta aula foi explorado como kanban e metodologias 
ágeis podem se integrar. Em resumo, pode-se apontar algumas práticas 
relevantes que se buscam ao integrar kanban e metodologias ágeis 
(JYOTHI e RAO, 2012):
1. A ideia de limitar o trabalho em andamento (WIP) e a importância 
dada ao fluxo ao do processo;
2. O Product Owner precisa decidir a cadência de trabalho e assim 
regular os itens que entram em desenvolvimento ou devem 
aguardar. Esse controle é feito diretamente no quadro kanban;
3. Reuniões em pé, junto ao quadro kanban e envolvendo líder e 
time, realizadas uma vez por semana para planejamento das 
estórias ou entregas incrementais;
4. O quadro kanban pode ser usado pelo time, ao invés dos quadros 
com as estórias das metodologias ágeis onde ficam os itens em 
desenvolvimento.
5. Conclusão
Como discutido ao longo desta aula, o uso do kanban – digital ou não, 
como sistema de controle no desenvolvimento de projetos pode ser útil, pois:
1. Possibilita um melhor controle do processo de desenvolvimento – 
limitando o WIP e estimulando o fluxo do processo.
2. Estimula a melhoria do processo – pois torna o fluxo visível e 
estimula o kaizen.
9898 
Entretanto, dado a flexibilidade do kanban, é importante customizar sua 
aplicação para efetivamente maximizar todos os benefícios possíveis.
TEORIA EM PRÁTICA
O mercado de fidelidade voltado para a retenção dos 
clientes deixou de ser restrito às companhias áreas. Hoje 
estes programas de fidelidade buscam ser um incentivo 
para recompensar os seus clientes e encorajar a repetição 
de negócios. Com o intuito de reforçar a fidelidade, estes 
programas têm crescido muito.
Focando neste setor, foi criada uma startup chamada 
Fidelity. Seu objetivo é atuar no setor do varejo alimentar, 
embora a Fidelity não atue diretamente no setor. A 
proposta é reunir dentro do mesmo programa de fidelidade 
diferentes redes pequenas e médias de supermercados. 
E poder oferecer para os usuários benefícios em todas 
as empresas associadas, não se limitando a uma única 
rede de supermercados, como seria o normal. Isso é 
bom para o consumidor, que tem acesso a uma rede 
maior, com maiores oportunidades, e excelente para o 
supermercadista, que dá acesso a benefícios para seus 
clientes que não poderiam ser ofertados.
Por fim, a Fidelity oferece para as redes de supermercados 
associadas ao programa, dados e análises bastante 
completas sobre o comportamento do seu cliente regular. 
Isso possibilita o lançamento de promoções e outras 
estratégias de marketing mais bem direcionadas. 
Recentemente a Fidelity tem enfrentado alguns problemas:
9999 99
• Supermercados associados instatisfeitos com o baixo 
volume de sugestões de marketing oferecidos pela 
Fidelity. Além disso, eles também consideram o tempo 
para fornecimento destas informações muito elevado. 
Devido ao lead time elevado, só é possível fazer uma 
campanha de marketing por mês.
• Os consumidores têm recebido ofertas sem sentido para 
eles. Por exemplo, produtos femininos ofertados para 
homens, dentre outros problemas.
• Internamente, a Fidelity tem crescido rapidamente 
em pessoas, mas isso não tem se refletido em um 
atendimento melhor. É comum ver a equipe trabalhando 
muitas horas depois do dia de trabalho para tirar o atraso 
nas campanhas. Mesmo datas especiais, como dia das 
mães e Black Friday, geram confusão e atraso.
A empresa, além das áreas de suporte comumente usadas, 
como RH e Financeiro, tem três áreas críticas: Data Mining, 
Comercial e Marketing.
As áreas ficam fisicamente separadas, até porque a forma 
de trabalho destas áreas é bastante díspar. Data mining 
precisa de silêncio para produzir as análises. Marketing 
promove várias discussões em grupo para estimular a 
criatividade e sinergia. E o comercial é a confusão comum 
em toda área comercial. 
No intuito de sanar estes problemas, que a empresa 
considera naturais dado o acelerado crescimento, você, 
analista de RH, foi encarregado de implementar uma 
metodologia ágil e controle visual via kanban.
100100 
Agora considere as seguintes questões que você precisará 
responder ao preparar junto com o gerente da área de 
eventos para este projeto: 
1. Como envolver áreas tão diferentes em um projeto? 
Essa união deve perdurar ou só existirá durante 
o projeto?
2. Qual abordagem deve ser utilizada? Quais são os riscos 
do projeto?
3. Como desenvolver este projeto? Qual deve 
ser a equipe?
4. Qual deve ser a meta deste projeto e como medi-la?
5. Como integrar matricialmente todos os envolvidos no 
processo de gestão de eventos?
6. Como garantir que os stakeholders do projeto serão 
atendidos?
7. Qual deve ser o croqui do quadro kanban para gerir a 
futura operação?
VERIFICAÇÃO DE LEITURA
1. O uso do kanban reforça as práticas ágeis na 
medida em que: 
a. Ajuda na visualização dos itens em desenvolvimento 
e destes em relação aos demais – priorizando os mais 
importantes ou críticos.
101101 101
b. Garante o balanceamento do volume de trabalho 
para os times de desenvolvimento, evitando 
sobrecarga ou ociosidade pontual.
c. Especialmente útil para fazer o nivelamento 
da demanda.
d. A principal aplicação do kanban é funcionar como um 
controle de pendência (to do list). 
e. O controle visual proporcionado pelo kanban só se 
aplica no desenvolvimento de projetos quando usado 
em conjunto com o Scrum.
2. A análise quantitativa dos dados do funcionamento do 
sistema kanban oferecem informações sobre: 
a. Os tempos de processamento, lead time e ajuda na 
remoção de gargalos.
b. A eficiência do processo, monitorando-a e aumenta-a.
c. A expectativa para o término ou execução de 
atividades ou itens específicos.
d. O kanban permite o controle do estoque em processo 
(work-in-process), os tempos de espera ao longo 
de todo o processo e a maximização da utilização 
do gargalo.
e. Todas as alternativas anteriores.
3. Quando se trata do kanban on-line, pode-se apontar 
como benefícios relevantes para a gestão de 
documentos:
102102 
a. A facilidade de se anexar documentos com os dados 
do projeto ao cartão kanban.
b. Estabelecer times de projeto.
c. Convidar qualquer indivíduo para participar 
do projeto.
d. Compartilhar e colaborar nas atividades pendentes 
em desenvolvimento.
e. Todas as alternativas anteriores.
Referências Bibliográficas
ANDERSON, David J. Kanban: successful evolutionary change for your technology 
business. Blue Hole Press, 2010.
Coleman, B. Jay, and M. Reza Vaghefi. “Heijunka (?): A key to the Toyota production 
system.” Production and inventory management jornal, v. 35, n. 4 (1994): 31.
ESPARRAGO JR, Romeo A. Kanban. Production and Inventory Management Journal, 
v. 29, n. 1, p. 6, 1988.
JYOTHI, Veerapaneni Esther; RAO, K. Nageswara. Effective implementation of agile 
practices-incoordination with lean Kanban. International Journal on Computer 
Science and Engineering, v. 4, n. 1, p. 87, 2012.
SPEAR, Steven J. Fixing health care from the inside, today. Harvard business review, 
v. 83, n. 9, p. 78, 2005.
SPEAR, Steven; BOWEN, H. Kent. Decodificando o DNA do Sistema Toyota de 
Produção. Harvard Business Review, p. 97-106, 1999.
SPEAR, Steven J.; KENAGY, John. Deaconess-Glover Hospital (C). Harvard Business 
School, 2005.
TARDIN, Gustavo Guimarães et al. O sistema puxado e o nivelamento da 
produção. 2001.
103103 103
Gabarito
Questão 1 – Resposta: A
a) Ajuda na visualização dos itens em desenvolvimento e destes 
em relação aos demais, priorizando os mais importantes ou 
críticos. 
Verdadeiro.b) Garante o balanceamento do volume de trabalho para os times 
de desenvolvimento, evitando sobrecarga ou ociosidade pontual.
Parcialmente correto. Somente quando o kanban é usado com o 
heijunka, este ajuda a prever e identificar sobrecargas pontuais. 
c) Especialmente útil para fazer o chamado nivelamento 
da demanda.
Somente quando o kanban é usado em conjunto com o quadro 
heijunka, é possível fazer o nivelamento da demanda.
d) A principal aplicação do kanban é funcionar como um controle 
de pendência (to do list). 
Embora seja verdadeira, a aplicação do kanban traz muitos outros 
benefícios mais importantes.
e) O controle visual proporcionado pelo kanban só se aplica 
no desenvolvimento de projetos quando usado em conjunto 
com o Scrum.
Falso. Praticamente todas as metodologias ágeis comportam e se 
beneficiam do kanban.
Questão 2 – Resposta: C
a) Os tempos de processamento, lead time e ajuda na remoção 
de gargalos.
104104 
Falso. O uso do quadro kanban ajuda na identificação dos tempos 
de processo e do lead time, mas não ajuda na remoção do gargalo – 
salvo que o identifica.
b) A eficiência do processo, monitorando-a e aumenta-a.
Falso. O controle via kanban promove um excelente sistema de 
monitoramento, mas não contribui diretamente para aumentar a 
eficiência dos processos.
c) A expectativa para o término ou execução de atividades ou itens 
específicos.
Verdadeiro.
d) O kanban permite o controle do estoque em processo (work-
in-process), os tempos de espera ao longo de todo o processo e a 
maximização da utilização do gargalo.
O sistema kanban não contribui diretamente para aumentar a 
utilização do recurso gargalo do processo.
e) Todas as alternativas anteriores.
Falso.
Questão 3 – Resposta: A
a) A facilidade de se anexar documentos com os dados do projeto 
ao cartão kanban.
Verdadeiro.
b) Estabelecer times de projeto.
Falso. Não tem relevância para a documentação do projeto, 
embora importante para a gestão do projeto.
c) Convidar qualquer indivíduo para participar do projeto.
Falso. Não tem relevância para a documentação do projeto, 
embora importante para a gestão do projeto.
105105 105
d) Compartilhar e colaborar nas atividades pendentes em 
desenvolvimento.
Falso. Não tem relevância para a documentação do projeto, 
embora importante para a gestão do projeto.
e) Todas as alternativas anteriores.
Falso.
106106 
Pessoas: Empoderamento e 
Energização
Autor: Carlos Lobo
Objetivos
• Discutir a relevância das pessoas em 
qualquer projeto;
• Meios para motivar e gerir equipes de projeto;
• Relembrar a ideia de liderança;
• Exemplificar formas de organização e gestão de 
times de projeto.
107107 107
 1. Introdução
Independente da metodologia ágil, ou mesmo do controle visual usado 
na gestão do projeto, fica muito claro no Manifesto Ágil (BECK, 2001) 
que as pessoas são elemento crítico nestas novas abordagens de gestão. 
Note que na declaração de intenções do Manifesto Ágil está explícita a 
preferência pelos indivíduos e as interações dentre eles, em detrimento 
de uma documentação mais robusta.
Quando se trata de metodologia ágil, a consequência direta da 
necessidade de rapidez e adaptabilidade a um mundo cada vez mais 
turbulento e disruptivo é precisar de pessoas e empresas responsivas. 
(COCKBURN e HIGHSMITH, 2001). Assim, o fator humano no contexto 
das metodologias ágeis não é secundário. Um indivíduo responsivo 
indica uma pessoa com uma postura proativa para tomar para si e 
solucionar um problema. 
Nesta aula serão abordados dois pontos críticos deste cenário: como 
organizar os times de trabalho de forma a garantir-lhes autonomia e 
motivação; e segundo o papel crítico desempenhado pela liderança.
 2. Visão do Indivíduo na Organização
Neste tópico será discutida a organização do trabalho, tema com 
mais de 100 anos de pesquisas, já que na indústria esta questão 
mereceu grande atenção desde os tempos de Ford. De outro modo, 
será discutida a motivação de equipes e indivíduos e, por outro lado, 
o papel desempenhado pela liderança. O estilo de liderança também 
não tem uma formulação única, mas será elencado nas discussões 
aqui empreendidas. 
Alguns indicativos da relevância do indivíduo dentro da organização são 
os modelos que existem. O primeiro deles é o Toyota Way de Liker (2005). 
108108 
Conforme apresentado na figura 1, Liker propôs o modelo dos 4Ps: 
Filosofia, Processo, Pessoas e Parceiros, e, por fim, Solução de Problemas.
A maior inovação trazida pelo modelo dos 4Ps foi sair da visão baseada 
em processo, trazendo 3 novas perspectivas: filosofia de longo prazo, 
pessoas e parceiros, e, também, a solução de problemas.
Figura 1 | Modelo dos 4Ps 
Fonte: LIKER (2005).
Note que este modelo é na verdade uma estratégia completa de 
produção. Esta estratégia baseia-se em uma filosofia de orientar as 
decisões de gestão em uma visão de longo prazo, através das pessoas. 
Nessa estratégia, o lean busca desenvolver pessoas e fornecedores 
com uma visão de longo prazo, fugindo das decisões de curto prazo 
normalmente baseadas somente no custo. 
Outro modelo, voltado para implementação eficaz de estratégias de 
negócio, é discutido no livro “Execução” (BOSSIDY; CHARAN, 2007). 
Neste livro, os autores discutem o que todas as empresas acabam tendo 
em comum: Estratégia, Pessoas e Operações. Entretanto, só algumas 
109109 109
conseguem implementar no prazo e de forma eficaz a sua Estratégia. 
Dado que o projeto de Operações é basicamente conhecido, recai sobre 
as Pessoas o destino da implementação da estratégia, e normalmente o 
sucesso ou insucesso da companhia.
A figura 2 apresenta este modelo. Note que o modelo é tridimensional, 
ou seja, explicita como os processos relacionados às pessoas suportam 
a integração entre Estratégia e Operações. Depois, como a Estratégia 
promove a integração entre Pessoas e Operações, e, por último, como 
Operações promove a ligação entre Pessoas e Estratégia. Na figura 2, 
dado o foco nos indivíduos, limitou-se a apresentação dos processos 
relacionados às Pessoas.
Figura 2 | Modelo Estratégico 
Fonte: BOSSIDY e CHARAN (2007).
Bossidy e Charam ainda advogam que cabe ao líder, e a mais ninguém, 
colocar as pessoas certas em cada uma das funções e lideranças locais. 
Apontam ainda que isso não ocorre normalmente por:
• Falta de conhecimento: Os líderes podem não conhecer 
suficientemente os líderes nomeados por eles para os projetos;
110110 
• Falta de coragem: Os líderes podem não ter a coragem de separar 
os indivíduos com alto desempenho dos pouco eficazes e tomar as 
devidas ações.
• Buscam conforto psicológico: Os líderes podem escolher 
somente indivíduos com os quais eles fiquem confortáveis 
– psicologicamente. Ao invés dos mais capacitados para o 
objetivo desejado.
Aqui, buscou-se reforçar a relevância dos indivíduos nas organizações, 
independentemente das metodologias ágeis. Embora o lean na visão do 
Toyota Way também seja uma metodologia ágil. 
3. Organização do Trabalho
Neste tópico será discutida a motivação de equipes e indivíduos. E por 
outro lado, o papel desempenhado pela liderança. O estilo de liderança 
também não tem uma formulação única, pois depende da situação.
3.1 Motivação e organização de times
No dicionário, “Motivação” significa: ato ou efeito de motivar, de 
despertar o interesse por algo. [Psicologia] Reunião das razões pelas 
quais alguém age de certa forma; processo que dá origem a uma 
ação consciente.
Por muito tempo se tem pesquisado o que motivaria as pessoas a 
serem mais produtivas. Muitos modelos foram desenvolvidos, mas 
ainda não existe um consenso sobre um modelo geral aplicável em 
diferentes cenários. De qualquer modo, existe consenso de que os 
fatores que influenciam a motivação do indivíduo podem ser divididos 
em intrínsecos e extrínsecos.
Fatores intrínsecos são aqueles resultantes da própria atividade 
profissional: as metas e aspirações do indivíduo. Ou seja, satisfação 
111111 111
com o trabalho realizado,possibilidade de crescimento, relações sociais, 
razões espirituais etc. 
Já os fatores extrínsecos são aqueles que dependem do ambiente, ou 
as necessidades básicas do ser humano: salário, espaço de trabalho, 
responsabilidade etc.
A pirâmide de Maslow – apresentada na figura 3, descreve o 
comportamento do ser humano frente ao que o motiva.
Figura 3 | A Pirâmide de Maslow 
 
Fonte: Adaptada de MACLEOD (2007).
Pessoas
Um time de trabalho pode parecer com um grupo ágil, sem sê-lo. A 
diferença, à primeira vista, pode ser tênue. É difícil para um time ágil 
funcionar dentro de uma organização mais rígida, assim como um time 
rígido funcionaria mal em uma organização ágil.
No projeto ágil típico coexistem diferentes stakeholders:
112112 
• Gerente executivos e de negócios;
• Líder de projeto;
• Equipe de projeto;
• Cliente final;
• Dentre outros.
Time
Como visto do Manifesto Ágil, o projeto baseia-se fortemente na 
colaboração e comunicação. Assim, o time é fundamental para o 
bom desempenho e entrega do projeto. A falta de empatia com o 
cliente, ou membros do time que não consigam trabalhar juntos, 
podem comprometer o resultado final do projeto, dado que afetam o 
ambiente de colaboração.
A química do time e o turnover são dois fatores importantes a serem 
considerados em times ágeis. Dado que as metodologias ágeis não 
priorizam a documentação, a alta rotatividade de pessoal pode 
levar à perda de conhecimento crítico para o projeto. Embora seja 
possível promover uma rotação da equipe por todas as atividades em 
desenvolvimento ou áreas, a perda de um indivíduo importante pode 
ser catastrófica. Este é, sem dúvida, um risco a ser avaliado e controlado 
pelo gestor do projeto. A XP – por exemplo, reconhece a necessidade de 
reter o conhecimento desenvolvido ao reter os indivíduos.
Os times ágeis normalmente são autogerenciados e trabalham em 
intensa colaboração, como prega o Manifesto Ágil, como elementos de 
dentro e fora da própria organização. Times autogeridos não significa 
não ter um líder, e estes podem ser formados e desfeitos em diferentes 
configurações, muitas vezes, de acordo com os objetivos
Exemplos
O Spotify é um aplicativo de streaming oriundo da Suécia. A empresa 
possui 1.500 funcionários, todos dedicados ao produto – único, 
113113 113
da empresa. E grande parte destes funcionários participa do 
desenvolvimento e aperfeiçoamento do produto.
Para se organizar, o Spotify dividiu suas equipes em unidades muito 
pequenas. Cada unidade cuida de determinada funcionalidade do 
seu aplicativo, possuindo um PO (Product Owner) próprio, que é o 
responsável por alimentar as equipes com as histórias dos usuários que 
deverão ser desenvolvidas. Cada Squad possui autonomia por escolher, 
desenvolver e implantar em produção alterações no software. 
As Squads no Spotify são agrupadas em tribos, que são áreas de negócio, 
por exemplo, para o aplicativo mobile existe uma tribo de mobile, 
formada por diversas Squads, que possuem domínio sobre determinada 
função do app. Cada tribo possui um líder de tribo, esse líder é 
responsável por garantir o ambiente propício para existência das Squads 
e promover a devida interação entre elas, podendo estipular encontros 
periódicos para que possam compartilhar trabalho e experiências. A 
figura 4 apresenta o modelo implementado.
Figura 4 | Exemplo de Organização de Times na Spotify 
Fonte: Adaptada de KNIBERG e IVARSSON (2012).
114114 
Para fomentar o compartilhamento de ideias, tecnologias e inovação, 
o Spotify criou os Chapters. Estes são formados por profissionais com 
o mesmo escopo de trabalho, por exemplo, desenvolvedores que 
estejam em uma mesma tribo, mas em Squads diferentes. Podem 
possuir reuniões periódicas ou fóruns para compartilhar dúvidas e 
soluções de problemas.
Por fim, as Guilds. Elas são formadas por pessoas-chave que estejam 
espalhadas entre as tribes e squads. Esses grupos possuem um 
coordenador próprio. Naturalmente, pode-se observar que este 
modelo é uma variação da organização matricial.
O lean, oriundo da Toyota, tem seu próprio modelo de organização do 
trabalho. Ele se baseia em times de trabalho capitaneados por um líder. 
Veja o modelo na figura 5.
Figura 5 | Organização em Times de Trabalho de acordo com o Lean 
Fonte: Elaborada pelo autor.
Embora o modelo lean de organização abdique em certo grau da 
autonomia dos times de trabalho, é a existência destes que garantem 
produtividade, qualidade e prazo. Os líderes de time de grupo no 
Lean têm a responsabilidade de realizar as entregas nos prazos pré-
estabelecidos, mas não a autoridade sobre os membros do time. Ou 
115115 115
seja, eles são responsáveis por entregar a produtividade esperada, mas 
sem ascendência hierárquica sobre o time. Na Toyota, a proporção é de, 
em média, 1 líder para cada grupo de 4 indivíduos. Em outras empresas, 
onde o ritmo de produção é mais lento, esta proporção costuma ser 
maior, chegando a 7 ou 8 indivíduos por time. Acima desta quantidade, o 
efeito positivo sobre a produtividade do time começa a decair.
Embora estes exemplos não sejam exaustivos quanto às possibilidades 
de organização do trabalho em times, cabe apresentar um terceiro 
modelo, conforme apresentado na figura 6. 
Figura 6 | Organização de Times em Projetos Complexos 
Fonte: Elaborada pelo autor.
Pense em um projeto grande e complexo, com o envolvimento de 
dezenas de pessoas e vários requisitos funcionais razoavelmente 
independentes. Este modelo, desdobramento de uma organização 
116116 
matricial, pode ser útil. Os projetistas respondem verticalmente para 
suas estruturas hierárquicas de onde são oriundos. Entretanto, durante 
o projeto, estes são alocados para times de projeto responsáveis por 
algum subconjunto do projeto. Uma vez que o projeto do subconjunto 
seja entregue, o time se desfaz e os indivíduos podem ser realocados 
para outros times, com outros objetivos.
ASSIMILE
Não existe uma estrutura organizacional única e que se 
aplique em qualquer empresa e em qualquer ambiente.
Mesmo empresas que adotem estruturas não 
convencionais, podem fazê-lo pontualmente e usando 
soluções combinadas de estrutura.
A maioria, embora não todas, das formas de organização 
são derivadas da organização matricial na sua forma 
original. A estrutura matricial é a mistura, forte ou fraca, das 
estruturas convencionais funcional e por projetos.
3.2 Liderança
Naturalmente, para que os times de trabalho funcionem da maneira 
esperada, depende-se sobremaneira da liderança. Depende do 
líder, no método ágil, dar foco nos fatores humanos do projeto em 
desenvolvimento: parceria, talento, habilidade e comunicação. Estes 
atributos são a preocupação básica de qualquer time ágil de trabalho. O 
desenvolvimento das habilidades individuais é importante, assim cada 
117117 117
indivíduo poderá entregar mais valor, de maneira sinérgica, à equipe, 
com o passar do tempo.
Segundo CORAM e BOHNER (2005), o DSDM - Dynamic System 
Development Model, por exemplo, aponta as diferenças entre gerentes 
tradicionais de projetos e os gerentes ágeis. Uma destas é:
O gestor de projetos tradicional normalmente irá focar em garantir um 
contrato detalhado com os clientes sobre a totalidade do sistema a ser 
entregue, com os custos e cronogramas. No projeto com a DSDM, o 
gerente de projeto está focado em estabelecer uma relação colaborativa 
com os clientes.
Ainda segundo CORAM e BOHNER (2005), o líder de projeto tem duas 
funções-chave: gerenciar o projeto e liderar o time. E segundo, os 
métodos ágeis, os desafios em ambas as funções, são completamente 
distintos dos métodos convencionais. Times ágeis de trabalho contam 
com pessoal experiente e normalmente são responsáveis por grandes 
desafios. Assim, um líder do estilo coach ou mentor é mais efetivo. 
Assim, a liderança se dá basicamente pela colaboração ao invés do 
comando e controle. Isso representa uma mudança cultural, dado que 
este tipo de líder deve compartilharalgumas decisões. Veja a figura 7 
sobre os tipos de liderança possíveis.
118118 
Figura 7 | Liderança Situacional 
 
Fonte: Adaptada de Hersey & Blanchard (1986).
Além das funções do líder serem distintas, os líderes de projeto 
devem ser muito mais envolvidos com o projeto que nos métodos 
convencionais. No SCRUM, o gerente de projeto se reúne com o time 
diariamente. Como visto anteriormente, reuniões curtas e frequentes 
com o time são o usual no time ágil. 
E os gerentes também têm de se envolver mais com a colaboração com 
o cliente, ao invés de focar em definir entregáveis e contratos. 
119119 119
 PARA SABER MAIS
Para conhecer melhor as funções desempenhadas pelo 
líder lean na Toyota, veja:
O Modelo Toyota de Liderança Lean: Como conquistar e manter 
a excelência pelo desenvolvimento de lideranças (LIKER e 
CONVIS, 2013).
Neste livro, os autores defendem a ideia de que uma das 
razões para o sucesso da Toyota está na capacidade dos 
seus líderes conhecerem profundamente as atividades 
e o trabalho em desenvolvimento. E por outro lado, sua 
capacidade de desenvolver, treinar e liderar pessoas. O 
próprio conceito de learning organisation baseia-se no líder 
da Toyota.
Ainda segundo LIKER e CONVIS (2013), existem seis 
características importantes que este líder precisa ter:
I. Disposição e desejo de liderar; 
II. Conhecimento do trabalho;
III. Responsabilidade pelo trabalho;
IV. Habilidade para a melhoria contínua;
V. Habilidade de liderança;
VI. Habilidade de ensinar.
4. Conclusão
Nesta seção foram discutidos três elementos fundamentais que são 
muito impactados pelos métodos ágeis:
120120 
I. Pessoas;
II. Estrutura Organizacional; e
III. Liderança.
Note que o comportamento e talentos esperados das pessoas são 
distintos. O envolvimento e comprometimento esperados são maiores. 
A motivação para estas é maior, embora a responsabilidade também o 
seja. Nesse sentido, o método ágil promove a comunicação e interações 
constantes. O indivíduo deve estar apto para isso.
Concomitantemente, a organização do trabalho também é distinta. 
As formas tradicionais de organização – funcional e projetizada - não 
funcionam. A unidade fundamental da organização passou a ser o time 
de trabalho, mesmo que este se forme e desfaça muitas vezes ao longo 
do tempo, de acordo com as necessidades. O ambiente de mudança 
constante pode não ser confortável para qualquer indivíduo. 
Por fim, o papel-chave desempenhado pela liderança. O líder deve 
comandar menos e operar muito mais como um mentor. Ele tem 
muito mais responsabilidade e muito menos postura autoritária ou 
centralizadora, mesmo porque muitos times são autogeridos. Na 
verdade, se o líder não for capaz ou mesmo não almejar esta liderança, 
usar um método ágil de gestão pode não ser apropriado.
TEORIA EM PRÁTICA
A Schédio, palavra grega para indicar desenho, é uma 
startup da área de design industrial. Ela atende empresas 
de diferentes ramos e áreas. Desde a indústria de 
computadores com projetos de teclados, mouses e fones 
de ouvido para uso profissional, passando por utensílios 
domésticos como lavadoras e fogões de última geração, e 
chegando a veículos automotores de duas e quatro rodas.
121121 121
A Schédio tipicamente nasceu da experiência e talento do 
seu fundador, que começou como o projetista principal da 
empresa, e se expandiu muito. Atualmente são quase duas 
centenas de projetistas. Como em muitas outras startups, o 
talento em projetos do fundador não foi acompanhado do 
talento para a gestão operacional.
Incialmente, para fazer frente às demandas tão diversas, 
a equipe se organizou pelos segmentos dos clientes: 
Automotivo, linha branca, hardware, dentre outros. Essa 
ideia foi boa, trouxe algum benefício da especialização, 
embora tenha gerado alguns momentos de ociosidade 
em algumas equipes. Isso não foi um problema muito 
grande porque o cliente paga por essa ociosidade quando é 
atendido por uma equipe de talento e especializada em sua 
área de negócios.
Para fazer frente às necessidades de organização, os 
líderes de área mais experientes tornaram-se naturalmente 
os supervisores das áreas de projeto. Algumas áreas de 
suporte também foram se formando e crescendo de acordo 
com a demanda: RH, Finanças, etc.
Algumas áreas cresceram demais e entre supervisores e 
projetistas foi necessário colocar um coordenador. Isso 
aconteceu quando o trabalho administrativo da área se 
tornou tão grande que o supervisor praticamente deixou 
suas atividades de projeto.
Além disso, os supervisores começaram a proteger seus 
projetistas e, mesmo quando ociosos, recusavam-se a 
cedê-los para outras áreas com receio de não os receber 
de volta no futuro. Isso cria algum ressentimento entre os 
supervisores.
122122 
Recentemente, a Schédio tem sofrido com a concorrência 
de outras empresas menores que estão ganhando alguns 
clientes antigos dela:
• Alguns clientes gostam dos projetos entregues pela 
Schédio. A qualidade não costuma ser uma queixa 
frequente. Entretanto, custo elevado e prazo longo, 
poucas vezes cumprido, levam os clientes quase ao 
desespero.
• O tempo total desde a colocação do pedido por um 
cliente até sua entrega e aprovação final pode durar 
desde um mês até vários meses em projetos mais 
complexos.
• Nem sempre o melhor projetista, o mais experiente, 
tornava-se um líder eficaz. Isso é especialmente ruim, 
pois a empresa perdia um projetista experiente e 
ganhava um supervisor deficiente. E uma vez feita 
a mudança, as possibilidades de solução são muito 
limitadas.
• As mudanças de escopo do projeto, mesmo depois da 
contratação ou mesmo próximo da entrega final, têm 
sido uma tendência crescente e a Shédio ainda não sabe 
como tratar esta questão. Atender o cliente ou mostrar o 
contrato assinado?
Neste cenário, você foi contratado para estudar, propor e 
implementar uma metodologia ágil que permita a Schédio 
se adaptar a estas dificuldades e manter-se à frente da 
concorrência.
Agora considere as seguintes questões que você precisará 
responder ao preparar uma proposta para a Schédio.
123123 123
1. Qual deve ser a estrutura organizacional futura? Esta 
deve ser perene ou mutável no tempo? Como alocar as 
áreas de suporte para melhorar o serviço?
2. O melhor modo de organização é o baseado na área de 
atuação dos clientes?
3. Como romper as fronteiras das áreas que algumas vezes 
são tratadas como ilhas independentes?
4. O sucesso de um time de projeto é só dele ou 
da empresa?
5. Como escolher o líder para um projeto específico? A 
liderança deve ser permanente ou baseada no projeto 
em desenvolvimento e na expertise de cada projetista?
6. Como atuar para ser mais flexível no atendimento 
ao cliente e garantir custos e principalmente, prazos 
reduzidos?
VERIFICAÇÃO DE LEITURA
1. São exemplos de organização de times de trabalho 
inspirados na organização matricial: 
a. Times de trabalho no Lean e Guilds, Chapters e Tribes.
b. Guilds, Chapters e Tribes como na Spotify, e modelo de 
organização de times baseados em subconjuntos ou 
funcionalidades do produto final.
124124 
c. Somente no modelo da Spotify - Guilds, 
Chapters e Tribes.
d. Somente no modelo de times do Lean. 
e. Nos modelos de times baseados em subconjuntos, ou 
em times semiautônomos como no Lean.
2. As maiores responsabilidades do líder de time no 
método ágil é: 
a. Apontar as atividades de cada membro e 
responsabilizar-se pela produtividade.
b. Responsabilizar-se pela produtividade e fomentar o 
crescimento de cada indivíduo do time.
c. Monitorar e controlar tempos e prazos, assim 
como controlar a produtividade individual de cada 
membro do time.
d. Fomentar a colaboração dentre os membros do time 
e distribuir o trabalho dentre os indivíduos.
e. Todas as alternativas anteriores.
3. Segundo a Pirâmide de Maslow, a ordem das 
necessidades do indivíduo, a sequência correta é:
a. Fisiologia, Segurança, Estima, Realizações 
Pessoais e Social.
b. Fisiologia, Segurança, Estima,Social e 
Realizações Pessoais.
125125 125
c. Segurança, Social, Estima e Realizações Pessoais.
d. Fisiologia, Segurança, Social, Estima e 
Realizações Pessoais.
e. Nenhuma das alternativas anteriores.
Referências Bibliográficas
BECK, Kent et al. The agile manifesto. 2001.
BOSSIDY, Larry; CHARAN, Ram. Execução. Elsevier Brasil, 2004.
COCKBURN, Alistair; HIGHSMITH, Jim. Agile software development: The people 
factor. Computer, n. 11, p. 131-133, 2001.
CORAM, Michael; BOHNER, Shawn. The impact of agile methods on software project 
management. In: 12th IEEE International Conference and Workshops on the 
Engineering of Computer-Based Systems (ECBS’05). IEEE, 2005. p. 363-370.
KNIBERG, Henrik; IVARSSON, Anders. Scaling Agile@ Spotify. online, UCVOF, ucvox. 
files, 2012.
LIKER, Jeffrey K. The toyota way. Esensi, 2005.
LIKER, Jeffrey K.; CONVIS, Gary L. O Modelo Toyota de Liderança Lean: Como 
conquistar e manter a excelência pelo desenvolvimento de lideranças. Bookman 
Editora, 2013.
MCLEOD, Saul. Maslow’s hierarchy of needs. Simply psychology, v. 1, 2007.
Gabarito
Questão 1 – Resposta: B
Guilds, Chapters e Tribes como na Spotify, e modelo de organização 
de times baseados em subconjuntos ou funcionalidades do 
produto final.
Estes modelos originam-se no modelo matricial. Em ambos, o 
indivíduo está ligado a um grupo de trabalho específico, mas 
responde hierarquicamente a um outro líder que se mantém 
constante ao longo do tempo.
126126 
Questão 2 – Resposta: B
Responsabilizar-se pela produtividade e fomentar o crescimento de 
cada indivíduo do time.
No modelo de time ágil, o líder deve responsabilizar-se diretamente 
pelo atendimento dos prazos (ou pela produtividade) e fomentar o 
crescimento de cada membro do seu time.
Questão 3 – Resposta: D
Fisiologia, Segurança, Social, Estima e Realizações Pessoais.
127127 127
Pessoas: Gestão da Mudança
Autor: Carlos Lobo
Objetivos
• Discutir o processo de mudança;
• Entender os riscos envolvidos no processo de 
mudança para um método ágil;
• Como mitigar os riscos envolvidos.
128128 
1. Introdução
Nesta seção será discutida a gestão da mudança de uma organização 
que busque implementar um método ágil de gestão. De outro modo, 
discutiremos a gestão das mudanças que ocorrem ao longo de um 
projeto e como as metodologias ágeis simplificam a adequação de 
escopo, prazos etc.
Mesmo em um mundo em constante e intensa transformação, 
possivelmente na maioria das empresas o que deveria ser simples, 
não é. As mudanças costumam encontrar a resistência das pessoas. 
É importante ressaltar que ninguém gosta de mudanças. Mesmo 
mudanças que pareçam fáceis, podem representar um grande 
desafio, especialmente no tocante às percepções dos indivíduos sobre 
as mudanças. Ou seja, o entendimento das pessoas sobre o que 
está mesmo ocorrendo e, consequentemente, seu comportamento 
frente à mudança. Tal fato sugere que fatores subjetivos impactam na 
aceitação ou rejeição acerca da mudança. Desse modo, normalmente 
se pode inferir o nível de resistência às mudanças pela avaliação da 
cultura organizacional.
2. Cultura Organizacional
Segundo Chiavenato (1999), cultura organizacional é:
[...] o conjunto de hábitos e crenças estabelecidos através de normas, 
valores, atitudes expectativas compartilhados por todos os membros da 
organização. Ela refere-se ao sistema de significados compartilhado por 
todos os membros e que distingue uma organização das demais. Constitui 
o modo institucionalizado de pensar e agir [...]. A essência da cultura 
de uma empresa é expressa de maneira como ela faz seus negócios, a 
maneira como ela trata seus clientes e funcionários, o grau de autonomia 
ou liberdade que existe em suas unidades ou escritórios e o grau de 
José Paulo Fernandes
Realce
129129 129
lealdade expresso por seus funcionários com relação à empresa. A cultura 
organizacional representa as percepções dos dirigentes e funcionários da 
organização e reflete a mentalidade que predomina na organização.
Ou seja, a cultura organizacional não é algo que se possa colocar 
inteiramente em um documento. Também não é totalmente mensurável 
– embora faça parte de muitos planejamentos estratégicos! Mas todo 
novo funcionário em uma empresa qualquer aprende rapidamente ou 
não se adequa e acaba de algum modo deixando a empresa. 
Dito de outra maneira, a cultura é o conjunto de regras informais 
e não documentadas que fazem os indivíduos se comportarem de 
determinado modo. Ela também direciona as ações do dia a dia, 
permitindo que a empresa atinja seus objetivos e metas. 
Desse modo, já se percebe que a mudança da gestão tradicional 
de projetos para um dado método ágil não é trivial. E mesmo após 
as mudanças implementadas, frente às primeiras dificuldades, os 
indivíduos podem retomar as práticas – cultura - anteriores. Isso pode 
ocorrer quando o time se vê frente a uma situação nova e fora de sua 
zona de conforto.
Segundo Chiavenato (1999), a cultura organizacional compõe-se de:
• Artefatos: as coisas concretas que cada indivíduo vê, ouve e sente 
quando se depara com uma organização; 
• Valores compartilhados: são as justificativas aceitas por todos 
os membros, ou seja, os valores relevantes que se tornam 
importantes para as pessoas e que definem as razões pelas 
quais elas o fazem; 
• Pressupostos básicos: são crenças inconscientes, percepções, 
sentimentos e pressuposições dominantes nos quais as pessoas 
acreditam. 
130130 
E cada um destes três elementos podem se apresentar de forma visível 
– tecnologia, estrutura organizacional, títulos, etc., ou de forma invisível – 
padrões de influência e poder, sentimentos, posturas, dentre outros. 
Assim, pode-se resumir a ideia de que a cultura organizacional se forma 
a partir dos valores de cada indivíduo e da interpretação – positiva ou 
negativa, que estes fazem da realidade da empresa. 
Ainda de acordo com Edgar Schein, a cultura é extremamente 
importante e não deve esperar realizar uma mudança circunstancial nela 
dentro de um curto espaço de tempo. Além disso, ele argumenta que 
você não muda a cultura tentando mudá-la diretamente. Ainda, Shook 
(2010) vai além e faz uma proposta para influenciar positivamente a 
cultura, como ilustrado na figura 1.
Figura 1 | Mecanismo de mudança da cultura 
Fonte: SHOOK (2010).
De acordo com Shook (2010) e diversos outros autores, como 
Mann (2014), um modelo mais pragmático de alterar a cultura é 
usar a gestão e controle dos processos para reforçar as posturas 
desejadas e criar hábitos. E a partir destes hábitos influenciar a cultura 
organizacional existente. Ou seja, ao invés de mudar o modo de 
pensar das pessoas para mudar o modo de agir, passa-se a mudar o 
modo de agir para alterar o modo de pensar. A figura 2 ilustra este 
mecanismo em funcionamento.
131131 131
A consequência disso é simples. O sistema de gestão é a ferramenta 
certa para estimular e cobrar os hábitos desejados e indiretamente 
influenciar a cultura organizacional. Mann chega a advogar que o 
sistema de gestão é o elemento que sempre faltou para que empresas 
ocidentais conseguissem emular o modelo Toyota (Lean) de produção, 
obtendo resultados financeiros similares.
Figura 2 | Processo de mudança 
comportamento e cultura
Fonte: Mann (2014).
 PARA SABER MAIS
Para se aprofundar em um exemplo de mudança cultural 
que se tornou um grande exemplo de sucesso, consulte o 
artigo escrito por Shook (2010):
132132 
SHOOK, John. How to change a culture: Lessons from 
NUMMI. MIT Sloan Management Review, v. 51, n. 2, 
p. 63-68, 2010.
Neste artigo é descrito o processo de formação da 
NUMMI, empresa criada em jointventure pela GM e 
Toyota. Foi a primeira experiência com operações da 
Toyota nos US. Fundamentalmente, a GM forneceu as 
instalações e o pessoal, e a Toyota, a gerência da fábrica e 
o modelo de gestão.
3. Resistência a Mudança
Segundo De Resende et al. (2011), a resistência à mudança aparece 
mesmo em companhias que aparentemente estão dispostas amudar. 
E isso ocorre porque, basicamente, as pessoas não querem mudar.
Segundo Cohen e Fink (2003):
As pessoas resistem à mudança quando consideram que suas 
consequências são negativas. Embora as pessoas sejam diferentes em 
termos de sua disposição em antever consequências negativas, e mesmo 
quando suas razões pareçam lógicas ou até equivocadas a quem está de 
fora, as pessoas não resistem automaticamente às mudanças. As pessoas 
resistem às mudanças por alguma razão e a tarefa do gerente é tentar 
identificar essas razões e, quando possível, planejar a mudança de modo a 
reduzir ou eliminar os efeitos negativos e corrigir as percepções errôneas.
Kotter e Schlesinger (apud CHIAVENATO et al, 2005) apontam algumas 
contramedidas para a resistência à mudança:
1. Comunicação e educação: Fazer a prévia comunicação da 
mudança às pessoas para ajudá-las a compreender a lógica e a 
necessidade da mesma.
José Paulo Fernandes
Realce
133133 133
2. Participação e envolvimento: Inserir as pessoas no processo. 
Torná-las parte da mudança.
3. Facilitação e apoio: Facilitar e apoiar às pessoas a se ajustarem à 
mudança mais rapidamente. 
4. Negociação e acordo: Oferecer algo de valor em troca da 
implementação da mudança.
5. Manipulação e cooptação: Buscar influenciar as pessoas.
6. Coerção: Finalmente, a resistência pode ser tratada de forma 
coercitiva por meio da ameaça explícita ou implícita. 
Note que esta lista de contramedidas é de cunho voltado para 
orientação e não garante o sucesso do processo de gestão da 
mudança. A combinação destas contramedidas possivelmente é o 
mais indicado.
A combinação é indicada porque as causas para a resistência podem ser 
lógicas, psicológicas ou sociológicas. O gestor do processo de mudança 
deve estar atento para identificar corretamente as causas para usar a 
contramedida apropriada.
Segundo Silva e Vergara (2003), para que a mudança seja adotada 
como sua, o indivíduo deve se tornar um verdadeiro ator na mudança, 
se não sujeito da mesma. Em suma, é preciso engajar as pessoas 
na mudança. 
Assim, por mais necessária e racional que seja a mudança propriamente 
dita, o gestor não deve ignorar a subjetividade existente na percepção 
dos envolvidos, podendo aparentar até mesmo uma possível falta de 
interesse e consequentemente criando resistência ao novo.
Em resumo, é necessário que os indivíduos possam ser sujeitos da 
mudança e expressarem suas preocupações para que o pensamento 
lógico possa se estabelecer. Só assim a mudança poderá ser efetiva.
134134 
4. Gestão do dia a dia
Como visto, o sistema de gestão é a ferramenta adequada para criar 
hábitos e mudar a cultura organizacional – ou implantar processos 
ágeis de criação. Assim, uma alternativa é usar a gestão do dia a dia no 
suporte à mudança.
A figura 3 apresenta este modelo de gestão proposto por 
Mann (2014).
Figura 3 | Processo de Gestão do dia a dia 
Fonte: Adaptada de Mann (2014).
David Mann sugere 3 reuniões diárias com o objetivo de escalar os 
principais níveis na estrutura da empresa. Estas reuniões – similares 
às indicadas no SCRUM - têm como objetivo discutir e resolver os 
problemas que impediram que se atingisse os objetivos para o 
período – dia - anterior. Estruturalmente, as reuniões seguem o 
esquema da figura 4.
135135 135
Figura 4 | Processo de Gestão do dia a dia 
Fonte: Adaptado de Mann (2014).
ASSIMILE
David Mann sugere pelo menos três reuniões estruturadas 
e encadeadas:
7. A reunião de nível 1 ocorre diariamente. Nela, o 
líder do time discute com os respectivos membros 
o desempenho no dia anterior e, quando possível, 
direciona os problemas. Esta reunião é breve e realizada 
no próprio local de trabalho.
8. No nível 2 ocorre uma reunião entre os líderes 
de time e nível acima – líderes de grupo ou 
coordenadores. Nesta reunião, os principais 
problemas – e em especial os que não foram sanados 
na reunião de nível 1 – são discutidos.
136136 
9. Finalmente, no 3º nível é feita uma reunião entre o 
gerente e os líderes de time.
5. Conclusão
Nesta seção foram discutidas as dificuldades que podem ser esperadas 
no processo de mudança de uma gestão tradicional para o método ágil. 
A resistência à mudança é conhecida e esperada. Assim, é função do 
gestor tomar as contramedidas corretas para de forma proativa, atuar e 
garantir o sucesso da implementação.
Também foi apontado que é impossível atuar diretamente sobre a 
cultura de uma companhia. E o atalho correto é atuar ou estimular 
as posturas e comportamentos desejados até que estes se tornem 
hábitos. Aí sim, a cultura organizacional estará sendo mudada e, 
consequentemente, o uso de métodos ágeis de gestão estarão mais 
próximos de se tornar realidade. 
TEORIA EM PRÁTICA
A Rapport é uma startup especializada em sistemas de TI 
para análise de dados para a elaboração de relatórios com 
indicadores de performance de interesse do usuário. Eles 
oferecem um produto padrão para uso geral e soluções 
customizadas, onde é feita a adaptação para o ERP da 
empresa, assim como a coleta integrada e direta de dados 
da operação do cliente.
A Rapport nasceu e cresceu criando soluções sob 
encomenda. Depois de se tornar famosa pelas soluções 
customizadas, entrou no mercado com um produto padrão 
137137 137
para clientes menores que precisavam de uma solução 
mais simples e de custo reduzido. Essa ideia pareceu boa 
na época. Atualmente, a área de finanças defende que o 
produto seja descontinuado porque o a margem é baixa 
e toda empresa acaba tendo de se envolver do suporte 
e revisões regulares das versões deste produto. Além 
disso, eles argumentam que este produto não faz parte da 
atividade principal da Rapport.
Atualmente, a Rapport tem cerca de 400 engenheiros 
de software envolvidos diretamente no atendimento aos 
clientes para customização e implementação de soluções 
específicas. Além destes, a empresa conta com uma área 
comercial e as áreas de suportes comuns: RH, Finanças, TI, 
Compras, dentre outras.
Os gestores da Rapport nunca pensaram, ou melhor, 
não chegaram a considerar importante como organizar 
o trabalho e motivar as pessoas. Assim, tanto a área 
comercial quanto o desenvolvimento das soluções 
customizadas para os clientes e o produto padronizado 
da Rapport, têm equipes dedicadas. Os engenheiros são 
envolvidos nos projetos de acordo com a necessidade. 
Eles ficam em departamentos que se formaram com o 
crescimento da companhia. Cada departamento é focado 
em uma funcionalidade do sistema. Mesmo o comercial 
não tem alguma segmentação. O indivíduo, ao conhecer a 
necessidade do cliente, decide se deve oferecer a solução 
padrão ou uma customização. Isso foi bom no início. Mas 
eventualmente alguém considera que o comercial ofereça 
uma solução customizada – cujo preço é maior – para um 
cliente que seria bem atendido pela solução padrão. 
138138 
O comercial fez isso pois tende a oferecer soluções de preço 
maior, afinal a comissão que eles recebem é proporcional. 
Por fim, cabe esclarecer que a solução padrão é 
desenvolvida pelos engenheiros de software nos períodos 
de ociosidade. Essa solução pareceu uma boa forma de 
nivelar a carga de trabalho e aproveitar os momentos de 
baixa no mercado.
Estas dificuldades de organização interna levou a Rapport a 
contratar supervisores para cada grupo de 10 engenheiros 
de software. Estes supervisores não têm competências na 
área técnica, sua função é distribuir o trabalho e apurar a 
produtividade de cada engenheiro.
Dado que os custos são elevados e os prazos não atendem 
mais à demanda de mercado, a Rapport decidiu implantar 
a gestão ágil e estabelecer algum tipo de organização 
em times. A preocupação é a resistência. Os engenheiros 
pensam que isso os transformará em algum tipo de 
robô, onde sua liberdade e criação serão restringidas. As 
cobranças sobre eficiência e prazos também não deixam 
as pessoas felizes. Elas não entendem as razões para tanto. 
Pensam tratar-se de perseguição. 
De outro modo, as pessoasem geral ficaram um tanto 
preocupadas quando entrou um MD novo para dirigir a 
empresa depois da entrada de um grupo de investimento 
que, além do aporte de capital necessário para o 
crescimento da empresa, assumiu o controle da mesma.
Neste cenário você foi contratado para estudar, propor e 
implementar uma metodologia ágil que permita a Rapport 
139139 139
se adaptar a estas dificuldades e manter-se à frente da 
concorrência.
Agora como MD da empresa você considera promover uma 
grande mudança na organização. Evidentemente, para 
fazê-la, será preciso mudar a cultura organizacional da 
empresa. Só assim será possível implementar um método 
ágil de gestão e alguma forma de times de trabalho. Embora 
exista alguma resistência às mudanças, como é natural, 
você avalia que a figura do supervisor não é bem-vista pela 
empresa, e consequentemente não está entregando os 
resultados esperados. Essa pode ser uma oportunidade 
a ser aproveitada. Neste cenário, faça um plano de 
mudança da cultura operacional, estrutura e modelo de 
gestão da Rapport. Algumas questões que precisam ser 
respondidas são:
1. Como efetivamente modificar a cultura organizacional 
para que ela se torne uma empresa ágil?
2. Qual método ágil adotar? Quais os prós e contras dele?
3. Qual deve ser a estrutura organizacional futura? Esta 
deve ser perene ou mutável no tempo? Como alocar as 
áreas de suporte? Qual é o papel futuro do supervisor?
4. Como romper as fronteiras das áreas de 
desenvolvimento?
5. A área comercial está funcionando como desejado? 
O que fazer para aperfeiçoar sua atuação?
6. Que melhoria introduzir para diminuir os prazos de 
desenvolvimento exigidos pelo mercado?
7. Como vencer as resistências internas?
140140 
VERIFICAÇÃO DE LEITURA
1. As razões para a resistência as mudanças são de ordem: 
a. Lógica, sociológica e psicológica.
b. Lógica, psicológica e motivacional.
c. As razões para a resistência às mudanças nunca 
são lógicas. Quando se analisa racionalmente as 
mudanças, elas são mais fáceis de serem transpostas.
d. Falta de comunicação e participação. 
e. Falta de participação e as razões psicológicas como 
medo e apreensão sobre o desconhecido.
2. Sobre o modelo descrito por Mann para a gestão do dia 
a dia podemos afirmar que: 
a. Como modelo, tem 3 elementos principais: 
Controles visuais, Liderança e Contabilidade diária 
dos resultados. Esta última é feita através de pelo 
menos 3 reuniões encadeadas e de forma a escalar 
a estrutura hierárquica, cujo objetivo é identificar 
e solucionar os problemas que ocorreram no 
período anterior.
b. Embora existam diferentes elementos, a principal 
e mais importante figura no modelo de gestão do 
dia a dia é o líder do time. Ele é o responsável direto 
pela reunião de nível 1 e abastece de informações a 
reunião de 2º nível. Além disso, ele dá o ritmo para o 
time na linha de frente.
141141 141
c. Em tese, nenhum problema deve chegar até a 
reunião de nível 3. Esta reunião é fundamentalmente 
uma revisão do visto nas duas primeiras. Todos os 
problemas devem ter sido endereçados, ou mesmo 
resolvidos, antes.
d. As 3 reuniões de contabilidade diária de resultados 
devem ser formais, como sugerido no SCRUM, 
documentadas e registradas para consulta posterior. 
Normalmente estas reuniões precisam ser feitas em 
sala apropriada para tal.
e. Nenhuma das alternativas anteriores.
3. Algumas ações para contornar ou mesmo evitar a 
reconhecida resistência à mudança, incluem:
a. Alinhamento, comunicação, envolvimento e coerção.
b. Inserção das pessoas na mudança, facilitação e apoio 
e coerção.
c. Coerção, cooptação e delegação.
d. Socialização, facilitação e negociação.
e. Nenhuma das alternativas anteriores.
Referências Bibliográficas
CHIAVENATO, Idalberto. Comportamento Organizacional: a teoria e a prática de 
inovar. Rio de Janeiro: Campos, 2005. 
______. Gestão de pessoas: o novo papel dos recursos humanos nas organizações. 
Rio de Janeiro: Campus, 1999. 
142142 
COHEN, R. Allan; FINK, L. Stephen. Comportamento Organizacional: conceitos e 
estudos de casos. 7. ed. Rio de Janeiro: Campus, 2003.
DE REZENDE, Frederico Pifano; DE FREITAS, Flávio Ozorio; DE OLIVEIRA 
SILVA, Elizângela Aparecida Toledo. Cultura organizacional e resistência a 
mudança. 2011.
MANN, David. Creating a lean culture: tools to sustain lean conversions. Productivity 
Press, 2014.
SCHEIN, Edgar H. Organizational culture and leadership. John Wiley & Sons, 2010.
SHOOK, John. How to change a culture: Lessons from NUMMI. MIT Sloan Management 
Review, v. 51, n. 2, p. 63-68, 2010.
SILVA, José R. G. da; VERGARA, Sylvia C. Sentimentos, subjetividade e supostas 
resistências à mudança organizacional. Revista Administração de Empresas, 2003.
Gabarito
Questão 1 – Resposta: A
Lógica, sociológica e psicológica.
Questão 2 – Resposta: B
Embora existam diferentes elementos, a principal e mais 
importante figura no modelo de gestão do dia a dia é o líder do 
time. Ele é o responsável direto pela reunião de nível 1 e abastece 
de informações a reunião de 2º nível. Além disso, ele dá o ritmo 
para o time na linha de frente.
Questão 3 – Resposta: B
Inserção das pessoas na mudança, facilitação e apoio e coerção.
1. Comunicação e educação: Fazer a prévia comunicação da 
mudança às pessoas para ajudá-las a compreender a lógica e a 
necessidade da mesma.
2. Participação e envolvimento: Inserir as pessoas no processo. 
Torná-las parte da mudança.
143143 143
3. Facilitação e apoio: Facilitar e apoiar as pessoas a se ajustarem à 
mudança mais rapidamente. 
4. Negociação e acordo: Oferecer algo de valor em troca da 
implementação da mudança.
5. Manipulação e cooptação: Buscar influenciar as pessoas.
6. Coerção: Finalmente, a resistência pode ser tratada de forma 
coercitiva por meio da ameaça explícita ou implícita. 
	Sumário
	Apresentação da disciplina
	Origens dos Métodos Ágeis: Manifesto Ágil 
	Objetivos
	 1. Introdução
	2. Desafios em Serviços na Gestão de Projetos
	3. Visão e Valores dos Métodos Ágeis
	Verificação de leitura
	Referências Bibliográficas
	Gabarito
	Scrum, XP e Lean: Princípios comuns 
	Objetivos
	 1. Introdução
	 2. Scrum
	 3. XP
	 4. Lean
	 5. Pontos comuns e diferenças entre Scrum, XP e Lean
	Verificação de leitura
	Referências Bibliográficas
	Gabarito
	Análise Comparativa
	Objetivos
	1. Introdução
	 2. Outras Metodologias
	 3. Análise Comparativa
	Verificação de leitura 
	Referências Bibliográficas
	Gabarito
	Balanceando Agilidade e Disciplina
	Objetivos
	 1. Introdução
	2. Risco
	3. Gestão de Riscos em Ambiente Ágil: Balanceando Agilidade e Controle
	4. Conclusão
	Verificação de leitura
	Referências Bibliográficas
	Gabarito
	Kanban aplicado aos Métodos Ágeis
	Objetivos
	1. Introdução
	2. Kanban
	3. Controles Visuais Digitais
	4. Kanban como suporte para as metodologias ágeis
	5. Conclusão
	Verificação de leitura
	Referências Bibliográficas
	Gabarito
	Pessoas: Empoderamento e Energização
	Objetivos
	 1. Introdução
	 2. Visão do Indivíduo na Organização
	3. Organização do Trabalho
	4. Conclusão
	Verificação de leitura
	Referências Bibliográficas
	Gabarito
	Pessoas: Gestão da Mudança
	Objetivos
	1. Introdução
	2. Cultura Organizacional
	3. Resistência a Mudança
	4. Gestão do dia a dia
	5. Conclusão
	Verificação de leitura
	Referências Bibliográficas
	Gabarito