O que é Scrumban?

Por |2018-11-19T18:15:24+00:0019/11/2018|0 Comentários  |  Download PDF Versão em PDF  |  Imprima esse artigo Imprima esse artigo

Conhecemos Scrum e Kanban como sabores dos métodos Ágeis. Scrum é mais adequado para projetos de produtos e de desenvolvimento. O Kanban é melhor para suporte à produção. Scrumban é uma metodologia de desenvolvimento Agile que é um híbrido de Scrum e Kanban. Scrumban está se tornando muito popular nas indústrias de serviços, onde temos projetos de desenvolvimento e manutenção.

Scrum

Scrum é um processo iterativo e prescritivo que usa a metodologia Agile.

  • Equipes pequenas, multifuncionais e auto organizadas
  • O trabalho é dividido em uma lista de pequenas entregas concretas
  • Uma lista por prioridade é classificada e o esforço relativo de cada item é estimado
  • O tempo é dividido em iterações curtas de duração fixa (sprints, em geral de 2 a 4 semanas), com o código potencialmente utilizável demonstrado após cada iteração
  • Com base nas informações obtidas ao inspecionar a liberação após cada iteração, plano de liberação é otimizado e as prioridades atualizadas, em colaboração com o cliente
  • É feita uma retrospectiva após cada iteração

Fluxo de trabalho no Scrum

No Scrum, o trabalho que será feito no próximo sprint é previamente selecionado. A seguir, o sprint é bloqueado, o trabalho é feito e depois do sprint a fila está vazia.

Fluxo de trabalho no Scrum

Kanban

Kanban é uma metodologia de sinalização para controle de fluxo de operação.

  • O trabalho é dividido em cartões e colocado em um painel.
  • São usadas colunas nomeadas para ilustrar onde cada item está no fluxo de trabalho.
  • O trabalho em andamento ou em processo (work in process) é limitado, atribuindo-se limites explícitos para quantos itens podem estar em andamento em cada estado do fluxo de trabalho.
  • É medido o lead time (tempo médio para completar um item, às vezes chamado de “tempo de ciclo”) e o processo é otimizado para tornar o lead time o mais pequeno e previsível possível.

Fluxo de trabalho no Kanban

No Kanban, o tamanho das filas, chamado de limite de trabalho em processo, é limitado. Isso significa que os itens nas filas podem ser alterados a qualquer momento e que não há “final da sprint“. O trabalho continua fluindo.

fluxo de trabalho no kanban

Scrumban = Scrum + Kanban

O Scrumban é baseado em sistema puxado, onde a equipe já não planeja o trabalho durante a sprint planning, em vez disso, o refinamento é feito continuamente.

  • Usa a natureza prescritiva do Scrum para ser Ágil.
  • Usa a melhoria de processo do Kanban para permitir que a equipe melhore continuamente seu processo.

Usando o sistema puxado do Kanban o fluxo se torna mais suave à medida que a capacidade de processo melhora.

Tempo de ciclo

Podem ser usados pulmões e diagramas de fluxo para mostrar fraquezas e oportunidades no processo. Desse modo, à medida que nos aproximamos do nível de produção, começamos a nos tornar menos preocupados com o burndown e mais preocupados com o tempo do ciclo. O lead time médio e o tempo de ciclo se tornam o foco principal do desempenho.

Se o tempo de ciclo estiver sob controle e a capacidade da equipe for equilibrada com a demanda, o tempo de espera também estará sob controle. Se o tempo de ciclo estiver sob controle, as burndowns são previsíveis e deixam de importar.

Backlog

Como a equipe agora coloca o trabalho em uma fila pequena e pronta antes de inseri-lo no trabalho em andamento, o backlog da iteração sempre contém algo para ser feito (fluxo ininterrupto).

backlog

Em vez de se preocupar em estimar um escopo de trabalho para cada iteração, limita-se o tamanho do backlog de iteração usando-se um tamanho fixo para o backlog, o qual será executado até zero antes do término do intervalo de planejamento.

  • Evite criar / analisar muitas histórias (requisitos / defeitos) para reduzir o desperdício
  • Garanta o nível necessário de análise antes de iniciar o desenvolvimento
  • O backlog deve ser orientado por eventos, com um ponto de pedido
  • Priorização sob demanda – o processo ideal de planejamento de trabalho deve sempre fornecer à equipe a melhor coisa para trabalhar a seguir, nem mais nem menos

Planejamento de iteração

No Scrumban, podemos fazer o planejamento de iteração em intervalos regulares, sincronizados com revisão e retrospectiva, mas o objetivo do planejamento é preencher os espaços disponíveis e não preencher todos os espaços e, certamente, não determinar o número de vagas. Isso reduz muito a sobrecarga e a cerimônia do planejamento de iteração.

O tempo gasto no processamento em lote para estimativa de planejamento da iteração pode ser substituído por uma inspeção de controle de qualidade no momento em que o trabalho é promovido para a fila pronta. Se um item de trabalho tiver problemas, ele será devolvido e merecerá uma análise de causa raiz.

Scrumban Board

scrumban board

Vantagens do Scrumban

  • Qualidade
  • Just-in-time (decisões e fatos justamente quando são necessários)
  • Prazo curto de entrega
  • Kaizen (melhoria contínua)
  • Minimização de desperdício (tudo o que não agrega valor ao cliente)
  • Melhoria de processo, adicionando alguns valores do Scrum como e quando necessário

Quando considerar Scrumban

  • Projetos de manutenção
  • Trabalho orientado a eventos, como help desk / suporte ou na fase de embalagem
  • Projetos com histórias de usuários frequentes e inesperadas ou erros de programação
  • Equipes focadas no desenvolvimento de novos produtos
    • Trabalho que antecede o desenvolvimento do sprint (backlog, pesquisa e desenvolvimento)
    • Trabalho após o desenvolvimento do sprint (teste, empacotamento e implantação do sistema)
  • Se o Scrum apresentar problemas de fluxo de trabalho, recursos e processos
  • Gerenciar comunidades de melhoria durante / após o início do uso do Scrum

Kanban vs. Scrumban

  Kanban Scrumban
Papéis Nenhum papel prescrito Equipe + papéis necessários
Reunião diária de Scrum Sem reuniões Garantir trabalho contínuo nos requisitos e reduzir tempo ocioso dos membros da equipe
Pode ser feito para planejar o preenchimento dos espaços
Reunião de Revisão e Retrospectiva Não prescrito Podem ser feitas conforme necessário para melhorar o processo e compartilhar aprendizados
Fluxo de Trabalho Contínuo Mesmo que no Kanban, porém limita os espaços  para que o processo de “puxar” se torne mais confortável

Scrum vs. Scrumban

Scrum Scrumban
Artefatos Conselho, backlogs, burndowns Somente conselho
Cerimônias Scrum diário, planejamento da sprint, revisão da sprint, retrospectiva da sprint Scrum diário (planejamento, revisão e retrospectiva conforme necessário)
Iterações Sim (sprints) Não (fluxo contínuo)
Estimativa Sim Não (tamanho similar)
Equipes Deve ser multifuncional Pode ser especializado
Papéis Product Owner, Scrum Master, Equipe Equipe + papéis necessários
Trabalho de equipe Colaborativo, conforme as tarefas necessitem Todos juntos para atingir objetivos
Trabalho em andamento Controlado pelo conteúdo da sprint Controlado pelo estado do fluxo de trabalho
Mudanças Devem esperar pela próxima sprint Adicionadas ao quadro conforme necessário
Backlog do produto Lista de histórias priorizadas e estimadas Cartões just-in-time
Impedimentos Tratados imediatamente Evitados

Resumo

Kanban é compatível com a mecânica do Scrum, o método de gerenciamento de projetos. A adição do WIP (trabalho em processo) e visualização ao Scrum (ou seja, Scrumban) ajuda a melhorar a eficácia do Sprint.

Além disso, também está introduzindo o limite do WIP como um mecanismo para catalisar mudanças incrementais. O limite de WIP elimina a necessidade de compromisso para impulsionar a mudança, reduz a dependência disfuncional do esforço heroico e melhora o sistema ao considerar possíveis melhorias. Na prática se parece um pouco como o Scrum, mas no nível cultural ele se parecerá com Kanban – evolução suave ao invés de tratamento de choque e revolução.

Mauro Sotille

Especialista em gerenciamento de projetos, programas, PMO e riscos. Com 25 anos de experiência em gerenciamento de projetos, foi responsável por mais de 50 projetos em diversos países. Atuou em empresas como Hewlett-Packard, Saab Sweden e Dana. É Diretor da PM Tech (www.pmtech.com.br), onde fornece capacitação profissional e consultoria a organizações na implantação bem-sucedida de cultura corporativa de Projetos. Foi Mentor do Project Management Institute (PMI) para o Brasil, Presidente do PMI-RS e membro da equipe que desenvolveu o Guia PMBOK® e outros guias. Certificado pelo PMI como Project Management Professional (PMP) desde 1998, Risk Management Professional (PMI-RMP) e PMO-CC, é autor de livros sobre Gerenciamento de Projetos, Escritórios de Projetos (PMO) e Certificação PMP. Doutorando em Administração de Empresas, possui MBA em Administração, pós-graduação em Computação e graduação em Informática e em Engenharia Mecânica. É professor convidado junto à Fundação Getúlio Vargas e outras instituições.

Siga-me: TwitterFacebookLinkedInPinterestGoogle PlusFlickr

Artigos Relacionados

Deixar Um Comentário