A utilização do Scrum em um sistema web: um estudo de caso

ISSN 23162872 T.I.S. São Carlos, v. 1, n. 1, p. 7681, jul. 2012 Tecnologias, Infraestrutura e Software A utilização do Scrum em um sistema web: um estudo de caso Flávia dos Santos Zenaro Abstract: This paper aims to address the question about software development using the Scrum agile development methodology in a web system that support decision making, called the Decision Support System or Sistema de Apoio a Decisão (SAD), based in Regency, Frequency and Monetary Value (RFV), which shows the evolution of customer of a company. Will be reported in this article what are the advantages of developing a web system using the Scrum agile methodology, indicating the gains from its use compared to traditional methodologies. The the professionals can prioritize project development gains in production areas and teams in applying the methodology scrum at the expense of traditional methodology. Keywords: agile, Scrum, web application Resumo: Este artigo tem como objetivo abordar a questão sobre desenvolvimento de software utilizando a metodologia de desenvolvimento ágil Scrum em um sistema Web de apoio a tomada de decisão, chamado Sistema de Apoio a Decisão (SAD), baseado em Regência, Freqüência e Valor Monetário (RFV), que demonstra a evolução da carteira de clientes de uma empresa. Neste artigo serão relatados os processos Como resultado deste estudo temos os benefícios que a metodologia ágil Scrum tem no desenvolvimento de software em pequenas equipes. aplicarem a metodologia Scrum em detrimento da metodologia tradicional. Palavraschave: metodologia ágil, Scrum, aplicação web I. INTRODUÇÃO A escolha de uma metodologia de desenvolvimento é uma das etapas no inicio do desenvolvimento de um novo software, assim como a escolha da linguagem de programação e o banco metodologia a ser utilizada para o software em questão repercute, sem dúvida, em benefícios ao longo de todo o processo de fabricação de um software. ração no momento da escolha, como: a quantidade de integrantes da equipe de desenvolvimento, o tamanho do software que será desenvolvido, o conhecimento da metodologia por parte dos integrantes e o prazo de entrega. Com prazos cada vez mais apertados, recursos mais enxutos e senvolvimento de software e as empresas são obrigados a trabalharem, são necessários métodos que ajudem a atingir todos esses objetivos minimizando gastos e maximizando os resultados. Assim, o sucesso de um software não está somente na escolha se enquadra com o cenário e o ambiente em que esse software será desenvolvido. Conhecer as vantagens e desvantagens e os pontos fortes e fracos da metodologia são a chave para uma escolha mais acertada e, com isso, aumentar a probabilidade de software, tenha mais qualidade, atenda as necessidades reais do cliente, seja desenvolvido em menos tempo e com menos esforço de desenvolvimento. O restante do artigo está organizado da seguinte maneira: Na seção II é apresentado o objetivo do artigo. Na seção III é apresentada a fundamentação teórica em que a pesquisa foi baseada. Na seção IV são detalhadas as pesquisas realizadas anteriormente sobre o assunto. Na seção V é exibida a possível abordagem e metodologia de pesquisa, enquanto que na práticos encontrados. II. OBJETIVO Nesse contexto, este trabalho terá como maior objetivo descrever as vantagens que a metodologia ágil Scrum trouxe ao Departamento de Computação Universidade Federal de São Carlos (UFSCar) Caixa Postal 676 13.565905 São Carlos SP Brasil Autor para correspondência: fzenaro@yahoo.com.br

A utilização do Scrum em um sistema web: um estudo de caso longo do desenvolvimento do software para Web chamado SAD. As vantagens são visíveis desde a etapa de planejamento onde é estabelecida a visão do projeto e a primeira versão do Product backlog até a fase releasing, auxiliando assim, futuros programadores a entenderem como esta metodologia deve ser empregada em cada fase do desenvolvimento de software e em quais fases essa metodologia trará mais benefícios para o projeto. III. METODOLOGIA ÁGIL Pelo motivo das metodologias tradicionais serem as mais estudadas e aplicadas e pelo fato que as metodologias de desenvolvimentos ágeis serem relativamente novas em comparação à primeira, uma discussão mais aprofundada sobre esse assunto se faz necessário. Isso é válido para que equipes de projetos poderão aplicálas. uma revolução dos métodos tradicionais de desenvolvimento de software. Alguns dos pontos chaves destas metodologias são a de eliminar gastos com documentação, documentando só o estritamente necessário, dando mais valor à comunicação e colaboração com o cliente, criando atividades que tragam valor à produção de software com qualidade. Os aspectos humanos do desenvolvimento de software são mais enfatizados nas metodologias ágeis do que os aspectos de Engenharia de Software propriamente dito. O grande diferencial nas metodologias ágeis é o reconhecimento de que as pessoas são uma fonte importante de conhecimento e condutores do sucesso do projeto. Outra diferença marcante desta metodologia em comparação requisitos chamado na metologia ágil como Product Backlog sprint. O Scrum faz parte dessas metodologias. Outras podem ser citadas também: XP (Extreme Programming), FDD (Feature Driven Development), Crystal, Adaptative Software Development, DSDM (Dynamic System Development Method) e LD (Agile Lean Development). Com a criação do Manifesto Ágil os seus conceitos ganharam conhecimento. São eles formados por 4 propostas: 2º Software executável no lugar de desenvolvimento de documentação. 3º Colaboração do cliente ao invés de negociação de contratos. 4º Respostas rápidas a mudanças no lugar de seguir planos. A metodologia ágil Scrum foi criada como um tipo de processo de desenvolvimento inicialmente aplicado no gerenciamento de projetos em empresas de fabricação de automóveis e produtos de consumo em que se prioriza utilização de equipes pequenas para a operação das tarefas que envolvem o desenvolvimento de software. processo para projeto e desenvolvimento de software orientado a objeto, que seja focado nas pessoas e que seja indicado para ambientes em que os requisitos surgem e mudam rapidamente. para o gerenciamento do processo de desenvolvimento de software. O primeiro desenvolvimento de software com Scrum foi realizado em 1993 por Jeff Sutherland na Easel Corporation (Sutherland 2004), e, junto com Ken Schwaber, formalizaram o Scrum (Sutherland e Schwaber 2007) como processo de desenvolvimento na OOPSLA. IV. UTILIZAÇÃO DO SCRUM EM PROCESSO DE DESENVOLVIMENTO DE SOFTWARE O Scrum possui um ciclo de vida composto de 4 fases a saber: planejamento, stagging, desenvolvimento e releasing. Na fase de planejamento é estabelecida a visão do projeto e expectativas garantindo recursos para a sua execução. São cria Product backlog e o plano de release que são as datas de entrega do sistema. O Product backlog é o ponto inicial do Scrum, sendo considerada a prática responsável pela coleta dos requisitos, conforme aponta Schwaber (2004, p.33). Nesta prática, através de com todas as necessidades do negócio e os requisitos técnicos a serem desenvolvidos, ou seja, o Product backlog é uma lista de atividades que provavelmente serão desenvolvidas durante o projeto. Na fase stagging criando itens adicionais ao Product backlog relacionados com o tipo do sistema, time, ambiente de desenvolvimento e tipo de aplicação. Nesta fase os times são formados e são construídos os métodos de comunicação e coordenação entre eles. É na fase de desenvolvimento que os sprints são realizados para o desenvolvimento dos incrementos de funcionalidades do sistema. A fase de releasing é para efetuar a entrega do sistema ao cliente. As práticas gerenciais do Scrum são: Product backlog, Daily Scrum, Sprint, Sprint Planning Meeting, Sprint Backlog e Sprint Review Meeting. Daily Scrum) são efetuadas pela equipe de desenvolvimento, cliente, se possível, e Scrum Master a cada dia de duração do sprint. Tem como objetivo disseminar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia. Os Daily Scrums normalmente são realizados no mesmo local e no mesmo horário do dia. Idealmente são realizados na parte da manhã, para ajudar a equipe a estabelecer as prioridades do novo dia de trabalho. discutidas durante o Daily Scrum, mas sim por algumas pessoas em um momento após a reunião. Neste período o objetivo é fundamentais: O que você fez ontem?, O que fará hoje? e Existe algum impedimento no seu caminho?. 77 T.I.S. 2012; 1 (1): 7681

Flávia dos Santos Zenaro Concentrandose no que cada pessoa fez ontem e no que ela fará hoje, a equipe ganha uma excelente compreensão sobre qual trabalho foi feito e qual trabalho ainda precisa ser feito. Nesta reunião os membros da equipe assumem compromissos uns para com os outros, fortalecendo os laços de comprometimento e engajamento no projeto. A reunião Sprint Planning é realizada com a presença do Product Owner, Scrum Master e de todo Scrum Team. Durante a reunião Sprint Planning, o Product Owner explica as funcionalidades de maior prioridade para o Scrum Team, nesta reunião o Scrum Team eles irão mover do Product backlog para o Sprint Backlog. Juntos, o Scrum Team e o Product Owner tivo para o Sprint (Sprint Goal), que é uma breve descrição do que pretendese atingir no Sprint. O sucesso do Sprint será veri Sprint Review, baseado no Sprint Goal Sprint Backlog. Depois da reunião Sprint Planning, o Scrum Team reúne se separadamente para discutir o que foi proposto e decidir o quanto eles se comprometem a fazer durante o próximo Sprint. Product Owner, mas será sempre prerrogativa do Scrum Team determinar o quanto eles podem se comprometer. A metodologia ágil Scrum utiliza o desenvolvimento através de ciclos geralmente de duas semanas a 30 dias (chamados Sprint rias. Assim, como resultado, um produto independente e acabae controle do desenvolvimento de software de maneira interativa e incremental, tem o objetivo de ser aplicado em pequenas o funcionamento do Scrum. Um projeto se inicia com uma visão do produto que será desenvolvido, ou seja, pelos requisitos e funcionalidades que o software deverá conter. Estes requisitos e funcionalidades são Product Owner (PO) ou Dono do Projeto. Após isso, é criado o Sprint Backlog que nada mais é do que a escolha dos requisitos que deverão ser implantados no próximo Sprint. O Sprint é o tempo de desenvolvimento das funcionalidades cada Sprint, é entregue um incremento do produto, um sistema acabado e funcionando, após ter passado por todo o processo de desenvolvimento, auditoria e teste. O Scrum implementa um esqueleto iterativo e incremental, através de três papéis principais [Schwaber 2004]. São eles: Scrum Master, Product Owner e o Time, que serão descritos a seguir. A. O Papel do ScrumMaster Em um projeto tradicional, o gerente de projeto é o respon Scrum Master tem o papel de gerir a equipe, mantendoa unida e no caminho certo, e é também a pessoa que tem um bom conhecimento dos processos que envolvem o desenvolvimento com Scrum para poder cobrálos de sua equipe. O Scrum Master também é o responsável por proteger o time de interferências externas, removendo os impedimentos levantados pelo time e apoiandoo no uso do Scrum. B. O Papel do Time Conhecida como Team Members ou Equipe Scrum, é a equipe ou as várias equipes que podem trabalhar em paralelo na execução de um projeto de software. É responsável pelo desenvolvimento dos itens de backlog product backlog em incremento de funcionalidades, gerenciando seu próprio trabalho. O time é responsável coletivamente pelo sucesso da iteração e conseqüentemente pelo projeto como um todo. C. O Papel do Product Owner Na metodologia Scrum, o Product Owner é o dono do projeto, ou seja, é a pessoa para quem está sendo desenvolvido o projeto. O Product Owner é quem estabelece os objetivos do Dias de Trabalho Restantes Figura 1. Visão Geral do Processo Scrum (adaptado de Schwaber, 2004) Figura 2. O avanço do desenvolvimento ao longo do Sprint. (adaptado de Schwaber, 2004) T.I.S. 2012; 1 (1): 7681 78

A utilização do Scrum em um sistema web: um estudo de caso cklogs, como são conhecidas, e participa ativamente de todo o desenvolvimento do software, validando o produto de cada sprint. A cada iteração, o time controla o andamento do projeto re Sprint Burndown tra o trabalho restante estimado no Sprint. O eixo na vertical apresenta os dias de esforço restantes no Sprint. O eixo na horizontal representa os dias do Sprint. dro de trabalho, no qual as tarefas são dispostas segundo seus status [Schwaber 2004]. Esse quadro oferece maior clareza das tarefas, pois, como o Burndown, basta olhar para ele para realizar a leitura do progresso do Sprint. Product backlog sprint a equipe demonstra as funcionalidades de trabalho para o Product Owner. V. UTILIZAÇÃO DO SCRUM NO PROCESSO DE DESENVOLVIMENTO DO SISTEMA SAD vimento de software pelo método ágil Scrum utilizando um sistema web chamado Sistema de Apoio a Decisão (SAD) como estudo de caso. Para isso, será detalhado como esse sistema foi desenvolvido e quais foram os resultados obtidos com a utilização da metodologia Scrum. Nesse sentido, a aplicação da metodologia Scrum resultou na demonstração dos resultados do desenvolvimento do sistema SAD nos requisitos funcionais: logar no sistema, cadastrar Para o desenvolvimento do sistema SAD foi criado o product backlog, como ilustra a tabela 1, onde ID é um número portância do item de backlog podendo variar de 0 à 10 sendo o número 10 o mais importante, no campo Est colocase a estimativa em horas para a implementação do item de backlog, em Como demonstrar uma descrição em alto nível ou um pseudocódigo do que deve acontecer durante o sprint e em Notas colocase qualquer informação que seja importante para o entendimento do item a ser desenvolvido. A partir da criação da tabela de product backlog foi possível ção de quais itens do product backlog entrariam no primeiro sprint. VI. DESCRIÇÃO DOS SPRINTS REALIZADOS Dentro deste contexto, descrevese a seguir os detalhes dos sprints para os itens 1, 3 e 4 do product backlog: Logar no sistema, Incluir usuário e Alterar usuário respectivamente. Tabela 1. Product backlog do sistema SAD Product backlog ID Nome Imp Est Como demonstrar Notas 1 Logar no sistema 5 5 Usuários técnicos operacionais e estratégicos fazem o login no sistema informando email e senha já pré cadastradas pelo usuário técnico. 2 banco de dados 3 4 5 Incluir usuário Alterar usuário Excluir usuário 8 8 5 7 5 5 5 5 a conexão do banco do cliente com o banco SAD. Logarse, entrar na tela de cadastro de usuário, digitar os dados de Logarse, entrar na tela de alterar usuário. Se o usuário for do tipo técnico poderá alterar todos os dados. Para os outros tipos será permitida somente a alteração da senha. Logarse, acionar o item excluir. Somente o usuário técnico poderá realizar a exclusão dos usuários. Informar nome e email do usuário a ser excluído. Utilizar o mesmo arquivo CSS do ID 3. Utilizar o mesmo arquivo CSS do ID 3. 6 dados 8 8 com o banco de dados do sistema. 7 RFV 10 10 RFV de r1 a r5 e f1 a f5. 79 T.I.S. 2012; 1 (1): 7681

Flávia dos Santos Zenaro product backlog foi escolhido pelo Scrum Master, para o primeiro sprint, o desenvolvimento do item 1 Logar no sistema. Foi utilizado um sprint de 7 dias com uma equipe de 3 pes ponsável pelo layout e os outros pela programação do módulo. Neste caso, pelo fato da equipe ter um número de integrantes reduzido, cada integrante desempenhou mais de um papel. O Product Owner além de estabelecer os itens do product backlog e determinar as prioridades de programação também participou do time, auxiliando no desenvolvimento. O Scrum Master desempenhou o papel de programador junto ao time, Scrum Master sprint Login do sistema. Figura 4. Tela de Inclusão de Usuário do sistema SAD no terceiro sprint. Figura 5. Tela de Inclusão de Usuário do sistema SAD Figura 3. Tela de Login do sistema SAD Para o segundo sprint foi escolhido o item 3 Incluir Usuário do Product Backlog. Para este sprint foram gastos 15 dias e tempo aproximado de 7 horas. Para este sprint os acompanhamentos diários que a metodologia Scrum utiliza foram adaptados pela equipe, ao invés de serem diários, foram feitos conforme a necessidade. Quando cada membro do time encerrava a sua parte no desenvolvimento, comunicavaa aos outros integrantes por email enviando os arquivos e um resumo do desenvolvimento. Quando algum integrante precisava de ajuda, este solicitatentava avançar no sprint. Quando julgávamos necessário era marcado um encontro para realizar o desenvolvimento em grusprint. Para o terceiro sprint foi escolhido o item Alterar usuário para dar continuidade ao sistema que já possuía a funcionalidade de Incluir usuário. Neste sprint foi estimado o tempo de 5 (cinco) horas de programação para a sua conclusão, mas devido a alguns impedimentos como a falta de experiência na linguagem java e problemas na programação que enfrentamos, foram necessárias 8 (oito) horas de desenvolvimento e um encontro para desenvolvimento em conjunto. Os acompanhamentos foram com intervalos de 1 (um) dia com envio por email do projeto e dos problemas que estavam sendo enfrentados por cada programador. VII. CONCLUSÃO A partir deste estudo de caso concluise que com a utilização do Scrum no desenvolvimento do sistema SAD a agilidade no processo de fabricação do software foi satisfatória mesmo com um número pequeno de integrantes. Evidenciamos assim, que a quantidade de pessoas envolvidas na elaboração de um software só o sucesso ou fracasso de um sistema, mas sim a utilização de uma metodologia que se enquadre com o cenário que envolve seu desenvolvimento. Durante as etapas da utilização da metodologia Scrum no desenvolvimento do sistema SAD, percebeuse a necessidade dos sprints de 30 dias para 7 ou 15 dias, conforme o calendário volvido por cada um, e saber quais os principais impedimentos sprint como tirar ximo item do product backlog a ser desenvolvido. Daily Scrum foram feitas de 1 a 3 vezes na semana, dependendo da complexidade do sprint, assim cada um do time enviava por email informade um encontro para desenvolver algum item mais complexo em conjunto. T.I.S. 2012; 1 (1): 7681 80

A utilização do Scrum em um sistema web: um estudo de caso Dessa forma, como a metodologia Scrum nunca fora antes utilizada por nenhum dos integrantes do grupo, podemos concluir que foi uma experiência que acrescentou ganhos a todos e uma grande oportunidade de obtenção de conhecimento e vivência no desenvolvimento de software utilizando uma metodologia ágil. Evidenciamos que o Scrum agiliza e torna o processo de desenvolvimento de software mais direto pela ausência de criação de uma documentação detalhada, como nos modelos tradicionais de desenvolvimento de software vamente no tempo total do projeto. Através dos sprints é possível desenvolver um produto acabado a cada ciclo de tempo fazendo com que o cliente possa utilizar o software suas utilidades logo no início do desenvolvimento do sistema e ao longo do projeto em períodos curtos de tempo, propiciando oportunidades de ajustes e melhorias contínuas durante todo o desenvolvimento. REFERÊNCIAS BECK, K AT ALL. (2001) Manifesto for Agile Software Development. Disponível em: <http://www.agilemanifesto.org>. Acesso em: 25/04/2010. Cavalcanti, Eric at all. Ferramenta OpenSource para Apoio ao Uso do scrum por Equipes Distribuídas. Disponível em: <http://www.lbd.dcc.ufmg.br:8080/colecoes/wdds/2009/ 006.pdf>. Acesso em: 26/05/2010 Cohn, Mike. Introduction to Scrum An Agile Process. Disponível em: <http://www.mountaingoatsoftware.com/topics/scrum>. Acesso em: 23/10/2010. Highsmith, J. Agile Project Management Creating Innovative Products, AddisonWesley, 2004. Kniberg, Henrik. Scrum e XP direto das Trincheiras Como nós fazemos Scrum. InfoQ, 2007. Schwaber, K. Agile Project Management With scrum. Microsoft Pr, 2004. Sutherland, Jeff. Agile Development: Lessons Learned from the First scrum. Cutter Agile Project Management Advisory Service: Executive Update, vol.5, 2004. Sutherland, Jeff, Schwaber, Ken. The Scrum Papers: Nuts, Bolts, and Origins of an Agile Process, Draft 14/10/2007. 81 T.I.S. 2012; 1 (1): 7681