______________________ 1Sociedade Educacional de Santa Catarina – SOCIESC. e-mail: hyebahi@gmail.com. 2Sociedade Educacional de Santa Catarina – SOCIESC. e-mail: camargho@gmail.com.

DESENVOLVIMENTO E APLICAÇÃO DE UMA FERRAMENTA PARA CONTROLE DE

SOLICITAÇÕES E UTILIZAÇÃO DE SCRUM EM EMPRESA NIBSS: ESTUDO DE

CASO

Haissam Yebahi1, Luiz Camargo2

Resumo: O sucesso de projetos na área da engenharia de software depende muitas vezes da

aplicação das melhores práticas, de acordo com as características particulares do projeto e do

conhecimento técnico dos responsáveis por garantir seu sucesso. As metodologias ágeis estão se

tornando uma grande aliada em projetos de software, cujo principal objetivo está em realizar as

entregas de forma mais rápida e assegurar a satisfação do cliente. O presente artigo tem como

objetivo desenvolver uma ferramenta para melhorar a gestão de solicitações da área de TI e

avaliar a utilização do scrum em ambiente corporativo para maximizar o retorno de investimento

de acordo com as necessidades do negócio. Ao implantar a ferramenta de controle de solicitações,

foi possível reportar as entregas para a gerência da TI e permitir aos coordenadores

acompanharem o andamento de projetos e atividades executadas. A adoção do scrum está sendo

feita gradativamente e o sucesso da utilização depende do apoio dos envolvidos e já se percebe um

maior comprometimento da equipe em aumentar a qualidade do serviço prestado. Apesar dos

benefícios propostos pelo scrum, deve ser considerado o tempo necessário para sua

institucionalização e assim aumentar a satisfação dos envolvidos.

Palavras-chave: Scrum. Metodologias ágeis. Processos de software.

1 INTRODUÇÃO

Projetos na área de TI (Tecnologia da Informação) em ambiente corporativo são normalmente

planejados de acordo com a necessidade dos envolvidos, que dependem de informações gerenciais

para organizar e suprir as demandas internas.

Mudanças durante o ciclo de vida de um software são quase que inevitáveis. O sucesso de

projetos na área da engenharia de software depende muitas vezes da aplicação das melhores

práticas, de acordo com as características particulares do projeto e do conhecimento técnico dos

responsáveis pela execução (PFLEEGER, 2004).

As metodologias ágeis vêm se tornando uma grande aliada em projetos de software que não

necessitam de controles rígidos de documentação e permitem flexibilidade na execução das

atividades. Um dos principais motivos para tal aceitação se deve ao foco em entregas rápidas e de

forma incremental de acordo com as expectativas do cliente, o que torna os resultados visíveis em

um curto intervalo de tempo.

Em 2001, foi publicado o manifesto ágil, responsável por definir os princípios e práticas desta

metodologia que mais tarde se tornou a Agile Alliance, uma organização não lucrativa que promove

o desenvolvimento ágil (AGILE ALLIANCE, 2012).

O scrum é fundamentado nas teorias empíricas de controle de processo utilizando uma

abordagem iterativa e incremental para melhorar estimativas, controlar riscos e permitir manter o

foco na entrega com maior valor de negócio ao cliente (SCHWABER & SUTHERLAND, 2011).

No Scrum existe o product backlog, formado pelas solicitações do cliente, comumente denominado

product owner, o qual seria responsável por definir prioridades e estaria inserido de forma mais

transparente nas tomadas de decisões de entregas periódicas, denominadas de sprint. Outro papel

importante é o scrum master, responsável por garantir que o scrum seja entendido e aplicado, além

de prover suporte para o sucesso do projeto pela equipe de desenvolvimento (KNIBERG, 2007).

De acordo com o observatório da SOFTEX, responsável por realizar pesquisas voltadas ao

setor nacional de software e serviços de TI, o Brasil é constituído por empresas que formam a

chamada IBSS (Indústria Brasileira de Software e Serviços de TI), cuja receita provém de

atividades relacionadas a TI (e.g., desenvolvimento de software, consultoria, suporte técnico) e as

NIBSS (Não-IBSS), formadas por empresas com fonte de renda de outros setores econômicos que

realizam atividades internas de TI com a finalidade de obter melhorias nos processos internos

(SOFTEX, 2012).

O presente artigo tem como objetivo principal descrever o cenário atual de uma empresa

NIBSS, situada na cidade de Joinville, Santa Catarina, e avaliar a utilização de scrum na área de TI.

Os objetivos específicos deste projeto englobam desenvolver uma ferramenta de controle de

solicitações, para melhorar o processo das entregas e ter um controle das atividades realizadas e

propor a utilização do framework scrum para maximizar o ROI (Retorno de Investimento) de

acordo com as metas da empresa. Para o controle de sprint e product backlog utilizados no scrum,

será desenvolvido um módulo integrado com o sistema de solicitações. Também será

disponibilizado um portal web, contendo indicadores gráficos para acompanhamento das

solicitações e manter a transparência do andamento das atividades.

Na primeira seção é apresentada uma introdução dos temas que serão abordados no artigo. Na

segunda seção é abordada uma introdução à engenharia de software e na terceira seção são

elencados os conceitos e a fundamentação teórica sobre metodologias ágeis com foco em scrum. Na

seção quatro é descrito como era o modelo da área de TI da empresa e na quinta seção é

apresentado o sistema desenvolvido para controle de solicitações e a proposta de utilizar o scrum

para melhorar o processo de entregas e resultados alcançados. A sexta e última seção apresenta as

conclusões do artigo.

2 ENGENHARIA DE SOFTWARE

Segundo IEEE (1990), a engenharia de software pode ser definida como a aplicação de uma

abordagem sistemática, quantificável e disciplinada para produzir sistemas de qualidade. Um dos

objetivos é reduzir os riscos de insucesso através da utilização de práticas e modelos bem aceitos

nas mais diversas áreas da computação.

Através da engenharia de software, surgiram diversas abordagens para tentar resolver e

controlar as mudanças e riscos de forma inerente dando origem aos modelos universais de processos

de software (PETERS; PEDRYCZ, 2001).

Conforme citado por Osiek (2011), o Standish Group, grupo responsável por coletar

informações de projetos de desenvolvimento de software e ambientes de TI, publicou em 2011 um

relatório relacionado a projetos de software no qual se registrou um percentual de 37% de sucesso, a

maior taxa desde 1994. A utilização de metodologias ágeis e o investimento em modernização de TI

estão entre as razões para esse aumento. Entre os fatores de insucesso podem ser citadas,

estimativas imprecisas de prazos, baixa comunicação, falta de comprometimento, compreensão

incorreta e baixa qualidade.

3 METODOLOGIAS ÁGEIS

Diferentemente dos modelos tradicionais de processos de software (e.g., cascata, espiral), os

métodos ágeis são formados por um conjunto de técnicas e práticas que tornam o desenvolvimento

de produtos mais iterativo, com a participação direta do cliente e a realização de entregas

incrementais. Isso permite oferecer um ambiente mais dinâmico e transparente, reduzir custos e

responder mais rapidamente as mudanças (MOREIRA; LESTER; HOLZNER, 2010).

Em 2001, quando foi realizada a publicação do manifesto ágil, foram definidos os valores que

geraram os princípios fundamentais utilizados na definição de ágil. Entre os princípios, podem ser

citados (ibidem):

A maior prioridade é a satisfação do cliente, entregando software cedo e com

frequência, com o objetivo de agregar o maior valor de negócio;

Mudanças no mundo real são inevitáveis e são sempre bem vindas. Mesmo que

cheguem após iniciar o desenvolvimento do software, deve-se enfatizar e trabalhar

pensando que elas podem ser introduzidas a qualquer momento;

Desenvolver projetos em torno de indivíduos motivados e enfatizar a comunicação

direta entre os envolvidos, ao invés de utilizar ferramentas e processos mais

burocráticos; e

Produto funcionando é a medida primária de progresso e tarefas devem ser quebradas

até que se atinja um nível gerenciável e modular.

Em pesquisa realizada pelo Standish Group no ano de 2011, modelos ágeis representam três

vezes mais sucesso se comparados ao modelo tradicional em cascata, além de consumir menos

tempo e recurso (COHN, 2012).

Para obter maior sucesso e usufruir dos benefícios dos métodos ágeis, é necessário verificar se

os princípios são adequados e possíveis de serem aplicados no ambiente de trabalho. Resultados

ágeis dependem de equipes pequenas e próximas para facilitar a interação e comunicação entre os

envolvidos (MOREIRA; LESTER; HOLZNER, 2010).

3.1 Scrum

Scrum pode ser definido como um framework estrutural utilizado para gerenciar o

desenvolvimento de produtos, no qual é possível se utilizar de técnicas e processos de acordo com

as estratégias específicas desejadas, empregando uma abordagem iterativa e incremental focada em

equipes multidisciplinares (SCHWABER & SUTHERLAND, 2011).

O scrum possui a fundamentação originada das teorias empíricas de controle de processo e é

formado por três pilares de apoio (SCHWABER & SUTHERLAND, 2011):

Transparência: Tornar visíveis aspectos significativos do processo aos responsáveis e

permitir que compartilhem de um mesmo entendimento através de um padrão comum;

Inspeção: Deve-se realizar com frequência a verificação dos artefatos do scrum, bem

como o progresso dos objetivos e detectar variações indesejáveis; e

Adaptação: Quando for detectado que um ou mais aspectos do processo foram

desviados para fora dos limites, devem ser realizados ajustes o mais rápido possível

para minimizar estes desvios. No scrum existem quatro oportunidades formais para

inspeção e adaptação: reunião de planejamento, reunião diária, reunião de revisão e

retrospectiva de sprint.

Time scrum

No scrum, a execução das atividades é determinada de acordo com os papéis dos envolvidos,

que devem estar comprometidos com os objetivos. Ao definir os times (i.e. equipe scrum), os

membros devem ter autonomia para decidir executar o trabalho da melhor forma possível e assim

obter maior flexibilidade e produtividade. Cada membro da equipe possui um papel definido. Entre

os papéis para cada membro da equipe estão (SCHWABER & SUTHERLAND, 2011):

Product owner

Ou dono do produto, tem sólidos conhecimentos a respeito das necessidades e é responsável

por maximizar o retorno de investimento e garantir que a equipe agregue valor ao negócio. Sua

responsabilidade estende-se em definir os itens que fazem parte do product backlog para garantir

que a equipe de desenvolvimento entenda as necessidades e possa trabalhar de forma a alcançar os

objetivos. Deve estar presente sempre que possível para esclarecer eventuais dúvidas da equipe de

desenvolvimento (MOREIRA; LESTER; HOLZNER, 2010).

Scrum Master

É responsabilidade do scrum master ou líder do time scrum, implementar os métodos, valores e

práticas do scrum e fazer com que sejam entendidos e aplicados tanto pela equipe de

desenvolvimento quanto pelo product owner. Também é responsável por motivar a equipe a se

auto-organizar, remover impedimentos que comprometam a entrega, realizar o acompanhamento e

ser uma pessoa colaborativa, responsável, comprometida e influente (ibidem).

Equipe Desenvolvimento

É formada pelos profissionais responsáveis por realizar as entregas ou versões funcionais ao

final de cada sprint. Normalmente, equipes scrum são formadas por até doze pessoas e todos devem

estar comprometidos com o sucesso do projeto. A equipe deve ser pequena o suficiente para se

manter ágil e grande o suficiente para completar uma parcela significativa do trabalho (ibidem).

Product Backlog

Um dos artefatos gerados no scrum é o product backlog, uma lista ordenada e priorizada pelo

product owner, contendo informações suficientes para as atividades serem estimadas e permitir a

uma equipe scrum, controlar o que deve ser feito. Histórias de usuários, melhorias, correções e

tarefas fazem parte do product backlog. A prioridade pode ser definida de acordo com os atributos,

como por exemplo, valor, risco e necessidade. Itens de maior prioridade devem ser listados no topo

e devem ser mais detalhados do que itens com menor prioridade (SCHWABER & SUTHERLAND,

2011).

Sprint

Um dos eventos mais importantes no scrum são os sprints, pois através deles são determinadas

as histórias que serão executadas pela equipe de desenvolvimento. Possuem um tamanho pré-

definido, normalmente entre uma e quatro semanas e ao final devem gerar uma versão incremental,

potencialmente utilizável do produto (KNIBERG, 2007).

Sprints possuem um objetivo, escopo e prazo definido, portanto podem ser comparados a um

projeto e permitem previsibilidade para garantir a inspeção e adaptação do progresso em direção à

meta definida (ibidem).

O planejamento é sempre feito no início de um sprint e envolve tanto a equipe quanto o

product owner. As histórias são estimadas pela equipe até que se atinja a duração do sprint.

Somente deve ser incluído o que for possível de ser entregue, respeitando-se os prazos estabelecidos

de acordo com a duração do sprint (ibidem).

Após a definição, não devem ser incluídos novos itens, porém pode-se deixar um intervalo de

tempo livre para correção de bugs e urgências ou até mesmo uma lista de itens desejados para serem

incluídos ao final, caso haja tempo disponível (ibidem).

Sprints curtos tornam entregas mais ágeis e melhoram o feedback, sprints longos possuem mais

tempo para executar as atividades, garantir a entrega e se recuperar de possíveis imprevistos. Sprints

podem ser cancelados antes do término previsto quando as metas não puderem ser alcançadas,

ocorrerem mudanças nas prioridades ou seu objetivo se tornar obsoleto (SCHWABER &

SUTHERLAND, 2011).

Um product backlog nunca está completo e deve ser atualizado constantemente incluindo,

removendo ou repriorizando itens para refletir as mudanças, devido a suas características dinâmicas.

Ciclo de vida

As iterações do scrum (figura 2) iniciam-se com uma reunião de planejamento de sprint, que

envolve o scrum master, o product owner e a equipe responsável por executar os itens selecionados

para o sprint backlog. O product owner deve estar presente, pois é ele quem define os objetivos que

devem ser alcançados, esclarece eventuais dúvidas para a equipe e define o que deve ser entregue.

Figura 2 – Ciclo de vida do Scrum

Fonte: Adaptado de MARCIEL (2009)

A equipe é responsável por estimar as atividades que serão executadas e discutir as dúvidas

existentes. O scrum master atua como um facilitador da reunião e outras pessoas podem participar

da reunião desde que contribuam de alguma forma. (MOREIRA; LESTER; HOLZNER, 2010):

Realizada a definição dos itens do sprint backlog, a equipe inicia a execução das atividades.

Diariamente devem ser realizadas reuniões de aproximadamente quinze minutos entre a equipe e o

scrum master, para identificar e remover possíveis obstáculos, manter o foco da equipe e atualizar o

progresso de execução das tarefas do sprint backlog. Através da comunicação, os membros da

equipe podem colaborar para atingir o objetivo da melhor forma possível e aumentar a qualidade

das entregas (SCHWABER & SUTHERLAND, 2011).

A equipe realiza o acompanhamento do progresso através de gráficos de burndown que exibem

informações para avaliar se os objetivos serão alcançados no prazo definido e verificar a velocidade

da equipe. A comparação é feita entre as estimativas feitas no início do sprint e as atividades

concluídas.

Ao finalizar um sprint, deve ser realizada uma reunião de revisão, cujo objetivo é identificar o

que ficou pronto, identificar os problemas ocorridos durante o sprint e como eles foram resolvidos.

O resultado dessa reunião é um product backlog revisado com as possíveis atividades que serão

executadas no próximo sprint (SCHWABER & SUTHERLAND, 2011).

Como etapa final, a equipe deve fazer uma reunião de retrospectiva para analisar como está a

relação entre os envolvidos, processos e ferramenta, verificar pontos que devem ser melhorados e

discutir melhorias que poderiam ser feitas no próximo sprint.

4 MODELO DA ÁREA DE TI DO ESTUDO DE CASO

O modelo da área de TI deste estudo de caso é dividido em equipes formadas por analistas de

negócio e desenvolvedores, para atender as demandas das áreas de negócio (e.g., controladoria,

comercial, manufatura) que prestam suporte e atendimento às solicitações dos usuários.

As demandas mantidas internamente são divididas entre customizações para o ERP (Enterprise

Resource Planning – Sistemas para Planejamento de Recursos Corporativos) e sistemas legados.

4.1 Contextualizações do problema

Tanto as solicitações quanto os projetos não possuem um controle centralizado das

informações referentes às demandas existentes para as equipes de TI. Quando se trata de projetos, o

controle é realizado pelo gerente responsável que gerencia e transforma as necessidades em tarefas,

para que elas possam ser executadas pela equipe de desenvolvimento.

Na Figura 3, encontra-se o procedimento comum existente para executar as solicitações.

Inicialmente as demandas são enviadas pelos solicitantes por email, o analista de TI responsável

pela área de negócio avalia se a solicitação é pertinente e encaminha para a equipe responsável por

executar a tarefa. Dependendo da complexidade, os analistas realizam especificações funcionais e

técnicas, detalhando as atividades que devem ser executadas pelos desenvolvedores.

Figura 3 – Processo atual de solicitações para a área de TI

De forma geral, é possível avaliar que não existe um controle efetivo de prazos para iniciar e

terminar as solicitações. O objetivo desse projeto está relacionado a melhorar a gestão e o processo

das entregas, torná-las mais frequentes e reportar os resultados a gerência.

5 FERRAMENTAS DESENVOLVIDAS PARA AVALIAÇÃO DO ESTUDO DE CASO

Esta seção descreve as ferramentas e atividades desenvolvidas durante o projeto, as tecnologias

utilizadas e por fim a proposta de melhorar o processo de entregas utilizando scrum.

5.1 Ferramenta para controle de solicitações

A ferramenta (Figura 4), desenvolvida em Oracle forms para ser executada diretamente no ERP

Oracle E-Business Suite, permite cadastrar as solicitações e controlar as atividades dos

desenvolvedores sem focar no micro gerenciamento.

Figura 4 – Tela para cadastro de solicitações

Usuário encaminha solicitação para TI

Analista avalia solicitação

Encaminha especificação para

equipe de desenvolvimento

Entregas são feitas de acordo com a

prioridade e urgência

5.2 Portal web de indicadores

Para facilitar a análise e interpretação dos dados, foram criados gráficos disponibilizados

através de um portal web na intranet da empresa. O portal foi desenvolvido utilizando a linguagem

PHP (Hipertext PreProcessor) e o framework MVC (Model View Controller – Modelo Visão e

Controle) Code Igniter, que permite separar os componentes em camada e desenvolver as

funcionalidades de forma modular.

Os gráficos foram feitos utilizando-se a API (Application Programming Interface – Interface de

Programação de Aplicativos) escrita em Javascript e disponibilizada pelo Google, denominada

Google Chart Tools, que permite criar diversos tipos de gráficos de forma bastante simplificada.

Entre os indicadores criados estão o gráfico por categoria sintético (e.g., melhorias, correções,

novos sistemas), atividades em aberto por área de TI e percentual de atividades concluídas no prazo.

5.3 Adaptação do framework scrum para o estudo de caso

Como etapa final, foi proposta a utilização do framework scrum com o objetivo de ter uma

melhoria no processo e tornar as entregas mais frequentes, maximizando o retorno para as áreas de

negócio.

Juntamente com o sistema de controle de solicitações, foi desenvolvido um módulo para manter

o product backlog, realizar o controle de sprints e acompanhar os sprints através de gráficos de

burndown.

Tanto os usuários chave quanto os analistas de negócio são candidatos a assumir o papel de

product owner, por serem as pessoas responsáveis por solicitar as necessidades para atender as

áreas de negócio. Ao realizar o cadastro de um product owner no sistema, devem ser associadas as

áreas de negócio, ou seja o product backlog será mantido por área de negócio.

Quando a solicitação for realizada por um usuário chave da área de negócio, somente as

informações básicas da atividade serão exibidas para preenchimento, as demais informações

utilizadas para gerenciamento pela TI serão preenchidas posteriormente pelos analistas ou durante a

realização do planejamento do sprint.

As estimativas serão feitas em horas e a prioridade ficou definida por um número, pois muitas

das solicitações sempre eram cadastradas como urgentes, dificultando visualizar qual era mais

importante.

A equipe de desenvolvimento responsável por executar as solicitações é formada por analistas e

desenvolvedores da própria empresa e de empresas terceirizadas. Os coordenadores e analistas de

TI são os candidatos a serem os scrum master dependendo da equipe em questão e atuam como

facilitadores para tornar o scrum aplicável e remover impedimentos da equipe.

A duração inicial para um sprint é de uma semana. Ao cadastrar um sprint são informados o

objetivo, data para início e término e são associados o product owner, scrum master e membros da

equipe responsáveis pelo desenvolvimento. Durante o planejamento do sprint, ficou decidido que os

envolvidos deveriam estar presentes. Nessa etapa, são realizadas as estimativas e escolhidas as

solicitações que devem ser entregues no prazo do sprint. Uma solicitação ficou definida como

pronta, quando estiver concluída, testada pelo product owner e liberada em produção. Para manter a

transparência, o acompanhamento do sprint pode ser realizado por todos os envolvidos no sprint,

através dos gráficos de burndown.

As reuniões diárias foram definidas para serem feitas na parte da manhã e de forma rápida, com

tempo máximo de vinte minutos. As retrospectivas e revisões de sprint foram estipuladas para

serem feitas no último dia do sprint, com tempo máximo de uma hora.

5.4 Resultados obtidos

Foram coletados dados das solicitações cadastradas no período de aproximadamente um ano.

Analisando esses dados, é possível observar na figura 5 que em média 30% das atividades eram

entregues dentro do prazo previsto.

Figura 5 – Solicitações concluídas no prazo previsto

Ao avaliar a utilização do scrum, foi possível verificar uma melhora na eficiência quanto aos

apontamentos de atividades e prazos, já que as solicitações começaram a ter data de previsão para a

entrega. Como apenas alguns sprints foram feitos, não é possível afirmar que a eficiência melhorou

totalmente, mas no gráfico da figura 5, percebe-se um ganho significativo quanto a entregas feitas

no prazo previsto e ao melhor gerenciamento das solicitações pelas equipes de desenvolvimento.

Com a ferramenta de controle de solicitações e os indicadores, foi possível analisar a natureza

das solicitações, quais áreas de negócio possuem mais solicitações e facilitar a comunicação com as

áreas dos usuários sobre as demandas existentes para a TI. Entre os resultados, destacam-se a

possibilidade de planejar semanalmente o atendimento das solicitações, melhorar o

acompanhamento dos desenvolvedores, além de melhor comprovação das atividades executadas

pelas equipes.

O gráfico da figura 6 permite avaliar que em média 50% das solicitações existentes são

relacionadas a melhorias, 18% são de correções e 25% estão relacionadas à extração de

informações. As demais são referentes ao desenvolvimento de novos sistemas e infraestrutura.

Figura 6 – Total de atividades cadastradas por categoria

Foi solicitado as equipes responsáveis por realizar os sprints de avaliação, responderem um

questionário (quadro 1) com o objetivo de avaliar o comprometimento dos envolvidos e comprovar

algumas das melhorias propostas pelo scrum.

A primeira pergunta foi realizada para verificar o conhecimento dos envolvidos sobre métodos

ágeis antes de realizar o projeto. A segunda pergunta teve o objetivo de verificar se as equipes

estavam interessadas em realizar as entregas de acordo com prazos definidos, para melhor

satisfação dos usuários. A terceira pergunta objetivou avaliar a importância dos stakeholders

(product owner) para definir as necessidades e assegurar que a interação entre os envolvidos,

proposta pelo scrum, iria auxiliar em melhor compreensão das necessidades. A quarta pergunta teve

o objetivo de comprovar que as atividades não estavam sendo totalmente estimadas, que por sua vez

afetavam os prazos de entrega. Já a quinta pergunta, serviu para verificar o comprometimento dos

envolvidos em realizar a gestão das solicitações na ferramenta desenvolvida. Por fim, a última

pergunta teve o objetivo de avaliar a motivação das equipes em continuar utilizando o scrum após

realizar os sprints de avaliação.

Quadro 1 – Tabulação das respostas do questionário após realizar sprints de avaliação

Item a responder Sim Não Às vezes

Conhecimento de métodos ágeis antes

deste projeto? 3 participantes 4 participantes Nenhum

É importante controlar solicitações e

definir prazos para entrega? 7 participantes Nenhum Nenhum

É fundamental a participação do product

owner para entender as necessidades? 7 participantes Nenhum Nenhum

Ao cadastrar uma nova solicitação realiza-

se a estimativa dessa solicitação? 2 participantes 1 participante 4 participantes

Você registra todas as solicitações no

sistema de solicitações? Nenhum 1 participante 6 participantes

Você se sente motivado em utilizar o

scrum para melhorar a gestão e controle

das solicitações? 3 participantes 4 participantes Nenhum

De acordo com as respostas do questionário no quadro 1, foi possível avaliar que poucos

envolvidos tinham conhecimento sobre metodologias ágeis, porém alegaram a importância em

realizar o controle dos prazos de entrega e a participação do product owner para definir as

necessidades. Conforme as informações apresentadas no gráfico da figura 5, as entregas fora do

prazo foram originadas principalmente pela falta de estimativas e devido ao baixo

comprometimento em realizar o controle das solicitações. Por fim, apenas alguns dos membros das

equipes se mostraram motivados em utilizar o scrum, apesar do apoio dos coordenadores e gerentes

de projetos.

6 CONCLUSÃO

Esse trabalho teve como objetivo favorecer a melhoria do processo de gestão de solicitações na

área de TI em uma empresa situada em Joinville, Santa Catarina, através do desenvolvimento e

aplicação de uma ferramenta e a utilização do scrum como metodologia ágil, para melhorar o

comprometimento das equipes com as entregas.

De acordo com os dados coletados e exibidos na figura 5, foi possível avaliar que em média

70% das solicitações não eram entregues no prazo. Isso permite fazer uma analogia com as

pesquisas feitas na área da engenharia de software e demonstrar que elas são condizentes

principalmente pela falta de estimativas e comprometimento dos envolvidos. Para mudar esse

quadro, foi proposta a adoção do scrum com a intenção de realizar uma melhoria contínua no

processo e assim tornar as entregas mais frequentes.

Por meio da figura 6, foi possível identificar que muitas das solicitações existentes são

relacionadas à extração de informações das bases de dados. Como a empresa possui uma ferramenta

de BI (Business Intelligence) disponível para algumas áreas de negócio, sugeriu-se aos

coordenadores que avaliassem a possibilidade de utilizar o BI para extração de informações e assim

reduzir o número de solicitações relacionadas a este tipo de atividade.

Os dados coletados no quadro 1 permitem demonstrar que algumas das práticas existentes no

scrum como, por exemplo, a participação direta do product owner, é importante para melhorar a

compreensão das necessidades e a importância em definir as entregas para aumentar a satisfação de

todos os envolvidos.

Recentemente, com uma mudança na área de TI, grande parte dos profissionais de TI foi

deslocada para um novo projeto. Devido a essas mudanças, o número de analistas e coordenadores

que auxiliariam a adoção do scrum reduziu-se consideravelmente, o que dificultou o gerenciamento

das equipes e a realização de sprints para a coleta de mais dados.

Avaliando a situação em que esse projeto se encontra, é possível concluir que apesar de difícil

adoção, a aplicação de scrum em empresas NIBSS é factível de ser utilizada. As equipes devem ser

motivadas e cobradas a realizarem o controle das atividades para que todos possam usufruir dos

benefícios propostos pelo scrum. Porém, a adoção e institucionalização devem ser feitas de forma

incremental para que o scrum seja aceito pelas equipes, melhorando o comprometimento, a

qualidade e a satisfação de todos os envolvidos.

Para permitir uma melhoria continua na ferramenta desenvolvida e no processo de controle das

solicitações, sugere-se utilizar alguma métrica para melhorar as estimativas das atividades (e.g.,

planing poker, pontos por história), criar rotinas para envio de notificação de informações por

email, como por exemplo, atividades pendentes em sprints, atividades concluídas ou atividades não

entregues no prazo e a criação de relatórios de produtividade por equipes e relatórios gerenciais.

REFERÊNCIAS

AGILE ALLIANCE. The Agile Manifesto. Disponível em: <http://www.agilealliance.org/the-

alliance/the-agile-manifesto>. Acesso em: 22 jan. 2013.

COHN, Mike. Agile Succeeds Three Times More Often Than Waterfall. Disponível em:

<http://www.mountaingoatsoftware.com/blog/agile-succeeds-three-times-more-often-than-waterfall>.

Acesso em: 24 jan. 2012.

IEEE, Standard Glossary of Software Engineering Terminology. IEEE Std.610.12-1990, 1990,

p.67. Disponível em: <http://www.idi.ntnu.no/grupper/su/publ/ese/ieee-se-glossary-610.12-

1990.pdf>. Acesso em 22 jan. 2013.

MARCIEL. Scrum. Disponível em: <http://blog.marciel.org/?p=66>. Acesso em: 28 jan. 2013.

MOREIRA, M.E.; LESTER M.; HOLZNER S. Agile for Dummies. Indianapolis: Wiley

Publishing Inc., 2010.

OSIEK A. B. Sucesso de projetos. Disponível em:

<http://blog.mhavila.com.br/2011/06/18/sucesso-de-projetos-atualizado>. Acesso em: 24 jan. 2013.

PETERS, J. F.; PEDRYCZ W. Engenharia de Software: Teoria e Prática. 2. ed. Rio de Janeiro:

Campus, 2001.

PFLEEGER, S. L. Engenharia de Software: Teoria e Pratica. São Paulo: Prentice Hall, 2004.

KNIBERG, Henrik. Scrum e XP direto das Trincheiras: Como nós fazemos Scrum. InfoQ.com:

2007. Disponível em: <http://www.infoq.com/resource/minibooks/scrum-xp-from-the-

trenches/pt/pdf/ScrumeXPDiretodasTrincheiras.pdf>. Acesso em: 10 set. 2012.

SCHWABER Ken.;SUTHERLAND Jeff. Guia do Scrum. Disponível em:

<http://scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum%20Guide%20-

%20Portuguese%20BR.pdf>. Acesso em: 21 jan. 2013.

SOFTEX. Observatório Softex. Disponível em:

<http://www.softex.br/observatoriosoftex/_home/default.asp>. Acesso em: 25 jan. 2013.

DEVELOPMENT OF A REQUEST CONTROL TOOL AND USING SCRUM IN A

CORPORATE ENVIRONMENT: CASE STUDY

Abstract: Success on software engineering projects often depends of using best practices,

according to the particular characteristics of the project and the technical knowledge of those

responsible for ensuring its success. Agile methodologies are becoming a great ally in software

projects, where the main objective is make deliveries faster and ensure customer fulfillment. This

article aims to develop a tool to improve the management of IT requests and evaluate the use of

scrum in a corporate environment to ensure return on investment in accordance with business

needs. With the request control tool it was possible to report deliveries and allow coordinators to

monitor the progress of projects and activities. The successful use depends on the commitment and

support of those involved, the adoption is being done gradually, a greater commitment is seen of

staff to increase quality of service. Despite the benefits offered by scrum, the time required for its

institutionalization should be considered and thus increase the satisfaction of those involved.

Keywords: Scrum. Agile Software Development. Software Management.