O que é Scrum?

Criado em 1995 por Ken Schwaber e Jeff Sutherland, o Scrum é um framework que busca auxiliar times a construírem e evoluírem produtos em ambientes complexos. O Scrum é classificado como sendo parte de um movimento maior, chamado de Ágil, que exploramos em outro texto. O Scrum é incrivelmente popular: 56% dos respondentes da maior pesquisa de adoção de métodos ágeis afirmam utilizá-lo. Mas essa “massificação” também traz diversos mal entendidos e desafios que exploraremos neste guia. Este é o primeiro post de uma sequência.

O que é Scrum?

Como dissemos no início, o Scrum é um “framework”. Isso significa que ele não diz exatamente como você deve gerenciar o desenvolvimento de produtos, mas apenas estabelece um “meta-processo” para fazê-lo.

No Guia do Scrum, está escrito que ele foi utilizado com sucesso para desenvolver software, hardware, software embarcado, redes de função de interação, veículos autônomos, escolas, projetos governamentais, marketing, etc. Quase tudo que usamos em nosso dia a dia.

O Scrum define alguns papéis, artefatos e eventos (reuniões) que são utilizadas em um projeto. Neste guia, usaremos exemplos de desenvolvimento de software, pois acreditamos que esses podem ser facilmente compreendidos por boa parte dos nossos leitores.

Sprints

No Scrum, um projeto é dividido em “Sprints”, que são ciclos de duração fixa (de 1 a 4 semanas). Ao final de cada Sprint, um incremento (parte que pode ser usada) do produto é entregue. Diferentemente da abordagem tradicional de desenvolvimento de software, o Scrum busca realizar entregas de valor curtas e contínuas ao longo do ciclo de vida de um produto.

Por exemplo: imagine que você faz parte de um time Scrum responsável por desenvolver um produto de assinatura. O objetivo desse produto é usuários poderem receber receitas e alimentos já particionados para cozinharem com as suas famílias.

Na abordagem tradicional, teríamos primeiro uma fase de elicitação de requisitos, com entrevistas e pesquisas para entender o público-alvo e listar todas as funcionalidades desejadas. Nos 3 meses seguintes os desenvolvedores ficariam projetando o software, definindo arquitetura de software e criando o banco de dados. Mais 4 meses seriam utilizados para implementar todas as features desse produto. E por fim, os 2 meses finais seriam compostos por testes finais de qualidade com o usuário.

Parece um plano perfeito, certo? O problema é que nesse modo de pensar investe-se muito dinheiro e energia, para somente no final do longo período obter algum feedback útil dos usuários. Por outro lado, no Scrum o time realizaria todas essas atividades dentro de uma Sprint, entregando uma parte simples (porém funcional) desse produto ao cliente final a cada ciclo.

A analogia do bolo

Analogia do BoloPara explicar a diferença do tradicional para o Scrum, podemos utilizar a analogia do bolo. Em um projeto tradicional, temos um conjunto de fases onde cria-se uma camada do bolo de cada vez. Cada camada corresponde a uma etapa funcional do projeto, como por exemplo, criar o banco de dados, desenvolver as APIs ou desenhar a interface do usuário. O problema é que o usuário final não utiliza uma dessas camadas de forma independente. Não adianta entregar o banco de dados para ele no final da fase. Ele só pode comer o bolo inteiro. Só o merengue não significa nada para o cliente.

No Scrum, ao invés de entregarmos uma camada por vez, buscamos entregar fatias. Uma fatia bem fina do bolo, mas que tenha todas as camadas. Assim o usuário pode experimentar e dizer: humm, gostaria que massa fosse mais doce. Aí na próxima Sprint você ajusta a quantidade de açúcar. Agora, se ele pudesse comer o bolo só depois que ele estivesse completamente pronto, o custo de mudar seria muito alto.

Papéis

O guia do Scrum define 3 papéis necessários para manter o framework em funcionamento. O Product Owner, o Time de Desenvolvimento e o Scrum Master.

Product Owner (PO)

O Product Owner é responsável por maximizar o retorno sobre o investimento do produto. Ele deve estar sempre atento às demandas de negócio e em constante contato com as partes interessadas: clientes, acionistas, diretores, usuários, etc.

O PO detém a visão do produto, ou seja, ele visualiza e busca levar o produto sendo construído para um determinado caminho. Isso é geralmente feito através da escrita de Itens de Backlog, que correspondem a funcionalidades, correções de defeitos e novos recursos que serão disponibilizados no produto.

O Product Owner prioriza o Backlog do Produto, que é uma lista em constante crescimento e evolução com as coisas que devem ser implementadas no produto. O PO deve ser apenas uma pessoa, e não um grupo. Além disso, ele precisa ter a autoridade exclusiva de mexer no Backlog. Diretores, gerentes e até sócios devem negociar com esse papel se quiserem incluir novos itens ou alterar os existentes.

Time de Desenvolvimento

O Time de Desenvolvimento é um grupo pequeno (de 3 a 9 integrantes, segundo o Guia do Scrum) que contém todas as competências necessárias para criar e manter o produto sendo trabalhado (leia sobre equipes multidisciplinares). Além disso, o Time de Desenvolvimento é auto-organizado: não existe um chefe responsável por gerenciar o trabalho (o Scrum Master também NÃO faz isso!).

No exemplo do nosso aplicativo de assinatura de receitas, provavelmente precisaríamos de pessoas com capacidade de desenvolver software, criar protótipos de interface, testar software, fazer pesquisas com usuário, etc. Todas essas competências devem estar presentes no Time de Desenvolvimento, em uma ou mais pessoas. Ou seja, provavelmente precisaríamos de um desenvolvedor, um designer e um testador. Obviamente, o time ser multidisciplinar não significa que todos devem saber tudo.

Scrum Master (SM)

O Scrum Master suporta os demais (Time de Desenvolvimento e Product Owner) no entendimento e aplicação do Scrum. Ele facilita as cerimônias e ajuda o grupo como um todo a se auto-organizar. Ninguém nasce sabendo usar o Scrum, muito menos trabalhar de forma autogerida. É por isso que esse papel é tão importante, especialmente durante as etapas iniciais de adoção do framework.

O Scrum Master não é um chefe. Ele não “cobra as entregas” dos membros do time ou é responsável pelo sucesso do produto. O Scrum Master atua mais como um coach, que oferece o espelho nos momentos adequados e encoraja os membros do time a tratarem as suas próprias tensões entre eles e a dependerem menos do SM ou do PO.

O SM também atua expandindo o Scrum dentro da organização em que atua, ensinando outros times e departamentos a trabalharem com o framework. É comum também o SM auxiliar o Product Owner a melhor expressar os itens do Backlog do Produto (normalmente na forma de histórias de usuário).

Até agora definimos o conceito de Sprint e os papéis do Scrum. No próximo texto, falaremos sobre os artefatos e eventos do framework, além de questões polêmicas, como escalabilidade, quando usá-lo e quando não. Fique ligado no nosso blog e assine a nossa newsletter para receber atualizações de novos conteúdos. 😉

Por |2018-07-12T15:40:12+00:00julho 12, 2018|Ágil, Gestão|0 Comentários

Sobre o Autor:

Davi é um transformador de organizações e desenvolvedor de software social. Não satisfeito com as mudanças realizadas em times de desenvolvimento de software como Agile Coach, resolveu abordar um problema organizacional mais profundo: a forma como lidamos com autoridade dentro de empresas. É amante dos temas desenvolvimento organizacional, produtividade, futuro do trabalho e organizações evolutivas. Davi também é pioneiro na prática de Holacracia no Brasil.

Deixe um comentário