Criar uma visualização para o fluxo de trabalho é uma das primeiras recomendações do Kanban e tem uma série de vantagens potenciais: melhoria da comunicação, transparência nas priorizações, clareza em relação aos gargalos, maior colaboração, etc…  Além de ótimos benefícios, soa como algo trivial de executar quando lido em um post como esse. Sinceramente, acredito que era para ser simples mesmo. Todavia, nada como uma boa dose de mundo real para mostrar que até coisas simples podem ficar complicadas.

NOTA DO ELEMAR: Este é o segundo post do Fernando Neiva, editado por mim.

Desafio #1 – Dificuldade em gerar um consenso sobre a granularidade dos itens

No nosso cenário cada time tinha uma percepção de como gostaria de visualizar os itens no quadro Kanban. Por exemplo, o time de negócio alegava que as User Stories eram demasiadamente granulares para poderem acompanhar a evolução do trabalho. Por essa razão, defendiam que precisavam ter uma visão agrupada em features, onde cada feature contempla um conjunto correlato de user stories.

Já para o time de desenvolvimento a visão deveria ser em user stories no mínimo, se possível, em tasks, onde cada task representa uma atividade técnica que precisa ser realizada para alcançar o objetivo de negócio proposto na User Story.

Até cogitamos, em certo momento, criar visões separadas, porém percebemos que um time trabalhando em uma visão e outros acompanhando em outra geraria ruído na comunicação.  Também ficou confuso alguns conceitos como a delimitação do work-in-progress que poderia ter sentidos diferentes dependendo da granularidade da visão.

Desafio #2 – Qual ferramenta utilizar para compartilhar a visualização com toda empresa

Os times de desenvolvimento trabalham no mesmo escritório (com exceção do Elemar que nos acompanha remotamente) e não seria problema utilizarmos um quadro com post-its para o controle de tarefas. Porém, temos equipes comerciais, consultores, implantação e operação distribuídas geograficamente.  Logo, tivemos que nos preocupar em escolher uma ferramenta online. Isso nos levou fazer alguns questionamentos. Acomodar uma visão de Kanban nos softwares que já utilizávamos ou adicionar mais um sistema na stack?

Para os squads de tecnologia receberem reports de bugs e solicitações dos usuários nós utilizávamos o Jira.  Já para controle das demandas, gerenciamento de configuração e integração o TFS.  A área de negócio e produto fazia uso de planilhas. (E o Elemar é fã do Trello).

Apesar de acharmos que essa era uma stack mais complexa que gostaríamos, cada software tinha uma razão legítima de existir e queríamos evitar fazer mudanças bruscas naquele momento que fossem impactar muitas pessoas. Mas, de qualquer forma, precisávamos manter nosso objetivo de melhorar a comunicação.

Cenas dos próximos capítulos

Fizemos algumas experimentações para chegar ao que estamos utilizando hoje. Houveram alguns erros que serviram de aprendizado.  Compartilharemos nos próximos posts o que funcionou e o que falhou no nosso cenário e o porquê.

Se você está adotando kanban também no dia a dia do seu time compartilhe conosco seu aprendizado, pode ajudar a mim e a outros que nos leem.

Mais posts da série “Kanban no Mundo Real”:

6 Comentários
  1. Estamos usando VSTS e Zendesk. Zendesk faz admissão de reportes de bugs e centraliza o atendimento ao cliente. E no VSTS geramos Work Items e Bugs. Por termos um time pequeno, não temos a separação entre área de negócio e de dev. Temos uma integração interessante entre Zendesk + MS Teams + Microsoft Flow e + VSTS, para integrar o zendesk com o vsts, na criação de itens de Bug.

  2. Olá Elemar e Fernando,

    Muito legal esse compartilhamento de experiências…

    Aqui na NDD, utilizamos o Kanban Físico para os times de desenvolvimento, com WIP e Classes de Serviços bem definidos. Não colocamos tasks nesse Kanban, prezamos que o Card trafegue por todas as raias do Kanban. Quando há quebra de tasks, normalmente elas não vão andar em todas as raias, pois terá a task do Dev, do Tester, do PO, etc.

    O PO, quando está criando o Backlog do time, registra esses itens no TFS e detalha eles conforme necessidade, com isso no Kanban Físico só vai o Card com o Título e Id do item no TFS. O time por sua vez se compromete a informar quando um item é iniciado e quando é concluído. Com isso conseguimos extrair facilmente indicadores como Cycle Time, Lead Time e Throughput. O item do TFS também é “linkado” nos Pull Requests que são feitos pelo time (normalmente 1:1), isso também gera indicadores de performance do time e contribui para práticas como Code Review.

    E para o pessoal da área de produtos e comercial, é criado no TFS um outro board, para representar o Upstream do Kanban. Nesse board a visão é macro, agrupada em itens já existentes do TFS (Feature, Epics) ou até mesmo em itens personalizados (Criamos um Request da área comercial). Esse board tem suas próprias raias e seus itens andam no board, conforme o trabalho do Downstream Kanban é conduzido pelos times de desenvolvimento. Novamente, podem ser extraídos indicadores desse fluxo.

    Não temos integração com o Trello, e o chefe aqui também gosta de usar. Para uma visão read-only, poderia ser usado o “Service Hook” do TFS, caso precise de um fluxo integrado acredito que esses Hooks só irão funcionar no VSO ou via customização especializada dessa integração.

    1. Olá, Hugo. Muito legal a experiência de vocês.
      Nós estamos considerando usar um quadro kanban físico também. Gostei bastante da sua ideia de usá-lo complementar ao TFS.

      Para integrar o TFS on-premise com outros softwares nós usamos o pacote Microsoft.TeamFoundationServer.ExtendedClient. Acho que não é a abordagem mais recente, mas atende.

      Sobre ter um board separado para área comercial funciona bem para vocês? Estávamos confusos devido a mudança de granularidade, por exemplo, uma feature que tenha uma U.S. em produção e outra que não começou fica em qual coluna do quadro?

      1. Olá Fernando,

        Esse board que mencionei, só para deixar claro, não é um board exclusivo para a área comercial. Esse board é de responsabilidade da área de produtos, que por sua vez mantém uma visão que dá transparência para a área comercial.

        Normalmente, quando um quadro de Upstream é criado, a feature ou item que já está priorizada para produção fica na coluna “Ready to Commit” que é o chamado Commitment Point do Upstream Kanban, ou seja, a partir desse momento ela pode ser puxada pelo time do Downstream Kanban. Após todos os trabalhos relacionados a feature ou item serem concluídos, o card é movido para a coluna “Ready to Delivery”.

        Entretanto, você pode customizar conforme o seu fluxo, aqui por exemplo, temos um produto que utiliza 5 colunas no lugar do “Ready to Commit”, essas colunas eles usam para priorizar as demandas, são elas: “Próximos 30 dias”, “1º Trimestre”, “2º Trimestre”…
        Nesse caso, o time do Downstream Kanban puxa os itens que estão priorizados em “Próximos 30 dias”. Foi feito isso para um cenário específico, onde haviam muitas demandas e a área comercial não tinha visibilidade. É importante essas variações, até para testar o conceito de inspeção e adaptação.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *