KanbanEScrumInfoQBrasil PDF

EDIO ONLINE
GRATUITA
Feito para voc
Cortesia da
Este livro distribudo gratuitamente no

portal InfoQ.com. Se voc recebeu este
livro de qualquer outra fonte, por favor,
suporte o autor e o editor cadastrando-se
na InfoQ.com.
Visite a pgina deste livro em:
http://www.infoq.com/br/minibooks/ka
nban-scrum-minibook
Kanban e Scrum obtendo o melhor de

ambos
Henrik Kniberg & Mattias Skarin

Prefcio por Mary Poppendieck & David
Anderson
2009 C4Media Inc.

Todos os direitos reservados.
C4Media, Editora do InfoQ.com.
Este livro parte da srie de livros do InfoQ Enterprise
Software Development.
Para informaes ou compra deste ou de outros livros
do InfoQ, por favor entre em contato com
books@c4media.com.
Nenhuma parte desta publicao pode ser reproduzida,
armazenada em sistema de recuperao ou publicao
ou ainda transmitida por qualquer meio ou para
quaisquer fins, seja eletrnica, mecnica, fotocpia,
gravao, digitalizao ou por qualquer outro processo
exceto aqueles listados como permitidos nas Sees
107 ou 108 do United States Copyright Act de 1976,
sem qualquer prvia autorizao por escrito do Editor.
Denominaes utilizadas pelas empresas para
distinguir seus produtos so sempre referenciadas
como marcas registradas. Em todas as instncias em
que a C4Media Inc. tiver cincia com relao a isto, os
nomes dos produtos aparecero com Inicial Maiscula
ou ento com TODAS AS LETRAS EM MAISCULO.
Os leitores, no entanto, devem contatar as empresas
apropriadas para obter informao mais completa a
respeito de registro e de marcas registradas.
Editora chefe: Diana Plesa
Arte de capa: Bistrian Iosip
Composio: Accurance
Dados Catalogrficos da Publicao na Biblioteca do
Congresso:
ISBN: 978-0-557-13832-6
Impresso nos Estados Unidos da Amrica
Contedo
Prefcio por Mary Poppendieck ................................................................. 8
Prefcio por David Anderson ................................................................... 10
Introduo ............................................................................................... 17
Propsito desse livro ............................................................................... 20
Parte I Comparao .............................................................................. 21
O que so mesmo Scrum e Kanban? ........................................................ 22
Scrum em poucas palavras ...................................................................... 22
Kanban em poucas palavras .................................................................... 25
Ento como Scrum e Kanban se relacionam? ........................................... 27
Scrum e Kanban so ambos ferramentas de processo ............................. 27
Compare ferramentas para compreenso, No julgamento .................... 27
Nenhuma ferramenta completa, nenhuma ferramenta perfeita ........ 28
O Scrum mais prescritivo que o Kanban ................................................ 29
No se prenda a uma nica ferramenta!.................................................. 31
Scrum prescreve papis ........................................................................... 33
Scrum prescreve iteraes em time-box .................................................. 34
Kanban limita WIP por estado de fluxo de trabalho, Scrum por iterao . 37
Ambos so empricos ............................................................................... 41
Scrum resiste a mudanas dentro de uma iterao.................................. 50
Quadro Scrum limpo entre cada iterao .............................................. 53
Scrum prescreve equipes multifuncionais ................................................ 55
Itens do Scrum backlog devem caber num sprint .................................... 57
Scrum prescreve estimativas e velocidade ............................................... 59
Ambos permitem trabalhar em mltiplos produtos simultaneamente .... 61
Ambos so Lean e geis ........................................................................... 64
Diferenas menores ................................................................................. 66
Scrum prescreve um product backlog priorizado .................................... 66
Em Scrum, so prescritas reunies dirias ............................................... 67
No Scrum, so prescritos grficos de burndown ...................................... 68

Quadro Scrum vs. quadro Kanban um exemplo menos trivial ............... 71
Resumo de Scrum vs. Kanban .................................................................. 80
Similaridades ........................................................................................... 80
Parte II Estudo de caso .......................................................................... 83
A natureza das operaes tcnicas .......................................................... 84
Por que diabos mudar?............................................................................ 85
Por onde comeamos?............................................................................. 88
Opinio dos Desenvolvedores sobre Operaes ...................................... 88
Opinio de Operaes sobre Desenvolvimento ....................................... 89
Comeando.............................................................................................. 90
Iniciando os times .................................................................................... 91
O workshop ............................................................................................. 91
Lidando com partes interessadas ............................................................. 93
Construindo o primeiro quadro ............................................................... 95
O primeiro modelo Kanban ..................................................................... 97
Definindo o primeiro limite de WIP ......................................................... 99
Honrando o limite de WIP ..................................................................... 101
Discusso no quadro.............................................................................. 101
Designando uma seo de transbordo ................................................... 101
Quais tarefas vo para o quadro? .......................................................... 103
Como estimar? ...................................................................................... 104
O que o tamanho estimado significa? Lead time ou tempo de trabalho?105
Ento, como que trabalhamos, realmente? ........................................ 106
Reunio diria em p ............................................................................. 107
Planejamento da iterao ...................................................................... 107
Encontrando um conceito de planejamento que funcione..................... 110
Uma Histria.......................................................................................... 110
Reinventando o planejamento .............................................................. 111
O que medir? ......................................................................................... 114

Como as coisas comearam a mudar ..................................................... 117
Lies gerais aprendidas ........................................................................ 124
medida que o trabalho em andamento progride, limitaes surgem . 124
O quadro vai mudar ao longo do tempo, no fixe o layout em ferro ..... 126
No tenha medo de experimentar e falhar ............................................ 128
Consideraes finais .............................................................................. 129
Comece com as retrospectivas! ............................................................. 129
Nunca pare de experimentar! ................................................................ 130
Sobre os autores .................................................................................... 132
Glossrio................................................................................................ 134
Sobre a traduo ................................................................................... 137
Coordenao ......................................................................................... 137
Reviso .................................................................................................. 137
Ilustraes ............................................................................................. 138
Traduo ............................................................................................... 138
Apoio ..................................................................................................... 139
Kanban e Scrum - obtendo o melhor

de ambos | 8
Prefcio por Mary Poppendieck

Henrik Kniberg uma das raras pessoas que conseguem
extrair a essncia de uma situao complicada, separar as
idias principais das distraes acidentais, e fornecer uma
explicao cristalina que incrivelmente fcil de entender.
Nesse livro, Henrik faz um trabalho brilhante ao explicar a
diferena entre Scrum e Kanban. Ele torna claro que ambos
so apenas ferramentas, e o que voc realmente precisa ter
um kit completo delas, entender os pontos fortes e fracos de
cada uma e como us-las.
Neste livro voc vai aprender o que exatamente o Kanban,
suas qualidades e limitaes, e como us-lo. Voc tambm
vai aprender coisas bem interessantes sobre como e quando
melhorar o Scrum, ou qualquer outra ferramenta que voc
estiver usando. Henrik deixa claro que o importante no a
ferramenta que voc escolhe usar inicialmente, mas o modo
como voc constantemente aperfeioa a utilizao dela e
amplia seu kit de ferramentas no decorrer do tempo.

de ambos | 9
Na segunda parte do livro, Mattias Skarin torna-o ainda mais

prtico mostrando uma utilizao de Scrum e Kanban numa
situao real. Voc ver um exemplo de como as ferramentas
foram usadas separadamente e combinadas para melhorar o
processo de desenvolvimento de um software. Voc vai notar
que no existe uma nica melhor forma de fazer as coisas;
voc tem que refletir e imaginar baseado na situao seu
prximo passo para uma forma melhor de desenvolver
software.
Mary Poppendieck

de ambos | 10
Prefcio por David Anderson

O Kanban baseado numa idia muito simples. As
Atividades em andamento devem ser limitadas. Algo novo s
deve ser iniciado quando uma pea de trabalho existente
liberada ou quando uma funo automtica inicia isso.
O Kanban, ou carto de sinalizao, um sinal visual
produzido indicando que novo trabalho pode ser iniciado e
que a atividade atual no coincide com o limite acordado. Isso
no soa muito revolucionrio 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.
O que percebemos sobre o Kanban que ele uma
abordagem para mudana gerencial. Ele no um processo ou
ciclo de vida de gerenciamento de projetos ou de
desenvolvimento de software. O Kanban uma abordagem
para introduzir mudanas em um ciclo de desenvolvimento de
software ou metodologia de gerenciamento de projetos. O
princpio do Kanban que voc inicia com o que estiver
fazendo agora. Voc entende seu processo atual ao mapear o
fluxo de valor e ao concordar, em seguida, em limitar as
Atividades em andamento (do ingls WIP) para cada estgio
desse processo. A partir da voc comea a rastrear as
atividades pelo sistema para inici-las quando os sinais do
Kanban aparecerem.
O Kanban tem sido til para equipes geis de
desenvolvimento de software, mas tem ganhado popularidade,
igualmente, em equipes que utilizam uma abordagem mais

de ambos | 11
tradicional. Ele est sendo introduzido como parte de uma

iniciativa Lean (enxuta) para moldar a cultura das
organizaes e encorajar a melhoria contnua.
Porque o WIP limitado em um sistema Kanban, tudo que
fica bloqueado por qualquer motivo tende a parar o sistema.
Se certa quantidade de itens de trabalho fica bloqueada, todo
o processo pra de funcionar. Isso cria a necessidade de
concentrar toda a equipe e toda a empresa na soluo do
problema para desbloquear o item e restaurar o fluxo.
O Kanban usa um mecanismo de controle visual para
acompanhar o trabalho medida que ele flui atravs das
vrias etapas do fluxo de valor.
Tipicamente usa-se um quadro branco com post-its, ou um
sistema de cartes eletrnicos. Fazer os dois ,
provavelmente, uma boa prtica. A transparncia que isso
gera tambm contribui para a mudana cultural. Mtodos
geis tm sido bons provendo transparncia sobre as
atividades em andamento e concludas, e reportando mtricas
como velocidade (a quantidade de trabalho finalizado em uma
iterao).
O Kanban, no entanto, vai um passo alm e d transparncia
ao processo e seu fluxo. O Kanban expe gargalos, filas,
variabilidade e desperdcio. Tudo que impacta o desempenho
da organizao em termos de quantidade de trabalho de valor
entregue e o tempo de ciclo necessrio para entreg-lo.
Proporciona aos membros da equipe e s partes interessadas
externas a visibilidade sobre os efeitos de suas aes (ou falta
de aes). Sendo assim, os primeiros estudos de caso esto
mostrando que o Kanban muda o comportamento e incentiva
uma maior colaborao no trabalho.

de ambos | 12
A visibilidade dos gargalos, desperdcio e variabilidade, e

seus impactos, tambm incentivam a discusso sobre
melhorias e as equipes rapidamente iniciam as melhorias nos
seus processos.
Como resultado, o Kanban encoraja a evoluo incremental
de processos existentes, evoluo que geralmente alinhada a
valores geis e Lean. O Kanban no demanda uma
revoluo drstica no modo como as pessoas trabalham,
encoraja, ao invs disso, uma mudana gradual. mudana
entendida e aceita por consenso entre trabalhadores e seus
colaboradores.
O Kanban, atravs da natureza do sistema pull1, encoraja
tambm comprometimento tardio, tanto em priorizao de
trabalho novo quanto na entrega de trabalho existente.
Tipicamente, os times vo concordar em uma cadncia de
priorizao para atender partes interessadas que estejam
contra a mar e decidir a prxima coisa em que trabalhar.
Estas reunies podem ser feitas regularmente porque so
normalmente muito curtas.
Uma questo muito simples deve ser respondida, algo como,
Desde nossa ltima reunio, 2 vagas ficaram livres. Nosso
tempo de ciclo corrente de 6 semanas para entrega. Quais 2
coisas vocs mais gostariam de ter entregues daqui a 6
semanas? Isso tem dois desdobramentos. Perguntar uma
simples questo geralmente resulta em uma resposta de boa
Pull system, ou sistema puxado: sistema em que os times que

puxam o trabalho, na medida de sua capacidade, e no o oposto,
quando o trabalho empurrado equipe sistema de trabalho mais
comum. Nota do Tradutor

de ambos | 13
qualidade, rapidamente desdobrada, e mantm a reunio

breve.
A natureza da questo significa que o comprometimento em
que se trabalhar atrasado at o ltimo momento
responsvel. Isto aumenta a agilidade gerenciando
expectativas,
diminuindo
tempos
de
ciclo
do
comprometimento entrega e eliminando retrabalho, pois a
chance de que prioridades mudem minimizada.
Uma ltima coisa sobre Kanban que o efeito de limitar o
WIP fornece previsibilidade de tempo em ciclos e faz as
entregas mais confiveis. A abordagem de "parar a linha de
produo" para superar os obstculos e os erros encontrados,
tambm parece encorajar nveis mais elevados de qualidade e
uma queda rpida de retrabalho.

de ambos | 14
Enquanto tudo isso se tornar evidente com explicaes

maravilhosamente claras neste livro, como ns chegamos at
aqui permanecer sombrio. Kanban no foi concebido em
uma nica tarde atravs de alguma apario divina incrvel.
Em vez disso, ele emergiu de vrios anos de experincia.
Muitos dos profundos efeitos psicolgicos e sociolgicos que
mudam a cultura, capacidade e maturidade ou organizaes
nunca foram imaginados. Ao contrrio, eles foram
descobertos. Muitos dos resultados com Kanban so contra
intuitivos. O que parece ser uma abordagem muito mecnica
o limite de WIP e o trabalho puxado na verdade, tem
efeitos profundos sobre as pessoas e como elas interagem e
colaboram umas com as outras.
Eu e nem qualquer outra pessoa envolvida com Kanban nos
primeiros dias antecipou isto.
Eu segui o que feito com o Kanban, como uma abordagem
de mudana, que tivesse xito com mnima resistncia.
Isto ficou claro para mim j em 2003. Eu tambm adotei isso
pelos benefcios mecnicos. Como eu estava descobrindo
atravs da aplicao de tcnicas de Lean durante esse tempo,
que se a gesto com atividades em andamento fazia sentido,
ento limitando isso fazia mais sentido. Levei a sobrecarga do
gerenciamento, fora de sua gesto.
Ento em 2004, eu decidi tentar implementar um sistema de
demanda (pull system) a partir dos primeiros princpios. Eu
tive uma oportunidade quando um gerente da Microsoft me
abordou e me pediu para ajud-lo a gerenciar mudanas em
sua equipe, fazendo manuteno de melhorias em uma
aplicao interna de TI.

de ambos | 15
A primeira implementao foi baseada na soluo do sistema

de demanda da Teoria das Restries (TOC), conhecido como
Tambor-Pulmo-Corda (Drum-Buffer-Rope em ingls). Foi
um enorme sucesso: o tempo do ciclo reduziu em 92%; o
rendimento aumentou mais de 3 vezes; e a previsibilidade
(data limite de desempenho) foi muito aceitvel em 98%.
Em 2005, Donald Reinertsen me convenceu a implementar
um sistema Kanban completo. Eu tive a oportunidade em
2006, quando eu assumi o comando do departamento de
engenharia de software em Corbis, Seattle.
Em 2007, eu comecei a apresentar os resultados. A primeira
apresentao foi em maio de 2007 no Lean New Product
Development Summit, em Chicago. Eu continuei com um
espao aberto no Agile 2007 em Washington DC, em agosto
daquele ano. 25 pessoas compareceram. 3 deles eram do
Yahoo! Aaron Sanders, Karl Scotland e Joe Arnold. Eles
foram para casa para Califrnia, ndia e o Reino Unido e
implementou o Kanban com seus times ainda lutando com o
Scrum. Eles tambm iniciaram um grupo de discusso no
Yahoo! que na poca em que este livro foi escrito tinha quase
800 membros.
O Kanban estava comeando a se espalhar e os primeiros a
adotarem estavam falando sobre suas experincias.
Agora em 2009, a adoo do Kanban realmente est
aumentando e cada vez mais relatrios de campo esto
chegando. Ns aprendemos muito sobre o Kanban nos
ltimos 5 anos e todos ns continuamos a aprender a cada dia.
Eu foquei meu prprio trabalho em usar Kanban, escrever
sobre Kanban, falar sobre Kanban e pensar sobre Kanban para
poder entend-lo melhor e explic-lo para os outros. Eu
deliberadamente deixei de comparar o Kanban com mtodos
Agile existentes, embora algum esforo tenha sido gasto em

de ambos | 16
2008 explicando porque o Kanban merecia ser considerado

uma abordagem compatvel com Agile.
Eu deixei para que outros com maior experincia
respondessem questes como Como o Kanban comparado
ao Scrum? Eu agradeo muito por Henrik Kniberg e Mattias
Skarin terem emergido como lderes nesta rea. Voc, o
trabalhador do conhecimento no campo, precisa de
informao para tomar decises e avanar com seu trabalho.
Henrik e Mattias esto atendendo s suas necessidades de
uma forma que eu nunca pude.
Eu estou particularmente impressionado com a profunda
abordagem para comparao de Henrik e seu trabalho
concreto, imparcial e balanceado. Seus desenhos e ilustraes
so particularmente informativos e freqentemente lhe salvam
de ter que ler muitas pginas de texto.
O estudo de caso de campo de Mattias importante porque
demonstra que o Kanban muito mais que teoria e mostra a
voc com exemplos como ele pode lhe ser til em sua
empresa.
Eu espero que voc goste do livro comparando Kanban com
Scrum e que ele lhe d um conhecimento maior sobre Agile
em geral e tanto Kanban quando Scrum em particular. Caso
voc queira aprender mais sobre Kanban, por favor visite o
web site de nossa comunidade, The Limited WIP Society,
http://www.limitedwipsociety.org/
David J. Anderson
Sequim, Washington, USA
8 de Julho de 2009.
Introduo | 17
Introduo
Normalmente ns no escrevemos livros. Ns preferimos
gastar nosso tempo nas trincheiras ajudando clientes a
otimizarem, testarem e refatorarem seu processo de
desenvolvimento e organizao. Entretanto, ns notamos uma
clara tendncia nos ltimos tempos e gostaramos de
compartilhar alguns pensamentos sobre isso. Este um caso
tpico:
Jim: Agora
finalmente
totalmente o Scrum!
Fred:
Jim: Bom, muito melhor do que o tnhamos

antes...
Fred:
Jim: ... mas voc sabe que somos uma equipe de

suporte e manuteno.
Fred:
Jim: Bem, ns amamos toda essa coisa de

ordenar itens por prioridade no product backlog,
equipes
auto-organizveis,
daily
scrums,
retrospectivas, etc...
Fred:
Jim: Ns continuamos falhando em nossos

sprints.
Fred:
estamos
usando
E como est sendo?
...mas?
Sim, e?
Ento qual o problema?
Por qu?
Jim: Porque
ns
achamos
difcil
nos
comprometermos com um plano de duas semanas.
Iteraes no fazem muito sentido para ns, ns

de ambos | 18
apenas trabalhamos no que mais urgente para hoje.
Talvez devssemos fazer iteraes de uma semana?
Fred: Voc poderia se comprometer com uma

semana de trabalho? Voc poder manter o foco e
trabalhar em paz por uma semana?
Jim: Na verdade no, ns temos novos

problemas diariamente. Talvez se fizssemos sprints
de um dia...
Fred: Seus problemas levam menos de um dia

para serem resolvidos?
Jim:
Fred: Ento sprints de um dia tambm no iriam

funcionar. Voc chegou a considerar a possibilidade
de no usar sprint nenhum?
Jim: Bem, francamente, ns gostaramos disso.

Mas isso no seria contra o Scrum?
Fred: O Scrum somente uma ferramenta. Voc

escolhe quando e como utiliz-la. No seja um
escravo dela!
Jim:
Ento o que deveramos fazer?
Fred:
Voc j ouviu falar sobre Kanban?
Jim: O que isso? Qual a diferena entre isso e

o Scrum?
Fred:
Jim: Mas apesar disso, ns realmente gostamos

do resto do Scrum, eu terei que mudar agora?
Fred:
No, voc pode combinar as tcnicas!
Jim:
Que? Como?
No, s vezes eles levam vrios dias.
Aqui, leia este livro!
Introduo | 19
Fred:
Apenas continue lendo...

de ambos | 20
Propsito desse livro

Se voc est interessado no desenvolvimento de software gil
Voc provavelmente j ouviu falar sobre Scrum, e voc
tambm pode ter ouvido falar sobre Kanban. Uma pergunta
que ouvimos com mais e mais freqncia : "Mas o que
Kanban, e como ele se compara ao Scrum?" Onde que eles
se complementam? Existem alguns tipos de conflitos?
O objetivo deste livro clarear o nevoeiro, assim voc pode
descobrir como Kanban e Scrum podem ser teis no seu
ambiente. Deixe-nos saber se conseguiremos!
Introduo | 21
Parte I Comparao
A primeira parte do livro uma tentativa de fazer uma
comparao objetiva e prtica entre Scrum e Kanban. uma
verso levemente atualizada do artigo original, "Kanban VS
Scrum", de abril de 2009. Esse artigo se tornou popular, de
modo que decidi transform-lo em um livro e pedir a meu
colega Mattias para combin-lo com um estudo de caso "das
trincheiras" de um de nossos clientes. Coisa boa! Sinta-se
livre para pular para a parte II se voc preferir comear com
o estudo de caso; eu no vou ficar ofendido. Bem, talvez
apenas um pouco.
/Henrik Kniberg
1
O que so mesmo Scrum e
Kanban?
OK! Vamos tentar resumir Scrum e Kanban em menos de 100
palavras cada.
Scrum em poucas palavras
Divida sua organizao em equipes pequenas,

multifuncionais e auto-organizadas.
O que so mesmo Scrum e Kanban?|

23
Divida o seu trabalho em uma lista de entregveis

pequenos e concretos. Classifique a lista por
prioridade e estime o esforo relativo de cada item.
Divida o tempo e pequenas e curtas iteraes de

durao fixa (geralmente 1 4 semanas), com cdigo
potencialmente entregvel demonstrado depois de
cada iterao.
Otimize o plano de entrega e atualize prioridades

em colaborao com o cliente, baseados em insights
atravs de inspeo da entrega depois de cada
iterao.
Otimize o processo executando uma retrospectiva

depois de cada iterao.
Ento ao invs de um grande grupo gastando um monte de

tempo construindo uma grande coisa, temos uma equipe
pequena gastando um tempo curto construindo uma
pequena coisa. Mas integrando regularmente para ver o
todo.
133 palavras... Perto o suficiente.
Para mais detalhes, verifique Scrum e XP direto das
Trincheiras. O livro grtis e est online. Eu conheo o
autor, ele um cara legal :o)
http://www.infoq.com/br/minibooks/scrum-xp-from-thetrenches
Para mais links sobre Scrum v em http://www.crisp.se/scrum
O que so mesmo Scrum e Kanban?|

25
Kanban em poucas palavras
Visualize o fluxo de trabalho

o
Divida o trabalho em partes, escreva cada

item em um carto e coloque na parede.
Use colunas nomeadas para ilustrar onde

cada item est no fluxo de trabalho.
Limite o trabalho em progresso (WIP - work in

progress) associe limites explcitos para quantos
itens podem estar em progresso em cada estado do
fluxo de trabalho.
Acompanhe o tempo de execuo da tarefa (tempo

mdio para completar um item, algumas vezes
chamado de tempo de ciclo), otimize o processo
para tornar o tempo de execuo o menor e mais
previsvel possvel.
Ns coletamos links teis de Kanban em:

http://www.crisp.se/kanban
Ento como Scrum e Kanban se

relacionam?| 27
2
Ento como Scrum e
Kanban se relacionam?
Scrum e Kanban so ambos ferramentas
de processo
Ferramenta = qualquer coisa utilizada com a finalidade de
realizar uma tarefa ou atingir um objetivo. Processo = como
voc trabalha.
Scrum e Kanban so ferramentas de processo que, em certa
medida, te ajudam a trabalhar de maneira mais eficaz,
dizendo a voc o que fazer. Java tambm uma ferramenta,
ela lhe fornece uma maneira mais simples de programar. A
escova de dentes tambm uma ferramenta, que ajuda voc a
alcanar seus dentes para que voc possa limp-los.
Compare ferramentas para

compreenso,
No julgamento
Faca ou garfo qual a melhor ferramenta?

de ambos | 28
Uma pergunta completamente sem sentido certo? Porque a

resposta depende do seu contexto. Para comer almndegas
provavelmente o garfo o melhor. Para cortar cogumelos a
faca provavelmente melhor. Para batucar na mesa qualquer
um dele serve. Para comer um bife voc provavelmente vai
querer usar as duas ferramentas juntas. Para comer arroz...
bem... alguns preferem garfo, enquanto outros preferem os
pauzinhos.
Sendo assim, quando comparamos ferramentas devemos ter

cuidado. Compare para compreenso, no para julgamento.
Nenhuma ferramenta completa,

nenhuma ferramenta perfeita
Como quaisquer ferramentas, Scrum e Kanban no so
perfeitos nem tampouco completos. Eles no lhe dizem tudo o
que voc precisa fazer, eles apenas lhes oferecem algumas
restries e orientaes. Por exemplo, Scrum lhe restringe a
ter iteraes de tempo fixo e equipes multifuncionais,
enquanto que Kanban lhe restringe a utilizar quadros visveis
e limitar o tamanho de suas linhas de produo.

relacionam?| 29
O interessante aqui que o valor de uma ferramenta que ela
limita suas opes. Uma ferramenta-processo que lhe permite
fazer tudo no l muito til. Ns poderamos chamar este
processo Faa Qualquer Coisa ou que tal Faa a Coisa
Certa. O processo Faa a Coisa Certa certamente funciona,
uma bala de prata! Afinal, se ele no funcionar, bvio que
voc no est seguindo o processo :o)
Usar as ferramentas adequadas vai lhe ajudar a ter sucesso,
mas isso no vai lhe garantir o sucesso. fcil confundir
sucesso/falha de um projeto com sucesso/falha da ferramenta.
Um projeto pode ter sucesso por utilizar uma boa

ferramenta.
Um projeto pode ter sucesso apesar de uma pssima

ferramenta.
Um projeto pode falhar por causa de uma pssima

ferramenta.
Um projeto pode falhar apesar de utilizar uma boa

ferramenta.
O Scrum mais prescritivo que o

Kanban
Podemos comparar ferramentas analisando quantas regras
elas oferecem. Prescritivo significa mais regras a seguir e
adaptativo significa menos regras a seguir. Prescritivo
100% significa que voc no precisa usar seu crebro, j h
regra para tudo. Adaptativo 100% significa faa qualquer
coisa, no existe nenhum tipo de regras ou restries. Como
podemos ver, os dois extremos da escala acabam se tornando
ridculos.

de ambos | 30
Mtodos geis so s vezes chamados de mtodos leves
(lightweight), especificamente porque eles so menos
prescritivos que os mtodos tradicionais. De fato, o primeiro
princpio do Manifesto gil Indivduos e Interaes sobre
Processos e Ferramentas.
Scrum e Kanban so ambos altamente adaptativos, mas
falando relativamente, Scrum mais prescritivo que Kanban.
Scrum lhe d mais restries, por conta disso, deixa menos
opes abertas. Por exemplo, o Scrum prescreve o uso de
iteraes de durao fixa, o Kanban no.
Vamos comparar mais alguns processos e ferramentas na
escala prescritivo x adaptativo:
RUP bastante prescritivo ele tem mais de 30 papis, mais

de 20 atividades e mais de 70 artefatos; uma quantidade
enorme de coisas para aprender. Entretanto no consideramos
que voc vai usar tudo isso; consideramos que voc vai
selecionar um subconjunto adequado para seu projeto.
Infelizmente isso parece ser difcil na prtica. Hmmmm
vamos precisar do artefato Registro da Auditoria de
Configurao? Vamos precisar do papel de Gerente de
controle de mudanas? No tenho certeza, ento vamos

relacionam?| 31
mant-los caso for necessrio. Esta pode ser uma das razes
pelas quais as implementaes do RUP normalmente so
consideradas muito pesadas quando comparadas aos mtodos
geis como Scrum e XP.
XP (eXtreme programming programao extrema)
bastante prescritiva comparada ao Scrum. Ela inclui quase
tudo do Scrum + algumas boas prticas de engenharia bem
especficas como desenvolvimento orientado a testes e
programao em par.
Scrum menos prescritivo que XP, uma vez que ele no
prev nenhuma prtica especfica de engenharia. Porm,
Scrum mais prescritivo que Kanban, uma vez que prescreve
coisas como iteraes e equipes multifuncionais.
Uma das principais diferenas entre Scrum e RUP que no
RUP voc recebe coisas demais, e voc supostamente remove
o material que no precisa. No Scrum voc recebe muito
pouco, e supostamente adiciona o material que lhe falta.
Kanban deixa quase tudo em aberto. As nicas restries so:
Visualize Seu Fluxo de Trabalho e Limite Suas Atividades
em Andamento. Apenas a alguns centmetros de Faa
Qualquer Coisa, mas ainda assim surpreendentemente
poderoso.
No se prenda a uma nica

ferramenta!
Misture e combine as ferramentas de que voc precisa! Eu mal
posso imaginar uma equipe Scrum de sucesso que no inclui,
por exemplo, a maioria dos elementos do XP. Muitas equipes
Kanban usam reunies dirias (uma prtica Scrum). Algumas
equipes Scrum escrevem alguns dos seus itens de backlog
como casos de uso (uma prtica RUP) ou limitam seus
tamanhos de fila (uma prtica Kanban). O que funcionar para
voc.

de ambos | 32
Miyamoto Musashi (famoso samurai do sculo 17, famoso por
sua tcnica de luta das espadas gmeas) disse, brilhantemente:
No desenvolva apego a
nenhuma arma ou escola de
combate.
- Miyamoto Musashi
Contudo, preste ateno nas limitaes de cada ferramenta. Por

exemplo, se voc usa Scrum e decide parar de usar iteraes de
tempo fixo (ou qualquer outro aspecto central do Scrum), ento
no diga que voc est usando Scrum. Scrum suficientemente
minimalista tal como , se voc remover coisas e continuar
chamando isso de Scrum a palavra ficar sem sentido e
confusa. Chame de algo como "inspirado em Scrum" ou "uma
derivao do Scrum", ou que tal "Scrumish" :o)
Scrum prescreve papis| 33
3
Scrum prescreve papis
Scrum prescreve 3 papis: Product Owner (cria a viso do
produto e prioridades), Equipe (implementa o produto) e
ScrumMaster (remove impedimentos e fornece liderana de
processo).
Kanban no prescreve papel nenhum.
Isso no significa que voc no possa ou no deva ter o papel
de um Product Owner em Kanban! Significa apenas que voc
no precisa. Tanto em Scrum quanto em Kanban, voc livre
para incluir quaisquer papis adicionais que precisar.
Mas tenha cuidado ao incluir papis, tenha certeza de que os
papis adicionais realmente agregam valor e no entram em
conflito com outros elementos do processo. Voc tem certeza
de que precisa do papel de Gerente de Projetos? Em um
grande projeto talvez seja uma grande idia, talvez seja a
pessoa que ajuda a sincronizar mltiplos projetos e Product
Owners entre si. Em um projeto pequeno esse papel pode ser
um desperdcio, ou pior, pode levar a uma sub-otimizao e
ao micro gerenciamento.
O raciocnio comum tanto em Scrum quanto em Kanban
menos mais. Ento, na dvida, comece com menos.
No resto do artigo eu usarei o termo Product Owner para
representar aquele que define as prioridades de uma equipe,
independente do processo usado.

de ambos| 34
4
Scrum prescreve iteraes em
time-box
Scrum baseado em iteraes de tempo fixo. Voc pode
escolher a durao da iterao, mas a idia geral manter a
mesma durao de iterao por um perodo de tempo, desta
forma estabelecendo uma cadncia.
Incio da iterao: Um plano de iterao criado,

isto , a equipe puxa um nmero especfico de itens
do product backlog, baseado nas prioridades do
Product Owner e no quanto a equipe acha que pode
completar em uma iterao.
Durante a iterao: A equipe concentra-se em

entregar os itens com que se comprometeu. O escopo
da iterao fixado.
Fim da iterao: A equipe demonstra o cdigo de

trabalho para as partes interessadas relevantes. Este
cdigo, idealmente, deveria ser potencialmente
entregvel (isto , testado e pronto para funcionar).
Em seguida, a equipe faz uma retrospectiva para
discutir e melhorar seu processo.
Ento o Scrum uma nica cadncia de tempo fixo que

combina trs diferentes atividades: planejamento, melhoria de
processo e (idealmente) release.

time-box| 35
No Kanban, iteraes de durao fixa no so prescritas.
Voc pode escolher quando planejar, melhorar processo e
entregar. Pode escolher fazer essas atividades numa
periodicidade regular (release toda segunda), ou por
demanda (release sempre que tivermos algo til a entregar).
Equipe #1 (cadncia nica)

Ns fazemos iteraes do Scrum
Equipe #2 (trs cadncias)

Ns temos trs cadncias diferentes. Toda semana ns
liberamos tudo o que est pronto para a release. Toda
segunda semana ns temos uma reunio de planejamento e
atualizamos nossas prioridades e planos para release. Toda
quarta semana ns temos uma reunio de retrospectiva para
ajustar e melhorar nosso processo

time-box| 36
Equipe #3 (mais orientada para eventos)

Ns Iniciamos uma reunio de planejamento sempre que
esgotamos nosso trabalho a fazer. Iniciamos uma release
sempre que temos um grupo Mnimo Aceitvel de
Funcionalidades (MAF's) pronto para entrega. Iniciamos um
crculo de qualidade espontneo sempre que nos deparamos
com o mesmo problema pela segunda vez. Tambm fazemos
uma retrospectiva mais profunda toda quarta semana.
Kanban limita WIP por estado de

fluxo de trabalho, Scrum por
iterao| 37
5
iterao
Em Scrum, o sprint backlog mostra quais so as tarefas a
serem executadas durante a iterao corrente (= sprint na
linguagem Scrum). Geralmente ele representado usando
cartes na parede, conhecido tambm por quadro do Scrum
ou quadro de tarefas.
Ento qual a diferena entre o quadro de Scrum e o quadro
de Kanban? Vamos comear com um projeto trivialmente
simples e compar-los:
Em ambos os casos ns estamos controlando um grupo de

itens ao longo do progresso pelo fluxo todo. Ns
selecionamos trs estados: No iniciado, Iniciado e Pronto.
Voc pode escolher os estados que quiser algumas equipes

iterao| 38
adicionam outros estados como, por exemplo, Combinar,
Testar, Entregar, etc. Mas no se esquea da regra menos
mais.
Ento qual a diferena entre esses dois exemplos de quadros?
Sim o pequeno 2 na coluna do meio no quadro Kanban. E
isto tudo. Este 2 significa no pode haver mais de 2 itens
nesta coluna ao mesmo tempo.
Em Scrum no h nenhuma regra advertindo a equipe para
no colocar todas as atividades na coluna Em execuo ao
mesmo tempo! Porm, h um limite implcito, j que a
interao, por si s, tem um escopo fixo. Neste caso, o limite
implcito por coluna 4, j que h apenas 4 itens em todo o
quadro. Ento, Scrum limita as atividades em andamento2
indiretamente, enquanto Kanban as limita diretamente.
A maioria das equipes Scrum aprende na prtica que no
uma boa idia ter muitas atividades na coluna em execuo,
e criam uma cultura de tentar finalizar as atividades atuais
antes de comear outras.
Alguns at decidem claramente limitar os nmeros de
atividades permitidas na coluna em execuo e ento
tchammm! o quadro Scrum se transforma em um quadro
Kanban!
Ento, tanto Scrum quanto Kanban limitam as atividades em
andamento, mas de formas diferentes. Equipes Scrum
geralmente medem a velocidade quantos itens (ou unidades
de medidas correspondentes como pontos da estria3) sero
feitos por iterao.
Uma vez que a equipe sabe sua velocidade, ela torna-se seu
limite de atividades em andamento. Uma equipe que tem
velocidade mdia de 10, geralmente, no ir colocar mais de
10 itens (ou pontos da estria) em uma iterao.
2
3
NT.: WIP (Work Itens in Progress) no original.

NT.: History Points no original

de ambos| 39
Desta forma, em Scrum as atividades em andamento so
limitadas por unidade de tempo.
Em Kanban as atividades em andamento so limitadas pelo
fluxo de trabalho.
No exemplo de Kanban acima, no mximo 2 itens podem
estar no estado Iniciado ao mesmo tempo, independente da
cadncia. Voc precisa escolher qual limite aplicar para cada
estado dentro do fluxo de trabalho, mas a idia geral limitar
as atividades em andamento de todos os estados e suas fases,
iniciando o quanto antes e terminando o mais tarde possvel
dentro dos limites estabelecidos.
Desta forma, no exemplo acima devemos considerar um
limite para as atividades em andamento No iniciado
tambm (ou como quer que se chame o primeiro estado das
suas tarefas).
Uma vez que tenhamos os limites das atividades em
andamento devidamente estabelecidos, podemos comear a
medir e prever o tempo de execuo do ciclo, isto , o tempo
mdio que cada item leva para cumprir todo o ciclo atravs do
quadro.
Prever o tempo gasto em todo o fluxo nos permite uma maior
fidelidade aos ANS - Acordos de Nvel de Servio (ou do
ingls SLAs Service-Level Agreements) e fazer planos de
entrega mais realistas.

iterao| 40
Se o tamanho dos itens variar muito, talvez voc deva,
alternativamente, considerar ter os limites das atividades em
andamento definidos em pontos da histria, ou qualquer outra
unidade de medida que voc esteja usando.
Algumas equipes investem e se esforam em dividir itens,
aproximadamente, nos mesmos tamanhos para evitar esses
tipos de consideraes e reduzir o tempo gasto nestas
estimativas (voc pode at considerar a estimativa a ser
gasta).
mais fcil criar um fluxo regular se os itens estiverem
aproximadamente uniformizados.

de ambos| 41
6
Ambos so empricos
Imagine se houvesse botes nestes medidores, e voc pudesse

configurar o seu processo apenas girando os botes. "Eu
quero alta capacidade, baixo tempo de execuo, alta
qualidade, e alta previsibilidade. Ento, eu giraria os botes
para 10, 1, 10, 10 respectivamente."
No seria timo? Infelizmente, no existem tais controles
diretos. No que eu saiba, pelo menos. Avise-me se voc
encontrar algum.
Em vez disso o que temos um monte de controles indiretos.

iterao| 42
Tanto Scrum quanto Kanban so empricos no sentido que se
espera que voc experimente o processo e personalize ao seu
ambiente. Na verdade, voc tem que experimentar. Nem
Scrum nem Kanban fornecem todas as respostas eles apenas
fornecem um conjunto bsico de restries para conduzir o
seu prprio processo de melhoria.
O Scrum diz que voc deve ter uma equipe

multifuncional. Ento, quem deve estar em qual
equipe? No sei, experimente.
O Scrum diz que a equipe define quanto trabalho

realizar em um sprint. Ento, quanto trabalho eles
devem escolher? No sei, experimente.
O Kanban diz que voc deve limitar o WIP. Ento,

qual deve ser esse limite? No sei, experimente.
Como eu mencionei antes, Kanban impe menos restries

que Scrum. Isso significa que voc tem mais parmetros para
pensar, mais botes para apertar. Isso pode ser tanto uma
desvantagem quanto uma vantagem, dependendo do seu
contexto. Quando voc abre a janela de configurao de uma
ferramenta de software, prefere ter 3 opes para ajustar, ou
100 opes para ajustar? Provavelmente algo no meio disso.
Depende de quanto voc precisa ajustar e de quanto voc
conhece da ferramenta.
Ento, vamos imaginar que ns reduzimos o limite de WIP
baseados na hiptese de que isso ir melhorar nosso processo.
Vamos, ento, observar algumas coisas como capacidade,
lead time, qualidade e previsibilidade de mudanas. Iremos
tirar concluses dos resultados e da mudar mais algumas
coisas, melhorando continuamente nosso processo.
H muitos nomes para isso. Kaizen (melhoria contnua no
jargo do Lean), Inspecionar e Adaptar (no jargo do Scrum),
Controle de Processo Emprico, ou, por que no, o Mtodo
Cientfico.

de ambos| 43
O elemento mais importante disso o ciclo de feedback.
Mude alguma coisa => Saiba como foi => Aprenda com isso
=> Mude alguma coisa novamente. Falando de um modo
geral, voc quer o ciclo de feedback o mais rpido possvel,
para que seja possa adaptar o processo rapidamente.
Em Scrum, a iterao bsica de um feedback o sprint. H
mais, porm, especialmente se voc combinar com o XP
(eXtreme Programming):
Quando feito corretamente, Scrum + XP lhe oferece vrios

ciclos de feedback extremamente valiosos.
O ciclo interno de feedbacks, programao em par, um ciclo
de feedbacks de poucos segundos. Defeitos so encontrados e
corrigidos nos segundos da criao (Ei, essa varivel no
deveria ser um 3?"). Isso um ns estamos construindo o
programa corretamente?" ciclo de feedbacks.
O ciclo externo de feedbacks, o sprint, oferece um ciclo de
feedbacks de poucas semanas. Isso um ns estamos
construindo o programa corretamente?" ciclo de feedbacks.
Ento, e sobre o Kanban? Bem, primeiramente voc pode (e
provavelmente deve) colocar todos os ciclos de feedback
acima no seu processo, usando ou no Kanban. Kanban,
ento, lhe oferece algumas mtricas, em tempo real, muito
teis.

iterao| 44
Tempo mdio de execuo. Atualizado a cada vez

que um item atinge o Done (ou o que vocs
chamam de sua coluna mais direita).
Gargalos. Um sintoma tpico que a coluna X est

repleta de itens, enquanto a coluna X+1 est vazia.
Procure por "bolhas de ar" em seu quadro.
A coisa agradvel sobre mtricas em tempo real que voc

pode escolher o comprimento do seu ciclo de feedback, com
base na freqncia com que voc est disposto a analisar as
mtricas e fazer mudanas. Ciclos muito longos significam
que melhorias no seu processo se daro de forma lenta. Ciclos
muito curtos podem fazer com que o seu processo no tenha
tempo para estabilizar entre cada mudana, o que pode causar
perda.
Na verdade, o comprimento do ciclo de feedback em si uma
das coisas com as quais voc pode experimentar... como uma
espcie de meta-ciclo de feedback. OK, parando por aqui.
Exemplo: Experimentando com WIP limites em Kanban.

Um dos pontos de ajuste (tweak points) tpicos de Kanban o
limite de trabalho em progresso (WIP). Ento, como vamos
saber se o nosso est correto?
Vamos dizer que temos uma equipe de 4 pessoas, e ns
decidimos comear com um limite de WIP, de 1.

de ambos| 45
Sempre que comearmos a trabalhar em um item, no

poderemos iniciar um novo item at que o primeiro esteja
concludo. Dessa maneira, o item em que estamos trabalhando
tende a ser concludo mais rapidamente.
timo! Mas ento fica claro que normalmente no possvel
as quatro pessoas trabalharem no mesmo item (no contexto
deste exemplo), temos ento gente sem nada para fazer. Se
isso acontece de vez em quando no problema, mas se
acontece freqentemente o tempo de execuo mdio vai
acabar aumentando. Resumindo, um WIP de 1 significa que
uma vez que entrem os itens vo sair de Iniciado
rapidamente, mas antes disso vo ficar presos em No
Iniciado mais tempo do que o necessrio, portanto o tempo
de execuo do fluxo todo vai ficar desnecessariamente alto.
Ento, se WIP de 1 era pouco, que tal aumentar para 8?

iterao| 46
Funciona bem por algum tempo. Descobrimos que, na mdia,
trabalhar em pares faz com que o trabalho acabe mais rpido.
Ento, numa equipe de quatro pessoas, normalmente teremos
dois itens em andamento ao mesmo tempo. O WIP de 8 um
limite superior, ento no h problema em ter menos itens em
andamento.
Imagine agora, que nos deparamos com um problema com o
servidor de integrao, portanto no podemos concluir
completamente qualquer um dos itens (nossa definio de
"Done" inclui a integrao). Esse tipo de coisa acontece
algumas vezes corretamente?
J que no podemos completar o item D ou E, comearemos a

trabalhar no item F. No podemos integrar nenhum, ento ns
comeamos o novo item G. Depois de um tempo ns
atingimos nosso limite do Kanban - 8 itens em "Em
Desenvolvimento".

de ambos| 47
Nesse ponto no podemos comear mais itens. Ei, melhor

ns concertarmos esse maldito servidor de integrao! O
limite das atividades em andamento (WIP) levou-nos a reagir
e corrigir o gargalo em vez de apenas aumentar um monte de
atividade inacabada.

iterao| 48
Isso bom. Mas se o limite das atividades em andamento
fosse 4, ns teramos reagido muito mais cedo, assim
fornecendo-nos um melhor tempo mdio de execuo (lead
time).
Portanto, isso um equilbrio. Medimos o tempo mdio de
execuo e ficamos otimizando nosso limite das atividades
em andamento para aperfeioar o tempo de execuo.
Depois de um tempo podemos encontrar os itens acumulando

na coluna "No Iniciado". Talvez seja hora de adicionar um
limite das atividades em andamento nessa coluna tambm.

de ambos| 49
Por que precisamos de uma coluna No Iniciado? Bem, se o
cliente estivesse sempre disponvel para falar com a equipe o
que fazer na seqncia quando perguntarem.
Ento a coluna No Iniciado no seria necessria.
Mas nesse caso o cliente s vezes no est disponvel, ento a
coluna No Iniciado fornece a equipe uma pequena reserva
de trabalho nesse item.
Experimente! Ou, como dizem os Evangelistas de Scrum
(Scrumologists), Inspecione & Adapte!
Scrum resiste a mudanas dentro

de uma iterao| 50
7
de uma iterao
Digamos que nosso quadro do Scrum se parea com este:
E se algum aparecer querendo adicionar E ao quadro?

Uma equipe de Scrum tipicamente diria algo como No,
desculpe, estamos comprometidos com A+B+C+D nesse
sprint. Mas sinta-se livre para adicionar E ao product
backlog. Se o Product Owner considerar que isto tem alta
prioridade, ele adicionar isso no prximo sprint. Sprints do
tamanho certo do ao time tempo focado suficiente para
conseguir fazer alguma coisa, enquanto ainda permitem que o
Product Owner gerencie e atualize prioridades com
periodicidade regular.

de ambos | 51
AMBOS SO EMPRICOS | 51
Mas ento, o que uma equipe de Kanban diria?
Um Kanban poderia dizer Fique vontade para adicionar E

na coluna No Iniciado. Entretanto, o limite 2 para aquela
coluna, ento voc ter de remover C ou D nesse caso.
Estamos trabalhando em A e B neste momento, mas assim
que ns tivermos capacidade, vamos pegar o item do topo do
No Iniciado.
Assim, o tempo de resposta (quanto demora a responder a
uma mudana de prioridades) de uma equipe de Kanban to
longo quanto capacidade de se tornar disponvel, seguindo o
princpio geral de um item fora = um item dentro
(controlado pelos limites de trabalho em andamento).
Em Scrum, o tempo de resposta em mdia a metade da
durao do sprint.
Em Scrum, o Product Owner no pode alterar o quadro
Scrum quando a equipe j estiver comprometida com
determinados de itens na iterao. J em Kanban, voc
precisa definir suas prprias regras bsicas sobre quem tem
permisso de modificar o que no quadro. Normalmente para o
Product Owner reservada uma coluna do tipo A Fazer ou
Done ou Backlog ou ainda Proposta bem esquerda,
onde ele pode fazer as modificaes que bem entender.

de uma iterao| 52
No entanto, estas duas abordagens no so mutuamente
exclusivas. Uma equipe Scrum pode decidir por deixar o
Product Owner modificar as prioridades no meio do sprint
(ainda que isto devesse ser considerado normalmente uma
exceo).
E uma equipe Kanban pode decidir incluir restries sobre
quando as prioridades podem ser modificadas. Uma equipe
Kanban pode ainda decidir usar iteraes com durao fixa e
compromissos predefinidos, tal como em Scrum.

de ambos | 53
8
Quadro Scrum limpo
entre cada iterao
Um quadro do Scrum se parece algo como isto durante as
diferentes fases de um sprint.
Quando o sprint acaba, o quadro limpo todos os itens so

removidos. O sprint novo iniciado e depois da reunio de
planejamento do sprint, temos um novo quadro do Scrum,
com novos itens na coluna mais esquerda.
Tecnicamente isso desperdcio, mas para equipes Scrum
experientes isso no costuma demorar muito, e o processo de
limpeza do quadro pode dar um bom senso de realizao e
fechamento.
Quadro Scrum limpo entre cada

iterao| 54
Algo como lavar os pratos depois do jantar - faz-lo di, mas

nos sentimos bem depois.
Em Kanban, o quadro normalmente uma coisa de
persistncia - voc no precisa limp-lo e comear de novo.

de ambos| 55
9
Scrum prescreve
equipes multifuncionais
Um quadro de Scrum pertence a exatamente uma equipe
Scrum. Uma equipe Scrum multifuncional, ela contm todas
as habilidades necessrias para completar todos os itens
contidos na iterao. Um quadro de Scrum geralmente
visvel a qualquer pessoa que esteja interessada, mas somente
aqueles que fazem parte da equipe Scrum podem edit-lo
a sua ferramenta para gerenciar o seu compromisso para esta
iterao.
Em Kanban, equipes multifuncionais so opcionais, e o

quadro de atividades no precisa pertencer exclusivamente a
uma nica equipe. Um quadro de atividades est relacionado
a um fluxo de trabalho, no necessariamente a uma equipe.
Scrum prescreve equipes

multifuncionais| 56
Aqui esto dois exemplos:
Exemplo 1: Todo o quadro de atividades usado por uma

nica equipe multifuncional. Assim como no Scrum.
Exemplo 2: O Product Owner define prioridades na coluna 1.
Uma equipe multifuncional de desenvolvedores faz o
desenvolvimento (coluna 2) e testa (coluna 3). A entrega
(coluna 4) feita por uma equipe especializada. Existe certa
sobreposio de competncias, dessa maneira se a equipe que
faz a entrega acaba se tornando um gargalo, um membro da
equipe de desenvolvimento ir ajud-los na atividade de
entrega.
Assim, em Kanban necessrio estabelecer algumas regras
bsicas definindo quem usa e como deve ser usado o quadro
de atividades, sendo que voc pode experimentar com essas
regras at aperfeioar o fluxo.

de ambos | 57
10
Itens do Scrum backlog devem
caber num sprint
Ambos Scrum e Kanban so baseados no desenvolvimento
incremental, isto , quebrar o trabalho em pedaos menores.
Uma equipe Scrum ir comprometer-se apenas aos itens que
julguem poder terminar dentro de uma iterao (baseado no
conceito de Done). Caso um item seja grande demais para
caber em um sprint, a equipe e o Product Owner tero que
encontrar formas de quebr-lo em pedaos menores at que
ele se encaixe.
Se os itens tendem a ser grandes, as iteraes sero maiores
(embora geralmente no maiores do que 4 semanas).
Itens do Scrum backlog devem

caber num sprint| 58
Equipes Kanban tentam minimizar o tempo de execuo e

equilibra o fluxo, de modo que indiretamente criam um
incentivo para quebrar itens em pedaos relativamente
menores. Porm no h nenhuma regra explcita indicando
que os itens devam ser suficientemente pequenos para caber
em um determinado perodo de tempo.
Em um mesmo quadro ns podemos ter um item que ir levar
1 ms para ser concludo e outro item que levar 1 dia.

de ambos | 59
11
Scrum prescreve estimativas e
velocidade
No Scrum, equipes devem estimar o tamanho (= quantidade
de trabalho) de cada item aos quais eles se comprometeram.
Somando o tamanho de cada item concludo ao final de cada
sprint, ns teremos a velocidade. A velocidade uma medida
da capacidade a quantidade de coisas que ns podemos
entregar por sprint.
Aqui temos um exemplo de uma equipe caso esta tenha uma
velocidade mdia igual a 8.
Saber que a velocidade mdia 8 bom porque nos permite

fazer previses mais realistas sobre quais itens podemos
entregar nos futuros sprints, e portanto, fazer planos de
entrega cada vez mais prximos da realidade.
Scrum prescreve estimativas e

velocidade| 60
J no Kanban, estimativa no obrigatrio. Portanto, se voc
precisar ter comprometimentos voc precisar decidir como
fornecer previses.
Algumas equipes optam por fazer estimativas e medir a
velocidade assim como no Scrum. Outras equipes escolhem
pular as estimativas, mas tentam quebrar cada item em itens
menores de aproximadamente do mesmo tamanho desta forma
eles podem medir a velocidade simplesmente em termos de
quantos itens foram concludos por unidade de tempo (por
exemplo, requisitos ou funcionalidades por semana).
Algumas equipes agrupam itens em nveis mnimos de
funcionalidades (do ingls MMFs (minimum marketable
features) e medem a mdia de tempo de execuo por MMF, e
usam esta medio para estabelecer o ANS (Acordos de Nvel de
Servio) por exemplo, quando ns nos comprometemos a um
MMF, este ser sempre entregue no prazo de 15 dias.
Existem inmeras tcnicas interessantes para o modelo
Kanban de planejamento de entregas e gerenciamento de
compromissos porm no h tcnica especfica ou
mandatria a ser seguida ento v em frente e pesquise novas
formas e tcnicas at encontrar a que se encaixe melhor ao
seu contexto. Provavelmente veremos algumas boas
prticas surgir ao longo do tempo.

de ambos| 61
12
Ambos permitem trabalhar
em mltiplos produtos
simultaneamente
No Scrum, Product Backlog um nome muito infeliz, pois
implica que todos os itens devem ser do mesmo produto.
Aqui temos dois produtos, verde e amarelo, cada um com seu
prprio product backlog e sua prpria equipe:
Produto
Verde
Produto
Amarelo
Mas, e se voc s tem uma equipe? Bem, pense no product

backlog mais como um backlog da equipe. Ele lista as
prioridades das iteraes programadas para uma equipe em
particular (ou um grupo de equipes). Ento, se essa equipe
est mantendo mltiplos produtos, basta juntar os produtos
em uma nica lista. Isso nos fora a priorizar os produtos, o
Ambos permitem trabalhar em

mltiplos produtos
simultaneamente| 62
que til em alguns casos. Existem muitas maneiras de fazer
isso na prtica:
Uma estratgia seria ter a equipe focada em um produto por
sprint:
Outra estratgia seria ter a equipe trabalhando em

caractersticas dos dois produtos em cada sprint:
a mesma coisa no Kanban. Podemos ter diversos produtos

fluindo atravs do mesmo quadro branco. Podemos distinguilos utilizando diferentes cartes coloridos:

de ambos| 63
... ou por raias:
Produto Verde:
Produto Amarelo:
Ambos so Lean e geis | 64
13
Ambos so Lean e geis
Eu no vou explorar o Pensamento Lean e o Manifesto gil
aqui, mas em termos gerais tanto o Scrum quanto o Kanban
so bem alinhados com estes valores e princpios. Por
exemplo:
Scrum e Kanban so sistemas puxados, que

correspondem ao princpio de gesto de inventrio
de Just In Time (JIT) do Lean. Isto significa que a
equipe escolhe quando e quanto de trabalho ir se
comprometer para ento puxar o trabalho quando
esto prontos para comear, ao invs de ter que
empurrar o trabalho de algum lugar. Assim como
uma impressora puxa para a prxima pgina somente
quando est pronta para imprimi-la (embora exista
um nmero pequeno e limitado de papel que pode
ser puxado).
Scrum e Kanban so baseados em otimizao emprica

e continua de processo, que corresponde ao princpio
de Kaizen do Lean.
Scrum e Kanban do nfase resposta a mudana ao

invs de seguir um plano pr-estabelecido (embora o
Kanban tipicamente permita uma resposta mais
rpida do que o Scrum), um dos quatro valores do
manifesto gil.

de ambos| 65
... e mais.
Sob certa perspectiva, o Scrum pode ser visto como no to
enxuto porque ele prescreve itens em srie em iteraes de
durao fixa. Mas isso depende do tamanho da sua iterao e
com o que voc est comparando. Comparado com um
processo mais tradicional, no qual talvez integramos e
entregamos alguma coisa 2 a 4 vezes por ano, um time Scrum
produzindo cdigo entregvel a cada 2 semanas
extremamente enxuto.
Mas ento, se voc fizer a iterao cada vez mais curta, voc
est essencialmente aproximando ao Kanban. Quando voc
comea a falar sobre deixar a iterao mais curta que uma
semana, voc pode pensar em livrar-se inteiramente de
iteraes de durao fixa.
Eu disse isso antes e vou continuar dizendo: experimente at
voc encontrar algo que funcione para voc! E depois
continue experimentando :o)
Diferenas menores | 66
14
Diferenas menores
Aqui esto algumas diferenas que parecem ser menos
relevantes, em comparao com as outras mencionadas antes.
Entretanto, bom estar ciente delas.
Scrum prescreve um
product backlog priorizado
Em Scrum, a priorizao sempre feita por triagem do
product backlog, e as mudanas de prioridades realizam-se no
prximo sprint (no no sprint atual). Em Kanban voc pode
escolher qualquer plano de prioridade (ou mesmo nenhum), e
as mudanas realizam-se assim que a equipe estiver
disponvel (ao invs de em horrios fixos). Pode-se ou no ter
um product backlog, e pode-se ou no ser priorizado.
Na prtica, isso faz pouca diferena. Em um quadro de
Kanban a coluna mais esquerda desempenha, tipicamente, o
mesmo objetivo do product backlog de Scrum. Seja a lista
ordenada ou no por prioridade, a equipe precisa de algum
tipo de regra para a deciso de quais itens devem ser
realizados primeiro. Exemplos de regras para a deciso:
Sempre pegue o primeiro item do topo da lista.
Sempre pegue o item mais antigo (ento cada item

tem um timestamp).
Pegar qualquer item.

de ambos| 67
Gastar aproximadamente 20% em itens

manuteno e 80% em novas funcionalidades.
Dividir a capacidade da equipe aproximadamente de

modo uniforme entre o produto A e o produto B.
Sempre pegue os itens em vermelho primeiro, se

houver algum.
de
Em Scrum, o product backlog tambm pode ser usado na

forma de Kanban (eu acho). Podemos limitar o tamanho dele,
e criar regras de deciso de como ele deve ser priorizado.
Em Scrum, so prescritas reunies

dirias
Uma equipe Scrum tem uma pequena reunio (de no mximo
15 minutos) todos os dias na mesma hora e local. O objetivo
da reunio difundir informao sobre o que est
acontecendo, planejar o trabalho do dia em curso, e identificar
os problemas mais importantes. Isso s vezes chamado de
reunio diria em p, porque geralmente realizada em p
(para mant-la curta e manter um alto nvel de energia).
Reunies dirias no so prescritas no Kanban, mas, de
qualquer maneira, a maioria das equipes de Kanban costuma
faz-las. uma excelente tcnica, independentemente do
processo utilizado.
Em Scrum, a reunio diria orientada pessoa cada
pessoa passa a informao, um a um. Muitas equipes Kanban
usam um formato mais orientado ao quadro, concentradas nos
gargalos e outros problemas visveis. Essa abordagem mais
escalvel.
Se tivermos 4 equipes compartilhando o mesmo quadro e
realizando suas reunies dirias juntas, no necessariamente
teremos que ouvir todo mundo falar enquanto
nos
concentramos nas partes de gargalo que esto no quadro.
No Scrum, so prescritos grficos de

burndown
Um grfico de burndown do
sprint mostra, em uma base
diria, o quanto de trabalho
resta na iterao atual.
A unidade do eixo Y a
mesma unidade utilizada
nas tarefas de sprint.
Normalmente horas ou dias
(se a equipe divide itens de
backlog em tarefas) ou
pontos de histria (se a equipe no os divide). Entretanto, h
muitas variaes disso.
Em Scrum, grficos de burndown do sprint so usados como
uma das principais ferramentas para acompanhar o
andamento de uma iterao.
Algumas equipes tambm usam grficos de burndown de
release, que segue o mesmo formato, mas em nvel de release
- ele normalmente mostra quantos pontos de histria restam
no product backlog depois de cada sprint.
O principal objetivo de um grfico de burndown perceber
facilmente, o mais cedo possvel, se estamos atrs ou frente
do cronograma, para que possamos adaptar.
Em Kanban, grficos de burndown no so prescritos. Na
verdade, no prescrito nenhum grfico em especial. Mas
voc est, logicamente, autorizado a usar qualquer tipo de
grfico que quiser (incluindo burndowns).
Este um exemplo de um diagrama de Fluxo Cumulativo.
Este tipo de grfico mostra o quanto seu fluxo regular e
como as atividades em andamento afetam o seu lead time.

de ambos| 69
Funciona da seguinte maneira: Todos os dias, totalize o

nmero de itens em cada coluna do quadro Kanban e coloque
os valores no eixo Y. Assim, temos que no dia 4 havia 9 itens
no quadro. Comeando pela coluna mais direita, havia 1
item em Produo, 1 item em Teste, 2 itens em
Desenvolvimento e 5 itens no backlog. Se ns plotarmos estes
pontos todos os dias e conectarmos os pontos teremos um
bom grfico como o do exemplo acima. As setas vertical e
horizontal mostram a relao entre as atividades em
andamento e o lead time.
A seta horizontal nos mostra que os itens adicionados ao
backlog no dia 4 levaram, em mdia, 6 dias para alcanar a
produo. Aproximadamente metade deste tempo foi em
Teste. Podemos observar que limitando as atividades em
andamento em Teste e em backlog poderamos reduzir
significativamente o tempo de espera total.
A inclinao da rea azul-escuro nos mostra a velocidade (ou
seja, nmero de itens implantados por dia). Ao longo do
tempo, podemos ver como a maior velocidade reduz o tempo
de espera, enquanto maior nmero de atividades em
andamento aumenta o tempo de espera.
A maioria das organizaes quer as coisas prontas mais
rapidamente (reduzir o lead time). Infelizmente muitas caem
na armadilha de pensar que isso significa ter mais gente ou
trabalhar horas-extras. Normalmente, a maneira mais eficaz
de conseguir que as coisas sejam feitas mais rapidamente
liberar o fluxo e limitar o trabalho capacidade, no
adicionar mais gente ou trabalhar mais. Esse tipo de diagrama
mostra porque e por isso aumenta a probabilidade de que a
equipe e a gerncia colaborem efetivamente.
Isto se torna ainda mais claro se distinguirmos entre estados
enfileirados (como aguardando testes) e estados de trabalho
(como testando). Queremos minimizar absolutamente o
nmero de itens esperando em filas, e um diagrama de fluxo
cumulativo ajuda a fornecer os incentivos corretos para isso.

de ambos| 71
15
Quadro Scrum vs.
quadro Kanban um exemplo
menos trivial
Em Scrum, o sprint backlog apenas uma parte de algo maior
a parte que mostra o que a equipe est fazendo durante o
sprint atual. A outra parte o product backlog a lista de
coisas que o Product Owner quer que sejam feitas nos sprints
futuros.
O Product Owner pode visualizar, mas no pode tocar no
sprint backlog. Ele pode modificar o product backlog a
qualquer momento, mas tais mudanas no tero efeito (i.e.,
no afetam o trabalho que est sendo feito no momento) at o
prximo sprint.
Quadro Scrum vs. quadro Kanban

um exemplo menos trivial| 72
Quando o sprint est pronto, a equipe entrega cdigo
potencialmente entregvel para o Product Owner. Ento a
equipe termina o sprint, faz sua reviso e orgulhosamente
demonstra as funcionalidades A, B, C, e D ao Product Owner.
O Product Owner agora pode decidir se vai produzir.
A ltima parte colocar realmente em produo usualmente
no includa no sprint, portanto, no visvel no backlog do
sprint.
Neste cenrio, o quadro Kanban deve preferencialmente se
parecer com isto:
Agora todo o fluxo de trabalho est no mesmo quadro no

estamos mais simplesmente olhando para o que uma equipe
Scrum est fazendo em uma iterao.
No exemplo acima, a coluna Backlog , apenas, uma lista
de coisas desejveis, sem qualquer ordem especial. A coluna
Selecionados contm os itens com maiores prioridades,
com o limite Kanban igual a 2. Desta forma, deve conter
apenas 2 itens com alta prioridade ao mesmo tempo. Sempre
que a equipe estiver pronta para comear a trabalhar em um
novo item, ela ir pegar o primeiro item da coluna
Selecionados. A qualquer momento o Product Owner
poder fazer mudanas nas colunas Backlog e
Selecionados, mas no poder mudar as demais colunas.
A coluna Desenvolver (dividida em duas sub-colunas)
mostra o que est sendo desenvolvido no momento, com um

de ambos| 73
limite Kanban de 3. Em termos de infra-estrutura de rede, o
limite Kanban corresponde a largura de banda e o tempo de
execuo corresponde ao ping (ou tempo de resposta).
Por que ns dividimos a coluna Desenvolver em duas subcolunas Iniciado e Pronto? Para dar equipe de produo
a oportunidade de saber quais itens eles podem mover para a
produo.
O limite de 3 compartilhado pelas duas sub-colunas. Por
qu? Vamos imaginar que temos dois itens em Pronto:
Isto significa que s podemos ter 1 item em Iniciado. Isto

significa
que
teremos
capacidade
em
excesso.
Desenvolvedores que poderiam iniciar um novo item, mas
no esto liberados em virtude do limite do Kanban. Isto lhes
d forte incentivo para concentrar esforos e ajudar a colocar
as coisas em produo, limpar a coluna Pronto e maximizar
o fluxo. Este efeito bom e gradual quanto mais coisas em
Pronto, menos coisas sero permitidas no Iniciado o
que ajuda a equipe a concentrar-se nas coisas certas.
Fluxo contnuo
Um fluxo contnuo um tipo de cenrio com um fluxo
perfeito, em que um item flui atravs do quadro sem ficar
preso em nenhuma coluna. Isso quer dizer que a todo o
momento existe algum trabalhando naquele item. Aqui est
um exemplo de como o quadro pode parecer nesse caso:

B est sendo desenvolvido nesse momento, A est sendo

colocado em produo nesse momento. Sempre que a equipe
estiver pronta para o prximo item, ela ir perguntar para o
Product Owner qual o item mais importante, e ela ter uma
resposta na hora. Se este cenrio ideal continuar, podemos
nos livrar das duas colunas Backlog e Escolhido e assim
ter um tempo de resposta realmente curto!
Cory Ladas expressou isso muito bem: O processo ideal de
planejamento do trabalho deve sempre fornecer equipe de
desenvolvimento a melhor coisa para trabalhar em seguida,
nem mais e nem menos.
O limite das atividades em andamento existe para impedir que
problemas fujam do controle. Ento, se as coisas esto fluindo
bem, os limites das atividades em andamento no so
realmente usados.
Um dia na terra do Kanban

de ambos| 75


de ambos| 77

O quadro de Kanban precisa se parecer com

este?
No, o quadro acima foi apenas um exemplo!
A nica coisa que o Kanban prescreve que o fluxo de
trabalho deve ser visual, e que o WIP deve ser limitado.
O objetivo criar um bom fluxo atravs do sistema e
minimizar o lead time. Ento voc precisa regularmente
levantar questes como:
Que colunas devemos ter?
Cada coluna representa um estado de fluxo de trabalho, ou
uma pilha (fila) entre dois estados de fluxo de trabalho.
Comece simples e adicione colunas conforme o necessrio.

de ambos| 79
Quais devem ser os limites do Kanban?
Quando o limite de Kanban para as suas colunas foi
atingido e voc no tem nada para fazer, comece a procurar
por um gargalo (pontos empilhando acima, direita no
quadro) e ajudar a corrigir o gargalo.
Se no houver nenhum gargalo, uma indicao de que o
limite do Kanban pode estar muito baixo, uma vez que a
razo para ter o limite era reduzir o risco de se alimentar
gargalos.
Se voc notar que muitos itens continuam por um longo
tempo sem serem trabalhados, uma indicao que o limite
de Kanban pode estar muito alto.
Limite de Kanban muito baixo => pessoas ociosas

=> m produtividade.
Limite de Kanban muito alto => tarefas inativas =>

lead time ruim.
Quo estritos so os limites de Kanban?

Algumas equipes as tratam como regras estritas (isto , a
equipe no pode exceder um limite), algumas equipes as
tratam como diretrizes ou disparadores de discusso (isto ,
quebrar um limite de kanban permitido, mas deve ser uma
deciso intencional com uma razo concreta). Ento, mais
uma vez, cabe a voc. Eu lhe disse que o Kanban no era
muito prescritivo, certo?
Resumo de Scrum vs. Kanban| 80
16
Resumo de Scrum vs. Kanban
Similaridades
Ambos so Lean e Agile.
Ambos usam controle de cronograma.
Ambos limitam atividades em andamento.
Ambos usam transparncia para direcionar a

melhoria do processo.
Ambos concentram-se na entrega de software que

funcione, o mais rpido possvel e freqentemente.
Ambos so baseados em equipes auto-organizveis.
Ambos exigem que o trabalho seja dividido em

partes.
Em ambos, o planejamento de release

continuamente otimizado, baseado em dados
(velocidade / tempo de execuo) empricos.

de ambos| 81
Diferenas
Scrum
Kanban
Iteraes Timeboxed prescritas.
Iteraes Timeboxed opcionais.

Pode ter cadncia separada para o
planejamento, release e melhoria
de processos. Pode ser orientada
para eventos, em vez de
timeboxed.
Equipe compromete-se a uma

quantidade especfica de trabalho
para esta iterao.
Compromisso opcional.
Usa a velocidade como padro

mtrico para o planejamento e
melhoria de processos.
Usa o Lead time como padro

mtrico para o planejamento e
melhoria de processos.
Equipes multifuncionais
prescritas.
Equipes multifuncionais opcionais.

Equipes de Especialistas
autorizada.
Os itens devem ser divididos

para que possam ser concludos
dentro de 1 sprint
Nenhum tamanho especial de item

prescrito
Grfico Burndown
Nenhum tipo especfico de

diagrama prescrito
WIP limitado indiretamente (por

sprint)
WIP limitado diretamente (por

situao do fluxo de trabalho)
Estimativa prescrita
Estimativa opcional
No poder adicionar itens

iterao em uso
Pode adicionar novos itens

sempre que houver capacidade
disponvel
O sprint backlog de uma

equipe especifica
Quadros kanban podem ser

compartilhados por vrias
Resumo de Scrum vs. Kanban | 82

equipes ou individualmente
Possui 3 papis (Product
Owner/ScrumMaster/Team)
No discrimina nenhum papel
Um quadro Scrum reiniciado

entre cada sprint
Um quadro kanban continua
Prescreve um product backlog

priorizado
Priorizao opcional.
Ento isso. Agora voc sabe as diferenas.
Mas ainda no acabou, agora a melhor parte!

Prepare-se, hora de colocar a mo na massa com
Mattias e ver como isso na prtica!

de ambos| 83
Parte II Estudo de caso

Kanban na vida real
Esta a histria de como ns aprendemos a melhorar usando

Kanban. Quando comeamos, no havia muita informao
disponvel e o Dr. Google naquela poca nos deixou de mos
vazias. Hoje, Kanban est evoluindo com sucesso e h um
emergente campo de conhecimento. Eu claramente
recomendo que dem uma olhada no trabalho de David
Anderson, por exemplo, em classes de servio. Ento, esta
a primeira (e ltima) concesso (eu prometo!).
Independentemente da soluo que voc implementar,
certifique-se de que ela resolve seus problemas especficos. E
pronto. Vamos chegar l. Ento, essa nossa histria.
Mattias Skarin
A natureza das operaes tcnicas|

84
17
A natureza das operaes
tcnicas
Se voc nunca ficou disponvel 24/7, voc tem apenas uma
leve idia do sentido de responsabilidade ao gerenciar um
ambiente de produo.
Esperam que voc resolva a situao no meio da noite,
independentemente de voc ser ou no a origem do problema.
Ningum sabe, por isso que eles te ligam. um grande
desafio porque voc no criou o hardware, os drivers, o S.O
ou o software customizado.
Suas opes muitas vezes limitam-se a reduzir o problema,
reduzindo o impacto e salvando as evidncias necessrias
para recriar o problema, e esperar que a pessoa responsvel
por causar aquilo consiga reproduzir e resolver o que voc
acabou de testemunhar.
Para as operaes tcnicas, a capacidade de resposta e
resoluo de problemas com rapidez e preciso so
fundamentais.
84

de ambos | 85
18
Por que diabos mudar?
Em 2008, um de nossos clientes, uma organizao de
desenvolvimento de jogos escandinava, trabalhou em uma
srie de melhorias de processo. Uma delas incluiu escalar
Scrum para a organizao de desenvolvimento e,
gradualmente, remover os impedimentos que no permitiam
que as equipes de desenvolvimento entregassem software.
Por que diabos mudar? | 86

medida que o software comeou a fluir e o desempenho
melhorou, esta presso aumentada voltou-se para as equipes
tcnicas de operaes.
Antes, as equipes de operaes estavam normalmente
margem; agora, elas estavam se tornando cada vez mais
envolvidas, como parte ativa do processo de
desenvolvimento.
Figura 1. A organizao das operaes tcnicas incluiu trs equipes, os

engenheiros de bancos de dados (DBAs), os administradores de sistemas e o
suporte de segundo nvel.

de ambos| 87
Portanto, ajudar a equipe de desenvolvimento no foi
suficiente.
Se ns tivssemos nos concentrado apenas nas equipes de
desenvolvimento isso teria causado atrasos em importantes
melhorias de infra-estrutura que eram executadas pelas
equipes de operaes tcnicas. Melhorias nas duas reas eram
necessrias.
Alm disso, o progresso nas equipes de desenvolvimento
significou que os gerentes fossem cada vez mais requisitados
a ajudar com anlises e sugestes sobre as idias. Significou
que eles tiveram menos tempo para a priorizao das tarefas
em tempo real e para soluo de problemas.
A equipe de gerenciamento percebeu que eles precisavam agir
antes que a situao ficasse fora de controle.
Por onde comeamos? | 88
19
Por onde comeamos?
Um bom ponto de partida foi perguntar s equipes de
desenvolvimento, quem eram os clientes de operaes
tcnicas.
Opinio dos Desenvolvedores sobre

Operaes
Perguntei Quais so as trs coisas mais importantes que vem
na sua cabea quando voc pensa em Operaes? As
repostas mais comuns foram:
Conhecimento Varivel
O sistema de workflow
deles pssimo
Muito competentes quando o

assunto infra-estrutura
O que os caras esto

fazendo?
Eles querem ajudar, mas, na

verdade, conseguir ajuda difcil
So necessrios muitos emails para coisas simples
Projetos demoram muito
Dificuldade para entrar em

contato
Em resumo, essa era a opinio dos desenvolvedores sobre

operaes. Agora, vamos comparar isso com a opinio de
operaes sobre desenvolvimento.

de ambos| 89
Opinio de Operaes sobre

Desenvolvimento
Porque voc no est usando as vantagens da plataforma?

Vamos fazer dos releases um assunto mais leve!
A sua pssima qualidade nos prejudica!
Eles tm que mudar foi um tema comum na
argumentao de ambos os lados. Obviamente o esprito
precisaria mudar se quisssemos nos mexer para solucionar
problemas comuns. Do lado positivo; Muito competentes
quando o assunto infra-estrutura (indica confiana no
ncleo da confiana) me fez acreditar que a mentalidade ns
VS eles podia ser resolvida se crissemos as condies de
trabalho certas. Eliminar excesso de trabalho e concentrar-nos
em qualidade foi uma opo vivel.
Comeando| 90
20
Comeando
Ento ns precisvamos comear, mas por onde? A nica
coisa que sabamos ao certo era: onde quer que comecemos,
no ser onde iremos terminar.
Meu conhecimento o de um desenvolvedor ento eu
certamente sabia pouco sobre a natureza das operaes. Eu
no estava a ponto de explodir e comear a mudar tudo. Eu
precisava de uma abordagem menos confrontadora que,
entretanto, pudesse nos ensinar coisas relevantes, descartar as
irrelevantes, e que fosse fcil de aprender.
Os candidatos eram:
Scrum que vinha funcionando bem com as equipes
de desenvolvimento.
Kanban novo & no testado, mas com boa
adaptabilidade aos princpios Lean que nos faltavam.
Nas discusses com os gerentes, Kanban e os princpios de
Lean pareciam se encaixar nos problemas que estvamos
tentando resolver. Do ponto de vista deles, sprints no se
encaixariam muito bem porque estavam tendo que fazer
novas priorizaes diariamente. Ento, Kanban foi o ponto de
partida mais lgico, mesmo sendo algo completamente novo
para ns.

de ambos| 91
21
Iniciando os times
Como iniciamos os times? No existia manual sobre como
fazer isto acontecer.
Fazer de forma errada era arriscado demais. Fora perder as
oportunidades de melhoria, ns ramos ns lidando com uma
plataforma de produo com pessoal altamente especializado
e habilidoso; difceis de serem substitudas. Deixar eles
alienados era uma idia ruim.
Ns deveramos iniciar? E aceitar as conseqncias

conforme elas aparecem?
Ou deveramos executar um treinamento primeiro?
Era bvio para ns deveramos realizar o treinamento certo?

Mas como? Era um desafio conseguir todo o time tcnico de
operao participando do treinamento (quem iria atender se
algum ligasse?).
No final decidimos fazer um treinamento com meio dia de
durao, mantendo simples e baseado em exerccios.
O workshop
Um dos benefcios do workshop foi que ajudou a trazer tona
nossos problemas cedo. Tambm proporcionou um ambiente
de alta confiana onde as complicaes puderam ser
discutidas diretamente com os membros do time.
Iniciando os times| 92
Quero dizer, vamos enfrentar isso nem todos estavam muito
interessados em mudar a atual forma de trabalhar. Mas a
maioria dos membros do time estava aberta a tentar.
Ento executamos a oficina demonstrando os princpios mais
importantes e fizemos uma simulao de Kanban em escala
reduzida.
No final do workshop fizemos uma votao para verificar se

os times estavam dispostos a tentar isso de verdade. Sem
objees neste ponto, pudemos seguir em frente.

de ambos| 93
22
Lidando com partes interessadas
Era de se supor que as partes interessadas tambm seriam
igualmente afetadas por uma implementao Kanban.
Entretanto as mudanas devem ser para melhor isso
significa que a equipe deve comear a dizer no a trabalhos
que no tem como concluir, a atentar para a qualidade e
remover todas as coisas no prioritrias do backlog da equipe.
Apesar disso, ter uma discusso antes sempre uma boa
idia.
As partes interessadas mais prximas so o pessoal do suporte
de primeiro nvel e os gerentes de departamento. Uma vez
que eles estejam participando de todo o processo, eles j esto
dando seu aval para o desenvolvimento do produto. Mesmo
para as equipes de desenvolvimento (que j estavam mesmo
esperando melhorias de qualquer maneira). Mas, para uma
equipe em particular a equipe de suporte as coisas so
diferentes. O problema mais significativo era que eles
estavam sobrecarregados de trabalho. Alm disso, eles lidam
diretamente com demandas de problemas do cliente e a
empresa tem o compromisso de responder a todas as
demandas. Agora isto estar prestes a mudar se
implementarmos Kanban e comearmos a impor limites para
a quantidade de trabalho em andamento.
Lidando com partes interessadas|

94
Ento, fizemos uma jornada com as principais partes

interessadas e lhes apresentamos as nossas intenes, os
benefcios esperados e as possveis conseqncias. Para meu
alvio, nossas idias em geral foram bem recebidas, algumas
vezes com uma observao do tipo seria timo se finalmente
pudssemos dar um tempo com esse monte de demandas.
94

de ambos| 95
23
Construindo o primeiro quadro
Uma boa forma de iniciar a construo de um quadro Kanban
fazendo o mapa de fluxo de valor.
basicamente uma visualizao da cadeia de valor e
proporciona compreenso sobre os estgios de trabalho, fluxo
e tempo atravs do sistema (tempo de ciclo).
Mas iniciamos de modo muito mais simples; um quadro

Kanban desenhado e papel junto com o gerente. Revisamos
umas duas vezes e ento seguimos em frente.
Construindo o primeiro quadro |

96
As questes que surgiram nessa fase foram:
Quais tipos de trabalho tm aqui?
Quem cuida disso?
Devemos dividir as responsabilidades conforme os

diferentes tipos de trabalho?
Como
lidamos
com
responsabilidades
compartilhadas tendo habilidades especficas?
J que os diferentes tipos de trabalho tinham diferentes

acordos de nvel de servio, foi natural deixar que cada
equipe controlasse a elaborao de seu quadro. Eles mesmos
fizeram as colunas e as linhas.
A prxima grande deciso foi se usaramos responsabilidade
compartilhada conforme os diferentes tipos de trabalho.
Deveramos deixar uma parte fixa de a equipe lidar com
questes diretas (trabalho reativo) e deixar o resto da equipe
concentrada nos projetos (trabalho proativo) Decidimos tentar,
inicialmente, a responsabilidade compartilhada.
A razo principal foi identificarmos que auto-organizao,
aprendizagem constante e transferncia de conhecimento pelos
membros da equipe seriam essenciais para manter o crescimento.
A desvantagem dessa deciso seria potenciais problemas para
todos, mas esta foi melhor soluo que pudemos encontrar para
comear.
Uma pequena nota: quando fizemos o workshop, as equipes de
fato se auto-organizaram a partir deste problema. Eles deixaram
uma pessoa lidar com as requisies imediatas e o resto tratou
das questes maiores.

de ambos| 97
O primeiro modelo Kanban

Abaixo est o modelo bsico que usamos para Kanban. Note
que a equipe decidiu deixar os itens em fluxo ascendente
(como bolhas na gua) em vez do modelo mais tpico, de
fluxo da esquerda para a direita.
Figura 2. Este o primeiro modelo para Kanban. Prioridades seguem da esquerda

para a direita e o fluxo de baixo para cima. Atividades em andamento, contadas
como nmero total de tarefas na linha atividades em andamento (circulada em
vermelho). Modelo influenciado por experincias relatadas por Linda Cook.
Figura 3. Primeiro quadro Kanban para administrao de equipe.
Construindo o primeiro quadro |

98
Linhas usadas
Estado de workflow (linha)

Backlog
Atividades prontas para serem
iniciadas
Atividades em andamento
Done
Como definimos
Histrias que o gerente decide como
necessrias.
Histrias so estimadas e divididas em
tarefas de at, no mximo, 8 horas.
A linha que contm a quantidade de
tarefas em andamento. Comeamos
com um limite de 2x o tamanho da
equipe -1 (um a menos para
colaborao). Ento, para uma equipe
de 4 pessoas, a quantidade de tarefas
em andamento seria de 7.
Executvel pelo usurio.
Colunas utilizadas
Tipo de trabalho
Lanamento de verso
Suporte
No planejado
Projeto A
Projeto B
Como definimos
Ajudar as equipes de desenvolvimento
a fazer lanamentos de verses do
software
Requisies menores vindas de outras
equipes.
Trabalho no antecipado que precisa
ser feito, mas que no tem um
responsvel definido. Por exemplo,
melhorias tpicas em infra-estrutura.
Projeto
de
grande
enfoque
tecnolgico, por exemplo, mudanas
de hardware em um ambiente de teste.
Outro grande projeto.
Nem todos os quadros Kanban se parecem. Tudo comea com

um desenho simples que evolui ao longo do tempo.

de ambos| 99
24
Definindo o primeiro limite de WIP
Nossa primeira definio para o limite de atividades em
andamento (WIP) foi bem generoso. Decidimos isso ao
visualizar o fluxo que teramos e fomos experimentando a
partir dali. Era pouco provvel que tivssemos como prever o
limite ideal desde o incio. Com o passar do tempo, iramos
ajustando os limites da quantidade de atividades em
andamento (WIP) toda vez que encontrssemos uma boa
razo para isso (tudo o que precisvamos fazer era indicar o
valor no quadro).
A primeira quantidade de atividades em andamento (WIP)
que utilizamos foi 2n-1 (n = nmero de membros na equipe, 1 para encorajar a cooperao). Por qu? Simplesmente
porque no tnhamos uma idia melhor . Tambm no havia
por que no comear desta forma. A frmula oferecia uma
explicao simples e lgica a todos que tentavam empurrar
uma tarefa para a equipe: ... ento, dado que cada membro
da equipe s podia trabalhar em, no mximo, duas tarefas ao
mesmo tempo, uma ativa e outra aguardando, como
poderamos esperar que pegassem mais tarefas ainda?
Agora, olhando para trs, qualquer limite generoso teria
funcionado para os iniciantes. Ao monitorar o quadro Kanban
fica fcil descobrir os limites adequados ao longo do tempo.
Definindo o primeiro limite de

WIP| 83
Figura 4. Como aplicamos o limite da quantidade de atividades em andamento

para as equipes de DBA e administrao de sistemas, um limite conforme o tipo
de trabalho.
Uma observao que fizemos foi que era intil definir o limite
da quantidade de atividades em andamento em pontos da
histria.
Era muito difcil de acompanhar o andamento das atividades.
O nico limite suficientemente fcil de acompanhar era
simplesmente contar a quantidade de itens (= tarefas
simultneas).
Para a equipe de suporte utilizamos atividades em andamento
(WIP) definidas por coluna. Isto porque ns precisvamos
reagir mais rpido caso o limite estivesse sendo excedido.

de ambos| 101
25
Honrando o limite de WIP
Enquanto o respeito ao limite de WIP parece fcil na teoria,
um acordo difcil de honrar na prtica. Significa dizer no
em algum momento. Tentamos vrias abordagens para lidar
com isso.
Discusso no quadro
Se um descumprimento do acordo fosse descoberto,
deveramos trazer a parte interessada at o quadro e perguntar
o que ele quis obter. A princpio, a razo mais freqente para
o descumprimento era simplesmente a inexperincia. Em
alguns casos encontramos diferentes vises na priorizao.
Um caso tpico seria o membro de uma equipe especialista
trabalhando em uma rea especfica. Essas foram as nicas
vezes em que tivemos atrito. Na maioria das vezes os
problemas foram resolvidos imediatamente conversando em
frente ao quadro.
Designando uma seo de transbordo

Se dizer no fosse muito conflitante, e remover os itens
fosse muito difcil, ns movamos os itens de baixa prioridade
para uma seo de transbordo4 no quadro quando os limites
N.T.: Overflow
Honrando o limite de WIP| 85

de WIP eram ultrapassados. Duas regras so aplicadas s
tarefas da seo de transbordo:
1. Elas no foram esquecidas, quando tivermos tempo
iremos lidar com elas.
2. Se ns as cortarmos, voc ser informado.
Depois de apenas duas semanas ficou bvio que os itens
excedentes no seriam tratados. Ento, com o apoio do
gerente da equipe, eles puderam finalmente ser removidos.
Figura 5. Um esboo do quadro do kanban da equipe de suporte, com a seo de

transbordo bem direita.

de ambos | 85
26
Quais tarefas vo para o quadro?
Havamos decidido no colocar no quadro todo o trabalho
feito pela equipe. Monitorar coisas como uma ligao
telefnica ou pegar caf deixaria o quadro Kanban um
monstro administrativo. Ns estvamos aqui para resolver
problemas, no criar problemas . Ento decidimos colocar
no quadro somente tarefas com tamanho > 1 hora; qualquer
coisa menor seria considerada rudo branco. O limite de 1h
realmente funcionou muito bem e foi uma das poucas coisas
que no foram modificadas. (Tivemos que revisar a premissa
sobre o impacto que o rudo de fundo tinha, mas mais
posteriormente).
Figura 6. Ns comeamos assumindo que a capacidade total era consumida

principalmente por dois tipos de trabalho: maiores (projetos) e menores (suporte).
Acompanhar a velocidade nos projetos poderia nos dar uma indicao da data de
entrega, caso isso fosse necessrio. Rudo branco (suporte pequeno < 1h,
reunies, pegar caf, auxiliar os colegas) sempre era esperado.
Como estimar? | 104
27
Como estimar?
Este um tpico em discusso; e certamente h mais de uma
resposta:
Estimar regularmente.
Estimar quando necessrio.
Usar estimativas em dias / pontos da histria.
Estimativas so incertas. Use os tamanhos de

camiseta (pequena, mdia, grande)
No faa estimativas ou as faa s quando existir

um custo, devido a atrasos, que justifique isso.
Ligeiramente influenciados pelos Scrum (j que foi onde tudo

comeou, afinal) ns decidimos comear com pontos da
Histria. Mas, na prtica, as equipes tratavam os pontos da
histria de forma equivalente a homem-hora (parecia mais
natural para eles). Inicialmente todas as histrias eram
estimadas. Com o passar do tempo, os gerentes aprenderam
que, se mantivessem um nmero baixo de projetos,
simultaneamente, eles no deixariam as partes interessadas
esperando. Aprenderam tambm que, no caso de uma
mudana repentina, eles poderiam prioriz-la novamente e
solucionar o problema.
A necessidade de projetar uma data de entrega j no era mais
um grande problema. Isto levou os gerentes a pararem de

de ambos | 88
pedir estimativas antecipadas. Eles s as pediam se temessem
que manteriam as pessoas esperando.
H algum tempo atrs, um gerente, estressado com um
telefonema, prometeu entregar o projeto at o final desta
semana. Sendo este um projeto com quadro Kanban, foi
fcil estimar o andamento do trabalho (contando as histrias
prontas) e concluir que ele s estaria cerca de 25% concludo
aps uma semana. Desta forma, mais trs semanas seriam
necessrias. Confrontado com os fatos, o gerente mudou a
prioridade do projeto, interrompeu os trabalhos simultneos
e tornou a entrega possvel. Sempre verifique o quadro
O que o tamanho estimado significa?

Lead time ou tempo de trabalho?
Nossos pontos da histria refletem tempo de trabalho, i.e.,
quantas horas de esforo ininterrupto esperamos que esta
histria leve; e no tempo de planejamento (lead time - ou
tempo de cronograma, ou quantas horas de espera). Ao medir
o nmero de pontos por histria que ficam prontos a cada
semana, (velocidade) pudemos deduzir o tempo gasto com
planejamento (lead time).
Ns estimamos cada nova histria apenas uma vez, no
revisamos as estimativas de histrias durante sua execuo.
Isto nos permitiu minimizar o tempo da equipe gasto com
estimativas.
Ento, como que trabalhamos,

realmente?| 106
28
realmente?
Na realidade, o Kanban muito livre. Voc pode trabalhar de
diversas maneiras. Pode deixar a equipe trabalhar de acordo
com as atividades agendadas, ou pode escolher trabalhar em
atividades quando houver a motivao necessria que as
justifique.
Figura 7. Quando trs tarefas chegam ao backlog, isso provoca um evento de

planejamento/estimativa.
Ns optamos por agendar dois eventos recorrentes:

Reunio diria em p com a equipe em
frente ao quadro, para trazer problemas tona e

de ambos | 107
ajudar a criar a viso em partes das tarefas de
outros membros da equipe.
Planejamento de iterao semanal, para fins
de planejamento e melhoria contnua.
Isso funcionou bem para ns.
Reunio diria em p
A reunio diria em p era similar a Daily Scrum. Acontecia
depois da reunio de Scrum de Scrums, com participao
de todas as equipes (Desenvolvimento, Testes, Operao). A
reunio de Scrum de Scrums trazia informaes importantes
para as equipes Kanban como, por exemplo, que problemas
deveriam ser encaminhados primeiro, ou qual equipe de
desenvolvimento estava sofrendo mais no momento.
Inicialmente, os gerentes participavam com freqncia destas
reunies, propondo solues e priorizando decises. Ao longo
do tempo, conforme as equipes foram melhorando a autoorganizao, os gerentes passaram a freqent-las menos
(mas no estavam longe, caso a equipe precisasse).
Planejamento da iterao

realmente?| 108
Uma vez por semana, ns organizamos um planejamento de
iterao. Ns o mantivemos, semanalmente, em um horrio
fixo, porque descobrimos que, se no fosse planejado, o
horrio seria consumido por outras prioridades . E ns
precisvamos de mais conversas entre as equipes. Uma
agenda tpica era:
Atualizar quadro e grficos. (Projetos Prontos eram

movidos para um Quadro dos Prontos.)
Olhe para a semana passada. O que aconteceu?

Porque aconteceu assim? O que pode ser feito para
melhorar?
Reajustes do limite de atividades em andamento

(WIP), se necessrio.
Quebra de tarefas e estimativas de novos projetos [se

houver necessidade para isto].
Basicamente, o planejamento da iterao foi uma combinao

de estimativa e impulso por melhoria contnua. Problemas
qualificados como pequenos e mdios foram resolvidos na
hora, com o suporte dos gerentes de linha. Mas, mantendo o
foco nos mais complexos, questes de infra-estrutura foram
um martrio. Para lidar com isso ns habilitamos as equipes a
apontarem at 2 impedimentos da equipe aos seus gerentes.
As regras eram:
1. Os
gerentes
podem trabalhar
em at 2 slots ao
mesmo tempo.
2. Caso
ambos
estejam cheios,
voc
pode
adicionar
um
novo, desde que

de ambos | 109
remova o menos importante.
3. As equipes decidem quando o problema est
resolvido.
Essa mudana foi positiva. Rapidamente as equipes puderam

ver que os gerentes estavam trabalhando para ajud-las, at
mesmo nas questes mais difceis. Elas podiam apontar para
os impedimentos e perguntar qual o andamento deste
assunto? Eles no seriam esquecidos ou anulados por uma
nova estratgia de alta prioridade.
Um exemplo de impedimento grave era que os operadores
no tinham o suporte necessrio que precisavam dos
desenvolvedores quando eles suspeitavam de uma falha (bug).
Eles precisavam de ajuda para descobrir qual parte do sistema
havia causado o problema, mas como os desenvolvedores
estavam ocupados desenvolvendo coisas novas do sprint, os
problemas continuavam a se acumular. No causou surpresa
os operadores sentirem que os desenvolvedores no se
importavam suficientemente com a qualidade.
Quando esse impedimento apareceu, ele foi escalado
primeiramente para o gerente de linha e, em seguida, para o
gerente de departamento. Este agendou uma reunio
juntamente com o lder de desenvolvimento. Nas discusses
seguintes, os gerentes concordaram em priorizar a qualidade.
Eles criaram uma soluo de suporte rotativo a cada sprint,
uma equipe de desenvolvimento deveria ficar de planto e
disponvel, instantaneamente, para ajudar nas operaes.
Depois de garantir o suporte de seus gerentes, o lder de
desenvolvimento pegou uma lista de contatos das pessoas das
equipes de suporte. Imediatamente, eles testaram a soluo,
pensando que o plano no funcionaria. Mas, desta vez, o
dever de casa foi levado a srio e o impedimento considerado
resolvido. Esse fato trouxe grande segurana s equipes de
operaes.
Encontrando um conceito de
planejamento que funcione| 110
29
planejamento que funcione
Uma Histria
Lembro-me de um momento importante para uma das
equipes. Eu estava sentado com eles na segunda sesso de
estimativa. A equipe estava travada com um projeto sem
saber como estimar. Havia muitas dvidas e toda a sesso de
estimativa ficou parada. Ao invs de interferir e assumir o
controle, eu pedi a eles que refinassem o processo para
encontrar uma soluo melhor. Liderados pelo gerente, eles
aceitaram o desafio e comearam a projetar uma soluo
prpria. Esse evento foi um momento decisivo, uma vitria
importante a partir do qual eles se transformaram em uma
equipe com confiana. Depois disso eles comearam a
evoluir to rapidamente que ns tivemos que sair do
caminho.
Dois meses depois, o gerente me abordou aps uma
retrospectiva. Eu tenho um problema, disse ele, apontando
para o quadro do Kanban da equipe. Ns no temos
problemas reais, o que eu devo fazer?

de ambos | 111
Reinventando o planejamento
As sesses de estimativa com Planning Poker envolvendo
todos os membros da equipe no funciona bem para todos as
equipes de operaes. Eis algumas razes:
O conhecimento foi difundido muito uniformemente

na equipe.
Freqentemente apenas uma pessoa estava falando.
Os membros da equipe queriam atacar problemas

urgentes que pipocavam em suas mesas.
Mas,
por
experimentao,
as
equipes
vieram,
independentemente, com dois processos de estimativa
diferentes. Cada um funcionou bem para a respectiva equipe.
Abordagem 1 - Troca e reviso
Para cada projeto/histria, associe um par snior +

jnior para fazer as estimativas (i.e., uma pessoa que
conhea bem a histria e uma que no a conhea).
Isso ajuda a difundir o conhecimento.
Os demais membros da equipe escolhem qual

histria eles querem ajudar a estimar (mas com o
limite de quatro pessoas por histria, para manter as
discusses efetivas).
planejamento que funcione| 112
Cada equipe de estimativa quebra suas histrias em

tarefas e, se necessrio, estima tambm as tarefas.
Ento as equipes trocam histrias e fazem reviso

umas das outras (uma pessoa de cada equipe
permanece nos bastidores para explicar o trabalho
de sua equipe para os revisores).
Pronto!
Normalmente todo um ciclo de uma sesso de planejamento

levou cerca de 45 minutos e o nvel de energia permaneceu
alto ao longo da reunio. 1 ou 2 ajustes ainda foram feitos a
partir desta troca e reviso de histrias.

de ambos | 113
Abordagem 2 avaliao snior em

alto nvel,
e ento a estimativa
Dois membros seniores do time fazem uma reviso de alto
nvel da histria/projeto antes do planejamento. Eles devem
analisar solues de arquitetura e escolher uma delas para o
problema. Uma vez em acordo, o time deve entrar e quebrar a
histria/projeto em tarefas, usando a soluo proposta como
um ponto de partida.
Figura 8. Quebra de tarefas com peer-review por outro time no planejamento da

iterao.
O que medir? | 114
30
O que medir?
H muitas coisas que podem ser medidas - o ciclo de tempo
(tempo que leva da descoberta da necessidade at que ela seja
satisfeita), velocidade, filas, burndowns. A questo
importante que as mtricas podem ser usadas para melhorar
o processo. Meu conselho experimentar e ver o que
funciona para voc. Aprendemos que grficos burndown
foram um exagero para alguns projetos mais curtos do que 14 semanas. A base do progresso poderia ainda ser avaliada
com uma olhada para o quadro Kanban (quantas histrias
estavam no backlog e quantas foram feitas).
Mtrica candidata
Tempo de Ciclo
Pr
Fcil de medir. No
necessita de
estimativa. Comea e
termina com cliente.
Contra
No leva tamanho em
considerao.
Velocidade Total
(agregada atravs de
todos os tipos de
trabalho)
Um fcil e grosseiro
indicador para
direcionar melhoria e
variao.
No ajuda a prever datas

de entrega para tipos de
trabalho especficos.

de ambos | 115
Velocidade por tipo
Mais precisa que

velocidade total.
Comprimento de
Fila
Um rpido indicador
de flutuao de
demanda.
Fcil de visualizar.
Para ser til, deve

iniciar de uma
necessidade de cliente
at a entrega.
Toma um pouco mais de
tempo para rastrear
comparada velocidade
total.
No informa se a causa
demanda desigual ou
capacidade desigual.
Uma fila zerada pode
indicar na realidade uma
sobrecarga.
Ns comeamos medindo a velocidade por tipo de trabalho

e o tamanho das filas. A velocidade por tipo de trabalho
simples de medir e faz o trabalho. Os tamanhos das filas so
bons
indicadores
desde
que
sejam
mostrados
instantaneamente (se voc souber onde procur-los).
Figura 9. Gargalos e oportunidades. A rea vermelha mostra como as filas se

desenvolveram, mostrando um gargalo de teste. A falta de uma fila na coluna de
backlog de suporte indica que novos trabalhos de suporte no podem esperar.
Isso um bom sinal para um alto nvel de servio.
O que medir? | 116

Ns no usamos um diagrama de fluxo cumulativo, mas seria
interessante.
Ns no usamos diagramas de fluxo cumulativos porque o

quadro do Kanban e o grfico de velocidade j nos deram
informaes suficientes, pelo menos em nossas fases iniciais
de maturidade. Gargalos, irregularidades e excesso de
trabalho poderiam tambm ser facilmente identificados e
resolv-los nos manteria ocupados por mais seis meses.

de ambos | 117
31
Como as coisas comearam a
mudar
Trs meses depois de introduzir o Kanban, a equipe do
sistema de administrao ganhou da Direo o ttulo de
equipe com a melhor performance no departamento de TI.
Ao mesmo tempo, a equipe foi votada como umas das 3
melhores experincias na retrospectiva da companhia. A
retrospectiva da companhia um evento de toda a empresa
que acontece a cada 6 semanas, e esta foi a primeira vez que
uma equipe entrou na lista das 3 melhores! E, apenas 3 meses
antes, essa equipe havia recebido diversos tipos de
reclamaes devido a pontos de gargalo.
A qualidade do servio claramente melhorou. E como isso
aconteceu?
O momento crucial foi quando todos comearam a trabalhar
em conjunto. A Direo forneceu um foco claro e protegia a
equipe de coisas externas aos seus trabalhos, e a equipe
assumiu a responsabilidade sobre a qualidade e os prazos. Isto
levou uns trs ou quatro meses at funcionar, mas depois flua
sem problemas. No que todos os problemas tinham ido
embora (isso colocaria a todos para fora do trabalho, certo?
) mas ns encontramos novos desafios do tipo como ns
iremos manter a equipe motivada para melhorar (quando eles
no forem mais o gargalo)?.
Como as coisas comearam a mudar

| 118
Uma pea importante no quebra-cabeas da auto-organizao
foi a introduo do conceito uma pessoa de contato de
operao por time. Cada time de desenvolvimento tinha seu
prprio contato no time de operaes. O Kanban tornou isso
possvel permitindo aos membros do time se autoorganizarem ao redor do trabalho, prevenindo trabalho em
excesso e habilitando melhoria contnua. Antes, uma pessoa
qualquer do time poderia puxar trabalho da fila, e resolver, da
melhor forma, um chamado, conforme sua habilidade, e
depois iniciar o prximo. Qualquer falha de comunicao
significava iniciar tudo novamente, com um novo chamado de
suporte. Quando o conceito um ponto de contato para cada
time de desenvolvimento foi lanado, o time de suporte teve
a oportunidade de responder mais rapidamente a falhas na
entrada ou a problemas de qualidade que ameaavam o
sistema.

de ambos | 119
Curiosidade depois de algum tempo, protocolos de
comunicao evoluram; pessoas do time de operaes
comearem a usar mensagens instantneas para
desenvolvedores que eles conheciam bem, e-mails para
aqueles que escrevem melhor do que falam, e telefones, se
essa fosse a maneira mais rpida de resolver o problema .
Antes
Figura 10. Antes: Gerente de primeiro nvel o ponto de contato com o time.
Qualquer coisa importante que precise ser feita, passar por ele. Pequenas
situaes, como problemas de desenvolvedores, so recebidas por um sistema de
controle de chamados. Pouca iterao entre as pessoas ocorrendo.

| 120
Depois
Figura 11. Depois: um contato das operaes por equipe implantado. As

equipes de desenvolvimento falam diretamente com o contato das operaes
definido. Muita interao pessoa-a-pessoa. Os membros da equipe de operaes
auto-organizam o seu trabalho utilizando o quadro Kanban. O gerente volta o
foco para a priorizao de projetos maiores e fornece apoio quando problemas
maiores surgem.

de ambos | 121
Ento, qual o impacto no desempenho da equipe?
Figura 12. Velocidade total e velocidade do projeto, medidos como pontos da

histria "prontos" por semana. O total a soma de todas as colunas, a velocidade
do projeto representa a parte dedicada a projetos (grandes esforos de trabalho,
por exemplo, fazer upgrade na plataforma de hardware). As duas quedas
relacionam-se a 1) uma semana em que quase todos os membros de equipes
estavam viajando e 2) uma grande release do desenvolvimento.
Assim, o time demonstrou uma tendncia positiva de forma

geral. Ao mesmo tempo, a equipe investiu pesadamente em
compartilhamento de conhecimento usando programao em
par.

| 122
Enquanto isso, vamos dar uma olhada no desempenho da
equipe;
Figura 13. Velocidade Total e pequenas tarefas de suporte. A queda bem no meio
corresponde ao Natal.
A velocidade total tende para cima embora a variao seja

significativa. O tamanho da variao inspirou a equipe a
monitorar o nmero de pequenas tarefas de suporte (tarefas
muito pequenas para serem adicionadas ao quadro Kanban).
Como voc pode notar, o grfico indica a clara correlao
inversa entre o nmero de pequenas tarefas de suporte e a
velocidade total.
A equipe de suporte comeou a usar Kanban mais tarde do
que as outras duas equipes. Ento, ns ainda no temos tantos
dados confiveis.
Aumento de maturidade
Quando comeamos, encontrar reas problemticas era fcil.
Mas achar a grande oportunidade para melhorias era difcil. O
quadro Kanban nos propiciou todo um novo nvel de
transparncia. No apenas ficou fcil apontar os problemas,
como tambm levantar questes importantes sobre fluxo,

de ambos | 123
variaes e etapas. Ns comeamos utilizando as etapas como
uma maneira para identificar problemas. Quatro meses depois
de comear a usar Kanban, os gerentes estavam procurando as
origens das variaes que prejudicavam suas equipes.
Conforme as equipes evoluam de grupos de indivduos para
unidades auto-organizveis, os gerentes perceberam que eles
estavam se deparando com um novo conjunto de desafios em
termos de liderana. Eles tinham de tratar mais com questes
em nvel pessoal lidar com reclamaes, definir objetivos
compartilhados, resolver conflitos e negociar acordos. No foi
uma transio indolor eles disseram abertamente que para
aprender a lidar com tudo isso foi necessrio muito jogo de
cintura e muita pacincia. Mas eles aceitaram o desafio e, no
fim das contas, acabaram por se tornar lderes melhores.
Lies gerais aprendidas | 124
32
Lies gerais aprendidas
medida que o trabalho em
andamento progride, limitaes
surgem
Todas as equipes comeam com limites de trabalho em
andamento bem generosos. Nesse momento, a maior parte da
energia consumida tentando criar fluxo e garantindo que a
organizao esteja obtendo o suporte de que necessita.
No comeo, os gerentes queriam ter vrios projetos em
execuo simultaneamente, mas, aps algumas semanas,
tornou-se evidente que no havia capacidade suficiente para
lidar com os projetos de baixa prioridade. Bastava uma breve
olhada no quadro para ver que nenhum trabalho sequer era
iniciado nas coisas de baixa prioridade. Isso alertou os
gerentes para reduzir o nmero de projetos por equipe.
Com o tempo, como o fluxo se tornou mais estvel para o
trabalho de alta prioridade, comeamos a estreitar os limites
do trabalho em andamento. Isso foi feito reduzindo-se o
nmero de projetos em andamento (colunas) de trs para dois
e, ento, para um. medida que isso ocorria, restries de
fora da equipe comearam a aparecer. Membros da equipe
comearam a reportar que no estavam conseguindo ajuda de
outros na equipe, de modo que os gerentes mudaram sua
ateno para lidar com isso.

de ambos | 125
Outra coisa que ficou claro foi o quanto a entrada de outras

equipes pode prejudicar o desempenho. Foi difcil manter um
fluxo adequado quando novos itens de entrada precisam
constantemente de correo.
Estes problemas no eram visveis antes de comear. A
questo foi ento que problemas deveramos atacar
primeiro - e como chegar a um consenso sobre isso. Com o
quadro Kanban, todo mundo pde ver como um problema
especfico impacta no fluxo, o que facilita obtermos o
momento certo de se lidar com as questes ao longo das
fronteiras organizacionais.
O quadro vai mudar ao longo do

tempo, no fixe o layout em ferro
Todos os quadros Kanban mudam ao longo do tempo.
Normalmente demora dois ou trs designs at que um time
ache um quadro que funcione bem. Ento, investir uma
grande quantidade de tempo no primeiro quadro ,
provavelmente, desperdcio. Tenha certeza de que voc pode
modificar a organizao do quadro de forma fcil. Ns
usamos fita preta para desenhar o layout. Estas eram fceis de
serem modificadas e poderiam funcionam bem em paredes e
quadros brancos. Outra forma de organizao que eu vi
desenhar no quadro linhas de guia com marcadores finos (mas
tenha certeza que o desenho pode ser apagado! ).

de ambos | 127
Abaixo mostrado um tpico exemplo de organizao de
layout. Prioridades mudaram freqentemente no incio ento,
para evitar ter que mover colunas inteiras de notas adesivas
para frente e para trs, o time colocou um nmero de
prioridade acima de cada coluna.
Figura 14. Kanban inicial com notas para a prioridade corrente.
No tenha medo de experimentar e

falhar
A lio que eu tirei dessa aventura que no h um ponto
final. Ns falhamos no momento em que pensamos existir
um. H somente experimentaes e aprendizado sem fim.
Nunca falhar significa no aprender. Ns falhamos inmeras
vezes no caminho (desenho ruim do quadro, estimativas,
burndowns redundantes...) mas cada vez ns aprendemos
algo novo e importante. Se tivssemos parado de tentar, como
poderamos ento estar aprendendo?
O sucesso do Kanban tem agora inspirado as equipes de
gerncia e de desenvolvimento Scrum a iniciarem
experimentaes com quadros Kanban. Talvez esse livro
ajude!

de ambos | 129
Consideraes finais
Comece com as retrospectivas!
Muitas opes e coisas para pensar, hein? Espero que esse
livro tenha ajudado e esclarecer um pouco do nevoeiro. Pelo
menos funcionou para ns. :o)
Se voc est interessado em mudar e melhorar o seu processo,
vamos tomar uma deciso para voc agora mesmo. Se voc
no estiver fazendo retrospectivas regularmente, comece por
elas! E tenha certeza de que elas levem a uma mudana de
verdade. Traga um facilitador se necessrio. Assim que voc
tiver estabelecido retrospectivas eficazes, voc ter comeado
sua jornada de evoluo rumo ao processo certo para o seu
contexto seja ele baseado em Scrum, XP, Kanban, uma
combinao deles ou qualquer outra.
Consideraes finais | 130
Nunca pare de experimentar!

Kanban ou Scrum no so o objetivo; aprendizado contnuo .
Uma das melhores coisas sobre software o ciclo curto de
feedback, que a chave para o aprendizado. Portanto, use o
ciclo de feedback! Questione tudo, experimente, falhe,
aprenda e ento experimente novamente. No se preocupe em
acertar desde o comeo, porque voc no acertar! Apenas
comece em algum ponto e evolua a partir de l.
A nica falha real a falha em aprender com a falha.
Mas espere, voc pode aprender com isso tambm
Boa sorte e curta a viagem!
/Henrik & Mattias, Estocolmo 24/06/2009

de ambos | 131
H: Isso tudo o que temos?

M: Eu acho que sim. Vamos parar por aqui.
H: Talvez devamos contar a eles que somos?
M: Boa observao. Se fizermos parecer que somos caras
legais, talvez possamos fazer consultorias.
H: Vamos fazer isso, ento! E ento paramos por aqui.
M: Sim, ns temos trabalho a fazer, e os leitores tambm.
H: Na verdade, minhas frias comeam agora :o)
M: Ei, no esnoba.

de ambos| 132
Sobre os autores
Henrik Kniberg e Mattias Skarin so consultores da Crisp em
Estocolmo. Eles gostam de ajudar empresas a terem sucesso
tanto no lado tcnico quanto no lado humano do
desenvolvimento de software e j ajudaram dzias de
empresas a colocar em funcionamento princpios de Lean e
metodologias geis.
Henrik Kniberg
Durante a ltima dcada Henrik foi o CTO de 3 empresas
de TI suecas e ajudou muitas mais a melhorar seus
processos. Ele Certified Scrum Trainer e trabalha
regularmente com pioneiros de Lean e Agile como Jeff
Sutherland, Mary Poppendieck e David Anderson.
O livro anterior de Henrik (Scrum e XP direto das
Trincheiras) tem mais de 150.000 leitores e um dos livros
mais populares sobre o tema. Ele recebeu o prmio de melhor
palestrante em vrias conferncias internacionais.
Henrik cresceu em Tquio e agora vive em Estocolmo com
sua esposa Sophia e trs filhos. Ele msico nas horas vagas,
compondo msicas e tocando baixo e teclado em bandas
locais.
henrik.kniberg<at>crisp.se
http://blog.crisp.se/henrikkniberg
http://www.crisp.se/henrik.kniberg
Sobre os autores | 114

Mattias Skarin
Mattias trabalha como consultor Lean ajudando empresas
de Software a aproveitarem os benefcios do Lean e do
Agile. Ele assessora todas as camadas da organizao, dos
desenvolvedores aos gerentes. Ele ajudou uma empresa de
jogos a reduzir o tempo de desenvolvimento de um jogo de
24 para 4 meses, recuperou a confiana de todo o
departamento de desenvolvimento e foi um dos primeiros
pioneiros do Kanban.
Como empreendedor, ele co-fundador e administra duas
empresas.
Mattias graduado Mestre da Cincia em Gesto da
Qualidade e trabalhou como desenvolvedor por 10 anos em
sistemas de misso crtica.
Ele vive em Estocolmo e gosta de danar rock and roll, correr
e esquiar.
mattias.skarin<at>crisp.se
http://blog.crisp.se/mattiasskarin
http://www.crisp.se/mattias.skarin

de ambos| 134
Glossrio
Nesta traduo, mantivemos alguns termos em ingls, pois
estes j fazem parte do vocabulrio dos trabalhadores da rea.
Caso no tenha familiaridade com os termos e expresses,
pode consultar as breves definies apresentadas abaixo. Em
caso de mais alguma dvida, no exite em nos enviar um email com sua requisio para que ela seja acrescentada nas
prximas revises.
Termo em Ingls
Significado
Acceptance Test
Teste de aceitao ou teste funcional
Burndown chart
Grfico de burndown: grfico que

apresenta referncia de trabalho
estimado para uma iterao,
visualmente informando se os
objetivos estimados tm tendncia
de serem cumpridos ou no. Taxa
de queima.
Daily Standup / Daily Scrum
Reunio diria, muitas vezes feita de

p para no se alongar muito.
Deploy
Montado / Instalado
Done
Pronto, forte conceito proveniente

do Scrum.
Story Points
Pontos da histria (User Story),

unidade usada para estimar histrias
de usurio.
Kanban
Quadro de sinalizao, tambm

uma metodologia gil.
Lean
Enxuto, Lean Manufacturing

proveniente do Modelo Toyota de

de ambos| 135
Produo, dele foi originada a Lean
Software
Development,
uma
metodologia gil
Live!
Vivo! Em produo! Funcional!
MMF (Minimum marketable feature

set)
Conjunto mnimo
funcionalidades.
Ongoing
Iniciado
Peer-Review
Reviso por pares
Product Backlog
Pilha priorizada de funcionalidades,

um artefato do Scrum.
Release
Entrega
Scrum
Metodologia gil
ScrumMaster
Lder da equipe Scrum
Sprint
Iterao Scrum
aceitvel
de

de ambos| 136
Sprint Backlog
Pilha de funcionalidades priorizada,

proveniente do product backlog,
mas visando o escopo apenas de um
sprint.
Stakeholder
Parte interessada
Sticky Note
Nota Adesiva, Nota Colante, Post-It
Team
Time ou Equipe
Timebox
Durao fixa, determinada, forte

conceito Scrum
Value Stream Map
Mapa de fluxo de valor, ferramenta

muito utilizada no Lean
Work-in-Progress (WIP)
WIP Atividades (ou trabalho) em

andamento
Workflow
Fluxo de trabalho
Workshop
Oficina

de ambos| 137
Sobre a traduo
Este livro foi traduzido voluntariamente por brasileiros, nas
mais diversas funes, com os mais diversos conhecimentos
das lnguas cujo nico interesse foi o de disseminar e
popularizar as metodologias geis
Coordenao
Renato Willi
renato.willi@gmail.com
Vinicius Assef
viniciusban@gmail.com
Reviso
Caso o leitor encontre algum erro ou falha, ou queira fazer
uma reviso completa da traduo do livro, entre em contato
com um dos coordenadores para enviar sua reviso e ter seu
nome registrado aqui.
Verso 1.0
Adriana Luppi
dirsluppi@hotmail.com
Daniel Wildt
dwildt@gmail.com
Rafael Fuchs
rafaelfuchs@gmail.com
Vinicius Assef
Paulo Victor G. Gross de Souza pvggds@gmail.com

de ambos| 138
Ilustraes
Eduardo Bobsin Machado
eduardo.bobsin@gmail.com
Renato Willi
Vitor Machel
invasao@gmail.com
Traduo
Juliana Berossa Steffen
julianaberossa@gmail.com
Marcelo Andrade
mfandrade@gmail.com
Eduardo Bobsin
eduardo.bobsin@gmail.com
Rodrigo Russo
rodrigozrusso@gmail.com
Daniel Wildt
dwildt@gmail.com
Luciano Costa
lucianocosta.info@gmail.com
Renato Willi
Marcos Vincius Guimares marcosvafg@gmail.com

Adam Brandizzi
brandizzi@gmail.com
Andr Pantalio
andre0610@gmail.com
Cssio Marques
cassiommc@gmail.com
Ismael Stahelin
nilehats@gmail.com
Rafael Fuchs
rafaelfuchs@gmail.com
Gerson Dias
gerson.dias.job@gmail.com
Ian Gallina
ian.gallina@gmail.com

de ambos| 139
Rafael Dantas
rafaeldantas@gmail.com
Vitor Machel
invasao@gmail.com
Vinicius Assef
Bruno Pedroso
brunopedroso@gmail.com
Cassiano Alves
cassiano.alves@gmail.com
Gustavo Grillo
gustavogrillo@gmail.com
Igo Coelho
igocoelho@gmail.com
Rafael Prikladnicki
Adriana Luppi
rafael.prikladnicki@gmail.com
drisluppi@hotmail.com
Apoio
SEA Tecnologia
Caelum
www.seatecnologia.com.br
www.caelum.com.br/

KanbanEScrumInfoQBrasil PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

KanbanEScrumInfoQBrasil PDF

Enviado por

Direitos autorais:

Formatos disponíveis

EDIO ONLINE

Este livro distribudo gratuitamente no

Visite a pgina deste livro em:

Kanban e Scrum obtendo o melhor de

Henrik Kniberg & Mattias Skarin

2009 C4Media Inc.

No Scrum, so prescritos grficos de burndown ...................................... 68

O que medir? ......................................................................................... 114

Kanban e Scrum - obtendo o melhor

Prefcio por Mary Poppendieck

Kanban e Scrum - obtendo o melhor

Na segunda parte do livro, Mattias Skarin torna-o ainda mais

Kanban e Scrum - obtendo o melhor

Prefcio por David Anderson

Kanban e Scrum - obtendo o melhor

tradicional. Ele est sendo introduzido como parte de uma

Kanban e Scrum - obtendo o melhor

A visibilidade dos gargalos, desperdcio e variabilidade, e

Pull system, ou sistema puxado: sistema em que os times que

Kanban e Scrum - obtendo o melhor

qualidade, rapidamente desdobrada, e mantm a reunio

Kanban e Scrum - obtendo o melhor

Enquanto tudo isso se tornar evidente com explicaes

Kanban e Scrum - obtendo o melhor

A primeira implementao foi baseada na soluo do sistema

Kanban e Scrum - obtendo o melhor

2008 explicando porque o Kanban merecia ser considerado

Jim: Bom, muito melhor do que o tnhamos

Jim: ... mas voc sabe que somos uma equipe de

Jim: Bem, ns amamos toda essa coisa de

Jim: Ns continuamos falhando em nossos

E como est sendo?

Ento qual o problema?

Kanban e Scrum - obtendo o melhor

Fred: Voc poderia se comprometer com uma

Jim: Na verdade no, ns temos novos

Fred: Seus problemas levam menos de um dia

Fred: Ento sprints de um dia tambm no iriam

Jim: Bem, francamente, ns gostaramos disso.

Fred: O Scrum somente uma ferramenta. Voc

Ento o que deveramos fazer?

Voc j ouviu falar sobre Kanban?

Jim: O que isso? Qual a diferena entre isso e

Jim: Mas apesar disso, ns realmente gostamos

No, voc pode combinar as tcnicas!

No, s vezes eles levam vrios dias.

Aqui, leia este livro!

Apenas continue lendo...

Kanban e Scrum - obtendo o melhor

Propsito desse livro

Scrum em poucas palavras

Divida sua organizao em equipes pequenas,

O que so mesmo Scrum e Kanban?|

Divida o seu trabalho em uma lista de entregveis

Divida o tempo e pequenas e curtas iteraes de

Otimize o plano de entrega e atualize prioridades

Otimize o processo executando uma retrospectiva

Ento ao invs de um grande grupo gastando um monte de

O que so mesmo Scrum e Kanban?|

Kanban em poucas palavras

Visualize o fluxo de trabalho

Divida o trabalho em partes, escreva cada

Use colunas nomeadas para ilustrar onde