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

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.

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.

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.

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.

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

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

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.

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.

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.

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.