Kanban em 10 Passos Jesper Boeg

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

Edio e reviso final Leonardo Galvo

InfoQ Brasil, C4Media Inc. Todos os direitos reservados.

http://infoq.com/br

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

Contedo

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

Kanban em 10 Passos

!

infoq.com/br 4

Contexto e Fundamentos Antes de mergulhar no guia passo a passo de implementao do Kanban, vamos gastar alguns minutos apresentando os conceitos para que se possa reconhecer onde cada passo se encaixa no framework Kanban de gesto de mudanas. O escopo deste minilivro no descrever a fundo os conceitos do Kanban; para isto, recomendo a leitura do excelente livro "Kanban" de David J. Anderson.

Ao invs disso, fao uma pequena introduo seguida de conselhos no estilo passo a passo sobre como iniciar no Kanban.

O Kanban, ou mais precisamente o "sistema Kanban para desenvolvimento de software" representa uma implementao mais direta dos princpios de Desenvolvimento Lean de Produtos para o desenvolvimento de software que os mtodos geis tradicionais. Com foco consistente no fluxo e no contexto, o Kanban oferece uma abordagem menos prescritiva comparada ao Agile, e tem se tornado uma extenso popular dos mtodos geis tradicionais como Scrum e XP.

A palavra "Kanban" vem do japons e significa "Carto Visual". Uma pesquisa pela palavra no Google retorna mais de 5 milhes de resultados; isto porque a palavra tambm utilizada para descrever o sistema que vem sendo utilizado h dcadas pela Toyota para visualmente controlar e equilibrar a linha de produo. O termo tem se tornado quase sinnimo da implementao dos princpios Lean. Ento, embora sistemas kanban sejam conceito relativamente novo em TI, vm sendo utilizados por mais de 50 anos no sistema de produo Lean na Toyota.

O pioneiro no uso do Kanban em software foi David J. Anderson, que em conjunto com Don Reinerstsen, tem se empenhado para expandir o conhecimento do Lean e o uso do Kanban para visualizar e otimizar o fluxo de trabalho no desenvolvimento de software, nas reas de manuteno e de operaes.

Quando devo considerar trabalhar com o Kanban?

Se a resposta for sim para uma ou mais das questes abaixo, existe uma boa chance de que voc se beneficie da leitura deste livro:

Voc tem se esforado para implementar o Agile em sua organizao, mas sem muito sucesso?

Voc tem usado o Agile por algum tempo, mas as melhorias de desempenho comearam a estagnar?

Voc est utilizando tempo precioso em prticas geis que j no parecem mais se encaixar no contexto em que est trabalhando?

Tem usado Agile como um checklist, mas sem compreender completamente os princpios bsicos?

Sente a necessidade de flexibilidade que v alm da oferecida por iteraes fixas e planejadas?

Kanban em 10 Passos

!

infoq.com/br 5

Suas prioridades mudam diariamente?

Voc est utilizando processos criados para o desenvolvimento gil num contexto em que no se adaptam facilmente, como por exemplo em manuteno e operaes?

Precisa de uma transio gradual da execuo em cascata para o Agile, para evitar altos nveis de resistncia organizacional?

Se seu objetivo trabalhar em um contexto estritamente voltado ao Scrum, ou se atualmente est utilizando um processo cascata, ou se est tentando encontrar um caminho para otimizar sua implementao Agile atual independente do caso, a maioria pode se beneficiar de conhecimento mais profundo em Lean e o Kanban provou ser um excelente catalisador nessa direo.

O que Kanban?

Existem diversas abordagens para o Kanban, mas a maioria dos especialistas concorda que o Kanban um mtodo de gesto de mudanas, que d nfase aos seguintes princpios:

Visualizar o trabalho em andamento;

Visualizar cada passo em sua cadeia de valor, do conceito geral at software que se possa lanar;

Limitar o Trabalho em Progresso (WIP Work in Progress), restringindo o total de trabalho permitido para cada estgio;

Tornar explcitas as polticas sendo seguidas;

Medir e gerenciar o fluxo, para poder tomar decises bem embasadas, alm de visualizar as consequncias dessas decises;

Identificar oportunidades de melhorias, criando uma cultura Kaizen, na qual a melhoria contnua responsabilidade de todos.

Tudo isso, com a filosofia subjacente de que se deve:

Comear com o que se est fazendo agora;

Concordar em buscar mudanas incrementais e evolucionrias;

Respeitar o processo atual, com seus papis, responsabilidades e cargos.

Quem est familiarizado com o Lean ir reconhecer muitos desses princpios como sendo a fundao para um sistema "puxado"(pull) Lean; forma tambm as bases para uma cultura de melhoria contnua (Kaizen). O que o Kanban faz, em primeiro lugar, servir como um catalisador para introduzir ideias Lean na entrega de sistemas de software. Isso tambm declarado por David Anderson em seu livro:

O Kanban (com K maisculo) o mtodo de mudana evolucionria que utiliza um sistema kanban (com k minsculo), alm da visualizao e outras ferramentas, para catalisar a introduo das ideias Lean nas reas de desenvolvimento e operaes de TI.

Kanban em 10 Passos

!

infoq.com/br 6

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

Figura 1. Princpios do Kanban em ao

Como se v, todo o trabalho se torna visvel com o Kanban. Os limites de WIP so estabelecidos (escritos na parte de cima de cada coluna). As polticas se tornam explcitas e o fluxo passa a ser medido. Note que a ltima coluna no possui limite de WIP, devido equipe ter optado especificamente por um ritmo semanal de entregas (3 da tarde na tera-feira. Isso significa que todo o trabalho finalizado liberado neste momento, semanalmente.

O foco do Kanban conduzir mudanas evolucionrias, e estes passos simples tm-se provado extremamente teis para esse objetivo. A razo pela qual nos referimos a esse sistema como um "Sistema Puxado Kanban" (Kanban Pull System) que, ao visualizar o fluxo e estabelecer os limites de WIP, garantimos que nunca se pode introduzir mais trabalho no sistema que a capacidade do sistema de processar esse trabalho. Est disponvel apenas uma quantidade limitada de permisses de trabalho (kanbans); ento necessrio que se complete o trabalho existente antes que um novo trabalho possa ser iniciado. Isto resulta em funcionalidades sendo puxadas pelo sistema, com base na capacidade deste, em vez de empurradas com base em previses ou demandas.

No h regras quanto aparncia especfica do quadro. As nicas limitaes so a imaginao, a criatividade e as restries de um sistema eletrnico, ou o espao na parede. Como este minilivro um guia para principiantes, iremos utilizar exemplos bastante simples de quadros para demonstrar os fundamentos.

Como comear com o Kanban?

Espera-se que as 10 etapas apresentadas neste texto auxiliem o leitor a comear bem com o Kanban mas antes de chegarmos nesse ponto, importante compreender que o Kanban aborda a gesto de mudanas de forma diferente que a maioria dos mtodos geis.

Kanban em 10 Passos

!

infoq.com/br 7

O Kanban construdo sobre os conceitos da mudana evolucionria. Uma abordagem comear a entender como funciona atualmente seu sistema de entrega de software. Quando conseguir visualizar, medir e gerenciar o fluxo sendo utilizado, melhore-o um passo de cada vez, aliviando o seu maior gargalo. Isso muito diferente do que ocorre, por exemplo, no Scrum onde se comea redefinindo papis, processos e artefatos. Isso faz do Kanban um mtodo ideal para utilizao em conjunto com processos existentes, que podem ser desde o Scrum at Cascata. O Kanban tambm excelente em situaes em que estruturas organizacionais inibem mudanas radicais. Lembre-se desse princpio fundamental: "Respeite o processo atual, seus papis, responsabilidades e cargos"

Em termos do Lean, isto significa que o Kanban construdo principalmente sobre o conceito de Kaizen (melhoria contnua). O Kanban apenas usa Kaikaku (mudana dramtica) em situaes especiais, nas quais mudanas estruturais so necessrias ou quando srias melhorias de desempenho precisam ser realizadas.

Figura 2. O Kanban segue uma abordagem evolucionria para a otimizao de processos

Onde o Kanban pode ser utilizado?

Agora estamos quase prontos para iniciar. Porm, antes de mergulhar nos detalhes da implementao, vamos falar rapidamente sobre os mitos do Kanban, para garantir que as sees a seguir sejam lidas com os conceitos corretos em mente.

Na Trifork, ajudamos vrias empresas e equipes a aumentar a efetividade por meio da adoo do Kanban. No incio, parecia que os principais grupos alvo eram as equipes de manuteno e operaes, mas o Kanban se provou til tambm para o desenvolvimento de software. Equipes e organizaes trabalhando com o modelo cascata tambm perceberam nessa abordagem evolucionria a possibilidade de uma transio gradual para o desenvolvimento gil de produtos.

Mitos e fatos do Kanban

Mito: O Kanban adequado apenas para equipes trabalhando com tarefas pequenas e padronizadas, como as de operaes e manuteno.

Kanban em 10 Passos

!

infoq.com/br 8

Fato: O Kanban altamente inspirado pelo trabalho de Don Reinertsen, sobre o Desenvolvimento Lean de Produtos. E se provou ser to boa opo para o desenvolvimento de software quanto para operaes e manuteno.

Mito: O Kanban e o Scrum so opostos.

Fato: Nenhum dos princpios do Kanban restringe o uso do Scrum. O Kanban funciona como um agente de mudanas, e os princpios do Scrum devem, portanto, ser usados apenas nos casos em que ajudam a otimizar o fluxo de trabalho. Nada impede de se comear com o Scrum e utilizar o Kanban para impulsionar futuras mudanas muitos projetos tm sido muito bem sucedidos com essa estratgia. Pode-se at argumentar que esta era essa a inteno original com o Scrum tambm, mas de alguma forma se perdeu com o foco em cerimnias, papis e artefatos.

Mito: Por no insistir no compromisso com iteraes planejadas, o Kanban torna-se vtima da Lei de Parkinson, em que O trabalho se expande de modo a preencher o tempo disponvel para a sua concluso.

Fato: Apesar de ser uma preocupao vlida, os projetos com Kanban raramente apresentam esse comportamento, pois as cadncias fixas, a visualizao permanente, a medio do tempo de ciclo, e os ciclos de feedback curtos com o negcio, mantm o foco controlado e as tarefas fluindo.

Mito: As equipes que utilizam Kanban no utilizam timeboxes (perodos fixos de tempo).

Fato: Os timeboxes no so exigidos no Kanban, mas devem ser utilizados quando ajudarem a otimizar o fluxo, o nvel de feedback e a qualidade. A maioria das equipes Kanban praticam uma cadncia fixa de planejamento, reviso e entregas mas sem vincular estritamente essas cadncias. Desse modo, dispensa-se o modelo tradicional de iteraes, mas preservando o valor gerado.

Mito: As equipes Kanban no fazem estimativas

Fato: As estimativas no so obrigatrias, mas devem ser usadas quando apropriadas. A maioria dos projetos Kanban de desenvolvimento usam algum grau de dimensionamento inicial ou para assegurar o gerenciamento, a priorizao e o alinhamento ideal de portflio, ou para os trabalhos considerados mais sensveis anlise de custo/benefcio ou ao desempenho relacionado a prazos.

Mito: O Kanban melhor do que Crystal/Scrum/XP/FDD etc.

Fato: O Kanban antes de tudo um catalisador para a conduo de mudanas e precisa de um ponto de partida. Assim, apesar de a maioria dos projetos poder se beneficiar do uso do Kanban, o Kanban no um substituto para, por exemplo, o Scrum, que , na maioria dos casos, um ponto de partida perfeito para a adoo do Kanban.

Kanban em 10 Passos

!

infoq.com/br 9

Embora a comunidade Kanban esteja constantemente lutando contra esses e outros mitos, o Kanban ainda continua at hoje sendo um dos conceitos mais mal compreendidos na comunidade gil, principalmente pelas duas razes abaixo:

Boa parte dessa confuso se devem ao fato de o Kanban ser um mtodo de mudanas e de existirem nele poucas partes descritivas dizendo como se trabalhar, quais os papis existentes etc. Como o conceito de um mtodo de mudanas mal compreendido, as pessoas tentam compar-lo com mtodos prescritivos como o Scrum e o XP.

Exemplos locais e comportamentos emergentes do Kanban, em projetos do mundo real, passaram a representar um "mtodo Kanban" para algumas pessoas. fcil ver porque h tanta incompreenso, pois muitos projetos Kanban apresentam as mesmas prticas emergentes. No entanto, a realidade que o Kanban se apoia no uso dos princpios Lean para otimizar processos existentes, de forma evolucionria. Assim, no pode e no deve ser comparado com Scrum, XP, Crystal, FDD ou outro mtodo que se esteja utilizando.

A segunda razo possvel que a palavra "Kanban" remete a muitos conceitos, que vm da sua origem nos sistemas de produo Lean. O termo portanto talvez no seja palavra ideal para descrever um mtodo de mudana para o desenvolvimento de software e operaes de TI.

Embora os sistemas puxados kanban impulsionem mudanas na forma que so usados em sistemas de produo, o Kanban em software baseia-se em um conjunto muito mais amplo dos princpios Lean. Isso cria uma dissonncia que dificulta o entendimento daqueles que trabalharam com Lean no passado.

Voc vai perceber que muito da rejeio ao Kanban por partes da comunidade gil tem como fonte esse mal-entendido.

A boa notcia que a maioria dos projetos, geis ou no, podem ser beneficiados pelo uso dos princpios do Kanban, para impulsionar as mudanas e a melhoria contnua.

O leitor atento pode ter notado que o ttulo deste livro no est alinhado exatamente aos princpios do Kanban. Como j disse David J. Anderson "o design do sistema Kanban um processo de pensamento; no uma cpia ou modelo de implementao de processo". No entanto, que estiver familiarizado com o "Modelo de Dreyfus para aquisio de competncias" ir reconhecer que para se adquirir uma nova competncia, sempre so necessrias prescries iniciais.

Minha esperana que este texto introdutrio ajude o leitor a fazer a transio mais rpida e suavemente. O mais importante saber que as receitas aqui apresentadas servem apenas como uma forma de se adquirir conhecimento para avanar, e no como um ponto final ou uma lista de verificao a ser seguida cegamente. Os modelos e prticas sugeridos nos dez passos deste livro so comportamentos emergentes, constatados com experincia prtica em projetos utilizando Kanban. O que sugerido aqui no se trata do mtodo de mudana Kanban em si.

Agora que temos uma ideia geral, vejamos como aplicar os conceitos na prtica. Cada passo a seguir consiste de uma explicao concisa dos motivos, seguidos pelas prticas.

Kanban em 10 Passos

!

infoq.com/br 10

Passo 1: Visualizar o fluxo de trabalho O primeiro passo para visualizar o seu fluxo de trabalho entender como seu sistema atual funciona.

Compreendendo seu sistema de entrega de software

Para ser capaz de tomar decises bem embasadas sobre a melhor forma de otimizar o fluxo de trabalho, o primeiro passo entender o que est sendo feito atualmente mas se deve resistir a tentao de j realizar mudanas. Alm disso, deve-se mapear todo o fluxo de trabalho para a entrega de software, sem focar apenas na parte de desenvolvimento.

Existem vrias formas de se mapear o fluxo de trabalho. A mais popular a utilizao do conceito Lean de Mapeamento da Cadeia de Valor (Value Stream Mapping VSM). Recentemente, esta prtica Lean tem sido atacada por comunidades geis o principal argumento que o de que o trabalho com conhecimento no um processo linear, diferentemente de outras atividades em sistemas de produo. Isso levou criao da tcnica de Redes de Criao de Conhecimento (Knowledge Creation Networks), que so mais indicadas para atividades no lineares.

Para o exemplo simples apresentado aqui, porm, utilizaremos a tcnica VSM, que mais simples, e que considero extremamente til. Deve-se, contudo, explorar a opo que melhor se adapte ao contexto do leitor.

Em sua forma mais simples, um Mapa de Cadeia de Valor uma visualizao dos estgios pelos quais passa o trabalho, desde a matria prima at o produto final em software, de uma ideia vaga at uma funcionalidade implantada em produo. Para o trabalho de conhecimento (como o desenvolvimento de software), o mais importante pensar em cada estgio como sendo a representao de um grupo de atividades.

Em um estgio chamado Testes, por exemplo, h mais trabalho do que simplesmente testar, incluindo corrigir, refatorar, discutir, atualizar critrios de aceite etc. Mas como o termo mais representativo Testes, iremos definir nosso trabalho como estando neste estgio, enquanto todas essas atividades estiverem acontecendo. O espao entre os estgios em que nenhuma informao est sendo adicionada definido como tempo de espera (wait time). A Figura 3 mostra um exemplo retirado de um projeto real.

Figura 3. Exemplo de mapa de cadeia de fluxo de valor

Mais tarde, poderamos perceber que a implementao, na verdade, consiste em Detalhamento das histrias de usurio e Desenvolvimento, seguido de Reviso de cdigo mas vamos focar

Kanban em 10 Passos

!

infoq.com/br 11

nessa verso simplificada por enquanto. Outras ideias de melhoria comeam a surgir: Por que existe um tempo mdio de cinco meses da especificao at a implementao? Por que estamos esperando duas semanas para testar? Resista tentao de lidar com essas questes por enquanto, pois haver tempo de sobra para isso mais tarde. O foco agora entender como nosso sistema atual funciona.

Inicialmente, uma boa ideia limitar o nmero de estgios, pois se pode perder rapidamente a viso do todo ao dar muita nfase na mecnica. Mais tarde, pode ser benfico adicionar mais detalhes e estgios, mas procure manter o fluxo o mais simples possvel por enquanto.

Visualizao do seu sistema de entregas

Agora que j temos um entendimento melhor de nosso sistema de entrega de software, o prximo passo tentar visualiz-lo atravs de um sistema eletrnico, ou simplesmente utilizando um quadro branco. A menos que se esteja trabalhando em uma equipe distribuda, geralmente uma boa ideia comear apenas com o quadro branco. Nada torna seu trabalho mais visvel do que t-lo sua frente o tempo todo e poder toc-lo fisicamente. medida que cresce a maturidade da equipe e se sente a necessidade de coletar mais dados, pode-se querer mover a visualizao do trabalho para uma verso eletrnica. Mas vamos nos ater ao quadro fsico por enquanto.

Muitas vezes, voc acabar com pelo menos dois tipos de estgios: os de Atividade, nos quais o trabalho est sendo de fato realizado, e os de Buffer, nos quais o trabalho est aguardando para ser lanado/desenvolvido etc. Veremos mais sobre isso adiante.

A primeira verso do seu quadro pode parecer com a mostrada na Figura 4. Perceba que todo o trabalho necessrio para se completar uma funcionalidade representado no quadro, e no apenas o desenvolvimento.

Figura 4. Estgio de atividade e estgio de buffer

Kanban em 10 Passos

!

infoq.com/br 12

Toda funcionalidade comea como uma ideia geral na "Caixa de entrada do PO" (PO Inbox, na imagem) e termina na coluna Pronto para produo (Ready to Release, na imagem). A funcionalidade removida desta ltima coluna quando est liberada e em produo. Note que no fizemos mudana alguma pode-se ainda estar usando uma implementao estrita do Scrum.

Caso visualizar seu trabalho seja difcil, pare. No v alm, a no ser que tenha conseguido visualizar todo o trabalho que voc faz. Se ainda existe informao escondida e algumas tarefas estiverem completamente fora do seu sistema de entregas, h pouca chance de que se consiga tomar decises fundamentadas sobre a melhor forma de otimizao. Uma regra geral que se pode gerenciar apenas o trabalho que se pode ver.

Visualizar o trabalho difcil na vida real. As razes para a dificuldade so das mais variadas. Por exemplo, as pessoas sabem que esto fazendo coisas que no deveriam; tm medo de serem punidas caso seus superiores saibam como as coisas realmente funcionam; e apesar de cansadas e sob presso, sentem que deixaro seus colegas desamparados se no estiverem constantemente apagando incndios. Antes de seguir em frente necessrio corrigir esses problemas, e fazer com que todos os envolvidos acreditem que ningum ser culpado ou responsabilizado por deixar claro o trabalho que est realmente sendo feito.

Visualizar seu fluxo de trabalho gera uma srie de benefcios, sendo os mais importantes:

Foco no todo: Fica visvel exatamente como o seu trabalho afeta as outras pessoas e vice-versa;

Transparncia: Todos sabem exatamente o que est acontecendo e nenhuma informao escondida;

Identificao de desperdcios: Surgir naturalmente um questionamento da razo pela qual as coisas so feitas como so (mais sobre isto adiante).

Passo 2: Limitar o trabalho em progresso Uma vez que consiga visualizar o fluxo de trabalho, mova para o prximo passo limitar o trabalho em progresso (WIP).

Compreendendo o WIP

Para entender porque faz sentido limitar o WIP, precisamos passar pela Lei de Little: Tempo de Ciclo = WIP / Produo por unidade de tempo (frmula adaptada para a terminologia do desenvolvimento de produtos)

O tempo de ciclo o tempo que se leva para um item de trabalho passar pelo nosso sistema kanban; em outras palavras, o tempo que se leva para uma funcionalidade selecionada para implementao chegar produo. O que significa "selecionada para implementao" dependente de contexto. Para alguns, a entrada de um item no backlog; para outros, trata-se do momento em que um item selecionado para detalhamento. Pode-se tambm distinguir entre "Lead Time" e

Kanban em 10 Passos

!

infoq.com/br 13

"Tempo de ciclo": o primeiro seria o tempo desde a chegada do item at sua entrega; o segundo o tempo desde a seleo para implementao at sua entrega.

O WIP descreve o total de trabalho em progresso no sistema kanban. Quantos pontos de histria/histrias de usurio/itens de backlog esto atualmente em progresso em seu sistema? Mais uma vez, isso vai depender do contexto. Alguns especialistas incluem todos os itens de backlog no WIP; outros consideram apenas os itens selecionados para implementao.

Produo (throughput) por unidade de tempo a mdia do nmero de itens produzidos em um determinado perodo de tempo. No Scrum, comumente chamado de velocidade.

Isso significa que, dado um sistema com 100 histrias de usurio em progresso (WIP) e uma produo de duas histrias por semana, o tempo mdio de ciclo calculado como 100/2 = 50 semanas ou quase um ano. Reduzir esse tempo para 25 semanas poderia ser feito dobrando-se a produo, ou reduzindo o nmero de histrias de usurio em progresso para 50. Na maioria dos casos, mais fcil inicialmente reduzir o WIP do que dobrar a produo.

Como se pode perceber, limitar o WIP est intimamente ligado reduo do tempo de ciclo para aumentar a produtividade e minimizar a quantidade de trabalho em que investimos tempo e recursos (mas que ainda no gerou nenhum valor de negcio). Ciclos de feedback rpidos so tambm uma excelente maneira de minimizar riscos, dado que as decises so validadas continuamente e os problemas de qualidade so expostos imediatamente. Este um assunto explorado mais detalhadamente no livro "Custos da Qualidade" de Capers Jones (1980).

Ento, como fazer? No h como saber o nmero exato de quantos itens deveriam ser permitidos em cada estgio de nosso quadro, ento escolhemos um nmero da melhor forma possvel. Uma boa ideia deixar que esse exerccio seja guiado pelas polticas em que sua equipe gostaria de dar nfase. Caso a equipe ache uma boa ideia incentivar o trabalho em pares, ento se pode escolher um limite de 3 para uma equipe de seis pessoas.

Veja que isto verdade apenas para colunas de atividade, como "desenvolvimento", "testes" etc. J para colunas de buffer como "pronto para desenvolvimento", a regra geral que, se essas colunas estiverem vazias uma vez por ano, o limite de WIP est muito grande (pois durante 364 dias o buffer foi maior que o necessrio). E se estiver vazia todo dia, ento o limite est pequeno demais. comum ouvir que o limite universal de WIP 5: se estiver em dvida, 5 provavelmente um bom nmero para se comear.

Visualizando limites de WIP

H vrias formas de se visualizar o limite de trabalho em progresso. As Figuras 5 e 6 mostram duas formas comuns de se fazer isso. Na Figura 5, apenas um item pode ser colocado em cada espao desenhado no quadro, disparando um sinal visual quando houver uma "permisso" para comear/puxar novas atividades (o espao est vazio).

Na Figura 6, mais fcil dividir o estgio da atividade em "em progresso" e "feito", j que o limite de WIP simplesmente escrito no topo de cada coluna. Isso pode ajudar a compreender melhor o funcionamento do seu sistema de entregas, e a maneira mais comum de exibir o limite de WIP

Kanban em 10 Passos

!

infoq.com/br 14

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

Figura 5. Limites de WIP visualizados com containers

Figura 6. Limites de WIP visualizados usando nmeros nos cabealhos de colunas

Identificao dos limites ideais para o WIP

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

Kanban em 10 Passos

!

infoq.com/br 15

Uma abordagem mais radical seria determinar limites de trabalho em progresso muito pequenos; menores do que o seu sistema capaz de lidar e colocar um buffer antes de cada estgio. Observa-se, ento, onde o trabalho se acumula e gradualmente ajusta-se o limite do WIP at que o trabalho flua atravs do sistema. Ambas as abordagens requerem experincia e no se espera um acerto logo na primeira tentativa. No h concluso definitiva quanto melhor abordagem, mas recomenda-se manter suas polticas de trabalho em mente, nas duas situaes.

Em qualquer situao, importante que se determine uma poltica explcita sobre como sero tomadas as decises para alterar um limite. Para maximizar o aprendizado, o ideal tomar essas decises em conjunto com a equipe, garantindo que todos possam expor suas opinies e entender as decises. No se trata apenas do fluxo, mas tambm de aprendizado.

Lembre-se sempre que os limites iniciais de trabalho em progresso so apenas bons palpites, dados em um momento em que se tem poucas informaes. medida que so adquiridas mais informaes sobre o sistema, e encontradas melhores formas de se trabalhar, os limites devem ser ajustados. Se, depois de trs meses, ainda se est trabalhando com os mesmos limites iniciais e os mesmos estgios, h boa chance de que tenha sido perdido o passo mais importante: o de melhoria contnua, que cobriremos mais tarde em mais detalhes.

Limites muito pequenos iro impedir o fluxo e deixar pessoas ociosas por tempo demais; ou ento os limites sero simplesmente ignorados, sem discusses srias. Limites muito soltos, por outro lado, aumentam o tempo de ciclo e mantm o trabalho parado por mais tempo do que necessrio.

O que se percebe rapidamente que, com os limites de WIP estabelecidos, seu sistema s ser capaz de trabalhar at a capacidade. Vai ser necessrio finalizar uma atividade para conseguir permisso para comear outra. Apesar disso parecer trivial, trata-se de um conceito fundamental em um sistema puxado Lean, e uma ferramenta poderosa na busca por um sistema de entrega de software que seja eficaz, sustentvel e previsvel.

Pode-se imaginar o funcionamento de um sistema puxado como uma corrente de clipes de papel. Enquanto estiver puxando a corrente pela mesa por uma das pontas, os clipes seguem em uma fila organizada, mas caso se decida empurr-los, h o caos (veja a Figura 7).

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

Kanban em 10 Passos

!

infoq.com/br 16

No incio, haver desconforto por no se poder comear algo novo, mesmo quando isso parece ser a "coisa certa" a fazer. Esse desconforto sinal de que existe um impedimento no fluxo. O mais importante no ignorar o problema e aproveitar a oportunidade para realizar melhorias.

Nos momentos de discusso sobre o WIP, comum se focar demais no nmero de itens em progresso. Mas no devemos esquecer que o tamanho dos itens tambm importante. Itens grandes bloqueiam recursos por longos perodos e perturbam o fluxo ao passo que itens menores fluem muito mais rapidamente pelo sistema de entregas, fornecendo feedbacks mais rpidos. Porm, analisar os itens e quebr-los em partes pequenas, em um conjunto "mnimo de funcionalidades vendveis" (minimal marketable features MMF) uma tarefa que requer imaginao, habilidade e experincia.

Passo 3: Estabelecer polticas explcitas para garantia de qualidade Caso esteja familiarizado com a filosofia Lean, o leitor pode ter ouvido falar do termo "Qualidade embutida" e pode se questionar porque a qualidade to importante. A resposta no est em encontrar e corrigir defeitos, mas no fato de problemas de qualidade serem muito mais caros do que se pensa.

No Kanban, concentra-se em criar polticas explcitas que otimizem a qualidade e deem consistncia ao sistema de entrega de software e usamos essas polticas como base para a melhoria contnua.

Entendendo a qualidade

Uma interface de baixa qualidade que impede a concluso de uma tarefa, ou um defeito que atrapalha o fluxo de trabalho ambos so problemas de qualidade que estressam o sistema Kanban, gerando ciclos de desperdcio. Isso conhecido em sistemas Lean como "demanda de falha", e descreve todas as atividades e o retrabalho ligados baixa qualidade no projeto do produto.

s vezes aceitvel lanar um produto com baixa qualidade para se obter mais feedback. Pode haver tambm vantagens financeiras em permitir que se encontre o defeito em produo, ao invs de em desenvolvimento pois o custo e o tempo poderiam ser maiores sem o feedback dos usurios. Na maioria dos casos, porm, a baixa qualidade se trata apenas de um sintoma de processo imaturo.

Por que problemas de qualidade so to caros? Verifiquemos essa questo em cenrios comuns no desenvolvimento de software.

Um usurio (vamos cham-lo de Joo) no consegue concluir sua tarefa devido a um defeito em nossa aplicao. Joo abre um chamado relatando o bug ou liga para o suporte de primeiro nvel. Ele no sabe muito sobre o trabalho necessrio para um desenvolvedor investigar o problema, ou talvez o suporte de primeiro nvel no conhea a aplicao to bem quanto deveria.

Kanban em 10 Passos

!

infoq.com/br 17

Em ambos os casos, informaes erradas ou inadequadas so passadas ao desenvolvedor, que acaba resolvendo um problema diferente (que pode at no ser um problema e gerar um novo bug); ou o desenvolvedor pode simplesmente desistir. At que o defeito seja corrigido, o usurio insiste nesse processo. S que no foi apenas Joo que ficou impossibilitado de completar o que estava fazendo. Informaes inconsistentes foram persistidas na base de dados, que agora requer o uso de um script de SQL complicado para reverter os dados a um estado consistente.

No incomum que situaes como essa ocorram e de que 100 a mil vezes mais tempo e recursos sejam gastos com a soluo comparando-se com o custo de evitar a introduo do defeito.

Alm disso, problemas de qualidade levam mudana constante de contexto e ao apagamento de incndios. Naturalmente colocamos de lado o trabalho que estamos fazendo para corrigir um defeito srio ou um problema de usabilidade no ambiente de produo. E quando, aps metade do dia, o problema finalmente resolvido, no conseguimos lembrar dos detalhes do outro problema complicado em que estvamos trabalhando e temos que gastar meia hora apenas para se reambientar.

Por essas razes, o Lean d grande nfase na adoo de medidas para prevenir que falhas aconteam no sistema de entrega, usando o Poka Yoke (pronuncia-se "Poc Ioqu"). Em sistemas de produo, o Poka Yoke feito utilizando-se padres e checklists que devem ser seguidos para se completar uma tarefa. Por exemplo, at clulas fotossensveis so usadas para registrar se uma chave de fenda especfica est sendo utilizada a quantidade correta de vezes, ou se todas as partes necessrias foram removidas de uma pilha.

Isso pode parecer um ambiente desumano para se trabalhar, mas na realidade os trabalhadores de sistemas de produo Lean no se enxergam como robs seguindo cegamente padres e checklists. Eles se veem como especialistas que esto constantemente tentando melhorar o sistema no qual esto trabalhando, ao sugerirem aperfeioamentos e novas ideias. No livro "Toyota: A Frmula da Inovao, 2006", de Matthew E. May, o autor refere-se a este fato como a principal razo pela qual a Toyota ainda consegue implementar um milho de novas melhorias todos os anos.

Visualizao das polticas

Mas como traduzimos, essas ideias para o desenvolvimento de software? J temos boa parte do trabalho feito, pois j estamos visualizando o trabalho com o quadro Kanban e j limitamos o trabalho em progresso. Tudo o que se precisa fazer agora adicionar no quadro as polticas sendo usadas atualmente para assegurar a qualidade e a consistncia. Ao fazer isso, seu quadro pode ficar parecido com o da Figura 8.

Kanban em 10 Passos

!

infoq.com/br 18

Figura 8. Polticas explcitas visualizadas no quadro

Repare que estgios inteiros podem ter polticas para garantia de qualidade, e que polticas tambm podem servir para a garantia da consistncia e de qualidade do prprio processo (ex.: medindo o tempo de ciclo e o ndice de defeitos). Tudo isso nos leva a outra prtica fundamental do Kanban: tornar as polticas explcitas.

Vrias equipes j atingiram nveis extraordinrios nas prticas voltadas preveno de falhas nos ltimos anos, e implementaram sistemas que eram impensveis apenas alguns anos atrs. O movimento de Lean Startup tem mostrado que possvel lanar software em produo diversas vezes ao dia sem indisponibilidades ou altos ndices de defeitos. Isto s funciona porque foram adotadas prticas como testes unitrios, testes de integrao, e testes de regresso e de desempenho, que ajudam a validar o cdigo assim como indicadores de desempenho que sinalizam sempre quando o sistema no se comportar como esperado, retornando-o automaticamente para sua ltima verso estvel. Isso torna quase impossvel introduzir quantidades grandes de erros.

Tenha em mente que voc nunca deve se sentir dominado por suas prprias polticas e checklists. Voc no um autmato; um profissional do conhecimento, observando constantemente e tentando melhorar o sistema em que est trabalhando. Comece adicionando os procedimentos que est utilizando no momento e adicione, remova ou altere esses procedimentos quando perceber maneiras novas e melhores de garantir a qualidade. Cada defeito uma oportunidade de pensar sobre como evitar que outro defeito aparea.

No comeo, pode parecer penoso analisar e aprender com cada defeito que surgir. Mas com o tempo, conforme a qualidade melhora, o processo se tornar mais natural. Esse um preo que vale a pena pagar, e conhecido como "Tolerncia zero" nos crculos de testes geis.

comum que essa ideia seja interpretada de forma incorreta, como "no podemos gastar o tempo que gostaramos criando mecanismos para tornar os produtos prova de falhas". O que vale no final que teremos zero defeitos. "Tolerncia zero" no significa que nunca mais possam existir defeitos, e sim que devemos conscientemente refletir sobre cada defeito e buscar a perfeio.

Kanban em 10 Passos

!

infoq.com/br 19

Ao implementar o Kanban, essencial que todos se comprometam com as polticas adotadas (inicialmente essas polticas descrevem apenas o processo atual), e que aceitem que necessria uma deciso da equipe para mud-las. Quando algum decide infringir as polticas por conta prpria, sem o envolvimento da equipe, o processo rapidamente degenera. Lembre-se: quando voc sentir a necessidade de desrespeitar uma poltica, ser geralmente por uma boa razo e este um bom momento para iniciar as discusses necessrias. Em relao s polticas, "altere mas no quebre" a frase que sempre repito quando forneo treinamentos em Kanban.

Passo 4: Ajustar cadncias Quando voc tiver conseguido visualizar seu fluxo, limitado o trabalho em progresso e estabelecido polticas para assegurar a qualidade, a prxima coisa que se deve avaliar so as cadncias ou ritmos de trabalho. Em um sistema de entrega de software h diversas atividades que se beneficiam de cadncias regulares e encontrar a cadncia exata para cada tipo de atividade essencial para melhorar o fluxo.

Repare que, em um sistema kanban, no somos obrigados a sincronizar tudo utilizando um mnimo denominador comum. Podemos ajustar as cadncias de cada atividade para nveis timos individualmente. Cadncias tpicas que precisamos considerar so a de planejamento (entrada) e a de entrega (sada). H muitas outras cadncias, como a de reviso/retrospectiva e a de garantia de qualidade. Vamos focar em planejamento e entrega, por enquanto.

Entendendo cadncias

Encontrar a cadncia ideal de entrega uma das tarefas mais importantes no Desenvolvimento Lean de Produtos, pois ajuda a otimizar os ciclos de feedback, reduzir os riscos e otimizar o seu processo de entrega. O feedback rpido faz parte do ncleo do Agile e do Lean. Quando fao o coaching de equipes, continuamente friso que o trabalho que ainda no entregou valor deve ser visto apenas como uma hiptese que precisamos validar o mais cedo possvel.

Apesar de entregar cada funcionalidade diretamente para produo ser a soluo tima (considerando que se tenha um sistema otimizado para lidar com isso), na realidade, a maioria dos projetos trabalham com duas cadncias de entrega.

Uma cadncia em que o cdigo disponibilizado em um ambiente de pr-produo para se obter feedback inicial (cadncia de lanamentos internos);

Outra cadncia na qual a nova verso lanada em ambiente de produo (cadncia de lanamentos externos).

Especialmente em projetos novos, estas duas cadncias podem estar muito distantes uma da outra. Pode levar at cinco meses para que o sistema tenha funcionalidades suficientes para ser colocado em produo. Ao mesmo tempo, o cdigo pode estar sendo lanado e testado todos os dias em um ambiente de pr-produo.

Kanban em 10 Passos

!

infoq.com/br 20

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

Figura 9. Otimizao do tamanho dos lotes

Quanto mais funcionalidades so includas em uma entrega, mais barato ser o custo por funcionalidade (menor custo transacional). Em contrapartida o custo de espera maior, uma vez que cada funcionalidade ter de esperar mais tempo para ser lanada. Isso resulta em perda de valor de negcio, feedback desatualizado, decises pouco embasadas e menor envolvimento com o usurio.

Custos de espera so um pouco diferentes para lanamentos externos e internos. Como um lanamento interno no expe nenhum valor real de negcio para os clientes, os custos de espera representam se restringem a feedback desatualizado, decises desinformadas e motivao do usurio/negcio diminuda devido ao baixo envolvimento. Mas qualquer pessoa que tenha trabalhado em um ambiente de negcios real reconhecer que esses problemas podem ser to prejudiciais quanto a perda de receita.

O grfico da Figura 9, j citado, mostra uma curva do tipo "u" para a linha de custo total. A curva apresenta uma parte inferior bastante suave, significando que no necessrio encontrar o ponto timo exato para a cadncia de entregas. Mesmo com um erro de 10 a 15%, haver bons resultados.

Kanban em 10 Passos

!

infoq.com/br 21

Estabelecendo as cadncias ideais

Muitos projetos, infelizmente, nem sequer consideram os aspectos acima com profundidade. Diversas equipes geis maduras so capazes de fazer entregas em ambientes de pr-produo com um clique de um boto mas ainda assim demoram trs semanas para receber o feedback dos usurios sobre uma funcionalidade. Quando os custos de transao esto na casa dos poucos reais, deve-se considerar seriamente o uso de lotes muito pequenos. Algumas vezes isso pode ser problemtico, j que os usurios podem no estar disponveis, mas na maioria dos casos o que acontece que a possibilidade nem sequer tinha sido considerada.

Outro ponto importante que a Toyota nos ensinou que os custos de transao no so fixos.

O movimento de implantao contnua (continuous deployment) tem mostrado que possvel lanar verses confiveis para produo 50 vezes ao dia, para sistemas lidando com milhes de pessoas. Isto s pode ser atingido com um procedimento completamente automatizado de lanamento, e todo um conjunto de testes unitrios, testes de integrao e de regresso. esse investimento que permite trabalhar em lotes de poucas linhas de cdigo.

As mesmas consideraes devem ser levadas em conta para se chegar a uma cadncia de planejamento adequada. Quando o tempo entre os encontros de planejamento se torna mais longo, mais coisas precisam ser planejadas em um grande lote. Isso resulta em mais esforo de design em progresso e menos decises fundamentadas devido a um tempo de ciclo mais longo. Por outro lado, realizar encontros dirios pode se mostrar custoso demais e aumentar o custo transacional.

Em alguns casos, equipes que utilizam Kanban escolhem realizar o planejamento sob demanda. Isso pode ser feito com o envio de um email para os interessados, convidando-os para um encontro, ou uma conferncia. Isso sempre que houver espao para que a fila de entrada seja preenchida com, por exemplo, os trs itens de maior prioridade. Normalmente o planejamento "sob demanda" utilizado por equipes mais avanadas e requer experincia na gerncia dos fluxos. Portanto, pense bem antes de comear com essa estratgia.

Passo 5: Medir o fluxo Medir o progresso de projetos , infelizmente, um dos aspectos mais mal compreendidos e mal aplicados no desenvolvimento de software. comum ver mtricas sendo usadas para tornar os gerentes de projeto responsveis por aspectos sobre os quais no tm controle; ou ainda como critrios de sucesso fixos, estabelecidos quando nem se conhecia o sistema a ser desenvolvido.

Entendendo mtricas

Em mtricas, uma regra bsica a ser lembrada que seu sistema de entrega de software tem capacidade limitada. Quando o sistema pressionado alm da capacidade, haver queda na qualidade, ritmo insustentvel, custos de manuteno mais altos, ou tudo isso ao mesmo tempo. Ainda assim, sempre vemos gerentes de projeto quase orgulhosos de terem feito suas equipes

Kanban em 10 Passos

!

infoq.com/br 22

trabalharem alm do horrio por trs meses, ou que, por algum esforo heroico, conseguiram controlar as coisas no ltimo momento, depois de semanas de caos.

Apesar de ser positivo comemorar grandes realizaes, os projetos de desenvolvimento de software no precisam de heris, e sim de gente capaz de fazer entregas com transparncia e em ritmo sustentvel. Tudo a mais simplesmente muito caro. Aqui se aplica uma frase de Kent Beck: "se um problema precisa de mais trabalho que uma semana de horas extras, ento o problema no deveria ser resolvido com horas extras".

Pode-se, claro, aumentar a capacidade no decorrer do tempo, contratando mais pessoas, otimizando processos, ou os dois (mas cuidado ao fazer ajustes visando resultados de curto prazo). Outra boa regra a ser usada : "seu sistema nunca ter mais capacidade do que a capacidade que j provou ter". Seguindo essa regra, pode-se evitar os antipadres de excesso de otimismo e comparaes com o sucesso dos outros. Comeando um projeto do zero, sua capacidade ser apenas um palpite, baseado em desempenhos anteriores. O importante medir o progresso desde o comeo para validar todas as suposies. Veremos mais sobre esse assunto no Passo 8.

Ento, pense em seu plano como uma ferramenta que serve como guia, no como critrio de sucesso. E mea seu fluxo para determinar se voc ainda est no caminho certo. O objetivo obter um sistema de entrega de software estvel e previsvel, para que se possa tomar decises bem fundamentadas sobre prazos, dependncias, pessoal, escopo e custos.

O que medir?

Como medir o fluxo? Antes de escolher a forma de medir, deve-se sempre se perguntar o que ser feito com a informao obtida. Se voc no pretende mudar nada com uma mtrica, provvel que se trate de algo que no se deveria estar sendo medido. Para comear, sugiro quatro tcnicas: Diagramas de Fluxo Cumulativo, Tempo de Ciclo, ndices de Defeitos e Itens Bloqueados.

Diagramas de fluxo cumulativo (CFD)

Diagramas de fluxo cumulativo parecem estar substituindo os grficos de burndown (comuns no Scrum), nas equipes e organizaes geis mais maduras. So fceis de atualizar e fornecem uma melhor perspectiva do estado do projeto.

Os CFDs mostram essencialmente um retrato da quantidade de trabalho em seu sistema, para cada estgio de sua cadeia de valor, no decorrer do tempo. O grfico inclui o mesmo tipo de informaes que grficos de burndown tradicionais, mas vai alm (veja um exemplo na Figura 10).

Kanban em 10 Passos

!

infoq.com/br 23

Figura 10. Exemplo de diagrama de fluxo cumulativo

Interpretando o CFD

A rea que mostra os itens "done" (prontos) representa a velocidade no decorrer do tempo. A rea entre as linhas done e "backlog" o trabalho em progresso (WIP).

Se a distncia entre duas linhas na rea do trabalho em progresso (WIP) aumentar, isso pode ser um sinal de gargalos;

Se a linha de backlog estiver mais inclinada que a de done, h sinal claro de que se est adicionando mais trabalho ao sistema se comparado sua capacidade atual de entrega;

Projetar onde as linhas que representam os itens de backlog e de done iro se encontrar a melhor maneira de estimar a data final de entrega;

O tempo mdio de ciclo e quantidade de itens na fila tambm podem ser extrados do diagrama.

Aprender a interpretar um diagrama de fluxo cumulativo (CFD) fcil. A Figura 11, do livro de Don Reinertsen, mostra uma excelente representao visual. Observe que a rea em preto representa o trabalho em progresso (WIP).

Kanban em 10 Passos

!

infoq.com/br 24

Figura 11. Como ler um Diagrama de Fluxo Cumulativo

Tempo de ciclo

Apesar de seu Diagrama de Fluxo Cumulativo mostrar o tempo mdio de ciclo, medir os tempos de ciclo individuais vale muito a pena em termos de previsibilidade.

Mdias podem ser enganosas. Uma representao visual trar informaes mais detalhadas sobre a confiabilidade do seu sistema, alm da oportunidade de atender demandas dos clientes com mais preciso (veremos mais sobre isso no Passo 9).

Medir o tempo de ciclo ainda mais fcil que atualizar o grfico CFD. Tudo que se tem de fazer registrar o dia em que se comeou a trabalhar em um item (lembre-se de tornar esta poltica explcita tambm). Quando o trabalho concludo, basta marcar o nmero de dias gastos para completar o item. Assim, seu diagrama dever ficar parecido com o mostrado na Figura 12.

Como cada "passo" no eixo X representa um item de trabalho completo, as equipes frequentemente escolhem deixar o eixo sem unidades.

Kanban em 10 Passos

!

infoq.com/br 25

Figura 12. Exemplo de diagrama de tempo de ciclo

Apesar de simples, o diagrama de tempo de ciclo pode trazer muitas informaes e responder vrias perguntas sobre como seu sistema est funcionando:

Os nmeros indicam algum nvel de consistncia ou os nmeros so incongruentes?

Como est a tendncia? Aponta na direo correta?

O diagrama permite investigar os nmeros muito discrepantes (positivos e negativos)

O diagrama tambm permite verificar as consequncias das decises (tarefas grandes, resoluo de incidentes, problemas de qualidade etc.)

Se 90% dos itens de trabalho levam menos de uma semana, possvel se comprometer com o cliente dizendo que ele/ela pode esperar que 9 em cada 10 itens sejam feitos neste prazo.

importante lembrar que o tempo de ciclo um indicador tardio, o que significa que veremos apenas os problemas depois que ocorrerem. Ou seja, quando tarde demais para fazer algo a respeito. Portanto, devemos usar diagramas de tempo de ciclo em conjunto com um CFD, por exemplo, para poder agir proativamente.

ndice de defeitos

Como mencionado, problemas de qualidade so extremamente caros, portanto importante ficar atento a eles. Medir o ndice e o nmero total de defeitos em seu sistema uma maneira fcil de evitar que problemas de qualidade fujam do controle.

surpreendente ver to poucas organizaes tratarem ndices de defeitos como um indicador de chave de desempenho (Key Performance Indicator KPI). Indicadores de desempenho nos mostram informaes valiosas sobre o estado do projeto, por exemplo:

Kanban em 10 Passos

!

infoq.com/br 26

Por que o nmero de novos defeitos tem aumentado? Houve relaxamento de alguma poltica de Qualidade?

Como o alto ndice de defeitos na semana 20 afetou o tempo de ciclo?

Qual o impacto no diagrama de fluxo cumulativo quando o nmero de defeitos aumentou?

Tome sempre cuidado para no tirar muitas concluses com base em conjuntos individuais de informaes. Uma semana ruim pode ser apenas uma coincidncia. E no deixe de prestar ateno s tendncias para saber se est tudo indo na direo correta. A Figura 13 mostra um exemplo de um diagrama de ndice de defeitos.

Figura 13. Exemplo de diagrama de taxa de defeitos

Manter o nmero total de defeitos abaixo de 20 uma boa poltica para a maioria dos projetos. Se a lista se tornar maior que vinte itens, fica difcil administr-la e se gasta muito tempo dando manuteno no backlog de defeitos conferindo entradas duplicadas, defeitos desatualizados e itens corrigidos. E quando o nmero alto, as pessoas parecem ficar mais preocupadas, demandando mais relatrios e mtricas para acompanhar a lista de defeitos. Comeam a surgir quadros gerenciais sobre defeitos e reunies semanais de acompanhamento, que roubam tempo valioso. Mesmo defeitos cosmticos requerem ateno e exigem tempo adicional para administrar.

comum que se acabe tentando simplesmente alterar a categorizao da severidade dos defeitos para se livrar do problema, mas uma soluo inadequada, devido s razes discutidas acima.

Itens bloqueados

Espero que voc j esteja convencido da importncia do fluxo para que os sistemas se comportem com previsibilidade, e para que os processos individuais operem com eficcia. A maioria das pessoas, independentemente do contexto ser Agile ou no, j viu itens ficarem bloqueados por longos perodos e por vrias razes. Apesar de o grfico CFD e o diagrama de tempo de ciclo

Kanban em 10 Passos

!

infoq.com/br 27

mostrarem esse acmulo de atividades paradas, a equipe pode achar vantajoso medir e visualizar explicitamente sua habilidade de lidar com esses problemas.

Algumas empresas utilizam o nmero de itens bloqueados e a habilidade de resolv-los como indicador chave na medio do desempenho. Reconhecem que impedimentos tm srios efeitos de longo prazo no sistema de entregas, e que a habilidade de resolv-los rapidamente bom indicativo do desempenho e da eficcia da equipe. Itens bloqueados devem sempre estar visveis no quadro. E medi-los no decorrer do tempo uma boa maneira de saber se a equipe est caminhando na direo certa. A Figura 14 mostra um exemplo de diagrama de itens bloqueados.

Figura 14. Exemplo de diagrama de itens bloqueados

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

Kanban em 10 Passos

!

infoq.com/br 28

Figura 15. Visualizao de item bloqueado com marcador

Evite separar um local especfico do quadro para os itens bloqueados. Como esse local no faz parte do fluxo atual de trabalho, h a tendncia de a rea no ganhar a devida importncia (at que algum aparea berrando, querendo saber porque um item no foi concludo ainda!). Usar um espao especfico do quadro tambm parece fazer com que haja menos interesse em resolver os problemas, e mais interesse em declarar que outras partes so os responsveis pela resoluo.

Geralmente, quatro diagramas prximos ao quadro constituem o limite de quantidade de informao que a maioria das pessoas capaz de absorver, antes que percam interesse ou ateno. Mas importante que essas informaes estejam visveis; mant-las escondidas em uma planilha em algum sistema eletrnico raramente chamar a ateno devida. A Figura 16 mostra os quatro grficos discutidos nesse captulo, exibidos logo acima do quadro da equipe.

Kanban em 10 Passos

!

infoq.com/br 29

Figura 16. Mtricas de fluxo visualizadas no topo do quadro

Passo 6: Priorizao Pode ser surpreendente estarmos no sexto passo e ainda no termos comeado a priorizar. Mas, como diz David J. Anderson, caso no se tenha um sistema de entrega de software funcionando, com um fluxo contnuo e entregas seguras e de qualidade, a priorizao ter pouca importncia.

Quando chega o momento de priorizar, como fazer esse trabalho da melhor forma possvel? Focaremos aqui na priorizao de um tipo de trabalho especfico, as histrias de usurio. No Passo 7, veremos como tipos de trabalho diferentes devem ser tratados.

Custo de atraso

Um conceito importante usado para priorizao o Custo de Atraso (COD Cost of Delay). O Custo de Atraso representa a receita ou a economia perdidas com a escolha de no se trabalhar em um determinado item (uma histria de usurio, por exemplo). A mais alta prioridade deve ser o item com o maior custo de atraso. O custo de atraso geralmente associado ao Custo de Implementao (COI), a prazos e a outros fatores.

No est no escopo deste texto explicar em detalhes o Custo de Atraso, mas aqui s precisamos conhecer o conceito de custo de oportunidade e saber que toda vez que se escolhe trabalhar em algum item, escolhe-se tambm bloquear algum outro. Calcular exatamente o COD quase sempre impossvel no desenvolvimento de produtos; ento geralmente ser necessrio seguir

Kanban em 10 Passos

!

infoq.com/br 30

bons palpites. Aprender a associar um valor econmico ao trabalho desempenhado um exerccio de amadurecimento para projetos e organizaes.

Visualizando prioridades

Para garantir que o item certo ser escolhido, a fila de entrada deve conter sempre os itens ordenados por prioridade. Essa regra aplicvel tanto ao planejar um lote de trabalho para o prximo Sprint no Scrum, quanto no trabalho com um fluxo contnuo. Neste ltimo caso, os itens de maior prioridade so puxados continuamente sempre que houver uma autorizao de trabalho. A Figura 17 mostra um exemplo.

Figura 17. Polticas de priorizao visualizadas no quadro

Outros fatores importantes para a priorizao, que tambm devem ser includos na classificao final, so:

Riscos e incertezas: obtenha informaes o mais cedo possvel, para apoiar decises de alto risco e de alto impacto;

Necessidades bsicas: infraestrutura do projeto etc.;

Tamanho equilibrado: misture histrias de diferentes tamanhos para manter um fluxo constante;

Tipos de histria equilibrados: misture histrias funcionais e no-funcionais para garantir um fluxo constante de valor;

Dependncias: trate dependncias proativamente, para que o trabalho no fique impedido.

Kanban em 10 Passos

!

infoq.com/br 31

Ao trabalhar com um backlog tradicional, ou uma especificao de requisitos como a do modelo Cascata, contendo 50 itens ou mais, pode-se questionar quantos dos itens iro ser visualizados no quadro. No h regra geral. Algumas equipes acreditam que melhor visualizar toda a fila de entrada; outras mantm uma lista separadamente, em um local fsico ou ferramenta, e gradualmente vo puxando alguns itens mais importantes para o quadro.

Gosto de usar o iceberg como metfora para descrever essa poltica. Apenas o topo do iceberg fica visvel acima d'gua, mas quando removemos o topo (ou seja, puxamos os itens para o sistema), o gelo abaixo emerge para formar um novo topo. Ao mesmo tempo, manter um limite explcito de WIP na fila de entrada uma boa ideia, para que o trabalho em progresso no saia do controle.

Geralmente comparo um backlog com o piso superior no utilizado de uma casa. Caso se coloque l tudo o que se tem medo de jogar fora, h pouca chance de encontrar o que realmente se precisa quando necessitar. Mantenha o backlog enxuto e certifique-se que ele no esteja crescendo demais e saindo do controle.

Passo 7: Identificao de classes de servio Poucos questionariam a necessidade de tratamento especial de um problema que resulta em 10 mil usurios sem acesso ao sistema, causando perda de $10o mil por hora. Mas muitas vezes a importncia e prioridade de um item no so to claras. Como ter certeza que foi escolhida a melhor maneira de lidar com diferentes tipos de trabalho?

No Kanban, itens de trabalho so tratados de acordo com suas caractersticas. Esse tratamento diferenciado recebe o nome de "classe de servio".

Identificando tipos de trabalho

Um bom comeo identificar os diferentes tipos de trabalho. Por exemplo, quase todos os projetos de software possuem algum tipo de requisito, como histrias de usurio e casos de uso; tambm possuem defeitos. Todos esses seriam tipos de trabalho. E se pode quebr-los em subtipos. Veja alguns exemplos tpicos de tipos de trabalho:

Histrias de Usurio (Pequenas, Mdias e Grandes); Defeitos (Cosmticos, Crticos e Impeditivos); Relatrios Manuais; Edies Textuais; Tarefas de Suporte; Instalao.

Definindo classes de servio

O prximo passo depois de definir os diferentes tipos de trabalho determinar como sero tratados em seu sistema. Cada forma distinta de lidar com tipos diferentes uma Classe de Servio. Abaixo definimos quatro classes de servio:

Kanban em 10 Passos

!

infoq.com/br 32

Classe Padro:

Custo adicional: 0

Tipos de trabalho: Defeitos cosmticos, histrias de usurio

Tratamento especial: Nenhum

Classe Prioritria:

Custo adicional: $500

Tipos de trabalho: Defeitos crticos, histrias de usurio de alta prioridade

Tratamento especial: Ganha prioridade em todos os estgios

Classe de Prazo Fixo:

Custo adicional: $0-2000

Tipos de trabalho: Histrias de Usurio

Tratamento especial: Tem prioridade em todos os estgios, se o prazo estiver prximo; caso contrrio tratada como uma classe de servio padro. A implantao emergencial pode ser necessria.

Classe Urgente:

Custo adicional: $3000-5000

Tipos de trabalho: Defeito impeditivo

Tratamento especial: Rompe os limites do WIP, para todo o WIP existente; implantao emergencial

Em nosso sistema de entrega de software, uma classe de servio se diferencia de um tipo de trabalho comum, de acordo com o tratamento especial que recebe. Observe que sempre haver custos associados a algum tratamento especial, e medir o fluxo ir permitir fazer uma estimativa mais embasada. Qual o efeito do tratamento especial? Qual seu impacto nos demais itens do fluxo (considerando que se possa estimar o custo de atraso)? Quanto tempo mais, ao todo, ser gasto devido a mudanas de contexto e de implantaes prioritrias?

Uma boa ideia colher dados referentes a vrias semanas. Assim ser possvel chegar a uma melhor estimativa dos custos de tratar certos itens de forma especial. Ficar mais claro o efeito dos itens urgentes sobre o diagrama de tempo de ciclo e o quanto implantaes emergenciais atrapalham o fluxo e consomem recursos.

Em geral, uma boa ideia determinar um limite para o nmero de itens em classes no-padro em seu sistema. Leve em conta a regra: "se tudo urgente, nada urgente".

Visualizando classes de servio

H diversas formas de se visualizar classes de servio. Duas das mais populares so um cdigo de cores (Figura 18) e raias (Figura 19). Pode-se tambm usar uma combinao dessas duas formas.

Kanban em 10 Passos

!

infoq.com/br 33

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

Figura 19. Classes de servios visualizadas com raias

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

Kanban em 10 Passos

!

infoq.com/br 34

Passo 8: Gerenciamento do fluxo Ao chegar neste ponto, j estaremos operando em um ambiente gil e maduro. Visualizamos o fluxo de trabalho, o trabalho em progresso est limitado, polticas de qualidade esto estabelecidas, o fluxo est sendo medido. O prximo passo aprender a interpretar o sistema e tomar aes apropriadas quando houver oportunidades de melhoria.

Filtros de decises

Os filtros de deciso Agile e Lean, criados por David J. Anderson, sero teis para guiar nossas aes. Veja a seguir as questes/aspectos considerados por cada um.

Filtro de decises Agile

Estamos obtendo progresso mesmo com informao imperfeita?

Estamos encorajando uma cultura baseada em alta confiana?

Estamos tratando o WIP como um risco e no como um ativo?

Os dois primeiros itens do filtro so mais abrangentes; so utilizados para tomar decises mais bem embasadas, ao se enfrentar desafios e situaes difceis.

Filtro de decises Lean

Valor mais importante que fluxo

O fluxo mais importante que eliminao de desperdcios

Elimine desperdcios para melhorar a eficincia

O filtro de decises Lean diz, essencialmente, que o valor mais importante que o fluxo. Portanto, deve-se ter cuidado ao abrir mo do valor gerado para reduzir o tempo de ciclo. Isso comum em projetos geis, nos quais o valor de negcio e s vezes a qualidade so sacrificados apenas para conseguir que mais trabalho seja feito.

Em um dos piores casos que j presenciei, trs equipes trabalhando no mesmo produto precisaram fazer horas extras por trs meses. Quando perguntei porque isso aconteceu, a nica resposta que consegui foi que havia uma longa lista de funcionalidades a serem desenvolvidas, e de defeitos a corrigir. Quando perguntei sobre o objetivo de negcio, a maioria me olhou com olhar de interrogao. Consegui convencer o grupo de que havia necessidade de chegar a um acordo com o cliente sobre a viso para a entrega, em vez de trabalhar cegamente com base em uma longa lista e finalmente senti que estvamos indo na direo certa.

Depois de uma semana de muito trabalho e negociaes, os POs e o gerente de programa apresentaram uma nova viso. A maioria ficou satisfeita, mas uma pessoa perguntou: "Notaram que o quadro no tem nenhum item que nos aproxime dessa viso?" Apesar de terem tentado respond-lo com naturalidade, a vergonha estava estampada na cara de todos. A equipe tinha no mnimo dez itens em vrios estgios no quadro, e nenhum deles estava alinhado com a nova viso.

Kanban em 10 Passos

!

infoq.com/br 35

Terem trabalhado tantas horas extras, por tanto tempo, parecia ter sido um enorme desperdcio de tempo e recursos.

Foi uma lio valiosa. Pode-se ter o melhor sistema Kanban do mundo e um timo fluxo pela cadeia de valor inteira, mas se no houver ciclos de feedback com base na sua hiptese de valor, voc pode simplesmente estar gerando desperdcio com eficincia. Porm, o fluxo mais importante que eliminao de desperdcio; ento tenha cuidado ao trocar fluxo por uma maior utilizao de capacidade, por exemplo.

O momento de procurar eliminar desperdcios chega quando o valor e o fluxo j estiverem otimizados; mas lembre-se de prestar mais ateno ao produto do que s pessoas.

Com os filtros de deciso Agile e Lean em mente, vamos examinar alguns conceitos fundamentais na gerncia do fluxo em nosso sistema de entrega de software.

Otimizando o fluxo, no a utilizao

Ao procurar oportunidades de melhorias, evite pensar em termos de utilizao. Busque oportunidades para aumentar o fluxo de itens de trabalho passando pelo seu sistema, e faa perguntas como:

Os limites de trabalho em progresso (WIP) so adequados?

possvel diminuir o tamanho das histrias?

Existe alguma forma de identificar funcionalidades grandes, antes que entrem em seu sistema e acabem bloqueando a capacidade por longos perodos?

possvel equilibrar o tamanho das histrias de usurio para criar um fluxo mais contnuo?

Pode-se treinar a equipe visando flexibilidade, para evitar silos e aliviar gargalos?

Existem buffers adequados em seu sistema para lidar com variaes?

O foco est na otimizao do todo e no na otimizao de estgios individuais?

A otimizao do fluxo em vez da otimizao da utilizao est no corao do pensamento Lean.

Os fabricantes de veculos norte-americanos costumavam medir e premiar pessoas de acordo com a produo de portas, por exemplo mesmo que fossem ficar empilhadas em algum armazm. Como efeito, mquinas individualmente trabalhavam de forma rapidssima, mas a produo como um todo era mais lenta. Grandes armazns tornavam difcil a procura pelas peas ou de mov-las de uma parte a outra. E se tinha uma quantidade enorme de recursos financeiros presa em estoques.

O sistema Toyota de produo mudou completamente esse panorama. Mostrou que colocar o foco no produto final, e adequar a velocidade das mquinas individuais velocidade com que veculos saam da linha de produo (tempo ttico), trazia vantagens econmicas incontestveis.

O principal sempre pensar em termos de fluxo do produto final, e no em tornar mais rpidos os passos individuais. Infelizmente, muitos gerentes ainda do nfase muito maior em fazer as

Kanban em 10 Passos

!

infoq.com/br 36

pessoas trabalharem mais rapidamente, do que na qualidade e no fluxo do produto. Lembre-se sempre de observar o produto, e no as pessoas!

Em conversa recente com um cliente, em que todos estavam preocupados com a utilizao, surgiu a pergunta: "O que fazer para garantir que todos estejam sempre ocupados?", qual algum respondeu: "Tenho uma tarefa em que posso trabalhar sempre que no houver nada mais importante a fazer". Perguntei h quanto tempo vinha trabalhando naquela tarefa e qual o valor que gerava. "Trabalho nela h um ano, mas ainda no foi lanada, e nenhum valor foi gerado ainda". Um de seus colegas perguntou quando acreditava que poderia ser lanada. A resposta: "Devido a mudanas recentes em nosso portflio de produtos, provvel que a tarefa no faa mais sentido e seja descontinuada em uma semana ou duas". O resto do grupo riu e admitiu abertamente que esse no era um cenrio incomum na empresa.

Aliviando gargalos

A Teoria das Restries (TOC Theory of Constraints) prega que sempre haver um gargalo em um sistema, limitando o fluxo de produo. Apesar da TOC oferecer uma viso simplificada do fluxo e da forma de se lidar com os gargalos, ajuda a entender a importncia de ver o sistema como um todo, e de aplicar esforos onde geram mais valor.

A utilizao de um sistema puxado kanban torna aparentes os gargalos. Ser percebido visualmente o trabalho se acumulando nos estgios anteriores ao gargalo e ficando escasso em estgios posteriores. Uma reao comum, nesse caso, adicionar mais capacidade mas essa nem sempre a maneira mais efetiva de se lidar com gargalos. No se pode escalar pessoas como mquinas, e o possvel aumento de capacidade por meio de aumento de pessoal muitas vezes consumido por custos adicionais de coordenao e de treinamento. Vale lembrar a lei de Brook: "Adicionar mais gente a um projeto de software atrasado gera mais atraso."

Em vez disso, procure aes para proteger o gargalo de trabalho desnecessrio. Em um dos projetos de participei, identificamos que a equipe de POs representava o gargalo. Ficou claro que boa parte do tempo era gasta na investigao de defeitos e no apoio a usurios que no haviam recebido treinamento adequado para trabalhar com o sistema. Essas tarefas poderiam ser facilmente transferidas para outros integrantes da equipe de desenvolvimento. Decidimos ento fazer um rodzio dos desenvolvedores para realizar as tarefas, com isso retirando a sobrecarga no grupo que estava gerando o gargalo.

A alternativa de mais longo prazo seria procurar entender o que levou situao atual e melhorar os fluxos no sistema para torn-los mais intuitivos ou treinar melhor os usurios. A remoo de trabalho que no gera valor de longe a forma mais efetiva de aliviar gargalos.

Uma terceira alternativa seria investigar se havia impedimentos bloqueando itens de trabalho para a equipe de POs, o que poderia estar consumindo sua capacidade. Nesse caso, a equipe deveria fazer o que se chama de swarm (esforo concentrado) para remover esses impedimentos o quanto antes.

No livro "Kanban", de David J. Anderson, so apresentadas outras maneiras de se lidar com gargalos.

Kanban em 10 Passos

!

infoq.com/br 37

Introduzindo buffers

Se voc sabe que existe um gargalo no sistema, uma boa ideia proteg-lo com um buffer logo antes. Se, por exemplo, seu gargalo for o desenvolvimento, um estgio de buffer com itens "Prontos para desenvolvimento" poderia ser adicionado. Escolher o tamanho correto para o buffer exige experincia. Se o buffer esvazia frequentemente, duas vezes por semana, por exemplo, recomendvel aumentar o seu tamanho ou avaliar se o estgio que est sendo protegido ainda um gargalo (pode ser que um estgio anterior seja o gargalo, porque o buffer est ficando vazio constantemente).

Planejando entregas

Apesar de ser chamado "Desenvolvimento de Produtos", a maioria das equipes que trabalham atualmente com desenvolvimento de software desenvolvem suas atividades sob as restries da gerncia de projetos custo, tempo e escopo. Pensar apenas em termos de fluxo muitas vezes uma abordagem ingnua, j que haver gerentes ou diretores que esperam respostas a questes como: Estamos no prazo? Os custos esto dentro do esperado? Podemos entregar o escopo combinado?

Para chegar a essa situao, duas coisas precisam ser feitas. Primeiro, deve-se concordar que, como no se pode fixar as trs restries ao mesmo tempo, o escopo ir ser flexvel. Atrasar uma data combinada difcil e comumente significa muito tempo gasto em reorganizao, coordenao e comunicao. Por outro lado, aumentar o oramento com o aumento de pessoal tambm, conforme j vimos, raramente uma boa ferramenta para atingir um prazo apertado. Adicionar pessoas um movimento estratgico de longo prazo. Aumentar o oramento no significa aumentar o nmero de pessoas, e sim aumentar a quantidade de horas que as pessoas trabalham. Isso pode ser uma ferramenta til se houver apenas uma semana de prazo. Mas em todas as outras situaes, vale lembrar a declarao de Kent Beck, de que caso se tenha um problema que no pode ser resolvido com uma semana de horas extras, o problema no deve ser resolvido com horas extras.

comum que gerentes de projeto utilizem horas extras como ferramenta desesperada para mostrar que esto tomando alguma atitude. Os gerentes sabem que no resolvero os problemas dessa forma, mas fazem assim mesmo para mostrar algum tipo de ao. So raros os casos em que alterar o prazo a soluo correta. Em caso de dvida, o melhor manter o escopo flexvel.

Em segundo lugar, preciso entender o que "escopo flexvel" um conceito que costuma ser interpretado como abordagem "deixe fazer" no desenvolvimento de software, com pouca ou nenhuma disciplina. Contudo, trabalhar com escopo flexvel exige justamente o contrrio. Deve haver tanto disciplina quanto habilidade de medir o progresso com preciso, para garantir que so bem fundamentadas as decises tomadas em um ambiente de mudanas contnuas. Esse um fator fundamental para trazer o melhor retorno sobre investimento (ROI) possvel.

Sabemos que nossas estimativas originais, em termos de complexidade, custo e valor para o negcio, foram feitas no momento em que tnhamos poucas informaes disponveis. Ainda assim, nossos prazos e custos esto apoiados sobre essas suposies. Portanto, fundamental medir nosso progresso para ter certeza que o projeto ainda vivel.

Kanban em 10 Passos

!

infoq.com/br 38

J que estamos utilizando diagramas CFD, por que no us-los para medir tambm o progresso? Os oramentos, na maioria, so feitos com base em entregas; por isso vamos ver um exemplo desse tipo. Ao ter um oramento, um prazo e um escopo inicial, simplesmente desenhamos nossa velocidade esperada no CFD e medimos nosso progresso com base nela.

Lembre-se que a maioria dos projetos gera uma curva em S, e que os desvios, como regra geral, indicam que h mais informaes disponveis do que havia antes. Somos, portanto, capazes de tomar decises mais bem embasadas (inclusive a de encerrar o projeto).

Figura 20. Planos de entregas visualizados no diagrama de fluxo cumulativo (CFD)

A Figura 20 mostra um exemplo real de curva S sobre um grfico CFD. Como se v, era esperado que o backlog crescesse por volta de 40% (com base em experincia) de 28 para 40 pontos. Mas em determinado momento, ele havia mais que duplicado de tamanho (57 pontos). Apesar de a imagem mostrar que se comeou com uma velocidade acima do esperado, a velocidade caiu depois da metade da release, devido a problemas de qualidade.

Experimente!

Gerenciar o fluxo tambm significa tentar melhorar continuamente (visto em mais detalhes no Passo 10). Muitos projetos fazem isso s cegas, sem ter como saber se as alteraes foram de fato bem sucedidas.

Kanban em 10 Passos

!

infoq.com/br 39

Infelizmente, muitos projetos geis esto nessa categoria. As retrospectivas so utilizadas para estabelecer experimentos, mas o acompanhamento (quando ocorre) apenas inclui verificar que o experimento foi conduzido. claro que sempre haver boa dose de incerteza, mas de forma mais frequente do que se pensa, as mtricas citadas neste livro oferecem indicao visual clara de que algo funcionou ou no.

Por exemplo, considere o caso em que voc decide incluir mais analistas de teste equipe de desenvolvimento, para fazer mais testes com antecedncia. esperado que haja uma queda no ndice de defeitos em um prazo razovel, e ento se possa trabalhar com um limite de WIP menor para o estgio de testes.

Gerenciar o fluxo significa ser capaz de interpretar seu sistema de software, para tomar as melhores decises possveis com a informao disponvel, em busca do maior retorno sobre o investimento.

Figura 21. Alivie gargalos para melhorar o fluxo

Passo 9: Estabelecer SLAs Nesse ponto, j estamos adiantados na direo de estabelecer um sistema de entrega de software efetivo e confivel, e o momento de mostrar os resultados para o pblico externo. Possuir um sistema puxado estvel, e utilizar mtricas simples para medir o desempenho do sistema, torna possvel estabelecer acordos de nveis de servios (SLAs) que realmente so cumpridos. Isso ajuda a manter o sistema saudvel e evita a tradicional recada de se voltar ao caos e ao apagamento de incndios, a partir do momento que a iniciativa Kanban deixar de ser novidade. Ento como funciona?

Estabelecendo o SLA correto

Diferentemente das abordagens geis tradicionais como o Scrum, que valorizam muito a previsibilidade por meio do compromisso do Sprint, um sistema kanban pressupe que a

Kanban em 10 Passos

!

infoq.com/br 40

previsibilidade ser adquirida por meio de um sistema de entrega de software que funciona de forma previsvel. Existe uma diferena sutil nessas duas abordagens em relao previsibilidade, a qual no deve ser subestimada. Os mtodos geis so orientados por um plano; os sistemas kanban, so orientados pelo fluxo.

Caso cada classe de servio tenha tratamento especfico e consistente ao longo do tempo, e as consequncias dos esforos de melhoria sejam medidas, grande a possibilidade de que o tempo de ciclo e a qualidade e os custos melhorem com o tempo. Tais informaes podem ser compartilhadas com seus clientes. As classes de servio mencionadas anteriormente poderiam ter SLAs semelhantes aos exemplos abaixo:

Classe Padro SLA:

Mdia: 15 dias 90% dentro do prazo de 21 dias Todas no prazo mximo de 30 dias

Classe urgente SLA:

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

Classe de prazo fixo SLA:

98% dentro do prazo Classe prioritria SLA:

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

O fundamental aqui que os nmeros so baseados em informaes colhidas por meio do acompanhamento do desempenho de nosso sistema de entregas. Caso surja a necessidade de informaes mais detalhadas, podemos facilmente ajustar as mtricas. Se, por exemplo, as classes padro variarem muito em tamanho, pode-se adicionar detalhes para mostrar aos clientes o efeito direto dessa variao como nos exemplos a seguir.

Classe padro

SLA 200-300 pontos (grande): Mdia: 15 dias 90% dentro do prazo de 21 dias Todas no prazo mximo de 30 dias

Kanban em 10 Passos

!

infoq.com/br 41

SLA 100-200 pontos (mdia):

Mdia: 13 dias 90% dentro do prazo de 18 dias Todas no prazo mximo de 25 dias

SLA 10-100 pontos (pequena):

Mdia: 14 dias 90% dentro do prazo de 14 dias Todas no prazo mximo de 18 dias

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

Figura 22. Polticas para classes de servios afixadas ao lado do quadro

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

Kanban em 10 Passos

!

infoq.com/br 42

A grande distribuio de informaes com a visualizao do fluxo de trabalho e de polticas explcitas, alm dos SLAs para cada classe de servio, grande incentivo ao dilogo constante sobre oportunidades de melhoria muito alm do que se v em projetos de software tradicionais. Todos os dias, somos obrigados a realizar decises explcitas sobre como lidar melhor com o trabalho. O aumento na irradiao de informaes tambm constitui boa base para a melhoria contnua. E parece haver um entendimento mais profundo dos conceitos do Agile e do Lean, de quem trabalha em um sistema Kanban; portanto mais difcil acontecer retrocessos para um processo anterior, ou a adoo de algum antipadro.

Como so coletados dados reais, o Kanban tambm oferece a oportunidade de executar e validar experimentos de forma mais cientfica, em comparao ao que acontece em projetos geis tradicionais. As iniciativas para melhorar o tempo de ciclo geralmente resultam em efeitos mensurveis. Isso torna a melhoria contnua em um sistema kanban muito mais confivel e consistente. E como podemos ver e medir os efeitos das iniciativas de mudana, ficamos muito mais suscetveis a aumentar a exigncia quanto qualidade do sistema de entregas.

Para algumas pessoas, trabalhar com Kanban faz com que vejam pela primeira vez o sistema de entregas como um todo, o que d uma percepo profunda do trabalho das outras pessoas, e de como dependem de voc e vice-versa. Tambm surgem oportunidades de otimizar no apenas silos individuais, mas todo o sistema de entregas.

Apesar de os crculos espontneos de qualidade (o termo Lean para discusses entre membros da equipe) serem excelentes veculos para a melhoria contnua, muitas equipes usando Kanban podem tambm se beneficiar de uma cadncia regular de retrospectivas (eventos Kaizen, na terminologia Lean). As retrospectivas do oportunidade equipe de ver o trabalho de outra forma; permite que surjam sugestes para mudanas estruturais maiores, conhecidas no Lean como Kaikaku (mudana dramtica). A combinao de crculos de qualidade, reunies dirias e uma cadncia de retrospectivas, forma um coquetel poderoso em prol de melhorias.

Como mencionado anteriormente, um fator fundamental na obteno desses efeitos se ater regra "Mude suas polticas; no as quebre". Se as pessoas no agem de acordo com as polticas da equipe, o sistema de entregas provavelmente ir se degradar com o tempo e no ser possvel ver o verdadeiro valor de se visualizar o trabalho.

Frequentemente me perguntam se o Kanban no serviria como desculpa para voltar a prticas disfuncionais, dada ausncia de regras para garantir o uso de prticas Lean ou Agile. Embora eu compreenda a lgica por trs das perguntas, no tenho esse receio.

O Kanban uma forma nica de catalisar os princpios do Agile e do Lean, mesmo em situaes em que aparentemente impossvel faz-lo. As poucas vezes que presenciei o Kanban falhar foram devido falta de apoio da gerncia, que em alguns casos at mesmo trabalhou contra o processo. Ou onde no houve esforos para explicar a importncia de visualizar o trabalho, gerenciar o fluxo e obter feedback.

Para ser bem sucedido com Kanban, necessrio o comprometimento da gesto. Alm disso, as pessoas que esto adotando os princpios em seus trabalhos dirios devem entender sempre porque isso faz sentido. Quando tais aspectos esto presentes, no h razo para esperar que a

Kanban em 10 Passos

!

infoq.com/br 43

iniciativa ir falhar, ou que o sistema ser usado para desfazer iniciativas de mudanas anteriores, ou regredir para prticas antigas e disfuncionais.

Boa sorte na sua jornada! Espero que estes captulos possam ter inspirado voc a avanar na sua jornada Agile e Lean e a usar o Kanban nos projetos de sua empresa. Adoraria receber seu feedback sobre esse trabalho, assim como conhecer experincias suas sobre como o livro pode t-lo ajudado a obter um retorno de investimento melhor para voc e os seus clientes.

Para se aprofundar em Kanban, sugiro entrar nos grupos de Kanban "kanbandev" e "kanbanops" do Yahoo Groups, para participar de discusses sobre a aplicao do Kanban na prtica. Uma forma de aprofundar ainda mais o conhecimento atravs da leitura dos seguintes livros:

Kanban, David J. Anderson, 2010

The Principles of Product Development Flow: Second Generation Lean Product Development, Donald G. Reinertsen, 2009

The Elegant Solution: Toyotas Formula for Mastering Innovation, Matthew may, 2008

Lean Thinking: Banish Waste and Creaste Wealth in Your Corporation, James P. Womack and Daniel T. Jones, 2003

The Toyota way: 14 Management Principles from the Worlds Greatest Manufacturer, Jeffrey Liker, 2004

The Lean Startup: How Constant Innovation Creates Radically Successful Businesses

Boa sorte!

Jesper Boeg jbo@trifork.com

Kanban-CapaInfoQBrasil-Kanban10Passos