Karl Scotland iniciou uma discussão examinando se os workflows ou estágios em um sistema kanban se enquadram nos ideais ágeis de times colaborativos e cross-funcionais. Ele iniciou citando que os estágios em um quadro kanban podem ser muito similares às fases do método cascata. A discussão seguinte esclareceu que os estágios não são necessariamente uma passagem de responsabilidade, e podem levar muito bem á outros conhecimentos.
Karl iniciou com o exame de um sistema kanban aparentemente muito similar ao processo cascata:
Análise -> Construção -> Testes -> Liberação
A seguir ele apresentou um típico quadro de tarefas Scrum, parecido com isto:
A Fazer -> Em progresso -> Finalizado
Depois Karl apresentou maneiras de como fazer com que o quadro de tarefas revele mais informações a respeito de como o trabalho flui através do sistema. Em muitos ambientes, funcionalidades (histórias) que tem sido marcadas como “Finalizadas” não são imediatamente liberadas, ou colocadas em um ambiente de produção. Nestes casos, pode ser algo iluminado fazer uma distinção entre ‘pronto para produção’ e ‘em produção’ no quadro. Se o quadro revela que o trabalho em progresso esta acumulando esperando por liberação, o negócio deve decidir aperfeiçoar o processo adotando implantação contínua, por exemplo.
Karl continua para encontrar outras maneiras de subdividir os estágios no quadro de tarefas. Ele também sugere nomes que ele sente que são mais sugestivos do trabalho sendo feito em cada estágio, por último chegando a este fluxo:
Incubado -> Ilustrado -> Instanciado -> Demonstrado -> Liquidado
A partir deste momento a discussão começou com Robin Dymond citando que simplesmente mudar os rótulos, não quer dizer que irá mudar o comportamento, mas mudar os rótulos pode ser parte de uma solução maior:
A melhor abordagem é simplificar o processo utilizando times multi-funcionais co-alocados, puxe o teste para frente do processo, e torne todos responsáveis pela qualidade, incluindo o cliente. Neste caso eu utilizaria palavras diferentes, porque os passos do processo são de longe os menos importantes do que como os times trabalham em conjunto para entregar as funcionalidades.
Keith Braitwaite fez esta observação:
Eu sugiro que por mais que os processos similares a Kanban sejam descritos em termos (e com fotos) que não só permitem, mas que permitem positivamente uma interpretação linear, bloqueios e contratempos, falta de planejamento e retrabalho, um grande número de pessoas será resistente a esta idéia.
Esta observação é congruente com grande parte da doutrina agile, que busca evitar contratempos e eliminar ou encurtar seqüências, de maneira a facilitar ciclos de feedback mais curtos. Por exemplo, enquanto a prática ágil de desenvolvimento orientado a testes (TDD) possui os estágios:
Teste -> Codificação -> Refatoração
Na prática, o desenvolvedor irá fazer ciclos através destes estágios tão rápido que fazer o rastreamento deles em um quadro de tarefas seria um tédio.
Da perspectiva lean, o importante é que as funcionalidades são continuamente puxadas através do sistema (fluxo contínuo), como oposto ao trabalho de ser enfileirado e então ser completado em lote. O processo cascata tradicional é um exemplo de uma abordagem lotes-e-filas. Todo o trabalho de compilação de requisitos é feito em um lote, com os requisitos sendo enfileirados esperando pelo trabalho de design iniciar. Similarmente, o trabalho de design é feito como um lote e a saída é enfileirada para codificação, e assim por diante.
Em um sistema de fluxo contínuo, as funcionalidades são puxadas do backlog e depois são trabalhadas continuamente até que estejam completas. Se existem estágios identificados durante o desenvolvimento, um quadro kanban pode ser utilizado para identificar onde o progresso do trabalho esta acumulando. Estes gargalos então são marcados para uma melhoria no processo, para manter o fluxo de trabalho fluindo através do sistema eficientemente.
O workflow de uma funcionalidade é somente este. A funcionalidade vai através de um número de estados do momento em que é concebido até o momento que é feito o deploy, em uso e gerando valor. Um workflow em kanban não impõe bloqueio entre os indivíduos. Igualmente é o fato de que não há demanda que o time não possa atacar para assegurar que ela trafegue suavemente e rápido entre os estados.
Vasco Duarte sentiu que a discussão estava muito focada em processos e ferramentas, acabando perdendo a idéia do kanban, que é reduzir o trabalho-em-progresso.
Porque vocês se preocupam? O fato é que uma seqüência Kanban (uma funcionalidade do backlog para a liberação) é sobre um curto período de tempo (um dia, talvez 2/3?) que a seqüência que você utiliza será muito similar à análise, design, implementar, teste, implementar. Claro que não é algo linear, porque ainda estamos discutindo isto? Porque uma atividade está atribuída para um grupo pequeno de pessoas que vão saber o que fazer, mesmo que isto signifique “quebrar a seqüência.”
De fato, se o quadro kanban está sendo utilizado para se ter certeza de que cada uma das atividades necessárias ocorreu, ele esta sendo usado para reforçar a definição de feito do time, sendo este um trabalho mais apropriado para um simples checklist.
Para você, os estágios em um quadro kanban são parecidos com os estágios de um processo cascata? Se sim, a similaridade é superficial ou importante? Deixe um comentário e compartilhe sua perspectiva.