Este artigo relata como foi abordada a metodologia ágil SCRUM, durante a elaboração de um software, apresentado como resultado de um TCC para obtenção do título de bacharel em Sistemas de Informação.

1. 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:
joelber.flavio@gmail.com
2 Pós-Graduando em Engenharia de Software pelo Centro Universitário de Patos de Minas – UNIPAM. E-mail:
kellyson.si@hotmail.com
3 Pós-Graduando em Engenharia de Software pelo Centro Universitário de Patos de Minas – UNIPAM. E-mail:
leandrocgsi@hotmail.com
4 Mestre em Engenharia Elétrica. Docente no Centro Universitário de Patos de Minas – UNIPAM. E-mail:
fernandocmjr@unipam.edu.br

2. 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

3. 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

4. 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

5. “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.

6. 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.

7. 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

8. 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.

9. 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)
Modelar casos de uso
Jude
Elaborar documento de
requisitos
Definir requisitos
do sistema
Realizar entrevistas com
os stakeholders
Microsoft Word
Microsoft Word
Artefato
Casos de uso que
modelam o contexto
Documento de requisitos
inicial
Requisitos de sistema
Casos de uso modelam o
Corrigir casos de uso
Jude
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.

10. Quadro 2 – O Refinamento de Requisitos
História
Tarefa
Ferramenta(s)
Apresentação do
Apresentar documentos
de especificação de
Microsoft Word
requisitos
Refinar requisitos de
sistema
Coletar novos
requisitos
documentos de
especificação de
requisitos
Documentos de
Microsoft Word
especificação de
requisitos atualizado
Corrigir documentos de
especificação de
Artefato
Microsoft Word
requisitos
Requisitos de sistema
corrigidos
Fonte: Dados do Trabalho
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
Elaborar do modelo
Elaboração do modelo
conceitual
Ferramenta(s)
Case Studio
conceitual do banco de
dados
Artefato
Modelo conceitual
do banco de dados
Script SQL para a
Gerar o script SQL
Case Studio
construção do banco
físico
MySQL Query
Rodar o script SQL
Browser e
MySQL
Construir o banco físico
MySQL Query
Criar usuários
Browser e
MySQL
Fonte: Dados do Trabalho
Banco de dados
físico
Banco de dados
atualizado com
usuários e
permissões

11. 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)
Priorizar histórias
ScrumHalf
Quebrar histórias em
tarefas
ScrumHalf
Artefato
Histórias de usuário
priorizadas
Histórias de usuário
quebradas
Eclipse Helios
Netbeans 7.0
MySQL
Software pronto
Browsers
Programação
Incremento de
para testar
Apache Tomcat
Eclipse Helios
Desenvolvimento
Netbeans 7.0
Testes unitários
MySQL
Browsers
Apache Tomcat
Incremento de
software pronto para
os testes de
integração
Eclipse Helios
Netbeans 7.0
MySQL
software pronto para
Browsers
Testes de integração
Incremento de
entrar em produção
Apache Tomcat
Atualização do
Backlog de Produto
ScrumHalf
Fonte: Dados do Trabalho
Backlog de Produto
atualizado

12. 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
Fonte: Dados do Trabalho

13. 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
Fonte: Dados do Trabalho
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

14. 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)
Fonte: Dados do Trabalho
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

15. 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.

16. REFERÊNCIAS
3MONTHS. Project Lyfecycle. Disponível em: < http://blog.3months.com/wpcontent/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-scrumminibook> 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-comofazer.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.