a utilização do scrum em um sistema web um estudo de caso

Departamento de Computação – Universidade Federal de São Carlos (UFSCar)Caixa Postal 676 – 13.565-905 – São Carlos – SP – Brasil

Autor para correspondência: [email protected]

ISSN 2316-2872T.I.S. São Carlos, v. 1, n. 1, p. 76-81, jul. 2012

©Tecnologias, Infraestrutura e Software

A utilização do Scrum em um sistema web:

um estudo de caso

Flávia dos Santos Zenaro

Abstract: This paper aims to address the question about software development using the Scrum agile development methodology in a web

system that support decision making, called the Decision Support System or Sistema de Apoio a Decisão (SAD), based in Regency, Frequency

and Monetary Value (RFV), which shows the evolution of customer of a company. Will be reported in this article what are the advantages of

developing a web system using the Scrum agile methodology, indicating the gains from its use compared to traditional methodologies. The

the professionals can prioritize project development gains in production areas and teams in applying the methodology scrum at the expense

of traditional methodology.

Keywords: agile, Scrum, web application

Resumo: Este artigo tem como objetivo abordar a questão sobre desenvolvimento de software utilizando a metodologia de desenvolvimen-to ágil Scrum em um sistema Web de apoio a tomada de decisão, chamado Sistema de Apoio a Decisão (SAD), baseado em Regência, Fre-qüência e Valor Monetário (RFV), que demonstra a evolução da carteira de clientes de uma empresa. Neste artigo serão relatados os processos

Como resultado deste estudo temos os benefícios que a metodologia ágil Scrum tem no desenvolvimento de software em pequenas equipes.

aplicarem a metodologia Scrum em detrimento da metodologia tradicional.

Palavras-chave: metodologia ágil, Scrum, aplicação web

I. INTRODUÇÃO

A escolha de uma metodologia de desenvolvimento é uma das etapas no inicio do desenvolvimento de um novo software, assim como a escolha da linguagem de programação e o banco

metodologia a ser utilizada para o software em questão reper-cute, sem dúvida, em benefícios ao longo de todo o processo de fabricação de um software.

-ração no momento da escolha, como: a quantidade de integran-tes da equipe de desenvolvimento, o tamanho do software que será desenvolvido, o conhecimento da metodologia por parte dos integrantes e o prazo de entrega.

Com prazos cada vez mais apertados, recursos mais enxutos e -

senvolvimento de software e as empresas são obrigados a traba-lharem, são necessários métodos que ajudem a atingir todos es-ses objetivos minimizando gastos e maximizando os resultados.

Assim, o sucesso de um software não está somente na escolha

se enquadra com o cenário e o ambiente em que esse software será desenvolvido. Conhecer as vantagens e desvantagens e os pontos fortes e fracos da metodologia são a chave para uma escolha mais acertada e, com isso, aumentar a probabilidade de

software, tenha mais qualidade, atenda as necessidades reais do cliente, seja desenvolvido em menos tempo e com menos esforço de desenvolvimento.

O restante do artigo está organizado da seguinte maneira: Na seção II é apresentado o objetivo do artigo. Na seção III é apresentada a fundamentação teórica em que a pesquisa foi baseada. Na seção IV são detalhadas as pesquisas realizadas anteriormente sobre o assunto. Na seção V é exibida a possí-vel abordagem e metodologia de pesquisa, enquanto que na

práticos encontrados.

II. OBJETIVO

Nesse contexto, este trabalho terá como maior objetivo des-crever as vantagens que a metodologia ágil Scrum trouxe ao

A utilização do Scrum em um sistema web: um estudo de caso

77 T.I.S. 2012; 1 (1): 76-81

longo do desenvolvimento do software para Web chamado SAD.

As vantagens são visíveis desde a etapa de planejamento onde é estabelecida a visão do projeto e a primeira versão do Pro-

duct backlog até a fase releasing, auxiliando assim, futuros pro- gramadores a entenderem como esta metodologia deve ser em-pregada em cada fase do desenvolvimento de software e em quais fases essa metodologia trará mais benefícios para o projeto.

III. METODOLOGIA ÁGIL

Pelo motivo das metodologias tradicionais serem as mais estudadas e aplicadas e pelo fato que as metodologias de de-senvolvimentos ágeis serem relativamente novas em compa-ração à primeira, uma discussão mais aprofundada sobre esse assunto se faz necessário. Isso é válido para que equipes de

projetos poderão aplicá-las.

uma revolução dos métodos tradicionais de desenvolvimento de software. Alguns dos pontos chaves destas metodologias são a de eliminar gastos com documentação, documentando só o estritamente necessário, dando mais valor à comunicação e co-laboração com o cliente, criando atividades que tragam valor à produção de software com qualidade.

Os aspectos humanos do desenvolvimento de software são mais enfatizados nas metodologias ágeis do que os aspectos de Engenharia de Software propriamente dito. O grande diferen-cial nas metodologias ágeis é o reconhecimento de que as pes-soas são uma fonte importante de conhecimento e condutores do sucesso do projeto.

Outra diferença marcante desta metodologia em comparação

requisitos chamado na metologia ágil como Product Backlog sprint.

O Scrum faz parte dessas metodologias. Outras podem ser citadas também: XP (Extreme Programming), FDD (Feature Driven Development), Crystal, Adaptative Software Develop-ment, DSDM (Dynamic System Development Method) e LD (Agile Lean Development).

Com a criação do “Manifesto Ágil” os seus conceitos ganha-ram conhecimento. São eles formados por 4 propostas:

2º Software executável no lugar de desenvolvimento de docu-mentação.

3º Colaboração do cliente ao invés de negociação de contratos.4º Respostas rápidas a mudanças no lugar de seguir planos.

A metodologia ágil Scrum foi criada como um tipo de pro-cesso de desenvolvimento inicialmente aplicado no gerencia-mento de projetos em empresas de fabricação de automóveis e produtos de consumo em que se prioriza utilização de equipes pequenas para a operação das tarefas que envolvem o desenvol-vimento de software.

processo para projeto e desenvolvimento de software orientado

a objeto, que seja focado nas pessoas e que seja indicado para ambientes em que os requisitos surgem e mudam rapidamente.

para o gerenciamento do processo de desenvolvimento de sof-

tware.O primeiro desenvolvimento de software com Scrum foi

realizado em 1993 por Jeff Sutherland na Easel Corporation (Sutherland 2004), e, junto com Ken Schwaber, formalizaram o Scrum (Sutherland e Schwaber 2007) como processo de de-senvolvimento na OOPSLA.

IV. UTILIZAÇÃO DO SCRUM EM PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

O Scrum possui um ciclo de vida composto de 4 fases a sa-ber: planejamento, stagging, desenvolvimento e releasing.

Na fase de planejamento é estabelecida a visão do projeto e expectativas garantindo recursos para a sua execução. São cria-

Product backlog e o plano de release que são as datas de entrega do sistema.

O Product backlog é o ponto inicial do Scrum, sendo con-siderada a prática responsável pela coleta dos requisitos, con-forme aponta Schwaber (2004, p.33). Nesta prática, através de

com todas as necessidades do negócio e os requisitos técnicos a serem desenvolvidos, ou seja, o Product backlog é uma lista de atividades que provavelmente serão desenvolvidas durante o projeto.

Na fase stagging

criando itens adicionais ao Product backlog relacionados com o tipo do sistema, time, ambiente de desenvolvimento e tipo de aplicação. Nesta fase os times são formados e são construídos os métodos de comunicação e coordenação entre eles.

É na fase de desenvolvimento que os sprints são realizados para o desenvolvimento dos incrementos de funcionalidades do sistema.

A fase de releasing é para efetuar a entrega do sistema ao cliente.

As práticas gerenciais do Scrum são: Product backlog, Dai-

ly Scrum, Sprint, Sprint Planning Meeting, Sprint Backlog e Sprint Review Meeting.

Daily Scrum) são efetuadas pela equi-pe de desenvolvimento, cliente, se possível, e Scrum Master a cada dia de duração do sprint. Tem como objetivo disseminar

impedimentos e priorizar o trabalho a ser realizado no dia que se inicia.

Os Daily Scrums normalmente são realizados no mesmo lo-cal e no mesmo horário do dia. Idealmente são realizados na parte da manhã, para ajudar a equipe a estabelecer as priorida-des do novo dia de trabalho.

discutidas durante o Daily Scrum, mas sim por algumas pesso-as em um momento após a reunião. Neste período o objetivo é

fundamentais: O que você fez ontem?, O que fará hoje? e Exis-te algum impedimento no seu caminho?.


T.I.S. 2012; 1 (1): 76-81 78

Concentrando-se no que cada pessoa fez ontem e no que ela fará hoje, a equipe ganha uma excelente compreensão sobre qual trabalho foi feito e qual trabalho ainda precisa ser feito. Nesta reunião os membros da equipe assumem compromissos uns para com os outros, fortalecendo os laços de comprometi-mento e engajamento no projeto.

A reunião Sprint Planning é realizada com a presença do Product Owner, Scrum Master e de todo Scrum Team. Durante a reunião Sprint Planning, o Product Owner explica as funcio-nalidades de maior prioridade para o Scrum Team, nesta reu-nião o Scrum Team

eles irão mover do Product backlog para o Sprint Backlog.Juntos, o Scrum Team e o Product Owner -

tivo para o Sprint (Sprint Goal), que é uma breve descrição do que pretende-se atingir no Sprint. O sucesso do Sprint será veri-

Sprint Review, baseado no Sprint Goal Sprint Backlog.

Depois da reunião Sprint Planning, o Scrum Team reúne--se separadamente para discutir o que foi proposto e decidir o quanto eles se comprometem a fazer durante o próximo Sprint.

Product Owner, mas será sempre prerrogativa do Scrum Team determinar o quanto eles podem se comprometer.

A metodologia ágil Scrum utiliza o desenvolvimento atra-vés de ciclos geralmente de duas semanas a 30 dias (chamados Sprint -rias. Assim, como resultado, um produto independente e acaba-

e controle do desenvolvimento de software de maneira intera-tiva e incremental, tem o objetivo de ser aplicado em pequenas

o funcionamento do Scrum.Um projeto se inicia com uma visão do produto que será

desenvolvido, ou seja, pelos requisitos e funcionalidades que o

software deverá conter. Estes requisitos e funcionalidades são Product Owner (PO) ou Dono do Projeto. Após

isso, é criado o Sprint Backlog que nada mais é do que a escolha dos requisitos que deverão ser implantados no próximo Sprint.

O Sprint é o tempo de desenvolvimento das funcionalidades

cada Sprint, é entregue um incremento do produto, um sistema acabado e funcionando, após ter passado por todo o processo de desenvolvimento, auditoria e teste. O Scrum implementa um esqueleto iterativo e incremental, através de três papéis princi-pais [Schwaber 2004]. São eles: Scrum Master, Product Owner e o Time, que serão descritos a seguir.

A. O Papel do ScrumMaster

Em um projeto tradicional, o gerente de projeto é o respon-Scrum

Master tem o papel de gerir a equipe, mantendo-a unida e no caminho certo, e é também a pessoa que tem um bom conhe-cimento dos processos que envolvem o desenvolvimento com Scrum para poder cobrá-los de sua equipe. O Scrum Master também é o responsável por proteger o time de interferências externas, removendo os impedimentos levantados pelo time e apoiando-o no uso do Scrum.

B. O Papel do Time

Conhecida como Team Members ou Equipe Scrum, é a equipe ou as várias equipes que podem trabalhar em paralelo na execu-ção de um projeto de software. É responsável pelo desenvolvi-mento dos itens de backlog product

backlog em incremento de funcionalidades, gerenciando seu próprio trabalho. O time é responsável coletivamente pelo suces-so da iteração e conseqüentemente pelo projeto como um todo.

C. O Papel do Product Owner

Na metodologia Scrum, o Product Owner é o dono do pro-jeto, ou seja, é a pessoa para quem está sendo desenvolvido o projeto. O Product Owner é quem estabelece os objetivos do

Figura 1. Visão Geral do Processo Scrum (adaptado de Schwaber, 2004)

Dias de

Trabalho

Restantes

Figura 2. O avanço do desenvolvimento ao longo do Sprint. (adaptado de Schwaber, 2004)


79 T.I.S. 2012; 1 (1): 76-81

-cklogs, como são conhecidas, e participa ativamente de todo o desenvolvimento do software, validando o produto de cada sprint.

A cada iteração, o time controla o andamento do projeto re-

Sprint Burndown -tra o trabalho restante estimado no Sprint. O eixo na vertical apresenta os dias de esforço restantes no Sprint. O eixo na ho-rizontal representa os dias do Sprint.

-dro de trabalho”, no qual as tarefas são dispostas segundo seus status [Schwaber 2004]. Esse quadro oferece maior clareza das tarefas, pois, como o Burndown, basta olhar para ele para reali-zar a leitura do progresso do Sprint.

Product backlog

-sprint a equipe demonstra as

funcionalidades de trabalho para o Product Owner.

V. UTILIZAÇÃO DO SCRUM NO PROCESSO DE DESENVOLVIMENTO DO SISTEMA SAD

-vimento de software pelo método ágil Scrum utilizando um sis-tema web chamado Sistema de Apoio a Decisão (SAD) como estudo de caso.

Para isso, será detalhado como esse sistema foi desenvol-vido e quais foram os resultados obtidos com a utilização da metodologia Scrum.

Nesse sentido, a aplicação da metodologia Scrum resultou na demonstração dos resultados do desenvolvimento do siste-ma SAD nos requisitos funcionais: logar no sistema, cadastrar

Para o desenvolvimento do sistema SAD foi criado o pro-

duct backlog, como ilustra a tabela 1, onde “ID” é um número

-portância do item de backlog podendo variar de 0 à 10 sendo o número 10 o mais importante, no campo “Est” coloca-se a estimativa em horas para a implementação do item de backlog, em “Como demonstrar” uma descrição em alto nível ou um pseudo-código do que deve acontecer durante o sprint e em “Notas” coloca-se qualquer informação que seja importante para o entendimento do item a ser desenvolvido.

A partir da criação da tabela de product backlog foi possível -

ção de quais itens do product backlog entrariam no primeiro sprint.

VI. DESCRIÇÃO DOS SPRINTS REALIZADOS

Dentro deste contexto, descreve-se a seguir os detalhes dos sprints para os itens 1, 3 e 4 do product backlog: Logar no sis-tema, Incluir usuário e Alterar usuário respectivamente.

Tabela 1. Product backlog do sistema SAD

Product backlog

ID Nome Imp Est Como demonstrar Notas

1Logar no sistema

5 5Usuários técnicos operacionais e estratégicos fazem o login no sistema informando email e senha já pré cadastradas pelo usuário técnico.

2

banco de dados

8 8a conexão do banco do cliente com o banco SAD.

3Incluir usuário

5 7Logar-se, entrar na tela de cadastro de usuário, digitar os dados de

4Alterar usuário

5 5Logar-se, entrar na tela de alterar usuário. Se o usuário for do tipo téc-nico poderá alterar todos os dados. Para os outros tipos será permitida somente a alteração da senha.

Utilizar o mesmo arquivo CSS do ID 3.

5Excluir usuário

5 5Logar-se, acionar o item excluir. Somente o usuário técnico poderá realizar a exclusão dos usuários. Informar nome e email do usuário a ser excluído.

Utilizar o mesmo arquivo CSS do ID 3.

6dados

8 8com o banco de dados do sistema.

7RFV

10 10 - RFV de r1 a r5 e f1 a f5.


T.I.S. 2012; 1 (1): 76-81 80

product backlog foi escolhido pelo Scrum Master, para o primeiro sprint, o desenvolvimento do item 1 Logar no sistema.

Foi utilizado um sprint de 7 dias com uma equipe de 3 pes--

ponsável pelo layout e os outros pela programação do módulo. Neste caso, pelo fato da equipe ter um número de integrantes reduzido, cada integrante desempenhou mais de um papel.

O Product Owner além de estabelecer os itens do product

backlog e determinar as prioridades de programação também participou do time, auxiliando no desenvolvimento. O Scrum

Master desempenhou o papel de programador junto ao time, Scrum Master

sprint Login do sistema.

Figura 3. Tela de Login do sistema SAD

Para o segundo sprint foi escolhido o item 3 “Incluir Usuá-rio” do Product Backlog. Para este sprint foram gastos 15 dias e tempo aproximado de 7 horas.

Para este sprint os acompanhamentos diários que a metodo-logia Scrum utiliza foram adaptados pela equipe, ao invés de serem diários, foram feitos conforme a necessidade. Quando cada membro do time encerrava a sua parte no desenvolvimen-to, comunicava-a aos outros integrantes por email enviando os arquivos e um resumo do desenvolvimento.

Quando algum integrante precisava de ajuda, este solicita-

tentava avançar no sprint. Quando julgávamos necessário era marcado um encontro para realizar o desenvolvimento em gru-

sprint.Para o terceiro sprint foi escolhido o item Alterar usuário para

dar continuidade ao sistema que já possuía a funcionalidade de Incluir usuário. Neste sprint foi estimado o tempo de 5 (cinco) horas de programação para a sua conclusão, mas devido a alguns impedimentos como a falta de experiência na linguagem java e problemas na programação que enfrentamos, foram necessárias 8 (oito) horas de desenvolvimento e um encontro para desenvol-vimento em conjunto. Os acompanhamentos foram com interva-los de 1 (um) dia com envio por email do projeto e dos proble-mas que estavam sendo enfrentados por cada programador.

no terceiro sprint.

Figura 5. Tela de Inclusão de Usuário do sistema SAD

VII. CONCLUSÃO

A partir deste estudo de caso conclui-se que com a utilização do Scrum no desenvolvimento do sistema SAD a agilidade no processo de fabricação do software foi satisfatória mesmo com um número pequeno de integrantes. Evidenciamos assim, que a quantidade de pessoas envolvidas na elaboração de um sof-

tware

só o sucesso ou fracasso de um sistema, mas sim a utilização de uma metodologia que se enquadre com o cenário que envolve seu desenvolvimento.

Durante as etapas da utilização da metodologia Scrum no desenvolvimento do sistema SAD, percebeu-se a necessidade

dos sprints de 30 dias para 7 ou 15 dias, conforme o calendário

-volvido por cada um, e saber quais os principais impedimentos

sprint como tirar -

ximo item do product backlog a ser desenvolvido. Daily Scrum foram

feitas de 1 a 3 vezes na semana, dependendo da complexidade do sprint, assim cada um do time enviava por email informa-

de um encontro para desenvolver algum item mais complexo em conjunto.

Figura 4. Tela de Inclusão de Usuário do sistema SAD


81 T.I.S. 2012; 1 (1): 76-81

Dessa forma, como a metodologia Scrum nunca fora antes utilizada por nenhum dos integrantes do grupo, podemos con-cluir que foi uma experiência que acrescentou ganhos a todos e uma grande oportunidade de obtenção de conhecimento e vi-vência no desenvolvimento de software utilizando uma meto-dologia ágil.

Evidenciamos que o Scrum agiliza e torna o processo de de-senvolvimento de software mais direto pela ausência de criação de uma documentação detalhada, como nos modelos tradicio-nais de desenvolvimento de software -vamente no tempo total do projeto. Através dos sprints é pos-sível desenvolver um produto acabado a cada ciclo de tempo fazendo com que o cliente possa utilizar o software

suas utilidades logo no início do desenvolvimento do sistema e ao longo do projeto em períodos curtos de tempo, propiciando oportunidades de ajustes e melhorias contínuas durante todo o desenvolvimento.

REFERÊNCIAS

BECK, K AT ALL. (2001) Manifesto for Agile Software Devel-

opment. Disponível em: <http://www.agilemanifesto.org>. Acesso em: 25/04/2010.

Cavalcanti, Eric at all. Ferramenta OpenSource para Apoio ao

Uso do scrum por Equipes Distribuídas. Disponível em: <http://www.lbd.dcc.ufmg.br:8080/colecoes/wdds/2009/ 006.pdf>. Acesso em: 26/05/2010

Cohn, Mike. Introduction to Scrum - An Agile Process. Dis-ponível em: <http://www.mountaingoatsoftware.com/top-ics/scrum>. Acesso em: 23/10/2010.

Highsmith, J. Agile Project Management – Creating Innovative

Products, AddisonWesley, 2004.Kniberg, Henrik. Scrum e XP direto das Trincheiras Como nós

fazemos Scrum. InfoQ, 2007.Schwaber, K. Agile Project Management With scrum. Micro-

soft Pr, 2004.Sutherland, Jeff. Agile Development: Lessons Learned from the

First scrum. Cutter Agile Project Management Advisory Service: Executive Update, vol.5, 2004.

Sutherland, Jeff, Schwaber, Ken. The Scrum Papers: Nuts,

Bolts, and Origins of an Agile Process, Draft 14/10/2007.

a utilização do scrum em um sistema web um estudo de caso

Documents