Metodologia Ágil

Kanban x Scrum: diferenças e como implementá-los

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 antes de prosseguir nesse artigo.)

Selenium - Testes Automatizados com TestNG
Curso de Selenium - Testes Automatizados com TestNG
CONHEÇA O CURSO

Afinal, 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.

KanbanScrum
RitmoFluxo contínuoSprints regulares definidas (ex: 1 semana, 2 semanas)
FunçõesSem funções existentesFunções definidas, como Scrum Master, equipe de desenvolvimento, etc.
EntregasContínua ou a critério da equipeNo final de cada Sprint devem ser aprovadas. Caso não seja, a mesma tarefa volta para a próxima Sprint.
MudançasPodem ocorrer a qualquer momentoAs 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.

Colocando 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). Lembrando que você pode saber mais sobre esses termos neste artigo.

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. E você, já fez uso deles na sua empresa?

PMP/CAPM - Modelos Econômicos e Ética para Gerentes de Projetos
Curso de PMP/CAPM - Modelos Econômicos e Ética para Gerentes de Projetos
CONHEÇA O CURSO

Scrum como ferramenta de apoio ao gerenciamento de projetos

No post anterior, vimos como os projetos de TI podem ser beneficiados utilizando as técnicas do PMI. Foi citado também sobre a utilização de metodologias ágeis como forma de complemento para o sucesso nos projetos de TI. Veremos neste artigo mais profundamente sobre o Scrum, principal metodologia ágil utilizada no mercado.

Teste de Software Avançado
Curso de Teste de Software Avançado
CONHEÇA O CURSO

O que é e como funciona o Scrum?

O Scrum é uma metodologia ágil que permite manter o foco na entrega de valor para o negócio no menor tempo possível. Seu conceito principal é decompor um projeto em pequenas tarefas mais simples, chamadas de Sprints. Uma Sprint pode ser semanal ou mensal, tendo datas de início e fim bem definidas, possuindo as atividades que devem ser cumpridas dentro deste prazo.

Essa metodologia é composta basicamente por três papéis:

Product Owner ou Dono do Produto

Representa o negócio em si, além de ser o ponto central de liderança do projeto. É função dele comunicar a todos quais objetivos quer atingir. Para isso, ele precisa colaborar ativamente com o Scrum Master e toda a equipe de desenvolvimento, como por exemplo, participar das reuniões e responder rapidamente às questões realizadas pelo time. Ele é responsável por aceitar ou rejeitar o resultado dos trabalhos.

Scrum Master

O Scrum Master orienta a equipe para que as metas sejam cumpridas devidamente. É responsável para que o Scrum seja entendido e aplicado por todos da equipe. Ele também ajuda a desenvolver sua própria abordagem do Scrum, porém sempre respeitando as particularidades de cada organização.

Time de desenvolvimento

O time de desenvolvimento deve ser constituído por poucas pessoas, é recomendado no máximo 10. Aí você deve estar se perguntando o que fazer caso você tenha uma equipe de 15 ou 20 pessoas. A resposta é simples! Você sempre deve dividir sua equipe nesses casos. Uma equipe de 20 pessoas pode ser dividida em 3 equipes menores, podendo ser duas equipes com 7 pessoas e uma equipe com 6 pessoas.

Estas devem se programar para que a meta do Product Owner seja atingida. O time deve conter as habilidades e conhecimentos necessários para produzir com qualidade.

Principais artefatos da metodologia

Agora vamos fazer um passo a passo de como deve funcionar a metodologia Scrum. Primeiramente deve ser determinado quais são as funcionalidades a serem implementadas, estas ficarão em uma lista chamada “Product Backlog”, podendo ser requisitos funcionais, não-funcionais e até mesmo configurações do ambiente. A “Sprint Planning Meeting” é uma reunião na qual é decidido os requisitos, estes devem agregar valor de negócio do produto.

A Sprint deve começar com uma “Daily Scrum Meeting”, onde é priorizada as funcionalidades contidas na “Product Backlog”, selecionando as atividades que cada um da equipe irá realizar na Sprint que irá ser iniciada, priorizando as atividades mais importantes primeiro, porém devem ser tarefas que possam ser completadas durante a Sprint.

É importante ressaltar que não pode ter mudanças nas tarefas durante a realização da Sprint

Cada membro do time escolhe uma tarefa da “Product Backlog” e deve atualizar o status dessa tarefa a cada dia.

As tarefas escolhidas para a Sprint passarão do “Product Backlog” para um outro quadro, podendo ser chamado por exemplo de “Sprint 1”, “Primeira Sprint”, etc.

A comunicação é essencial no Scrum, por isso temos o “Daily Scrum”. Ele é um encontro diário rápido, normalmente de 15 minutos e geralmente realizado logo no início do dia. Basicamente todos do time respondem às seguintes perguntas:

  • O que você fez ontem?
  • O que vai fazer hoje?
  • Quais foram os problemas encontrados?

A reunião é de grande importância pois a partir daí o Scrum Master pode medir os avanços e caso tenha algum problema, pode ser resolvido de forma imediata.

Depois que a Sprint acaba ocorre a “Sprint Review”, onde a equipe apresenta seus resultados. Nesta etapa os resultados devem ser comparados com o início da Sprint. O Product Owner identifica o que foi finalizado e o que não foi, e discute com a equipe o atual “Product Backlog” onde todos colaboram sobre o que deve ser feito a seguir, decidindo se o mesmo deve ser liberado ou continuar a ser aprimorado por mais uma Sprint. A “Sprint Review” fornece dados importantes para a reunião da próxima Sprint.

A “Sprint Retrospective Meeting”, a retrospectiva da Sprint, tem o objetivo de verificar o que funciona e o que não funciona, caso necessite será realizada adaptações no processo de trabalho. Essa reunião deve ser realizada depois de cada Sprint e todos devem participar, levantando as seguintes questões:

  • O que gostaria de começar a fazer?
  • O que gostaria de parar de fazer?
  • O que gostaria de continuar fazendo?

Após esses passos, tudo volta novamente, sendo iniciada uma nova Sprint.

Scrum Master X Gerente de Projetos

Então se eu tenho Scrum Master para gerenciar o time, eu não preciso de um gerente de projetos, certo?

Errado. O Scrum Master tem um papel de facilitador, de um líder, mas não substitui o gerente de projetos. A metodologia Scrum defende que o time deve ser auto-gerenciável, ou seja, não deve haver a necessidade de um gerente de projetos na equipe. Porém, a ideia é que isso mude e que a contribuição do gerente de projetos venha complementar o time Scrum.

O gerente de projetos e o Scrum Master tem papéis diferentes. O gerente de projetos é capacitado para liderar e trabalhar para garantir que todos os processos serão implementados corretamente. Além disso, também auxilia na prestação de contas, contribuindo para a resolução de conflitos em relação ao que é esperado pelos usuários e protege a equipe de influências externas.

Já o Scrum Master tem o seu papel de orientador, sendo que as tarefas de planejamento e execução do projeto ficam a cargo do Product Owner e da equipe do projeto. Apesar disso, ele enfrenta diversos desafios como por exemplo, a gestão do tempo para garantir a execução das atividades da melhor forma.

Quando se trata de Agile, por mais que o termo “time auto gerenciado” esteja na moda, a figura do gerente de projetos ainda é fundamental, pois um gerente de projetos pode auxiliar o Scrum Master, não o sobrecarregando com outros tipos de tarefas.

O fato é que a figura do gerente de projetos continua existindo no papel de apoiador e não de controlador. A responsabilidade total do projeto e de integração com todas as outras frentes continua sendo do gerente de projetos.

Concluindo

Apesar de tudo isso e todas as vantagens que a metodologia tem a nos oferecer, sabemos que sua aplicação é um pouco complexa, ademais, você estará lidando com pessoas. Porém, se a metodologia for aplicada corretamente e houver comunicação e planejamento entre absolutamente todos da equipe (incluindo o gerente se projetos, se houver) há grandes chances de o produto final sair conforme o planejado e em um curto prazo de tempo.

O que achou dessa metodologia? Já participou de um projeto onde o Scrum foi utilizado? Conta pra gente. =)

COBIT 5 - Fundamentos, Componentes e Certificação
Curso de COBIT 5 - Fundamentos, Componentes e Certificação
CONHEÇA O CURSO