Não há uma solução rápida quando se trata de escolher uma estrutura ágil para a equipe ágil. Não importa se usar kanban, scrum ou uma combinação dos dois, como scrumban e kanplan, o método ágil é um processo de equipe. Cada equipe precisa descobrir qual estrutura funciona melhor como uma base para como planejar, monitorar e lançar ótimos softwares.
Scrumban vs. kanban vs. scrum
O objetivo do kanban é fornecer às equipes o trabalho suficiente para que trabalhem consistentemente. As equipes que usam kanban se beneficiam do planejamento flexível, foco mais claro e transparência total, pois o que estiver no quadro é a prioridade. É nisso que os desenvolvedores estão trabalhando. O kanban é ideal para equipes operacionais com foco em entrega contínua com prioridades em constante mudança.
Por outro lado, o scrum divide o trabalho em várias iterações de tamanho fixo chamados de sprints. Tudo o que estiver programado para um sprint é a prioridade da equipe (por exemplo, uma função específica ou grupo de funções). As equipes de produtos com um roteiro claro e partes do trabalho priorizadas normalmente se beneficiam com o scrum.
Mas talvez sua equipe se beneficie mais com uma combinação de scrum e kanban? Ou queira fazer a transição do scrum para o kanban? Se isso lembra sua equipe, a solução é o scrumban. Essa metodologia mista se manifesta de diferentes modos, mas as tendências mais comuns entre equipes scrumban envolvem o uso de sprints com uma lista de pendências do scrum e limites de WIP e tempo de ciclo do kanban. (Observação: o tempo de ciclo é a quantidade de tempo que uma tarefa demora para passar pelo fluxo de trabalho de uma equipe.)
E as equipes que não querem trabalhar iterativamente, mas ainda desejam ter a capacidade de monitorar o backlog? O Kanplan (ou a ativação do recurso de backlog do Kanban) no Jira pode ser a resposta.
O que é o kanplan?
O Kanplan é uma metodologia mista para a prática do desenvolvimento de software com agilidade. Como o Scrumban, ele combina funções do Scrum e do Kanban. O Kanplan é ideal para equipes que querem revisar um backlog, mas não querem trabalhar em sprints.
Por que o kanban é uma base e não uma estrutura rigorosa?
A equipe de engenharia de criação da Atlassian é responsável por uma plataforma usada para compilar, testar e entregar o software da Atlassian. Os desenvolvedores dependem de uma infraestrutura confiável e da integração contínua (CI) rápida. Quatro anos atrás isso se resumia a 21 mil compilações por mês. Atualmente, esse número excede 150 mil compilações por mês.
Essa capacidade de dimensionar pode ser atribuída ao crescimento da equipe, migração do Subversion para o Git, testes automatizados e algo menos óbvio: a decisão de mover do scrum para o kanban. A natureza do trabalho de engenharia de criação (solicitações ad hoc, incidentes, trabalho de inovação) não se adéqua bem em uma estrutura scrum. Então a equipe decidiu usar o scrumban e, rapidamente, passou para o kanban, pois ninguém gostava de trabalhar com sprints. No entanto, o kanban não era tudo o que eles esperavam. Como em muitas equipes, eles tentaram fazer com que ele funcionasse. Foram de um quadro para vários, um quadro de engenharia de suporte, um quadro de trabalho do projeto e outros, todos com diferentes fluxos de trabalho. Mas o maior obstáculo em todos os quadros? O "deserto", como definiu um membro da equipe, de problemas não classificados que precisavam ser movidos para o status de prontos para o modo de trabalho. Uma vez na coluna "Em andamento", a equipe podia começar, mas a coluna "Para fazer" – a coluna "deserto" – era apenas isso: um deserto.
Transformar sua lista de afazeres em uma lista de pendências
Nossa equipe de engenharia de criação tentou ordenar sua longa e desorganizada lista de afazeres com reuniões rápidas diárias e reuniões de planejamento semanal. Mas eles realmente precisavam de uma lista de pendências em vez de mais reuniões.
Como os quadros kanban tradicionalmente não têm a funcionalidade de lista de pendências, os gerentes de produtos, os gerentes de desenvolvimento e os líderes de equipe usam os problemas da primeira coluna para o planejamento. À medida que a lista cresce, é difícil ver e priorizar os problemas. A equipe de engenharia de criação dividiu seus quadros com base em diferentes áreas de trabalho, mas o quadro da equipe combinada permaneceu sobrecarregado (é necessário descer muito a barra de visualização).
Em vez de tentar descobrir modos diferentes de reorganizar a equipe, os quadros, ou de reinventar a roda, a equipe do Jira decidiu levar os backlogs para o Kanban. A função Kanplan apresenta um backlog em uma coluna ampla com os itens em uma visualização de lista. Isso divide o quadro Kanban em duas telas diferentes: o backlog para a revisão de tarefas e o quadro Kanban para a equipe de engenharia selecionar e mover tarefas pelo fluxo de trabalho.
Essa funcionalidade não é diferente do backlog de um quadro Scrum no Jira. Por exemplo, ao clicar no ícone do backlog na barra lateral, você acessa uma coluna ampla de itens do backlog. Após organizar seu backlog, é possível arrastar e soltar os itens na etapa seguinte do seu fluxo de trabalho.
Essa combinação de tela de lista de pendências do scrum e do quadro kanban em um quadro ágil funciona como uma lista de pendências do quadro scrum. Ao clicar em um problema, é possível ver a exibição de detalhes do problema. Exibições focadas, como a exibição de detalhes do problema, permitem que os membros da equipe executem tarefas mais rapidamente e com menos distrações.
Finalmente, para as equipes não scrum que usam epics e versões pré-atribuídas para organizar suas liberações, elas podem se beneficiar das ferramentas encontradas nos quadros scrum, como problemas de visualização ou edição rápida. Essa edição simples e rápida fornece aos gerentes de produto, gerentes de desenvolvimento, e quaisquer outras pessoas no modo de planejamento, a capacidade de gerenciar eficientemente epics e versões.
Deseja adicionar uma lista de referências ao seu quadro kanban?
Siga este tutorial para ativar um backlog em seu projeto Kanban:
O objetivo do kanplan, conforme dito por um cliente, é proporcionar a você "o melhor dos dois mundos". É possível fazer o trabalho sem ter um sprint em andamento, bem como inserir tarefas em uma lista de pendências para ajudar você a se planejar melhor. Ele elimina o deserto da equipe de engenharia de criação da Atlassian e fornece às equipes kanban um modo de planejamento que ainda não existe em um ambiente kanban. Ele também orienta um novo modo de trabalho para equipes que não sentem que o kanban, o scrum ou o scrumban fornecem a base necessária para fazer o trabalho que querem.
Ao possibilitar um modo de planejamento em um quadro kanban, equipes novas e já experientes em kanban encontram modos de fazer essa estrutura ágil funcionar em vez de tentar seguir melhores práticas que podem não ser aplicáveis à equipe. Lembre-se: o desenvolvimento ágil está relacionado à melhoria contínua e não a melhores práticas.
