UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO

UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO SCRUM PROJECT: FERRAMENTA DE APOIO AO GERENCIAMENTO DE PROJETOS DE SOFTWARE BASEADA NOS PRINCÍPIOS DA METODOLOGIA ÁGIL SCRUM Área de Engenharia de Software por Monike Roberta Kluge Adriana Gomes Alves, M. Eng Orientadora Itajaí (SC), julho de 2009

UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO SCRUM PROJECT: FERRAMENTA DE APOIO AO GERENCIAMENTO DE PROJETOS DE SOFTWARE BASEADA NOS PRINCÍPIOS DA METODOLOGIA ÁGIL SCRUM Área de Engenharia de Software por Monike Roberta Kluge Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientadora: Adriana Gomes Alves, M. Eng. Itajaí (SC), julho de 2009

SUMÁRIO LISTA DE ABREVIATURAS...iv LISTA DE FIGURAS...v LISTA DE TABELAS...vi RESUMO...vii ABSTRACT...viii 1 INTRODUÇÃO...1 1.1 PROBLEMATIZAÇÃO... 2 1.1.1 Formulação do Problema... 2 1.1.2 Solução Proposta... 3 1.2 OBJETIVOS... 3 1.2.1 Objetivo Geral... 3 1.2.2 Objetivos Específicos... 3 1.3 METODOLOGIA... 3 1.4 ESTRUTURA DO TRABALHO... 4 2 FUNDAMENTAÇÃO TEÓRICA...5 2.1 PROCESSOS DE SOFTWARE... 5 2.2 METODOLOGIAS TRADICIONAIS... 7 2.3 METODOLOGIAS ÁGEIS... 11 2.4 SCRUM... 12 2.4.1 Papéis no Scrum... 14 2.4.2 Estrutura do Processo Scrum... 16 2.4.3 Ciclo de Vida do Scrum... 25 2.4.4 Ferramentas... 26 3 PROJETO...29 3.1 ANÁLISE DE REQUISITOS... 29 3.1.1 Requisitos Funcionais... 29 3.1.2 Requisitos Não Funcionais... 30 3.1.3 Regras de Negócio... 31 3.2 DIAGRAMA DE CASOS DE USO... 31 3.2.1 Módulo Projeto... 31 3.2.2 Módulo Product Backlog... 32 3.2.3 Módulo Controle de Sprint... 33 3.3 DIAGRAMA DE CLASSES... 35 3.4 DIAGRAMA ENTIDADE-RELACIONAMENTO... 36 4 DESENVOLVIMENTO...37 4.1 IMPLEMENTAÇÃO DA FERRAMENTA... 37 4.1.1 Framework ScriptCase... 38 ii

4.2 A FERRAMENTA SCRUM PROJECT... 39 4.2.1 Acesso ao Sistema... 39 4.2.2 Módulo de Cadastros... 42 4.2.3 Módulo Projeto... 44 4.2.4 Módulo Product Backlog... 45 4.2.5 Módulo Sprint Backlog... 46 4.2.6 Módulo Reunião de Planejamento... 47 4.2.7 Módulo Reunião Diária... 48 4.2.8 Reunião de Revisão... 49 4.2.9 Reunião de Retrospectiva... 50 4.2.10 Relatórios... 51 5 CONCLUSÕES...53 6 REFERÊNCIAS BIBLIOGRÁFICAS...54 GLOSSÁRIO...56 A DESCRIÇÃO DOS CASOS DE USO...58 A.1 MÓDULO PROJETO... 58 A.2 MÓDULO PRODUCT BACKLOG... 65 A.3 MÓDULO DE CONTROLE DE SPRINT... 67 iii

LISTA DE ABREVIATURAS ASD CASE DSDM FDD MOSCOW ROI RUP TCC UML UNIVALI XP Adaptative Software Development Computer Aided Software Engineering Dynamic System Development Method Feature Driven Development Must, Should, Could, Want Return on Investment Rational Unified Process Trabalho de Conclusão de Curso Unified Modeling Language Universidade do Vale do Itajaí Extreme Programming iv

LISTA DE FIGURAS Figura 1. Camadas da Engenharia de Software...5 Figura 2. Modelo em Cascata...8 Figura 3. Fases do RUP...10 Figura 4. Adoção do Scrum...12 Figura 5. Framework do Scrum...14 Figura 6. Fluxo do Scrum...16 Figura 7. Product Backlog...18 Figura 8. Priorização do Product Backlog...18 Figura 9. Importância do Product Backlog...19 Figura 10. Estimando o Product Backlog através do Planning Poker...20 Figura 11. Estrutura de uma Sprint...21 Figura 12. Planejamento da Sprint...22 Figura 13. Controle da Sprint Backlog...23 Figura 14. Burndown Charts dias/horas...24 Figura 15. Burndown Charts Sprint /estimativa...24 Figura 16. Diagrama de casos de uso do módulo Projeto...32 Figura 17. Diagrama de casos de uso do módulo Product Backlog...33 Figura 18. Diagrama de casos de uso do módulo controle de Sprint...34 Figura 19. Diagrama de classes de domínio...35 Figura 20 - Diagrama de entidade-relacionamento do banco de dados...37 Figura 21 - Framework ScriptCase...38 Figura 22. Tela inicial ScriptCase...39 Figura 23. Tela autenticação dos usuários na ferramenta...40 Figura 24. Menu da ferramenta Scrum Project para o perfil Scrum Master....41 Figura 25. Menu da ferramenta Scrum Project para o perfil Scrum Time....41 Figura 26. Menu da ferramenta Scrum Project para o perfil Product Owner...42 Figura 27. Cadastro de usuários...43 Figura 28 - Cadastro de times...44 Figura 29 - Cadastro de projetos...45 Figura 30 - Cadastro de Product Backlog...46 Figura 31 - Cadastro de Sprint Backlog...47 Figura 32 - Cadastro da Reunião de Planejamento...48 Figura 33 - Informar reunião diária...49 Figura 34 - Informar reunião de revisão...50 Figura 35 - Informar reunião de retrospectiva...51 Figura 36 - Consulta Sprint Backlog...52 v

LISTA DE TABELAS Tabela 1. Funcionalidades dos Softwares Avaliados e da Ferramenta Proposta...27 Tabela 2. Características Gerais dos Softwares Avaliados e da Ferramenta Proposta...28 vi

RESUMO Kluge, Monike Roberta. Scrum Project: ferramenta de apoio ao gerenciamento de projetos de software baseados nos princípios da metodologia ágil Scrum. Itajaí, 2008. 81 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2009. A área de Gerenciamento de Projetos há muito tempo, vem enfrentando problemas relativos a atrasos na entrega de projetos, orçamento extrapolado e insatisfação de clientes e usuários. Visando a atingir melhores resultados, as empresas estão adotando metodologias de desenvolvimento de software flexíveis a mudanças e que propiciem maior interação entre cliente e desenvolvedor. Essas metodologias, chamadas de ágeis, surgiram em oposição às metodologias tradicionais, orientadas para a produção de documentação. Entre as metodologias ágeis, destaca-se o Scrum, uma metodologia que tem, por objetivo, definir um processo de desenvolvimento de software de forma iterativa incremental e que pode ser aplicado no gerenciamento de atividades e desenvolvimento de novos produtos. Este Trabalho de Conclusão de Curso (TCC) apresenta o desenvolvimento de uma ferramenta de gerenciamento de projetos, denominada Scrum Project, que implementa os artefatos do Scrum e propicia o gerenciamento de projetos de forma ágil e flexível. Palavras-chave: Gerenciamento de Projetos. Metodologias Ágeis. Scrum. vii

ABSTRACT Since a long time, area of Project Management has been facing problems related to delays in delivering projects, exceeded budget, and dissatisfaction of customers and users. Seeking for achieving the best results, the companies are adopting methodologies of software development, which are flexible to changes and that may provide a greater interaction between the customer and the developer. These methodologies, called "agile", emerged opposing to traditional methodologies, which are geared towards the production of documentation. Among agile methodologies, one highlight is the Scrum, a methodology which aims at defining a process for software development in an iterative, incremental way that may be applied to the activities management and the development of new products. This Final Work presents the development of a tool for the projects management, called the Scrum Project, which implements the Scrum's artifacts and makes the projects management more agile and flexible. Keywords: Project Management. Agile Methodologies. Scrum. viii

1 INTRODUÇÃO O desafio constante da área de Engenharia de Software é melhorar o processo de desenvolvimento de software. Apesar da crescente evolução das técnicas, métodos e ferramentas, a entrega de softwares no prazo e custo pré-estabelecidos nem sempre é possível. Vários são os fatores que podem influenciar esse atraso, tais como: mudanças de escopo, saída de pessoas importantes, excesso de formalização da documentação, programadores inexperientes, alta taxa de erros, falhas de critérios de qualidade entre outros (COSTA FILHO et al, 2005). O sucesso na entrega de softwares é algo difícil de ser realizado. Desde 1994, o Standish Group International publica a cada dois anos um estudo nomeado de Chaos Research que consolida as informações de uma pesquisa sobre sucessos e fracassos dos projetos de software desenvolvidos com as mais diversas metodologias. Na última pesquisa divulgada (STANDISH, 2008) foram apontadas as seguintes conclusões: Em 1998, o número de projetos que terminaram no prazo, dentro do orçamento e atendendo aos requisitos do cliente era de 26%. Em 2006, o número de projetos aumentou para 35%; Em 1998 e 2008, o número de projetos finalizados e com software operacional entregue foi mensurado em 46%, porém nesses projetos, o orçamento e o prazo ultrapassam os limites estipulados; e Em 1998, o número de projetos cancelados era de 28%. Em 2008, esse número reduziu para 19%. Apesar do aumento significativo no número de projetos bem sucedidos, as somas da porcentagem dos projetos fracassados e comprometidos equivalem a 65% do total de projetos. Um aspecto que contribui para esse número é o fato de que a maior parte dos projetos desenvolvidos é baseada em metodologias tradicionais (FOWLER, 2003; LARMAN, 2004, apud COSTA FILHO et al, 2005). Segundo Soares (2004) os processos tradicionais, muito orientados para a produção de documentação, podem tornar-se fatores limitadores de desenvolvimento, dado que muitas organizações não possuem recursos e conhecimento para adotar processos complexos de produção de software. As metodologias tradicionais são aplicadas em situações em que os requisitos do sistema são estáveis com evoluções futuras previsíveis. Entretanto, muitos projetos caracterizam-se por

requisitos dinâmicos, estando sujeitos a freqüentes mudanças resultantes da dinâmica da organização (SOUZA NETO, 2004). Em oposição às metodologias tradicionais surgiram as Metodologias Ágeis, que proporcionam um desenvolvimento de software mais rápido, atendendo os requisitos do cliente, no prazo e custo e ainda permitem modificações à medida que novas necessidades surgem (COSTA FILHO et al, 2005). Segundo Soares (2004), ao contrário das metodologias tradicionais, as metodologias ágeis surgiram com a proposta de aumentar o foco nas pessoas e não no processo de desenvolvimento, além disso, existe a preocupação de gastar menos tempo com documentação e mais na resolução de problemas de forma iterativa. Entre as metodologias ágeis destaca-se o Scrum. Segundo Schwaber e Beedle (2002, apud PEREIRA, 2005), o Scrum é um processo iterativo e incremental de desenvolvimento de software. Utiliza técnicas simples unidas ao senso comum e baseadas em experiências passadas, já testadas e aprovadas. O uso do Scrum vai de encontro com a necessidade de pequenas empresas de desenvolvimento de software, pelo fato de ser simples, ágil e com o mínimo de burocracia. O uso da metodologia Scrum deve ser facilitado através da utilização de uma ferramenta que forneça o apoio necessário no desenvolvimento das atividades envolvidas nesse processo. Pelo fato do uso de metodologias ágeis serem um assunto relativamente novo, existem poucas ferramentas disponíveis que suportam o processo ágil de desenvolvimento utilizando Scrum. As ferramentas existentes no mercado são desenvolvidas em inglês e algumas não contemplam todas as funcionalidades definidas pelo Scrum. Diante desse cenário, esse trabalho propõe o desenvolvimento de uma ferramenta de apoio ao gerenciamento de projetos de software baseados nos princípios da metodologia ágil Scrum. Essa ferramenta deverá auxiliar os analistas e desenvolvedores de sistemas na implantação do Scrum de forma ágil e rápida, possibilitando ao gerente do projeto obter maior controle, integração entre cliente e desenvolvedor, acompanhar cada fase do projeto e possibilidade de alterar o escopo no momento em que necessite. 1.1 PROBLEMATIZAÇÃO 1.1.1 Formulação do Problema As empresas de software estão utilizando o Scrum como metodologia para gerenciamento de projetos, porém a inexistência de uma ferramenta que contemple os artefatos do Scrum obriga as empresas a gerenciarem seus projetos de forma manual, através de quadros informativos 2

preenchidos com post-its. As ferramentas existentes no mercado são desenvolvidas em inglês e algumas não contemplam todas as funcionalidades do Scrum. Já as ferramentas mais completas são pagas. 1.1.2 Solução Proposta A solução proposta nesse projeto é o desenvolvimento de uma ferramenta que apóie o desenvolvimento de projetos utilizando a metodologia Scrum. Essa ferramenta foi desenvolvida em português, baseada em software livre e de código fonte aberto para que outros desenvolvedores possam adaptá-la e atender as necessidades de sua empresa. 1.2 OBJETIVOS 1.2.1 Objetivo Geral Desenvolver uma ferramenta para gerenciamento de projetos baseada na metodologia ágil Scrum. 1.2.2 Objetivos Específicos Os objetivos específicos desse TCC são: Pesquisar e compreender detalhadamente a metodologia ágil Scrum; Pesquisar e analisar soluções de softwares similares; Estudar e aprender as ferramentas computacionais necessárias à implementação do sistema; Realizar a modelagem conceitual da ferramenta; Implementar a ferramenta; Testar e validar a implementação da ferramenta; e Documentar o desenvolvimento. 1.3 Metodologia Para o desenvolvimento da Fundamentação Teórica foram realizadas pesquisas buscando compreender os principais conceitos referentes às Metodologias Tradicionais, Ágeis e Scrum. Essas 3

pesquisas foram mais intensas na Metodologia Scrum, visando entender sua estrutura e fluxo de funcionamento. Foram estudadas algumas ferramentas existentes no mercado analisando suas características e quais artefatos do Scrum as mesmas possuem implementados. Essas pesquisas foram realizadas através de livros, artigos científicos, sites de busca e trabalhos acadêmicos. O desenvolvimento do Projeto foi iniciado com uma análise de todos os requisitos que a ferramenta deveria atender. Os requisitos foram identificados com base nas informações levantadas sobre o Scrum e no levantamento de carências das ferramentas existente. Após a identificação dos requisitos, foi realizada a modelagem do banco de dados, representada através de um diagrama Entidade-Relacionamento. Por último, foi descrito a implementação da ferramenta. As telas que a mesma apresenta suas funcionalidades e como é possível o gerenciamento de projetos através dessa ferramenta. 1.4 Estrutura do trabalho Este projeto esta estruturado em cinco capítulos: (i) Introdução; (ii) Fundamentação Teórica; (iii) Projeto; (iv) Desenvolvimento; e (v) Conclusões. O Capítulo 1 (Introdução) apresentou uma visão geral sobre o projeto desenvolvido, o problema encontrado e qual a solução proposta, os objetivos do TCC e sua metodologia de desenvolvimento. O Capítulo 2 (Fundamentação Teórica) apresenta conceitos dos temas necessários para o desenvolvimento do projeto: Processos de Software, Metodologias Tradicionais, Metodologias Ágeis, Scrum e estudo sobre as Ferramentas similares disponíveis. O Capítulo 3 (Projeto) especifica o projeto detalhado da ferramenta desenvolvida, incluindo requisitos elicitados, casos de uso, diagrama de classes e modelagem do banco de dados. O Capítulo 4 (Desenvolvimento) descreve como a ferramenta foi implementa, ilustrando suas telas e funcionalidades. O Capítulo 5 (Conclusões) apresenta as considerações finais do trabalho desenvolvido, dificuldades encontradas e sugestões de melhorias a serem realizadas na ferramenta com de intuito de dar continuidade ao trabalho. 4

2 FUNDAMENTAÇÃO TEÓRICA Neste capítulo é apresentada a revisão bibliográfica sobre o tema base desse presente projeto: a metodologia ágil Scrum. A seção 2.1 apresenta uma visão sobre processo de software expondo seu conceito e a diferença entre processo e método. Na seção 2.2 é apresentada uma breve discussão sobre metodologias tradicionais, expondo suas características, vantagens e desvantagens do seu uso. A seção 2.3 apresenta informações sobre as metodologias ágeis, expondo suas vantagens de utilização, crescimento de uso e principais características. Por fim, a seção 2.4 apresenta a metodologia ágil Scrum, suas características, sua relação com o Manifesto Ágil, seu funcionamento e as ferramentas utilizadas. 2.1 Processos de Software A engenharia de software é uma disciplina relacionada com os aspectos de produção de software, desde os estágios iniciais de especificação do sistema até sua manutenção (HELDMAN, 2005). Segundo Pressman (2006), a engenharia de software é dividida em camadas e tem como principal foco a qualidade do produto final gerado. A Figura 1 ilustra a divisão da engenharia de software. Figura 1. Camadas da Engenharia de Software Fonte: Adaptado de Pressman (2006). A primeira camada da engenharia de software se refere às ferramentas que fornecem apoio automatizado ou semi-automatizado para os processos e métodos. Segundo Pressman (1995, p. 32) quando as ferramentas são integradas de forma que a informação criada por uma ferramenta possa

ser usada por outra, é estabelecido um suporte ao desenvolvimento de software chamado engenharia de software auxiliada por computador - CASE. As ferramentas CASE auxiliam as atividades de engenharia de processos, desde análise de requisitos e modelagem até programação e testes. A camada de métodos de engenharia de software é uma representação abstrata das atividades, modelos e artefatos, fornecem a técnica de como fazer para construir software (PRESSMAN, 2006, p. 18), englobando um conjunto de tarefas que inclui análise de requisitos, projeto, construção de programas, teste e manutenção. Os métodos orientam os processos recomendando práticas mais adequadas e atividades a serem seguidas. O alicerce da engenharia de software é a camada de processo. O processo de engenharia de software é um conjunto de atividades realizadas por pessoas, cujo objetivo é o desenvolvimento ou aperfeiçoamento de um software e sua documentação (LEITE, 2008). Segundo Jacobson (apud PRESSMAN, 2006, p.19), um processo define quem está fazendo o quê, quando e como alcançar um certo objetivo. De acordo com Sommerville (2007), existem quatro atividades fundamentais que são comuns a todos os processos de software: 1. Especificação de software: clientes e engenheiros definem o software a ser produzido e suas restrições; 2. Desenvolvimento de software: o software é projetado e programado; 3. Validação de software: o software é verificado para garantir que atende o que o cliente deseja; e 4. Manutenção de software: o software é adaptado para atender as modificações do cliente e do mercado. Por fim, a base para todas as camadas da Engenharia de Software é o foco na qualidade do produto final gerado. A engenharia fornece métodos, processos e ferramentas de forma que o gerente de projeto possa garantir que o software será gerado com a qualidade desejada. Os processos de software são complexos e dependem da visão do gerente do projeto e do tipo de software que se deseja construir. Cada software, dependendo de sua finalidade, exige um processo de desenvolvimento diferente e, apesar da diversidade de modelos de processos de 6

software, não existe um processo ideal, forçando as empresas a realizarem adaptações para atender suas demandas de desenvolvimento. Alguns sistemas críticos necessitam de um processo de desenvolvimento estruturado, ou ditos burocráticos, outros sistemas de negócio possuem requisitos que mudam rapidamente exigindo um processo flexível e ágil (SOMMERVILLE, 2007). Dentre os processos de softwares existentes, podem ser citadas as metodologias tradicionais, que são orientadas a documentação, e as metodologias ágeis, que procuram desenvolver software com o mínimo de documentação (SOARES, 2004). 2.2 Metodologias Tradicionais As metodologias tradicionais surgiram em um contexto de desenvolvimento de software muito diferente do atual, baseado apenas em um mainframe e terminais burros 1. Na época o custo para realizar alterações e correções em programas era muito elevado, uma vez que o acesso aos computadores era limitado e não existiam ferramentas como depuradores e analisadores de código. Por isso o software era planejado por inteiro, documentado e por último programado (ROYCE, 1970, apud SOARES, 2004). A maior parte dos projetos, que utilizam metodologia tradicional, baseiam-se no modelo em cascata. A principal característica desse modelo é a separação das fases do projeto, que consistem em: levantamento de requisitos, modelagem, implementação, testes e implantação. Nesse modelo uma fase só inicia quando a anterior estiver pronta (RIBEIRO, 2008). A Figura 2 ilustra as fases do modelo em cascata e a dependência entre elas. 1 O termo terminal burro refere-se a terminais formados apenas por vídeo e teclado, que não possuem unidade de armazenamento e nem poder de processamento, ficando interconectados a um computador central, chamado de mainframe. Disponível em < http://www.versoereverso.unisinos.br/index.php?e=2&s=9&a=13 > Acesso em 10 jan. 2008. 7

Figura 2. Modelo em Cascata Fonte: Adaptado de Sommerville (2007). O modelo em cascata gera questionamentos com relação a sua eficácia, pois dificulta o controle do projeto. Entre os problemas encontrados no modelo em cascata estão (PRESSMAN, 2006): Projetos reais dificilmente seguem o fluxo seqüencial que o modelo propõe. A natureza linear do modelo em cascata leva a estados de bloqueio, nos quais alguns membros da equipe do projeto precisam esperar que outros membros terminem as atividades pendentes; Em geral, é difícil para o cliente definir todo o escopo do projeto na fase de levantamento de requisitos. O modelo em cascata exige isso e tem dificuldade para reagir com mudanças no escopo, pois a cada alteração é necessário retornar ao início do projeto para modificar a documentação; e A versão executável do projeto somente fica disponível no final do projeto. A vantagem do modelo em cascata é a documentação produzida em cada fase, porém esse modelo deve ser usado em projetos onde os requisitos são bem compreendidos e haja pouca probabilidade de mudanças durante o desenvolvimento do sistema (SOMMERVILLE, 2007). Como proposta para solucionar os problemas do modelo em cascata surgiu o Processo Unificado. Ivar Jacobson, Grady Booch e James Rumbaugh (apud PRESSMAN, 2006, p. 51) 8

discutem a necessidade de um processo de software guiado por casos de uso, centrado na arquitetura, iterativo e incremental quando afirmam: Hoje, a tendência em software é em direção a sistemas maiores, mais complexos. Isso se deve, em parte, ao fato de que computadores têm se tornado mais potentes a cada ano, levando os usuários a esperar mais deles. Essa tendência tem também sido influenciada pelo uso da internet, que está se expandindo, para trocar toda espécie de informação... Nosso apetite por softwares cada vez mais sofisticados cresce à medida que aprendemos de uma versão de um produto para a seguinte como o produto poderia ser aperfeiçoado. Desejamos softwares que sejam melhor adaptados às nossas necessidades, mas que, por sua vez, não torne o software somente mais complexo. Em resumo, desejamos mais. Um produto comercial baseado no processo unificado é o RUP (Rational Unified Process). O RUP, desenvolvido pela empresa Rational Software Corporation, é considerado um framework genérico que engloba as melhores práticas de mercado. Segundo Sommerville (2007), o RUP é um exemplo de modelo de processo moderno que foi derivado do trabalho sobre a UML e do Processo Unificado de Desenvolvimento associado. O objetivo do RUP é descrever um software usando técnicas comerciais visando aumentar a qualidade dos softwares gerados. Está fundamentado em três princípios básicos: Iterativo e Incremental; Guiado por casos de uso; e Baseado na arquitetura do sistema. O RUP é um modelo constituído por quatro fases que compõem o processo de desenvolvimento (FERREIRA, 2007): 1. Iniciação: nessa fase é estabelecido o escopo do projeto e suas fronteiras, determinando os principais casos de uso do sistema. Esses casos de uso devem ser elaborados com a precisão necessária para se proceder estimativas de prazos e custos. 2. Elaboração: o propósito nessa fase é analisar mais detalhadamente o domínio do problema, estabelecer uma arquitetura de fundação sólida, desenvolver um plano de projeto para o sistema a ser construído e eliminar os elementos que oferecem maior risco. Os elementos de risco a serem analisados, nesta fase, são os riscos de requisitos, tecnológicos, de recursos e políticos. Essa fase é a mais crítica de todas, pois ao final dessa fase a engenharia é considerada completa e os custos para modificação do sistema aumentam à medida que o projeto avança. 9

3. Construção: essa fase compreende a modelagem e desenvolvimento do sistema, tendo como base a arquitetura entregue na fase anterior. Essa fase geralmente é composta por diversas iterações, onde ao final de cada iteração tem uma parte executável do produto. 4. Transição: o objetivo dessa fase é assegurar que o software esteja disponível para a comunidade de usuários. Os usuários testam o software e geram relatórios contendo defeitos e modificações necessárias. Além disso, a equipe cria informações de apoio necessárias aos usuários (manual do usuário e procedimento de instalação). A Figura 3 ilustra as fases do desenvolvimento do RUP e as atividades desenvolvidas em cada fase. Figura 3. Fases do RUP Fonte: Ferreira (2007). No RUP as fases de desenvolvimento não ocorrem em seqüência, mas em paralelo. Isso significa que ao mesmo tempo em que as fases de elaboração, construção e transição estão sendo realizadas, uma nova fase de incremento de software já foi iniciada. (PRESSMAN, 2006). Embora o RUP represente uma nova geração de processos genéricos, ele não é um processo adequado a todos os tipos de desenvolvimento. Para projetos de software pequenos o RUP é um processo complexo e trabalhoso devido à quantidade de documentação gerada (SOMMERVILLE, 2007). 10

2.3 Metodologias Ágeis Atualmente os negócios operam em um ambiente global sujeito a rápidas mudanças. Eles têm de responder rapidamente às mudanças econômicas, oportunidades de mercado e ao surgimento de novos produtos e serviços. O software é parte integrante das operações de negócio, sendo assim, é essencial que o software seja desenvolvido ou modificado de forma rápida e eficiente para suprir as novas necessidades impostas pelos avanços do mercado (SOMMERVILLE, 2007). Segundo Sommerville (2007, p.260): Os processos de desenvolvimento de software baseados em especificações completas de requisitos, projeto, construção e teste não estão voltados para o desenvolvimento rápido de software. Quando os requisitos são alterados ou quando problemas com requisitos são descobertos, o projeto ou implementação precisa ser refeito e testado novamente. Como conseqüência, um processo em cascata ou baseado em especificações é geralmente prolongado e a versão final do software é entregue para o cliente muito tempo depois dos requisitos serem definidos, o que poderá tornar o software inútil. Para enfrentar esses desafios encontrados pelos desenvolvedores de software, um grupo de 17 metodologistas formou a Agile Software Development Alliance, freqüentemente citada apenas como Agile Alliance, em fevereiro de 2001. Esse grupo de pessoas definiu um manifesto com as melhoras práticas de desenvolvimento de software e, com base nesse manifesto formulou um conjunto de princípios que definem critérios para o desenvolvimento ágil de software, a partir dessas definições surgiu o termo Metodologia Ágil (AGILE MANIFESTO, 2008). Os conceitos do Manifesto Ágil são (AMBLER, 2004): Indivíduos e interações ao invés de processos e ferramentas; Software executável ao invés de documentação; Colaboração do cliente ao invés de negociação de contratos; e Respostas rápidas a mudanças ao invés de seguir planos. O Manifesto Ágil não rejeita processos, ferramentas, documentação e planejamento, mas mostra que eles têm importância secundária quando comparado com indivíduos e interações, com o software estar executando corretamente, com a colaboração do cliente e as respostas rápidas a mudanças e alterações (SOUZA NETO, 2004). O conceito de metodologia ágil é mais adequado para a execução de projetos de curta duração em pequenas e médias empresas. Entre os métodos ágeis existentes podem-se citar: Extreme Programming (XP), Scrum, Dynamic System Development Method (DSDM), Adaptive Software Development (ASD), Crystal, 11

Feature Driven Development (FDD) e Lean Development. Uma pesquisa realizada sobre o estado do desenvolvimento ágil indica que 40% dos entrevistados utilizam Scrum como metodologia base (VERSIONONE, 2007 apud TAVARES, 2008). A Figura 4 mostra o percentual de adoção do Scrum quando comparado com outras metodologias ágeis. Figura 4. Adoção do Scrum Fonte: Yoshima (2007). Métodos, práticas e técnicas para o desenvolvimento ágil de projetos prometem aumentar a satisfação do cliente (BOEHM, 2003) para produzir alta qualidade de software e para acelerar os prazos de desenvolvimento de projetos. Empresas como a Rede Globo de televisão, Microsoft, Google, Yahoo, Nokia, BBC, CESAR, Philips, adotaram o Scrum para desenvolvimento de software e o resultado obtido foi vantajoso (BERNABO, 2007). O Scrum é um método ágil que vem ganhando grande visibilidade nos últimos cinco anos, em projetos de desenvolvimento de software, ressaltando benefícios como comprometimento da equipe, motivação, colaboração, integração e compartilhamento de conhecimento, o que facilita em muito o gerenciamento e sucesso dos projetos (SCHWABER, 2004, apud MARÇAL et al., 2007). Por esses motivos, este método foi escolhido como objeto de estudo deste trabalho de conclusão de curso e é melhor detalhado nos itens a seguir. 2.4 Scrum O Scrum é uma metodologia ágil utilizada para gerenciar e controlar o desenvolvimento de software utilizando práticas iterativas e incrementais. Baseado nas práticas de gerenciamento do 12

Extreme Programming e no RUP, o Scrum produz os benefícios do desenvolvimento ágil com a vantagem de ser uma implementação simples (YOSHIMA, 2007). Inicialmente o Scrum foi concebido como um estilo de gerenciamento de projetos, em empresas de fabricação de automóveis e produtos de consumo, por Hirotaka Takeuchi e Ikujiro Nonaka no livro The New Product Development Game (Harvard Business Review, 1986). Eles notaram que projetos usando equipes pequenas e multidisciplinares produziam os melhores resultados, e associaram estas equipes altamente eficazes à formação do Scrum no Rugby 2. A primeira experiência reconhecida do Scrum foi realizada em 1993 por Jeff Shuterland que implementou em sua organização, a Easel Corporation, um processo baseado na formação do Rugby e nos estudos de Nanaka e Takeuchi. Em 1995, Ken Schwaber formalizou a definição do Scrum e ajudou a implantá-lo em desenvolvimento de software (MACEDO e DESCHAMPS, 2008). Scrum é uma metodologia objetiva, com papéis bem definidos e de fácil adaptação. Segundo o seu autor Schwaber (2004, apud MARÇAL et al., 2007) o Scrum não é um processo previsível, ele não diz exatamente o que fazer, não irá resolver todos os problemas, mas com certeza os problemas serão mais facilmente identificados através do framework e do conjunto de práticas oferecidos. O framework do Scrum é composto em papéis, cerimônias e artefatos. A Figura 5 ilustra as atividades que compõe cada item do framework. 2 Rugby é um jogo praticado na Inglaterra, composto por oito jogadores em cada time. O Scrum é um termo utilizado no Rugby e consiste em colocar a bola em jogo novamente através do trabalho em equipe. 13

Figura 5. Framework do Scrum Fonte: Bernabo (2007). 2.4.1 Papéis no Scrum O Scrum, como qualquer outra metodologia, é baseado em papéis e responsabilidades, sendo, estas mais abrangentes e direcionadas para atingir o sucesso do projeto (YOSHIMA, 2007). A metodologia Scrum define basicamente três papéis: Product Owner, Scrum Master e Scrum Team, apresentados a seguir (MARÇAL et al., 2007). 2.4.1.1 Product Owner Product Owner significa dono do produto. É o cliente ou um importante interessado do projeto, que representa os interesses de todos os envolvidos com o software. Suas principais responsabilidades são (MARÇAL et al., 2007): Definir as características e funcionalidades do produto; Concentrar as informações vindas das pessoas envolvidas no projeto ou do mercado, de maneira que se obtenha uma visão única dos requisitos do sistema; A maior responsabilidade é o ROI (Return on Investment) do projeto; Priorizar as funcionalidades do projeto de acordo com as necessidades dos usuários; Solicitar alterações a serem implementadas nas próximas iterações; e Aceitar ou rejeitar os resultados de cada iteração. 14

2.4.1.2 Scrum Master O Scrum Master desempenha um papel de liderança, gerenciando os interesses do Product Owner mediante o time. Comparando com uma abordagem tradicional de gerenciamento de projetos, o Scrum Master seria um gerente de projetos. O Scrum Master possui como responsabilidades (YOSHIMA, 2007): Promover a criatividade e conhecimento do time visando aumento de produtividade; Estimular uma comunicação cooperação entre as pessoas do time; Garantir o desenvolvimento do projeto no prazo e custo; Realizar reuniões de acompanhamento (Daily Scrum, Sprint, Review e Sprint Retrospective); Auxiliar o Product Owner a maximizar a produtividade atingindo os seus objetivos com o Scrum; Facilitar a colaboração entre as funções e áreas e eliminar os impedimentos do time; Proteger o time de interferências externas; Controlar as tarefas realizadas, em andamento, concluídas e o surgimento de novas tarefas; e Atualizar o Burndown Chart. 2.4.1.3 Scrum Team O Scrum Team é um grupo de pessoas responsável em desenvolver as funcionalidades do projeto. Suas características são (MARÇAL et al., 2007): Multi-funcional e auto-organizável. O time deve ter capacidade e o conhecimento técnico sobre todo o processo de desenvolvimento do produto; Entre 7 a 9 pessoas; Seleciona, entre os itens priorizados, os que serão executados durante cada iteração; e Demonstra as funcionalidades do produto e os resultados obtidos ao Product Ower. 15

2.4.2 Estrutura do Processo Scrum O Scrum define conceitos importantes referentes à aplicação da metodologia no desenvolvimento do projeto. Esses conceitos fundamentam práticas para definir a estratégia de desenvolvimento do projeto e fornecem visibilidade do andamento dos trabalhos e previsibilidade do que acontecerá. A Figura 6 ilustra o fluxo de desenvolvimento no Scrum (YOSHIMA, 2007). O fluxo no Scrum inicia com a definição da lista de funcionalidades que deverão ser implementadas, essa lista é chamada de Product Backlog. Para cada iteração ou Sprint, é realizada uma reunião inicial de planejamento chamada de Sprint Planning Meeting, onde os itens desta lista são priorizados pelo cliente, no Scrum chamado de Product Owner. A equipe define quais funcionalidades poderão ser atendidas dentro da iteração de acordo com a capacidade da mesma. Essa lista planejada para a iteração é chamada de Sprint Backlog (TAVARES, 2008). Diariamente, durante a Sprint, a equipe faz uma reunião chamada Daily Meeting que ajuda a manter a comunicação do time sobre o andamento do projeto, disseminar conhecimento e identificar impedimentos. No final de cada Sprint, na reunião chamada Sprint Review, a equipe apresenta as funcionalidades que foram desenvolvidas durante a Sprint. Esse ciclo se repete várias vezes até que o Product Backlog seja atendido (TAVARES, 2008). Esses conceitos são melhor apresentados na seções a seguir. Figura 6. Fluxo do Scrum Fonte: Pereira (2008). 16

2.4.2.1 Sprint O Scrum é baseado em iterações chamadas de Sprints. As Sprints podem ter de duas a quatro semanas de duração e, ao final desse período uma parte do projeto é demonstrada ao Scrum Owner. Essa demonstração é importante para avaliar o andamento do projeto, verificar se os requisitos exigidos estão sendo desenvolvidos e avaliar a produtividade da equipe (MARÇAL et al., 2007). 2.4.2.2 Time Boxing O Time Boxing é todo um espaço de tempo definido e cronometrado que faz com que a equipe se concentre nas atividades importantes, sem gastar tempo com tarefas desnecessárias para o objetivo. Por exemplo, um Sprint com período de 30 dias ou reuniões diárias de 15 minutos representam um Time Box, ou seja, o tempo definido para execução de cada tarefa no Scrum (YOSHIMA, 2007). 2.4.2.3 Product Backlog O conceito mais importante no Scrum é o Backlog do produto (Product Backlog). O Product Backlog contém uma lista de itens definidos e priorizados pelo Product Owner, que incluem os requisitos funcionais e não funcionais de um sistema. Os itens do Product Backlog são chamados de histórias e todos os envolvidos no projeto podem inclui-lás, porém somente o Product Owner pode priorizá-las. Essa lista não precisa ser definida por completa no início do projeto, podendo ser complementada com novas funcionalidades à medida que aumenta o conhecimento no produto. Normalmente, no início do projeto, essa lista contém somente os itens necessários para o desenvolvimento do primeiro Sprint. A ordenação da lista Product Backlog é por ordem de prioridade, ou seja, no topo da lista estão os itens mais prioritários (TAVARES, 2008). Outro item importante do Scrum é o Backlog de Impedimentos (Impediment Backlog), uma lista que contém todos os itens que impedem o progresso do projeto e geralmente estão associados a riscos. Estes itens não possuem uma priorização, mas estão associados a algum item de Backlog do produto ou a tarefas do item. O Scrum Master deve ter controle sobre esses itens, possibilitando ao time desenvolver o Backlog do produto sem impedimentos (MARÇAL et al., 2007). A Figura 7 exemplifica itens do Product Backlog que deverão ser priorizados e estimados pelo Product Owner e pela equipe do projeto respectivamente. 17

Figura 7. Product Backlog Fonte: Albuquerque (2007). 2.4.2.4 Priorização do Product Backlog pelo Product Owner Após o desenvolvimento do Backlog do Produto os itens devem ser priorizados. A Figura 8 ilustra um exemplo de priorização baseado na importância dos itens do Backlog para o Product Owner. Esse método de priorização é nomeado por alguns autores como método MoSCoW Must, Should, Could, Want, e consiste em numerar os requisitos de acordo com sua importância (ALBUQUERQUE, 2007). Figura 8. Priorização do Product Backlog Fonte: Albuquerque (2007). 18

Outra forma de priorizar os requisitos consiste em numerar os itens de acordo com a sua importância. A Figura 9 ilustra a importância dos requisitos usados como exemplo na Figura 8 (os itens de menor valor são os mais importantes). Figura 9. Importância do Product Backlog Fonte: Albuquerque (2007). 2.4.2.5 Estimativa do Product Backlog Antes de iniciar a reunião do planejamento é preciso ter o Backlog priorizado e estimado. Uma técnica objetiva é o Planning Poker que pode ser usada onde a estimativa pode ser feita em horas/tamanho (MARÇAL et al., 2007). O Planning Poker é uma forma de estimativa em conjunto, podendo ser feita como um jogo. Todos os membros do time, inclusive o Product Owner, participam de forma democrática para chegar a um consenso de estimativa, para cada item do Backlog. O primeiro passo do jogo é fornecer para cada membro da equipe um conjunto de cartas baseado na seqüência numérica de Fibonacci (1,2,3,5,8,13,..). A escolha dessa seqüência esta ligada aos gaps que são maiores à medida que os números aumentam, ou seja, os números maiores têm menos granularidade, deixando visível a diferença entre os itens à medida que eles se distanciam (ALBUQUERQUE, 2007). O jogo é iniciado selecionando o item do Backlog que o Product Owner e o time acreditam que seja o mais fácil de implementar, e a ele é associado o menor número da seqüência. Depois o próximo item é selecionado, e é comparando o seu grau de dificuldade com os dos itens já estimados. Nesse momento cada membro da equipe seleciona uma carta que represente o grau de dificuldade associado ao item e espera até que os outros participantes terminem suas seleções. 19

Quando todos terminaram as cartas são exibidas e se houver um consenso geral nas seleções feitas, o número da carta que corresponde ao tamanho é associado ao item. Em caso de divergência, é necessário que os participantes expliquem o motivo de sua escolha, para que todos possam repensar e validar a sua escolha. Após a finalização dessa discussão, uma nova rodada é realizada para que todos tenham oportunidade de reavaliar seus julgamentos. Esse processo continua até que os membros participantes seguem em um consenso. O Scrum Master é responsável em organizar as discussões para que sejam produtivas e organizadas. Esse ciclo é seguido até que todos os itens do Backlog sejam estimados (MARÇAL et al., 2007). A Figura 10 ilustra uma equipe estimando, através do Planning Poker, valores para cada história do Product Backlog. Figura 10. Estimando o Product Backlog através do Planning Poker Fonte: Pereira (2008). 2.4.2.6 Sprint Backlog É uma lista que contém as tarefas que o Scrum Team irá trabalhar durante a Sprint. Os itens do Product Backlog, priorizados pelo Product Owner, são quebrados em tarefas que formam o Sprint Backlog. Cada tarefa deve ser estimada pela equipe quanto ao número de horas necessário para completá-la, normalmente as tarefas são completadas em até 16 horas. É responsabilidade da equipe manter a lista atualizada diariamente com as tarefas concluídas, e a estimativa de tempo necessário para a conclusão das tarefas em andamento (TAVARES, 2008). 20

2.4.2.7 Execução da Sprint Uma Sprint inicia com um dia de planejamento que ocorre em duas partes. Nesse dia todos os envolvidos no projeto planejam quais serão os objetivos a serem realizados nos próximos 28 dias (caso a Sprint tenha 30 dias). Após o planejamento a equipe trabalha no desenvolvimento do projeto. No último dia da Sprint, o produto desenvolvido pelo time é avaliado juntamente com o Product Owner e uma reunião de Retrospectiva é realizada, com o intuito de discutir as lições apreendidas e definir ajustes necessários ao processo. A Figura 11 ilustra a estrutura de execução de uma Sprint e seus conceitos são discutidos a seguir (YOSHIMA, 2007). Figura 11. Estrutura de uma Sprint Fonte: Yoshima (2007). 2.4.2.8 Planejamento da Sprint (Sprint Planning Meeting) A reunião de planejamento da Sprint é a primeira reunião que ocorre e acontece em duas partes, cada uma dela com Time-Box de quatro horas. Na primeira parte da reunião de planejamento o Scrum Master reúne-se com o Product Owner para verificar qual é o Product Backlog, focando no ROI (Retorno sobre Investimento) do projeto. Na segunda parte do planejamento o Scrum Master se reúne com o time e com o Product Owner para planejar o Sprint Backlog. Para escolher os itens que irão compor o Sprint Backlog a equipe estima o Product Backlog, definindo complexidade e prazo das tarefas (YOSHIMA, 2007). A Figura 12 ilustra a Reunião de Planejamento da Sprint e as atividades desenvolvidas em cada parte. 21

Figura 12. Planejamento da Sprint Fonte: Pereira (2008). 2.4.2.9 Gerenciamento da Sprint Backlog Durante a execução da Sprint, a alocação de recursos para cada tarefa é dirigida pelo próprio time, cada membro da equipe seleciona as tarefas que podem realizar e o time estabelece a ordem e dependência entre elas. Um fator importante de sucesso para o time com o uso do Scrum é o controle da disciplina. O time é considerado auto-gerenciável, e deve responder como tal. Para isto todos os membros do time devem reportar as horas utilizadas em tarefas para que o valor de horas restantes seja calculado corretamente e o time possa verificar o seu progresso. Para esse acompanhamento o time usa um gráfico chamado de Sprint Burndown. O Sprint Burndown exibe o progresso diário do time em função do total de horas estabelecido e é explicado a seguir (YOSHIMA, 2007). A Figura 13 mostra uma maneira de controlar a execução dos itens da Sprint Backlog através do uso de um quadro de trabalho. O objetivo é organizar as atividades dos itens do Sprint Backlog em quatro estados: para fazer, em andamento, para verificar e concluído (MARÇAL et al., 2007). 22

Figura 13. Controle da Sprint Backlog Fonte: Pereira (2008). 2.4.2.10 Burndown Chart O gráfico de Burndown é o principal artefato para acompanhamento do andamento da Sprint. Ele é gerado com base nas atualizações diárias da equipe com o status das tarefas, e no número de horas restantes para a conclusão de cada tarefa. A soma de horas das tarefas determina a quantidade de horas necessárias para finalizar a Sprint, e conforme as tarefas são concluídas, o gráfico vai decrescendo até atingir o número de horas zero. O eixo Y representa o número total de horas estimado para a Sprint e o eixo X os dias da Sprint, de acordo com o seu tamanho. As Figura 14 e 15 representam exemplos de Burndown Charts (TAVARES, 2008). 23

Figura 14. Burndown Charts dias/horas Fonte: Pereira (2008). Figura 15. Burndown Charts Sprint /estimativa Fonte: Albuquerque (2007). 2.4.2.11 Reunião Diária (Daily Meeting) Durante a Sprint o time controla o progresso de execução das tarefas através de reuniões diárias. Essa reunião é rápida, não mais do que 15 minutos, e o objetivo é fazer com que cada membro do time responda as seguintes perguntas feitas pelo Scrum Master (ALBUQUERQUE, 2007): O que foi feito desde ontem?; O que você planeja fazer para amanhã?; e 24

Você tem algum impedimento?. A reunião tem por objetivo auxiliar o Scrum Master na verificação do andamento do trabalho, manter a comunicação e sincronização do status do projeto entre os membros da equipe (YOSHIMA, 2007). 2.4.2.12 Reunião de Revisão (Sprint Review) A Sprint Review é um importante ponto de inspeção da metodologia Scrum. Essa reunião de fechamento ocorre no último dia da Sprint e representa o momento em que a equipe e o Scrum Master demonstram as funcionalidades implantadas ao Product Owner. Essa reunião é importante, pois auxilia na correção de erros do projeto antes do início da nova Sprint (YOSHIMA, 2007). 2.4.2.13 Reunião de Retrospectiva (Sprint Retrospective) Ao final de cada Sprint acontece a reunião de revisão. O objetivo dessa reunião é entregar o produto e realizar uma demonstração para que o Product Owner possa verificar se o produto produzido está de acordo com suas expectativas. Nessa reunião se discute como foi o desenvolvimento da Sprint e o que precisa ser melhorado (ALBUQUERQUE, 2007). 2.4.3 Ciclo de Vida do Scrum O ciclo de vida do Scrum é baseado em três fases (SOUZA NETO, 2004): 1. Pré-Planejamento (pre-game phase): nessa fase os requisitos são descritos e priorizados no Product Backlog, a estimativa de esforço para cada requisito é realizada, definição da equipe, definição das ferramentas de desenvolvimento e estimativa de riscos do projeto; 2. Desenvolvimento (game phase): nessa fase ocorre o desenvolvimento iterativo e incremental das funcionalidades do produto através de múltiplas Sprints, reuniões diárias e de revisão; e 3. Pós- Planejamento (post-game phase): após a fase de desenvolvimento são realizadas reuniões para analisar o progresso do projeto e demonstrar o software atual para o 25

Product Owner. Nessa fase são realizadas as etapas de integração, testes e documentação. 2.4.4 Ferramentas O uso do Scrum é recente, por isso o mercado dispõe de poucas ferramentas. Dentre as ferramentas encontradas destacam-se: 1. Mingle; 2. Scrinch; 3. Scrum Works; e 4. ProjectKoach. A Mingle é uma ferramenta desenvolvida pelo grupo ThoughtWorks 3, uma empresa líder em desenvolvimento ágil. Entre suas funcionalidades pode-se destacar: planejamento do projeto, desenvolvimento do Product Backlog e Sprint Backlog, reuniões diárias e revisões, métricas de acompanhamento utilizando Burndown Chart, controle de velocidade de desenvolvimento, estimativas, entre outras. O Mingle é uma ótima ferramenta para gerenciamento de projetos com Scrum, porém é desenvolvida em inglês e o valor de sua licença varia de acordo com o tempo de uso e o número de usuários. O Scrinch é uma ferramenta desenvolvida em Java e distribuída pela SourceFourge 4. A ferramenta é gratuita, porém desenvolvida em inglês e com interface de difícil utilização. Suas funcionalidades contemplam: desenvolvimento do Product Backlog e Sprint Backlog, definição do time de desenvolvedores, definição do Time Boxing da Sprint, controle de velocidade, priorização e estimativa do Product Backlog, entre outras. O ScrumWorks é uma ferramenta desenvolvida pela empresa Danube 5. Existem duas versões dessa ferramenta disponíveis: ScrumWorks Pro (versão paga) e Scrum Works Basic (versão grátis). A ferramenta paga possui as funcionalidades básicas do Scrum, porém é desenvolvida em inglês. 3 Mingle. Disponível em <http://studios.thoughtworks.com/mingle-agile-project-management/>. Acesso em 24 out. 2008. 4 Sprinch. Disponível em < http://sourceforge.net/projects/scrinch >. Acesso em 24 out. 2008. 5 Scrum Works. Disponível em <http://danube.com/scrumworks> Acesso em 24 out. 2008. 26

A ferramenta ProjectKoach é desenvolvida pela Good Software Inc 6, é gratuita e de fácil utilização, porém seu idioma é o inglês. Entre suas funcionalidades destacam-se: planejamento de Sprints, inclusão de tarefas, estimativa de tempo de duração de cada tarefa e definição do time. Essa ferramenta não contempla todas as funcionalidades do Scrum, como por exemplo, Burndown Chart, reuniões diárias, revisão e planejamento da Sprint. Essa ferramenta evidencia o controle do escopo do projeto. Os softwares testados foram o Scrinch, o ProjectKoach e a versão grátis do Mingle. O ScrumWorks Basic foi instalado, mas exige certificado de licença para o funcionamento pleno. Esse certificado foi solicitado, porém a Danube não enviou a resposta com a autorização para utilização do aplicativo. As Tabela 1 e 2 demonstram a análise realizada com as principais funcionalidades avaliadas e também requisitos não funcionais. Além dos softwares avaliados, a tabelas contêm a solução proposta pelo presente TCC. O softwares ScrumWorks está sendo avaliado de acordo com as informações fornecidas no site do aplicativo. Tabela 1. Funcionalidades dos Softwares Avaliados e da Ferramenta Proposta Ferramenta Criação de Sprints Criação Product Backlog Criação Sprint Backlog Prioriza estima Tarefas Criação de Time Burndown Chart Mingle Sim Sim Sim Sim Não Sim Scrinch Sim Não Sim Sim Sim Sim Scrum Works Sim Sim Sim Sim Sim Não Identificado ProjectKoach Sim Não Sim Não Sim Não Ferramenta Proposta Sim Sim Sim Sim Sim Não 6 ProjectKoach. Disponível em <http://www.projectkoach.com/>. Acesso em 24 out. 2008. 27

Tabela 2. Características Gerais dos Softwares Avaliados e da Ferramenta Proposta Ferramenta Software Gratuito Plataforma Web Língua Portuguesa Mingle Não Sim Não Scrinch Sim Não Não Scrum Works Sim Sim Não ProjectKoach Sim Não Não Ferramenta Proposta Sim Sim Sim Através do estudo das ferramentas, foi possível identificar que as ferramentas disponíveis no mercado não contemplam todas as atividades necessárias para gerenciamento de projetos utilizando a metodologia Scrum. A ferramenta proposta, além de conter todos os artefatos do Scrum, tem como diferencial as seguintes características: será um software gratuito, código fonte aberto, voltado para a web e na língua portuguesa. 28

3 PROJETO A primeira atividade realizada durante a fase de Projeto foi a análise dos requisitos funcionais, não funcionais e regras de negócio que devem ser atendidos pela ferramenta. Os requisitos foram levantados com base na fundamentação teórica e no estudo das ferramentas similares, realizada no Capítulo 2. Em seguida, os casos de uso foram definidos com base nas principais operações desenvolvidas pelo usuário. Por últimos os diagramas de classes e entidade-relacionamento foram construídos. 3.1 Análise de Requisitos Durante a etapa de modelagem, realizada no TCCI, a análise dos requisitos teve o objetivo de identificar o escopo do projeto e definir as funcionalidades que o sistema deveria atender. Nessa análise, os requisitos funcionais, os não funcionais e as regras de negócio foram elicitados, documentados e analisados. Para o desenvolvimento do TCCII esses requisitos foram refinados e implementados na ferramenta, originando operações que podem ser realizadas pelo usuário. As seções seguintes apresentam o resultado desse trabalho. 3.1.1 Requisitos Funcionais Os requisitos funcionais descrevem o funcionamento do sistema e abrangem as tarefas que ele disponibilizará aos usuários. Para maior entendimento e dimensão da ferramenta, os requisitos funcionais foram divididos em três módulos: Projeto e Time, Product Backlog e Sprint. Na etapa de análise os seguintes requisitos funcionais foram identificados: Projeto e Time RF01: O sistema deverá permitir cadastrar, alterar e excluir um projeto; RF02: O sistema deverá permitir cadastrar, alterar e excluir usuários; e RF03: O sistema deverá permitir cadastrar, alterar e excluir um time. 29

Product Backlog RF01: O sistema deverá permitir cadastrar, alterar e excluir itens em um Product Backlog; RF02: O sistema deverá permitir priorizar os itens de um Product Backlog; RF03: O sistema deverá permitir estimar os itens de um Product Backlog; e RF04: O sistema deverá permitir cadastrar, alterar e excluir um Impediment Backlog para um item do Product Backlog. Sprint RF01: O sistema deverá permitir cadastrar e excluir uma Sprint para um projeto; RF02: O sistema deverá permitir informar a data de início e fim de uma Sprint; RF03: O sistema deverá permitir selecionar os itens do Product Backlog que irão compor a Sprint Backlog; RF04: O sistema deverá permitir cadastrar, alterar e excluir tarefas em uma Sprint Backlog; RF05: O sistema deverá permitir alocação de uma tarefa a um membro do time; RF06: O sistema deverá permitir informar a data de início e fim de cada tarefa; RF07: O sistema deverá permitir informar o tempo de duração de cada tarefa; RF08: O sistema deverá permitir informar horas trabalhadas e o status do andamento em cada tarefa; RF09: O sistema deverá permitir inserir informações sobre a reunião diária; RF10: O sistema deverá permitir inserir informações sobre a reunião de planejamento; RF11: O sistema deverá permitir inserir informações sobre a reunião de revisão; e RF12: O sistema deverá permitir inserir informações sobre a reunião de retrospectiva. 3.1.2 Requisitos Não Funcionais Os requisitos não funcionais especificam as características do software, neste caso, a linguagem de programação, o banco de dados e a plataforma utilizados. 30

RNF01: O sistema deve ser voltado para WEB; RNF02: O sistema deve ser desenvolvido na linguagem de programação PHP; RNF03: O sistema utilizará o Banco de Dados PostgreSQL; e RNF04: O sistema deverá solicitar ao usuário login e senha de acesso. 3.1.3 Regras de Negócio As regras de negócio definem as particularidades do funcionamento da ferramenta: RN01: O Scrum é composto por três papéis: Product Owner, Scrum Master e Scrum Team; RN02: As Sprints devem ter de 2 a 4 semanas de duração; RN03: Ao final de cada Sprint uma parte do produto deverá ser entregue; e RN04: A estimativa do Product Backlog será realizada baseando na seqüência numérica de Fibonacci. 3.2 Diagrama de Casos de Uso Os casos de uso melhoram a compreensão da análise dos requisitos, são documentos narrativos que descrevem a seqüência de eventos de um ator que usa um sistema para completar um processo (JACOBSON et al, 1992, apud LARMAN, 2000). Os casos de uso do sistema desenvolvido foram organizados em três módulos, a fim de facilitar o entendimento da modelagem. A seguir são apresentados os módulos que compõem o sistema, sendo a descrição de cada caso de uso apresentada no Apêndice A. 3.2.1 Módulo Projeto Esse módulo permite ao usuário gerenciar os cadastros básicos para iniciar as atividades na ferramenta e cadastrar, alterar ou excluir um projeto. A Figura 16 mostra a interação entre o usuário (ator) e os casos de uso que constituem esse módulo. Antes de iniciar um projeto é necessário que os usuários, cargos dos usuários e o time do projeto estejam cadastrados. 31

uc Pacote 1 - Módulo Proj... UC 01.01 - Manter Usuário UC 01.03 - Manter Projeto UC 01.02 - Manter Time Scrum Master Figura 16. Diagrama de casos de uso do módulo Projeto 3.2.2 Módulo Product Backlog Esse módulo permite ao usuário o gerenciamento do Product Backlog do projeto. O Product Owner e o Scrum Master possuem como tarefas o gerenciamento e priorização do Product Backlog e Impediment Backlog. A estimativa do Product Backlog é realizada por todos os elementos do grupo. A Figura 17 ilustra esse módulo e as principais atividades desenvolvidas. 32

uc Pacote 2 - Product Backlog UC 02.01 - Gerenciar Product Backlog UC 02.02 - Gerenciar Impediment Backlog Product Ow ner Scrum Master UC 02.03 - Estimar Product Backlog Scrum Team Figura 17. Diagrama de casos de uso do módulo Product Backlog 3.2.3 Módulo Controle de Sprint A Figura 18 mostra as atividades desenvolvidas no módulo Controle de Sprint. Os responsáveis por esse módulo são o Scrum Master e o Scrum Team. É função do Scrum Master gerenciar a Sprint, selecionar os itens do Product Backlog que irão compor o Sprint Backlog, acompanhar o andamento do projeto através da visualização do gráfico Burndown e auxiliar o Scrum Time a cadastrar as tarefas para cada item do Product Backlog. A função do Scrum Team é gerenciar cada tarefa, ou seja, alocar a tarefa a um membro do grupo, estimar sua duração, informar horas trabalhadas por semana e a situação da tarefa (não iniciada, em desenvolvimento, finalizada, em testes ou pendente) e gerenciar as reuniões diárias. 33

uc Controle de Sprint UC 03.10 - UC 03.09 - Gerenciar Reunião de Rev isão UC 03.11 - Gerenciar Reunião de Planejamento UC 03.01 - Cadastrar Sprint UC 03.09 - Gerenciar Reunião de Retrospectiv a Scrum Master UC 03.02 - Selecionar Itens do Product Backlog UC 03.03 - Cadastrar tarefas UC 03.08 - Gerenciar Reunião Diária UC 03.04 - AlocarTarefa Scrum Team UC 03.07 - Informar Status da Tarefa UC 03.05 - Informar Duração de Cada Tarefa UC 03.06 - Informar Horas Trabalhadas em Cada Tarefa Figura 18. Diagrama de casos de uso do módulo controle de Sprint 34

3.3 Diagrama de Classes Segundo Furlan (1998), o diagrama de classes trata-se de uma estrutura lógica estática em uma superfície de duas dimensões mostrando uma coleção de elementos declarativos de modelo, como classes, tipos e seus respectivos conteúdos e relações. A Figura 19 mostra o diagrama de classes da ferramenta proposta. class Scrum Project Projeto - Nome_Projeto: varchar - Objetivo_Projeto: varchar - Data_Inicio: date - Data_Fim: date - Valor_Projeto: decimal + Incluir_Projeto() : void + Atualizar_Projeto() : void + Deletar_Projeto() : void 1 1 1..* 1 Time - Descrição: varchar - Código_Usuário: int - Nome_Usuário: varchar - Nome_Cargo: varchar + Incluir_Time() : void + Atualizar_Time() : void + Deletar_Time() : void + Incluir_Usuario_Time() : void 0..* 1 0..* 1..* Usuários - Nome: varchar - Data_Nasc.: date - RG: varchar - CPF: varchar - Endereço: varchar - Bairro: varchar - Cidade: varchar - CEP: integer - Estado: varchar - Telefone: varchar - Celular: varchar - E-Mail: varchar - Login: varchar - Senha: varchar + Incluir_Usuário() : void + Atualizar_Usuário() : void + Deletar_Usuário() : void Product Backlog - Projeto: varchar - Item_Product_Backlog: varchar - Prioridade: int - Estimativa: int - Fator_Impedimento: varchar + Incluir_Product() : void + Alterar_Product() : void + Deletar_Product() : void 1..* 1 0..* Sprint Backlog - Item_Product: varchar - Tarefa: varchar - Responsavel: varchar - Data_Inicio: date - Data_Fim: date - Horas_Estimadas: int - Semana_1: int - Semana_2: int - Semana_3: int - Semana_4: int - Status: varchar + Cadastrar_Sprint_Back() : void + Gerenciar_Tarefas() : void 0..* 0..* 1 1 Sprint - Projeto: varchar - Data_Inicio: date - Data_Fim: date + Incluir_Sprint() : void + Atualizar_Sprint() : void + Deletar_Sprint() : void 1 1 1 1..* 1 Reunião Planejamento - Projeto: varchar - Apresen_Sprint: varchar 1 - Local_Reuniao: varchar - Duracao: int - Program_Prevista: varchar - Objetivo: vachar - Como_Atingir: varchar + Incluir_Dados() : void + Alterar_Dados() : void + Deletar_Dados() : void Reunião Diária - Projeto: varchar - Sprint: int - Usuario: varchar - Desenvolvimento_Ontem: varchar - Desenvolvimento_Amanhã: varchar - Impedimentos: varchar + Incluir_Dados() : void + Alterar_Dados() : void + Deletar_Dados() : void Reunião Retrospectiva - Projeto: varchar - Desenvolvimento: varchar - Pontos_Melhorar: varchar - Sugestões: varchar + Incluir_Dados() : void + Alterar_Dados() : void + Deletar_Dados() : void 1 Reunião Revisão - Projeto: varchar - Erro_Encontrado: varchar - Status: varchar + Incluir_Dados() : void + Alterar_Dados() : void + Deletar_Dados() : void Figura 19. Diagrama de classes de domínio A seguir é apresentada uma breve descrição das classes do diagrama (Figura 19): Usuário: classe que contém os dados referentes aos usuários da ferramenta; Time: essa classe contém os usuários que pertencem a um time do projeto, divididos em cargos; Projeto: é a principal classe da ferramenta, contém informações gerais referentes ao projeto; 35

Product_Backlog: essa classe contém a descrição dos itens que deverão ser desenvolvidos no projeto; Impediment_Backlog: contém os itens considerados fatores de impedimento para o desenvolvimento do projeto; Sprint_Backlog: essa classe contém os itens do Product Backlog quebrados em tarefas, com prazo estimado de desenvolvimento, data de início e fim e horas informadas semanalmente pelo desenvolvedor da tarefa; Sprint: guarda informações referentes às Sprints (iterações) do projeto; Reunião_Planejamento: armazena informações referentes a reunião de planejamento de cada Sprint do projeto, tais como objetivo e duração da Sprint e desenvolvedores; Reunião_Diária: classe que armazena os dados de todas as reuniões diárias que ocorreram durante o desenvolvimento da Sprint; Reunião_Retrospectiva: classe que contém informações referente a reunião de demonstração do produto realizada no final do Sprint para o cliente; Reunião_Revisão: classe que armazena as informações da reunião de revisão realizada no final do desenvolvimento de uma Sprint. 3.4 Diagrama Entidade-Relacionamento Após a definição das classes de domínio utilizadas pela ferramenta Scrum Project, foi construído o diagrama de Entidade-Relacionamento apresentando a estrutura do banco de dados. A Figura 20 apresenta esse diagrama. 36

dm Scrum CARGO «column» *PK CD_CARGO: integer NM_CARGO: varchar(30) DS_CARGO: varchar(100) «PK» + PK_CARGO(integer) USUARIO «column» USUARIO_TIME *PK CD_USUARIO: integer NM_USUARIO: varchar(50) «column» NR_RG: varchar(12) TIME «column» *PK CD_TIME: integer DS_TIME: varchar(100) «PK» + PK_TIME(integer) *pfk CD_TIME: integer *pfk CD_USUARIO: integer *pfk CD_CARGO: integer «FK» + FK_USUARIO_TIME_CARGO(integer) + FK_USUARIO_TIME_TIME(integer) + FK_USUARIO_TIME_USUARIO(integer) «PK» + PK_USUARIO_TIME(integer, integer, integer) NR_CPF: varchar(15) DT_NASCIMENTO: date DS_LOGRADOURO: varchar(100) NR_LOGRADOURO: integer NM_BAIRRO: varchar(30) NM_CIDADE: varchar(30) NR_CEP: integer DS_ESTADO: varchar(30) NR_TELEFONE: varchar(20) NR_CELULAR: varchar(20) DS_MAIL: varchar(50) LOGIN: varchar(20) SENHA: varchar(20) REUNIAO_REVISAO «column» *PK CD_REUNIAO_REV: integer FK CD_SPRINT: integer «FK» ITEM_REUNIAO_REVISAO «column» *PK CD_SEQ: integer FK CD_REUNIAO_REV: integer DS_ERRO: varchar(100) DS_STATUS: varchar(30) PROJETO «PK» + PK_USUARIO(integer) + FK_REUNIAO_REVISAO_SPRINT(integer) «PK» + PK_REUNIAO_REVISAO(integer) «FK» + FK_ITEM_REUNIAO_REVISAO_REUNIAO_REVISAO(integer) «PK» «column» + PK_ITEM_REUNIAO_REVISAO(integer) *PK CD_PROJETO: integer FK CD_TIME: integer NM_PROJETO: varchar(50) DS_PROJETO: varchar(200) REUNIAO_RETROSPECTIVA FK CD_USUARIO: integer DT_INICIO: date DT_FIM: date VL_PROJETO: decimal(10,2) DT_CRIACAO: date DT_ATUALIZACAO: date «column» SPRINT «column» *PK CD_REUNIAO_RETRO: integer FK CD_SPRINT: integer DS_DESENVOLVIMENTO: varchar(300) DS_SER_MELHORADO: varchar(300) DS_SUGESTAO: varchar(300) *PK CD_SPRINT: integer «FK» + FK_PROJETO_TIME(integer) + FK_PROJETO_USUARIO(integer) «PK» + PK_PROJETO(integer) * CD_PROJETO: integer DT_INICIO: date DT_FIM: date «PK» «FK» + FK_REUNIAO_RETROSPECTIVA_SPRINT(integer) «PK» + PK_REUNIAO_RETROSPECTIVA(integer) + PK_SPRINT(integer) REUNIAO_PLANEJAMENTO «column» *PK CD_REUNIAO: integer *FK CD_SPRINT: integer DS_OBJETIVO_SPRINT: varchar(200) DS_ATINGE_OBJETIVOS: varchar(300) DT_APRESENTACAO_SPRINT: date PRODUCT_BACKLOG «column» *PK CD_PRODUCT: integer *FK CD_PROJETO: integer DESCRICAO_ITEM: varchar(100) NR_PRIORIDADE: integer NR_ESTIMATIVA: integer DS_IMPEDIMENTO: varchar(100) DS_STATUS: varchar(30) SPRINT_BACKLOG «column» *FK CD_SPRINT: integer FK CD_PRODUCT: integer *PK CD_ITEM_SPRINT: integer REUNIAO_DIARIA «column» *PK CD_SEQ_REUNIAO: integer FK CD_SPRINT: integer FK CD_USUARIO: integer DT_REUNIAO: date DS_ATIVIDADE_ONTEM: varchar(200) DS_ATIVIDADE_AMANHA: varchar(200) DS_IMPEDIMENTO: varchar(300) DS_LOCAL_REUNIAO_DIARIA: varchar(50) DS_HORARIO: varchar(50) DS_AGENDA_REUNIAO: varchar(300) «FK» + FK_REUNIAO_PLANEJAMENTO_SPRINT(integer) «PK» + PK_REUNIAO_PLANEJAMENTO(integer) «FK» + FK_ITEM_PRODUCT_BACKLOG_PROJETO(integer) «PK» + PK_ITEM_PRODUCT_BACKLOG(integer) DS_TAREFA: varchar(50) NR_HORAS_EST: integer NR_HORAS_SEM_1: integer NR_HORAS_SEM_2: integer NR_HORAS_SEM_3: integer NR_HORAS_SEM_4: integer DS_STATUS: varchar(20) FK CD_USUARIO: integer DT_INICIO: date DT_FIM: date «FK» + FK_REUNIAO_DIARIA_SPRINT(integer) + FK_REUNIAO_DIARIA_USUARIO(integer) «PK» + PK_REUNIAO_DIARIA(integer) CD = CÓDIGO DS = DESCRIÇÃO DT = DATA NM = NOME NR = NÚMERO VL = VALOR «FK» + FK_ITEM_SPRINT_PRODUCT_BACKLOG(integer) SEM = SEMANA EST = ESTIMADA + FK_ITEM_SPRINT_SPRINT(integer) + FK_SPRINT_BACKLOG_USUARIO(integer) «PK» + PK_ITEM_SPRINT(integer) Figura 20 - Diagrama de entidade-relacionamento do banco de dados 4 DESENVOLVIMENTO Este capítulo descreve o desenvolvimento da ferramenta Scrum Project, apresentando o framework utilizado para seu desenvolvimento e a apresentação das telas e funcionalidades disponíveis. 4.1 Implementação da Ferramenta O desenvolvimento da ferramenta foi realizado focando sua utilização em ambiente web, objetivando independência de plataforma e maior disponibilidade aos usuários. Para isso, utilizouse o framework de desenvolvimento ScriptCase e o banco de dados PostgreSQL. Optou-se por esse framework por ser uma ferramenta nacional, com documentação e suporte em português, pela 37

agilidade e redução no tempo de desenvolvimento oferecido e compatibilidade com o banco de dados utilizado e por desenvolver os sistemas em PHP (Hypertext Preprocessor). 4.1.1 Framework ScriptCase O ScriptCase é um ambiente de desenvolvimento de aplicações web de forma rápida e eficiente, reduz tempo para desenvolvimento e manutenção e permite a criação de novos sistemas utilizando formulários, consultas, relatórios e menus. O ScriptCase suporta os bancos de dados mais usados no mercado como Oracle, DB2, SQLServer, MySQL, PostgreSQL e Sybase. O código-fonte da aplicação é em PHP com JavaScript e fazem uso da tecnologia Ajax para permitir a transferência de dados sem a necessidade de recarga da interface, tornando menor o tempo de resposta das operações realizadas. As aplicações rodam independente da ferramenta sendo compatíveis com Windows, Unix, AS/400, entre outros (NETMAKE, 2009). A Figura 21 representa uma visão do funcionamento desse framework. Figura 21 - Framework ScriptCase Fonte: Netmake (2009). O ScriptCase pode ser obtido através da internet, sob licença acadêmica ou download da versão trial com licença para 30 dias de uso. A Figura 22 mostra a tela inicial do ScriptCase. 38

Figura 22. Tela inicial ScriptCase Fonte: Netmake (2009). 4.2 A Ferramenta Scrum Project A ferramenta Scrum Project foi desenvolvida de acordo com a modelagem entidaderelacionamento apresentada na seção 3.4, tendo em vista o cumprimento dos requisitos e regras de negócio definidos. Nas próximas seções é apresentado o resultado desse trabalho. 4.2.1 Acesso ao Sistema O acesso dos usuários ao sistema é controlado através de autenticação de login e senha previamente cadastrados. A Figura 23 apresenta a tela inicial do ambiente, na qual o usuário informa seu login e senha e é feita a validação dos dados informados. 39