DESENVOLVIMENTO E APLICAO DE UMA FERRAMENTA PARA CONTROLE DE SOLICITAES E UTILIZAO DE SCRUM EM EMPRESA NIBSS: ESTUDO DE CASO Haissam Yebahi1,

Luiz Camargo2 Resumo: O sucesso de projetos na rea de engenharia de software depende muitas vezes da aplicao das melhores prticas, de acordo com as caractersticas particulares do projeto e do conhecimento tcnico dos responsveis por garantir seu sucesso. As metodologias geis esto se tornando uma grande aliada em projetos de software, cujo principal objetivo est em realizar as entregas de forma mais rpida e assegurar a satisfao do cliente. O presente artigo tem como objetivo desenvolver uma ferramenta para melhorar a gesto de solicitaes da rea de TI e avaliar a utilizao do scrum em ambiente corporativo para maximizar o retorno de investimento de acordo com as necessidades do negcio. Ao implantar a ferramenta de controle de solicitaes, foi possvel reportar as entregas para a gerncia da TI e permitir aos coordenadores acompanharem o andamento de projetos e atividades executadas. A adoo do scrum est sendo feita gradativamente e o sucesso da utilizao depende do apoio dos envolvidos e j se percebe um maior comprometimento da equipe em aumentar a qualidade do servio prestado. Apesar dos benefcios propostos pelo scrum, deve ser considerado o tempo necessrio para sua institucionalizao e assim aumentar a satisfao dos envolvidos. Palavras-chave: Scrum. Metodologias geis. Processos de software.

INTRODUO

Projetos na rea de TI (Tecnologia da Informao) em ambiente corporativo so normalmente planejados de acordo com a necessidade dos envolvidos, que dependem de informaes gerenciais para organizar e suprir as demandas internas. Mudanas durante o ciclo de vida de um software so quase que inevitveis. O sucesso de projetos na rea de engenharia de software depende muitas vezes da aplicao das melhores prticas, de acordo com as caractersticas particulares do projeto e do conhecimento tcnico dos responsveis pela execuo (PFLEEGER, 2004). As metodologias geis vm se tornando uma grande aliada em projetos de software que no necessitam de controles rgidos de documentao e permitem flexibilidade na execuo das atividades. Um dos principais motivos para tal aceitao se deve ao foco em entregas rpidas e de forma incremental de acordo com as expectativas do cliente, o que torna os resultados visveis em um curto intervalo de tempo. Em 2001, foi publicado o manifesto gil, responsvel por definir os princpios e prticas desta metodologia que mais tarde se tornou a Agile Alliance, uma organizao no lucrativa que promove o desenvolvimento gil (AGILE ALLIANCE, 2012). O scrum fundamentado nas teorias empricas 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 negcio ao cliente (SCHWABER & SUTHERLAND, 2011). No Scrum existe o product backlog, formado pelas solicitaes do cliente, comumente denominado product owner, o qual seria responsvel por definir prioridades e estaria inserido de forma mais transparente nas tomadas de decises de entregas peridicas, denominadas de sprint. Outro papel importante o scrum master, responsvel por garantir que o scrum seja entendido e aplicado, alm de prover suporte para o sucesso do projeto pela equipe de desenvolvimento (KNIBERG, 2007). ______________________ 1 Sociedade Educacional de Santa Catarina SOCIESC. e-mail: hyebahi@gmail.com. 2 Sociedade Educacional de Santa Catarina SOCIESC. e-mail: camargho@gmail.com.

De acordo com o observatrio da SOFTEX, responsvel por realizar pesquisas voltadas ao setor nacional de software e servios de TI, o Brasil constitudo por empresas que formam a chamada IBSS (Indstria Brasileira de Software e Servios de TI), cuja receita provm de atividades relacionadas a TI (e.g., desenvolvimento de software, consultoria, suporte tcnico) e as NIBSS (No-IBSS), formadas por empresas com fonte de renda de outros setores econmicos 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 cenrio atual de uma empresa NIBSS, situada na cidade de Joinville, Santa Catarina, e avaliar a utilizao de scrum na rea de TI. Os objetivos especficos deste projeto englobam desenvolver uma ferramenta de controle de solicitaes, para melhorar o processo das entregas e ter um controle das atividades realizadas e propor a utilizao 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 mdulo integrado com o sistema de solicitaes. Tambm ser disponibilizado um portal web, contendo indicadores grficos para acompanhamento das solicitaes e manter a transparncia do andamento das atividades. Na primeira seo apresentada uma introduo dos temas que sero abordados no artigo. Na segunda seo abordada uma introduo engenharia de software e na terceira seo so elencados os conceitos e a fundamentao terica sobre metodologias geis com foco em scrum. Na seo quatro descrito como era o modelo da rea de TI da empresa e na quinta seo apresentado o sistema desenvolvido para controle de solicitaes e a proposta de utilizar o scrum para melhorar o processo de entregas e resultados alcanados. A sexta e ltima seo apresenta as concluses do artigo. 2 ENGENHARIA DE SOFTWARE

Segundo IEEE (1990), a engenharia de software pode ser definida como a aplicao de uma abordagem sistemtica, quantificvel e disciplinada para produzir sistemas de qualidade. Um dos objetivos reduzir os riscos de insucesso atravs da utilizao de prticas e modelos bem aceitos nas mais diversas reas da computao. Atravs da engenharia de software, surgiram diversas abordagens para tentar resolver e controlar as mudanas 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 responsvel por coletar informaes de projetos de desenvolvimento de software e ambientes de TI, publicou em 2011 um relatrio relacionado a projetos de software no qual se registrou um percentual de 37% de sucesso, a maior taxa desde 1994. A utilizao de metodologias geis e o investimento em modernizao de TI esto entre as razes para esse aumento. Entre os fatores de insucesso podem ser citadas, estimativas imprecisas de prazos, baixa comunicao, falta de comprometimento, compreenso incorreta e baixa qualidade. 3 METODOLOGIAS GEIS

Diferentemente dos modelos tradicionais de processos de software (e.g., cascata, espiral), os mtodos geis so formados por um conjunto de tcnicas e prticas que tornam o desenvolvimento de produtos mais iterativo, com a participao direta do cliente e a realizao de entregas incrementais. Isso permite oferecer um ambiente mais dinmico e transparente, reduzir custos e responder mais rapidamente as mudanas (MOREIRA; LESTER; HOLZNER, 2010). Em 2001, quando foi realizada a publicao do manifesto gil, foram definidos os valores que geraram os princpios fundamentais utilizados na definio de gil. Entre os princpios, podem ser citados (ibidem): A maior prioridade a satisfao do cliente, entregando software cedo e com frequncia, com o objetivo de agregar o maior valor de negcio;

Mudanas no mundo real so inevitveis e so sempre bem vindas. Mesmo que cheguem aps iniciar o desenvolvimento do software, deve-se enfatizar e trabalhar pensando que elas podem ser introduzidas a qualquer momento; Desenvolver projetos em torno de indivduos motivados e enfatizar a comunicao direta entre os envolvidos, ao invs de utilizar ferramentas e processos mais burocrticos; e Produto funcionando a medida primria de progresso e tarefas devem ser quebradas at que se atinja um nvel gerencivel e modular. Em pesquisa realizada pelo Standish Group no ano de 2011, modelos geis representam trs vezes mais sucesso se comparados ao modelo tradicional em cascata, alm de consumir menos tempo e recurso (COHN, 2012). Para obter maior sucesso e usufruir dos benefcios dos mtodos geis, necessrio verificar se os princpios so adequados e possveis de serem aplicados no ambiente de trabalho. Resultados geis dependem de equipes pequenas e prximas para facilitar a interao e comunicao 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 possvel se utilizar de tcnicas e processos de acordo com as estratgias especficas desejadas, empregando uma abordagem iterativa e incremental focada em equipes multidisciplinares (SCHWABER & SUTHERLAND, 2011). O scrum possui a fundamentao originada das teorias empricas de controle de processo e formado por trs pilares de apoio (SCHWABER & SUTHERLAND, 2011): Transparncia: Tornar visveis aspectos significativos do processo aos responsveis e permitir que compartilhem de um mesmo entendimento atravs de um padro comum; Inspeo: Deve-se realizar com frequncia a verificao dos artefatos do scrum, bem como o progresso dos objetivos e detectar variaes indesejveis; e Adaptao: Quando for detectado que um ou mais aspectos do processo foram desviados para fora dos limites, devem ser realizados ajustes o mais rpido possvel para minimizar estes desvios. No scrum existem quatro oportunidades formais para inspeo e adaptao: reunio de planejamento, reunio diria, reunio de reviso e retrospectiva de sprint. Time scrum No scrum, a execuo das atividades determinada de acordo com os papis 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 possvel e assim obter maior flexibilidade e produtividade. Cada membro da equipe possui um papel definido. Entre os papis para cada membro da equipe esto (SCHWABER & SUTHERLAND, 2011): Product owner Ou dono do produto, tem slidos conhecimentos a respeito das necessidades e responsvel por maximizar o retorno de investimento e garantir que a equipe agregue valor ao negcio. 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 alcanar os objetivos. Deve estar presente sempre que possvel para esclarecer eventuais dvidas da equipe de desenvolvimento (MOREIRA; LESTER; HOLZNER, 2010). Scrum Master

 responsabilidade do scrum master ou lder do time scrum, implementar os mtodos, valores e prticas do scrum e fazer com que sejam entendidos e aplicados tanto pela equipe de desenvolvimento quanto pelo product owner. Tambm responsvel por motivar a equipe a se auto-organizar, remover impedimentos que comprometam a entrega, realizar o acompanhamento e ser uma pessoa colaborativa, responsvel, comprometida e influente (ibidem). Equipe Desenvolvimento formada pelos profissionais responsveis por realizar as entregas ou verses funcionais ao final de cada sprint. Normalmente, equipes scrum so 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 informaes suficientes para as atividades serem estimadas e permitir a uma equipe scrum, controlar o que deve ser feito. Histrias de usurios, melhorias, correes 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 so os sprints, pois atravs deles so determinadas as histrias que sero executadas pela equipe de desenvolvimento. Possuem um tamanho prdefinido, normalmente entre uma e quatro semanas e ao final devem gerar uma verso incremental, potencialmente utilizvel 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 inspeo e adaptao do progresso em direo meta definida (ibidem). O planejamento sempre feito no incio de um sprint e envolve tanto a equipe quanto o product owner. As histrias so estimadas pela equipe at que se atinja a durao do sprint. Somente deve ser includo o que for possvel de ser entregue, respeitando-se os prazos estabelecidos de acordo com a durao do sprint (ibidem). Aps a definio, no devem ser includos novos itens, porm pode-se deixar um intervalo de tempo livre para correo de bugs e urgncias ou at mesmo uma lista de itens desejados para serem includos ao final, caso haja tempo disponvel (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 possveis imprevistos. Sprints podem ser cancelados antes do trmino previsto quando as metas no puderem ser alcanadas, ocorrerem mudanas 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 mudanas, devido a suas caractersticas dinmicas. Ciclo de vida As iteraes do scrum (figura 2) iniciam-se com uma reunio de planejamento de sprint, que envolve o scrum master, o product owner e a equipe responsvel por executar os itens selecionados para o sprint backlog. O product owner deve estar presente, pois ele quem define os objetivos que devem ser alcanados, esclarece eventuais dvidas para a equipe e define o que deve ser entregue.

Figura 2 Ciclo de vida do Scrum

Fonte: Adaptado de MARCIEL (2009) A equipe responsvel por estimar as atividades que sero executadas e discutir as dvidas existentes. O scrum master atua como um facilitador da reunio e outras pessoas podem participar da reunio desde que contribuam de alguma forma. (MOREIRA; LESTER; HOLZNER, 2010): Realizada a definio dos itens do sprint backlog, a equipe inicia a execuo das atividades. Diariamente devem ser realizadas reunies de aproximadamente quinze minutos entre a equipe e o scrum master, para identificar e remover possveis obstculos, manter o foco da equipe e atualizar o progresso de execuo das tarefas do sprint backlog. Atravs da comunicao, os membros da equipe podem colaborar para atingir o objetivo da melhor forma possvel e aumentar a qualidade das entregas (SCHWABER & SUTHERLAND, 2011). A equipe realiza o acompanhamento do progresso atravs de grficos de burndown que exibem informaes para avaliar se os objetivos sero alcanados no prazo definido e verificar a velocidade da equipe. A comparao feita entre as estimativas feitas no incio do sprint e as atividades concludas. Ao finalizar um sprint, deve ser realizada uma reunio de reviso, cujo objetivo identificar o que ficou pronto, identificar os problemas ocorridos durante o sprint e como eles foram resolvidos. O resultado dessa reunio um product backlog revisado com as possveis atividades que sero executadas no prximo sprint (SCHWABER & SUTHERLAND, 2011). Como etapa final, a equipe deve fazer uma reunio de retrospectiva para analisar como est a relao entre os envolvidos, processos e ferramenta, verificar pontos que devem ser melhorados e discutir melhorias que poderiam ser feitas no prximo 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 negcio e desenvolvedores, para atender as demandas das reas de negcio (e.g., controladoria, comercial, manufatura) que prestam suporte e atendimento s solicitaes dos usurios. As demandas mantidas internamente so divididas entre customizaes para o ERP (Enterprise Resource Planning Sistemas para Planejamento de Recursos Corporativos) e sistemas legados. 4.1 Contextualizaes do problema

Tanto as solicitaes quanto os projetos no possuem um controle centralizado das informaes referentes s demandas existentes para as equipes de TI. Quando se trata de projetos, o

controle realizado pelo gerente responsvel 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 solicitaes. Inicialmente as demandas so enviadas pelos solicitantes por email, o analista de TI responsvel pela rea de negcio avalia se a solicitao pertinente e encaminha para a equipe responsvel por executar a tarefa. Dependendo da complexidade, os analistas realizam especificaes funcionais e tcnicas, detalhando as atividades que devem ser executadas pelos desenvolvedores. Figura 3 Processo atual de solicitaes para a rea de TI

Usurio encaminha solicitao para TI

Analista avalia solicitao

Entregas so feitas de acordo com a prioridade e urgncia

Encaminha especificao para equipe de desenvolvimento

De forma geral, possvel avaliar que no existe um controle efetivo de prazos para iniciar e terminar as solicitaes. O objetivo desse projeto est relacionado a melhorar a gesto e o processo das entregas, torn-las mais frequentes e reportar os resultados a gerncia. 5 FERRAMENTAS DESENVOLVIDAS PARA AVALIAO DO ESTUDO DE CASO

Esta seo 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 solicitaes

A ferramenta (Figura 4), desenvolvida em Oracle forms para ser executada diretamente no ERP Oracle E-Business Suite, permite cadastrar as solicitaes e controlar as atividades dos desenvolvedores sem focar no micro gerenciamento. Figura 4 Tela para cadastro de solicitaes

5.2

Portal web de indicadores

Para facilitar a anlise e interpretao dos dados, foram criados grficos disponibilizados atravs 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 Viso e Controle) Code Igniter, que permite separar os componentes em camada e desenvolver as funcionalidades de forma modular. Os grficos foram feitos utilizando-se a API (Application Programming Interface Interface de Programao de Aplicativos) escrita em Javascript e disponibilizada pelo Google, denominada Google Chart Tools, que permite criar diversos tipos de grficos de forma bastante simplificada. Entre os indicadores criados esto o grfico por categoria sinttico (e.g., melhorias, correes, novos sistemas), atividades em aberto por rea de TI e percentual de atividades concludas no prazo. 5.3 Adaptao do framework scrum para o estudo de caso

Como etapa final, foi proposta a utilizao 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 negcio. Juntamente com o sistema de controle de solicitaes, foi desenvolvido um mdulo para manter o product backlog, realizar o controle de sprints e acompanhar os sprints atravs de grficos de burndown. Tanto os usurios chave quanto os analistas de negcio so candidatos a assumir o papel de product owner, por serem as pessoas responsveis por solicitar as necessidades para atender as reas de negcio. Ao realizar o cadastro de um product owner no sistema, devem ser associadas as reas de negcio, ou seja o product backlog ser mantido por rea de negcio. Quando a solicitao for realizada por um usurio chave da rea de negcio, somente as informaes bsicas da atividade sero exibidas para preenchimento, as demais informaes utilizadas para gerenciamento pela TI sero preenchidas posteriormente pelos analistas ou durante a realizao do planejamento do sprint. As estimativas sero feitas em horas e a prioridade ficou definida por um nmero, pois muitas das solicitaes sempre eram cadastradas como urgentes, dificultando visualizar qual era mais importante. A equipe de desenvolvimento responsvel por executar as solicitaes formada por analistas e desenvolvedores da prpria empresa e de empresas terceirizadas. Os coordenadores e analistas de TI so os candidatos a serem os scrum master dependendo da equipe em questo e atuam como facilitadores para tornar o scrum aplicvel e remover impedimentos da equipe. A durao inicial para um sprint de uma semana. Ao cadastrar um sprint so informados o objetivo, data para incio e trmino e so associados o product owner, scrum master e membros da equipe responsveis pelo desenvolvimento. Durante o planejamento do sprint, ficou decidido que os envolvidos deveriam estar presentes. Nessa etapa, so realizadas as estimativas e escolhidas as solicitaes que devem ser entregues no prazo do sprint. Uma solicitao ficou definida como pronta, quando estiver concluda, testada pelo product owner e liberada em produo. Para manter a transparncia, o acompanhamento do sprint pode ser realizado por todos os envolvidos no sprint, atravs dos grficos de burndown. As reunies dirias foram definidas para serem feitas na parte da manh e de forma rpida, com tempo mximo de vinte minutos. As retrospectivas e revises de sprint foram estipuladas para serem feitas no ltimo dia do sprint, com tempo mximo de uma hora. 5.4 Resultados obtidos

Foram coletados dados das solicitaes cadastradas no perodo de aproximadamente um ano. Analisando esses dados, possvel observar na figura 5 que em mdia 30% das atividades eram entregues dentro do prazo previsto.

Figura 5 Solicitaes concludas no prazo previsto

Ao avaliar a utilizao do scrum, foi possvel verificar uma melhora na eficincia quanto aos apontamentos de atividades e prazos, j que as solicitaes comearam a ter data de previso para a entrega. Como apenas alguns sprints foram feitos, no possvel afirmar que a eficincia melhorou totalmente, mas no grfico da figura 5, percebe-se um ganho significativo quanto a entregas feitas no prazo previsto e ao melhor gerenciamento das solicitaes pelas equipes de desenvolvimento. Com a ferramenta de controle de solicitaes e os indicadores, foi possvel analisar a natureza das solicitaes, quais reas de negcio possuem mais solicitaes e facilitar a comunicao com as reas dos usurios sobre as demandas existentes para a TI. Entre os resultados, destacam-se a possibilidade de planejar semanalmente o atendimento das solicitaes, melhorar o acompanhamento dos desenvolvedores, alm de melhor comprovao das atividades executadas pelas equipes. O grfico da figura 6 permite avaliar que em mdia 50% das solicitaes existentes so relacionadas a melhorias, 18% so de correes e 25% esto relacionadas extrao de informaes. As demais so referentes ao desenvolvimento de novos sistemas e infraestrutura. Figura 6 Total de atividades cadastradas por categoria

Foi solicitado as equipes responsveis por realizar os sprints de avaliao, responderem um questionrio (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 mtodos 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 satisfao dos usurios. A terceira pergunta objetivou avaliar a importncia dos stakeholders (product owner) para definir as necessidades e assegurar que a interao entre os envolvidos, proposta pelo scrum, iria auxiliar em melhor compreenso das necessidades. A quarta pergunta teve o objetivo de comprovar que as atividades no 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 gesto das solicitaes na ferramenta desenvolvida. Por fim, a ltima pergunta teve o objetivo de avaliar a motivao das equipes em continuar utilizando o scrum aps realizar os sprints de avaliao. Quadro 1 Tabulao das respostas do questionrio aps realizar sprints de avaliao Item a responder Sim Conhecimento de mtodos geis antes deste projeto? 3 participantes importante controlar solicitaes e definir prazos para entrega? 7 participantes fundamental a participao do product owner para entender as necessidades? 7 participantes Ao cadastrar uma nova solicitao realizase a estimativa dessa solicitao? 2 participantes Voc registra todas as solicitaes no sistema de solicitaes? Nenhum Voc se sente motivado em utilizar o scrum para melhorar a gesto e controle das solicitaes? No s vezes

4 participantes Nenhum Nenhum Nenhum 1 participante 1 participante Nenhum Nenhum 4 participantes 6 participantes

3 participantes

4 participantes Nenhum

De acordo com as respostas do questionrio no quadro 1, foi possvel avaliar que poucos envolvidos tinham conhecimento sobre metodologias geis, porm alegaram a importncia em realizar o controle dos prazos de entrega e a participao do product owner para definir as necessidades. Conforme as informaes apresentadas no grfico 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 solicitaes. 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 CONCLUSO

Esse trabalho teve como objetivo favorecer a melhoria do processo de gesto de solicitaes na rea de TI em uma empresa situada em Joinville, Santa Catarina, atravs do desenvolvimento e aplicao de uma ferramenta e a utilizao 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 possvel avaliar que em mdia 70% das solicitaes no eram entregues no prazo. Isso permite fazer uma analogia com as pesquisas feitas na rea de engenharia de software e demonstrar que elas so condizentes principalmente pela falta de estimativas e comprometimento dos envolvidos. Para mudar esse quadro, foi proposta a adoo do scrum com a inteno de realizar uma melhoria contnua no processo e assim tornar as entregas mais frequentes.

Por meio da figura 6, foi possvel identificar que muitas das solicitaes existentes so relacionadas extrao de informaes das bases de dados. Como a empresa possui uma ferramenta de BI (Business Intelligence) disponvel para algumas reas de negcio, sugeriu-se aos coordenadores que avaliassem a possibilidade de utilizar o BI para extrao de informaes e assim reduzir o nmero de solicitaes relacionadas a este tipo de atividade. Os dados coletados no quadro 1 permitem demonstrar que algumas das prticas existentes no scrum como, por exemplo, a participao direta do product owner, importante para melhorar a compreenso das necessidades e a importncia em definir as entregas para aumentar a satisfao de todos os envolvidos. Recentemente, com uma mudana na rea de TI, grande parte dos profissionais de TI foi deslocada para um novo projeto. Devido a essas mudanas, o nmero de analistas e coordenadores que auxiliariam a adoo do scrum reduziu-se consideravelmente, o que dificultou o gerenciamento das equipes e a realizao de sprints para a coleta de mais dados. Avaliando a situao em que esse projeto se encontra, possvel concluir que apesar de difcil adoo, a aplicao de scrum em empresas NIBSS factvel de ser utilizada. As equipes devem ser motivadas e cobradas a realizarem o controle das atividades para que todos possam usufruir dos benefcios propostos pelo scrum. Porm, a adoo e institucionalizao devem ser feitas de forma incremental para que o scrum seja aceito pelas equipes, melhorando o comprometimento, a qualidade e a satisfao de todos os envolvidos. Para permitir uma melhoria continua na ferramenta desenvolvida e no processo de controle das solicitaes, sugere-se utilizar alguma mtrica para melhorar as estimativas das atividades (e.g., planing poker, pontos por histria), criar rotinas para envio de notificao de informaes por email, como por exemplo, atividades pendentes em sprints, atividades concludas ou atividades no entregues no prazo e a criao de relatrios de produtividade por equipes e relatrios gerenciais. REFERNCIAS AGILE ALLIANCE. The Agile Manifesto. Disponvel em: <http://www.agilealliance.org/thealliance/the-agile-manifesto>. Acesso em: 22 jan. 2013. COHN, Mike. Agile Succeeds Three Times More Often Than Waterfall. Disponvel 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. Disponvel em: <http://www.idi.ntnu.no/grupper/su/publ/ese/ieee-se-glossary-610.121990.pdf>. Acesso em 22 jan. 2013. MARCIEL. Scrum. Disponvel 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. Disponvel 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 Prtica. 2. ed. Rio de Janeiro: Campus, 2001. PFLEEGER, S. L. Engenharia de Software: Teoria e Pratica. So Paulo: Prentice Hall, 2004.

KNIBERG, Henrik. Scrum e XP direto das Trincheiras: Como ns fazemos Scrum. InfoQ.com: 2007. Disponvel em: <http://www.infoq.com/resource/minibooks/scrum-xp-from-thetrenches/pt/pdf/ScrumeXPDiretodasTrincheiras.pdf>. Acesso em: 10 set. 2012. SCHWABER Ken.;SUTHERLAND Jeff. Guia do Scrum. Disponvel <http://scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum%20Guide%20%20Portuguese%20BR.pdf>. Acesso em: 21 jan. 2013. SOFTEX. Observatrio Softex. Disponvel <http://www.softex.br/observatoriosoftex/_home/default.asp>. Acesso em: 25 jan. 2013. em:

em:

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.