1. DESENVOLVIMENTO ÁGIL: UMA ABORDAGEM SOBRE O SCRUM
Klaus Fischer Gomes Santana1
Rafael Araújo de Freitas2
RESUMO
A metodologia Scrum assume-se como extremamente ágil e flexível.
Defini-se como um processo de desenvolvimento iterativo e incremental que pode
ser aplicado a qualquer produto ou no gerenciamento de qualquer atividade
complexa, proporcionando um excelente entendimento entre as equipes de
desenvolvimento. Com todo esse entrosamento e participação ativa dos clientes, o
rendimento do projeto aumenta e os requisitos e a solicitação de alteração passa a
ser atendido mais rapidamente. As metodologias de desenvolvimento ágil vem se
destacando a cada dia, porém essas ainda são pouco difundidas no meio
acadêmico. O objetivo deste artigo, além de difundir esse assunto e servir de apoio
para futuras pesquisas, é demonstrar de maneira simples e objetiva, o
funcionamento, as características, o vocabulário e a aplicação da metodologia
Scrum em um ambiente de trabalho.
Palavras-chave: Engenharia de Software, Métodos de Desenvolvimento,
Desenvolvimento Ágil, SCRUM.
1 INTRODUÇÃO
Um desafio constante da área de Engenharia de Software é melhorar o
processo de desenvolvimento de software. Mesmo com a constante evolução de
métodos, técnicas e ferramentas, a entrega de softwares em prazos e custos
estabelecidos nem sempre é efetiva. Uma das causas desse problema é o excesso
de formalidade nos modelos de processo propostos nos últimos 30 anos.
Existe hoje a necessidade de criar software de forma mais rápida, mas
com qualidade. Esse produto pode ser obtido utilizando métodos ágeis e padrões
organizacionais e de processos.
O desenvolvimento ágil é uma filosofia. É uma maneira de pensar sobre
produção de software. A decisão canônica desta maneira de pensar é o “Manifesto
Ágil” (Becket al., 2001), um conjunto de 4 valores (figura 1) e 12 princípios (figura 2).
1
Graduando em Análise e Desenvolvimento de Sistemas. E-mail: klausfgsantana@gmail.com
2
Graduando em Análise e Desenvolvimento de Sistemas. E-mail: jedi.rafael@gmail.com

2. Figura 1: Manifesto para o ágil
Fonte: http://manifestoagil.com.br/index.html
Figura 2: Princípios do manifesto ágil
Fonte: http://manifestoagil.com.br/principios.html
Nos últimos anos, métodos ágeis como o XP (Beck, 1999), Scrum
(Schwaber, 2002) e Crystal (Cockburn, 2002), entre outros, passaram a ser
utilizados por grandes empresas como Google, Yahoo, Symantec, Microsoft, entre
outras, universidades, institutos de pesquisa e agências governamentais.
Neste Artigo abordaremos a Metodologia de Desenvolvimento Ágil Scrum,
veremos como se dá sua implantação no processo de desenvolvimento de software.

3. 2 ENTENDENDO O SCRUM
Estamos crescendo tão rápido que parece que sempre precisamos de mais
umas regrinhas aqui, mais um pouco de papel ali... precisamos ter muito
cuidado, pois cada novo nível gerencial, cada nova regra ou formulário
atrapalha. Eles acabam com a mágica, cortam a eletricidade da inspiração.
Com restrições em excesso, você pára de pensar no que pode fazer e
começa a pensar no que não dá para fazer (Cirque Du Soleil – A reinvenção
do Espetáculo; Ed. Campus; Elsevier).
As raízes do Scrum estão num artigo que sumariza as 10 melhores
práticas em empresas japonesas, escrito por Takeuchi e Nonaka, cujo título é “O
jogo do desenvolvimento de novos produtos”, publicada na Harvard Bussinesss
Review em janeiro de 1986. Este artigo introduziu o termo Scrum para referir-se às
reuniões de equipes que praticam a autodireção e a adaptabilidade.
A palavra Scrum não é uma sigla e nem tem tradução para o Português.
O termo Scrum é o nome usado para a reunião de jogadores, no jogo de Rugby,
quando eles se organizam em círculo para planejar a próxima jogada. É uma forma
de mostrar que o projeto deve ser conduzido em pequenos ciclos, mas com uma
visão de longo prazo, que é ganhar o jogo.
Desenvolvimento de produtos complexos ocorre em situações de muitas
mudanças. Quanto mais próximo do limite do caos a equipe conseguir trabalhar,
porém mantendo a ordem, mais competitivo e útil será o produto resultante. O
Scrum é a metodologia que permite esta forma de trabalhar.
O processo de desenvolvimento de sistemas é complicado e complexo.
Logo, grande flexibilidade e controle são necessários. A evolução favorece aqueles
que se expões e aceitam as mudanças e estão preparados para se adaptarem a
essas. Nesse caso é necessária uma abordagem gerencial de projetos que permita
às equipes operarem de forma flexível e adaptável num ambiente complexo, usando
processos imprecisos.
Scrum é um processo bastante leve para gerenciar e controlar projetos de
desenvolvimento de software e para criação de produtos, além de tratar-se de
metodologia ágil e seguir as filosofias iterativa e incremental. Ele se concentra no
que é realmente importante: gerenciar o projeto e criar um produto que acrescente
valor para o negócio.

4. A maioria dos métodos e técnicas de gerenciamento de projetos são
bastante prescritivas, isso força as pessoas a seguirem uma sequência predefinida
de passos, com pouca flexibilidade para mudanças. Tradicionalmente, os projetos de
construção de software seguem um ciclo envolvendo captura de requisitos, análise,
projeto técnico (design), programação, teste e implantação com cada estágio sendo
completado antes que o próximo seja iniciado.
Contudo, são características importantes do Scrum: a adaptabilidade e o
empirismo. Sua abordagem é oposta a do modelo em cascata, inicia-se a análise
assim que alguns requisitos estiverem disponíveis, assim que alguma análise tiver
sido feita começam os trabalhos de projeto técnico (design), e assim por diante.
Em outras palavras, o projeto trabalha num pedaço pequeno de cada vez.
Esta abordagem pode ser chamada de iterativa, e cada iteração consiste na captura
de requisitos, um pouco de análise, um pouco de design, mais alguma programação
e testes, culminando num ciclo iterativo com várias entregas conforme podemos ver
na figura 3.
Figura 3: Ciclo de iterações de sprint de um projeto.
3 O PRODUCT BACKLOG
O projeto no Scrum começa com uma visão, que pode ser vaga no
princípio, talvez expressa em termos de marketing ou uma visão técnica, e que
depois ficará mais clara à medida que o projeto evoluir.

5. A partir da visão é definida uma lista de itens priorizados, composta por
requisitos e funcionalidade que precisam ser construídos para que a visão seja
concretizada. Estamos falando do Product Backlog).
O Product Backlog é o coração do Scrum. É basicamente uma lista de
requisitos, histórias, coisas que o cliente deseja, descritas usando uma linguagem
que seja clara para o cliente.
Figura 4:Eexemplo de planilha com o Backlog Product.
O Scrum baseia-se no desenvolvimento iterativo, que é uma técnica que
procura antecipar o lucro do projeto de uma forma controlada. O produto pode ser
entregue aos clientes de forma incremental, antecipando o momento de entrega
para o cliente.
Desta forma, o projeto começará a gerar valor e lucro muito mais cedo. O
Scrum busca este objetivo produzindo uma versão que pode ser potencialmente
distribuída para o mercado em intervalos regulares de 30 dias. Pesquisas indicam
que 80% do valor do produto vem de 20% das suas freatures. Com isso em mente,
poderíamos construir, de forma interativa, um produto que tenha estes 20% das
freatures logo no início do projeto.
4 PAPÉIS NO SCRUM
O Scrum trabalha basicamente com três papéis: o Product Owner, o
Scrum Master e a Equipe Scrum.

6. O Product Owner é responsável por representar os interesses das
pessoas que apostaram no projeto e no produto resultante. O Product Owner
consegue a verba, define os requisitos gerais, define os objetivos e o plano de
releases. A lista de requisitos é o Product Backlog. O Product Owner provavelmente
será um gerente de projeto, ou um patrocinador do projeto, um membro da equipe
de marketing ou um cliente interno (KNIBERG, 2007).
O Scrum Master ocupa uma posição similar à ocupada pelo Product
Owner. É responsável por forçar os valores e as práticas do Scrum, remover
obstáculos, ensinar o processo a todas as pessoas, implementar o Scrum e garantir
que todas as pessoas sigam as regras e as práticas do Scrum. O Scrum Master é
um líder e não um gerente suas responsabilidades podem se resumir em:
• Remover as barreiras entre a equipe de desenvolvimento e o Product
Owner, de modo que o Product Owner possa orientar o
desenvolvimento;
• Ensinar ao Product Owner, como maximizar o ROI (Return on
investment) e atingir os seus objetivos através do Scrum;
• Melhorar a vida da Equipe Scrum, facilitando a criatividade através do
empowerment;
• Manter a informação sobre o progresso da Equipe Scrum sempre
atualizado e disponível para todos os interessados.
A Equipe Scrum é o grupo de pessoas responsável por desenvolver ou
construir as funcionalidades do produto. As equipes são autogerenciadas, auto-
organizadas e multifuncionais. Geralmente, a equipe é composta por 5 a 10
membros (o recomendado são sete pessoas) e deve ser multifuncional, composta
por indivíduos com diferentes especializações. A equipe pode ser composta por
desenvolvedores em tempo integral e participantes externos (marketing, vendas,
clientes etc.).
5 FASES DO SCRUM

7. O Scrum é composto por três fases: pré-game, game e pós-game. A
primeira e última fases consistem em processos definidos, onde todos os processos,
mais as entradas e as saídas, são bem definidos. Os conhecimentos sobre como
realizar estas fases são explícitos e podem compreender uma ou mais iterações.
No Pré-game temos duas partes: planejamento e arquitetura. No
planejamento é definido um novo release, com base nas informações conhecidas
até o momento, tabuladas num Backlog, junto com uma estimativa de prazo e custo.
No caso de um novo produto, esta fase consiste na conceitualização e análise. No
caso da evolução de um produto já existente, esta fase consiste numa análise
limitada. Na arquitetura os itens do Backlog são projetados com vistas à
implementação. Esta fase inclui definições e modificações na arquitetura e design de
alto nível (KNIBERG,2007).
Na fase intermediária do game o processo é empírico. A maioria dos
processos nesta fase são indefinidos e tratados como uma caixa preta que requerem
apenas controles externos. Por exemplo, o controle de riscos ocorre em cada Sprint
para evitar o caos e maximizar a flexibilidade. Na fase do game o produto é
construído em múltiplas iterações chamadas no Scrum de Sprint. O produto pode
ser modificado a qualquer momento durante o planejamento do Sprint, bem como
durante o Sprint. Essas mudanças ocorrem por conta da complexidade, ações da
decorrência, prazo, qualidade, pressão de custo etc. Esta fase é composta dos
seguintes macroprocessos:
• Reuniões com as equipes para rever o planejamento dos releases;
• Revisão dos padrões com os quais o sistema precisa ser compatível e fazer
os ajustes necessários;
• Realização dos Sprints até que o produto esteja pronto para distribuição.
Quando a gerência decide que as variáveis de tempo, concorrência de
mercado, requisitos, custos e qualidade estão adequadas para distribuir o produto,
ela declara que o release está fechado e a fase de pós-game começa. Nesta fase o
produto é preparado para distribuição, incluindo integração, testes adicionais,
documentação de usuário, preparação de material para treinamento e de marketing,
dentre outras coisas.
6 PRÁTICAS DO SCRUM
6.1 Plano de Jogo

8. No Scrum o plano de jogo funciona da seguinte maneira: registram-se
todos os requisitos num Product Backlog, que é uma lista inicial de requisitos. Cabe
lembrar que essa lista pode ser ajustada durante o projeto pelo Product Owner, a fim
de modificar a sequência em que os itens serão trabalhados, bem como para
adicionar ou retirar itens.
Os requisitos não necessitam ser precisos nem estarem descritos de
forma completa e detalhada, estes requisitos serão obtidos com os futuros usuários
do produto e com pessoas do negócio. Os principais itens, ou seja, os de maior
importância, vão para o topo da lista.
Mesmo com muitos itens já definidos, pode acontecer de apenas alguns
deles estarem associados a um Sprint. No desenvolvimento ágil você nunca deverá
planejar nada além da iteração seguinte, isto pode ser uma perda de tempo, mesmo
porque o conteúdo de cada Sprint é sempre definido nas reuniões de planejamento
que precedem cada Sprint.
6.2 Sprint
Um Sprint é um conjunto de atividades de desenvolvimento conduzidas
num período de tempo predefinido, chamado de Time Box (caixa de tempo), que
normalmente varia de uma a quatro semanas. Este intervalo é baseado na
complexidade do produto, na avaliação de riscos e no grau de volatilidade dos
requisitos.
Durante um Sprint a equipe desenvolve as seguintes atividades:
• Desenvolvimento (análise, projeto técnico – design, programação,
testes e documentação);
• Empacotamento (criação de programas executáveis);
• Revisão (revisão do que foi feito, correção de problemas);
• Ajustes (consolidar as informações obtidas na revisão e realizar as
mudanças necessárias).
Ao final do período do Sprint, normalmente em 30 (trinta) dias, é
produzido uma versão do produto que pode potencialmente ser distribuída para o
mercado. Esta versão deve prover algum valor para o negócio.

9. A vantagem desse curto período é que ele permite ao Product Owner, o
cliente, repriorizar os itens do Product Backlog com base no resultado do Sprint
anterior. A importância disto é que o projeto sempre estará produzindo algo que
possa ser utilizado no negócio.
Todo Sprint começa com uma reunião de planejamento, trabalhando de
forma colaborativa o Product Owner e a Equipe Scrum para decidirem os itens da
próxima iteração. Os objetivos básicos desta reunião são:
a) O Product Owner deve selecionar os itens de maior prioridade;
b) O Product Owner relembra à Equipe Scrum quais os objetivos do
projeto;
c) É dito ao Product Owner o que a Equipe Scrum pensa que conseguirá
realizar, considerando o que está sendo pedido.
A reunião de planejamento não deve durar mais que 8 (oito) horas, sendo
dividida em duas partes de 4 (quatro) horas. Na primeira o Product Owner apresenta
e descreve os itens de maior prioridade. A equipe faz questionamentos e esclarece
dúvidas quanto ao conteúdo, propósito, significado e intenções. Quando a equipe
achar que tem informações suficientes, seleciona os itens que acredita que poderá
desenvolver durante a iteração.
Nas próximas 4 (quatro) horas é planejado o Sprint, já que é a equipe que
vai gerenciar seu próprio trabalho. É feita também pelo Dono do Produto e pelo
Mestre Scrum uma estimativa de tempo, que inicialmente são apenas
“adivinhações”, ganhando precisão no decorrer do processo. Terminada a reunião a
equipe de projeto cria o Backlog do Sprint, um quadro que vai ser atualizado
diariamente, bastante parecido com o quadro do Product Backlog. Lembrando que o
objetivo é definir o que vai ser trabalhado e não como o trabalho vai ser feito.
6.3 Reuniões do Scrum
No Scrum a Equipe Scrum realiza uma reunião de 15 minutos todos os
dias pela manhã. O propósito da reunião é sincronizar o trabalho diário de todos os
membros da equipe, sempre sem se desviar do foco principal. Essa reunião é curta,
com todos os participantes em pé, podendo caso necessário, ser ampliada para 30
minutos.

10. Outra prática interessante é a cobrança de R$ 1,00 de cada participante
que chegar atrasado. Pode até parecer engraçado, mais ajuda criar foco e evitar que
as reuniões tenham que se prolongar devido ao atraso de alguns participantes.
Existe também a reunião de revisão do Sprint, que ocorre no final de cada
Sprint. É uma reunião de quatro horas onde a equipe apresenta o trabalho
desenvolvido para o Product Owner.
Após a reunião de revisão do Sprint, o Scrum Master faz uma reunião de
retrospectiva com a Equipe. Em três horas de duração ela visa encorajar a Equipe a
revisar seu processo de trabalho, tendo em vista o framework e as práticas do
Scrum, para ter um melhor desempenho na próxima iteração.
6.4 Escalabilidade
Se houver necessidade pode ser montado mais de uma Equipe Scrum e
realizar um trabalho em paralelo. Esta técnica chama-se escalar o projeto. Projetos
escalados necessitam de controles adicionais para acompanhar e sincronizar os
trabalhos. Quanto às reuniões diárias cada equipe realiza a sua, que serão seguidas
de reuniões de Scrum, com um representante de cada equipe.
Antes de escalar um projeto deve ser preparada a infra-estrutura
adequada para o projeto, utilizando o primeiro Sprint para tal implementação.
Requisitos não funcionais para a construção da infra-estrutura de escalonamento
devem ganhar maior prioridade no Product Backlog, já que estes itens precisam
estar prontos para que o projeto possa ser escalonado.
7. CONCLUSÃO
O Scrum é um método bastante simples e objetivo, é composto por
poucas práticas, artefatos e regras e por isso é fácil de aprender. Não é um
processo prescritivo, sendo indicado para trabalhos complexos onde é muito difícil
prever acontecimentos futuros.
Ainda oferece framework e conjunto de práticas que mantém a clareza do
processo. O que permite que a equipe e outros interessados possam acompanhar o
andamento do projeto e tomar as decisões que forem necessárias para direcionar o
projeto.

11. Após estudarmos o desenvolvimento ágil, e principalmente o Scrum,
podemos ver o quanto é benéfico para o processo de construção de software tais
técnicas. O fato de apontarmos uma ou outra é bastante complicado, sendo que
dependendo dos objetivos da equipe de desenvolvimento, as vezes é comum o
trabalho em conjunto de mais de uma metodologia de desenvolvimento ágil.
8. REFERÊNCIAS
MARTINS, José Carlos Cordeiro. Técnicas para gerenciamento de projetos de
software. Rio de Janeiro: Brasport, 2007, 432p.
SHORE, Jim; WARDEN, Shane. A Arte do Desenvolvimento Ágil. Alta Books,
2008, 408 p.
KNIBERG, Henrik. Scrum e XP direto das trincheiras. INFOQ. 2007, 141p.
SCHWABER, Ken. Guia do Scrum. ScrumAlliance. 2009, 22p.
Manifesto para o desenvolvimento ágil de software. Disponível em:
<http://manifestoagil.com.br/index.html>. Acesso em 02 nov.
Doze princípios por trás do manifesto ágil. Disponível em:
<http://manifestoagil.com.br/principios.html>. Acesso em 02 nov.