Kanban em 10 Passos

Jesper Boeg


Traduo para portugus e reviso
Leonardo Campos
Marcelo Costa
Lcio Camilo
Rafael Buzon
Paulo Rebelo
Eric Fer
Ivo La Puma
Leonardo Galvo
Thiago Vespa
Manoel Pimentel
Daniel Wildt

Coordenao de traduo
Leonardo Campos
Edio e reviso final
Leonardo Galvo
InfoQ Brasil, C4Media Inc.
Todos os direitos reservados.
http://infoq.com/br

Sobre o autor
Jesper Boeg trabalha como coach de Agile e
Lean desde o incio de 2006. Hoje Vice-
Presidente do departamento de Excelncia em
Agile da empresa dinamarquesa Trifork (parceira
do InfoQ nos eventos QCon San Francisco e
QCon London). Tem Mestrado na rea de
Sistemas de Informao na Universidade
Aalborg, com uma tese sobre como gerenciar
com sucesso equipes distribudas de
desenvolvimento de software. Jesper apoia
empresas e organizaes na adoo de
princpios Lean e Agile, com enfoque em deixar
claro o porqu de cada princpio. Jesper realiza
com frequncia apresentaes em conferncias
Agile e Lean. membro da comisso de
organizao do evento GOTO Aarhus e atuou
como coordenador de trilhas em vrias
conferncias QCon e GOTO.




Contedo

CONTEXTO E FUNDAMENTOS 4
QUANDO DEVO CONSIDERAR TRABALHAR COM O KANBAN? 4
O QUE KANBAN? 5
COMO COMEAR COM O KANBAN? 6
ONDE O KANBAN PODE SER UTILIZADO? 7
MITOS E FATOS DO KANBAN 7
PASSO 1: VISUALIZAR O FLUXO DE TRABALHO 10
PASSO 2: LIMITAR O TRABALHO EM PROGRESSO 12
COMPREENDENDO O WIP 12
VISUALIZANDO LIMITES DE WIP 13
IDENTIFICAO DOS LIMITES IDEAIS PARA O WIP 14
PASSO 3: ESTABELECER POLTICAS EXPLCITAS PARA GARANTIA DE QUALIDADE 16
ENTENDENDO A QUALIDADE 16
VISUALIZAO DAS POLTICAS 17
PASSO 4: AJUSTAR CADNCIAS 19
ENTENDENDO CADNCIAS 19
ESTABELECENDO AS CADNCIAS IDEAIS 21
PASSO 5: MEDIR O FLUXO 21
ENTENDENDO MTRICAS 21
O QUE MEDIR? 22
DIAGRAMAS DE FLUXO CUMULATIVO (CFD) 22
INTERPRETANDO O CFD 23
TEMPO DE CICLO 24
NDICE DE DEFEITOS 25
ITENS BLOQUEADOS 26
PASSO 6: PRIORIZAO 29
CUSTO DE ATRASO 29
VISUALIZANDO PRIORIDADES 30
PASSO 7: IDENTIFICAO DE CLASSES DE SERVIO 31
IDENTIFICANDO TIPOS DE TRABALHO 31
DEFININDO CLASSES DE SERVIO 31
VISUALIZANDO CLASSES DE SERVIO 32
PASSO 8: GERENCIAMENTO DO FLUXO 34
FILTROS DE DECISES 34
OTIMIZANDO O FLUXO, NO A UTILIZAO 35
ALIVIANDO GARGALOS 36
INTRODUZINDO BUFFERS 37
PLANEJANDO ENTREGAS 37
EXPERIMENTE! 38
PASSO 9: ESTABELECER SLAS 39
ESTABELECENDO O SLA CORRETO 39
PASSO 10: MELHORIA CONTNUA 41
BOA SORTE NA SUA JORNADA! 43


Kanban em 10 Passos

infoq.com/br 4
Contexto e Fundamentos
Antes de mergulhar no guia passo a passo de implementao do Kanban, vamos gastar alguns
minutos apresentando os conceitos para que se possa reconhecer onde cada passo se encaixa no
framework Kanban de gesto de mudanas. O escopo deste minilivro no descrever a fundo os
conceitos do Kanban; para isto, recomendo a leitura do excelente livro "Kanban" de David J.
Anderson.
Ao invs disso, fao uma pequena introduo seguida de conselhos no estilo passo a passo sobre
como iniciar no Kanban.
O Kanban, ou mais precisamente o "sistema Kanban para desenvolvimento de software" representa
uma implementao mais direta dos princpios de Desenvolvimento Lean de Produtos para o
desenvolvimento de software que os mtodos geis tradicionais. Com foco consistente no fluxo e
no contexto, o Kanban oferece uma abordagem menos prescritiva comparada ao Agile, e tem se
tornado uma extenso popular dos mtodos geis tradicionais como Scrum e XP.
A palavra "Kanban" vem do japons e significa "Carto Visual". Uma pesquisa pela palavra no
Google retorna mais de 5 milhes de resultados; isto porque a palavra tambm utilizada para
descrever o sistema que vem sendo utilizado h dcadas pela Toyota para visualmente controlar e
equilibrar a linha de produo. O termo tem se tornado quase sinnimo da implementao dos
princpios Lean. Ento, embora sistemas kanban sejam conceito relativamente novo em TI, vm
sendo utilizados por mais de 50 anos no sistema de produo Lean na Toyota.
O pioneiro no uso do Kanban em software foi David J. Anderson, que em conjunto com Don
Reinerstsen, tem se empenhado para expandir o conhecimento do Lean e o uso do Kanban para
visualizar e otimizar o fluxo de trabalho no desenvolvimento de software, nas reas de manuteno
e de operaes.
Quando devo considerar trabalhar com o Kanban?
Se a resposta for sim para uma ou mais das questes abaixo, existe uma boa chance de que voc
se beneficie da leitura deste livro:
! Voc tem se esforado para implementar o Agile em sua organizao, mas sem muito
sucesso?
! Voc tem usado o Agile por algum tempo, mas as melhorias de desempenho comearam a
estagnar?
! Voc est utilizando tempo precioso em prticas geis que j no parecem mais se encaixar
no contexto em que est trabalhando?
! Tem usado Agile como um checklist, mas sem compreender completamente os princpios
bsicos?
! Sente a necessidade de flexibilidade que v alm da oferecida por iteraes fixas e
planejadas?


Kanban em 10 Passos

infoq.com/br 5
! Suas prioridades mudam diariamente?
! Voc est utilizando processos criados para o desenvolvimento gil num contexto em que
no se adaptam facilmente, como por exemplo em manuteno e operaes?
! Precisa de uma transio gradual da execuo em cascata para o Agile, para evitar altos
nveis de resistncia organizacional?
Se seu objetivo trabalhar em um contexto estritamente voltado ao Scrum, ou se atualmente est
utilizando um processo cascata, ou se est tentando encontrar um caminho para otimizar sua
implementao Agile atual independente do caso, a maioria pode se beneficiar de conhecimento
mais profundo em Lean e o Kanban provou ser um excelente catalisador nessa direo.
O que Kanban?
Existem diversas abordagens para o Kanban, mas a maioria dos especialistas concorda que o
Kanban um mtodo de gesto de mudanas, que d nfase aos seguintes princpios:
! Visualizar o trabalho em andamento;
! Visualizar cada passo em sua cadeia de valor, do conceito geral at software que se possa
lanar;
! Limitar o Trabalho em Progresso (WIP Work in Progress), restringindo o total de trabalho
permitido para cada estgio;
! Tornar explcitas as polticas sendo seguidas;
! Medir e gerenciar o fluxo, para poder tomar decises bem embasadas, alm de visualizar as
consequncias dessas decises;
! Identificar oportunidades de melhorias, criando uma cultura Kaizen, na qual a melhoria
contnua responsabilidade de todos.
Tudo isso, com a filosofia subjacente de que se deve:
! Comear com o que se est fazendo agora;
! Concordar em buscar mudanas incrementais e evolucionrias;
! Respeitar o processo atual, com seus papis, responsabilidades e cargos.
Quem est familiarizado com o Lean ir reconhecer muitos desses princpios como sendo a
fundao para um sistema "puxado"(pull) Lean; forma tambm as bases para uma cultura de
melhoria contnua (Kaizen). O que o Kanban faz, em primeiro lugar, servir como um catalisador
para introduzir ideias Lean na entrega de sistemas de software. Isso tambm declarado por David
Anderson em seu livro:
O Kanban (com K maisculo) o mtodo de mudana evolucionria que utiliza um
sistema kanban (com k minsculo), alm da visualizao e outras ferramentas, para
catalisar a introduo das ideias Lean nas reas de desenvolvimento e operaes de TI.


Kanban em 10 Passos

infoq.com/br 6
Mostraremos diversos exemplos de quadros kanban nos captulos a seguir, alm de explicar a
mecnica da tcnica. Para se ter uma ideia dos conceitos fundamentais, a Figura 1 mostra um
exemplo.

Figura 1. Princpios do Kanban em ao
Como se v, todo o trabalho se torna visvel com o Kanban. Os limites de WIP so estabelecidos
(escritos na parte de cima de cada coluna). As polticas se tornam explcitas e o fluxo passa a ser
medido. Note que a ltima coluna no possui limite de WIP, devido equipe ter optado
especificamente por um ritmo semanal de entregas (3 da tarde na tera-feira. Isso significa que
todo o trabalho finalizado liberado neste momento, semanalmente.
O foco do Kanban conduzir mudanas evolucionrias, e estes passos simples tm-se provado
extremamente teis para esse objetivo. A razo pela qual nos referimos a esse sistema como um
"Sistema Puxado Kanban" (Kanban Pull System) que, ao visualizar o fluxo e estabelecer os limites
de WIP, garantimos que nunca se pode introduzir mais trabalho no sistema que a capacidade do
sistema de processar esse trabalho. Est disponvel apenas uma quantidade limitada de permisses
de trabalho (kanbans); ento necessrio que se complete o trabalho existente antes que um
novo trabalho possa ser iniciado. Isto resulta em funcionalidades sendo puxadas pelo sistema, com
base na capacidade deste, em vez de empurradas com base em previses ou demandas.
No h regras quanto aparncia especfica do quadro. As nicas limitaes so a imaginao, a
criatividade e as restries de um sistema eletrnico, ou o espao na parede. Como este minilivro
um guia para principiantes, iremos utilizar exemplos bastante simples de quadros para demonstrar
os fundamentos.
Como comear com o Kanban?
Espera-se que as 10 etapas apresentadas neste texto auxiliem o leitor a comear bem com o
Kanban mas antes de chegarmos nesse ponto, importante compreender que o Kanban aborda
a gesto de mudanas de forma diferente que a maioria dos mtodos geis.


Kanban em 10 Passos

infoq.com/br 7
O Kanban construdo sobre os conceitos da mudana evolucionria. Uma abordagem comear
a entender como funciona atualmente seu sistema de entrega de software. Quando conseguir
visualizar, medir e gerenciar o fluxo sendo utilizado, melhore-o um passo de cada vez, aliviando o
seu maior gargalo. Isso muito diferente do que ocorre, por exemplo, no Scrum onde se comea
redefinindo papis, processos e artefatos. Isso faz do Kanban um mtodo ideal para utilizao em
conjunto com processos existentes, que podem ser desde o Scrum at Cascata. O Kanban tambm
excelente em situaes em que estruturas organizacionais inibem mudanas radicais. Lembre-se
desse princpio fundamental: "Respeite o processo atual, seus papis, responsabilidades e cargos"
Em termos do Lean, isto significa que o Kanban construdo principalmente sobre o conceito de
Kaizen (melhoria contnua). O Kanban apenas usa Kaikaku (mudana dramtica) em situaes
especiais, nas quais mudanas estruturais so necessrias ou quando srias melhorias de
desempenho precisam ser realizadas.

Figura 2. O Kanban segue uma abordagem evolucionria para a otimizao de processos
Onde o Kanban pode ser utilizado?
Agora estamos quase prontos para iniciar. Porm, antes de mergulhar nos detalhes da
implementao, vamos falar rapidamente sobre os mitos do Kanban, para garantir que as sees a
seguir sejam lidas com os conceitos corretos em mente.
Na Trifork, ajudamos vrias empresas e equipes a aumentar a efetividade por meio da adoo do
Kanban. No incio, parecia que os principais grupos alvo eram as equipes de manuteno e
operaes, mas o Kanban se provou til tambm para o desenvolvimento de software. Equipes e
organizaes trabalhando com o modelo cascata tambm perceberam nessa abordagem
evolucionria a possibilidade de uma transio gradual para o desenvolvimento gil de produtos.
Mitos e fatos do Kanban
Mito: O Kanban adequado apenas para equipes trabalhando com tarefas pequenas e
padronizadas, como as de operaes e manuteno.


Kanban em 10 Passos

infoq.com/br 8
! Fato: O Kanban altamente inspirado pelo trabalho de Don Reinertsen, sobre o
Desenvolvimento Lean de Produtos. E se provou ser to boa opo para o
desenvolvimento de software quanto para operaes e manuteno.
Mito: O Kanban e o Scrum so opostos.
! Fato: Nenhum dos princpios do Kanban restringe o uso do Scrum. O Kanban funciona
como um agente de mudanas, e os princpios do Scrum devem, portanto, ser usados
apenas nos casos em que ajudam a otimizar o fluxo de trabalho. Nada impede de se
comear com o Scrum e utilizar o Kanban para impulsionar futuras mudanas muitos
projetos tm sido muito bem sucedidos com essa estratgia. Pode-se at argumentar que
esta era essa a inteno original com o Scrum tambm, mas de alguma forma se perdeu
com o foco em cerimnias, papis e artefatos.
Mito: Por no insistir no compromisso com iteraes planejadas, o Kanban torna-se vtima da Lei
de Parkinson, em que O trabalho se expande de modo a preencher o tempo disponvel para a sua
concluso.
! Fato: Apesar de ser uma preocupao vlida, os projetos com Kanban raramente
apresentam esse comportamento, pois as cadncias fixas, a visualizao permanente, a
medio do tempo de ciclo, e os ciclos de feedback curtos com o negcio, mantm o foco
controlado e as tarefas fluindo.
Mito: As equipes que utilizam Kanban no utilizam timeboxes (perodos fixos de tempo).
! Fato: Os timeboxes no so exigidos no Kanban, mas devem ser utilizados quando
ajudarem a otimizar o fluxo, o nvel de feedback e a qualidade. A maioria das equipes
Kanban praticam uma cadncia fixa de planejamento, reviso e entregas mas sem
vincular estritamente essas cadncias. Desse modo, dispensa-se o modelo tradicional de
iteraes, mas preservando o valor gerado.
Mito: As equipes Kanban no fazem estimativas
! Fato: As estimativas no so obrigatrias, mas devem ser usadas quando apropriadas. A
maioria dos projetos Kanban de desenvolvimento usam algum grau de dimensionamento
inicial ou para assegurar o gerenciamento, a priorizao e o alinhamento ideal de
portflio, ou para os trabalhos considerados mais sensveis anlise de custo/benefcio ou
ao desempenho relacionado a prazos.
Mito: O Kanban melhor do que Crystal/Scrum/XP/FDD etc.
! Fato: O Kanban antes de tudo um catalisador para a conduo de mudanas e precisa de
um ponto de partida. Assim, apesar de a maioria dos projetos poder se beneficiar do uso do
Kanban, o Kanban no um substituto para, por exemplo, o Scrum, que , na maioria dos
casos, um ponto de partida perfeito para a adoo do Kanban.


Kanban em 10 Passos

infoq.com/br 9
Embora a comunidade Kanban esteja constantemente lutando contra esses e outros mitos, o
Kanban ainda continua at hoje sendo um dos conceitos mais mal compreendidos na comunidade
gil, principalmente pelas duas razes abaixo:
Boa parte dessa confuso se devem ao fato de o Kanban ser um mtodo de mudanas e de
existirem nele poucas partes descritivas dizendo como se trabalhar, quais os papis existentes etc.
Como o conceito de um mtodo de mudanas mal compreendido, as pessoas tentam compar-
lo com mtodos prescritivos como o Scrum e o XP.
Exemplos locais e comportamentos emergentes do Kanban, em projetos do mundo real, passaram
a representar um "mtodo Kanban" para algumas pessoas. fcil ver porque h tanta
incompreenso, pois muitos projetos Kanban apresentam as mesmas prticas emergentes. No
entanto, a realidade que o Kanban se apoia no uso dos princpios Lean para otimizar processos
existentes, de forma evolucionria. Assim, no pode e no deve ser comparado com Scrum, XP,
Crystal, FDD ou outro mtodo que se esteja utilizando.
A segunda razo possvel que a palavra "Kanban" remete a muitos conceitos, que vm da sua
origem nos sistemas de produo Lean. O termo portanto talvez no seja palavra ideal para
descrever um mtodo de mudana para o desenvolvimento de software e operaes de TI.
Embora os sistemas puxados kanban impulsionem mudanas na forma que so usados em
sistemas de produo, o Kanban em software baseia-se em um conjunto muito mais amplo dos
princpios Lean. Isso cria uma dissonncia que dificulta o entendimento daqueles que trabalharam
com Lean no passado.
Voc vai perceber que muito da rejeio ao Kanban por partes da comunidade gil tem como fonte
esse mal-entendido.
A boa notcia que a maioria dos projetos, geis ou no, podem ser beneficiados pelo uso dos
princpios do Kanban, para impulsionar as mudanas e a melhoria contnua.
O leitor atento pode ter notado que o ttulo deste livro no est alinhado exatamente aos
princpios do Kanban. Como j disse David J. Anderson "o design do sistema Kanban um processo
de pensamento; no uma cpia ou modelo de implementao de processo". No entanto, que
estiver familiarizado com o "Modelo de Dreyfus para aquisio de competncias" ir reconhecer
que para se adquirir uma nova competncia, sempre so necessrias prescries iniciais.
Minha esperana que este texto introdutrio ajude o leitor a fazer a transio mais rpida e
suavemente. O mais importante saber que as receitas aqui apresentadas servem apenas como
uma forma de se adquirir conhecimento para avanar, e no como um ponto final ou uma lista de
verificao a ser seguida cegamente. Os modelos e prticas sugeridos nos dez passos deste livro
so comportamentos emergentes, constatados com experincia prtica em projetos utilizando
Kanban. O que sugerido aqui no se trata do mtodo de mudana Kanban em si.
Agora que temos uma ideia geral, vejamos como aplicar os conceitos na prtica. Cada passo a
seguir consiste de uma explicao concisa dos motivos, seguidos pelas prticas.


Kanban em 10 Passos

infoq.com/br 10
Passo 1: Visualizar o fluxo de trabalho
O primeiro passo para visualizar o seu fluxo de trabalho entender como seu sistema atual
funciona.
Compreendendo seu sistema de entrega de software
Para ser capaz de tomar decises bem embasadas sobre a melhor forma de otimizar o fluxo de
trabalho, o primeiro passo entender o que est sendo feito atualmente mas se deve resistir a
tentao de j realizar mudanas. Alm disso, deve-se mapear todo o fluxo de trabalho para a
entrega de software, sem focar apenas na parte de desenvolvimento.
Existem vrias formas de se mapear o fluxo de trabalho. A mais popular a utilizao do conceito
Lean de Mapeamento da Cadeia de Valor (Value Stream Mapping VSM). Recentemente, esta
prtica Lean tem sido atacada por comunidades geis o principal argumento que o de que o
trabalho com conhecimento no um processo linear, diferentemente de outras atividades em
sistemas de produo. Isso levou criao da tcnica de Redes de Criao de Conhecimento
(Knowledge Creation Networks), que so mais indicadas para atividades no lineares.
Para o exemplo simples apresentado aqui, porm, utilizaremos a tcnica VSM, que mais simples, e
que considero extremamente til. Deve-se, contudo, explorar a opo que melhor se adapte ao
contexto do leitor.
Em sua forma mais simples, um Mapa de Cadeia de Valor uma visualizao dos estgios pelos
quais passa o trabalho, desde a matria prima at o produto final em software, de uma ideia vaga
at uma funcionalidade implantada em produo. Para o trabalho de conhecimento (como o
desenvolvimento de software), o mais importante pensar em cada estgio como sendo a
representao de um grupo de atividades.
Em um estgio chamado Testes, por exemplo, h mais trabalho do que simplesmente testar,
incluindo corrigir, refatorar, discutir, atualizar critrios de aceite etc. Mas como o termo mais
representativo Testes, iremos definir nosso trabalho como estando neste estgio, enquanto
todas essas atividades estiverem acontecendo. O espao entre os estgios em que nenhuma
informao est sendo adicionada definido como tempo de espera (wait time). A Figura 3
mostra um exemplo retirado de um projeto real.

Figura 3. Exemplo de mapa de cadeia de fluxo de valor
Mais tarde, poderamos perceber que a implementao, na verdade, consiste em Detalhamento
das histrias de usurio e Desenvolvimento, seguido de Reviso de cdigo mas vamos focar


Kanban em 10 Passos

infoq.com/br 11
nessa verso simplificada por enquanto. Outras ideias de melhoria comeam a surgir: Por que
existe um tempo mdio de cinco meses da especificao at a implementao? Por que estamos
esperando duas semanas para testar? Resista tentao de lidar com essas questes por enquanto,
pois haver tempo de sobra para isso mais tarde. O foco agora entender como nosso sistema
atual funciona.
Inicialmente, uma boa ideia limitar o nmero de estgios, pois se pode perder rapidamente a
viso do todo ao dar muita nfase na mecnica. Mais tarde, pode ser benfico adicionar mais
detalhes e estgios, mas procure manter o fluxo o mais simples possvel por enquanto.
Visualizao do seu sistema de entregas
Agora que j temos um entendimento melhor de nosso sistema de entrega de software, o prximo
passo tentar visualiz-lo atravs de um sistema eletrnico, ou simplesmente utilizando um
quadro branco. A menos que se esteja trabalhando em uma equipe distribuda, geralmente uma
boa ideia comear apenas com o quadro branco. Nada torna seu trabalho mais visvel do que t-lo
sua frente o tempo todo e poder toc-lo fisicamente. medida que cresce a maturidade da
equipe e se sente a necessidade de coletar mais dados, pode-se querer mover a visualizao do
trabalho para uma verso eletrnica. Mas vamos nos ater ao quadro fsico por enquanto.
Muitas vezes, voc acabar com pelo menos dois tipos de estgios: os de Atividade, nos quais o
trabalho est sendo de fato realizado, e os de Buffer, nos quais o trabalho est aguardando para
ser lanado/desenvolvido etc. Veremos mais sobre isso adiante.
A primeira verso do seu quadro pode parecer com a mostrada na Figura 4. Perceba que todo o
trabalho necessrio para se completar uma funcionalidade representado no quadro, e no
apenas o desenvolvimento.

Figura 4. Estgio de atividade e estgio de buffer


Kanban em 10 Passos

infoq.com/br 12
Toda funcionalidade comea como uma ideia geral na "Caixa de entrada do PO" (PO Inbox, na
imagem) e termina na coluna Pronto para produo (Ready to Release, na imagem). A
funcionalidade removida desta ltima coluna quando est liberada e em produo. Note que no
fizemos mudana alguma pode-se ainda estar usando uma implementao estrita do Scrum.
Caso visualizar seu trabalho seja difcil, pare. No v alm, a no ser que tenha conseguido
visualizar todo o trabalho que voc faz. Se ainda existe informao escondida e algumas tarefas
estiverem completamente fora do seu sistema de entregas, h pouca chance de que se consiga
tomar decises fundamentadas sobre a melhor forma de otimizao. Uma regra geral que se
pode gerenciar apenas o trabalho que se pode ver.
Visualizar o trabalho difcil na vida real. As razes para a dificuldade so das mais variadas. Por
exemplo, as pessoas sabem que esto fazendo coisas que no deveriam; tm medo de serem
punidas caso seus superiores saibam como as coisas realmente funcionam; e apesar de cansadas e
sob presso, sentem que deixaro seus colegas desamparados se no estiverem constantemente
apagando incndios. Antes de seguir em frente necessrio corrigir esses problemas, e fazer com
que todos os envolvidos acreditem que ningum ser culpado ou responsabilizado por deixar claro
o trabalho que est realmente sendo feito.
Visualizar seu fluxo de trabalho gera uma srie de benefcios, sendo os mais importantes:
! Foco no todo: Fica visvel exatamente como o seu trabalho afeta as outras pessoas e
vice-versa;
! Transparncia: Todos sabem exatamente o que est acontecendo e nenhuma informao
escondida;
! Identificao de desperdcios: Surgir naturalmente um questionamento da razo pela
qual as coisas so feitas como so (mais sobre isto adiante).
Passo 2: Limitar o trabalho em progresso
Uma vez que consiga visualizar o fluxo de trabalho, mova para o prximo passo limitar o trabalho
em progresso (WIP).
Compreendendo o WIP
Para entender porque faz sentido limitar o WIP, precisamos passar pela Lei de Little: Tempo de Ciclo
= WIP / Produo por unidade de tempo (frmula adaptada para a terminologia do desenvolvimento
de produtos)
O tempo de ciclo o tempo que se leva para um item de trabalho passar pelo nosso sistema
kanban; em outras palavras, o tempo que se leva para uma funcionalidade selecionada para
implementao chegar produo. O que significa "selecionada para implementao" dependente
de contexto. Para alguns, a entrada de um item no backlog; para outros, trata-se do momento em
que um item selecionado para detalhamento. Pode-se tambm distinguir entre "Lead Time" e


Kanban em 10 Passos

infoq.com/br 13
"Tempo de ciclo": o primeiro seria o tempo desde a chegada do item at sua entrega; o segundo
o tempo desde a seleo para implementao at sua entrega.
O WIP descreve o total de trabalho em progresso no sistema kanban. Quantos pontos de
histria/histrias de usurio/itens de backlog esto atualmente em progresso em seu sistema?
Mais uma vez, isso vai depender do contexto. Alguns especialistas incluem todos os itens de
backlog no WIP; outros consideram apenas os itens selecionados para implementao.
Produo (throughput) por unidade de tempo a mdia do nmero de itens produzidos em um
determinado perodo de tempo. No Scrum, comumente chamado de velocidade.
Isso significa que, dado um sistema com 100 histrias de usurio em progresso (WIP) e uma
produo de duas histrias por semana, o tempo mdio de ciclo calculado como 100/2 = 50
semanas ou quase um ano. Reduzir esse tempo para 25 semanas poderia ser feito dobrando-se a
produo, ou reduzindo o nmero de histrias de usurio em progresso para 50. Na maioria dos
casos, mais fcil inicialmente reduzir o WIP do que dobrar a produo.
Como se pode perceber, limitar o WIP est intimamente ligado reduo do tempo de ciclo para
aumentar a produtividade e minimizar a quantidade de trabalho em que investimos tempo e
recursos (mas que ainda no gerou nenhum valor de negcio). Ciclos de feedback rpidos so
tambm uma excelente maneira de minimizar riscos, dado que as decises so validadas
continuamente e os problemas de qualidade so expostos imediatamente. Este um assunto
explorado mais detalhadamente no livro "Custos da Qualidade" de Capers Jones (1980).
Ento, como fazer? No h como saber o nmero exato de quantos itens deveriam ser permitidos
em cada estgio de nosso quadro, ento escolhemos um nmero da melhor forma possvel. Uma
boa ideia deixar que esse exerccio seja guiado pelas polticas em que sua equipe gostaria de dar
nfase. Caso a equipe ache uma boa ideia incentivar o trabalho em pares, ento se pode escolher
um limite de 3 para uma equipe de seis pessoas.
Veja que isto verdade apenas para colunas de atividade, como "desenvolvimento", "testes" etc. J
para colunas de buffer como "pronto para desenvolvimento", a regra geral que, se essas colunas
estiverem vazias uma vez por ano, o limite de WIP est muito grande (pois durante 364 dias o
buffer foi maior que o necessrio). E se estiver vazia todo dia, ento o limite est pequeno demais.
comum ouvir que o limite universal de WIP 5: se estiver em dvida, 5 provavelmente um bom
nmero para se comear.
Visualizando limites de WIP
H vrias formas de se visualizar o limite de trabalho em progresso. As Figuras 5 e 6 mostram duas
formas comuns de se fazer isso. Na Figura 5, apenas um item pode ser colocado em cada espao
desenhado no quadro, disparando um sinal visual quando houver uma "permisso" para
comear/puxar novas atividades (o espao est vazio).
Na Figura 6, mais fcil dividir o estgio da atividade em "em progresso" e "feito", j que o limite
de WIP simplesmente escrito no topo de cada coluna. Isso pode ajudar a compreender melhor o
funcionamento do seu sistema de entregas, e a maneira mais comum de exibir o limite de WIP


Kanban em 10 Passos

infoq.com/br 14
em TI. As pessoas que j trabalharam com manufatura Lean tendem a optar pela primeira verso
(Figura 5), pois se parece mais com o sinal para puxar mais trabalho, identificado pelo carto
visual.

Figura 5. Limites de WIP visualizados com containers

Figura 6. Limites de WIP visualizados usando nmeros nos cabealhos de colunas
Identificao dos limites ideais para o WIP
H vrias "escolas de pensamento" sobre qual o tamanho ideal dos limites iniciais de trabalho em
progresso (WIP), e estaria fora do escopo deste minilivro abordar esse tpico em detalhes. Uma das
formas, entretanto, de se definir um limite inicial observar o sistema e determinar valores com
certa folga, para que o fluxo de trabalho atual continue desimpedido. Em seguida, ao se identificar
o gargalo, comea-se a ajustar os limites, um por vez.


Kanban em 10 Passos

infoq.com/br 15
Uma abordagem mais radical seria determinar limites de trabalho em progresso muito pequenos;
menores do que o seu sistema capaz de lidar e colocar um buffer antes de cada estgio. Observa-
se, ento, onde o trabalho se acumula e gradualmente ajusta-se o limite do WIP at que o trabalho
flua atravs do sistema. Ambas as abordagens requerem experincia e no se espera um acerto
logo na primeira tentativa. No h concluso definitiva quanto melhor abordagem, mas
recomenda-se manter suas polticas de trabalho em mente, nas duas situaes.
Em qualquer situao, importante que se determine uma poltica explcita sobre como sero
tomadas as decises para alterar um limite. Para maximizar o aprendizado, o ideal tomar essas
decises em conjunto com a equipe, garantindo que todos possam expor suas opinies e entender
as decises. No se trata apenas do fluxo, mas tambm de aprendizado.
Lembre-se sempre que os limites iniciais de trabalho em progresso so apenas bons palpites,
dados em um momento em que se tem poucas informaes. medida que so adquiridas mais
informaes sobre o sistema, e encontradas melhores formas de se trabalhar, os limites devem ser
ajustados. Se, depois de trs meses, ainda se est trabalhando com os mesmos limites iniciais e os
mesmos estgios, h boa chance de que tenha sido perdido o passo mais importante: o de
melhoria contnua, que cobriremos mais tarde em mais detalhes.
Limites muito pequenos iro impedir o fluxo e deixar pessoas ociosas por tempo demais; ou ento
os limites sero simplesmente ignorados, sem discusses srias. Limites muito soltos, por outro
lado, aumentam o tempo de ciclo e mantm o trabalho parado por mais tempo do que necessrio.
O que se percebe rapidamente que, com os limites de WIP estabelecidos, seu sistema s ser
capaz de trabalhar at a capacidade. Vai ser necessrio finalizar uma atividade para conseguir
permisso para comear outra. Apesar disso parecer trivial, trata-se de um conceito fundamental
em um sistema puxado Lean, e uma ferramenta poderosa na busca por um sistema de entrega de
software que seja eficaz, sustentvel e previsvel.
Pode-se imaginar o funcionamento de um sistema puxado como uma corrente de clipes de papel.
Enquanto estiver puxando a corrente pela mesa por uma das pontas, os clipes seguem em uma fila
organizada, mas caso se decida empurr-los, h o caos (veja a Figura 7).

Figura 7. Pull contra Push: a metfora da cadeia de clips


Kanban em 10 Passos

infoq.com/br 16
No incio, haver desconforto por no se poder comear algo novo, mesmo quando isso parece ser
a "coisa certa" a fazer. Esse desconforto sinal de que existe um impedimento no fluxo. O mais
importante no ignorar o problema e aproveitar a oportunidade para realizar melhorias.
Nos momentos de discusso sobre o WIP, comum se focar demais no nmero de itens em
progresso. Mas no devemos esquecer que o tamanho dos itens tambm importante. Itens
grandes bloqueiam recursos por longos perodos e perturbam o fluxo ao passo que itens
menores fluem muito mais rapidamente pelo sistema de entregas, fornecendo feedbacks mais
rpidos. Porm, analisar os itens e quebr-los em partes pequenas, em um conjunto "mnimo de
funcionalidades vendveis" (minimal marketable features MMF) uma tarefa que requer
imaginao, habilidade e experincia.
Passo 3: Estabelecer polticas explcitas
para garantia de qualidade
Caso esteja familiarizado com a filosofia Lean, o leitor pode ter ouvido falar do termo "Qualidade
embutida" e pode se questionar porque a qualidade to importante. A resposta no est em
encontrar e corrigir defeitos, mas no fato de problemas de qualidade serem muito mais caros do
que se pensa.
No Kanban, concentra-se em criar polticas explcitas que otimizem a qualidade e deem
consistncia ao sistema de entrega de software e usamos essas polticas como base para a
melhoria contnua.
Entendendo a qualidade
Uma interface de baixa qualidade que impede a concluso de uma tarefa, ou um defeito que
atrapalha o fluxo de trabalho ambos so problemas de qualidade que estressam o sistema
Kanban, gerando ciclos de desperdcio. Isso conhecido em sistemas Lean como "demanda de
falha", e descreve todas as atividades e o retrabalho ligados baixa qualidade no projeto do
produto.
s vezes aceitvel lanar um produto com baixa qualidade para se obter mais feedback. Pode
haver tambm vantagens financeiras em permitir que se encontre o defeito em produo, ao invs
de em desenvolvimento pois o custo e o tempo poderiam ser maiores sem o feedback dos
usurios. Na maioria dos casos, porm, a baixa qualidade se trata apenas de um sintoma de
processo imaturo.
Por que problemas de qualidade so to caros? Verifiquemos essa questo em cenrios comuns no
desenvolvimento de software.
Um usurio (vamos cham-lo de Joo) no consegue concluir sua tarefa devido a um defeito em
nossa aplicao. Joo abre um chamado relatando o bug ou liga para o suporte de primeiro nvel.
Ele no sabe muito sobre o trabalho necessrio para um desenvolvedor investigar o problema, ou
talvez o suporte de primeiro nvel no conhea a aplicao to bem quanto deveria.


Kanban em 10 Passos

infoq.com/br 17
Em ambos os casos, informaes erradas ou inadequadas so passadas ao desenvolvedor, que
acaba resolvendo um problema diferente (que pode at no ser um problema e gerar um novo
bug); ou o desenvolvedor pode simplesmente desistir. At que o defeito seja corrigido, o usurio
insiste nesse processo. S que no foi apenas Joo que ficou impossibilitado de completar o que
estava fazendo. Informaes inconsistentes foram persistidas na base de dados, que agora requer o
uso de um script de SQL complicado para reverter os dados a um estado consistente.
No incomum que situaes como essa ocorram e de que 100 a mil vezes mais tempo e recursos
sejam gastos com a soluo comparando-se com o custo de evitar a introduo do defeito.
Alm disso, problemas de qualidade levam mudana constante de contexto e ao apagamento de
incndios. Naturalmente colocamos de lado o trabalho que estamos fazendo para corrigir um
defeito srio ou um problema de usabilidade no ambiente de produo. E quando, aps metade
do dia, o problema finalmente resolvido, no conseguimos lembrar dos detalhes do outro
problema complicado em que estvamos trabalhando e temos que gastar meia hora apenas para
se reambientar.
Por essas razes, o Lean d grande nfase na adoo de medidas para prevenir que falhas
aconteam no sistema de entrega, usando o Poka Yoke (pronuncia-se "Poc Ioqu"). Em sistemas
de produo, o Poka Yoke feito utilizando-se padres e checklists que devem ser seguidos para
se completar uma tarefa. Por exemplo, at clulas fotossensveis so usadas para registrar se uma
chave de fenda especfica est sendo utilizada a quantidade correta de vezes, ou se todas as partes
necessrias foram removidas de uma pilha.
Isso pode parecer um ambiente desumano para se trabalhar, mas na realidade os trabalhadores de
sistemas de produo Lean no se enxergam como robs seguindo cegamente padres e
checklists. Eles se veem como especialistas que esto constantemente tentando melhorar o
sistema no qual esto trabalhando, ao sugerirem aperfeioamentos e novas ideias. No livro
"Toyota: A Frmula da Inovao, 2006", de Matthew E. May, o autor refere-se a este fato como a
principal razo pela qual a Toyota ainda consegue implementar um milho de novas melhorias
todos os anos.
Visualizao das polticas
Mas como traduzimos, essas ideias para o desenvolvimento de software? J temos boa parte do
trabalho feito, pois j estamos visualizando o trabalho com o quadro Kanban e j limitamos o
trabalho em progresso. Tudo o que se precisa fazer agora adicionar no quadro as polticas sendo
usadas atualmente para assegurar a qualidade e a consistncia. Ao fazer isso, seu quadro pode ficar
parecido com o da Figura 8.


Kanban em 10 Passos

infoq.com/br 18

Figura 8. Polticas explcitas visualizadas no quadro
Repare que estgios inteiros podem ter polticas para garantia de qualidade, e que polticas
tambm podem servir para a garantia da consistncia e de qualidade do prprio processo (ex.:
medindo o tempo de ciclo e o ndice de defeitos). Tudo isso nos leva a outra prtica fundamental
do Kanban: tornar as polticas explcitas.
Vrias equipes j atingiram nveis extraordinrios nas prticas voltadas preveno de falhas nos
ltimos anos, e implementaram sistemas que eram impensveis apenas alguns anos atrs. O
movimento de Lean Startup tem mostrado que possvel lanar software em produo diversas
vezes ao dia sem indisponibilidades ou altos ndices de defeitos. Isto s funciona porque foram
adotadas prticas como testes unitrios, testes de integrao, e testes de regresso e de
desempenho, que ajudam a validar o cdigo assim como indicadores de desempenho que
sinalizam sempre quando o sistema no se comportar como esperado, retornando-o
automaticamente para sua ltima verso estvel. Isso torna quase impossvel introduzir
quantidades grandes de erros.
Tenha em mente que voc nunca deve se sentir dominado por suas prprias polticas e checklists.
Voc no um autmato; um profissional do conhecimento, observando constantemente e
tentando melhorar o sistema em que est trabalhando. Comece adicionando os procedimentos
que est utilizando no momento e adicione, remova ou altere esses procedimentos quando
perceber maneiras novas e melhores de garantir a qualidade. Cada defeito uma oportunidade de
pensar sobre como evitar que outro defeito aparea.
No comeo, pode parecer penoso analisar e aprender com cada defeito que surgir. Mas com o
tempo, conforme a qualidade melhora, o processo se tornar mais natural. Esse um preo que
vale a pena pagar, e conhecido como "Tolerncia zero" nos crculos de testes geis.
comum que essa ideia seja interpretada de forma incorreta, como "no podemos gastar o tempo
que gostaramos criando mecanismos para tornar os produtos prova de falhas". O que vale no
final que teremos zero defeitos. "Tolerncia zero" no significa que nunca mais possam existir
defeitos, e sim que devemos conscientemente refletir sobre cada defeito e buscar a perfeio.


Kanban em 10 Passos

infoq.com/br 19
Ao implementar o Kanban, essencial que todos se comprometam com as polticas adotadas
(inicialmente essas polticas descrevem apenas o processo atual), e que aceitem que necessria
uma deciso da equipe para mud-las. Quando algum decide infringir as polticas por conta
prpria, sem o envolvimento da equipe, o processo rapidamente degenera. Lembre-se: quando
voc sentir a necessidade de desrespeitar uma poltica, ser geralmente por uma boa razo e este
um bom momento para iniciar as discusses necessrias. Em relao s polticas, "altere mas no
quebre" a frase que sempre repito quando forneo treinamentos em Kanban.
Passo 4: Ajustar cadncias
Quando voc tiver conseguido visualizar seu fluxo, limitado o trabalho em progresso e
estabelecido polticas para assegurar a qualidade, a prxima coisa que se deve avaliar so as
cadncias ou ritmos de trabalho. Em um sistema de entrega de software h diversas atividades que
se beneficiam de cadncias regulares e encontrar a cadncia exata para cada tipo de atividade
essencial para melhorar o fluxo.
Repare que, em um sistema kanban, no somos obrigados a sincronizar tudo utilizando um
mnimo denominador comum. Podemos ajustar as cadncias de cada atividade para nveis timos
individualmente. Cadncias tpicas que precisamos considerar so a de planejamento (entrada) e a
de entrega (sada). H muitas outras cadncias, como a de reviso/retrospectiva e a de garantia de
qualidade. Vamos focar em planejamento e entrega, por enquanto.
Entendendo cadncias
Encontrar a cadncia ideal de entrega uma das tarefas mais importantes no Desenvolvimento
Lean de Produtos, pois ajuda a otimizar os ciclos de feedback, reduzir os riscos e otimizar o seu
processo de entrega. O feedback rpido faz parte do ncleo do Agile e do Lean. Quando fao o
coaching de equipes, continuamente friso que o trabalho que ainda no entregou valor deve ser
visto apenas como uma hiptese que precisamos validar o mais cedo possvel.
Apesar de entregar cada funcionalidade diretamente para produo ser a soluo tima
(considerando que se tenha um sistema otimizado para lidar com isso), na realidade, a maioria dos
projetos trabalham com duas cadncias de entrega.
! Uma cadncia em que o cdigo disponibilizado em um ambiente de pr-produo para
se obter feedback inicial (cadncia de lanamentos internos);
! Outra cadncia na qual a nova verso lanada em ambiente de produo (cadncia de
lanamentos externos).
Especialmente em projetos novos, estas duas cadncias podem estar muito distantes uma da
outra. Pode levar at cinco meses para que o sistema tenha funcionalidades suficientes para ser
colocado em produo. Ao mesmo tempo, o cdigo pode estar sendo lanado e testado todos os
dias em um ambiente de pr-produo.


Kanban em 10 Passos

infoq.com/br 20
O que importante ao escolher uma cadncia, tanto para as entregas internas quanto para as
externas, estar consciente dos impactos econmicos dessa escolha. Sempre h custos
transacionais associados com a entrega (por exemplo, o custo de mover sua verso de um
ambiente para outro); e sempre h um custo de espera (holding cost). O ponto timo entre esses
dois custos determina a cadncia ideal. Veja esse processo visualmente, na Figura 9, extrada do
livro de Don Reinertsen sobre Desenvolvimento Lean de Produtos (utilizada com permisso).

Figura 9. Otimizao do tamanho dos lotes
Quanto mais funcionalidades so includas em uma entrega, mais barato ser o custo por
funcionalidade (menor custo transacional). Em contrapartida o custo de espera maior, uma vez
que cada funcionalidade ter de esperar mais tempo para ser lanada. Isso resulta em perda de
valor de negcio, feedback desatualizado, decises pouco embasadas e menor envolvimento com
o usurio.
Custos de espera so um pouco diferentes para lanamentos externos e internos. Como um
lanamento interno no expe nenhum valor real de negcio para os clientes, os custos de espera
representam se restringem a feedback desatualizado, decises desinformadas e motivao do
usurio/negcio diminuda devido ao baixo envolvimento. Mas qualquer pessoa que tenha
trabalhado em um ambiente de negcios real reconhecer que esses problemas podem ser to
prejudiciais quanto a perda de receita.
O grfico da Figura 9, j citado, mostra uma curva do tipo "u" para a linha de custo total. A curva
apresenta uma parte inferior bastante suave, significando que no necessrio encontrar o ponto
timo exato para a cadncia de entregas. Mesmo com um erro de 10 a 15%, haver bons
resultados.


Kanban em 10 Passos

infoq.com/br 21
Estabelecendo as cadncias ideais
Muitos projetos, infelizmente, nem sequer consideram os aspectos acima com profundidade.
Diversas equipes geis maduras so capazes de fazer entregas em ambientes de pr-produo
com um clique de um boto mas ainda assim demoram trs semanas para receber o feedback
dos usurios sobre uma funcionalidade. Quando os custos de transao esto na casa dos poucos
reais, deve-se considerar seriamente o uso de lotes muito pequenos. Algumas vezes isso pode ser
problemtico, j que os usurios podem no estar disponveis, mas na maioria dos casos o que
acontece que a possibilidade nem sequer tinha sido considerada.
Outro ponto importante que a Toyota nos ensinou que os custos de transao no so fixos.
O movimento de implantao contnua (continuous deployment) tem mostrado que possvel
lanar verses confiveis para produo 50 vezes ao dia, para sistemas lidando com milhes de
pessoas. Isto s pode ser atingido com um procedimento completamente automatizado de
lanamento, e todo um conjunto de testes unitrios, testes de integrao e de regresso. esse
investimento que permite trabalhar em lotes de poucas linhas de cdigo.
As mesmas consideraes devem ser levadas em conta para se chegar a uma cadncia de
planejamento adequada. Quando o tempo entre os encontros de planejamento se torna mais
longo, mais coisas precisam ser planejadas em um grande lote. Isso resulta em mais esforo de
design em progresso e menos decises fundamentadas devido a um tempo de ciclo mais longo.
Por outro lado, realizar encontros dirios pode se mostrar custoso demais e aumentar o custo
transacional.
Em alguns casos, equipes que utilizam Kanban escolhem realizar o planejamento sob demanda.
Isso pode ser feito com o envio de um email para os interessados, convidando-os para um
encontro, ou uma conferncia. Isso sempre que houver espao para que a fila de entrada seja
preenchida com, por exemplo, os trs itens de maior prioridade. Normalmente o planejamento
"sob demanda" utilizado por equipes mais avanadas e requer experincia na gerncia dos fluxos.
Portanto, pense bem antes de comear com essa estratgia.
Passo 5: Medir o fluxo
Medir o progresso de projetos , infelizmente, um dos aspectos mais mal compreendidos e mal
aplicados no desenvolvimento de software. comum ver mtricas sendo usadas para tornar os
gerentes de projeto responsveis por aspectos sobre os quais no tm controle; ou ainda como
critrios de sucesso fixos, estabelecidos quando nem se conhecia o sistema a ser desenvolvido.
Entendendo mtricas
Em mtricas, uma regra bsica a ser lembrada que seu sistema de entrega de software tem
capacidade limitada. Quando o sistema pressionado alm da capacidade, haver queda na
qualidade, ritmo insustentvel, custos de manuteno mais altos, ou tudo isso ao mesmo tempo.
Ainda assim, sempre vemos gerentes de projeto quase orgulhosos de terem feito suas equipes


Kanban em 10 Passos

infoq.com/br 22
trabalharem alm do horrio por trs meses, ou que, por algum esforo heroico, conseguiram
controlar as coisas no ltimo momento, depois de semanas de caos.
Apesar de ser positivo comemorar grandes realizaes, os projetos de desenvolvimento de
software no precisam de heris, e sim de gente capaz de fazer entregas com transparncia e em
ritmo sustentvel. Tudo a mais simplesmente muito caro. Aqui se aplica uma frase de Kent Beck:
"se um problema precisa de mais trabalho que uma semana de horas extras, ento o problema no
deveria ser resolvido com horas extras".
Pode-se, claro, aumentar a capacidade no decorrer do tempo, contratando mais pessoas,
otimizando processos, ou os dois (mas cuidado ao fazer ajustes visando resultados de curto prazo).
Outra boa regra a ser usada : "seu sistema nunca ter mais capacidade do que a capacidade que j
provou ter". Seguindo essa regra, pode-se evitar os antipadres de excesso de otimismo e
comparaes com o sucesso dos outros. Comeando um projeto do zero, sua capacidade ser
apenas um palpite, baseado em desempenhos anteriores. O importante medir o progresso desde
o comeo para validar todas as suposies. Veremos mais sobre esse assunto no Passo 8.
Ento, pense em seu plano como uma ferramenta que serve como guia, no como critrio de
sucesso. E mea seu fluxo para determinar se voc ainda est no caminho certo. O objetivo obter
um sistema de entrega de software estvel e previsvel, para que se possa tomar decises bem
fundamentadas sobre prazos, dependncias, pessoal, escopo e custos.
O que medir?
Como medir o fluxo? Antes de escolher a forma de medir, deve-se sempre se perguntar o que ser
feito com a informao obtida. Se voc no pretende mudar nada com uma mtrica, provvel
que se trate de algo que no se deveria estar sendo medido. Para comear, sugiro quatro tcnicas:
Diagramas de Fluxo Cumulativo, Tempo de Ciclo, ndices de Defeitos e Itens Bloqueados.
Diagramas de fluxo cumulativo (CFD)
Diagramas de fluxo cumulativo parecem estar substituindo os grficos de burndown (comuns no
Scrum), nas equipes e organizaes geis mais maduras. So fceis de atualizar e fornecem uma
melhor perspectiva do estado do projeto.
Os CFDs mostram essencialmente um retrato da quantidade de trabalho em seu sistema, para cada
estgio de sua cadeia de valor, no decorrer do tempo. O grfico inclui o mesmo tipo de
informaes que grficos de burndown tradicionais, mas vai alm (veja um exemplo na Figura 10).


Kanban em 10 Passos

infoq.com/br 23

Figura 10. Exemplo de diagrama de fluxo cumulativo
Interpretando o CFD
A rea que mostra os itens "done" (prontos) representa a velocidade no decorrer do tempo. A rea
entre as linhas done e "backlog" o trabalho em progresso (WIP).
! Se a distncia entre duas linhas na rea do trabalho em progresso (WIP) aumentar, isso
pode ser um sinal de gargalos;
! Se a linha de backlog estiver mais inclinada que a de done, h sinal claro de que se est
adicionando mais trabalho ao sistema se comparado sua capacidade atual de entrega;
! Projetar onde as linhas que representam os itens de backlog e de done iro se encontrar
a melhor maneira de estimar a data final de entrega;
! O tempo mdio de ciclo e quantidade de itens na fila tambm podem ser extrados do
diagrama.
Aprender a interpretar um diagrama de fluxo cumulativo (CFD) fcil. A Figura 11, do livro de Don
Reinertsen, mostra uma excelente representao visual. Observe que a rea em preto representa o
trabalho em progresso (WIP).


Kanban em 10 Passos

infoq.com/br 24

Figura 11. Como ler um Diagrama de Fluxo Cumulativo
Tempo de ciclo
Apesar de seu Diagrama de Fluxo Cumulativo mostrar o tempo mdio de ciclo, medir os tempos de
ciclo individuais vale muito a pena em termos de previsibilidade.
Mdias podem ser enganosas. Uma representao visual trar informaes mais detalhadas sobre
a confiabilidade do seu sistema, alm da oportunidade de atender demandas dos clientes com
mais preciso (veremos mais sobre isso no Passo 9).
Medir o tempo de ciclo ainda mais fcil que atualizar o grfico CFD. Tudo que se tem de fazer
registrar o dia em que se comeou a trabalhar em um item (lembre-se de tornar esta poltica
explcita tambm). Quando o trabalho concludo, basta marcar o nmero de dias gastos para
completar o item. Assim, seu diagrama dever ficar parecido com o mostrado na Figura 12.
Como cada "passo" no eixo X representa um item de trabalho completo, as equipes
frequentemente escolhem deixar o eixo sem unidades.


Kanban em 10 Passos

infoq.com/br 25

Figura 12. Exemplo de diagrama de tempo de ciclo
Apesar de simples, o diagrama de tempo de ciclo pode trazer muitas informaes e responder
vrias perguntas sobre como seu sistema est funcionando:
! Os nmeros indicam algum nvel de consistncia ou os nmeros so incongruentes?
! Como est a tendncia? Aponta na direo correta?
! O diagrama permite investigar os nmeros muito discrepantes (positivos e negativos)
! O diagrama tambm permite verificar as consequncias das decises (tarefas grandes,
resoluo de incidentes, problemas de qualidade etc.)
Se 90% dos itens de trabalho levam menos de uma semana, possvel se comprometer com o
cliente dizendo que ele/ela pode esperar que 9 em cada 10 itens sejam feitos neste prazo.
importante lembrar que o tempo de ciclo um indicador tardio, o que significa que veremos
apenas os problemas depois que ocorrerem. Ou seja, quando tarde demais para fazer algo a
respeito. Portanto, devemos usar diagramas de tempo de ciclo em conjunto com um CFD, por
exemplo, para poder agir proativamente.
ndice de defeitos
Como mencionado, problemas de qualidade so extremamente caros, portanto importante ficar
atento a eles. Medir o ndice e o nmero total de defeitos em seu sistema uma maneira fcil de
evitar que problemas de qualidade fujam do controle.
surpreendente ver to poucas organizaes tratarem ndices de defeitos como um indicador de
chave de desempenho (Key Performance Indicator KPI). Indicadores de desempenho nos mostram
informaes valiosas sobre o estado do projeto, por exemplo:


Kanban em 10 Passos

infoq.com/br 26
! Por que o nmero de novos defeitos tem aumentado? Houve relaxamento de alguma
poltica de Qualidade?
! Como o alto ndice de defeitos na semana 20 afetou o tempo de ciclo?
! Qual o impacto no diagrama de fluxo cumulativo quando o nmero de defeitos aumentou?
Tome sempre cuidado para no tirar muitas concluses com base em conjuntos individuais de
informaes. Uma semana ruim pode ser apenas uma coincidncia. E no deixe de prestar ateno
s tendncias para saber se est tudo indo na direo correta. A Figura 13 mostra um exemplo de
um diagrama de ndice de defeitos.

Figura 13. Exemplo de diagrama de taxa de defeitos
Manter o nmero total de defeitos abaixo de 20 uma boa poltica para a maioria dos projetos. Se
a lista se tornar maior que vinte itens, fica difcil administr-la e se gasta muito tempo dando
manuteno no backlog de defeitos conferindo entradas duplicadas, defeitos desatualizados e
itens corrigidos. E quando o nmero alto, as pessoas parecem ficar mais preocupadas,
demandando mais relatrios e mtricas para acompanhar a lista de defeitos. Comeam a surgir
quadros gerenciais sobre defeitos e reunies semanais de acompanhamento, que roubam tempo
valioso. Mesmo defeitos cosmticos requerem ateno e exigem tempo adicional para administrar.
comum que se acabe tentando simplesmente alterar a categorizao da severidade dos defeitos
para se livrar do problema, mas uma soluo inadequada, devido s razes discutidas acima.
Itens bloqueados
Espero que voc j esteja convencido da importncia do fluxo para que os sistemas se comportem
com previsibilidade, e para que os processos individuais operem com eficcia. A maioria das
pessoas, independentemente do contexto ser Agile ou no, j viu itens ficarem bloqueados por
longos perodos e por vrias razes. Apesar de o grfico CFD e o diagrama de tempo de ciclo


Kanban em 10 Passos

infoq.com/br 27
mostrarem esse acmulo de atividades paradas, a equipe pode achar vantajoso medir e visualizar
explicitamente sua habilidade de lidar com esses problemas.
Algumas empresas utilizam o nmero de itens bloqueados e a habilidade de resolv-los como
indicador chave na medio do desempenho. Reconhecem que impedimentos tm srios efeitos
de longo prazo no sistema de entregas, e que a habilidade de resolv-los rapidamente bom
indicativo do desempenho e da eficcia da equipe. Itens bloqueados devem sempre estar visveis
no quadro. E medi-los no decorrer do tempo uma boa maneira de saber se a equipe est
caminhando na direo certa. A Figura 14 mostra um exemplo de diagrama de itens bloqueados.

Figura 14. Exemplo de diagrama de itens bloqueados
A forma mais comum de visualizar itens bloqueados no quadro simplesmente colar um post-it
colorido a uma funcionalidade, com o problema que est causando o bloqueio e a data em que
surgiu. A Figura 15 mostra um exemplo de quadro em que marcado um item bloqueado.


Kanban em 10 Passos

infoq.com/br 28

Figura 15. Visualizao de item bloqueado com marcador
Evite separar um local especfico do quadro para os itens bloqueados. Como esse local no faz
parte do fluxo atual de trabalho, h a tendncia de a rea no ganhar a devida importncia (at
que algum aparea berrando, querendo saber porque um item no foi concludo ainda!). Usar um
espao especfico do quadro tambm parece fazer com que haja menos interesse em resolver os
problemas, e mais interesse em declarar que outras partes so os responsveis pela resoluo.
Geralmente, quatro diagramas prximos ao quadro constituem o limite de quantidade de
informao que a maioria das pessoas capaz de absorver, antes que percam interesse ou ateno.
Mas importante que essas informaes estejam visveis; mant-las escondidas em uma planilha
em algum sistema eletrnico raramente chamar a ateno devida. A Figura 16 mostra os quatro
grficos discutidos nesse captulo, exibidos logo acima do quadro da equipe.


Kanban em 10 Passos

infoq.com/br 29

Figura 16. Mtricas de fluxo visualizadas no topo do quadro
Passo 6: Priorizao
Pode ser surpreendente estarmos no sexto passo e ainda no termos comeado a priorizar. Mas,
como diz David J. Anderson, caso no se tenha um sistema de entrega de software funcionando,
com um fluxo contnuo e entregas seguras e de qualidade, a priorizao ter pouca importncia.
Quando chega o momento de priorizar, como fazer esse trabalho da melhor forma possvel?
Focaremos aqui na priorizao de um tipo de trabalho especfico, as histrias de usurio. No
Passo 7, veremos como tipos de trabalho diferentes devem ser tratados.
Custo de atraso
Um conceito importante usado para priorizao o Custo de Atraso (COD Cost of Delay). O Custo
de Atraso representa a receita ou a economia perdidas com a escolha de no se trabalhar em um
determinado item (uma histria de usurio, por exemplo). A mais alta prioridade deve ser o item
com o maior custo de atraso. O custo de atraso geralmente associado ao Custo de Implementao
(COI), a prazos e a outros fatores.
No est no escopo deste texto explicar em detalhes o Custo de Atraso, mas aqui s precisamos
conhecer o conceito de custo de oportunidade e saber que toda vez que se escolhe trabalhar em
algum item, escolhe-se tambm bloquear algum outro. Calcular exatamente o COD quase
sempre impossvel no desenvolvimento de produtos; ento geralmente ser necessrio seguir


Kanban em 10 Passos

infoq.com/br 30
bons palpites. Aprender a associar um valor econmico ao trabalho desempenhado um exerccio
de amadurecimento para projetos e organizaes.
Visualizando prioridades
Para garantir que o item certo ser escolhido, a fila de entrada deve conter sempre os itens
ordenados por prioridade. Essa regra aplicvel tanto ao planejar um lote de trabalho para o
prximo Sprint no Scrum, quanto no trabalho com um fluxo contnuo. Neste ltimo caso, os itens
de maior prioridade so puxados continuamente sempre que houver uma autorizao de
trabalho. A Figura 17 mostra um exemplo.

Figura 17. Polticas de priorizao visualizadas no quadro
Outros fatores importantes para a priorizao, que tambm devem ser includos na classificao
final, so:
! Riscos e incertezas: obtenha informaes o mais cedo possvel, para apoiar decises de alto
risco e de alto impacto;
! Necessidades bsicas: infraestrutura do projeto etc.;
! Tamanho equilibrado: misture histrias de diferentes tamanhos para manter um fluxo
constante;
! Tipos de histria equilibrados: misture histrias funcionais e no-funcionais para garantir
um fluxo constante de valor;
! Dependncias: trate dependncias proativamente, para que o trabalho no fique
impedido.


Kanban em 10 Passos

infoq.com/br 31
Ao trabalhar com um backlog tradicional, ou uma especificao de requisitos como a do modelo
Cascata, contendo 50 itens ou mais, pode-se questionar quantos dos itens iro ser visualizados no
quadro. No h regra geral. Algumas equipes acreditam que melhor visualizar toda a fila de
entrada; outras mantm uma lista separadamente, em um local fsico ou ferramenta, e
gradualmente vo puxando alguns itens mais importantes para o quadro.
Gosto de usar o iceberg como metfora para descrever essa poltica. Apenas o topo do iceberg fica
visvel acima d'gua, mas quando removemos o topo (ou seja, puxamos os itens para o sistema), o
gelo abaixo emerge para formar um novo topo. Ao mesmo tempo, manter um limite explcito de
WIP na fila de entrada uma boa ideia, para que o trabalho em progresso no saia do controle.
Geralmente comparo um backlog com o piso superior no utilizado de uma casa. Caso se coloque
l tudo o que se tem medo de jogar fora, h pouca chance de encontrar o que realmente se precisa
quando necessitar. Mantenha o backlog enxuto e certifique-se que ele no esteja crescendo
demais e saindo do controle.
Passo 7: Identificao de classes de servio
Poucos questionariam a necessidade de tratamento especial de um problema que resulta em 10
mil usurios sem acesso ao sistema, causando perda de $10o mil por hora. Mas muitas vezes a
importncia e prioridade de um item no so to claras. Como ter certeza que foi escolhida a
melhor maneira de lidar com diferentes tipos de trabalho?
No Kanban, itens de trabalho so tratados de acordo com suas caractersticas. Esse tratamento
diferenciado recebe o nome de "classe de servio".
Identificando tipos de trabalho
Um bom comeo identificar os diferentes tipos de trabalho. Por exemplo, quase todos os projetos
de software possuem algum tipo de requisito, como histrias de usurio e casos de uso; tambm
possuem defeitos. Todos esses seriam tipos de trabalho. E se pode quebr-los em subtipos. Veja
alguns exemplos tpicos de tipos de trabalho:
! Histrias de Usurio (Pequenas, Mdias e Grandes);
! Defeitos (Cosmticos, Crticos e Impeditivos);
! Relatrios Manuais;
! Edies Textuais;
! Tarefas de Suporte;
! Instalao.
Definindo classes de servio
O prximo passo depois de definir os diferentes tipos de trabalho determinar como sero
tratados em seu sistema. Cada forma distinta de lidar com tipos diferentes uma Classe de Servio.
Abaixo definimos quatro classes de servio:


Kanban em 10 Passos

infoq.com/br 32
Classe Padro:
! Custo adicional: 0
! Tipos de trabalho: Defeitos cosmticos, histrias de usurio
! Tratamento especial: Nenhum
Classe Prioritria:
! Custo adicional: $500
! Tipos de trabalho: Defeitos crticos, histrias de usurio de alta prioridade
! Tratamento especial: Ganha prioridade em todos os estgios
Classe de Prazo Fixo:
! Custo adicional: $0-2000
! Tipos de trabalho: Histrias de Usurio
! Tratamento especial: Tem prioridade em todos os estgios, se o prazo estiver prximo; caso
contrrio tratada como uma classe de servio padro. A implantao emergencial pode
ser necessria.
Classe Urgente:
! Custo adicional: $3000-5000
! Tipos de trabalho: Defeito impeditivo
! Tratamento especial: Rompe os limites do WIP, para todo o WIP existente; implantao
emergencial
Em nosso sistema de entrega de software, uma classe de servio se diferencia de um tipo de
trabalho comum, de acordo com o tratamento especial que recebe. Observe que sempre haver
custos associados a algum tratamento especial, e medir o fluxo ir permitir fazer uma estimativa
mais embasada. Qual o efeito do tratamento especial? Qual seu impacto nos demais itens do fluxo
(considerando que se possa estimar o custo de atraso)? Quanto tempo mais, ao todo, ser gasto
devido a mudanas de contexto e de implantaes prioritrias?
Uma boa ideia colher dados referentes a vrias semanas. Assim ser possvel chegar a uma
melhor estimativa dos custos de tratar certos itens de forma especial. Ficar mais claro o efeito dos
itens urgentes sobre o diagrama de tempo de ciclo e o quanto implantaes emergenciais
atrapalham o fluxo e consomem recursos.
Em geral, uma boa ideia determinar um limite para o nmero de itens em classes no-padro em
seu sistema. Leve em conta a regra: "se tudo urgente, nada urgente".
Visualizando classes de servio
H diversas formas de se visualizar classes de servio. Duas das mais populares so um cdigo de
cores (Figura 18) e raias (Figura 19). Pode-se tambm usar uma combinao dessas duas formas.


Kanban em 10 Passos

infoq.com/br 33

Figura 18. Classes de servios visualizadas com um cdigo de cores

Figura 19. Classes de servios visualizadas com raias
A utilizao das classes de servio permite lidar com cada tipo de item de forma racional, de acordo
com seu impacto econmico, em vez de atacar o incidente reativamente. Permite tambm fazer
promessas fundamentadas aos clientes, levando em conta a classe de servio. Esse um tpico que
cobriremos em mais detalhes no Passo 9.


Kanban em 10 Passos

infoq.com/br 34
Passo 8: Gerenciamento do fluxo
Ao chegar neste ponto, j estaremos operando em um ambiente gil e maduro. Visualizamos o
fluxo de trabalho, o trabalho em progresso est limitado, polticas de qualidade esto
estabelecidas, o fluxo est sendo medido. O prximo passo aprender a interpretar o sistema e
tomar aes apropriadas quando houver oportunidades de melhoria.
Filtros de decises
Os filtros de deciso Agile e Lean, criados por David J. Anderson, sero teis para guiar nossas
aes. Veja a seguir as questes/aspectos considerados por cada um.
Filtro de decises Agile
! Estamos obtendo progresso mesmo com informao imperfeita?
! Estamos encorajando uma cultura baseada em alta confiana?
! Estamos tratando o WIP como um risco e no como um ativo?
Os dois primeiros itens do filtro so mais abrangentes; so utilizados para tomar decises mais bem
embasadas, ao se enfrentar desafios e situaes difceis.
Filtro de decises Lean
! Valor mais importante que fluxo
! O fluxo mais importante que eliminao de desperdcios
! Elimine desperdcios para melhorar a eficincia
O filtro de decises Lean diz, essencialmente, que o valor mais importante que o fluxo. Portanto,
deve-se ter cuidado ao abrir mo do valor gerado para reduzir o tempo de ciclo. Isso comum em
projetos geis, nos quais o valor de negcio e s vezes a qualidade so sacrificados apenas para
conseguir que mais trabalho seja feito.
Em um dos piores casos que j presenciei, trs equipes trabalhando no mesmo produto precisaram
fazer horas extras por trs meses. Quando perguntei porque isso aconteceu, a nica resposta que
consegui foi que havia uma longa lista de funcionalidades a serem desenvolvidas, e de defeitos a
corrigir. Quando perguntei sobre o objetivo de negcio, a maioria me olhou com olhar de
interrogao. Consegui convencer o grupo de que havia necessidade de chegar a um acordo com
o cliente sobre a viso para a entrega, em vez de trabalhar cegamente com base em uma longa
lista e finalmente senti que estvamos indo na direo certa.
Depois de uma semana de muito trabalho e negociaes, os POs e o gerente de programa
apresentaram uma nova viso. A maioria ficou satisfeita, mas uma pessoa perguntou: "Notaram
que o quadro no tem nenhum item que nos aproxime dessa viso?" Apesar de terem tentado
respond-lo com naturalidade, a vergonha estava estampada na cara de todos. A equipe tinha no
mnimo dez itens em vrios estgios no quadro, e nenhum deles estava alinhado com a nova viso.


Kanban em 10 Passos

infoq.com/br 35
Terem trabalhado tantas horas extras, por tanto tempo, parecia ter sido um enorme desperdcio de
tempo e recursos.
Foi uma lio valiosa. Pode-se ter o melhor sistema Kanban do mundo e um timo fluxo pela
cadeia de valor inteira, mas se no houver ciclos de feedback com base na sua hiptese de valor,
voc pode simplesmente estar gerando desperdcio com eficincia. Porm, o fluxo mais
importante que eliminao de desperdcio; ento tenha cuidado ao trocar fluxo por uma maior
utilizao de capacidade, por exemplo.
O momento de procurar eliminar desperdcios chega quando o valor e o fluxo j estiverem
otimizados; mas lembre-se de prestar mais ateno ao produto do que s pessoas.
Com os filtros de deciso Agile e Lean em mente, vamos examinar alguns conceitos fundamentais
na gerncia do fluxo em nosso sistema de entrega de software.
Otimizando o fluxo, no a utilizao
Ao procurar oportunidades de melhorias, evite pensar em termos de utilizao. Busque
oportunidades para aumentar o fluxo de itens de trabalho passando pelo seu sistema, e faa
perguntas como:
Os limites de trabalho em progresso (WIP) so adequados?
possvel diminuir o tamanho das histrias?
Existe alguma forma de identificar funcionalidades grandes, antes que entrem em seu
sistema e acabem bloqueando a capacidade por longos perodos?
possvel equilibrar o tamanho das histrias de usurio para criar um fluxo mais contnuo?
Pode-se treinar a equipe visando flexibilidade, para evitar silos e aliviar gargalos?
Existem buffers adequados em seu sistema para lidar com variaes?
O foco est na otimizao do todo e no na otimizao de estgios individuais?
A otimizao do fluxo em vez da otimizao da utilizao est no corao do pensamento Lean.
Os fabricantes de veculos norte-americanos costumavam medir e premiar pessoas de acordo com
a produo de portas, por exemplo mesmo que fossem ficar empilhadas em algum armazm.
Como efeito, mquinas individualmente trabalhavam de forma rapidssima, mas a produo como
um todo era mais lenta. Grandes armazns tornavam difcil a procura pelas peas ou de mov-las
de uma parte a outra. E se tinha uma quantidade enorme de recursos financeiros presa em
estoques.
O sistema Toyota de produo mudou completamente esse panorama. Mostrou que colocar o foco
no produto final, e adequar a velocidade das mquinas individuais velocidade com que veculos
saam da linha de produo (tempo ttico), trazia vantagens econmicas incontestveis.
O principal sempre pensar em termos de fluxo do produto final, e no em tornar mais rpidos os
passos individuais. Infelizmente, muitos gerentes ainda do nfase muito maior em fazer as


Kanban em 10 Passos

infoq.com/br 36
pessoas trabalharem mais rapidamente, do que na qualidade e no fluxo do produto. Lembre-se
sempre de observar o produto, e no as pessoas!
Em conversa recente com um cliente, em que todos estavam preocupados com a utilizao, surgiu
a pergunta: "O que fazer para garantir que todos estejam sempre ocupados?", qual algum
respondeu: "Tenho uma tarefa em que posso trabalhar sempre que no houver nada mais
importante a fazer". Perguntei h quanto tempo vinha trabalhando naquela tarefa e qual o valor
que gerava. "Trabalho nela h um ano, mas ainda no foi lanada, e nenhum valor foi gerado
ainda". Um de seus colegas perguntou quando acreditava que poderia ser lanada. A resposta:
"Devido a mudanas recentes em nosso portflio de produtos, provvel que a tarefa no faa
mais sentido e seja descontinuada em uma semana ou duas". O resto do grupo riu e admitiu
abertamente que esse no era um cenrio incomum na empresa.
Aliviando gargalos
A Teoria das Restries (TOC Theory of Constraints) prega que sempre haver um gargalo em um
sistema, limitando o fluxo de produo. Apesar da TOC oferecer uma viso simplificada do fluxo e
da forma de se lidar com os gargalos, ajuda a entender a importncia de ver o sistema como um
todo, e de aplicar esforos onde geram mais valor.
A utilizao de um sistema puxado kanban torna aparentes os gargalos. Ser percebido
visualmente o trabalho se acumulando nos estgios anteriores ao gargalo e ficando escasso em
estgios posteriores. Uma reao comum, nesse caso, adicionar mais capacidade mas essa nem
sempre a maneira mais efetiva de se lidar com gargalos. No se pode escalar pessoas como
mquinas, e o possvel aumento de capacidade por meio de aumento de pessoal muitas vezes
consumido por custos adicionais de coordenao e de treinamento. Vale lembrar a lei de Brook:
"Adicionar mais gente a um projeto de software atrasado gera mais atraso."
Em vez disso, procure aes para proteger o gargalo de trabalho desnecessrio. Em um dos
projetos de participei, identificamos que a equipe de POs representava o gargalo. Ficou claro que
boa parte do tempo era gasta na investigao de defeitos e no apoio a usurios que no haviam
recebido treinamento adequado para trabalhar com o sistema. Essas tarefas poderiam ser
facilmente transferidas para outros integrantes da equipe de desenvolvimento. Decidimos ento
fazer um rodzio dos desenvolvedores para realizar as tarefas, com isso retirando a sobrecarga no
grupo que estava gerando o gargalo.
A alternativa de mais longo prazo seria procurar entender o que levou situao atual e melhorar
os fluxos no sistema para torn-los mais intuitivos ou treinar melhor os usurios. A remoo de
trabalho que no gera valor de longe a forma mais efetiva de aliviar gargalos.
Uma terceira alternativa seria investigar se havia impedimentos bloqueando itens de trabalho para
a equipe de POs, o que poderia estar consumindo sua capacidade. Nesse caso, a equipe deveria
fazer o que se chama de swarm (esforo concentrado) para remover esses impedimentos o quanto
antes.
No livro "Kanban", de David J. Anderson, so apresentadas outras maneiras de se lidar com
gargalos.


Kanban em 10 Passos

infoq.com/br 37
Introduzindo buffers
Se voc sabe que existe um gargalo no sistema, uma boa ideia proteg-lo com um buffer logo
antes. Se, por exemplo, seu gargalo for o desenvolvimento, um estgio de buffer com itens
"Prontos para desenvolvimento" poderia ser adicionado. Escolher o tamanho correto para o buffer
exige experincia. Se o buffer esvazia frequentemente, duas vezes por semana, por exemplo,
recomendvel aumentar o seu tamanho ou avaliar se o estgio que est sendo protegido ainda
um gargalo (pode ser que um estgio anterior seja o gargalo, porque o buffer est ficando vazio
constantemente).
Planejando entregas
Apesar de ser chamado "Desenvolvimento de Produtos", a maioria das equipes que trabalham
atualmente com desenvolvimento de software desenvolvem suas atividades sob as restries da
gerncia de projetos custo, tempo e escopo. Pensar apenas em termos de fluxo muitas vezes
uma abordagem ingnua, j que haver gerentes ou diretores que esperam respostas a questes
como: Estamos no prazo? Os custos esto dentro do esperado? Podemos entregar o escopo
combinado?
Para chegar a essa situao, duas coisas precisam ser feitas. Primeiro, deve-se concordar que, como
no se pode fixar as trs restries ao mesmo tempo, o escopo ir ser flexvel. Atrasar uma data
combinada difcil e comumente significa muito tempo gasto em reorganizao, coordenao e
comunicao. Por outro lado, aumentar o oramento com o aumento de pessoal tambm,
conforme j vimos, raramente uma boa ferramenta para atingir um prazo apertado. Adicionar
pessoas um movimento estratgico de longo prazo. Aumentar o oramento no significa
aumentar o nmero de pessoas, e sim aumentar a quantidade de horas que as pessoas trabalham.
Isso pode ser uma ferramenta til se houver apenas uma semana de prazo. Mas em todas as outras
situaes, vale lembrar a declarao de Kent Beck, de que caso se tenha um problema que no
pode ser resolvido com uma semana de horas extras, o problema no deve ser resolvido com horas
extras.
comum que gerentes de projeto utilizem horas extras como ferramenta desesperada para
mostrar que esto tomando alguma atitude. Os gerentes sabem que no resolvero os problemas
dessa forma, mas fazem assim mesmo para mostrar algum tipo de ao. So raros os casos em que
alterar o prazo a soluo correta. Em caso de dvida, o melhor manter o escopo flexvel.
Em segundo lugar, preciso entender o que "escopo flexvel" um conceito que costuma ser
interpretado como abordagem "deixe fazer" no desenvolvimento de software, com pouca ou
nenhuma disciplina. Contudo, trabalhar com escopo flexvel exige justamente o contrrio. Deve
haver tanto disciplina quanto habilidade de medir o progresso com preciso, para garantir que so
bem fundamentadas as decises tomadas em um ambiente de mudanas contnuas. Esse um
fator fundamental para trazer o melhor retorno sobre investimento (ROI) possvel.
Sabemos que nossas estimativas originais, em termos de complexidade, custo e valor para o
negcio, foram feitas no momento em que tnhamos poucas informaes disponveis. Ainda assim,
nossos prazos e custos esto apoiados sobre essas suposies. Portanto, fundamental medir
nosso progresso para ter certeza que o projeto ainda vivel.


Kanban em 10 Passos

infoq.com/br 38
J que estamos utilizando diagramas CFD, por que no us-los para medir tambm o progresso?
Os oramentos, na maioria, so feitos com base em entregas; por isso vamos ver um exemplo desse
tipo. Ao ter um oramento, um prazo e um escopo inicial, simplesmente desenhamos nossa
velocidade esperada no CFD e medimos nosso progresso com base nela.
Lembre-se que a maioria dos projetos gera uma curva em S, e que os desvios, como regra geral,
indicam que h mais informaes disponveis do que havia antes. Somos, portanto, capazes de
tomar decises mais bem embasadas (inclusive a de encerrar o projeto).

Figura 20. Planos de entregas visualizados no diagrama de fluxo cumulativo (CFD)
A Figura 20 mostra um exemplo real de curva S sobre um grfico CFD. Como se v, era esperado
que o backlog crescesse por volta de 40% (com base em experincia) de 28 para 40 pontos. Mas
em determinado momento, ele havia mais que duplicado de tamanho (57 pontos). Apesar de a
imagem mostrar que se comeou com uma velocidade acima do esperado, a velocidade caiu
depois da metade da release, devido a problemas de qualidade.
Experimente!
Gerenciar o fluxo tambm significa tentar melhorar continuamente (visto em mais detalhes no
Passo 10). Muitos projetos fazem isso s cegas, sem ter como saber se as alteraes foram de fato
bem sucedidas.


Kanban em 10 Passos

infoq.com/br 39
Infelizmente, muitos projetos geis esto nessa categoria. As retrospectivas so utilizadas para
estabelecer experimentos, mas o acompanhamento (quando ocorre) apenas inclui verificar que o
experimento foi conduzido. claro que sempre haver boa dose de incerteza, mas de forma mais
frequente do que se pensa, as mtricas citadas neste livro oferecem indicao visual clara de que
algo funcionou ou no.
Por exemplo, considere o caso em que voc decide incluir mais analistas de teste equipe de
desenvolvimento, para fazer mais testes com antecedncia. esperado que haja uma queda no
ndice de defeitos em um prazo razovel, e ento se possa trabalhar com um limite de WIP menor
para o estgio de testes.
Gerenciar o fluxo significa ser capaz de interpretar seu sistema de software, para tomar as melhores
decises possveis com a informao disponvel, em busca do maior retorno sobre o investimento.

Figura 21. Alivie gargalos para melhorar o fluxo
Passo 9: Estabelecer SLAs
Nesse ponto, j estamos adiantados na direo de estabelecer um sistema de entrega de software
efetivo e confivel, e o momento de mostrar os resultados para o pblico externo. Possuir um
sistema puxado estvel, e utilizar mtricas simples para medir o desempenho do sistema, torna
possvel estabelecer acordos de nveis de servios (SLAs) que realmente so cumpridos. Isso ajuda a
manter o sistema saudvel e evita a tradicional recada de se voltar ao caos e ao apagamento de
incndios, a partir do momento que a iniciativa Kanban deixar de ser novidade. Ento como
funciona?
Estabelecendo o SLA correto
Diferentemente das abordagens geis tradicionais como o Scrum, que valorizam muito a
previsibilidade por meio do compromisso do Sprint, um sistema kanban pressupe que a


Kanban em 10 Passos

infoq.com/br 40
previsibilidade ser adquirida por meio de um sistema de entrega de software que funciona de
forma previsvel. Existe uma diferena sutil nessas duas abordagens em relao previsibilidade, a
qual no deve ser subestimada. Os mtodos geis so orientados por um plano; os sistemas
kanban, so orientados pelo fluxo.
Caso cada classe de servio tenha tratamento especfico e consistente ao longo do tempo, e as
consequncias dos esforos de melhoria sejam medidas, grande a possibilidade de que o tempo
de ciclo e a qualidade e os custos melhorem com o tempo. Tais informaes podem ser
compartilhadas com seus clientes. As classes de servio mencionadas anteriormente poderiam ter
SLAs semelhantes aos exemplos abaixo:
Classe Padro
SLA:
Mdia: 15 dias
90% dentro do prazo de 21 dias
Todas no prazo mximo de 30 dias

Classe urgente
SLA:
Mdia: 2 dias
90% dentro do prazo de 3 dias
Todas no prazo mximo de 4 dias

Classe de prazo fixo
SLA:
98% dentro do prazo

Classe prioritria
SLA:
Mdia: 8 dias
90% dentro do prazo de 13 dias
Todas no prazo mximo de 18 dias

O fundamental aqui que os nmeros so baseados em informaes colhidas por meio do
acompanhamento do desempenho de nosso sistema de entregas. Caso surja a necessidade de
informaes mais detalhadas, podemos facilmente ajustar as mtricas. Se, por exemplo, as classes
padro variarem muito em tamanho, pode-se adicionar detalhes para mostrar aos clientes o efeito
direto dessa variao como nos exemplos a seguir.
Classe padro
SLA 200-300 pontos (grande):
Mdia: 15 dias
90% dentro do prazo de 21 dias
Todas no prazo mximo de 30 dias


Kanban em 10 Passos

infoq.com/br 41

SLA 100-200 pontos (mdia):
Mdia: 13 dias
90% dentro do prazo de 18 dias
Todas no prazo mximo de 25 dias

SLA 10-100 pontos (pequena):
Mdia: 14 dias
90% dentro do prazo de 14 dias
Todas no prazo mximo de 18 dias

Para muitos clientes, essas informaes so valiosas para a priorizao. E saber que esses nmeros
so reais gera muito mais confiana e colaborao do que em projetos anteriores. Isso tambm
contribui para tornar visveis os benefcios diretos de se dividir o trabalho em partes menores
tanto em termos de riscos, quanto de custo e tempo de ciclo. Para garantir que todos estejam
cientes dos SLAs atuais e das Classes de Servio, a maioria das equipes considera til afixar essas
informaes prximas ao quadro, como mostra a Figura 22.

Figura 22. Polticas para classes de servios afixadas ao lado do quadro
Passo 10: Melhoria contnua
Criar e manter um ciclo constante de melhorias um dos elementos mais importantes ao
implementar o Kanban. Como dito anteriormente, o Kanban um mtodo para criar mudanas
evolucionrias e a boa notcia que ter seguido os passos anteriores torna muito mais fcil o
processo de melhoria contnua.


Kanban em 10 Passos

infoq.com/br 42
A grande distribuio de informaes com a visualizao do fluxo de trabalho e de polticas
explcitas, alm dos SLAs para cada classe de servio, grande incentivo ao dilogo constante
sobre oportunidades de melhoria muito alm do que se v em projetos de software tradicionais.
Todos os dias, somos obrigados a realizar decises explcitas sobre como lidar melhor com o
trabalho. O aumento na irradiao de informaes tambm constitui boa base para a melhoria
contnua. E parece haver um entendimento mais profundo dos conceitos do Agile e do Lean, de
quem trabalha em um sistema Kanban; portanto mais difcil acontecer retrocessos para um
processo anterior, ou a adoo de algum antipadro.
Como so coletados dados reais, o Kanban tambm oferece a oportunidade de executar e validar
experimentos de forma mais cientfica, em comparao ao que acontece em projetos geis
tradicionais. As iniciativas para melhorar o tempo de ciclo geralmente resultam em efeitos
mensurveis. Isso torna a melhoria contnua em um sistema kanban muito mais confivel e
consistente. E como podemos ver e medir os efeitos das iniciativas de mudana, ficamos muito
mais suscetveis a aumentar a exigncia quanto qualidade do sistema de entregas.
Para algumas pessoas, trabalhar com Kanban faz com que vejam pela primeira vez o sistema de
entregas como um todo, o que d uma percepo profunda do trabalho das outras pessoas, e de
como dependem de voc e vice-versa. Tambm surgem oportunidades de otimizar no apenas
silos individuais, mas todo o sistema de entregas.
Apesar de os crculos espontneos de qualidade (o termo Lean para discusses entre membros da
equipe) serem excelentes veculos para a melhoria contnua, muitas equipes usando Kanban
podem tambm se beneficiar de uma cadncia regular de retrospectivas (eventos Kaizen, na
terminologia Lean). As retrospectivas do oportunidade equipe de ver o trabalho de outra forma;
permite que surjam sugestes para mudanas estruturais maiores, conhecidas no Lean como
Kaikaku (mudana dramtica). A combinao de crculos de qualidade, reunies dirias e uma
cadncia de retrospectivas, forma um coquetel poderoso em prol de melhorias.
Como mencionado anteriormente, um fator fundamental na obteno desses efeitos se ater
regra "Mude suas polticas; no as quebre". Se as pessoas no agem de acordo com as polticas da
equipe, o sistema de entregas provavelmente ir se degradar com o tempo e no ser possvel
ver o verdadeiro valor de se visualizar o trabalho.
Frequentemente me perguntam se o Kanban no serviria como desculpa para voltar a prticas
disfuncionais, dada ausncia de regras para garantir o uso de prticas Lean ou Agile. Embora eu
compreenda a lgica por trs das perguntas, no tenho esse receio.
O Kanban uma forma nica de catalisar os princpios do Agile e do Lean, mesmo em situaes em
que aparentemente impossvel faz-lo. As poucas vezes que presenciei o Kanban falhar foram
devido falta de apoio da gerncia, que em alguns casos at mesmo trabalhou contra o processo.
Ou onde no houve esforos para explicar a importncia de visualizar o trabalho, gerenciar o fluxo
e obter feedback.
Para ser bem sucedido com Kanban, necessrio o comprometimento da gesto. Alm disso, as
pessoas que esto adotando os princpios em seus trabalhos dirios devem entender sempre
porque isso faz sentido. Quando tais aspectos esto presentes, no h razo para esperar que a


Kanban em 10 Passos

infoq.com/br 43
iniciativa ir falhar, ou que o sistema ser usado para desfazer iniciativas de mudanas anteriores,
ou regredir para prticas antigas e disfuncionais.
Boa sorte na sua jornada!
Espero que estes captulos possam ter inspirado voc a avanar na sua jornada Agile e Lean e a
usar o Kanban nos projetos de sua empresa. Adoraria receber seu feedback sobre esse trabalho,
assim como conhecer experincias suas sobre como o livro pode t-lo ajudado a obter um retorno
de investimento melhor para voc e os seus clientes.
Para se aprofundar em Kanban, sugiro entrar nos grupos de Kanban "kanbandev" e "kanbanops" do
Yahoo Groups, para participar de discusses sobre a aplicao do Kanban na prtica. Uma forma de
aprofundar ainda mais o conhecimento atravs da leitura dos seguintes livros:
Kanban, David J. Anderson, 2010
The Principles of Product Development Flow: Second Generation Lean Product
Development, Donald G. Reinertsen, 2009
The Elegant Solution: Toyotas Formula for Mastering Innovation, Matthew may, 2008
Lean Thinking: Banish Waste and Creaste Wealth in Your Corporation, James P. Womack
and Daniel T. Jones, 2003
The Toyota way: 14 Management Principles from the Worlds Greatest Manufacturer, Jeffrey
Liker, 2004
The Lean Startup: How Constant Innovation Creates Radically Successful Businesses
Boa sorte!
Jesper Boeg
jbo@trifork.com