Anda di halaman 1dari 290

Este livro inaugura a

segunda gerao dos


Metdos geis. Eu prevejo
que ele se tornar um
clssico instantaneamente.
Alan Shalloway,

David J. Anderson foi pioneiro na tcnica Kanban


com a Microsoft em 2004 e desde ento tem refinado
a abordagem. Kanban fornece os insights de David
nessa nova e evolucionria abordagem para gerenciamento de mudana. O Mtodo Kanban melhorar
a maturidade e a agilidade da sua organizao com
uma resistncia mnima a mudana.

Alisson Vale
Fundador, Phidelis

Com a popularizao dos


mtodos geis temos
muitas perguntas sobre
como mudar grandes
organizaes do caos para
um lugar melhor. A abordagem Kanban descrita
neste livro revolucionou
meu trabalho nesses ambientes, na melhor forma
Kaizen."
Rodrigo Yoshima,
Fundador, Aspercom

BLUE HOLE PRESS

ISBN 978- 0 - 9845214 - 6 - 3


B L U E
H O L E
PRESS

9 780984 521463

David J. Anderson

David J. Anderson um consultor


de gesto independente com
muitos anos de experincia
gerenciando, e liderando equipes
de software em algumas das
maiores empresas do mundo. Ele
fundador do Lean Software &
Systems Consortium e co-autor
da Nota Tcnica CMMI and Agile:
Why not embrace both! do
Software Engineering Institute.

Kanban mudou o meu


negcio. Lendo este livro,
eu agora entendo porque!

Mudana Evolucionria de Sucesso para


Seu Negcio de Tecnologia

CEO e Consultor Snior


Net Objectives

Este livro responde algumas perguntas:


O que Kanban?
Porque eu gostaria de usar Kanban?
Como fao para implementar Kanban?
Como identifico oportunidades de melhoria e o
que devo fazer em relao a elas?

kanban

Kanban est se tornando uma maneira popular de


visualizar e limitar trabalho-em-progresso em
desenvolvimento de software e no trabalho em tecnologia da informao. Equipes ao redor do mundo
esto incluindo Kanban nos seus processos
existentes para catalisar uma mudana cultural e
promover melhor agilidade no negcio.

Sequim, Washington
www.blueholepress.com
B L U E
H O L E
PRESS

David J. Anderson

KANBAN
Mudana Evolucionria de Sucesso para
Seu Negcio de Tecnologia
Prefcio de Donald G. Reinersten
Traduo Andrea Pinto

Elogios para Kanban

O trabalho de David com Sistemas Kanban tem uma influncia significante


em como eu abordo desenvolvimento de software e mudou a maneira como
eu penso em processos. Em vez de visualizar trabalho em termos de estrias,
pontos, e timeboxes, eu agora enxergo WIP, fluxo, e cadncia. Este livro um
marco por trazer esta perspectiva para um pblico maior, e leitura obrigatria para qualquer pessoa a procura de maneiras de criar organizaes de
desenvolvimento bem sucedidas e sustentveis.
Karl Scotland
Consultor Prtico Snior, EMC Consulting
Kanban um assunto complicado para se escrever, visto que a implementao
de qualquer pessoa ser adaptada para o seu fluxo de trabalho e gargalos especficos, mas David consegue fornecer um framework terico slido enquanto
mantm uma aderncia estrita aos resultados prticos do mundo real.
Chris Simmons
Gerente de Desenvolvimento, Sophos
O livro Kanban de David Anderson vai alm do nvel introdutrio de como
kanban conduz mudana, e fornece uma explicao clara dos aspectos prticos, atravs de exemplos ricos e dicas prticas. Kanban para o trabalho de
conhecimento suporta poderosamente a tendncia emergente de autonomia
no espao de trabalho, um dos desenvolvimentos de gerenciamento mais
interessante da nossa equipe.
Christina Skaskiw
Consultora gil
A melhor metodologia de mudana para software que vi nos ltimos dez anos.
David A. Bulkin
Vice Presidente, Lithespeed, LLC

Kanban
Mudana Evolucionria de Sucesso
para Seu Negcio de Tecnologia

David J. Anderson

B L U E
H O L E
PRESS

Sequim, Washington

Blue Hole Press


Sequim, WA, USA
www.blueholepress.com

Copyright 2011 por David J. Anderson


Todos os direitos reservados. Nenhuma parte desta publicao pode
ser reproduzida ou transmitida em qualquer forma ou por qualquer
meio, eletrnico ou mecnico, incluindo cpia, reproduo, ou qualquer sistema de armazenamento ou recuperao de informao, sem
a permisso prvia por escrito do editor.
Aplicado para
Library of Congress Cataloging-in-Publication Data; disponvel em
www.loc.gov
Paperback ISBN: 978-0-9845214-6-3
Kindle ISBN:

978-0-9845214-7-0

PDF ISBN:

978-0-9853051-5-4

Projeto grfico da capa copyright 2011 by Diego Mocot


Projeto da capa e do interior by Vicki L. Rowland
Fotos na pgina 12 utilizadas com permisso, Thomas Blomseth
Traduo Andrea Pinto
10 9 8 7 6 5 4 3 2

ndice Analtico
ndice Analtico_________________________________________ v
Prefcio_____________________________________________xiii
Parte Umv Introduo
Captulo 1
Resolvendo um dilema do Gerente gil__________________________1
Minha Busca pelo Ritmo Sustentvel_____________________________ 2
Minha Busca pela Gesto de Mudana Bem Sucedida _______________ 3
Do Drum-Buffer-Rope para o Kanban____________________________ 6
Surgimento do Mtodo Kanban_________________________________ 7
Adoo do Kanban pela Comunidade____________________________ 8
O Valor do Kanban Contra-intuitivo___________________________ 8

Captulo 2
O que o Mtodo Kanban?_________________________________ 11
O que um Sistema Kanban?__________________________________ 13
Kanban Aplicado ao Desenvolvimento de Software________________ 13
Por que Usar um Sistema Kanban?_____________________________ 15
Kanban em Ao___________________________________________ 16
Um Modelo para o Mtodo Kanban____________________________ 17
Kanban como um Sistema Complexo Adaptvel para Lean__________ 17
Comportamento Emergente com Kanban________________________ 18
Kanban como um Doador de Permisses________________________ 19

vi

ndice Analtico

Parte dois v Benefcios do Kanban


Captulo 3
Uma Receita para o Sucesso________________________________ 25
Implementando a Receita____________________________________ 26
Foco na Qualidade__________________________________________ 27
Reduzir Trabalho-em-Progresso e Entregar Frequentemente_________ 29
WIP, Lead Time, e Defeitos_________________________________ 30
Quem melhor?_________________________________________ 33
Entregas frequentes aumentam a confiana____________________ 34
Conhecimento implcito __________________________________ 35
Equilibrando a demanda e o rendimento_________________________ 35
Crie folga_________________________________________________ 36
Priorize___________________________________________________ 37
Influncia______________________________________________ 37
Construindo Maturidade__________________________________ 38
Ataque as Fontes de Variabilidade para Melhorar Previsibilidade______ 38
Receita para o Sucesso e Kanban_______________________________ 39

Captulo 4
Do Pior ao Melhor em Cinco Trimestres__________________________ 41
O Problema_______________________________________________ 42
Visualizar o Fluxo de Trabalho________________________________ 43
Fatores Influenciando o Desempenho___________________________ 43
Torne Explcitas as Polticas do Processo_________________________ 45
Estimativa Era um Desperdcio________________________________ 45
Limitar Trabalho em Progresso (WIP)___________________________ 46
Estabelecendo uma Cadncia na Entrada________________________ 47
Fazendo um Novo Acordo____________________________________ 48
Implementando Mudanas___________________________________ 48
Ajustando as Polticas_______________________________________ 49
Procurando mais Melhorias___________________________________ 50
Resultados________________________________________________ 51

Captulo 5
Uma Cultura de Melhoria Contnua____________________________ 55
Cultura Kaizen_____________________________________________ 56
Kanban Acelera Maturidade e Capacidade Organizacional___________ 57

ndice Analtico

Mudana Sociolgica________________________________________ 62
Propagao Viral da Colaborao______________________________ 63
Mudana Cultural Talvez Seja o Maior Benefcio do Kanban_________ 65

Parte Trs v Implementando Kanban


Captulo 6
Mapeando a Cadeia de Valor________________________________ 71
Definindo um Ponto Inicial e Final de Controle___________________ 72
Tipos de Item de Trabalho____________________________________ 72
Desenhando uma Parede de Cartes____________________________ 73
Anlise da Demanda________________________________________ 77
Anatomia de um Carto de Item de Trabalho_____________________ 79
Acompanhamento Eletrnico_________________________________ 80
Atribuindo Limites de Entrada e Sada__________________________ 82
Lidando com Concorrncia___________________________________ 83
Lidando com atividades Desordenadas__________________________ 85

Captulo 7
Coordenao com Sistemas Kanban___________________________ 87
Controle Visual e Puxado____________________________________ 87
Acompanhamento Eletrnico_________________________________ 89
Reunies Standup Dirias____________________________________ 90
O Aps a Reunio__________________________________________ 92
Reunies para Reabastecimento de Fila__________________________ 92
Reunies de Planejamento de Release___________________________ 93
Triagem__________________________________________________ 94
Reviso e Escalao de Log de Problemas________________________ 96
Avatar Amigo (Sticky Buddies) ________________________________ 97
Sincronizao atravs de Localizaes Geogrficas_________________ 98

Captulo 8
Estabelecendo uma Cadncia de Entrega_______________________ 101
Coordenao dos Custos de Entrega___________________________ 103
Custos de Transao de Entrega_______________________________ 104
Eficincia de Entrega_______________________________________ 106
Quanto de eficincia o bastante?_____________________________ 107
Estabelecendo uma Cadncia de Entrega_______________________ 107

vii

viii

ndice Analtico

Melhore a Eficincia para Aumentar a Cadncia de Entrega_________ 108


Fazendo Entregas Sob Demanda ou Ad Hoc_____________________ 109

Captulo 9
Estabelecendo uma Cadncia de Entrada_______________________ 113
Coordenando Custos de Priorizao___________________________ 113
Acordando uma Cadncia de Priorizao_______________________ 116
Eficincia de Priorizao____________________________________ 116
Custos de Transao de Priorizao____________________________ 117
Melhore Eficincia para Aumentar a Cadncia de Priorizao_______ 118
Fazendo Priorizao Ad Hoc ou Por Demanda___________________ 119

Captulo 10
Estabelecendo Limites para o Trabalho-em-Progresso_______________ 123
Limites para Tarefas________________________________________ 124
Limites para Filas__________________________________________ 125
Retenha Gargalos__________________________________________ 126
Tamanho da Fila de Entrada_________________________________ 126
Sees Ilimitadas de Trabalho________________________________ 128
No Estresse a Sua Organizao_______________________________ 129
No Estabelecer um Limite de WIP um Erro___________________ 130
Alocao de Capacidade____________________________________ 131

Captulo 11
Estabelecendo Acordo de Nvel de Servio_______________________ 133
Definies Tpicas de Classe de Servio_________________________ 134
Expedio________________________________________________ 135
Data Fixa de Entrega_______________________________________ 136
Classe Padro_____________________________________________ 138
Classe Intangvel __________________________________________ 138
Polticas para Classe de Servio_______________________________ 139
Polticas de Expedio______________________________________ 140
Polticas de Data de Entrega Fixa______________________________ 140
Polticas de Classe Padro___________________________________ 141
Classe Intangvel__________________________________________ 142
Determinando Meta para Entrega de Servio____________________ 142
Estabelecendo uma Classe de Servio__________________________ 144

ndice Analtico

Colocando Classes de Servio em Uso__________________________ 145


Aloque Capacidade para Classes de Servio_____________________ 146

Captulo 12
Mtricas e Relatrios de Gerenciamento________________________ 149
Monitorando WIP_________________________________________ 150
Lead Time________________________________________________ 151
Desempenho de Entrega na Data______________________________ 152
Rendimento______________________________________________ 153
Problemas e Itens de Trabalho Bloqueados______________________ 154
Eficincia do Fluxo________________________________________ 155
Qualidade Inicial__________________________________________ 156
Carga de Falhas___________________________________________ 156

Captulo 13
Escalando Kanban _____________________________________ 159
Requisitos Hierrquicos_____________________________________ 160
Dissocie Entrega de Valor de Variabilidade do Item de Trabalho_____ 161
Paredes de Carto em Duas Camadas__________________________ 163
Introduzindo Raias________________________________________ 164
Abordagem Alternativa para Variabilidade no Tamanho___________ 165
Incorporando Classes de Servio______________________________ 165
Integrao de Sistemas______________________________________ 166
Gerenciando Recursos Compartilhados________________________ 166

Captulo 14
Reviso Operacional____________________________________ 169
Antes da Reunio__________________________________________ 169
Defina um Tom de Negcio desde o Incio______________________ 170
Convide os Participantes a Sair da Plateia e Agregar Valor__________ 171
Agenda Principal__________________________________________ 171
Pedra Angular para uma Transio Lean________________________ 172
Cadncia Apropriada_______________________________________ 173
Demonstrando o Valor dos Gerentes___________________________ 174
Foco Organizacional Fomenta Kaizen__________________________ 174
Um Exemplo Anterior______________________________________ 174

ix

ndice Analtico

Captulo 15
Empreendendo uma Iniciativa de Mudana Kanban________________ 179
Mudana Cultural em vez de uma Iniciativa de Mudana Gerenciada_ 179
O Primeiro Objetivo para Nosso Sistema Kanban_________________ 180
Objetivos Secundrios para Nosso Sistema Kanban_______________ 181
Conhecer os Objetivos e Articular os Benefcios__________________ 185
Passos para Dar Incio______________________________________ 186
Kanban Requer um Tipo Diferente de Negociao________________ 188
Fazendo uma Negociao Kanban_____________________________ 190
Limites de WIP___________________________________________ 190
Priorizao_______________________________________________ 192
Entrega/Release___________________________________________ 192
Lead Time e Classes de Servio_______________________________ 194

Parte Quatro v Fazendo Melhorias


Captulo 16
Trs Tipos de Oportunidade de Melhoria________________________ 199
Gargalos, Eliminao de Desperdcio, e Reduo da Variabilidade____ 200
Teoria das Restries_______________________________________ 200
Five Focusing Steps______________________________________ 201
Lean, TPS, e Reduo de Desperdcio__________________________ 202
Deming e Six Sigma________________________________________ 203
Adequar Kanban para a Cultura da Sua Empresa_________________ 204

Captulo 17
Gargalos e Disponibilidade No-Instantnea_____________________ 207
Recursos com Capacidade Limitada___________________________ 209
Aes de Elevao_________________________________________ 209
Aes de Explorao/Proteo________________________________ 210
Aes de Subordinao_____________________________________ 213
Recursos Disponveis No - Instantaneamente___________________ 214
Aes de Explorao/Proteo________________________________ 217
Aes de Subordinao_____________________________________ 218
Aes de Elevao_________________________________________ 219

ndice Analtico

Captulo 18
Um Modelo Econmico para Lean____________________________ 223
Redefinindo Desperdcio__________________________________ 223
Custos de Transao________________________________________ 224
Custos de Coordenao_____________________________________ 226
Como voc Sabe se uma Atividade um Custo?__________________ 228
Carga Defeituosa__________________________________________ 229

Captulo 19
Fontes de Variabilidade__________________________________ 231
Fontes Internas de Variabilidade______________________________ 233
Tamanho do Item de Trabalho________________________________ 233
Mesclas de Tipos de Item de Trabalho__________________________ 234
Mesclas de Classes-de-Servio________________________________ 235
Fluxo Irregular____________________________________________ 236
Rework__________________________________________________ 237
Fontes Externas de Variabilidade______________________________ 237
Ambiguidade de Requisitos__________________________________ 238
Requisies de Expedio___________________________________ 239
Fluxo Irregular____________________________________________ 240
Disponibilidade do Ambiente________________________________ 241
Outros Fatores de Mercado__________________________________ 242
Dificuldades em Agendar Atividades de Coordenao_____________ 243

Captulo 20
Gerenciamento de Problemas e Polticas de Escalao_______________ 247
Gerenciando Problemas_____________________________________ 248
Escalando Problemas_______________________________________ 249
Acompanhando e Reportando Problemas_______________________ 250

Notas____________________________________________
Agradecimentos___________________________________
ndice___________________________________________
Sobre o Autor_____________________________________
Recursos Adicionais________________________________
Sobre o Tradutor___________________________________

253
257
261
267
268
269

xi

Para Nicola and Natalie

Prefcio

u sempre observo o trabalho de David Anderson. Meu primeiro


contato com ele foi em outubro de 2003, quando ele me enviou
um exemplar do seu livro, Agile Management for Software Engineering:
Applying Theory of Constraints for Business Results. Como o ttulo
indica, esse livro foi altamente influenciado pela Teoria das Restries
(TOC*) de Eli Goldratt. Depois, em maro de 2005, eu o visitei na
Microsoft; nessa poca ele estava fazendo um trabalho impressio
nante com diagramas de fluxo cumulativo. Mais tarde, em abril de
2007, eu tive a chance de observar o inovador sistema kanban que ele
implementou na Corbis.
Certamente, velocidade mais til caso se esteja na direo correta;
eu tenho confiana de que David est na direo certa. Eu estou particularmente animado com esta ltima obra sobre sistemas kanban.
Eu sempre achei as ideias de produo enxuta mais teis no desenvolvimento de produtos do que as de TOC. De fato, em outubro de
2003 eu escrevi para David dizendo Uma das fragilidades de TOC
a sua falta de nfase na importncia do tamanho dos lotes. Se a sua
primeira prioridade encontrar e reduzir a restrio voc est muitas
vezes resolvendo o problema errado. Eu ainda acredito que isso seja
verdade.
Em nosso encontro de 2005 eu novamente encorajei David a olhar
alm do foco em gargalos de TOC. Eu expliquei a ele que o dramtico sucesso do Sistema de Produo Toyota (TPS ) no tinha nada
a ver com encontrar e eliminar gargalos. O desempenho dos ganhos
da Toyota veio a partir do uso da reduo do tamanho do lote e da
variabilidade para reduzir o estoque de trabalho-em-progresso. Foi
a reduo de estoque que proporcionou os benefcios econmicos e
* N. de T.: Sigla de Theory of Constraints.
xiii

xiv

Prefcio

foram esses sistemas de restrio de trabalho-em-progresso como o kanban que tornaram isso possvel.
Na poca em que visitei a Corbis em 2007 eu vi uma impressionante implementao de um sistema kanban. Eu disse a David que ele tinha progredido muito alm da
abordagem kanban usada pela Toyota. Por que eu disse isso? O Sistema de Produo
Toyota elegantemente aperfeioado para lidar com tarefas repetitivas e previsveis: tarefas com durao e custos de atraso homogneos. Sob certas condies correto usar
abordagens como a priorizao first-in-first-out (FIFO)*. Tambm correto bloquear a
entrada de trabalho quando o limite de WIP atingido. No entanto, essas abordagens
no so timas quando devemos lidar com atividades no-repetitivas e imprevisveis;
com diferentes custos de atraso; e duraes diferentes exatamente com o que devemos lidar no desenvolvimento de produtos. Precisamos de sistemas mais avanados, e
este livro o primeiro a descrever esses sistemas em detalhes prticos.
Eu gostaria de oferecer aos leitores alguns breves avisos. Primeiro, se voc acha que
realmente entende como sistemas kanban funcionam, provavelmente voc est pensando em sistemas kanban usados em produo enxuta. As ideias neste livro vo muito
alm de tais sistemas simples que usam limites estticos de WIP, escalonamento FIFO
e uma nica classe de servio. Preste muita ateno a essas diferenas.
Segundo, no enxergue essa abordagem apenas como um sistema de controle visual.
O modo como quadros kanban deixam o WIP visvel surpreendente, mas apenas
um pequeno aspecto dessa abordagem. Se voc ler esse livro cuidadosamente voc vai
encontrar muito mais. Os insights reais ficam em aspectos como o de design de processos de chegada e partida, a gesto de recursos no-substituveis e o uso de classes
de servio. No perca as sutilezas se distraindo com a parte visual.
Terceiro, no d menos valor a esses mtodos pelo fato deles parecerem fceis de
usar. Essa facilidade de uso um resultado direto do insight de David sobre o que
produz o mximo de benefcio com o mnimo de esforo. Ele est bem ciente das necessidades dos praticantes e prestou muita ateno ao que realmente funciona. Mtodos
simples criam menor ruptura e quase sempre produzem os benefcios mais amplamente sustentados.
* N. de T.: Termo no traduzido devido sua utilizao mais ampla no idioma original (Ingls) pela comunidade de TI no
Brasil. Traduo: primeiro a entrar, primeiro a sair.
N. de T.: Sigla de work-in-progress.
N. de T.: Termo no traduzido devido sua utilizao mais ampla no idioma original (Ingls) pela comunidade de TI no
Brasil. Traduo: projeto.
N. de T.: Termo no traduzido devido sua utilizao mais ampla no idioma original (Ingls) pela comunidade de TI no
Brasil. Traduo: compreenso, viso.

Prefcio

Este um emocionante e importante livro que merece leitura atenta. O que voc
obter dele depender de quo seriamente voc o l. Nenhum outro livro lhe dar
melhor exposio sobre essas avanadas ideias. Eu espero que voc o aprecie tanto
quanto eu o apreciei.
Don Reinertsen,
7 de fevereiro de 2010
Redondo Beach, California
Autor de The Principles of Product Development Flow

xv


PARTE UM

Introduo

C aptulo 1

Resolvendo um dilema
do Gerente gil

m 2002, eu era um gerente de desenvolvimento preparado para


a batalha em uma filial da diviso PCS da Motorola (telefones
celulares) situada em Seattle, Washington. Meu departamento havia
sido parte de uma empresa startup que a Motorola havia adquirido
naquele mesmo ano. Ns desenvolvamos software para servidores de
rede para servios de dados, como download over-the-air* e gerenciamento de dispositivos over-the-air. Essas aplicaes para servidor
eram parte de sistemas integrados que funcionavam em conjunto com
cdigo cliente nos aparelhos de celular, bem como com outros elementos dentro das redes das operadoras de celular e infra-estrutura
de retaguarda, como cobrana. Nossos prazos eram definidos pelos
gerentes sem levar em conta complexidade de engenharia, riscos ou
tamanho do projeto. Nossa base de cdigo havia evoludo desde a
empresa startup original, onde muitos custos haviam sido cortados.
Um desenvolvedor snior insistiu em referir-se ao nosso produto
como um prottipo. Ns estvamos com uma necessidade desesperada de produtividade e qualidade maiores para suprir as demandas
do negcio.
No meu trabalho, em 2002, e atravs do meu esforo de ter escrito
meu livro anterior1, dois novos desafios principais estavam na minha
* Termo no traduzido devido sua utilizao mais ampla no idioma original (Ingls) pela comunidade de TI no Brasil. Traduo: pelo ar, atravs do ar.
1

Captulo 1 Resolvendo um dilema do Gerente gil

mente. Primeiro, como eu poderia proteger minha equipe das incessantes demandas
de negcio e alcanar o que a comunidade gil agora se refere como um ritmo sustentvel? E segundo, como eu poderia obter sucesso na adoo em escala de uma
abordagem gil por toda e empresa e superar a inevitvel resistncia mudana?

Minha Busca pelo Ritmo Sustentvel


Em 2002, a comunidade gil se referia noo de um ritmo sustentvel como simplesmente a semana de 40 horas2. Os Princpios Por Trs do Manifesto gil3 nos
diziam que Processos geis promovem desenvolvimento sustentvel. Os patrocinadores, desenvolvedores e usurios devem ser capazes de manter um ritmo constante
indefinidamente. Dois anos antes, minha equipe na Sprint PCS se acostumou ao me
ouvir dizer que desenvolvimento de software de larga escala uma maratona, no
um sprint*. Se os membros da equipe mantivessem o ritmo para o longo curso em um
projeto de 18 meses, ns no poderamos permitir que eles ficassem esgotados depois
de um ms ou dois. O projeto deveria ser planejado, orado, programado e estimado
de forma que os membros da equipe pudessem trabalhar um horrio razovel a cada
dia para evitar que eles ficassem cansados. O desafio pra mim como gerente foi atingir
esse objetivo e acomodar todas as demandas do negcio.
Em meu primeiro emprego como gerente em 1991, em uma startup de 5 anos de
idade que fazia placas de captura de vdeo para PCs e outros computadores menores,
o feedback do CEO foi de que a liderana me considerava como muito negativo. Eu
estava sempre respondendo No quando pediam por mais produtos ou funcionalidades quando nossa capacidade de desenvolvimento j estava esticada ao mximo. Em
2002, havia claramente um padro: Eu passara mais de dez anos dizendo No, lutando
contra as incessantes e instveis demandas de donos de empresas.
Em geral, equipes de engenharia de software e departamentos de TI parecem estar
merc de outros grupos que negociam, persuadem, intimidam e rejeitam mesmo os
planos mais defensveis e objetivos. Mesmo planos baseados em profunda anlise e
apoiados por anos de dados histricos estavam vulnerveis. Muitas equipes, que nunca
tiveram um mtodo de anlise profundo ou qualquer histrico de dados, estavam impotentes nas mos de outros que as foravam a se comprometer com entregveis desconhecidos (e muitas vezes completamente irracionais).
* Termo no traduzido devido sua utilizao mais ampla no idioma original (Ingls) pela comunidade de TI no Brasil.
Traduo: nesse contexto de corrida/maratona, significa corrida de velocidade em curta distncia.
Termo no traduzido devido sua utilizao mais ampla no idioma original (Ingls) pela comunidade de TI no Brasil.
Traduo: inicializao.

Minha Busca pela Gesto de Mudana Bem Sucedida

Enquanto isso, a fora de trabalho havia aceitado como norma cronogramas loucos
e comprometimentos de trabalho absurdos. Aparentemente suposto que engenheiros
de software no possuem vida familiar ou social. Se isso parece abusivo, porque !
Eu conheo muitas pessoas cujos comprometimentos com o trabalho causaram danos
irreparveis aos relacionamentos com seus filhos e com outros membros da famlia.
difcil ter compaixo pelo tpico geek desenvolvedor de software. No estado onde moro,
em Washington, nos Estados Unidos, engenheiros de software so a segunda profisso
em renda anual, depois dos dentistas. Como os trabalhadores da linha de montagem
da Ford na segunda dcada do sculo 20 ganhando cinco vezes o salrio mdio dos
EUA ningum se preocupou com a monotonia do trabalho ou com o bem-estar
deles porque eram muito bem remunerados. difcil imaginar o surgimento de sindicatos em reas de trabalho do conhecimento como desenvolvimento de software,
principalmente porque difcil imaginar algum buscando as causas de doenas fsicas
ou psicolgicas que esses desenvolvedores apresentam rotineiramente. Empregadores
mais ricos tm sido capazes de prover benefcios de sade adicionais, como massagens
e psicoterapia, e prover dias de folga ocasionais de sade mental, ao invs de buscar
as causas raiz do problema. Um redator tcnico em uma bem conhecida empresa de
software uma vez me fez um comentrio, No h estigma sobre usar antidepressivos,
todo mundo est tomando! Em resposta a esse abuso, engenheiros de software tendem
a sujeitar-se s demandas, receber seus extravagantes salrios e sofrer as consequncias.
Eu queria romper esse modelo. Eu queria encontrar uma abordagem ganha-ganha
que me permitisse dizer Sim e ainda proteger a equipe promovendo um ritmo sustentvel. Eu queria devolver minha equipe devolver a eles a vida social e familiar
e melhorar as condies que estavam causando problemas de sade relacionados
ao stress em desenvolvedores nos seus vinte e poucos anos. Ento eu decidi tomar uma
posio e tentar fazer alguma coisa em relao a esses problemas.

Minha Busca pela Gesto de Mudana Bem Sucedida


A segunda coisa em minha mente era o desafio de liderar a mudana em grandes
organizaes. Eu havia sido um gerente de desenvolvimento na Sprint PCS e depois
na Motorola. Em ambas as empresas, havia uma necessidade real de negcio de desenvolver um modo mais gil de trabalhar. Mas em ambos os casos eu havia me esforado
para escalar mtodos geis alm de uma ou duas equipes.
Eu no tinha uma posio de poder suficiente em nenhum dos casos para simplesmente impor a mudana em uma grande quantidade de equipes. Eu estava tentando
influenciar a mudana a pedido da liderana snior, mas sem qualquer poder. Foi

Captulo 1 Resolvendo um dilema do Gerente gil

pedido a mim para influenciar colegas a fazerem em suas equipes mudanas similares
s quais eu havia implementado com a minha prpria equipe. As outras equipes resistiram adoo das tcnicas que estavam claramente produzindo melhores resultados
com a minha equipe. Provavelmente havia muitas facetas para essa resistncia, mas o
tema mais comum era o de que a situao de qualquer das outras equipes era diferente;
as tcnicas da minha equipe teriam de ser modificadas e adaptadas s necessidades
alheias. Na metade de 2002, eu havia concludo que aplicar prescritivamente um processo de desenvolvimento de software em uma equipe no funcionava.
Um processo precisa ser adaptado para cada situao especfica. Fazer isso reque
reria liderana ativa em cada equipe. Isto estava muitas vezes em falta. Mesmo com
a liderana certa, eu duvidava que mudanas significativas pudessem acontecer sem
um framework em uso e sem orientao sobre como adaptar o processo para que se
encaixe em diferentes situaes. Sem isso para guiar o lder, coach* ou engenheiro de
processos, qualquer adaptao provavelmente seria imposta subjetivamente, baseada
em crenas supersticiosas. Era muito provvel que isso criaria polmica e objees da
mesma forma que impor um template de processo inadequado.
Eu tinha abordado parcialmente esse problema no livro que eu estava escrevendo
naquele momento, Agile Management for Software Engineering. Eu me perguntava,
Por que o desenvolvimento gil produz resultados econmicos melhores do que as
abordagens tradicionais?. Eu procurei usar o framework da Teoria das Restries4 para
o processo.
Enquanto pesquisava e escrevia o livro, eu percebi que de alguma forma, cada situao era nica. Por que o fator limitante ou o gargalo deveria estar no mesmo lugar
para toda equipe em todo projeto, todo o tempo? Cada equipe diferente: diferente
conjunto de habilidades, capacidades e experincia. Cada projeto diferente: diferente oramento, cronograma, escopo e perfil de risco. E cada organizao diferente:
uma diferente cadeia de valor operando em um diferente mercado, como mostra a
Figura1.1. Ocorreu-me que isto poderia fornecer uma pista para a resistncia mudana. Se as propostas de mudanas s prticas de trabalho e comportamentos no
tivessem um benefcio percebido, as pessoas resistiriam a elas. Se essas mudanas no
afetam o que os membros da equipe percebem como sua restrio ou fator limitante,
ento eles resistiro. Ou seja, mudanas sugeridas fora de contexto sero rejeitadas
pelos trabalhadores que viveram e compreenderam o contexto do projeto.
* Termo no traduzido devido sua utilizao mais ampla no idioma original (Ingls) pela comunidade de TI no Brasil.
Traduo: instrutor, mentor, consultor.
Termo no traduzido devido sua utilizao mais ampla no idioma original (Ingls) pela comunidade de TI no Brasil.
Traduo: padro.

Minha Busca pela Gesto de Mudana Bem Sucedida

Parecia melhor deixar que um novo processo evolusse eliminando um gargalo por
vez. Essa a tese central da Teoria das Restries de Goldratt. Enquanto reconhecia
que tinha muito a aprender, eu senti que havia valor no material e continuei com o
manuscrito originalmente planejado. Eu sabia muito bem que meu livro no fornecia
recomendaes sobre como implementar as ideias em escala, pois oferecia pouca ou
nenhuma recomendao sobre gesto de mudana.
A abordagem de Goldratt, explicada no captulo 16, procura identificar um gargalo
e, em seguida, encontrar maneiras de alivi-lo at que ele no restrinja o desempenho.
Quando isso acontece, um novo gargalo emerge e o ciclo se repete. uma abordagem
iterativa para melhorar o desempenho sistematicamente, identificando e removendo
gargalos.

Fig 1.1!

Equipes possuem
diferentes!

Conjuntos de
Habilidades!
Nveis de Experincia!
Nveis de Capacidade!

Projetos possuem
diferentes!

Oramentos!
Cronogramas!
Escopos!
Pers de Risco!

Organizaes possuem diferentes!


Cadeias de Valor!
Mercados Alvo!

Figura 1.1 Porque metodologias tamanho nico no funcionam

Eu percebi que eu poderia sintetizar essa tcnica com algumas ideias de Lean.
Modelando
o fluxo
de trabalho tamanho
de um ciclonico
de vidano
de desenvolvimento
de software
Figura
1.1 Porque
metodologias
funcionam
como uma cadeia de valor e ento criando um sistema de acompanhamento e visualizao para acompanhar alteraes de estado do trabalho emergente medida que ele
flui atravs do sistema, eu poderia ver os gargalos. A capacidade de identificar um
gargalo o primeiro passo para o modelo por baixo da Teoria das Restries. Goldratt
j tinha desenvolvido uma aplicao da teoria para problemas de fluxo, estranhamente
chamado de Drum-Buffer-Rope. Independentemente da estranheza do nome, percebi
que uma soluo simplificada do Drum-Buffer-Rope poderia ser implementada para o
desenvolvimento de software.
Termo no traduzido devido sua utilizao mais ampla no idioma original (Ingls) pela comunidade de TI no Brasil.
Traduo: Leve.
Termo no traduzido devido sua utilizao mais ampla no idioma original (Ingls) pela comunidade de TI no Brasil.
Traduo: Tambor-Amortecedor-Corda.

Captulo 1 Resolvendo um dilema do Gerente gil

Genericamente, Drum-Buffer-Rope um exemplo de uma classe de solues conhecidas como sistemas puxados. Como veremos no captulo 2, um sistema kanban outro
exemplo de um sistema puxado. Um efeito colateral interessante de sistemas puxados
que eles limitam trabalhos-em-progresso (WIP) para uma quantidade acordada, impedindo assim que os trabalhadores fiquem sobrecarregados. Alm disso, apenas os
trabalhadores no gargalo permanecem totalmente ocupados; os outros devem ter alguma folga. Percebi que sistemas puxados potencialmente poderiam resolver ambos os
meus desafios. Um sistema puxado me permitiria implementar a mudana do processo
de forma incremental, com (eu esperava) resistncia significativamente reduzida e ele
iria facilitar um ritmo sustentvel. Decidi estabelecer um sistema puxado Drum-BufferRope na primeira oportunidade. Eu queria experimentar a evoluo do processo incremental e ver se ele habilitaria ritmo sustentvel e reduziria a resistncia mudana.
A oportunidade chegou no Outono de 2004 na Microsoft, e ela totalmente documentada no estudo de caso no captulo 4.

Do Drum-Buffer-Rope para o Kanban


Implementar uma soluo de Drum-Buffer-Rope na Microsoft funcionou bem. Com
muito pouca resistncia, a produtividade mais que triplicou e os prazos de entrega encolheram em 90 por cento, enquanto que a previsibilidade melhorou em 98 por cento. No
outono de 2005, eu informei os resultados em uma conferncia em Barcelona5 e novamente no inverno de 2006. Meu trabalho chamou a ateno de Donald Reinertsen, que
fez uma viagem especial para visitar-me no meu escritrio em Redmond, Washington.
Ele queria convencer-me que eu tinha todas as peas no lugar para implementar um
sistema kanban completo.
Kan-ban uma palavra japonesa que significa literalmente carto de sinal em
Portugus. Em um ambiente de produo, este carto usado como um sinal para
informar a uma etapa anterior do processo para produzir mais. Aos trabalhadores em
cada etapa do processo no permitido trabalhar a menos que eles sejam sinalizados
com um kanban de uma etapa posterior. Embora eu estivesse ciente desse mecanismo,
eu no estava convencido de que era uma tcnica til ou vivel para aplicao ao trabalho do conhecimento e engenharia de software, especificamente. Eu entendi que um
sistema kanban permitiria um ritmo sustentvel. No entanto, no estava ciente de sua
reputao como um mtodo para a conduo de melhoria de processo incremental.
Eu ignorava o que tinha dito Taiichi Ohno, um dos criadores do Sistema de Produo
Toyota, os dois pilares do Sistema de Produo Toyota so just-in-time e automao
com um toque humano, ou autonomao. A ferramenta usada para operar o sistema

Surgimento do Mtodo Kanban

kanban. Em outras palavras, kanban fundamental para o processo de kaizen (me


lhoria contnua) usado na Toyota. o mecanismo que faz com que ele funcione. Eu
cheguei a reconhec-lo como uma verdade plena atravs de minhas experincias ao
longo de cinco anos que se seguiram.
Felizmente, Don fez um argumento convincente de que eu deveria mudar de implementaes de Drum-Buffer-Rope para um sistema kanban pela razo altamente esotrica de que um sistema kanban faz uma recuperao mais elegante de uma paralisao
no gargalo do que o sistema de Drum-Buffer-Rope. Entender essa idiossincrasia, no
entanto, no importante para que voc possa ser capaz de ler e compreender este livro.
Revisitando a soluo final implementada na Microsoft, percebi que se a tivssemos
concebido como um sistema kanban desde o incio, o resultado teria sido idntico. Foi
interessante para mim que duas abordagens diferentes resultariam no mesmo produto.
Portanto, se o processo resultante foi o mesmo, no me senti compelido a pensar nele
especificamente como uma implementao de Drum-Buffer-Rope.
Desenvolvi uma preferncia pelo termo kanban em relao ao Drum-Buffer-Rope.
Kanban usado em produo Lean (ou o Sistema de Produo Toyota). Este corpo
de conhecimento tem adoo e aceitao muito mais amplas do que a Teoria das
Restries. Kanban, mesmo sendo japons, menos metafrico que Drum-Buffer-Rope.
Kanban era mais fcil de dizer, mais fcil de explicar e se tornou mais fcil de ensinar
e implementar, ento ele pegou.

Surgimento do Mtodo Kanban


Em Setembro de 2006, sa da Microsoft para assumir o departamento de engenharia
de software na Corbis, uma empresa de acervo fotogrfico e de direitos de propriedade
intelectual, com base no centro de Seattle. Encorajado pelos resultados da Microsoft, eu
decidi implementar um sistema puxado kanban na Corbis. Novamente, os resultados
foram encorajadores e levaram ao desenvolvimento da maior parte das ideias apresentadas neste livro. este conjunto ampliado de ideias visualizao de fluxo de trabalho,
tipos de item de trabalho, cadncia, classes de servio, relatrios de gesto especficos
e reviso de operaes que define o mtodo Kanban.
No restante deste livro descrevo o Kanban (com K maisculo) como o mtodo de
mudana evolutiva que utiliza um sistema puxado kanban (com k minsculo), visualizao e outras ferramentas para catalisar a introduo de ideias Lean no desenvolvimento de tecnologia e operaes de TI. O processo evolutivo e incremental.
Kanban permite alcanar o aperfeioamento do processo especfico ao contexto com

Captulo 1 Resolvendo um dilema do Gerente gil

o mnimo de resistncia mudana, mantendo um ritmo sustentvel para os traba


lhadores envolvidos.

Adoo do Kanban pela Comunidade


Em maio de 2007, Rick Garber e eu apresentamos os primeiros resultados da Corbis
na conferncia Lean New Product Development em Chicago para um pblico de cerca
de 55 pessoas. Mais tarde nesse vero, na conferncia Agile 2007, em Washington,
realizei uma sesso aberta para discutir sistemas kanban; cerca de 25 pessoas participaram. Dois dias mais tarde, um dos participantes, Arlo Belshee, deu uma palestra
relmpago, na qual ele compartilhou sua tcnica de Naked Planning6. Verificou-se que
outros tambm haviam implementado sistemas puxados. Um grupo de discusso do
Yahoo! foi formado e cresceu rapidamente para 100 membros. No momento em que
escrevo, ele tem mais de 1000 membros. Vrios dos participantes da sesso aberta firmaram o compromisso de tentar Kanban em seu local de trabalho, muitas vezes com
equipes que haviam se esforado com Scrum. Os pioneiros mais notveis foram Karl
Scotland, Aaron Sanders e Joe Arnold, todos do Yahoo!, que rapidamente levaram o
Kanban para mais de dez equipes em trs continentes. Outro participante notvel na
sesso aberta foi Kenji Hiranabe, que havia desenvolvido solues kanban no Japo.
Logo depois ele escreveu dois artigos sobre o tema para InfoQ7,8 que despertaram muito
interesse e ateno. No outono de 2007 Sanjiv Augustine, autor de Managing Agile
Projects9 e um dos fundadores da Agile Project Leadership Network (APLN), visitou a
Corbis em Seattle e descreveu nosso sistema kanban como o primeiro novo mtodo
gil que observei em cinco anos.
No ano seguinte, no Agile 2008, em Toronto, houve seis apresentaes sobre o uso
das solues kanban em diferentes situaes. Uma delas, de Joshua Kerievsky, da
Industrial Logic, uma empresa de consultoria e treinamento em Extreme Programming,
mostrou como ele tinha evoludo ideias semelhantes para adaptar e melhorar o Extreme
Programming para seu contexto de negcios. Nesse ano, a Agile Alliance entregou o
prmio Gordon Pask a Arlo Belshee e Kenji Hiranabe por suas contribuies para a
comunidade gil. Ambos haviam feito uma visvel contribuio para o surgimento do
Kanban e produzido e comunicado ideias notavelmente semelhantes sobre o assunto.

O Valor do Kanban Contra-intuitivo


De muitas maneiras, o trabalho do conhecimento a anttese de uma atividade de produo repetitiva. Desenvolvimento de software certamente no similar manufatura.

O Valor do Kanban Contra-intuitivo

Os domnios apresentam atributos totalmente diferentes. Manufatura tem pouca variabilidade, enquanto que grande parte do desenvolvimento de software altamente varivel e procura explorar a variabilidade atravs de novidades no projeto a fim de obter
lucro. Software por natureza soft e muitas vezes pode ser alterado de forma fcil
e barata, enquanto que a manufatura tende a centralizar-se em coisas hard que so
difceis de mudar. natural ser ctico sobre o valor dos sistemas kanban no desenvolvimento de software e outros trabalhos em TI. Grande parte do que aprendemos
sobre Kanban ao longo dos ltimos anos, como uma comunidade, contra-intuitivo.
Ningum previu o efeito na cultura corporativa ou a melhora na colaborao multifuncional que ocorreu na Corbis (que descrita no captulo 5). Nestas pginas, espero
mostrar a voc que Kanban pode!. Espero convenc-lo de que, empregando as regras
simples do Kanban, voc pode melhorar a produtividade, a previsibilidade e a satisfao do cliente, bem como reduzir os tempos de entrega. E com tudo isto, a cultura da
sua organizao ir mudar medida que o aumento do trabalho colaborativo ajuda
a estabelecer melhores e mais funcionais relaes de trabalho em toda a organizao.

10

Captulo 1 Resolvendo um dilema do Gerente gil

Takeaways
Sistemas Kanban so da famlia de abordagens conhecidas como sistemas
puxados.
A aplicao Drum-Buffer-Rope por Eliyahu Goldratt da Teoria das Restries
uma implementao alternativa de um sistema puxado.
A motivao para buscar uma abordagem de sistema puxado foi dupla:
encontrar uma maneira sistemtica de obter um ritmo sustentvel de traba
lho e encontrar uma abordagem para introduzir mudanas de processo que
encontrariam resistncia mnima.
Kanban o mecanismo que sustenta o Sistema de Produo Toyota e sua
abordagem kaizen para melhoria contnua.
O primeiro sistema kanban virtual para engenharia de software foi implementado na Microsoft, no incio de 2004.
Os resultados das primeiras implementaes de Kanban foram encorajadores
no que diz respeito a alcanar um ritmo sustentvel, minimizando resistncia
mudana atravs de uma abordagem evolutiva e incremental e produzindo
benefcios econmicos significativos.
O Mtodo Kanban como uma abordagem para mudana comeou a crescer em adoo pela comunidade depois da conferncia Agile 2007 em
Washington, D.C., em agosto de 2007.
Ao longo deste texto, kanban (k minsculo) refere-se aos cartes sinali
zadores e kanban sistema (k minsculo) refere-se ao sistema puxado
implementado com cartes sinalizadores (virtuais).
Kanban (K maisculo) usado para se referir metodologia de melhoria
de processo incremental e evolutiva que surgiu na Corbis de 2006 a 2008
e continuou a evoluir na ampla comunidade de desenvolvimento Lean de
software nos anos seguintes.

C aptulo 2

O que o Mtodo
Kanban?

a primavera de 2005, tive a sorte de ter um perodo de frias em


Tquio, no Japo, no incio de Abril, durante a temporada da
flor de cerejeira. Para aproveitar este espetculo, fiz uma segunda
visita aos Jardins do Oriente, no Palcio Imperial, no centro de
Tquio. Foi l que tive uma revelao kanban no era apenas para
manufatura.
No sbado, 9 de abril de 2005, entrei no parque pela entrada norte,
atravessando a ponte sobre o fosso prxima estao de metr de
Takebashi. Muitos cidados de Tquio estavam aproveitando a oportunidade em uma manh ensolarada de sbado para desfrutar da
tranquilidade do parque e da beleza da sakura (flor de cerejeira).
A prtica de fazer um piquenique sob as cerejeiras, enquanto as flores caem em torno de voc, conhecida como hanami (festa da flor).
uma tradio antiga no Japo uma oportunidade para refletir
sobre a beleza, a fragilidade e o quo curta a vida. A vida breve da
flor de cerejeira uma metfora para a nossa vida e nossa existncia
curta, bonita e frgil no meio a imensido do universo.
A flor de cerejeira contrastava com os edifcios cinzentos do centro de Tquio, sua agitao e pressa, multides pulsantes de pessoas
ocupadas e rudo do trfego. Os jardins eram um osis no corao da
selva de concreto. Assim que eu cruzei a ponte com a minha famlia, um idoso cavalheiro japons com uma mochila sobre seu ombro
11

Captulo 2 O que o Mtodo Kanban?

aproximou-se de ns. Abrindo sua sacola, ele puxou um punhado de cartes plsticos.
Ele ofereceu um para cada um de ns, pausando brevemente para decidir se minha
filha de trs meses presa ao meu peito necessitaria de um carto. Ele decidiu que sim
e entregou-me duas placas. Ele no disse nada e, como meu japons limitado, no
ofereceu nenhuma conversa. Andamos pelos jardins para procurar um local para desfrutar de nosso piquenique em famlia.
Duas horas mais tarde, aps uma agradvel manh ao sol, ns recolhemos nosso
piquenique e fomos em direo sada, no Porto Leste em Otemachi. Assim que
chegamos, entramos em uma fila na frente de um pequeno quiosque. Bem frente, vi
pessoas devolvendo seus cartes plsticos de entrada. Eu
procurei no meu bolso e encontrei os cartes que havia
recebido. Chegando perto do quiosque, vi dentro uma
senhora japonesa perfeitamente uniformizada. Entre ns
havia uma tela de vidro com um buraco em semicrculo
como um guich, muito semelhante a um guich de um
cinema ou parque de diverses. Eu coloquei meus cartes
plsticos no balco atravs do buraco no vidro. A senhora pegou-os com suas mos
com luvas brancas e empilhou-os em um compartimento junto com os outros. Ela
inclinou sua cabea ligeiramente e agradeceu-me com um sorriso. Dinheiro algum foi
entregue. Nenhuma explicao foi dada para porque eu estava carregando dois cartes
de admisso de plstico branco desde a entrada do parque duas horas antes.
O que estava acontecendo com estes bilhetes de admisso? Por que se preocupar em
emitir um bilhete, se nada foi cobrado? Meu primeiro palpite foi que ele devia ser um
esquema de segurana. Contando-se todas as placas devolvidas, as autoridades poderiam assegurar-se de que nenhum visitante perdido permanecesse dentro do parque
quando ele estivesse fechado ao fim do dia. Aps uma rpida reflexo percebi que seria
um sistema de segurana muito pobre. Quem poderia dizer que eu havia recebido dois
cartes em vez de apenas um? Minha filha de trs meses contaria como bagagem ou
como um visitante? Parecia haver muita variabilidade no sistema. Oportunidades demais para erros! Se fosse um esquema de segurana, certamente iria falhar e produzir
falsos positivos todos os dias. (Como uma breve observao, tal sistema no pode
produzir facilmente falsos negativos, pois ele exigiria a
confeco de bilhetes de entrada adicionais. Este um
atributo comum til dos sistemas kanban.) Dessa maneira, haveria tropas em torno dos arbustos todas as noites a procura de turistas perdidos. No, deveria ser outra
coisa. Percebi, ento, que os jardins do Palcio Imperial
estavam usando um sistema kanban!

Fotos cedidas esta pgina Thomas Blomseth

12

Kanban Aplicado ao Desenvolvimento de Software

Esta epifania extremamente esclarecedora me permitiu pensar alm da fabricao


no que diz respeito aos sistemas de kanban. Parecia provvel que tokens* kanban eram
teis para todos os tipos de situaes de gesto.

O que um Sistema Kanban?


Certo nmero de kanbans (ou cartes) equivalente capacidade (em acordo) de um
sistema colocado em circulao. Um carto anexado a um trabalho. Cada carto age
como um mecanismo de sinalizao. Um novo trabalho pode ser iniciado apenas quando
um carto est disponvel. Este carto livre anexado a um trabalho e o segue medida
que ele flui atravs do sistema. Quando no h mais cartes livres, nenhum trabalho
adicional pode ser iniciado. Qualquer novo trabalho deve esperar em uma fila at que
um carto esteja disponvel. Quando algum trabalho for concludo, seu carto liberado
e reciclado. Com um carto agora livre, um novo trabalho da fila pode ser iniciado.
Este mecanismo conhecido como um sistema puxado porque o novo trabalho
puxado para o sistema quando existe capacidade para lidar com ele, em vez de ser
empurrado para o sistema com base na demanda. Um sistema puxado no pode ser
sobrecarregado se a capacidade, conforme determinado pelo nmero de cartes sinalizadores em circulao, tiver sido configurada adequadamente.
Nos Jardins do Palcio Imperial, os prprios jardins so o sistema: os visitantes so os
trabalhos em progresso, e a capacidade limitada pelo nmero de cartes de admisso
em circulao. Os visitantes recm chegados ganham cartes somente quando esto disponveis. Em um dia normal isso nunca um problema. No entanto, nos dias de maior
movimento, como um feriado ou um sbado durante a temporada de flor de cerejeira, o
Parque popular. Quando todos os bilhetes de admisso so entregues, novos visitantes
fazem fila na ponte e aguardam que cartes sejam reciclados assim que visitantes deixam
o local. O sistema kanban fornece um mtodo simples, barato e fcil de ser implementado para controlar o tamanho da multido, limitando o nmero de pessoas dentro do
Parque. Isso permite que os administradores do Parque mantenham os jardins em boas
condies e evitem danos causados por muitos pedestres e superlotao.

Kanban Aplicado ao Desenvolvimento de Software


No desenvolvimento de software, estamos usando um sistema kanban virtual para
limitar o trabalho-em-progresso. Embora kanban signifique carto sinalizador e
* N. de T.: Termo no traduzido devido sua utilizao mais ampla no idioma original (Ingls) pela comunidade de TI no
Brasil. Traduo: sinalizaes.

13

14

Captulo 2 O que o Mtodo Kanban?

no existem cartes utilizados na maioria das implementaes de Kanban no desenvolvimento de software, estes cartes no funcionam realmente como sinais para puxar
mais trabalho. Em vez disso, eles representam itens de trabalho. Da o termo virtual,
porque no h nenhum carto sinalizador fsico. O sinal para puxar o novo trabalho
inferido da quantidade visual dos trabalhos-em-progresso subtrado de algum indicador do limite (ou capacidade). Alguns profissionais aplicaram kanban fsico usando
tcnicas como clipes autocolantes ou slots fsicos em uma placa. Mais frequentemente
o sinal gerado a partir de um sistema de acompanhamento de trabalho em software.
O captulo 6 fornece exemplos da mecnica de sistemas kanban que se aplicam ao
trabalho de TI.
Paredes de cartes se tornaram um mecanismo de controle visual popular no desenvolvimento de software gil, como mostrado na Figura 2.1. Usando um quadro de
aviso de cortia com cartes de ndice fixados em uma placa ou um quadro de comunicaes com notas auto-adesivas para acompanhar os trabalhos em progresso (WIP)
tornou-se comum. Vale a pena observar, nesta fase inicial, que apesar de alguns comentrios da Comunidade em contrrio, estes muros de carto no so inerentemente

Figura 2.1 Um quadro kanban (cortesia da SEP)

Por que Usar um Sistema Kanban?

sistemas kanban. Eles so sistemas de controle visual apenas. Eles permitem s equipes
observarem visualmente os trabalhos em progresso e a se auto-organizarem, atribuindo
suas prprias tarefas e movendo o trabalho de um backlog* para concluso sem orientao de um gerente de projeto ou linha. No entanto, se no houver nenhum limite
explcito para trabalho-em-progresso e uma sinalizao para puxar o novo trabalho
atravs do sistema, ele no um sistema kanban. Isto melhor explicado no captulo 7.

Por que Usar um Sistema Kanban?


Como deve se tornar evidente nos prximos captulos, ns usamos um sistema kanban para limitar o trabalho-em-progresso de uma equipe para definir a capacidade
e equilibrar a demanda sobre a equipe em relao ao rendimento do trabalho entregue. Fazendo isso, podemos conseguir um ritmo sustentvel de desenvolvimento para
que todos os indivduos possam alcanar um equilbrio entre trabalho e vida pessoal.
Como voc ver Kanban tambm elimina rapidamente os problemas que prejudicam
o desempenho e desafia uma equipe a se concentrar em resolver esses problemas para
manter um fluxo constante de trabalho. Ao fornecer visibilidade para problemas de
qualidade e de processos, torna bvio o impacto de defeitos, gargalos, variabilidade
e custos econmicos no fluxo e na vazo. O simples ato de limitar o trabalho-em-progresso com o kanban incentiva maior qualidade e maior desempenho. A combinao de fluxo aperfeioado e melhor qualidade ajuda a reduzir os prazos de entrega
e a melhorar o desempenho da data de entrega e a previsibilidade. Ao estabelecer uma
cadncia regular de liberao e entregando consistentemente, Kanban ajuda a construir a confiana com os clientes e confiana ao longo da cadeia de valor com outros
departamentos, fornecedores e parceiros.
Ao fazer tudo isso, Kanban contribui para a evoluo cultural das organizaes.
Ao expor problemas, fazendo com que uma organizao d enfoque em resolv-los e
eliminando seus efeitos no futuro, Kanban facilita o surgimento de uma organizao altamente colaborativa, de alta confiana, altamente habilitada, e em constante melhoria.
Kanban tem mostrado melhorar a satisfao do cliente atravs de entregas regulares, confiveis e de alta qualidade de software de alto valor. Ele tambm tem mostrado
aumentar a produtividade, qualidade e prazos de entrega. Alm disso, h evidncias
de que kanban um catalisador fundamental para o surgimento de uma organizao
mais gil atravs de mudana cultural evolutiva.

* N. de T.: Termo no traduzido devido sua utilizao mais ampla no idioma original (Ingls) pela comunidade de TI no
Brasil. Traduo: itens de trabalho em espera.

15

16

Captulo 2 O que o Mtodo Kanban?

O restante deste livro dedicado a ajud-lo a entender como usar sistemas kanban
no desenvolvimento de software e para ensin-lo a implementar um sistema desse tipo
para obter esses benefcios com a sua equipe.

Kanban em Ao
Na edio original deste livro em Ingls, o desenho na Figura 2.2 aparece na capa do
livro. Este desenho foi encomendado especialmente para o livro e ilustra o Mtodo
Kanban em ao.
No desenho podemos ver uma pequena equipe de trabalhadores do conhecimento
numa reunio diria em frente a um quadro branco. O quadro mostra o fluxo de
trabalho e o trabalho-em-progresso atual da equipe. evidente que a atividade de
testes est faminta. Enquanto isso a atividade de anlise est bastante carregada com
trabalho incompleto. A discusso entre os membros da equipe reala isto. Enquanto
um membro da equipe est ocioso, outro est completamente sobrecarregado e outro
est parado esperando pela resoluo de um item de bloqueio. O sistema kanban com
limite de WIP est certamente estimulando esta conversa. Com limites restritos de
trabalho-em-progresso, os testadores ficaro ociosos se a atividade de desenvolvimento
no for finalizada em tempo hbil.
Um quarto membro da equipe est falando e mostra uma postura de liderana. O
sistema kanban est realando um problema; membros da equipe esto discutindo o
problema; e um quarto membro os est encorajando a fazer algo em relao a isso.
O desenho mostra vrios aspectos do Mtodo Kanban em ao. O fluxo de trabalho
da equipe est visvel e um sistema kanban com limite de trabalho-em-progresso; isto
serve para realar problemas e provocar discusses. Combinado com uma ao de
liderana, e um entendimento de problemas de processo que ocorrem comumente, a
equipe pode discutir os problemas abertamente e sugerir melhorias no processo.
Como voc aprender na parte 4, a equipe pode utilizar um conhecimento de modelos tericos para avaliar problemas no processo e sugerir melhoria, isto demonstra uso
de mtodo cientfico. Modelos permitem antecipar os resultados de qualquer mudana
que seja implementada. Os resultados podem ser observados durante dias e semanas
e comparados com as expectativas.
A parte 4 explica modelos baseados em Lean, Teoria das Restries e o System of
Profound Knowledge. Quando a equipe tem conhecimento nesses modelos, junto a uma
evidncia visual, ela negocia mudanas no processo e forma um consenso em relao
ao que deve ser feito.
De maneira geral a Figura 2.2 retrata a essncia do Mtodo Kanban. Ela ilustra uma
cultura kaizen - uma organizao focada na melhoria contnua, trabalhando colaborativamente para melhorar seu desempenho e capacidade.

Kanban como um Sistema Complexo Adaptvel para Lean

Figura 2.2 Essncia do mtodo Kanban

Um Modelo para o Mtodo Kanban


A fim de documentar o mtodo Kanban em um livro, acredito que necessrio descrever formalmente o modelo. Como Kanban foi surgindo da prtica e evoluindo ao
longo dos ltimos quatro anos, eu nunca havia pensado em fazer essa definio at
agora. Preocupa-me que pode se tornar esttico e pessoas se tornaro dogmticas em
seu pensamento, citando o modelo como a verdadeira fonte para a excelncia do processo kanban ou us-lo como um teste para Estamos praticando Kanban?. Espero
que quando eu tentar definir Kanban, eu tambm consiga encorajar voc a abrir a
sua mente para a ideia de que nosso aprendizado continuar a evoluir, e ao invs de
citar esta seo deste livro, voc vai procurar uma definio contempornea na web na
Limited WIP Society (www.limitedwipsociety.org).

Kanban como um Sistema Complexo Adaptvel para Lean


O mtodo Kanban introduz um sistema complexo adaptvel cujo objetivo catalisar
um resultado Lean dentro de uma organizao. Sistemas complexos adaptveis tm
condies iniciais e regras simples que so necessrias para semear comportamento
emergente complexo e adaptvel. Neste caso, o resultado desejado uma Cultura

17

18

Captulo 2 O que o Mtodo Kanban?

Kaizen - uma organizao focada em melhoria contnua que leva tanto a um melhor
resultado econmico para o negcio, como a um melhor resultado sociolgico para os
funcionrios. Kanban usa cinco propriedades fundamentais como condies iniciais
para estimular um conjunto emergente de comportamentos Lean. Em organizaes
que desejam como resultado uma cultura de melhoria contnua, eu tenho observado
que todas as cinco propriedades principais esto presentes:
1. Visualize o Fluxo de Trabalho
2. Limite Trabalho-em-Progresso
3. Mea e Gerencie o Fluxo
4. Torne as Polticas do Processo Explcitas
5. Use Modelos* para Reconhecer Oportunidades de Melhoria
Com estas cinco propriedades em ao, os atos de liderana como o apresentado na
Figura 2.2 catalisam mudanas de processo e levam ao surgimento de novos comportamentos que geram o resultado econmico e sociolgico desejados.

Comportamento Emergente com Kanban


H uma lista crescente de comportamentos emergentes que podemos esperar com
implementaes Kanban. Alguns ou todos eles tm surgido na maioria das implementaes recentes; todos eles surgiram na Corbis durante 2007. Esperamos que esta
lista continue a crescer medida que aprendemos mais sobre os efeitos do Kanban nas
organizaes.
1. Processo adaptado para cada projeto/cadeia de valor
2. Cadncias Independentes (ou Desenvolvimento sem Iteraes)
3. Trabalho Agendado por (oportunidade) Custo do Atraso
4. Valor otimizado com Classes de Servio
5. Risco Gerenciado com Capacidade de Alocao
* Modelos comuns em uso com Kanban incluem a Teoria das Restries, Pensamento Sistmico (System Thinking), uma
compreenso de variabilidade atravs dos ensinamentos de W. Edwards Deming e o conceito de muda (desperdcio) do
Sistema de Produo Toyota. Os modelos usados com Kanban evoluem continuamente e ideias de outros campos de
conhecimento como sociologia, psicologia e gerenciamento de riscos esto surgindo em algumas implementaes.

Takeaways
Kanban como um Doador de Permisses
19

6. Tolerncia para um Processo de Experimentao


7. Gerenciamento Quantitativo
8. Propagao Viral (de Kanban) por toda a Organizao
9. Equipes pequenas agrupam-se para formar pools de trabolho mais flexiveis

Kanban como um Doador de Permisses


Kanban no uma metodologia de ciclo de vida para desenvolvimento de software ou
uma abordagem de gerenciamento de projetos. Ele requer que algum processo j esteja
em vigor de maneira que Kanban possa ser aplicado para alterar incrementalmente o
processo base.
Esta abordagem evolutiva, promovendo mudana incremental, tem sido controversa
na comunidade de desenvolvimento gil de software. controversa porque ela sugere
que as equipes no devem adotar um modelo de processo ou mtodo definido. Uma
indstria de servios e ferramentas se desenvolveu em torno de um pequeno conjunto
de prticas definidas em dois mtodos populares de desenvolvimento gil. Agora com
Kanban, indivduos e equipes podem ser habilitados a desenvolver suas prprias solues nicas de processo que desviam da necessidade de tais servios e exigem um
novo conjunto de ferramentas. Na verdade, Kanban incentivou uma nova onda de
fornecedores de ferramentas rebeldes e ansiosos para deixar para trs as ferramentas
de gerenciamento gil de projetos existentes com algo mais visual e programvel que
pode ser facilmente adaptado para um fluxo de trabalho especfico.
No incio do desenvolvimento gil de software, os lderes da comunidade muitas vezes no entendiam por que seus mtodos funcionavam. Ns falvamos sobre
ecossistemas10e aconselhvamos aos implementadores que seguissem todas as prticas ou a soluo provavelmente falharia. Nos ltimos anos tem havido uma tendncia
negativa que estende esse pensamento. Algumas empresas tm publicado Modelos de
Maturidade gil que visam avaliar a adoo de prticas. A comunidade de Scrum tem
um teste baseado em prtica muitas vezes referido como o Nokia Test11.Estas avaliaes baseadas em prticas so projetadas para induzir conformidade e negar necessidade de adaptao baseada em contexto. Kanban est dando ao mercado a permisso
de ignorar esses esquemas de avaliao baseada em prticas. encorajar ativamente a
diversidade.
Em 2007, vrias pessoas visitaram meu escritrio na Corbis para ver Kanban em
ao. A pergunta comum de qualquer visitante associado com a comunidade de desenvolvimento gil de software poderia ser parafraseada como, David, temos andado

20

Captulo 2 O que o Mtodo Kanban?

pelo seu edifcio e vimos sete quadros kanban. Cada um diferente! Cada equipe est
seguindo um processo diferente! Como voc consegue lidar com essa complexidade?
Minha resposta era sempre um desdenhoso claro! A situao de cada equipe diferente. Elas evoluem seu processo para encaixar em seu contexto. Mas eu sabia que
esses processos foram derivados dos mesmos princpios porque os membros da equipe
compreenderam os princpios bsicos, e, portanto, eram capazes de se adaptar ao serem
transferidos de uma equipe para outra.
Como mais pessoas tm tentado Kanban, elas perceberam que ele ajuda a resolver
os problemas que encontraram com a gesto de mudana em suas organizaes.
Kanban permitiu s suas equipes, projeto ou organizao mostrar melhor agilidade.
Reconhecemos que Kanban est dando permisso ao mercado para criar um processo
sob medida e aperfeioado para um contexto especfico. Kanban dar s pessoas permisso para pensar por si mesmas. Ele est dando s pessoas permisso para serem
diferentes: diferentes da equipe no mesmo andar, no outro andar, no edifcio ao lado e
em uma empresa vizinha. Ele est dando s pessoas permisso para se afastar do livro-texto. O melhor de tudo,
Kanban est fornecendo as ferramentas que nos permitem explicar (e justificar) porque melhor ser diferente e
porque uma escolha diferente a escolha certa nesse contexto. Para enfatizar esta escolha, eu projetei uma camiseta para a Limited WIP Society, inspirado pelo pster de
Shepard Fairey para a campanha de Obama e exibindo o
rosto de Taiichi Ohno, o criador do sistema kanban na
Toyota. O slogan Yes We Kanban projetado para enfatizar que voc tem permisso. Voc tem permisso para
limitedwipsociety.org
tentar Kanban. Voc tem permisso para modificar seu
processo. Voc tem permisso para ser diferente. Sua situao nica e voc merece
desenvolver uma definio de processo nico, sob medida e aperfeioado para seu
domnio, sua cadeia de valor, os riscos que voc gerencia, as competncias da sua
equipe e as exigncias dos seus clientes.

YES WE KANBAN

Takeaways
21

Takeaways
Sistemas Kanban podem ser usados em qualquer situao em que h um
desejo de limitar a quantidade de coisas dentro de um sistema.
Os Jardins do Palcio Imperial em Tquio usam um sistema kanban para
controlar o tamanho da multido dentro do parque.
A quantidade de cartes de sinalizao kanban em circulao limita o trabalho-em-progresso.
Um novo trabalho puxado para dentro do processo assim que um carto
de sinalizao retorna no momento em que uma tarefa ou pedido tem seu
trabalho em curso concludo.
No trabalho de TI estamos (geralmente) usando um sistema de kanban
virtual j que nenhum carto fsico de fato circula para definir o limite de
trabalho-em-progresso.
Paredes de carto comuns no desenvolvimento gil de software no so sistemas kanban.
Sistemas kanban criam uma tenso positiva no ambiente de trabalho que
fora a discusso sobre os problemas.
O Mtodo Kanban (ou Kanban com K maisculo) utiliza um sistema kanban como catalisador de mudana.
Kanban requer que as polticas do processo sejam explicitamente definidas.
Kanban usa ferramentas de vrias reas do conhecimento para encorajar
anlise dos problemas e descoberta de solues.
Kanban possibilita a melhoria incremental do processo atravs da descoberta
repetitiva dos problemas que afetam o desempenho do processo.
Uma definio contempornea do Mtodo Kanban pode ser encontrada on-line no web site da Limited WIP Society, www.limitedwipsociety.org.
Kanban est agindo como um doador de permisso na profisso de desenvolvimento de software, encorajando as equipes a elaborar solues de processo
especficas ao contexto em vez de seguir dogmaticamente uma definio de
processo de ciclo de vida de desenvolvimento de software ou um template.


PARTE DOIS

Benefcios do Kanban

C aptulo 3

Uma Receita
para o Sucesso

urante toda a dcada passada fui desafiado a responder a


seguinte pergunta: Como um gerente, que medidas devem ser
tomadas quando se herda uma equipe j existente, especialmente uma
que no funciona de forma gil, com habilidades diversas, e que talvez
seja completamente disfuncional? Normalmente fui colocado em cargos de gesto como um agente de mudana, sendo desafiado a criar
uma mudana positiva e progredir rapidamente, dentro de dois ou
trs meses.
Atuando como gerente em grandes organizaes, eu nunca contratei o meu prprio time. Eu sempre fui convidado a liderar uma equipe
existente e, com alteraes mnimas de pessoal, criar uma revoluo
no desempenho da organizao. Acredito que esta situao muito
mais comum do que aquela onde voc comea contratando um time
inteiro novo.
Eu gradualmente evolu uma abordagem para gerenciar mudanas; ela baseada em experincias, incluindo aprendizado atravs
de falhas. As falhas resultaram das minhas tentativas de impor um
processo e um fluxo de trabalho para a equipe. A verdade que ordens gerenciais tendem a falhar. Quando pedi s equipes para mudar
seu comportamento e usar um mtodo gil como Feature Driven
Development, encontrei resistncia. Sugeri que ningum deveria
ter receio, pois eu iria proporcionar-lhes a formao e a orientao
25

26

Captulo 3 Uma Receita para o Sucesso

necessrias. Eu tinha a aquiescncia na melhor das hipteses, e no uma verdadeira,


profunda, institucionalizao da mudana. Pedir para as pessoas mudarem seu comportamento gera medo e baixa a auto-estima, pois esse pedido d a entender que as
habilidades existentes so claramente desvalorizadas.
Eu desenvolvi o que eu vim a chamar a minha Receita para o Sucesso para abordar
estas questes. A Receita para o Sucesso apresenta diretrizes para um novo gerente liderar uma equipe existente. Seguir a receita permite melhora rpida com baixos nveis
de resistncia da equipe. Eu quero agradecer a influncia direta de Donald Reinertsen
para as duas primeiras e a ltima etapa da receita e a influncia indireta de Eli Goldratt,
cujos escritos sobre a Theory of Constraints e o seu Five Focusing Steps muito influenciaram as etapas quatro e cinco.
Os seis passos da receita so:
Foco na qualidade
Reduzir Trabalho-em-Progresso
Entregar Frequentemente
Equilibrar a Demanda e Rendimento
Priorizar
Atacar Fontes de Variabilidade para Melhorar a Previsibilidade

Implementando a Receita
A Receita entregue na sequncia de execuo para um gerente de funo tcnica. O
foco na qualidade vem em primeiro lugar, porque est sob a influncia e o controle
exclusivos de um gerente, como um gerente de desenvolvimento ou de teste, ou o
supervisor do gerente, com um cargo como Diretor de Engenharia. medida que a
lista continua, necessrio cada vez menos controle e mais colaborao com outros
grupos de diferentes nveis organizacionais, at a etapa Priorizar. Priorizao justamente o trabalho do setor de negcios, e no da organizao de tecnologia, e por isso
no deveria ser da competncia do gerente tcnico. Infelizmente, comum a gesto
de negcios abdicar dessa responsabilidade e deixar um responsvel tcnico priorizar
o trabalho e depois culp-lo por fazer ms escolhas. Atacar Fontes de Variabilidade
para Melhorar a Previsibilidade a ltima etapa da lista, porque alguns tipos de variabilidade exigem mudanas comportamentais, a fim de reduzi-las. Pedir s pessoas
para mudarem de comportamento difcil! Assim, melhor atacar a variabilidade

Implementando a Receita

por ltimo at que a situao melhore a partir da obteno de algum sucesso com as
etapas anteriores. Como veremos no captulo 4, s vezes necessrio analisar as causas
da variabilidade, a fim de permitir que alguns desses passos anteriores aconteam. O
truque escolher as fontes de variabilidade que requerem pouca mudana comportamental que pode ser facilmente aceita.
Focar na qualidade mais fcil porque uma disciplina tcnica que pode ser orientada pelo gerente funcional. As outras etapas so mais desafiadoras, por dependerem
de acordo e colaborao de outras equipes, exigindo habilidades de articulao, negociao, psicologia, sociologia e inteligncia emocional. Construir o consenso em torno
da necessidade de Equilibrar a Demanda e o Rendimento crucial. Resolver problemas
de disfuno entre os papis e as responsabilidades dos membros da equipe exige ainda
maior capacidade de diplomacia e negociao. Faz sentido, ento, ir atrs do que est
diretamente sob seu controle e que voc sabe que ter um efeito positivo tanto na sua
equipe, como no desempenho do seu negcio.
Desenvolver um maior nvel de confiana com outros times pode ajudar a lidar com
assuntos mais difceis. Construir e apresentar cdigo de alta qualidade com poucos defeitos aumenta a confiana. Liberar cdigo de alta qualidade com regularidade constri
ainda mais confiana. O aumento do nvel de confiana possibilita que o gerente ganhe
mais capital poltico. Isso permite um movimento para a prxima etapa da receita. Em
ltima anlise, a sua equipe vai ganhar respeito suficiente para que voc seja capaz de
influenciar os donos do produto, sua equipe de marketing, e patrocinadores do negcio para que mudem de comportamento e colaborem para priorizar o trabalho mais
valioso a ser desenvolvido.
Atacar as fontes de variabilidade para melhorar a previsibilidade difcil. No deve
ser realizada at que a equipe j esteja trabalhando num nvel mais maduro e tenha me
lhorado muito. Os quatro primeiros passos na receita tero um impacto significativo.
Eles traro sucesso para um novo gerente. No entanto, para realmente criar uma cultura
de inovao e melhoria contnua, ser necessrio atacar as fontes de variabilidade no
processo. Portanto, o passo final na receita um crdito extra: o passo que separa os
verdadeiramente grandes lderes tcnicos dos gestores meramente competentes.

Foco na Qualidade
O Manifesto gil no diz nada sobre qualidade, embora os princpios por detrs do
Manifesto12 falam sobre perfeio, havendo, dessa maneira, um foco implcito em qualidade. Ento, se a qualidade no aparece no Manifesto, porque ela a primeira etapa na
minha receita para o sucesso? Simplificando, uma quantidade excessiva de defeitos o

27

28

Captulo 3 Uma Receita para o Sucesso

maior desperdcio no desenvolvimento de software. Os nmeros so impressionantes


e mostram vrios nveis de variao de magnitude. O relatrio Capers Jones13 em 2000,
durante a bolha dot-com, mediu a qualidade do software das equipes norte-americanas
e o nmero variou de 6 defeitos por ponto de funo para menos de 3 defeitos por 100
pontos de funo, um intervalo de 200 para 1. O ponto mdio de aproximadamente 1
defeito por 0.6 a 1.0 pontos de funo. Isto implica que comum que as equipes gastem
mais de 90 por cento do seu esforo corrigindo defeitos. Como prova direta disso, no
final de 2007, Aaron Sanders, um dos primeiros defensores do Kanban, relatou, na lista
de discusso Kanbandev Yahoo! que uma equipe com a qual estava trabalhando estava
gastando mais de 90 por cento de sua capacidade disponvel na correo de defeitos.
Incentivar a qualidade desde o incio ter um grande impacto sobre a produtividade
e o rendimento das equipes com altas taxas de defeitos. Uma melhoria de duas a quatro
vezes no rendimento um nmero razovel. Com equipes realmente ruins, uma me
lhoria de dez vezes pode ser possvel, focando-se na qualidade.
O problema da melhoraria na qualidade de software bem conhecido.
Tanto o desenvolvimento gil como as abordagens tradicionais de qualidade tm
o seu mrito. Elas devem ser usadas em combinao. Profissionais de teste devem
testar. Usar testadores para encontrar defeitos impede que os defeitos escapem para o
cdigo em produo. Pedir para que os desenvolvedores escrevam testes unitrios e
automatize-os para a execuo de testes de regresso automatizados tambm tem efeito
surpreendente. Parece haver uma vantagem psicolgica quando se pede aos desenvolvedores que escrevam os testes primeiro. O Test Driven Development (TDD) parece
fornecer a vantagem de que a cobertura do teste seja mais completa. importante
ressaltar que times bem disciplinados que eu gerenciei e que escreveram testes aps a
codificao funcional, demonstraram liderana de qualidade na indstria. No entanto,
parece evidente que, para equipes mdias, insistir em escrever os testes primeiro, isto
, antes da codificao funcional, melhora a qualidade.
Inspees de cdigo melhoram a qualidade. Quer sejam realizadas com programao em pares, peer review, code walkthroughs ou inspees Fagan completas, inspees de cdigo funcionam. Elas ajudam a melhorar a qualidade interna e externa
do cdigo. Inspees de cdigo tm um resultado melhor se realizadas muitas vezes e
em pequenos lotes. Eu encorajo as equipes a inspecionar o cdigo todo dia, por pelo
menos, 30 minutos.
Anlise colaborativa e projeto melhoram a qualidade. Quando as equipes so
convidadas a trabalhar em conjunto para analisar os problemas e solues de projeto,
a qualidade superior. Eu encorajo as equipes a realizar anlise colaborativa e sesses
de modelagem de projeto com toda a equipe. Modelagem de projeto deve ser realizada
em pequenos lotes todo dia. Scott Ambler chamou isso de Modelagem gil14.

Implementando a Receita

Uso de padres de projeto melhora a qualidade. Padres de projeto capturam solues conhecidas para problemas conhecidos. Padres de projeto garantem que mais
informao estar disponvel no incio do ciclo de vida e que os defeitos de projeto so
eliminados.
Uso de ferramentas de desenvolvimento modernas melhora a qualidade. Muitas
ferramentas modernas incluem funes para executar anlise de cdigo esttica e dinmica. Essas funes devem ser utilizadas e ajustadas para cada projeto. Essas ferramentas de anlise podem impedir que programadores cometam erros elementares, como a
introduo de problemas bem conhecidos, como falhas de segurana.
Ferramentas modernas mais exticas de desenvolvimento, tais como Software
Product Lines (ou Fbricas de Software) e Linguagens de Domnio Especfico reduzem
defeitos. As fbricas de software podem ser utilizadas para encapsular os padres de
projeto, como fragmentos de cdigo, reduzindo o potencial de insero de defeitos
no cdigo. Elas tambm podem ser utilizadas para automatizar tarefas repetitivas de
codificao, novamente, reduzindo o potencial de insero de defeitos no cdigo. O
uso de fbricas de software tambm reduz a demanda de inspees de cdigo, visto
que o cdigo gerado por essas ferramentas no precisa ser re-inspecionado, ele tem
uma qualidade embutida.
Algumas dessas ltimas sugestes realmente se enquadram na categoria de reduo
da variabilidade no processo. O uso de fbricas de software, e talvez at mesmo os
padres de projeto, fazem com que os desenvolvedores mudem de comportamento. A
grande sacada vem da utilizao de testadores profissionais, da escrita de testes no incio, da automao dos testes de regresso, e de inspees de cdigo. E mais uma coisa...
Reduzir a quantidade de projeto-em-progresso aumenta a qualidade do software.

Reduzir Trabalho-em-Progresso e Entregar Frequentemente


Em 2004 eu estava trabalhando com duas equipes na Motorola. Ambas as equipes estavam desenvolvendo cdigo para um servidor de aplicaes de celular. Uma equipe estava
trabalhando no download over-the-air (OTA) de ringtones, jogos e outras aplicaes e
dados do servidor. A outra equipe estava desenvolvendo o dispositivo gerenciador over-the-air no servidor. Ambas as equipes estavam usando a metodologia Feature Driven
Development (FDD). Ambas as equipes tinham aproximadamente o mesmo tamanho cerca de oito desenvolvedores, um arquiteto, no mximo cinco testadores, e um gerente
de projeto. Trabalhando em conjunto com o pessoal de marketing, as equipes foram
responsveis pela anlise e projeto. Alm disso, havia equipes que trabalhavam com

29

Captulo 3 Uma Receita para o Sucesso

projeto centrado na experincia do usurio e equipes responsveis pela documentao


do usurio (redao tcnica) que prestavam servios para ambas as equipes do projeto.
WIP, Lead Time, e Defeitos

A Figura 3.1 apresenta um diagrama de fluxo cumulativo do projeto da equipe de


download OTA. Um diagrama de fluxo cumulativo um grfico de rea que representa a quantidade de trabalho em um determinado estado. Os estados indicados neste
grfico so: inventrio, que significa fila a iniciar; iniciado, que significa que os
requisitos para a funcionalidade foram explicados para os desenvolvedores; projetado,
que significa especificamente que um diagrama de sequncia UML foi elaborado para
a funcionalidade; codificado, que significa que os mtodos do diagrama de sequncia
foram implementados, e completo, que significa que todos os testes unitrios foram
executados com sucesso, que o cdigo foi revisado, e que o lder dos desenvolvedores
aceitou o cdigo e o promoveu para testes.
A primeira linha do grfico mostra o nmero de funcionalidades para o escopo do
projeto. O escopo foi entregue em dois lotes para os donos do negcio. A segunda linha
mostra a quantidade de funcionalidades iniciadas. A terceira linha mostra a quantidade
de funcionalidades projetadas. A quarta mostra a quantidade implementada, e a quinta
linha mostra a quantidade de funcionalidades
concludas e prontas para testes.
Fig 3.1
Project B Cumulative Flow
175
150

Features

125
100
75
50

Mdia Lead Time!

25

11-Mar

26-Feb

12-Feb

29-Jan

15-Jan

1-Jan

18-Dec

4-Dec

20-Nov

6-Nov

23-Oct

9-Oct

30

Time
Inventory

Started

Designed

Coded

Complete

Figura 3.1 Diagrama de fluxo cumulativo da equipe de Download OTA outubro de 2003 a inverno de 2004

Figura 3.1 Diagrama de uxo cumula4vo da equipe de Download OTA outubro de 2003 a
inverno de 2004

Implementando a Receita

A distncia vertical entre a segunda e quinta linhas em um determinado dia mostra


a quantidade de trabalho-em-progresso, enquanto que a distncia horizontal entre a
segunda e a quinta linhas mostra o tempo mdio entre o inicio e fim de uma funcionalidade (lead time). importante notar que a distncia horizontal um tempo mdio,
e no um lead time especfico para uma funcionalidade especfica. O diagrama de
fluxo cumulativo no controla funcionalidades especficas. A quinquagsima quinta
funcionalidade iniciada poderia ser a trigsima funcionalidade concluda. No existe
nenhuma associao entre uma linha sobre o eixo-y e uma funcionalidade especfica
no backlog.
Faltou disciplina equipe trabalhando no download ou talvez a equipe no tenha
comprado a ideia de usar o mtodo FDD. Eles no trabalharam de forma colaborativa,
como exige a FDD. Eles distriburam grandes quantidades de funcionalidades para
desenvolvedores individuais. Normalmente, eles tinham dez funcionalidades em progresso por desenvolvedor a qualquer momento. A equipe desenvolvendo o dispositivo
gerenciador over-the-air no servidor seguiu o mtodo segundo sua definio. Eles trabalharam bem colaborativamente. Eles desenvolveram testes unitrios para 100 por
cento das funcionalidades. E o mais importante, eles trabalharam em pequenos lotes
de funcionalidades por vez, normalmente de cinco a dez funcionalidades em progresso
para toda a equipe em qualquer perodo de tempo. Como referncia, uma funcionalidade em FDD costuma representar cerca de 1.6 a 2.0 pontos de funo de cdigo.
A equipe do servidor de download OTA obteve um tempo mdio por unidade de
trs meses a partir do incio at a concluso de uma funcionalidade para entrega
equipe em Seattle, Washington, a fim de testar a integrao em Champaign, Illinois,
como apresentado na figura 3.1. A equipe desenvolvendo o dispositivo gerenciador
OTA teve um tempo mdio por unidade de 5-10 dias, como ilustrado na Figura 3.2. A
diferena na qualidade inicial, medida pela quantidade de defeitos escapados nos testes
de sistema ou nos teste de integrao, foi superior a 30 vezes entre as duas equipes. A
equipe desenvolvedora do dispositivo gerenciador OTA produziu com uma qualidade
inicial superior da indstria, com dois ou trs defeitos para cada 100 funcionalidades,
enquanto que a equipe do servidor de download OTA obteve um desempenho mdio
da indstria com cerca de dois defeitos por funcionalidade.
Podemos ver a partir da anlise dos grficos que a quantidade de trabalho-em-progresso est diretamente relacionada ao lead time. A Figura 3.2 mostra claramente
que o lead time mdio diminui quando a quantidade de trabalho em progresso diminui.
No ponto mais alto, o tempo mdio de doze dias. Mais tarde no projeto, com menos
trabalho em progresso , o tempo de espera mdio cai para apenas quatro dias.
H uma relao de causa e efeito entre a quantidade de trabalho em progresso e
lead time mdio, e esta relao linear. Na indstria de transformao, essa relao

31

Captulo 3 Uma Receita para o Sucesso


Fig3.2!

240
220
200
180
160
140
120
100
80
60
40
20
0

Mdia Lead Time!

30
-M
ar

23
-M
ar

16
-M
ar

9M
ar

2M
ar

eb
24
-F

eb

WIP!

17
-F

eb

Features

Device Management Ike II Cumulative Flow

10
-F

32

Time
Inventory

Started

Designed

Coded

Complete

Figura
3.2 Diagrama
de fluxo
cumulativo
da equipe
do de
dispositivo
gerenciador
Figura
3.2 Diagrama
de fluxo cumulativo
da equipe
do dispositivo gerenciador
OTA inverno
2004
OTA inverno de 2004

conhecida como Littles Law. As evidncias obtidas nas duas equipes da Motorola
sugerem existir uma correlao entre o aumento do lead time e um decrscimo na qualidade. Lead times mais longos parecem estar associados com uma significativa piora
na qualidade. De fato, um lead time mdio de aproximadamente 6 vezes e meia maior
resultou em um aumento de 30 vezes no nmero de defeitos iniciais. Maiores lead times
so resultado de maiores quantidades de trabalho em progresso . Assim, o ponto de
nivelamento gerencial para a melhoria da qualidade reduzir a quantidade de trabalho
em progresso . Quando descobri isto, passei a gerenciar o trabalho em progresso como
meio de controle da qualidade e me convenci da relao entre o WIP (Work In Progress)
e qualidade inicial. No entanto, atualmente no h provas cientficas para apoiar este
resultado observado empiricamente.
Reduzir o trabalho em progresso, ou encurtar o tamanho de uma iterao, impactar significativamente na qualidade inicial. Parece que a relao entre a quantidade
de trabalho em progresso e qualidade inicial no linear, ou seja, defeitos aumentam
desproporcionalmente ao aumento da quantidade de WIP. Portanto, faz sentido que
as iteraes de duas semanas sejam melhores do que as iteraes de quatro semanas e
que iteraes de uma semana sejam ainda melhores. Iteraes menores conduziro a
um aumento da qualidade.
Seguindo a lgica dos elementos apresentados, faz ainda mais sentido simplesmente limitar o WIP usando um sistema kanban. Se soubermos que a gesto do WIP

Implementando a Receita

aumentar a qualidade, porque no introduzir polticas explcitas para limit-lo, libertando assim os gerentes para que se concentrem em outras atividades?
Devido estreita interao entre o trabalho em progresso e qualidade, a etapa 2 da
receita deve ser implementada junto, ou logo aps a primeira etapa.
Quem melhor?

Durante a semana de comemorao do Natal no ano de 2003, eu me reuni com a


equipe de download OTA e comentei com o lder de equipe que havia muito trabalho
em progresso, que o lead time estava muito longo, e que poucas coisas eram realmente
concludas. Eu compartilhei minha preocupao pela piora na qualidade que resulta
disso. Ele considerou o meu conselho e em Janeiro de 2004 introduziu algumas alteraes forma como a equipe trabalhava. O resultado foi uma reduo no WIP em 2004
e um lead time comprovadamente mais curto. Tais mudanas, porm, vieram tarde
demais para impedir a equipe de criar um grande nmero de defeitos.
Embora o diagrama sugira que o projeto foi concludo em meados do ms de Maro
de 2004, a equipe continuou trabalhando no software at meados de Julho do mesmo
ano. Metade da equipe de download OTA foi removida de seus projetos originais para
ajudar a corrigir os defeitos. Em Julho de 2004, o gerente geral de negcios da unidade
declarou o produto completo, apesar de haver frequentes preocupaes relacionadas
qualidade. O produto foi entregue equipe de campo de engenharia. Durante a implantao, aproximadamente 50 por cento dos clientes cancelaram as entregas devido
a preocupaes com a qualidade. A equipe de campo de engenharia, apesar de manter
boas relaes pessoais com a equipe de engenharia do produto, tinha por estes um
baixo nvel de respeito profissional, alm de falta de confiana na capacidade da equipe.
Sua opinio era de que o produto era de m qualidade e que a equipe foi incapaz de
oferecer algo melhor.
Ironicamente, se voc entrasse naquele prdio no bairro SODO de Seattle durante
aquela poca e perguntasse aos desenvolvedores, Quem o cara mais inteligente por
aqui?, eles apontariam para algum da equipe de download OTA. Se, ao invs disso,
voc lhes perguntasse: Quem tem mais experincia? Novamente, a mesma resposta.
Se voc olhasse os currculos, teria visto que a experincia mdia da equipe de download OTA ultrapassava o da equipe de desenvolvimento do dispositivo gerenciador
OTA em trs anos. No papel, tudo sugeria que a equipe de download OTA era melhor.
E at hoje, algumas dessas pessoas acreditam que eles eram melhores, apesar de todas
as numerosas provas no sentido contrrio.
Eu sei pela minha experincia com a gerncia e orientao desta equipe que alguns
dos membros da equipe do dispositivo gerenciador OTA sofriam de baixa auto-estima
profissional e receio de no serem to talentosos quanto algumas das pessoas realmente

33

34

Captulo 3 Uma Receita para o Sucesso

inteligentes que pertenciam outra equipe. No entanto, a produtividade da equipe do


dispositivo gerenciador OTA foi cinco vezes e meia maior, com uma qualidade inicial
trinta vezes maior. A adoo do processo correto, uma boa disciplina, gesto firme e
boa liderana, tudo isso fez a diferena. O que este exemplo demonstra que voc no
precisa das melhores pessoas para produzir resultados de nvel mundial. Uma das crenas centrais da comunidade gil, a que me refiro como esnobismo artesanal, sugere
que tudo que voc precisa para o sucesso no desenvolvimento gil um pequeno grupo
de pessoas realmente boas. No entanto, neste caso, uma equipe com talentos esparcos
foi capaz de produzir resultados de nvel mundial.
Entregas frequentes aumentam a confiana

Reduzir WIP encurta tambm o lead time. Quando o lead time mais curto, possvel
a liberao de cdigo funcional com maior frequncia. Entregas com frequncia maior
constroem a confiana com equipes externas, em especial a equipe de marketing ou
patrocinadores comerciais. Confiana uma coisa difcil de definir. Os socilogos
chamam de capital social. O que eu aprendi que a confiana guiada por eventos e
que pequenos, porm frequentes gestos ou eventos reforam mais a confiana do que
gestos grandiosos feitos apenas ocasionalmente.
Quando falo isto nas aulas, eu gosto de perguntar s alunas qual a opinio delas depois do primeiro encontro com um homem. Suponha que eles se divertiram bastante, e
que depois ele no telefona por duas semanas. Ele, ento, aparece em sua porta com um
buqu de flores e um pedido de desculpas. Depois, peo-lhes para comparar este cara
com outro que arruma tempo para escrever uma mensagem de texto em seu caminho
para casa naquela noite para dizer: Eu tive uma grande noite. Eu realmente quero
te ver novamente. Posso te ligar amanh?, e depois realmente liga no dia seguinte.
Adivinha quem elas preferem? Muitas vezes, pequenos gestos no custam nada, mas
constroem mais confiana do que os grandes, caros (ou expansivos) gestos concedidos
ocasionalmente.
assim tambm com o desenvolvimento de software. Realizar entregas pequenas,
frequentes e de alta qualidade cria mais confiana com as equipes parceiras do que
entregas maiores, porm com menos frequncia.
Entregas pequenas mostram que a equipe de desenvolvimento de software pode
cumprir seu trabalho e est comprometida em fornecimentos com qualidade. Elas
constroem a confiana com a equipe de marketing ou patrocinadores comerciais.
Entregas de cdigo de alta qualidade constroem a confiana com os parceiros de diferentes nveis, como operaes, suporte tcnico, engenharia de campo e de vendas.

Equilibrando a demanda e o rendimento

Conhecimento implcito

muito fcil especular por que pequenos lotes de cdigo melhoram a qualidade. A
complexidade dos problemas relacionados a trabalho de conhecimento cresce exponencialmente com a quantidade de trabalho em progresso. Enquanto isso, nossos crebros humanos lutam para lidar com toda essa complexidade. Em desenvolvimento de
software muito da transferncia de conhecimento e descoberta de informao tcita
por natureza e criada durante sesses de trabalho colaborativas, face a face. A informao verbal e visual, mas em um formato casual, como um desenho em um quadro.
Nossas mentes tm uma capacidade limitada para armazenar todo esse conhecimento
implcito, que se degrada enquanto tentamos armazen-lo. Falhamos em lembrar detalhes precisos e cometemos enganos. Em equipes que trabalham no mesmo local e que
possuem livre acesso entre si, essa perda de memria pode ser corrigida atravs de
reiteradas discusses ou colhendo a memria compartilhada por um grupo de pessoas.
Assim, equipes geis localizadas em um espao de trabalho compartilhado so mais
propensas a reter o conhecimento implcito por mais tempo. Independentemente de
qualquer coisa, o conhecimento implcito se deprecia com o tempo, ento lead times
mais curtos so essenciais. Sabemos que a reduo do trabalho em progresso est diretamente relacionada reduo do lead time. Assim, podemos inferir que haver menor
depreciao do conhecimento implcito quando temos menos trabalho em progresso,
resultando em maior qualidade.
Em resumo, a reduo do trabalho em progresso melhora a qualidade e permite
entregas mais frequentes. Entregas com maior frequncia de cdigo de alta qualidade
melhoram a confiana com as equipes externas.

Equilibrando a demanda e o rendimento


Equilibrar a demanda em relao ao rendimento implica em definirmos a frequncia na
qual aceitaremos novos requisitos durante o desenvolvimento do software, mantendo a
velocidade na qual cdigos funcionais so entregues. Quando isso ocorre, estamos efetivamente ajustando nosso trabalho em progresso a determinado tamanho. Enquanto o
trabalho entregue, puxamos um novo trabalho (ou requisitos) das fontes criadoras
de demanda. Assim, qualquer discusso sobre priorizao e comprometimento com
novas atividades s pode ocorrer aps a entrega de algum trabalho atual.
O efeito desta mudana profundo. O rendimento do seu processo ser restringido
por um gargalo. improvvel que voc saiba onde o gargalo est. De fato, se voc
conversar com qualquer pessoa da cadeia de valor, ela provavelmente alegar estar

35

36

Captulo 3 Uma Receita para o Sucesso

completamente sobrecarregada. No entanto, uma vez que voc consiga equilibrar a


demanda e o rendimento e limitar o trabalho em progresso dentro de sua cadeia de
valor, a mgica acontecer. Apenas os recursos relacionados ao gargalo continuaro
totalmente carregados. Rapidamente, outras pessoas da cadeia de valor descobriro ter
uma folga na sua capacidade de produo. Enquanto isso, aqueles que trabalham no
gargalo estaro ocupados, mas no sobrecarregados de tarefas. Pela primeira vez, talvez
em anos, a equipe no estar mais sobrecarregada e muitas pessoas experimentaro
algo muito raro nas suas carreiras: a sensao de ter tempo disposio.

Crie folga
Muito do estresse ser retirado da organizao e as pessoas sero capazes de se concentrar em fazer o seu trabalho com preciso e qualidade. Elas podero se orgulhar de
seu trabalho e iro desfrutar dessa experincia. As pessoas com algum tempo de sobra
comeam a usar esse tempo em prol de melhorar suas circunstncias, podendo, por
exemplo, melhorar seu ambiente de trabalho ou fazer algum treinamento. Elas provavelmente comearo a melhorar as suas habilidades, suas ferramentas, e a maneira
como interagem com as outras pessoas em outros nveis da organizao. Com o passar
do tempo e como pequenas melhorias levam a outras melhorias, a equipe estar realizando melhoria contnua. A cultura mudar. A capacidade de folga criada pela ao
de limitar o trabalho em progresso e puxar um novo trabalho apenas quando houver
capacidade, viabilizar uma melhoria que ningum antes acreditou ser possvel.
necessrio folga para viabilizar a melhoria contnua. necessrio equilibrar demanda e rendimento, e limitar a quantidade de trabalho em progresso para que a folga
ocorra.
Intuitivamente, as pessoas acreditam que devem eliminar a folga. Ento, depois de
limitar o trabalho em progresso, equilibrando demanda e rendimento, a tendncia
equilibrar a produo, ajustando os recursos a fim de que todos sejam plenamente
utilizados de forma eficiente. Embora possa parecer eficiente e satisfazer as prticas
de gesto contbil tpicas do sculo XX, isso impedir a criao de uma cultura de
melhoria. necessrio folga para viabilizar a melhoria contnua. Para ter folga, faz-se necessrio a presena de uma cadeia de valor desequilibrada com um recurso de
gargalo. Aperfeioar para utilizao no desejvel.

Equilibrando a demanda e o rendimento

Priorize
Caso as trs primeiras etapas da receita tenham sido implementadas, tudo estar funcionando normalmente. Cdigo de alta qualidade estar sendo entregue com frequncia. Lead times de desenvolvimento sero relativamente curtos, visto que o trabalho em
progresso limitado. Novos trabalhos devem ser puxados para o desenvolvimento apenas quando h capacidade aps a concluso dos trabalhos existentes. Nesse momento,
a ateno da gerncia pode se voltar para o aperfeioamento do valor entregue e no
apenas quantidade de cdigo entregue. H pouco ganho em se dar ateno a definio
de prioridades quando no h previsibilidade na entrega. Por que se esforar tentando
priorizar a entrada, quando no h uma dependncia de prioridade na entrega? At
que isso seja resolvido, o tempo de gesto ser melhor utilizado ao se concentrar em
aumentar tanto a capacidade, como a previsibilidade da entrega. Faz-se necessrio
priorizar a entrada quando se sabe que realmente possvel entregar o trabalho com a
mesma prioridade na qual ele foi solicitado.
Influncia

Priorizao no deve ser realizada pela organizao de engenharia e, portanto, no


deve estar sob o controle da gesto de engenharia. Melhorar a priorizao exige que o
dono do produto, o patrocinador do negcio, ou o departamento de marketing mude
seu comportamento. Na melhor das hipteses, a gerncia de engenharia pode procurar
influenciar a forma como a priorizao realizada.
A fim de possuir capital poltico e social para influenciar a mudana, um nvel de
confiana deve ser estabelecido. Sem uma capacidade de entregar cdigo de alta qualidade com frequncia no h como existir confiana e, portanto, nessa situao, h
pouca possibilidade de influncia na definio de prioridades e de, assim, aperfeioar
o valor a ser entregue pela equipe de software.
Recentemente, tornou-se popular na comunidade gil se falar sobre aperfeioamento do valor do negcio e como a taxa de produo de cdigo funcional (chamada
de velocidade de desenvolvimento de software) no uma mtrica importante. Isso
ocorre porque o valor de negcio entregue a verdadeira medida do sucesso. Embora
isso seja verdade, importante no perder de vista a escada de maturidade da capacidade que uma equipe deve subir. A maioria das organizaes incapaz de medir e
informar o valor de negcio entregue. Elas devem primeiramente construir capacidade
nas competncias bsicas antes de tentar maiores desafios.

37

38

Captulo 3 Uma Receita para o Sucesso

Construindo Maturidade

Essa maneira como eu acredito que uma equipe deve amadurecer: em primeiro lugar,
aprendendo a construir um cdigo de alta qualidade. Ento, reduzindo o trabalho em
progresso, encurtando os prazos e entregando frequentemente. Em seguida, equilibrando demanda e rendimento, limitando o trabalho em progresso, e criando folga
para liberar banda, o que permitir melhorias. Ento, com um bom funcionamento e
aperfeioando a capacidade de desenvolvimento de software, melhorar a priorizao
para aperfeioar a entrega de valor. Apenas aguardar pelo aperfeioamento do valor
do negcio um desejo. Tome aes para chegar a este nvel de maturidade de forma
incremental - siga a Receita para o Sucesso.

Ataque as Fontes de Variabilidade para Melhorar Previsibilidade


Os efeitos da variabilidade e como reduz-los dentro de um processo so tpicos avanados. Reduzir a variabilidade no desenvolvimento de software requer que as pessoas
mudem a maneira como elas trabalham para aprender novas tcnicas e mudar seu
comportamento pessoal. Tudo isso difcil. Portanto, no para principiantes ou para
as organizaes imaturas.
Variabilidade resulta em mais trabalho em progresso e prazos mais longos; isto
explicado detalhadamente no captulo 19. A variabilidade gera uma maior necessidade
de folga nos recursos que no so gargalo, a fim de lidar com o fluxo de trabalho, visto
que seus efeitos se manifestam sobre o fluxo de trabalho atravs da cadeia de valor;
uma compreenso completa de por que isso verdade exige algum conhecimento
em controle estatstico de processo e teoria das filas, o que est alm do escopo deste
livro. Pessoalmente gosto do trabalho de Donald Wheeler e Reinertsen Donald sobre
a variabilidade e filas, por isso, se voc quiser mais informaes sobre esses temas,
comece por a.
Por agora, acredite que a variabilidade no tamanho dos requisitos, e na quantidade
de esforo despendida na anlise, projeto, codificao, teste, integrao e entrega prejudica o rendimento do processo e os custos para executar uma cadeia de valor no
desenvolvimento de software.
No entanto, algumas fontes de variabilidade so inadvertidamente projetadas
em processos atravs de escolhas de polticas pobres. O estudo de caso no captulo
4 destaca alguns exemplos: o replanejamento mensal, o acordo de nvel de servio
nas estimativas, e priorizao de mudanas em produo. Todos estes trs exemplos
so controlados por polticas que podem ser alteradas; basta mudar uma poltica de

Receita para o Sucesso e Kanban

processo existente para reduzir drasticamente fontes de variabilidade que afetam a


previsibilidade.

Receita para o Sucesso e Kanban


Kanban viabiliza todos os seis passos da Receita para o Sucesso. Kanban viabiliza a
Receita para o Sucesso e a Receita para o Sucesso viabiliza a promessa de implementao do Kanban pelos gerentes, alm de mostrar porque Kanban uma tcnica to
valiosa.

39

40

Captulo 3 Uma Receita para o Sucesso

Takeaways
Kanban implementa todos os aspectos da Receita para o Sucesso.
A Receita para o Sucesso explica o valor de Kanban.
Baixa qualidade pode representar o maior desperdcio em desenvolvimento
de software.
Reduzir o trabalho em progresso aumenta a qualidade.
Melhoria na qualidade aumenta a confiana com parceiros de outros nveis,
como o de operaes.
Entregas realizadas com frequncia aumentam a confiana com parceiros de
maior nvel organizacional, como marketing.
A demanda e o rendimento podem ser balanceados num sistema puxado.
Um sistema puxado expe os gargalos e cria folgas onde no h gargalos.
Uma priorizao de boa qualidade maximiza o valor entregue a partir de uma
cadeia de valor de desenvolvimento de software em bom funcionamento.
Priorizao tem pouco valor caso no exista uma boa qualidade ou previsibilidade de entrega.
Fazer mudanas para reduzir variabilidade requer folga.
Reduzir variabilidade reduz a necessidade de folga.
Reduzir a variabilidade viabiliza um balanceamento de recursos (e, potencialmente, uma reduo de pessoas).
Reduzir a variabilidade reduz requisitos de recursos.
Reduzir a variabilidade permite reduzir kanban tokens, diminuir WIP, e
reduzir o lead time mdio.
As folgas viabilizam as oportunidades de melhoria.
Melhoria no processo leva a uma maior produtividade e previsibilidade.

C aptulo 4

Do Pior ao Melhor em
Cinco Trimestres

m outubro de 2004, Dragos Dumitriu era um gerente de programa na Microsoft. Ele havia se tornado recentemente chefe de
um departamento que tinha a reputao de ser o pior na diviso de
TI da Microsoft.
O cargo de Gerente de Programa na Microsoft mais prontamente interpretado em outros lugares como de gerente de projeto,
mas na Microsoft ele tipicamente tambm inclui alguma responsabilidade pela anlise e arquitetura. Atribui-se a um gerente de programa
alguma iniciativa, projeto ou produto e ele responsvel por uma
feature ou um conjunto delas. Um gerente de programa recrutar recursos de reas funcionais, tais como desenvolvimento e testes, a fim
de completar o trabalho. Dragos foi o responsvel pela manuteno
de software da unidade de negcios XIT. Esta equipe (como ilustrado
na figura 4.1) localizada numa filial na ndia que era nvel 5 no modelo CMMI, realizou pequenas atualizaes e corrigiu alguns defeitos
de produo para cerca de 80 aplicaes de tecnologia da informao multifuncionais utilizadas pelo pessoal da Microsoft em todo o
mundo. Dragos trabalhava no campus corporativo em Redmond,
Washington. Nesta poca, eu tambm estava trabalhando l.

41

42

Captulo 4 Do Pior ao Melhor em Cinco Trimestres

Figura 4.1 A equipe em Hyderabad, India, no final de 2004; Dragos o quarto da esquerda para a direita

O Problema
Dragos se ofereceu a assumir a equipe que tinha a pior reputao de atendimento ao
cliente da Microsoft. Seu trabalho como agente de mudana, determinado a corrigir os
longos lead times e a baixa expectativa em relao equipe, foi prejudicado pelo clima
poltico. Vrios de seus antecessores na posio ainda eram colegas de trabalho em
outros projetos dentro da mesma unidade de negcios, e preocupava-os que a melhora
no desempenho, causada por ele, os faria parecer ruins, em comparao.
Os programadores e testadores trabalhando para a filial seguiam o Software
Engineering Institutes Personal Software Process / Team Software Process (metodologia PSP / TSP), conforme determinado contratualmente pela Microsoft. Jon De
Vaan, que na poca se reportava diretamente a Bill Gates, era um grande f de Watts
Humphrey, do Software Engineering Institute. Como chefe da Engineering Excellence
da Microsoft, ele estava em posio de determinar quais processos deveriam ser usados
dentro do departamento de TI e nas filiais. Isso significava que mudar o mtodo do
ciclo de desenvolvimento de software em uso no era uma opo disponvel.
Dragos percebeu que nem o PSP / TSP, nem o nvel CMMI na filial eram a raiz dos
problemas. Na verdade, a equipe produziu basicamente o que lhes foi pedido, e com
uma qualidade muito elevada. No entanto, eles tinham um lead time de cinco meses
para solicitaes de mudanas e isso, juntamente com o seu backlog de solicitaes, foi
crescendo incontrolavelmente. A percepo era de um time que foi mal organizado e
gerenciado. Como resultado, a gerncia snior no estava disposta a fornecer investimentos adicionais para corrigir o problema.

Fig 4.2!

Solicitaes de!
Mudana!

GP!

Gerente Des.!

Fatores Influenciando o Desempenho

Gerente de Teste!

Teste de Aceitao do Usurio!

Gerentes de!
Produto!

Backlog!

155 Dias!

Figura 4.2 Equipe de manuteno XIT: Fluxo inicial apresentando lead time
Figura 4.2 Equipe de manuteno XIT: Fluxo inicial apresentando lead time

Assim, as restries para mudanas eram polticas, fiscais e relacionadas s polticas


da empresa. Ele pediu meu conselho.

Visualizar o Fluxo de Trabalho


Eu pedi que Dragos esboasse o fluxo de trabalho e ele elaborou um desenho simples
que descrevia o ciclo de vida de uma solicitao de mudana, e ento, ns discutimos
os problemas. A Figura 4.2 uma cpia exata do que Dragos desenhou. A figura do
GP representa Dragos.
As solicitaes chegavam incontrolavelmente. Quatro gerentes de produto representavam e controlavam o oramento de um conjunto de clientes que eram donos das
aplicaes mantidas pelo XIT. Eles adicionavam novas requisies, inclusive defeitos
escapados na produo (encontrados em campo). Estes defeitos no haviam sido criados pelo time de manuteno, mas pelos times de desenvolvimento das aplicaes. Os
times de desenvolvimento das aplicaes geralmente eram desmontados um ms aps a
entrega de um sistema novo, e o cdigo fonte era manipulado pelo time de manuteno.

Fatores Influenciando o Desempenho


Quando uma requisio chegava, Dragos devia envi-la para a ndia para uma estimativa. A poltica era que as estimativas deviam ser realizadas e ento enviadas de
volta para os donos do negcio em 48 horas. Isso facilitava o clculo do retorno do

43

44

Captulo 4 Do Pior ao Melhor em Cinco Trimestres

investimento (ROI) a fim de decidir se a requisio deveria ir em frente. Uma vez por
ms, Dragos deveria se reunir com os gerentes de produto e outros stakeholders para
re-priorizar o backlog e criar um plano de projeto para as requisies.
Nessa poca eram entregues em torno de sete requisies por ms. O backlog possua 80 ou mais itens e continuava crescendo. Isso significa que 70 ou mais requisies
estavam sendo re-priorizadas e re-agendadas todo ms, e que elas demoravam mais do
que 4 meses para serem processadas; essa era a causa raiz da insatisfao. As requisies
eram pequenas, e a constante re-priorizao significava que as pessoas que faziam as
requisies estavam constantemente decepcionadas.
As requisies eram acompanhadas numa ferramenta chamada Product Studio.
Uma verso atualizada dessa ferramenta foi posteriormente publicada como Team
Foundation Server Work Item Tracking. O time de manuteno XIT tinha um tipo de
organizao que eu frequentemente tinha contato nas minhas aulas e no meu trabalho
de consultoria eles tinham muitos dados, mas no os utilizavam. Dragos comeou a
explorar os dados e descobriu que uma requisio demandava 11 dias de engenharia.
No entanto o lead time era de tipicamente 125 a 155 dias. Mais de 90 por cento do lead
time era gasto em filas, ou em outras formas de desperdcio.
As estimativas para novas requisies consumiam muito esforo, ento ns decidimos avaliar esse cenrio fazendo algumas conjecturas. Apesar das estimativas serem de
rough order of magnitude ordem de magnitude aproximada (ROM), a expectativa
do cliente era receber uma estimativa precisa, dessa maneira, os membros da equipe
eram muito cautelosos no levantamento das estimativas. O esforo para realizao de
cada estimativa era em torno de um dia para cada desenvolvedor e testador. Ns calculamos rapidamente que apenas a estimativa de esforo estava consumindo 33 por cento
da capacidade, e que num ms ruim esse valor poderia ser quase 40 por cento. Esta
capacidade foi alocada em detrimento das atividades de codificao e teste. Estimativas
para novas requisies tambm atrapalhavam os planos feitos para o ms.
Alm das requisies de mudana, a equipe tinha um segundo tipo de trabalho,
conhecido como production text changes (PTCs) mudana de texto em produo
os quais eram de natureza grfica ou textual, ou envolviam modificaes de valor em
tabelas ou arquivos XML. Essas alteraes no necessitavam de um desenvolvedor e
eram frequentemente realizadas pelos donos do negcio, gerentes de produto, ou pelo
gerente de programa; mas era necessria uma aprovao formal de teste, ento elas
afetavam os testadores.
PTCs chegavam sem muito aviso, e eram tradicionalmente priorizados em relao
a qualquer outro trabalho ou estimativa de esforo. PTCs tendiam a chegar em batches
espordicos e tambm afetavam qualquer plano feito para o ms. (veja Figura 4.3).

Fig 4.3!

Estimativa Era um Desperdcio

PTC
Correo de textos!

Solicitaes de!
Mudana!

GP!

Gerente de Des.!

ROM!

Gerente de Teste!

ROM!

Teste de Aceitao do Usurio!

Gerentes de!
Produto!

Backlog!

155 Dias!

Figura 4.3 Fluxo de trabalho apresentando as estimativas ROM e entrada de PTC


Figura 4.3 Fluxo de trabalho apresentando as estimativas ROM e entrada de PTC

Torne Explcitas as Polticas do Processo


A equipe estava seguindo o processo exigido, o qual inclua muitas polticas de deciso ruins que foram feitas por gerentes em vrios nveis. importante entender um
processo como um conjunto de polticas que governam o comportamento e que esto
sob controle gerencial. Por exemplo, a poltica que definia o uso do PSP/TSP foi estabelecida no nvel do vice-presidente executivo, um degrau abaixo de Bill Gates, e seria
difcil ou impossvel mud-la. No entanto, muitas outras polticas como priorizar estimativas sobre codificao e teste, foram desenvolvidas localmente e estavam sob a autoridade colaborativa dos gerentes imediatos. possvel que as polticas fizessem sentido
na poca em que foram implementadas; mas as circunstncias mudaram e no houve
tentativa de revisar e atualizar as polticas que governavam as operaes da equipe.

Estimativa Era um Desperdcio


Aps algumas discusses com seus colegas e gerente, Dragos decidiu promulgar duas
polticas gerenciais iniciais. Primeiro, a equipe pararia de estimar. Dragos queria recuperar a capacidade desperdiada pela atividade de estimativa e us-la para desenvolver e testar software. Eliminar a aleatoriedade no cronograma causada pela realizao
de estimativas melhoraria a previsibilidade, e Dragos esperava que essa combinao
tivesse um grande impacto na satisfao do usurio.
No entanto, remover as estimativas era um problema, pois afetaria os clculos de
ROI, e os clientes poderiam achar que as priorizaes seriam mal feitas. Alm disso, as

45

46

Fig. 4.4!

Captulo 4 Do Pior ao Melhor em Cinco Trimestres

estimativas eram usadas para facilitar a contabilidade de custos entre departamentos e


as transferncias de oramento. Estimativas tambm eram usadas para implementar a
poltica de governana; eram permitidas apenas pequenas requisies atravs do sistema
de manuteno. Grandes requisies que excediam mais de 15 dias de desenvolvimento
ou teste deviam ser submetidas para um projeto de iniciativa maior atravs do program
management office (PMO) formal. Falaremos sobre esses problemas em breve.

Limitar Trabalho em Progresso (WIP)


A outra mudana que Dragos decidiu fazer foi limitar o trabalho em progresso e puxar
trabalho a partir de uma fila de entrada aps a finalizao do trabalho atual. Ele escolheu limitar o WIP em desenvolvimento para uma requisio por desenvolvedor e usar
uma regra similar para os testadores. Ele incluiu uma fila entre desenvolvimento e teste

XIT Change Request


CR!

Limite inicial!
Kanban Virtual
8 = WIP + 7 dias
buffer!

New
More Info

Analysis

New
Approved

Backlog

On
Hold

Info
Received

Resolved

Dev Queue

Started

Test Queue

On
Hold

Started

Dev

Test

Failed

Re-opened
Transferred to Proj Team
Pending Future Project
By Design
Duplicate
Wont Fix
No Repro

PTC!

Resolved
(needs
exception)
Limite inicial!
Kanban Virtual
8 = WIP + 7 dias
buffer!

Failed,
Scope Changed

Abandoned

Passed

UAT Queue

Started
UAT

Passed
SOX

Complete
Closed

Released

Production Queue

4.4 Diagrama de estados


com deo estados
fluxocomde
trabalho
desejado
limites de WIP
Figura 4.4 Diagrama
o fluxo
de trabalho desejado
e limites deeWIP

Estabelecendo uma Cadncia na Entrada

para o recebimento de PTCs e para suavizar


o fluxo de trabalho entre desenvolvimento e
teste, como ilustrado na Figura 4.4. Esta
abordagem de uso de um buffer para suavizar
a variabilidade em tamanho e esforo discutida no captulo 19.

Estabelecendo uma Cadncia na Entrada


A fim de facilitar a deciso de limitar o WIP e institucionalizar um sistema puxado,
Dragos precisou pensar sobre a cadncia na interao com os gerentes de produto. Ele
imaginou que uma reunio semanal seria vivel, j que o tpico da reunio seria simplesmente o reabastecimento da fila de entrada a partir do backlog. Numa semana tpica
haveria trs slots - espaos disponveis - na
fila. Dessa maneira a discusso seria ao
redor da seguinte questo, Quais trs itens
do backlog voc mais deseja que sejam os
prximos a serem entregues?; esta cadncia
modelada na Figura 4.5.
Ele queria garantir um tempo de entrega de 25 dias a partir da aceitao na fila de
entrada. Essa durao de 25 dias era consideravelmente maior do que os 11 dias em

Fig. 4.5!

PTC
Expedio!

Solicitaes de!
Mudana!

Gerente Local!

GP!

Kanban!
8 cartes!
(3 WIP!
5 Buffer)!

Kanban
8 cartes!

Teste de Aceitao do Usurio!

Gerentes de!
Produto!

Backlog!

25 Dias!

Figura 4.5 Fluxo de trabalho com limites de WIP Kanban e filas


Figura 4.5 Fluxo de trabalho com limites de WIP Kanban e filas

47

48

Captulo 4 Do Pior ao Melhor em Cinco Trimestres

mdia gastos em engenharia para completar o trabalho. Os desvios estatsticos requeriam algo em torno de 30 dias, mas ele antecipou alguns deles; 25 dias soava atrativo,
especialmente comparando-se ao lead time atual de 140 dias. Ele esperava atingir a
meta com regularidade, construindo confiana com os gerentes de produto e seus
clientes enquanto isso.

Fazendo um Novo Acordo


Dragos fez uma oferta para os gerentes de produto. Ele pediu para que eles se reunissem uma vez por semana para discutir priorizao, pois ele limitaria a quantidade de
trabalho em progresso e a equipe pararia de estimar. Em troca, ele garantiria entregas
dentro de 25 dias e a reportagem do desempenho da equipe em relao a essa mtrica.
Dragos estava pedindo que os clientes desistissem do clculo do ROI para transferncia de oramento entre departamentos baseando-se nas estimativas por requisio. Em
troca, ele estava oferecendo um tempo de entrega menor nunca visto e confiabilidade.
Para lidar com os problemas de contabilidade, Dragos pediu que eles considerassem
que todas as requisies exigiam, em mdia, um esforo de 11 dias de engenharia, isto
, eles deviam aceitar que os custos eram essencialmente fixos. Dragos estava pedindo
que eles desconsiderassem o paradigma contabilidade de custo no qual a transferncia
de oramento entre departamentos era baseada.
A justificativa para isso era que a filial tinha um contrato de 12 meses que era faturado mensalmente. A filial alocava as pessoas com esse contrato e elas eram pagas sem
considerar se estavam trabalhando ou no. Os fundos desse oramento eram fixos e
distribudos proporcionalmente para os quatro gerentes de produto. Dragos garantiu
que cada um dos gerentes de produto teria uma alocao de capacidade justa; isso
deveria liber-los do acompanhamento individual das requisies. Se eles aceitassem
que os seus dlares lhe compravam capacidade e que ela estava garantida, talvez eles
desconsiderassem o acordo de custo baseado em unidade para transferncia de oramento. Algumas regras simples foram criadas para determinar quem deveria selecionar
as requisies para reabastecer a fila a fim de que a capacidade fosse alocada de maneira
justa. Um esquema simples e leve elaborado por todos foi suficiente para alcanar isso.

Implementando Mudanas
Enquanto os gerentes de produto e muitos colegas gerentes de Dragos na unidade XIT
continuavam cticos, o consenso era de que ele deveria ter uma chance, afinal as coisas
iam mal e estavam piorando. As coisas no ficariam piores do que j estavam! Algum
precisava tentar algo, e era esperado que Dragos implementasse algumas mudanas.

Ajustando as Polticas

Ento as mudanas foram promulgadas.


Elas comearam a funcionar. Requisies eram processadas e entregues para produo. O tempo de entrega para novos compromissos foi de 25 dias como prometido.
A reunio semanal funcionou sem problemas, e a fila era reabastecida a cada semana.
A confiana comeou a ser construda com os gerentes de produto.

Ajustando as Polticas
Voc deve estar se perguntando como a priorizao ficou mais fcil se o clculo do
ROI no era mais realizado. Descobrimos que o clculo no era necessrio. Se algo era
importante e tinha valor, ele era selecionado do backlog para a fila de entrada; se no era
importante, ele no era selecionado. Posteriormente Dragos reconheceu que uma nova
poltica era necessria: Qualquer item com mais de seis meses era retirado do backlog.
Se o item no era importante o suficiente para ser selecionado mesmo aps seis meses
da sua entrada no backlog, poder-se-ia assumir que ele nunca seria importante. Caso
ele fosse realmente importante poderia ser submetido novamente.
Onde est a poltica de governana que previne que itens grandes sejam direcionados para manuteno quando deveriam ser submetidos para um projeto maior? Isso
foi resolvido aceitando-se que esses itens poderiam desviar-se para a manuteno, visto
que os dados histricos demonstravam que esses itens eram menos de dois por cento
do total de requisies. Os desenvolvedores foram instrudos a ficarem em alerta, e
caso uma nova requisio aparentasse requerer mais de 15 dias de esforo, eles deveriam alertar o gerente local. O risco e o custo de se fazer isso eram menores do que
meio por cento da capacidade disponvel; era um timo tradeoff*. Retirando as estimativas, a equipe ganhou mais de
33 por cento da capacidade com
um risco menor do que 1 por
cento daquela capacidade. Essa
nova poltica delegou aos gerentes a responsabilidade de gerenciar riscos e de manifestarem-se
quando fosse necessrio!
As primeiras duas mudanas
foram estabelecidas para durarem 6 meses. Algumas poucas mudanas foram feitas
durante esse perodo. Como mencionado, a poltica de expurgar um item do backlog
* N. de T.: Termo no traduzido devido sua utilizao mais ampla no idioma original (Ingls) pela comunidade de TI no
Brasil. Traduo: troca, compensao, compromisso.

49

50

Captulo 4 Do Pior ao Melhor em Cinco Trimestres

foi adicionada; a reunio semanal com os donos do produto tambm desapareceu. O


processo estava sendo executado to naturalmente que Dragos modificou a ferramenta
Product Studio a fim de que um e-mail fosse enviado quando um slot se tornasse disponvel na fila de entrada. Ele poderia dessa maneira alertar os gerentes de produto
por e-mail que decidiam entre eles quem colocaria um item na fila. A escolha era feita
e uma nova requisio era retirada do backlog e includa na fila duas horas aps o slot
ter se tornado disponvel.

Procurando mais Melhorias


Dragos comeou a procurar mais melhorias. Ele vinha estudando os dados histricos
de produtividade dos testadores da sua equipe e comparando-os com os de outras
equipes dentro do XIT mantido pela mesma filial. Ele concluiu que os testadores no
estavam sobrecarregados e que tinham muita capacidade disponvel. Como consequncia os desenvolvedores eram um gargalo significante. Ele decidiu visitar a equipe na
ndia. Quando retornou ele instruiu a filial a fazer uma mudana na alocao das pessoas. Ele reduziu a equipe de testes de trs para dois e incluiu um novo desenvolvedor
(Figura 4.6). Isso resultou num aumento quase linear da produtividade, e o rendimento
naquele trimestre subiu de 45 para 56.

Fig 4.6!

PTC
Expedio!
Gerente Local!

PM!
Solicitaes de!
Mudana!

Kanban!
9 cartes!
(4 WIP!
5 Buffer)!

Kanban
8 cartes!

Teste de Aceitao do Usurio!

Gerentes de!
Produto!

Backlog!

Figura 4.6 Nivelamento de recursos

Figura 4.6 Nivelamento de recursos

25 Dias!

Resultados

O ano fiscal da Microsoft estava chegando ao fim. Os gerentes seniores receberam a


noticia de uma melhoria significante na produtividade e na consistncia das entregas
da equipe de manuteno de software XIT XIT Sustained Engineering. Finalmente a
gerncia confiava em Dragos e nas tcnicas que ele estava empregando. Destinou-se
mais dinheiro ao departamento para mais duas pessoas: um desenvolvedor e um testador foram contratados em Julho de 2005 (Figura 4.7). Os resultados foram significantes
(Figuras4.8, 4.9).

Fig. 4.7!

PTC
Expedio!
Gerente Local!

GP!

Solicitaes de!
Mudana!

Kanban!
11 cartes!
(5 WIP!
6 Buffer)!

Kanban
8 cards!

Teste de Aceitao do Usurio!

Gerentes de!
Produto!

Backlog!

25 Dias!

Figura 4.7 Adicionando recursos


Figura 4.7 Adicionando recursos

Resultados
A capacidade adicional foi suficiente para aumentar o rendimento em relao
demanda. O resultado? O backlog foi inteiramente eliminado em 22 de Novembro
de 2005. Nessa poca a equipe tinha reduzido o lead time para uma mdia de 14 dias
contra os 11 dias inicias de esforo de engenharia. A meta de desempenho para tempo
de entrega de 25 dias foi atendida em 98 por cento. O rendimento das requisies
aumentou mais de 3 vezes, enquanto o lead time diminuiu em mais de 90 por cento,
e a confiabilidade aumentou praticamente da mesma maneira. Nenhuma mudana
foi realizada no processo de desenvolvimento ou de teste. As pessoas trabalhando em
Hyderabad no tinham conhecimento de mudanas significantes. O mtodo PSP/
TSP no foi alterado e todos os requisitos de governana coorporativa, processo e
de contrato com a filial foram atendidos. A equipe ganhou o Engineering Excellence
Award Prmio de Excelncia em Engenharia na segunda metade de 2005. Dragos foi

51

Fig 4.8!

Captulo 4 Do Pior ao Melhor em Cinco Trimestres

$7500!

60

56!

50
45!

40
45!

30
17!

20

$2900!

10
0
Sep-04

Dec-04

Mar-05

$3300!

Jun-05

Sep-05

Dec-05

Figura 4.9 Tempo de resoluo da manuteno XIT, apresentado nos anos fiscais da Microsoft

4.9!

Figura
4.8 Rendimento
trimestral sobreposto
ao custo sobreposto
unitrio
Figura
4.8 Rendimento
trimestral
ao custo unitrio
XIT-SE TTR
From 5 Months To 3 Weeks in 5 Quarters

180

Other Sev TTR


Sev 1

Novo Gerente!
Sem ROMs!
Novo Processo de Priorizao!
Gerenciamento do Fluxo!

160
140
Calendar Days

52

120

Backlog Zero!

Des. mudou : taxa de


testes de 3:3 para 4:2!

100
80

Des. mudou : teste


de 4:2 para 5:3!

60
40
Custo menor!

20
0
FY04 Q4

FY05 Q1

FY05 Q2

Produtividade

FY05
maior Q3
por
pessoa!
Quarter

FY05 Q4

FY06 Q1

FY06 Q2

Lead time menor!


Satisfao maior
do cliente!

Figura 4.9 Tempo de resoluo da manuteno XIT, apresentado nos anos fiscais da Microsoft

recompensando com responsabilidades adicionais, e o dia-a-dia do gerenciamento da


equipe foi para as mos do gerente local na ndia, que foi re-alocado para Washington.

Resultados

Essas melhorias aconteceram em parte devido a incrvel habilidade gerencial de


Dragos Dumitriu, mas os elementos bsicos de mapeamento da cadeia de valor, anlise de fluxo, limitao do WIP, e implementao de um sistema puxado foram peas
chave. Sem o paradigma de fluxo e a abordagem kanban de limitar o WIP, os ganhos
de desempenho no teriam acontecido. Kanban possibilita mudanas incrementais
com polticas de risco simples e baixa resistncia mudana.
O caso XIT mostrou como um sistema puxado com WIP limitado foi implementado
num projeto distribudo usando recursos offshore, e facilitado com o uso de uma ferramenta de acompanhamento eletrnica. No havia quadro visual e as caractersticas
mais sofisticadas do Mtodo Kanban descritas nesse livro ainda emergiriam. No entanto, qual gerente poderia ignorar a possibilidade de uma melhoria na produtividade
de mais de 200 por cento, com uma reduo do lead time em 90 por cento, serem
alcanadas com uma melhoria significante da previsibilidade e com polticas de risco
mnimas e pouca resistncia mudana?

53

54

Captulo 4 Do Pior ao Melhor em Cinco Trimestres

Takeaways
O primeiro sistema kanban foi implementado pela equipe de manuteno
de software da Microsoft XIT Sustained Engineering, que comeou em 2004.
O primeiro sistema kanban usava uma ferramenta de acompanhamento eletrnica.
O primeiro sistema kanban foi implementado com uma equipe offshore de
nvel 5 no modelo CMMI em Hyderabad, ndia.
O fluxo de trabalho deve ser esboado e visualizado.
O processo deve ser descrito como um conjunto de polticas explcitas.
Kanban proporciona mudanas incrementais.
Kanban proporciona mudana com uma poltica de risco mnima.
Kanban proporciona mudana com pouca resistncia.
Kanban revelar oportunidades de melhoria que no envolvem mudanas
complexas nos mtodos de engenharia.
O primeiro sistema kanban produziu um aumento de 200 por cento na produtividade com uma reduo de 90 por cento no lead time e uma melhoria
similar na previsibilidade.
Melhorias significantes so possveis gerenciando gargalos, eliminando desperdcio, e reduzindo a variabilidade que afeta as expectativas e a satisfao
dos clientes.
Mudanas podem levar tempo para proporcionarem um efeito generalizado.
O primeiro estudo de caso levou 15 meses para surtir um bom efeito.

C aptulo 5

Uma Cultura de
Melhoria Contnua

m Japons, a palavra kaizen literalmente significa melhoria contnua. Uma cultura de trabalho onde todos os trabalhadores
esto focados em continuamente melhorar a qualidade, a produtividade e a satisfao do cliente conhecida como uma cultura kaizen.
Muito poucas empresas realmente conseguiram esta cultura.
Empresas como a Toyota, onde a participao dos trabalhadores no
seu programa de melhoria prximo de 100%, e onde cada funcionrio tem em mdia uma sugesto implementada todos os anos como
parte de melhoria contnua, so muito raras.
No mundo do desenvolvimento de software, o Software
Engineering Institute (SEI) da Carnegie Mellon University definiu o
nvel mais alto do seu CMMI (Capability Maturity Model Integration)
como Otimizando. Otimizando implica que a qualidade e o desempenho da organizao esto sendo continuamente refinados. Embora
no explicitamente declarado, visto que o CMMI fala pouco sobre
cultura, mais provvel que um comportamento de otimizao contnua acontea dentro de uma organizao com uma cultura kaizen.

55

56

Captulo 5 Uma Cultura de Melhoria Contnua

Cultura Kaizen
Para entender porque to difcil alcanar uma cultura kaizen, primeiro devemos
entender como tal cultura seria. S ento podemos discutir por que podemos querer
alcanar tal cultura e quais seriam os seus benefcios.
Na cultura kaizen a fora de trabalho tem poder. Indivduos sentem-se livres para
agir; livres para fazer a coisa certa. Eles espontaneamente se debruam sobre os problemas, discutem as opes e implementam correes e melhorias. Em uma cultura
kaizen, a fora de trabalho no tem medo. A norma subjacente para a gesto ser tolerante a falhas se a experimentao e a inovao fizerem parte do processo - assim como
a melhoria de desempenho. Em uma cultura kaizen, indivduos so livres (dentro de
alguns limites) para se auto-organizarem em torno do trabalho que eles fazem e como
eles o fazem. Controles visuais e sinais so evidentes e as pessoas se oferecem para
trabalhar em tarefas de trabalho ao invs de serem atribudas por um superior. Uma
cultura kaizen envolve um elevado nvel de colaborao e uma atmosfera de coleguismo
onde todo mundo olha para o desempenho da equipe e os negcios acima de si. Uma
cultura kaizen centra-se no pensamento em nvel de sistemas ao fazer melhorias locais
que melhoram o desempenho geral.
Uma cultura kaizen tem um elevado nvel de capital social. uma cultura de alta
confiana em que indivduos, independentemente de sua posio na hierarquia de
tomada de decises de negcios, respeitam uns aos outros e a contribuio de cada
pessoa. Culturas de alta confiana tendem a ter estruturas mais horizontais do que
culturas de confiana inferior. o grau de capacitao que permite uma estrutura
mais horizontal trabalhar de forma eficaz. Assim, alcanar uma cultura kaizen pode
permitir a eliminao de desperdcio de camadas de gerenciamento e reduzir os custos
de coordenao, como resultado.
Muitos aspectos de uma cultura kaizen esto em oposio s normas culturais e
sociais estabelecidas na cultura ocidental moderna. No ocidente, somos levados a ser
competitivos. Nossos sistemas de ensino incentivam a concorrncia nos estudos e nos
esportes atlticos. Mesmo nossos esportes de equipe tendem a incentivar o desenvolvimento de heris e equipes construdas em torno de um ou dois jogadores excepcionalmente talentosos. A norma social enfocar primeiramente o indivduo e confiar em
pessoas extraordinrias para alcanar a vitria ou para nos salvar do perigo. No de
se admirar que tenhamos dificuldade no local de trabalho para incentivar coleguismo
e pensamento no nvel de sistemas e cooperao.

Kanban Acelera Maturidade e Capacidade Organizacional

Kanban Acelera Maturidade e Capacidade Organizacional


O Mtodo Kanban projetado para minimizar o impacto inicial das mudanas e reduzir a resistncia adoo da mudana. Adotar Kanban deve mudar a cultura da sua
empresa e ajudar a torn-la madura. Se a adoo feita corretamente, a organizao ir
transformar-se em uma que adota mudanas facilmente e se torna boa na implementao de alteraes e melhorias no processo. O SEI refere-se a isso como uma capacidade
de Inovao Organizacional e Implantao (OID, sigla no original)15 dentro do modelo
CMMI. Tem sido mostrado16 que organizaes que atingem este nvel elevado de capacidade de gesto de mudana podem adotar mtodos de desenvolvimento gil, tais
como Scrum, mais rpido e melhor do que organizaes menos maduras.
Quando voc implementa Kanban pela primeira vez voc est procurando otimizar
os processos existentes e alterar a cultura organizacional, ao invs de substituir os processos existentes por outros que podem fornecer melhorias econmicas dramticas.
Esta situao levou a crticas17 de que Kanban otimiza apenas algo que precisa ser
alterado. No entanto, h agora considerveis evidncias empricas18 de que Kanban
acelera a obteno dos altos nveis de maturidade organizacional e capacidade em reas
de processo de alta maturidade fundamentais tais como Anlise Causal e Resoluo
(CAR, sigla no original) e Inovao Organizacional e Implantao.
Quando voc escolhe usar Kanban como um mtodo para orientar a mudana em
sua organizao, voc est seguindo a opinio de que melhor aperfeioar o que j
existe, porque mais fcil e mais rpido e encontrar menos resistncia do que executar uma iniciativa de mudana gerenciada e projetada. A introduo de uma mudana
radical mais difcil do que melhorar incrementalmente o que j existe. Voc tambm
deve compreender que os aspectos de jogo colaborativo do Kanban iro contribuir para
uma mudana significativa na sua cultura corporativa e sua maturidade. Esta mudana
permitir mais tarde alteraes mais significativas, novamente com baixa resistncia,
do que se estivesse tentando fazer essas alteraes imediatamente. A adoo do Kanban
um investimento de longo prazo em capacidade, maturidade e cultura da sua organizao. No se destina como uma soluo rpida.

Estudo de Caso: Desenvolvimento de Aplicaes na Corbis


Quando apresentei um sistema kanban na Corbis, em 2006, eu o fiz por muitos dos benefcios
mecnicos que se demonstrou com a Microsoft XIT em 2004 (como descrito no captulo 4). A
aplicao inicial foi a mesma manuteno de aplicaes de TI. Eu no estava antecipando uma
mudana cultural significativa ou uma mudana significativa na maturidade organizacional. Eu
no esperava o que agora conhecemos como o Mtodo Kanban evolusse a partir deste trabalho.

57

58

Captulo 5 Uma Cultura de Melhoria Contnua

Enquanto eu escrevo este livro em 2010, estabeleceu-se agora que Kanban naturalmente encaixase com o trabalho de manuteno de TI. Em 2006, ainda no era claro, mas uma forma de sistema
kanban parecia se encaixar bem com os problemas funcionais dos trabalhos de manuteno. Eu
no entrei na Corbis com a inteno de praticar Kanban. Entrei l com a inteno de melhorar a
satisfao do cliente com a equipe de desenvolvimento de software. Foi uma coincidncia feliz
que o primeiro problema a ser tratado era a falta de previsibilidade com relao s entregas de
manuteno de software de TI.

Cenrio e Cultura
Em 2006, Corbis era uma empresa privada, com cerca de 1300 funcionrios em todo o mundo.
Ela controlava os direitos digitais para muitas obras de arte fascinantes, bem como representava
aproximadamente 3000 fotgrafos profissionais, licenciando seu trabalho para uso por editores
e anunciantes. Era a segunda maior empresa do mundo de estoque de fotografias. Havia outras
linhas de negcios tambm, o mais notvel dos quais foi o negcio de licenciamento de direitos que
controlava os direitos em nome dos familiares, propriedades e empresas de gerenciamento, para
as imagens e os nomes de personalidades e celebridades. O departamento de TI era composto por
cerca de 110 pessoas divididas entre engenharia de software e manuteno de sistemas/operaes
de rede. A fora de trabalho era aumentada em alguns momentos com terceirizados para trabalhar
em projetos grandes. No seu auge em 2007, o departamento de engenharia de software empregou
105 pessoas, incluindo um contingente de 35 pessoas em Seattle e outras 30 em um fornecedor
em Chennai, ndia. A maioria dos testes era realizada por esta equipe em Chennai. Houve uma
abordagem muito tradicional ao gerenciamento de projetos: tudo era planejado em uma rvore
de dependncias de tarefas e conduzido por um escritrio de gerenciamento de programas. Era
uma companhia com uma cultura conservadora, no que havia sido uma indstria relativamente
conservadora e lenta. Empregava abordagens conservadoras e tradicionais de gerenciamento de
projetos e de ciclo de vida de engenharia de software.
O departamento de TI mantm um conjunto diversificado de aproximadamente 30 sistemas. Alguns
eram tipicamente sistemas contbeis e sistemas de recursos humanos; outros eram exticos e
s vezes esotricos, aplicaes para a indstria de gesto de direitos digitais. Havia uma ampla
gama de tecnologias, plataformas de software e linguagens suportadas. A fora de trabalho era
incrivelmente fiel; muitas pessoas no departamento de TI haviam estado com a empresa por mais
de oito anos, alguns com at 15 anos de servio. Nada mau para uma empresa que tinha 17 anos.
O processo existente era tradicional, o ciclo de vida de desenvolvimento de software (SDLC, sigla
no original) estilo cascata, que tinha sido institucionalizado ao longo dos anos com a criao de um
departamento de anlise de negcios, um departamento de anlise de sistemas, um departamento
de desenvolvimento e um departamento de teste offshore. Dentro destes departamentos havia
muitos especialistas, tais como analistas cuja experincia era contabilidade e cuja especialidade era

Kanban Acelera Maturidade e Capacidade Organizacional

em finanas. Alguns desenvolvedores tambm eram especialistas, por exemplo, os programadores


de J.D. Edwards, que mantinham o software de contabilidade J.D. Edwards.
Nada disto era ideal; mas era o que era. As coisas eram da forma como eram. Quando entrei para
a empresa havia alguma expectativa e ansiedade de que eu iria impor um mtodo gil e usar o
poder da minha posio para forar as pessoas a mudar seu comportamento. Embora isto pudesse
ter funcionado, teria sido brutal, e o impacto durante a transio teria sido grave. Eu tinha medo de
tornar as coisas piores, com medo de que projetos ficassem parados enquanto um novo treinamento
era fornecido e o pessoal adaptado s novas formas de trabalho. Eu tambm estava com medo de
perder pessoas-chave, sabendo que a fora de trabalho era frgil devido aos nveis excessivos de
especializao. Eu escolhi introduzir um sistema kanban, colocar o trabalho de manuteno de
sistemas de volta aos trilhos e ver o que aconteceria.

A Necessidade de uma Funo de Manuteno de Software


A manuteno de software (ou RRT para Rapid Response Team, como ela era conhecida internamente) tinha sido financiada pelo comit executivo com um oramento adicional de dez por
cento para o departamento de engenharia de software. Isto equivalia a cinco pessoas adicionais em
2006. Algum tempo antes da minha chegada, as cinco pessoas haviam sido contratadas. Devido
natureza diversa dos sistemas envolvidos e ao elevado grau de especializao existente da equipe,
foi decidido que uma equipe dedicada de cinco pessoas para fazer o trabalho de manuteno no
seria uma boa soluo. Ento cinco pessoas adicionais foram colocadas no pool geral de recursos: um gerente de projeto, um analista, um desenvolvedor e dois testadores. Isto introduziu uma
complicao adicional que era necessria, de uma perspectiva de governana, para mostrar que
o adicional de cinco pessoas estava realmente fazendo trabalhos de manuteno e no tinham
simplesmente sido sugados para o portflio do grande projeto. No entanto, em um dia qualquer,
essas cinco pessoas poderiam ser qualquer uma das aproximadamente 55 pessoas na equipe.
Uma soluo teria sido que todos preenchessem planilhas de tempos complexas, o que teria acrescentado um encargo administrativo, para mostrar que 10 por cento das horas da equipe estavam
sendo gastas em atividades de manuteno. Isso teria sido altamente intrusivo, mas como tipicamente gerentes de nvel mdio respondem a tal desafio. Outra abordagem era introduzir um
sistema kanban.
Uma expectativa havia sido definida de que uma equipe de manuteno permitiria Corbis fazer
verses incrementais para os sistemas de TI a cada duas semanas. Grandes projetos normalmente
envolviam grandes atualizaes de sistemas e novas verses a cada trs meses. Mas com o amadurecimento do negcio e a natureza destes sistemas se tornou mais complexa, esta cadncia de
grandes liberaes trimestrais tinha se tornado intermitente. Alm disso, alguns dos sistemas existentes foram efetivamente descontinuados e realmente deveriam ser substitudos completamente.

59

60

Captulo 5 Uma Cultura de Melhoria Contnua

Substituio de sistemas legados um grande desafio, e normalmente envolve projetos longos


com uma grande equipe at que uma paridade de funcionalidade alcanada e o antigo sistema
possa ser desligado assim que o outro colocado online (essa abordagem muito longe de ser
ideal, mas normal).
Assim as liberaes de manuteno eram a nica rea dentro do TI da Corbis onde kanban poderia
permitir alguma forma de agilidade nos negcios.

Pequenos Projetos de Manuteno No Estavam Funcionando


O sistema existente para entregar verses de manuteno, o sistema que estava quebrado, devia
agendar uma srie de projetos de curta durao, de duas semanas. Isso poderia ter sido reconhecido
como desenvolvimento de software gil usando iteraes de duas semanas, mas no foi. Quando
eu cheguei, a negociao de escopo para um ciclo de liberao de duas semanas estava levando
cerca de trs semanas. Assim os custos de transao iniciais de uma liberao eram maiores do que
o trabalho de valor agregado. Estava levando cerca de seis semanas para que uma verso de duas
semanas fosse liberada.

Implementando a Mudana
Era claro que antes de fazer quaisquer alteraes que o status quo era inaceitvel. O atual sistema
era incapaz de oferecer o nvel exigido de agilidade nos negcios. Manuteno de sistemas nos
deu uma oportunidade ideal para introduzir mudanas. Trabalhos de manuteno no eram em
geral de misso crtica. No entanto, eram altamente visveis, j que as pessoas de negcios tinham
acesso direto priorizao, e as escolhas eram altamente tticas e importantes em curto prazo para
as metas de negcio. Manuteno de sistemas era algo que todos se preocupavam e queriam trabalhar eficazmente. E finalmente, havia uma razo convincente para fazer alteraes. Todo mundo
estava descontente com o sistema existente. Os desenvolvedores, testadores e analistas estavam
todos irritados com o tempo desperdiado com negociaes de escopo, e as pessoas de negcios
estavam extremamente insatisfeitas com os resultados.
Projetamos um sistema kanban com liberaes agendadas a cada duas semanas, previstas para
as 13h a cada duas quartas-feiras e com reunies de priorizao agendadas com as pessoas de
negcios, marcadas s 10h de cada segunda-feira. Assim, a cadncia de priorizao era semanal e a cadncia de liberao era quinzenal. A escolha da cadncia foi determinada atravs de
discusses colaborativas com parceiros e baseada nos custos de transao e coordenao das
atividades. Algumas outras mudanas foram feitas. Introduzimos uma fila chamada Pronto para
Engenharia (entrada) com um limite de trabalho-em-progresso de cinco itens e, em seguida,
acrescentamos limites durante todo o ciclo de anlise, desenvolvimento, construo e teste de
sistema. Teste de aceitao, homologao e pronto para produo ficaram ilimitados, j que eles

Kanban Acelera Maturidade e Capacidade Organizacional

no foram considerados como sendo de capacidade restrita e estavam, at certo ponto, fora do
nosso controle poltico imediato.

Efeitos Primrios das Mudanas


Os efeitos da introduo de um sistema kanban foram, em um nvel, esperados, mas em outro, eles
eram muito notveis. Ns comeamos a fazer liberaes a cada duas semanas. Aps cerca de trs
iteraes, elas foram acontecendo sem incidentes. A qualidade era boa e havia pouca ou nenhuma
necessidade de correes emergenciais quando o novo cdigo ia para produo. O overhead de
agendamento e planejamento de liberaes havia cado drasticamente, e as disputas entre as
equipes de desenvolvimento e o escritrio de gesto de programa tinham desaparecido quase
completamente. Portanto, kanban havia cumprido sua promessa bsica. Ns estvamos liberando
releases de alta qualidade muito regularmente, com um mnimo de overhead* de gerenciamento.
Custos de transao e coordenao de um release foram reduzidos drasticamente. A equipe estava
recebendo mais trabalho e eles estavam entregando esse trabalho ao cliente mais frequentemente.
Os efeitos secundrios foram ainda mais notveis.

Efeitos Imprevistos da Introduo do Kanban


Para a equipe de desenvolvimento, introduzimos a parede de cartes fsica usando notas auto-adesivas em um quadro branco em Janeiro de 2007. Comeamos a realizao de reunies dirias
em torno do quadro por 15 minutos s 9h30min todos os dias. O quadro fsico tinha um enorme
efeito psicolgico comparado a qualquer coisa que obtivemos da ferramenta de registro eletrnico
que usamos na Microsoft. Ao participar de p todos os dias, os membros da equipe eram expostos
a uma espcie de fotografia do fluxo de trabalho atravs do quadro. Itens de trabalho bloqueados
eram marcados com bilhetes cor-de-rosa, e a equipe tornou-se muito mais focada na resoluo de
problemas e manuteno do fluxo. A produtividade aumentou drasticamente.
Com o fluxo de trabalho agora visvel no quadro, comecei a prestar ateno ao funcionamento do
processo. Como resultado, eu fiz algumas mudanas no quadro. Minha equipe de gerentes veio a
entender as alteraes que eu estava fazendo e por que, e at maro, eles estavam fazendo alteraes por eles mesmos. Por sua vez, os membros de suas equipes, os desenvolvedores individuais,
testadores e analistas, comearam a ver e a entender como as coisas funcionavam. No incio do
vero, todos na equipe se sentiam aptos a sugerir mudanas e tnhamos observado a formao
espontnea (geralmente multifuncionais) de grupos de indivduos que discutiam problemas de
processo e os desafios, e faziam alteraes conforme eles acreditavam ser apropriado. Normalmente,
eles informavam gesto aps o fato. O que havia surgido durante aproximadamente seis meses
* N. de T.: Termo no traduzido devido sua utilizao mais ampla no idioma original (Ingls) pela comunidade de TI no
Brasil. Traduo: sobrecarga.

61

62

Captulo 5 Uma Cultura de Melhoria Contnua

era uma cultura kaizen na equipe de engenharia de software. Os membros da equipe se sentiam
com poder. O medo tinha sido removido. Eles se orgulhavam do seu profissionalismo e de suas
realizaes e eles queriam fazer melhor.

Mudana Sociolgica
Desde a experincia da Corbis, tem havido relatos similares da rea. Rob Hathaway da
Indigo Blue foi o primeiro a replicar verdadeiramente esses resultados com o grupo
de TI na IPC Media em Londres. O fato de que outros tm sido capazes de replicar os
efeitos sociolgicos do Kanban que observamos na Corbis me faz acreditar que existe
uma causalidade e que no foi uma coincidncia nem um efeito direto do meu envolvimento pessoal.
Eu pensei muito sobre o que provocou essas mudanas sociolgicas. Mtodos geis
tm nos oferecido transparncia no trabalho-em-progresso h uma dcada, e as equipes que seguem o Mtodo Kanban parecem alcanar uma cultura kaizen mais rpida e
eficazmente do que equipes tpicas de desenvolvimento gil de software. Muitas vezes,
equipes que adicionam Kanban a seus mtodos geis existentes encontram uma melhoria significativa no capital social entre membros da equipe. O que poderia ser isso?
A minha concluso que Kanban fornece transparncia para o trabalho e tambm
para o processo (ou fluxo de trabalho). Ele fornece visibilidade sobre como o trabalho
passado de um grupo para outro. Kanban permite que todos os interessados vejam os
efeitos de suas aes ou inatividades. Se um item est bloqueado e algum capaz de
desbloque-lo, Kanban mostra isso. Talvez haja um requisito ambguo. Normalmente,
o especialista no assunto que pode resolver a ambiguidade poderia esperar para receber um e-mail com uma convocao para uma reunio. Aps uma chamada, eles
organizam uma reunio de acordo com suas agendas, talvez trs semanas depois. Com
Kanban e a visibilidade que ele proporciona, o especialista no assunto percebe o efeito
da falta de ao e prioriza a reunio, talvez reorganizando sua agenda para marcar uma
reunio na semana atual, em vez de atras-la por duas semanas. Alm da visibilidade
do fluxo de processo, limites de trabalho-em-progresso tambm foram interaes
desafiadoras a acontecer mais cedo e mais frequentemente. No fcil ignorar um
item bloqueado e simplesmente trabalhar em outra coisa. Este aspecto pare a linha
do Kanban parece incentivar o comportamento de enxame* atravs do fluxo de valor.
* N. de T.: swarming behavior, no original, designa o comportamento em que indivduos se renem como um enxame, a
fim de resolver um problema em conjunto.

Mudana Sociolgica

Quando as pessoas de diferentes reas funcionais e diferentes cargos se unem sobre um


problema e colaboram para encontrar uma soluo, mantendo o fluxo de trabalho e
melhorando o desempenho no nvel do sistema, aumenta o nvel de capital social e de
confiana da equipe. Com elevados nveis de confiana gerados atravs da colaborao
melhorada, o medo eliminado da organizao.
Limites de trabalho-em-progresso , juntamente com classes de servios (explicados
no Captulo 11) tambm capacitam os indivduos para tomar decises de planejamento
por conta prpria, sem direo ou superviso da gesto. Delegar poder melhora o
nvel de capital social, demonstrando que os superiores confiam nos subordinados
para tomar decises de alta qualidade por conta prpria. Os gerentes so liberados da
superviso de colaboradores individuais e podem concentrar sua energia mental em
outras coisas, como o desempenho de processos, gesto de risco, desenvolvimento da
equipe e maior satisfao de clientes e funcionrios.
Kanban melhora significativamente o nvel de capital social dentro da equipe. Os
maiores nveis de confiana e a eliminao do medo incentivam a inovao colaborativa e resoluo de problemas. O efeito resultante o rpido surgimento de uma
cultura kaizen.

Propagao Viral da Colaborao


Kanban claramente melhorou a atmosfera do departamento de engenharia de software
da Corbis, mas foram os resultados alm desse grupo os mais notveis. Vale a pena relatar e analisar como a propagao viral do Kanban melhorou a colaborao na empresa.

Estudo de Caso: Desenvolvimento de Aplicaes na Corbis, continuao


Toda manh de segunda-feira, s 10h, Diana Kolomiyets, a gerente de projeto responsvel por coordenar liberaes de manuteno de sistemas de TI, convocava a reunio do comit de priorizao
RRT. Os participantes da rea de negcios normalmente eram vice-presidentes. Eles comandavam
uma unidade de negcios e se reportavam a um vice-presidente snior ou a um alto executivo da
empresa. Dito de outra forma, um vice-presidente se reportava a um membro do comit executivo.
Corbis ainda era pequena o suficiente de modo que fazia sentido para um gerente de to alto nvel
participar da reunio semanal. Igualmente, as opes tticas sendo feitas eram suficientemente
importantes que precisavam realmente a direo de um vice-presidente para influenciar uma boa
escolha.
Normalmente, cada participante recebia um e-mail na sexta-feira anterior reunio. Nele haveria algo como: Ns antecipamos que haver dois slots livres na fila na prxima semana. Por

63

64

Captulo 5 Uma Cultura de Melhoria Contnua

favor, examinem seus itens de backlog e selecionem os candidatos para discusso na reunio de
segunda-feira.

Barganhando
Nas primeiras semanas do novo processo, alguns dos participantes vinham com uma expectativa
de negociao. Eles poderiam dizer, Sei que h apenas um slot livre, mas eu tenho duas pequenas
requisies, voc pode fazer as duas? Esta negociao raramente era tolerada. Os outros membros
do comit de priorizao assegurariam que todos seguiriam as regras. Eles poderiam responder
Como posso saber que eles so pequenos? Devo acreditar em sua palavra? ou rebater com Eu
tambm tenho dois pequenos. Por que motivo eu no devo ter meus favoritos selecionados?
Refiro-me a isso como o Perodo de Negociao, pois indica o estilo de negociao que aconteceu
nas reunies de priorizao.

Democracia
Aps cerca de seis semanas e coincidentemente na mesma poca em que a equipe de desenvolvimento introduziu o uso do quadro fsico, o comit de priorizao introduziu um sistema de
votao democrtico. Eles espontaneamente se ofereceram, j que eles se cansaram das disputas.
A negociao na reunio estava desperdiando tempo. Levou algumas iteraes para aperfeioar o
sistema de votao, que se estabeleceu como um sistema onde cada participante tem direito a um
voto para cada slot livre na fila naquela semana. No incio da reunio, cada membro propunha um
pequeno nmero de candidatos para a seleo. Com o passar do tempo, propor solicitaes ficou
mais sofisticado, algumas pessoas vieram com apresentaes do PowerPoint, outros com planilhas
que estabeleciam um caso de negcio. Mais tarde, ouvimos que alguns membros estavam fazendo
lobby com seus colegas, levando-os para o almoo. Acordos estavam sendo feitos, se eu votar na
sua escolha nesta semana, voc votar na minha na prxima semana? Paralelamente ao novo
sistema democrtico de priorizao, o nvel de colaborao estava crescendo entre as unidades de
negcios no nvel de vice-presidente. Embora ns no tenhamos percebido no momento, o nvel
do capital social na empresa inteira estava crescendo. Quando os lderes de unidades de negcios comeam a colaborar, parece que as pessoas fazem o mesmo dentro de suas organizaes.
Elas seguem o caminho do seu lder. Comportamento colaborativo juntamente com visibilidade e
transparncia gera mais comportamento colaborativo. Refiro-me a este perodo como o Perodo
de Democracia.

Abaixo com a democracia


A democracia foi muito boa, mas depois de mais quatro meses, parecia que ela havia falhado em
eleger o melhor candidato. Um esforo considervel foi gasto para implementar uma funcionalidade

Mudana Cultural Talvez Seja o Maior Benefcio do Kanban

de e-commerce para o mercado do Leste Europeu. O caso de negcio tinha sido estelar, mas sua
candidatura foi suspeita desde o incio, e alguns tinham questionado a qualidade dos dados. Aps
vrias tentativas, esse recurso foi selecionado e foi devidamente implementado. Foi uma das maiores funcionalidades processadas atravs do sistema RRT, e muitas pessoas se envolveram e notaram
isso. Dois meses aps o lanamento, nosso Diretor de Inteligncia de Negcio fez alguma minerao de dados sobre as receitas geradas. Era uma frao do que tinha sido prometido no caso de
negcio original, e o perodo de retorno estimado sobre o esforo despendido foi calculado em 19
anos. Devido transparncia que o Kanban nos ofereceu, muitas partes interessadas tornaram-se
conscientes disto, e houve discusso sobre como a preciosa capacidade tinha sido desperdiada
com esta escolha quando uma escolha melhor poderia ter sido feita em vez desta. Este foi o fim
do Perodo da Democracia.

Colaborao
O que o substituiu foi notvel. Tenha em mente que o comit de priorizao consistia em sua
maior parte de funcionrios do nvel de vice-presidente e diretores da empresa. Eles tinham ampla
visibilidade sobre aspectos do negcio que muitos de ns no tnhamos conscincia. Assim, no
incio da reunio, eles comeavam a perguntar Diana, qual o lead time atual de entrega?. Ela
poderia responder No momento nossa mdia de 44 dias para produo. Ento eles faziam uma
simples pergunta: Qual a mais importante iniciativa ttica de negcios nesta empresa 44 dias a
partir de agora?. Poderia haver alguma discusso, mas normalmente havia acordo rpido. Oh, vai
ser o lanamento da nossa campanha europia na conferncia em Cannes. timo! Quais itens na
lista de pendncias so necessrios para apoiar o evento de Cannes?. Uma busca rpida poderia
produzir uma lista de seis itens. Existem trs slots livres nesta semana. Vamos escolher trs de
seis e ns vamos escolher os outros na prxima semana. Houve muito pouco debate. No havia
nenhuma barganha ou negociao. A reunio terminava depois de cerca de 20 minutos. Eu passei
a me referir a isso como o Perodo de Colaborao. Ele representa o mais alto nvel de capital social
e confiana entre as unidades de negcios que foi alcanado durante o meu tempo como Diretor
Snior de Engenharia de Software na Corbis.

Mudana Cultural Talvez Seja o Maior Benefcio do Kanban


Foi interessante ver esta mudana cultural acontecer e ver como afetou a maioria da
empresa enquanto os empregados seguiram a liderana dos seus vice-presidentes e
comearam a colaborar mais com os seus colegas de outras unidades de negcios. Esta
mudana foi profunda o suficiente para que o recm-nomeado CEO, Gary Shenk, me

65

66

Captulo 5 Uma Cultura de Melhoria Contnua

chamasse para o seu escritrio para perguntar se eu tinha uma explicao. Ele me disse
que ele tinha observado um novo nvel de colaborao e esprito de coleguismo nas
categorias snior da empresa e que as unidades de negcios anteriormente antagnicas
pareciam estar interagindo muito melhor. Ele sugeriu que o processo da RRT tinha algo
a ver com isso e perguntou se eu tinha alguma explicao para ele. Estou certo que eu
no era to articulado como agora, escrevendo este captulo dois anos mais tarde, mas
eu o convenci de que nosso sistema kanban tinha reforado bastante a colaborao e
junto com isso o nvel de capital social entre todos os envolvidos.
Os efeitos colaterais culturais que agora reconhecemos ser do Kanban com K maisculo foram bastante inesperados e de muitas maneiras contra-intuitivos. Ele perguntou:
Por que no estamos fazendo todos os nossos principais projetos desta forma? Porque
no? Ento combinamos de implementar Kanban no portflio de grandes projetos. O
fizemos porque Kanban permitiu uma cultura kaizen, e aquela mudana cultural foi
to desejvel que o custo de alterar as vrias mecnicas de priorizao, agendamento,
emisso de relatrios e entrega que resultaria da implementao Kanban foi considerado como um preo que valia a pena pagar.

Takeaways
67

Takeaways
Kaizen significa melhoria contnua.
Uma cultura kaizen aquela onde os indivduos se sentem com poder, agem
sem medo, espontaneamente se unem, colaboram e inovam.
Uma cultura kaizen possui um alto grau de capital social e confiana entre os
indivduos, independente de seu nvel na hierarquia corporativa.
Kanban fornece transparncia tanto no trabalho quando no processo atravs
do qual o trabalho flui.
A transparncia do processo permite que todos os interessados vejam os
efeitos de suas aes ou falta de ao.
Indivduos esto mais propensos a oferecer seu tempo e colaborar quando
eles podem ver os efeitos de suas aes.
Limites de WIP* do Kanban possibilitam o comportamento pare a linha.
Limites de WIP do Kanban incentivam o comportamento de enxame para
resolver problemas.
Uma maior colaborao atravs do comportamento de enxame sobre os problemas e interao com interessados externos aumenta o nvel de capital
social na equipe e a confiana entre seus membros.
Limites de WIP do Kanban e classes de servio do poder aos indivduos de
puxar trabalho e tomar decises de priorizao e agendamento sem superviso ou direo de um superior.
Maiores nveis de autonomia aumentam o capital social entre os trabalhadores e gerentes.
Comportamento colaborativo pode se espalhar de forma viral.
Indivduos buscaro a liderana em seus gerentes seniores. Comportamento
colaborativo e de coleguismo entre os lideres seniores afetaro o comportamento de toda a fora de trabalho.

* N. de T.: Sigla de work-in-progress.


N. de T.: swarming, no original


PARTE TRS

Implementando Kanban

C aptulo 6

Mapeando a Cadeia
de Valor

anban uma abordagem que conduz mudana no processo existente pelo aperfeioamento. A essncia de se comear com
Kanban mudar o mnimo possvel. Voc deve resistir a tentao de
mudar o fluxo de trabalho, nomes dos cargos, papis e responsabilidades, e prticas de trabalho especficas. Tudo o que os membros da
equipe e outros parceiros, participantes, e stakeholders derivaram da
sua auto-estima, orgulho profissional, e ego devem permanecer inalterados. O alvo principal da mudana ser a quantidade do WIP e a
interface e interao com as partes do negcio da cadeia de valor.
Ento voc deve trabalhar com a sua equipe para mapear a cadeia de
valor como ela existe. Tente no mud-la ou invent-la numa maneira
idealizada.
Em algumas situaes polticas, pode existir um processo oficial
que no est sendo seguido. Quando voc tenta mapear a cadeia de
valor, sua equipe insistir que voc re-documente o processo oficial,
e no o processo sendo usado. Voc deve resistir a isso e insistir que
a equipe mapeie o processo que eles realmente usam. Sem isso ser
impossvel usar uma parede de cartes como uma ferramenta de visualizao de processo porque os membros da equipe s podem usar
a parede de cartes se ela refletir o que eles realmente fazem.

71

72

Captulo 6 Mapeando a Cadeia de Valor

Definindo um Ponto Inicial e Final de Controle


necessrio decidir onde comear e onde finalizar a visualizao do processo, e
fazendo isso, definir os pontos de interface com os parceiros envolvidos antes do ponto
inicial e aps o final. importante lidar com esse estgio inicial da implementao
de Kanban, visto que escolhas erradas podem levar a falhas. Equipes bem sucedidas
tendem a adotar a visualizao do fluxo de trabalho com cartes e limites de WIP
dentro da sua esfera poltica de controle, e negociar uma nova maneira de interagir
com os parceiros imediatos fora dessa esfera. Por exemplo, se voc controla o departamento de engenharia ou desenvolvimento de software e tem controle ou influncia
sobre anlise, projeto, teste, e codificao; ento mapeie esta cadeia de valor e negocie
novos estilos de interao com os parceiros de negcio envolvidos antes da cadeia de
valor que fornecem requisitos, priorizao, e gerenciamento de portflio, e aqueles
envolvidos aps a cadeia de valor como operao de sistemas, ou departamento de
produo-manuteno. Colocando os limites dessa maneira, voc est solicitando
sua equipe apenas a adotar o comportamento de limitar o WIP. Voc no est solicitando s equipes envolvidas antes e aps a cadeia de valor a mudar a maneira como
elas trabalham. Voc no est solicitando a eles interagir com voc de uma maneira
diferente e sim a interagir de uma maneira compatvel com o sistema puxado que
voc quer implementar.

Tipos de Item de Trabalho


Uma vez que voc tenha selecionado o ponto inicial no fluxo de trabalho ou cadeia de
valor, identifique os tipos de trabalho que chegam nesse ponto e quaisquer outros que
existam dentro do fluxo de trabalho que precisaro ser limitados. Por exemplo, defeitos so como um tipo de trabalho que existe dentro do fluxo de trabalho. Voc pode
identificar outros tipos de trabalho centrados no desenvolvimento, como refactoring*,
manuteno de sistema, atualizao de infra-estrutura e trabalhos relacionados. Para
trabalho na entrada, voc pode ter tipos como User Story ou Use Case ou Requisito
Funcional ou Feature. Em alguns casos, os tipos da entrada podem ser hierrquicos,
como Epic, uma coleo de user stories.
* N. de T.: Termo no traduzido devido sua utilizao mais ampla no idioma original (Ingls) pela comunidade de TI no
Brasil. Traduo: refatorao.
N. de T.: Termo no traduzido devido sua utilizao mais ampla no idioma original (Ingls) pela comunidade de TI no
Brasil. Traduo: Estria de Usurio.
N. de T.: Termo no traduzido devido sua utilizao mais ampla no idioma original (Ingls) pela comunidade de TI no
Brasil. Traduo: Caso de Uso.
N. de T.: Termo no traduzido devido sua utilizao mais ampla no idioma original (Ingls) pela comunidade de TI no
Brasil. Traduo: pica.

Desenhando uma Parede de Cartes

Tipos tpicos de itens de trabalho vistos em equipes que adotam Kanban tm includo, mas no so limitados, aos seguintes.
Requisito
Feature
User Story
Use Case
Solicitao de Mudana
Defeito em Produo
Manuteno
Refactoring
Defeito
Sugesto de Melhoria
Blocking Issue
til relacionar tipos de item de trabalho a sua fonte, como Requisito Regulatrio,
Solicitao da rea de Vendas, Requisito de Planejamento Estratgico, e assim por
diante. Usar uma conveno para a nomenclatura que faz com que a fonte da solicitao
seja transparente fornece um contexto adicional e permite que o sistema evolua para
servir mltiplos clientes.
Tipos de item de trabalho tendem a ser definidos pela fonte do trabalho, o fluxo do
trabalho, ou o tamanho do trabalho. Por exemplo, os PTCs do exemplo da Microsoft
no captulo 4 tm um fluxo de trabalho diferente, apesar de a fonte ser a mesma das
Solicitaes de Mudana. No faz sentido ter dois sistemas kanban diferentes para
os dois tipos. A mesma equipe faz o trabalho. fcil visualizar os tipos usando cores
diferentes de tickets ou linhas diferentes (raias) numa parede de cartes.

Desenhando uma Parede de Cartes


tpico desenhar paredes de carto para mostrar as atividades que acontecem ao trabalho em vez de funes especficas ou descries de trabalho. Frequentemente h uma
sobreposio forte entre uma funo e uma atividade; por exemplo, analistas realizam
anlise. No entanto, a conveno com o uso de Kanban em projetos de software ao
longo dos ltimos anos tem sido modelar o trabalho e no os trabalhadores, as funes,
ou a interao entre as funes.

73

74

Captulo 6 Mapeando a Cadeia de Valor

Antes de desenhar uma parede de carto para visualizar o fluxo de trabalho, faz sentido fazer um rascunho ou model-la. Figura 4.4 (pgina 46) mostra um modelo muito
formal, usando uma notao de grfico de estados, do fluxo de trabalho desejado, com
filas includas para solicitao de mudana e mudanas de texto em produo processadas pela equipe de manuteno do XIT na Microsoft. Voc pode encontrar uma
abordagem menos formal perfeitamente adequada. Um desenho com atores, similar
quele apresentado no captulo 4, ou um grfico de fluxo ou seu equivalente pode ser
suficiente.
Uma vez que voc entendeu o seu fluxo de trabalho esboando-o ou modelando-o,
comece a definir uma parede de cartes desenhando colunas num quadro que representa as atividades realizadas, na ordem em que elas so realizadas (Figura 6.1). Ao
desenhar as colunas iniciais, faz sentido risc-las com um marcador. No entanto, com
o uso as linhas sero apagadas. Durante as primeiras semanas voc perceber que vai
querer fazer algumas poucas mudanas no fluxo de trabalho, ento faz sentido continuar a usar um marcador que pode ser apagado. No entanto, haver um ponto que voc
vai querer algo mais permanente. Rolos de fita de vinil estreitos esto disponveis em
lojas de escritrio, especificamente projetados para trabalho de preciso em quadros
brancos, como ilustrado na Figura 6.2. Tornou-se comum na Corbis delinear colunas
Esboo
dede
umcartes
fluxo de
trabalho
parede
de cartes
(da esquerda para a direita
eFigura
linhas6.1
numa
parede
usando
essanuma
fita. Esta
prtica
agora largamente
adotada, com equipes usando vrias classes e tamanhos de fita para marcar linhas e
colunas.

Fig 6.1!

Fila!
Entrada!

Anlise!

Desenvolv.!

Teste!

Fluxo!
Figura 6.1 Esboo de um fluxo de trabalho numa parede de cartes (da esquerda para a direita

Stage! Prod!

Desenhando uma Parede de Cartes

Figura 6.3 Fluxo de trabalho com buffers e filas


Fig. 6.3!

Figura 6.2 Fita de preciso para quadro branco

Fila!
Anlise!
Entrada!Em Prog! Feito!

Des.
Pronto!

Desenvolv.!
Em Prog!

Feito!

Build Teste! Release Stage! Prod.!


Pronto!
Pronto!

Fluxo!
Figura 6.3 Fluxo de trabalho com buffers e filas

Note que para os passos da atividade necessrio modelar o que est em progresso
e o trabalho finalizado; por conveno isto feito dividindo-se a coluna.
Depois, adicione uma fila de entrada a qualquer atividade de entrega aps a cadeia
de valor que voc deseja visualizar, como apresentado na Figura 6.3.
Finalmente, adicione qualquer buffer ou fila que voc acredita ser necessrio. H escolas de pensamento diferentes em relao a isto, e ele realmente um tpico avanado.
Uma discusso completa sobre onde colocar buffers e como dimension-los est alm
do escopo deste livro, ento ser suficiente nesse momento descrever duas abordagens
populares.

75

76

Captulo 6 Mapeando a Cadeia de Valor

Figura 6.4 Parede de cartes ilustrando o uso de cartes com formato de diamante no topo das colunas de fila ou buffer (cortesia da
Liquidnet Holdings, Inc.)

A primeira escola de pensamento diz para no tentarmos adivinhar a localizao do


gargalo ou a fonte de variabilidade que precisar de um buffer. Em vez disso, implemente o sistema e espere que o gargalo se revele, ento faa mudanas para introduzir
um buffer (Figura 6.4).
Uma variante desta abordagem sugere que inicialmente devem ser atribudos limites de WIP razoavelmente fracos para que a variabilidade, desperdcio, e gargalos no
tenham um impacto significante na primeira implementao do sistema puxado. Isto
discutido em mais detalhe no captulo 10, e depois nos captulos 17 e 19.
Outra escola de pensamento usa uma abordagem diferente. Ela sugere que em vez
de implementar limites de WIP frouxos para evitar uma introduo desafiadora do
sistema, cada estgio deve ser buffered, e as atividades devem ter limites bem apertados.
Gargalos e variabilidade se revelaro assim que os buffers ficarem cheios. Mudanas
pequenas e simples podem ento ser tomadas para reduzir o tamanho dos buffers e
ento eventualmente voc pode eliminar buffers desnecessrios.
Durante a escrita deste livro, no houve evidncia suficiente que sugerisse qual abordagem a melhor.
Algumas equipes adotaram uma conveno de mostrar colunas de buffers e filas
usando um carto com uma rotao de 45 graus. Isto fornece um indicador de

Anlise da Demanda

visualizao forte sobre quanto trabalho est fluindo em vez de estar enfileirado em
qualquer instante no tempo. Isto permite que a equipe e outros stakeholders vejam,
literalmente, a quantidade do custo econmico (ou desperdcio) no sistema.

Anlise da Demanda
Para cada tipo de trabalho identificado, voc deve fazer um estudo da demanda. Se
voc tem dados histricos, use-os para fazer um estudo quantitativo. Se voc no
tem, ento uma anlise derivada de forma subjetiva ser suficiente. No exemplo da
Microsoft XIT no captulo 4, por exemplo, havia dois tipos de trabalho, Solicitaes
de Mudana e Mudana de Texto em Produo - Production Text Changes (PTCs).
Indiscutivelmente, as Solicitaes de Mudana deveriam ser quebradas em dois tipos,
Defeitos em Produo e Solicitaes de Mudana (para nova funcionalidade). Se eu
estivesse apoiando essa equipe hoje, eu recomendaria que ela acompanhasse quatro
tipos de trabalho no total: Solicitaes de Mudana, Defeitos em Produo, Mudanas
de Texto em Produo, e Defeitos (ou defeitos escapados).
Para cada um destes tipos deveramos estudar a demanda. As demandas para PTCs
vinham em rajadas. Podiam no existir PTCs por seis semanas, e numa nica semana
podia haver uma exploso de talvez dez chegando de uma nica vez. PTCs eram pequenos e rpidos de implementar. Isto significava que o seu impacto no era forte. difcil
desenhar um sistema para lidar com uma demanda intermitente como esta. Se PTCs
representassem um esforo significante, seria necessria a construo de um espao
considervel no sistema para lidar adequadamente com os PTCs para no impactar
fortemente na previsibilidade das Solicitaes de Mudana.
Solicitaes de Mudana, por outro lado, chegavam num ritmo muito mais constante. Enquanto a sua chegada era de natureza estocstica, a demanda era relativamente
constante, de aproximadamente cinco a sete novas requisies por semana. Seria possvel colocar num grfico a taxa de chegada dos PTCs e colocar a demanda para entender
a taxa mdia de chegada e a propagao da variao. O sistema kanban pode ento ser
projetado e recursos alocados adequadamente para lidar com esta demanda.
Alguns tipos de item de trabalho exibem uma demanda sazonal, como requisitos
regulatrios. Novos impostos legislativos afetam sistemas financeiros e de folha de
pagamento de maneira sazonal. Em um caso que me deparei, o departamento de TI de
uma equipe de corrida automobilstica recebia mudanas regulatrias do corpo diretivo do esporte no incio de cada temporada de corrida. Eles podiam tambm receber
requisitos regulatrios durante a temporada, mas o volume sobre a pr-temporada
era significativamente maior, visto que os principais regulamentos da corrida eram

77

78

Captulo 6 Mapeando a Cadeia de Valor

alterados de um ano para o outro. importante entender esta demanda para que o
projeto do sistema kanban possa ser ajustado para lidar com a demanda para tipos
diferentes de trabalho.

Alocando Capacidade de Acordo com a Demanda


Uma vez que voc tenha o entendimento da demanda, voc pode decidir como alocar
capacidade dentro do sistema kanban para lidar com a demanda. O exemplo na Figura
6.5 mostra trs raias, uma para cada tipo de trabalho, nomeadas, change requests*;
internal maintenance work, como refactoring de cdigo; e production text changes. A
alocao 60 por cento para change requests, 10 por cento para trabalho de refactoring
de cdigo, e 30 por cento para production text changes. Dada uma anlise da demanda
que mostra que production text changes chegam a rajadas, a alocao apresentada
sugere que um espao significante est sendo reservado para lidar urgentemente com
production text changes que chegam sem impactar datas de entrega de outros trabalhos. A alocao de capacidade deve estar alinhada ao perfil de risco. Se, por exemplo,
aceitvel que o desempenho de entrega na data caia quando production text changes
chegam, e que lead times das requisies de mudana sejam maiores e menos previsveis, a alocao poderia ser diferente. Talvez 85 por cento para change requests, 10
porFigura
cento6.5para
maintenance,
5 porindicando
cento para
production
text changes. Outra escolha
Quadro
Kanban come raias,
capacidade
da alocao

Fig 6.5

Fila Entrada

Anlise

Em Prog

Feito

Des.
Pronto

Desenvolv.

Em Prog Feito

Build Teste Release


Pronto
Pronto ...

Solicitao
Mudana
60%

Manuteno
10%
Mudana de Texto
em Produo
30%

Figura 6.5 Quadro Kanban com raias, indicando capacidade da alocao


* N. de T.: Termo no traduzido. Traduo: solicitaes de mudana.
N. de T.: Termo no traduzido. Traduo: trabalho de manuteno interno.
N. de T.: Termo no traduzido. Traduo: mudanas de texto em produo.

Anatomia de um Carto de Item de Trabalho

poderia ser deixar uma raia para production text changes, mas no alocar capacidade
para ela, e adotar uma poltica de exceder o limite do trabalho-em-progresso quando
uma rajada de production text changes chegar. Esta poltica eliminar espao e produzir uma sada econmica ideal durante a operao normal. No entanto, quando uma
exploso de production text changes chegar, outros trabalhos podem ser fortemente
impactados no lead time e na previsibilidade. Esta foi a escolha feita em muitos exemplos reais do captulo 4; no havia capacidade sobressalente reservada para lidar com
production text changes.
Mais tarde, quando discutirmos sobre atribuio de limites para trabalho-em-progresso, usaremos esta informao de alocao para atribuir limites especficos para
filas em cada raia.

Anatomia de um Carto de Item de Trabalho


Cada carto visual que representa um pedao discreto de trabalho de valor para o
cliente contm muitas informaes. O projeto do carto importante. A informao
nos cartes deve facilitar o sistema puxado e dar poder aos indivduos para tomarem
suas prprias decises ao puxar. A informao num ticket pode variar por tipo de
trabalho ou por classe de servio (discutido no captulo 11).
No exemplo da Figura 6.6, o nmero no topo esquerda o nmero eletrnico de
acompanhamento usado para
unicamente o item e para lig-lo a sua verso
6.6identificar
!

Problema anexado
solicitao de
mudana indica
necessidade de
ateno da gerncia!

Nmero!
eletrnico ID!

Data de entrega difcil


devido a razes
regulatrias, legais, ou
estratgicas!

Engenheiro!
atribudo!
Data de Aceite
tempo inicial no SLA!

Representa um item que


excedeu o SLA indica que o
item deve ser priorizado, se
possvel!

Figura 6.6 Zoom de uma parede de cartes apresentando a anatomia dos cartes de item de trabalho

79

80

Captulo 6 Mapeando a Cadeia de Valor

eletrnica no sistema de acompanhamento. O ttulo do item escrito no meio do carto. A data que o item entrou no sistema escrita abaixo no lado esquerdo, que tem
um propsito duplo: Facilita o enfileiramento first-in, first-out (FIFO) para classe de
servio padro, e permite que os membros da equipe vejam quantos dias expiraram
em relao ao acordo de nvel de servio (descrito no captulo 11). Para itens de classe
de servio de data de entrega fixa, a data de entrega requerida escrita abaixo do lado
direito do ticket.
No exemplo da Figura 6.6, outras informaes so mostradas fora do ticket. Uma
estrela indica que o item est atrasado em relao ao lead time do nvel de acordo de
servio. Eu tenho visto isto sendo feito mais recentemente anexando uma etiqueta na
parte de cima direita do ticket. O nome da pessoa atribuda tambm escrito em
cima do ticket. Como a pessoa atribuda mudar medida que o ticket fluir atravs
do quadro, indesejvel escrever o nome no ticket. No entanto, implementaes mais
recentes apresentam pequenas etiquetas presas aos itens, o uso de ims (quando o
quadro branco magntico), e etiquetas ou ims com os avatares dos membros da
equipe. Personagens do South Park so escolhas populares para os avatares. Qualquer
mecanismo que permite aos membros da equipe e a gerncia imediata visualizarem
rapidamente quem est trabalhando suficiente.
Como regra geral, o projeto do ticket usado para representar um pedao individual
de trabalho deve possuir informao suficiente para facilitar decises de gerenciamento
de projeto, como qual deve ser o prximo item a ser puxado, sem a interveno da direo ou gerncia. A ideia delegar poder aos membros da equipe com transparncia
do processo, objetivos do projeto, e informao sobre risco. medida que voc descobre mais sobre classes de servio e nveis de acordo de servio, voc descobrir que
Kanban facilita um mecanismo poderoso de auto-organizao e gerenciamento de risco.
Igualmente, delegando poder aos membros da equipe para fazer seu prprio agendamento e priorizar decises, Kanban mostra respeito aos indivduos e uma confiana no
sistema (ou projeto do processo). Um carto de item de trabalho bem projetado um
elemento chave para uma cultura de alta confiana e uma organizao Lean.

Acompanhamento Eletrnico
Acompanhamento eletrnico tem sido uma caracterstica de um sistema kanban em
desenvolvimento de software desde que ele foi primeiramente introduzido em 2004.
Isto , no entanto, opcional. Para equipes distribudas geograficamente, ou para aquelas
que possuem polticas que permitem que os membros da equipe trabalhem nas suas
casas uma ou mais vezes por semana, o acompanhamento eletrnico essencial. O

Acompanhamento Eletrnico

Figura 6.7 Screen shot da ferramenta de acompanhamento eletrnico Agile Zen

acompanhamento eletrnico pode ser realizado com sistemas de acompanhamento


de tickets e itens de trabalho bsicos, como Jira, Microsoft Team Foundation Server,
Fog Bugz, e HP Quality Center. No entanto, um sistema mais poderoso permitir que
voc visualize o acompanhamento dos itens de trabalho como se fosse numa parede
de cartes.
Durante a escrita deste livro, uma quantidade de ferramentas web-based e application-based estavam surgindo no mercado para fornecer acompanhamento eletrnico
usando quadros visuais que simulam paredes de cartes com colunas, limites de WIP,
e outros aspectos essenciais de Kanban. Estas incluem, mas no esto limitadas a:
Lean Kit Kanban, Agile Zen, Target Process, Silver Catalyst, RadTrack, Kanbanery,
VersionOne, Greenhopper para Jira, Flow.io, e alguns projetos adicionais open-source
que adicionam interfaces Kanban a ferramentas como Team Foundation Server e
FogBugz. A Figura 6.7 mostra um exemplo da AgileZen.
O acompanhamento eletrnico necessrio para equipes que aspiram nveis mais
altos de maturidade organizacional. Se voc prev a necessidade para gerenciamento
quantitativo, desempenho do processo organizacional (comparar o desempenho atravs de sistemas kanban, equipes ou projetos), e/ou anlise e resoluo de causa raiz
(anlise de causa raiz baseada em dados estatsticos), voc usar uma ferramenta eletrnica desde o incio.

81

82

Captulo 6 Mapeando a Cadeia de Valor

Atribuindo Limites de Entrada e Sada


Alinhe o projeto do sistema kanban e a parede de cartes com uma deciso tomada
antecipadamente para delimitar o limite de controle do WIP. provvel que os seus
parceiros envolvidos antes e aps a sua cadeia de valor solicitem visualizar o seu trabalho na parede de cartes. No entanto, melhor fornecer transparncia dentro do seu
trabalho primeiramente e esperar que os outros solicitem fazer parte da sua iniciativa
Kanban.
No exemplo mostrado na Figura 6.8, a fila de entrada designada E.R para
Engineering Ready. Faz sentido atribuir o ponto de entrada nesse momento do ciclo
de vida porque o departamento de anlise de negcio que atua antes da cadeia de valor
reporta atravs de uma parte diferente da estrutura da organizao. H pouca confiana
ou colaborao entre os gerentes atravs dos dois grupos. A fila de entrada, portanto, foi
reabastecida do backlog de requisitos gerados pelo departamento de anlise de negcio.
Neste exemplo, a entrega da cadeia de valor a implantao em produo. Uma vez
que o software implantado e entregue para o departamento de operaes de redes e
sistemas para manuteno e suporte dirio, ele considerado fora do escopo.

Figura 6.8 Apresentando a fila de entrada Engineering Ready (ER)

Lidando com Concorrncia

Lidando com Concorrncia


Uma concorrncia comum ao desenhar uma parede de cartes para um sistema kanban
um processo no qual duas ou mais atividades podem ocorrer concorrentemente, por
6.9!

Coluna Aberta para Atividades Concorrentes!


5!

8!

4!

Fila!
Entrada!

Anlise!

Em Prog!

Feito!

2!

2!

Des. & Des. Testes!


Em Prog!

Feito!

Teste Teste! Release


Pronto!
Pronto! ...!

Figura 6.9 Coluna aberta para atividades concorrentes


6.10!

Coluna Dividida para


Atividades Concorrentes!
5!

4!

4!

2!

2!

4!

Fila!
Anlise!
Entrada! Em Prog! Feito!

Des. !

Em Prog!

Feito!

Teste Teste! Release


Pronto!
Pronto! ...!
!

Combinar!
4!

Dividir!

Des. Testes!
In Prog!

Figura 6.10 Coluna dividida para atividades concorrentes


Figura 6.10 Coluna dividida para colunas concorrentes

83

84

Captulo 6 Mapeando a Cadeia de Valor


6.11!

Coluna Aberta para Atividades


No Sequenciais!
5!

4!

8!

Fila!
Anlise!
Entrada! Em Prog! Feito!

2!

Des. & Des. Testes!


Em Prog!

Feito!

2!

Teste Teste! Release


Pronto!
Pronto! ...!


Projeto UI!
Segurana!

Persistncia!
Lgica Negcio!

6.12!

Figura 6.11 Coluna aberta para atividades no sequenciais


Figura 6.11 Coluna aberta para atividades no sequenciais

Coluna Dividida para


Atividades No Sequenciais!
5!

4!

Fila!
Anlise!
Entrada! Em Prog! Feito!

2!

4!

Desenvolv.!

Em Prog!
Projto UI!

Feito!

Teste Teste! Release


Pronto!
Pronto! ...!

Segurana!

Projeto UI!
Segurana!
Persistncia!
Lgica Negcio!

2!

Persistncia!



Lgica Negcio!

Figura
6.12 Coluna dividida para atividades no sequenciais
Figura 6.12 Coluna dividida para atividades no sequenciais

Lidando com atividades Desordenadas

exemplo, desenvolvimento de software e teste de software. H dois padres bsicos


para lidar com esta situao. Um no model-la de maneira alguma; apenas deixe
uma coluna onde as duas atividades podem ocorrer juntas (Figua 6.9). Isto simples,
mas muitas equipes no optaram por esse padro. Algumas equipes tm adaptado esse
modelo usando cores de tickets para mostrar atividades diferentes. A outra opo
dividir o quadro verticalmente em duas (ou mais) partes (Figura 6.10).
Neste exemplo, necessrio algum mecanismo de marcao para ligar itens acima
no quadro com os itens abaixo no quadro. Isto pode envolver, por exemplo, uma referncia cruzada na parte de cima direita do ticket ao seu item associado. Num bom
sistema de acompanhamento eletrnico possvel ligar itens relacionados como atividades de desenvolvimento e teste.

Lidando com atividades Desordenadas


Particularmente em trabalhos de alta inovao e experimentais, haver muitas atividades que acontecem num pedao de trabalho de valor para o cliente, mas estas atividades
no precisam acontecer em qualquer ordem em particular. Nestas circunstncias,
importante perceber que Kanban no deve forar voc a completar as atividades numa
ordem determinada. O que importante ao modelar seu sistema kanban que ele deve
refletir a maneira que o trabalho real feito.
H algumas estratgias para o problema de mltiplas atividades desordenadas. A
primeira similar ao lidar com concorrncia: Tenha simplesmente uma nica coluna
como um balde de atividades e no acompanhe explicitamente no quadro qual delas
finalizada.
A segunda, e potencialmente a escolha mais poderosa, modelar as atividades de
maneira similar a atividades concorrentes. Neste projeto, como mostrado na Figura
6.11, os tickets devem se mover verticalmente para cima e para baixo nas colunas
medida que eles so puxados para cada uma das atividades especficas. Podem-se visualizar quais atividades foram finalizadas para cada item modificando-se o projeto
do ticket para se ter uma caixa pequena para cada atividade. Quando uma atividade
finalizada, a caixa pode ser preenchida para visualmente sinalizar que o item est
pronto para ser puxado para outra atividade na mesma coluna. Se todas as caixas so
preenchidas, o item est pronto para ser puxado para a prxima coluna no quadro, ou
pode ser movido para a coluna done (Figura 6.12).

85

86

Captulo 6 Mapeando a Cadeia de Valor

Takeaways
Decida os limites externos do sistema kanban. frequentemente melhor
limitar isto para o escopo imediato de controle poltico. No force visualizao, transparncia, e limites de WIP em qualquer departamento que no
colabora voluntariamente.
Modele a parede de cartes alinhada s decises tomadas limitando WIP e
visualizao do trabalho.
Defina tipos de item de trabalho e modele como os seus trabalhos fluem.
Alguns tipos podem no precisar de todos os passos no fluxo.
Projete o carto do item de trabalho para que ele tenha informao suficiente
para facilitar auto-organizao para puxar, e permitir que os membros da
equipe tomem decises de alta qualidade considerando o risco, baseando-se
no tipo do item de trabalho, acordos de nvel de servio, e classes de servio.
Use um sistema de acompanhamento eletrnico se a equipe distribuda,
tem alguma poltica de trabalho em casa, ou aspira um comportamento de
alta maturidade que requer informao quantitativa que um sistema eletrnico pode fornecer.
Quando apropriado, discuta mtodos para lidar com concorrncia de atividade e escolha como model-las e visualiz-las.
Quando apropriado, discuta mtodos para lidar com atividades que no
precisam seguir um fluxo ordenado especfico e escolha como model-las e
visualiz-las.

C aptulo 7

Coordenao com
Sistemas Kanban
Controle Visual e Puxado
Quando as pessoas falam sobre Kanban, a forma mais popular de
coordenao que vem a mente a parede de cartes. Tipicamente,
os limites de trabalho-em-progresso so desenhados no quadro no
topo de cada coluna ou atravs de uma extenso das colunas. O ato
de puxar sinalizado se o nmero de cartes na coluna menor do
que o limite indicado. Na Figura 7.1, podemos ver que o limite escrito
acima de Specification* quatro itens. No entanto, h apenas trs cartes naquela coluna. Como 4 3 = 1, isto sinaliza que podemos puxar
um item para Specification (o departamento de anlise de sistemas) da
fila de entrada, Engineering Ready. Por sua vez, a fila de entrada tem
um limite de cinco. H atualmente apenas dois itens restando naquela
fila. Quando puxamos um item para Analysis, haver apenas um item
restando (5 1 = 4). Isto sinaliza que podemos priorizar quatro novos
itens para a fila de entrada na prxima reunio de priorizao.
Quando uma equipe decide puxar um item, ela pode escolher qual
item puxar tendo como base a informao visual disponvel, como
o tipo do item de trabalho, a classe de servio, a data da entrega (se
* N. de T.: Traduo: Especificao.
N. de T.: Traduo: Engenharia Finalizada/Pronta.
N. de T.: Traduo: Anlise.
87

88

Captulo 6 Mapeando a Cadeia de Valor

Figura 7.1 Mostrando limites kanban acima na parede de cartes

Figura 7.2 Zoom da parede de cartes mostrando a anatomia dos detalhes do carto

Acompanhamento Eletrnico

aplicvel), e a idade do item de trabalho. Polticas para puxar relacionadas s classes de


servio sero discutidas no captulo 11.
A Figura 7.2 mostra de perto algumas notas que representam itens de trabalho na
nossa parede de cartes. As cores so utilizadas para comunicar uma combinao de
tipos de item de trabalho e classes de servio. O nome do dono ou membro da equipe
atribudo escrito acima do carto. Algumas equipes gostam de usar notas adesivas
menores com nomes, ou pequenos avatares colados ao item de trabalho para mostrar
quem est trabalhando nele. Isto permite que todos na equipe vejam quem est trabalhando naquilo.
Na Figura 6.6, o nmero de acompanhamento eletrnico mostrado no topo do
lado esquerdo do post-it. A data que um item entrou na fila de entrada apresentada
na parte de baixo do lado esquerdo do post-it. A idade do item pode ser deduzida a
partir desta data. Se um item uma classe de servio que tem uma data de entrega
garantida, isso apresentado na parte de baixo do lado direito do post-it. Se um item
est atrasado, isso representado com um asterisco vermelho no topo do post-it do
lado direito. Se algo est bloqueado, um ticket rosa anexado ao item bloqueado. No
exemplo da Figura 7.2, um problema um item de trabalho de primeira classe, uma
vez que ele possui seu prprio nmero eletrnico de acompanhamento, uma data na
qual ele entrou no sistema, e um membro da equipe com atribuio para resolv-lo
apresentado na parte de cima dele.
Este esquema idiossincrtico para a primeira implementao kanban na Corbis.
Sua implementao ir certamente diferir. No entanto, voc provavelmente vai querer capturar visualmente o membro da equipe atribudo, a data inicial, o nmero de
acompanhamento eletrnico, o tipo do item de trabalho, a classe de servio, e alguma
informao de status, como se o item est atrasado ou no. O objetivo visualmente
comunicar informao suficiente para tornar o sistema auto-organizvel e auto-expediting no nvel da equipe. Como um mecanismo de controle visual, o quadro kanban
deve permitir que os membros da equipe puxem trabalho sem direo do seu gerente.

Acompanhamento Eletrnico
Como uma alternativa, ou, como um complemento, para a parede de cartes, um sistema
eletrnico frequentemente utilizado para acompanhar trabalho num sistema kanban.
Algumas das ferramentas disponveis para isto so listadas no captulo 6. Para uma lista
mais atualizada, visite a pgina na web da Limited WIP Society, www.limitedwipsociety.org.
Com a minha equipe, ns implementamos nossa prpria aplicao, Digital
Whiteboard (veja Figura 7.3) , a partir do Team Foundation Server. No caso de estudo

89

Fig

90

7.3!

Captulo 7 Coordenao com Sistemas Kanban

Figura 7.3 Quadro branco digital utilizado na Corbis

Figura 7.3 Quadro branco digital utilizado na Corbis

do captulo 4, o acompanhamento eletrnico foi feito utilizando uma ferramenta interna da Microsoft chamada Product Studio. Ela foi precursora da Team Foundation
Server, e desde 2005 a Microsoft tem usado Team Foundation Server para o seu prprio
acompanhamento interno de projetos de desenvolvimento.
A aplicao mostrada na Figura 7.3 apresenta os limites kanban agrupados acima
nas colunas. Ela capaz de mostrar visualmente quando um limite kanban excedido.
Ela tambm apresenta a quantidade de itens de status para cada item de trabalho,
incluindo cones diferentes que mostram se um item est atrasado ou est bloqueado
com um problema.
O acompanhamento eletrnico importante para sistemas kanban porque ele permite muitas coisas que no so viveis com uma parede de cartes simples. O acompanhamento eletrnico permite coleta de dados que podem ser usados para gerar mtricas
e relatrios para o dia a dia do gerenciamento e para retrospectivas, por exemplo, nas
revises operacionais mensais.

Reunies Standup Dirias


Reunies standup* so um elemento comum nos processos de desenvolvimento
geis. Elas acontecem tipicamente pela manh antes que o trabalho comece e seguem
* N. de T.: Termo no traduzido devido sua utilizao mais ampla no idioma original (Ingls) pela comunidade de TI no
Brasil. Traduo: em p.

Reunies Standup Dirias

geralmente um formato pr-acordado. Uma reunio standup tpica acontece para uma
nica equipe de aproximadamente doze pessoas usualmente em torno de seis pessoas.
O formato geralmente envolve reunir todo o grupo e fazer trs perguntas: O que foi
feito ontem? O que voc far hoje? Voc est bloqueado ou precisa de alguma ajuda?
Cada membro da equipe responde estas perguntas e ento a equipe coordenada para
fazer o trabalho do dia.
Reunies standup acontecem de maneira diferente com Kanban. A necessidade de
fazer as trs perguntas evitada pela parede de cartes. A parede contm toda a informao sobre quem est trabalhando onde. Pessoas que participam regularmente
podem ver o que mudou desde ontem e evidente visualmente se algo est bloqueado
ou no. Ento standups tm um formato diferente com um sistema kanban. O foco
no fluxo de trabalho. O facilitador, tipicamente o gerente do projeto ou um gerente de
linha, andar pelo quadro. A conveno tm se desenvolvido para se olhar o trabalho
de trs para frente da direita para a esquerda (na direo do puxar) atravs dos
tickets no quadro. O facilitador deve solicitar uma atualizao do status em um ticket
ou simplesmente perguntar se h alguma informao adicional que no est no quadro
e pode no ser conhecida pela equipe.
Uma nfase particular ser dada para itens que esto bloqueados (tm um ticket
rosa anexado) ou atrasados devido a defeitos (tm uma srie de tickets azuis anexados).
Perguntas tambm podem ser feitas sobre itens que parecem estar parados e no tm se
movimentado por alguns dias. Algumas equipes planejaram maneiras de visualizar isto.
Uma equipe de corrida italiana e fabricante de carros esportivos, por exemplo, marca
um ponto ao lado do ticket para cada dia que ele permanece numa posio nica. Isto
permite que a equipe pergunte se um item pode ser marcado como bloqueado se ele
no est fluindo ativamente. Isto melhora a capacidade de gerenciamento de problemas da organizao (descrita mais detalhadamente no captulo 20). A equipe discutir
brevemente quem est trabalhando no problema e quando ele ser resolvido. Haver
tambm uma chamada para outros problemas bloqueadores que no esto no quadro
e para as pessoas que precisam de ajuda para falar. Equipes mais avanadas e maduras
sabem que no precisaro navegar sobre cada carto na parede. Elas tendero a focar
apenas nos tickets que esto bloqueados ou que tm defeito. Este mecanismo permite
que a reunio standup seja escalada para envolver um nmero muito maior de pessoas;
Daniel Vacanti liderou uma standup bem sucedida com mais de 50 pessoas num projeto
na Corbis em 2007 onde, apesar do grande tamanho da equipe, a reunio era finalizada
em 10 minutos toda manh.

91

92

Captulo 7 Coordenao com Sistemas Kanban

O Aps a Reunio
O Aps a Reunio consiste na conversa de pequenos grupos de 2 ou 3 pessoas. Este
comportamento surgiu espontaneamente, visto que os membros da equipe queriam
discutir algo que estavam pensando: talvez um problema bloqueador, talvez um problema de projeto tcnico ou de arquitetura, mas mais frequentemente, um problema
relacionado ao processo. O Aps a Reunio um elemento vital da cultura de transformao que surge com Kanban. Aps a Reunio gera ideias de melhoria e resulta em
adaptao do processo e inovao.
Em grandes projetos, algumas Aps a Reunio tm o formato de reunies standup ao
estilo de Scrum. Equipes de no mximo seis pessoas trabalhando juntas numa feature,
story, ou requisito podem ser reunir brevemente para coordenar seus esforos do dia.
H uma diferena interessante entre esse comportamento de processo de Kanban e
Scrum. Com Scrum, as equipes primeiramente se renem e ento delegam ao Scrum
de Scrums a coordenao de um programa ou projeto grande. Com Kanban o comportamento inverso a reunio no nvel de programa acontece primeiramente.

Reunies para Reabastecimento de Fila


Reunies para reabastecimento de fila servem ao propsito de priorizao em Kanban.
Esta priorizao dita ser diferida ou adiada at o ltimo momento razovel, devido
natureza do mecanismo de reabastecimento da fila e a cadncia das reunies. Reunies
para reabastecimento de fila so realizadas com um grupo de representantes do negcio
ou donos do produto (para usar o vocabulrio do desenvolvimento gil). recomendado que estas reunies aconteam em intervalos regulares. Fornecer uma cadncia
constante para reabastecimento de fila reduz o custo de coordenao de se fazer a
reunio e fornece certeza e confiana para o relacionamento entre o negcio e a equipe
de desenvolvimento de software.
O propsito desta reunio preencher a fila do sistema kanban para uma nica
cadeia de valor, sistema, ou projeto. Stakeholders que tm interesse nas entregas de
uma equipe e que possuem itens a espera no backlog devem participar desta reunio.
Os participantes do negcio devem ser os mais seniores da organizao. Pessoas mais
seniores podem tomar mais decises e frequentemente tm acesso a uma larga informao sobre o contexto. Isto melhora a qualidade da tomada da deciso e aperfeioa
o processo de seleo para reabastecimento de fila.
Idealmente, uma reunio de priorizao vai envolver muitos donos do negcio
ou pessoas do negcio de grupos potencialmente concorrentes da empresa. A tenso criada por esta situao se torna uma influncia positiva na tomada de deciso e

Reunies de Planejamento de Release

estimula um ambiente saudvel e colaborativo com a equipe de desenvolvimento de


software. Se apenas um dono do negcio participa, h um potencial para que a interao seja controversa.
Outros stakeholders interessados devem estar presentes na reunio, idealmente incluindo: qualquer um responsvel pela entrega, por exemplo, um gerente de projeto;
pelo menos um gerente funcional tcnico, como um gerente de desenvolvimento ou
teste, ou um gerente funcional tcnico mais snior; algumas pessoas que possam avaliar risco tcnico, por exemplo, um tcnico ou arquiteto de dados; um profissional de
usabilidade; um especialista em sistemas e operao; e um analista de negcio. Com a
minha equipe em 2007, um gerente de desenvolvimento, o gerente da equipe de anlise, e ocasionalmente o arquiteto corporativo ou arquiteto de dados participavam da
reunio. Os gerentes de desenvolvimento se revezavam, participando da reunio de
maneira rotativa.
A cadncia das reunies de priorizao afetar o tamanho da fila no sistema kanban
e, portanto, o lead time geral atravs do sistema. Para maximizar a agilidade da equipe,
recomendado que as reunies sejam to frequentes quanto seja possvel; um intervalo
semanal o comumente recomendado.
Algumas equipes tm evoludo para uma priorizao orientada demanda em vez
de reunies regulares. Isto recomendado apenas para organizaes maduras nas quais
todos os stakeholders da reunio podem estar disponveis sob demanda. No caso de estudo da Microsoft do captulo 3, o gerente de projeto criou gatilhos no banco de dados
que o alertavam quando havia um espao livre na fila de entrada. Ele ento instigaria
uma discusso de priorizao com quatro donos do negcio via email, alertando-os
que o espao estava disponvel para priorizao. Uma discusso eletrnica garantiria
que um novo item seria selecionado do backlog. Este processo tipicamente durava duas
horas. Ter esse sistema por demanda em vez de uma reunio semanal poderia reduzir
o tamanho da fila, o que levaria a uma melhoria subsequente no lead time atravs do
sistema.

Reunies de Planejamento de Release


Reunies de planejamento de release acontecem especificamente para planejar o release ao final da cadeia de valor. Se os releases esto ocorrendo regularmente, com uma
cadncia, digamos, quinzenal, ento faz sentido agendar a atividade de planejamento
de release para que ela acontea regularmente. Isto reduz o custo de coordenao para
conduzir a reunio e garante que todos que precisam participar tero tempo disponvel.

93

94

Captulo 7 Coordenao com Sistemas Kanban

A pessoa responsvel por coordenar a entrega, usualmente o gerente de projeto,


tipicamente lidera as reunies de planejamento de release. Quaisquer outras partes
interessadas devem ser convidadas: Isto usualmente inclui especialistas em gerncia de
configurao; operao de sistemas e especialistas de rede; desenvolvedores; testadores;
analistas de negcio; e para todos esses colaboradores individuais, seus supervisores ou
gerentes imediatos. Especialistas esto presentes devido ao seu conhecimento tcnico e
capacidade de avaliao de riscos. Gerentes esto presentes para que decises possam
ser tomadas.
Uma organizao madura ter um checklist ou framework para um release que facilita
o planejamento. Alguns dos pontos a serem considerados so os seguintes.
Quais itens no sistema esto (ou estaro) prontos para o release?
O que necessrio para realmente fazer o release de cada item para produo?
Qual teste post-release ser necessrio para validar a integridade dos sistemas em
produo?
Quais os riscos envolvidos?
Como esses riscos esto sendo mitigados?
Quais planos de contingncia so necessrios?
Quem precisa ser envolvido no release e estar presente durante o puxar para
produo (ou outro mecanismo de entrega)?
Quanto tempo dura o release?
Quais outras logsticas sero envolvidas?
A sada deve ser um template completo representando um plano de release. Tenho
visto com equipes particularmente sofisticadas o release planejado como uma orquestrao de procedimentos a serem executados em uma sequencia determinada.
Numa reunio grande, pode ser impossvel completar um planejamento de release,
e pode ser necessrio algum trabalho de acompanhamento aps a reunio por parte
do gerente de projeto.

Triagem
Triagem um termo emprestado da profisso mdica; ele se refere prtica de avaliar e classificar pacientes de emergncia em categorias para prioridade de ateno. O

Triagem

sistema foi usado primeiramente em unidades mdicas em campos de batalha, onde


os pacientes eram separados em trs categorias: fora do alcance de ajuda e provavelmente morrer em breve, provavelmente sobreviver apenas se um tratamento mdico
imediato for realizado, e provavelmente sobreviver sem tratamento mdico imediato.
Atualmente salas de emergncia usam um sistema similar para priorizar pacientes
medida que eles chegam para tratamento.
A triagem foi adotada em desenvolvimento de software para classificar defeitos
(bugs*) durante a fase de estabilizao de um projeto de software tradicional. Triagem
utilizada para classificar bugs que sero corrigidos, e sua prioridade, versus bugs que
no sero corrigidos e ser permitido que escapem para produo quando o produto
for released. Uma triagem tpica de defeitos envolve um lder de testes, um supervisor
de testes ou gerente, um desenvolvedor lder, um desenvolvedor supervisor ou gerente,
e um dono do negcio.
Com Kanban faz sentido fazer a triagem de defeitos. No entanto, a aplicao mais
til da triagem no backlog de itens esperando para entrar no sistema.
Triagem de backlog deve ser realizada em intervalos relativamente pouco frequentes
(Nota: alguns mtodos geis de desenvolvimento de software referem-se a isso como
preparao de backlog). Mensalmente, trimestralmente, e duas vezes ao ano so intervalos que so populares com as equipes. Os participantes de uma triagem de backlog
sero tipicamente os mesmos donos do negcio ou representantes do negcio que
participam da reunio de reabastecimento de fila, juntamente ao gerente do projeto.
As pessoas tcnicas tipicamente no participaro em quantidade to grande. Talvez um
gerente mdio de funo tcnica esteja presente.
O propsito de uma triagem de backlog repassar cada item no backlog e decidir se ele deve permanecer no backlog ou se deve ser excludo. Ela no uma classificao de pilha ou fornece qualquer priorizao alm de uma escolha simples
mantenha-ou-exclua.
Algumas equipes tm evitado a necessidade de triagem atravs de automao e polticas. O caso de estudo da equipe Microsoft XIT do captulo 4 excluiria qualquer item
com mais de seis meses num intervalo mensal regular. O motivo era que se um item
no havia sido selecionado para a fila de entrada em seis meses, era improvvel que
ele tivesse um valor significante e, portanto, improvvel que ele fosse selecionado em
algum momento. Se isto acontecesse, era tambm improvvel que ele fosse solicitado
novamente e, portanto, nada era perdido ao exclu-lo do backlog.

* N. de T.: Termo no traduzido devido sua utilizao mais ampla no idioma original (Ingls) pela comunidade de TI no
Brasil. Traduo: defeitos.

95

96

Captulo 7 Coordenao com Sistemas Kanban

O propsito de se fazer uma triagem no backlog reduzir o seu tamanho. O benefcio


de um backlog menor que ele facilita discusses de priorizao. Se h 200 itens no
backlog, ser gasto um tempo significativamente menor em selecionar os ganhadores
do que se existir 2000 itens no backlog.
Uma boa regra se o backlog excede trs meses de trabalho, isto , trs meses de
rendimento de entrega, e todos os itens no backlog no podem entrar no sistema dentro deste tempo, pode ser uma boa ideia podar o backlog. O tamanho apropriado do
backlog vai variar de acordo com mercados e domnios diferentes. Domnios com uma
alta volatilidade precisaro talvez de um tamanho de backlog equivalente a um ms de
itens em trabalho. Domnios com uma volatilidade muito baixa podem ser capazes de
lidar com um backlog de at um ano de itens em trabalho.
Portanto, h uma relao entre o tamanho do backlog, a volatilidade do domnio
no qual o sistema kanban est operando, e a velocidade de entrega, ou rendimento, da
equipe. Se uma equipe entrega 20 user stories por ms e o domnio tem alguma, mas
no muita, volatilidade, ento o backlog de trs meses desejvel, o backlog deve ter
aproximadamente 60 itens.

Reviso e Escalao de Log de Problemas


Quando itens de trabalho num sistema Kanban esto impedidos, eles sero marcados
como tal e um item de trabalho de problema ser criado. O problema permanecer
aberto at que o impedimento seja removido e o item de trabalho original possa progredir atravs do sistema. Revisar problemas abertos, no entanto, torna-se vital para
melhorar o fluxo atravs do sistema.
Reviso de log de problemas deve acontecer frequentemente e regularmente.
Novamente, uma cadncia regular reduz custos de coordenao e garante que stakeholders relevantes tero tempo para participar. Organizaes muito maduras podem ser
capazes de dispensar reunies regulares e realizar reunies sob demanda. Isto ser
apropriado se h uma quantidade relativamente pequena de problemas em aberto e se
o custo de coordenao maior em reunies sob demanda realmente menor do que o
custo de se realizar uma reunio agendada regularmente.
Revises de log de problemas devem envolver o gerente de projeto e os membros da
equipe que possuem itens bloqueados. As principais perguntas a serem respondidas
so Quem est atribudo e trabalhando no problema? e Para quando a resoluo
esperada? Problemas que no esto progredindo e esto eles mesmos bloqueados e
antigos devem ser escalados para a gerncia mais snior.

Avatar Amigo (Sticky Buddies)

Pode no ser necessrio que a gerncia snior esteja presente na reviso de log de
problemas, mas importante se ter caminhos e polticas de escalao claramente
definidos.
Gerenciamento e escalao de problemas so tipicamente mal conduzidos, at
mesmo em organizaes de desenvolvimento gil. Resolver problemas rapidamente,
particularmente problemas que so externos a equipe de desenvolvimento, como disponibilidade do ambiente, requisitos ambguos, ou falta de equipamento para teste,
melhora o fluxo e aumenta muito a produtividade da equipe e o valor entregue.
Gerenciamento e escalao de problemas so disciplinas importantes que fornecem
um grande retorno. Melhor-las deve ser uma prioridade at mesmo para equipes
imaturas. Isto discutido no captulo 20.

Avatar Amigo (Sticky Buddies)


O conceito de um avatar amigo foi introduzido na Corbis para resolver um problema de coordenao. Havia uma poltica que permitia a realizao de home office
pelo menos uma vez por semana, particularmente para funcionrios que moravam
longe da cidade. A poltica remonta a uma mudana de escritrio de Bellevue para
Seattle, Washington, alguns anos antes. Pessoas em home office eram capazes de acessar o sistema de acompanhamento eletrnico, controle de verso, ambiente de build, e
assim por diante via VPN. Ento eles eram capazes de visualizar o trabalho atribudo
para eles, trabalhar neles, complet-los e test-los. Eles eram capazes de atualizar o
status eletrnico do trabalho, marc-lo como finalizado e de torn-los disponveis para
serem puxados para o fim da cadeia de valor. No entanto, eles no estavam fisicamente
presentes no escritrio e aptos a moverem a sua etiqueta na parede de cartes.
A soluo para isto foi cada pessoa em home office fazer um acordo com alguma
pessoa par que estaria presente no escritrio para agir como seu delegado. Quando
algum em home office finalizava um item e mudava seu status eletrnico, ele deveria
contatar seu avatar amigo por mensagem instantnea, email, ou telefone, e solicit-lo
a atualizar o quadro fsico.
Avatares amigos tambm facilitavam o desenvolvimento distribudo atravs de
diferentes localizaes geogrficas. Isto foi particularmente importante na Corbis, visto
que a equipe de teste estava em Chennai, na ndia, e havia outros desenvolvedores
especialistas em sistemas financeiros no Sul da Califrnia.

97

98

Captulo 7 Coordenao com Sistemas Kanban

Sincronizao atravs de Localizaes Geogrficas


Sincronizar equipes que usam sistema kanban atravs de localizaes geogrficas mltiplas um assunto que vem sempre a tona como uma questo elementar para aqueles
que consideram implementar um sistema kanban. Frequentemente o questionador
assume que implementaes anteriores de Kanban foram realizadas numa nica localizao geogrfica e que eu (e outros defensores de Kanban) no considerei os desafios
de coordenao atravs de equipes geograficamente distribudas.
Na verdade, o oposto verdadeiro. A primeira equipe da Microsoft, do captulo 4,
estava localizada em Hyderabad, ndia, com o gerenciamento e donos do negcio em
Redmond, Washington. Corbis, descrita no captulo 5, tambm tinha pessoas na ndia
e outras localidades fora de Seattle, como Los Angeles e Nova York, como tambm
pessoas em home office.
A chave para coordenar atravs de mltiplas localizaes usar um sistema eletrnico; no suficiente ter apenas uma parede de cartes.
Alm do acompanhamento eletrnico, ser necessrio manter a parede fsica de
cartes sincronizada, pelo menos diariamente. importante atribuir a algum essa
responsabilidade em cada localizao. Uma equipe que trabalhamos em 2008 era distribuda entre Nova York e Los Angeles. Eles mantinham (quase sempre) paredes de
carto idnticas em cada localizao e faziam com que um membro da equipe fosse
responsvel por mant-las sincronizadas diariamente.
Algumas equipes coordenam reunies standup pelo telefone ou usando um sistema
de vdeo-conferncia. Antes de qualquer reunio standup, vdeo-conferncia, ou chamada telefnica, a pessoa localmente responsvel deveria gastar um tempo para garantir que o quadro fsico estava sincronizado com o sistema eletrnico.

Takeaways
99

Takeaways
A melhor prtica utilizar uma parede fsica de cartes e um sistema de
acompanhamento eletrnico.
possvel utilizar Kanban atravs de localizaes geogrficas mltiplas,
desde que um sistema eletrnico esteja sendo utilizado.
Sistemas eletrnicos que simulam a funcionalidade de uma parede fsica de
cartes esto disponveis em uma variedade de fornecedores.
Realizar reunies regulares reduz o custo de coordenao para estas reunies
e melhora a participao.
Priorizao e planejamento de release devem ser realizados independentemente e devem ter uma cadncia independente.
Reunies standup dirias devem ser utilizadas para discutir problemas, impedimentos, e fluxo. Tipicamente, elas no seguem os padres estabelecidos de
outros mtodos de desenvolvimento gil.
Standups dirios so uma parte essencial para incentivar uma cultura de
melhoria contnua. Como o standup envolve toda a equipe brevemente todo
dia, ele fornece uma oportunidade para todos os stakeholders sugerirem e
discutirem oportunidades de melhoria. O perodo imediatamente posterior
ao standup frequentemente se desenvolve em uma discusso informal sobre
melhorias no processo.
Preparar o backlog com uma triagem regular para reduzir o seu tamanho
melhora a efetividade e eficincia das reunies de priorizao.
Gerenciamento, escalao, e resoluo de problemas so disciplinas centrais
para melhoria do desempenho de uma equipe e elas devem ser endereadas
o quanto antes no desenvolvimento da equipe.
Caminhos e polticas de escalao devem ser claramente definidos.

C aptulo 8

Estabelecendo uma
Cadncia de Entrega

parte 3 (captulos 6 at o 15) descreve os mecanismos para a


implementao de um sistema kanban, concluindo com o captulo 15, o qual descreve como conduzir uma iniciativa de mudana
Kanban. A permisso para implementar a iniciativa requer uma negociao diferente daquela tipicamente realizada entre uma organizao
de desenvolvimento de software e seus parceiros e stakeholders. Parte
desse novo tipo de negociao envolve acordos e compromissos de
entregas regulares de software funcional.
O termo cadncia de entrega no ttulo deste captulo implica no
estabelecimento de um padro de entrega de software funcional em
um intervalo regular. Por exemplo, se o acordo realizar uma entrega
a cada duas semanas teremos uma cadncia quinzenal ou de 26 entregas por ano. O acordo pode tambm considerar o dia da entrega.
Por exemplo, toda segunda quarta-feira do ms, como foi o caso dos
releases de manuteno das aplicaes de TI da Corbis.
Na comunidade de desenvolvimento de software gil geralmente
estabelece-se que uma cadncia regular importante. Mtodos de
desenvolvimento gil alcanam a regularidade com iteraes time-boxed, que duram tipicamente de uma a quatro semanas. O argumento para o uso de time-boxing baseado na noo de que uma
pulsao regular do projeto importante. H um entendimento de
que, para isso, necessrio o uso de iteraes time-boxed. No incio de
101

102

Captulo 8 Estabelecendo uma Cadncia de Entrega

uma iterao, um escopo, ou backlog, acordado e um compromisso feito. O trabalho


comea! Atividades de anlise, planejamento de testes, projeto, desenvolvimento, teste
e refactoring so realizadas. Se tudo der certo, todo o escopo acordado finalizado. A
iterao acaba com a entrega de software funcional e a reunio de retrospectiva para
discutir melhorias futuras e ajustes no processo. O ciclo ento comea novamente.
Tudo isso acontece numa cadncia regular que foi acordada no incio semanal, quinzenal, mensal, ou qualquer outra.
Kanban dispensa o uso de iteraes time-boxed desacoplando as atividades de priorizao, desenvolvimento e entrega. permitido o ajuste da cadncia de cada uma
dessas atividades naturalmente. Kanban no dispensa o uso do conceito de cadncia
regular. Equipes Kanban entregam software regularmente, dando preferncia a uma
escala menor de tempo. Kanban faz entregas de acordo com os Princpios Por Trs do
Manifesto gil19, no entanto, Kanban evita qualquer disfuno introduzida artificialmente pelo uso de time-box ao forar que as atividades sejam realizadas num perodo
fixo de tempo.
Nos ltimos dez anos as equipes que usam mtodos geis tm aprendido que menos
WIP melhor. Aprenderam tambm que transferncias menores de batch so melhores do que transferncias maiores. Como uma resposta a esse aprendizado, a partir
da segunda metade da ltima dcada, essas equipes comearam a adotar iteraes de
durao menor. Equipes SCRUM tpicas saram de quatro para duas semanas e equipes
Extreme Programming de duas para uma semana. Um dos problemas introduzidos por
essa abordagem a dificuldade de analisar o trabalho em unidades pequenas o suficiente de maneira que caibam na janela de tempo disponvel. O mercado respondeu
a isso desenvolvendo tcnicas mais sofisticadas de anlise e escrita de user stories. O
objetivo foi reduzir o tamanho das estrias tornando-as mais granulares, reduzindo a
variabilidade no tamanho a fim de que elas coubessem em iteraes menores. Embora
essa abordagem soe boa na teoria, ela difcil de ser alcanada. Ela se encaixa na categoria do sexto elemento da Receita de Sucesso: Atacar fontes de variabilidade para
melhorar a previsibilidade. Como descrito no captulo 3, reduzir variabilidade algo
difcil de conseguir porque sempre requer que as pessoas mudem seu comportamento
e aprendam novas habilidades.
As equipes tm ento lutado para escrever user stories consistentemente pequenas
o suficiente para que caibam em iteraes time-boxed pequenas; isso leva a muitas
disfunes. A primeira a reverso da tendncia de iteraes menores para iteraes
maiores. A alternativa escrever estrias com foco em elementos da arquitetura ou
alguma decomposio tcnica dos requisitos. Isso resulta, por exemplo, em uma estria para a interface do usurio, uma estria para a camada de persistncia, e assim por
diante. Uma segunda alternativa quebrar as estrias em fases por trs iteraes, na

Coordenao dos Custos de Entrega

primeira iterao faz-se a anlise e talvez o planejamento dos testes, a segunda envolve
o desenvolvimento de cdigo e a terceira os testes de sistema e a correo de defeitos.
Qualquer uma dessas disfunes possvel. As duas ltimas burlam a noo de iteraes time-boxed e disfaram o fato de que o trabalho ainda est em progresso quando
ele sinalizado como finalizado.
Kanban dissocia o tempo de criao de uma user story da taxa de entrega. Enquanto
algum trabalho finalizado e est pronto para ser entregue, outro trabalho pode estar
em progresso . Tendo dissociado lead time para desenvolvimento da cadncia de entrega, faz sentido perguntar com qual frequncia a priorizao (e talvez o planejamento
e a estimativa) deve acontecer. improvvel que discusses sobre planejamento, estimativa e priorizao devam acontecer no mesmo ritmo, visto que so atividades completamente diferentes que frequentemente precisam da ateno de diferentes grupos
de pessoas. O esforo de coordenao relacionado a entregas certamente diferente
do esforo de coordenao para priorizao de novas atividades; Kanban permite a
dissociao dessas atividades.
Kanban tambm dissocia a cadncia da priorizao, tanto do lead time, como da
cadncia da entrega. Este captulo aborda os elementos envolvidos na obteno de uma
cadncia de entrega adequada e quando e se faz sentido ter entregas ad hoc ou por demanda em vez de entregas regulares. Seguindo a mesma linha de raciocnio, o captulo
9 aborda como estabelecer uma cadncia de priorizao e quando ou se faz sentido
ter reunies de priorizao por demanda ou ad hoc em vez de reunies de priorizao
regulares. E o captulo 11 descreve como estabelecer expectativas em relao ao lead
time e como comunicar o contedo de um release.

Coordenao dos Custos de Entrega


Coordenar cada entrega de software envolve custos. Faz-se necessrio envolver as pessoas para se discutir a implantao (ou release), empacotamento, marketing, comunicao, documentao, treinamento para o usurio final, treinamento para o revendedor,
help-desk e para o suporte tcnico, documentao de instalao, procedimentos de instalao, equipe de planto, assistncia no ambiente de implantao, e assim por diante.
Planejar o release de um pedao de software funcional pode ser inacreditavelmente
complexo, dependendo da natureza do domnio de negcio e do tipo de software.
Atualizar um web site pode ser trivial comparado a atualizao de um firmware de
equipamentos militares espalhados pelo mundo, ou de satlites em rbita, ou de um
avio caa, ou dos ns de uma rede telefnica.

103

104

Captulo 8 Estabelecendo uma Cadncia de Entrega

Em 2002, quando estvamos nos Estados Unidos planejando o release da atualizao


do PCS Vision para a operadora de celular Sprint PCS, dezenas de milhares de pessoas
precisaram ser treinadas. Nas lojas ao redor de todo o pas 17.000 pessoas tiveram que
ser treinadas nas features da nova rede e nos 15 ou mais aparelhos de celular oferecidos.
Um nmero similar de pessoas teve que ser treinada para dar suporte s inevitveis
ligaes para o suporte que poderiam advir quando o consumidor adquirisse seus
novos aparelhos. Apenas o planejamento do treinamento de 30.000 pessoas um custo
enorme de tempo e dinheiro.
importante entender ento, os custos associados coordenao de entregas. Por
exemplo, se os desenvolvedores de software tm que participar de reunies para coordenao de entregas, isso est distraindo-os da construo do software para a entrega?
Em seguida h uma lista de algumas questes a serem consideradas:
Quantas reunies?
Quantas pessoas?
Quanto tempo ser gasto?
Qual custo de oportunidade incorrido quando as pessoas so distradas das suas
atividades regulares?

Custos de Transao de Entrega


fcil entender os custos fsicos de transao para se fazer uma entrega; primeiramente h o pagamento. O cliente pagar ao fornecedor usando algum instrumento monetrio, um carto de crdito, por exemplo. Para a comodidade de se ter
um pagamento via carto de crdito, as bandeiras lderes de mercado, como Visa ou
MasterCard cobram uma taxa de transao de tipicamente dois a quatro por cento
do valor da transao.
Alm dos custos de transao financeira entre cliente e fornecedor, h tambm as
taxas de entrega. Entrega envolve gasto em dinheiro, mas tambm em tempo e mo de
obra, e pode haver tambm os custos de instalao. Digamos, por exemplo, que voc
compre uma mquina de lavar da Sears e agende a entrega para um determinado dia.
Nos bastidores, agendar a entrega e coordenar o motorista para que o modelo correto
da mquina de lavar seja entregue na casa correta no dia determinado uma coordenao de custos de entrega. Retirar a mquina do estoque, dirigir at a sua casa e
entreg-la para voc so custos de transao. Talvez a mesma pessoa, ou outra pessoa,
um encanador, instale-a para voc. O encanador gasta tempo para dirigir at a sua casa

Custos de Transao de Entrega

e ainda mais tempo para realizar a instalao. Todo esse tempo e esforo de entrega e
instalao faz parte do custo de transao de se comprar uma mquina de lavar.
Economicamente, o varejo absorve o custo da transao do carto de crdito. Os
outros custos de transao para entrega e instalao so frequentemente repassados
para o consumidor. Nem todos os custos de transao so vistos ou sentidos por
todos os participantes na cadeia de valor, mas eles afetam o desempenho do sistema
econmico como um todo. O efeito real de todos esses custos o acrscimo no valor
final pago pelo consumidor sem o aumento do valor entregue.
verdade que a mquina de lavar sem ser entregue ou instalada tem pouco valor,
mas o seu valor agregado est na sua capacidade de lavar roupas. A entrega e a instalao so atividades sem valor agregado que devem ser contadas como custo de
transao.
Em desenvolvimento de software, os custos de transao de entrega tambm podem
ser fsicos por natureza. Algumas empresas, como a Microsoft, ainda release to manufacture RTM e fazem impresso de mdia fsica, como DVDs, e os empacota e os
envia para distribuidores, varejistas e outros parceiros. Com software embarcado pode
ser necessrio fabricar chips, ou, pelo menos, injetar cdigo de software dentro do
firmware usando tecnologia como EE-PROM. Os chips, se necessrio, podero ento
ser colocados dentro do hardware que controlaro.
Em outros casos, pode ser necessrio se fazer uma implantao eletrnica. Por exemplo, celulares agora permitem o que chamado de gerenciamento de dispositivo over-the-air para atualizao de firmware e configuraes do dispositivo. Muitos satlites
e sondas espaciais permitem atualizao over the air. Essa facilidade na implantao
faz com que as misses espaciais sejam muito mais geis do que eram no passado. As
misses espaciais podem ser alteradas pelo upload do software. Defeitos podem ser
corrigidos no local. Alguns defeitos vergonhosos do Telescpio Hubble, como a capacidade de foco, foram parcialmente corrigidos com alteraes no software; isto alterou
a economia da implantao.
Muitas pessoas lendo este livro podem estar envolvidas em desenvolvimento web
ou desenvolvimento de aplicaes internas. Implantao pode significar apenas copiar
arquivos de discos para outras mquinas. Apesar disso parecer trivial, frequentemente
no . Frequentemente faz-se necessrio planejar um procedimento elaborado para
desativar bancos de dados, servidores de aplicao, e outros sistemas, e ento atualiz-los e ativ-los novamente. Uma das maiores dificuldades a migrao de um esquema
de banco de dados de uma gerao do banco para outra, pois bancos de dados podem
ser muito grandes. O processo de colocar os dados em srie num arquivo e analis-los, descompact-los e, talvez melhor-los ou aument-los com outros dados, e ento
compact-los e coloc-los num novo esquema pode levar horas talvez at dias.

105

106

Captulo 8 Estabelecendo uma Cadncia de Entrega

Em alguns ambientes, desenvolvimento de software pode levar horas ou dias. Isto


acontece no porque o software de baixa qualidade ou tem uma arquitetura defeituosa; isso simplesmente reflete a natureza do domnio no qual o software utilizado.
Todas as atividades envolvidas em entregar software, sendo ele uma aplicao empacotada, firmware embarcado ou uma aplicao a ser executada num servidor interno,
devem contabilizar planejamento, agendamento e recursos para ento serem realmente
realizadas.

Eficincia de Entrega
A equao que calcula a eficincia da entrega pode ser avaliada por dois caminhos. O
caminho mais simples olhar apenas para o trabalho e custos envolvidos. O mtodo
mais complexo considera o valor entregue.
Primeiro, o modelo apenas de custos. Devemos considerar os custos totais incorridos entre releases. Esse valor muitas vezes conhecido burn rate da organizao. Se
os releases so mensais e o fluxo de caixa negativo de $1.3 milhes por ms, os custos
so de pelo menos $1.3 milhes por release. Podemos tambm incorrer em custos de
fabricao, custos de impresso e custos de publicidade, isto , despesas no reembolsveis de coordenao do release. Tudo isso relativamente fcil de contar. Vamos
imaginar que o valor $200.000, ento o custo total de $1.5 milhes.
Sabemos que os custos no reembolsveis de entrega so de $200.000, mas quanto
dos $1.3 milhes foram gastos planejando, coordenando, e realmente realizando a
entrega? Se tivermos dados adequados de controle de tempo disponveis, poderemos calcular este valor. Mesmo que no tenhamos, poderemos dar um bom palpite.
Quantas reunies? Quantas pessoas? Quantas horas por reunio? Adicione o nmero
de homens-hora para as atividades relacionadas implantao, multiplique pela carga
horria. Se isso somar $300.000, teremos um custo de transao e coordenao de
$500.000 por entrega.
Eficincia de Entrega% =
100% x (1 - ((Custos de Transao + Custo de Coordenao) / (Margem + Custos de Transao + Custos de Coordenao)))

No nosso exemplo, nosso percentual de eficincia :


100% x (1 - ($500,000 / ($500,000 + $500,000))) = 50%

Para ser mais eficiente temos que (a) aumentar o tempo entre entregas, ou (b) reduzir os custos de coordenao e transao. A escolha (a) a escolha tpica das empresas
ocidentais do sculo XX. a escolha que valoriza a economia de escala: Faa coisas

Quanto de eficincia o bastante?

em batches maiores para amortizar os custos durante os longos perodos de tempo.


Escolha (b) a escolha tpica das empresas japonesas do sculo XX e empresas buscando o Lean Thinking. Escolha (b) foca na reduo do desperdcio reduzindo custos
de coordenao e transao a fim de tornar o tamanho do batch eficiente - nesse caso,
tornar o tempo entre releases eficiente.

Quanto de eficincia o bastante?


Essa realmente uma questo aberta. Cada empresa tem vises diferentes sobre o valor
adequado para eficincia, e muito depender do valor a ser entregue.

Estabelecendo uma Cadncia de Entrega


Se entendermos o valor envolvido num release podemos fazer uma escolha melhor
em relao frequencia de entrega. Caso a nossa entrega mensal de software gera uma
receita de $2 milhes versus um custo de $1.5 milhes, saberemos que temos uma margem de $500.000 dessa atividade. Podemos reescrever nossa equao de eficincia como:
%Eficincia de Entrega = 100% x (Custos de Transao + Custos de Coordenao) / ( Margem + Custos de Transao + Custos de Coordenao)

Para o nosso exemplo, isto produziria um percentual de eficincia de:


100% x $500,000 / ($500,000 + $500,000) = 50%

Agora isso fica ainda mais complicado porque calcular o valor real de uma entrega
pode ser quase impossvel. Podemos no ter pedidos de preo fixo. Podemos especular
sobre a aceitao do mercado, o preo e a margem que podemos alcanar. Podemos
entregar itens de valor intangvel, como uma reviso da identidade da nossa marca e
materiais de marketing, ou usabilidade e correo de defeitos para o nosso produto ou
web site.
Calcular se devemos ou no postergar e entregar com uma frequncia menor para
sermos mais eficientes, igualmente difcil. Aumentar nosso time to market pode causar um efeito adverso em nossa participao no mercado, preo e margem. O conceito
de eficincia de entrega no uma cincia exata. O mais importante que voc, a
equipe, e a organizao estejam cientes dos custos de se fazer uma entrega em tempo
e dinheiro e que sejam capazes de fazer alguma avaliao racional sobre uma frequencia de entrega aceitvel.
Se uma equipe de quinze pessoas precisa de dez pessoas por trs dias para fazer
uma entrega de cdigo, aceitvel fazer uma entrega a cada dez dias teis (ou duas

107

108

Captulo 8 Estabelecendo uma Cadncia de Entrega

semanas)? A resposta ser provavelmente, no. Talvez uma vez por ms, ou a cada vinte
dias teis, seja uma escolha melhor. Por outro lado, o mercado pode exigir agilidade e
time to market, e os riscos podem ser mitigados por releases mais frequentes, e nesse
caso o custo vale a pena. Voc precisa usar o bom senso e decidir por si mesmo.

Melhore a Eficincia para Aumentar a Cadncia de Entrega


Continuando o exemplo, determinamos a necessidade de dez pessoas para entregar o
cdigo. A partir disso inferimos que um release mensal aceitvel. No entanto, muitas
pessoas acreditam que com a melhoria na qualidade do cdigo, melhoria na gerncia
de configurao, melhores ferramentas para lidar com a migrao de dados e ensaios
regulares dos procedimentos de instalao, seria possvel diminuir o tempo de trs dias
para oito horas. Subitamente um release a cada duas semanas parece vivel. Ser que
semanalmente seria possvel? O que voc faria?
Meu conselho que inicialmente a escolha seja conservadora. Concorde com um
release mensal. Deixe a organizao provar que ela pode alcanar esse nvel de consistncia. Depois de alguns meses, reflita sobre a qualidade do cdigo e fomente um programa para melhoria da gerncia de configurao. Caso existam recursos disponveis
envolva-os na criao de ferramentas para melhorar a migrao de dados para outros
esquemas durante um release. E finalmente, encoraje a equipe a exercitar o release num
ambiente de testes. Talvez voc precise comprar, instalar e licenciar um ambiente como
esse; tudo isso vai levar tempo.
Desafie a equipe e os gerentes funcionais imediatos que controlam e fazem os releases a reduzir os custos de transao e de coordenao. A partir do momento que esses
custos diminuam, revise o progresso nas reunies de reviso operacionais e estabelea
contato com outros stakeholders. Quando voc se sentir seguro a se comprometer com
uma cadncia de release mais frequente, como uma quinzenal, faa!
Reduzir custos de coordenao e transao est no corao do Lean. Isso eliminao de desperdcio na sua forma mais potente, permitindo que batches menores
tornem-se eficientes e permitindo agilidade no negcio. Reduzir custos de coordenao e transao mudar o jogo. No entanto, no foque simplesmente em reduz-los.
Reduza-os com um objetivo em mente fazer entregas mais frequentes de software
funcional e consequentemente entregar valor aos seus clientes mais regularmente.

Fazendo Entregas Sob Demanda ou Ad Hoc

Fazendo Entregas Sob Demanda ou Ad Hoc


Entregas regulares trazem vantagens. Comprometer-se com datas especficas de entrega,
por exemplo, toda segunda quarta-feira, permite que as pessoas envolvidas se programem; isso fornece segurana. Isso tambm reduz os custos de coordenao j que no
h mais sobrecarga para decidir quando a entrega deve ser realizada e quem deve participar tudo isso foi estabelecido uma vez e continuar consistente a partir de ento.
Entregas regulares tambm ajudam a construir confiana. Falta de previsibilidade
destri confiana. Notam-se muito mais as falhas em se fazer entregas em datas pr-acordadas do que falhas especficas no contedo da entrega.
Tendo-se usado um forte argumento para uma cadncia regular de entrega, faz sentido fazer entregas sob demanda ou ad hoc em alguma circunstncia? Quais seriam
essas circunstncias?
Primeiramente, entregas sob demanda ou ad hoc fazem sentido quando os custos
de coordenao para as atividades do release so pequenos. Quando os custos de coordenao so baixos, no h benefcios de agendar atividades de coordenao regulares. Em segundo lugar, isso faz sentido quando os custos de transao so baixos,
talvez porque a implantao do cdigo seja largamente automatizada e a qualidade
seja garantida com antecedncia, antes da implantao. E finalmente, isso faz sentido
em ambientes onde as implantaes so to frequentes que no h necessidade real
de se desenvolver um padro: Novo software est sendo entregue to frequentemente
que parece contnuo para a maioria dos observadores e stakeholders externos seus
crebros no foram programados para antecipar uma data de entrega. E quando no
h expectativas, no podem existir desapontamentos.
Esse tipo de implantao quase contnua de cdigo parece ser til e necessria em
algumas indstrias. Os exemplos que emergiram dos pioneiros no uso de Kanban tm
sido principalmente na indstria de mdia, por exemplo, a IPC Media em Londres,
onde eles usam mltiplos sistemas Kanban para planejar o desenvolvimento para propriedades de mdia online como o mousebreaker.com, um jogo online muito viciante.
As duas primeiras circunstncias de custos baixos de coordenao e transao
tendem a indicar organizaes de alta maturidade. Isso tambm tem sido observado
pelos pioneiros no uso de Kanban. O departamento XIT da Microsoft fez uma parceria com um fornecedor CMMI nvel de maturidade 5 na ndia e com a Microsoft TI
em Redmond, Washington, que aproximadamente CMMI nvel 3 de maturidade.
Organizaes com alta maturidade tendem a ter nveis estabelecidos de confiana com
parceiros da cadeia de valor e stakeholders externos, incluindo gerncia snior, dessa
maneira elas no precisam de cadncia regular de entrega para construir confiana.

109

110

Captulo 8 Estabelecendo uma Cadncia de Entrega

Ento, em geral, escolha uma cadncia regular exceto em circunstncias nas quais,
confiana e altos nveis de capacidade e maturidade j existam, e em domnios onde
uma implantao quase contnua desejvel.
H uma circunstncia final na qual aceitvel se fazer entregas sob demanda.
Quando h uma requisio urgente que est sendo tratada como um caso especial e
de expedio. Esse conceito de classe de servio de Expedio explicado na seo Lead
Time do captulo 11. Devemos escolher expedir por diversas razes, a primeira e mais
bvia delas est no advento de um defeito de produo crtico. Em circunstncias nas
quais nada mais importa a no ser corrigir o problema, um release fora do ciclo deve
ser planejado.
H outras circunstncias onde releases fora do ciclo fazem sentido. Talvez a equipe
de vendas tenha feito um pedido para um grande cliente que deseja uma verso customizada de um software e devido a restries oramentrias e do ciclo fiscal ele precisa
da entrega para antes do final do ms (e do trimestre). O pedido vem do grupo de
operaes e a engenharia de software deve parar tudo para cumprir esse pedido do
cliente porque isso trar muita receita.
Sob essas circunstncias faz sentido planejar um release especial e fora do ciclo. Esse
release deve ser tratado como excepcional, e a cadncia regular deve ser restabelecida
assim que possvel logo aps o release excepcional; embora seja necessrio usar o bom
senso. Por exemplo, se um release regular agendado para quarta-feira e o release
excepcional requisitado para a sexta-feira da mesma semana, faz sentido atrasar o
release de quarta-feira para sexta-feira. Caso voc escolha fazer isso, importante comunicar apropriadamente e suficientemente cedo de modo que as expectativas sejam
redefinidas. Voc no quer perder a confiana com seus parceiros da cadeia de valor
como um efeito colateral de tentar ser flexvel e til.

Takeaways
111

Takeaways
Cadncia de entrega significa um acordo de entregas de software funcional
a intervalos regulares.
Kanban desacopla cadncia de entrega tanto do lead time de desenvolvimento como da cadncia de priorizao.
Iteraes curtas e time-boxed tm levado a disfunes para algumas equipes
tentando adotar mtodos de desenvolvimento gil.
Entrega ou release de software envolve coordenao de muitas pessoas de
vrias funes; toda essa coordenao tem um custo mensurvel.
Entrega ou release de software traz consigo um conjunto de custos de transao em tempo e dinheiro; esses custos podem ser determinados e acompanhados.
Eficincia de entrega pode ser calculada comparando-se a soma dos custos
de transao e coordenao para se fazer uma entrega e o custo total para se
criar o software para a entrega.
Cadncia de entrega pode ser estabelecida comparando-se o custo de produo do release e o valor recebido do release.
Eficincia e cadncia podem ser aumentadas focando-se na reduo dos custos de transao e coordenao.
Entregas regulares constroem confiana.
Fixar uma expectativa de cadncia regular e fazer entregas consistentes a essa
expectativa pode ser viciante.
Agendar entregas regulares reduz custos de coordenao.
Entregas sob demanda ou ad hoc podem fazer sentido para organizaes de
alta maturidade com altos nveis de confiana e baixos custos de transao e
coordenao de entrega.
Requisies legtimas para expedir entregas tambm podem ser causa de releases fora do ciclo. Releases regulares devem ser restabelecidos o mais rpido
possvel depois de um release excepcional.

C aptulo 9

Estabelecendo uma
Cadncia de Entrada

ste captulo discute os elementos envolvidos no estabelecimento


de uma cadncia de priorizao adequada e quando, ou se, faz
sentido ter uma priorizao sob demanda ou ad hoc em vez de uma
reunio de priorizao agendada regularmente.

Coordenando Custos de Priorizao


Quando estvamos introduzindo Kanban na Corbis, em 2006, escolhemos comear com a manuteno de engenharia que lidava com
requisies de atualizao pequenas e correo de defeitos para a
sute completa das aplicaes de TI, incluindo funes tanto financeiras e de recursos humanos, como tambm de sistemas de domnio
mais especfico do sistema de gerenciamento de ativos e o web site
de e-commerce. Esses sistemas serviam pelo menos seis unidades de
negcio, incluindo vendas, marketing, operaes de venda, finanas,
e ao departamento que dava suporte cadeia de fornecedores que
vendia fotografia digital, meta-data tagging, catalogao, e execuo
essencialmente a cadeia de fornecedores do negcio.
Seis departamentos competiam pelos recursos compartilhados disponveis para fazer essas pequenas mudanas e atualizaes. Quando
o sistema kanban foi introduzido, um caso de negcio foi feito para

113

114

Captulo 9 Estabelecendo uma Cadncia de Entrada

uma unidade de engenharia de apoio que poderia fornecer releases estratgicos e frequentes. Essa unidade de apoio possibilitaria agilidade limitada no negcio atravs de
releases de pequenas funes de forma incremental enquanto outros novos projetos
de aplicaes de TI foram construdos utilizando um mecanismo de governana departamental de gerenciamento de programa (Program Management Office PMO)
tradicional. Cada projeto do portfolio foi justificado e autorizado com base no seu caso
de negcio independente. A unidade de apoio foi aprovada pelo comit executivo, e
um financiamento adicional de dez por cento foi autorizado para a unidade de engenharia de software, o que gerou cinco contrataes adicionais para o departamento.
Essa nova capacidade foi chamada de Equipe de Resposta Rpida (ERR). O nome foi
completamente imprprio inicialmente a equipe no era rpida, no dava respostas
rpidas, e na verdade nem havia uma equipe.
No era vivel criar um departamento de manuteno especializado com essas cinco
pessoas novas. Corbis tinha uma diversidade considervel de sistemas de TI e muitos
requeriam habilidades especficas. A unidade de anlise que desenvolvia e elaborava
requisitos de sistema dependia particularmente fortemente de especialistas. As cinco
pessoas adicionais foram distribudas pela unidade de engenharia de software nas funes de gerenciamento de projeto, anlise de sistema, desenvolvimento, teste, gerncia
de configurao, e build. Dessa maneira no havia uma equipe, o E em ERR no tinha
sentido. O desafio da gerncia foi mostrar que os dez por cento adicionais para recursos
estavam sendo gastos em trabalhos de manuteno e simplesmente no estavam sendo
consumidos pelo trabalho em grandes projetos do portflio.
Decidiu-se dedicar um gerente de projeto na unidade de apoio de engenharia.
Apesar dessa gerente no trabalhar em tempo integral na unidade de apoio, ela era um
ponto focal nico para comunicao e coordenao e contava como metade de uma
das cinco pessoas alocadas na iniciativa. Um engenheiro de build da equipe de gerncia
de configurao tambm foi designado especificamente para a iniciativa. Seus deveres
eram manter os sistemas de pr-produo requeridos para teste e staging e construir
cdigo e coloc-lo no ambiente de teste quando requisitado.
Para manter a integridade do ambiente de teste, que era usado por mltiplos projetos
ao mesmo tempo, Corbis tinha uma poltica onde apenas engenheiros de build tinham
permisso de promover o cdigo do ambiente de desenvolvimento para o ambiente de
teste. Essa poltica mudou posteriormente, mas em Setembro de 2006 a realidade que
era necessrio um engenheiro de build para promover o cdigo para teste.
Antes da introduo de Kanban, o esforo de coordenao requerido para se chegar num acordo em relao ao escopo de um release de manuteno era proibitivo.

Coordenando Custos de Priorizao

O gerente de projeto, e frequentemente seu chefe, e o grupo de gerncia de projeto,


deveriam convocar uma reunio com todas as partes relevantes, incluindo analistas de
negcio, representantes do negcio, analistas de sistema, gerentes de desenvolvimento,
lderes de teste, e engenheiro de build, e algumas vezes o gerente da gerncia de configurao, como tambm o pessoal de operaes de sistema e help-desk. Essas reunies poderiam durar muitas horas e eram frequentemente inconclusivas. Membros da
equipe deveriam fazer estimativas, e outra reunio era agendada. A ltima reunio era
frequentemente repleta de debates sobre prioridades, e novamente, era frequentemente
inconclusiva. Em Setembro de 2006 gastava-se duas semanas com muitas reunies que
duravam muitas horas para se chegar num acordo em relao ao escopo de um release que supostamente deveria ter apenas duas semanas de construo e implantao.
Devido durao de duas semanas de uma iterao, apenas requisies muito pequenas poderiam ser acomodadas e muitas requisies potencialmente valiosas eram ignoradas. Essas requisies deveriam ser redirecionadas para um projeto maior e dessa
maneira poderiam levar meses ou anos antes de serem implementadas. O sistema no
era rpido e no dava respostas rpidas antes da introduo do sistema kanban, ento
o RR de ERR tambm no tinha sentido.
Kanban libertou esta equipe de todas essas disfunes e ela, por iniciativa prpria,
ganhou o nome de Equipe de Resposta Rpida.
Quando o sistema kanban foi introduzido, os donos do negcio foram educados
no fluxo de trabalho, na fila de entrada e no mecanismo puxado. Eles aprenderam
que seriam questionados simplesmente para preencher os espaos vazios na fila e que
no seria necessrio priorizar o backlog de requisies. Se havia dois espaos livres na
fila, a pergunta deveria ser, Quais so os dois prximos novos itens? Assumindo que
tnhamos dados do lead time mdio e do desempenho do atendimento aos prazos versus o lead time alvo e o acordo de nvel de servio, a pergunta mais elaborada poderia
ser, Quais dois itens poderiam ser entregues em 30 dias a partir de hoje? O desafio
seria ento que os seis donos de negcio que competiam entre si de alguma maneira
chegassem num acordo de quais seriam os dois itens dentre s muitas possibilidades
de escolha.
Contudo, a pergunta simples, e era esperado responder-se a uma pergunta to
simples em uma hora facilmente. Havia um consenso que uma hora era razovel, consequentemente os donos do negcio eram questionados se eles abririam mo de uma
hora de sua semana para participar de uma reunio semanal de priorizao para preencher a fila de entrada para a unidade de engenharia de apoio.

115

116

Captulo 9 Estabelecendo uma Cadncia de Entrada

Acordando uma Cadncia de Priorizao


A reunio foi agendada para toda segunda-feira s 10 a.m. Geralmente havia a participao de gerentes de negcio de hierarquia superior que no costumavam participar das reunies de escopo de release, e usualmente o vice-presidente de cada grupo
funcional. Adicionalmente, o gerente de projeto, o Diretor Snior da Engenharia de
Software, o Diretor Snior dos Servios de TI (cujas responsabilidades incluam a
gerncia de projeto), pelo menos um gerente de desenvolvimento, o gerente de teste, o
gerente do time de anlise, e ocasionalmente alguns contribuidores individuais poderiam participar.
Entrar em acordo para uma cadncia regular fornecia a todos, previsibilidade. Eles
estavam prontos a abrir mo de uma hora nas manhs das segundas-feiras, e geralmente a participao na reunio era boa.
Cadncia de priorizao semanal uma boa periodicidade. Ela fornece interaes
frequentes com os donos do negcio, e ela constri confiana atravs da interao dos
envolvidos. No jogo colaborativo e cooperativo de desenvolvimento de software, ela
possibilita que os jogadores movam as peas uma vez por semana. Reunies semanais
so possveis devido simplicidade da pergunta a ser respondida e a garantia de que a
reunio pode ser finalizada em uma hora. Quando pessoas de negcio gastam tempo
longe da administrao dos seus negcios, elas precisam ver que o seu tempo est
sendo bem gasto.
Muitos dos aspectos de kanban contribuem para que a reunio de priorizao semanal seja gratificante: uma experincia colaborativa; h transparncia no trabalho
e no fluxo de trabalho; o progresso pode ser reportado toda semana; e todos sentem
que esto contribuindo para algo valioso. Para muitos dos vice-presidentes na Corbis,
parecia que o processo ERR estava fazendo a diferena. Eles ganharam um novo nvel
de respeito no departamento de TI e eles aprenderam a colaborar com os seus pares em
outros departamentos de uma maneira que anteriormente no era comum na Corbis.

Eficincia de Priorizao
Reunies de coordenao de periodicidade semanal podem no ser a resposta certa para
a sua organizao. Voc pode achar que os seus desafios de coordenao so mais difceis
ou mais simples do que queles da Corbis. Algumas equipes sentam-se prximas, ento
no h necessidade de uma reunio; a coordenao de priorizao pode ser uma rpida
discusso pelas mesas. Por outro lado, algumas equipes podem ter pessoas em fusos
horrios diferentes e em muitos continentes diferentes, ento reunies semanais no
sero facilmente agendadas. Talvez as perguntas a serem respondidas no sejam simples

Custos de Transao de Priorizao

como no exemplo da Corbis e a reunio pode durar muito tempo. difcil imaginar uma
situao com mais de 6 grupos competindo pelo mesmo recurso compartilhado, mas
possvel. Quanto mais grupos envolvidos, mais tempo a reunio pode demorar. Quanto
mais longa a reunio, menos frequentemente voc vai conseguir faz-la.
Como um conselho geral, priorizaes mais frequentes so desejveis. Elas permitem que a fila de entrada seja menor, e, como resultado, h menos desperdcio no
sistema. O WIP baixo e dessa maneira o lead time mais curto. Priorizaes mais
frequentes permitem que todas as partes trabalhem junto mais frequentemente. A experincia de trabalho colaborativo constri confiana e melhora a cultura. Empenhe-se
para encontrar o esquema de coordenao menor e mais eficiente possvel e faa reunies de priorizao o mais frequentemente possvel.

Custos de Transao de Priorizao


Para facilitar uma reunio eficiente toda segunda-feira, Diana Kolomiyets, a gerente de
projeto, deveria enviar um e-mail na quinta-feira ou sexta-feira para informar aos participantes o nmero estimado de espaos vazios na fila na segunda-feira pela manh.
Ela solicitava que eles olhassem o backog de requisies e escolhessem os candidatos
para seleo na segunda-feira. Essa tarefa de casa frequentemente solicitava-os a preparar algum argumento para dar suporte seleo bem sucedida do seu item favorito.
Ns comeamos a ver documentos de suporte nas reunies da segunda-feira. Algumas
pessoas preparavam um caso de negcio, ou alguma apresentao para dar suporte
sua escolha; outros comearam a fazer lobby entre si. Era comum que alguns participantes da reunio levassem outra pessoa da reunio para um almoo na sexta-feira,
especificamente para ganhar apoio para sua escolha na segunda-feira pela manh. A
troca de votos foi introduzida e um membro poderia concordar em dar apoio a outro
membro da equipe numa semana e em troca receberia apoio para o seu prprio item
numa semana futura. A natureza das regras do jogo, onde mltiplas organizaes competem por um recurso ERR compartilhado, introduziu um novo nvel de colaborao.
Ocasionalmente, a equipe de negcio poderia ficar preocupada que uma requisio
fosse muito cara para implementar comparando-se com o seu valor, ento eles poderiam solicitar equipe de anlise que fizesse uma estimativa. Posteriormente, regras
relacionadas a classes de servio foram introduzidas como forma de guiar se as estimativas valeram pena ou no; isso totalmente explicado no captulo 11.
Todas essas atividades, incluindo estimativas, preparao de plano de negcio, e seleo de candidatos do backlog, so trabalhos de preparao para priorizao. Em termos
econmicos esses so custos de transao de priorizao; desejvel que esses custos

117

118

Captulo 9 Estabelecendo uma Cadncia de Entrada

sejam mantidos baixos. Se os custos de transao tornam-se onerosos, no importando


o quo baixos so os custos de coordenao, a equipe no vai querer se reunir regularmente. Evitando, o mximo possvel, estimativas detalhadas, os custos de transao so
minimizados, fazendo que reunies de priorizao sejam mais frequentes.

Melhore Eficincia para Aumentar a Cadncia de Priorizao


No geral, a equipe de gerenciamento deve estar consciente de todos os custos de transao e coordenao incorridos por todos no apenas a equipe de desenvolvimento
os envolvidos na priorizao e seleo de novos itens na fila para desenvolvimento
e entrega.
Muitas organizaes geis usam uma forma de priorizao chamada Planning Poker
que utiliza a tcnica wisdom of the crowds sabedoria da multido, na qual todos
os membros da equipe votam usando um carto representando um nmero de tamanho. realizada uma mdia dos votos, ou algumas vezes chega-se num consenso
discutindo-se os desvios nos votos e votando-se novamente at que todos na equipe
concordem numa estimativa. Os cartes de poker frequentemente usam uma escala de
numerao no linear, como a Srie de Fibonacci, para incentivar o dimensionamento
relativo.
Alguns argumentam que essa tcnica de planejamento, que tambm uma forma de
jogo colaborativo e cooperativo, muito eficiente, visto que ela permite que uma estimativa bastante precisa seja estabelecida rapidamente. H evidncias que comprovam
isso, mas h igualmente evidncias que sugerem que pensamento em grupo tambm
possvel. J ouvi relatos de equipes, como um startup em So Francisco, que recorrentemente subestimavam, apesar do uso de um jogo transparente e colaborativo como o
Planning Poker. J ouvi de gerentes seniores de um web site de agendamento de viagens
muito conhecido, que suas equipes consistentemente superestimavam, apesar de utilizarem o Planning Poker. Acreditando ou no que esses jogos de planejamento sejam
efetivos, vale muito a pena consider-los, dado os argumentos de que eles so efetivos.
verdade que jogos de planejamento envolvendo toda a equipe podem gerar muito
rapidamente uma estimativa para um item individual, como uma user story; no entanto,
o exerccio envolve toda a equipe; h um custo de coordenao significante para isso.
Isso funcionar efetivamente em pequenas equipes focadas em produtos simples; no
entanto, se extrapolamos a tcnica para uma organizao como a Corbis, onde estvamos mantendo 27 sistemas de TI usando 55 pessoas, muitas das quais especialistas
no seu campo, domnio, sistema, ou tecnologia, seria necessrio ter quase todas as 55
pessoas na reunio para se fazer uma boa estimativa e alcanar uma wisdom from the

Fazendo Priorizao Ad Hoc ou Por Demanda

crowd . Os custos de transao para planejamento e estimativas seriam baixos, mas os


de coordenao seriam altos.
No geral, devido a esse efeito de custo de coordenao, esses mtodos de planejamento geis so eficientes apenas para pequenas equipes focadas em sistemas simples
e linhas de produto.
Escolhendo-se eliminar as estimativas para a maioria das classes de servio, os custos de transao e de coordenao sero reduzidos. Essa reduo facilita reunies de
priorizao mais frequentes porque as reunies permanecem eficientes. Isso permitiu
que equipes kanban fizessem priorizao ad hoc ou por demanda.

Fazendo Priorizao Ad Hoc ou Por Demanda


Como descrito no captulo 4, em 2004, Dragos Dumitriu introduziu um sistema kanban com sua equipe de Engenharia de Apoio XIT na Microsoft. Os parceiros de negcio principais foram quatro gerentes de produto que representavam vrias unidades
de negcio. Eles focaram e priorizaram requisies de mudana para os 80 ou mais
sistemas de TI apoiados pela XIT.
Quando Dragos e eu projetamos o sistema kanban para introduo com a XIT, ns
projetamos uma fila de entrada grande o bastante em face de pelo menos uma semana
de rendimento. Apesar do fato que todos os quatro representantes de negcio e Dragos
estavam situados em Redmond, Washington, no campus da Microsoft, a reunio de
priorizao acontecia por telefone. O campus da Microsoft imenso; a quantidade de
prdios pode atingir o nmero de centenas, embora haja apenas algo em torno de 40
prdios no total. A rea coberta tem vrios quilmetros quadrados e o transporte entre
as sees do campus feito por mini nibus ou Toyota Prius. Muitos preferem realizar
chamadas de conferncia para reunies de priorizao do que faz-las face a face. Isso
tem um impacto negativo no nvel de confiana e no capital social, mas facilita eficincia.
Ento Dragos estabeleceu uma ligao telefnica semanal para priorizar novas requisies do backlog. Os quatro gerentes de produto representavam as unidades de negcio
que forneciam financiamento para os fundos da equipe de Dragos via transferncia
de fundos entre companhias. Baseado nesse financiamento era possvel determinar
aproximadamente quantas vezes algum deveria escolher um item do backlog. O gerente de produto que fornecia seis dcimos para o fundo poderia escolher trs de cada
cinco oportunidades. Os outros poderiam selecionar itens de uma maneira similar
baseando-se nos seus nveis de financiamento. O gerente de produto que fornecia o
menor financiamento poderia escolher um item em cada 11. Podemos descrever isso
como um mtodo de seleo ponderado round-robin.

119

120

Captulo 9 Estabelecendo uma Cadncia de Entrada

Ento as regras do jogo de priorizao colaborativo e cooperativo XIT eram simples.


Cada semana os gerentes de produto deveriam preencher os espaos abertos da fila de
entrada tipicamente trs espaos. Cada um deles poderia escolher baseando-se na
sua posio na fila round-robin. O lead time alvo para o acordo de nvel de servio era
de 25 dias. Ento se eles tinham uma chance de escolher uma requisio de mudana
para desenvolvimento, eles deveriam perguntar a si mesmos Quais dos itens no meu
backlog eu gostaria que fossem entregues em 25 dias a partir de hoje? A ordem na qual
eles fariam a escolha era muito clara e simples baseada no seu nvel de financiamento
para o departamento.
Devido natureza simples das regras, a reunio era finalizada muito rapidamente.
Tornou-se claro que uma ligao telefnica de coordenao no era realmente necessria. Dragos tinha o banco de dados Microsoft Product Studio (um precursor do Visual
Studio Team System, Team Foundation Server) que fornecia um email a partir de um
gatilho que indicava quando um espao tornava-se livre. Ele ento enviava o e-mail
para os quatro gerentes de produto. Eles acordavam rapidamente sobre quem deveria
escolher um item e a pessoa selecionava algum deles. Tipicamente, um espao vazio
na fila era preenchido em duas horas.
Os custos de coordenao excepcionalmente baixos, unidos aos custos de transao
baixos relacionados deciso de no se estimar requisies de mudana, e junto relativa alta maturidade da equipe envolvida, permitiu que a Microsoft XIT dispensasse
o agendamento regular das reunies de priorizao.
importante notar que a Microsoft em Redmond aproximadamente o equivalente
a uma organizao CMMI-ML3 e que o fornecedor sendo utilizado para o desenvolvimento e teste XIT era uma equipe CMMI-ML5 situada em Hyderabad, na ndia. Ento
essa equipe tinha a vantagem de custos de coordenao baixos, custos de transao
baixos, e particularmente nveis altos de maturidade organizacional. O efeito desses
trs fatos significou que reunies de priorizao por demanda tornaram a equipe mais
efetiva.
Como regra geral, voc deve escolher priorizao ad hoc ou por demanda quando
voc tem uma organizao de alto nvel de maturidade, custos baixos de transao, e
custos baixos de coordenao de priorizao. Caso contrrio, melhor usar reunies
de priorizao com agendamento regular e coordenar a seleo da fila de entrada com
uma cadncia regular.

Takeaways
121

Takeaways
Cadncia de priorizao significa um acordo sobre um intervalo regular
entre reunies para priorizar novo trabalho para desenvolvimento na fila de
entrada.
Kanban remove disfunes potenciais relacionadas coordenao do planejamento de iterao dos mtodos geis dissociando a cadncia de priorizao do lead time de desenvolvimento e entrega.
Priorizao de novas requisies de trabalho como user stories envolve a
coordenao de muitas pessoas de vrias funes; toda essa coordenao
tem um custo mensurvel.
Estimativas para facilitar decises de priorizao representam custos de transao em tempo e dinheiro associados com a priorizao; esses custos podem
ser determinados e acompanhados.
Polticas relacionadas ao mtodo de priorizao e as entradas para tomada
de deciso representam as regras do jogo colaborativo e cooperativo de priorizao no Kanban aplicado ao desenvolvimento de software.
Jogos de planejamento utilizados nas metodologias geis no so escalados
com facilidade e podem representar um custo de coordenao significante
para equipes maiores com um foco mais amplo do que uma simples linha
de produto.
Cadncia de priorizao pode ser estabelecida encorajando-se os envolvidos
na deciso de priorizao a fazer reunies regulares baseando-se nos custos
de transao e coordenao envolvidos.
Eficincia e cadncia de priorizao podem ser incrementadas focando-se
em reduzir seus custos de transao e coordenao.
Reunies de priorizao frequentes constroem confiana.
Agendar reunies de priorizao regulares reduz os custos de coordenao e
particularmente til em organizaes de baixa maturidade.
Priorizao ad hoc ou por demanda pode fazer sentido para organizaes de
alta maturidade com nveis estabelecidos de confiana e com custos baixos de
transao e coordenao associados s polticas de priorizao para tomada
de deciso.

C aptulo 10

Estabelecendo Limites
para o Trabalhoem-Progresso

omo discutido no captulo 2, uma das cinco propriedades fundamentais no Mtodo Kanban o trabalho-em-progresso (WIP
Work-In-Progress) ser limitado. Ento verdade dizer que uma das
decises mais importantes que voc far quando introduzir Kanban
escolher os limites para o trabalho-em-progresso atravs do fluxo
de trabalho.
O captulo 15 aconselha que o trabalho-em-progresso deve ser
acordado por consenso com os stakeholders em todos os nveis e gerncia snior. verdade que limites podem ser declarados unilateralmente; no entanto, h poder em conseguir consenso e obter um
comprometimento dos stakeholders externos em relao poltica de
limitar o WIP. Quando sua equipe e o processo so colocados sob
stress voc pode recorrer ao acordo colaborativo no qual houve consenso. Voc pode redirecionar a discusso para uma redefinio do
processo em vez de desviar-se ou estender o sistema, ou us-lo indevidamente diferentemente de como foi projetado e implementado.
Construir consenso uma maneira de manter a disciplina do limite
do WIP e evitar substituir ou abandonar um limite.

123

124

Captulo 10 Estabelecendo Limites para o Trabalho-em-Progresso

Limites para Tarefas


Na Microsoft com a equipe XIT, Dragos Dumitriu decidiu que os desenvolvedores e
testadores deveriam trabalhar num nico item de cada vez; no deveriam existir mltiplas tarefas. Isso foi declarado unilateralmente, mas felizmente essa escolha no se
tornou problemtica com outros stakeholders. Isso estava alinhado com as prticas de
trabalho correntes e o mtodo Personal Software Process (PSP) em uso pela equipe.
A organizao era madura o bastante para manter a disciplina e seguir o processo que
havia sido acordado. Voc deve lembrar que no incio do estudo de caso, no outono
de 2004, havia trs desenvolvedores e trs testadores na equipe. Ento o limite do WIP
para cada, desenvolvimento e teste, era trs.
Em 2006 na Corbis, com a iniciativa da engenharia de apoio, ns tomamos uma
deciso similar; onde analistas, desenvolvedores e testadores, deveriam trabalhar em
apenas um item de valor para o cliente de cada vez. Com novos projetos grandes, ns
comeamos a tomar decises diferentes; havia mais trabalho colaborativo nesses projetos. Era comum que equipes de duas ou trs pessoas trabalhassem num nico item.
Como esses itens poderiam ser bloqueados ou atrasarem, ns especulamos se faria
sentido permitir a troca de algumas tarefas e algum paralelismo adicional; consequentemente o limite do WIP foi estabelecido de maneira que duas ou trs pessoas trabalhassem no mesmo item, mas que permitisse tambm algum acmulo. Por exemplo,
se tnhamos dez pessoas e antecipadamente duas pessoas por item, o limite do WIP
poderia ser cinco adicionando um pouco mais para suavizar o impacto de um item
bloqueado. Talvez oito (cinco mais trs) seria o limite correto nessas circunstncias.
Havia alguma pesquisa e observao emprica que sugeriam que dois itens em progresso para cada trabalhador era o nmero ideal. Esse resultado frequentemente
citado para justificar multitarefa. No entanto, eu acredito que essa pesquisa tende a
refletir a realidade de trabalho nas organizaes observadas; h muitos impedimentos
e razes para o trabalho atrasar. A pesquisa no relata a maturidade das organizaes
estudadas, nem correlaciona os dados com quaisquer questes externas (variaes causadas por atribuio, discutidas no captulo 19). Portanto, o resultado pode ser uma
consequencia dos ambientes estudados e no um nmero ideal de fato. No obstante,
voc pode enfrentar resistncia noo de que um item por pessoa, par, ou equipe
pequena, a escolha correta. O argumento pode ser que tal poltica muito restritiva.
Nesse caso, estabelecer um limite de WIP de dois itens por pessoa, par ou equipe
razovel. Pode haver inclusive casos onde um limite de trs itens por pessoa, par, ou
equipe aceitvel.
No h frmula mgica para se fazer essa escolha. importante lembrar que o
nmero pode ser ajustado empiricamente. Voc pode escolher um nmero e ento

Limites para Filas

observar se ele est funcionando bem. Caso no esteja, ajuste-o para cima ou para
baixo.

Limites para Filas


Quando um trabalho finalizado e est espera para ser puxado para o prximo estgio no seu fluxo de trabalho, diz-se que ele est enfileirado. Quo grande essas filas
podem ser? O menor possvel. O limite de WIP para uma fila aparece frequentemente
entre colchetes com a etapa de trabalho anterior. Por exemplo, as filas Desenvolvimento
e Desenvolvimento Completo so colocadas juntas entre colchetes (Figura 10.1). Caso
uma poltica muito firme para o WIP das tarefas seja estabelecida, como um item por
pessoa, par, ou equipe pequena, ser necessrio ter alguma fila que absorva a variao
e mantenha o fluxo. Se, em operao, o seu sistema kanban sofrer do comportamento
pare-avance que faz com que os funcionrios fiquem parados devido variabilidade
da quantidade de tempo necessria para finalizar as tarefas, voc pode precisar aumentar o tamanho das filas. No entanto, caso voc tenha escolhido dois itens por pessoa,
par ou equipe, por exemplo, voc j tem um retentor para variabilidade, dessa maneira

10.1!

g 10.1!
Buffer!
Gargalo!
5!

4!

Fila!
Anlise!
Entrada! Em Prog! Feito!

3!

Fila!
Disponibilidade!
Fila!
Item Feito! No-instantnea!
4!

Des.
Desenvolv.!
Pronto! Em Prog! Feito!

2!

2!

= 20 total!

Build Teste! Release


...!
Pronto!
Pronto!

Figura 10.1 Parede de cartes mostrando tipos diferentes de filas e um buffer


Figura 10.1
Parede de cartes mostrando tipos diferentes de filas e um buffer

125

126

Captulo 10 Estabelecendo Limites para o Trabalho-em-Progresso

o tamanho da sua fila pode ser efetivamente zero. Simplesmente coloque juntas entre
colchetes a coluna da tarefa e a fila completa.

Retenha Gargalos
O gargalo no seu fluxo de trabalho pode requerer uma reteno sua frente. Este
um mecanismo tpico de explorao de gargalo, como ser explicado no captulo 16. O
tamanho da reteno importante. Novamente voc deve querer que ele seja o menor
possvel. Retenes e filas adicionam WIP ao seu sistema e o seu efeito aumentar o
lead time. No entanto, retenes e filas suavizam o fluxo e melhoram a previsibilidade
do lead time. Suavizando o fluxo, h aumento do rendimento, ento mais trabalho
entregue atravs do sistema kanban. Retenes tambm garantem que as pessoas se
mantm trabalhando e proporcionam uma melhor utilizao do sistema. Deve existir
balanceamento e a reteno ajuda a mant-lo. Em muitas circunstncias voc est
procura de agilidade no negcio atravs de lead times menores e maior qualidade,
em parte, atravs de menos trabalho-em-progresso. No entanto, no sacrifique previsibilidade a fim de alcanar agilidade ou qualidade. Se os tamanhos da sua fila e
reteno so muito pequenos e o seu sistema sofre do comportamento pare-avance
devido variabilidade, seu lead time ser imprevisvel, com uma ampla variabilidade.
A chave para escolher um limite de WIP para uma reteno que ele deve ser grande
o suficiente para garantir um fluxo suave no sistema e evitar tempo ocioso no gargalo.
Mais detalhes no tamanho da reteno e como projetar retenes para restrio de
capacidade e gargalos de no disponibilidade imediata sero discutidos no captulo 16.

Tamanho da Fila de Entrada


O tamanho da fila de entrada pode ser diretamente determinado a partir da cadncia
de priorizao e do rendimento, ou taxa de produo do sistema. Por exemplo, se uma
equipe est produzindo a uma taxa media de cinco trabalhos finalizados por semana
(com uma variao tpica de quatro a sete itens por semana), e a cadncia de reabastecimento da fila semanal, o tamanho da fila pode ser atribudo para sete; novamente
isso pode ser ajustado empiricamente. Se voc executa o seu sistema por muitos meses
e a fila nunca totalmente esgotada antes que a reunio de priorizao ocorra, ela est
provavelmente muito grande, ento a reduza em um e observe os resultados. Repita
isso at que voc tenha uma reunio de priorizao na qual voc solicitar aos representantes do negcio que preencham a fila inteira.

Tamanho da Fila de Entrada

Se, por outro lado, voc tem uma reunio de priorizao na segunda-feira e a fila
esgotada na quinta-feira tarde e como resultado algumas pessoas da equipe esto
ociosas sua fila muito pequena. Aumente o tamanho da fila em um e observe por
mais algumas poucas semanas.
Tamanhos de fila e reteno devem ser ajustados empiricamente conforme necessrio. Portanto, no se aflija em tomar uma deciso para estabelecer um limite de WIP.
No atrase o incio do uso do seu sistema kanban porque voc no consegue chegar a
nmeros perfeitos para limite do WIP. Escolha alguma coisa! Escolha dar progresso
com informaes imperfeitas e ento observe e ajuste; Kanban um processo emprico.
Qual tamanho deve ter a fila de entrada se voc est usando priorizao por demanda? Voc deve recordar do captulo 4 que a equipe XIT tinha uma fila de entrada
de cinco itens. Ela foi projetada para ser grande o bastante para absorver o rendimento
de uma semana. Ela foi baseada no pressuposto de que a reunio de priorizao estava
acontecendo semanalmente. No entanto, os gerentes de produto decidiram rapidamente que a reunio era desnecessria e que era aceitvel se fazer decises dirigidas a
evento quando um espao na fila tornava-se disponvel. Uma vez que isso aconteceu,
eu deveria ter avisado a Dragos para reduzir a entrada de cinco para apenas um.
um reflexo da minha inexperincia naquele momento eu no ter feito isso. O sistema
mudou. Os pressupostos sob os quais ele foi projetado mudaram. A poltica para o
tamanho da fila de entrada foi baseada naqueles pressupostos e deveria ter sido revisitada. As melhorias no lead time teriam sido mais expressivas caso tivssemos feito isso.
Quando a XIT mudou para uma priorizao sob demanda eles levavam tipicamente
duas horas para preencher um espao vazio na fila. Teria sido aceitvel assumir que o
maior tempo para reiniciar a fila seria de quatro horas. No entanto, os desenvolvedores
no estavam fisicamente prximos aos gerentes de produto. As pessoas que tomavam
as decises de priorizao estavam em Redmond, Washington, e os desenvolvedores
em Hyderabad. Cada um deles estava trabalhando (oficialmente) oito horas por dia
em fusos horrios opostos. Ento havia ocasies nas quais os indianos pegavam um
trabalho pela manh, o finalizavam, e precisavam que a fila fosse reabastecida, mas os
gerentes de produto estavam obviamente, dormindo. Devido a esse problema de disponibilidade no instantnea, ns provavelmente deveramos ter permitido 16 horas
para reabastecimento de um nico item na fila em circunstncias extremas. Lembre-se
que os desenvolvedores eram o gargalo no fluxo de trabalho. Para maximizar o rendimento, ns nunca queramos os desenvolvedores ociosos. Ento ns precisamos ser
conservadores; 16 horas conservador quando se gasta apenas duas horas em mdia
para a deciso de reabastecimento da fila de entrada. Ento qual seria o rendimento
num perodo mdio de 16 horas? No auge do desempenho, a equipe alcanaria 56 itens
num nico trimestre; isso menos do que cinco por semana. Ento num perodo de

127

e 10.2

128

Captulo 10 Estabelecendo Limites para o Trabalho-em-Progresso

16 horas era improvvel que eles finalizassem at mesmo um nico item da fila, ento
um tamanho de fila de um era aceitvel. No existir fila seria aceitvel. Haveria ainda
alguma chance da equipe sofrer de tempo ocioso quando eles finalizassem um item
durante a janela de 16 horas quando os gerentes de produto poderiam estar indisponveis para reabastecer a fila.

Sees Ilimitadas de Trabalho


Na soluo de sistema puxado para problemas de fluxo da Teoria das Restries, conhecida como Tambor-Reteno-Corda (Drum-Buffer-Rope), todas as etapas de trabalho
a partir do gargalo tm WIP ilimitado. Este esquema baseado no pressuposto de que
elas tm mais capacidade para aumento do rendimento do que o gargalo e tm folga
na capacidade que resulta em tempo ocioso; como resultado no h necessidade de
limitar o WIP. Isto ilustrado na Figura 10.2(a) a qual baseada na metfora usada
em The Goal de Goldrat e apresenta uma patrulha de escoteiros caminhando em fila
indiana. Uma corda amarrada entre o escoteiro lder e o escoteiro que se movimenta
mais lentamente (no. 4 na fila), que o gargalo do rendimento (a taxa na qual a patrulha cobre o terreno). Apenas uma corda necessria, visto que os escoteiros que esto
atrs do escoteiro mais lento nunca ficaro para trs, visto que eles podem andar mais
rpido do que o quarto da fila que restringe o passo de toda a patrulha
Com um sistema kanban, a maioria de todas as situaes no fluxo de trabalho tem
limites de WIP. Isso traz uma vantagem potencial, pois impedimentos causados por
uma variabilidade inesperada, ou no antecipada, podem fazer com que um passo
Bottleneck

(a) D-B-R

(b) CONWIP

(c) D-B-R + CONWIP


(CapWIP)
(d) Kanban
Figura 10.2 Desenhos ilustrando quatro sistemas puxados diferentes com limites de WIP

No Estresse a Sua Organizao

anterior torne-se um gargalo temporrio. O limite de WIP local com o sistema kanban
far com que a fila pare rapidamente, mantendo o sistema livre de gargalos e no sobrecarregado. Quando o impedimento removido, o sistema reiniciar graciosamente.
O estilo kanban de limitar o WIP ilustrado na figura 10.2(d), que mostra como os
escoteiros poderiam ser amarrados uns aos outros se utilizassem o estilo kanban. Neste
caso, cada escoteiro amarrado ao prximo da fila. So necessrias cinco cordas para
controlar o passo da patrulha inteira de seis escoteiros.
Em alguns casos pode ser aceitvel que um sistema kanban no tenha limites nos
passos finais do processo. No exemplo da XIT na Microsoft, assumiu-se que a disponibilidade do usurio base para realizar os testes de aceitao era efetivamente infinita e
essencialmente instantnea, portanto no havia necessidade de limitar o WIP no teste
de aceitao do usurio. Na Corbis, a fila release-pronto foi eliminada. Isto foi baseado
no pressuposto de que o batch do trabalho release-pronto nunca se tornaria excessivo,
dado cadncia de release ser quinzenal. Se, por outro lado, fosse possvel que o material para release-pronto se tornasse excessivo isso poderia aumentar a complexidade do
release, o que poderia resultar em custos antieconmicos de coordenao e transao
do release sendo ento necessrio limitar o WIP na fila release-pronto. No entanto, esse
nunca foi o caso da Corbis, dessa maneira o estado release-pronto permaneceu sem
restries.

No Estresse a Sua Organizao


Escolher estreitar demasiadamente os limites de WIP inicialmente pode gerar estresse
excessivo na sua organizao. Organizaes de baixa maturidade com poucas capacidades tero mais impedimentos. Portanto, organizaes de baixa maturidade com poucas
capacidades podem acreditar que introduzir um sistema kanban exige muito esforo
caso atribuam-se limites de WIP muito baixos. Se h muitos impedimentos, representados por vrios tickets de cor rosa espalhados pelo quadro, apertar demasiadamente
os limites de WIP significar que tudo vai parar e as pessoas ficaro ociosas. Apesar
de em tempo ocioso tendermos a focar a ateno e acelerar os esforos para resoluo
de problemas e remoo de impedimentos, isso pode ser muito doloroso para uma
organizao de baixa maturidade. Gerentes seniores podem ficar irritados observando
tantas pessoas ociosas ainda recebendo contracheques.
Ao introduzir mudana, voc deve estar ciente da curva de efeito J. Idealmente, cada
mudana produz um pequeno J onde qualquer impacto no desempenho superficial,
ento o sistema rapidamente se recupera e apresenta melhoria. Caso voc aperte muito

129

130

Captulo 10 Estabelecendo Limites para o Trabalho-em-Progresso

os limites de WIP, voc sofrer da curva de efeito J que muito profunda e muito longa,
a qual pode causar efeitos indesejveis: Kanban est expondo todos os problemas da
organizao, mas ele pode acabar sendo culpado por fazer tudo ficar pior, e ser visto
como sendo parte do problema mais do que a soluo; ento tenha cuidado. Voc
pode ser mais agressivo com as suas polticas de limite de WIP com organizaes de
maior capacidade e mais maduras que sofrem com pequenos problemas inesperados
(variaes atribudas causa). Para organizaes mais caticas, voc deve introduzir limites mais soltos inicialmente com um WIP maior e uma inteno de reduz-lo
posteriormente.

No Estabelecer um Limite de WIP um Erro


Embora eu advirta voc a no ser agressivo quando estabelecer os limites de WIP iniciais, eu me tornei convicto de que no estabelecer limite para WIP um erro.
Alguns precursores de Kanban, como o Yahoo!, escolheram no estabelecer limites
porque eles supuseram que suas equipes eram muito caticas para lidar com o esforo
que isso pode introduzir. A esperana era que essas organizaes amadureceriam atravs do controle visual dos elementos de Kanban e que os limites de WIP poderiam ser
introduzidos posteriormente. Isto se provou problemtico, no entanto, e muitas equipes
abandonaram Kanban sem visualizar muitas melhorias, enquanto outras foram dissolvidas em reorganizaes corporativas ou cancelamento de projetos, negando-nos mais
dados. Na Corbis, muitas equipes em projetos maiores usavam Kanban com limites
muito soltos de WIP para funcionalidades de alto nvel; os resultados eram bastante
distintos.
Tenho convico de que a tenso criada pela imposio de limite de WIP atravs
da cadeia de valor uma tenso positiva. Esta tenso positiva fora a discusso sobre
os problemas da organizao e disfunes. As disfunes geram impedimentos para o
fluxo e resultam em produtividade, lead time e qualidade aqum do esperado. A discusso e colaborao invocadas pela tenso positiva do WIP limitado so saudveis.
um mecanismo que possibilita a emergncia de uma cultura de melhoria contnua.
Sem limites de WIP, o progresso na melhoria de processo lento. Equipes que impuseram limites de WIP desde o incio relataram crescimento acelerado na capacidade
e maturidade organizacional e tm entregado resultados de negcio superiores com
frequncia; entregas previsveis de software de alta qualidade. Em comparao, equipes
que deferiram a introduo de limites de WIP tm geralmente lutado muito e apresentado melhorias limitadas.

Alocao de Capacidade

Alocao de Capacidade
Uma vez que estabelecemos os limites de WIP para o fluxo atravs do sistema, podemos
considerar a alocao de capacidade por tipo de item de trabalho ou classe de servio.
Figura 10.3 mostra o projeto da parede de cartes do captulo 6 com limites de WIP
atravs das colunas totalizando 20 cartes. A capacidade alocada atravs dos tipos de
item de trabalho, nomeados, 60 por cento para requisies de mudana, 10 por cento
para itens de manuteno, e 30 por cento para mudanas de textos em produo. Isso
equivale a um limite de WIP na raia de 12 para requisies de mudana, 2 para itens
de manuteno, e 6 para mudanas de textos em produo.
Alocao de capacidade nos permite garantir o servio para cada tipo de trabalho
recebido pelo sistema kanban. A alocao deve geralmente ser feita em resposta demanda observada para cada tipo de trabalho. Portanto, importante realizar anlise
de demanda
para facilitar uma alocao razovel de limites de WIP nas raias para cada
Fig 10.3!
tipo de trabalho.
10.3!

Figura 10.3 Parede de cartes mostrando raias para cada tipo de trabalho com limites
de WIP explcitos para cada raia
5!

Alocao!
Total = 20!

4!

Fila!
Anlise!
Entrada! Em Prog! Feito!

3!

4!

Des.
Desenvolv.!
Pronto! Em Prog! Feito!

2!

2!

= 20 total!

Build Teste! Release


Pronto!
Pronto! ...!

Sol. Mudana
12!

Manuteno!
2!
Defeitos em Produo!
6!

Figura 10.3 Parede de cartes mostrando raias para cada tipo de trabalho com limites de WIP explcitos para cada raia

131

132

Captulo 10 Estabelecendo Limites para o Trabalho-em-Progresso

Takeaways
Limites de WIP devem ser acordados a partir de consenso com os stakeholders de todos os nveis e a gerncia snior.
Decises unilaterais para limites de WIP so possveis, mas podem ser difceis de defender posteriormente, quando o sistema colocado sob estresse.
Limites de WIP para tarefas devem ser estabelecidos para um nmero mdio
de itens por pessoa, pares de desenvolvedores, ou equipes pequenas e colaborativas.
Tipicamente, o limite deve estar num intervalo de um a trs itens por pessoa,
par, ou equipe.
Limites de fila devem ser mantidos pequenos, tipicamente apenas grandes
o bastante para absorver a variao natural (causa randmica) no tamanho
dos itens e durao das tarefas.
Os gargalos devem ser retidos.
O tamanho da reteno deve ser o menor possvel, mas grande o suficiente
para garantir um timo desempenho no gargalo e manuteno do fluxo do
sistema.
Todos os limites de WIP podem ser ajustados empiricamente.
Kanban um processo emprico.
No se deve desperdiar tempo tentando determinar um limite de WIP perfeito; simplesmente escolha um nmero que prximo o bastante, e progrida; ajuste empiricamente, se necessrio.
Etapas de trabalho posteriores sem limite so possveis.
Deve-se ter cuidado ao se estabelecer etapas sem limite no fluxo para que no
sejam introduzidos gargalos ou custos de transao e coordenao excessivos
quando entregas so feitas (transferncia de batch para etapas posteriores).
Uma vez que os limites de WIP foram estabelecidos, a capacidade pode ser
alocada atravs dos itens de trabalho.
Usa-se frequentemente raias para cada tipo de trabalho e um limite de WIP
para cada raia.
Alocao de capacidade requer anlise da demanda comparativa atravs dos
diferentes tipos de trabalho recebidos pelo sistema kanban.

C aptulo 11

Estabelecendo Acordo
de Nvel de Servio

s temos familiaridade com o conceito de diferenciar classes de


servio. Todos que fizeram um check-in para um vo num aeroporto sabem que clientes que pagam mais pela passagem, ou que
gozam de prmios de um programa de fidelidade, so autorizados a
usar uma via rpida para driblar a fila. Algumas vezes esses privilgios
so estendidos para as filas de segurana do aeroporto e incluem o
uso de um salo especial e tratamento preferencial no momento do
embarque. Os clientes que pagam mais ou aqueles que so fiis companhia area gozam de uma melhor classe de servio.
Somos familiarizados com o conceito em desenvolvimento de software e sistemas de TI tambm, mas evidentemente com resoluo de
defeitos, e particularmente com defeitos em produo. Ns avaliamos
defeitos por severidade (impacto) e prioridade (urgncia). Defeitos
de severidade e prioridade altas so resolvidos imediatamente. Eles
recebem uma classe de servio diferente, mais alta do que outros trabalhos. Para corrigir um defeito de produo de severidade alta, colocamos outros trabalhos de lado, envolvemos quantas pessoas sejam
necessrias, e frequentemente elaboram-se planos especiais para uma
correo de emergncia, patch, ou release para mitigar o problema.
Este conceito pode ser aplicado mais genericamente, o que oferece
mais vantagens para a agilidade no negcio e gerenciamento de risco.
Algumas requisies so mais necessrias do que outras, enquanto
133

134

Captulo 11 Estabelecendo Acordo de Nvel de Servio

algumas so mais valiosas do que outras. Oferecendo tratamento diferente para tipos
de trabalho com classes de servio diferentes, podemos fornecer ao cliente mais flexibilidade otimizando o resultado econmico.
Classes de servio nos fornecem um caminho conveniente de classificao do trabalho a fim de fornecer nveis aceitveis de satisfao do cliente a um custo economicamente excelente. Identificando rapidamente a classe de servio de um item, somos
poupados da necessidade de realizar estimativas ou anlise detalhadas. Polticas associadas com uma classe de servio afetam a maneira como os itens so puxados no
sistema. Classe de servio determina prioridade dentro do sistema. Classes de servio
permitem uma auto-organizao, uma abordagem de valor e risco otimizada para
priorizao e re-planejamento.

Definies Tpicas de Classe de Servio


Classes de servio so tipicamente definidas baseando-se no impacto do negcio.
Diferentes notas coloridas, cartes de ndice, ou tickets so atribudos para cada classe
e claramente identificam a classe de servio de uma dada requisio, como na figura
11.1;
caso contrrio, so desenhadas raias separadas na parede de cartes para repreFigura 11.1 Parede de cartes mostrando tickets coloridos para demosntrar classes
sentar
os membros
das classes
deMaassen
servio. QNH)
de dervio
(cortesia
de Olav
11.1!

5!

Fila!

4!

3!

Anlise!

Entrada! Em Prog!

Feito!

4!

2!

2!

Des.
Desenvolv.! Build Teste! Release Stage! Prod.!
Pronto! Em Prog! Feito! Pronto!
Pronto!

Figura 11.1 Parede de cartes mostrando tickets coloridos para demonstrar classes de servio

Expedio

Cada classe de servio traz seu conjunto de polticas prprio que afeta a maneira
como os itens so priorizados quando eles so puxados no sistema kanban. A classe de
servio tambm traz uma promessa explcita para o cliente. Em seguida h um breve
exemplo de um conjunto de definies de classes de servio. Apesar desse conjunto
no ser uma cpia precisa daqueles utilizados em qualquer implementao especfica
de Kanban, ele representa uma forte generalizao de classes de servio observadas
em campo.
Neste conjunto exemplo so oferecidas quatro classes de servio. Como um guia
geral, voc deve oferecer no mximo seis classes. Ser muito complicado administrar
e operar muitas classes. O nmero de classes de servio deve ser pequeno o bastante de
maneira que todos os envolvidos membros da equipe e stakeholders externos possam lembrar todas elas, e deve ser o suficiente para oferecer flexibilidade na resposta
demanda do cliente.

Expedio
A classe de servio de Expedio (ou Bala de Prata)
bem compreendida na indstria de manufatura. Um cenrio tpico pode ser uma equipe de vendas tentando alcanar a meta de venda trimestral associada a um cliente que
tem um oramento que deve ser gasto at o final do ano
fiscal. O cliente vem postergando uma deciso de compra; ele finalmente faz a escolha, mas o ano fiscal est acabando. O pedido realizado, mas ele deve ser entregue
antes do prazo acordado. O fabricante acorda o preo e a
quantidade e aceita o pedido. O pedido deve ser preenchido, entregue, e enviado antes
do ltimo dia do trimestre. Um pedido como esse tipicamente chega fbrica via o
escritrio do vice-presidente regional de vendas, como uma requisio de entrega de
expedio, dado o curto espao de tempo e o valor do pedido.
A habilidade de expedir d ao vendedor a habilidade de dizer Sim! em circunstncias difceis para atender s necessidades do cliente. No entanto, expedir pedidos,
afeta de maneira negativa a cadeia de fornecedores e os sistemas de distribuio da
manufatura. Expedir conhecida na engenharia e operao industrial por aumentar os
nveis de estoque e aumentar os lead times de outros pedidos que no sejam de expedio. O negcio escolhe gerar valor numa venda especfica ao custo de atrasar outros
pedidos e incorrer em custos adicionais de transporte para altos nveis de estoque.
Caso a companhia seja bem gerenciada, o valor gerado a partir da expedio exceder

135

136

Captulo 11 Estabelecendo Acordo de Nvel de Servio

os custos incorridos a partir de lead times maiores (e potencial perda de negcio como
resultado) e o custo de transporte para um nvel maior de estoque.
Companhias de manufatura frequentemente criam polticas para limitar o nmero
de requisies de expedio que chegam fbrica. Uma poltica comum conceder
um nmero fixo de balas de prata para o vice-presidente regional de vendas num
perodo determinado de tempo. Portanto, o termo bala de prata tornou-se sinnimo
de expedir na manufatura ou distribuio.
Infelizmente, como esclarecimento, o termo bala de prata j estava em uso pela
engenharia de software. Fred Brooks a definiu como uma mudana simples (na tecnologia ou no processo) que geraria melhoria de uma ordem de magnitude (dez vezes)
na produtividade do programador. Portanto, eu recomendo que voc use o termo
Expedio para esta classe de servio. Nas companhias que fazem manufatura, ou nas
quais o gerente snior familiar com manufatura, no entanto, observei que eles preferem o termo bala de prata. Isso bom desde que as pessoas de tecnologia percebam
a diferena do uso.

Data Fixa de Entrega


Em meados de Fevereiro de 2007, um desenvolvedor
entrou no meu escritrio para perguntar se eu estava
ciente de um problema com uma plataforma de servio que usvamos para processamento de carto de
crdito; eu no estava ciente, ento ele explicou. Para
atender demanda de novas funcionalidades em 2006,
eles tinham substitudo completamente a plataforma
por um novo sistema que tinha uma interface de programao de aplicao (API) completamente nova. Eles
tinham informado a todos os seus clientes e deram a
eles 15 meses para que o sistema antigo fosse substitudo at 31 de Maro de 2007.
Colocando de outra maneira, se ns no atualizssemos nossos sistemas para usar a
nova plataforma, ns deixaramos de comercializar na Internet em 1 de Abril de 2007.
Isto seria significativamente inconveniente para um negcio onde muito da receita era
gerada por meio de vendas na web, sem mencionar o constrangimento para o dono da
firma. Ns tnhamos apenas seis semanas para fazer as mudanas necessrias e distribuir o novo cdigo em produo. O ticket para esse trabalho entrou no sistema kanban
marcado com uma data fixa de entrega. A informao adicional no ticket visava chamar
ateno para o custo e o impacto no atraso da entrega, como tambm para permitir que
a equipe expedisse o item por ela mesma e garantisse a entrega no prazo.

Data Fixa de Entrega

No foi a primeira vez que ns vimos uma requisio desse tipo. Tivemos uma
requisio anterior a essa relacionada integrao de sistemas de TI de uma empresa
adquirida. A data fixa anexada foi derivada do caso de negcio para a aquisio, o que
mostrou significante economia nos custos a partir de 1 de Fevereiro do mesmo ano.
Um conceito, ou padro, parecia estar emergindo. Algumas requisies relacionadas
a grandes obrigaes contratuais, algumas relacionadas a requisitos de regulamentao
(usualmente do governo federal), e outras relacionadas a iniciativas estratgicas, como
a aquisio de outros negcios. Requisies dessa natureza traziam um custo de atraso
significante, direta ou indiretamente, que tendiam a se encaixar em uma das duas categorias: Haveria uma data quando uma pena ou multa um custo direto, especfico e
no reembolsvel poderia ser cobrada, imposta pela autoridade regulatria ou pelos
termos estabelecidos no contrato. Alternativamente, haveria um requisito para parar
alguma atividade, como a venda de um tipo de item em particular ou uma operao
numa jurisdio especfica, at que os requisitos fossem atendidos. Na segunda alternativa, o custo indireto o custo da perda de uma oportunidade a perda potencial
de receita durante o perodo de atraso. Os dois tipos esto graficamente representados
na Figura 11.2.
Negcios com calendrio sazonal, como escolas e faculdades, tendem a ter restries
fortes no calendrio. Se voc trabalha com o setor de educao, voc tem clientes para
os quais voc deve entregar software em momentos fixos do ano: Falhas para entregar
no perodo esperado causam perdas nas vendas. Devemos considerar que tudo que
envolve fsica ou culturalmente uma janela de mercado tem uma funo de custo
do atraso de primeiro grau (ou prxima disso), e deve ser tratado com uma data de
entrega fixa, se esta data futura est dentro de uma janela de tempo razovel a partir

Custo!

Custo!

Fig 11.2!

t!
(a) Multa regulatria!

t!
(b) Falta de habilidade (ou negao!
da capacidade) para comercializar!

Figura 11.2 Duas funes de custo de perfil de atraso para classe de servio de Data Fixa

137

138

Captulo 11 Estabelecendo Acordo de Nvel de Servio

da data atual ou culturalmente uma janela de mercado deve ser considerada como
uma funo de custo do atraso de primeiro grau, e deve ser tratada com uma data de
entrega fixa.

Classe Padro
A maioria dos itens necessrios com urgncia deve ser
tratada como itens de classe padro. As polticas e o
acordo de nvel de servio para um item de classe padro
podem variar de acordo com o tipo de item de trabalho.
Um projeto de sistema kanban comum separa os tipos de
trabalho por tamanho, como pequeno, mdio e grande.
Pode ser oferecido um acordo de servio diferente para
cada tamanho de itens de classe padro. Por exemplo,
itens pequenos so processados tipicamente dentro de
quatro dias, itens de tamanho mdio em um ms e itens
grandes em trs meses. Itens de classe padro tendem a ter um custo de atraso tangvel
que pode ser calculado (embora no necessariamente em unidade monetria). O custo
de atraso tende a ser imediato: se temos esta funo hoje, os benefcios viro amanh.

Classe Intangvel
Faz sentido oferecer uma quarta classe de servio menor.
Eu me esforcei para encontrar um nome adequado para
esta classe e estabeleci o nome intangvel. Eu no
estou completamente satisfeito com ele, dessa maneira
ele pode ser alterado numa prxima edio desse livro.
Itens de classe intangvel podem ser importantes e valiosos, mas no h um custo de atraso tangvel associado a
eles num futuro prximo. Isto , no h custo de atraso
dentro do prazo de entrega do item. Requisies que
atendem a esse padro so as entregas que possuem uma
data fixa de entrega em potencial, mas uma data que est num futuro distante, como
uma substituio de plataforma.
Por exemplo, em 2005 a Microsoft lanou o SQL Server 2005, a ltima verso do seu
servidor de banco de dados RDBMS. A edio de 2005 substituiu a edio de 2000, a
qual se tornou fim de vida. Como player dominante do Mercado, era requerido que a

Polticas para Classe de Servio

Microsoft desse suporte aos seus produtos por dez anos aps eles terem sido lanados.
Como resultado disso, o suporte ao SQL Server 2000 deveria continuar at 2010. Isto
deu aos clientes um perodo de cinco anos para substituir o cdigo que era incompatvel com a edio mais nova, 2005 (ou 2010) da plataforma. Ento substituir o cdigo
em 2005 ou 2006 stored procedures, cdigo persistente no tem uma prioridade de
tempo crtica. No h custo de atraso incorrido nestes anos. No entanto, com o passar
do tempo e se o cdigo no alterado, o custo aumenta. Torna-se cada vez mais difcil
trabalhar com outros produtos, visto que eles requerem novas verses do SQL Server
2005 como pr-requisito. Ocorre mais e mais presso para se fazer a troca para a nova
plataforma. Em 2009 o problema urgente, visto que a Microsoft parar de dar suporte
ao antigo produto, e falhas para atualizao faro com que o negcio seja executado
em mquinas antigas com sistemas operacionais e infra-estruturas no suportadas.
Se o risco inaceitvel, o cdigo deve ser atualizado. Substituio de plataforma um
problema comum que equipes de engenharia de software lutam continuamente. H um
desejo de comear logo o trabalho e complet-lo no tempo adequado, mas a capacidade para fazer o trabalho de atualizao deslocada por outro trabalho mais urgente
ou crtico. Em outras palavras, substituio de plataforma, embora tenha um custo de
atraso imediato baixo, deslocada por outros trabalhos com um custo de atraso maior
e mais imediato.
Faz sentido oferecer uma classe de servio que permitir que esse tipo de trabalho
seja empreendido o quanto antes. Pode-se alocar capacidade para o trabalho a fim de
garantir que ele seja finalizado; no entanto, pode no haver garantia de tempo. Mais do
que isso, este custo de atraso baixo do trabalho que sempre o colocar de lado quando
mais requisies de urgncia aparecerem. Para existir uma folga para processar uma
requisio de expedio, deve existir trabalho de custo de atraso baixo que pode ser
deslocado enquanto a requisio de expedio processada. Os itens de classe intangvel fornecem essa folga.

Polticas para Classe de Servio


Uma tcnica de visualizao deve ser empregada para prontamente se identificar uma
classe de servio. Como mencionado anteriormente, cores diferentes de tickets ou raias
diferentes na parede de cartes so as mais comuns. Algumas equipes tm usado decoraes como adesivos de estrelas colados ao ticket do item de trabalho. Uma raia para
requisies de expedio tambm uma escolha comum. Use um critrio seu para
como visualizar suas classes de servio. Este captulo usa cores diferentes para mostrar
classe de servio. O objetivo garantir que qualquer membro da equipe, em qualquer

139

140

Captulo 11 Estabelecendo Acordo de Nvel de Servio

dia, possa usar polticas simples de priorizao associadas a uma classe de servio para
tomar decises de priorizao de qualidade sem interveno ou superviso da gerncia.
A seguir h um exemplo de polticas de priorizao para as quatro classes de servio
definidas previamente. Naturalmente, para toda implementao, as definies de classe
de servio sero nicas e suas polticas de uso sero diferentes destes exemplos. Estas
polticas so baseadas em evidncia emprica e elas refletem com bastante preciso
polticas que equipes reais tm utilizado.

Polticas de Expedio
Requisies de expedio usam cartes brancos.
Apenas uma requisio de expedio permitida em qualquer momento. Em
outras palavras, uma classe de servio de Expedio tem um limite de WIP igual
a 1.
Um recurso qualificado deve puxar requisies de Expedio imediatamente.
Outro trabalho ser colocado on hold para processar a requisio de expedio.
Em qualquer ponto do fluxo de trabalho, o limite WIP pode ser excedido para
acomodar uma requisio de expedio. A capacidade no mantida em reserva
para expedio.
Se necessrio, um release especial (fora do ciclo) ser planejado para colocar uma
requisio de expedio em produo o mais cedo possvel.

Polticas de Data de Entrega Fixa


Itens com data de entrega fixa usam cartes roxos.
A data de entrega exigida apresentada no canto direito abaixo do carto.
Itens com data de entrega fixa so analisados e devem ser realizadas estimativas
de tamanho e esforo para avaliar o tempo de fluxo. Se o item grande pode ser
necessrio quebr-lo em itens menores; cada item menor ser avaliado independentemente a fim de verificar se ele se qualifica como um item de data de entrega
fixa.
Itens com data de entrega fixa so mantidos no backlog at eles serem selecionados
para a fila de entrada, prximo ao ponto ideal no tempo no qual ele deve ser
entregue no prazo, dado a estimativa do tempo de fluxo.

Polticas para Classe de Servio

Itens com data de entrega fixa so puxados preferencialmente em relao a outros


itens de menor risco. Neste exemplo, eles so puxados antes dos itens de classe
padro ou intangvel.
Itens com data de entrega fixa devem aceitar o limite WIP.
Itens com data fixa de entrega enfileiram para release quando eles esto finalizados e prontos para release. Eles so released regularmente um pouco antes da data
de entrega exigida.
Se um item com data de entrega fixa fica para trs, e entregar o release na data
desejada um risco, sua classe de servio deve ser promovida para uma requisio
de expedio.

Polticas de Classe Padro


Itens de classe padro usam cartes amarelos.
Itens de classe padro so priorizados para a fila de entrada baseando-se num
mecanismo acordado previamente, como uma votao democrtica, e so selecionados tipicamente baseando-se no seu custo de atraso ou valor de negcio.
Itens de classe padro usam o mecanismo de fila first in, first out (FIFO) a partir
do momento que so puxados pelo sistema. Tipicamente, quando uma opo
dada, um membro da equipe puxa o item de classe padro mais antigo se no h
um item de expedio ou com data fixa para ser escolhido preferencialmente.
Itens de classe padro enfileiram para release quando eles esto finalizados e prontos para release. Eles so released no prximo release agendado.
No realizada estimativa para determinar o nvel de esforo ou tempo de fluxo.
O tamanho dos itens de classe padro deve ser analisado. Itens grandes devem ser
quebrados em itens menores. Cada item deve ser enfileirado e fluir separadamente.
Itens de classe padro so geralmente entregues dentro de x dias da seleo com
um desempenho de entrega de m por cento.
Um acordo de nvel de servio tpico para uma classe padro deve oferecer um lead
time de 30 dias com um desempenho de 80% no desempenho de entrega no prazo. Em
outras palavras, quatro de cinco requisies devem ser entregues em 30 dias.

141

142

Captulo 11 Estabelecendo Acordo de Nvel de Servio

Classe Intangvel
Itens de classe intangvel usam cartes verdes.
Itens de classe intangvel so priorizados na fila de entrada baseando-se num
mecanismo acordado previamente, como uma votao democrtica, e so selecionados tipicamente baseando-se em algum impacto em longo prazo ou custo
de atraso.
Itens de classe intangvel so puxados pelo sistema de maneira ad hoc. Membros
da equipe podem escolher puxar um item de classe intangvel desconsiderando
sua data de entrada, enquanto um item de maior classe no est disponvel.
Itens de classe intangvel enfileiram para release quando so finalizados e prontos
para release. Eles so released no prximo release agendado ou ficam em espera
para serem agrupados a outros itens.
No realizada estimativa para determinar o nvel de esforo ou tempo de fluxo.
O tamanho dos itens de classe intangvel deve ser analisado. Itens grandes devem
ser quebrados em itens menores. Cada item deve ser enfileirado e fluir separadamente.
Tipicamente, um item de classe intangvel colocado de lado para se processar
uma requisio de expedio.
Pode no ser necessrio oferecer um acordo de nvel de servio para itens de
classe intangvel. Se for necessrio, deve ser um acordo significativamente mais
frouxo do que aquele oferecido para itens de classe padro, por exemplo, 60 dias
com 50 por cento de desempenho para entrega no prazo.

Determinando Meta para Entrega de Servio


No conjunto de classes exemplo acima, a classe de servio Padro usou uma meta
para o lead time, por exemplo, de 28 dias (4 semanas). O conceito de oferta de uma
meta para o lead time, associado mtrica de desempenho de entrega no prazo uma
alternativa para tratar cada item individualmente e se ter uma estimativa e compromisso para a data de entrega de cada item. O acordo de nvel de servio nos permite
evitar atividades custosas, como estimativas; atividades que reduzam a confiana, como
assumir compromissos; e propagar risco agregando um conjunto grande de requisies
e comprometendo-se apenas com o desempenho global sob a forma de desempenho

Determinando Meta para Entrega de Servio

percentual de entrega no prazo. Ao evitar compromissos que no seremos capazes de


cumprir, evitamos o perigo de perder a confiana de nossos clientes. No entanto,
importante comunicar que a meta do lead time para a classe de servio Padro apenas
isso, uma meta!
Dados histricos ajudam a determinar a meta do lead time. Caso voc no tenha
dados histricos, d um palpite razovel. Caso voc tenha, ento o meio mais cientfico
para determinar a meta do lead time processar o lead time (a partir da seleo do item
at a entrega) atravs de um controle-processo estatstico ou uma ferramenta kanban
de acompanhamento que d suporte a controle de processo estatstico (como a Sylver
Catalyst) e usar o limite de controle mximo (o limite plus-3 six sigma) para o seu lead
time. Isso garante uma meta que voc pode alcanar sob circunstncias mais normais
e perd-la apenas quando h um problema genuno de causa atribuvel. (veja captulo
19 para uma explanao mais detalhada).
Se, por outro lado, o ultimo pargrafo no significou nada para voc, ento uma
explicao mais leiga que voc precisa que o lead time seja atingvel a maior parte do
tempo, mas que tambm seja agressivo o bastante para manter a equipe focada. provvel que os seus itens de trabalho variem em tamanho, complexidade, risco, e expertise
requeridos; dessa maneira, o lead time varia significativamente. Tudo bem. Se voc
realiza uma anlise espectral de alguns dados histricos e verifica que talvez 70 por
cento dos itens sejam entregues em 28 dias, e os 30 por cento restantes espalham-se por
100 dias, ento talvez seja razovel sugerir uma meta para data de entrega de 28 dias.
Eu aprendi que o uso de classes de servio uma tcnica poderosa. Com a minha
equipe de 2007, aproximadamente 30 por cento de todas as requisies atrasavam comparando meta do lead time. Ns relatamos isso como a mtrica de Desempenho do
Prazo. Ela nunca foi acima de 70 por cento. No entanto, apesar desse mau desempenho
em relao data de entrega, ns tnhamos poucas reclamaes. As razes para isso
tornaram-se evidentes: Todos os itens importantes aqueles com risco ou valor alto
eram sempre entregues na data, e havia confiana que os ltimos seriam entregues
dentro de duas ou quatro semanas adicionais, visto que as entregas aconteciam com
uma regularidade confivel.
As classes de servio de Expedio e Data de Entrega Fixa estavam garantindo que
itens importantes fossem sempre entregues no prazo. Enquanto isso, os outros itens
da classe Padro atrasavam em apenas um ou dois releases (14 ou 28 dias, respectivamente). Os clientes confiavam na cadncia de release; a confiana foi conquistada pela
ao. Ns entregvamos consistentemente um release toda segunda quarta-feira. Com
o custo de atraso insignificante associado a muitos itens de classe Padro (e Intangvel,
visto que eles no foram delineados separadamente), o negcio focou no que tinha

143

144

Captulo 11 Estabelecendo Acordo de Nvel de Servio

que ser entregue e no planejamento de itens futuros em vez de se preocupar muito em


relao a datas precisas de entrega para trabalho-em-progresso.
Este resultado foi significante porque Kanban com classes de servio claramente
mudou a psicologia do cliente e alterou significativamente a natureza do relacionamento e as expectativas. Os clientes foram orientados a uma relao de longo prazo e
ao desempenho do sistema, e no a entrega de um item ou itens especficos. Isto deu
liberdade equipe de desenvolvimento para focar nas coisas certas e no desperdiar
tempo com questes que surgiam a partir de um baixo nvel de confiana entre a equipe
e o cliente.

Estabelecendo uma Classe de Servio


A classe de servio para um item deve ser estabelecida quando o item selecionado
para a fila de entrada. Se um item uma requisio de expedio, isto deve ser evidente
isso vem com uma requisio para o item ser processado o mais cedo possvel. A
justificativa baseia-se no caso de negcio que mostra alguma oportunidade imediata
ou identifica um custo significante que ser incorrido se a requisio no for realizada, talvez o custo j esteja sendo incorrido. Isto tpico com defeitos de produo
de severidade alta.
Se um item tem uma data de entrega fixa isto tambm deve ser evidente por sua natureza. Talvez a requisio esteja relacionada a um novo requisito regulatrio previsto
por uma autoridade regulatria independente, ou a uma natureza sazonal do negcio.
Se um item da classe de data fixa, a data tipicamente conhecida, e encontra-se dentro de um perodo de tempo razovel talvez duas vezes mais longo do que a meta de
lead time da classe de servio padro e o item deve ter sido estimado de modo a ser
introduzido no ponto ideal para garantir entrega no prazo.
Uma escolha difcil se o item da classe padro ou intangvel. Minha observao
que itens de classe padro seguem uma funo de custo de oportunidade que faz efeito
imediatamente. Por exemplo, se tivssemos essa nova feature hoje, poderamos estar
fazendo dinheiro a partir dela amanh. Ento entregar antes desejvel, mas atrasar
no acarreta a mesma pena, como algo de natureza de data fixa ou uma requisio de
expedio.
Itens intangveis tendem a ser associados com itens importantes e de valor que
tm um (oportunidade) custo de atraso que no traz efeito num futuro prximo.
Tipicamente, a funo de custo faz uma curva de inflexo para cima em trimestres, ou
anos, no futuro. Isto est bem alm de um horizonte de planejamento imediato, isto
, duas ou trs vezes um lead time tpico. Se o nosso lead time atual geralmente 28

Colocando Classes de Servio em Uso

145

dias, ento nosso horizonte de planejamento talvez de trs meses. Itens que incorrero numa perda de oportunidade ou num custo tangvel dentro de trs meses devem
ser tratados como classe padro, enquanto itens no qual o custo ou benefcio no
visualizado dentro de trimestres ou anos no futuro devem ser tratados como itens de
classe intangvel.

Colocando Classes de Servio em Uso


Classes de servio devem ser definidas para cada sistema kanban. As polticas associadas com cada classe de servio devem ser explicadas para todos os membros da equipe.
Todos que participam da standup meeting* pela manh devem gostar e entender as classes de servio em uso. Para isso se tornar efetivo, o nmero de classes de servio deve
ser mantido relativamente pequeno quatro a seis uma boa diretriz. E novamente,
Figura
11.3 Parede
de cartes
capacidade
da alocao
das classes
como
queremos
que cada
membromostrando
da equipe lembre
as classes
de servio,atravs
o que elas
Fig 11.3!
de servio
significam,
e como us-las, o nmero de polticas para cada classe de servio deve ser
mantido pequeno e as polticas devem ser simples. As definies devem ser precisas
5!

4!

Fila!
Anlise!
Entrada! Em Prog! Feito!

3!

4!

Des.
Desenvolv.!
Pronto! Em Prog! Feito!

2!

2! = 20 total!

Build Teste! Release


...!
Pronto!
Pronto!

Alocao!
+1 = +5%!
4 = 20%!
10 = 50%!
6 = 30%!
Figura 11.3 Parede de cartes mostrando capacidade da alocao atravs das classes de servio

* N. de T.: Termo no traduzido devido sua utilizao mais ampla no idioma original (Ingls) pela comunidade de TI no
Brasil. Traduo: reunio em p.

146

Captulo 11 Estabelecendo Acordo de Nvel de Servio

e sem ambiguidade. Novamente, uma boa diretriz deve ser no mais de seis polticas
por classe de servio.
Armados com um entendimento das classes de servio e das polticas associadas a
elas, a equipe deve ter poder para auto-organizar o fluxo de trabalho. Itens de trabalho
devem fluir atravs do sistema de uma maneira a otimizar o valor do negcio e o servio ao cliente, tendo como resultado releases de software que maximizam a satisfao
do cliente.

Aloque Capacidade para Classes de Servio


Figura 11.3 mostra um sistema kanban com um limite de WIP total de 20. Classes de
servio so designadas por quatro cores de tickets. Os tickets brancos de expedio
no contam para o limite de WIP, mas so limitados a apenas um item de cada vez.
Portanto, eles tm um impacto de cinco por cento na capacidade total quando presentes, e aumentam o trabalho-em-progresso para 21 itens. Neste exemplo, os tickets roxos
para data de entrega fixa representam 20 por cento do total. Isto significa que podem
existir apenas quatro tickets roxos no quadro a qualquer momento, mas eles podem
estar presentes em qualquer coluna. Itens de classe padro amarelos representam 50
por cento do total de alocao, com um total de 10 itens. Os 30 por cento restantes so
alocados para os itens verdes de classe intangvel.
Agora que alocamos capacidade para as diferentes classes de servio, a atividade
de preenchimento da fila de entrada torna-se complicada pela capacidade disponvel
para cada classe. Como apresentado, h capacidade para um item de data de entrega
fixa e trs para itens de classe intangvel; isto gera muitas perguntas. E se no tivermos
demanda atual para um item de data fixa? O que devemos fazer? Devemos preencher
o espao vazio com um item de classe padro? Caso positivo, o status desse item deve
ser de data fixa ou deve ser tratado como um item de classe padro? Se fizermos isso,
no estaremos ajustando a poltica de alocao de capacidade?
Todas essas questes legtimas e problemas legtimos destacados vm tona diariamente quando usamos um sistema kanban. No h respostas certas ou erradas para
estas questes. As respostas precisam ser derivadas no contexto e so especficas para
cada situao.
O que podemos deduzir da alocao escolhida que o domnio tem um nmero
significante de itens de natureza de data fixa e que h tambm uma capacidade para
itens intangveis. Isto deve implicar que h algumas iniciativas maiores com datas de
entrega de maior prazo como uma substituio de plataforma a caminho. Isso tambm pode indicar riscos significantes no domnio. Talvez haja uma natureza sazonal

Aloque Capacidade para Classes de Servio

para a demanda o que aumenta o nmero de requisies de expedio ou itens de data


fixa. Para ser capaz de responder de maneira adequada a esta demanda sazonal sem
causar aumento da insatisfao do cliente, escolhemos alocar mais capacidade para
itens intangveis em vez de itens de classe padro, dessa forma estamos construindo
mais folga no sistema.
Escolher o que fazer quando a fila de entrada tem um espao vazio para um item de
data fixa quando no h itens de data fixa disponveis depende dos riscos presentes no
domnio. Se h uma demanda significante para itens de data fixa e o custo associado a
estes itens alto (portanto o risco alto), devemos escolher deixar o espao vazio. Isso
pode fazer sentido para efetivamente reservar capacidade para um futuro item de data
fixa. Se posteriormente existir um item de data fixa, podemos escolher retirar o item
de classe padro ou exceder o limite de WIP temporariamente. Todas estas escolhas
tero efeitos diferentes no lead time, no desempenho de entrega no prazo, propagao
de variabilidade no lead time, satisfao do cliente, e gerenciamento de risco. Voc
precisa tomar essas decises por voc mesmo; levar algum tempo para desenvolver
uma experincia e discernimento adequados para permitir que voc faa as melhores
escolhas para a sua equipe, projeto, ou organizao.
Alocao de capacidade apenas outra estratgia do sistema kanban. Se voc acredita que sua alocao no est alinhada com a demanda, ento a ajuste mude as
polticas e ajuste os limites de WIP de acordo com as mudanas.

147

148

Captulo 11 Estabelecendo Acordo de Nvel de Servio

Takeaways
Classes de servio fornecem um mtodo simples para otimizar a satisfao
do cliente.
Itens de trabalho devem ser atribudos para uma classe de servio de acordo
com o impacto no negcio.
Classes de servio devem ser claras, apresentadas visualmente com o uso,
por exemplo, de cartes de cores diferentes ou raias diferentes na parede de
cartes.
Deve ser definido um conjunto de polticas de gerenciamento para cada
classe de servio. Apenas classes de servio relacionadas a itens de maior
risco devem envolver atividades que desperdiam tempo como estimativa.
Os membros da equipe devem ser treinados para que entendam as classes de
servio e as polticas associadas a elas.
Algumas classes de servio devem incluir uma meta de lead time.
O desempenho de entrega no prazo (percentual) deve ser monitorado para
metas de lead time.
Classes de servio possibilitam uma auto-organizao, delegam poder aos
membros da equipe, e liberam tempo da gerncia para focar no processo em
vez do trabalho.
Classes de servio mudam a psicologia do cliente.
Se as classes de servio so utilizadas apropriadamente e combinadas com
uma cadncia de entrega regular, poucas reclamaes sero recebidas, at
mesmo se uma poro significante dos itens no alcanarem sua meta de
lead time.
A capacidade do sistema Kanban deve ser alocada para cada classe de servio.
O percentual de capacidade alocada para cada classe de servio deve estar
alinhado com a demanda.

C aptulo 12

Mtricas e Relatrios de
Gerenciamento

mbora a ideia que Kanban seja minimamente invasivo e altere


o menos possvel a cadeia de valor, papis, e responsabilidades;
ele altera a maneira como a equipe interage com os seus parceiros os
stakeholders externos. Por causa disso, Kanban precisa reportar mtricas um pouco diferentes das que voc deve estar acostumado numa
abordagem tradicional ou num gerenciamento de projeto gil.
O fluxo contnuo do sistema Kanban significa que estamos menos
interessados em reportar se um projeto est on-time* ou se um
plano especfico est sendo seguido. O que importante mostrar:
que o sistema Kanban previsvel e est funcionando como projetado,
que a organizao tem agilidade no negcio, que h um foco no fluxo,
e que existe um desenvolvimento claro de melhoria contnua.
Para previsibilidade queremos mostrar o quanto nosso desempenho bom com as classes de servio. Itens de trabalho so tratados
apropriadamente, e, se a classe de servio tem uma meta de lead time,
o quanto estamos conseguindo atend-la? O que desempenho de
entrega no prazo?
Para cada um dos nossos indicadores, queremos acompanhar a
evoluo ao longo do tempo, de maneira que possamos ver a propagao da variao. Se quisermos demonstrar melhoria continua
* N. de T.: Termo no traduzido devido sua utilizao mais ampla no idioma original (Ingls)
pela comunidade de TI no Brasil. Traduo: dentro do prazo.
149

150

Captulo 12 Mtricas e Relatrios de Gerenciamento

precisamos que a tendncia melhore com o passar do tempo. Se quisermos demonstrar


melhoria na previsibilidade, precisamos que a propagao da variao diminua e que
o desempenho de entrega no prazo aumente.

Monitorando WIP
Antes de chegarmos aos indicadores de desempenho, no entanto, acredito que a mtrica
mais fundamental deve mostrar que o sistema kanban est funcionando apropriadamente. Para fazer isto, precisamos de um diagrama de fluxo acumulativo que mostra
as quantidades de trabalho-em-progresso em cada estgio do sistema. Se o sistema
kanban est fluindo corretamente, as faixas do grfico devem ser regulares e os tamanhos
ser estveis.
Figuradevem
12.1 Exemplo
de um diagrama de fluxo cumulativo de um Sistema Kanban
O exemplo do grfico na Figura 12.1 mostra quo bem a equipe est mantendo os
g 12.1!

Solicitaes em backlog!
Trabalho em Progresso!
Released!

Figura 12.1 Exemplo de um diagrama de fluxo cumulativo de um Sistema Kanban

limites de WIP. Podemos ver que o WIP (a faixa de cor clara no meio) est crescendo
no meio do perodo de tempo. No comeo, o limite de WIP 27; no final do perodo,
devido a um ajuste pessoal, o limite de WIP 21. Tambm podemos ver a mdia do
lead time escaneando o grfico horizontalmente.

Lead Time

Lead Time
A prxima mtrica de interesse indica o quanto previsvel nossa organizao na
entrega, considerando as definies de classe de servio. A mtrica fundamental para
isto o lead time. Se um item foi expedido, quo rpido ele foi do pedido at a produo? Se ele era de uma classe padro, ns o entregamos dentro da meta de lead time?
Descobri que a melhor maneira para mostrar estes dados com um espectro de anlise

g 12.2!

Lead Time Distribution


3.5
3

CRs & Bugs

2.5
2

Intervalo da maioria das CRs 30 -> 55!

1.5

Desvios!

14
8

14
1

12
7

12
0

11
3

99
10
6

92

85

78

71

g 12.3!
64

57

50

43

36

29

22

15

13
4

0.5

Days

Figura 12.2 Exemplo de uma anlise espectral do Lead Time

Mean Lead Time Trend

Figura 12.2 Exemplo de uma anlise espectral do Lead Time


60.0

50.0

Days

40.0

CRs
Bugs
Combo

30.0

20.0

10.0

0.0
Dec

Jan

Feb

Mar

Apr

Figura 12.3 Exemplo de uma Tendncia Mdia do Lead Time

Figura 12.3 Exemplo de uma Tendncia Mdia do Lead Time

May

151

152

Captulo 12 Mtricas e Relatrios de Gerenciamento

Figura 12.4 Exemplo de um relatrio mostrando a mdia do lead time e o desempenho da data na entrega

do lead12.4
time,
apresentando
num grfico
a metaa de
leaddotime
de nvel
Figura
Exemplo
de um relatrio
mostrando
mdia
leadversus
time eooacordo
desempenho
da
na (SLA)
entregapara uma classe de servio (veja Figura 12.2).
de data
servio

Reportar a taxa de lead time (media) tem utilidade como um relatrio do desempenho geral do sistema (veja Figura 12.3), mas no muito til como um indicador de
previsibilidade ou como um meio para informar oportunidades de melhoria.
O espectro de anlise muito mais til em nos informar sobre itens que falharam em
atingir a meta de tempo e outros desvios estatsticos. No exemplo mostrado na Figura
12.4, faria sentido investigar a causa raiz do grupo de itens que falharam em atingir a
meta. Se a causa raiz puder ser tratada, o Desempenho de Entrega na Data (percentual
de itens entregues como esperado) deve melhorar.

Desempenho de Entrega na Data


Acredito que seja til reportar Desempenho de Entrega na Data para os meses mais
recentes e para o ano da data. Voc pode tambm reportar desempenho ano a ano (ou
de 12 meses atrs) para comparao; portanto, til se ter 13 meses de dados.
Voc pode incluir os itens da classe de servio de Data de Entrega Fixa na mtrica
de Desempenho de Entrega na Data. Neste caso, voc estar respondendo seguinte
pergunta, O item foi entregue na data? No entanto, embora voc tenha o lead time
registrado, ele no to til quanto comparar o lead time estimado e o atual. Estimado
versus o atual demonstra o quanto previsvel a equipe e quo bem ela est trabalhando
com itens de servio de Data Fixa de Entrega. Lembre-se que itens de Data Fixa so
analisados e estimados. O desempenho da data de entrega com itens de data fixa um
fator determinante da qualidade da estimativa inicial. Naturalmente, a mtrica mais
importante se o item foi entregue antes da data limite. A preciso da estimativa
um indicador da eficincia de execuo do sistema. Se as estimativas so conhecidas
por serem imprecisas, a equipe tender a iniciar itens de data fixa em primeiro lugar

g 12.5!

Rendimento

Figura 12.5 Exemplo de um grfico de barra mostrando o rendimento


Figura 12.5 Exemplo de um grfico de barra mostrando o rendimento

para garantir a entrega; isto no o ideal. O desempenho geral em termos de valor e


rendimento pode ser melhorado atravs da melhoria nas estimativas.

Rendimento
Rendimento deve ser reportado como o nmero de itens ou alguma indicao do
seu valor que foram entregues num perodo de tempo determinado, como um ms.
Rendimento deve ser reportado como uma tendncia ao longo do tempo, como mostrado na Figura 12.5. O objetivo melhor-lo continuamente. Rendimento muito
similar mtrica gil velocidade. Ele indica quantas user stories, ou story points,
foram finalizados num perodo de tempo determinado. Se voc no est usando tcnicas de requisitos geis, mas utilizando outras coisas, como itens de especificao
funcional, requisio de mudana, casos de uso, etc., ento reporte esses nmeros.
Em primeira instncia importante ser capaz de reportar o nmero bruto. medida
que a sua equipe amadurecer e tornar-se mais sofisticada, voc ser capaz de reportar
o tamanho relativo, como o nmero total de story points, pontos de funo, ou alguma
outra medida de qualidade. Se a sua organizao muito sofisticada, voc poder
reportar o valor monetrio do trabalho entregue. No perodo da escrita desse livro eu
sabia de apenas uma equipe, na BBC de Londres, que era capaz de reportar o valor em
dlares do trabalho entregue.
Dado de rendimento usado em Kanban com um propsito inteiramente diferente
do que velocidade num ambiente tpico de desenvolvimento gil. Rendimento no

153

154

g 12.6!

Captulo 12 Mtricas e Relatrios de Gerenciamento

Figura 12.6 Exemplo de um grfico de Problemas e Itens de Trabalho Bloqueados

Figura 12.6 Exemplo de um grfico de Problemas e Itens de Trabalho Bloqueados

usado para prever a quantidade de entregas em um intervalo de tempo ou para qualquer compromisso especfico de entrega. Rendimento usado como um indicador
de quo bem o sistema (a equipe e a organizao) est executando e para demonstrar
melhoria contnua. Compromissos so feitos em Kanban para o lead time e as metas de
entrega na data. Rendimento pode ser usado em grandes projetos para indicar o tempo
aproximado para finalizao com um buffering apropriado para variao.

Problemas e Itens de Trabalho Bloqueados


O grfico The Issues and Blocked Work Items mostra um diagrama de fluxo acumulado
de impedimentos reportados sobreposto a um grfico da quantidade de trabalho-em-progresso que se tornaram bloqueados, como mostrados na Figura 12.6. Este grfico
nos d uma indicao de quo boa a organizao em identificar, reportar, e gerenciar
problemas bloqueados e os seus impactos. Se o Desempenho de Entrega na Data
ruim, haver uma evidncia correspondente no grfico mostrando que alguns impedimentos foram descobertos e no resolvidos rpido o suficiente. Este grfico pode ser
usado dia a dia para alertar a gerncia snior dos impedimentos e seus impactos. Ele
pode ser usado tambm como um relatrio de longo prazo para indicar a capacidade
da organizao em resolver impedimentos e manter as coisas fluindo uma medida
da capacidade em gerenciamento e resoluo de problemas.

12.7!

g 12.7!

Eficincia do Fluxo

100%
90%
80%

CRs
Bugs

70%

Combo
60%
50%
40%

30%
20%

10%
0%

Dec

Jan

Feb

Mar

Apr

Figura 12.7 Exemplo de lead time: taxa de tempo atribuda


Figura 12.7 Exemplo de lead time: taxa de tempo atribuda

Eficincia do Fluxo
Um bom indicador Lean de desperdcio no sistema medir o lead time em relao ao
tempo de toque. Na manufatura, tempo de toque se refere ao tempo que um trabalhador gasta realmente tocando um trabalho. Em desenvolvimento de software, isto
muito difcil de medir. No entanto, a maioria dos sistemas de acompanhamento
consegue acompanhar o tempo atribudo (a um indivduo) em relao ao tempo gasto
bloqueando e enfileirando. Portanto, embora reportar a relao do lead time a um
tempo atribudo no nos traga uma indicao precisa do desperdcio no sistema, ela
nos traz uma relao conservadora que mostra o potencial que existe para melhoria,
como na Figura 12.7.
No fique alarmado caso essa relao inicial seja algo em torno de 10:1. Eu participei de muitas conferncias e vi participantes de indstrias diversas, como projeto de
aeronaves e projeto de equipamentos mdicos reportarem relaes similares. Parece
que com trabalho de conhecimento ns somos terrivelmente ineficientes e incapazes
de uma agilidade necessria para tornar uma ideia ou requisio em um produto de
trabalho eficientemente.
A mtrica de eficincia do fluxo no muito til dia a dia, mas, novamente, pode
ser outro indicador de melhoria contnua.

155

156

Captulo 12 Mtricas e Relatrios de Gerenciamento

12.8

Mean

Figura 12.8 Grfico mostrando defeitos por feature

Qualidade Inicial
Defeitos representam custo de oportunidade e afetam o lead time e o rendimento do
sistema Kanban. Faz sentido reportar o nmero de defeitos escapados como um percentual em relao ao WIP total e rendimento. No decorrer do tempo, queremos ver a
taxa de defeito prxima a zero, como mostrado na Figura 12.8.

Carga de Falhas
Carga de falhas acompanha quantos itens de trabalho ns processamos devido baixa
qualidade de itens anteriores quantos itens de trabalho so defeitos de produo ou
novas features que foram requisitadas atravs do servio ao cliente da organizao
devido usabilidade fraca ou falhas em antecipar necessidades do usurio apropriadamente. Idealmente, a carga de falhas deve cair ao longo do tempo. Isto um bom
indicador de que estamos melhorando como um todo na organizao e pensando no
nvel de sistema.

Takeaways
157

Takeaways
Acompanhe WIP com um diagrama de fluxo acumulado para monitorar dia
a dia os limites WIP.
Acompanhe lead time para cada item processado e reporte a mdia e o espectro de anlise para cada classe de servio.
Lead time um indicador da agilidade do negcio.
Acompanhe lead time estimado versus atual para itens de classe de servio
de Data de Entrega Fixa.
Reporte Desempenho de Entrega na Data como um indicador de previsibilidade.
Impedimentos bloqueiam o fluxo e impactam o lead time e o desempenho
de entrega na data; reporte problemas bloqueados e o nmero de itens de
trabalho bloqueados em um diagrama de fluxo acumulado sobrepondo um
grfico de itens bloqueados. Use-o para indicar a capacidade de reportar e
resolver problemas rapidamente.
Eficincia de fluxo a relao do lead time a um tempo atribudo de engenharia.
Ele indica o quanto eficiente a organizao em processar trabalho novo, e
um indicador secundrio da agilidade do negcio. Ele indica tambm o espao
disponvel para melhoria sem a necessidade de mudar mtodos de engenharia.
Relatrios de Qualidade Inicial reportam o nmero de defeitos descobertos
pelos testadores dentro do sistema e indica quanta capacidade est sendo
gasta devido baixa qualidade inicial.
Carga de Falha reporta o percentual de trabalho que gerado devido a
alguma falha do sistema e mostra a capacidade que poderia estar sendo usada
para features novas e de valor agregado.

C aptulo 13

Escalando Kanban

t agora os exemplos e histrias de implementaes Kanban apresentados focaram na manuteno de software pequenas mudanas de sistema feitas com releases para produo rpidos e frequentes.
H muitos sistemas que esto em manuteno, e uma poro significante dos leitores envolvidos em desenvolvimento de software achar
os conselhos e guias teis. Igualmente, h muito mais pessoas de TI
envolvidas em suporte e operao onde sistemas de ticketing para pedidos pequenos de trabalho so tambm comuns; uma abordagem
Kanban ser igualmente til para eles. No entanto, h outros cujo
desenvolvimento de projetos de tamanho significante a norma. Se
voc est lendo isto se perguntando por que e como eu uso Kanban em
grandes projetos e atravs de um portflio de projetos, espero que o
captulo 5 tenha convencido voc que Kanban possibilita mudanas
culturais significantes e positivas. Os benefcios observados com
Kanban so suficientemente desejveis nos desafiando a fazer a seguinte
pergunta, Como devemos fazer Kanban em grandes projetos?
Grandes projetos apresentam desafios considerveis. Muitos requisitos a serem entregues juntos. Sero necessrios alguns meses at que
uma entrega seja realizada. O tamanho da equipe grande. Muitos
trabalhos estaro acontecendo em paralelo. Pedaos significantes de
trabalho podem precisar ser integrados. Por exemplo, documentao
e pacotes de projeto podem precisar ser integrados com o build final
do software antes que um release seja realizado.
159

160

Captulo 13 Escalando Kanban

Como lidar com estes desafios?


A resposta olhar para os primeiros princpios. O primeiro princpio de Kanban
limitar o trabalho-em-progresso e puxar trabalho usando um sistema visual de sinalizao. Alm disso, olharmos para os princpios Lean, princpios geis, e o fluxo de
trabalho e o processo que j esto em uso como nosso ponto inicial. Ento queremos
limitar o WIP, usar controles visuais e de sinalizao, e puxar trabalho apenas quando
h capacidade para se fazer isso; mas tambm queremos pequenas transferncias de
batch, para priorizar por valor, gerenciar risco, realizar progresso com informaes
imperfeitas, construir uma cultura de alta confiana, e responder rapidamente e graciosamente a mudanas que chegam durante o projeto.
Com um projeto grande, como numa iniciativa de manuteno, voc precisar acordar uma cadncia de priorizao para preenchimento da fila de entrada. A regra geral
uma cadncia maior com reunies mais frequentes. Olhe para os princpios novamente. Quais so os custos de transao e coordenao de sentar-se com a equipe de
marketing ou donos do negcio e entrar em acordo nos prximos itens da fila para
desenvolvimento? Do outro lado da cadeia de valor, voc ter muitas integraes ou
pontos de sincronizao convergindo para um release do que apenas um nico ponto
de release; novamente uma maior frequencia melhor. Faa a pergunta, Quem est
envolvido em reunies com pessoas do negcio para demonstrar trabalho recente e
ento integr-lo a fim de que ele se torne um release ready*?
Depois, voc dever entrar em acordo em relao aos limites de WIP; os princpios
para se fazer isso no mudam. Classes de servio continuaro a fazer sentido e a ajud-lo a lidar graciosamente com mudanas durante o projeto.

Requisitos Hierrquicos
Voc precisar definir tambm tipos de item de trabalho para o seu projeto. Muitos
projetos grandes exibem requisitos hierrquicos. No incomum que muitos deles
tenham at trs nveis de hierarquia. Podem existir tambm diferentes tipos de requisitos, como requisitos do cliente que vm dos donos do negcio e requisitos do produto,
provenientes da equipe tcnica, de qualidade ou de arquitetura. Os requisitos devem
ser quebrados em requisitos funcionais e no funcionais ou requisitos de qualidade
do servio. Mesmo com desenvolvimento de software gil, o cliente pode especificar requisitos em termos de estrias de tamanho grande que so quebradas em user
stories e so talvez quebradas para o nvel menor de tarefas ou pequenas unidades
* N. de T.: Termo no traduzido devido sua utilizao mais ampla no idioma original (Ingls) pela comunidade de TI no
Brasil. Traduo: release pronto.

Dissocie Entrega de Valor de Variabilidade do Item de Trabalho

referenciadas como gros de areia. Tambm vi grandes estrias quebradas em estrias


arquiteturais que por sua vez so quebradas em user stories. Feature-driven development
tambm possui trs camadas de requisitos features, conjunto de features (ou atividades), e reas de assunto.
Para equipes adaptando Kanban para projetos maiores fez sentido atribuir tipos de
item de trabalho diferentes para diferentes nveis da hierarquia. Por exemplo, as estrias
grandes so um tipo de item de trabalho, e user stories menores so outro tipo. Em um
projeto mais tradicional, requisitos do cliente so de um tipo, enquanto requisitos do
produto so de outro, e itens de especificao funcional pequenos so o terceiro item.
Tipicamente, as equipes tm escolhido acompanhar os dois nveis superiores de
um quadro Kanban. Eu pessoalmente no vi uma equipe ou projeto no qual se tentou
acompanhar trs nveis com Kanban. Algumas ferramentas eletrnicas do suporte
a requisitos hierrquicos que permitem ao usurio exibir ou omitir nveis diferentes,
apresentando apenas dois nveis de cada vez.
Usualmente h um terceiro nvel mais baixo, como tarefas, em um projeto gil; as
tarefas no so acompanhadas no mural de cartes do projeto ou dentro de um sistema
kanban no nvel da equipe. Desenvolvedores individuais podem escolher acompanhar
tarefas, ou talvez equipes pequenas e cross-functional possam escolher acompanhar
tarefas localmente, mas fora do quadro do projeto e fora da viso dos gerentes e parceiros da cadeia de valor; isto no motivado pela necessidade de esconder informao.
Simplesmente o nvel mais baixo de atividade no interessante da perspectiva da
cadeia de valor e nvel de desempenho. O nvel mais baixo frequentemente focado
no esforo e atividades em vez do valor para o cliente e funcionalidade.
Enquanto escrevia esse livro, uma variao do Kanban para uso pessoal estava surgindo, liderado por Jim Benson e outros. Kanban Pessoal usado em casa e no escritrio a nvel individual, ou com pequenos grupos de duas ou trs pessoas que esto
colaborando ativamente no mesmo conjunto de itens de trabalho. impossvel saber
no tempo da escrita desse livro se Kanban Pessoal ser assimilado para dentro do corpo
do conhecimento ou emergir como uma disciplina de valor prprio.

Dissocie Entrega de Valor de Variabilidade do Item de Trabalho


A ideia que surgiu na maioria das equipes Kanban acompanhando os dois nveis mais
altos de requisitos que o nvel mais alto de requisitos, os requisitos menos granulares,
geralmente descreviam alguma unidade atmica de valor para o mercado ou cliente.
Essas user stories grandes ou requisitos do cliente eram frequentemente escritas em
um nvel no qual fazia sentido um release para o mercado. O produto j estava em

161

162

Captulo 13 Escalando Kanban

manuteno e essas requisies deviam ser processadas e released individualmente.


Algumas vezes a comunidade Kanban refere-se a este nvel de requisitos como minimal marketable feature (ou MMF). H confuso em relao a esse conceito, visto que
MMF foi definido por Denne e Cleland-Liang no livro Software by Numbers, e sua
definio no totalmente aderente a essa. Eu prefiro uma definio de minimum
marketable release (MMR) que descreve um conjunto de features que so coerentes
como um conjunto para o cliente e teis o bastante para justificar os custos de entrega.
No faz sentido tratar MMR como um item nico que flui atravs do nosso sistema
kanban. Um MMR feito de muitos itens de trabalho. MMR faz sentido a partir de uma
perspectiva do custo de transao do release, e no a partir da perspectiva do fluxo. Em
alguns casos pode fazer sentido o release de uma pequena feature diferenciada de valor
alto. Por outro lado, como muitos descobriram, o primeiro MMF sempre grande
porque o primeiro release de um novo sistema deve incluir todas as capacidades essenciais para entrar no mercado e toda a infra-estrutura para suport-lo. Podem existir
dois ou trs pedidos de diferentes magnitudes em relao ao tamanho dos MMFs (ou
MMRs). Um tipo de item de trabalho com instncias que variam no tamanho acima
de mil vezes ser problemtico.
Sistemas kanban no prezam por uma variao to grande no tamanho. Isso requer
buffers grandes e que o limite do WIP seja excedido para amenizar o fluxo; sem os
buffers os sistemas sofreriam grandes variaes no lead time. Buffers grandes e mais
WIP significa lead times maiores e perda da agilidade no negcio. A alternativa pior!
Se no usarmos buffer para a variabilidade no tamanho, haver grandes flutuaes
no lead time. Como resultado, impossvel oferecer uma meta de lead time abaixo do
acordo de nvel de servio que possa ser alcanada com consistncia. O resultado ser
uma previsibilidade ruim e perda de confiana no sistema. Projetar um sistema kanban
em torno do conceito de MMF como levar a uma perda na agilidade do negcio, e/
ou uma perda da previsibilidade, uma perda da confiana entre TI e o negcio, e uma
insatisfao geral com a abordagem Kanban.
No entanto, usar Minimal Marketable Release (MMR) como um gatilho para uma
entrega, em conjunto com tipos de item de trabalho menores e mais granulares, minimizar custos e maximizar a satisfao com o release.
Equipes podem se adaptar a esse desafio focando em tcnicas de anlise que produzem um nvel mais baixo de requisitos, como user stories ou uma especificao funcional. Isso vai gerar uma variao de tamanho menor e mais granular. Um tamanho ideal
seria algo num intervalo de meio dia a quatro dias de esforo de engenharia.
Num projeto maior estabelecemos que cada item de trabalho grande, chamado
Requisito, e acompanhado com tickets verdes, se quebraria numa mdia de 21
Features menores, acompanhadas com tickets amarelos. Embora as features fossem
escritas de uma maneira orientada ao usurio e valor, elas eram analisadas para serem

Paredes de Carto em Duas Camadas

menores e similares no tamanho. Se ele fosse um projeto gil, esses nveis teriam sido
Epic, acompanhados em verde, e User Story, acompanhados em amarelo.
Os itens menores, mais granulares, possibilitam fluxo e previsibilidade do rendimento e lead time, enquanto que itens menos granulares numa camada mais alta do
quadro nos permite controlar o nmero de requisitos releasable, marketable em progresso a qualquer tempo.
Adotando uma abordagem de duas camadas, ns dissociamos a entrega de valor da
variabilidade no tamanho e esforo necessrios para entregar esse valor.
Faz sentido atribuir limites de WIP nos dois nveis. Com muitos projetos verificamos
que fazia sentido atribuir uma equipe pequena e cross-funcional para cada requisito de
alto nvel. Estas equipes puxariam itens menores e mais granulares para o seu requisito
de alto nvel fluindo-os atravs do quadro sem intervenes at que o requisito fosse
finalizado e estivesse pronto para integrao ou entrega; ento a equipe puxaria outro
requisito menos granular. Haveria tambm oportunidade de redistribuir membros da
equipe, adicionando ou liberando membros da equipe dependendo do tamanho do
prximo item puxado.

Paredes de Carto em Duas Camadas


As primeiras equipes usando Kanban em projetos grandes adotaram um estilo de duas
camadas para a parede de carto, como apresentado na Figura 13.1.
Nessa foto, os requisitos menos granulares so apresentados com tickets verdes. Eles
fluem da esquerda para a direita atravs de um conjunto de estados, nomeados, backlog,
proposto (anlise), ativo (projeto e desenvolvimento), resolvido (testando) e fechado.
Os requisitos ativos so apresentados no topo na parte central da foto. Eles, por sua
vez, so quebrados em vrias features menores, apresentadas com tickets amarelos. As
features fluem atravs do prprio conjunto de estados, nomeados, proposto (anlise),
ativo (projeto e cdigo), resolvido (testando) e pronto. Os estados que as features fluem
so similares aos estados dos requisitos de alto nvel, mas eles no precisam ser similares; voc pode modelar isso da maneira que achar mais adequada; meu conselho
modelar o que voc faz agora; evite mudar o processo.
Os tickets amarelos so rastreados de volta aos seus pais identificando-os com os
nmeros IDs dos seus pais.
Num exemplo como este, possvel limitar o WIP nos dois nveis hierrquicos, mas
os tickets amarelos so todos agrupados em um pool. No tenho evidncia de campo
suficiente para saber se essa ou no uma boa estratgia. O que eu sei que ela no se
adequou a essa equipe.

163

164

Captulo 13 Escalando Kanban

Figura 13.1 Fotografia de um quadro de duas camadas

Introduzindo Raias
Fazer a correspondncia dos tickets amarelos mais granulares com os seus pais menos
granulares importante. Parece fazer sentido limitar o WIP no nvel mais baixo dentro
de uma equipe cross-functional. Para facilitar essa abordagem, algumas equipes inovaram o sistema de parede de carto e introduziram raias horizontais.
Na figura 13.2, o requisitos de alto nvel, apresentados com tickets verdes, fluem
atravs do mesmo conjunto de estados nomeados, backlog, proposto, ativo, resolvido
e fechado. No entanto, a parte central foi redesenhada comparando a Figura 13.1. Os
requisitos menos granulares em verde esto verticalmente empilhados esquerda. Para
cada um destes tickets verdes prolonga-se uma raia dividida no mesmo conjunto de
estados para as features amarelas mais granulares. O nmero de raias agora o limite
de WIP para os requisitos customer-marketable menos granulares, enquanto que os
limites para as features mais granulares podem agora ser atribudos para cada raia se as
equipes individuais escolherem fazer assim. A coluna imediatamente direita da pilha
vertical de requisitos verdes contm os nomes dos membros permanentes da equipe. Os
tickets laranja menores anexados aos tickets amarelos, efetivamente contm os nomes
dos recursos especialistas flutuantes, como user-experience designers e arquitetos de
banco de dados.
A raia varivel da parede de carto significa que agora estamos gerenciando o WIP
de customer-marketable verticalmente, enquanto estamos gerenciando o WIP das

Incorporando Classes de Servio

Figura 13.2 Fotografia de um quadro de duas camadas com raias

features de baixa variabilidade horizontalmente. Este formato provou ser muito popular e tornou-se tpico.

Abordagem Alternativa para Variabilidade no Tamanho


Outra abordagem para lidar com variabilidade no tamanho criar tipos de trabalho
diferentes para tamanhos diferentes de itens. Raias podem ento ser estabelecidas para
itens de cada tamanho/tipo. Limites de WIP devem ser estabelecidos para cada coluna
em cada raia, i.e., cada caixa na parede de carto. Devido baixa variabilidade atravs
de cada raia (como os itens so similares no tamanho), cada raia deve fluir relativamente suave. Esta uma maneira de lidar com variabilidade sem recorrer a um sistema
de duas camadas.

Incorporando Classes de Servio


Os dois mtodos mais bvios para visualmente diferenciar cartes na parede so usar
cores e raias. No entanto, em projetos grandes, cada ticket tipicamente tem trs atributos que precisamos comunicar: tipo do item de trabalho, nvel na hierarquia, e classe de
servio. importante notar que, no exemplo (Figura 13.2), a escolha de se ter diferentes

165

166

Captulo 13 Escalando Kanban

tipos de item de trabalho na hierarquia e ento usar tanto cores como raias para desi
gnar o nvel na hierarquia significa que a hierarquia est sendo sobrecarregada com
dois mtodos de visualizao.
Se voc precisa comunicar classe de servio alm do tipo e nvel de hierarquia do
requisito, pode fazer sentido usar cores para as classes de servio. Se os tipos so usados
para propsitos diferentes do nvel de hierarquia, por exemplo, para mostrar erros ou
defeitos, ou valor agregado versus carga de falha, voc pode escolher outra abordagem,
talvez introduzindo um cone ou um adesivo anexado ao carto para identificar o tipo;
ou voc pode preferir usar cores para os tipos e um cone ou adesivo para classes de
servio, e.g., uma estrela prata para uma requisio de expedio.
O que pode ser mais fcil, como vimos evoluir na Corbis, o uso de cores para diversos propsitos, como nvel na hierarquia, tipo e classe de servio. Esta abordagem,
na qual as cores designam claramente qualquer atributo, aceitvel para os usurios de
sistema Kanban e muito eficiente em termos de opes disponveis para visualizao.

Integrao de Sistemas
Em alguns projetos grandes, voc pode ter equipes mltiplas trabalhando em componentes diferentes de um sistema que precisa ser integrado posteriormente. Alguns destes
componentes podem envolver hardware ou firmware, e pode no ser passvel a tcnicas
modernas de integrao contnua. Quando voc possui esses tipos de componentes que
precisam ser integrados, voc precisa determinar um ponto de integrao baseado numa
atividade de planejamento de alto nvel. Este ponto pode ento ser tratado como uma
data fixa para entrega destes componentes dependentes. Isto permite que cada equipe v
em frente independentemente com o seu sistema kanban, mas tambm permite coordenar a entrega de itens dependentes quando eles so necessrios. Entrega em atraso de
um item dependente causa grande atraso para o projeto como um todo. Este alto custo
de atraso justifica trat-lo como um item de classe de servio de data fixa.

Gerenciando Recursos Compartilhados


comum em grandes projetos e atravs de portfolios de projetos o compartilhamento
de recursos especialistas; por exemplo, arquitetos de software, arquitetos e administradores de banco de dados, user-experience testing, user-experience design, e auditor
de segurana de software. H trs mtodos estabelecidos para lidar com estes recursos
compartilhados em Kanban.

Gerenciando Recursos Compartilhados

No primeiro mtodo alguns dos itens de trabalho tm tickets laranja menores anexados a eles. Estes tickets menores mostram o nome do recurso compartilhado requerido,
como Sandy, a arquiteta de dados da empresa. No nvel menor de intruso, esta ao
simples de visualizar o trabalho de recursos compartilhados frequentemente suficiente para coordenar a carga de trabalho individual. Se muitos tickets comearem a
aparecer com o mesmo nome, isso pode trazer tona questes sobre como esta pessoa
est gerenciando o trabalho em mltiplas coisas ao mesmo tempo. Isto deve ser suficiente para facilitar uma discusso na mudana da poltica todo o trabalho precisa
ser visto por aquela pessoa? ou escal-la para um prximo nvel.
O prximo nvel reconhecer que recursos compartilhados no esto instantaneamente disponveis, e visualizar isto marcando os itens que precisam de ateno de um
recurso compartilhado (um ticket laranja), como bloqueado at uma pessoa estar efetivamente trabalhando nele. Isto tem o efeito de invocar o responsvel do gerenciamento
e resoluo de problemas para resolver a disponibilidade do recurso compartilhado.
Isto tambm tem o efeito de mostrar gerncia se a disponibilidade do recurso um
problema e um gargalo potencial.
O nvel mais alto de gerenciamento de um recurso compartilhado dar ao recurso
seu prprio sistema kanban. Por exemplo, a arquiteta de dados da empresa, o user experience, o auditor de segurana de software, e assim por diante, podem ter seu prprio
sistema kanban. Cada equipe ou recurso analisaria independentemente sua demanda e
atribuiria tipos de item de trabalho baseados na fonte da requisio, e classe de servio
baseados na prioridade e resposta requisitadas. A demanda seria analisada e polticas
para alocao da capacidade atribudas.
Neste nvel, o que emergiu uma arquitetura orientada a servios para desenvolvimento do software. Cada grupo dentro da empresa oferece seu prprio conjunto de
servios que so exibidos como nveis de acordo de servio para diferentes classes de
servio e tipos de item de trabalho. Clientes destes recursos compartilhados submetem
requisies de trabalho para o seu backlog; estas requisies so enfileiradas e selecionadas para processamento, como descrito neste livro. Se requisies de um determinado cliente no so processadas de maneira suficientemente rpida, isto pode abrir
uma discusso sobre se o sistema est projetado corretamente ou no, e se as polticas
em relao capacidade de alocao e classes de servio precisam ou no ser alteradas.
Isto pode inclusive fornecer evidncias para realinhamento ou aumento de pessoal.

167

168

Captulo 13 Escalando Kanban

Takeaways
Projetos grandes podem seguir os princpios centrais de Kanban.
Limites de WIP, cadncia de priorizao, cadncia de entrega, e classes de servio
so tcnicas vlidas para projetos maiores.
Projetos maiores tendem a ter requisitos hierrquicos; estes nveis de hierarquia
devem ser modelados com tipos de item de trabalho.
Tipicamente, as equipes acompanham os dois itens mais altos de requisitos da
hierarquia na parede de carto e limitam o WIP para um ou os dois nveis.
O nvel mais alto de requisitos tipicamente modela requisitos customer-marketable
que se tornam unidades atmicas que podem ser released individualmente.
O segundo nvel de requisitos tipicamente escrito numa linguagem orientada ao
cliente/usurio e analisado de maneira que os requisitos sejam mais granulares e
tenham tamanhos similares.
O segundo nvel de requisitos mais granulares facilita o fluxo reduzindo
variabilidade no sistema puxado kanban.
Ser necessria uma parede de carto em duas camadas pra visualizao dos dois
nveis de requisitos a serem acompanhados.
A utilizao de raias tornou-se uma tcnica popular para mostrar hierarquia e
facilitar a limitao do WIP.
O limite de WIP dos requisitos menos granulares limitado pelo nmero de raias.
O limite de WIP dos requisitos mais granulares pode ser limitado para cada raia,
se desejado.
Tipicamente, pequenas equipes cross-functional so atribudas para cada raia.
Demanda de recurso compartilhado pode ser visualizada com adesivos menores
anexados aos itens de trabalho.
A disponibilidade no instantnea de recursos compartilhados pode ser destacada
com tickets de bloqueio (rosa, por exemplo) anexados ao ticket original do item
de trabalho.
Recursos compartilhados podem desenvolver seus sistemas kanban prprios.
Uma rede de sistemas kanban para recursos compartilhados atravs de um portfolio
de projetos pode ser vista como uma arquitetura de desenvolvimento de software
orientada a servios.

C aptulo 14

Reviso Operacional
Antes da Reunio
So 7:30 a.m. da segunda sexta-feira de Maro de 2007. Cheguei cedo
no trabalho porque nesta manh aconteceria nossa quarta reviso
operacional mensal do departamento. Estou com Rick Garber, o
gerente do nosso grupo de engenharia de processo de software. Rick
tem a responsabilidade de coordenar a agenda e a reunio de reviso
operacional. Ele est ocupado imprimindo a apresentao que contm aproximadamente 70 slides PowerPoint para a apresentao de
hoje. Depois que a impresso estava pronta seguimos para o Harbor
Club no centro da cidade de Seatlle com uma caixa com 100 apresentaes. A reviso operacional estava agendada para comear s
8:30a.m., mas o buffet do caf da manh foi servido s 8:00. A reunio
foi planejada para 80 pessoas. O convite inclua todos da minha organizao e todos os meus colegas da organizao de Erik Arnold. No
entanto, com algumas pessoas na ndia, ou em outras partes do EUA,
e sempre algumas que no podem comparecer por motivos pessoais,
ns alcanamos aproximadamente 80 pessoas.
O convite tambm inclua meu chefe, o CIO da Corbis, e outros
gerentes seniores, e nossos parceiros na cadeia de valor. O grupo externo que compareceu em maior nmero foi a equipe Operaes de
Rede e Sistemas liderada pelo meu colega Peter Tutak. Eles eram responsveis por recuperar falhas de sistemas em produo, ento eles
169

170

Captulo 14 Reviso Operacional

eram os mais impactados pelas nossas falhas. Eles tambm sentiam o maior impacto
quando fazamos novos releases para produo. Ento, evidentemente, eles tinham
muito a ganhar participando ativamente.
O grupo comeou a chegar a tempo para o caf da manh. A sala era no ltimo
andar de uma torre de Seattle e nos proporcionava uma vista linda da cidade, o porto,
os piers, a Baa Elliott. A sala estava cheia de mesas redondas, com seis a oito pessoas
em cada uma delas. Ns tnhamos uma tela de projeo e um plpito em uma das extremidades. Rick gerenciou a agenda com preciso. Cada apresentador tinha em torno
de oito minutos para os seus quatro ou cinco slides. Havia um buffer de tempo para
permitir a variabilidade devido aos questionamentos e discusses. Eu comecei minha
apresentao prontamente com algumas declaraes. Eu pedi a todos que voltassem ao
final do ms de Janeiro e ao que eles estavam fazendo naquele perodo. Lembrei a todos
que estvamos ali para revisar o desempenho da organizao para o ms de Fevereiro.
Rick pegou uma bela imagem da empresa nos arquivos para simbolizar um tema para o
ms e para ajudar a sacudir a memria, lembrando a todos uma atividade chave do ms.

Defina um Tom de Negcio desde o Incio


Passei a vez para Rick, que resumiu os itens de ao gerenciais do ultimo ms e forneceu uma atualizao do status. Depois introduzimos nossa analista financeira, que
apresentou um resumo do desempenho da companhia no ms o motivo para o adiamento at a segunda sexta-feira do ms subsequente era para que tivssemos dados
financeiros aps o fechamento dos livros do ms anterior. Ela resumiu os detalhes
do oramento para o meu centro de custo e para o de Erick. Verificamos o planejado
versus o realizado para as reas com maior oramento, como tambm as metas de
headcount*. Discutimos posies em aberto e incentivamos os membros das equipes a
submeterem candidatos para essas posies. Saindo dessa primeira parte, todos os participantes sabiam o quo bem a companhia estava e o quo bem o grupo de engenharia
de software estava gerenciando o oramento e, portanto, quanto espao disponvel ns
tnhamos para comprar itens como monitores de tela plana e novos computadores. O
propsito de lidar com nmeros financeiros lembrar a todos da equipe que estamos
administrando um negcio; no estamos apenas mostrando zeros e uns como uma
brincadeira com um grupo de amigos.

* N. de T.: Termo no traduzido devido sua utilizao mais ampla no idioma original (Ingls) pela comunidade de TI no
Brasil. Traduo: nmero de funcionrios.

Agenda Principal

Convide os Participantes a Sair da Plateia e Agregar Valor


O prximo orador um convidado um vice-presidente de outra parte da companhia. Eu tive a brilhante ideia de que se ns queramos que nossos parceiros da cadeia
de valor tivessem interesse em ns, devamos mostrar interesse neles e convid-los a
apresentar. Oferecemos 15 minutos ao nosso convidado, que os usou. Ento ouvimos
uma apresentao da operao de vendas, a parte do negcio que preenchia os pedidos
do cliente e garantia a entrega do produto. Embora alguns negcios da Corbis fossem
realizados pela web e preenchidos eletronicamente, nem tudo que a firma oferecia era
entregue como um download; um departamento inteiro preenchia pedidos mais complexos para profissionais de agncias de publicidade e firmas de mdia. Meu colega,
Erick Arnold, teve a brilhante ideia de solicitar ao convidado o patrocnio do caf da
manh para manter nossos custos sob controle; isso funcionou tambm. Ao longo dos
meses seguintes nossa equipe aprendeu muitos aspectos do negcio e os lderes seniores da companhia aprenderam o que fazamos e como fazamos, e como era difcil lidar
com os nossos problemas. Nove meses depois, executivos falavam abertamente sobre
como a equipe de TI era bem gerenciada e como a sua unidade de negcio deveria
seguir o nosso exemplo.

Agenda Principal
Quando nosso convidado finalizou sua apresentao, ns partimos para a parte principal da nossa reunio. Cada gerente tinha oito minutos para uma apresentao do
desempenho do seu departamento. Fizemos isso com algumas atualizaes de projetos
especficos do nosso escritrio de gerenciamento de programa. Cada um dos gerentes
imediatos levantou-se e gastou cinco minutos apresentando rapidamente suas mtricas.
Geralmente eles seguiram o formato apresentado no captulo 12: eles apresentavam
informao sobre taxa de defeito, lead time, rendimento, eficincia do valor agregado,
e, ocasionalmente, um relatrio especfico que entrava em algum aspecto do nosso
processo para o qual eles precisavam de mais informao. Ento eles fizeram perguntas,
comentrios, e sugestes por alguns minutos.
Esta quarta reunio mensal de Reviso Operacional, em Maro de 2007 foi particularmente interessante. A primeira Reviso Operacional foi em Dezembro; todos
vieram, uma participao de quase 100 por cento. Muitas curiosidades e depois muitos
comentrios como, Eu nunca vi transparncia como essa na minha carreira, e Isto
foi interessante. O feedback mais til foi, Na prxima vez podemos ter um buffet
quente em vez de frio? Ento inclumos um caf da manh quente. No segundo ms
as pessoas disseram, Sim, outro ms bom. Algo interessante! Obrigada pelo caf da

171

172

Captulo 14 Reviso Operacional

manh quente! No terceiro ms alguns dos desenvolvedores perguntaram, Porque eu


preciso acordar to cedo? e Isso um bom uso do meu tempo?
No quarto ms aconteceu de revermos um problema significante. A companhia
tinha adquirido um negcio na Austrlia. Foi solicitado ao departamento de TI desligar todos os sistemas de TI da subsidiria australiana e migrar todos os 50 usurios
para os sistemas da Corbis. A solicitao tinha uma data arbitrria, mas era urgente.
Esta data baseou-se numa economia de escala estilo de reduo de custos que tinha
justificado parte do preo da aquisio, ento havia um custo de atraso envolvido. A
solicitao chegou com um nico item na nossa fila de manuteno. Ela era grande o
bastante para justificar 10 tickets, mas ns a tratamos como sendo apenas um. O efeito
de um item mal dimensionado como esse entrando num sistema kanban bem conhecido na engenharia industrial. Ele obstrui o sistema e estende o lead time para tudo o
que vem atrs dele; e isso aconteceu conosco. O lead time pulou, de uma mdia de 30
para 55 dias. A teoria das filas tambm nos diz que reduzir o backlog quando ele est
completamente preenchido leva um tempo grande. Ns descobrimos que gastaramos
cinco meses para recuperar a meta de lead time.
Alm disso, ns tnhamos um release que requisitava uma correo de emergncia.
De repente, a sala estava iluminada com perguntas, comentrios, e debate. Depois
de trs meses de tdio e bons dados, ns tnhamos uma histria para contar. As pessoas
estavam surpresas que ns (a gerncia) estvamos dispostos a falar abertamente sobre
o problema e o que fazer sobre ele, e que a Reviso Operacional no era apenas apresentar o quanto ramos bons, apresentar apenas os dados bons. Ningum questionou
novamente porque fazamos a reunio mensalmente.
A reunio terminou com Rick resumindo os itens de ao gerencial das discusses
ocorridas pela manh e agradecendo a todos por terem comparecido. Era 10:30 e hora
de voltar ao escritrio.

Pedra Angular para uma Transio Lean


H muitas coisas importantes a serem compreendidas sobre Reviso Operacional.
Primeiramente, acredito que Reviso Operacional a pedra angular para uma transio Lean e a implementao do mtodo Kanban. Ela uma retrospectiva objetiva,
orientada aos dados do desempenho da organizao. Ela est acima e alm de qualquer
projeto e ela define uma expectativa de gerenciamento quantitativa objetiva e orientada a dados mais do que um gerenciamento qualitativo subjetivo que mais utilizado
em um projeto gil com retrospectiva de iterao. Reviso operacional fornece um
feedback continuo que permite crescimento da maturidade organizacional e melhoria

Cadncia Apropriada

contnua do nvel da organizao. Acredito verdadeiramente que ela essencial para a


transio com sucesso para uma escala de negcio Lean (ou gil).

Cadncia Apropriada
Tambm acredito que a Reviso Operacional deve ser mensal. Uma frequncia maior
pode ser onerosa para coleta de dados, e o tempo envolvido para a reunio significa
que h um desejo de no faz-la frequentemente. Fazer com que a reunio dure duas
horas um desafio. Se ela no fosse uma reunio orientada a dados, repleta de grficos e relatrios, isso no seria possvel. Uma reunio subjetiva de escala no pode ser
finalizada em duas horas. Uma retrospectiva de projeto tpica leva mais de duas horas,
ento imagine tentar realizar uma retrospectiva de toda uma organizao e complet-la
em duas horas usando um estilo de anlise delta. Parte do segredo de manter a durao
curta da reunio realiz-la como base em dados objetivos; manter a agenda apertada
e gerenci-la durante a reunio.
Pode haver uma tendncia de realizar revises operacionais menos frequentemente;
trimestralmente mais comum. Minha experincia com revises operacionais trimestrais so do meu tempo na diviso PCS da Motorola. Minha observao em relao a
essas reunies que elas eram sesses de reportagem e reviso da gerncia superior, e
no sesses organizacionais projetadas para orientar melhoria contnua e maturidade
organizacional. Uma frequncia trimestral pouco para verdadeiramente conduzir um
programa de melhoria. Os dados tm frequentemente quatro meses no momento da
reviso trimestral. Um trimestre um grande espao de tempo para ser revisado numa
nica reunio, dessa maneira a reviso tende a ser superficial. Relatrios e mtricas
tendem a serem indicadores de resultado e focados na reportagem de desempenho em
relao meta dos lderes seniores.
Reunies trimestrais tornam-se atraentes porque elas parecem ser mais eficientes
apenas uma reunio de duas horas a cada trs meses do que mensalmente. Elas tambm
custam menos numa base anual apenas quatro reunies em vez de 12. Depois que
eu deixei a Corbis no incio de 2008, meu antigo chefe reduziu a cadncia da reviso
operacional para trimestral para reduzir custos. Depois de trs trimestres, e com a sada
desse chefe, a nova liderana questionou o valor das reunies e decidiu cancel-las.
Dentro de poucos meses o desempenho da organizao desvalorizou consideravelmente, e o nvel de maturidade da organizao retraiu de uma equivalncia ao Nvel 4
do Modelo CMMI para o Nvel 2 do Modelo CMMI, de Gerenciado Quantitativamente
para meramente Gerenciado.

173

174

Captulo 14 Reviso Operacional

Podemos tirar vrias conclusoes disso. A perda de um feedback contnuo reduziu


as oportunidades para reflexo e adaptao que poderiam levar a melhorias. Eliminar
uma reunio focada numa reviso objetiva de desempenho da organizao d a entender que a liderana no se preocupa com o desempenho. O resultado foi um retrocesso
significante na maturidade da organizao e no desempenho em termos de previsibilidade, qualidade, lead time, e rendimento.

Demonstrando o Valor dos Gerentes


A reviso operacional tambm mostra s pessoas o que os gerentes fazem e como o
gerenciamento pode agregar valor s suas vidas. Ela tambm ajuda a treinar a fora de
trabalho a pensar como gerentes, e a entender em que momento realizar intervenes e
quando recuar e deixar a equipe se auto-organizar e resolver seus prprios problemas.
Revises operacionais ajudam a desenvolver o respeito entre o conhecimento individual dos trabalhadores e seus gerentes e entre os diferentes nveis de gerenciamento.
Desenvolver o respeito constri confiana, estimula a colaborao, e desenvolve o capital social da organizao.

Foco Organizacional Fomenta Kaizen


Enquanto retrospectivas de projetos individuais so sempre teis, uma reviso operacional de toda a organizao fomenta a institucionalizao de mudanas, melhorias,
e processos. Ela estimula a propagao viral de melhorias atravs de uma organizao
criando uma pequena rivalidade entre projetos e equipes que motiva a todos melhorar
o seu desempenho. Equipes querem demonstrar como elas podem ajudar a organizao com uma melhor previsibilidade, mais rendimento, lead times menores, custos
menores, e maior qualidade.

Um Exemplo Anterior
Eu no inventei revises operacionais. Elas so muito comuns em muitas empresas
grandes. No entanto, eu aprendi como conduzi-las de uma maneira objetiva para toda
a unidade de negcio quando eu trabalhava na Sprint PCS em 2001. Meu chefe, o
Vice Presidente e Gerente Geral da sprintpcs.com, as instituiu por vrios motivos. Ele
queria desenvolver a maturidade da sua organizao uma unidade de negcio de 350
pessoas responsvel pelo web site, por todo o e-commerce, e o atendimento online aos
clientes do negcio de telefonia celular da Sprint. Ns fazamos reviso operacional

Takeaways
175

na sprintpcs.com toda terceira sexta-feira do ms s 2 p.m. Ela durava duas horas e


agrupava aproximadamente 70 pessoas seniores e gerentes da unidade de negcio,
mais o diretor ou convidados do nvel da gerncia snior dos nossos parceiros da
cadeia de valor. Lderes seniores, incluindo o Chefe do Escritrio de Marketing e o
VP do Planejamento Estratgico tambm eram participantes regulares. O formato era
muito similar ao da Corbis. Ela era inteiramente orientada a dados objetivos. Cada
gerente apresentava seus prprios dados. A reunio comeava primeiramente com os
dados financeiros. A agenda era planejada e gerenciada firmemente. Depois da reunio,
todos iam para casa mais cedo na sexta-feira. A reunio acontecia fora da empresa,
num campus local de uma faculdade. Enquanto a sprintpcs.com lutou com tcnicas de
desenvolvimento de software gil, a reviso operacional era um elemento chave para o
desenvolvimento da maturidade organizacional e melhoria da governana da organizao. Ela mostrou s pessoas que os gerentes estavam fazendo a diferena e sabiam como
gerenciar, e ela deu s pessoas e aos gerentes da linha de frente uma chance de mostrar
aos lderes seniores como elas podiam ajudar e onde eles precisavam de intervenes
para verdadeiramente fazer a diferena.
Dado duas experincias dentro de um perodo de quatro anos atravs da ltima
dcada, tornei-me convicto de que reviso operacional uma parte crtica para uma
transio com sucesso para Lean ou Agilidade e um componente vital para o desenvolvimento da maturidade organizacional.

176

Captulo 14 Reviso Operacional

Takeaways
Revises operacionais devem ser para toda a organizao.
Revises operacionais devem ter o foco em dados objetivos.
Cada departamento deve reportar seus dados.
As apresentaes devem ser mantidas curtas e devem tipicamente relatar
mtricas e indicadores similares queles discutidos no captulo 12.
Lidar com informao financeira ratifica que a engenharia de software
parte de um negcio maior, e que uma boa governana importante.
Uma cadncia mensal para a reviso operacional adequada. Uma frequencia maior onerosa em relao ao tempo gasto e para a coleta e preparao
dos dados. Uma frequencia menor tende a reduzir o valor e minar a natureza
da reunio.
As reunies devem ser mantidas curtas; tipicamente duas horas.
Revises operacionais devem ser utilizadas para fornecer um feedback continuo e orientar melhoria continua na empresa ou no nvel da unidade de
negcio.
Revises operacionais mostram aos indivduos como o gerenciamento pode
agregar valor s suas vidas e o que efetivamente os gerentes fazem.
Revises operacionais efetivas constroem confiana mtua entre os gerentes
e os trabalhadores.
Stakeholders externos que participam das revises operacionais tm a oportunidade de ver como a engenharia de software e o grupo de TI funcionam
e entender seus problemas e desafios; isto fomenta confiana e colaborao.
Revises operacionais devem analisar dados ruins e problemas da mesma
maneira que devem gozar o sucesso e exaltar as virtudes das equipes com
bons resultados.
Realizar as reunies fora do escritrio ajuda a manter o foco dos participantes.
Fornecer alimentao estimula o comparecimento.
O envolvimento de lderes seniores comunica que a organizao considera
seriamente o desempenho e melhoria contnua da organizao-

Takeaways
177

Atribuir um interesse srio ao desempenho, melhoria continua, e gerenciamento quantitativo vital para o desenvolvimento de uma cultura kaizen
entre todos os trabalhadores.
Revises operacionais tm mostrado que lidam diretamente com os nveis
de crescimento da maturidade organizacional.
Sugestes de melhoria devem ser capturadas como itens de ao gerenciais e
devem ter seu progresso revisado no incio das reunies subsequentes.
Gerentes devem ter responsabilidade e devem demonstrar que esto fazendo
o acompanhamento das sugestes.

C aptulo 15

Empreendendo uma
Iniciativa de
Mudana Kanban

ar incio ao uso de Kanban no uma iniciativa comum de


processo que voc pode ter empreendido no passado. importante estabelecer uma base para um sucesso de longo prazo. Para fazer
isso, necessrio entender os objetivos por detrs do uso da abordagem Kanban para mudana. Intitulei esse livro, Mudana
Evolucionria de Sucesso para o Seu Negcio de Tecnologia. Fiz isso
para destacar o ponto que o principal motivo para adotar Kanban
gerenciamento de mudana; tudo mais secundrio.

Mudana Cultural em vez de uma


Iniciativa de Mudana Gerenciada
O captulo 5 descreve como Kanban aperfeioa o processo existente
atravs de uma srie de mudanas incrementais e evolucionrias.
Esse processo de aperfeioar o que j existe leva a uma melhoria na
maturidade organizacional e eventualmente possibilita que sejam
introduzidas mudanas maiores e mais estratgicas. Devido a isto,
improvvel que voc direcionar uma adoo de Kanban atravs de
uma iniciativa de transio planejada e um programa de treinamento
prescrito. Esta uma mudana significativa em relao a como uma
transio gil tpica planejada e gerenciada. De fato, a abordagem
de gerenciamento de mudana para a introduo de mtodos geis
179

180

Captulo 15 Empreendendo uma Iniciativa de Mudana Kanban

bastante parecida com as iniciativas de gerenciamento de mudana anteriores, como


aquelas baseadas no CMMI ou na introduo de mtodos como o Rational Unified
Process. A iniciativa de mudana tende a ser uma iniciativa com o estilo grande planejamento antecipado. H um tipo especfico de mudana gerenciada na qual o processo
atual primeiramente definido e avaliado, seguindo-se de uma seleo de um mtodo
gil a partir de um livro. Aps essa etapa h um empenho no planejamento de treinamento e formao para se fazer a transio da equipe ou organizao do que eles fazem
no momento atual para o novo processo gil definido. Uma vez que isto finalizado
e o novo processo est em execuo, outra avaliao conduzida para demonstrar a
adoo dos novos mtodos. Esta no a abordagem com Kanban. Com Kanban no
h uma iniciativa planejada, no h avaliaes, e no h uma declarao no final que
diga, Agora ns somos geis! Idealmente no h final. Ao invs disso, a liderana
conduz um processo contnuo encorajando mudanas incrementais. Como resultado,
h uma transformao gradual atravs de uma cultura Kaizen.
verdade que algum treinamento ser necessrio. No entanto, mais do que desperdiar muito tempo em educao, num primeiro momento, mais importante obter um
consenso em relao introduo de Kanban e comear a us-lo. Este captulo procura
explicar os fundamentos para uma transio bem sucedida para Kanban e fornece a
voc um guia com 12 passos simples para dar incio transio.
Embora nosso principal objetivo com Kanban seja introduzir mudana com resistncia mnina, devem existir outros objetivos; mudar pelo objetivo de mudana
intil. Estes outros objetivos devem refletir necessidades genunas de negcio como
uma maior qualidade ou entrega previsvel. Os objetivos listados aqui devem ser considerados exemplos. Os objetivos especficos da sua organizao podem ser diferentes.
O passo 1 no seu processo deve ser acordar os objetivos da sua organizao para a
introduo de Kanban.

O Primeiro Objetivo para Nosso Sistema Kanban


Estamos fazendo Kanban porque acreditamos que ele proporciona um caminho melhor
para introduzir mudana. Portanto mudana com resistncia mnina deve ser nosso
primeiro objetivo.

Objetivo 1 Aperfeioar o Processo Atual


Os processos atuais sero aperfeioados atravs da introduo de visualizao e limite do trabalho-em-progresso para catalisar mudanas. Como os papis e responsabilidades no mudam, a resistncia dos funcionrios dever ser mnima.

Objetivos Secundrios para Nosso Sistema Kanban

Objetivos Secundrios para Nosso Sistema Kanban


Sabemos que Kanban nos permite alcanar todos os seis elementos da Receita para
o Sucesso (do captulo 3). No entanto, podemos reformular levemente os objetivos e
expandir alguns dos pontos da receita para refletir aquele ponto que pode nos ajudar
a cumprir mais de um objetivo.

Objetivo 2 Entregar com Alta Qualidade


Kanban nos ajuda a focar na qualidade limitando o trabalho-em-progresso e permitindo-nos definir polticas sobre o que aceitvel antes de um item de trabalho ser puxado para o prximo passo
no processo. Estas polticas podem incluir critrios de qualidade. Se, por exemplo, atribumos uma
poltica rigorosa de que user stories no podem ser puxadas at que todos os testes tenham sido
executados com sucesso e os defeitos resolvidos, estamos efetivamente parando a linha at que a
user story esteja em condio boa o bastante para continuar. Com uma equipe nova em Kanban, no
devemos implementar uma regra to rigorosa, mas devem existir algumas polticas relacionadas
qualidade que direcionam a equipe a desenvolver cdigo com uma quantidade menor de defeitos.
Objetivo 3 Melhorar a Previsibilidade do Lead Time
Sabemos que a quantidade de WIP tem relacionamento direto com o lead time e que h tambm
uma correlao entre lead time e um crescimento no linear na taxa de defeitos; portanto faz sentido
mantermos o WIP pequeno; seria mais fcil simplesmente acordar uma quantidade fixa. Isto pode
tornar lead times seguros e nos ajudar a manter a taxa de defeitos baixa.
Objetivo 4 Melhorar a Satisfao dos Funcionrios
Embora a satisfao dos funcionrios seja valorizada na maioria das empresas, raramente uma
prioridade. Investidores e gerentes seniores tm a viso de que recursos so fungveis e facilmente
substitudos. Isto reflete uma tendncia de gerenciamento centrada nos custos ou abordagem de
investimento. Ela no considera o grande Impacto no desempenho com uma fora de trabalho
motivada e experiente. Reteno de pessoal importante. Com o envelhecimento da populao de
desenvolvedores de software, eles preocupam-se mais com o resto das suas vidas. Muitos lamentam desperdiar vinte anos trancados num escritrio forados a trabalhar num cdigo que falha em
atender s expectativas do mercado e torna-se obsoleto logo aps o release.
Balancear trabalho/vida no apenas balancear o nmero de horas que uma pessoa gasta no
trabalho e o nmero de horas que ela est disponvel para sua famlia, amigos, hobbies, paixes, e
outras atividades; tambm fornecer confiana. Digamos, por exemplo, que um membro da equipe
com uma paixo por arte quer assistir a uma aula de pintura numa escola mdia local. Ela comea s

181

182

Captulo 15 Empreendendo uma Iniciativa de Mudana Kanban

6:30 p.m e acontece toda quarta-feira por dez semanas. Sua equipe pode assegurar para essa pessoa que ele ou ela est livre para deixar o escritrio em tempo de comparecer aula toda semana?
Fornecer um bom balanceamento para trabalho/vida tornar sua empresa um empregador mais
atraente no seu mercado local. Isto ajudar a motivar os funcionrios e dar aos membros da sua
equipe a energia para manter nveis altos de desempenho por meses ou anos. uma iluso acreditar
que voc conseguir um alto desempenho a partir de trabalhadores com conhecimento quando
voc os sobrecarrega com trabalho. Isto pode ser verdade taticamente por poucos dias, mas no
sustentvel por mais de uma ou duas semanas. um bom negcio fornecer um bom balanceamento trabalho/vida nunca sobrecarregando suas equipes.
Objetivo 5 Proporcionar Folga para Permitir Melhoria
Embora o terceiro elemento da Receita para o Sucesso - Balancear Demanda e Rendimento - possa
ser utilizado para evitar sobrecarregar os membros da equipe e para permitir que eles tenham um
balanceamento confivel entre trabalho/vida, ele tem um efeito secundrio. Ele cria uma folga na
cadeia de valor. Deve existir um gargalo na sua organizao. Toda cadeia de valor tem um. O rendimento dos passos posteriores ao gargalo limitado pelo rendimento do gargalo, no importando
o quo rpidos sejam os passos anteriores ao gargalo. Portanto, quando voc balanceia a demanda
da entrada e o rendimento, voc cria tempo ocioso em todos os pontos da sua cadeia de valor
exceto no gargalo.
A maioria dos gerentes repudia a ideia de tempo ocioso. Eles tm sido geralmente treinados para
gerenciar a utilizao dos recursos (ou eficincia, como frequentemente chamado), e inerentemente acreditam que mudanas podem ser feitas para reduzir custos se h tempo ocioso. Isto pode
ser verdade, mas importante apreciar o valor da folga.
Folga pode ser usada para melhorar a resposta de requisies urgentes e fornecer banda para
possibilitar melhoria no processo. Sem folga, os membros da equipe no tm tempo para aprender
novas tcnicas, ou melhorar suas ferramentas, ou suas habilidades e capacidades. Sem folga no
h liquidez no sistema para responder a requisies urgentes ou mudanas tardias. Sem folga no
h agilidade ttica no negcio.
Objetivo 6 Simplificar Priorizao
Uma vez que a equipe seja capaz de focar na qualidade, limitar o WIP, entregar frequentemente
e balancear demanda e rendimento, eles tero uma capacidade de desenvolvimento de software
confivel: uma mquina de fazer software! Uma fbrica de software. Uma vez que essa capacidade
est em vigor, convm ao negcio fazer um uso aperfeioado dela. Fazer isso requer um mtodo
de priorizao que maximiza o valor de negcio e minimiza risco e custo. Idealmente um esquema

Objetivos Secundrios para Nosso Sistema Kanban

de priorizao que aperfeioa o desempenho do negcio (ou departamento de tecnologia) mais


desejvel.
Os campos de engenharia de software e gerenciamento de projeto tm desenvolvido esquemas
de priorizao desde que os projetos de software comearam h talvez 50 anos atrs; a maioria
dos esquemas simples. Por exemplo, Alto, Mdio e Baixo fornecem trs classificaes simples.
Nenhuma delas tem um significado direto para o negcio. Alguns esquemas mais elaborados
comearam a ser usados com a chegada de mtodos de desenvolvimento de software gil como
MoSCoW (Must have, Should have, Could have, Wont have). Outros mtodos como Feature
Driven Development usam uma verso modificada e simplificada da tcnica Kano Analysis muito
popular em companhias japonesas. No entanto, outros defendem uma ordem estritamente numrica (1, 2, 3, 4) por valor de negcio ou risco tcnico. O desafio do ltimo esquema que ele
frequentemente cria um conflito entre itens de risco alto que devem ser priorizados primeiramente
e itens de maior valor que tambm devem ser priorizados primeiramente.
Todos estes esquemas sofrem de um problema fundamental. Para responder mudana do mercado e outros eventos, necessrio repriorizar. Imagine, por exemplo, que voc tem um backlog de
400 requisitos priorizados por ordem numrica - 1 a 400 - e que voc est entregando incrementalmente em iteraes mensais usando um mtodo de desenvolvimento gil. Todo ms voc ter
que repriorizar o backlog restante de at 400 itens.
Na minha experincia, solicitar que os donos do negcio priorizem itens um desafio. O motivo
disto simples: H muita incerteza no mercado e no ambiente de negcio. difcil prever o valor
futuro de um item em relao a outro, quando algum item ser necessrio, e se um item ter mais
valor se priorizado primeiramente. Solicitar um dono de negcio para priorizar um backlog em um
sistema de tecnologia fazer um grande nmero de perguntas difceis para as quais as respostas
so incertas. Quando as pessoas no tm certeza, elas tendem a ter uma reao ruim; elas podem
se mover mais lentamente, elas podem recusar cooperao, elas podem tornar-se desconfortveis
e disfuncionais. Elas podem reagir simplesmente mudando constantemente de opinio, fazendo
planos de projeto aleatrios, e desperdiando muito tempo da equipe reagindo s mudanas.
necessrio um esquema que posterga comprometimentos o mximo possvel e que faz apenas
uma simples pergunta que fcil de responder. Kanban fornece isto solicitando aos donos do
negcio que preencham os espaos vazios da fila enquanto os fornece um lead time confivel e
uma mtrica de desempenho de entrega na data.
Ns j temos seis objetivos valiosos para o nosso sistema Kanban, e para muitos
negcios, eles devem ser o bastante. No entanto, eu e outros precursores de Kanban
descobrimos que outros dois objetivos ainda mais valiosos so possveis e desejveis.

183

184

Captulo 15 Empreendendo uma Iniciativa de Mudana Kanban

Objetivo 7 Fornecer Transparncia no Projeto e Operao do Sistema


Quando eu comecei a usar sistemas Kanban, eu acreditava em transparncia para o trabalho-em-progresso, taxa de entrega (rendimento), e qualidade porque eu entendia que isso contribuiria para
a confiana dos clientes e gerentes seniores. Eu estava fornecendo transparncia em relao ao local
onde a requisio estava no sistema, quando ela seria finalizada, e qual qualidade estava associada
a ela. Eu estava fornecendo tambm transparncia em relao ao desempenho da equipe. Fiz isso
para fornecer aos clientes confiana de que estvamos trabalhando nas suas requisies e uma ideia
de quando elas deveriam estar finalizadas. Alm disso, eu queria educar a gerncia snior nas nossas
tcnicas e desempenho e construir uma confiana em mim como gerente e na minha equipe como
um grupo de profissionais engenheiros de software bem formados.
H um efeito secundrio de toda essa transparncia que eu no havia previsto. Enquanto tudo fica
bem quanto transparncia para requisies de trabalho e desempenho, transparncia no processo
e em como ele funciona tem um efeito mgico. Ela faz com que todos os envolvidos vejam os efeitos
das suas aes ou falta de aes. Como resultado, as pessoas so mais sensatas. Elas mudaro o seu
comportamento para melhorar o desempenho do sistema como um todo. Elas iro colaborar em
mudanas necessrias no nvel de poltica, pessoal, recursos humanos, e assim por diante.
Objetivo 8 Projetar um Processo para Viabilizar o Surgimento de uma Organizao de Alta Maturidade
Para a maioria dos lderes de negcio seniores com quem eu falo, esse objetivo final representa seus
desejos e expectativas para os seus negcios e organizaes de desenvolvimento de tecnologia. Eles
procuram por previsibilidade acima de tudo, juntamente agilidade no negcio e boa governana.
Lderes de negcio querem ser capazes de fazer promessas aos seus colegas numa mesa de comit
executivo, para os seus conselhos administrativos, para os seus stakeholders, para os seus clientes,
e para o mercado em geral, e eles querem ser capazes de manter as suas promessas. Sucesso no
nvel de um executivo snior depende muito de confiana, e confiana requer confiabilidade. Acima
de tudo isso, lderes seniores querem riscos gerenciados apropriadamente para que eles possam
entregar resultados previsveis.
Alm disso, eles percebem que o mundo de hoje anda mais rpido e que mudana ocorre rapidamente: Novas tecnologias surgem; a globalizao muda o mercado de trabalho e o mercado de
consumidores, causando grandes flutuaes na demanda (por produto) e fornecimento (de trabalho); condies da economia mudam; concorrentes mudam suas estratgias e ofertas de mercado;
o mercado experimenta mudana com o envelhecimento da populao medida que essa se torna
mais rica e mais classe mdia. Ento lderes de negcio querem que seus negcios sejam geis. Eles
querem responder mudana rapidamente e tirar vantagem de oportunidades.

Conhecer os Objetivos e Articular os Benefcios

Alinhado a tudo isso eles querem uma boa governana. Eles querem apresentar que os fundos de
investimento esto sendo gastos sabiamente. Eles querem os custos sob controle e querem que o
risco de investimento no portfolio seja distribudo de maneira ideal.
Para fazer tudo isso, eles gostariam de ter mais transparncia dentro das suas organizaes de
desenvolvimento de tecnologia. Eles gostariam de ter acesso a verdadeiros status de projetos e
gostariam de ser capazes de ajudar quando necessrio. Eles querem uma organizao gerenciada
de forma mais madura que reporta fatos com dados, mtricas, e indicadores, e no anedotas e
avaliaes subjetivas.
Todos esses desejos equiparam-se a uma organizao operando no que o SEI define
como Nvel de Maturidade 4 na sua escala de cinco nveis de capacidade e maturidade
do CMMI. Os nveis 4 e 5 so conhecidos nessa escala como sendo os nveis de maturidade mais altos. Pouqussimas organizaes tm alcanado esse nvel de maturidade
independentemente da solicitao de uma avaliao formal Standard CMMI Appraisal
Method for Process Improvement (SCAMPI). No de se admirar que a maioria dos
lderes seniores de grandes empresas de tecnologia frustrada com o desempenho dos
seus grupos de engenharia de software, visto que a maturidade organizacional real no
atende o nvel desejado.

Conhecer os Objetivos e Articular os Benefcios


Ento agora temos um conjunto de objetivos para o nosso sistema Kanban. Precisamos
conhecer esses objetivos e sermos capazes de articul-los, porque antes de comearmos Kanban, precisamos ter o aval dos stakeholders na nossa cadeia de valor. Kanban
mudar a maneira que interagimos com outros grupos no negcio. Se esses stakeholders
aceitam as mudanas, seremos capazes de articular os benefcios.
A seguir h um guia passo a passo prescritivo para a inicializao de um sistema
Kanban para uma nica cadeia de valor na sua organizao. Este guia tem sido desenvolvido baseado em experincias reais e validado por muitos iniciantes na adoo de
Kanban, aqueles que seguiram esses passos (quase todos) e obtiveram sucesso e aqueles
que reconheceram que a sua falha parcial poderia ter sido evitada se esse guia estivesse
disponvel no momento.
Este guia fornecido, em parte, para chamar a ateno para a diferena entre Kanban
e mtodos de desenvolvimento gil anteriores. Kanban requer um engajamento colaborativo com a cadeia de valor mais ampla e um gerenciamento de risco mdio (e
talvez snior) desde o incio. Uma adoo unilateral de Kanban sem primeiramente

185

186

Captulo 15 Empreendendo uma Iniciativa de Mudana Kanban

construir um consenso entre os gerentes externos e a equipe imediata ter um sucesso


limitado e trar benefcios limitados ao negcio.
Tem sido dito para mim que esse conjunto de passos pode parecer assustador, e que
algumas pessoas comentaram que tendo lido isso, elas teriam desistido completamente
de tentar Kanban. Espero que o mbito mais amplo desse livro tenha explicado como se
engajar em cada um desses passos e tenha fornecido a voc conselhos teis aprendidos
com a experincia em campo.

Passos para Dar Incio


1. Acorde um conjunto de objetivos para a introduo de Kanban.
2. Mapeie a cadeia de valor (a sequncia de todas as aes que a organizao de
desenvolvimento realiza para atender a requisio dos clientes/stakeholders). (Veja
captulo 6)
3. Defina algum ponto onde voc quer controlar a entrada. Defina o que vem antes
desse ponto e quais so os stakeholders envolvidos (explicado no captulo 6). Por
exemplo, voc deseja controlar a chegada de requisitos para a equipe de pr-produo de projeto? Os stakeholders envolvidos antes desse ponto devem ser os
gerentes de produto.
4. Defina algum ponto de sada a partir do qual voc no quer ter controle. Defina
o que vem depois dele e quais so os stakeholders envolvidos (explicado no captulo 6). Por exemplo, talvez voc no precise controlar o cumprimento da entrega
do produto.
5. Defina um conjunto de tipos de item de trabalho baseados nos tipos de requisio
de trabalho que vm dos stakeholders antes do ponto de entrada (explicado no
captulo 6). Voc tem tipos de itens que so sensveis ao tempo e outros no? Caso
positivo, ento voc pode precisar de algumas classes de servio (explicado no
captulo 11).
6. Analise a demanda para cada tipo de item de trabalho. Observe a taxa de chegada
e variao dos itens. A variao sazonal ou orientada a eventos? Quais riscos
esto associados com este tipo de demanda? O sistema deve ser projetado para
lidar com uma demanda mdia ou de pico? Qual a tolerncia para entregas em
atraso ou incerteza para este tipo de trabalho? Crie um perfil de risco para
demanda. (explicado no captulo 6)

Passos para Dar Incio

7. Rena-se com os stakeholders envolvidos antes do ponto de entrada e depois do


ponto de sada do sistema deve ser uma reunio grande, ou muitas reunies
pequenas. (Explicado com maior profundidade mais frente neste captulo.)
a. Discuta polticas relacionadas capacidade da parte da cadeia de valor que
voc quer controlar e acorde um limite de WIP (explicado no captulo 10).
b. Discuta e acorde um mecanismo de coordenao da entrada, como uma reunio de priorizao regular, com os parceiros envolvidos antes do ponto de
entrada (explicado no captulo 9).
c. Discuta e acorde um mecanismo de coordenao de entrega/release, como
release regular, com os parceiros envolvidos aps o ponto de sada (explicado
no captulo 8).
d. Voc pode precisar introduzir o conceito de classes de servio diferentes para
as requisies de trabalho (explicado no captulo 11).
e. Acorde uma meta de lead time para cada classe de servio dos itens de trabalho. Isso conhecido como service-level agreement (SLA), e foi explicado no
captulo 11.
8. Crie um quadro/parede de cartes para acompanhar a cadeia de valor que voc
est controlando (explicado nos captulos 6 e 7).
9. Opcionalmente, crie um sistema eletrnico para acompanhar e reportar o mesmo
(explicado nos captulos 6 e 7).
10. Acorde com a equipe realizar uma standup meeting diria na frente do quadro;
convide os stakeholders envolvidos antes do ponto de entrada e depois do ponto
de sada, mas no obrigue o envolvimento deles (explicado no captulo 7).
11. Acorde em ter revises operacionais regulares para anlise retrospectiva do processo; convide os stakeholders envolvidos antes do ponto de entrada e depois do
ponto de sada, mas no obrigue o envolvimento deles (explicado no captulo 14).
12. Eduque a equipe no quadro, limites de WIP e sistema puxado. Nada mais no
mundo delas deve ter mudado. As atribuies do emprego so as mesmas. As
atividades so as mesmas. As entregas so as mesmas. Os artefatos so os mesmos.
O processo deles no foi alterado, alm do seu pedido para que eles aceitem limites de WIP e puxar trabalho baseados na poltica de classe de servio em vez de
receb-los de maneira empurrada.

187

188

Captulo 15 Empreendendo uma Iniciativa de Mudana Kanban

Kanban Requer um Tipo Diferente de Negociao


Kanban requer que a equipe de desenvolvimento de software faa uma negociao
diferente com os seus parceiros de negcio. Para entender isto, devemos primeiramente
entender as alternativas tpicas que esto em uso.
Gerenciamento de projeto tradicional faz uma promessa baseada na restrio tripla
escopo, cronograma e oramento. Aps alguns elementos de estimativa e planejamento,
elaborado um oramento para o provimento de recursos, e um escopo de requisitos
e cronograma so acordados.
Gerenciamento gil de projeto, no entanto, no faz um compromisso to rgido e
arrojado. Pode existir uma data de entrega acordada para alguns meses no futuro, mas
um escopo preciso nunca estabelecido. Alguma definio de alto nvel do escopo
pode ser estabelecida, mas detalhamentos nunca so realizados. Um oramento (ou
burn rate) pode ser acordado para fornecer uma quantidade fixa de recursos. A equipe
de desenvolvimento gil prossegue de uma maneira iterativa, entregando incrementos de funcionalidades em iteraes time-boxed (ou sprints) curtas. Tipicamente, elas
duram de uma a quatro semanas. No incio de cada uma dessas iteraes, algumas
estimativas e planejamentos so realizados e um compromisso feito. O escopo priorizado frequentemente e entendido que se a equipe no pde manter o compromisso,
o escopo ser reduzido, e a data de entrega ser mantida. No nvel de iterao (ou time-box), o desenvolvimento gil bem similar ao gerenciamento de projeto tradicional.
A nica diferena chave o entendimento explcito que o escopo ser reduzido se
necessrio; enquanto que um gerente de projeto tradicional poderia escolher aumentar
o cronograma, adicionar recursos, reduzir escopo, ou uma combinao dos trs.
Kanban requer um tipo diferente de negociao. Kanban no procura fazer uma
promessa e um compromisso baseado em algo incerto. Uma implementao tpica
Kanban envolve um consenso de que existir uma entrega regular de software em
funcionamento de alta qualidade talvez quinzenalmente. oferecida transparncia
completa aos stakeholders externos em relao ao trabalho e ao processo e visibilidade
diria do progresso, caso eles queiram. So oferecidas tambm oportunidades frequentes de seleo de novos itens mais importantes para desenvolvimento. A frequncia
deste processo de seleo deve ser maior do que a taxa de entrega tipicamente, uma
vez por semana, embora algumas equipes tenham alcanado uma frequncia de seleo
por demanda ou taxas frequentes, como diariamente ou duas vezes por semana.
A equipe se compromete a fazer um timo trabalho e entregar a maior quantidade
de software em funcionamento possvel; e a fazer esforo continuo para aumentar a
qualidade, frequncia e lead time da entrega. Alm de oferecer uma flexibilidade inacreditvel ao negcio de seleo de itens para processamento em quantidades muito

Kanban Requer um Tipo Diferente de Negociao

pequenas, a equipe pode tambm oferecer uma flexibilidade na priorizao e importncia fornecendo classes de servio de trabalho diferentes. Este conceito explicado
no captulo 11.
Kanban no se compromete com certa quantidade de trabalho entregue numa certa
data. Ele oferece compromisso considerando o nvel de acordo de servio para cada
classe de servio junto a um compromisso de entregas regulares confiveis, transparncia, flexibilidade na priorizao e processamento, melhoria contnua na qualidade,
rendimento, frequncia de entrega, e lead time. Kanban oferece um compromisso no
nvel de servio, balanceando risco atravs da agregao de uma grande quantidade
de itens. Um sistema Kanban projetado apropriadamente oferece um compromisso
em relao a pontos que o cliente realmente valoriza. Em troca, a equipe solicita um
compromisso de longo prazo para os clientes e parceiros da cadeia de valor: um compromisso de se ter um relacionamento de negcio contnuo no qual a equipe de desenvolvimento de software luta constantemente para melhorar o nvel de servio atravs
da melhoria da qualidade, rendimento, frequncia de entrega, e lead time para entrega.
Como o cliente reconhece um relacionamento continuo e de longo prazo, se ele estiver
disposto a medir o servio mais do que pressionar a equipe a ser precisa em relao a
qualquer item, o sistema pode funcionar.
A abordagem tradicional para se formar um compromisso em relao ao escopo,
cronograma, e oramento um indicativo de uma transio nica. Isso implica que no
h um relacionamento continuo; isso implica num baixo nvel de confiana.
A abordagem Kanban baseada na noo de que a equipe estar junta e engajada
num relacionamento de longo perodo de tempo com o fornecedor. A abordagem
Kanban implica repetio de negcio. Ela implica num compromisso para um relacionamento, e no meramente para um pedao de trabalho. Kanban implica num nvel
de confiana alto desejado entre a equipe de software e os parceiros da cadeia de valor.
Ela implica que todos acreditam que esto formando uma parceria de longo prazo e
que eles desejam que essa parceria seja altamente eficaz.
Um compromisso Kanban convidar a todos da cadeia de valor a cuidar do desempenho do sistema a cuidar da qualidade e da quantidade de software sendo entregue,
da frequncia da entrega, e do lead time da entrega. Kanban convida os parceiros da
cadeia de valor a se comprometerem com o conceito de agilidade de negcio verdadeiro
e entrar em consenso num trabalho colaborativo para que ele acontea. Isto diferencia
significativamente Kanban das abordagens geis anteriores de desenvolvimento de
software.
Estabelecendo uma negociao Kanban com os stakeholders envolvidos antes
do ponto de entrada e depois do ponto de sada do sistema, voc estabelecer um

189

190

Captulo 15 Empreendendo uma Iniciativa de Mudana Kanban

compromisso fundamental para o nvel de desempenho do sistema. Voc estabelecer


a fundao para uma cultura de melhoria continua.

Fazendo uma Negociao Kanban


Uma parte crtica para uma implementao Kanban bem sucedida a negociao inicial desse tipo diferente de barganha. O que acontece durante essas negociaes iniciais
o estabelecimento das regras do jogo colaborativo que ser jogado a partir de ento.
vital que os parceiros da cadeia de valor sejam envolvidos com o estabelecimento
dessas regras, pois ser necessrio que eles participem do jogo para que ele seja justo e
para que as sadas reflitam os objetivos e as intenes.
O passo 7 do processo de 12 passos para introduo de Kanban sugere que nos
reunamos com os stakeholders envolvidos antes do ponto de entrada no sistema, como
marketing e pessoas do negcio que fornecem os requisitos, e os parceiros envolvidos
aps o ponto de sada no sistema, como operao de sistema e equipe de desenvolvimento ou organizao de vendas e entrega. Precisamos acordar com eles as polticas
relacionadas ao WIP, priorizao, entregas, classes de servio, e lead time. O conjunto
de polticas acordado com esses parceiros definir as regras do nosso jogo colaborativo
de desenvolvimento de software. difcil tratar cada um dos cinco elementos isoladamente, visto que eles so essencialmente inter-relacionados. Ento embora entendamos que deve haver um conjunto de polticas para cada um dos cinco elementos, as
negociaes sero circulares por natureza medida que os participantes iteram sobre
as opes. Por exemplo, se uma meta de lead time proposta inaceitvel, pode ser possvel introduzir uma classe de servio diferente que oferece um lead time menor para
certos tipos de requisio de trabalho. Os cinco elementos WIP, priorizao, entrega,
classes de servio e lead time fornecem alavancas que podem ser puxadas para afetar
o desempenho do sistema. A habilidade saber como puxar essas alavancas e como
negociar opes para chegar a um acordo que funcionar efetivamente.

Limites de WIP
Eu conheci um gerente de desenvolvimento em Denmark que me contou que os seus
desenvolvedores trabalhavam em sete atividades e meia, em mdia, simultaneamente;
isto claramente indesejvel. Eu me pergunto se algum acredita realmente que este
nvel de multitarefa apropriado. Se eu fosse ele, eu usaria esse fato como ponto inicial para as minhas negociaes. Eu abriria a conversa declarando que, em mdia,
os membros da equipe esto trabalhando em sete atividades e meia em paralelo. Eu

Fazendo uma Negociao Kanban

assinalaria o que isso faz com o lead time e previsibilidade e convidaria os meus colegas
e outros stakeholders a sugerir qual seria um nmero melhor. Alguns deles iriam
sugerir que apenas um item por pessoa a melhor ideia. E poderia ser, mas essa uma
escolha muito agressiva. O que aconteceria se algo estivesse bloqueado? No seria
bom ter uma alternativa para onde mudar? Ento talvez outra pessoa sugerisse que
duas atividades em paralelo a resposta correta. Alguns podem concordar que trs;
provvel que o intervalo de opes fique entre uma e trs atividades. Se a equipe tem
dez desenvolvedores e voc chega a um consenso de no mximo duas atividades no
processo por pessoa ento voc ter um acordo de limite de WIP de 20 para a equipe
de desenvolvimento.
H outras alternativas. Talvez voc queira trabalhar com pares de programadores;
ento duas atividades por par com dez desenvolvedores significar um limite de WIP
de dez. Alternativamente, voc pode usar um mtodo altamente colaborativo como
Feature Driven Development ou Feature Crews, nos quais equipes pequenas de no mximo cinco ou seis pessoas trabalham numa nica Minimum Marketable Feature, User
story, ou em batches de features (como em FDD), conhecido como Chief Programmer
Work Package (CPWP). Uma equipe FDD pode acordar limitar CPWPs em trs para
a equipe de dez desenvolvedores. (Um CPWP tipicamente otimizado para eficincia
do desenvolvimento baseado na anlise da arquitetura do domnio e contm de 5 a 15
funes de alta granularidade.)
Ento tivemos uma conversa sobre limites de WIP com os nossos stakeholders.
Fizemos isso discutindo qual a expectativa razovel para multitarefa e relacionando-a
a confiabilidade de entrega e s expectativas de lead lime. Acordar limites de WIP com
os nossos parceiros um elemento vital. Embora possamos declarar unilateralmente
os limites de WIP, envolver outros stakeholders e chegar a um consenso estabelece um
compromisso com as regras do nosso jogo colaborativo; em algum ponto no futuro
esse compromisso ser inestimvel. Haver um dia que nossos parceiros nos solicitaro trabalho adicional. Eles faro isso porque alguma coisa importante e valiosa.
Seus motivos sero genunos. Quando eles fizerem isso, seremos capazes de responder
pedindo a eles para reconhecerem que temos um limite de WIP acordado. provvel
que nosso sistema esteja cheio e aceitar outro item, embora importante, quebrar esse
limite; ento nossa resposta deve ser:
Sim, adoraramos aceitar esse novo trabalho, visto que percebemos que ele muito
importante para voc. Igualmente, voc sabe e entende que temos um acordo em relao ao limite de WIP. Voc fez parte dessa deciso, e voc entenda porque a fizemos. Queremos ser capazes de processar requisies confiveis e em tempo hbil. Para
atender a sua requisio, precisaremos colocar algo de lado. Qual dos itens atuais em
progresso voc prefere que seja retirado para dar incio ao novo item?

191

192

Captulo 15 Empreendendo uma Iniciativa de Mudana Kanban

Se no tivssemos includo nossos parceiros na deciso de limite de WIP, seramos incapazes de ter essa discusso. Eles simplesmente continuariam a nos pressionar.
Nosso sistema puxado com WIP limitado seria quebrado e nossa organizao escorregaria por um caminho ngreme de volta a um sistema empurrado.
Se ns temos um jogo colaborativo verdadeiro e bem sucedido de desenvolvimento
de software, as regras para o jogo devem ser acordadas atravs de um consenso entre
todos os stakeholders.

Priorizao
Ns tambm queremos entrar em consenso num mecanismo para re-preenchimento
da fila. Tipicamente, estamos procura de um acordo para termos uma reunio regular de re-preenchimento e um mecanismo que diga qual novo item ser selecionado.
Devemos ter essa conversa perguntando, Se fssemos fazer uma pergunta muito simples para voc, como, Quais duas coisas voc precisa para fazer uma entrega daqui a
42 dias? Com qual freqncia voc seria capaz de se reunir conosco para termos essa
discusso? Desejamos que a reunio no dure mais do que 30 minutos. Como voc
est oferecendo realizar uma reunio extremamente focada, e voc est fazendo uma
pergunta muito direta e sugerindo que o compromisso de tempo mnimo, voc ver
que os parceiros envolvidos antes do ponto de entrada do sistema estaro dispostos
a ser muito colaborativos. No incomum conseguir um acordo para uma reunio
semanal. Uma frequncia maior comum em domnios que se movem com maior
velocidade como mdia, onde os ciclos de release podem ser mais frequentes.

Entrega/Release
Agora devemos acordar algo similar com nossos parceiros envolvidos no final da cadeia
de valor. Uma cadncia de entrega que faz sentido muito especfica para o domnio
ou situao. Se for um software para a web, ns temos que implant-lo num servidor.
Implantao envolve cpia de arquivos e talvez atualizao de um esquema de banco
de dados e ento migrao dos dados de uma verso do esquema para outra. Esta
migrao de dados provavelmente tem o seu cdigo prprio e levar seu prprio tempo
para executar. Para calcular o tempo total de implantao, voc precisar considerar em
quantos servidores ele ser instalado, quantos arquivos sero copiados, quanto tempo
levar para desligar os sistemas e reinici-los, quanto tempo ser gasto na migrao dos
dados, e assim por diante. Algumas implantaes podem durar minutos, outras horasou at dias. Em outros domnios, podemos precisar fabricar mdia fsica como DVDs,

Fazendo uma Negociao Kanban

empacot-los em caixas, e distribu-los atravs de canais fsicos como distribuidores,


concessionrias, varejistas, ou clientes corporativos. Podem existir outros elementos
envolvidos, como a impresso de manuais ou treinamento para equipe de vendas e
suporte. Pode ser necessrio elaborar um treinamento para essas pessoas.
Por exemplo, em 2002, eu fiz parte do primeiro release de uma atualizao por estgios da rede de telefonia mvel da Sprint PCS. Esta primeira atualizao para a tecnologia 3G foi chamada 1xRTT. O lanamento envolveu o release de 15 novos aparelhos
com uma meta de 16 features novas que utilizavam a capacidade de alta velocidade da
nova rede. A Sprint tinha uma rede espalhada atravs dos Estados Unidos e empregava
17000 pessoas. Eles tinham uma quantidade similar de pessoas em call centers que
cuidavam das chamadas dos usurios. O canal de vendas a varejo e o atendimento a
clientes tinham sido treinados para dar suporte no lanamento do novo aparelho de
celular. Por brincadeira, sugeri que a melhor maneira de se fazer isso seria desligar tudo
por dois dias, levar todos para Kansas City por uma noite, alugar o estdio Kansas City
Chief, onde deveramos apresentar um PowerPoint de duas horas nas duas telas gigantes do estdio. Essa teria sido a maneira mais eficiente, mas era totalmente inaceitvel
por muitos motivos. Nossos clientes dificilmente aceitariam um suporte 48 horas fora
do ar enquanto treinvamos nossos operadores na prxima gerao de tecnologia. E
perder dois dias de lucro nas vendas do canal de varejo no teria ajudado nossas metas
de lucro anual.
Um programa de treinamento foi elaborado, e uma educao no formato treine os
treinadores foi realizada. Um programa para treinamento do pessoal de varejo regional foi elaborado, como tambm um similar para os call centers. Formadores foram
enviados a campo por seis semanas para treinamento de grupos pequenos de pessoas
medida que as mudanas aconteciam. O custo de realizao do treinamento foi alto.
O comprometimento de tempo seis semanas foi significante, e a meia vida do
treinamento na memria dos funcionrios era tambm de seis semanas. Se perdssemos a janela de lanamento do novo servio, o treinamento teria que ser repetido e a
implantao seria postergada em no mnimo seis semanas.
Se o seu domnio como uma rede telefnica, voc sabe que a cadncia de release
no ser frequente. Quando os custos de transao para se fazer um release inclui seis
semanas de treinamento, fazer releases com uma frequncia maior do que anual
proibitivo.
A sada desejvel uma cadncia de release com a maior frequncia que faa sentido.
Ento comece perguntando, Se entregamos a voc cdigo de alta qualidade com uma
quantidade mnina de defeitos, e ele vem com uma nota adequada, transparncia em
relao a sua complexidade, e confiana na entrega, com qual frequncia voc poderia
distribu-lo em produo? Isto provocar uma discusso em relao s definies que

193

194

Captulo 15 Empreendendo uma Iniciativa de Mudana Kanban

voc usou, e alguma reafirmao ser requerida. No entanto, voc deve pressionar por
um resultado que maximize a agilidade no negcio sem estressar demasiadamente
qualquer parte do sistema.

Lead Time e Classes de Servio


Quando conversamos sobre lead time, ajuda termos algum dado histrico de desempenho anterior. Idealmente, queremos ter um lead time e dados de tempo das atividades
de engenharia. No exemplo da Microsoft do captulo 14, sabemos que o lead time foi
em torno de 125 dias para defeitos de severidade 1 e 155 dias para outras severidades.
A primeira coisa que deve chamar a sua ateno nisso que h duas classes de servio.
Defeitos de severidade 1 tm recebido historicamente alguma forma de tratamento
especial. Nunca houve alguma formalidade em relao a isso, mas o resultado disso
que defeitos de severidade 1foram processados mais rapidamente.
Saber isso nos ajuda a oferecer duas classes de servio diferentes. Podemos sugerir
aos stakeholders externos que iremos adotar duas classes de servio e que teremos lead
times distintos para cada uma delas.
Igualmente, ns tambm sabemos a partir dos dados histricos que o esforo mdio
da engenharia era de 11 dias e que o valor maior foi de 15 dias. Ento decidimos sugerir um lead time de 25 dias a partir da seleo na fila de entrada. No h mais cincia
envolvida do que essa. Agora imagine o efeito psicolgico disso. O negcio tinha um
desempenho mdio de quatro a cinco meses e acabamos de sugerir 25 dias. A diferena
que oferecemos um lead time de 25 dias sem incluir nenhum enfileiramento inicial e
os 155 dias era um lead time que envolvia enfileiramento. No obstante isso soe como
uma melhoria fantstica. No uma surpresa que a empresa concorde.
Existem outras alternativas. Voc pode pegar os dados histricos do esforo de engenharia e coloc-lo num grfico de controle de processo estatstico. Isso dar a voc um
limite mximo de controle (ou 3-sigma). Voc pode ento querer aumentar o nmero
de limite mximo por segurana para absorver variaes externas. No entanto, se voc
fizer isso, voc deve ser transparente com os seus parceiros e mostr-los como voc
est calculando os nmeros.
Outra alternativa seria perguntar qual o nvel de resposta que o seu negcio realmente precisa. Isso pode ser feito no contexto de um conjunto de classes de servio.
Por exemplo, se o negcio responde, Precisamos entregar em trs dias. Voc deve
responder, Tudo precisa ser entregue em trs dias? A resposta certamente ser, No
Isto poder dar a voc a oportunidade de solicitar uma definio de tipos de requisio
que precisam ser entregues em trs dias. Voc pode ento criar uma classe de servio

Fazendo uma Negociao Kanban

para este tipo de trabalho. Ento repita o processo para o restante do trabalho. A sada
deve ser uma estratificao das requisies de trabalho em muitas faixas para as quais
uma classe de servio pode ser criada. provvel que cada uma dessas faixas contenha
trabalho que possui o mesmo formato de funo para custo de atraso. Os detalhes envolvidos na criao de classes de servio e o conceito de funo de custo de atraso so
totalmente explicados no captulo 11.
A meta de lead time que voc acordar para cada classe de servio deve ser apresentada como uma meta e no como um compromisso. Voc se comprometer a fazer o
seu melhor para alcanar a meta e a reportar o desempenho de entrega na data em
relao ao lead time do service-level agreement (SLA) para cada classe de servio. Em
algumas situaes, no haver confiana suficiente que permita um acordo que o lead
time do SLA uma meta em vez de um compromisso. Se voc precisa acordar que o
lead time no SLA representa um compromisso, voc deve aumentar a meta com uma
margem de segurana. Isto ir deixar claro que um nvel baixo de confiana resulta em
custo econmico direto.
O critrio de sada para a discusso com o seu parceiro em relao a isso : Voc ter
um consenso em relao aos limites de WIP ao longo da cadeia de valor; voc ter um
acordo para a coordenao de priorizao e o mtodo a ser usado; voc ter um acordo
similar para a coordenao de entrega e o mtodo para isso; e voc ter uma definio
de um conjunto de acordos de nvel de servio que incluem uma meta de lead time
para cada classe de servio.

195

196

Captulo 15 Empreendendo uma Iniciativa de Mudana Kanban

Takeaways
H pelo menos oito objetivos possveis para a introduo de Kanban na sua
organizao.
Melhore o desempenho atravs de melhorias no processo introduzidas com
resistncia mnima.
Faa entregas com alta qualidade.
Tenha um lead time previsvel controlando a quantidade de trabalho-em-progresso.
Proporcione uma vida melhor aos membros da sua equipe atravs de um melhor
balanceamento trabalho/vida.
Fornea folga no sistema balanceando demanda e rendimento.
Fornea um mecanismo de priorizao simples que posterga comprometimento e
mantm as opes abertas.
Fornea um esquema transparente para visualizar oportunidades de melhoria,
possibilitando, desse modo, uma mudana para uma cultura mais colaborativa
que estimula a melhoria contnua.
Lute por um processo que permita resultados previsveis, agilidade no negcio,
boa governana, e o desenvolvimento que o Software Engineering Institute chama
de organizao de alta maturidade.
importante definir os seus objetivos e ser capaz de articular os benefcios da
introduo Kanban para conseguir um acordo consensual com outros stakeholders.
Siga o guia de 12 passos para introduzir o processo Kanban.
Kanban requer um tipo diferente de barganha com os stakeholders externos e donos
do negcio. uma barganha baseada na suposio de um relacionamento de longo
prazo e num comprometimento em relao ao nvel de desempenho do sistema.
Incluir stakeholders externos para se chegar a um acordo nos elementos bsicos do
sistema Kanban faz com que eles se tornem colaboradores.
Polticas bsicas para limite de WIP, metas de lead time, classes de servio,
priorizao, e entrega, representam as regras do jogo colaborativo de
desenvolvimento de software.
Envolver stakeholders externos como colaboradores para acordar as regras do jogo
permitir um comportamento colaborativo mais tarde, quando o sistema ser
colocado sobre stress.


PARTE QUATRO

Fazendo Melhorias

C aptulo 16

Trs Tipos de
Oportunidade de
Melhoria

aptulos 6 ao 15 descrevem como construir e operar um sistema


kanban e a adotar a abordagem Kanban para gerenciamento de
mudana e melhoria. O restante do livro descreve como identificar
oportunidades para melhoria, o que fazer com elas, e como escolher
entre elas.
O captulo 2 identifica as cinco principais propriedades que voc
deve encontrar numa organizao usando Kanban. A quinta propriedade descreve como os modelos so usados para identificar, avaliar,
e orientar oportunidades de melhoria. H muitos modelos possveis.
Este captulo foca em trs modelos e suas variantes: A Teoria das
Restries e o seu Five Focusing Steps; um subconjunto de ideias do
Pensamento Lean que identificam atividades desnecessrias, como
custos econmicos; e algumas variaes que focam no entendimento e reduo da variabilidade. Outros modelos so possveis. A
comunidade j experimenta modelos como Teoria da Opo Real e
Gerenciamento de Risco. O que est descrito aqui so exemplos. Eles
so um incio. Eu gostaria de motiv-lo a adot-los, visto que sei que
eles funcionam, e gostaria de incentivar voc a expandir seu pensamento e olhar para a grande variedade de modelos que capacitam e
delegam equipe a gerao de melhorias.

199

200

Captulo 16 Trs Tipos de Oportunidade de Melhoria

Gargalos, Eliminao de Desperdcio, e Reduo


da Variabilidade
Cada um destes modelos para melhoria tem sido completamente explorado e tem
desenvolvido seu prprio corpo de conhecimento. Cada um tem a sua prpria escola
de pensamentos em melhoria contnua. Com Kanban, escolhi sintetizar os trs e fornecer uma viso geral de como identificar oportunidades de melhoria usando cada
modelo. Cada uma das trs escolas de pensamento em melhoria contnua descrita
abaixo tem o seu prprio grupo de pensadores lderes, suas prprias conferncias, seu
prprio critrio de conhecimento e experincia, e seu prprio grupo de seguidores. Sua
empresa deve se inscrever em uma ou mais destas escolas. Ser capaz de mostrar como
as tcnicas Kanban podem fornecer oportunidades para melhoria usando a tcnica
favorita da sua organizao ser uma vantagem. Saber que voc tem um conjunto vasto
de paradigmas de melhoria e ferramentas para escolher fornecem uma flexibilidade
maior para a realizao de mudanas.
Aqueles amplamente familiarizados com metodologias de melhoria contnua podem
pular o resto deste captulo e irem para o captulo 17. Aqueles que desejam uma viso
geral dos mtodos disponveis, e alguma referncia na literatura e histria, podem
achar o restante deste captulo valioso.

Teoria das Restries


A Teoria das Restries foi desenvolvida por Eli Goldratt e publicada pela primeira vez
no seu livro sobre empresas, The Goal, em 1984. Nos ltimos 25 anos, The Goal passou
por muitas revises e o framework terico conhecido como Five Focusing Steps tem se
tornado mais bvio em edies mais recentes.
O Five Focusing Steps a base para melhoria continua na Teoria das Restries. Ele
conhecido como POOGI (Process Of OnGoing Improvement). A Teoria das Restries
(ou TOC Theory of Constraints) cheia de acrnimos. Estranhamente, Five Focusing
Steps uma exceo; ele no abreviado para FFS.
Na dcada de 90, a Teoria das Restries evoluiu um mtodo para anlise da causa
raiz e gerenciamento de mudana conhecido como Thinking Processes (ou TP). O motivo para este desenvolvimento foi a descoberta junto comunidade de TOC que as
suas restries para o alcance de melhoria com os clientes eram gerenciamento de
mudana e resistncia a mudanas.
Parecia que o Five Focusing Steps funcionava bem apenas para problemas de fluxo
e que muitos desafios no trabalho no se encaixavam perfeitamente no paradigma
de fluxo. Ento TP evoluiu. A qualificao profissional e o programa de treinamento

Gargalos, Eliminao de Desperdcio, e Reduo da Variabilidade

para os consultores TOC mudaram do uso de Five Focusing Steps e suas aplicaes,
como Drum-Buffer-Rope, para TP. Portanto, quando muitas pessoas da comunidade
se referem a TOC, esto na verdade se referindo a TP e no aos Five Focusing Steps.
Observei ao participar de conferncias TOC que o uso do Five Focusing Steps dentro
da comunidade TOC transformou-se em algo como uma arte esquecida.
At onde eu tenho visto a comunidade TOC tende a aceitar paradigmas como eles
so estabelecidos em vez de desafi-los. Portanto, a soluo TOC para gerenciamento
de projeto, Corrente Crtica, evoluiu apoiada no paradigma de restrio tripla do gerenciamento de projeto (escopo, oramento e cronograma) e o modelo grfico de dependncia para agendar as atividades no projeto. Ningum desafiou esse modelo. Ningum
at eu publicar meu primeiro livro, Agile Management for Software Engineering, que
desafiou o paradigma de gerenciamento de projeto e sugeriu que melhor modelar
projetos como cadeias de valor e fluxo de problemas e aplicar o Five Focusing Steps.
Fazendo isso, seria ento possvel usar todo o corpo de conhecimento Lean, baseado
em fluxo, e sintetiz-lo com foco Five Focusing Steps nos gargalos. A sntese de TOC
com Lean possibilitaria melhorias no projeto e no desempenho da organizao e a base
para o surgimento de Kanban.
Tenho concordado que qualquer processo ou fluxo de trabalho que envolve diviso de trabalho pode ser definido como uma cadeia de valor; e que qualquer cadeia
de valor pode ser observada como um fluxo. Lean e Toyota Production System foram
construdos essencialmente ao redor dessa suposio. Se qualquer cadeia de valor tem
fluxo, ento o Five Focusing Steps pode ser aplicado. Portanto, o Five Focusing Steps
perfeitamente um satisfatrio POOGI, e TP no necessrio a menos que voc esteja
usando-o como uma ferramenta para gerenciamento de mudana. Eu pessoalmente
no desenvolvi uma afinidade com TP. Minha ferramenta de gerenciamento de mudana preferida Kanban, como mostra esse texto.
Five Focusing Steps

O Five Focusing Steps uma frmula simples para um processo em melhoria contnua.
Ele declara:
1. Identifique a restrio.
2. Decida como explorar a restrio.
3. Subordine tudo o mais no sistema deciso tomada no Passo 2.
4. Eleve a restrio.
5. Evite inrcia; identifique a prxima restrio e retorne ao Passo 2.

201

202

Captulo 16 Trs Tipos de Oportunidade de Melhoria

O Passo 1 nos solicita a identificao de um gargalo na nossa cadeia de valor.


O Passo 2 nos solicita a identificar o rendimento potencial do gargalo e compar-lo com o que est realmente acontecendo. Como voc perceber, o gargalo estar
raramente ou nunca funcionando com toda a sua capacidade. Ento pergunte, Como
conseguir atingir toda a capacidade do nosso gargalo? O que precisaremos mudar para
isso acontecer? Esta a deciso do Passo 2.
O Passo 3 nos solicita a fazer qualquer que seja a mudana necessria para implementar as ideias do passo 2. Isto deve envolver fazer mudanas adicionais em outros
lugares da cadeia de valor para obter toda a capacidade do gargalo. Esta ao de maximizar a capacidade do gargalo conhecida como explorar o gargalo.
O Passo 4 sugere que se o gargalo est operando com toda a sua capacidade e ainda
no produz rendimento suficiente, sua capacidade precisa ser reforada para aumentar
o rendimento. O passo 4 nos solicita a implementar uma melhoria para reforar a capacidade e aumentar o rendimento de maneira suficiente, aliviando o gargalo e fazendo
com que a restrio no sistema se mova para outro local na cadeia de valor.
O Passo 5 requer que demos tempo para as mudanas se estabilizarem e ento identificar um novo gargalo na cadeia de valor e repetir o processo. O resultado um sistema
de melhoria continua no qual o rendimento sempre aumenta.
Se os Five Focusing Steps so institucionalizados apropriadamente, toda a organizao alcanar uma cultura de melhoria continua.
O captulo 17 explica como identificar e gerenciar gargalos usando o Five Focusing
Steps.

Lean, TPS, e Reduo de Desperdcio


Lean surgiu no incio da dcada de 90 aps o texto seminal, The Machine That Changed
the World, de Womack, Jones, e Daniels, descrito a partir de uma observao emprica e
externa de como o Toyota Production System (TPS) funcionava. As primeiras literaturas
sobre Lean tinham algumas falhas. Elas falharam em identificar o gerenciamento da
variabilidade que inerente ao TPS e isso foi aprendido e adaptado a partir do System
of Profound Knowledge de Deming. Lean tambm foi vtima de m interpretao e
uma simplificao exacerbada. Muitos consultores Lean avanaram sobre o conceito
de Reduo de Desperdcio (ou eliminao) e ensinaram Lean como um exerccio puro
e simples de eliminao de desperdcio. Neste anti-padro de Lean, todas as atividades de trabalho foram classificadas como valor-agregado e sem-valor-agregado. As
atividades desnecessrias, sem-valor-agregado eram ento sub-classificadas em desperdcio necessrio e desnecessrio. As atividades desnecessrias eram eliminadas e
as necessrias eram reduzidas. Embora esse seja um uso vlido das ferramentas Lean

Gargalos, Eliminao de Desperdcio, e Reduo da Variabilidade

para melhoria, ele tende a no considerar as sadas, para a reduo de custos, e o valor,
visto que no abrange as ideias Lean de Valor, Cadeia de Valor e Fluxo.
Kanban viabiliza todos os aspectos do pensamento Lean e fornece as ferramentas
para melhorar o resultado do valor atravs do foco no gerenciamento do fluxo, como
tambm na eliminao do desperdcio.
O captulo 18 explica como identificar atividades com desperdcio e o que fazer
com elas.

Deming e Six Sigma


W. Edwards Deming geralmente lembrado como um dos trs pais do movimento de
Garantia da Qualidade no sculo vinte. No entanto, sua contribuio foi consideravelmente maior. Ele evoluiu o uso do Statistical Process Control (SPC) e o desenvolveu para
uma tcnica de gerenciamento que ele nomeou de System of Profound Knowledge. Seu
sistema foi elaborado para impedir os gerentes de tomarem decises de baixa qualidade
e substitu-las por decises objetivas, melhores e contra-intuitivas. Deming ocasionalmente mencionado como talvez o mais importante cientista gerencial do sculo vinte,
e, em minha opinio, isto muito merecido. Suas contribuies se estenderam do SPC
para Garantia da Qualidade e Cincia Gerencial.
Deming teve uma influncia significante na filosofia de gerenciamento japonesa
na metade do sculo vinte, e seu trabalho relacionado ao SPC e System of Profound
Knowledge um pilar chave do TPS.
Enquanto algumas equipes altamente maduras Kanban, por exemplo, no banco de
investimento BNP Parisbas em Londres, adotaram SPC, SPC est alm do escopo desse
livro e ser abordado num texto futuro sobre tcnicas Kanban avanadas.
No entanto, os princpios para o entendimento da variao em sistemas e tarefas
de trabalho que sustentam SPC so muito teis. O predecessor de Deming, Walter
Shewhart, classificou variabilidade no desempenho de tarefas em duas categorias, causa
de oportunidade e causa de atribuio. Mais tarde Deming as renomeou para causa
comum e causa especial, e na segunda edio do The New Economics, ele admitiu que
isto ocorreu por motivos amplamente pedaggicos. No h inovao especfica em
mudar os termos. Entender variao e como ela impacta no desempenho, e desenvolver
a capacidade de classific-la em uma das duas categorias so habilidades gerenciais
necessrias. Aprender as aes gerenciais necessrias que devem ser tomadas baseadas no tipo de variao essencial para um programa de melhoria contnua. Lean e
Teoria das Restries dependem fortemente de um entendimento sobre variao para

203

204

Captulo 16 Trs Tipos de Oportunidade de Melhoria

viabilizar melhoria, mesmo quando essas melhorias so expressas como gerenciamento


de gargalo ou reduo de desperdcio.
O captulo 19 explica como identificar variaes comuns e especiais e sugere ideias
para aes gerenciais apropriadas. O captulo 20 elabora esse tema; ele descreve como
construir uma capacidade de gerenciamento de problemas que responde a variaes
de causa atribuvel com o objetivo de eliminar esses problemas o mais rpido possvel
para manter o fluxo e maximizar a entrega de valor. Nota: Sem conhecimento e foco
no gerenciamento de variabilidade, focalizar o fluxo ser ineficaz. Lean sem as ideias
de Deming Lean sem um entendimento de variao, e, por implicao, Lean sem
um foco na manuteno do fluxo. Dado que a literatura inicial de Lean no incluiu um
entendimento de variao e nenhuma referncia ao System of Profound Knowledge de
Deming, fcil entender a causa raiz do anti-padro de ensino de Lean como apenas
um processo de reduo de desperdcio.
Enquanto as ideias de Deming eram incorporadas no TPS no Japo no nvel de cho
de fbrica, onde SPC e o System of Profound Knowledge eram empregados para identificar oportunidades de melhoria locais, outro corpo de conhecimento desenvolveu-se
nos EUA baseado nas ideias de Deming. Six Sigma comeou na Motorola, mas se tornou realmente conhecida quando foi adotada pela GE sob a liderana de Jack Welch.
Six Sigma emprega SPC para identificar causas de variao comum e especial e usa
um processo similar quele descrito por Deming para eliminar causa de variao especial e sua causa raiz e evita que eles sejam recorrentes; e adicionalmente, para reduzir
causa de variao comum e tornar o processo, fluxo e o sistema mais previsveis.
Ao contrrio de TPS, relacionado a iniciativas de cho de fbrica executadas por trabalhadores com poder de implementar pequenos eventos kaizen s centenas e milhares,
Six Sigma desenvolveu um mtodo de comando-e-controle de menor confiabilidade
que tende a envolver pouqussimas oportunidades de melhoria, geralmente implementadas num nvel mais estratgico, e a execut-las como projetos especficos prprios.
O lder de projeto carrega o ttulo de Black Belt e tem geralmente anos de treinamento
na metodologia para ganhar esse status. Como Kanban incorpora as ideias de Deming
e fornece instrumentos e transparncia para visualizao de variabilidade e seu efeito,
Kanban pode ser usado para viabilizar um programa de melhoria no estilo kaizen ou
programa de melhoria no estilo Six Sigma.

Adequar Kanban para a Cultura da Sua Empresa


Se a sua empresa uma companhia Six Sigma, Kanban pode ajud-lo a executar iniciativas Six Sigma no desenvolvimento de software, sistemas, produto, ou organizao
de TI. Se a sua empresa uma companhia Lean, Kanban naturalmente se adqua. Ele

Adequar Kanban para a Cultura da Sua Empresa

pode viabilizar uma iniciativa Lean completa para o seu desenvolvimento de software,
sistemas, produto, ou organizao de TI. Se a sua empresa usa a Teoria das Restries,
Kanban pode viabilizar um programa de gerenciamento de restries completo (remoo de gargalos) para o seu desenvolvimento de software, sistemas, produto, ou organizao de TI. No entanto, talvez seja necessrio voc reformular a implementao do
sistema puxado como uma implementao Drum-Buffer-Rope em vez de se referir a
isso como sendo um sistema kanban. Como Kanban se desenvolveu a partir de uma
implementao Drum-Buffer-Rope, eu sei que isso funcionar. No entanto, discusses
especficas sobre como modelar uma cadeia de valor e atribuir limites de WIP para o
Buffer e Rope esto alm do escopo desse texto.

205

206

Captulo 16 Trs Tipos de Oportunidade de Melhoria

Takeaways
Kanban requer que modelos sejam usados para identificar oportunidades
de melhoria.
Kanban d suporte a pelo menos trs tipos de mtodos de melhoria continua:
Gerenciamento de Restrio (remoo de gargalo), Reduo de Desperdcio
e Gerenciamento de Variabilidade (conhecido como SPC e o System of
Profound Knowledge).
Kanban viabiliza a identificao de gargalos e uma implementao completa
do Five Focusing Steps da Teoria das Restries.
Kanban viabiliza a visualizao de atividades de desperdcio, e pode ser
usado para viabilizar uma iniciativa dentro do desenvolvimento de software,
sistemas, produto, ou organizao de TI.
Kanban fornece os instrumentos para o uso da Theory of Profound Knowledge
e Statistical Process Control de Deming. Ele pode ser usado para orientar uma
iniciativa kaizen ou uma iniciativa Six Sigma.

C aptulo 17

Gargalos e
Disponibilidade
No-Instantnea

ashington SR-520 uma auto-estrada que liga Seattle s periferias do nordeste de Kirkland e Redmond. Ela a artria
principal para os moradores da periferia suburbana que trabalham
no centro da cidade e para os funcionrios da Microsoft e outras
empresas de alta tecnologia localizadas nestes subrbios, como AT&T,
Honeywell, e Nintendo, que moram na cidade e transitam na direo
oposta todos os dias da semana. Durante oito horas todos os dias, a
rodovia tem um gargalo de trfego srio nas duas direes. Se voc
ficar na ponte que atravessa a auto-estrada na Rua N.E. 76 no subrbio pequeno de Medina (logo aps a rua de propriedade de Bill Gates,
s margens do Lake Washington), ao final da tarde e olhar para o lado
leste, voc ver a ligao com o trfego do lado oeste da cidade rastejando lentamente at a colina Bellevue antes de fundir-se s duas faixas para cruzar a ponte flutuante para Seattle. A velocidade do trfego
at a colina de aproximadamente 10 milhas por hora e o fluxo
irregular, com os veculos constantemente diminuindo a velocidade
e parando. Se voc atravessa a rua e olha para o lado leste em direo
aos arranha-cus da cidade de Seattle, o Space Needle, e as montanhas
Olmpicos distncia, voc ver o trfego movendo-se suavemente
at voc a quase 50 milhas por hora. Que mgica est acontecendo
bem debaixo dos seus ps para que as mudanas de velocidade do
trfego aconteam de maneira to dramtica que o fluxo se transforme de irregular para suave?
207

208

Captulo 17 Gargalos e Disponibilidade No-Instantnea

Um pouco antes da ponte, a estrada diminui de trs para duas faixas antes de cruzar
o lago. A faixa mais direita da rodovia uma faixa high-occupancy vehicle (HOV)
que requer que o veculo tenha dois ou mais passageiros. Ela frequentada por muitos
nibus pblicos e carros particulares. A ao desses veculos afunilando-se no outro
trfego suficiente para causar ruptura e desacelerao. Nas muitas milhas que precedem a ponte, muitas outras rodovias fundem-se auto-estrada, aumentando o volume
do trfego que j pesado em horrio de pico. O efeito disso fluxo irregular e velocidades muito lentas.
Em segurana de trfego os planejadores preocupam-se com a distncia entre os
carros. Idealmente, necessria uma distncia suficiente para que os carros possam
reagir s mudanas e parar com segurana caso seja necessrio. Esta distncia est
relacionada velocidade e ao tempo de reao. A recomendao legal de distncia
de dois segundos. Na linguagem Lean este o tempo ideal entre veculos. Portanto, se
h duas faixas e dois segundos entre veculos, o rendimento mximo da estrada de
30 veculos em cada faixa por minuto ou 60 veculos por minuto; isto verdade independentemente da velocidade dos veculos. Essas regras so quebradas em velocidades
muito baixas ou velocidades excessivamente altas para aqueles que ultrapassam 50
milhas por hora na SR-520. Por razes prticas o rendimento (referido como a capacidade de criar confuso na gesto do trfego) de 3600 veculos por hora.
No entanto, caso voc fique em p na ponte e conte o nmero de carros que passam
abaixo dela numa tarde tpica s 5 p.m., voc observar que menos de 10 carros por
minuto atravessam a ponte flutuante em direo a Seattle. Apesar da demanda alta, a
rodovia opera em menos de um quinto do seu rendimento potencial. Por qu?
A ponte flutuante acima do Lake Washington um gargalo. Ns entendemos intuitivamente este conceito. A largura de um gargalo controla o fluxo de um lquido para
dentro e para fora de uma garrafa. Podemos tirar o liquido rapidamente da garrafa
com um gargalo grande, mas haver um risco grande de derram-lo. Com um gargalo
menor, o fluxo menor, mas pode ser mais preciso. Gargalos restringem o potencial
do rendimento, neste exemplo, de 60 carros por minuto, ou 3600 por hora, para menos
de 10 carros por minuto, ou 600 carros por hora.
De maneira geral, um gargalo pode estar em qualquer lugar do processo onde um
backlog de itens fica a espera para ser processado. No exemplo da SR-520, esse backlog
a fila de veculos ocasionalmente parada at o Overlake, sete milhas a leste. Em desenvolvimento de software, pode existir qualquer backlog de trabalho no iniciado ou
trabalho-em-progresso ; requisitos esperando por anlise; trabalho analisado esperando por projeto, desenvolvimento, e teste; trabalho testado esperando por implantao; e assim por diante.

Recursos com Capacidade Limitada

Como discutido, a SR-520 entrega apenas 20 por cento do seu potencial em horrio
de pico quando ela mais necessria. Para uma explicao completa sobre isso, precisamos entender como explorar completamente o potencial do gargalo e o efeito que a
variabilidade tem sobre o potencial. Estes conceitos so explicados aqui no captulo 17
e mais a frente no captulo 19.

Recursos com Capacidade Limitada


A Rua N.E. 76 ponte da SR-520 um gargalo de capacidade limitada. Sua capacidade
de 60 carros por minuto em duas faixas. Antes disso a estrada tem trs faixas, fazendo
com que o trfego afunile para cruzar o lago no ponto mais antigo da ponte que foi
projetado 50 anos atrs com apenas duas faixas. Naquele tempo, havia muita capacidade e a ponte no era um gargalo. Os subrbios ao leste eram pequenas vilas, e o
deslocamento pela gua era raro e naqueles dias, apenas em direo cidade e no o
inverso como comum atualmente.

Aes de Elevao
O gargalo com capacidade limitada da SR-520 similar a um user-experience designer
numa equipe de software onde responsvel por projetar todas as telas e caixas de
dilogo nas quais o usurio interage. Ela trabalha a todo vapor, mas seu rendimento
insuficiente para alcanar a demanda do projeto. A reao natural da maioria dos
gerentes nessa situao contratar outra pessoa para ajudar. Na Teoria das Restries
de Eli Goldratt, isso conhecido como elevando a restrio adicionar capacidade
a fim de que o gargalo seja removido.
No nosso exemplo da SR-520 seria algo equivalente a substituir a ponte flutuante
que atravessa o Lake Washington por uma nova ponte com trs faixas de trfego nos
dois sentidos. Para manter tudo igual, deveria ser uma ponte composta por uma faixa
HOV e uma faixa para bicicleta, como tambm duas faixas abertas para todo o trfego;
esta , de fato, a ao a qual o Washington State Department of Transportation est se
dedicando. A ponte custar muitas centenas de milhes de dlares e levar uma dcada
para ser construda. Durante a escrita deste livro a construo no foi iniciada.
Elevar a capacidade limitada com recursos deve ser a ltima opo. Aumentar a
capacidade do gargalo custa tempo e dinheiro. Se tivermos que contratar outro user-experience designer, por exemplo, ser necessrio levantar oramento para pagar esta
nova pessoa, como tambm oramento para bancar o processo de contratao, o qual
pode incluir taxas que devero ser pagas aos agentes para indicaes. O progresso do

209

210

Captulo 17 Gargalos e Disponibilidade No-Instantnea

projeto atual diminuir enquanto reviso de currculos e entrevistas com os candidatos


so realizadas. Nosso recurso mais precioso, nosso user-experience designer que restringe o gargalo, ser solicitado a ler currculos, selecionar candidatos, e entrevist-los,
gastando tempo do projeto. Como resultado, sua capacidade de finalizar designs ser
reduzida, como tambm seu potencial de rendimento para todo o projeto. Isto em
parte a afirmao da Lei de Fred Brook que adicionar pessoas a um projeto atrasado
apenas faz com que ele atrase ainda mais. Embora a observao de Brook tenha sido
anedtica, e que agora possamos fazer uma explanao mais cientfica deste fenmeno,
a indstria de software entendeu, pelo menos nos ltimos 35 anos, que a ideia de contratar mais pessoas atrasa o projeto.

Aes de Explorao/Proteo
Em vez de escolher imediatamente elevar a capacidade limitada e gastar mais dinheiro
e tempo enquanto diminui o ritmo do projeto, melhor procurar maneiras de explorar completamente a capacidade do recurso do gargalo. Por exemplo, observado que
a SR-520 tem um rendimento de apenas 20 por cento do seu potencial em horrio
de pico. Quais aes poderiam ser tomadas para melhorar esse rendimento? Vamos
sonhar por um momento. Se o rendimento da estrada no horrio de rush estivesse
alcanando seu potencial de 3600 veculos por hora, seria necessrio substituir a ponte
existente por uma nova? O tempo de viagem poderia ser curto o suficiente que os
contribuintes do Estado de Washington (como o autor) prefeririam gastar seus dlares
de impostos em outras coisas mais importantes e urgentes? Tal como mais livros em
escolas locais? Talvez!
Como poderamos ento explorar o verdadeiro potencial da rodovia? Na realidade
a origem dos problemas est nos condutores dos veculos. O tempo de reao deles e
as aes que eles tomam so altamente variveis. medida que os carros afunilam-se
a partir da faixa HOV, os veculos da faixa central precisam desacelerar e dar espao
para um carro entrando na faixa. Alguns motoristas reagem mais lentamente do que
outros; outros freiam mais vigorosamente do que outros, e efeito disso o trfego se
comportar de maneira imprevisvel. Alguns motoristas, distrados pela flutuao na
faixa a frente e a velocidade reduzida em relao faixa da esquerda, decidem mudar
para a faixa da esquerda. O mesmo efeito acontece novamente. Todos os veculos diminuem de velocidade, mas a velocidade no afeta realmente o rendimento. A distncia
entre os veculos o mais importante. O que se deseja um fluxo mais suave do trfego
com uma distncia de dois segundos entre os veculos*. No entanto, com o elemento
* Em alguns lugares da Califrnia o tempo de 1.4 segundos considerado adequado, embora no seja o ideal numa perspectiva de segurana.

Recursos com Capacidade Limitada

humano os veculos no aceleram ou desaceleram suavemente, causando um efeito


sanfona na distncia entre os veculos. O tempo de reao dos indivduos em pressionar
o acelerador e os pedais de freio, e o tempo de reao das peas e transmisso para as
engrenagens dos veculos significa uma diminuio da distncia com o aumento do
trfego. A variabilidade no sistema tem um alto impacto no rendimento.
Corrigir este problema para a SR-520 nos leva a ilha da fantasia em termos de controle de veculos, embora algumas indstrias alems tenham experimentos com esse
tipo de sistema. Sistemas que usam radar ou lasers para avaliar a distncia entre veculos e manter o trfego movendo-se de maneira suave podem remover a variabilidade
que ocorre na SR-520. Tais sistemas tm a habilidade de desacelerar suavemente cadeias
inteiras de veculos, mantendo a distncia entre eles. Como resultado, o rendimento
do trfego permanece alto. No entanto, eliminar a variabilidade de veculos privados
dirigidos pelos seus ocupantes tem alguns limites. Se voc quer um transporte de baixa
variabilidade, voc teria que acorrentar os carros uns aos outros e coloc-los em trilhos.
Esse o motivo fundamental pelo qual o transporte ferrovirio de massas mais efetivo do que automveis que transportam um grande nmero de pessoas rapidamente.
A boa notcia que em nosso escritrio, nossos recursos de capacidade limitada so
afetados por variabilidade que podemos tratar. Falamos muito nesse livro sobre atividades de coordenao e custos de transao associados a atividades que agregam valor.
Se tivermos um user-experience designer com capacidade restrita, podemos procurar
manter essa pessoa ocupada trabalhando em atividades que agregam valor minimizando a quantidade de atividades sem valor agregado (desperdcio) solicitadas a ela.
Por exemplo, em 2003 eu tinha uma equipe de testes com capacidade limitada. A fim
de maximizar a explorao de toda a sua capacidade, procurei por recursos com mais
folga e encontrei analistas de negcio e um gerente de projeto. A equipe de teste foi
liberada de atividades burocrticas, como preenchimento de folhas de ponto. Eles tambm foram liberados do planejamento de projetos futuros. Permitimos que os analistas
desenvolvessem planos de teste para iteraes e projetos futuros enquanto os testadores
estavam ocupados em realizar testes das atividades em progresso.
Uma abordagem melhor que eu no considerei teria sido elaborar um perfil de
risco para os requisitos que deveriam ser testados apenas pelos profissionais da equipe
de teste. Requisitos que no atendessem os critrios poderiam ento ser testados por
profissionais de outras reas que exerceriam um papel amador como testadores; por
exemplo, os analistas de negcio. Esta tcnica de bifurcao usando um perfil de
risco uma boa maneira de otimizar a utilizao de um gargalo enquanto gerencia-se
risco no projeto.
Uma soluo em longo prazo pode ser investir pesadamente em automao de teste.
A palavra chave nessa ltima frase investir. Se voc se pega dizendo investir, voc

211

212

Captulo 17 Gargalos e Disponibilidade No-Instantnea

est falando numa ao de elevao. Adicionar recursos no a nica maneira de elevar


a capacidade. Automao uma estratgia boa e natural de elevao. A comunidade
de desenvolvimento de software gil tem feito muito na ltima dcada para encorajar
automao de testes. Como regra geral, considere automao como uma estratgia de
elevao. No entanto, um efeito colateral maravilhoso da automao que ela reduz a
variabilidade: tarefas e atividades so repetidas com preciso digital. Ento automao
reduz variabilidade no processo e pode ajudar a melhorar a explorao da capacidade
de outro gargalo.
O prximo caminho para garantir explorao mxima da capacidade restringida
da sua user-experience designer garantir que ela est sempre fazendo progresso no
trabalho atual. Se a user-experience designer reporta que ela est bloqueada por algum
motivo externo, o gerente de projeto e, se necessrio, toda a equipe pode se debruar
sobre o problema para resolv-lo. Uma capacidade organizacional forte para identificar,
escalar e resolver problemas essencial para a explorao de gargalos com capacidade
restrita.
Se h muitos problemas bloqueando o trabalho atual, ento os problemas impedindo
o recurso de capacidade restrita, neste caso, nossa user-esperience designer, devem
ter prioridade mxima. Para um gerenciamento de problemas de alto desempenho e
efetivo faz-se necessrio conhecer a localizao do recurso de capacidade restrita e dar
prioridade a ele quando solicitado.
A transparncia do sistema Kanban ajudar a identificar a localizao do recurso de
capacidade restrita (gargalo) e o impacto de quaisquer problemas impedindo o fluxo
a partir daquele ponto no sistema. Com todos do projeto conscientes do impacto em
nvel de sistema de um impedimento no gargalo, a equipe se debruar com prazer
sobre o problema para resolv-lo. A gerncia snior e os stakeholders externos, com
interesse que o release saia na data, iro tambm investir uma maior parte do tempo
deles mais espontaneamente quando entenderem o valor deste tempo e o impacto que
uma resoluo rpida do problema proporcionar.
Portanto, desenvolver uma capacidade organizacional de acompanhar e reportar de
forma transparente em projetos usando um sistema kanban crtico para melhorar o
desempenho. Transparncia leva a visibilidade dos gargalos e impedimentos e, consequentemente, a uma melhor explorao da capacidade disponvel para realizar trabalho
de valor atravs de uma equipe focada em manter o fluxo.
Outra tcnica que comumente utilizada para garantir explorao mxima de um
recurso de capacidade restrita garantir que o recurso nunca est ocioso. Um recurso
de capacidade restrita deixado sem trabalho devido a problemas inesperados no fluxo
de atividades anterior a ele, como, por exemplo, ausncia de um analista de requisitos por alguns dias no trabalho devido a problemas mdicos familiares, pode ser um

Recursos com Capacidade Limitada

desperdcio terrvel. De repente a restrio movida. Ou talvez uma grande parte dos
requisitos seja alterada pelo negcio ao se fazer uma mudana estratgica. Enquanto
a equipe espera por novos requisitos a serem desenvolvidos, o user-experience est
ocioso. O que acontece se as atividades anteriores do fluxo so variveis por natureza?
Isto comum com solicitao e desenvolvimento de requisitos. Portanto, a taxa de
chegada de trabalho a ser realizado deve ser regular. Podem existir muitos motivos
que faam o recurso de capacidade restrita se tornar ocioso devido a uma lacuna temporria no trabalho. A maneira mais comum de evitar esse tempo ocioso proteger
o recurso do gargalo com um buffer de trabalho. O objetivo do buffer absorver a variabilidade na taxa de chegada de novos trabalhos na fila, neste exemplo, para a nossa
user-experience designer. Buffering adiciona um WIP total ao nosso sistema. De uma
perspectiva Lean, adicionar um buffer de trabalho adiciona desperdcio, e aumenta o
lead time. No entanto, a vantagem no rendimento fornecida pela garantia de um fluxo
constante de trabalho atravs do nosso recurso de capacidade restrita normalmente
um negcio melhor. Voc ter mais trabalho pronto apesar de um lead time ligeiramente mais longo e de um total de trabalho-em-progresso ligeiramente maior.
Usar buffers para garantir que um recurso de gargalo est protegido de tempo ocioso
frequentemente referido como proteger o gargalo ou uma ao de proteo. Antes
de considerar elevar um gargalo voc deve procurar maximizar a explorao e proteg-lo para garantir que a capacidade disponvel utilizada o mximo possvel.
Nosso exemplo de gerenciamento de trfego na SR-520, onde o rendimento real foi
menor do que 20 por cento do potencial muito comum com trabalhos de conhecimento como anlise de requisitos e desenvolvimento de software. frequentemente
possvel enxergar melhorias em mais de quatro vezes na taxa de entrega explorando
o gargalo.
No exemplo da Microsoft no captulo 4, foi alcanada uma melhoria de duas vezes
e meia atravs de uma melhor explorao e proteo que removia a variabilidade do
sistema sem gastar qualquer dinheiro ou elevando o gargalo.

Aes de Subordinao
Uma vez que voc tenha decidido explorar e proteger um recurso de capacidade limitada, voc pode precisar tomar uma ao subordinar outras coisas no sistema para
fazer o seu esquema de explorao funcionar efetivamente.
Deixe-me revisitar nosso sistema de trfego de fantasia num mundo futuro. Aqui,
decidimos no construir uma nova ponte flutuante atravs do Lake Washington; em
vez disso decidimos encaixar todos os veculos viajando na SR-520 em horrio de pico

213

214

Captulo 17 Gargalos e Disponibilidade No-Instantnea

num sistema de gerenciamento de velocidade que usa radar e comunicao wireless


para regular a velocidade do trfego em um trecho de sete milhas da rodovia. Esse novo
sistema agir como um controle de cruzeiro e substituir o uso manual do acelerador e
pedais de freio. Os cidados sero incentivados a se ajustarem ao sistema com benefcios fiscais. Uma vez que uma quantidade suficiente de carros tenha o sistema, ele pode
ser ligado e os carros que no o tiverem tero que encontrar uma rota alternativa ou
atravessar a rodovia fora dos horrios de pico. O resultado ser um trfego suavizado
e um aumento da explorao da capacidade do gargalo. Meu palpite que um sistema
assim, se efetivo, poderia recuperar 50 por cento da capacidade perdida. Ou colocando
de outra maneira, ele poderia aumentar o rendimento atravs da SR-520 em horrios
de pico em aproximadamente duas vezes e meia.
Ento o que fizemos neste exemplo? Ns subordinamos o direito do motorista de
empregar e controlar sua prpria velocidade em busca de um objetivo maior de uma
viagem mais rpida facilitada por um rendimento maior atravs da ponte. Esta a
essncia de uma ao de subordinao. Alguma coisa ter que mudar para melhorar a
explorao do gargalo.
Para os conhecedores da Teoria das Restries frequentemente no intuitivo notar
que mudanas requeridas para melhorar o desempenho do gargalo no so usualmente
realizadas no gargalo. Enquanto eu revisava o texto do meu primeiro livro20 um membro muito conhecido da comunidade de desenvolvimento de software gil sugeriu
que usar Teoria das Restries como uma abordagem de melhoria levaria todos da
equipe a querer ser parte de um recurso de gargalo porque eles teriam toda a ateno
da gerncia. Este um erro fcil de ser cometido. De maneira no intuitiva a maioria do
gerenciamento de gargalos acontece fora do gargalo. Muitas das mudanas focam em
reduzir a carga de falhas para o gargalo para maximizar o seu rendimento. Como regra
geral, espere maximizar a explorao da capacidade do gargalo, e, portanto maximizar
o rendimento, e como resultado, minimizar o tempo de entrega no seu projeto tomando aes em toda a cadeia de valor, e muito provavelmente no no prprio gargalo.

Recursos Disponveis No - Instantaneamente


Recursos disponveis no-instantaneamente no so, estritamente falando, gargalos.
No entanto, geralmente eles se parecem com gargalos, e as aes que precisamos tomar
para compens-los so similares em natureza quelas para o gargalo. Qualquer pessoa
que j tenha dirigido um carro e parado num sinal de trfego entende o conceito de
disponibilidade no-instantnea. Enquanto estamos parados num sinal vermelho, o
carro no pode fluir pela rodovia. A ausncia de fluxo no causada por limitao da

Recursos Disponveis No - Instantaneamente

capacidade na rodovia, mas por uma poltica que permite aos carros viajando na outra
rodovia o direito de atravessar a rodovia na qual o nosso carro est viajando.
Um exemplo melhor, e voltando ao nosso tema sobre transporte no Estado de
Washington deste captulo, seria o sistema de balsa que opera atravs do Puget Sound,
ligando o Kitsap e Olympic Pennsula com o continente ao redor da cidade de Seattle.
H trs barcas, duas que saem de Seattle e atravessam para Bremerton e Bainbridge, e
a minha favorita, a SR-104 que atravessa de Edmonds no lado leste para Kingston no
lado oeste. No mapa, a rota da balsa apresentada como sendo parte da rodovia SR104. Ela frequentemente marcada como pedgio, em vez de explicitamente dizer
voc tem que pegar um barco a partir daqui ;-) . As pessoas que a utilizam pensam
na balsa como uma rodovia disponvel no-instantaneamente.
Quando voc chega balsa, voc paga um valor em dinheiro e solicitado a ficar
numa rea de espera. O tempo de espera tpico em torno de 30 minutos, visto que a
balsa gasta mais ou menos 30 minutos para atravessar o Puget Sound, e h um perodo
de 10 a 15 minutos para descarregar os veculos, e outro perodo semelhante para carregar os novos veculos antes da partida. Usualmente a companhia opera dois barcos,
ento h uma partida a cada 50 minutos aproximadamente. Nos horrios de pico eles
podem operar trs barcos na rota, diminuindo o tempo de espera entre partidas para
aproximadamente 35 minutos.
Na maior parte do tempo, a balsa fica praticamente cheia, mas o sistema no tem
capacidade limitada. O fato dos carros ficarem numa rea de espera um buffer e
ento serem carregados na balsa para a partida (batch transferido) no indica um
recurso de capacidade restrita. As barcas partem uma ou duas vezes a cada hora, com
uma capacidade de aproximadamente 200 carros a cada partida.
Em horrios de pico, como nas tardes de sexta-feira, a capacidade da barca torna-se restrita. Quando isto acontece, a taxa de chegada de carros que desejam atravessar
excede a capacidade de transport-los. A capacidade cerca de 300 carros por hora. A
quantidade de carros comea a se acumular, enfileirando-se para fora da rea de espera,
antes do pedgio. Durante as demandas de pico, voc pode observar veculos frequentemente acumulando-se por duas milhas atravs de Edmond ou Kingston. Pouco pode
ser feito; os carros precisam apenas esperar. No fcil elevar a restrio trazendo outra
barca. A agenda e o cronograma das partidas das barcas so projetados para fornecer
um nvel razovel de servio num tempo razovel. Ter um excesso de capacidade seria
excessivamente caro para os contribuintes do estado que subsidiam o servio.
Voltando para desenvolvimento de software e trabalho de conhecimento, disponibilidade no-instantnea tende a ser um problema com recursos compartilhados ou
pessoas que so solicitadas a realizar uma grande quantidade de tarefas distintas em

215

216

Captulo 17 Gargalos e Disponibilidade No-Instantnea

paralelo multi-tasking. Como sabemos, no existe realmente algo como multi-tasking


no escritrio; o que fazemos frequentemente um chaveamento de tarefas. Se formos
solicitados a trabalhar em trs coisas simultaneamente, trabalhamos em uma por um
perodo de tempo, ento chaveamos para a segunda, e ento para a terceira. Se algum
est esperando que a primeira tarefa seja finalizada enquanto estamos na segunda ou
terceira, ento pareceremos ter uma disponibilidade no-instantnea na perspectiva
daquela pessoa (e da primeira tarefa).
Um exemplo de disponibilidade no-instantnea que observei ocorreu com um engenheiro de build. A companhia tinha uma poltica que apenas o gerente de configurao da equipe pessoalmente poderia buildar o cdigo e empurr-lo para o ambiente
de teste. Esta poltica estava relacionada a uma estratgia de gerenciamento de risco
baseada na experincia que desenvolvedores eram menos cuidadosos e poderiam buildar cdigo que quebraria o ambiente de teste. O ambiente de teste era frequentemente
compartilhado entre muitos projetos, portanto o impacto de um build ruim era significante. O departamento de tecnologia no tinha uma boa capacidade de coordenao no
nvel de programa, e a probabilidade da equipe de um projeto estar trabalhando numa
rea de sistemas integrados de TI que poderia afetar outro projeto era muito grande. A
funo de coordenao tcnica para saber o que estava acontecendo no nvel de cdigo
entre e pelos projetos foi dada ao departamento de gerncia de configurao. Estes
profissionais eram conhecidos como engenheiros de build. O engenheiro de build era
responsvel por saber o impacto de um conjunto de mudanas em um determinado
build de software e por evitar a quebra do ambiente de teste a fim de que o fluxo de
todos os projetos no fosse afetado por uma queda do ambiente de teste.
Geralmente, um projeto tinha um engenheiro de build atribudo a partir do pool
compartilhado da equipe de engenheiros de configurao. No entanto, a demanda de
um nico projeto para builds de cdigo dentro do ambiente de teste no era suficiente
para manter um engenheiro de build ocupado por um dia inteiro. De fato, no era suficiente para mant-lo ocupado por mais do que uma ou duas horas por dia. Portanto, os
engenheiros de build eram solicitados a fazer vrias atividades em paralelo. Eles eram
alocados em vrios projetos, como tambm em outros deveres.
Pegue o exemplo de Doug Burros na Corbis; ele foi alocado em duas atividades: ele
tinha a responsabilidade de montar novos ambientes e tambm de manter os existentes. Ele era o engenheiro de gerncia de configurao com responsabilidade integral
de manter a configurao atual. Isto inclua aplicar patches e atualizaes de sistemas
operacionais e servidores de banco de dados, patches e atualizaes de middleware,
configurao de sistema e topologia da rede, entre outras coisas. Ele separava em torno
de uma hora por dia para realizar a tarefa de build; tipicamente pela manh, a partir de

Recursos Disponveis No - Instantaneamente

10:00 at 11:00. Caso os desenvolvedores solicitassem um build de teste s 3:00p.m.,


eles esperariam at o dia seguinte. O engenheiro de build no estava disponvel instantaneamente. O trabalho poderia ser bloqueado e, como a engenharia de suporte era
operada usando um sistema kanban, o trabalho poderia voltar toda a cadeia de valor,
causando tempo ocioso para muitos outros membros da equipe.
As aes tomadas em resposta ao problema de disponibilidade no-instantnea so
extraordinariamente parecidas quelas para recurso com capacidade limitada.

Aes de Explorao/Proteo
A primeira coisa foi reconhecer que Doug era um recurso disponvel no-instantaneamente e observar o impacto disso. O trabalho estava acumulando quando ele no estava
disponvel porque os limites do kanban eram firmemente definidos. Como Doug era
uma fonte de variabilidade no fluxo, o curso correto da ao foi colocar um buffer de
trabalho antes de Doug. O truque era fazer este buffer grande o suficiente para permitir
que o fluxo continuasse sem faz-lo to grande que Doug se tornaria um recurso de
capacidade restrita. Tive uma conversa com ele sobre a natureza da atividade de build.
Ficou claro que ele poderia fazer o build de sete itens dentro de sua hora por dia de
disponibilidade. Ento criamos um buffer com um limite kanban de sete. Introduzimos
isso na cadeia de valor e na parede de cartes incluindo uma nova coluna chamada
Build Ready. Ns aumentamos ento o potencial total do WIP no sistema para 20 por
cento, mas isso funcionou. Embora os builds no estivessem disponveis instantaneamente, era possvel manter o fluxo das atividades antes dele durante o dia. O resultado
foi um impulso significante no rendimento e um lead time menor, apesar do aumento
do WIP. Outra opo, na qual novamente ns no pensamos naquele momento, poderia ter sido solicitar a Doug trabalhar duas vezes por dia, meia hora cada, em vez de
uma hora seguida por dia. Essas duas vezes de meia hora cada uma teriam sido divididas no dia, uma pela manh, e outra tarde. Isso poderia ter facilitado o fluxo. O
efeito poderia ter sido reduo da presso para fazer o buffer da disponibilidade no-instantnea. Talvez o tamanho do buffer pudesse ter sido reduzido para dois ou trs.
Isso teria um impacto de apenas 10 por cento no total do WIP e poderia ter resultado
em um lead time menor atravs do sistema.
Como regra geral, quando encontrar problemas de disponibilidade no-instantnea,
pense em como melhorar a disponibilidade. A ltima opo tornar um problema de
disponibilidade no-instantnea num recurso disponvel instantaneamente.

217

218

Captulo 17 Gargalos e Disponibilidade No-Instantnea

Aes de Subordinao
Como discutido anteriormente, aes de subordinao geralmente envolvem mudanas nas polticas atravs da cadeia de valor a fim de maximizar a explorao do gargalo.
Quais as opes disponveis como aes de subordinao para o nosso engenheiro de
build disponvel no-instantaneamente?
A primeira coisa foi examinar a poltica de solicitar a Doug realizar trs funes
diferentes. Qual a melhor escolha? Eu conversei isso com a gerente de Doug. Parecia
que na equipe dela, os engenheiros gostavam e precisavam de diversidade no trabalho
para se manter interessados. Tambm, ao solicitar aos membros da equipe a realizao
do build do sistema, manuteno no sistema, e build de engenharia, manter-se-ia uma
habilidade generalista atravs de todos os membros da equipe e a manuteno do pool
de recursos flexvel. Isto forneceria ao gerente mais opes e evitaria o potencial de
gargalos de recurso com capacidade restrita devido a um alto grau de especializao.
A generalizao tambm apelava aos membros da equipe de uma perspectiva da carreira e currculo. Eles no queriam se tornar to restritivamente qualificados. Ento
solicitar equipe trabalhar em apenas uma rea, como engenharia de build, no era
desejado.
Outra opo poderia ter sido abandonar a ideia de mltiplas tarefas e dedicar o
esforo de Doug na equipe de suporte. Isto teria dado a ele muito tempo ocioso. Ele
poderia estar sentando a espera de trabalho, como um bombeiro no quartel esperando
uma chamada de um incndio. Manter Doug em constante espera certamente curaria
os problemas de fluxo, mas seria uma escolha razovel?
Os oramentos eram apertados e adicionar pessoas equipe de gerenciamento de
configurao para fazer as atividades de Doug, manipular os builds dos sistemas e manuteno, seria muito caro e talvez impossvel. Eu precisaria solicitar ao meu chefe um
oramento para ter outra pessoa porque eu queria ter algum ocioso a maior parte do
tempo. Isto seria uma boa negociao para gerenciamento de riscos?
Para decidir isto precisamos olhar para o custo do atraso da equipe de suporte e
compar-lo ao custo de ter outro membro na equipe e ao custo de alternativas para a
manuteno do fluxo. A realidade era que poucos itens na fila da equipe de suporte
tinham um custo de atraso significante. Ento a ideia de que manteramos algum
ocioso, esperando por trabalho, para aperfeioar o fluxo no era uma alternativa vivel.
Claramente, a ao de explorao ao adicionar um buffer de trabalho para manter o
fluxo era a alternativa melhor e mais barata.
No entanto, a conversa sobre o que fazer em relao a falta de disponibilidade instantnea de Doug criou um debate na equipe sobre a poltica de se ter apenas engenheiros de build realizando esse trabalho. Discutimos a opo de acabar com a poltica

Recursos Disponveis No - Instantaneamente

e permitir que desenvolvedores fizessem o build de cdigo e o jogassem no ambiente


de teste. Essa ideia foi rejeitada porque a organizao no tinha um mtodo alternativo
vivel para coordenar os riscos tcnicos atravs dos projetos. Uma opo de fornecer
um ambiente de teste dedicado para cada projeto foi rejeitada por motivos de custo e
no era uma alternativa prtica num perodo de tempo curto ou mdio. Todos continuaram a enxergar o valor da funo do engenheiro de build e da equipe de gerncia
de configurao.

Aes de Elevao
No entanto, fazer o buffer e adicionar WIP para resolver o problema era como um
Band-Aid sobre uma ferida (um paliativo). Era como uma alternativa de contorno. E
voc pode enxerg-la dessa maneira. Foi uma correo ttica uma correo ttica efetiva, mas, todavia uma correo ttica que gerou um custo. Como o sistema Kanban
foi exposto a um gargalo de disponibilidade no-instantnea e permitiu a equipe ter
um grande debate sobre a causa e as possveis correes, uma discusso sobre ter um
humano para fazer o build do cdigo como resposta foi inevitvel. Seria possvel automatizar o processo de build? A resposta foi Sim, embora o investimento fosse pesado.
Seria necessrio um desenvolvimento considervel da capacidade em gerncia de configurao e uma coordenao entre projetos. Adicionalmente, alguns especialistas em
automao deveriam ser contratados por um perodo de tempo para criar o sistema e
faz-lo funcionar.
Gastamos em torno de seis meses e tivemos dois contratados por oito semanas. O
financiamento total final ficou em torno de $60.000. No entanto, o resultado final foi
que Doug no foi mais requisitado a fazer builds, e os builds eram instantaneamente
disponibilizados assim que os desenvolvedores precisassem deles. Neste ponto foi possvel eliminar o buffer e reduzir o WIP do sistema. Isto resultou numa pequena reduo
do lead time.
A automao foi a ltima rota para elevao do gargalo de disponibilidade no-instantnea. Adicionar capacidade, isto , contratar outro engenheiro, no era uma
boa escolha.
Outro caminho que envolve automao tambm foi perseguido virtualizao de
ambientes. Virtualizao j foi lugar comum na nossa indstria; no entanto, naquele
momento nosso ambiente de teste ainda era fsico. Virtualizao no era uma capacidade organizacional. Ao se gastar tempo para que isto ocorresse, o ambiente de teste
poderia ser facilmente configurado e restaurado. Isto reduziria o impacto se um build
quebrasse o ambiente; em gerenciamento de risco isto uma estratgia de mitigao.

219

220

Captulo 17 Gargalos e Disponibilidade No-Instantnea

Isto tambm possibilitaria ambientes dedicados reduzindo ou eliminado o risco de


um build quebrar a configurao do projeto de outra pessoa.
Ento o buffer foi utilizado como uma estratgia de curto prazo e de explorao ttica, enquanto a automao foi perseguida como uma estratgia de elevao de longo
prazo.
E o nosso exemplo da balsa Edmonds-to-Kingston? Como ela poderia ser elevada?
Bem, o Estado de Washington est atualmente considerando duas opes. Uma seria
substituir as atuais balsas envelhecidas da frota por uma nova frota de barcos maiores
e mais eficientes. No entanto, Washington tem muita experincia com pontes flutuantes. H duas que atravessam o Lake Washington, incluindo uma na SR-520, que
aparentemente a ponte mais longa do mundo desse tipo, e outra que atravessa o Hood
Canal na SR-104. O que est sendo considerado agora a possibilidade de construo
em tempo recorde de uma nova ponte flutuante atravs do Puget Sound como parte
da SR-104 e a substituio completa da balsa. A ponte planejada no apenas resolveria
o problema de capacidade limitada em horrios de pico, como resolveria problemas
de disponibilidade no-instantnea que prejudicam todos os servios de balsa que
so uma opo para fluxo de trfego. Tal ponte abriria o crescimento da economia de
Kitsap e Olympic Pennsula. Talvez daqui a 50 anos algum esteja escrevendo um livro
discutindo como a ponte flutuante da SR-104 que atravessa o Puget Sound um gargalo
e um recurso de capacidade limitada durante os horrios de pico?

Takeaways
221

Takeaways
Gargalos restringem e limitam o fluxo de trabalho.
Gargalos aparecem de duas maneiras: capacidade limitada incapacidade
de realizar mais trabalho; e disponibilidade no-instantnea capacidade
limitada devido disponibilidade limitada (mas usualmente previsvel).
Gerenciamos gargalos usando o Five Focusing Steps da Teoria das Restries.
Aumentar a capacidade de um gargalo conhecido como elevao.
As aes tomadas para elevar um recurso de capacidade limitada sero tipicamente diferentes das aes tomadas para elevar um recurso de disponibilidade no-instantnea.
Elevao pode envolver incluso de recursos, ou automao, ou mudanas
em polticas que fazem com que o recurso previamente no disponvel instantaneamente torne-se disponvel.
Aes de elevao tipicamente so custosas e levam tempo para serem implementadas. Aes de elevao so frequentemente consideradas investimentos
estratgicos em melhoria de processo.
Frequentemente os gargalos no processo esto atuando bem abaixo da sua
capacidade potencial - abaixo da capacidade restrita terica.
O rendimento de um gargalo pode ser melhorado acima do limite da capacidade restrita terica utilizando aes de explorao e proteo.
Tipicamente, proteo envolve adicionar um buffer de WIP em frente ao
gargalo. Isto verdadeiro para recursos de capacidade limitada ou recursos
disponveis no-instantaneamente.
Aes de explorao tipicamente envolvem mudanas em polticas que controlam o trabalho realizado pelo recurso do gargalo.
Classes de servio podem ser usadas como aes de explorao.
Aes de subordinao so tomadas em qualquer lugar da cadeia de valor
a fim de possibilitar a explorao desejada ou aes de proteo. Aes de
subordinao so tipicamente mudanas de polticas.
Aes de explorao, proteo e subordinao so frequentemente fceis e
baratas de se implementar, visto que elas envolvem primariamente mudanas nas polticas. Portanto, maximizar o rendimento de um gargalo atravs

222

Captulo 17 Gargalos e Disponibilidade No-Instantnea

de uma explorao completa pode ser vista como uma melhoria ttica de
processo.
Apesar da natureza ttica de explorao de um gargalo, os ganhos so frequentemente muito bons. Melhorias no rendimento de uma vez e meia a
cinco vezes com uma consequente queda do lead time, podem ser alcanadas
com pequeno ou nenhum custo durante um perodo curto de meses.
Explorao sempre deve ser perseguida primeiramente, antes de se tentar
elevao.
No incomum que um conjunto de aes de explorao e subordinao
tticas seja implementado enquanto um plano para uma mudana estratgica
para elevar uma restrio seja implementado durante um longo perodo de
tempo.

C aptulo 18

Um Modelo Econmico
para Lean

esperdcio (ou muda em Japons) a metfora usada em Lean


(e no Toyota Production System) para atividades que no agregam valor ao produto final. A metfora do desperdcio tem se provado problemtica com trabalhadores do conhecimento.
Frequentemente difcil aceitar como desperdcio tarefas ou atividades que so custosas ou dispendiosas, mas so necessrias ou essenciais para completar um trabalho com valor agregado; por exemplo,
reunies stand-up dirias so necessrias para coordenar a maioria
das equipes. Essas reunies no agregam valor direto ao produto final,
ento, tecnicamente, elas so desperdcio, mas isso tem sido difcil
de aceitar pela maioria dos desenvolvedores geis praticantes. Em vez
ter pessoas confusas com argumentos sobre o que desperdcio ou
no, eu conclu que seria melhor encontrar um paradigma alternativo
e uma linguagem alternativa menos confusa ou com um apelo emocional.

Redefinindo Desperdcio
Seguindo autores lderes como Donald G. Reinertsen, adotei o uso do
linguajar econmico e me refiro a essas atividades de desperdcio
como custos. Classifico custos em trs categorias abstratas principais:

223

224

Figure 18.1!

Captulo 18 Um Modelo Econmico para Lean

Trabalho com Valor


Agregado!
Carga de Falha!

Custos de
Transao!

Custos de
Transao!

custo!

Custos de Coordenao!

tempo!
Figura 18.1 O modelo Econmico de Custo para o desenvolvimento de software Lean

Custos de Transao; Custos de Coordenao; e Carga Defeituosa. A figura 18.1 ilustra


isto.
A figura 18.1 mostra que no passar do tempo h um nmero de atividades de valor
agregado para uma iterao ou projeto. Ao redor destas atividades esto os custos de
transao e coordenao. A capacidade para atividades de valor agregado pode ser deslocada para trabalhos que so considerados carga defeituosa, isto , trabalho que ou retrabalho ou demanda colocada no sistema devido a uma implementao anterior ruim.
Cada um destes custos discutido em detalhes nas sees seguintes. Eu os descreverei usando um exemplo simples do mundo real a atividade de pintar a cerca na
minha casa em Seattle com um conservante de madeira colorido.

Figura 18.1 O modelo Econmico de Custo para o desenvolvimento de software Lean

Custos de Transao
A cerca tem vinte e uma partes. O valor do cliente a entrega de uma parte da cerca
pintada com o conservante de madeira. O valor completo da entrega quando as vinte
e uma partes esto pintadas em ambos os lados.
Antes de comear o trabalho, eu tinha primeiramente que procurar todos os materiais. Isto envolveu uma ida a Home Depot. Havia tambm um trabalho de preparao da cerca: reparar, lixar, e aparar as plantas e arbustos a fim de permitir acesso ao
trabalho de pintura. Nenhuma destas atividades poderia ser descrita como de valor
agregado. O cliente no se preocupa se eu precisei ir a Home Depot. O cliente no se
preocupa se esta atividade demanda tempo. De fato, ela irritante, visto que atrasa o
incio e o final do projeto. Todas estas atividades atrasaro a entrega de valor ao cliente.

Custos de Transao

Ento o projeto tem algumas atividades de configurao que so essenciais antes de


se iniciar o trabalho de valor agregado.
Podem existir outras. Pode existir um planejamento. Pode existir tambm uma atividade de estimativa e um nivelamento de expectativas. O cliente pode ter cotado um
preo para o trabalho e a data de entrega. (Neste caso, o cliente do projeto era a minha
esposa.)
Quando realmente comeou o trabalho de pintura, conclu que quarenta e duas
partes da cerca era muita coisa para uma sesso simples. A velocidade da pintura foi de
aproximadamente quatro partes por hora. Ento o trabalho foi dividido em seis sesses.
Se isso fosse desenvolvimento de software, chamaramos isto de iteraes ou sprints.
Se fosse manufatura chamaramos de batches. Quando comecei uma sesso de pintura
simples, eu tambm tinha algumas atividades de configurao. A primeira era mudar
de roupa. Ento eu deveria arrumar os materiais: deveria mover a tintura, escovas, e
outras ferramentas da garagem para o lugar adequado para aquele dia de pintura; s
ento eu poderia comear a pintar.
Resumindo, projetos e iteraes tm atividades de configurao.
Aps algumas horas de pintura, eu queria fazer uma parada. Talvez fosse a hora do
almoo, mas eu no poderia simplesmente deixar tudo e comear a almoar. Eu devia
primeiramente me assegurar de que a lata da colorao foi fechada, e ento deixar as
escovas protegidas, limpando-as ou jogando-as num jarro de gua prevenindo que elas
no enduream enquanto fao uma parada. Depois precisaria me limpar. Eu lavo as
minhas mos e tiro meu macaco de trabalho; s ento posso ir almoar.
Quando todo o projeto foi finalizado, uma parte do conservante de madeira sobrou,
e toda lata cheia pode retornar a Home Depot para reembolso. Ento foi necessria
outra ida para a Home Depot.
Parece que tanto projetos como iteraes tm um conjunto de atividades de limpeza.
Em termos econmicos, estas atividades de configurao e limpeza so referidas
como custos de transao. Toda atividade de valor agregado tem custos de transao
associados. Estas atividades de custo de transao so coisas que o cliente no v e a
maioria no d valor, e para as quais eles so no mximo ambivalentes. O cliente pode
ser forado a pagar os custos destas atividades, mas preferiria no faz-lo. Quo frequentemente voc chama um encanador para consertar sua mquina de lavar roupas
ou mquina de lavar pratos e cobrado por um valor de $90 de honorrios? Este
um custo de transao. Voc preferiria um valor menor? Escolheria um encanador
que no cobrasse esta taxa? Os custos de transao no agregam valor. Eles podem ser
necessrios, mas em termos Lean, eles so desperdcio.
Ento os dois primeiros tipos de desperdcio so custos de transao, especificamente: a configurao, ou front-end, e a limpeza, ou custos de transao de back-end.

225

226

Captulo 18 Um Modelo Econmico para Lean

Se voc considerar isto para as atividades de desenvolvimento de software, voc notar que todos os projetos tm um nmero de atividades de configurao, como planejamento de projeto, planejamento de recursos e recrutamento, precificao, estimativa,
planejamento de risco, planejamento da comunicao, aquisio de instalaes, e assim
por diante. A maioria dos projetos tambm tem custos de limpeza e outros custos de
transao de back-end, como entrega para o cliente, desmontagem de ambientes, retrospectivas, auditorias, treinamento para usurio, e assim por diante.
Iteraes tambm tm custos de transao, incluindo o planejamento da iterao e a
seleo do backlog (ou requisitos do escopo), talvez estimativa, oramento, alocao de
recursos, e setup* do ambiente. No back end, elas tero custos de transao que incluem
integrao, entrega, retrospectiva e configurao do ambiente.

Custos de Coordenao
necessrio coordenao to logo tenhamos duas ou mais pessoas tentando alcanar
um objetivo em comum, juntas. Inventamos sistemas de linguagem e comunicao
para a coordenao entre humanos. Quando combinamos em nos encontrar com amigos, beber, jantar, e assistir um cinema na noite de sexta-feira, ns incorremos em
custos de coordenao. Todos os emails, mensagens de texto, e chamadas telefnicas
que so necessrias para organizar a noite social so custos de coordenao.
Ento custos de coordenao em projetos qualquer atividade que envolve comunicao e agendamento. Quando pessoas na equipes de projeto reclamam que elas no
podem fazer trabalho de valor agregado como anlise, desenvolvimento, ou teste
porque elas esto respondendo a emails, elas esto realizando um conjunto de atividades de coordenao: cada email lido e respondido uma atividade de coordenao.
Quando elas reclamam que elas no conseguem realizar trabalho de valor agregado
como anlise, programao, ou teste porque elas esto sempre em reunies, estas
reunies tambm so custos de coordenao.
De maneira geral, qualquer forma de reunio uma atividade de coordenao, incluindo as favoritas da comunidade gil, como reunies standup dirias, a menos que a
reunio seja projetada para produzir uma entrega de valor ao cliente. Se trs desenvolvedores se juntam em frente a um quadro branco e modelam um projeto para o cdigo
que eles vo implementar, isto no uma atividade de coordenao, ela uma atividade
de valor agregado. Porque? Ela de valor agregado porque ela produz informao que
est diretamente relacionada a uma funo de valor para o usurio.
* N. de T.: Termo no traduzido devido sua utilizao mais ampla no idioma original (Ingls) pela comunidade de TI no
Brasil. Traduo: configurao.

Custos de Coordenao

Se enxergarmos desenvolvimento de sistemas e de software como um processo de


chegada de informaes, no qual nosso ponto inicial no tem informao, e ter a informao completa significa trabalhar em funcionalidades que atendem s necessidades
do cliente, ento qualquer informao que chega entre o ponto inicial e o ponto final
que nos move para frente no trabalho em funcionalidades que atendem s necessidades
do cliente de valor agregado.
Se os membros da equipe se renem para criar informao de valor agregado, como
projeto, um teste, uma parte da anlise, ou parte do cdigo, ento esta reunio no
um custo de coordenao, uma atividade de valor agregado.
No entanto, se os membros da equipe se renem para discutir status, ou atribuio
de atividades, ou cronograma que ajudam a coordenar suas aes e o fluxo de entrega,
essa reunio um custo de coordenao e deve ser considerada desperdcio. Como tal,
voc deve procurar reduzir ou eliminar reunies de coordenao.
Portanto, um standup de 5 minutos melhor do que um standup de 15 minutos se
ela alcana a mesma quantidade de coordenao. Um standup de 15 minutos melhor
do que um standup de 30 minutos se ele atinge a mesma quantidade de coordenao.
Voc pode pensar em reduzir atividades de coordenao encontrando maneiras
melhores de coordenar pessoas.
Uma maneira dar poder a equipe para se auto-organizar. Gerenciamento do tipo
comandar-e-controlar, no qual as pessoas se renem para atribuir tarefas aos indivduos um desperdcio. melhor deixar a equipe auto-organizar suas tarefas. Autoorganizao geralmente reduz os custos de coordenao em um projeto. No entanto
para que funcione ela requer informao. Tcnicas dentro do Kanban como o uso
de acompanhamento visual da cadeia de valor e visualizao do trabalho usando uma
parede de cartes e ferramentas eletrnicas e relatrios fornecem informao de
coordenao que possibilita auto-organizao e reduz os custos de coordenao no
projeto. O uso de classes de servio e visualizao delas com cartes coloridos ou raias
na parede de cartes, junto com um conjunto de polticas para classes de servio, possibilitam auto-organizao de cronograma e priorizao automtica. Isto algumas vezes
referenciado como auto-expedio (um termo que associo a Eli Goldrat na referncia
a gerenciamento de buffer).
De maneira geral, quanto mais informao pode ser transparente para os trabalhadores do conhecimento da equipe, mais a auto-organizao ser possvel e menos atividades de coordenao sero necessrias. Deixe a transparncia no trabalho, fluxo do
processo, e polticas de gerenciamento de risco deslocar as atividades de coordenao.
Reduza desperdcio atravs de um uso abrangente de transparncia.

227

228

Captulo 18 Um Modelo Econmico para Lean

Como voc Sabe se uma Atividade um Custo?


Eu descobri que muitas pessoas tm problema em identificar atividades de desperdcio.
Tenho visto, por exemplo, defensores geis concordarem que reunies standup dirias
tm valor agregado. Eu no concordo com essa viso. Eu no posso saber se o cliente
se preocupa ou no se a equipe faz reunies standup ou no. O que o cliente quer
funcionalidade que atenda os seus objetivos, entregue na data com alta qualidade. Se
a equipe precisa ou no fazer reunies standup dirias para atender a entrega no vai
nem vem na sua perspectiva.
Ento como identificar atividades de custos de transao ou coordenao que geram
desperdcio?
Acredito que fazer a seguinte pergunta a voc mesmo, Se esta atividade agrega valor
verdadeiramente, eu a faria mais?.
Quando voc pergunta aos defensores do Scrum que veementemente concordam
que reunies standup dirias agregam valor, se eles fariam o standup duas vezes ao
dia ou se eles a aumentariam de 15 minutos para 30 minutos, eles com certeza iro
responder, No!.
Bem, se reunies standup verdadeiramente agregam valor, Eu respondo, ento
faz-las com uma frequencia maior uma coisa boa!
Este realmente um teste cido que demonstra a diferena entre uma atividade que
verdadeiramente agrega valor e um custo de transao ou coordenao. Desenvolver
mais requisitos do cliente claramente agrega valor. Voc faria mais se pudesse e o cliente
alegremente pagaria mais por isso. Planejamento claramente no agrega valor. O cliente
no pagaria por mais planejamento se ele pudesse evitar.
Ento pergunte a voc mesmo, Eu faria mais disso? Desafie outras pessoas com a
mesma pergunta sobre as atividades que eles empreenderiam. Se a resposta , No,
ento considere o que voc deve fazer para minimizar tempo e energia gastos na atividade, ou como voc poderia tornar a atividade mais efetiva, e, portanto, reduzir a
durao, frequncia, ou quantidade da atividade.
Algumas vezes pode ser difcil determinar se uma atividade um custo de transao
ou coordenao. Algumas atividades frequentemente parecem com os dois. Eu vejo
essa confuso a todo o momento ensinando Kanban. Como eu fao com os participantes das aulas, eu incitaria voc a no desperdiar muita energia tentando determinar
a diferena. O que importante voc identificar uma atividade que no agrega valor
e, portanto, um desperdcio e voc saber que voc quer reduzir ou eliminar essa
atividade como parte de um programa de melhoria contnua.

Carga Defeituosa

Carga Defeituosa
Carga defeituosa uma demanda gerada pelo cliente que deve ser evitada atravs de
entregas de qualidade antecipadamente. Por exemplo, vrias chamadas de help desk
geram custos para o negcio. Se o produto ou servio de software ou tecnologia forem
de alta qualidade, mais usveis, mais intuitivos, mais adequados ao propsito, ento
haver menos chamadas. Isso pode possibilitar ao negcio reduo do nmero de
pessoas no call center e reduo de custos.
Vrias chamadas tendem a gerar muitos tickets de defeito em produo. Na seleo
das funes do escopo para um projeto ou iterao, o negcio deve escolher entre
novas ideias e defeitos em produo. Defeitos em produo no so apenas defeitos
no software; eles incluem problemas de usabilidade e outros problemas no-funcionais
como baixo desempenho, falta de resposta sobre carga ou certas condies na rede, e
assim por diante. A resoluo para um defeito de produo em relao a um requisito
no-funcional pode parecer uma nova funcionalidade um design para uma nova tela
talvez mas na verdade no . uma carga defeituosa. Aquele design da nova tela veio
tona devido a um defeito de usabilidade de um release anterior.
Carga defeituosa no cria novo valor; ela faz com que o valor de um release anterior
no seja alcanado. Embora alguns deles possam estar relacionados a variabilidade
do mercado ou imprevisibilidade, ser descoberto que alguns dos dficits vieram de
problemas de releases anteriores. Talvez um erro no produto evite o uso de alguma
funcionalidade. Por causa disto, clientes potenciais se desligam do produto e retardam
a compra ou escolhem um produto concorrente.
Ento a figura confusa. Carga defeituosa ainda agrega valor. Mas o que importante que ela agrega valor que j deveria estar l. Reduzir carga de defeitos reduz
a oportunidade do custo de atraso. Reduzir custos significa mais lucros mais cedo.
Reduzir carga defeituosa significa mais capacidade disponvel para ser gasta em novas
funcionalidades. Reduzir carga defeituosa permite ao negcio perseguir mais nichos
de Mercado, oferecendo mais produtos. Reduzir carga defeituosa permite mais opes.
Reduzir carga defeituosa pode permitir uma reduo no tamanho da equipe, e, portanto, uma reduo direta dos custos.

229

230

Captulo 18 Um Modelo Econmico para Lean

Takeaways
Desperdcio pode ser classificado em trs categorias abstratas principais: custos de transao, custos de coordenao e carga defeituosa.
O conceito de desperdcio uma metfora.
A metfora do desperdcio no funciona bem para todos, visto que desperdcio frequentemente necessrio, embora no agregue valor especificamente.
Como resultado, eu o substitu por um modelo econmico de custos.
Para determinar se uma atividade verdadeiramente um desperdcio pergunte, Eu faria mais dela se pudesse? Se a resposta for no, ento a atividade
alguma forma de desperdcio.
Custos de transao so de dois tipos: atividade de configurao e limpeza,
ou atividade de entrega.
Custos de coordenao so atividades que so realizadas para atribuir tarefas
s pessoas, agendar eventos, ou coordenar o trabalho de duas ou mais pessoas
em direo a uma sada comum.
Carga defeituosa um trabalho de valor no agregado que gerado devido
a alguma falha anterior, como um defeito no software, ou por um projeto ou
implementao ruim que levou a uma falta de adoo pelo cliente, uma falha
em notar a funo de retorno, ou uma chegada significante de chamadas no
help desk ou requisies de servio.
Carga defeituosa usa capacidade que poderia ser utilizada para features
novas, inovadoras, de valor agregado para o cliente e que geram retorno.
Transformar ideias em trabalho e entregar cdigo ao cliente mais rapidamente maximiza o potencial do valor e minimiza o desperdcio.

C aptulo 19

Fontes de Variabilidade

ariabilidade tem sido estudada desde o incio de 1920 no processo industrial. O pioneiro no assunto foi Walter Shewhart.
Suas tcnicas tornaram-se a fundao para o movimento de garantia
da qualidade e so elementos fundamentais dos mtodos para qualidade e melhoria contnua Toyota Production System e Six Sigma. As
tcnicas de Shewhart foram adotadas, desenvolvidas, e avanadas por
W. Edwards Deming, Joseph Juran, e David Chambers. O trabalho
dessas pessoas inspirou Watts Humphrey e os membros fundadores
do Software Enginnering Institute na Carnegie Mellon University, que
abraaram a crena de que o estudo da variabilidade e sua reduo
sistemtica poderiam trazer grandes benefcios para a profisso de
engenharia de software.
H uma grande quantidade de material publicado por Shewhart,
Deming e Juran no estudo da variabilidade e seu uso como uma
tcnica de gerenciamento e base para um programa de melhorias.
Adicionalmente, muito tem sido publicado sobre o mtodo de avaliao quantitativo conhecido como Statistical Process Control (SPC)
que surgiu como a ferramenta principal para o estudo da variao
e as aes sobre ela. Durante a escrita desse livro, o uso de SPC est
surgindo com equipes que adotam Kanban. No entanto, o uso de SPC
considerado um tpico avanado e de alta maturidade que ser visto

231

232

Captulo 19 Fontes de Variabilidade

mais a frente neste livro. Aqui falaremos sobre variao em termos mais gerais na sua
forma mais simples.
Shewhart classificou variabilidade e variao no processo de desempenho em duas
categorias: interna e externa.
Fontes internas de variao so variaes que esto sob o controle do sistema em
operao. Com Kanban para engenharia de software e operaes de TI, pensamos no
sistema como um processo que definido por um conjunto de polticas que governam
a operao do sistema. Elas podem ser afetadas diretamente por mudanas realizadas
por indivduos, a equipe, ou gerncia. Mudanas nas polticas mudam a operao do
sistema e o seu desempenho. Portanto, uma mudana na definio do processo, representa uma mudana que afeta as fontes internas de variao. Ironicamente, Shewhart
nomeou estas variaes geradas internamente de variao de causa aleatria chance-cause variations. Aleatria implica que a variao aleatria e a aleatoriedade
uma consequncia direta do projeto do sistema. Isso no implica que a aleatoriedade
distribuda uniformemente ou segue uma distribuio padro. Mudanas no processo
do projeto a partir de mudanas nas polticas internas afetaro qualquer mdia da
variao, propagao, e forma da distribuio.
Para usar um exemplo geral, um rebatedor no jogo de baseball tem uma taxa de acertos (conhecida como mdia de crquete) que indica a frequncia com a qual ele acerta
arremessos que alcanam a primeira base, ou mais. Rebatedores diferentes exibem
taxas diferentes, com um intervalo tpico de aproximadamente 0.100 a 0.350. Em um
determinado dia, um rebatedor pode no alcanar sua taxa de arremesso tpica. Isto
determinado por alguns fatores como seleo do arremesso, o quo bem os jogadores
acertam a bola, e arremessos especficos.
Se mudarmos as regras do baseball para permitir, digamos quatro golpes antes que
um rebatedor estivesse fora, ento mudaramos as probabilidades em favor do rebatedor em relao ao arremesso. Como resultado a mdia do rebatedor aumentaria. Como
resultado dessa regra, alguns jogadores mais talentosos poderiam muito bem alcanar
taxas de acerto mais altas como 0.500. Este um exemplo de alterao no sistema que
modifica a variao de causa aleatria dentro do sistema.
Se interpretarmos isso para um exemplo especfico em desenvolvimento de software,
uma variao interna de causa aleatria seria o nmero de defeitos criados por linha de
cdigo, por requisito, por tarefa, ou por unidade de tempo. O valor mdio, a propagao, e a distribuio da taxa de defeito podem ser afetados mudando-se as ferramentas
e o processo, como insistir em testes unitrios, integrao contnua, e reviso em pares.
A definio de processo em uso pela sua equipe, expressa como as polticas representam as regras do jogo colaborativo de desenvolvimento de software. As regras do
jogo determinam as fontes e a quantidade de variao interna. A ironia est na noo

Fontes Internas de Variabilidade

de que variaes de causa aleatria esto na verdade diretamente sob o controle da


equipe e gerncia atravs da sua habilidade de modificar polticas, mudar o processo,
e afetar fontes de variao interna.
Fontes externas de variao so eventos que acontecem que esto fora do controle da
equipe ou gerncia imediata. Elas so aleatoriedades que vm de outras equipes, fornecedores, clientes, so atos de Deus aleatrios, como eles so conhecidos na indstria
de segurana; por exemplo, a interrupo de duas semanas de um server farm causada
por uma inundao devido a um temporal. Fontes externas de variao requerem uma
abordagem diferente de gerenciamento. Elas no podem ser afetadas diretamente por
polticas, mas um processo pode ser colocado em uso para lidar efetivamente com
variaes externas. O corpo de conhecimento que se relaciona diretamente com esse
campo o gerenciamento de problemas e risco.
Shewhart nomeou variaes externas como variaes causadas por atribuio
assignable-cause variations. Por atribuio, ele coloca que algum (ou um grupo de
pessoas) pode facilmente apontar para a fonte do problema e descrev-la consistentemente como um, Havia uma tempestade. Choveu muito forte e nosso server farm foi
inundado. . Variaes causadas por atribuio no podem ser controladas pela equipe
ou gerncia local, mas podem ser previstas, e planos podem ser feitos e processos projetados para lidar com elas adequadamente.

Fontes Internas de Variabilidade


O processo de desenvolvimento de software e gerenciamento de projeto em uso, acoplados a uma maturidade organizacional e capacidade dos indivduos da equipe determina a quantidade de fontes internas de variabilidade e o grau desta variabilidade.
Para evitar confuso, Kanban no deve ser pensado como um processo de ciclo de
vida de desenvolvimento de software ou um processo de gerncia de projeto. Kanban
uma tcnica de gerenciamento de mudana que requer alteraes no processo existente: mudanas como adicionar limites de trabalho-em-progresso no processo.

Tamanho do Item de Trabalho


O mtodo de anlise usado para quebrar os requisitos e especific-los para desenvolvimento tem o seu prprio grau de variabilidade. Uma dimenso para isto o tamanho
dos itens de trabalho. A literatura prvia que descreve o mtodo Extreme Programming
explica user stories como uma descrio narrativa de uma feature como implementada
e usada por um usurio final, escrita num carto. A nica restrio era o tamanho do

233

234

Captulo 19 Fontes de Variabilidade

carto. O esforo requerido para criar uma user story foi descrito como qualquer coisa
entre metade de um dia a 5 semanas de trabalho. Em alguns anos, um template para
escrita de user stories surgiu de uma comunidade em Londres.
As a <user>, I want a <feature>, in order to <deliver some value>

O uso deste template padronizou enormemente a escrita de user stories. Um dos


criadores dessa abordagem, Tim McKinnon, relatou para mim em 2008 que agora ele
tinha dados para apresentar que a mdia do esforo para uma user story era 1.2 dias
e a propagao da variao era de aproximadamente metade de um dia a quatro dias.
Este um exemplo especfico de reduo da variao de causa aleatria no mtodo
Extreme Programming solicitando equipe a padronizar a escrita de user stories usando
um template. Fazendo isso, Tim mudou as regras do jogo. As regras originais solicitavam aos membros da equipe a escrever stories em cartes numa forma narrativa, e
as novas regras solicitavam a eles continuar a escrita em cartes, mas seguindo um
formato de sentena especfico. Estas mudanas estavam claramente sob a influncia
e controle dos gerentes locais. Elas so internas ao sistema. O tamanho de uma user
story controlado por variao de causa aleatria.

Mesclas de Tipos de Item de Trabalho


Quando todo o trabalho tratado da mesma maneira, e nomeado por um nico tipo,
h uma probabilidade de uma variao maior no tamanho, esforo, risco, ou outros
fatores. Quebrando o trabalho em tipos especficos, possvel tratar tipos diferentes
de formas diferentes e fornecer uma previsibilidade maior.
Por exemplo, a comunidade Extreme Programming desenvolveu definies de tipo
para tamanhos de stories diferentes. Elas adquiriram nomes como picas ou gro de
areia. Uma story pica deve ser uma story grande que precisar de muitas pessoas e
muitas semanas para ser desenvolvida, enquanto que um gro de areia deve ser uma
story pequena que pode ser completada por um nico desenvolvedor ou um par de
desenvolvedores em poucas horas. Adotando esta nomenclatura pica, Story, e Gro
de Areia temos agora trs tipos. Para cada tipo individual, a propagao da variao
ser menor do que seria se todo o trabalho fosse tratado como uma story nica.
Dentro de um departamento de desenvolvimento de software tpico devem existir
diferentes tipos de trabalho. Deve existir trabalho de valor para o cliente com um nome
como feature, story ou use case. Como descrito, eles devem ser estratificados em
elementos de tamanho, ou em algum subtipo de domnio ou perfil de risco. Devem
existir trabalhos de remoo de defeitos como production bugs ou (internal) bug.

Fontes Internas de Variabilidade

Deve existir trabalho de manuteno descrito como refactoring, re-architecting, ou


simplesmente upgrading. Softwares que operam sistemas, bancos de dados, plataformas, linguagens, APIs, e arquiteturas de servio mudam no decorrer do tempo e o
cdigo base precisa ser atualizado para enderear as mudanas.
Uma estratgia adicional para melhorar a previsibilidade alocar capacidade total
de WIP para tipos especficos. Por exemplo, com a minha equipe de manuteno na
Corbis, eram permitidos apenas dois itens IT Maintenance a qualquer momento. Isto
limitou a capacidade a ser utilizada nas atualizaes de API e banco de dados. Esta
estratgia particularmente til quando os tipos so divididos por tamanho e esforo
requeridos, como picos, story e gro de areia. Alocando capacidade especfica para
cada tipo, a resposta do sistema mantida e a previsibilidade maior.
Considere uma equipe com um quadro Kanban no qual h um limite de duas stories
picas, oito stories regulares, e quatro stories gro de areia. Duas picas esto em progresso. Um slot abre na fila para uma story regular, mas no h nenhuma no backlog
pronta para ser iniciada. A equipe pode escolher comear uma story pica ou gro de
areia, ou se ater ao tipo de alocao e incorrer em algum tempo ocioso.
Se eles comeam uma story pica, e alguns dias depois uma story regular aparece
no backlog, eles sero incapazes de iniciar uma story regular por algum tempo. Isto
aumentar o lead time para as stories regulares.
Comear um gro de areia menor uma escolha melhor, visto que ela deve acabar
antes de outra story regular estar pronta para ser iniciada. Neste caso, no h impacto,
mas h um benefcio de rendimento adicional. No entanto, se eles no tiverem sorte
e falharem em completar o item menor antes de uma story estar pronta para iniciar,
ento o lead time das stories regulares ser afetado adversamente, embora de maneira
mais leve do que no cenrio pico.
Previsibilidade e gerenciamento de riscos devem ser trunfos tpicos para oportunidade de aumento do rendimento, visto que os donos do negcio e gerentes seniores
valorizam mais previsibilidade do que rendimento. Previsibilidade constri e mantm
confiana, um dos principais valores geis, melhor do que entregar mais com menos
confiana.

Mesclas de Classes-de-Servio
Se considerarmos as classes de servio descritas no captulo 11, podemos antecipar
como a variabilidade pode ser afetada mesclando os itens. Se uma organizao sofre
com uma grande quantidade de requisies de expedio, isto tornar tudo aleatrio,

235

236

Captulo 19 Fontes de Variabilidade

aumentando a mdia de lead time e a propagao de variao, reduzindo a previsibilidade de todo o sistema.
Requisies de expedio so essencialmente variaes externas e sero descritas
na prxima seo.
Se a demanda por outras classes de servio relativamente estvel, o desempenho
do lead time para cada classe de servio deve ser relativamente confivel. A mdia e
a propagao da variao devem ser mensurveis e devem permanecer constantes de
alguma maneira. Isto fornece previsibilidade. Voc pode alcanar isto se o backlog
suficientemente grande e cheio de uma grande quantidade mesclada de cada classe.
Aloque um limite de WIP para cada classe de servio. Isto possibilitar que a mdia e
a propagao da variabilidade se estabeleam e o sistema ser previsvel.
Se a demanda varivel por exemplo, se h apenas poucos itens de data de entrega
fixa e eles tendem a ser sazonais, alguma ao deve ser tomada para dar forma e controlar a demanda: devem ser institudas mudanas na alocao de limites de WIP atravs
dos tipos, sazonalmente, para antecipar mudanas na demanda, ou, alternativamente,
mudanas nas polticas para puxar associadas a um conjunto de classes de servio em
cascata devem ser feitas sazonalmente para lidar com flutuaes na demanda.
Considere uma equipe com um limite de WIP de 20, alocados como 4 itens de data
fixa, 10 itens de classe padro, e 6 itens de classe intangvel. Voc pode ter uma poltica
onde estes limites devem ser estritamente seguidos, ou, voc pode afrouxar a regra e
permitir que um item padro ou intangvel preencha um slot de um item de data fixa
quando h demanda sazonal insuficiente para itens de data fixa. Estas polticas podem
ser trocadas em pocas diferentes do ano para melhorar o resultado econmico global
e garantir que o sistema permanea relativamente previsvel.

Fluxo Irregular
Fluxo irregular de trabalho pode ser causado por fontes de variao externa e interna.
Cada item nico puxado pelo sistema kanban ser diferente: diferentes em natureza em
algum grau, diferentes no tamanho, complexidade, perfil de risco e esforo requeridos.
A aleatoriedade natural disto causar altos e baixos no fluxo. Um sistema kanban naturalmente lida com isto medida que os limites de WIP so reforados. No entanto, a
variabilidade maior de outras fontes, como tamanho do item de trabalho, padres de
demanda, mescla de tipos, mescla de classes de servio, e fontes externas, requerem um
buffering adequado para absorver os altos e baixos no fluxo atravs do sistema. Buffers
adicionais podem ser necessrios e os limites de WIP devero ser maiores quando
h mais variabilidade no sistema. Limites de WIP maiores resultaro em lead times

Fontes Externas de Variabilidade

maiores, mas o fluxo mais suave deve reduzir a variabilidade. Portanto, aumentar o
limite de WIP para suavizar o fluxo aumentar o lead time mdio e reduzir o intervalo
da variabilidade do lead time. Este geralmente o resultado mais desejado dos gerentes,
proprietrios, e usualmente clientes, valorizar previsibilidade em relao a uma chance
aleatria de um lead time menor ou rendimento maior.

Rework
Rework*, devido a defeitos internos sendo corrigidos antes do release ou defeitos em
produo deslocando novos trabalhos de valor agregado ao cliente, afetam a variabilidade. Se uma taxa de defeito conhecida, medida regularmente, e razoavelmente
constante, o sistema pode ser projetado para lidar com isso graciosamente. Tal sistema
ser economicamente ineficiente, mas ele deve ser confivel. O que causa uma falta de
previsibilidade quando a taxa de defeito no prevista corretamente. Rework devido
a defeitos no planejados aumenta o lead time, tende a aumentar a propagao da variao, e reduz enormemente o rendimento. Parece ser muito difcil planejar uma taxa de
defeito especfica, por exemplo, oito defeitos por user story, muito menos saber ou ser
capaz de prever seu tamanho ou complexidade. A melhor estratgia para reduo da
variabilidade devido a defeitos perseguir incansavelmente alta qualidade com uma
quantidade muito baixa de defeitos.
Fazer mudanas no processo de ciclo de vida do desenvolvimento de software pode
afetar muito as taxas de defeito. Uso de reviso em pares, programao em pares, testes
unitrios, framework de testes automticos, integrao contnua (ou muito frequente),
batch de tamanho pequeno, arquiteturas definidas corretamente, e projeto de cdigo
bem elaborado, fracamente acoplado e de alta coeso reduzir enormemente os defeitos. Mudanas que afetam diretamente as taxas de defeitos e indiretamente melhoram
a previsibilidade do sistema esto sob o controle direto da equipe e gerncia local.

Fontes Externas de Variabilidade


Fontes externas de variabilidade vm de lugares que no so diretamente controlados pelo processo de desenvolvimento de software ou mtodo de gerncia de projeto.
Algumas destas viro de partes do negcio ou cadeia de valor, como fornecedores ou
clientes. Outras fontes externas incluem elementos do mundo fsico que no podem ser

* N. de T.: Termo no traduzido devido sua utilizao mais ampla no idioma original (Ingls) pela comunidade de TI no
Brasil. Traduo: retrabalho.

237

238

Captulo 19 Fontes de Variabilidade

facilmente antecipados, previstos, ou controlados por exemplo, parte do equipamento


falhar ou condies de tempo adversas.

Ambiguidade de Requisitos
Requisitos mal escritos, planos de negcio mal definidos, e falta de planejamento estratgico, viso, ou outra informao de definio do contexto pode significar que um
membro da equipe incapaz de tomar uma deciso e, portanto, incapaz de completar
uma parte do trabalho. Um item de trabalho se torna bloqueado devido a sua inabilidade de tomar uma deciso; necessria nova informao para esclarecer a situao
para que ento o membro da equipe possa tomar uma boa deciso, permitindo que o
trabalho-em-progresso flua em direo a sua concluso.
Para reduzir o impacto desses bloqueios, a equipe e o gerente direto precisam implementar um processo de gerenciamento e resoluo de problemas efetivo, como descrito
no captulo 20.
medida que a equipe e a organizao amadurecem, pode ser possvel discutir a
causa raiz da falha e elimin-la. Problemas de bloqueio devido ambiguidade de requisitos podem ser resolvidos influenciando diretamente o processo de anlise usado
para desenvolver os requisitos, e melhorando o nvel de capacidade e habilidade de
quem os define. Medies como estas requerem tipicamente a colaborao de outros
departamentos e gerentes e uma vontade por parte da empresa de melhorar.
Isto foi alcanado em 2007 na Corbis atravs de um processo gradual. Primeiro, o
sistema kanban foi implementado, incluindo um quadro visual, um sistema de acompanhamento eletrnico, e a transparncia que veio com isso. A empresa se tornou cada
vez mais envolvida e interessada na atividade de
desenvolvimento de software e em monitorar o
desempenho do processo. Foi gerado um relatrio
apresentando o nmero de problemas abertos, o
nmero de itens de trabalho bloqueados, e o
tempo mdio de resoluo. (Veja Figura 12.6, relatrio de Problemas e Itens de Trabalho
Bloqueados, na pgina 154.)
Quando um requisito fazia todo o seu caminho
at o teste de aceitao antes de ser rejeitado pela
empresa como algo que ela no precisava, a equipe
reagia criando uma lixeira no quadro e colocando
o ticket nela, como apresentado na Figura 19.1.
A gerncia ento solicitava um conjunto pequeno Figura 19.1 Quadro com uma lixeira

Fontes Externas de Variabilidade

Figura 19.2 Relatrio de Trabalho Rejeitado e Cancelado mostrando os itens abandonados do ms anterior

Figura 19.2 Relatrio de Trabalho Rejeitado e Cancelado mostrando os itens abandonados

de
que apresentava os trabalhos que entravam no sistema, mas falhavam em
dorelatrios
ms anterior
fazer todo o caminho por ele (Figura 19.2).
A combinao de transparncia, relatrios, e sensibilizao em relao ao impacto
e o custo de requisitos ruins resultaram na mudana voluntria do comportamento
da empresa. O relatrio de desperdcio que apresentava os efeitos de requisitos ruins
mostrou inicialmente cinco dos dez itens mensais. No quinto ms ele estava vazio.
A empresa compreendeu que tomando mais cuidado poderia evitar desperdcio de
capacidade. Eles colaboravam voluntariamente para melhorar o resultado do sistema.
O efeito disso foi a eliminao da causa raiz de variaes de causa atribuda a partir de
requisitos mal escritos ou informao de contexto mal definida.
Embora a equipe de desenvolvimento de software tenha tomado aes para fornecer uma transparncia maior e sensibilizao, estas aes no afetaram diretamente o
processo de desenvolvimento de requisitos. O processo de gerenciamento e resoluo
de problemas meramente mitigou o impacto dos problemas bloqueadores levantando
sensibilizao e reduzindo o tempo de resoluo. O resultado foi um impacto menor
na mdia do lead time e na propagao da variao. Os efeitos de transparncia e reportagem eventualmente resultaram numa mudana externa do processo que eliminou
a causa raiz do problema.
Esta uma evidncia de que aes podem ser tomadas localmente e afetaro indiretamente variaes de causa atribuda.

Requisies de Expedio
Requisies de expedio acontecem devido a eventos externos, como um pedido inesperado do cliente, ou devido a alguma quebra no processo interno da empresa, por exemplo, uma falta de comunicao que resulta numa descoberta tardia de algum requisito
importante. Requisies de expedio so, por definio, variaes de causa atribuda,
visto que o motivo para a requisio sempre conhecido e, portanto sempre atribuvel.

239

240

Captulo 19 Fontes de Variabilidade

Expedio conhecida na indstria de engenharia por ser ruim. Ela afeta a previsibilidade de outras requisies. Ela aumenta o lead time mdio e a propagao da variabilidade e reduz o rendimento. Evidncia coletada na Corbis durante 2007 demonstrou que
esse resultado da engenharia industrial verdadeiro para o processo de desenvolvimento
de software: Expedir indesejvel mesmo se est sendo feito para gerar valor.
A necessidade para expedir pode ser reduzida. Aumentar a capacidade de folga atravs
de melhorias no rendimento, automao, ou aumento de recursos melhorar a habilidade
de resposta. Lead times menores, transparncia maior, e melhoria na maturidade organizacional reduziro a necessidade de expedir. Boas equipes que adotam a abordagem
Kanban tm exibido uma demanda muito pequena para requisies de expedio. De
fato, durante o ano de 2007 na Corbis houve apenas cinco requisies desse tipo no total.
Podemos esperar que tanto quanto requisitos ruins, como transparncia do processo
e informao de boa qualidade relacionada a rendimento, lead time, e desempenho de
entrega na data influenciaro o comportamento no incio da cadeia de valor. Espera-se
que a demanda seja moldada efetivamente e entendida cedo o bastante de maneira que
possa ser manipulada como uma classe regular em vez de uma requisio de expedio.
Um mtodo para provocar esta mudana concordar em limitar o nmero de requisies de expedio que sero processadas a qualquer momento. Na Corbis esse limite
era um. Negando habilidade ao negcio de expedir qualquer coisa que eles queiram,
voc fora as pessoas do incio da cadeia de valor, como pessoas de marketing e vendas,
a explorar oportunidades mais cedo e avali-las efetivamente. Se as pessoas de vendas
so pagas por comisso e medidas pela receita gerada, falha para expedir alguma coisa
ir afet-las. Se a falha devido ao limite de WIP para requisies de expedio ter
sido alcanado, ento elas tentaro fortemente coletar no futuro informao suficientes
para colocar uma requisio em tempo de atender uma classe de servio regular.

Fluxo Irregular
Fluxo irregular de trabalho pode ser causado por variaes de causa aleatria ou
atribuvel mencionadas acima. Todas as variaes de causa atribuvel que afetam o
fluxo resultam em trabalho bloqueado. Problemas como ambiguidade de requisitos,
e ambiente ou recursos especialistas de disponibilidade compartilhada so motivos
comuns para trabalho bloqueado por causa atribuvel.
Itens de trabalho bloqueados requerem uma forte disciplina e capacidade com o
gerenciamento e resoluo de problemas, como descrito no captulo 20. H duas abordagens para lidar com problemas de itens de trabalho bloqueados.
A primeira abordagem facilitar o fluxo, mas custa do lead time e possivelmente
qualidade. Voc pode melhorar o fluxo tendo um limite geral maior de WIP alcanado

Fontes Externas de Variabilidade

atravs de buffering explcito ou usando uma poltica com menos restrio no WIP, por
exemplo, 3 atividades por pessoa, em mdia, em vez de 1.2 atividades por pessoa. O
limite de WIP maior significa que enquanto alguma coisa est bloqueada, os membros
da equipe podem trabalhar em outros itens. Eu recomendo essa abordagem para organizaes imaturas. Os efeitos devem ser simples e no dramticos. Os lead times sero
maiores, mas isso no deve ser um problema em muitos domnios. A propagao da
variao dever ser maior, e ento o lead time ser menos previsvel; no entanto, eles
devero ser mais previsveis atravs do uso do sistema kanban do que eles eram antes.
A maior desvantagem em usar limites de WIP maiores que h uma tenso menor
(ou nenhuma) para provocar discusso e implementao de melhorias. No h consequentemente nenhuma presso para melhoria: O efeito cataltico de kanban perdido.
A segunda abordagem perseguir gerenciamento e resoluo de problemas implacavelmente e, medida que a equipe amadurecer, se mover em direo a anlise e eliminao da causa raiz com melhorias especficas projetadas para prevenir variaes de
causa atribuvel no futuro. Nesta abordagem voc deixa os limites de WIP, tamanhos de
buffer, e polticas de trabalho razoavelmente apertadas, e voc faz com que o trabalho
pare quando as atividades ficam bloqueadas. O tempo ocioso destas pessoas atribudas
a trabalhos bloqueados levanta a conscientizao do problema bloqueado. Isto pode
causar um comportamento colaborativo de resoluo do problema, o qual encorajar
os membros ociosos da equipe a pensar sobre a causa raiz e possveis mudanas no
processo que reduziro ou eliminaro a possibilidade de recorrncia. Mantendo os
limites de WIP apertados e perseguindo o gerenciamento e resoluo de problemas
como uma capacidade tem criado uma cultura de melhoria contnua. Vi isso pela
primeira vez na Corbis em 2007, mas houve muitos outros relatrios que surgiram
em 2009 em empresas como Software Engineering Professionals em Indianapolis, IPC
Media, e BBC WorldWide, ambas em Londres. No h evidncia suficiente que possa
sugerir que Kanban gera uma cultura que focada na melhoria contnua. Os elementos
de processo consistentes nos exemplos parecem ser uma vontade de reforar polticas
de WIP apertado, de marcar trabalho bloqueado, de permitir que a linha pare, de incorrer em tempo ocioso, e de perseguir o gerenciamento e resoluo de problemas como
uma disciplina organizacional. O que resulta disto um foco na anlise e eliminao
de causa raiz e a introduo gradual de melhorias que reduzem variaes de causa
atribuvel e do incio a uma cultura maior de melhoria contnua.

Disponibilidade do Ambiente
Disponibilidade do ambiente um problema tpico de causa atribuvel que pode ter
um efeito significativo no fluxo, rendimento, e previsibilidade. Falhas no ambiente

241

242

Captulo 19 Fontes de Variabilidade

frequentemente causam uma falha em todo o fluxo de trabalho. Um sistema kanban


trar visibilidade para o problema e seu impacto. O tempo ocioso incorrido pela fortificao do limite de WIP encoraja colaborao para resolver a falha. Quando as pessoas do incio da cadeia de valor, como desenvolvedores e testadores, ajudam pessoas
de manuteno de sistemas a recuperar um ambiente, este comportamento referido
frequentemente como um movimento em massa (swarming). Movimento em massa
implica no conceito de que a equipe se move em conjunto para trabalhar num nico
problema at que ele seja resolvido. A natureza de Kanban encoraja equipes a focarem em lead time, rendimento, e fluxo atravs da cadeia de valor. Alinhando todos os
grupos no incio e final da cadeia de valor com os mesmos objetivos, h um incentivo
para que o comportamento em massa surja. Todos ganham quando pessoas ociosas se
voluntariam a colaborar para resolver um problema que as afeta mesmo se ele no est
na sua rea de trabalho imediata ou rea de responsabilidade.

Outros Fatores de Mercado


Em Outubro de 2008, seguindo o colapso de Lehman Brothers e uma srie de eventos
traumticos no setor financeiro, bancos e firmas de investimento de centros financeiros lderes como Londres e Nova York comearam a cancelar ou significativamente
modificar projetos de TI em desenvolvimento. O motivo era que o mundo deles virou
de cabea para baixo. Eles estavam lutando pela sua sobrevivncia. De repente eles
precisaram entender melhor sua liquidez e a do Mercado. No era mais importante
entregar o mais recente produto de commodity extico. O mercado no poderia cuidar
menos dos investimentos. No outono de 2008, empresas financeiras estavam interessadas apenas na solvncia ou insolvncia, dependendo de quanta sorte elas tinham.
Este um exemplo grave mas muito real que mostra como portfolios de projetos
e requisitos para projetos em progresso podem mudar dramaticamente. Reagir a esse
tipo de mudanas tende a distrair as equipes e resultar em significantes quedas no rendimento, aumentos dramticos no lead time, queda (frequente) da qualidade, e perda
de previsibilidade medida que a equipe recupera-se da aleatoriedade que a flutuao
no mercado causou aos trabalhos internos do projeto.
Tais eventos claramente so variaes de causa atribuvel. Eles precisam ser acomodados usando estratgias e tticas de gerenciamento de risco. H um corpo de conhecimento considervel em variao de causa atribuvel, ou risco dirigido a eventos.
Construir uma capacidade de gerenciamento de riscos forte como parte de um objetivo
geral de melhoria da maturidade organizacional melhorar a previsibilidade da unidade de engenharia de software se ela est usando Kanban ou no. No entanto, sistemas

Fontes Externas de Variabilidade

kanban exibem alta previsibilidade quando o risco bem gerenciado. Isto constri
confiana no sistema.
Sistemas Kanban tm um nmero de outros elementos que ajudam no gerenciamento de riscos. O limite de WIP reduz risco, visto que apenas uma pequena frao do
trabalho est em progresso em qualquer momento. Alocao de limites de WIP pelos
tipos de itens de trabalho e classes de servio ajuda a gerenciar riscos e absorver variaes de causa atribuvel. Outras estratgias esto surgindo, e provvel que um livro
subsequente tambm surja, detalhando mtodos avanados para melhorar Kanban e
tticas de gerenciamento de riscos.
Tenho apresentado material em gerenciamento de riscos com sistemas kanban que
surgiram a partir do uso de Kanban em conferncias durante o ano de 2009, que est
disponvel online.20

Dificuldades em Agendar Atividades de Coordenao


Outra fonte comum de variao de causa atribuvel que causa bloqueio no trabalho e
fluxo irregular o desafio de coordenar equipes externas, stakeholders, e recursos. Uma
reao frequente aos desafios de coordenao agendar reunies com uma cadncia regular. Em algumas instncias isso muito eficiente. No entanto, no sempre
possvel.
O fluxo pode ser interrompido por uma restrio governamental ou regulatria
que requer uma auditoria ou um signoff. As pessoas necessrias para realizar esta
funo podem no estar disponveis instantaneamente ou pode ser difcil fazer um
agendamento.
Em primeira instncia, variao de causa atribuvel desta natureza deve ser endereada conscientizando e dirigindo a ateno a ela com visibilidade e transparncia.
Marcando itens como bloqueados e levantando visibilidade na fonte do bloqueio, a
gerncia, equipe, e stakeholders da cadeia de valor ficaro conscientes do impacto dos
desafios de coordenao.
Esta conscincia deve liderar algumas mudanas comportamentais que melhoraro
situao.
Uma ttica pode ser examinar as regras governamentais e regulatrias e decidir se
tudo precisa ser avaliado, aprovado, auditado, ou examinado. Assumindo que algum
perfil de risco permite que o trabalho seja bifurcado em duas categorias, as que precisam e as que no precisam que uma reunio acontea, tipos de item de trabalho ou
classes de servio podem ser usados para separar o trabalho. Voc pode ento usar
alocao de limites de WIP para os tipos ou classes para garantir a suavidade do fluxo.

243

244

Captulo 19 Fontes de Variabilidade

Takeaways
O estudo de variao no processo industrial iniciou na dcada de 1920 com
Walter Shewhart e evoluiu atravs do trabalho de W. Edwards Deming,
Joseph Duran, e David Chambers da metade do sculo em diante.
Um estudo de variao e seu mtodo de anlise estatstica esto no corao
do Toyota Production System (e, portanto, Lean) e do mtodo Six Sigma para
melhoria de processo.
Os trabalhos de W. Edwards Deming e Joseph Duran foram a maior inspirao para o trabalho do Software Engineering Institute na Carnegie Mellon
University e do Capability Maturity Model (agora Capability Maturity Model
Integration, ou CMMI).
Shewhart dividiu fontes de variao em duas categorias: aquelas internas ao
processo ou sistema e aquelas externas ao processo ou sistema.
Variaes internas so referidas como variaes de causa aleatria.
Variaes externas so referidas como variaes de causa atribuvel.
Podem existir vrias fontes de variao de causa aleatria na cadeia de valor
do ciclo de vida de desenvolvimento de software. Exemplos tpicos incluem
tamanho do item de trabalho, tipo, classe de servio, fluxo irregular, e rework.
H possivelmente uma lista infinita de fontes de variao de causa atribuvel.
Exemplos tpicos incluem ambiguidade de requisitos, requisies de expedio, disponibilidade do ambiente, fluxo irregular, fatores relacionados s
pessoas, e desafios em agendar atividades de coordenao ou overhead.
Variao de causa aleatria pode ser controlada atravs do uso de polticas
que definem o ciclo de vida de desenvolvimento de software e processo de
gerncia de projeto em uso.
Variaes de causa atribuvel podem ser gerenciadas atravs do uso da
capacidade de gerenciamento e resoluo de problemas, como tambm
da capacidade de gerenciamento de riscos, e elas podem ser reduzidas ou
eliminadas atravs da capacidade de anlise e eliminao de causa raiz.
Sistemas Kanban produzem melhores resultados econmicos quando acoplados a uma capacidade slida e dirigida a eventos de gerenciamento de riscos.

Takeaways
245

Kanban tambm oferece caminhos adicionais para gerenciar riscos como


uma alocao de WIP atravs das classes de servio e tipos de itens de
trabalho e o uso de um perfil de risco para categorizar trabalhos em tipos ou
classes e process-los de acordo com a categorizao.
Mais trabalhos em estratgias avanadas de gerenciamento de riscos e tticas
com Kanban esto em progresso , e ser um tpico de um futuro livro.

C aptulo 20

Gerenciamento de
Problemas e Polticas
de Escalao

uando um trabalho no nosso sistema kanban torna-se bloqueado por qualquer motivo, tornou-se conveno indicar isso na
parede de cartes anexando uma nota adesiva rosa ao carto, indicando o motivo do bloqueio. Em sistemas eletrnicos, podem existir
outras maneiras para indicar que um item de trabalho est bloqueado,
como mostr-lo com uma borda vermelha. Preferencialmente, as features do sistema eletrnico devem permitir que o motivo para o bloqueio seja acompanhado separadamente, ou o problema que est
bloqueando o trabalho deve ser acompanhado como um item de trabalho de primeira classe ligado ao item de valor para o usurio que
est dependendo da resoluo do problema.
Durante a escrita deste livro notei que algumas pessoas que tentam
usar Kanban pela primeira vez referem-se a estes itens bloqueados
como gargalos. Isto est errado. Um item bloqueado deve estar entupindo o pipe e restringindo o fluxo, mas no um gargalo, como o
descrito no captulo 17. Ele tambm no um recurso de capacidade
limitada ou um recurso de disponibilidade no instantnea. Da mesma
maneira que uma rolha em um gargalo no um gargalo. Se voc deseja
restaurar o fluxo no gargalo voc simplesmente retira a rolha.
perigoso pensar em itens de trabalho bloqueados como gargalos porque isso leva a um tipo de pensamento errado para resolver
o problema. Itens de trabalho bloqueados devem ser tratados como
247

248

Captulo 20 Gerenciamento de Problemas e Polticas de Escalao

causa especial de variaes em vez de gargalos. O que similar o resultado esperado.


Em ambos os casos um gargalo ou item de trabalho bloqueado queremos resolver
o problema para melhorar o fluxo.
Itens de trabalho bloqueados requerem que uma organizao desenvolva uma capacidade para gerenciamento e resoluo de problemas para restaurar o fluxo o mais
rpido possvel, como tambm uma capacidade de anlise e resoluo de causa raiz
para prevenir recorrncia. A segunda capacidade foi discutida no captulo 19 como
remoo de variaes de causa especial. A primeira discutida aqui.

Gerenciando Problemas
No suficiente simplesmente marcar e acompanhar um item de trabalho bloqueado.
Muitas ferramentas de desenvolvimento de software geis iniciais permitiam apenas
esta capacidade. Enquanto til ter informao sobre um item, uma story, uma feature,
ou use case bloqueado, minha observao de equipes ao redor do mundo tem sido que
ter conhecimento que alguma coisa est bloqueada no leva ao desenvolvimento de
uma capacidade forte de torn-la no bloqueada.
essencial acompanhar o motivo do bloqueio e trat-lo como um item de primeira
classe, embora seja um item de trabalho de carga defeituosa. Um tipo de item de trabalho especial, Problema, colocado a parte
para esse propsito. Problemas so acompanhados usando-se tickets na cor rosa (Figura 20.1).
Eles devem ter um nmero de acompanhamento, e um membro da equipe usualmente
o gerente de projeto deve ser atribudo para
garantir a resoluo.
Quando um membro da equipe trabalhando
num item de valor para o cliente incapaz de
proceder, ele ou ela devem marcar o item como
bloqueado, anexar um ticket rosa descrevendo
o motivo do bloqueio, e criar um item de trabalho Problema na ferramenta de acompanhamento eletrnica. O problema deve ser ligado ao
seu item de trabalho original (veja Figura 20.1).
Alguns exemplos so: ambiguidade nos requisitos, e uma pessoa com conhecimento no est
disponvel para instantaneamente resolver a Figura 20.1 Item de impedimento (rosa) anexado ao item
de trabalho Solicitao de Mudana diretamente afetado

Escalando Problemas

ambiguidade; uma configurao de ambiente requerida e o engenheiro para realizar


esta tarefa est atualmente indisponvel; ou requerido um especialista para trabalhar num
item e a pessoa est indisponvel devido a frias, doena, ou outro tempo fora do trabalho.
Como discutido no captulo 7, manter o fluxo deve ser o principal foco de discusso
de uma reunio standup diria. Portanto, a reunio deve focar em discutir bloqueios e
progresso direcionado a resoluo de problemas. A reunio deve focar fortemente nos
tickets rosa. Questes devem ser levantadas sobre quem est trabalhando em resolver
o problema e o status do progresso da resoluo. O problema precisa ser escalado? Se
sim, para quem?
Membros ociosos da equipe devem ser encorajados a acompanhar os problemas e
geralmente mergulhar nos problemas e ajudar da maneira que eles possam a resolv-los e restaurar o fluxo do sistema. Uma equipe com uma capacidade forte de auto-organizao tende a fazer isso naturalmente. Membros da equipe sero voluntrios na
ajuda para a resoluo dos problemas. Onde esta capacidade de organizao ainda vai
emergir, o gerente de projeto pode precisar atribuir membros da equipe para trabalhar
na resoluo de problemas.
Problemas devem ser acompanhados como todos os itens de trabalho. O acompanhamento inclui uma data inicial e uma data final e um link para todos os itens de trabalho de valor para o cliente afetados. Note que um nico item pode estar bloqueando
mais de um item de valor para o cliente. Est outra boa razo para acompanhar problemas independentemente dos itens de trabalho e para ter Problema como um item
de trabalho distinto. Quando escolher uma ferramenta eletrnica para acompanhar seu
sistema kanban, esteja certo de escolher uma que d suporte a acompanhamento de
problemas como um item de primeira classe ou uma ferramenta que suficientemente
customizvel de maneira que voc possa criar um item de trabalho chamado Problema
e designar que ele ser apresentado usando cartes rosa (ou vermelho).

Escalando Problemas
Quando uma equipe incapaz de resolver um problema por ela prpria, ou uma parte
externa requerida para resolver um problema e est indisponvel ou sem dar resposta,
o problema deve ser escalado para um gerente mais snior ou outro departamento.
importante para a organizao desenvolver uma forte capacidade de escalao de
problema. Sem isso, manter e restaurar o fluxo aps um bloqueio pode ser problemtico.
A base para uma boa capacidade de escalao uma poltica ou processo de escalao documentada, O captulo 15 discute o poder das polticas organizacionais desenvolvidas de maneira colaborativa. Polticas de escalao devem ser desenvolvidas de
maneira colaborativa e os departamentos envolvidos na cadeia de valor devem entrar

249

250

Captulo 20 Gerenciamento de Problemas e Polticas de Escalao

em consenso. As polticas de escalao devem ser largamente conhecidas e compreendidas, e um documento (ou web site) descrevendo-as deve estar prontamente disponvel para todos os membros da equipe. No deve existir ambiguidade sobre como
e quando escalar um problema. Tomando-se um tempo para definir caminhos de escalao e escrever as polticas que os circundam, a equipe sabe para onde enviar os
problemas para resoluo. Isto economiza tempo da equipe imaginar para quem um
problema deve ser escalado e atribui expectativas para aqueles indivduos mais seniores
de que eles fazem parte do sistema. Gerentes seniores precisam ter responsabilidade
em resolver problemas. Isto ajudar a manter o fluxo e por fim a minimizar o custo de
atraso (ou melhorar o payoff a partir de maior velocidade de entrega).

Acompanhando e Reportando Problemas


Como declarado anteriormente, problemas devem ser acompanhados como itens de
trabalho de primeira classe com o seu prprio item de trabalho. H uma evoluo para
a conveno do uso de cartes rosa ou vermelhos, ou notas adesivas para a visualizao
de problemas (Figura 20.2). Uma data inicial, uma data final, um membro da equipe
atribudo, uma descrio do problema, e links para os itens de valor bloqueados para o
cliente so os requisitos mnimos para um sistema de acompanhamento de problemas

Figura 20.2 Quadro mostrando muitos impedimentos afetando mltiplas features

g 20.3!

Acompanhando e Reportando Problemas

Figura 20.3 Grfico de problemas CFD sobreposto com itens de trabalho Bloqueados

Figura 20.3 Grfico de problemas CFD sobreposto com itens de trabalho Bloqueados

(Figura 20.3). Tambm pode ser til acompanhar alguns histricos de esforo gasto
para resoluo, um histrico de indivduos atribudos, uma indicao do caminho de
escalao, um tempo estimado para resoluo, uma avaliao de impacto, e sugestes
de correes de causa raiz para futuras prevenes.
Mesmo que tickets rosa na parede de cartes forneam uma visualizao forte de
quantos itens esto atualmente bloqueados, tambm til acompanhar e reportar problemas de outras maneiras. Um diagrama de fluxo cumulativo de problemas e itens de
trabalho bloqueados fornece um indicador visual forte da capacidade da organizao
no gerenciamento e resoluo de problemas. A tendncia de itens de trabalho bloqueados no decorrer do tempo indica se a capacidade de anlise e resoluo de causa raiz
oportunidades de melhoria para eliminar variaes de causa atribuvel est desenvolvendo. Um relatrio tabular de problemas atuais, indivduos atribudos, status, data
de resoluo prevista, itens de trabalho afetados, e o potencial impacto pode tambm
se provar til no dia a dia do gerenciamento de grandes projetos.
Estes relatrios devem ser apresentados em cada reviso operacional e deve ser reservado um tempo para se discutir a maturidade da capacidade organizacional no gerenciamento e resoluo de problemas e na anlise e resoluo de causa raiz. A organizao deve
estar consciente do impacto de carga defeituosa de problemas bloqueando trabalho. Isto
possibilitar decises objetivas sobre oportunidades de melhoria e benefcios provveis
de investimentos em correes de causa raiz para prevenir variaes de causa especial.

251

252

Captulo 20 Gerenciamento de Problemas e Polticas de Escalao

Takeaways
Sistemas Kanban devem ter um tipo de item de trabalho, Problema, usado
para acompanhar problemas que causam bloqueio de trabalho de valor para
o cliente.
Tornou-se conveno a utilizao de notas adesivas rosa (ou vermelha) na
parede de cartes para a visualizao de problemas de bloqueio.
Tickets rosa de problemas so anexados aos itens que esto bloqueados.
Para manter o fluxo essencial uma forte capacidade para gerenciamento e
resoluo de problemas.
Itens de trabalho bloqueados e problemas no so gargalos. Eles devem ser
gerenciados como variaes de causa especial em vez de recursos de capacidade limitada ou recursos de disponibilidade no instantnea.
Gerenciamento de problemas deve ser um foco forte nas reunies standup
dirias.
Para gerenciamento de problemas essencial uma forte capacidade de escalao de problemas.
Polticas de escalao devem ser claramente definidas e documentadas e
todos os membros da equipe devem ter conscincia delas.
Polticas de escalao funcionam melhor quando elas so acordadas colaborativamente por todos os departamentos envolvidos na cadeia de valor.
Problemas podem ser acompanhados eletronicamente.
Relatrios baseados em dados eletrnicos facilitaro o dia a dia do gerenciamento e resoluo em grandes projetos.
Use um diagrama de Problemas e Itens de Trabalho Bloqueados para visualizar o desenvolvimento da capacidade para gerenciamento e resoluo de
problema e anlise e resoluo de causa raiz.

Notas

1. Anderson, David J. Agile Management for Software Engineering:


Applying the Theory of Constraints for Business Results. Upper
Saddle River, NJ: Prentice Hall, 2003.
2. Beck, Kent. Extreme Programming Explained: Embrace Change.
Boston: Addison Wesley, 2000.
3. Beck, Kent et al., The Principles Behind the Agile Manifesto.
www.agilemanifesto.org/principles.html.
4. Goldratt, Eliyahu M. What is this thing called The Theory of
Constraints and How should it be implemented? Great Barrington,
MA: North River Press, 1999.
5. Anderson, David J., and Dragos Dumitriu, From Worst to
Best in 9 Months: Implementing a Drum-Buffer-Rope Solution
in Microsofts IT Department, Proceedings of the TOCICO
World Conference, Barcelona, November 2005.
6. Belshee, Arlo. Naked Planning, Promiscuous Pairing and
Other Unmentionables. 2008 Agile Conference, podcast.
http://agiletoolkit.libsyn.com/index.php?post_id=400364.
7. Hiranabe, Kenji. Visualizing Agile Projects Using Kanban
Boards. InfoQ, August 27, 2007; www.infoq.com/articles/
agile-kanban-boards.
253

254

Notas 20 Notas
Captulo

8. Hiranabe, Kenji, Kanban Applied to Software Development: From Agile to Lean,


InfoQ, January 14, 2008. www.infoq.com/articles/hiranabe-lean-agile-kanban.
9. Augustine, Sanjiv. Managing Agile Projects. Upper Saddle River, NJ: Prentice Hall,
2005.
10. Highsmith, Jim. Agile Software Development Ecosystems. Boston: Addison Wesley,
2002.
11. The Nokia Test is attributed in origin to Bas Vodde, described here by Jeff
Sutherland, who has adopted and updated it. http://jeffsutherland.com/
scrum/2008/08/nokia-test-where-did-it-come-from.html.
12. Beck et al., The Principles Behind the Manifesto. www.agilemanifesto.org/
principles.html.
13. Jones, Capers. Software Assessment Benchmarks and Best Practices. Boston: Addison
Wesley, 2000.
14. Ambler, Scott. Agile Modeling: Effective Practices for Extreme Programming and the
Unified Process. Hoboken, N.J.: Wiley, 2002.
15. Chrissis, Mary Beth, Mike Konrad, and Sandy Shrum. CMMI: Guildelines for
Process Integration and Product Improvement, 2d ed. Boston: Addison Wesley, 2006.
16. Sutherland, Jeff, Carsten Ruseng Jakobsen, and Kent Johnson. Scrum and
CMMI Level 5: A Magic Potion for Code Warriors. Proceedings of the Agile
Conference, Agile Alliance/IEEE, 2007.

Jakobsen, Carsten Ruseng and Jeff Sutherland. Mature Scrum at Systematic.


Methods & Tools, Fall 2009. www.methodsandtools.com/archive/archive.php?id=95.

17. Larman, Craig and Bas Vodde. Scaling Lean & Agile Development: Thinking and
Organizational Tools for Large-Scale Scrum. Boston: Addison Wesley, 2008.
18. Willeke, Eric, with David J. Anderson and Eric Landes (editors) Proceedings of the
Lean & Kanban 2009 Conference. Bloomington, IN: Wordclay, 2009.
19. Beck et al, Principles Behind the Agile Manifesto, 2001, www.agilemanifesto.
org/principles.html

Notas

255

20. Anderson, David J. New Approaches to Risk Management. Agile 2009,


Chicago, Illinois; www.agilemanagement.net/Articles/Papers/Agile2009NewApproachesto.html.

Agradecimentos

ada livro publicado representa um esforo de gerenciamento de


projeto e de coordenao significantes e envolve toda uma
equipe de pessoas, da qual o autor realmente apenas uma pequena
parte. Este livro no teria acontecido sem os esforos de valor inestimvel de Janice Linden-Reed e Vicki Rowland. Eu gostaria de agradec-las pela incrvel pacincia e perseverana em ter este manuscrito
pronto para publicao dentro de um prazo apertado (com um custo
de atraso alto).
Eu gostaria de agradecer a Donald Reinertsen por me estimular a
usar Kanban e por me fornecer um frum para falar sobre ele publicamente. Eu tambm gostaria de agradec-lo por suas palavras gentis
no Prefcio e seus esforos em construir uma comunidade de vida
longa e prspera atravs da formao do Lean Software & Systems
Consortium.
Eu gostaria de agradecer a Karl Scotland, Joe Arnold, e Aaron Sanders, e tambm a Eric Willeke, Chris Shinkle, Olav Maassen, Chris
Matts, e Rob Hathaway. O entusiasmo inicial deles e a adoo de
Kanban levaram diretamente formao de uma comunidade agora
prspera e disseminao viral do mtodo ao redor do mundo. Sem
o suporte destas pessoas no haveria demanda para este manuscrito,
e Kanban seria um mtodo obscuro usado por algumas companhias
no Pacfico Nordeste dos Estados Unidos, em vez de uma nova abordagem excitante usada por equipes em cada continente - de startups
de 5 pessoas no Cambodia a companhias de segurana de 300 anos
em Netherlands, em grandes companhias de petrleo no Brasil e fornecedores terceirizados na Argentina, como tambm companhias
de mdia em Londres, Los Angeles, e Nova York, e muito mais pelo
mundo. A adoo de Kanban um fenmeno, e no teria acontecido
257

258

Agradecimentos

sem o encontro afortunado de mentes que ocorreu em Agosto de 2007 em Washington,


DC, na conferncia Agile 2007.
Este livro no seria uma ferramenta to til e uma experincia de leitura to prazerosa sem os comentrios inteligentes e feedback construtivo de um grande nmero de
revisores do manuscrito. Eu gostaria de dar ateno especial s contribuies de Daniel Vacanti, Greg Brougham, Christina Skaskiw, Chris Matts, Bruce Mount, Norbert
Winklareth, e, novamente, Janice Linden-Reed. Cada um deles produziu uma reviso
estratgica e inteligente em uma ou mais verses iniciais do manuscrito que levaram
a uma significante reestruturao do contedo. O resultado um livro melhor e mais
fcil de ler e entender, e isso ser uma ferramenta mais til comunidade em longo
prazo.
Alm disso, h muitos outros membros da comunidade que contriburam com feed
back e edies que foram todas consideradas cuidadosamente medida que o manuscrito evolua durante 2009 e 2010. Obrigada: Jim Benson, Matthias Bohlen, Joshua
Kerievsky, Chris Simmons, Dennis Stevens, Arne Roock, Mattias Skarin, Bill Barnett,
Olav Maassen, Steve Freeman, Derick Bailey, John Heintz, Lilian Nijboer, Si Alhir, Siddharta Govindaraj, Russell Healy, Benjamin Mitchell, David Joyce, Tim Uttormark,
Allan Kelly, Eric Willeke, Alan Shalloway, Alisson Vale, Maxwell Keeler, Guilherme
Amorim, Reni Elisabeth Pihl Friis, Nis Holst, Karl Scotland, e Robert Hathaway.
Eu gostaria de agradecer a minha incansvel gerente de escritrio, Mikiko Fujisaki,
que mantm as rodas girando do David J. Anderson & Associates, Incorporated, e sem
a qual eu nunca teria encontrado tempo para escrever esse livro.
Meu velho amigo e colega Pujan Roka kindly se ofereceu para desenhar a ilustrao
da capa. Pujan um artista talentoso de histrias em quadrinhos, e tambm tem livros
publicados, at o momento dois deles sobre gerenciamento. Saiba mais sobre ele e suas
publicaes em http://www.pujanroka.com/.
A comunidade tem sido generosa na adoo e entusiasmo sobre Kanban, o que
resultou em gentis propostas de traduo do livro para idiomas locais. Eu gostaria de
agradecer a Jan Piccard de Muller, Andrea Pinto, Arne Roock, Masa Maeda, e Hiroki
Kondo, que j esto trabalhando fortemente na traduo para os idiomas Francs,
Portugus, Espanhol e Japons. Tenho certeza que os seus esforos ajudaro a espalhar
a adoo de Kanban ao redor do mundo e expandir a comunidade e o entusiasmo em
relao ao mtodo nas suas respectivas regies.
Eu gostaria de agradecer a Nicole Kohari, Chris Hefley, David Joyce, Thomas Blomseth, Jeff Patton, e Steve Reid, todos eles contriburam com imagens para o livro.
E finalmente eu gostaria de agradecer ao meu bom amigo Dragos Dumitriu, que
est agora na Avanade, e minha equipe na Corbis: Darren Davis, Larry Cohen, Mark
Grotte, Dominica Degrandis, Troy Magennis, Stuart Corcoran, e tambm a Rick

Agradecimentos
259
Agradecimentos

Garber, Corey Ladas, e Diana Kolomiyets. Sem eles, Kanban nunca teria acontecido.
Seus esforos em implement-lo e us-lo criaram exemplos e histrias a partir das quais
todos ns aprendemos e subsequentemente adotamos e adaptamos solues para situaes novas e mais desafiadoras. Sem eles no haveria livro, comunidade, e um crescente
nmero de clientes satisfeitos que esto desfrutando de um software de alta qualidade
desenvolvido de maneira regular e rpida, quando e onde eles precisam, com agilidade,
em resposta natural demanda da suas indstrias e usurios.
Nossa jornada Kanban continua e espero que com este livro voc seja persuadido a
fazer parte dela.
David J. Anderson
Na trilha de evangelizao Kanban,
em algum lugar na Europa, Abril 2010

ndice
A
acordo de nivel de servio
aloque capacidade para classes de
servio, 146148
classe intangvel , 138, 142
classe padro, 138
colocando classes de servio em uso, 145
data fixa de entrega, 136137
definies tpicas de classe de servio,
134
determinando meta para entrega de
servio, 142143
estabelecendo uma classe de servio, 144
expedio, 135
polticas de classe padro, 141
polticas de data de entrega fixa, 140
polticas de expedio, 140
polticas para classe de servio, 139
gil, 2, 19, 188
Agile Alliance, 8, 254
Agile Conference, 253254
Agile Manifesto, 253254
Agile Zen, 81
amigos pegajosos, vii, 97
Aps a Reunio, 92
automao, 212, 219

B
bloqueados itens de trabalho, 154, 157, 247,
251252
Brooks, Fred, 136

cadeia de valor, 36, 7172, 82, 182, 185, 189,


201202, 242
acompanhamento eletrnico
8081, 8990
parede de cartes, 74
cadncia, viii, 47, 60, 101103, 109, 111,
116, 121, 160, 168
cadncia de entrada
acordando uma cadncia de priorizao,
116
coordenando custos de priorizao,
113115
custos de transao de priorizao, 117
eficincia de priorizao, 116
fazendo priorizao ad hoc ou por
demanda, 119121
melhore eficincia para aumentar a
cadncia de priorizao, 118
cadncia de entrega, 111
coordenao dos custos de entrega, 103
custos de transao de entrega, 104105
eficincia de entrega, 106
fazendo entregas sob demanda ou ad
hoc, 108112
melhore a eficincia para aumentar a
cadncia de entrega, 108
quanto de eficincia o bastante?, 107
capacidade, 13, 3637, 4849, 57, 78, 131,
146147, 157, 202, 209215, 219, 221, 235,
244, 248249, 251252
capital social, 63, 67
261

262

ndice
Captulo 2 ndice

caracterstica comercial mnima (MMF), 162


Chambers, David, 231, 244
classe padro, 138, 141, 146
classes de servio, viii, 89, 134135, 143, 145
146, 148, 166167, 190, 194, 227, 236,
243
colaborao, 63
confiana, 15, 27, 34, 56, 63, 109, 143, 184
coordenao, 103104, 106109, 111, 116,
118121, 226228, 243
coordenao com sistemas Kanban, 87100
acompanhamento eletrnico, 89
avatar amigo (sticky buddies), 97
controle visual e puxado, 8788
o aps a reunio, 92
reunies de planejamento de release, 93
reunies para reabastecimento de fila, 92
reunies standup dirias, 9091
reviso e escalao de log de problemas, 96
sincronizao atravs de localizaes
geogrficas, 97100
triagem, 9495
cultura kaizen, 56
custo, 105106, 111, 137139, 144, 195, 218,
228
custos de coordenao, 109, 226
custos de transao, 104105, 111, 118, 121,
225226

D
defeitos, 2829, 31, 77, 95, 133, 156, 181, 194,
229, 237
demanda, 3536, 7778, 93, 147, 182, 186, 236
Deming, W. Edwards, x, 18, 202204, 206,
231, 244
desempenho, 15, 56, 141142, 152, 174, 184
desenvolvimento gil, 19
desenvolvimento de software, 38
desperdcio, 202, 223, 227228, 230
Digital Whiteboard, 89
Drum-Buffer-Rope, 67

Dumitriu, Dragos, 4151, 53, 119120, 124,


127, 253, 258

E
eficincia, vii, 106107
empreendendo uma iniciativa de mudana
Kanban, 179198
conhecer os objetivos e articular os
benefcios, 185
entrega/release, 192193
fazendo uma negociao Kanban, 190
Kanban requer um tipo diferente de
negociao, 188189
lead time e classes de servio, 194198
limites de WIP, 190191
mudana cultural em vez de uma iniciativa
de mudana gerenciada, 179
o primeiro objetivo para nosso sistema
Kanban, 180
objetivos secundrios para nosso sistema
Kanban, 181184
passos para dar incio, 186187
priorizao, 192
entrega, vii, viii, ix, 15, 3738, 78, 80, 93, 96,
101109, 111, 136, 138, 140144, 146,
148, 152, 154, 157, 162163, 166, 188
190, 192, 195, 224, 226
equipes, 4, 19, 2829, 35, 62, 102, 118, 130,
161
escalando kanban , 159168
abordagem alternativa para variabilidade
no tamanho, 165
dissocie entrega de valor de variabilidade
do item de trabalho, 161162
gerenciando recursos compartilhados,
166167
incorporando classes de servio, 165
integrao de sistemas, 166
introduzindo raias, 164
paredes de carto em duas camadas, 163
requisitos hierrquicos, 160

ndice

263

Kanban como um Doador de Permisses

estabelecendo acordo de nvel de servio,


133148
aloque capacidade para classes de servio,
146148
classe intangvel , 138
classe intangvel, 142
classe padro, 138
colocando classes de servio em uso, 145
data fixa de entrega, 136137
definies tpicas de classe de servio, 134
determinando meta para entrega de
servio, 142143
estabelecendo uma classe de servio, 144
expedio, 135
polticas de classe padro, 141
polticas de data de entrega fixa, 140
polticas de expedio, 140
polticas para classe de servio, 139
estabelecendo limites para o trabalho-emprogresso, 123132
alocao de capacidade, 131
limites para filas, 125
limites para tarefas, 124
no estabelecer um limite de wip um erro,
130
no estresse a sua organizao, 129
retenha gargalos, 126
sees ilimitadas de trabalho, 128
tamanho da fila de entrada, 126127
estabelecendo uma cadncia de entrada,
113122
acordando uma cadncia de priorizao, 116
coordenando custos de priorizao, 113115
custos de transao de priorizao, 117
eficincia de priorizao, 116
fazendo priorizao ad hoc ou por
demanda, 119121
melhore eficincia para aumentar a
cadncia de priorizao, 118
estabelecendo uma cadncia de entrega,
101112
coordenao dos custos de entrega, 103
custos de transao de entrega, 104105
eficincia de entrega, 106

fazendo entregas sob demanda ou ad hoc,


108112
melhore a eficincia para aumentar a
cadncia de entrega, 108
quanto de eficincia o bastante?, 107
estimativa, 4445, 103, 118, 142, 152, 226
expedio, 135, 139140, 239240

F
fbricas de software, 29
fila de entrada, 82, 87, 127
filas, 125
Flow.io, 81
fluxo, i, xi, 5, 1516, 18, 30, 38, 43, 47, 53,
6162, 7274, 86, 125126, 128, 132,
140, 149150, 155, 157, 162, 200201,
203204, 207208, 212213, 217218,
227, 236237, 240, 242244, 247249
fluxo de trabalho, 72, 74
Fog Bugz, 81
folga, 36, 182
fontes de variabilidade, 231246
ambiguidade de requisitos, 238
dificuldades em agendar atividades de
coordenao, 243246
disponibilidade do ambiente, 241
fluxo irregular, 236, 240
fontes externas de variabilidade, 237
fontes internas de variabilidade, 233
mesclas de classes-de-servio, 235
mesclas de tipos de item de trabalho, 234
outros fatores de mercado, 242
requisies de expedio, 239
rework, 237
tamanho do item de trabalho, 233

GH
Garber, Rick, 8, 169
gargalos, 214, 221
gargalos e disponibilidade no-instantnea,
207222

264

ndice
Captulo 2 ndice

aes de elevao, 209, 219222


aes de explorao/proteo, 210212,
217
aes de subordinao, 213, 218
recursos com capacidade limitada, 209
recursos disponveis no instantaneamente, 214216
Gates, Bill, 42, 45, 207
gerenciamento de problemas e polticas de
escalao, 247252
acompanhando e reportando problemas,
250252
escalando problemas, 249
gerentes de produto, 48, 127
gesto, 37, 61, 63
Goldratt, Eli, xiii, 5, 10, 26, 200, 209, 253
grandes projetos, 159
Greenhopper para Jira, 81
Humphrey, Watts, 42, 231

I
iniciativa de mudana Kanban
conhecer os objetivos e articular os
benefcios, 185
entrega/release, 192193
fazendo uma negociao Kanban, 190
Kanban requer um tipo diferente de
negociao, 188189
lead time e classes de servio, 194198
limites de WIP, 190191
mudana cultural em vez de uma iniciativa
de mudana gerenciada, 179
o primeiro objetivo para nosso sistema
Kanban, 180
objetivos secundrios para nosso sistema
Kanban, 181184
passos para dar incio, 186187
priorizao, 192
inspees de cdigo, 28
itens de trabalho, 86, 89, 161162, 248249, 251

JK
Jira, 81
Juran, Joseph, 231
kaizen, 5556, 67
Kanban, i, v, vi, x, xiv, 610, 1321, 3940,
5354, 5758, 6163, 6667, 73, 78,
8081, 8990, 92, 98, 102103, 109, 115,
119, 129130, 149150, 159, 161162,
166, 168, 179181, 183, 185, 188190,
196, 199, 203206, 217, 241243, 257,
259
Kanbanery, 81

L
lead time, 31, 103, 126, 143144, 148, 151
152, 155, 157, 162, 172, 181, 189190,
194195, 237, 240
Lean, v, ix, x, xi, 5, 78, 10, 1618, 8081, 107
108, 155, 160, 172173, 175, 199, 201
205, 208, 213, 223225, 244, 254, 257
Lean Kit Kanban, 81
liberao comercial mnima (MMR), 162
limites para trabalho-em-progresso
alocao de capacidade, 131
limites para filas, 125
limites para tarefas, 124
no estabelecer um limite de WIP um
erro, 130
no estresse a sua organizao, 129
retenha gargalos, 126
sees ilimitadas de trabalho, 128
tamanho da fila de entrada, 126127
log de problemas, 96

M
Manifesto gil, 2, 27, 102, 253254
mapeando a cadeia de valor, 7187
acompanhamento eletrnico, 8081
anlise da demanda, 7778

ndice

265

Kanban como um Doador de Permisses

anatomia de um carto de item de trabalho,


79
atribuindo limites de entrada e sada, 82
definindo um ponto inicial e final de
controle, 72
desenhando uma parede de cartes, 7376
lidando com atividades desordenadas, 85
lidando com concorrncia, 8384
tipos de item de trabalho, 72
maturidade, 57, 109, 120, 129, 185
melhoria, 18, 36, 40, 55, 99, 108, 130, 199200,
202, 204, 241
melhoria contnua, 18, 36, 55, 200, 241
mtodo Kanban, 1124
comportamento emergente com Kanban,
18
Kanban aplicado ao desenvolvimento de
software, 1314
Kanban como um doador de permisses,
1924
Kanban como um sistema complexo
adaptvel para lean, 17
Kanban em ao, 16
o que um sistema Kanban?, 13
por que usar um sistema Kanban?, 15
um modelo para o mtodo Kanban, 17
mtricas, 149
mtricas e relatrios de gerenciamento, 149158
carga de falhas, 156157
desempenho de entrega na data, 152
eficincia do fluxo, 155
lead time, 151
monitorando WIP, 150
problemas e itens de trabalho bloqueados,
154
qualidade inicial, 156
rendimento, 153
Microsoft, 7, 4142, 119120
modelo econmico para Lean, 223230
carga defeituosa, 229
como voc sabe se uma atividade um
custo?, 228
custos de coordenao, 226227
custos de transao, 224225

redefinindo desperdcio, 223


modelos, 16, 18, 199
muda (desperdcio), 18, 184, 223
mudana, i, vi, x, 3, 6, 10, 25, 44, 46, 5354, 57,
66, 71, 73, 7778, 120, 129, 131, 179
180, 184, 200201, 232, 239
mudana cultural, 66

NO
Nokia Test, 254
Ohno, Taiichi, 6, 20
oportunidades de melhoria
adequar Kanban para a cultura da sua
empresa, 204205
Deming e six sigma, 203
gargalos, eliminao de desperdcio, e
reduo da variabilidade, 200
Lean, TPS, e reduo de desperdcio, 202
teoria das restries, 200
five focusing steps, 201

P
padres de projeto, 29
Pask, Gordon, Award, 8
polticas, vi, viii, 38, 43, 45, 49, 53, 121, 140,
145146, 148, 167, 181, 190, 221, 227,
232233, 236, 241, 249, 252
previsibilidade, 235, 237
priorizao, viii, 37, 60, 64, 9293, 103, 113,
116121, 126127, 140
processo, 4, 67, 16, 1821, 38, 45, 71, 92,
179180, 196, 204, 232233, 238239,
244

QR
qualidade, 15, 2729, 3235, 40, 181, 189, 203
raias, 164165
Receita para o Sucesso, 39
ataque as fontes de variabilidade para
melhorar previsibilidade, 38

266

ndice
Captulo 2 ndice

crie folga, 36
equilibrando a demanda e o rendimento, 35
foco na qualidade, 2729
implementando a receita, 26
priorize, 3738
construindo maturidade, 38
influncia, 37
receita para o sucesso e Kanban, 39
reduzir trabalho-em-progresso e entregar
frequentemente, 2935
conhecimento implcito, 35
entregas frequentes aumentam a
confiana, 34
quem melhor?, 33
WIP, lead time, e defeitos, 3032
recursos compartilhados, 167168
Reinertsen, Donald, xv, 6, 26, 38, 223, 257
rendimento, 3536, 127, 153, 182, 202, 208,
210, 214, 235, 240
resolvendo um dilema do gerente gil, 110
adoo do Kanban pela comunidade, 8
do Drum-Buffer-Rope para o Kanban, 6
minha busca pela gesto de mudana bem
sucedida , 36
minha busca pelo ritmo sustentvel, 2
o valor do Kanban contra-intuitivo, 8
surgimento do mtodo Kanban, 7
reunies, vii, 9293, 96, 99, 116, 119121, 173,
226, 228
reunies de priorizao, 120
risco, 49, 53, 80, 141, 143, 147, 183, 185, 211,
234, 242243
ritmo sustentvel, 2, 6

S
Scrum, 92, 254
Shewhart, Walter, 203, 231233, 244
sistemas puxados, 6
Sistema Toyota de Produo, 202
Sistema Toyota de Produo (TPS)
Six Sigma, x, 143, 203204, 206, 231, 244
Solicitaes de Mudana, 77

standup, vii, 9092, 9899, 145, 187, 226228,


249, 252
sucesso, 27, 39

T
Telescpio Hubble, 105
Toyota, xiii, xiv, 67, 10, 18, 20, 55, 119, 201
202, 223, 231, 244
trabalho-em-progresso (WIP), vi, xiv, 3133,
3536, 38, 46, 53, 67, 123124, 128132,
150, 164, 168, 187, 190191, 217, 236,
241, 243
trabalho em progresso, 3132, 3536, 38
transparncia, 184, 239
trs tipos de oportunidade de melhoria,
199206
adequar Kanban para a cultura da sua
empresa, 204205
deming e six sigma, 203
gargalos, eliminao de desperdcio, e
reduo da variabilidade, 200
Lean, TPS, e reduo de desperdcio, 202
teoria das restries, 200
five focusing steps, 201
triagem, 95

U, V, W
user stories, 161, 234
valor, ix, 3638, 40, 7172, 82, 105107, 135,
153, 161, 171, 182183, 185, 189, 201
203, 211, 223230, 240, 242, 249
variabilidade, xi, 2627, 38, 40, 76, 102, 165,
211, 231, 233, 236237
variaes, 233, 239, 244
Visual Studio Team System, 120
Welch, Jack, 204
Wheeler, Donald, 38

Sobre o Autor

avid J. Anderson lidera uma firma de consultoria em gerenciamento focada em melhorar o desempenho de companhias de
tecnologia. Ele est na rea de desenvolvimento de software h aproximadamente 30 anos e gerenciou equipes em projetos de desenvolvimento de software gil na Sprint, Motorola, Microsoft, e Corbis.
David tem o crdito da primeira implementao de um processo kanban para desenvolvimento de software em 2005. David foi um fundador do movimento gil atravs do seu envolvimento na criao do
Feature Driven Development. Ele tambm foi um fundador da Agile
Project Leadership Network (APLN), um fundador signatrio da
Declaration of Interdependence, e um membro fundador do Lean
Software and Systems Consortium. Ele modera muitas comunidades
online para desenvolvimento lean/gil. Ele autor do Agile
Management for Software Engineering: Applying the Theory of
Constraints for Business Results. Mais recentemente, David est focado
em criar uma sinergia do modelo CMMI para maturidade organizacional com mtodos geis e Lean atravs de projetos com a Microsoft
e o SEI. Ele um co-autor da Nota Tcnica do SEI CMMI and Agile:
Why not Embrace Both! Ele mora em Sequim, Washington, EUA.

267

Recursos Adicionais
David J. Anderson and Associates
http://djandersonassociates.com
The Limited WIP Society
www.limitedwipsociety.org
Kanban Development Yahoo! Group
http://finance.groups.yahoo.com/group/kanbandev/
Kanban101
www.kanban101.com


Sobre o Tradutor

eu primeiro contato com David Anderson aconteceu em Janeiro de 2009,


quando participei do treinamento intitulado The Zen of Agile Management no
RSS Recife Summer School, iniciativa na poca liderada pelo CESAR Centro
de Estudos e Sistemas Avanados do Recife http://www.cesar.org.br/site/, organizao onde eu trabalho desde essa poca.
Uma boa parte dos conceitos e ideias apresentados durante o treinamento era
desconhecida por mim e fiquei surpresa com alguns deles pela simplicidade e
benefcios em curto prazo. Ideias como o mapeamento da cadeia de valor para
o contexto no qual seu projeto est inserido, projeto esse de qualquer natureza,
manuteno ou desenvolvimento, com a identificao dos papeis envolvidos em
toda a cadeia, como tambm dos papeis que alimentam/abastecem a cadeia e
daqueles que recebem os resultados. O conceito de anlise de demanda e categorizao destas em classes de servio para tratamento diferenciado na cadeia
de valor. A ideia de no estimar esforo para determinada classe de servio,
mas sim, trabalhar com cadncia de entrega constante, com escopo varivel,
utilizando a capacidade e produtividade da equipe.
Foram dois dias muito intensos, onde tudo foi abordado de maneira inovadora por David Anderson, isto , ele trouxe ideias j conhecidas, mas nos
provocando para entend-las de uma maneira diferente, considerando conceitos
de Lean e Agile. Finalizei o treinamento com a cabea cheia de ideias, mas sem
poder para implement-las nos projetos onde eu atuava.
Quando eu participei desse treinamento, atuava como Engenheira de
Qualidade de Software e tinha pouca autonomia para definir a metodologia
de desenvolvimento e acompanhamento a ser utilizada nos projetos de desenvolvimento de software; alm disso, a organizao havia obtido a certificao
CMMI3 h pouco tempo e estvamos aprendendo a tornar o processo de desenvolvimento organizacional mais gil, inicialmente utilizando SCRUM em
alguns projetos.
269

270

Sobre o Tradutor

Em Setembro de 2009, migrei para a rea de Operaes da organizao. Dessa forma, voltei a
trabalhar como Analista de Sistemas e fui alocada em um projeto onde a lder da equipe havia feito o
mesmo treinamento, e juntas utilizamos Kanban pela primeira vez dentro da organizao. O projeto
j estava dividido em iteraes com escopos definidos pelo cliente, mas o utilizamos mesmo assim e
no decorrer do projeto fizemos alteraes nos escopos pr-definidos com a colaborao do cliente a
partir de transparncia e visibilidade do status das atividades do projeto; construmos uma relao
de confiana com o cliente; a construo de confiana com o cliente um efeito colateral que emerge
com o uso de Kanban; assunto muito abordado por David Anderson nos seus treinamentos, efeito
o qual pude evidenciar em todos os projetos onde utilizei essa receita de sucesso. Essa iniciativa
rendeu resultados que foram apresentados no giles que aconteceu em Lima, no Peru, em 2010 e
no Agile Brazil 2010.
Aps essa primeira experincia, eu venho utilizando Kanban em todos os projetos de desenvolvimento de software os quais eu lidero, projetos estes completamente distintos. Inclusive, um dos
projetos no qual obtive resultados muito positivos foi apresentado no Lean Software and Systems
Conference 2011 em Long Beach, Califrnia.
Em Janeiro de 2010, tive a oportunidade novamente de realizar um treinamento ministrado por
David Anderson, dessa vez com foco em Kanban. Nesse treinamento, tive conhecimento que o livro
recm-lanado havia sido traduzido para o idioma Alemo; ento, abordei o David e perguntei se ele
tinha interesse de traduzir o livro para Portugus, trabalho esse que agora est nas mos do leitor.
O trabalho de traduo desse livro foi extremamente gratificante, pois pude entrar mais profundamente em todos os conceitos por trs de Kanban. Foi um trabalho feito apenas por mim, no
foi revisado a no ser por mim, e foi meu primeiro trabalho de traduo. Dessa maneira, o leitor
mais atento deve encontrar alguns erros. Sugestes de melhoria sero muito bem aceitas e sero
consideradas em prximas edies do livro; afinal, um livro que aborda um framework de melhoria
contnua deve tambm ser melhorado continuamente.
Procurei no traduzir termos que so utilizados rotineiramente dentro da rea de TI no traduzidos, com o objetivo de no confundir a mente do leitor. Espero que esse livro seja fascinante e
valioso para o leitor como foi para mim, e que sirva como base para uma transformao significativa
para a sua organizao. Convido voc tambm a participar ativamente da comunidade Kanban a
nvel mundial.
Andrea Pinto
Maro, 2012
Recife, Pernambuco
Lder de equipe, CESAR

Este livro inaugura a


segunda gerao dos
Metdos geis. Eu prevejo
que ele se tornar um
clssico instantaneamente.
Alan Shalloway,

David J. Anderson foi pioneiro na tcnica Kanban


com a Microsoft em 2004 e desde ento tem refinado
a abordagem. Kanban fornece os insights de David
nessa nova e evolucionria abordagem para gerenciamento de mudana. O Mtodo Kanban melhorar
a maturidade e a agilidade da sua organizao com
uma resistncia mnima a mudana.

Alisson Vale
Fundador, Phidelis

Com a popularizao dos


mtodos geis temos
muitas perguntas sobre
como mudar grandes
organizaes do caos para
um lugar melhor. A abordagem Kanban descrita
neste livro revolucionou
meu trabalho nesses ambientes, na melhor forma
Kaizen."
Rodrigo Yoshima,
Fundador, Aspercom

BLUE HOLE PRESS

ISBN 978- 0 - 9845214 - 6 - 3


B L U E
H O L E
PRESS

9 780984 521463

David J. Anderson

David J. Anderson um consultor


de gesto independente com
muitos anos de experincia
gerenciando, e liderando equipes
de software em algumas das
maiores empresas do mundo. Ele
fundador do Lean Software &
Systems Consortium e co-autor
da Nota Tcnica CMMI and Agile:
Why not embrace both! do
Software Engineering Institute.

Kanban mudou o meu


negcio. Lendo este livro,
eu agora entendo porque!

Mudana Evolucionria de Sucesso para


Seu Negcio de Tecnologia

CEO e Consultor Snior


Net Objectives

Este livro responde algumas perguntas:


O que Kanban?
Porque eu gostaria de usar Kanban?
Como fao para implementar Kanban?
Como identifico oportunidades de melhoria e o
que devo fazer em relao a elas?

kanban

Kanban est se tornando uma maneira popular de


visualizar e limitar trabalho-em-progresso em
desenvolvimento de software e no trabalho em tecnologia da informao. Equipes ao redor do mundo
esto incluindo Kanban nos seus processos
existentes para catalisar uma mudana cultural e
promover melhor agilidade no negcio.

Sequim, Washington
www.blueholepress.com
B L U E
H O L E
PRESS

David J. Anderson

KANBAN
Mudana Evolucionria de Sucesso para
Seu Negcio de Tecnologia
Prefcio de Donald G. Reinersten
Traduo Andrea Pinto