A Histria de um Sistema Kanban

Um dos aspectos mais interessantes dos mtodos geis sua estruturao conceitual.
Oficialmente so quatro declaraes de valor que nos inspiram, um pequeno conjunto de
princpios que nos guiam e uma grande quantidade de mtodos que nos ajudam a estabelecer
"como" as coisas devem ser feitas. Cada mtodo estabelece seu prprio conjunto de
pressupostos e prticas. E comum equipes de projeto adotarem prticas de diferentes
mtodos enquanto os adaptam s suas realidades.

Depois de quase cinco anos trabalhando com desenvolvimento gil, nosso dia-a-dia de
trabalho nos levou alm das fronteiras estabelecidas pelos diversos mtodos. Algumas prticas
se consolidaram e hoje esto imersas no nosso cotidiano de tal maneira que sem elas, tudo
pra. Outras foram vencidas pelo nosso processo de adaptao e acabaram em desuso.
Em janeiro desse ano, nosso processo adaptativo cruzou o caminho de uma nova abordagem
hoje especialmente defendida e divulgada por David Anderson e Corey Ladas. Essa
abordagem usa um kanban como elemento central para fazer fluir todo o trabalho necessrio
para tirar uma demanda da lista de desejos do cliente, transformando-o em software funcional.
O foco do modelo a entrega de software just-in-time. Isso significa essencialmente entregar o
software certo na hora certa e fazer isso repetidamente com o objetivo de diminuir ao mximo o
tempo entre a demanda e a entrega, por meio da deteco e eliminao das perdas que
ocorrem nesse intervalo. Na prtica, essa abordagem abre todas as portas para uma boa
implementao Lean e pode ser uma boa opo em determinados tipos de projetos.

O kanban o instrumento utilizado para amortecer as demandas e permitir o estabelecimento

do "fluxo" e do "pull system" to necessrios em ambientes que querem se beneficiar do
modelo de produo enxuta (Lean). At aqui no h nada novo. Projetos geis de modo geral
j se beneficiam do uso de kanbans j a bastante tempo. No entanto, esse modelo extrapola o
tradicional quadro de 3 colunas (Pendente, Em andamento e concludo) para um sistema que
sinaliza e restringe o trabalho de tal maneira que qualquer "hands-off" amortecido pelo
kanban e "puxado" (ao invs de alocado). O objetivo estabelecer o fluxo unitrio, um fluxo de
valor que comea na demanda e finaliza com a entrega efetiva para o cliente. Assim, o
desenvolvedor puxa do backlog de demandas, quem inspeciona puxa do backlog de inspeo,
quem faz deploy puxa do quadro de itens resolvidos e por a vai. O trabalho primeiro
sinalizado e s depois puxado por quem ir execut-lo, e este s puxa depois que sinaliza o
trabalho que acabou de fazer de forma que a prxima etapa do processo possa pux-lo
novamente at que ela chegue ao cliente. Ou seja, quem termina sempre sinaliza o item n e
ento puxa o n+1.

Nesse modelo, no h iteraes. H um fluxo contnuo de entregas e a previsibilidade dessas

entregas se d com base no SLA (Service Level Agreement) conquistado pela equipe. Para
chegar nesse ponto, a equipe precisa medir e controlar seu Lead Time e esse ser o principal
parmetro de controle da sua produo. Como no h iteraes, o backlog pode ser alterado o
tempo todo, cartes podem ser removidos, inseridos ou reordenados a qualquer momento.

J o esquema de priorizao se adapta bem a um cenrio onde h competio pelo recurso,

ou seja, um determinado nmero de clientes compete pelos mesmos recursos do projeto.
Nesse cenrio, a tarefa de priorizar no pode ser dos clientes, mas de um elemento
intermediador capaz de utilizar diferentes critrios para o estabelecimento da ordem pela qual
as entregas devem sair. A priorizao ser o resultado de uma anlise que leva em conta uma
srie de aspectos circunstanciais que envolvem questes tcnicas, comerciais e de negcio,
mas o aspecto mais relevante o chamado Cost of Delay, ou o custo decorrente de se fazer ou
no uma entrega hoje, amanh ou na prxima segunda-feira.

No que diz respeito a estimativas, a orientao no estimar. As demandas so categorizadas

para composio do SLA, no estimadas. E essa categorizao feita com base no feeling e
na experincia da equipe. As expectativas dos clientes devem ser adaptadas capacidade de
produo da equipe.
Hoje tenho visto a utilizao dos termos Kanban Development ou Sustaining Enginnering para
identificar esse modelo. Mas independentemente do modo como ele chamado, aqui na
empresa ele tem sido uma grande fonte de inspirao para avanarmos na organizao do
nosso modelo de trabalho.
No meu entendimento, essa abordagem no deve substituir os mtodos geis mais utilizados
atualmente, mas uma boa alternativa para projetos que no conseguem atender a alguns de
seus pressupostos. Ele se adaptar bem a projetos que:

1) J mantm o(s) seu(s) produtos em uso em ambiente de produo;

2) Demandam re-organizao constante do backlog;
3) H forte competio pelo recurso (o tempo investido nas features atende a diferentes
interessados)
4) vivel a utilizao de SLA (Service Level Agreement) como instrumento de negociao,
planejamento e prestao de contas junto aos clientes;
A seguir eu descrevo um pouco da nossa implementao dessa abordagem.

O elemento centralizador desse modelo o quadro kanban de acompanhamento do trabalho.

Ele identifica a parte mais relevante do backlog e tambm o chamado Work in Process. Nosso
quadro Kanban foi evoluindo na parede at chegar ao modelo apresentado na Figura 1.

Figura 1: Modelo kanban utilizado na parede.

O kanban era composto por cartes semelhantes ao apresentado na Figura 2. Mandamos

confeccionar esses cartes de forma a apresentarem informaes relevantes que no s nos
dessem um mapa visual do trabalho que precisava ou que estava sendo executado, mas
tambm que permitisse o registro de dados que tnhamos a inteno de monitorar (como o
tempo que o carto passava em cada estgio do nosso fluxo de trabalho).

Figura 2: Modelo de carto utilizado no kanban

Criamos trs categorias de cartes utilizando como critrio o benefcio que aquele tipo de
trabalho gerava para a equipe:

Cartes Verdes (Investimento): Agregam valor ao produto (novas features)

Cartes Vermelhos (Custo): Implementao necessria para manter o produto ou o cliente

em pleno funcionamento operacional (defeitos, extrao de dados, anlises de cenrios
complexos, infra-estrutura, etc). Normalmente cartes vermelhos representam o que eu
costumo chamar de aqueles-originados-devido-a-dbito-tcnico-aparente ou coisas-que-nosdistraem-de-agregar-valor-ao-produto, por isso essa cor gritante.

Cartes Amarelos (Improvement): Agregam valor ao modelo de execuo ou ao ambiente de

trabalho (Auto-improvement);

Cada carto recebe uma sinalizao que indica a sua expectativa de tamanho, o que
conhecido como T-Shirt Sizing. No nosso caso cada cor representa um dos 3 tamanhos
possveis (Small, Medium ou Large) ou simplesmente P,M e G.

Nosso objetivo ento medir quanto tempo cada tipo de carto leva para percorrer todo o fluxo
de trabalho, saindo do backlog at o status de entrega. Essa mtrica bastante conhecida no
modelo Lean como "Lead Time" e um dos principais elementos para monitoramento da
eficincia do sistema de trabalho, alm de ser til para a obteno de estimativas de datas para
entrega junto aos clientes.

Na nossa implementao, o backlog do kanban dividido em duas reas na parte esquerda

inferior do quadro. A primeira contm os 7 cartes de mais alta prioridade e contm aquelas
entregas que atingiram o estgio que chamamos de LRM (Last Responsible Moment). Ou seja,
cartes nesse estado requerem a ateno imediata da equipe, no por uma questo de
urgncia, mas porque ao compor o momento atual com o Lead Time da equipe, percebe-se
que estamos no momento certo para implement-los. A segunda rea contm os cartes que
"provavelmente" sero trabalhados nos prximos trinta dias. Os outros cartes do backlog
ficam guardados para no poluir o quadro.

Quando um desenvolvedor fica disponvel ele simplesmente "puxa" o carto que est no topo
da rea LRM (carto circulado em vermelho no topo dessa rea) para a rea associada ao seu
nome. A implementao envolve anlise, documentao, codificao e testes e est associada
a prtica de "Done Definition". Ao finalizar essa fase de implementao, o carto colocado na
rea de inspeo para que um outro membro da equipe possa "puxar" o carto para realizao
da inspeo.

Aps essa inspeo, o carto deixa o kanban da equipe de desenvolvimento e segue para um
novo kanban, dessa vez da equipe de atendimento ao cliente. Essa equipe puxa novamente o
carto para fazer o processo de deploy da demanda, explicando, notificando, instalando,

tirando dvidas ou executando qualquer operao que precise ser realizada no ambiente do
cliente. Veja Figura 3:

Figura 3: Kanban na rea de atendimento

Alguns pontos que achamos interessantes nessa abordagem:

- O foco completamente desviado para o controle e a otimizao da eficincia do sistema de

trabalho por meio do monitoramento do seu rendimento (Throughput);
- Mtricas simples (como Lead Time) mantm a equipe focada no objetivo global (rendimento
do sistema);
- Controle do WIP (Work In Process). O Kanban limita o trabalho em execuo, impedindo a
sobrecarga do sistema e forando-o a trabalhar com sua capacidade real; Um novo carto
s entra em WIP se um outro sair primeiro;
- A demanda deve se ajustar capacidade de produo do sistema (e no o contrrio).
Se a demanda no pode se adaptar ao fluxo, deve haver investimento no sistema para
que ele aumente o seu rendimento.
- Exposio imediata dos problemas: Os problemas so revelados e resolvidos no momento
em que eles surgem. Isso acontece porque o modelo depende do fluxo. Se um problema
interrompe o fluxo, o trabalho de todos afetado, o que faz com que ele seja resolvido mais
rapidamente;
- O esforo para estimar progressivamente reduzido at um nvel mnimo;
- Estimula o uso de prticas geis de engenharia e acompanhamento (controle visual, daily
meetings, pair programming, tdd, refactor, CI, etc) na medida em que a qualidade no pode

mais depender de inspees que s iriam acontecer muito tempo depois do desenvolvimento;
- Todo o trabalho da equipe convertido e mapeado em itens entregveis que tem valor real ou
para o nosso produto (cartes verdes) ou para nossos clientes (cartes vermelhos);
- Todo o trabalho da equipe est fisicamente visvel, nada fica oculto;
- Todos os entregveis passam um-a-um pelos mesmos estgios permitindo a implementao
do fluxo unitrio adotado no modelo Lean;
- Algumas ferramentas Lean so mais facilmente aplicveis. Veja Figura 4.

Figura 4: Value Stream Map (Clique para expandir)

Quando voc consegue trabalhar em termos de fluxo, uma coisa realmente interessante
acontece: voc comea a perceber as perdas. A reduo de perdas um dos elementos mais
importantes da abordagem enxuta e realmente difcil enxerg-las sem um fluxo estabelecido.
Depois de meses trabalhando dessa forma, as perdas apareciam para ns como painis de
neon piscando na nossa frente.
O que mais nos incomodou por muito tempo foi a redundncia do controle visual que tnhamos
no nosso quadro na parede, com o necessrio controle eletrnico que mantnhamos por meio
de um sistema de tickets (o Mantis) e pela necessidade de registrar os tempos para mudana
de estgio nos cartes para medio do Lead Time em planilhas eletrnicas. O quadro ficava
desatualizado com mais freqencia que gostaramos e a movimentao dos cartes dependia
da presena fsica das pessoas no escritrio. Em tempos de internet banda larga e remote
desktop, o recurso de trabalhar em casa era cada vez mais usado. Resumindo, qualquer carto
fora de posio nos incomodava demais.
A soluo veio por meio de um esforo conjunto da prpria equipe, onde alguns membros
trabalharam voluntariamente fora do seu horrio de trabalho para passar o kanban para o meio
eletrnico. Em menos de uma semana, conseguimos aposentar o quadro da parede e comear
a usar o que chamamos de kanban eletrnico. Ele apenas lia os dados do sistema de tickets e
os apresentava exatamente da mesma forma que estvamos acostumados a ver no quadro da
parede. Veja Figura 5 (Clique para expandir).

Figura 5: O kanban em sua forma eletrnica (Clique para expandir)

No modelo eletrnico, a rea "Entregue" s descarregada quando vira o ms. Essa
abordagem ficou bem melhor do que no quadro fsico, onde os cartes entregues no
permaneciam nem um dia sequer, pois eram imediatamente retirados para alimentao da
planilha eletrnica para clculo do Lead Time. O acmulo de cartes na rea de entregas d
uma sensao de produtividade para a equipe, j que ela consegue visualizar o resultado de
todo o seu trabalho no ms.
Com o tempo, o kanban comeou a nos mostrar tambm as mtricas calculadas
instantaneamente (eu precisava de vrias horas s para calcular manualmente o nosso lead
time e s ficvamos sabendo do nmero no fim do ms). Hoje utilizamos duas mtricas
principais:
a) Lead Time por categoria: revela o tempo mdio necessrio para fazermos nossas entregas
por categoria;
b) Nvel de Investimento no Produto: revela nossos nveis de "dbito-tcnico-aparente";

Figura 6: Nvel de investimento no produto

O kanban tambm passou a agregar ferramentas de colaborao, como a exibio de posts

publicados pela equipe no nosso blog interno. A idia extrapolarmos tambm para outras
fontes rss como o nosso wiki de documentao, os e-mails da nossa lista interna de discusso
e futuramente do twitter da equipe.

Figura 7: Team blog exibido no kanban

Por fim, ao passar o kanban da parede para a tela do computador, h o grande problema em
se perder o benefcio do controle visual que o kanban oferece. Mas nada que uma boa TV no
possa resolver...

Para saber mais sobre Kanban Development:

Lista de discusso no Yahoo Groups

Agile Management - David Anderson
Corey Ladas

Be the first to rate this post

urrently .0/5 Stars.

1
2
3
4
5

Posted by: alisson.vale

Posted on: 8/26/2008 at 7:47 PM
Tags: kanban
Categories: Projetos geis
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (7) | Post RSS
Related posts
Contando a Histria de uma Iterao com um Relatrio A3Documentao importante em
qualquer projeto. Aqueles que alegam que projetos ...Cycles of Assumptions EvaluationLast
May at the Lean SSC 2011 conference I introduced my thoughts to some colleagues about the
inter...Estudo de caso de um portal corporativo utilizado como instrumento para gesto de
projetos XPUm portal de contedo pode servir como um bom instrumento de acompanhamento
para projetos XP. Nesse ...

Comments (7)Helio Campos Mello de Andrade

Thursday, August 28, 2008 2:10 PM

Existe alguma possibilidade de vocs distribuirem o kanban eletrnico com uma licena livre?
Ou vcs j utilizam uma soluo livre?
alisson.vale
Thursday, August 28, 2008 4:20 PM

O Kanban eletrnico foi desenvolvido pela prpria equipe de trabalho. Levamos poucos dias
para torn-lo operacional, visto que todo o trabalho de movimentao dos cartes pode ser
feito pela prpria ferramenta de tickets.

No pensamos ainda em torn-lo open source, simplesmente porque ele est to preso ao
nosso cenrio que no sei se ele geraria algum valor para outros projetos com outras
realidades. Mas quem sabe? Eu particularmente adoraria torn-lo open source... Vamos ver...
Clavius Tales
Tuesday, September 09, 2008 11:42 AM

Oi, Alisson.

Brilhante como sempre! Magnfico "post". Vou fazer umas perguntas na [visaoagil], para onde
voc encaminhou o artigo.

Um abrao.

Tales

P.S.: desculpe a demora; que queria ler com calma.

Henrique Imbertti Jr
Friday, September 19, 2008 3:27 PM

Ol Alisson!

Aqui na empresa ns comeamos o desenvolvimento com Scrum h 3 meses e agora

queremos substituir os post-its por algo mais estruturado, como os cartes em uma superfcie
magntica.

Que tipo de material voc utilizou no seu quadro?

Abs,
Henrique

alisson.vale
Monday, September 29, 2008 10:57 PM

Oi Henrique,

Post-it no muito legal. Eu mandei fazer cartes em uma grfica com as cores e o modelo
que eu quis. Ficou baratinho: R$ 70,00 pra fazer mil cartes de 3 cores diferentes.

No precisa ser imantado. Compra aquele durex que vem em uma base de ferro. fcil de
manusear. O durex atende bem pra fixar os cartes na parede.