Metodologias Ágeis

WBA0725_v1.
INTRODUÇÃO ÀS
METODOLOGIAS ÁGEIS
© 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/
2
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
3
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.
4
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.
5
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.
6
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.
7
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 Balanced Scorecard
(Kaplan e Norton, 1996).
8
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.
9
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.
10
10
Figura 3 | Mapa Estratégico
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.
11
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;
12
12
• 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.
13
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
14
14
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.
15
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
16
16
partes do projeto, subconjuntos, é tão importante. As entregas
fracionadas 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.
17
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.
18
18
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.
19
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 à:
20
20
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.
21
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ário do contato com o cliente,
que é sempre bem-vindo.
22
22
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”.
23
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.
24
24
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.
25
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:
26
26
• 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.
27
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.
28
28
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.
29
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.
30
30
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
lean remete à 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).
31
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.
32
32
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).
33
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
34
34
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.
35
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.
36
36
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 merece
atençã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ê?
1. Considerando-se a 4ª Regra do DNA da Toyota, descrita
por Steven Spear, pode-se afirmar que:
37
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.
38
38
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.
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.
39
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.
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.
40
40
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.
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.
41
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.
42
42
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.
43
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 poder ocorrer).
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.
44
44
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.
45
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;
46
46
• 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.
47
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
48
48
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.
49
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
50
50
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).
51
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.
52
52
Tabela 1 | Análise Comparativa
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.
53
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.

responder ao preparar o plano para apresentar na reunião
de diretoria:
54
54
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.
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.
55
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.
56
56
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.
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.
57
_____________. 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.
58
58
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 desenvolvimento do 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.
59
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.
60
60
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.
61
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.
62
62
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.
63
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.
64
64
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).
65
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

processos sã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).
66
66
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).
67
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.
68
68
Figura 6 | Identificação de Riscos - SIPOC
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.
69
Figura 7 | Análise Qualitativa dos Riscos - SIPOC
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).
70
70
Figura 8 | Análise Quantitativa dos Riscos - SIPOC
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.
71
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
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.
72
72
Figura 10 | Monitoramento e Controle dos Riscos - SIPOC
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.
73
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.
74
74
Figura 11 | Tempo versus Custo de acordo com o controle
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.
75
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.
76
76
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.
77
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?
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.
78
78
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.
79
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)..
80
80
e. A EAP existe, em forma e conteúdo, na gestão
tradicional de projetos, a EAR somente nos
métodos ágeis.
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
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
81
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
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
respostas a riscos.
Os processos clássicos para a gestão de 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.
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.
82
82
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.
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.
83
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.
84
84
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.
85
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.
86
86
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.
87
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.
88
88
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 retirada em um supermercado.
89
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
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.
90
90
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.
91
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.
92
92
Figura 6 | Sistemas de Controle de Fluxo: Kanban, CONWIP e Empurrado
Kanban
Puxado
CONWIP
Puxado
Empurrado
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,
93
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
94
94
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ções personalizadas. A figura 9 traz um exemplo dele.
95
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.
96
96
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.
97
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:
98
98
• 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.
99
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?
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.
100
100
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:
101
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.
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.
102
102
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.
a) Os tempos de processamento, lead time e ajuda na remoção
de gargalos.
103
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.
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.
104
104
d) Compartilhar e colaborar nas atividades pendentes em
desenvolvimento.
e) Todas as alternativas anteriores.
Falso.
105
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.
106
106
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).
107
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
108
108
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;
109
• 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
110
110
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:
111
• 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,
112
112
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).
113
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
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
114
114
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
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
115
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
116
116
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 compartilhar algumas decisões. Veja a figura 7
sobre os tipos de liderança possíveis.
117
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.
118
118
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:
119
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.
120
120
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.
121
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.

responder ao preparar uma proposta para a Schédio.
122
122
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?
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.
123
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.
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.
124
124
c. Segurança, Social, Estima e Realizações Pessoais.
d. Fisiologia, Segurança, Social, Estima e

Realizações Pessoais.
e. Nenhuma das alternativas anteriores.
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
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.
125
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.
Fisiologia, Segurança, Social, Estima e Realizações Pessoais.
126
126
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.
127
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
128
128
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.
129
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.
130
130
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):
131
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 a mudar.
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.
132
132
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.
133
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.
134
134
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.
135
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
136
136
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.
137
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 pessoas em 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
138
138
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?
139
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.
140
140
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.
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.
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.
141
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
Lógica, sociológica e psicológica.
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.
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.
142
142
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.
143

Metodologias Ágeis

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Metodologias Ágeis

Enviado por

Direitos autorais:

Formatos disponíveis

WBA0725_v1.

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

1. Desenvolvimento ágil de software. 2. Scrum

Origens dos Métodos Ágeis: Manifesto Ágil 6

Scrum, XP e Lean: Princípios comuns 24

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

Como forma de identificar os métodos ágeis – embora não exista

Dentre os diversos métodos ágeis, pode-se destacar três:

• O Lean, que se originou na Toyota, mas que não é exclusividade

• O SCRUM é um método ágil que busca entregar o produto

• E o eXtreme Programming – XP, o método ágil mais utilizado no

Tanta flexibilidade e agilidade sacrifica muito os controles. Até quando

Finalmente será discutido processo de implementação da gestão ágil de

• Apresentar a origem dos Métodos Ágeis;

• Discutir os objetivos dos Métodos Ágeis;

• Explorar o Manifesto Ágil.

Segundo o dicionário Dicio, “ágil”, quando usado como adjetivo, indica

2. Desafios em Serviços na Gestão de Projetos

Embora o valor destas ferramentas e métodos seja inegável, em dadas

2.1 Em Busca da Relevância Perdida

A maioria dos sistemas de gestão, e, em especial, quase todos os

Se considerarmos o setor de serviços, ou setores onde a inovação é

Algumas alternativas foram desenvolvidas com o intuito de dar

O Balanced Scorecard (Kaplan e Norton, 1992) - apresentado na

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,

Fonte: Adaptada de Kaplan e Norton, 1992.

O Scorecard possibilita reunir medidas de desempenho e planejamento

Note que ao invés de termos diversos e difusos indicadores de

Para desdobrar o plano estratégico para toda a empresa, Kaplan e

Fonte: Kaplan e Norton (2000).

Outros modelos similares também foram desenvolvidos e um exemplo é

Mora Corral e Vivas Urieta (2001) propõem cinco etapas para

2.3 Sistema de Estratégia Minimalista

Este sistema tem como objetivo o abandono de excessos que

Nesse sentido, esta proposta de estrutura estratégica baseia-se nos 4Cs

Os 4Cs de Lauterborn surgiram em oposição aos tradicionais 4Ps do

3. Visão e Valores dos Métodos Ágeis

Os Métodos Ágeis oficialmente tiveram origem em uma reunião de

A visão buscada pelo grupo – explicitada na figura 4 – foi simplificar e

• Valorizar os indivíduos e as interações entre estes – é sabido que

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

Os princípios do Manifesto Ágil, segundo Fowler e Highsmith (2001), são:

• A mais alta prioridade é satisfazer o cliente através da entrega

• Acolher bem mudanças nos requisitos, mesmo quando já tivermos

A imprevisibilidade nos negócios é o desafio atual. A proposta é

• Faça entregas frequentes.

Embora este princípio esteja ligado ao desenvolvimento de

• Pessoal de negócios e desenvolvimento trabalham juntos

Note que o Manifesto Ágil está focado no desenvolvimento de

• Desenvolva os projetos com pessoal motivado, dê-lhes o

As ferramentas e tecnologias são importantes, mas são as

• O método mais eficiente e efetivo de prover informações para

Uma grande preocupação dos críticos do Manifesto Ágil é sua

Fonte: Adaptada de Nonaka e Takeushi (1995).

• O produto em desenvolvimento é o indicador básico de progresso.