Guia Scrum | 33. Quadros Scrumban e Kanban no Scrum

Scrum e Kanban são métodos de trabalho em equipe que compartilham muitas semelhanças. No entanto, também existem diferenças que gostaríamos de discutir hoje. Os quadros Kanban também são frequentemente adotados pelos times Scrum. Isso porque eles são muito práticos na visualização do trabalho em equipe e seu progresso. Ao combinar o melhor de ambas as metodologias, surgiu uma técnica chamada Scrumban. É popular em projetos que combinam desenvolvimento de produtos com entrega de serviços, onde Sprints longos e reuniões Scrum relativamente formalizadas nem sempre são adequadas.

Quadros Scrumban e Kanban em Scrum – índice:

1. Introdução
2. Kanban vs Scrum
3. Quadros Kanban no Scrum
4. Scrumban
5. Resumo

Introdução

Kanban é um método pioneiro no Japão. Originou-se na década de 1950 e foi principalmente uma ferramenta para gerenciar a produção contínua de forma a não criar estoques e excedentes, mas processar recursos de forma contínua. No início do século 21, o Kanban foi adaptado às necessidades de desenvolvimento de software por David J. Anderson.

Kanban vs Scrum

A maneira geral de trabalhar no Kanban difere do Scrum principalmente por trazer uma abordagem menos formal. No Kanban, não há diretrizes tão detalhadas sobre, por exemplo, trabalhar em Sprints, papéis de Product Owner, Scrum Master e Time de Desenvolvimento. Isso é possível porque o Kanban foca na continuidade de tarefas como a prestação de um tipo específico de serviço, que são mais repetíveis e não exigem um planejamento tão complexo.

No entanto, a finalidade e as formas de trabalho são semelhantes. O objetivo do Kanban é entregar o produto da mais alta qualidade ao cliente no prazo. Os princípios relativos às formas de trabalho comuns a ambos os métodos podem ser formulados da seguinte forma:

1. O trabalho deve ser suave e sem qualquer tempo de inatividade – no Scrum, isso é alcançado pela sucessão contínua de Sprints, enquanto no Kanban o trabalho é contínuo devido ao fluxo suave das tarefas. Eles formam uma fila, da qual os desenvolvedores escolhem (puxam) algumas tarefas para serem concluídas.
2. A equipe deve se concentrar apenas em tarefas selecionadas – usando a terminologia Kanban, a equipe deve “reduzir o trabalho em andamento”. No Scrum, o equivalente a isso são User Stories escolhidas do Product Backlog para colocar no Sprint Backlog
3. O progresso das tarefas deve ser visível para todas as pessoas envolvidas – no Kanban elas são visualizadas por quadros, que também são frequentemente apresentados em Times Scrum.

Quadros Kanban no Scrum

Um quadro Kanban é uma ferramenta amplamente utilizada para visualizar o trabalho em equipe. É uma tabela com várias colunas. Em cada um deles, existem tarefas com um determinado status. A categorização das tarefas é baseada em uma regra simples: um cartão com a descrição da tarefa – ou seu equivalente virtual – é colocado em uma das colunas. A versão mínima dos quadros Kanban contém três colunas:

• Façam
• Em andamento
• Concluído – para a última coluna vão as tarefas que atendem à Definição de Conclusão, sobre a qual escrevemos aqui.

Abaixo, você pode encontrar um exemplo de um quadro kanban de um sistema de gerenciamento de projetos tudo-em-um – Firmbee.com

Geralmente, há mais colunas. Se houver mais tarefas a serem concluídas, geralmente há uma coluna adicional intitulada “selecionado para conclusão” entre as colunas “a ser concluída” e “em andamento” . Enquanto a coluna “to-do” serve como Product Backlog, sobre o qual escrevemos aqui, a coluna “selecionado para conclusão” serve como Sprint Backlog, que descrevemos em detalhes neste artigo.

A segunda adição comum é uma coluna “em revisão” ou “para aprovação”. Geralmente é inserido entre as colunas contendo as tarefas “em andamento” e as “concluídas”. Ele contém tarefas concluídas pela Equipe de Desenvolvimento que está aguardando aprovação do Dono do Produto. A tarefa do Product Owner é verificar sua conformidade com os critérios de aceitação e obter sua aprovação final do Cliente. Nessa situação, apenas as tarefas finalmente aceitas são movidas para a última coluna.

Scrumban

Devido à enorme popularidade do Scrum e do Kanban, surgiu seu híbrido, combinando o melhor das duas formas de trabalhar. Scrumban funciona melhor em organizações que conectam a criação de Produtos com a prestação de serviços, muitas vezes envolvendo a implementação do Produto no Cliente. Por causa da redução de reuniões e comunicação, a Equipe pode ser maior.

Scrumban dá menos ênfase às métricas comumente usadas no Scrum, como o Burndown Chart. No entanto, utiliza os pilares do Scrum da necessidade de melhoria contínua do processo de trabalho e adequando-os às condições e necessidades do cliente.

Ao trabalhar no Scrumban, no entanto, o trabalho não é dividido em Sprints. As reuniões do Scrum são realizadas a cada 3, 6 ou 12 meses.

A programação do trabalho segue o princípio “On-Demand”, ou seja, conforme ele ocorre. As Histórias de Usuário são colocadas diretamente na primeira coluna do quadro Kanban contendo tarefas “a fazer”. Assim, ele serve como o Sprint Backlog, sobre o qual escrevemos mais detalhadamente neste artigo. Assim como no Sprint Backlog, as tarefas mais urgentes são colocadas no topo da lista de tarefas. No entanto, para projetos mais complexos, o Gerente de Projeto pode manter uma lista de tarefas separada correspondente ao Product Backlog, a partir da qual ele seleciona quais tarefas colocar na primeira coluna.

Ao mover tarefas da primeira para a segunda coluna, aplica-se a regra “Puxar” . Isso significa que as tarefas não são delegadas a um desenvolvedor específico. Cada pessoa escolhe uma tarefa da fila e a executa de forma independente.

O número de tarefas colocadas na coluna do meio, “para completar” costuma ser limitado dependendo do tamanho da equipe, para que, se possível, todos lidem com apenas uma tarefa por vez.

Resumo

Scrum e Kanban, embora usados ​​para propósitos semelhantes, são formas diferentes de trabalhar. Scrum funciona melhor em projetos criativos e inovadores feitos por pequenas equipes Scrum. O Kanban, por outro lado, foi criado para operar em um ambiente contínuo e sem tempo de inatividade para fornecer serviços semelhantes. O Scrum geralmente usa quadros Kanban como um método para visualizar o trabalho que está sendo feito. A combinação de ambos resultou no Scrumban, que funciona melhor como uma estrutura para organizações que vendem seus produtos e fornecem serviços baseados neles para o cliente.

Se você gosta do nosso conteúdo, junte-se à nossa comunidade de abelhas ocupadas no Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autor: Caroline Becker

Como Gerente de Projetos, Caroline é especialista em encontrar novos métodos para projetar os melhores fluxos de trabalho e otimizar processos. Suas habilidades organizacionais e capacidade de trabalhar sob pressão de tempo fazem dela a melhor pessoa para transformar projetos complicados em realidade.

Ver todas as postagens

Guia do Scrum:

1. Glossário de termos básicos, funções e noções
2. O que é Scrum?
3. Valores do Scrum
4. Como implementar o Scrum na sua empresa?
5. Time Scrum - o que é e como funciona?
6. Quem é um Product Owner?
7. Os erros mais comuns do Product Owner
8. Quem é o Scrum Master?
9. Características de um bom Scrum Master
10. Os erros mais comuns do Scrum Master
11. Quais estatísticas e métricas o Scrum Master deve acompanhar?
12. Cooperação entre Product Owner e Scrum Master
13. Equipe de Desenvolvimento em Scrum
14. Os erros mais comuns dos desenvolvedores
15. Artefatos do Scrum
16. Escalando Scrum
17. Backlog da Sprint
18. O que é o Backlog do Produto?
19. O que são histórias de usuários?
20. Criando a melhor história de usuário com INVEST
21. Os erros mais comuns da história do usuário
22. Critérios de aceitação da história do usuário
23. Estimativa e pontos de história no Scrum
24. Poker de Planejamento
25. Jogo de estimativa de equipe
26. Definindo Incremento
27. Eventos Scrum
28. O que é Sprint no Scrum?
29. Compromissos da Equipe Scrum - Objetivo do Produto, Objetivo do Sprint e Definição de Conclusão
30. O que é um gráfico Burndown?
31. Como criar e interpretar um gráfico de burndown?
32. Vantagens e desvantagens do gráfico de burndown
33. Quadros Kanban em Scrum e Scrumban
34. Velocidade no Scrum - Velocidade da Equipe de Desenvolvimento
35. Reunião diária
36. Planejamento de Sprint
37. Revisão da Sprint
38. O que é uma Sprint Retrospective?
39. Erros comuns durante uma Sprint Retrospective
40. Nutrição do Backlog do Produto