Escolar Documentos
Profissional Documentos
Cultura Documentos
InfoQBrasil Kanban10Passos
InfoQBrasil Kanban10Passos
Jesper Boeg
Sobre o autor
Jesper Boeg trabalha como coach de Agile e
Lean desde o incio de 2006. Hoje VicePresidente 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
QUANDO DEVO CONSIDERAR TRABALHAR COM O KANBAN?
O QUE KANBAN?
COMO COMEAR COM O KANBAN?
ONDE O KANBAN PODE SER UTILIZADO?
MITOS E FATOS DO KANBAN
4!
4!
5!
6!
7!
7!
10!
12!
12!
13!
14!
COMPREENDENDO O WIP
VISUALIZANDO LIMITES DE WIP
IDENTIFICAO DOS LIMITES IDEAIS PARA O WIP
PASSO 6: PRIORIZAO
CUSTO DE ATRASO
VISUALIZANDO PRIORIDADES
16!
16!
17!
19!
19!
21!
21!
21!
22!
22!
23!
24!
25!
26!
29!
29!
30!
31!
31!
31!
32!
34!
34!
35!
36!
37!
37!
38!
39!
39!
41!
43!
Kanban em 10 Passos
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.
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?
infoq.com/br
Kanban em 10 Passos
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?
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:
Medir e gerenciar o fluxo, para poder tomar decises bem embasadas, alm de visualizar as
consequncias dessas decises;
infoq.com/br
Kanban em 10 Passos
!
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.
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.
Kanban em 10 Passos
!
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.
infoq.com/br
Kanban em 10 Passos
!
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).
infoq.com/br
Kanban em 10 Passos
!
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 comparlo 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.
infoq.com/br
Kanban em 10 Passos
10
Kanban em 10 Passos
!
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.
infoq.com/br
11
Kanban em 10 Passos
!
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;
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
infoq.com/br
12
Kanban em 10 Passos
!
"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.
13
Kanban em 10 Passos
!
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.
14
Kanban em 10 Passos
!
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. Observase, 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).
infoq.com/br
15
Kanban em 10 Passos
!
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.
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.
infoq.com/br
16
Kanban em 10 Passos
!
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.
infoq.com/br
17
Kanban em 10 Passos
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.
infoq.com/br
18
Kanban em 10 Passos
!
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.
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.
infoq.com/br
19
Kanban em 10 Passos
!
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).
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.
infoq.com/br
20
Kanban em 10 Passos
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
infoq.com/br
21
Kanban em 10 Passos
!
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.
infoq.com/br
22
Kanban em 10 Passos
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).
infoq.com/br
23
Kanban em 10 Passos
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.
infoq.com/br
24
Kanban em 10 Passos
Apesar de simples, o diagrama de tempo de ciclo pode trazer muitas informaes e responder
vrias perguntas sobre como seu sistema est funcionando:
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:
infoq.com/br
25
Kanban em 10 Passos
!
Por que o nmero de novos defeitos tem aumentado? Houve relaxamento de alguma
poltica de Qualidade?
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
infoq.com/br
26
Kanban em 10 Passos
!
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.
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.
infoq.com/br
27
Kanban em 10 Passos
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.
infoq.com/br
28
Kanban em 10 Passos
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
infoq.com/br
29
Kanban em 10 Passos
!
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.
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;
infoq.com/br
30
Kanban em 10 Passos
!
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.
31
Kanban em 10 Passos
!
Classe Padro:
Custo adicional: 0
Tipos de trabalho: Defeitos cosmticos, histrias de usurio
Tratamento especial: Nenhum
Classe Prioritria:
infoq.com/br
32
Kanban em 10 Passos
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.
infoq.com/br
33
Kanban em 10 Passos
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
infoq.com/br
34
Kanban em 10 Passos
!
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.
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?
35
Kanban em 10 Passos
!
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.
infoq.com/br
36
Kanban em 10 Passos
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.
infoq.com/br
37
Kanban em 10 Passos
!
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).
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.
infoq.com/br
38
Kanban em 10 Passos
!
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.
39
Kanban em 10 Passos
!
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
infoq.com/br
40
Kanban em 10 Passos
!
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.
infoq.com/br
41
Kanban em 10 Passos
!
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
infoq.com/br
42
Kanban em 10 Passos
!
iniciativa ir falhar, ou que o sistema ser usado para desfazer iniciativas de mudanas anteriores,
ou regredir para prticas antigas e disfuncionais.
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
infoq.com/br
43