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

100 %
0 %
Information about SCRUM: ADOÇÃO DE UM FRAMEWORK ÁGIL NO DESENVOLVIMENTO DE UM SOFTWARE...
Technology

Published on March 10, 2014

Author: KELLYSONSI

Source: slideshare.net

Description

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

Tema: Novas tecnologias e ferramentas para gestão empreendedora. SCRUM: ADOÇÃO DE UM FRAMEWORK ÁGIL NO DESENVOLVIMENTO DE UM SOFTWARE PARA TRABALHO DE CONCLUSÃO DE CURSO GARCIA, Joelber Flávio dos Santos 1. SILVA, Kéllyson Gonçalves da 2. GONÇALVES, Leandro da Costa 3. MELLO JUNIOR, Fernando Corrêa de 4. Resumo: Desenvolver software, assim como qualquer outro produto, consiste em seguir uma série de processos (etapas) de construção para que se obtenha êxito. Esses processos, se tratando de tecnologia da informação, são conhecidos como metodologias ou frameworks, como sugerem alguns autores. Existem metodologias tradicionais e ágeis, essa última vem ganhando cada vez mais destaque em empresas que trabalham com TI. Esse artigo está centrado no uso do framework ágil Scrum e da ferramenta ScrumHalf, que foram utilizados para o desenvolvimento de uma aplicação web, com fins de controle do setor bibliotecário, e que servirá como estudo de caso. Palavras-Chave: Scrum, Manifesto Ágil, Desenvolvimento Ágil 1 INTRODUÇÃO As mudanças provocadas pela globalização e pela difusão da tecnologia da informação têm levado as organizações a adotarem uma ampla gama de recursos tecnológicos, além disso, a busca por maior competitividade acarreta no aumento da necessidade de acesso rápido, com segurança e agilidade às informações. Esse conjunto de fatores contribui para fortalecer e acelerar a informatização de processos, tornando as organizações mais flexíveis e adaptáveis frente ao mercado além de aproximá-las de seus clientes. 1 Pós-Graduando em Engenharia de Software pelo Centro Universitário de Patos de Minas – UNIPAM. E-mail: joelber.flavio@gmail.com 2 Pós-Graduando em Engenharia de Software pelo Centro Universitário de Patos de Minas – UNIPAM. E-mail: kellyson.si@hotmail.com 3 Pós-Graduando em Engenharia de Software pelo Centro Universitário de Patos de Minas – UNIPAM. E-mail: leandrocgsi@hotmail.com 4 Mestre em Engenharia Elétrica. Docente no Centro Universitário de Patos de Minas – UNIPAM. E-mail: fernandocmjr@unipam.edu.br

Nesse contexto têm surgido novas formas de gestão que possibilitem um melhor aproveitamento do trabalho em equipe, não poderia ser diferente no mundo do desenvolvimento de software. Muitas metodologias ou frameworks de gestão e desenvolvimento de software têm reinventado a “indústria do software”, dentre elas, destacam-se os frameworks ágeis de desenvolvimento de software, principalmente o XP (eXtreme Programming) e o Scrum. Este artigo visa apontar a experiência adquirida no desenvolvimento de um software para trabalho de conclusão de curso usando o framework ágil Scrum, que utiliza uma abordagem diferente da convencional, e está organizado da seguinte forma: o capítulo 2 discorre sobre a revisão de literatura, o terceiro, descreve como o Scrum foi adotado no desenvolvimento. E por fim, o último, detalha o processo de desenvolvimento durante os sprints. 2 REVISÃO DA LITERATURA 2.1 ENGENHARIA DE SOFTWARE A Engenharia de Software é uma área da engenharia que se propõe a fornecer parâmetros para o desenvolvimento de softwares. Ela está relacionada a todos os aspectos do desenvolvimento de software, abrangendo desde aspectos iniciais como a especificação de requisitos até processos de manutenção (SOMMERVILLE, 2008). A Engenharia de Software engloba três elementos – métodos, ferramentas e procedimentos – que permitem controlar o processo de desenvolvimento e oferecem uma base sólida para a implementação de softwares de forma produtiva e com qualidade. Os métodos fornecem os detalhes do que fazer para se construir o software, as ferramentas fornecem apoio automatizado ou semi-automatizados aos métodos e, por fim, os procedimentos formam um elo que conecta os métodos e as ferramentas, permitindo assim o desenvolvimento do software de forma racional e oportuna (PRESSMAN, 2006). O termo Engenharia de Software surgiu no final dos anos 60 durante uma conferência em que se discutia a “crise do software”. A crise do software, por sua vez, era um resultado direto da evolução tecnológica empregada na fabricação do hardware de computador baseado em circuitos integrados. Essa evolução viabilizou a implementação de softwares antes considerados impossíveis de serem desenvolvidos. Os softwares resultantes tornavam-se cada vez maiores e o desenvolvimento informal mostrava-se cada vez mais

inviável. Projetos de grande porte apresentavam, muitas vezes, anos de atraso. Os custos frequentemente superavam as previsões, o software resultante não era confiável além de ser difícil de manter e de desempenho insatisfatório (SOMMERVILLE, 2008). Esse quadro tornou evidente a necessidade de se criar novos processos de gestão e desenvolvimento de software. Inicialmente, os processos de desenvolvimento de software mantinham conceitos típicos da Engenharia. Eles ajudaram a sistematizar o processo de desenvolvimento de software e mais tarde deu origem a Engenharia de Software (SOUZA NETO, 2004). Desses processos surgiram as primeiras metodologias de desenvolvimento de software, como a metodologia cascata, a prototipação, o espiral e outros. Todavia, com as mudanças no hardware, nas exigências do mercado e no conceito de qualidade de software essas metodologias não atendiam mais de forma satisfatória ao processo e à gestão do desenvolvimento de software. Em resposta a este quadro surgiu às metodologias ou frameworks ágeis. 2.2 AS METODOLOGIAS ÁGEIS DE DESENVOLVIMENTO DE SOFTWARE A maioria dos conceitos adotados pelos frameworks ágeis nada possuem de novo. A principal diferença entre esses frameworks e as metodologias tradicionais são o enfoque e os valores. Os frameworks ágeis enfocam as pessoas e não os processos ou algoritmos como as metodologias tradicionais. Além disso, existe a preocupação de gastar menos tempo com documentação e mais com a implementação, propiciando assim maior interação entre desenvolvedores e clientes (ALVES, 2009). 2.2.1 O Manifesto Ágil Percebendo que a indústria de software apresentava um grande número de casos de fracasso, alguns líderes experientes adotaram modos de trabalho opostos às metodologias tradicionais. Nesse sentido, em 2001, durante uma reunião realizada por 17 desses lideres, concluiu-se que desenvolver software é algo complexo demais para ser definido por um único processo. O desenvolvimento de software depende de muitas variáveis e principalmente é realizado por pessoas em praticamente todas as etapas do processo (BASSI FILHO, 2008). Nesse encontro chegaram a um concenso quanto a alguns princípios que levavam a bons resultados. Entretanto, concluíram que uma metodologia unificada seria incapaz de atender

todas as particularidades (SOUZA NETO, 2004). Desse trabalho surgiu o Manifesto Ágil cujo foco era o cliente e a agilidade no desenvolvimento de softwares. O Manifesto Ágil valoriza quatro princípios centrais, que resumem bem o foco do novo processo (BEEDLE, 2001). 1. Indivíduos e interação entre eles mais que processos e ferramentas 2. Software em funcionamento mais que documentação abrangente 3. Colaboração com o cliente mais que negociação de contratos 4. Responder a mudanças mais que seguir um plano Após a divulgação do Manifesto Ágil, surgiram e/ou ganharam destaque uma ampla gama de novos frameworks denominados Ágeis. Dentre os quais os mais conhecidos são: eXtreme Programming (XP), o Scrum e o TDD. Esses frameworks mantêm entre si, muitas características em comum e geralmente diferenças sutis. De acordo com Pressman (2006), esses frameworks ressaltam quatro tópicos-chave: são equipes de desenvolvimento pequenas, entre 2 e 10 membros, que se auto-organizam; priorizam mais o desenvolvimento em detrimento da documentação; reconhecem, aceitam a mudança, além de valorizarem e estimularem a comunicação tanto entre os membros da equipe quanto entre a equipe e o cliente. Outras características não citadas por Pressmam, mas que merecem destaque são o fato de serem mais utilizadas em projetos pequenos, embora possam ser aplicadas em grandes projetos. Além disso, assim como no Processo Unificado (PU) os agilistas adotam o desenvolvimento iterativo a fim de maximizar o feedback e minimizar riscos. 2.2.2 Scrum O Scrum (nome derivado de uma formação tática adotada no jogo de rugby) é um framework de desenvolvimento de software, criado por Jeff Sutherland no início da década de 1990. Muitos de seus fundamentos foram incorporados da indústria automobilística japonesa. Assim como o XP, é conhecido e utilizado mundialmente. Posteriormente Shwaber e Beedle aperfeiçoaram os métodos do Scrum. Seus princípios são coerentes com as idéias do Manifesto Ágil. Por esse motivo, assim como no XP, o Scrum também visa maximizar a comunicação e o compartilhamento de conhecimento, minimizar a supervisão, adaptar-se de forma ágil as mudanças, produzir sucessivos incrementos de software, valorizar os testes e adotar uma documentação minimalista, geralmente feita após o final de cada iteração. Enfatiza ainda o uso de um conjunto de

“padrões de processo de software” que se mostraram eficientes para projetos com prazos curtos, requisitos mutáveis e negócio crítico (PRESSMAN, 2006). 2.2.3 O Quadro Kanban Uma característica significativa do Scrum é que, assim como no XP, o enfoque dado à documentação é pequeno. Na maioria das vezes, se resume a uma série de histórias de usuário – similares a casos de uso – afixadas em um quadro Kanban. O quadro Kanban é originário de um método, homônimo, de fabricação, orientado à produção em série e serve para facilitar a gerência do fluxo de produção. O desenvolvimento deste método é creditado à Toyota. Ele surgiu dentro do contexto do Just In Time do qual faz parte (PEINADO, 1999). O termo Kanban é uma palavra japonesa que significa literalmente registro ou placa visível que são características básicas do quadro. Figura 1 - O Quadro Kanban Fonte: RAHAL JUNIOR, 2011 A Figura 1 representa o fluxo de tarefas no quadro Kanban. Uma história de usuário ou Item de Backlog é quebrada em várias outras menores que são adicionadas a coluna A Fazer. Um membro da equipe escolhe um cartão de história, muda-o para a coluna Fazendo. Após implementar, executar os devidos testes de integração e considerar a tarefa como pronta ele então muda o cartão para coluna Feito. Isso se repetirá até que a equipe mude todas as histórias para a coluna Feito.

2.2.4 As Equipes e Papéis do Scrum O framework Scrum é formado por times scrum e os papéis a estes associados, time boxes (eventos com duração fixa) artefatos e regras. Os times scrum são configurados de modo a otimizar a flexibilidade e a produtividade. Por esse motivo, os membros de um Time Scrum são auto-organizáveis, interdisciplinares e trabalham em iterações. Cada grupo possui três papéis:  Product Owner(PO) que é o responsável por garantir o retorno sobre o investimento (return on investment – ROI) do projeto. Ele representa e defende os interesses do cliente, é ele quem cria, prioriza e mantém a lista de funcionalidades (Backlog de Produto) do projeto. Para exercer a função de Product Owner deve-se ter visão estratégica, disponibilidade, criatividade, poder de persuasão, ser comunicativo e conhecer bem as necessidades dos clientes – muitas vezes esse papel pode ser assumido pelo cliente ou um representante do mesmo;  Scrum Master que é o responsável por garantir o uso do Scrum, remover impedimentos e proteger a equipe das interferências externas. Ele auxilia o product owner no processo de priorização dos requisitos. Deve ser responsável, facilitador, humilde, comunicativo, influente e organizado;  Time Scrum que deve estimar o tempo e o esforço envolvido nos itens de projeto e definir as metas das Sprints, visando produzir produtos com alta qualidade e valor para o cliente. Deve ser multidisciplinar, comunicativo, comprometido, auto gerenciado e capaz de resolver conflitos; normalmente é composto de 5 a 9 pessoas. 2.2.5 O Sprint e os Artefatos do Scrum No Scrum existem vários Time-Boxes que são utilizados para gerar regularidade. Os Time-Boxes mais importantes no Scrum são: a sprint planing meeting (planejamento de versão), o sprint, a reunião diária, a revisão do sprint e a retrospectiva do sprint. O coração do Scrum para Schwaber (2010) é o sprint, que é uma iteração de um mês ou menos dentro da qual é feito um esforço de desenvolvimento. Ao final de cada sprint tem-se como resultado um pequeno incremento de software que é potencialmente entregável, após isto, a equipe pode iniciar um novo sprint.

O Scrum utiliza quatro artefatos principais. O backlog de produto que é uma lista priorizada de tudo que pode ser necessário desenvolver em um software. O backlog de sprint que é uma lista de tarefas priorizadas no backlog de produto e que ao final de uma sprint, resultará em um incremento. Um burndown que é um gráfico através do qual é medido a velocidade do time. Um burndown de release que mede o product backlog restante ao longo do tempo de um plano de release. E um burndown de sprint mede os itens do backlog de sprint restantes ao longo do tempo de um sprint (SHWABER, 2010). Figura 2 - O Ciclo de Vida do Framework Scrum Adaptado de 3MONTHS, 2011 A Figura 2 representa o ciclo de vida do framework Scrum. Nela pode-se observar que o product owner e a equipe, baseados na visão inicial do produto, definem as histórias a serem desenvolvidas, ou seja, o backlog de produto. Este, por sua vez, é dividido em pequenas “histórias” menores, pela equipe e pelo product owner. Posteriormente, o product owner escolhe então quais dessas histórias serão priorizadas para o sprint originando assim um backlog de sprint. Após definir-se o backlog do sprint, a equipe realiza uma reunião na qual estabelece as suas metas durante o sprint; trata-se da sprint plane meeting (reunião de planejamento do sprint). O próximo passo da espiral representa o incremento produzido durante o sprint. É nessa etapa que ocorre o desenvolvimento do produto. Uma vez que o

novo incremento foi desenvolvido, devidamente testado e integrado ao sistema a equipe faz uma revisão do sprint. Nessa revisão, a equipe apresenta o que foi realizado durante o sprint e demonstra as novas funcionalidades incorporadas. O product ownwer testa, para verificar se o item atende suas expectativas e determina se a meta do sprint foi ou não atingida. O próximo passo é a retrospectiva do sprint, nela são levantados o que aconteceu de bom, o que foi ruim e o que deve melhorar. O objetivo dessa reunião é trazer melhoria contínua ao trabalho da equipe. Feito isso o backlog de produto é atualizado e o ciclo é reiniciado. Acima do circulo maior, que representa o sprint, tem se outro circulo menor que representa a iteração diária onde são cumpridas as metas diárias que compõem o Sprint. Durante o sprint diário, os membros do time fazem uma pequena reunião de 15 minutos (reunião scrum diária), sempre de pé, no mesmo horário e local. Nela cada membro conta o que fez desde a última reunião o que pretende fazer e se está tendo algum problema. De acordo com Kniberg (2007), o Scrum fornece bases para a gestão do processo de desenvolvimento, mas não se preocupa com como será feito o desenvolvimento. O XP, por sua vez, sugere as práticas a serem seguidas para o desenvolvimento de um projeto e não se preocupa com a gestão. Sendo assim, muitas equipes ágeis utilizam XP e Scrum juntos, onde um fornece boas práticas de desenvolvimento e o outro, boas práticas de gestão. Devido a essa extensibilidade, os autores agilistas tendem a adotar o termo framework e não metodologia quando se referem a elas. Novas metodologias ou frameworks surgem o tempo todo e as vezes pode parecer dificil escolher uma “correta”. Nesse sentido, Henrajani (2007) afirma que todo projeto deve ter alguma estrutura de processo básico que precisa seguir. Não ter nenhum processo é ruim, mas o excesso deles é igualmente ruim. Sendo assim cabe a equipe encontrar o equilibrio correto, considerando as necessidades do cliente, o tamanho do projeto e as metas da equipe. 3 METODOLOGIA O ciclo de vida de desenvolvimento do software se baseou no framework Scrum, onde o desenvolvimento foi dividido em sprints que variaram de cinco dias a no máximo um mês. Ao final de cada sprint um micro incremento foi integrado ao sistema. Sempre que apareceram bugs e impedimentos eles retornaram ao Backlog de Produto até serem corrigidos e finalmente integrados ao sistema. As Reuniões Scrum Diárias foram realizadas pela equipe todos os dias pessoalmente ou via Skype. Já as revisões de sprint foram feitas ao final de cada sprint.

A tecnologia de desenvolvimento adotada foi a Plataforma Java, mais especificamente o framework de desenvolvimento web JavaServer Faces 2.0 e as bibliotecas de componentes Primefaces 2.2 e Facelets. Foi utilizado ainda o framework Hibernate para gerenciar as transações com o banco de dados. Para formatação de conteúdo foi utilizado CSS. Todo o tratamento de informações de interface com o usuário foi provido pelo Primefaces e/ou por validadores no lado servidor. Foi feito um levantamento de requisitos e definição do escopo geral da aplicação. Podem-se observar no Quadro 1 os resultados desse sprint foram os documentos de especificação de requisitos, que posteriormente foram reavaliados junto aos stakeholders. Quadro 1 – A Definição de Requisitos Histórias Tarefa Ferramenta(s) Modelar casos de uso Jude Elaborar documento de requisitos Definir requisitos do sistema Realizar entrevistas com os stakeholders Microsoft Word Microsoft Word Artefato Casos de uso que modelam o contexto Documento de requisitos inicial Requisitos de sistema Casos de uso modelam o Corrigir casos de uso Jude contexto corrigidos e/ou novos Reescrever o documento de requisitos Microsoft Word Documento de requisitos revisado Fonte: Dados do Trabalho Posteriormente, foram feitas revisões nos documentos de especificação de requisitos e escopo considerando os novos apontamentos dos stakeholders, como se pode ver no Quadro 2. O resultado foi a consolidação dos documentos de especificação de requisitos e a definição do escopo geral do sistema.

Quadro 2 – O Refinamento de Requisitos História Tarefa Ferramenta(s) Apresentação do Apresentar documentos de especificação de Microsoft Word requisitos Refinar requisitos de sistema Coletar novos requisitos documentos de especificação de requisitos Documentos de Microsoft Word especificação de requisitos atualizado Corrigir documentos de especificação de Artefato Microsoft Word requisitos Requisitos de sistema corrigidos Fonte: Dados do Trabalho Definidos os documentos de especificação de requisitos e o escopo geral, o foco da equipe passou a ser a construção do modelo conceitual do banco de dados e na construção do banco físico. Ao final teve-se como resultados o modelo conceitual e o script SQL que possibilitou a construção do banco de dados. O Quadro 3 detalha as tarefas executadas. Quadro 3 – Terceiro Sprint Concepção e Construção do Banco de Dados História Tarefa Elaborar do modelo Elaboração do modelo conceitual Ferramenta(s) Case Studio conceitual do banco de dados Artefato Modelo conceitual do banco de dados Script SQL para a Gerar o script SQL Case Studio construção do banco físico MySQL Query Rodar o script SQL Browser e MySQL Construir o banco físico MySQL Query Criar usuários Browser e MySQL Fonte: Dados do Trabalho Banco de dados físico Banco de dados atualizado com usuários e permissões

Após definir os requisitos e modelar o banco de dados, iniciou-se o processo de desenvolvimento. As histórias foram discutidas e priorizadas, considerando sempre o quanto agregavam de valor e sua importância para a aplicação como um todo. Além disso, foram consideradas histórias que representavam maior risco ao projeto. A equipe utilizou a ferramenta ScrumHalf como apoio a adoção das práticas Scrum. O Quadro 4 representa a estrutura básica dos sprints. As tarefas apresentadas nele se repetiram sucessivas vezes até que todas as histórias de usuário foram atendidas. A única mudança significativa, ocorreu nas “Histórias”, que, no Quadro 4, estão genericamente representadas pelo termo Desenvolvimento. Quadro 4 – Estrutura Básica dos Sprints História(s) Tarefa Ferramenta(s) Priorizar histórias ScrumHalf Quebrar histórias em tarefas ScrumHalf Artefato Histórias de usuário priorizadas Histórias de usuário quebradas Eclipse Helios Netbeans 7.0 MySQL Software pronto Browsers Programação Incremento de para testar Apache Tomcat Eclipse Helios Desenvolvimento Netbeans 7.0 Testes unitários MySQL Browsers Apache Tomcat Incremento de software pronto para os testes de integração Eclipse Helios Netbeans 7.0 MySQL software pronto para Browsers Testes de integração Incremento de entrar em produção Apache Tomcat Atualização do Backlog de Produto ScrumHalf Fonte: Dados do Trabalho Backlog de Produto atualizado

4 ANÁLISE DOS RESULTADOS Para a aplicação do Scrum a equipe utilizou uma ferramenta denominada ScrumHalf, própria para a prática dessa metodologia que está disponibilizada em www.scrumhalf.com.br. Definidos os requisitos com o cliente, iniciou-se o desenvolvimento da aplicação. No backlog de produto foram propostas as histórias que mais agregavam valor ao produto e essas, posteriormente foram aprovadas. O backlog de produto contém em sua parte superior informações a respeito do total de histórias elaboradas no decorrer do projeto, das histórias concluídas e a realizar, além de mostrar a quantidade de histórias que foram propostas, mas que ainda não foram aprovadas. É importante observar também, na Figura 3, que cada história possui um valor agregado, definido pela equipe de acordo com o grau de importância para a aplicação e uma estimativa, que representa a quantidade de dias para realizar aquela história. Figura 3 - Product Backlog Fonte: Dados do Trabalho

Com uma ou mais histórias aprovadas, cria-se o backlog de Sprint, onde é estipulada a meta da sprint, suas datas de início e término, quais histórias irão ser fragmentadas para transformar-se em tarefas no Kanban e os pontos previstos, que são o resultado da soma dos valores agregados de cada história selecionada para o sprint. Durante o período de desenvolvimento, o gráfico burndown mostra informações para que o Scrum Master possa acompanhar o desempenho da equipe. Ressalta-se que a equipe utilizou a versão gratuita da ferramenta, o que não inclui o gráfico, como mostra a Figura 4. Figura 4 - Criação do Backlog de Sprint Fonte: Dados do Trabalho Com as histórias fragmentadas, o quadro de tarefas é criado e ocorrem os procedimentos descritos na seção 2.2.3. A Figura 5 mostra que durante esse sprint, houve bugs e impedimentos em algumas tarefas, identificados pelas cores rosa e cinza respectivamente. Um método de sanar problemas durante a aplicação do Scrum ocorre nos encontros da equipe durante a reunião scrum diária onde a equipe se reúne durante 15 minutos, no máximo, para discutirem o que foi feito, o que tiveram de impedimentos e o que será desenvolvido até a reunião do dia seguinte. Esse encontro é importante, pois a troca de experiências contribui para que a sprint tenha sucesso ao seu término. Durante o

desenvolvimento da aplicação bibliotecária, as reuniões diárias da equipe ocorreram tanto pessoalmente, em um mesmo local, quanto através do aplicativo Skype. É possível observar, ainda na Figura 5 que, a qualquer momento, é possível finalizar a sprint, independente se o período de desenvolvimento terminou ou não, ressalta-se que essa funcionalidade da ferramenta é disponibilizada de acordo com o papel no scrum que o indivíduo ocupa e, nesse projeto, exclusivamente, foi disponibilizada a todos os membros da equipe, uma vez que eles exerciam todos os papéis do scrum ao mesmo tempo, pois ambos tiveram contato com os interesses do cliente, se autogerenciavam e trabalhavam no desenvolvimento da aplicação. Figura 5 - O Kanban (quadro de tarefas) Fonte: Dados do Trabalho Após a finalização do ciclo de desenvolvimento, ocorre a fase de revisão de sprint, onde são aprovados ou não a história que fez parte do ciclo de desenvolvimento e

também é definido se a meta proposta para a sprint foi alcançada ou não. Na retrospectiva de sprint, que sucede a revisão, os pontos positivos e negativos que ocorreram durante o desenvolvimento são registrados e armazenados em histórico, em seguida ocorre uma atualização do backlog de produto, e se o product owner aprovar, um incremento do produto é entregue, senão, volta ao ciclo até que seja aprovado. Logo após, a reunião de planejamento da próxima sprint acontece e essas etapas são repetidas sucessivamente até o término do projeto. O software de controle bibliotecário, produto deste estudo de caso, foi construído em cinco sprints, somente após todas essas etapas é que foi obtido como resultado um incremento estável e pronto para ser entregue ao cliente. 5 CONCLUSÃO Durante a aplicação do Scrum, houve a necessidade da participação do cliente (product owner) em, praticamente, todas as etapas de criação do software, o que se destaca como uma dificuldade encontrada, pois a disponibilidade por parte deste às reuniões era muito restrita, principalmente durante a programação e demonstração do micro-incremento. A realização da reunião scrum diária através do Skype, foi devido à impossibilidade de todos os membros da equipe se reunirem no mesmo local todos os dias. Também, durante o início do projeto, existiram dúvidas sobre a operação da ferramenta ScrumHalf, o que posteriormente foram diminuindo à medida em que a equipe adquiria familiaridade em seu manuseio. Como o Scrum valoriza software funcionando mais do que documentação, destaca-se como ponto positivo sua utilização, pois, o tempo que seria gasto para a confecção de documentos foi aproveitado com desenvolvimento, pesquisa e troca de experiências entre o time scrum. A ferramenta ScrumHalf, é muito eficiente para a aplicação do framework, uma vez que, não é necessário obter um quadro de tarefas real, e que é possível acessá-lo em qualquer ambiente com acesso a internet, além de suprir todas as etapas que o Scrum necessita, o que também acarreta como benefício, corte de custos com materiais físicos. Conclui-se que quando a equipe consegue agregar ao time o cliente, a possibilidade de controvérsias com o mesmo durante a entrega do produto é mínima, o que contribui para que os princípios do framework sejam cumpridos, levando o projeto ao êxito.

REFERÊNCIAS 3MONTHS. Project Lyfecycle. Disponível em: < http://blog.3months.com/wpcontent/uploads/2010/01/project_lifecycle_v1cc.png > acesso em: 04 abr. de 2011. ALVES, Sérgio de Rezende; ALVES, André Luiz. Engenharia de Requisitos em Metodologias Ágeis. Goiânia: Universidade Católica de Goiás (PUC – Goiás), 2009. Disponível em: < http://www.cpgls.ucg.br/ArquivosUpload/1/File/V%20MOSTRA% 20DE%20PRODUO%20CIENTIFICA/EXATAS/10-.PDF > acesso em: 04 abr. de 2011. BASSI FILHO, Dairton Luiz. Experiências com Desenvolvimento Ágil. São Paulo: USP – Istituto de Matemática e Estatística da Universidade de São Paulo, 2008. BEEDLE, Mike et al. Manifesto para o desenvolvimento ágil de software. Disponível em: <http://manifestoagil.com.br/>. Acesso em: 28 fev. 2011. HENRAJANI, Anil. Desenvolvimento ágil em Java com Spring, Hibernate e Eclipse. São Paulo: Pearson Prentice Hall, 2007. KNIBERG, Henrik. Scrum e XP Direto DasTrincheiras: Como nós fazemos Scrum. InfoQueue, 2007. Disponível em < http://infoq.com/br/minibooks/scrum-xp-fromthe-trenches > Acesso em 14 nov. 2010. KNIBERG, Henrik; SKARIN, Mattias. Kanban e Scrum : Obtendo o Melhor de Ambos. InfoQueue, 2007. Disponível em <http://www.infoq.com/br/minibooks/kanban-scrumminibook> Acesso em 14 nov. 2010. PEINADO, Jurandir. O papel do sistema de abastecimento Kanban na redução dos inventários. Revista da FAE, Curitiba, v.2, n.2, p.27-34, maio/ago. 1999. PRESSMAN, Roger S. Engenharia de Software : 6 ed. São Paulo: McGraw Hill/Nacional, 2006. RAHAL JUNIOR, Nelson Abu Samra . Melhorando o Entendimento “Como fazer?”. Disponível em: < http://blogdoabu.blogspot.com/2010/09/melhorando-o-entendimento-comofazer.html > acesso em 04 abr. 2011. SOMMERVILLE, Ian. Engenharia de Software : 8 ed. Rio de Janeiro: Prentice-Hall, 2008. SOUZA NETO, Oscar Nogueira de. Análise Comparativa das Metodologias de Desenvolvimento de Softwares Tradicionais e Ágeis. Belém: Unama – Universidade da Amazônia, 2004. SCHWABER, Ken. Guia do Scrum. Scrum Alliance, 2010. Disponível em: < http://www.scrum.org/storage/scrumguides/Scrum%20Guide%20-%20PTBR.pdf > acesso em 04 abr. 2011.

Add a comment

Related presentations

Related pages

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

×close share scrum: adoÇÃo de um framework Ágil no desenvolvimento de um software para trabalho de conclusÃo de curso
Read more

Scrum no contexto de processos de desenvolvimento - Technology

Apresentação sobre o framework SCRUM no contexto de metodologias para processos de desenvolvimento de software.
Read more

IMPLANTAÇÃO DA METODOLOGIA ÁGIL SCRUM EM UM AMBIENTE DE ...

EM UM AMBIENTE DE DESENVOLVIMENTO Trabalho de Conclusão de Curso ... A adoção do Scrum foi um processo ... Engenharia de Software. Cultura ágil. Scrum.
Read more

Joelber Garcia | LinkedIn

Publications. SCRUM: ADOÇÃO DE UM FRAMEWORK ÁGIL NO DESENVOLVIMENTO DE UM SOFTWARE PARA TRABALHO DE CONCLUSÃO DE CURSO IX COMINE - Congresso Mineiro de ...
Read more

O Lean do Scrum - msdn.microsoft.com

David Starr é o artesão principal de software para o Scrum.org onde ele ... o desenvolvimento de software ágil ... de trabalho usadas no Scrum.
Read more

Metodologia Ágil - Dinamismo no Desenvolvimento de Software

Dinamismo no Desenvolvimento de Software . ... e assinaram o “Manifesto para o Desenvolvimento Ágil de Software ... Curso Online Scrum ...
Read more

ESTUDO PARA ANÁLISE DO GERENCIAMENTO DE ESCOPO ATRAVÉS DA ...

... Ágil SCRUM no desenvolvimento de software ... na adoção do framework. ... PROJETOS ÁGIL SCRUM Trabalho de Conclusão de Curso ...
Read more

⭐ESTUDO DE FERRAMENTAS EM SOFTWARE LIVRE PARA GESTÃO ÁGIL ...

... DE SOFTWARE Trabalho de conclusão do curso Lato ... SCRUM NO DESENVOLVIMENTO DE SISTEMAS PARA O ... Software Framework Ágil, Scrum ...
Read more