A ferramenta Kanban

Kanban é uma ferramenta bem popular entre os times de desenvolvimento de software que utilizam metodologias ágeis no desenvolvimento. Hoje o Kanban é extremamente popular, mas suas origens datam de mais de 50 anos atrás.

 

No final dos anos 40, a Toyota começou a otimizar os processos de engenharia tomando como base o mesmo modelo que os supermercados usavam para organizar suas prateleiras. Os supermercados apenas deixam à mostra o suficiente para suprir as demandas do consumidor; essa prática otimiza o fluxo entre supermercado e consumidor. Já que a quantidade de produtos nas prateleiras deve estar sempre alinhada com a necessidade do consumidor, o supermercado ganha eficiência significativa no gerenciamento das prateleiras, ao diminuir a quantidade de estoque gerenciado por cada time. Enquanto isso, o supermercado ainda assegura que um determinado produto sempre esteja ao alcance do consumidor.

 

Quando a Toyota aplicou esse mesmo sistema no seu chão de fábrica, o objetivo era alinhar melhor seu gigantesco estoque com o consumo verdadeiro de materiais. Para comunicar os níveis de capacidade em tempo real ao chão de fábrica ( e aos fornecedores ), os operários passavam um cartão, ou “kanban” entre os times. Quando uma caixa de materiais usado na linha de produção se esvaziava, um kanban era passado para o almoxarifado descrevendo o material necessário, a exata quantidade desse material, e assim por diante. O almoxarifado deixava essa caixa de material esperando e a enviava para o chão de fabrica, e em troca, enviavam seu próprio kanban para o fornecedor. Enquanto a tecnologia ao redor desse processo evoluiu bastante desde a década de 40, esse mesmo processo de manufatura “just in time” ( JIT ) ainda é a alma dele.

 

Kanban para os times de desenvolvimento de software

 

Times de desenvolvimento ágil de software hoje, são capazes de usar esses mesmos princípios JIT ao corresponder a quantidade de trabalho em progresso ( WIP ) à capacidade do time. Isso dá aos times uma maior gama de opções no planejamento, resposta mais rápida, foco e transparência durante todo o ciclo de desenvolvimento.

 

 

Enquanto os princípios dessa ferramenta são atemporais e aplicáveis a quase qualquer tipo de indústria, os times de desenvolvimento de software viram que quando o assunto é desenvolvimento ágil, o Kanban é o maior sucesso. Isso ocorre, em parte porque os times consegue utilizar essa ferramenta com relativa baixa curva de aprendizado, uma vez que aprendidos os princípios básicos. E diferentemente de implementar o Kanban em um chão de fábrica, que envolveria mudanças em processos físicos e a adição substancial de materiais, a única coisa física que os times de desenvolvimento de software precisam, são cards e uma lousa; e ambos podem ser virtuais.

 

O quadro Kanban

 

O trabalho de todos os times de Kanban se resumem ao redor de um quadro Kanban. O quadro é um meio de visualizar o trabalho e otimizar o fluxo desse trabalho por todo o time. Enquanto quadros físicos são populares em alguns times de desenvolvimento, quadros virtuais são essenciais em qualquer time pela rastreabilidade, maior colaboração e acessibilidade de múltiplos lugares.

 

Independentemente de ser digital ou físico, a função do quadro é de assegurar que o trabalho do time consiga ser visualizado, seu fluxo de trabalho seja padronizado e todos os bloqueadores e dependências sejam imediatamente identificados e resolvidos. Um quadro básico de kanban them um fluxo de três passos:

 

  • To Do ( A fazer )
  • In Progress ( Em progresso )
  • Done ( Feito )

 

No entanto, dependendo do tamanho, estrutura ou objetivos do time, esse fluxo pode ser mapeado para satisfazer o processo único de um time em particular.

 

A metodologia kanban

 

A metodologia kanban se baseia na total transparência de trabalho e em comunicação em tempo real de capacidade; portanto o quadro kanban deve ser visto como a única fonte de verdade para o trabalho do time.

 

 

Cartões kanban

 

Em Japonês, kanban significa literalmente “sinal visual”. Para os times de kanban, cada item de trabalho é representado por um cartão separado no quadro.

 

O propósito principal de representar trabalho como um cartão no quadro de kanban, é permitir aos membros do time, o rastreio do progresso pelo fluxo de trabalho de uma forma altamente visual. Os cartões kanban contém informações críticas sobre um item de trabalho em particular, dando ao time total visibilidade sobre quem é o responsável por aquele item de trabalho, uma breve descrição do trabalho a ser realizado, quanto tempo estimado aquele pedaço de trabalho vai demorar, e assim por diante. Cartões em um quadro virtual de kanban normalmente também tem screenshots e outros detalhes técnicos que são valiosos para o cessionário ( aquele que é responsável pelo cartão em questão ). Ao permitir que os membros da equipe consigam ver o estado de cada item de trabalho em um ponto particular no tempo, assim como seus detalhes associados, consegue-se aumentar o foco, rastreabilidade e rápida identificação de bloqueadores e dependências.

 

Os benefícios do kanban

 

O kanban é uma das ferramentas de desenvolvimento ágil mais adotadas pelos desenvolvedores hoje. O kanban oferece várias vantagens adicionais no planejamento de tarefa para times de todos os tamanhos.

 

Planejar flexibilidade

 

Um time de kanban apenas foca no trabalho que está ativamente em progresso. Uma vez que o time completa um item de trabalho ( representado por um cartão ), eles removem o próximo item de trabalho do backlog. O product owner fica livre para priorizar novamente o trabalho do backlog sem atrapalhar o time, já que todas as mudanças fora do trabalho atual não impactam o time. Enquanto o product owner mantém os items de trabalho mais importantes no topo do backlog, o time de desenvolvimento assegura de entregar o melhor produto com maior valor possível para o negócio. Dessa forma não existe a necessidade de iterações de tamanho fixos como, por exemplo, no scrum.

 

Product owners experientes sempre conversam com os times considerando as mudanças do backlog; garantindo que não hajam surpresas ao fazer qualquer tipo de mudança no backlog.

 

Ciclos de desenvolvimento menores

 

Tempo de ciclo é uma métrica chave para os times de kanban. O tempo de ciclo é a quantidade de tempo que demora para uma unidade de trabalho viajar por todas as etapas do desenvolvimento de um time – de To Do até Done. Ao otimizar o tempo de ciclo, os times podem com confiabilidade prever a entrega de um trabalho futuro.

 

Times com habilidades que se complementam, levam a menores tempos de ciclos. Quando apenas uma pessoa possui uma habilidade necessária, aquela pessoa se torna o gargalo do fluxo de trabalho. Então os times aplicam práticas básicas como code review ( revisão de código ) e mentoria para espalhar o conhecimento entre todos. Habilidades compartilhadas significam que os membros do time pode pegar trabalhos heterogêneos, o que contribui para otimizar o tempo de ciclo; isso também proporciona um backup de trabalho. Dessa forma, caso haja algum problema com algum membro do time, todos os outros sabem fazer o que ele fazia.

 

No kanban, é responsabilidade do time inteiro assegurar que o trabalho se dá de forma suave por todo o processo.

 

Menos gargalos

 

Fazer muitas coisas ao mesmo tempo, matam a eficiência. Quanto mais items estão sendo feitos por um membro da equipe ao mesmo tempo, mais mudança no contexto, o que destrói por inteiro a eficiência do trabalho. Por isso, a chave para o kanban dar certo, é limitar a quantidade de trabalho em progresso (WIP ).

 

Métricas visuais

 

Um dos valores chave é um foco na melhora contínua na eficiência do time e sua eficácia em cada iteração de trabalho. Gráficos são um mecanismo visual para o time assegurar que estão em desenvolvimento contínuo. Quando os times conseguem ver dados, é mais fácil achar gargalos no processo e removê-los. Dois gráficos comuns no kanban são os diagramas de controle e de fluxo cumulativo.

 

Um diagrama de controle mostra o tempo de ciclo para cada item de trabalho assim como a média de tempo de término do time.

 

O objetivo do time é reduzir a quantidade de tempo que demora para um card se mover por todo o processo. Ver uma queda na média de tempo que demora para mover um card da equipe é um indicador de sucesso.

 

 

Um diagrama de fluxo cumulativo mostra o número de problemas em cada estado. O time pode identificar facilmente os bloqueios ao ver o número de cards aumentando em um determinado estado ( To do, In progress, Done ). Problemas em estados intermediários como In Progress ou In Review não são ainda enviados ao consumidor final, e um bloqueio nesses estados pode aumentar a probabilidade de conflitos na hora da integração.

 

 

Scrum vs. kanban

 

O kanban e o scrum compartilham dos mesmos conceitos mas tem diferentes abordagens. Não devemos confundir um com o outro.

 

SCRUM KANBAN
Cadência Sprints de duração regulares ( ex: 2 semanas ) Fluxo contínuo
Metodologia de lançamento No final de cada sprint, se for aprovado pelo product owner Entrega contínua, ou quando o time quiser
Papéis Product owner, scrum master, time de desenvolvimento Não existem papéis definidos.
Métricas chave Velocidade Tempo de ciclo
Filosofia de mudança Times devem tentar não fazer nenhuma mudança na previsão de tempo durante o sprint. Fazer isso irá comprometer o aprendizado durante o processo de estimar prazos. Mudanças podem ocorrer a qualquer momento

 

Alguns times misturam as idéias de kanban com as idéias do scrum, e há quem chame isso de “scrumban”. Mas é recomendável que os times, principalmente em estágios iniciais, se atenham a uma das duas metodologias. Sempre há a possibilidade de misturar depois.

 

Texto Traduzido do blog da Atlassian.

Cesar Vargas