Get best of the week

Método Kanban: Compreendendo seu processo como um processo de aprendizado coletivo

Prefácio


Na comunidade profissional de gerentes de processo de língua russa, há muito pouca literatura sobre o método Kanban em russo. Decidimos corrigir essa injustiça e publicaremos os artigos mais significativos do nosso ponto de vista em russo, o que influenciou o desenvolvimento do método.

Entendendo seu processo como um processo de aprendizado coletivo


E o primeiro artigo da série sobre como criar com mais eficiência uma visualização de seus processos de trabalho e perceber um quadro. O autor do artigo original é Alexei Zheglov e pode ser encontrado aqui.

Há uma tendência geral e desejo de tornar o trabalho mais coletivo. No entanto, quando peço às pessoas no escritório que desenhem um processo de seu trabalho, elas geralmente fornecem algo assim (simplifico):


Nesta visão, os trabalhadores formam uma correia transportadora, mas seu trabalho não se parece realmente com uma linha de montagem. Por exemplo, um desenvolvedor de software pode detectar uma inconsistência lógica na especificação de requisitos e enviar o trabalho de volta à inteligência de negócios. Um engenheiro de qualidade (QA) pode fazer o mesmo ao testar o software criado. O analista atualizará a especificação e enviará a tarefa de volta ao controle de qualidade. O controle de qualidade pode encontrar um erro e enviá-lo de volta ao desenvolvedor. Um especialista em implementação pode encontrar algo no código que está impedindo a entrega. Em seguida, o desenvolvedor faz as alterações necessárias. Agora, o código precisa ser re-testado; portanto, ele retorna ao controle de qualidade, após o qual retorna à implementação.

Essa interação ocorre não apenas entre os membros da equipe, mas também (importante) entre departamentos corporativos, serviços e equipes multifuncionais. Portanto, as pessoas desenham muitas setas conectadas em diferentes configurações para mostrar todos esses programas.

Alguns estão tentando visualizar esse processo em um quadro que eles chamam de "kanban":


Depois, eles se perguntam: e se, por exemplo, o testador devolver o item de trabalho ao analista ou desenvolvedor? O cartão deve permanecer no lugar ou se mover? E se tivermos um limite WIP (esses números estão nos cabeçalhos das colunas)? E se essa coluna já estiver preenchida até o limite, outro cartão deve voltar?

Existe uma maneira melhor?


Essa pergunta é bastante comum e está enraizada em um mal-entendido da natureza do trabalho de serviço profissional. Em vez de uma série de transmissões entre trabalhos especializados, trata-se principalmente de criar informações e acumular conhecimento. Isso se torna um obstáculo ao tentar fazer com que o processo pareça um fluxograma. Bem como uma limitação ao tentar visualizá-lo, após a execução do trabalho.

No exemplo de entrega de novas funcionalidades de um produto de software, o seguinte conhecimento pode ser criado (não necessariamente nessa ordem):

  • configuração exata do ambiente de trabalho (SO, servidor web, servidor de banco de dados, software de terceiros)
  • exemplos-chave do comportamento da funcionalidade desenvolvida, casos de uso, critérios de aceitação, especificações executáveis ​​etc.
  • ( , . .)
  • -
  • : , , ..
  •   , .

Todos em qualquer serviço profissional podem criar sua própria lista de conhecimentos que eles criam em seu processo de entrega. Quando o trabalho é concluído, todo esse conhecimento já existe, mas quando estamos apenas começando a trabalhar nas necessidades do cliente ou na solicitação de fornecimento de algo, tudo isso está faltando.

Se tentássemos visualizar o processo de acumulação desse conhecimento, o resultado poderia ser assim:


Neste exemplo, o trabalho de especificação é dominante no estágio inicial do processo de entrega. Os analistas de negócios podem realizar uma análise funcional, decomposição e refinamento de requisitos. Mas, ao mesmo tempo, outros profissionais podem contribuir. Os testadores podem ajudar a transformar os critérios de aceitação em testes executáveis. Os especialistas e desenvolvedores de implantação podem avaliar o impacto na base de código e na infraestrutura.

Essa atividade gera muito conhecimento no início, mas no final desaparece. Não podemos analisar infinitamente todo o caminho até a entrega. Assim, o desenvolvimento do código em algum momento se torna a principal maneira de acumular conhecimento.

Obviamente, a maior parte do desenvolvimento de código recai sobre os ombros dos desenvolvedores, mas outros também podem ajudar. Os requisitos ainda podem precisar de esclarecimentos e esclarecimentos (olá analista). O testador pode pegar um software parcialmente pronto, testá-lo e fornecer feedback ao desenvolvedor. Os desenvolvedores podem colaborar com especialistas em implementação para ver como as mudanças emergentes afetarão a implantação.

Mas essa atividade desaparecerá. Não podemos fazer mais progressos polindo o código. Então, passamos a testá-lo.e concentre-se em resolver os erros restantes. Outra atividade no estudo do conhecimento começa a dominar. Os testadores são responsáveis ​​por isso, mas precisam de ajuda de desenvolvedores, correções de bugs e outros especialistas.

Observe que os três pontos de inflexão no novo diagrama de processo não são transferências entre especialistas ou departamentos funcionais. São mudanças na atividade dominante e mudanças correspondentes no padrão de interação.

Conclusão


Não precisamos considerar os processos como uma rede de especialistas e a transferência de autoridade. Quando tentamos visualizar nossos processos visualmente, não precisamos representá-los na forma de blocos representando especialistas e muitas setas conectando-os em todas as direções.

Em vez disso, podemos ver nosso processo de entrega como obtendo informações e criando conhecimento. Fazendo a nós mesmos a pergunta: quais ações realizamos para acumular conhecimento para entregar o que entregamos , podemos visualizar nosso processo como uma sequência de ações conjuntas.

Qual é o próximo?


Nos próximos artigos, gostaria de dar exemplos da reflexão do processo de acumulação de conhecimento, para processos fora do mundo do desenvolvimento de software.

Preciso preparar vários artigos, como recomendações: como um especialista em processos pode compor uma reflexão de processos com equipes de serviços profissionais . Para quem usa sistemas Kanban, essa abordagem tem várias vantagens no design e na operação desses sistemas.

Muito obrigado a Aleksey Pimenov eStepev.

More articles:


All Articles