Scrum vs Kanban: mantenha a calma e escolha o que melhor combina com você

Quando se trata de escolher entre duas opções, sempre existe o risco de ser influenciado por opiniões e fatos duvidosos. Selecionando qualquer metodologia ou abordagem de trabalho, nos esforçamos para evitar erros e estudar o maior número possível de fatos e detalhes sobre o assunto para fazer a escolha certa.

No desenvolvimento de software Agile, essa escolha também é desafiadora, especialmente se for sobre Scrum e Kanban.

Scrum vs Kanban: duas metodologias, uma escolha

Antes de chegar a uma seleção tão difícil, provavelmente você pode se deparar com outro dilema preliminar relacionado à escolha entre Waterfall vs Agile . No entanto, você fez a escolha certa e agora enfrenta dois caminhos independentes no mundo do desenvolvimento Agile.

Scrum e Kanban são dois ramos da família Agile (no entanto, muitas pessoas não consideram o Kanban uma metodologia independente e a separam de outros métodos). Ambos são flexíveis e iterativos.

Foi realizada uma pesquisa em 2018 entre 101592 desenvolvedores de software de todo o mundo. Quase 86% deles usam o Agile em seu trabalho. Parece impressionante, certo?

Scrum ou Kanban: qual é a melhor escolha?

O Scrum permite que as pessoas resolvam problemas adaptativos complexos, enquanto entregam produtos de alto valor produtivo.

A estrutura do Scrum é leve e simples de entender, mas pode ser difícil de dominar. Consiste em iterações curtas ou Sprints, que geralmente duram de 2 a 3 semanas.

A lista de recursos possíveis para iteração é criada pela equipe. Então eles começam a executar um Sprint. Normalmente, os recursos que estão sendo trabalhados durante um Sprint não são alterados. O que foi iniciado no início deve ser feito até o final de qualquer maneira.

O Scrum contém vários termos, conceitos e artefatos. Para entender todos eles, leia e estude o glossário Scrum ou o guia definitivo.

O Kanban pode ser visualizado da perspectiva do local onde foi criado - empresa Toyota.

As linhas de transporte diárias produzem os componentes dos carros. Uma máquina especial projeta espelhos para carros Toyota: esquerda, direita, espelhos traseiros e espelhos para pára-sóis. Apenas um clique em um botão, o modo é alterado e eles recebem um novo produto.

O momento chave aqui é que eles podem mudar as prioridades a qualquer momento. Eles são capazes de mudar a máquina para um modo diferente e é isso.

No entanto, se você precisar de mais alguma teoria sobre o Kanban, considere-o como um sistema visual para gerenciar o trabalho à medida que ele avança no processo. Ele visualiza o fluxo de trabalho e o trabalho real passando por esse processo.

O Kanban ajuda a identificar possíveis gargalos nos processos e corrigi-los para fornecer um fluxo econômico.

A principal diferença entre Scrum e Kanban é a duração da iteração:

• Você trabalha por 2 semanas no Scrum.
• No Kanban, você pode fornecer aos desenvolvedores tarefas mesmo todos os dias.

Kanban é mais flexível. Imagine que ontem você lançou um novo recurso no servidor de produção com alguns eventos para rastrear os KPIs do recurso.

Com a ajuda da análise, seu gerente de produto entende que algo deu errado. Ele decide fazer algumas alterações na lógica do recurso. Ele coloca a tarefa em um quadro Kanban e a levanta em uma coluna. Assim que o programador estiver livre, ele assumirá essa tarefa e a liberará logo após o teste. Levará vários dias para tudo.

No caso do Scrum, você terá que esperar um Sprint inteiro, ou seja, 2-3 semanas.



O Scrum requer estimativa de tarefas com Story Points ou Horas. Você não poderá formar um Sprint sem essa estimativa. E você deve saber exatamente se concluirá todas as tarefas em 2 semanas.

Após duas semanas, você obtém estatísticas valiosas sobre quantos pontos ou horas da história sua equipe conseguiu concluir durante um Sprint. Com a ajuda dessas informações, um mestre do Scrum prevê onde a equipe estará em duas semanas.

No Kanban, as pessoas também podem estimar, mas isso é opcional. Não há velocidade da equipe. Você considera apenas um tempo médio para a conclusão da tarefa e o conta em um Relatório de tempo de ciclo.

Tempo do ciclo de tarefas = Tempo gasto trabalhando em uma tarefa - Tempo em que a tarefa foi iniciada

Imagine que o objetivo atual do Scrum é finalizar um Sprint, mas para o Kanban, você precisa finalizar uma tarefa.

Da teoria à prática: a maneira como fazemos

Limitando a limpeza

WIP é Trabalho em Andamento. É importante limitar o número de tarefas nas quais os especialistas podem trabalhar ao mesmo tempo. Sim, não há César e Napoleão entre nós para ser famoso por incríveis habilidades multitarefa.

É ideal quando as pessoas trabalham apenas em uma tarefa em uma unidade de tempo. Geralmente, leva 15 minutos para um desenvolvedor alternar de uma tarefa para outra.

Você precisa de tempo para preparar o chá, ler alguns artigos na Web, ler os requisitos para uma nova tarefa, lembrar onde parou e encontrou esse ponto no código.

Certifique-se de que mudar de tarefa para tarefa é deixar de uma rota de pensamentos para outra e nem sempre é fácil voltar.

Swimlanes

Ninguém está protegido contra falhas e seu site pode não funcionar durante o horário comercial. Você cria e atribui uma tarefa para corrigi-la imediatamente ao engenheiro do DevOps, por exemplo.

Mas ele está fazendo outra tarefa e planeja terminar amanhã no almoço. O que fazer? Não é uma boa idéia girar em torno dele, tocar no ombro e implorar para mudar para um bloqueador. Você pode fazer isso uma vez, mas é o caminho certo para agir? Definitivamente não, é por isso que usamos Swimlanes.

Neste exemplo, a Swimlane "Blocker" é a solução, fazendo com que o desenvolvedor pare de executar sua tarefa atual imediatamente, faça uma pausa e comece a trabalhar no bloqueio de coisas.

Também utilizamos uma raia “Algum dia” que cobre todas as tarefas que provavelmente faremos um dia nesse bloco.

O Swimlane ajuda a deixar de lado todas as coisas desnecessárias para que as pessoas possam se concentrar nas tarefas importantes.

Sub-colunas

Há uma coluna "Codificação" e uma coluna "Teste" logo após. Quando o desenvolvedor termina sua tarefa, ele a move para o "Teste". Você pode pensar que o testador já começou a trabalhar nessa tarefa, mas, na verdade, ele está executando outra. Depois que o desenvolvedor move a tarefa para teste, ele perturba o limite de WIP para o controle de qualidade. Este é um verdadeiro desafio!

Na verdade, o desenvolvedor é livre para não mover essa tarefa para a coluna "Testes" e a deixará na coluna "Codificação". Isso também não é bom porque sua tarefa permanecerá na coluna "Em andamento", embora ele já a tenha concluído.

No entanto, como executar a próxima tarefa se os limites do WIP não devem ser quebrados? As sub-colunas ajudam. O desenvolvedor simplesmente move a tarefa concluída da sub-coluna "Tarefa de codificação" para a "Codificação concluída". E o testador, quando chegar a hora, executará uma nova tarefa de teste na sub-coluna "Coding Done".

Considerações finais

Resumindo todos juntos, vamos definir o Scrum como uma metodologia de desenvolvimento flexível, mas intitularemos o Kanban como ainda mais flexível.

O Scrum parece melhor no início do desenvolvimento do produto, pois ajuda a gerenciar prazos mais facilmente. Além disso, há comunicação suficiente nas equipes. Eles discutem minuciosamente o Sprint Backlog antes do início.

Eles discutem tarefas com seus criadores. A equipe estima tarefas de acordo com o sistema Planning Poker. De fato, o Scrum ajuda a entender o núcleo do produto.

No entanto, após o lançamento do produto, você recebe comentários dos usuários e precisa reagir rapidamente. Você começa a medir e otimizar as métricas do produto, tudo divide seu ciclo de desenvolvimento em unidades menores e começa a realizar muitas pequenas tarefas no caos. Este é o momento certo para recordar o Kanban perfeito para esse caso.

Você aplicou as duas metodologias? Qual é o seu favorito na oposição Kanban vs Scrum?