Scrum: Tudo que Você Precisa Saber Sobre essa Metodologia!

Introdução

Se você está lendo esse Paper, você claramente tem um objetivo.

Você quer aprender como gerenciar seus times de maneira ágil para que eles tenham entregas cada vez mais rápidas e com uma qualidade maior. Conheça o Scrum!


Capítulo 1

Por que não utilizar metodologias tradicionais?

Nós não estamos dizendo que as metodologias tradicionais são de tudo ruins e não funcionam. Elas funcionaram por muito tempo, e até hoje são muito utilizadas!

Mas os métodos tradicionais de gerenciamento de projetos são extremamente engessadas para os dias de hoje, tendo planejamentos muitas vezes longos demais e que após algum tempo não são relevantes como se achava que eram.

Ao se gerenciar um time ou projeto utilizando metodologias tradicionais de gestão, normalmente se planeja um período grande de tempo, e quando os times vão realizar o planejado, qualquer adversidade já faz com que o planejamento anterior não esteja mais correto. Além do mais, durante o tempo planejado, as necessidades do cliente podem mudar (ou pode ser que você não tenha entendido a real necessidade dele), fazendo com que suas entregas não gerem o valor necessário para ele. As empresas de hoje necessitam de mais agilidade e adaptabilidade para se manter no mercado e prosperar.

Dessa forma as empresas que estavam tendo um crescimento maior do que o normal perante ao mercado notaram que precisavam de uma forma mais enxuta e ágil para gerenciar seus projetos e times. O novo método a ser utilizado deveria dar clareza aos colaboradores sobre as entregas necessárias e ser composto por ciclos menores, para que houvesse mais adaptabilidade, transparência entre os gestores e colaboradores, além de desfrutar de aprendizados a cada ciclo, tornando o próximo sempre melhor do que os anteriores.

Capítulo 2

Por que utilizar Scrum?

Digamos que você é um gerente de projetos ou um gerente estratégico da empresa onde trabalha e seus projetos tem constantes atrasos ou remarcações de deadlines, e quando conseguem terminar o trabalho, demoram para saber se as features ou funções novas que foram implementadas realmente surtem o efeito desejado nos clientes que você deseja que sejam impactados por aquilo.

Você faz tudo como o livro manda, estuda os pré-requisitos necessários para realizar a tarefa, estuda a disponibilidade de membros nas suas equipes, realiza as estimativas do tempo e recursos necessários para implementar a mudança, mas por algum motivo, sempre acaba tendo atrasos e a funcionalidade nem sempre é o que os clientes realmente querem.

Foi exatamente por estes motivos que surgiu a metodologia Scrum, uma metodologia que nasceu no começo dos anos 90 e foi popularizada por Jeff Sutherland e Ken Schwaber, junta conceitos de gestão Lean e desenvolvimento iterativo. A metodologia surgiu com o intuito de tornar o gerenciamento de projetos de desenvolvimento de software, focando em entregas constantes, focadas na criação de valor para os stakeholders e ciclos de feedback rápidos, mas já é utilizada em todas as áreas que se possa imaginar, como educação, construção civil e até projetos governamentais. O objetivo dessa metodologia é aumentar a velocidade das entregas, assim como diminuir o desperdício de trabalho e aumentar o valor percebido de cada entrega.

Temos um ótimo texto te mostrando alguns motivos para utilizar o Scrum em sua empresa, da uma olhadinha!

A metodologia foi difundida para o público geral por meio de um livro de autoria de Jeff Sutherland: Scrum: A Arte de Fazer o Dobro do Trabalho na Metade do Tempo.


Capítulo 3

Como utilizar o Scrum em sua empresa

“OK, João, já entendi os benefícios do Scrum, mas como eu começo a usar essa metodologia?”

A primeira dica que nós damos é: não comece tentando aplicar a metodologia na sua empresa inteira de uma vez.

“Mas se a metodologia é tão boa, por que não aplico na empresa inteira de uma vez?”.

Eu sei que pode parecer controverso, mas a resposta para essa pergunta é a experiência.

Quando se inicia o processo de transição de um modelo tradicional de gerenciamento para o Scrum, tanto os times quanto os gestores não costumam ter experiência em trabalhar com este novo modelo, e nós não desejamos perder a produtividade até que se adequem, não é?

Então a nossa dica, como experientes nisso, é: comece implementando alguns princípios, pouco a pouco, em uma equipe específica que esteja disposta a mudar o modelo de trabalho atual para um mais efetivo e, depois de ver os resultados, siga implementando outros princípios até que aquela equipe e logo mais a empresa inteira esteja realizando as boas práticas da metodologia Scrum.

Então o primeiro passo para utilizar o Scrum em sua empresa é estudar, aprender com os erros e acertos dos outros e implantar, de maneira controlada e natural, as práticas desta metodologia.

Capítulo 4

Funções necessárias para o funcionamento do Scrum

Product Owner (PO)

A função do PO é a de ser a voz do cliente dentro do time. Ele é quem garante que os esforços da equipe agreguem valor ao negócio. Ele é o responsável por criar as tarefas a serem realizadas, sempre centrado nas necessidades do cliente, descrever os critérios de aceitação delas (para o time saber quando a tarefa está efetivamente pronta) e priorizá-las por quais gerarão mais valor aos clientes além de ser o único que tem o poder de dizer se a tarefa gera o valor necessário ou não. Ele é dono do Produto, não do processo.

Scrum Master

Outra função de liderança no Scrum é necessária para direcionar o time de uma forma que realizem o trabalho com as melhores práticas do Scrum. O Scrum Master é um líder-servidor que tem como função de auxiliar o time para que estes sigam as melhores práticas do Scrum, tornando o trabalho mais relevante e ágil!

 

“Calma, mas o que é um líder-servidor?”. Um líder servidor é aquele que permite que haja no time um sistema de cooperação mútua e contínua, no qual o líder e a equipe tem o mesmo poder de fala e influência nas decisões, possibilitando a adoção de práticas e políticas mais eficientes.

 

“E como o Scrum Master deve agir para atingir isso?”. Valorizando as ideias e opiniões do time ao incentivar a inovação e a criatividade, fortalecendo o respeito pelas diferenças e construindo relações de confiança. Possuindo um poder de persuasão elevado, através do poder de comunicação e do questionamento. Reconhecendo as necessidades, de forma de manter a gestão alinhada ao que realmente importa. Identificando e preparando outros líderes servidores dentro da própria equipe, de modo a torná-la mais independente e pensando no indivíduo de forma completa, não apenas profissional, percebendo e agindo diante de problemas e necessidades pessoais.

Time Scrum

O Time Scrum é responsável pela entrega do produto. O time é tipicamente composto de 3 a 9 pessoas com habilidades multifuncionais, de modo que consigam executar as tarefas necessárias sem o apoio de nenhum membro de outro time, e que fazem o trabalho operacional (analisar, projetar, desenvolver, testar técnicas de comunicação, documentos, etc.). Nós recomendamos que a equipe tenha liberdade de se autogerir (quem sabe melhor as necessidades do time do que o próprio time?), mas que muitas vezes trabalhem com alguma forma de projeto ou gestão de equipe.


Capítulo 5

Sobre os ciclos do Scrum

Como dito anteriormente, para que se possa aplicar os conhecimentos obtidos em cada ciclo, devemos ter ciclos de feedback menores do que os métodos tradicionais (que chegam a durar alguns anos, muitas vezes!). 

O motivo de se diminuir os ciclos se assemelha à ocorrência dos juros compostos no mercado financeiro: a cada ciclo, aprendemos mais sobre o que devemos ou não fazer, fazendo com que o próximo ciclo seja ainda mais produtivo e assim segue, em uma curva de aprendizado exponencial.

Para que possamos realizar estes ciclos menores e realmente aprender com eles, usamos ciclos, chamados de Sprints, de 1 a 4 semanas (times mais maduros e com menos ocorrência de tarefas não planejadas costumam ter ciclos mais próximos do limite superior, enquanto times menos maduros e/ou com muitas ocorrências de tarefas não planejadas costumam ter ciclos menores) e durante esses ciclos, temos alguns eventos utilizados para consolidar o aprendizado e para termos certeza de que estamos indo no caminho de realizar nossos principais objetivos.


Capítulo 6

Eventos de um Sprint

Para utilizarmos a metodologia Scrum com a maior eficácia, realizamos alguns eventos durante os ciclos para aprendermos com o que foi feito no passado e nos aprimorarmos para os ciclos futuros.

Os eventos normalmente utilizados em um ciclo de Scrum são:

  • Grooming de Backlog;
  • Planejamento de Sprint (Sprint Planning);
  • Sprint;
  • Daily Scrum (ou Daily Meetup);
  • Revisão de Sprint;
  • Retrospectiva do Sprint.

E pode ser realizada uma comparação com o Ciclo PDCA (Ciclo de Deming) para entender melhor o objetivo de cada evento dentro de um ciclo de melhoria contínua.

O que é o Ciclo PDCA?

O Ciclo PDCA, também chamado de Ciclo de Deming, em homenagem ao seu idealizador, W. Edwards Deming é uma representação de um ciclo de melhoria contínua, consistindo de 4 etapas: Plan, Do, Check, Act (Planejar, Realizar, Checar, Agir). Neste ciclo, o primeiro passo é planejar o que será feito para realizar uma melhoria em algum problema atual (Plan), após isto, deve-se realizar o que foi planejado (Do), e ao se terminar a parte prática, checar o que deu certo, o que deu errado e como é possível melhorar para que possamos realizar um próximo ciclo ainda mais efetivo (Check) e gerar um plano de ação para concretizar as melhorias (Act). O objetivo ao utilizar este ciclo é: erre rápido, mas conserte seus erros mais rápido ainda.

A seguir vamos mostrar onde cada evento do Scrum se encaixa em cada etapa do Ciclo PDCA. 

Grooming de Backlog (Plan)

Durante essa reunião, que conta obrigatoriamente com o PO e o Scrum Master, podendo incluir qualquer membro do Time Scrum que se interesse (não obrigatoriamente) é quando enriquecemos o Backlog previamente realizado.

Nessa reunião, busca-se dividir as tarefas que sejam muito grandes para que possam ser realizadas na duração de no máximo um Sprint, além de receber e ponderar sobre as ideias que qualquer membro tenha tido com o objetivo de atingir os resultados da empresa, para saber se elas são realmente relevantes.

Sprint Planning (Plan)

Com o Backlog montado, incrementado durante a reunião de Grooming e priorizado pelo PO, vamos para a primeira reunião que vai precisar de todos os membros presentes, o Sprint Planning.

Nessa reunião conduzida pelo Scrum Master, a priorização realizada pelo PO poderá ser questionada caso o time veja valor em outras tarefas (lembrando que como o responsável pelo Backlog é o PO, ele tem a palavra final sobre a priorização), poderá advogar com o objetivo de fazer o PO mudar a priorização realizada anteriormente.

Após discutida a priorização, o time irá passar a realizar a estimativa de quanto esforço será necessário para completar cada tarefa do Backlog. Neste ponto surge uma das principais diferenças entre os métodos tradicionais de gerenciamento e das metodologias ágeis, como o Scrum.

Nas metodologias tradicionais, os gerentes de projeto se esforçam para tentar definir a quantidade de tempo que será necessária para que cada tarefa seja realizada. Mas como diz o já citado anteriormente Jeff Sutherland, quando estimamos uma tarefa utilizando o método de horas, normalmente erramos em um grau de 4 vezes, para menos ou para mais. Por exemplo, se estimamos que uma tarefa levará 2 horas para ficar pronta, o mais comum é que o tempo seja entre 30 minutos e 8 horas de duração, visto que não somos acostumados a realizar tais estimativas naturalmente.

Ao estimar a duração de uma tarefa, usamos o método de Story Points, no qual cada membro do time deverá ter acesso a um baralho de cartas com os números da sequência de Fibonacci (1, 2, 3, 5, 8, 13), escolher uma carta que, em seu entendimento, considera equivalente à quantidade de esforço necessária para a conclusão daquela tarefa e após todos terem escolhido, virar a carta para cima.

Caso haja uma diferença de mais de duas cartas, por exemplo, um membro votou que a tarefa tem tamanho 2, e outro votou que tem um tamanho 8 (3 cartas de diferença), cada um deve explicar a motivação que o levou a escolher a carta (um pode achar mais complicado pois não se lembrou de uma ferramenta que ajuda, ou o outro pode achar a tarefa menos complexa do que realmente é por inexperiência, etc), e assim se realiza uma nova rodada de votação com o objetivo de o time estar mais alinhado e chegar em números mais próximos.

Após a rodada ser efetuada, faz-se uma média simples de todos os números de Story Points que foram escolhidos e passa-se para a próxima tarefa a ser estimada.

Exemplo: Matheus achou que a tarefa tinha uma complexidade 3, Ana votou por 5 e João votou por 3. Soma-se os resultados (3+5+3 = 11) e se divide pelo número de participantes da reunião (11/3 = 3,67).

Ao final da reunião, o time decidirá a quantidade de tarefas que serão realizadas naquele Sprint, firmando um acordo com o Scrum Master. Para se definir a quantidade de tarefas a serem realizadas, o time pode (e deve) usar conhecimentos prévios sobre quantos Story Points foram realizados nos últimos Sprints.

Sprint (Do)

O Sprint é um evento time-boxed, o que significa que ele tem um tempo máximo definido, que não pode ser mudado sob nenhuma circunstância. Como dito anteriormente, a duração de um Sprint normalmente varia de 1 a 4 semanas.

Nessa etapa, o Time Scrum irá realizar o trabalho operacional de realizar e entregar as tarefas prontas para que as melhorias realizadas durante o Sprint possam ser implementadas.

Daily Scrum (Check, Act)

O Daily Scrum é um evento de ocorrência diária, sendo também um evento time-boxed de no máximo 15 minutos.

Nessa reunião, o time deverá se comunicar ao responder 3 perguntas:

  • O que você fez ONTEM para ajudar a equipe para concluir o objetivo do Sprint?
  • O que você vai fazer HOJE para ajudar a equipe para concluir o objetivo do Sprint?
  • Existe algum IMPEDIMENTO para a equipe concluir o objetivo do Sprint?

O objetivo dessa reunião é alinhar o time para que cada um saiba o que os outros estão fazendo e saber em que ponto estão no Sprint.

Com essas informações, é possível ter noção de algumas coisas, como: “As tarefas serão concluídas a tempo?” e “Existe alguma oportunidade para ajudar os membros da equipe a superar seus obstáculos?

Revisão de Sprint (Check)

A Revisão do Sprint é a primeira reunião a ser realizada após o final do Sprint e serve exatamente para descobrir possíveis pontos para aperfeiçoar o processo, para que a cada Sprint tenhamos uma melhoria de produtividade em nossas equipes.

A reunião de Revisão de Sprint tem como objetivos validar o trabalho realizado e dar feedbacks sobre a qualidade das entregas, demonstrando na prática o que foi realizado durante a duração do Sprint.

Lembrando que aqui só é apresentado o que foi 100% realizado (cumprindo com as definições de “pronto” pré-estabelecidas), pois nesta metodologia, costumamos dizer que metade do trabalho feito é pior do que não ter feito nada, visto que foi despendido tempo na realização daquela tarefa, mas ela não gerou nenhum valor final, então o que ocorreu foi um desperdício.

É nesta reunião que o seu PO (Product Owner) vai dizer se as tarefas na coluna FEITO estão de acordo com os padrões de qualidade necessários para gerar valor ao cliente ou público alvo, tendo ele o poder de vetar quaisquer alterações realizadas pelo time.

Retrospectiva do Sprint (Act)

Na última reunião do ciclo Scrum, entramos com a mentalidade de que nós podemos não ter o poder de mudar os processos realizados no passado, mas podemos mudá-los para termos um melhor resultado futuro.

Por querermos aumentar a produtividade do time, precisamos de feedbacks sobre o que deu certo e contribuiu para a agilidade do time durante o Sprint, para que possamos replicar estes comportamentos nos próximos Sprints, assim como o que deu errado e prejudicou a agilidade do time, para que possamos fazer um plano de ação para não cometermos os mesmos erros.

É importante se lembrar que nessa reunião nós não queremos achar culpados ou campeões, mas sim processos benéficos e processos maléficos. É aqui que conseguimos reajustar o rumo de um time para que as entregas futuras sejam sempre maiores do que as entregas passadas.

O objetivo é, ao final dessa reunião, termos um plano de ação montado para realizar as possíveis melhorias reveladas nela, além de boas práticas que o time deve continuar seguindo para que a qualidade e agilidade não caia.

Para ajudar a guiar essa reunião, pode-se utilizar um modelo de 3 perguntas para saber onde é possível melhorar e o que devemos continuar realizando, são elas:

  • O que aconteceu durante esse Sprint que prejudicou a agilidade do time?
  • O que aconteceu durante esse Sprint que auxiliou na agilidade do time?
  • O que fez vocês felizes durante esse Sprint?

 

Criação de Planos de ação (Act)

Ao final de cada ciclo de Sprint, com os aprendizados sobre o que deu certo e o que deu errado, nós devemos montar um plano de ação para que possamos consertar o que atrapalhou o time a chegar nas metas definidas e para que possamos continuar a fazer o que levou o time aos resultados mais satisfatórios.

Recomendamos que se criem tarefas de melhoria com a maior prioridade possível no seu Backlog. Ao priorizar essas tarefas, a primeira coisa que o time fará no próximo ciclo será voltado para a melhoria do mesmo, acelerando o crescimento e aumentando a força dos ciclos de melhoria contínua.


Capítulo 7

Artefatos utilizados no Scrum

Para botar o Scrum em prática, nós necessitamos de alguns itens, que chamaremos de artefatos para o melhor entendimento dos nossos leitores.

Backlog

Este artefato é o que vai transformar os pensamentos sobre o que pode gerar valor aos clientes ou leads da sua empresa em tarefas ou histórias de usuário.

A função de preencher o Backlog com tarefas e histórias de usuário é principalmente realizada pelo PO, criando tarefas e definindo objetivamente a partir de qual momento elas poderão ser consideradas como “prontas”. Mas isso não impede os membros do Time Scrum de criar quaisquer tarefas imaginadas por eles que possam gerar valor aos clientes ou leads, nós inclusive encorajamos essa prática no Roads, onde é comum utilizar uma reunião de Brainstorming com os membros para que se defina, e documente, tudo que pode gerar valor de alguma maneira a quem queremos atingir.

Após termos uma quantidade suficiente de tarefas ou histórias de usuário, é necessário que se priorize essas tarefas por valor gerado aos interessados. Para termos um Backlog priorizado, deve-se pensar: “O que vai gerar mais valor/impacto para quem estou tentando atingir?”. Assim como no ponto anterior, esta função vai é principalmente do PO, mas caso algum membro do Time Scrum tenha o pensamento diferente do PO, esse membro pode (e deve) trazer o ponto dele para a discussão, de modo a contribuir para uma priorização mais correta e focada no público-alvo que se pretende atingir.

Scrum Board

O Scrum Board é um quadro em estilo Kanban com 4 áreas, e é utilizado para guiar o time e acompanhar o estado que cada tarefa se encontra.

O quadro é dividido em 4 colunas, sendo elas:

  • A Fazer
    • Todas as tarefas que foram escolhidas para serem realizadas na duração do Sprint. Essa coluna também pode ser chamada de Backlog do Sprint.
  • Fazendo
    • Aqui se encontram as tarefas que cada membro do Time Scrum está realizando no momento. Vale lembrar que pesquisas recentes em Stanford demonstraram que realizar o chamado multitasking resulta em uma perda de produtividade, ao contrário do que se imaginava antigamente. Com esse conhecimento, é recomendado que cada membro realize somente uma tarefa por vez e só comece a próxima assim que finalizar a atual.
  • Checar
    • Assim que um membro termina uma tarefa, ela é passada para essa coluna para passar por um processo de checagem da mesma. O PO irá avaliar se a tarefa cumpre os requisitos pré-estabelecidos para que a tarefa seja considerada pronta e se a qualidade está dentro do esperado. Caso a tarefa seja realmente considerada feita, ela passa para a próxima coluna, mas caso ela não seja considerada feita, o PO explicará os motivos que o levaram a considerar a tarefa como não feita e ela voltará para a coluna anterior, para ser corrigida.
  • Feito
    • Na última coluna se encontram as tarefas finalizadas e checadas pelo PO. Essas tarefas estão prontas para serem lançadas ao mercado (ou já foram lançadas, dependendo do tipo de tarefa).

A imagem ao lado demonstra um exemplo de Scrum Board na prática, com suas colunas e tarefas. Cada tarefa é representada por um cartão.

Gráfico de Burndown

Como nós fazemos para saber o estado de um Sprint, se ele está adiantado, atrasado ou no prazo, mesmo antes de terminar?

Para ter acesso à essas informações, nós utilizamos um gráfico simples, chamado de Gráfico de Burndown. Para fazer esse gráfico, utilizamos no eixo Y a quantidade de Story Points e no eixo X os dias que vão passando.

A partir daí, traçamos uma linha reta, dividindo a quantidade de pontos total planejada para aquele Sprint pelo total de dias. Essa é a linha que irá nos guiar para sabermos se o estado do Sprint.

A outra linha que analisaremos é a linha que mostrará a quantidade de Story Points remanescentes em cada dia pelo tempo. Caso essa linha esteja acima da linha base, significa que o time não completou tarefas na taxa esperada no planejamento do Sprint, logo, está atrasado. Caso essa linha se encontre abaixo da linha base, significa que o time cumpriu mais tarefas do que foi planejado inicialmente, o que nos mostra que o time está adiantado naquele Sprint. O último caso é quando as linhas coincidem, e isso nos mostra que o time está dentro das expectativas planejadas


Capítulo 8

Vantagens de se utilizar o Scrum

Resumindo alguns motivos que levarão sua empresa a outro nível ao utilizar a metodologia Scrum, temos:

  • Os membros do Time Scrum se sentem muito mais motivados devido ao seu interesse de entregar o Sprint no prazo;
  • Com a eliminação do desperdício de tempo e recursos, é possível alcançar resultados mais expressivos, aumentando a produtividade da equipe.
  • Dentro da organização o projeto pode ser observado por todos. Enquanto em outras metodologias esta possibilidade não existia;
  • Como as atividades são feitas de forma fragmentada e subdivididas em pequenos períodos de trabalho, é possível detectar problemas logo no início e, assim, fazer as devidas correções rapidamente. Isso reduz os riscos do projeto e evita o retrabalho;
  • Com todas as etapas do projeto definidas e divididas em sprints, é mais fácil visualizar o progresso do projeto de maneira clara e transparente.

Capítulo 9

Alguns Cases de sucesso da metodologia Scrum

Saiba como grandes empresas transformaram suas formas de trabalhar com o Scrum:

Rede Globo

A Rede Globo aplica a metodologia Scrum em seu site, Globo.com, desde meados de 2007. Durante o processo de implementação muitos foram os problemas que surgiram e que precisaram ser resolvidos

Uma das dificuldades foi a falta de definição de prioridades e o período de adaptação da metodologia às necessidades da empresa.

Porém, a equipe responsável também teve muito sucesso com a iniciativa, não tendo dúvidas de que processos ágeis, como a metodologia Scrum, são primordiais para a otimização do desenvolvimento de softwares.

Yahoo!

Reduzir o tempo gasto no desenvolvimento de um software enquanto gerencia o tamanho da equipe: esses são alguns dos motivos para o Yahoo! ter apostado na metodologia Scrum.

Nesse gigante da Internet, eles planejam, criam e testam diferentes produtos e serviços durante um determinado período de dias, de modo a aprimorar e impulsionar cada vez mais a tecnologia utilizada por eles e oferecida ao público.

Google

No Google, vários setores apostam em métodos ágeis de desenvolvimentos de softwares, como o Scrum, criando e testando serviços e produtos. Cada equipe escolhe a tecnologia o método que melhor pode ser aplicado para a resolução de problemas.

Um dos projetos em que se utilizou a metodologia Scrum foi no desenvolvimento do Adwords e podemos ver os resultados: de 2015 até o final de 2019, as receitas do Google Adwords cresceram de US$67 bilhões para mais de US$134 bilhões no ano, um crescimento de 100% em 4 anos!