No nosso último artigo sobre Kanban, vimos alguns dos princípios básicos para que ele funcione corretamente. Começamos a abordar também que o Kanban não é uma metodologia ágil. Por ele ser comumente utilizado junto a uma metodologia ágil, como o Scrum por exemplo, pode haver essa confusão.
Sendo assim, vamos abordar nesse artigo quais são essas diferenças e como eles se complementam entre si.
*(Vale lembrar que já temos um artigo explicando sobre o Scrum, caso você queira saber mais sobre essa metodologia leia nosso artigo “Scrum como ferramenta de apoio ao gerenciamento de projetos”.
Curso Google Cloud - App Engine
Conhecer o cursoAfinal, quais são essas diferenças?
Depois de saber um pouco mais sobre o Scrum e o Kanban, podemos ver que eles compartilham alguns dos mesmos conceitos, mas com abordagens diferentes, portanto não devem ser confundidos um com o outro.
Na tabela abaixo, podemos ver de maneira geral algumas das principais diferenças.
| Kanban | Scrum | |
|---|---|---|
| Ritmo | Fluxo contínuo | Sprints regulares definidas (ex: 1 semana, 2 semanas) |
| Funções | Sem funções existentes | Funções definidas, como Scrum Master, equipe de desenvolvimento, etc. |
| Entregas | Contínua ou a critério da equipe | No final de cada Sprint devem ser aprovadas. Caso não seja, a mesma tarefa volta para a próxima Sprint. |
| Mudanças | Podem ocorrer a qualquer momento | As equipes devem se esforçar para não fazer alterações na previsão da sprint durante a mesma, pois a estimativa fica comprometida. |
Em outras palavras, o Kanban foca mais no acompanhamento visual dos processos e o Scrum no gerenciamento do projeto, por isso a junção desses dois é muito utilizada. Vamos abordar agora como é feita essa implementação em uma empresa.
Curso Selenium - Testes Automatizados com TestNG
Conhecer o cursoColocando o Kanban e Scrum em prática
Primeiramente precisamos ressaltar a importância do engajamento da equipe. Sem isso você não conseguirá ter sucesso. Esse engajamento é importante pois, no Kanban, cada colaborador é responsável por manter o painel sempre atualizado.
Primeiro começamos indo mais para o lado do Scrum, onde precisamos realizar alguns passos essenciais. Você deve definir sua equipe, escolher o Product Owner (pessoa responsável pela visão do que será entregue no projeto) e o Scrum Master (quem irá orientar a equipe).
Após os cargos definidos aos responsáveis, deve ser elaborada a Product Backlog, que é uma lista geral detalhada de tudo que precisa ser feito para chegar ao objetivo final, como por exemplo, a finalização de um software.
Após definir todas as tarefas que devem ser executadas na Product Backlog, deve-se estimar o respectivo esforço para cada uma delas. Isso é necessário para determinar a produtividade e a velocidade do projeto.
Uma das formas utilizadas é utilizando a sequência de Fibonacci. Mas calma que não é tão complicado assim. É determinado uma estimativa de pontos para cada tarefa, como 1,2,3,5,6,13,21… É bem rápido de se acostumar. Por exemplo, uma tarefa com 1 ponto, é uma tarefa bem rápida de ser feita, provavelmente poucas horas do dia, enquanto uma tarefa com 13 pontos já demanda um tempo maior, como alguns dias.
Depois das tarefas e estimativas prontas, é a hora da primeira reunião. Ela servirá para planejar a Sprint, que pode ser de 1 ou 2 semanas geralmente. Também é definido a Sprint Backlog, onde algumas tarefas da Product Backlog irão para a Sprint a fim de serem concluídas durante o período estimado.
Normalmente são passadas as tarefas prioritárias ou tarefas que conseguirão ser concluídas naquele período. É importante todos os envolvidos concordarem com o objetivo da Sprint. Também é importante pensar na realidade: colocar três tarefas com 13 de pontuação para um colaborador realizar em uma semana, pode ser que essas tarefas não sejam concluídas. Por isso que temos a pontuação para nos indicar o quanto de esforço teremos em cada tarefa e assim ter a estimativa se ela vai conseguir ser concluída a tempo. Se não, você pode até quebrar essa tarefa em duas ou três tarefas menores.
Agora vamos entrar no ponto que entra a metodologia Kanban. Você irá utilizar o Kanban para organizar o desenvolvimento, podendo ser utilizado um quadro com post-its ou também por meios digitais, já que temos muitas plataformas que permitem isso. Se for um quadro físico ele deve ficar em um local de fácil acesso onde todos possam vê-lo e se informar. Esse quadro pode ser dividido em “A fazer – Em execução – Feito” ou você pode dividir as colunas de acordo com suas necessidades. O importante é a equipe saber bem o que significa cada coluna e sempre manter os post-its atualizados.
A partir daí teremos o Daily Scrum, uma reunião diária entre a equipe e o Scrum Master. É uma reunião rápida apenas para que cada um responda a três perguntas: “O que você fez ontem?”, “O que vai fazer hoje?” e “Quais os problemas encontrados?”. Lembrando que são respostas curtas e rápidas, mas que serve para que toda a equipe saiba em que ponto estão na Sprint. Com isso, o Scrum Master conseguirá ver se todas as tarefas serão concluídas a tempo, e claro, é ele quem irá resolver qualquer obstáculo que possa ter na equipe.
Após o período da Sprint (1 ou 2 semanas) é realizada a Sprint Review. É a reunião onde a equipe apresenta o que conseguiu evoluir durante a Sprint, podendo apresentar somente o que conseguir colocar no quadro como “feito”, ou seja, a tarefa deve estar totalmente concluída.
Por fim, temos a retrospectiva da Sprint, onde os envolvidos podem fazer uma avaliação de tudo o que aconteceu, como lições aprendidas, o que não deu certo, dificuldades, o que pode ser melhorado. É uma reunião de feedback para aprimoração do processo, podendo assim melhorar as próximas Sprints.
Feito isso, volta tudo de novo… Uma nova Sprint, novas tarefas a serem realizadas, e assim sucessivamente.
Concluindo…
Agora sim ficou mais claro onde o Kanban ajuda o Scrum e como eles se complementam, outro artigo que aconselho a leitura é sobre as diferenças entre metodologia ágil x tradicional. E você, já fez uso deles na sua empresa?
