DESENVOLVIMENTO

DE SOFTWARE COM
METODOLOGIAS ÁGEIS

Wheslley Rimar Bezerra

Scrum
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:

 Descrever a origem, história e os fundamentos do Scrum.

 Explicar a diferença entre o desenvolvimento ágil de sistemas com
Scrum e o desenvolvimento tradicional de sistemas.
 Demonstrar a implementação do framework Scrum.

Introdução
Vivemos em uma época em que estamos cada vez mais conectados com
o mundo da tecnologia e as ferramentas que ele oferece. Esse processo
de conexão se tornou natural na vida das pessoas ao longo dos anos,
visto que a tecnologia foi se popularizando e se consolidando cada vez
mais em nossa sociedade. As demandas de desenvolvimento de software
também acompanham essa evolução, e os métodos, outrora tradicionais,
gradativamente são substituídos por ferramentas e metodologias que
dão agilidade ao processo.
Assim sendo, neste capítulo, você vai compreender o que é o Scrum
e entender a sua origem, além de saber quais são as principais diferenças
entre o Scrum e os métodos tradicionais de desenvolvimento de software.
Por fim, você conhecerá como se dá o processo de implementação do
Scrum no dia a dia de uma equipe de desenvolvimento de software.

1 Como tudo começou?

O Scrum foi idealizado por Jeff Sutherland, juntamente com Ken Schwaber,
no ano de 1993 (SUTHERLAND, 2016). A ideia que fundamentou o desen-
volvimento desse framework foi que ambos perceberam uma necessidade
cada vez mais latente: acelerar o desenvolvimento de software na indústria
da tecnologia. Àquela época, os projetos de software contavam com muitos
programadores envolvidos, contudo, o produto levava muito tempo para ser
2 Scrum

entregue ao cliente, pois eram utilizados modelos tradicionais de desenvolvi-

mento de sistemas, como o modelo em cascata, por exemplo.
Além disso, o desenvolvimento de ferramentas era muito caro e, em diversas
situações, o sistema construído não justificava os custos. Em meio a esses
problemas surgiu o Scrum, com a proposta de entregas contínuas e parciais
divididas em ciclos de desenvolvimento chamados de sprints, com foco em alta
performance e alta produtividade com efetivos ganhos em otimização de tempo.
Inicialmente, o Scrum foi pensado apenas para o gerenciamento de pro-
jetos voltados ao desenvolvimento de software, mas como a sua estrutura é
extremamente flexível, ele permite que seus conceitos sejam adotados por
outras áreas.

Apesar de otimizar o tempo, é preciso ter em mente que a qualidade do projeto deve ser
garantida pela equipe que trabalha com a metodologia Scrum. Assim, escopo, tempo,
custo e qualidade devem ser observados pelo time Scrum com muita responsabilidade.

Para facilitar o entendimento, podemos dizer que o Scrum é um framework

e, ao mesmo tempo, um conceito de gerenciamento de projetos que abrange
desde a parte de organização inicial do projeto até a entrega final do produto.
Seu modelo se baseia em entregas pequenas de um todo, ou seja, ao invés de
entregar o software completo somente no final do projeto, entregas menores
são feitas ao longo de todo o percurso de desenvolvimento, agregando valor
ao cliente em todos os momentos, pois ele já pode utilizar partes do produto
desde o momento da finalização das primeiras sprints. Essa ferramenta não
segue um fluxo sequencial (linear), mas processos cíclicos com equipes au-
togerenciáveis. O Scrum também não é utilizado da mesma forma em todas
as empresas. Devido à sua característica flexível, pode ser customizado para
a realidade de cada empresa que o implementa.
O Scrum é empírico. Isto significa que ele atua com base na observância dos
fatos e na experiência mediante ao que é conhecido. Além disso, o Scrum tem
três características que são percebidas logo de início por quem está tentando
aprendê-lo: leve, simples de entender e difícil de dominar (SCHWABER;
SUTHERLAND, 2017).
 Scrum 3

Entretanto, essas características não são motivos para pânico. Elas devem
ser motivadoras, pois ao dominar toda a estrutura que rodeia o Scrum, você
terá a oportunidade de vivenciar os seus benefícios e colher resultados positivos
com a sua implementação.
Mas em que se baseia o Scrum? São três os pilares: transparência, inspeção
e adaptação.

Transparência — Este primeiro pilar indica que tudo aquilo que for signi-
ficativo para o processo deve estar visível e transparente a todos, facilitando
uma comunicação mais assertiva entre os membros da equipe, ou seja, os fatos
são apresentados da forma como estão. Dessa forma, é possível padronizar
as definições sobre as etapas do trabalho, permitindo que haja senso comum
entre o grupo. Sendo assim, há uma relação de confiança, que é estabelecida
com o propósito de que todas as informações que são importantes para o bom
andamento do projeto sejam compartilhadas abertamente entre os envolvidos.

Inspeção — Este pilar indica que deve haver inspeção sobre os trabalhos que
estão sendo realizados, de modo a medir se a equipe está conseguindo atingir os
objetivos. A inspeção tem que ser feita com cautela, de forma a não prejudicar
a equipe, ou seja, em uma frequência que não gere atrasos nas entregas e que
não coloque a equipe em conflito. Ela deve ser conduzida pela equipe Scrum
como um todo. A ideia é verificar como estão o produto, os processos de
desenvolvimento e até mesmo as pessoas envolvidas na execução das tarefas.

Adaptação — Este pilar, por sua vez, indica que podem ocorrer adaptações
ao longo do projeto. Geralmente, elas ocorrem quando, na inspeção, são
identificadas falhas no processo. Estas falhas, também chamadas de desvios,
podem e devem ser ajustadas, a fim de não impactar na entrega final.
O Scrum pode ser direcionado para uso em diferentes objetivos. Segundo
Schwaber e Sutherland (2017), desde a sua concepção, no início dos anos 1990,
o Scrum foi direcionado para diferentes propósitos, tais como:

 pesquisa de mercado, tecnologias e funcionalidades de produtos;

 desenvolvimento de produtos, bem como suas melhorias;
 sustentação e renovação de produtos.

Pensando em produtos de tecnologia, o Scrum geralmente é usado na

construção e na implementação de software, mas pode ser utilizado também
para o desenvolvimento de hardware ou a manutenção de recursos de cloud
4 Scrum

computing. Em áreas não relacionadas à tecnologia, o Scrum assume um

importante papel de gerenciamento de operações. Mas, além do meio empre-
sarial, podemos utilizar o Scrum para situações do cotidiano, como organizar
uma festa ou os estudos.

2 Diferenças entre Scrum e métodos

tradicionais
O desenvolvimento de software não é algo novo. São muitas as técnicas e as
ferramentas de gestão de projetos criadas para facilitar a vida dos programa-
dores, mas nem sempre foi assim. Os modelos tradicionais que precedem os
modelos ágeis tinham estruturas bem complexas e rígidas. O modelo cascata
(do inglês, waterfall model), por exemplo, exige um planejamento muito bem
definido, no qual o escopo do projeto, o custo e o cronograma devem ser fixos.
Segundo Pressman e Maxim (2016), o modelo em cascata se estrutura
em fases bem definidas, como comunicação, planejamento, modelagem,
construção e entrega (Figura 1).

Comunicação
Início do projeto Planejamento
Estimativas Modelagem
Levantamento de requisitos Construção
Cronograma Análise
Código Entrega
Acompanhamento Projeto
Teste Entrega
Suporte
Feedback

Figura 1. Fases do modelo em cascata (waterfall model).

Fonte: Adaptada de Pressman e Maxim (2016).

Vamos detalhar as fases a seguir.

Comunicação — É o momento inicial do projeto no qual há o levantamento

de requisitos junto ao cliente. Aqui, apesar de ser a fase inicial, deve ser bem
criteriosa, pois é a partir dela que será elaborado o planejamento do projeto.

Planejamento — Uma vez com os requisitos bem definidos, inicia-se a etapa

de planejamento. Nela, as estimativas de esforço dos desenvolvedores e o
cronograma são feitos e é organizado como será o acompanhamento do projeto.
 Scrum 5

Modelagem — Nesta fase é feita toda a análise do projeto e são definidas

como serão construídas as funcionalidades do software.

Construção — Esta é a fase de codificação, ou seja, a construção do software

em si. Nela, também são realizados todos os testes da aplicação desenvolvida.

Entrega — Esta é a fase final. Após a finalização do desenvolvimento do

software, é feita a entrega ao cliente. Dependendo do contrato, há também o
suporte ao cliente, no qual podem ser corrigidos os bugs. Neste momento, é
aberto um canal para que o cliente possa dar seus feedbacks em relação ao
software.
Veja, a seguir, algumas das diferenças existentes entre o modelo de desen-
volvimento em cascata e o modelo ágil ao qual o Scrum faz parte (Quadro 1).

Quadro 1. Diferenças entre modelo cascata e modelo ágil (Scrum)

Modelo cascata Modelo ágil (Scrum)

Desenvolvimento dividido em Desenvolvimento baseado

fases (modelo sequencial) em ciclos (sprints)

Estrutura rígida (não aceita Estrutura flexível (pode haver

modificações no projeto) alterações no escopo do projeto)

Testes ocorrem somente após Testes ocorrem em diversos

a construção do software momentos enquanto o software
está em desenvolvimento

Não há interação com o O cliente participa de todo o

cliente durante o processo processo de desenvolvimento
de desenvolvimento

Tanto o modelo em cascata quanto o Scrum têm vantagens e desvantagens

em suas estruturas. Afinal, nenhuma das duas abordagens se propõe a ser a
melhor solução para o desenvolvimento de software. Todavia, o Scrum tem
ganhado a preferência entre as empresas, pois é um modelo que, ligado a
abordagens como o design thinking, torna o processo muito mais humanizado.
6 Scrum

Design thinking é uma abordagem que visa ao desenho de soluções em projetos, com
a proposta de ouvir e se colocar no lugar das pessoas envolvidas, transportando-as
ao centro do processo. O design thinking se utiliza do que há de melhor nas pessoas,
tais como: ser intuitivo, facilidade de reconhecimento de padrões, capacidade de
promover ideias que geram significado emocional, ou seja, que vão além do que é
funcional, entre outros (BROWN, 2018).

Além disso, é possível perceber que independentemente do tamanho do

projeto, utilizar a abordagem ágil como método de desenvolvimento pode
ser extremamente assertivo, conforme podemos observar no comparativo do
Quadro 2 a seguir, no qual são verificados os percentuais de sucesso entre o
modelo ágil e o modelo em cascata.

Quadro 2. Percentual de sucesso — modelo ágil versus modelo cascata

Bem- Posto em
Tamanho Método -sucedido risco Cancelado

Projeto Ágil 39% 52% 9%

de todo
Cascata 11% 60% 29%
tamanho

Projeto Ágil 18% 59% 23%

grande
Cascata 3% 55% 42%

Projeto Ágil 27% 62% 11%

médio
Cascata 7% 68% 25%

Projeto Ágil 58% 38% 4%

pequeno
Cascata 44% 45% 11%

Fonte: Adaptado de Hastie e Wojewoda (2015).

O Scrum, entretanto, enfrenta uma série de desafios em sua implementação

nas empresas. Esses desafios podem se tornar obstáculos se não forem bem
conduzidos. Vamos conhecer alguns deles.
 Scrum 7

Ambiente organizacional desfavorável — O Scrum requer mudanças na

mentalidade de todos os envolvidos para ser efetivo em seus propósitos. En-
tretanto, muitos desenvolvedores, acostumados aos modelos tradicionais,
apresentam resistência e relutam em aceitar o Scrum.

Gerentes que demonstram resistência — Além de alguns desenvolvedores,

pode ser um desafio convencer gerentes a aceitarem o Scrum. O papel de
gerente não existe no modelo Scrum com esse nome, sendo conhecido geral-
mente como product owner ou Scrum master, por exemplo. Logo, o gerente
deveria assumir um desses papéis citados anteriormente, mas muitos podem
interpretar como sendo uma involução ou perda de poder.

Equipes que não sabem lidar com autonomia — Os times Scrum têm por
característica fundamental a autonomia, mas muitas equipes, acostumadas ao
modelo tradicional, não sabem lidar com a autogestão. Isso pode desencadear
em uma série de relações conflituosas entre os membros da equipe ágil.

Agilidade versus “fazer de qualquer jeito” — A agilidade proporcionada

pelo Scrum não pode ser confundida com entregas de baixa qualidade, o
famoso “fazer de qualquer jeito”. A equipe não pode deixar de documentar
seus projetos ou deixar de testá-los.

Papéis confusos e indefinidos — No Scrum, todas as funções devem ser

muito bem definidas. Cada membro da equipe deve saber exatamente o seu
papel dentro do time. Isso fará com que as responsabilidades de cada um
estejam bem organizadas. A falta dessa consciência e maturidade faz com
que as entregas atrasem ou percam qualidade.
É importante observar que o Scrum é um excelente modelo, mas não resolve
todos os problemas. Na verdade, ele nem tem esse propósito. A ideia é facilitar
o cotidiano dos desenvolvedores com entregas parciais de qualidade, melho-
rando a comunicação entre todos os membros da equipe, clientes e gestores.

3 Implementando o Scrum
Possivelmente, você pôde perceber que neste capítulo nos dedicamos a entender
o que é o framework Scrum e como ele se destaca em relação às outras abor-
dagens de desenvolvimento. Agora, a partir deste ponto, vamos compreender
como se dá a sua implementação.
8 Scrum

Inicialmente, deve ser definido quem será o dono do produto (do inglês,
product owner). Esse papel será desempenhado por aqueles que irão designar
quais tarefas devem ser realizadas pelo time de desenvolvimento. O olhar
crítico do product owner será muito importante, principalmente na análise de
riscos. Geralmente, o product owner faz a mediação entre o cliente e a equipe.
Uma pessoa deve ser designada a desempenhar o papel de Scrum master.
Ela será responsável por treinar a equipe com a estrutura do Scrum, além de
reduzir ao máximo os obstáculos que estejam impactando a performance do
time.
O próximo passo é, portanto, definir o backlog do produto a ser desen-
volvido. Dizemos que backlog é a coleção de todas as funcionalidades que
precisam ser desenvolvidas para que o software se torne real. Algo importante
a saber sobre o backlog é que ele está em constante atualização, acompanhando
a evolução do produto. Se no decorrer do desenvolvimento surgir a neces-
sidade de adicionar uma nova funcionalidade ao produto, ela entra na lista
do backlog e cabe ao product owner priorizar quais itens do backlog devem
ser desenvolvidos primeiro. O backlog deve ser analisado pela equipe de
desenvolvimento, a fim de identificar se as informações para que determinada
tarefa seja executada são suficientes.
Além disso, os membros da equipe devem analisar o backlog e fazer uma
estimativa de quanto esforço será dedicado para cada tarefa. Esse esforço
não deve ser estimado em horas, mas em tamanhos relativos, como pequeno,
médio e grande, ou em pontos, utilizando a sequência de Fibonacci: 1, 2, 3,
5, 8, 13, etc.
Em seguida, inicia-se a etapa de planejamento do sprint, na qual acontece
a primeira reunião da equipe. Nela, ocorre a definição do sprint backlog, que,
na prática, representa quais são as funcionalidades do backlog dos produtos
que serão desenvolvidos no período da sprint. Geralmente, cada sprint (ciclo
de desenvolvimento de algumas funcionalidades do backlog) dura em torno
de duas a quatro semanas, respeitando o período de, no máximo, um mês.
Assim, durante essa reunião, o time observa todo o backlog e decide quais são
as funcionalidades que serão entregues no período daquela sprint.
Caso essa não seja a primeira sprint do time e já tiverem ocorrido ou-
tras anteriormente, devem ser analisados os números de pontos que foram
concluídos no sprint passado. Essa é uma questão muito importante, visto que
por meio desses pontos é possível mensurar a velocidade do grupo. Quanto
maior o número de pontos, maior é a velocidade da equipe.
Em conjunto com o Scrum, geralmente, as equipes de desenvolvimento
utilizam o quadro de tarefas Kanban, que, de forma bem sucinta, exibe os
 Scrum 9

status das tarefas em colunas to do (a fazer), in progress (em progresso/em

desenvolvimento/fazendo), test (em teste) e done (feito/concluído). Esse quadro,
em regra, é fixado em um local bem visível, onde todos da equipe podem ver.
Assim, qualquer pessoa que estiver no local em que o quadro está exposto
saberá em que nível do desenvolvimento do software a equipe está, pois nele
são colocados blocos de notas com cada tarefa a ser executada.

To do — Nesta coluna são inseridas todas as tarefas e funcionalidades que

estão na fila de desenvolvimento daquele sprint.

In progress — Nesta coluna são inseridas as tarefas que já estão em fase de

implementação naquele sprint.

Test — Nesta coluna são adicionadas as tarefas que já foram implementadas

para que sejam devidamente testadas, a fim de serem localizados possíveis
erros.

Done — Por fim, nesta última coluna entram as tarefas que já foram concluídas/
testadas e já estão prontas para serem colocadas em produção no sistema.
Uma maneira de substituir o quadro de tarefas Kanban físico é utilizando
ferramentas de software, como o Trello, por exemplo.
Observe na Figura 2 a interface gráfica do Trello. Com esta ferramenta é
possível construir um board (quadro) que representa o projeto que está sendo
desenvolvido pela equipe. Dentro do quadro, você tem acesso a como construir
listas de tarefas. Cada tarefa a ser realizada está organizada em um card
(cartão) diferente dentro da lista, assim como no quadro físico. Entretanto, o
Trello tem muitos outros recursos que auxiliam no gerenciamento de projetos,
como a possibilidade de fazer integrações com outras ferramentas.
10 Scrum

Figura 2. Interface Trello.

Outro ponto importante no desenvolvimento com Scrum é a reunião diária,

também conhecida como daily Scrum, na qual todos os dias, em um horário
predefinido, o time se reúne por no máximo 15 minutos. Essa reunião visa a
responder essencialmente três perguntas: o que foi feito no dia anterior? O que
será feito no dia de hoje? Há algum impedimento técnico ou não que esteja
dificultando a entrega do sprint? (SUTHERLAND, 2016).
Mais adiante são realizadas as reuniões de revisão do sprint (sprint review),
nas quais participam toda a equipe e, se possível, os clientes. Nessas reuniões
são demonstradas todas as tarefas que já estão 100% concluídas e não depen-
dem de mais nenhuma ação para que funcionem. É importante mencionar,
entretanto, que não há a necessidade de se entregar o produto completo, mas
sim funcionalidades, e estas precisam estar completas e funcionando.
Por fim, é chegado o momento da retrospectiva do sprint (sprint retros-
pective), que ocorre após todas as entregas terem sido devidamente realizadas.
Nessa reunião, a equipe discute os pontos fortes e fracos da sprint em questão,
visando a ter um desempenho melhor na próxima sprint. Após a discussão,
devem planejar como serão as melhorias para a próxima sprint, buscando a
excelência da equipe no fazer profissional.
Veja, na Figura 3, a seguir, como todos esses itens se relacionam e desem-
penham os seus papéis no desenvolvimento de software com Scrum.
 Scrum 11

Reunião
diária

A cada
24 horas

Sprint
Duração de até 4 semanas
Backlog Produto
do produto pronto
Planejamento
da sprint Backlog
da sprint Execução da Reunião
Reunião de
sprint de revisão
retrospectiva
(construção
do produto)

Figura 3. Processo do Scrum.

Fonte: Adaptada de Cruz (2018).

O desenvolvimento de software gerenciado pelo Scrum se consolidou nas

grandes empresas de tal forma que esse conceito foi se expandindo, ganhando
visibilidade e sendo adotado por empresas menores. A ideia, portanto, é fazer
entregas de qualidade com o menor tempo possível. O Scrum atua com equipes
reduzidas, visando que elas possam estabelecer uma relação de confiança durante
todo o projeto, gerando benefícios incalculáveis ao negócio e às pessoas envolvidas.
A estrutura do Scrum permite que ele seja aplicado em diversos segmentos, mas
os seus resultados positivos são mais bem observados em projetos que envolvem
tecnologia e que sejam orquestrados por equipes pequenas (CRUZ, 2018).

BROWN, T. Design thinking: uma metodologia poderosa para decretar o fim das velhas
ideias. Rio de Janeiro: Alta Books, 2018.
CRUZ, F. Scrum e Agile em projetos: guia completo. 2. ed. Rio de Janeiro: Brasport, 2018.
HASTIE, S.; WOJEWODA, S. Standish Group 2015 chaos report: Q&A with Jennifer Lynch.
2015. Disponível em: https://www.infoq.com/articles/standish-chaos-2015. Acesso
em: 3 ago. 2020.
PRESSMAN, R.; MAXIM, B. Engenharia de software. 8. ed. Porto Alegre: AMGH, 2016.
SCHWABER, K.; SUTHERLAND, J. Um guia definitivo para o Scrum: as regras do jogo. [S. l.:
s. n.], 2017. Disponível em: https://www.scrumguides.org/docs/scrumguide/v2017/2017-
-Scrum-Guide-Portuguese-Brazilian.pdf. Acesso em: 3 ago. 2020.
SUTHERLAND, J. Scrum: a arte de fazer o dobro do trabalho na metade do tempo. 2.
ed. São Paulo: Leya, 2016.
12 Scrum

Os links para sites da web fornecidos neste capítulo foram todos testados, e seu fun-
cionamento foi comprovado no momento da publicação do material. No entanto, a
rede é extremamente dinâmica; suas páginas estão constantemente mudando de
local e conteúdo. Assim, os editores declaram não ter qualquer responsabilidade
sobre qualidade, precisão ou integralidade das informações referidas em tais links.