Do que se trata o artigo:

Neste artigo será apresentado o método Kanban, uma interessante e simples abordagem para monitoramento e melhoria de processos de software que tem uma forte inspiração no Sistema Toyota de Produção.


Em que situação o tema é útil:

Se a sua empresa ou a sua equipe está com dificuldades para melhorar a forma de trabalho, não importando se ela usa ou não métodos ágeis, o Kanban pode ser uma das melhores alternativas para fazer isso com o mínimo de resistência. Além de ser um método muito simples, comparado à maioria das metodologias/frameworks de desenvolvimento atuais, suas propriedades promovem a colaboração.

Resumo DevMan:

O método Kanban para desenvolvimento de software a cada ano ganha mais destaque na indústria de TI, pois vem conseguindo promover a melhoria contínua no processo de trabalho de muitas equipes de empresas das mais variadas áreas de negócio e tamanho.

Nesse artigo é apresentada uma introdução ao método Kanban, destacando os seguintes tópicos:

  • Histórico e as motivações que levaram David Anderson a fazer a adaptação do método da indústria de manufatura (Toyota) para a indústria de software;
  • As cinco propriedades centrais e o funcionamento do método;
  • Kanban pode ser considerado um método ágil?
  • Um guideline para ter sucesso com o método Kanban, focando principalmente no que deve ser priorizado para se obter as melhorias mais significativas mais cedo.

Não há mais dúvidas de que a indústria de software é uma das mais importantes atualmente. O mercado brasileiro de software e serviços de TI, segundo o último relatório da ABES [9], é de US$ 19 bilhões e cresce de 25% a 30% ao ano desde 2004. Porém, grande parte do software produzido ainda é defeituoso, inadequado aos desejos do cliente, entregue fora do prazo e acima dos custos esperados.

Observando esses e muitos outros problemas, há mais de 10 anos, 17 profissionais da área escreveram e assinaram um manifesto: o manifesto para desenvolvimento ágil de software. Neste, todos concordaram com alguns valores comuns, dentre eles:

  • As metodologias ágeis concentram-se nas pessoas envolvidas na produção;
  • Os planejamentos em longo prazo são falhos;
  • É mais importante aceitar e adaptar-se a mudanças do que seguir planos rígidos;
  • Software funcionando é o melhor indicador de progresso nos projetos de software.

Tendo como base grande parte dos princípios desse manifesto, bem como a filosofia Lean do Sistema Toyota de Produção (TPS – Toyota Production System), surgiu o Kanban para Desenvolvimento de Software.

A filosofia Lean tem como objetivo a constante identificação e a eliminação de qualquer espécie de desperdício no sistema de produção.

A história do Kanban para desenvolvimento de software, assim como a história da grande maioria das metodologias, modelos de maturidade, processos de desenvolvimento e processos em geral, começa com um grande desejo, muitas ideias, testes (na prática) e diversos ajustes (o método “científico”) até atingir os primeiros casos de sucesso.

A principal diferença do Kanban para as demais metodologias de desenvolvimento de software atuais é que ele foi um modelo adaptado de outra indústria, a de manufatura, mais especificamente da Toyota. David Anderson [1] foi o grande responsável por essa adaptação.

A história começa em 2002, quando Anderson, cansado de ver equipes de desenvolvimento e departamentos inteiros de TI à mercê de outros departamentos, decide voltar seus esforços para responder a duas perguntas [1]:

  1. Como proteger a minha equipe da demanda incessante de negócio e alcançar o que a comunidade ágil chama de ritmo sustentável?
  2. Como adotar uma abordagem ágil em toda a empresa e superar inevitáveis resistências à mudança?

Como cita em seu último livro, Kanban: Successful Evolutionary Change for Your Technology Business [1], publicado em 2010, Anderson tinha um grande desejo: encontrar no setor de TI uma relação “ganha-ganha” entre o departamento de negócio e as equipes de desenvolvimento de software e TI.

Na tentativa de atingir esses objetivos, David idealizou, testou e falhou muitas vezes nas diversas organizações em que trabalhou. Ele notou que implantar um processo de desenvolvimento de software totalmente prescritivo, na maioria das vezes, não funcionava. Assim, chegou à conclusão de que um processo precisava ser adaptado para cada situação, e que para fazer isso, era necessária uma liderança ativa em cada equipe. Porém, esta era muitas vezes inexistente. E, mesmo com uma liderança certa, ele duvidava que mudanças significativas acontecessem sem uma metodologia ou, no mínimo, sem orientações de como adaptar o processo para atender a diferentes situações.

...
Quer ler esse conteúdo completo? Tenha acesso completo