SCRUM: ADOÇÃO DE UM FRAMEWORK ÁGIL NO DESENVOLVIMENTO DE UM SOFTWARE PARA TRABALHO DE CONCLUSÃO DE CURSO

Tema: Novas tecnologias e ferramentas para gestão empreendedora.

SCRUM: ADOÇÃO DE UM FRAMEWORK ÁGIL NO

DESENVOLVIMENTO DE UM SOFTWARE PARA TRABALHO DE

CONCLUSÃO DE CURSO

GARCIA, Joelber Flávio dos Santos 1.

SILVA, Kéllyson Gonçalves da 2.

GONÇALVES, Leandro da Costa 3.

MELLO JUNIOR, Fernando Corrêa de 4.

Resumo: Desenvolver software, assim como qualquer outro produto, consiste em seguir uma

série de processos (etapas) de construção para que se obtenha êxito. Esses processos, se

tratando de tecnologia da informação, são conhecidos como metodologias ou frameworks,

como sugerem alguns autores. Existem metodologias tradicionais e ágeis, essa última vem

ganhando cada vez mais destaque em empresas que trabalham com TI. Esse artigo está

centrado no uso do framework ágil Scrum e da ferramenta ScrumHalf, que foram utilizados

para o desenvolvimento de uma aplicação web, com fins de controle do setor bibliotecário, e

que servirá como estudo de caso.

Palavras-Chave: Scrum, Manifesto Ágil, Desenvolvimento Ágil

1 INTRODUÇÃO

As mudanças provocadas pela globalização e pela difusão da tecnologia da informação têm

levado as organizações a adotarem uma ampla gama de recursos tecnológicos, além disso, a

busca por maior competitividade acarreta no aumento da necessidade de acesso rápido, com

segurança e agilidade às informações. Esse conjunto de fatores contribui para fortalecer e

acelerar a informatização de processos, tornando as organizações mais flexíveis e adaptáveis

frente ao mercado além de aproximá-las de seus clientes.

1 Pós-Graduando em Engenharia de Software pelo Centro Universitário de Patos de Minas – UNIPAM. E-mail:

[email protected]


[email protected]


[email protected]

4 Mestre em Engenharia Elétrica. Docente no Centro Universitário de Patos de Minas – UNIPAM. E-mail:

[email protected]

Nesse contexto têm surgido novas formas de gestão que possibilitem um melhor

aproveitamento do trabalho em equipe, não poderia ser diferente no mundo do

desenvolvimento de software. Muitas metodologias ou frameworks de gestão e

desenvolvimento de software têm reinventado a “indústria do software”, dentre elas,

destacam-se os frameworks ágeis de desenvolvimento de software, principalmente o XP

(eXtreme Programming) e o Scrum.

Este artigo visa apontar a experiência adquirida no desenvolvimento de um

software para trabalho de conclusão de curso usando o framework ágil Scrum, que utiliza uma

abordagem diferente da convencional, e está organizado da seguinte forma: o capítulo 2

discorre sobre a revisão de literatura, o terceiro, descreve como o Scrum foi adotado no

desenvolvimento. E por fim, o último, detalha o processo de desenvolvimento durante os

sprints.

2 REVISÃO DA LITERATURA

2.1 ENGENHARIA DE SOFTWARE

A Engenharia de Software é uma área da engenharia que se propõe a fornecer

parâmetros para o desenvolvimento de softwares. Ela está relacionada a todos os aspectos do

desenvolvimento de software, abrangendo desde aspectos iniciais como a especificação de

requisitos até processos de manutenção (SOMMERVILLE, 2008). A Engenharia de Software

engloba três elementos – métodos, ferramentas e procedimentos – que permitem controlar o

processo de desenvolvimento e oferecem uma base sólida para a implementação de softwares

de forma produtiva e com qualidade. Os métodos fornecem os detalhes do que fazer para se

construir o software, as ferramentas fornecem apoio automatizado ou semi-automatizados aos

métodos e, por fim, os procedimentos formam um elo que conecta os métodos e as

ferramentas, permitindo assim o desenvolvimento do software de forma racional e oportuna

(PRESSMAN, 2006).

O termo Engenharia de Software surgiu no final dos anos 60 durante uma

conferência em que se discutia a “crise do software”. A crise do software, por sua vez, era um

resultado direto da evolução tecnológica empregada na fabricação do hardware de

computador baseado em circuitos integrados. Essa evolução viabilizou a implementação de

softwares antes considerados impossíveis de serem desenvolvidos. Os softwares resultantes

tornavam-se cada vez maiores e o desenvolvimento informal mostrava-se cada vez mais

inviável. Projetos de grande porte apresentavam, muitas vezes, anos de atraso. Os custos

frequentemente superavam as previsões, o software resultante não era confiável além de ser

difícil de manter e de desempenho insatisfatório (SOMMERVILLE, 2008).

Esse quadro tornou evidente a necessidade de se criar novos processos de gestão e

desenvolvimento de software. Inicialmente, os processos de desenvolvimento de software

mantinham conceitos típicos da Engenharia. Eles ajudaram a sistematizar o processo de

desenvolvimento de software e mais tarde deu origem a Engenharia de Software (SOUZA

NETO, 2004). Desses processos surgiram as primeiras metodologias de desenvolvimento de

software, como a metodologia cascata, a prototipação, o espiral e outros. Todavia, com as

mudanças no hardware, nas exigências do mercado e no conceito de qualidade de software

essas metodologias não atendiam mais de forma satisfatória ao processo e à gestão do

desenvolvimento de software. Em resposta a este quadro surgiu às metodologias ou

frameworks ágeis.

2.2 AS METODOLOGIAS ÁGEIS DE DESENVOLVIMENTO DE SOFTWARE

A maioria dos conceitos adotados pelos frameworks ágeis nada possuem de novo.

A principal diferença entre esses frameworks e as metodologias tradicionais são o enfoque e

os valores. Os frameworks ágeis enfocam as pessoas e não os processos ou algoritmos como

as metodologias tradicionais. Além disso, existe a preocupação de gastar menos tempo com

documentação e mais com a implementação, propiciando assim maior interação entre

desenvolvedores e clientes (ALVES, 2009).

2.2.1 O Manifesto Ágil

Percebendo que a indústria de software apresentava um grande número de casos

de fracasso, alguns líderes experientes adotaram modos de trabalho opostos às metodologias

tradicionais. Nesse sentido, em 2001, durante uma reunião realizada por 17 desses lideres,

concluiu-se que desenvolver software é algo complexo demais para ser definido por um único

processo. O desenvolvimento de software depende de muitas variáveis e principalmente é

realizado por pessoas em praticamente todas as etapas do processo (BASSI FILHO, 2008).

Nesse encontro chegaram a um concenso quanto a alguns princípios que levavam a bons

resultados. Entretanto, concluíram que uma metodologia unificada seria incapaz de atender

todas as particularidades (SOUZA NETO, 2004). Desse trabalho surgiu o Manifesto Ágil cujo

foco era o cliente e a agilidade no desenvolvimento de softwares.

O Manifesto Ágil valoriza quatro princípios centrais, que resumem bem o foco do

novo processo (BEEDLE, 2001).

1. Indivíduos e interação entre eles mais que processos e ferramentas

2. Software em funcionamento mais que documentação abrangente

3. Colaboração com o cliente mais que negociação de contratos

4. Responder a mudanças mais que seguir um plano

Após a divulgação do Manifesto Ágil, surgiram e/ou ganharam destaque uma

ampla gama de novos frameworks denominados Ágeis. Dentre os quais os mais conhecidos

são: eXtreme Programming (XP), o Scrum e o TDD. Esses frameworks mantêm entre si,

muitas características em comum e geralmente diferenças sutis. De acordo com Pressman

(2006), esses frameworks ressaltam quatro tópicos-chave: são equipes de desenvolvimento

pequenas, entre 2 e 10 membros, que se auto-organizam; priorizam mais o desenvolvimento

em detrimento da documentação; reconhecem, aceitam a mudança, além de valorizarem e

estimularem a comunicação tanto entre os membros da equipe quanto entre a equipe e o

cliente.

Outras características não citadas por Pressmam, mas que merecem destaque são o

fato de serem mais utilizadas em projetos pequenos, embora possam ser aplicadas em grandes

projetos. Além disso, assim como no Processo Unificado (PU) os agilistas adotam o

desenvolvimento iterativo a fim de maximizar o feedback e minimizar riscos.

2.2.2 Scrum

O Scrum (nome derivado de uma formação tática adotada no jogo de rugby) é um

framework de desenvolvimento de software, criado por Jeff Sutherland no início da década de

1990. Muitos de seus fundamentos foram incorporados da indústria automobilística japonesa.

Assim como o XP, é conhecido e utilizado mundialmente.

Posteriormente Shwaber e Beedle aperfeiçoaram os métodos do Scrum. Seus

princípios são coerentes com as idéias do Manifesto Ágil. Por esse motivo, assim como no

XP, o Scrum também visa maximizar a comunicação e o compartilhamento de conhecimento,

minimizar a supervisão, adaptar-se de forma ágil as mudanças, produzir sucessivos

incrementos de software, valorizar os testes e adotar uma documentação minimalista,

geralmente feita após o final de cada iteração. Enfatiza ainda o uso de um conjunto de

“padrões de processo de software” que se mostraram eficientes para projetos com prazos

curtos, requisitos mutáveis e negócio crítico (PRESSMAN, 2006).

2.2.3 O Quadro Kanban

Uma característica significativa do Scrum é que, assim como no XP, o enfoque

dado à documentação é pequeno. Na maioria das vezes, se resume a uma série de histórias de

usuário – similares a casos de uso – afixadas em um quadro Kanban. O quadro Kanban é

originário de um método, homônimo, de fabricação, orientado à produção em série e serve

para facilitar a gerência do fluxo de produção. O desenvolvimento deste método é creditado à

Toyota. Ele surgiu dentro do contexto do Just In Time do qual faz parte (PEINADO, 1999). O

termo Kanban é uma palavra japonesa que significa literalmente registro ou placa visível que

são características básicas do quadro.

Figura 1 - O Quadro Kanban

Fonte: RAHAL JUNIOR, 2011

A Figura 1 representa o fluxo de tarefas no quadro Kanban. Uma história de

usuário ou Item de Backlog é quebrada em várias outras menores que são adicionadas a

coluna A Fazer. Um membro da equipe escolhe um cartão de história, muda-o para a coluna

Fazendo. Após implementar, executar os devidos testes de integração e considerar a tarefa

como pronta ele então muda o cartão para coluna Feito. Isso se repetirá até que a equipe mude

todas as histórias para a coluna Feito.

2.2.4 As Equipes e Papéis do Scrum

O framework Scrum é formado por times scrum e os papéis a estes associados,

time boxes (eventos com duração fixa) artefatos e regras. Os times scrum são configurados de

modo a otimizar a flexibilidade e a produtividade. Por esse motivo, os membros de um Time

Scrum são auto-organizáveis, interdisciplinares e trabalham em iterações. Cada grupo possui

três papéis:

Product Owner(PO) que é o responsável por garantir o retorno sobre o investimento

(return on investment – ROI) do projeto. Ele representa e defende os interesses do

cliente, é ele quem cria, prioriza e mantém a lista de funcionalidades (Backlog de

Produto) do projeto. Para exercer a função de Product Owner deve-se ter visão

estratégica, disponibilidade, criatividade, poder de persuasão, ser comunicativo e

conhecer bem as necessidades dos clientes – muitas vezes esse papel pode ser

assumido pelo cliente ou um representante do mesmo;

Scrum Master que é o responsável por garantir o uso do Scrum, remover

impedimentos e proteger a equipe das interferências externas. Ele auxilia o product

owner no processo de priorização dos requisitos. Deve ser responsável, facilitador,

humilde, comunicativo, influente e organizado;

Time Scrum que deve estimar o tempo e o esforço envolvido nos itens de projeto e

definir as metas das Sprints, visando produzir produtos com alta qualidade e valor para

o cliente. Deve ser multidisciplinar, comunicativo, comprometido, auto gerenciado e

capaz de resolver conflitos; normalmente é composto de 5 a 9 pessoas.

2.2.5 O Sprint e os Artefatos do Scrum

No Scrum existem vários Time-Boxes que são utilizados para gerar regularidade.

Os Time-Boxes mais importantes no Scrum são: a sprint planing meeting (planejamento de

versão), o sprint, a reunião diária, a revisão do sprint e a retrospectiva do sprint. O coração

do Scrum para Schwaber (2010) é o sprint, que é uma iteração de um mês ou menos dentro da

qual é feito um esforço de desenvolvimento. Ao final de cada sprint tem-se como resultado

um pequeno incremento de software que é potencialmente entregável, após isto, a equipe pode

iniciar um novo sprint.

O Scrum utiliza quatro artefatos principais. O backlog de produto que é uma lista

priorizada de tudo que pode ser necessário desenvolver em um software. O backlog de sprint

que é uma lista de tarefas priorizadas no backlog de produto e que ao final de uma sprint,

resultará em um incremento. Um burndown que é um gráfico através do qual é medido a

velocidade do time. Um burndown de release que mede o product backlog restante ao longo

do tempo de um plano de release. E um burndown de sprint mede os itens do backlog de

sprint restantes ao longo do tempo de um sprint (SHWABER, 2010).

Figura 2 - O Ciclo de Vida do Framework Scrum

Adaptado de 3MONTHS, 2011

A Figura 2 representa o ciclo de vida do framework Scrum. Nela pode-se observar

que o product owner e a equipe, baseados na visão inicial do produto, definem as histórias a

serem desenvolvidas, ou seja, o backlog de produto. Este, por sua vez, é dividido em

pequenas “histórias” menores, pela equipe e pelo product owner. Posteriormente, o product

owner escolhe então quais dessas histórias serão priorizadas para o sprint originando assim

um backlog de sprint.

Após definir-se o backlog do sprint, a equipe realiza uma reunião na qual

estabelece as suas metas durante o sprint; trata-se da sprint plane meeting (reunião de

planejamento do sprint). O próximo passo da espiral representa o incremento produzido

durante o sprint. É nessa etapa que ocorre o desenvolvimento do produto. Uma vez que o

novo incremento foi desenvolvido, devidamente testado e integrado ao sistema a equipe faz

uma revisão do sprint. Nessa revisão, a equipe apresenta o que foi realizado durante o sprint e

demonstra as novas funcionalidades incorporadas. O product ownwer testa, para verificar se o

item atende suas expectativas e determina se a meta do sprint foi ou não atingida.

O próximo passo é a retrospectiva do sprint, nela são levantados o que aconteceu

de bom, o que foi ruim e o que deve melhorar. O objetivo dessa reunião é trazer melhoria

contínua ao trabalho da equipe. Feito isso o backlog de produto é atualizado e o ciclo é

reiniciado. Acima do circulo maior, que representa o sprint, tem se outro circulo menor que

representa a iteração diária onde são cumpridas as metas diárias que compõem o Sprint.

Durante o sprint diário, os membros do time fazem uma pequena reunião de 15 minutos

(reunião scrum diária), sempre de pé, no mesmo horário e local. Nela cada membro conta o

que fez desde a última reunião o que pretende fazer e se está tendo algum problema.

De acordo com Kniberg (2007), o Scrum fornece bases para a gestão do processo

de desenvolvimento, mas não se preocupa com como será feito o desenvolvimento. O XP, por

sua vez, sugere as práticas a serem seguidas para o desenvolvimento de um projeto e não se

preocupa com a gestão. Sendo assim, muitas equipes ágeis utilizam XP e Scrum juntos, onde

um fornece boas práticas de desenvolvimento e o outro, boas práticas de gestão. Devido a essa

extensibilidade, os autores agilistas tendem a adotar o termo framework e não metodologia

quando se referem a elas.

Novas metodologias ou frameworks surgem o tempo todo e as vezes pode parecer

dificil escolher uma “correta”. Nesse sentido, Henrajani (2007) afirma que todo projeto deve

ter alguma estrutura de processo básico que precisa seguir. Não ter nenhum processo é ruim,

mas o excesso deles é igualmente ruim. Sendo assim cabe a equipe encontrar o equilibrio

correto, considerando as necessidades do cliente, o tamanho do projeto e as metas da equipe.

3 METODOLOGIA

O ciclo de vida de desenvolvimento do software se baseou no framework Scrum,

onde o desenvolvimento foi dividido em sprints que variaram de cinco dias a no máximo um

mês. Ao final de cada sprint um micro incremento foi integrado ao sistema. Sempre que

apareceram bugs e impedimentos eles retornaram ao Backlog de Produto até serem corrigidos

e finalmente integrados ao sistema. As Reuniões Scrum Diárias foram realizadas pela equipe

todos os dias pessoalmente ou via Skype. Já as revisões de sprint foram feitas ao final de cada

sprint.

A tecnologia de desenvolvimento adotada foi a Plataforma Java, mais

especificamente o framework de desenvolvimento web JavaServer Faces 2.0 e as bibliotecas

de componentes Primefaces 2.2 e Facelets. Foi utilizado ainda o framework Hibernate para

gerenciar as transações com o banco de dados. Para formatação de conteúdo foi utilizado

CSS. Todo o tratamento de informações de interface com o usuário foi provido pelo

Primefaces e/ou por validadores no lado servidor.

Foi feito um levantamento de requisitos e definição do escopo geral da aplicação.

Podem-se observar no Quadro 1 os resultados desse sprint foram os documentos de

especificação de requisitos, que posteriormente foram reavaliados junto aos stakeholders.

Quadro 1 – A Definição de Requisitos

Histórias Tarefa Ferramenta(s) Artefato

Definir requisitos

do sistema

Modelar casos de uso Jude Casos de uso que

modelam o contexto

Elaborar documento de

requisitos Microsoft Word

Documento de requisitos

inicial

Realizar entrevistas com

os stakeholders Microsoft Word Requisitos de sistema

Corrigir casos de uso Jude

Casos de uso modelam o

contexto corrigidos e/ou

novos

Reescrever o documento

de requisitos Microsoft Word

Documento de requisitos

revisado

Fonte: Dados do Trabalho

Posteriormente, foram feitas revisões nos documentos de especificação de

requisitos e escopo considerando os novos apontamentos dos stakeholders, como se pode ver

no Quadro 2. O resultado foi a consolidação dos documentos de especificação de requisitos e

a definição do escopo geral do sistema.

Quadro 2 – O Refinamento de Requisitos

História Tarefa Ferramenta(s) Artefato

Refinar requisitos de

sistema

Apresentar documentos

de especificação de

requisitos

Microsoft Word

Apresentação do

documentos de

especificação de

requisitos

Coletar novos

requisitos Microsoft Word

Documentos de

especificação de

requisitos atualizado

Corrigir documentos de

especificação de

requisitos

Microsoft Word Requisitos de sistema

corrigidos


Definidos os documentos de especificação de requisitos e o escopo geral, o foco

da equipe passou a ser a construção do modelo conceitual do banco de dados e na construção

do banco físico. Ao final teve-se como resultados o modelo conceitual e o script SQL que

possibilitou a construção do banco de dados. O Quadro 3 detalha as tarefas executadas.

Quadro 3 – Terceiro Sprint Concepção e Construção do Banco de Dados

História Tarefa Ferramenta(s) Artefato

Elaboração do modelo

conceitual do banco de

dados

Elaborar do modelo

conceitual Case Studio

Modelo conceitual

do banco de dados

Gerar o script SQL Case Studio

Script SQL para a

construção do banco

físico

Construir o banco físico

Rodar o script SQL

MySQL Query

Browser e

MySQL

Banco de dados

físico

Criar usuários

MySQL Query

Browser e

MySQL

Banco de dados

atualizado com

usuários e

permissões


Após definir os requisitos e modelar o banco de dados, iniciou-se o processo de

desenvolvimento. As histórias foram discutidas e priorizadas, considerando sempre o quanto

agregavam de valor e sua importância para a aplicação como um todo. Além disso, foram

consideradas histórias que representavam maior risco ao projeto. A equipe utilizou a

ferramenta ScrumHalf como apoio a adoção das práticas Scrum.

O Quadro 4 representa a estrutura básica dos sprints. As tarefas apresentadas nele

se repetiram sucessivas vezes até que todas as histórias de usuário foram atendidas. A única

mudança significativa, ocorreu nas “Histórias”, que, no Quadro 4, estão genericamente

representadas pelo termo Desenvolvimento.

Quadro 4 – Estrutura Básica dos Sprints

História(s) Tarefa Ferramenta(s) Artefato

Desenvolvimento

Priorizar histórias ScrumHalf Histórias de usuário

priorizadas

Quebrar histórias em

tarefas ScrumHalf

Histórias de usuário

quebradas

Programação

Eclipse Helios

Netbeans 7.0

MySQL

Browsers

Apache Tomcat

Incremento de

Software pronto

para testar

Testes unitários

Eclipse Helios

Netbeans 7.0

MySQL

Browsers

Apache Tomcat

Incremento de

software pronto para

os testes de

integração

Testes de integração

Eclipse Helios

Netbeans 7.0

MySQL

Browsers

Apache Tomcat

Incremento de

software pronto para

entrar em produção

Atualização do

Backlog de Produto ScrumHalf

Backlog de Produto

atualizado


4 ANÁLISE DOS RESULTADOS

Para a aplicação do Scrum a equipe utilizou uma ferramenta denominada

ScrumHalf, própria para a prática dessa metodologia que está disponibilizada em

www.scrumhalf.com.br.

Definidos os requisitos com o cliente, iniciou-se o desenvolvimento da aplicação.

No backlog de produto foram propostas as histórias que mais agregavam valor ao produto e

essas, posteriormente foram aprovadas. O backlog de produto contém em sua parte superior

informações a respeito do total de histórias elaboradas no decorrer do projeto, das histórias

concluídas e a realizar, além de mostrar a quantidade de histórias que foram propostas, mas

que ainda não foram aprovadas. É importante observar também, na Figura 3, que cada história

possui um valor agregado, definido pela equipe de acordo com o grau de importância para a

aplicação e uma estimativa, que representa a quantidade de dias para realizar aquela história.

Figura 3 - Product Backlog


Com uma ou mais histórias aprovadas, cria-se o backlog de Sprint, onde é

estipulada a meta da sprint, suas datas de início e término, quais histórias irão ser

fragmentadas para transformar-se em tarefas no Kanban e os pontos previstos, que são o

resultado da soma dos valores agregados de cada história selecionada para o sprint. Durante o

período de desenvolvimento, o gráfico burndown mostra informações para que o Scrum

Master possa acompanhar o desempenho da equipe. Ressalta-se que a equipe utilizou a versão

gratuita da ferramenta, o que não inclui o gráfico, como mostra a Figura 4.

Figura 4 - Criação do Backlog de Sprint


Com as histórias fragmentadas, o quadro de tarefas é criado e ocorrem os

procedimentos descritos na seção 2.2.3. A Figura 5 mostra que durante esse sprint, houve

bugs e impedimentos em algumas tarefas, identificados pelas cores rosa e cinza

respectivamente. Um método de sanar problemas durante a aplicação do Scrum ocorre nos

encontros da equipe durante a reunião scrum diária onde a equipe se reúne durante 15

minutos, no máximo, para discutirem o que foi feito, o que tiveram de impedimentos e o que

será desenvolvido até a reunião do dia seguinte. Esse encontro é importante, pois a troca de

experiências contribui para que a sprint tenha sucesso ao seu término. Durante o

desenvolvimento da aplicação bibliotecária, as reuniões diárias da equipe ocorreram tanto

pessoalmente, em um mesmo local, quanto através do aplicativo Skype. É possível observar,

ainda na Figura 5 que, a qualquer momento, é possível finalizar a sprint, independente se o

período de desenvolvimento terminou ou não, ressalta-se que essa funcionalidade da

ferramenta é disponibilizada de acordo com o papel no scrum que o indivíduo ocupa e, nesse

projeto, exclusivamente, foi disponibilizada a todos os membros da equipe, uma vez que eles

exerciam todos os papéis do scrum ao mesmo tempo, pois ambos tiveram contato com os

interesses do cliente, se autogerenciavam e trabalhavam no desenvolvimento da aplicação.

Figura 5 - O Kanban (quadro de tarefas)


Após a finalização do ciclo de desenvolvimento, ocorre a fase de revisão de

sprint, onde são aprovados ou não a história que fez parte do ciclo de desenvolvimento e

também é definido se a meta proposta para a sprint foi alcançada ou não. Na retrospectiva de

sprint, que sucede a revisão, os pontos positivos e negativos que ocorreram durante o

desenvolvimento são registrados e armazenados em histórico, em seguida ocorre uma

atualização do backlog de produto, e se o product owner aprovar, um incremento do produto é

entregue, senão, volta ao ciclo até que seja aprovado. Logo após, a reunião de planejamento

da próxima sprint acontece e essas etapas são repetidas sucessivamente até o término do

projeto. O software de controle bibliotecário, produto deste estudo de caso, foi construído em

cinco sprints, somente após todas essas etapas é que foi obtido como resultado um incremento

estável e pronto para ser entregue ao cliente.

5 CONCLUSÃO

Durante a aplicação do Scrum, houve a necessidade da participação do cliente

(product owner) em, praticamente, todas as etapas de criação do software, o que se destaca

como uma dificuldade encontrada, pois a disponibilidade por parte deste às reuniões era muito

restrita, principalmente durante a programação e demonstração do micro-incremento. A

realização da reunião scrum diária através do Skype, foi devido à impossibilidade de todos os

membros da equipe se reunirem no mesmo local todos os dias. Também, durante o início do

projeto, existiram dúvidas sobre a operação da ferramenta ScrumHalf, o que posteriormente

foram diminuindo à medida em que a equipe adquiria familiaridade em seu manuseio. Como

o Scrum valoriza software funcionando mais do que documentação, destaca-se como ponto

positivo sua utilização, pois, o tempo que seria gasto para a confecção de documentos foi

aproveitado com desenvolvimento, pesquisa e troca de experiências entre o time scrum. A

ferramenta ScrumHalf, é muito eficiente para a aplicação do framework, uma vez que, não é

necessário obter um quadro de tarefas real, e que é possível acessá-lo em qualquer ambiente

com acesso a internet, além de suprir todas as etapas que o Scrum necessita, o que também

acarreta como benefício, corte de custos com materiais físicos. Conclui-se que quando a

equipe consegue agregar ao time o cliente, a possibilidade de controvérsias com o mesmo

durante a entrega do produto é mínima, o que contribui para que os princípios do framework

sejam cumpridos, levando o projeto ao êxito.

REFERÊNCIAS

3MONTHS. Project Lyfecycle. Disponível em: < http://blog.3months.com/wp-

content/uploads/2010/01/project_lifecycle_v1cc.png > acesso em: 04 abr. de 2011.

ALVES, Sérgio de Rezende; ALVES, André Luiz. Engenharia de Requisitos em

Metodologias Ágeis. Goiânia: Universidade Católica de Goiás (PUC – Goiás), 2009.

Disponível em: < http://www.cpgls.ucg.br/ArquivosUpload/1/File/V%20MOSTRA%

20DE%20PRODUO%20CIENTIFICA/EXATAS/10-.PDF > acesso em: 04 abr. de 2011.

BASSI FILHO, Dairton Luiz. Experiências com Desenvolvimento Ágil. São Paulo: USP –

Istituto de Matemática e Estatística da Universidade de São Paulo, 2008.

BEEDLE, Mike et al. Manifesto para o desenvolvimento ágil de software. Disponível em:

<http://manifestoagil.com.br/>. Acesso em: 28 fev. 2011.

HENRAJANI, Anil. Desenvolvimento ágil em Java com Spring, Hibernate e Eclipse. São

Paulo: Pearson Prentice Hall, 2007.

KNIBERG, Henrik. Scrum e XP Direto DasTrincheiras: Como nós fazemos Scrum.

InfoQueue, 2007. Disponível em < http://infoq.com/br/minibooks/scrum-xp-fromthe-trenches

> Acesso em 14 nov. 2010.

KNIBERG, Henrik; SKARIN, Mattias. Kanban e Scrum : Obtendo o Melhor de Ambos.

InfoQueue, 2007. Disponível em <http://www.infoq.com/br/minibooks/kanban-scrum-

minibook> Acesso em 14 nov. 2010.

PEINADO, Jurandir. O papel do sistema de abastecimento Kanban na redução dos

inventários. Revista da FAE, Curitiba, v.2, n.2, p.27-34, maio/ago. 1999.

PRESSMAN, Roger S. Engenharia de Software : 6 ed. São Paulo: McGraw Hill/Nacional,

2006.

RAHAL JUNIOR, Nelson Abu Samra . Melhorando o Entendimento “Como fazer?”.

Disponível em: < http://blogdoabu.blogspot.com/2010/09/melhorando-o-entendimento-como-

fazer.html > acesso em 04 abr. 2011.

SOMMERVILLE, Ian. Engenharia de Software : 8 ed. Rio de Janeiro: Prentice-Hall, 2008.

SOUZA NETO, Oscar Nogueira de. Análise Comparativa das Metodologias de

Desenvolvimento de Softwares Tradicionais e Ágeis. Belém: Unama – Universidade da

Amazônia, 2004.

SCHWABER, Ken. Guia do Scrum. Scrum Alliance, 2010. Disponível em: <

http://www.scrum.org/storage/scrumguides/Scrum%20Guide%20-%20PTBR.pdf > acesso

em 04 abr. 2011.

Technology

SCRUM: ADOÇÃO DE UM FRAMEWORK ÁGIL NO DESENVOLVIMENTO DE UM SOFTWARE PARA TRABALHO DE CONCLUSÃO DE CURSO