Scrum é uma metodologia, um framework, com práticas, regras, papéis, que você deve adotar e seguir, para moldar como a equipe conduzirá o projeto.
Já Kanban é um método, não é framework, não é metodologia, são práticas bem abstratas que apontam o que pode ser feito para melhorar o fluxo de trabalho, visualizar as filas e encontrar os gargalos e aumentar a capacidade de entrega, mas não prescreve nada, não impoe. O Kanban é adaptável ao processo atual da empresa, é evolucionário (que produz uma evolução no processo).
No Scrum se assume que as reuniões diárias de pé são essenciais (de pé vem do XP na verdade), com no máximo de 15 min de duração, isso na prática pode não ser o melhor caminho, Kanban não prescreve nada disso, apesar de que é reconhecido que uma abordagem para reuniões é essencial para a saúde de um processo.
O Scrum diz que você deve ter uma equipe multifuncional, ou seja, uma equipe com todas as competências necessárias para desenvolver uma característica completa.
Deve haver um Scrum Master que é o mestre do framework Scrum com a missão de garantir que o processo da equipe funcione bem, de forma eficaz e de acordo com as regras do Scrum.
Existe também um Product Owner que conhece a visão do produto, se comunica com as partes interessadas e garante que a equipe trabalhe no que é mais valoroso e de maior prioridade.
No Scrum você trabalha através de iterações, ou Sprints, geralmente de 1-4 semanas. Cada Sprint começa com uma reunião de planejamento da Sprint e termina com um incremento do produto potencialmente utilizável. É esperado que o plano permaneça inalterado durante todo o Sprint.
Um dos pontos a se pensar sobre o Scrum é que o correto é seguir o plano da Sprint, pois, se toda vez mudar o plano, então você não está adotando nada nesse aspecto e o processo se torna uma bagunça.
Geralmente o Scrum não vai se enquadrar bem num processo muito flexível, ou num projeto em que além da equipe principal, possa ter no meio das tarefas ter que passar parte do trabalho para uma empresa parceira, perdendo assim a condição de conduzir as Sprints.
Na onda dos método ágeis, surgiu uma ideia de que era necessário tornar o ambiente descontraído, light, e com isso colocaram puffs, salas de jogos, de lazer, doces nas empresas, mas isso não reflete o que os agilistas originais pregavam.
O que eles sempre propuseram é que muita pressão e estresse certamente vai fazer a equipe perder desempenho, e cometer mais e mais erros, e que o ideal é tentar encontrar a carga de trabalho ideal para a empresa sair ganhando mais e entregando mais rápido.
Outra ideia que pegou com ágil foi usar bermudas, ambiente menos formal, equipes independentes em que todos poderiam determinar o que seria melhor para o projeto, mas isso era outro erro, o que os agilistas pregavam era que a falta de transparência e a hierarquia rígida demais com muita burocracia e disputas entre cilos tornava o ambiente pesado e ineficiente, tudo tendo que passar por aprovações e tudo tendo que ser anotado fazia com que muitos processos simples ficassem complexos, e que era necessário mudar essa mentalidade, aumentando a comunicação entre as equipes, tornando os gestores mais acessíveis, derrubando os cilos, e tornando o objetivo final um objetivo único compartilhado entre todas as equipes, mas isso não significa acabar com qualquer aspecto de liderança e nem acabar com as documentações ou formalizações.
O Kanban tem menos regras. Por exemplo, não há nada sobre papéis ou sobre trabalhar em iterações. O Kanban é mais focado no fluxo contínuo, visualizando o trabalho e otimizando o tempo entre idéias e recursos executáveis.
No Scrum você trabalha em iterações chamadas Sprints. No Kanban o objetivo é visualizar as filas, remover barreiras, para ter um fluxo contínuo.
Ambos Kanban e Scrum Boards usam "sticky notes" para informar os status de progresso do desenvolvimento.
Na verdade Scrum não prescreve nenhum quadro para acompanhar o projeto, mas geralmente as equipes adotam um quadro com sticky notes similar ao adotado pelo Kanban.
Scrum está mais para equipes que estejam desenvolvendo um sistema.
Kanban está mais para equipes de manutenção ou de suporte.
Scrum está mais para projetos em que a equipe trabalhe isolada, e projetos sem muitas variabilidades.
Kanban está mais para projetos muito grandes de corporações que já possuem uma burocracia muito forte, ou projetos que dependam de equipes externas para concluir tarefas.
No Scrum todos os eventos são time-boxed, tem duração fixa, isso dependendo do caso é excelente, mas em muitos casos será um empecilho muito grande.
Um dos pilares do Kanban é o foco em fornecer o status do projeto de forma visual.
O Kanban lhe ajuda a assimilar e controlar o progresso de suas tarefas de forma visual.
O Kanban tem o Quadro Kanban.
O Scrum tem o Product Backlog e o Sprint Backlog.
Ao olhar para um quadro Kanban é fácil enxergar como o trabalho seu e de sua equipe fluem, permitindo não só comunicar o status, mas também dar e receber feedbacks.
O Kanban é um dos métodos de desenvolvimento de software menos prescritivo.
Com o Kanban o objetivo geralmente é a sua adoção gradual.
Com o Kanban você tem uma forma de sinalizar a necessidade de puxar mais trabalho.
O foco é controlar a quantidade de trabalho em andamento, para desafogar as equipes, e assim atingir um nível ótimo de desempenho e aumentar assim as entregas ao cliente, outro objetivo das práticas do Kanban são entender o que é de valor ao cliente e entregar o que realmente vá satisfazê-los, assim Kanban busca a empresa conseguir uma visão ampla do início ao fim do pedido do cliente, outro objetivo é a remoção de gargalos e obstáculos.
O importante é mudar a diretriz, não é mais empurrar trabalho, agora será puxar trabalho.
Há um ditado bem comum entre quem utiliza Kanban: Pare de começar, e comece a terminar.
Kanban possui quatro princípios fundamentais, são eles:
- Comece com o que você faz agora;
- Concordar em buscar mudanças evolucionárias;
- Inicialmente, respeite os papéis, responsabilidades e cargos atuais;
- Incentivar atos de liderança em todos os níveis.
Buffer
Priorização de itens
Limite WIP
Raias
Cards Wall
Com WIP (work in process) é imposto um limite no ritmo da equipe,
assim, tornando-se equilibrado, a equipe não se compromete com muito trabalho de uma só vez e reduz o tempo gasto em um item.
Evita-se assim também problemas causados pela alternância de tarefas, reduzindo a necessidade de priorizar constantemente itens.
Kaizen é uma palavra que, geralmente, significa melhoria contínua.
O Kanban sugere que modelos sejam usados para implementar mudanças contínuas, incrementais e evolutivas.
Existem vários modelos que você pode usar, incluindo:
. TOC
. System thinking
. 3ms
Um épico é uma grande estória.
Quando uma solicitação é muito extensa, ela precisa ser quebrada em partes menores (estórias).
Uma estória de usuário pode ser caracterizada como uma curta e simples descrição de um recurso.
As tarefas são os elementos de uma estória.
https://www.culturaagil.com.br/kanban-do-inicio-ao-fim/
https://realtimeboard.com/blog/scrum-kanban-boards-differences/
https://kanbanize.com/blog/kanban-vs-scrum-infographic/
https://pt.stackoverflow.com/questions/208427/quais-as-diferen%C3%A7as-entre-kanban-e-scrum