Scrumban: Como escolher o meio termo entre Scrum e Kanban

By Kate Eby | 22 de August de 2016

Depois que o Manifesto Ágil entrou na consciência do desenvolvimento de software, metodologias Ágeis começaram a surgir, buscando uma forma de colocar em prática os valores e princípios do método Ágil. Essas metodologias incluem Programação extrema (XP), Scrum, Desenvolvimento gerado por recursos (FDD), Desenvolvimento de software enxuto, Processo Ágil unificado (UP Ágil ou AUP), Crystal, Kanban e Método de desenvolvimento de sistemas dinâmicos (DSDM).

Cada método tem pontos fortes e fracos e cada um atende às necessidades dos desenvolvedores, mas com diferenças sutis. Como Andy Kyte, David Norton e Nathan Wilson, da Gartner, explicam em 10 Things CIOs Need to Know about Agile Development: “Na maioria das organizações comerciais e do setor público, o portfólio de aplicativos apresentará muitas classes diferentes de problemas de desenvolvimento, algumas das quais serão bem adequadas para o método ágil, enquanto outras podem ser mais adequadas para o desenvolvimento repetitivo gradual e outras ainda para um modelo de Waterfall modificado. O Ágil não é o “melhor”; é simplesmente mais bem adaptado a alguns problemas, mas não tanto a outros”.

Atualmente, o Scrum é a metodologia Ágil mais popular para desenvolvimento de software. No entanto, o Kanban tornou-se amplamente empregado para projetos de manutenção em que a grande mudança não é necessariamente a meta do projeto, mas sim o desenvolvimento contínuo sem depender de um backlog claramente definido. Este artigo discutirá como o Scrumban se tornou o meio termo entre as metodologias Ágeis Scrum e Kanban. Para entender totalmente o Scrumban, é preciso ter uma compreensão completa do Scrum e do Kanban.

Scrum: vantagens e desvantagens

Cada metodologia possui vantagens e desvantagens. Scrum é uma metodologia Ágil na qual pequenas equipes trabalham em colaboração por curtos períodos de desenvolvimento (sprints), para fornecer um software funcionando no final de cada sprint com prazos limitados. O Scrum muda deliberadamente o processo de planejamento, concentrando-se no rápido desenvolvimento do software em funcionamento em partes menores. Algumas das vantagens do Scrum são:

  • Melhorar a organização do cronograma – O Scrum supera a questão de requisitos de negócios complexos que são difíceis de entender e que dificultam a organização do cronograma. A abordagem Scrum de avaliar os requisitos é dividi-los em partes viáveis que são desenvolvidas rapidamente.
  • Reduzir o impacto dos erros – Os erros que podem ser cometidos em um Scrum são rapidamente retrabalhados e corrigidos no próximo Scrum.
  • Melhorar a comunicação – As reuniões diárias garantem que as atualizações de status (progresso e paradas) sejam altamente visíveis. Na verdade, o gerenciamento do desenvolvimento pode ser reduzido ao uso de um quadro de tarefas, no qual o backlog do Sprint está listado em uma tabela, juntamente com colunas relativas ao status.
  • Aumentar a produtividade – Reuniões diárias aumentam a produtividade da equipe.
  • Desenvolver melhores relacionamentos com o cliente – A natureza iterativa do Scrum resulta na importância do envolvimento e do feedback do cliente, e isso torna a equipe mais consciente das necessidades do cliente e a equipe, por sua vez, pode ser mais sensível a essas necessidades.
  • Melhorar o software – A mudança não é uma interrupção, mas um meio de melhorar o valor do software.

Em contrapartida, algumas das vantagens do Scrum são:

  • Aumentar o escopo – Sem um término definido para um projeto, e com a mudança adotada com satisfação, o aumento do escopo se torna um problema real. As partes interessadas geralmente são tentadas a adicionar cada vez mais funcionalidades.
  • Não é ideal para equipes grandes – O Scrum funciona melhor em equipes pequenas.
  • Membros inexperientes da equipe podem ser uma responsabilidade – A implementação bem-sucedida do Scrum depende da capacidade de os membros da equipe estimarem o tempo de desenvolvimento.
  • Inadequado para microgerenciadores – O Scrum funciona melhor quando o Scrum Master pode contar com a equipe sem temperamento controlador exagerado. No Scrum, indivíduos gerenciam seu trabalho em conjunto, não recebendo muita supervisão.
  • A rotatividade pode ser extremamente negativa – O pequeno tamanho da equipe e a falta dos períodos de desenvolvimento podem ser penosos.
  • O gerenciamento da qualidade é mais difícil – Os membros da equipe realizam todos os testes, mas os testes de regressão às vezes são deixados de fora do ciclo, e, como resultado, os testes de unidade acabam sendo os únicos realizados.

O que é a metodologia Kanban?

O Kanban, desenvolvido por Taiichi Ohno, engenheiro da Toyota, é definido como um método para gerenciar e melhorar a prestação de serviços gradualmente ao longo do tempo. Existem três princípios orientadores do método Kanban:

  • Comece com o que você tem agora
  • Aceite buscar mudanças graduais e evolutivas
  • Respeite o processo, as funções, as responsabilidades e os cargos atuais

Existem cinco propriedades principais do Kanban:

  • Visualizar o fluxo de trabalho
  • Limitar o trabalho em andamento (WIP)
  • Gerenciar o fluxo
  • Tornar explícitas as políticas de gerenciamento e processo
  • Melhoria contínua, também conhecida como Kaizen (usando modelos e método científico)

Kanban: vantagens e desvantagens

Assim como o Scrum, o Kanban tem suas vantagens e desvantagens. Algumas das vantagens do Kanban são:

  • Melhorar a alocação de recursos – O WIP é limitado, de modo que novos trabalhos são enviados para a equipe à medida que os recursos se tornam disponíveis.
  • Simplificar o gerenciamento de projetos – O quadro Kanban fornece uma visualização rápida do estado de todo o trabalho, permitindo um gerenciamento de projetos mais facilitado.
  • Reduzir a interrupção – A mudança é menos radical porque se trabalha com os processos que se tem e os melhora ao longo do tempo.
  • Tomar decisões mais informadas – Visualizar o fluxo de trabalho facilita a compreensão de como o trabalho prossegue e as decisões sobre as mudanças.

Algumas das desvantagens do Kanban são:

  • Os quadros Kanban devem ser atuais – Um quadro Kanban desatualizado pode causar grandes problemas. O Kanban conta com membros da equipe para manter tudo atualizado e, sem as reuniões diárias do Scrum, isso pode ser mais difícil de fazer.
  • Tornar o quadro Kanban excessivamente complexo – Quando há muitos itens ou processo sendo monitorados em um quadro Kanban, pode causar confusão e dificultar a atualização com precisão.
  • Falta de prazos– Sem prazos para o desenvolvimento, a equipe pode ficar atrasada

Scrum e Kanban: quais são as diferenças

Scrum e Kanban são muito diferentes. Pode parecer impossível conciliá-los. O Scrum tem um conjunto de funções prescritas, incluindo o Scrum Master, o proprietário do produto e a parte interessada. Por outro lado, o Kanban não tem funções prescritas. Tanto o Scrum quanto o Kanban são vistos como sistemas de “extração”, isto é, os membros da equipe extraem os recursos do backlog à medida que estão disponíveis para trabalhar neles. Outra perspectiva é que, devido ao caráter de “lote” do backlog, o Scrum é realmente um sistema de “extração”, no qual um conjunto de recursos é atribuído à equipe no início do Sprint. O Kanban é considerado um sistema inegavelmente baseado em extração, no qual os recursos são continuamente extraídos do backlog conforme necessário.

O Scrum possui uma reunião diária e várias reuniões necessárias, como a demonstração em que o software é revelado ao cliente para feedback. O Kanban não tem reuniões obrigatórias.

Talvez a diferença mais marcante entre o Scrum e o Kanban seja que enquanto o Scrum é limitado pela duração de Sprint, o Kanban opera sem um limite de tempo para o desenvolvimento. Não há início ou fim definido, mas sim um fluxo contínuo de trabalho, em que cada desenvolvimento bem-sucedido é seguido pelo início de um novo desenvolvimento.

Embora o Scrum seja feito para ser fácil e flexível, algumas equipes de desenvolvimento o acham muito rígido para seus negócios ágeis. Ao mesmo tempo, acham o Kanban muito vago. O Scrumban nasceu como um meio-termo entre o Scrum e o Kanban: a rigidez do Scrum combinada com a suavidade do Kanban tornou-se um método perfeito para muitas organizações ágeis.

Metodologia Scrumban: o melhor dos dois mundos

O Scrumban foi introduzido por Corey Ladas, um entusiasta da metodologia de desenvolvimento de software, em seu livro Scrumban: Essays on Kanban Systems for Lean Software Development. Ele afirma que o Scrumban foi criado como um meio de transição de uma equipe de desenvolvimento do Scrum para o Lean (depende de uma construção, medida, aprender fluxo para melhoria contínua e se concentra apenas no que traz valor aos clientes) ou o Kanban. Embora a intenção fosse que as equipes substituíssem o Scrum, tornou-se uma metodologia própria, combinando elementos do Scrum e do Kanban. A decisão de substituir o Scrum ou o Kanban pelo Scrumban deve ser tomada em resposta às necessidades ambientais e organizacionais.

O Scrumban é mais comumente usado em projetos de desenvolvimento e manutenção. Na prática, as equipes de desenvolvimento e manutenção precisam de muitas habilidades similares. As equipes de desenvolvimento precisam de um meio de gerenciar todo o seu processo de desenvolvimento, enquanto as equipes de manutenção devem ser capazes de fazer atualizações e reparos em software defeituoso.

Comparação do Scrumban com o Scrum

  • Iterações: a iteração é a característica definidora do Scrum, já o Scrumban adota a abordagem Kanban do fluxo de trabalho contínuo, com iterações opcionais.
  • Funções da equipe: o Scrum definiu funções em que os membros da equipe de desenvolvimento usam todas as posições de um projeto de desenvolvimento, já o Scrumban só requer funções conforme a necessidade.
  • Visualização: o Scrum pode usar quadros, mas depende principalmente de backlogs e gráficos de burndown, já o Scrumban, como o Kanban, depende do quadro do Scrumban para manter a visibilidade do trabalho.
  • Reuniões: o Scrum e o Scrumban realizam reuniões diárias, mas não há Sprint ou reuniões de planejamento de releases e retrospectivas no Scrumban. O Scrumban incorpora o planejamento sob demanda.
  • Estimativa: as equipes do Scrum devem estimar (muitas vezes usando o sistema de planejamento do período e pontos da narrativa) o tempo que o trabalho leva para cumprir os compromissos de uma Sprint, já o Scrumban não tem restrição de tempo. Em vez disso, a estimativa se torna aparente com o tempo à medida que a equipe realiza mais tarefas.
  • WIP: o WIP do Scrum é definido inteiramente pelo backlog da Sprint e planejado no início de cada Sprint, já a equipe do Scrumban limita o WIP aos recursos disponíveis.
  • Mudança: a mudança é bem-vinda no Scrum porque pode ser respondida e planejada em uma Sprint subsequente, mas, no Scrumban, a mudança é respondida instantaneamente. Com a falta de Sprints e backlogs, não há limites de tempo para a introdução de tarefas. A mudança se torna questão de disponibilização de um recurso para que seja assumido.
  • Congelamento de recursos: embora o Scrumban responda à mudança instantaneamente, há um limite. O Scrumban adota o congelamento de recursos – um tempo de corte em que mudanças ou recursos adicionais não podem ser adicionados porque o prazo do projeto está se aproximando.
  • Triagem: como o Scrumban não incorpora a estimativa, o estágio de triagem é fundamental. À medida que um prazo do projeto se aproxima, a triagem do Scrumban permite que o gerente de projetos encerre o trabalho com recursos menos importantes, a fim de concluir os recursos essenciais dentro do prazo.

Comparação do Scrumban com o Kanban

  • Funções da equipe: o Kanban não tem funções prescritas, mas, no Scrumban, há uma equipe definida e pode ter funções obrigatórias.
  • Reuniões: o Kanban não precisa de reuniões, mas o Scrumban é comporto por reuniões diárias. As reuniões diárias ajudam a manter a colaboração entre os membros da equipe e a superar os impedimentos para o progresso. Além disso, embora o Kanban seja um processo em evolução, não há reuniões prescritas para examinar a evolução ou melhorias propostas. O Scrumban permite retrospectivas pós-projeto que permitem que a equipe trabalhe em melhorias de processo e que os membros da equipe compartilhem o que aprenderam com o trabalho.
  • Métricas: tanto o Kanban quanto o Scrumban contam com a medição do tempo de espera e do tempo do ciclo (às vezes usados de forma intercambiável) como métrica-chave. Esta métrica estima o tempo médio necessário para concluir uma tarefa específica. O tempo de espera é o que o cliente vê desde o momento em que uma solicitação é feita até a entrega. O tempo do ciclo é o tempo desde o início do trabalho até a entrega.

Qual é o melhor ambiente para introduzir o Scrumban?

Você pode estar se perguntando qual é o melhor ambiente para introduzir o Scrumban. Como em todas as metodologias, o Scrumban não é para todos os ambientes ou culturas. Se sua organização é ideal para o Scrum, com muitos membros experientes, clientes que desejam participar do processo de desenvolvimento, uma compreensão clara das histórias dos usuários e uma cultura corporativa em que o gerenciamento e cronogramas de projetos definidos são altamente considerados, talvez queira se ater ao Scrum. Se você está operando principalmente em um ambiente de manutenção no qual o novo desenvolvimento é uma pequena parte das atividades da equipe, o trabalho está em andamento, é importante extrair tarefas conforme necessário e não há projetos definidos para clientes específicos, talvez queira se ater ao Kanban.

O melhor momento para implementar o Scrumban é quando:

  • Um projeto tem uma grande quantidade de mudanças inesperadas nas histórias de usuários e retrabalho de prioridades.
  • Você quer adicionar a extração de recursos ao processo de desenvolvimento do Scrum.
  • O Scrum não teve sucesso devido a vários problemas ou porque não há recursos suficientes para atender às restrições de tempo do Scrum.
  • O trabalho é impulsionado por eventos, como a central de atendimento, em que as prioridades mudam constantemente.
  • A equipe está totalmente focada em adicionar recursos e apoiar um produto existente.
  • O Scrum é usado por sua equipe de desenvolvimento, mas você está interessado em alguns princípios do Kanban.
  • Você acha que parte da rigidez do Scrum limita a capacidade da sua equipe de se adaptar às mudanças.
  • Você está em transição para o Kanban, mas precisa fazer pequenas mudanças de metodologia para limitar a interrupção.

A palavra final do Scrumban sempre será como a equipe responde ao método. O Scrum funciona bem para equipes que gostam de mais estrutura e querem saber no que trabalharão no dia seguinte. O principal benefício do Scrumban é a fluidez do modelo. No fim das contas, como é o caso de qualquer metodologia de desenvolvimento, a adoção da empresa e da equipe determinará o sucesso.

Por que o Smartsheet é uma ferramenta eficaz para Scrumban

Capacite seu pessoal para ir além com uma plataforma flexível desenvolvida para atender às necessidades da sua equipe e se adaptar conforme essas necessidades mudam. Com a plataforma Smartsheet fica fácil planejar, coletar informações, gerenciar e criar relatórios sobre o trabalho de qualquer lugar, ajudando sua equipe a ser mais eficiente e mostrar resultados. Crie relatórios sobre as principais métricas e obtenha visibilidade do trabalho em tempo real, à medida que ele acontece, através de relatórios, painéis e fluxos de trabalho automatizados criados para manter sua equipe conectada e informada. Quando as equipes têm clareza sobre o trabalho que está sendo realizado, elas podem ser muito mais produtivas durante o mesmo período de tempo. Experimente o Smartsheet gratuitamente hoje mesmo.

 

Ligue os seus colaboradores, processos e ferramentas com uma plataforma simples e fácil de utilizar.

Experimente o Smartsheet gratuitamente Get a Free Smartsheet Demo