Development and applying a request control tool and the impact evaluation using SCRUM in a corporate environment: case study

Transcrição

1 Desenvolvimento e aplicação de uma ferramenta para controle de solicitações e avaliação de impacto da utilização de SCRUM em empresa NIBSS: Estudo de caso Development and applying a request control tool and the impact evaluation using SCRUM in a corporate environment: case study Haissam Yebahi (hyebahi@gmail.com, Centro Universitário Tupy - UNISOCIESC, Santa Catarina, Brasil) R. Guilherme Berner, 281, Santo Antonio, , Joinville, SC, Brasil Luiz Camargo (camargho@gmail.com, Centro Universitário Tupy - UNISOCIESC, Santa Catarina, Brasil) 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. Abstract: Success on software engineering projects often depends on 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, whose main objective is deliver 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 adoption of scrum has been done gradually, and the successful use of it depends on the commitment and support of those involved. It has already been realized a greater commitment 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. Recebido 22/10/2013; Aceito 23/05/

2 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 inevitáveis. Muitas vezes, projetos na área da engenharia de software sofrem atrasos e custam mais do que o esperado, devido principalmente à falta de controle e à ausência de um processo adequado às particularidades específicas de cada projeto (SOMMERVILLE, 2011). 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 (LINDSTROM & JEFFRIES, 2003), (CONBOY & FITZGERALD, 2010). 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), (TELES, 2005), (SULAIMAN; BARTON; BLACKBURN, 2006) (DIAS & OLIVEIRA, 2009). 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 Recebido 22/10/2013; Aceito 23/05/

3 outros setores econômicos que realizam atividades internas de TI com a finalidade de obter melhorias nos processos internos (SOFTEX, 2013). 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. Na seção quatro são aborados os principais conceitos relacionados ao scrum. Na seção cinco é descrito como era o modelo da área de TI da empresa e na sexta 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 sétima e última seção apresenta as conclusões do artigo. 2. Engenharia de Software A engenharia de software é uma disciplina da engenharia responsável por tratar todos os aspectos envolvidos no processo de desenvolvimento de software, através de uma abordagem sistemática e organizada, para oferecer software com alta qualidade e custo efetivo (SOMMERVILLE, 2011). O desenvolvimento de software envolve diversas atividades sendo quatro delas as principais: a especificação, o desenvolvimento, a validação e a evolução do software. A organização de forma estruturada das atividades relacinadas ao desenvolvimento de software formam o conceito conhecido como processos de software (SOMMERVILLE, 2011). De acordo com dados coletados e publicados no Chaos Manifesto em 2013, pelo Standish Group, registrou-se um percentual de 39% de sucesso para os projetos de software Recebido 22/10/2013; Aceito 23/05/

4 em ambientes de TI, a maior taxa desde A utilização de metodologias ágeis, envolvimento dos usuários, suporte dos patrocinadores 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 e compreensão incorreta das necessidades (STANDISH GROUP, 2014). 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), (GROSSMAN, et. al., 2004), (RISING & JANOFF, 2000). 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 (MOREIRA; LESTER; HOLZNER, 2010): 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), (PAASIVARA & DURASIEWICZ 2008). 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 Recebido 22/10/2013; Aceito 23/05/

5 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). 4 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), (SOARES, 2005). 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), (KOVALEVSKI, 2010): 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. 4.1 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 (KOVALEVSKI, 2010), (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 Recebido 22/10/2013; Aceito 23/05/

6 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 (MOREIRA; LESTER; HOLZNER, 2010); Equipe de 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 (MOREIRA; LESTER; HOLZNER, 2010). 4.2 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 (KOVALEVSKI, 2010), (SCHWABER & SUTHERLAND, 2011). 4.3 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). Recebido 22/10/2013; Aceito 23/05/

7 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 (KNIBERG, 2007). 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 (KNIBERG, 2007). 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 (KNIBERG, 2007). 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. 4.4 Ciclo de Vida As iterações do scrum (figura 1) 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. Recebido 22/10/2013; Aceito 23/05/

8 Figura 1 - 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. Recebido 22/10/2013; Aceito 23/05/

9 5. Modelo 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. 5.1 Contextualização 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 2, encontra-se o procedimento comum existente para executar as solicitações. Inicialmente as demandas são enviadas pelos solicitantes por , 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 2 - Processo atual de solicitações para a área de TI Fonte: Os autores (2013) Recebido 22/10/2013; Aceito 23/05/

10 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. 6. 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. 6.1 Ferramenta para Controle de Solicitações A ferramenta (Figura 3), 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 3 - Tela para cadastro de solicitações Fonte: Os autores (2013) 6.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 Recebido 22/10/2013; Aceito 23/05/

11 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. 6.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 Recebido 22/10/2013; Aceito 23/05/

12 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. 6.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 4 que em média 30% das atividades eram entregues dentro do prazo previsto. Figura 4 - Solicitações concluídas no prazo previsto Fonte: Os autores (2013) 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 Recebido 22/10/2013; Aceito 23/05/

13 que a eficiência melhorou totalmente, mas no gráfico da figura 4, 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 5 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 5 - Total de atividades cadastradas por categoria Fonte: Os autores (2013) 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 Recebido 22/10/2013; Aceito 23/05/

14 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 Fonte: Os autores (2013) 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 4, 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. 7. Considerações Finais 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 Recebido 22/10/2013; Aceito 23/05/

15 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 4, 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 5, 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 , 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 Recebido 22/10/2013; Aceito 23/05/

16 equipes e relatórios gerenciais. Referências AGILE ALLIANCE. The Agile Manifesto. Disponível em: < Acesso em: 22 jan CONBOY, K. FITZGERALD, B. Method and Developer Characteristics for Effective Agile Method Tailoring: A Study of XP Expert Opinion. 2010, In. ACM New York, USA n1, v20 p DIAS, T. M. R.; OLIVEIRA, J. L. L. Adoção da Metodologia Extreme Programming para Construção de Software. 2009, In: III SBCARS: Simpósio Brasileiro de Componentes, Arquiteturas e Reutilização de Software, Natal, RN, Brasil. COHN, M. Agile Succeeds Three Times More Often Than Waterfall. 2012, Disponível em: < Acesso em: 24 jan GROSSMAN, F.; BERGIN, J.; LEIP, D.; MERRITT, S.; GOTEL, O. One XP Experience: Introducing Agile (XP) Software Development into a Culture That is Willing but Not Ready. 2004, In CASCON 04 Conference of the Centre for Advanced Studies on Collaborative Research, Ontario, Canada, IBM Press p MARCIEL. Scrum. Disponível em: , Acesso em: 28 jan MOREIRA, M. E.; LESTER, M.; HOLZNER, S. Agile for Dummies. 2010, Indianapolis: Wiley Publishing Inc., KNIBERG, Henrik. Scrum e XP direto das Trincheiras: Como nós fazemos Scrum. InfoQ.com: Disponível em: < Acesso em: 10 set KOVALEVSKI, V. Adaptation of SCRUM methodology to company business processes. 2010, In: 6 th CEE-SECR Central and Eastern Software Engineering Conference European, v2, p LINDSTROM, L.; JEFFRIES, R. Extreme Programming and Agile Software Development Methodologies. 2003, Press LLC, Boca Raton, Florida, USA. IS Management Handbook, 8th Edition. PAASIVARA, M.; DURASIEWICZ, S.; LASSENIUS, C. Distributed Agile Development: Using Scrum in a Large Project. 2008, In: ICGSE, IEEE International Conference on Global Software Engineering, v 4, p RISING, L. JANOFF, N. S. The Scrum software development process for small teams. Journal: IEEE Software, 2000, v 17, p SCHWABER Ken; SUTHERLAND Jeff. Guia do Scrum, Disponível em: < Acesso em: 21 jan SOARES, S. M. Metodologias Ágeis Extreme Programming e Scrum para o Desenvolvimento de Software. UNIPAC Universidade Presidente Antonio Carlos, 2005, Juiz de Fora MG. SOFTEX. Observatório Softex Disponível em: < Acesso em: 25 jan SOMMERVILLE, I. Software Engineering. 9th Edition. England: Pearson Ed., SULAIMAN, T.; BARTON, B.; BLACKBURN, T. AgileEVM - earned value management in Scrum Projects, 2006, In. Agile Conference, Minneapolis, Minnesota, USA, p STANDISH GROUP. Chaos Manifesto. Disponível em: < CHAOSManifesto2013.pdf>. Acesso em 17 mai TELES, V. M. Um Estudo de Caso da Adoção das Práticas e Valores do Extreme Programming. 2005, Dissertação (Mestrado em Informática), IM-NCE/UFRJ, Rio de Janeiro. Recebido 22/10/2013; Aceito 23/05/