Fundamentos da Agilidade
Nesta seo voc encontra artigos voltados para a prtica de mtodos geis.
Kanban: o gil adaptativo
Introduzindo Kanban na equipe gil
Flavio S. Mariotti
flaviomariotti@gmail.com
Especialista em Engenharia e Arquitetura
de Software. Ps Graduado pelo Instituto
de Pesquisa Avanada de Tecnologia IBTA
em Engenharia de Software baseado em
SOA. Bacharel em Sistemas de Informao
pela UNIUBE e tcnico em Processamento
de Dados pela FEB. Consultor independente
no desenvolvimento de software em arqui-
tetura OO, SOA, GIS e Plataforma .NET.
6 Engenharia de Software Magazine - Kanban: o gil adaptativo
De que se trata o artigo?
Este artigo traz uma breve abordagem do modelo
Kanban. O objetivo apresentar o sistema Kanban e
explicar sua proposta. Entender o conceito de visua-
lizao e o porqu algo to simples pode fazer uma
diferena to grande na qualidade dos resultados.
Em que situao o tema til?
Nos ltimos anos o conceito de metodologia gil
vem movimentando o mundo de desenvolvimento
de software. Metodologias mais populares como
Scrum e XP, criadas nas fabricas de software, vem
ganhando cada dia mais espao nas empresas
de tecnologia. Essas ferramentas surgiram com
a proposta de melhorar e agilizar os processos
envolvidos no desenvolvimento de software, po-
rm no mundo real fica claro que os processos ain-
da no esto perfeitos. Mas o que fazer ento,
sendo que essas ferramentas esto, teoricamente,
O
Kanban baseado na ideia
onde atividades em andamento
devem ser limitadas. Um novo
item s pode ser iniciado quando o item
em andamento finalizado ou quando
uma funo automtica inicia o mesmo
instantaneamente.
maduras e eficientes no que se prope? Como
identificar onde esto os gargalos que fazem as
equipes falharem nos seus sprints? Podemos dizer
com que o Kanban pode ajudar a identificar essas
falhas e solucion-las.
Resumo?
O mtodo Kanban para desenvolvimento de sof-
tware e processos geis tem como nfase no
sobrecarregar os membros que compe a equipe
de criao do produto. Por isso, o mtodo contem
princpios bsicos como: a equipe ou membro
deve iniciar uma nova tarefa quando capaz de
realiz-la agora, a equipe deve aceitar mudan-
as incrementais e evolutivas estimuladas pelo
mtodo Kanban e respeitar os atuais processos,
papis e responsabilidades. Neste sentido, este
artigo ir apresentar o sistema Kanban e explicar
sua proposta.
O Kanban, basicamente, tem como
principal objetivo transformar o tra-
balho em andamento visvel para toda
equipe, criando um sinal visual que
indica que o novo trabalho pode ou no
ser iniciado e se o limite acordado para
cada fase est sendo respeitado.

Neste momento, provavelmente voc est se perguntando,
o que isso tem de interessante? David J. Anderson teve essa
mesma sensao e segundo ele A teoria do Kanban no soa
muito revolucionria nem parece afetar profundamente o
desempenho, cultura, capacidade e maturidade de uma equipe
e a organizao na qual est inserida. Mas o impressionante
que afeta! O Kanban parece uma mudana pequena e, no
entanto, muda tudo a respeito de uma empresa.
Portanto, o Kanban no um processo e nem descreve papeis
e faces para serem seguidos. Podemos dizer que o Kanban
uma abordagem para mudana gerencial do projeto, um concei-
to para introduzir alteraes em um ciclo de desenvolvimento
de software ou gerenciamento de projetos.
Os mtodos geis fornecem transparncia sobre as ativida-
des em andamento e concludas, e reportam mtricas com
velocidade. O Kanban, no entanto, vai um passo alm e d
transparncia ao processo e seu fluxo, expondo gargalos, filas,
variabilidade e desperdcios. Portanto, tudo que impacta no
desempenho da equipe de produo e para entrega de valor,
fica explcito no modelo Kanban.
O que Kanban?
O nome Kanban de origem japonesa e sua traduo seria
como sinal ou carto. Portanto, vamos chamar de sina-
lizador ou melhor registro visual. O nome Kanban surgiu
dos sistemas de carto usados nas indstrias de produo, que
tinham como finalidade o gerenciamento do fluxo de trabalho
atravs da organizao de desenvolvimento.
O Kanban, com seu mecanismo de sinalizao, tem como
objetivo apresentar uma atividade de trabalho em processo,
ou seja, o nmero de atividades ou cartes em circulao
equivalente capacidade do sistema.
Uma outra caracterstica importante do modelo Kanban o
conceito de puxar tarefa quando h capacidade de process-
la. Esse recurso vai de encontro ao tradicional modelo de
empurrar tarefa conforme sua demanda, mantendo assim o
bom desempenho da equipe. Portanto, ao invs dos membros
que produzem o produto receberem atividades conforme suas
demandas, os requisitos so adicionados a lista de backlog e
puxados pelos membros que liberam suas atividades corren-
tes e se tornam disponveis para iniciar uma nova tarefa.
Uma boa metfora que descreve essa regra imaginarmos
uma rodovia que suporta at 100 veculos para manter o fluxo
de trafego com um bom desempenho, porm em todos os
feriados essa rodovia recebe em torno de 200 veculos. Essa de-
manda no suportada pela rodovia gera um congestionamento
afetando consideravelmente o desempenho do trafego. Logo,
no adianta empurrar um numero de atividades no suportada
pela equipe, isso ir causar um congestionamento e afetar o
desempenho de produo.
A implementao do modelo Kanban se resume em trs
etapas que so:
Visualizar os processos;
Limitar o trabalho em processo do ingls WIP (work in
progress);
AG IL I DAD E
Gerenciamento do lead-time, ou seja, tempo que a ativi-
dade leva para passar por todas as fases at a sua entrega.
O sistema Kanban
Para entendermos a proposta desde conceito, vamos primei-
ro estudar o sistema Kanban. Vamos chamar as tarefas que
compe o painel Kanban de cartes. O nmero de cartes
representa a capacidade limite acordada em cada fase de um
sistema que so colocadas em circulao.
Cada carto funciona como um mecanismo de sinalizao e o
sistema s permite iniciar uma nova tarefa quando um carto
est disponvel. muito importante respeitar essa regra, e fazer
com que qualquer novo trabalho espere em uma fila at que
um carto se torne disponvel.
O sistema Kanban fornece um mtodo simples, barato e fcil
de implementar e rapidamente comea a apresentar resultados
permitindo gerenciar o limite de atividades em andamento e
garantindo o bom desempenho da equipe.
Afinal, por que usar um sistema Kanban?
Ao entender a proposta de um sistema Kanban, se torna
simples perceber que o uso de um sistema prepara e limita o
trabalho em andamento para uma capacidade suportada pela
equipe. Esse recurso proporciona o equilbrio da demanda de
uma equipe controlando o seu rendimento, e consequentemente,
acelerando sua produo.
simples deduzir que todas as pessoas produzem mais
quando conseguem equilibrar a vida pessoal e profissional.
O Kanban buscar atingir um ritmo sustentvel de desenvol-
vimento para que todos os indivduos possam alcanar esse
objetivo entre vida pessoal e profissional. Segundo David J.
Anderson, O Kanban rapidamente elimina as questes que
prejudicam o desempenho, e desafia uma equipe para se con-
centrar em resolver essas questes a fim de manter um fluxo
constante de trabalho.
O Kanban atua fornecendo visibilidade nos processos, dei-
xando explcito os problemas e prendendo o foco da equipe em
qualidade. Portanto, este comportamento reflete os defeitos,
pontos de sobrecarga, custos econmicos sobre o fluxo de
rendimento e a variabilidade. A simples regra de limitar os
trabalhos em andamento no sistema Kanban estimula maior
qualidade e maior desempenho na execuo de cada tarefa.
O Kanban, com a combinao de fluxo, contribui para a reduo
do estresse da equipe e melhora a previsibilidade e colaborao,
refletindo com isso, nas datas de vencimento para entrega de ta-
refas. Com a equipe produzindo e cumprindo os prazos de libera-
o, o Kanban ajuda a fortalecer os laos de confiana dos clientes,
parceiros, fornecedores e outras entidades relacionadas.
Ao aplicar o Kanban, respeitando suas pequenas exigncias,
o sistema tende a contribuir para a maturidade da equipe,
podendo at afetar a cultura organizacional da empresa.
Com a identificao de falhas, a equipe consequentemente
concentra-se em uma fora tarefa para resolv-las, e por contar
com maior contribuio da equipe, a tendncia de prevenir
problemas futuros.
Edio 45 - Engenharia de Software Magazine 7
 Por conta desta filosofia, o Kanban vem mostrando efici-
ncia e ganhando diariamente diversos profissionais que se
renderam aos benefcios proporcionados por ele.
Aplicando o sistema Kanban no desenvolvimento de
software
Para o desenvolvimento de software, comum o uso de um
sistema Kanban digital. Porm, pode-se manter o conceito de
painel fsico e digital, isso reconhecido como boa prtica uma
vez que ele mantm o princpio de sinalizao visual.
Algumas empresas tem implementado o Kanban fsico utili-
zando lousas, painis, paredes ou tabuleiros. Na verdade, no
existe um objeto recomendado para usar, o importante que
este painel seja visvel, atingindo o conceito de sinalizador
visual. Ainda neste artigo sero apresentados alguns modelos
de painel Kanban.
importante lembrar a alguns profissionais que vem usando
paredes ou at mesmo portas do escritrio para sinalizar as ati-
vidades em andamento que, mesmo essa tcnica conseguindo
servir como sinalizador visual das atividades em andamento,
no podemos considerar isso um modelo Kanban. Para ser um
sistema Kanban necessrio existir a ideia de puxar tarefas,
conforme o limite acordado em cada fase, ou seja, para se tonar
um sistema Kanban necessrio aplicar as trs etapas cruciais
que so: criar o painel de visualizao, limitar os processos
WIP e gerenciar o lead-time, aplicando o conceito de puxar
uma nova tarefa quando um carto est disponvel.
Priorizao
Ao aplicar os trs primeiros passos para a implementao do
modelo Kanban, os resultados tendem a aparecer com: cdigos
de alta qualidade, lead-time de desenvolvimento relativamente
curto, e controle do desempenho de produo.
O gerenciamento do limite deve ser feito de forma rgida,
evitando a priorizao de excees imprevistas no negcio, e
focando no desenvolvimento dos itens conforme acordado na
estratgia do projeto. recomendado que a ateno da gesto
seja mais dedicada para melhorar a capacidade e previsibili-
dade de entrega.
Buscando a maturidade na produo
Para alcanar o adjetivo maturidade, fundamental que a
equipe primeiro busque aprender a construir cdigos de alta
qualidade e equilbrio no trabalho em andamento para cumprir
suas datas de entrega.
A busca pela qualidade est conectada com a velocidade no
nvel de produo. O desempenho da equipe de desenvolvi-
mento pode ser fortemente beneficiada com a eliminao de
retrabalhos, com isso, a equipe pode alcanar um ritmo de
produo de alta performance.
Comportamento emergente com Kanban
O Kanban foi implementado na Corbis em 2007 pelo seu
idealizador David J. Anderson. Este trabalho resultou em
uma lista de comportamentos emergentes que vem crescendo
8 Engenharia de Software Magazine - Kanban: o gil adaptativo
rapidamente com novas implementaes Kanban. provvel, e
esperado, que esta lista cresa medida que aprendemos mais
sobre os efeitos do Kanban nas empresas. Os comportamentos
que preenchem a lista atualmente so:
1. Processos limitados e adequados para cada fluxo do
projeto;
2. Desenvolvimento sem a necessidade de iterao;
3. Gerenciamento do custo de implementao;
4. Valores otimizados para classes de servios;
5. Gerenciamento de risco com alocao de capacidade;
6. Gesto quantitativa;
7. Tende a atingir outros departamentos;
8. Mescla pequenas equipes e proporciona um maior grupo
de trabalho.
Sinalizador visual Kanban
O sinalizador visual Kanban funciona como uma ferramenta
de sinalizao de processos, deixando explcito o fluxo de valor
atravs do processo em andamento. Para os adeptos ao Scrum,
o quadro Kanban pode ser comparado ao recurso de quadro/
placa Scrum para visualizao de tarefas.
Assim como a sequncia de colunas que representam os
diferentes estados de uma tarefa existente durante o processo
de desenvolvimento, o carto ou sinalizador Kanban movido
de uma fase ou estado para outro, at que tenha sido aprovado
para entrega.
Um quadro simples representando o sistema Kanban
pode conter as seguintes etapas: anlise, desenvolvimento,
aceitao e implantao. Esse modelo, primeira vista,
pode lembrar o conceito da engenharia de cascata, porm
na prtica, o Kanban no atua como o cascata e evita os
problemas decorrente do conceito. O Kanban tem como
linha de produo a regra de limitar o processo em anda-
mento, o WIP, essa regra evita as falhas apresentadas pela
engenharia cascata.
A teoria do sistema Kanban no quadro visual aplicada
com a regra em que cada coluna ter um WIP estabelecido
e representados pelo nmero mximo de cartes em cada
fase. O carto composto por uma breve histria do usu-
rio, descrevendo seus requisitos. Todo carto entra na fila
de backlog e aguarda a liberao de capacidade para entrar
nas colunas seguintes. Quando as atividades envolvidas
com o carto na coluna em andamento so finalizadas, o
mesmo movido para a coluna seguinte, liberando espao
para entrada de um novo carto.
O procedimento aplicado acima gera o conceito de puxar
cartes para inicializao. A prioridade dos cartes a serem
iniciados deve seguir as exigncias e estratgias do projeto.
Exemplos de sinalizadores visuais Kanban
O quadro de sinalizao visual do Kanban uma das princi-
pais etapas propostas pela ferramenta, porm, cabe ressaltar
que ao aplicar o limite de trabalho em andamento e determinar
o lead-time, importante customizar o quadro conforme suas
necessidades.

Nesta etapa do artigo, ser apresentado um modelo de quadro
Kanban. Este exemplo ser customizado conforme as necessi-
dades da equipe. O importante respeitar as poucas polticas
exigidas pelo Kanban, e depois customizar na tentativa de
acelerar e aperfeioar o conceito de comunicador visual.
A Figura 1 ilustra um modelo simples de sinalizador visual
Kanban. Nesta representao, fica fcil identificar o limite de
cartes estabelecidos para cada fase. Este limite est repre-
sentado pelos nmeros em vermelho no cabealho. Os cartes
ilustrados pelos retngulos representam uma breve histria
dos usurios, ou seja, as demandas. As imagens com formato
de rosto representam os responsveis pelos trabalhos em an-
damento. Portanto, este exemplo aplica as trs etapas cruciais
para obter os benefcios alcanados com o sistema Kanban.
Figura 1. Ilustrao de um sinalizador visual Kanban
importante ressaltar que o desenvolvimento de um quadro
Kanban ir evoluir conforme as necessidades de cada organiza-
o. Algumas empresas vem incluindo uma coluna chamada
Refletir. Esta fase prope uma reflexo por cada carto que
chega ao estado final do processo. Esta coluna adicionada
ao quadro na tentativa de aplicar melhoria continuada em
todos os processos.
Mattias Skarin publicou recentemente em seu blog dez
diferentes quadros de visualizao. Na apresentao de cada
modelo proposto por Mattias Skarin, fica clara a evoluo dos
sinalizadores conforme a necessidade de cada equipe. Conhea
mais acessando o endereo: http://blog.crisp.se/2009/11/16/
henrikkniberg/1258359420000.
Trabalhando com processos limitados
O Kanban vai alm de rastrear e demonstrar visualmente
o progresso de uma atividade em andamento. No Kanban, o
conceito de limitar o que deve ser feito aplicado em todas
as colunas do quadro. Essa uma maneira rpida de reduzir
o lead-time.
Para os usurios do Scrum, essa uma diferena fundamental
entre o quadro Scrum e o quadro Kanban. Um dos desafios co-
muns enfrentados com o Scrum o atraso na entrega conforme
AG IL I DAD E
o sprint. A entrega com atraso apresenta riscos e tende a afetar
o desempenho da produo, afetando significativamente o
resultado de valor entregue ao cliente.
O Scrum prope aos membros da equipe a trabalharem
juntos em apenas uma necessidade antes de iniciar um novo
item. O Kanban aplica essa orientao de forma implcita e
explcita, definindo um limite no nmero de itens em anda-
mento. Ao limitar a quantidade de trabalho em andamento, a
equipe , consequentemente, forada a colaborar na busca por
soluo nos itens que apresentam riscos para o desempenho
do desenvolvimento.
Outro benefcio alcanado com a aplicao de limites de
trabalho em andamento o ganho do conceito de puxar novos
itens, o que garante que nunca a demanda excede a capacidade
de produo. recomendado que os limites sejam estabelecidos
pela equipe em colaborao e a equipe de administrao ou
gesto do projeto. Isso contribui para otimizao no fluxo de
trabalho. Essa colaborao tambm implica na gesto alinhada
com a estratgia do negcio e proteo do limite WIP.
Benefcios alcanados com o Kanban
Alguns estudos vem mostrando os diversos benefcios alcan-
ados pelas equipes que adotaram o Kanban. Algumas van-
tagens observadas so: falhas tornam-se claramente visveis
em tempo real; o benefcio de encontrar os gargalos faz com
que as pessoas passem a colaborar ainda mais para a cadeia
de valor em vez de apenas fazerem a sua parte.
Um outro aspecto interessante do modelo Kanban que
ele fornece uma evoluo gradual do processo cascata para o
modelo de desenvolvimento gil de software. Com isso, vem
conquistando as empresas que ainda no tinham se rendido
s metodologias geis. O fato de poder fazer desenvolvimento
de software gil, sem necessariamente ter que usar o time-box,
iteraes e sprints de Scrum, torna o modelo mais amigvel e
fcil de ser adotado.
Outro benefcio relevante observado com o uso do Kanban
que, naturalmente, o conceito tende a se espalhar para outros
departamentos da organizao, aumentando a visibilidade de
tudo o que est acontecendo na empresa.
Combinando mtodos geis
Uma dvida frequente nas discusses e fruns sobre metodo-
logias geis : posso utilizar Kanban junto com meu processo
atual? A resposta simples e positiva, SIM. O Kanban vem com
a proposta de agregar. Portanto, o primeiro passo visualizar o
processo atual adotado pela empresa, e implementar os conceitos
Kanban para encontrar os gargalos existentes no processo.
Mitos e verdades do Kanban
Como toda metodologia, o Kanban j vem recebendo algumas
caractersticas que no condizem com a realidade. Uma delas
o mito que o Kanban no um processo com iteraes. Na
verdade, a iterao Kanban pode ser usada se necessria. Esse
recurso opcional, o importante faz-lo somente se existe
uma necessidade em seu contexto.
Edio 45 - Engenharia de Software Magazine 9
 Outro mito comum sobre o Kanban dizer que no se usa
estimativas, na verdade esse tambm um item opcional, e
requer cuidado com o uso desse recurso.
Um erro comum visto em debates sobre Kanban dizer que
esse modelo melhor que Scrum, XP, RUP e etc. O Kanban
apenas mais uma ferramenta do processo, e no h tal com-
parao para determinar qual melhor ou pior. Outro erro
dizer que o Kanban veio para substituir as tradicionais metodo-
logias geis. Novamente cabe lembrar que o Kanban apenas
um recurso que interfere sobre o gerenciamento de fluxo de
trabalho, portanto, sua proposta no substituir nenhuma
ferramenta, e sim, implementar os conceitos de mudana de
unidade, aplicando o modelo visualizao, limites de WIP e
evoluir com seus resultados.
Concluso
Com este artigo podemos concluir que o Kanban permite de
forma efetiva visualizar o fluxo de trabalho e dividir o trabalho
em partes, escrevendo cada item em um carto e incluindo
ele no painel de visualizao.
O uso de colunas nomeadas atua como sinalizador, ilustrando
onde cada item est no fluxo de trabalho. A aplicao de limite
de trabalho em progresso (WIP work-in-progress) em cada
coluna contribui para gesto e diminuio do lead-time.
provvel que diversas equipes de software adotem o
Kanban, sendo que algumas podem adotar o Kanban defini-
at o fluxo de valor da organizao. A verdade que vrias
empresas vem buscando alinhar seus esforos e ganhar vanta-
gens competitivas em seus mercados, e o Kanban, sem dvida,
pode ser uma ferramenta de auxilio na busca de uma produo
com alto desempenho.
Links
Limited WIP Society
http://www.limitedwipsociety.org/
InfoQ - Kanban
http://www.infoq.com/Kanban
Kanban and Scrum making the most of both
http://www.infoq.com/minibooks/kanban-scrum-minibook
David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business, 2010.
Jim Benson; Tonianne DeMaria Barry, Personal Kanban, 2011.
John M. Gross; Kenneth R. McInnis, Kanban Made Simple, 2008.
D seu feedback sobre esta edio! Feedback
eu

s
D
tivamente, enquanto outras equipes usaro Kanban no nvel A Engenharia de Software Magazine tem que ser feita ao seu gosto.

sobre e
de portflio de projetos, continuando a utilizar outras meto- Para isso, precisamos saber o que voc, leitor, acha da revista!

s
ta
edio
dologias no nvel de equipes pequenas. D seu voto sobre este artigo, atravs do link:
Kanban ainda uma ferramenta muito nova e vem se es- www.devmedia.com.br/esmag/feedback
tendendo desde pequenas equipes para o projeto de portflio

10 Engenharia de Software Magazine - Kanban: o gil adaptativo

Fundamentos da Agilidade
Nesta seo voc encontra artigos voltados para a prtica de mtodos geis.
Kanban no desenvolvimento de projetos de
software
Entendendo os desafios e a receita para o sucesso
Thiago Ghisi
thiago.ghisi@gmail.com / @thiagoghisi
Ps-graduando em Gesto de Negcios
(UNISUL). Bacharel em Cincia da Compu-
tao (UNISUL, 2011). Tcnico em Redes de
Computadores (SENAI, 2005).
consultor certificado para implementa-
o do MPS.BR e Sun Certified Program-
mer for the Java Platform, SE 6. H 6 anos
no ramo de tecnologia e desenvolvimento
de software, j atuou como: Professor Vo-
luntrio de Informtica, Tcnico em Infor-
mtica, Pesquisador de Iniciao Cientfica,
Desenvolvedor, QA, Gerente de Projetos,
Analista de Sistemas e de Requisitos, Au-
ditor de Garantia da Qualidade (PPQA) e
Analista de Processos. Possui experincia
na definio e implantao de processos
aderentes ao CMMI e ao MPS.BR e, em ava-
liaes MA-MPS nvel F e SCAMPI Classe A
nvel 2. entusiasta em desenvolvimento
gil desde 2007. Atuamente, trabalha na
Nexxera Techpeople, em Tubaro, SC.
De que se trata o artigo?
Neste artigo ser apresentado o mtodo Kanban,
uma interessante e simples abordagem para mo-
nitoramento e melhoria de processos de software
que tem uma forte inspirao no Sistema Toyota de
Produo.
Em que situao o tema til?
Se a sua empresa ou a sua equipe est com difi-
culdades para melhorar a forma de trabalho, no
importando se ela usa ou no mtodos geis, o
Kanban pode ser uma das melhores alternativas
para fazer isso com o mnimo de resistncia. Alm
de ser um mtodo muito simples, comparado
maioria das metodologias/frameworks de desen-
volvimento atuais, suas propriedades promovem
a colaborao.
N
o h mais dvidas de que a in-
dstria de software uma das
mais importantes atualmente.
O mercado brasileiro de software e ser-
vios de TI, segundo o ltimo relatrio
da ABES [9], de US$ 19 bilhes e cresce
de 25% a 30% ao ano desde 2004. Porm,
grande parte do software produzido
Edio 45 - Engenharia de Software Magazine
Resumo?
O mtodo Kanban para desenvolvimento de sof-
tware a cada ano ganha mais destaque na inds-
tria de TI, pois vem conseguindo promover a me-
lhoria contnua no processo de trabalho de muitas
equipes de empresas das mais variadas reas de
negcio e tamanho. Nesse artigo apresentada
uma introduo ao mtodo Kanban, destacando
os seguintes tpicos:
t
)JTUSJDP
F
BT
NPUJWBFT
RVF
MFWBSBN
%BWJE
"OEFS-
son a fazer a adaptao do mtodo da indstria de
manufatura (Toyota) para a indstria de software;
t
"T
DJODP
QSPQSJFEBEFT
DFOUSBJT
F
P
GVODJPOBNFO-
to do mtodo;
t
,BOCBO
QPEF
TFS
DPOTJEFSBEP
VN
NUPEP
HJM
t
6N
HVJEFMJOF
QBSB
UFS
TVDFTTP
DPN
P
NUPEP

Kanban, focando principalmente no que deve ser
priorizado para se obter as melhorias mais signifi-
cativas mais cedo.
ainda defeituoso, inadequado aos de-
sejos do cliente, entregue fora do prazo
e acima dos custos esperados.
Observando esses e muitos outros
problemas, h mais de 10 anos, 17
profissionais da rea escreveram e
assinaram um manifesto: o manifesto
para desenvolvimento gil de software.
11
Neste, todos concordaram com alguns valores comuns,
dentre eles:
As metodologias geis concentram-se nas pessoas envolvidas
na produo;
Os planejamentos em longo prazo so falhos;
mais importante aceitar e adaptar-se a mudanas do que
seguir planos rgidos;
Software funcionando o melhor indicador de progresso
nos projetos de software.
Tendo como base grande parte dos princpios desse manifes-
to, bem como a filosofia Lean do Sistema Toyota de Produo
(TPS Toyota Production System), surgiu o Kanban para
Desenvolvimento de Software.
A filosofia Lean tem como objetivo a constante identificao
e a eliminao de qualquer espcie de desperdcio no sistema
de produo.
A histria do Kanban para desenvolvimento de software,
assim como a histria da grande maioria das metodologias,
modelos de maturidade, processos de desenvolvimento e pro-
cessos em geral, comea com um grande desejo, muitas ideias,
testes (na prtica) e diversos ajustes (o mtodo cientfico) at
atingir os primeiros casos de sucesso.
A principal diferena do Kanban para as demais metodolo-
gias de desenvolvimento de software atuais que ele foi um
modelo adaptado de outra indstria, a de manufatura, mais
especificamente da Toyota. David Anderson [1] foi o grande
responsvel por essa adaptao.
A histria comea em 2002, quando Anderson, cansado de ver
equipes de desenvolvimento e departamentos inteiros de TI
merc de outros departamentos, decide voltar seus esforos
para responder a duas perguntas [1]:
1. Como proteger a minha equipe da demanda incessante de
negcio e alcanar o que a comunidade gil chama de ritmo
sustentvel?
2. Como adotar uma abordagem gil em toda a empresa e
superar inevitveis resistncias mudana?
Como cita em seu ltimo livro, Kanban: Successful Evolutio-
nary Change for Your Technology Business [1], publicado em
2010, Anderson tinha um grande desejo: encontrar no setor
de TI uma relao ganha-ganha entre o departamento de
negcio e as equipes de desenvolvimento de software e TI.
Na tentativa de atingir esses objetivos, David idealizou,
testou e falhou muitas vezes nas diversas organizaes em
que trabalhou. Ele notou que implantar um processo de de-
senvolvimento de software totalmente prescritivo, na maioria
das vezes, no funcionava. Assim, chegou concluso que
um processo precisava ser adaptado para cada situao, e que
para fazer isso, era necessria uma liderana ativa em cada
equipe. Porm, esta era muitas vezes inexistente. E, mesmo
com uma liderana certa, ele duvidava que mudanas signi-
ficativas acontecessem sem uma metodologia ou, no mnimo,
sem orientaes de como adaptar o processo para atender a
diferentes situaes.
12 Engenharia de Software Magazine - Kanban no desenvolvimento de projetos de software
Para David, sem um conjunto mnimo de orientaes para
guiar o lder, treinador ou engenheiro de processo, qualquer
adaptao no processo estava susceptvel a ser aplicada sub-
jetivamente. Novos times sempre iro resistir a mudanas se
voc empurrar para eles processos que foram feitos para outras
realidades e que tiveram bons resultados l.
A concluso que David chegou que preciso ter uma evo-
luo com o novo time de uma forma incremental, partindo
do processo que atualmente seguido. Isso porque: Cada
time diferente: diferentes conjuntos de habilidades tcnicas,
capacidades e experincia. Cada projeto diferente: oramento,
cronograma, escopo e riscos diferentes. E, cada organizao
diferente: o processo de produo de software diferente em
cada rea de negcio. [1].
Esse o principal motivo pelo qual o Kanban um framework
para melhorias. Isto , ele orienta que o processo de trabalho
deve ser customizado em cada time de cada projeto de cada
organizao. Ou seja, um processo no deve ter suas prticas
seguidas risca da mesma forma em todos os times, de todos
os projetos, de todas as organizaes do mundo, como a grande
maioria das metodologias do mercado prescreve.
Em 2005, o mtodo de trabalho de David Anderson era base-
ado principalmente na Teoria das Restries (TOC Theory of
Constraints) e na FDD (Feature Driven Development).
A Teoria das Restries foi apresentada pela primeira vez em
1984 por Eliyahu M. Goldratt, no famoso livro A Meta. Segun-
do David Anderson [1], a habilidade de identificar gargalos
em um sistema o primeiro passo para entender a Teoria das
Restries. O efeito dos sistemas puxados, ou, processo de
produo puxado so tpicos que tambm ajudam a compre-
ender melhor a teoria. Nele, a sada de produtos acabados, tal
como o software pronto para ser usado, ao final do processo de
desenvolvimento, dita o ritmo da introduo de novos requi-
sitos no sistema. Isso evita acmulos de produtos inacabados
ao longo da linha de montagem, diminuindo a quantidade de
trabalho em progresso. J a FDD uma famosa metodologia
gil que o prprio David ajudou a criar.
Mais tarde, em 2007, aps fazer algumas customizaes na
sua forma de trabalho inspiradas em prticas do Sistema Toyota
de Produo, David apresentou nas conferncias Lean New
Product Development e Agile 2007 os resultados prelimi-
nares do uso de Kanban na Corbis, uma empresa fundada por
Bill Gates, da Microsoft.
Durante certo perodo, David chegou a ter dvidas a respei-
to da eficincia do Sistema Toyota de Produo, mesmo com
muitas pessoas falando o contrrio. Porm, aps conhecer um
pouco mais a respeito do pensamento de Taiichi Ohno, um dos
criadores de tal sistema, e a ideia por trs da cultura Kaizen
(a qual ser falada no prximo tpico), David reconheceu, [1]
atravs de experincias ao longo dos cinco anos posteriores a
eficincia desse sistema que originou o Kanban.
Kanban (com K maisculo) um mtodo de mudana
evolutivo para monitoramento e melhoria de processos de
produo, que utiliza kanban (com k minsculo) para au-
xiliar na visualizao do fluxo e para permitir a criao de

um sistema puxado de trabalho alm de outras ferramentas
para catalisar a introduo de ideias Lean nas reas de de-
senvolvimento de software e operaes de TI. um processo
evolutivo e incremental. Kanban lhe permite atingir processos
otimizados para contextos muito especficos, com resistncia
mnima e mantendo um ritmo sustentvel para os trabalha-
dores envolvidos. [1].
O mtodo Kanban
Como implementar mudanas continuamente no processo
de trabalho da equipe com sucesso? Este um ponto funda-
mental e um dos motivadores centrais das cinco propriedades
do mtodo Kanban:
1. Visualizar o fluxo de trabalho;
2. Limitar a quantidade de trabalho em andamento;
3. Medir e otimizar o fluxo de trabalho;
4. Tornar explcitas as polticas do processo;
5. Gerenciar quantitativamente.
O Kanban no uma metodologia, mas sim um framework
para implementar mudanas de forma incremental. Esse um
conceito muito importante para que se entenda o Kanban como
um todo j que, quando se fala em metodologias, fala-se em
conjuntos de prticas e o Kanban no tem nenhuma prtica
prescrita. H, nele, somente propriedades que devem guiar a
melhoria no processo atual, no importando quais prticas
estejam sendo usadas.
Ao usar o Kanban, como veremos mais detalhes ao decorrer
do artigo, esperado que se consiga visualizar quais prticas
esto sendo positivas e quais esto sendo negativas e isso,
consequentemente, vai conduzir a mudanas, que, natural-
mente adicionaro, eliminaro ou alteraro as prticas atuais
de trabalho.
A forma mais comum de se conseguir visualizar o fluxo de
trabalho atravs de um kanban. Esse uma espcie de qua-
dro, que pode ser fsico, normalmente colocado em uma das
paredes do local onde a equipe trabalha, ou virtual. O uso do
quadro virtual tem alguns prs e contras. Os pontos fortes so
basicamente a facilidade de extrao de mtricas e o histrico.
O principal ponto fraco dessa abordagem a dificuldade que a
equipe ter para analisar e evoluir conjuntamente o processo
de trabalho.
Nesse quadro, inicialmente devem ser modeladas cada uma
das etapas necessrias para se produzir o software, isto , todo
o workflow de trabalho. E, em cada uma dessas etapas deve ser
colocado e mantido um carto, a fim de simbolizar um trabalho
que est em andamento, como podemos ver na Figura 1. Cada
um desses cartes deve conter informaes detalhadas sobre a
atividade, bem como quem est desenvolvendo o item, e quando
o mesmo foi iniciado.
No Kanban para desenvolvimento de software, o kanban
deve ser mantido e evoludo por toda a equipe, o tempo todo.
A proposta baseia-se em fazer a prpria equipe enxergar onde
est errando e deix-la tomar decises seguindo um framework
simples, que guiar grande parte dessas melhorias.
AG IL I DAD E
Figura 1. Kanban systems for software development [10]
Para Alisson Vale [5], em atividades que envolvem trabalho
criativo, como desenvolvimento de software, o propsito
do Kanban provocar conversaes sobre o sistema de
trabalho.
Para limitar a quantidade de trabalho em andamento
necessrio definir, monitorar e manter um limite mximo de
tarefas em andamento para cada uma das etapas de trabalho
mapeadas no quadro kanban, como visto na Figura 1.
Ao estabelecer os limites, a equipe comea a identificar
onde esto os principais gargalos do processo de produo
e comea a ter que terminar todo o trabalho inacabado na
linha de produo para conseguir puxar mais trabalho para
o gargalo. Com isso, o trabalho tende a ser finalizado de uma
forma incremental e no de uma forma cascata, tornando-se
assim um sistema puxado (TOC), onde a equipe que dita a
sua capacidade de produo.
O uso do sistema puxado, juntamente com a visualizao de
todo o processo de desenvolvimento por toda a equipe, permite
implementar mudanas no processo de modo incremental.
Consequentemente, h reduo significativa da resistncia, o
que facilita o alcance do ritmo sustentvel, teoria to comenta-
da em desenvolvimento gil, mas para a qual poucas definies
existem alm das 40 horas semanais de trabalho.
Uma citao de David [1] sintetiza isso: Um interessante
efeito colateral de sistemas puxados que eles limitam o
trabalho em andamento (WIP Work In Progress) para certa
quantidade acordada, evitando assim que trabalhadores fi-
quem sobrecarregados..
Outro fator importante o ganho que se tem ao praticamente
impedir que uma mesma pessoa execute vrias tarefas no mes-
mo projeto em paralelo. Vale destacar tambm o processo Just in
time (JIT), que evita o acmulo de estoque ao longo do processo
de desenvolvimento, como se faz no ciclo de vida em cascata.
Nesse caso, software em estoque so todos os requisitos que
ainda no foram liberados para o cliente usar.
No desenvolvimento de um software, como em qualquer
outra atividade intelectual, por mais contra intuitivo que possa
parecer, executa-se com mais qualidade e mais rapidamente
duas tarefas fazendo-as uma de cada vez, do que as duas em
paralelo o tempo todo.
Edio 45 - Engenharia de Software Magazine 13
 Segundo Rodrigo Yoshima [7], um dos grandes pontos fortes
desse mtodo o modelo embutido nele para trabalhar com a
melhoria de processos, o modelo Kaizen. Alm do modelo Kai-
zen, existe o modelo Kaikaku. Vamos s diferenas: Kaikaku
uma palavra que define mudanas de processos classificadas
como melhoria radical. [7].
Implantar o Scrum, por exemplo, exige esse cenrio [7], pois
o Scrum requer profundas mudanas organizacionais como
a gesto abdicar de muitos instrumentos de controle, quebrar
com a separao entre os grupos e mudar posies hierrquicas
estabelecidas.
Kaizen a palavra Lean para indicar mudanas de melhoria
menores e contnuas. Ao contrrio do Kaikaku, Kaizen no
to traumtico, melhor aceito por todos (gerentes inclusive) e
mais simples de implementar. Tudo a nossa volta est suscetvel
a um evento Kaizen. Kaizen simplesmente significa mudana
para melhor. [7].
Na abordagem Kanban, aplicando a cultura Kaizen, antes
de mudar qualquer coisa devemos entender o ambiente de
trabalho. Se filas, bloqueios, gargalos ou problemas entre
reas esto nos prejudicando, primeiro, vamos visualizar
isso, convencer o grupo dos problemas e usar Kaizen para a
melhoria do ambiente com pequenas mudanas incrementais
e constantes. Isso ir fortalecer a cultura da empresa, pois ela
compreender suas falhas com provas palpveis que sero a
motivao para as mudanas [7].
Segundo Jos Papo [8], alm disso, a filosofia e prticas Lean,
como o caso do Kanban, focam na auto-organizao do time, na
responsabilidade conjunta pelos objetivos de negcio do projeto e
na produtividade com qualidade e com ritmo sustentvel. Todas
elas so prticas de administrao consagradas e evidenciadas por
Peter Drucker para liderar trabalhadores do conhecimento.
As duas ltimas propriedades do Kanban citadas (tornar ex-
plcitas as polticas do processo e gerenciar quantitativamente)
so praticamente atendidas deixando claro para toda a equipe
as trs primeiras propriedades e reforando que toda sugesto
de otimizao no processo deve ter como base modelos mate-
mticos que provem as mtricas.
Kanban uma metodologia gil?
Nos ltimos tempos, acompanhamos uma briga forte entre
Kanban e as demais metodologias geis, principalmente o
Scrum. A polmica central : quem usa Kanban gil?
Rodrigo Yoshima [9] explica que o maior objetivo do Kanban
melhorar um processo existente, por pior que ele seja. Ainda
segundo Yoshima, o Kanban permite melhorar at mesmo
processos que seguem o ciclo de vida em cascata, fazendo eles
se tornarem geis e podendo melhorar continuamente, e at
mesmo superarem o Agile. Isso tudo graas cultura Kaizen
que o Kanban quer trazer tona.
Outro ponto a ser destacado que para o Kanban, diferente
da grande maioria das metodologias geis, no importa quais
prticas voc ir aplicar para melhorar o seu processo, o im-
portante que voc tenha argumentos, preferencialmente
estatsticos, que expliquem o porqu dessas decises.
14 Engenharia de Software Magazine - Kanban no desenvolvimento de projetos de software
Como David ressalta em seu livro [1], a abordagem evolutiva do
Kanban, que promove a implementao de mudanas no proces-
so de forma incremental, tem sido controversa na comunidade
gil de desenvolvimento de software. Isso ocorre principalmente
porque se sugere que as equipes no adotem um mtodo ou
modelo de processo. Vale ressaltar que a atual indstria de
servios e ferramentas desenvolveu-se em torno de um pequeno
conjunto de prticas definidas em dois populares mtodos de
desenvolvimento gil: XP e Scrum. Depois, com o Kanban, os
indivduos e as equipes esto habilitados para desenvolver suas
prprias solues por meio de um processo nico que evitaria
a necessidade de tais servios e ferramentas. Isso porque os
mesmos requerem um novo conjunto de ferramentas e servios
muito especficos para cada realidade. Dessa forma, torna-se
mais complicado para essa indstria ganhar dinheiro.
Tanta discusso acerca do assunto fez o pessoal do Kanban
criar um logo de manifesto chamado: Yes We Kanban, que
David [1] explica: O slogan Yes We Kanban se destina a
enfatizar que voc tem permisso. Voc tem permisso para
tentar Kanban. Voc tem permisso para modificar o seu pro-
cesso. Voc tem permisso para ser diferente. Sua situao
nica e merece o desenvolvimento de um processo adapta-
do e otimizado para o seu domnio, o seu fluxo de valor, os
riscos que voc gerencia, as habilidades de sua equipe e as
demandas de seus clientes..
Portanto, podemos dizer que o objetivo de Kanban no
tornar a sua equipe gil, e sim, melhorar a forma de trabalho.
Ele tanto pode melhorar processos geis como tambm pode
melhorar processos tradicionais.
Qual a receita para ter sucesso com Kanban?
Para que qualquer pessoa que queira ser um agente de
mudana na sua organizao tenha sucesso rpido (ou, uma
melhoria rpida) e com baixa resistncia da equipe, com foco
na melhoria de processos em alguns pontos com o uso ou at
mesmo sem o uso do mtodo Kanban, preciso seguir algumas
etapas. De acordo com David, so elas:
1. Focar na qualidade;
2. Limitar a quantidade de trabalho em progresso;
3. Entregar frequentemente;
4. Balancear demanda com a capacidade mxima;
5. Priorizar tarefas;
6. Atacar fontes de variedade.
O autor orienta que essas etapas sejam seguidas na ordem em
que so apresentadas. A partir de agora, passa-se a discorrer
um pouco a respeito de cada uma delas.
Focando na qualidade
Como os agentes de mudanas nas empresas de TI so ge-
ralmente pessoas com um background tcnico, essa tende a
ser uma das etapas mais fceis de ser implementada, princi-
palmente por ser um problema bem entendido por todos. As
outras etapas desse guia [1] tendem a ter uma implementao
mais difcil porque dependem da colaborao de outras reas

e equipes. Com isso, exigem que o agente de mudana tenha
muitas habilidades de negociao, articulao e bastante in-
teligncia emocional [1].
Os maiores geradores de retrabalho em desenvolvimento de
software so os defeitos causados principalmente pela baixa
qualidade das entregas. E, alm de um gerador de retrabalho,
baixa qualidade faz os clientes ficarem inseguros e a equipe
desmotivada.
O incentivo qualidade das entregas tem um grande
impacto na produtividade das equipes com altas taxas de
defeitos. Segundo David [1], em equipes verdadeiramente
ruins, somente concentrando-se na qualidade pode-se obter
uma melhoria de produtividade de at dez vezes.
Para David [1], tanto as tcnicas de desenvolvimento gil
como as abordagens tradicionais tm seu mrito para a
melhoria da qualidade. As principais prticas incentivadas
por ele para a melhoria da qualidade so:
1. Escrever testes automatizados, preferencialmente antes;
2. Revisar cdigo (Verificao);
3. Fazer atividades de anlise e design do software de forma
colaborativa;
4. Usar Design Patterns;
5. Usar ferramentas modernas de desenvolvimento.
Parece haver uma vantagem psicolgica em pedir para os
desenvolvedores escreverem testes antes, porm, importante
ressaltar que tambm existem inmeros casos de sucesso com a
escrita dos testes aps a codificao.
Inspees ou revises de cdigo ajudam a melhorar tanto a
qualidade externa como, notadamente, a qualidade interna do
software. Todas as tcnicas tm o seu valor. Programao em
par e reviso por pares so alguns exemplos. No entanto [1], ins-
pees de cdigo so melhores quando so feitas em pequenas
quantidades vrias vezes. David menciona [1] que ele costuma
encorajar as suas equipes a inspecionar cdigo, todos os dias, por
pelo menos 30 minutos.
Sem dvidas, quando toda a equipe trabalha em conjunto na
anlise dos problemas para as solues de design, a qualidade
superior do que quando apenas uma pessoa faz isso. Assim como
as inspees de cdigo, atividades de modelagem de software
devem ser feitas em pequenas quantidades, todos os dias.
Os padres de projeto de software, mais conhecidos pelo termo
original em ingls Design Patterns, descrevem solues para
problemas j conhecidos e recorrentes no desenvolvimento de
software orientado a objetos. O uso de padres de projeto garante
que defeitos de design sejam eliminados j no incio do projeto.
O uso de ferramentas modernas de desenvolvimento melhora
a qualidade porque a grande maioria dessas inclui funes de
anlise de cdigo esttica e dinmica, que evitam que os desenvol-
vedores introduzam problemas bsicos e j bem compreendidos,
como falhas de segurana, no software.
Limitando a quantidade de trabalho em andamento
fcil especular porque limitar a quantidade de tarefas em
andamento aumenta a qualidade. A complexidade do trabalho
AG IL I DAD E
do conhecimento, como em desenvolvimento de software,
cresce exponencialmente com a quantidade de trabalhos em
andamento. Tanto a transferncia como a descoberta de infor-
maes no desenvolvimento de software conhecimento tcito
por natureza e criado durante sesses de trabalho colabora-
tivo, face a face. A informao verbal e visual, mas em um
formato casual, como um esboo em um quadro branco.
Nossas mentes tm uma capacidade limitada para armazenar
conhecimento tcito. E, quanto mais tempo passa, h mais
falhas para recordar detalhes precisos. Assim, uma srie de
erros cometida. Equipes que trabalham de um modo gil,
em um mesmo espao de trabalho, tm uma maior facilidade
em reter o conhecimento tcito.
Mas, independentemente da forma de trabalho da equipe, o
conhecimento tcito se deprecia com o passar do tempo. Por
isso, tempos de espera (lead time) menores so essenciais para
os processos que envolvem muito conhecimento tcito. O foco
da reduo de trabalho em andamento est diretamente rela-
cionado com a reduo dos tempos de espera (lead time).
Assim, podemos deduzir que haver menor depreciao
de conhecimento tcito quando temos menos trabalho em
progresso o que resultar em maior qualidade. Em resumo,
reduzindo a quantidade de trabalho em andamento, melhora-
se a qualidade e possibilita-se entregas mais frequentes. Isso
aumenta a confiana externa na equipe.
Alm de reduzir a quantidade de trabalho em andamento,
importante reduzir o tempo de uma iterao, pois isso tambm
trar um impacto positivo significativo na qualidade. Segundo
David [1], parece que existe uma relao entre a quantidade
de trabalho em andamento e a qualidade, ou seja, defeitos vo
aumentar com o aumento da quantidade de WIP. Portanto, faz
sentido que iteraes de duas semanas sejam melhores do que
iteraes de quatro semanas e que iteraes de uma semana
sejam melhores ainda. Iteraes mais curtas iro resultar em
entregas de maior qualidade.
Seguindo a lgica das evidncias apresentadas, se sabido
que limitar o WIP ir melhorar a qualidade, por que no intro-
duzir poltica explcita para isso, deixando assim os gerentes
livres para se concentrarem em outras atividades? Essa jus-
tamente uma das propriedades do Kanban. Entretanto David
afirma [1] que ainda no existe nenhuma evidncia cientfica
desse resultado que foi observado apenas empiricamente.
Entregando frequentemente
Para entendermos a importncia dessa etapa, David apresenta
uma excelente analogia em seu livro [1]: Quando eu ensino
isso nas aulas, eu gosto de perguntar s mulheres da classe o
que elas pensam sobre duas situaes depois de ter um pri-
meiro encontro com um cara:
Situao 1: Eles tiveram um bom encontro, mas depois
disso ele no d sinais de vida a ela durante duas semanas.
Mas, ento, ele aparece em sua porta com um ramo de flo-
res e um pedido de desculpas;
Situao 2: Eles tiveram um bom encontro e na mesma noite
a caminho de casa ele envia uma mensagem de texto a ela
Edio 45 - Engenharia de Software Magazine 15
dizendo: Eu me diverti muito esta noite. Eu realmente quero
me encontrar com voc novamente. Posso ligar para voc
amanh? E, esse mesmo cara, segue ligando e enviando
mensagens dia aps dia.
Qual cara vocs acham que elas preferem?.
Pequenos e frequentes gestos no custam quase nada, entre-
tanto, eles constroem mais confiana do que grandes e caros
gestos ocasionalmente. Portanto, realizar frequentemente
pequenas entregas de alta qualidade constri mais confiana
para as equipes parceiras do que entregas maiores, mas com
menos frequncia.
Balanceando a demanda com a capacidade mxima
Construir um consenso em torno da necessidade de equilibrar
a demanda contra a capacidade da equipe crucial. No entanto,
para isso, preciso resolver problemas como a disfuno entre
os papis e as responsabilidades dos membros da equipe.
Essa etapa implica definir a taxa em que a equipe aceita novos
requisitos no processo de desenvolvimento de software para
corresponder com a capacidade em que a equipe pode entregar
cdigo de qualidade.
Quando se faz isso, fixa-se efetivamente a quantidade de
trabalho em andamento, permitindo efetivamente que seja a
equipe que crie a demanda de acordo com a sua capacidade
(sistema puxado).
Priorizando tarefas
Priorizar trabalho da rea de negcios, e no da rea de
TI da organizao. Assim, no deveria ser da competncia
de um gerente tcnico fazer isso. Entretanto, infelizmente,
comum a rea de negcios delegar a responsabilidade e deixar
um gerente tcnico priorizar o trabalho e depois culpar que o
gerente fez escolhas erradas.
Neste ponto, a ateno da gerncia deve-se voltar para otimi-
zar o valor entregue ao invs de meramente a quantidade de
cdigo entregue.
Atacando fontes de variedade
Podemos entender como fontes de variedade tudo aquilo
que de alguma forma prejudica o desempenho do processo
de produo.
Atacar as fontes de variedade a ltima etapa da receita
porque alguns tipos de variedade exigem profundas mudanas
de comportamento e, consequentemente, uma alta resistncia
da equipe.
A dica para implementar essa etapa focar nas fontes de va-
riedade que requerem pequenas mudanas de comportamento
e que podem ser aceitas facilmente pela equipe.
Segundo David [1], no se deve focar nessa etapa sem antes
implementar e dominar as primeiras cinco etapas da receita.
Resumindo, essa receita a forma que David [1] acredita que
uma equipe de desenvolvimento de software deve amadure-
cer: Em primeiro lugar, aprender a construir cdigo de alta
qualidade. Em seguida, reduzir o trabalho em andamento,
16 Engenharia de Software Magazine - Kanban no desenvolvimento de projetos de software
encurtar os lead times, e entregar (software funcionando)
com frequncia. Em seguida, equilibrar a demanda contra
a capacidade mxima, limitar a quantidade de trabalho
em andamento, e criar folga para liberar capacidade, o que
permitir a melhoria contnua. Ento, com isso funcionando
razoavelmente e continuamente otimizando a capacidade de
desenvolvimento de software, melhore a priorizao para
otimizar a entrega de valor..
O Kanban permite que voc implemente todas as seis etapas
dessa receita.
Concluso
interessante conhecer as motivaes que levaram David
Anderson a chegar at o mtodo Kanban para o Desenvol-
vimento de Software e, atravs da sua receita, entender o
porque da maioria das propriedades por trs do Kanban.
Essa metodologia tem sido um assunto recorrente e tende a
continuar sendo, j que uma forma eficiente de melhorar
continuamente a rea.
Se a sua empresa est com dificuldades para melhorar, no
importa se ela adota mtodos geis ou no, o Kanban pode
ser uma das alternativas para fazer isso com o mnimo de
resistncia, pois, alm de toda a simplicidade do mtodo, suas
propriedades promovem a colaborao.
Referncias
1. Anderson, D. (2010) Kanban: Successful Evolutionary Change for Your Technology Business.
Washington, Blue Hole Press.
2. Martin, R. (2011) The Clean Coder: A Code of Conduct for Professional Programmers. Indiana,
Prentice Hall.
3. Anderson, D. (2003) Agile Management for Software Engineering: Applying the Theory of
Constraints for Business Results. New Jersey, Prentice Hall.
4. Bernab, J. (2011) Mais comprometimento = menos produtividade? http://www.teamware.
com.br/blog/mais-comprometimento-menos-produtividade/
5. Vale, A. (2011) Kanban Explicado. http://www.slideshare.net/alissonvale/kanban-explicado
6. Wikipdia. TOC. http://pt.wikipedia.org/wiki/Teoria_das_restri%C3%A7%C3%B5es
7. Yoshima, R. (2011) Kaikaku Kaizen, http://blog.aspercom.com.br/2011/09/09/kaikaku-
kaizen/
8. Papo, J. (2010) Porque Lean/Agile funcionam? http://josepaulopapo.blogspot.com/2010/03/
agile-lean-funciona-por-que.html
9. ABES (2011). O Mercado Brasileiro de Software em 2011. http://www.abes.org.br/UserFiles/
Image/PDFs/Mercado_BR2011.pdf
10. Corey Ladas (2007). Kanban systems for software development (Imagem) http://
leansoftwareengineering.com/wp-content/uploads/2007/08/kanban1.png
D seu feedback sobre esta edio! Feedback
eu
s
D
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
sobre e
Para isso, precisamos saber o que voc, leitor, acha da revista!
s
ta
D seu voto sobre este artigo, atravs do link:
edio
www.devmedia.com.br/esmag/feedback