BT

O Kanban é o novo Scrum?

por Todd Charron , traduzido por Eric Fer em 17 Jul 2012 |

Por vários anos, muitas pessoas consideraram o Scrum como o ponto de partida ao se iniciar uma implementação ágil. De fato, muitos acreditam (de forma equivocada) que Scrum e Agile são a mesma coisa. Pela atual popularidade e extensa adoção, o Scrum tem sido a escolha ágil padrão de muitas organizações. Entretanto, com o recente crescimento da adoção do Kanban, alguns o veem como o próximo passo na evolução do Agile.

Abby Fichtner declarou em seu artigo que o Kanban é o novo Scrum:

Talvez seja pelo tempo que passei em startups, mas apesar de valorizar muito as ideias do Scrum como a auto-organização das equipes e do feedback contínuo, não posso deixar de pensar no Kanban como o próximo nível de agilidade, permitindo mais flexibilidade e aprendizado com as lições que temos extraído do Lean.

O maior problema que Abby identifica no Scrum é o sprint [com tempo fixo]:

Ao se trabalhar com startups, o conceito de sprint do Scrum é quase sempre considerado um intervalo de tempo muito longo para uma realidade imediatista. Quando os sprints são longos, as releases não são frequentes (postergando a entrada de receita) e a equipe é forçada a esperar muito tempo para poder se adaptar às novas necessidades do cliente. Isso se torna um desperdício, uma vez que se continua seguindo em frente com informações desatualizadas.

Por outro lado, se os sprints são muito curtos, funcionalidades grandes serão arbitrariamente divididas em partes menores, cujas partes, isoladamente, não serão úteis para o cliente e podem não deixar claro o que a equipe está tentando entregar como produto final.

Abby sugere que, uma vez que o Kanban não tem sprints e se preocupa em limitar o trabalho em progresso (Work In Progress - WIP), duas coisas acontecem ao ter uma funcionalidade concluída:

  1. A funcionalidade está disponível para implantação imediata em produção (caso a equipe entenda ser oportuno fazê-lo)
  2. A equipe pode começar a trabalhar na próxima demanda de maior prioridade, mesmo que a necessidade por esta demanda tenha sido descoberta no mesmo dia!

O resultado é mais feedback e a capacidade de se adaptar mais rapidamente às mudanças.

Erwin Verweij discorda, dizendo que no Scrum:

[A equipe] pode decidir como desenvolver a solução da melhor forma possível. Não existe pressão. A equipe estima o trabalho a ser desenvolvido e tem uma visão clara do que pode e do que não pode ser feito. Sei que a maioria dos gerentes de projeto gostam de ter o controle. E perder esse controle (mesmo que seja um falso controle) os faz sentir que estão sendo deixados de fora do processo.

E então tem-se o Kanban, que devolve o controle, definindo um fluxo de trabalho num formato visual que os gerentes de projeto entendem e amam. O Kanban não diz nada a respeito de velocidade ou o que pode ser feito em um período de tempo. Deste modo os gerentes de projeto podem começar a empurrar atividades para as equipes.

Os gerentes de projeto podem pressionar e começar a forçar a entrada de atividades (o que remete um pouco ao modelo Cascata (Waterfall)), ao usarem um quadro que representa o projeto dividido em colunas (design, desenvolvimento, testes etc).

Lisa Crispin, cuja equipe começou com Scrum e agora usa práticas do Lean, Kanban e XP, declara o seguinte:

O que nos tornou uma ótima equipe foi a habilidade genuína de se auto-organizar. A cada duas semanas nós temos uma retrospectiva e realmente queremos melhorar.

Acho que isso se deve ao fato da organização ter o foco na qualidade, deixando a equipe de desenvolvimento descobrir por si própria o que é preciso fazer para entregar software com a maior qualidade possível.

Derek Huether complementa:

Acredito que mais organizações precisem saber que o Kanban é uma alternativa viável ao Scrum. Ao continuarmos na capacitação de nossas equipes, mantendo uma boa cadência e tendo poucas cerimônias, mais equipes irão preferir o Kanban ao invés do Scrum.

George Dinwiddie parece ter encontrado um ponto de equilíbrio, entre os argumentos sobre Scrum e Kanban:

O Kanban tem foco em limitar o trabalho em progresso e sugere um intervalo curto de tempo entre a chegada da demanda e a entrega do produto final. Uma cadência regular é recomendada; o Scrum tem foco em cadências curtas e regulares e sugere também uma limitação do trabalho em progresso. Se você está aplicando estes modelos corretamente, ambos o levam para o mesmo objetivo.

Abby conclui:

Ainda acredito que o Scrum compreende excelentes ideias - como a auto-organização e feedback contínuo - que não deveriam ser menosprezadas. Mas essas mesmas ideias continuam funcionando sob a aplicação do Kanban.

Você acredita que o Kanban é o próximo passo depois do Scrum? Acredita que ambos, Scrum e Kanban, podem coexistir?

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Temos que ter um controle mínimo ? by Andre Cipriano

Caros, boa noite

Meu nome e André, tenho uma duvida vejo o Kanban como uma excelente opção para um fluxo continuo, lógico considero que um sistema nunca estará 100% pronto, vejo no scrum uma forma ainda de se fazer uma gestao do custo, do tempo enfim dar alguma previsão com base nos feedbacks que vamos obtendo, vejo atualmente uma dificuldade imensa de mostrar para o cliente que o sistema será construído de acordo com o budget que ele esta disposto a pagar, não sei se vocês me entendem gostaria do auxilio de vocês para que eu possa trabalhar essa dificuldade. Como vocês tem conduzido projetos com começo meio e fim?

Abraços e obrigado

Re: Temos que ter um controle mínimo ? by Rafael Buzon

Oi André, tudo bom?

Sua dúvida é pertinente e muito já foi discutido sobre estimativas, previsibilidade e previsões. Aqui vão algumas referencias aqui do próprio InfoQ Brasil:

Estimativas em Agile: Quanto tempo vai demorar para terminar o produto?
www.infoq.com/br/news/2011/10/estimativas-agile

Estimativas e cronogramas: úteis, prejudiciais ou os dois?
www.infoq.com/br/articles/estimativas-versus-cr...

Precisão e acurácia em estimativas ágeis
www.infoq.com/br/articles/precisao-acuracia-agile

Os projetos sempre têm um fim. E quando o fim é determinado (fixo pelo cliente muitas vezes), é melhor ainda. A questão gira um pouco sobre o paradigma do escopo X entrega de valor; seguir um plano X estar preparado para mudança; Colaboração X negociar contratos.

Em ágil, há muito peso no valor real gerado e priorizado pelo cliente, que é feito em primeiro lugar. Os compromissos de um projeto ágil se dão mais sobre os objetivos e metas que se busca atingir e não tanto sobre um escopo fechado. Há uma via de mão dupla com o cliente, na construção conjunta e colaborativa do produto, onde o risco é compartilhado ao invés de totalmente transferido ao fornecedor ou equipe que desenvolve.

A grosso modo é isso: um tempo fixo predeterminado (ou devido ao orçamento disponível ou à uma data fixa importante) e uma negociação sobre gerar valor colaborativamente com o cliente, neste período de tempo, a ponto de valer a pena o investimento e os objetivos principais serem atingidos.

...bem a grosso modo :)

Abraços,
Buzon

Re: Temos que ter um controle mínimo ? by Andre Cipriano

Abraços Buzon, muito obrigado!

Re: Temos que ter um controle mínimo ? by Leonardo Campos

Buzon, muito boa a resposta.

Um outro ponto que acho poderia ser ressaltado é o da previsibilidade.

Em sistemas "empurrados" (Mais tradicional sem limite de trabalho em progresso), o cronograma é obtido mais ou menos assim:
1 - Obtém-se o compromisso;
2 - Para se ter um cronograma;
3 - Para se ter alguma previsibilidade.

Nos sistemas puxados (caso do Kanban e do Scrum):
1 - Obtém-se previsibilidade (Velocidade/Throughtput/Lead Time - métricas históricas)
2 - Pare se ter um cronograma;
3 - Para então se ter um compromisso.

Tanto no Scrum quanto no Kanban a previsão é feita com base em aprendizado constante da própria "capacity" (em inglês não fica mais claro). A diferença é que ao passo que o aprendizado acontece em lote no Scrum (um Sprint), no Kanban acontece por história. Você vai medir quantas User Stories (ou pontos se preferir), por exemplo, se entrega por unidade de tempo, e então a projeção de futuro se dá na mesma forma que se faz com Scrum.

Um exemplo: Imagine que sua equipe consegue entrega 10 User Stories somando 60 pontos em 2 semanas. Agora a regra de previsibilidade é a mesma que no Scrum, apenas não se tem mais "Sprints" ou iterações.

Cuidado apenas se você for passar SLAs, mas acho que este é outro tópico ;-)

Espero ter contribuído com a resposta do Buzon.

Abraços,
Leonardo Campos

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

4 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT