Kanban na Yamí

O que o Japão tem a ver com a Yamí?

Tudo a ver!

A partir de um estudo feito pela Toyota sobre supermercados e suas técnicas de “prateleiras”, com o objetivo de aplicar essas ideias nos processos de fábrica, foi criado o método de gestão Kanban.

E nós da Yamí, nada bobos, também copiamos esse método!

Agora antes de falar dos nossos processos, é importante termos ciência de onde surgiu o Kanban.

Eles perceberam que os funcionários apenas reabasteciam as prateleiras quando o produto estava perto de se esgotar, o espaço para cada item era limitado e por isso somente quando necessário novos itens eram adicionados. Observaram que em um supermercado, os clientes obtinham somente a quantidade necessária do produto que desejavam e no momento necessário, ou seja, nem mais nem menos. Essas observações fizeram os engenheiros da Toyota visualizar um processo que refletia de acordo os processos anteriores, por exemplo, uma peça poderia ser produzida se a anterior a ela já estivesse vendida. A Toyota passou então a utilizar um kanban (ou seja, um cartão visual) para sinalizar passos em seus processos de fabricação. A forte natureza visual do sistema Kanban permitiu que as equipes se comunicassem com mais facilidade, organizando e melhorando o que e quando deveria ser feito. (Site Cultura Ágil)”

O Kanban está relacionado com o conceito de Pull Systems (sistemas de produção puxados), ou seja, tem por objetivo iniciar a produção quando um item é vendido, gerando demanda para a fabricação de outro, assim cada operação do processo é alimentada pela demanda da etapa anterior.

 


E como que esse tal de Kanban foi parar no mundo de desenvolvimento de software?

Em setembro de 2006 David J. Anderson, diretor sênior de engenharia da Corbis (empresa fundada por Bill Gates) teve a ideia de utilizar o sistema Kaban para a gestão de atualização de aplicativos. E com o passar dos anos, ele e sua equipe foram aprimorando o sistema.

 

OK, mas o que é o Kaban? Como ele pode ajudar no desenvolvimento?

O kanban é um método de desenvolvimento de software e uma forma de implementar o método ágil na execução de um projeto.

O kanban ajuda tanto o gestor de projetos, quanto os desenvolvedores e todos as partes interessadas do projeto a compreender e controlar os processos de execução das atividades do projeto de forma visual e prática.

Normalmente para conceber o Kanban é utilizado um quadro branco com post-it’s colados, representando as tarefas. Ao término da execução da tarefa dentro daquela etapa, a tarefa é puxada para a próxima etapa, até que seja finalizada, na última etapa.

O legal do Kaban é que a visibilidade proposta pelo método permite:

  •  Ver o projeto fluindo. Você consegue ver o andamento do projeto, o que realmente está sendo feito, aonde pode ocorrer um gargalo e qual atividade exige maior foco da equipe.
  •  Transparência, Comunicação e Colaboração. O kanban permite uma visão global do projeto, ou pelo menos da Sprint. A equipe, portanto, tem ciência do status do projeto e se vê contextualizada quanto as demandas do projeto, a execução de cada tarefa, os impedimentos, e os resultados. Naturalmente essa visão proporciona transparência, comunicação e colaboração.
  •  Incentiva o aprendizado e a melhoria contínua. Entendendo como o trabalho está fluindo, é possível identificar as tarefas que exigiram mais esforço que o previsto. Desta forma, a equipe pode transformar o provável problema em uma oportunidade factível. Como? Aprendendo e aplicando a melhoria contínua.
  •  Aumento da produtividade. A equipe consegue focar no que deve ser feito para entrega da sprint e o GP consegue agilizar o que é necessário para equipe produzir.

Ainda sobre a colaboração, esse é o principal ganho para a Yamí. Trabalhar em conjunto e de forma colaborativa e participativa melhora nosso humor e nossa autoestima, conduzindo-nos a trabalharmos mais motivados, elevando nossa produtividade. :-)

 


E o Kanban na Yamí?

Ah, isso é simples, adotamos o método associado a metodologia ágil Scrum.

As tarefas fazem parte das Sprints, bem como dos boards (etapas/fases).

Dependendo do Projeto trabalhamos de 3 a 5 boards, que seguem listados abaixo:

  • To Do (A Fazer): são as Tasks da Sprint Vigente que estão na fila para serem executadas. Quem adiciona as tasks a esse board é o GP.
  • Doing (Fazendo): são as Tasks da Sprint Vigente que estão em execução. Quem adiciona as tasks a esse board é a equipe, juntos, na reunião da Daily Scrum.
  • Doing – Falta validação GP (Fazendo): são as Tasks da Sprint Vigente que a execução foi finalizada, mas que falta a validação do GP.

O desenvolvedor deve anexar na atividade uma evidência da sua finalização, marcar a atividade como concluída e move-la para esse board.

O GP deve validar a atividade e a evidência.

Se necessário o GP deve efetuar testes integrados ou validar junto ao cliente.

*Board Opcional

  • Done – Subir para Produção (Feito): são as Tasks da Sprint Vigente que estão finalizadas e validadas, porém estão aguardando para subirem em produção. Quem adiciona as tasks a esse board é o GP.

*Board Opcional

  • Done – Produção (Feito): são todas as tasks que estão em produção. Quem adiciona as tasks a esse board é quem efetua a subida em produção ou o GP.

 

O post te ajudou? Ou só te deixou mais curioso sobre como trabalhamos?

Fique a vontade para entrar em contato <3

Fonte consulta: https://www.culturaagil.com.br/kanban-do-inicio-ao-fim/


Isto ajudou o seu problema?