Kanban – Além da Teoria

Caro leitor,

Antes de iniciar a sua leitura, sugiro que leia o meu post anterior sobre a introdução a metodologia Kanban.

O objetivo deste post é apresentar a comunidade ágil uma visão sistêmica e operacional de um sistema Kanban. Desta forma, estarei pulando a parte “filosófica” e irei direto ao ponto de como implementar um modelo Kanban em sua operação.

A implementação de um sistema Kanban pode ser dividida em três etapas, sendo elas:

1 – Planejamento

carrinho-de-compras-635x476

Nesta etapa, iremos em busca dos ingredientes do nosso sistema, começando pelo quadro.

Kanban Board

simle-kanban-board

O Kanban board é o reflexo do seu fluxo e processo de trabalho, evidenciando as etapas necessárias para a entrega de um item, requisição ou resolução de um incidente em produção. O board também oferece gestão a vista, naturalmente expondo fontes de gargalo e variações do seu sistema. A maioria das equipes adotam o uso do quadro físico ao implementar um sistema Kanban, porém, também há equipes maduras e auto-organizadas que usam quadros virtuais. Eu particularmente prefiro o quadro físico, é mais tangível :D.

Definindo a estrutura da equipe

equipe-kanban

Este é um dos passos mais importantes, como mencionado no meu post anterior, o Kanban é uma metodologia ágil e fluida, é preciso pensar em uma estrutura de equipe e processo que mantenha o seu sistema operante e sem interrupções, assim como o sistema cardiovascular de um individuo.

Pensando assim, busquei referências para montar um modelo de equipe em vários lugares, um deles sendo o livro “Kanban – Mudança Evolucionária de Sucesso para seu Negócio de Tecnologia” do David J. Anderson (pioneiro na aplicação do sistema Kanban na engenharia de software) e cheguei ao seguinte esboço:

  • Kanban Master – Profissional responsável por garantir a fluidez do sistema, tratar impedimentos, gargalos e garantir que o processo de desenvolvimento de software e níveis de acordo da equipe sejam atendidos com maestria. Indispensável no começo até a equipe se tornar madura e auto-organizada. Pode ser utilizado como um “Kanban Coach” após atingir este ultimo objetivo, ajudando a equipe a aprimorar o processo, regras, politicas e SLAs existentes.
  • Proxy – Profissional responsável pelo atendimento de primeiro nível da equipe, no caso, registrar os tickets que entrarem durante o dia de trabalho, levantamento e ordenação constante das demandas junto com a área de negócio, alimentar o backlog e a fila de buffer da equipe.
  • Engenheiro de Software – Profissional responsável por executar os tickets presentes no buffer da equipe, respeitando o processo de desenvolvimento e atendendo os níveis de acordo pré-estabelecido.

Work in Progress (WIP ou Limite de Trabalho em Progresso)

limit-wip-flow-on

Como mencionado em meu post anterior, o Kanban trabalha com um sistema puxado, isto quer dizer que um novo trabalho é puxado para dentro do sistema assim que outro for concluído e não empurrado sob demanda. Esta prática otimiza a entrega de demandas, aumenta o foco na qualidade da entrega e evita a carga esmagadora de trabalho sobre o seu sistema. Apenas limitar o trabalho em progresso não garante o sucesso do seu Kanban, para isto, é necessário estabelecer regras (iremos falar sobre a diante).

A minha recomendação é de limitar o WIP em até dois tickets por profissional. As etapas do seu sistema Kanban também devem ter uma limitação WIP, neste caso, esta limitação pode variar de acordo com a equipe e com as dinâmicas e politicas de trabalho que você escolher. Este numero pode ser reajustado com o tempo.

Definindo um acordo de nível de serviço (SLAs)

service-level-tracking

Antes de prosseguirmos, sugiro a leitura deste post para um melhor entendimento sobre os acordos de níveis de serviço.

Na engenharia de software, é necessário passar um “prazo” constantemente para os nossos clientes, independente do modelo de gestão ou metodologia de trabalho que você adote para a sua operação, a pergunta é sempre a mesma, quando é que fica pronto?

No Kanban, trabalhamos com os SLAs. O SLA vem para fornecer uma perspectiva para o seu cliente e garantir que um problema critico em produção seja resolvido em tempo hábil de forma a minimizar possíveis falhas nos serviços ou até mesmo prejuízo.

Nem sempre conhecemos a nossa operação profundamente e os sistemas que ali são atendidos, mesmo assim, o importante é ter um SLA inicial e acordar este com o cliente. Vale a pena também reiterar que este é um ponta pé inicial, sendo necessário o ajuste no nível de atendimento de forma continua, visando sempre a melhoria do atendimento.

Classes de Serviço

classes de serviço

Como já é de conhecimento, o Kanban trabalha com um sistema puxado onde o Engenheiro de Software sempre puxa o próximo item da fila. Durante o dia a dia de trabalho, nos deparamos com problemas críticos que surgem do nada. Como devemos proceder sendo que trabalhamos com um sistema puxado onde sou orientado a executar um item até o final? As classes de serviço servem para segmentar o que tem mais prioridade dentro de um sistema Kanban.

Classes de serviços que compõem um sistema Kanban:

  • Demandas – melhoria em uma determinada funcionalidade de um sistema.
  • Incidentes – interrupção de um determinado serviço não programada. Esta classe de serviço pode ser segmentada em diversos níveis  de criticidade, por exemplo:
    • Incidentes que afetam apenas 1 usuário.
    • Incidentes que afetam um grupo de usuário, porém, há como contornar.
    • Incidentes que afetam um grupo de usuário e não há solução de contorno.
    • Incidentes que afetam toda a operação (crítico).
  • Problemas (BugFix) – solução fundamental de um evento recorrente que causa impacto na operação.
  • Requisições de Serviço – alteração de conteúdo que não demanda nenhuma interrupção de sistema ou implantação e que podem ser feitas durante o horário comercial.
  • Expedição (Bala de prata) – alteração de conteúdo emergencial, como por exemplo, remoção de algum tipo de conteúdo não comercializado. É importante criar regras para esse tipo de classe de serviço, conscientizar e acordar datas pré-definidas para evitar um impacto no fluxo do sistema.
  • Product Backlog Item (PBI) – nova funcionalidade para um determinado sistema. este tipo de classe deve entrar no sistema Kanban apenas se a estimativa não extrapole duas semanas. É recomendado que este tipo de classe entre em projeto caso extrapole a estimativa de duas semanas.

Politicas e Regras do sistema Kanban

Signs

Por quê precisamos de politicas e regras em um sistema Kanban?

Para garantirmos a fluidez do nosso sistema, algumas regras precisam serem definidas e em seguida, devem ser compartilhadas com a operação, de preferência, visualmente em frente ao Kanban Board. Estas regras servem para blindar o sistema, os membros da equipe e orienta-los em como proceder em algumas ocasiões, exemplos:

  1. Você terminou uma task de implementação. O que você precisa fazer para que este item esteja pronto para ser entregue a área de qualidade e minimizar retrabalho?
  2. Você estava trabalhando em um ticket e se depara com um impedimento? Como proceder? Quem precisa saber? Como buscar uma solução? Enquanto espera, você deve puxar um novo ticket?
  3. Alguém do departamento de Marketing aparece gritando, correndo em chamas e falando a respeito de uma demanda urgente que deve entrar para execução no seu sistema Kanban. Como proceder?
  4. Estou trabalhando em uma demanda e acabo de receber um e-mail dizendo que o sistema está fora do ar. O que devo fazer? Qual a prioridade?

Estas regras devem ser compartilhadas também com a área de negócio.

Preparando a execução do sistema

plan

Tendo em mãos o meu Kanban Board, a minha equipe, o meu WIP definido, as minhas classes de serviço e regras do sistema definidas e acordadas com os meus clientes significa que estou pronto para começar a operação? Não, você não está pronto, ainda falta outro elemento importante, o planejamento.

O que é exatamente o planejamento? Quando começamos trabalhar em um projeto que já está em andamento, é comum recebermos um treinamento do membro mais experiente da equipe para depois assumir alguma ordem de trabalho. No sistema Kanban não é diferente, você está prestes a absorver um sistema que já está em plena operação em produção e por mais experiente que a sua equipe seja, ainda existe a necessidade de um repasse de conhecimento entre as equipes para que seja possível absorver e operar a sustentação de um sistema. Caso a sua equipe esteja absorvendo um sistema legado e sem documentação, é necessário acordar um tempo de análise, estudo e reconhecimento do sistema, para depois assumir a sustentação. Repita este ciclo para cada sistema que está prestes a entrar no seu sistema Kanban, estipule uma meta e inicie a operação.

2 – Execução

producao

Nesta etapa, podemos concluir que o nosso sistema Kanban já está em operação. Isto significa que o meu sistema consegue operar de forma auto-organizada? Já posso abrir uma cerveja? A resposta ainda é não. Este ainda é um momento crucial que requer bastante atenção. Neste exato momento, é possível que a sua operação esteja sendo pressionada pela área de negócio demandando uma previsão de entrega. Como lidar com esta situação? Você ainda não conhece a velocidade do seu time, como proceder?

Como medir a velocidade do meu time?

velocidade-time

É preciso monitorar o tempo de vida de um ticket desde a sua chegada no backlog da equipe e até o momento em que é entregue em produção. Esta métrica é chamada de “Lead Time“.

O que fazer com estas métricas de desempenho?

indicadores-de-desempenho

Deve ser estabelecido uma cadência de entrega de relatórios de desempenho da operação as áreas envolvidas, evidenciando o tempo de entrega e cumprimento de SLA para se aumentar a confiança com parceiros de um maior nível organizacional como product owners e diretores.

3 – Manutenção do Sistema

Ajuste-Inversiones-suspensiones-austeridad-empresario_CLAIMA20141012_0123_27

Neste ponto, podemos considerar que o nosso sistema está em pleno funcionamento. Quais são os próximos passos? O sistema Kanban traz a filosofia de melhoria continua, estamos prontos para inspecionar o nosso sistema Kanban, avaliar o rendimento do sistema, atacar fontes de variação e gargalos, promover melhorias na equipe, no processo, SLA, regras e politicas.

Para um entendimento mais profundo, recomendo a leitura do livro “Kanban – Mudança Evolucionária de Sucesso para seu Negócio de Tecnologia” do autor David J. Anderson (pioneiro na aplicação do sistema Kanban na engenharia de software).

 

Referências:

Livro”Kanban – Mudança Evolucionária de Sucesso para seu Negócio de Tecnologia“, David J. Anderson (pioneiro na aplicação do sistema Kanban na engenharia de software)

http://leankit.com/blog/2014/07/kanban-importance-of-process-policies/

 

 

 

 

 

 

 

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s