Anda di halaman 1dari 5

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 ágeisafirmam
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

Para 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 Davi Gabriel da Silva|julho 12, 2018|Ágil, Gestão|0 Comentários


COMPARTILHE ESTA PÁGINA!
FacebookTwitterLinkedInRedditGoogle+PinterestEmail
SOBRE O AUTOR: DAVI GABRIEL DA SILVA

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.