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

Tamanho: px
Começar a partir da página:

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

Transcrição

1 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 2.0: FERRAMENTA DE GERENCIAMENTO DE PROJETOS COM SCRUM Área de Engenharia de Software por Felipe Augusto Paterlini Correia Adriana Gomes Alves, M. Eng. Orientadora Itajaí (SC), dezembro de 2010

2 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 2.0: FERRAMENTA DE GERENCIAMENTO DE PROJETOS COM SCRUM Área de Engenharia de Software por Felipe Augusto Paterlini Correia 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), dezembro de 2010

3 Aos meus pais, João (em memória) e Luzia, pelo amor, carinho e amizade que sempre dedicaram a mim. ii

4 AGRADECIMENTOS Em primeiro lugar, agradeço de coração aos meus pais, João Batista Correia (em memória) e Luzia Aparecida Ribeiro Paterlini, pelo amor, carinho e educação que recebi ao longo de minha vida. Agradeço terem estado presentes em todos os momentos da minha vida, me apoiando e incentivando. Meus sinceros agradecimentos também à minha orientadora, professora e amiga Adriana Gomes Alves, que me orientou com seriedade e profissionalismo e me motivou desde o início, Quando problemas pessoais quase me fizeram desistir, recebi todo o seu apoio e compreensão. Sou grato imensamente também à minha namorada Francielle Spilmam pelo amor, compreensão e principalmente pela paciência neste ano em que estive mais ausente. E agradeço também por sua maravilhosa companhia que me acompanha desde o início do curso e me motivaram a levá-lo com mais seriedade e determinação. Agradeço a todos os professores da Univali, que participaram da minha formação profissional e pessoal. Sou grato também ao professor e coordenador do curso de Ciência da Computação, Luis Carlos Martins (Luca), pela disposição, simpatia e bom humor. Não poderia deixar de agradecer também a todos os meus amigos do trabalho, principalmente aos diretores da IBF Informática, Rafael Pacheco Luz e Héderson da Silva Cassimiro, pelo apoio e compreensão neste ano em que precisei me ausentar diversas vezes da empresa para me dedicar ao desenvolvimento deste trabalho. Por fim, agradeço aos meus grandes amigos Amauri Cattoni Junior e Marcelo Giovanella Girardi, pela imensa amizade e apoio que indiscutivelmente tenho recebido e que sempre me motivaram nesta longa jornada. Sou muito grato também a todos os meus amigos do curso, que estiveram presentes nas salas de aula e nos trabalhos de equipe. Agradeço em especial ao meu amigo Lennon Romano Bisolo, pela motivação, colaboração e grande amizade, e ao Odilo Schwade Junior, que também me motivou em momentos importantes durante a minha vida acadêmica. iii

5 SUMÁRIO LISTA DE ABREVIATURAS... vii LISTA DE FIGURAS... viii LISTA DE TABELAS... x RESUMO... xi ABSTRACT... xii 1 INTRODUÇÃO PROBLEMATIZAÇÃO Formulação do Problema Solução Proposta OBJETIVOS Objetivo Geral Objetivos Específicos METODOLOGIA ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA METODOLOGIAS ÁGEIS SCRUM Ciclo do Scrum Fases do Scrum Papéis e Responsabilidades Scrum Master Product Owner Scrum Team Sprint Sprint Planning Daily Scrum Meeting Sprint Review Sprint Retrospective Artefatos Product Backlog Impediment Backlog Planning Poker Task Board Burndown Chart FERRAMENTAS DE GERENCIAMENTO COM SCRUM Scrum Project FireScrum iv

6 2.3.3 VersionOne TargetProcess Comparativo PROJETO ANÁLISE DE REQUISITOS Requisitos Funcionais Requisitos Não Funcionais Regras de Negócio CASOS DE USO Módulo Acesso Módulo Cadastros Básicos Módulo Product Backlog Módulo Sprint Módulo Tarefa Módulo Planning Poker Módulo Task Board DIAGRAMA DE ENTIDADE RELACIONAMENTO DESENVOLVIMENTO IMPLEMENTAÇÃO SCRUM PROJECT Acesso Projetos Usuários Product Backlog Planning Poker Sprint Tasks Task Board Burndown Chart MELHORIAS CONCLUSÃO REFERÊNCIAS BIBLIOGRÁFICAS GLOSSÁRIO A DESCRIÇÃO DOS CASOS DE USO A.1 MÓDULO ACESSO UC Acessar o Sistema A.2 MÓDULO CADASTROS BÁSICOS UC Manter Usuário UC Manter Time UC Manter Projeto v

7 A.3 MÓDULO PRODUCT BACKLOG UC Manter Product Backlog A.4 MÓDULO SPRINT UC Manter Sprint UC Manter Reunião de Planejamento UC Gerenciar Reunião Diária UC Manter Reunião de Revisão UC Manter Reunião de Retrospectiva UC Visualizar Sprint Burndown A.5 MÓDULO TAREFA UC Manter Tarefas UC Alocar Tarefa UC Gerenciar Horas Trabalhadas UC Informar Status da Tarefa UC Gerenciar Impedimentos A.6 MÓDULO PLANNING POKER UC Definir a Complexidade UC Gerenciar a Sessão UC Estimar Itens de uma Sessão A.7 MÓDULO TASK BOARD UC Alocar Tarefa UC Alterar Status vi

8 LISTA DE ABREVIATURAS AJAX CRUD DSDM ER FDD HTML MIT PHP RIA ROI SAAS SQL TCC UNIVALI XP Asynchronous Javascript And XML Create, Retrieve, Update and Delete Dynamic Systems Development Method Entidade-Relacionamento Feature Driven Development HyperText Markup Language Massachusetts Institute of Technology Hypertext Preprocessor Rich Internet Applications Return of Investment Software as a Service Structured Query Language Trabalho de Conclusão de Curso Universidade do Vale do Itajaí Extreme Programming vii

9 LISTA DE FIGURAS Figura 1. Adoção de Metodologias Ágeis Figura 2. Visão geral de processo do Scrum Figura 3. Estimando o Product Backlog sem Planning Poker Figura 4. Sequência de cartas do Planning Poker Figura 5. Estimando o Product Backlog com Planning Poker Figura 6. Seleção da carta no Planning Poker Figura 7. Definição da complexidade do item em análise Figura 8. Task Board Figura 9. Tela da ferramenta Taskboard Figura 10. Sprint Burndown Figura 11. Gráfico Burndown e Task Board Figura 12. Tela inicial do Scrum Project Figura 13. Cadastro do Product Backlog no Scrum Project Figura 14. Módulo do Planning Poker no FireScrum Figura 15. Módulo do Task Board no FireScrum Figura 16. Tela para cadastro de Sprint no FireScrum Figura 17. Utilização de ferramentas em empresas de desenvolvimento de software Figura 18. Tela de Product Backlog da ferramenta VersionOne Figura 19. Task Board da ferramenta VersionOne Figura 20. Product Burndown da ferramenta VersionOne Figura 21. Cadastro de Stories da ferramenta TargetProcess Figura 22. Task Board da ferramenta TargetProcess Figura 23. Burndown Chart da ferramenta TargetProcess Figura 24. Atores do sistema Figura 25. Diagrama de Casos de Uso do Módulo Acesso Figura 26. Diagrama de Casos de Uso do Módulo Cadastros Básicos Figura 27. Diagrama de Casos de Uso do Módulo Product Backlog Figura 28. Diagrama de Casos de Uso do Módulo Sprint Figura 29. Diagrama de Estados do Módulo Tarefa Figura 30. Diagrama de Casos de Uso do Módulo Tarefa Figura 31. Diagrama de Atividades do Planning Poker Figura 32. Diagrama de Casos de Uso do Módulo Planning Poker Figura 33. Diagrama de Casos de Uso do Módulo Task Board Figura 34. Diagrama de Entidade Relacionamento Figura 35. Código-fonte da view do Task Board Figura 36. Trecho de código de uma requisição AJAX Figura 37. Trecho de código executado no Planning Poker Figura 38. Trecho de código da camada de controle do Planning Poker Figura 39. Trecho de código da geração do Burndown Chart Figura 40. Exemplo de formatação para a Internacionalização Figura 41. Tela de boas vindas do Scrum Project Figura 42. Tela de cadastro do projeto Figura 43. Tela de listagem dos projetos Figura 44. Tela do módulo de gerenciamento de usuários Figura 45. Tela de cadastro das Stories Figura 46. Tela de seleção das estórias para o Planning Poker viii

10 Figura 47. Tela do Planning Poker Figura 48. Tela do Planning Poker com estimativas Figura 49. Tela de cadastro da Sprint Figura 50. Tela de cadastro da tarefa Figura 51. Tela do Task Board Figura 52. Tela do gráfico Sprint Burndown ix

11 LISTA DE TABELAS Tabela 1. Comparativo de funcionalidades Tabela 2. Comparativo técnico x

12 RESUMO CORREIA, Felipe Augusto Paterlini. Scrum Project 2.0: ferramenta de gerenciamento de projetos com Scrum. Itajaí, 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í, Os processos de desenvolvimento de software têm passado por grandes modificações em sua estrutura para atender à crescente demanda do mercado. As empresas têm buscado soluções de desenvolvimento mais flexíveis porque precisam entregar softwares com prazos reduzidos, mantendo a qualidade de seu produto. Por esta razão, têm-se adotado as chamadas metodologias ágeis, que propõem a substituição de extensa documentação pela comunicação entre pessoas. Uma das metodologias ágeis mais conhecidas é chamada de Scrum, que tem como princípio o foco nas pessoas e possui diversos artefatos que buscam tornar procedimentos complexos em atividades mais simples e dinâmicas. Contudo, em equipes geograficamente distribuídas, faz-se necessário utilizar ferramentas para gerenciamento e acompanhamento de projetos com Scrum. Existem diversas ferramentas disponíveis, cada qual com suas características positivas e negativas, mas se pode perceber a necessidade de uma ferramenta open source com módulos específicos que simulem os artefatos físicos utilizados na metodologia. Desta forma, este Trabalho de Conclusão de Curso teve como objetivo analisar e reescrever o software Scrum Project incluindo módulos específicos como o Planning Poker, Task Board e Burndown Chart, dando continuidade ao trabalho desenvolvido por Kluge (2009). O Scrum Project é um sistema web, desenvolvido para apoiar as equipes que utilizam o Scrum como metodologia de gerenciamento de projetos. Entretanto, através da análise da ferramenta em comparação com outras disponíveis no mercado, pôde-se perceber a necessidade de diversas melhorias para torná-la uma ferramenta mais completa. Desta forma, além da inclusão das funcionalidades Planning Poker, Task Board e Burndown Chart, o software Scrum Project foi reescrito utilizando a modelagem existente. Palavras-chave: Gerenciamento de Projetos. Scrum. Desenvolvimento Ágil. xi

13 ABSTRACT During the last few decades, software development processes have gone through considerable changes within their structures in order to keep up with the increasing market demand. Companies have searched for more flexible development solutions, for they need to deliver their software in shorter terms, still maintaining quality. For this reason, the so-called agile methodologies are being adopted; they propose the replacement of extensive documentation by communication among people. One of the most popular agile methodologies is named Scrum, its principle is to focus on people and it has a variety of artifacts that try to turn complex procedures into simpler and more dynamic tasks. Nevertheless, using tools is necessary to improve management and monitoring Scrum projects. There are plenty of available tools, each one with for-and-against features, but it is becoming clear the necessity of a national (Brazilian) and Open Source tool. The goal of this Final Work was to analyze and join specific methods such as Planning Poker, Task Board and Burndown Chart with Scrum Project tool, maintaining Kluge s (2009) work development. Scrum Project is a web system, designed to support crews who make use of Scrum as a methodology of projects management. However, it s becoming clear the needs for a series of improvements to turn it into a complete tool. This way, in addition to including new functionalities, this work aims to identify and introduce improvements to Scrum Project, still using its positive characteristics. Keywords: Project Management. Scrum. Agile Development. xii

14 1 INTRODUÇÃO As empresas de desenvolvimento de software têm concentrado seus esforços na produção cada vez mais rápida, barata e de melhor qualidade buscando utilizar formas mais flexíveis de desenvolvimento de software que se adaptem às necessidades dos clientes (BOENTE; OLIVEIRA; ALVES, 2008). Além disso, estas empresas procuram formas de estarem mais bem preparadas para as mudanças constantes do mercado de software. Desta necessidade, surgiram as Metodologias de Desenvolvimento Ágil. Nas metodologias tradicionais de desenvolvimento, os sistemas mais complexos podem ser construídos através de uma sequencia de passos pré-determinada, isentos da necessidade de reavaliação dos requisitos e ideias iniciais do projeto em função de fatores externos como a evolução das empresas e da tecnologia (SZALVAY, 2004). Contudo, nos projetos em que existem constantes alterações nos requisitos, onde as equipes são pequenas, as datas de entrega do software são curtas e o desenvolvimento rápido é fundamental, a metodologia tradicional deve ser substituída pelos métodos ágeis (SOARES, 2004). Existem diversas metodologias ágeis voltadas para o desenvolvimento de software e todas elas compartilham dos mesmos princípios básicos: indivíduos e interações sobre processos e ferramentas, software funcional sobre documentação, colaboração do cliente sobre negociação contratual e respostas rápidas às mudanças sobre seguir planos fixos (AGILE MANIFESTO, 2001). Este trabalho é baseado nos conceitos de Scrum, uma das metodologias ágeis mais utilizadas no mundo, utilizada por 50% das empresas de desenvolvimento de software que utilizam metodologias ágeis, de acordo com uma pesquisa realizada pela VersionOne (2009). O Scrum, assim como outras metodologias ágeis, procura evitar a burocratização do processo de desenvolvimento de software através da priorização da comunicação verbal entre os integrantes da equipe e da utilização de artifícios visuais que auxiliem no acompanhamento do projeto. Dentre estes artefatos, pode-se citar o Planning Poker, o Task Board e o Burndown Chart. O Planning Poker é um jogo realizado entre os integrantes da equipe de desenvolvimento para avaliar a complexidade de cada funcionalidade que deverá ser desenvolvida no produto. Esta avaliação é importante para identificar quantas tarefas podem ser executadas em cada Sprint com base no tempo de desenvolvimento estimado para cada item do Backlog. O objetivo do Planning

15 Poker é realizar a definição da complexidade de cada item de forma mais dinâmica e com a contribuição de todos os participantes (VARASCHIM, 2009). O quadro de tarefas (Task Board, em inglês), consiste em gerenciar o andamento das atividades de um projeto através de Post-its e que acaba proporcionando uma maior visibilidade no andamento das tarefas, como apontado por Szimansky, Albuquerque e Furtado (2009), em estudo de caso realizado. Entretanto, torna-se necessário que os integrantes estejam distribuídos no mesmo espaço físico. Uma alternativa seria a utilização de uma ferramenta eletrônica que simulasse o ambiente físico do Task Board. De acordo com Perry (2008), uma das vantagens em se utilizar um Task Board eletrônico é o fato de ele estar disponível através da Internet, podendo ser acessada em qualquer local do mundo e, deste modo, sendo bastante útil quando se tem equipes distribuídas geograficamente. Outro artefato bastante utilizado no Scrum é o gráfico Burndown Chart. Ele pode ser subdivido em duas versões: o Product Burndown e Sprint Burndown. De acordo com Marçal et al. (2007), o Product Burndown representa a velocidade de entrega dos itens do Product Backlog pelo time. Seu objetivo é identificar se as funcionalidades previstas poderão ser entregues no prazo. O Sprint Burndown representa a velocidade e progresso de evolução das tarefas em uma determinada Sprint, possibilitando ao time identificar se as tarefas poderão ser finalizadas até o término da mesma. As ferramentas de apoio são importantes aliadas ao processo de desenvolvimento, mesmo quando se utiliza metodologias ágeis. Um dos fatores que sugere a adoção destas ferramentas provém do fato de que os integrantes de um projeto podem não estar presentes em um mesmo ambiente físico, uma vez que trabalhar com equipes geograficamente distribuídas tem sido uma solução adotada em diversas empresas. Nestes casos, como descrito por Mountain (2009 apud CAVALCANTI; MACIEL; ALBUQUERQUE, 2009), o uso de artefatos não automatizados como cartões e murais, pode representar um desafio na adoção da metodologia por equipes geograficamente distribuídas. No ano de 2009, a acadêmica Monike Roberta Kluge, do curso de Ciência da Computação, da Universidade do Vale do Itajaí, buscando uma ferramenta que oferecesse suporte ao gerenciamento de projetos com Scrum, desenvolveu o software Scrum Project, uma ferramenta web baseada em software livre e em Português do Brasil (KLUGE, 2009). Contudo, desde sua concepção, diversas outras ferramentas de apoio ao desenvolvimento de software com metodologias 2

16 ágeis foram desenvolvidas. Além disso, a ferramenta desenvolvida por Kluge (2009), apesar de prática e intuitiva, contempla somente as funcionalidades básicas que o Scrum exige e, por esta razão, ainda não tem capacidade suficiente para ser utilizada em uma empresa de desenvolvimento de software. A proposta deste trabalho de conclusão de curso foi reescrever o software Scrum Project e desenvolver os módulos Planning Poker, Task Board e Burndown Chart. Para alcançar este objetivo, realizou-se uma pesquisa sobre a metodologia Scrum, análise do software Scrum Project e ferramentas similares para que pudessem ser identificadas, além das funcionalidades citadas, outras possíveis melhorias. 1.1 PROBLEMATIZAÇÃO Formulação do Problema A metodologia Scrum é uma das metodologias ágeis mais utilizadas no mercado VERSIONONE (2009). Entretanto, grande parte das ferramentas utilizadas para apoio ao desenvolvimento de software é licenciada ou sua utilização é muito complexa, indo de encontro aos princípios do Scrum. A ferramenta Scrum Project, desenvolvida por Kluge (2009), apesar de gratuita e bastante simplificada, não contempla artefatos importantes do Scrum, como o Task Board, Planning Poker e Burndown Chart. Além disso, durante os estudos verificou-se que a ferramenta utilizada para o desenvolvimento da primeira versão do Scrum Project (i.e. Script Case), impossibilita sua continuidade pelo fato de ser uma ferramenta paga, apesar de gerar código em uma linguagem open source (i.e. PHP) Solução Proposta A solução proposta neste Trabalho de Conclusão de Curso foi reescrever o sistema Scrum Project através de um framework open source de desenvolvimento PHP para geração das classes e telas do sistema e integrar as funcionalidades Planning Poker, Task Board e Burndown Chart. Estes três módulos, foram desenvolvidos de acordo com suas características físicas, de forma que as equipes de desenvolvimento de software possam utilizar os artifícios da metodologia Scrum através dos módulos eletrônicos. 3

17 1.2 OBJETIVOS Objetivo Geral Reimplementar o software Scrum Project e incluir os módulos Planning Poker, Task Board e Burndown Chart Objetivos Específicos Os objetivos específicos deste trabalho de conclusão de curso são: Estudar e compreender a Metodologia Ágil Scrum; Pesquisar e avaliar as ferramentas disponíveis para o gerenciamento de projetos com Scrum; Estudar e avaliar a primeira versão da ferramenta Scrum Project; Realizar a análise e projeto do Scrum Project revisando a modelagem do software e incluindo novas funcionalidades; Implementar o Burndown Chart; Implementar o Task Board; Implementar o Planning Poker; Reimplementar as funcionalidades originais do Scrum Project; Testar e avaliar a implementação das novas funcionalidades da ferramenta; e Documentar o desenvolvimento. 1.3 Metodologia Para o desenvolvimento da Fundamentação Teórica, realizou-se uma pesquisa em metodologias ágeis e, especificamente, da metodologia Scrum. Como este trabalho é sequencia de outro Trabalho de Conclusão de Curso, fez-se um estudo da ferramenta Scrum Project, produto do trabalho anterior, buscando identificar melhorias e alterações necessárias. Para identificar as necessidades da ferramenta, foram pesquisadas e estudadas outras ferramentas disponíveis no mercado para gerenciamento de projetos com Scrum. 4

18 O desenvolvimento do Projeto teve como base as pesquisas realizadas na Fundamentação Teórica, análise da ferramenta Scrum Project e o estudo de ferramentas similares. Como a ferramenta possui modelagem e requisitos definidos, foram realizadas somente as modificações necessárias para adaptar o Scrum Project aos objetivos propostos neste trabalho, sendo que todas estas alterações e particularidades são descritas no capítulo de Projeto. Neste capítulo, foram utilizados diagramas de casos de uso e entidade relacionamento. Em todos eles, foram realizadas algumas modificações e inclusões para atender às necessidades deste trabalho. Também são apresentados os protótipos de interfaces dos módulos Planning Poker, Task Board e Burndown Chart. Por fim, apresenta-se o desenvolvimento desta nova versão da ferramenta Scrum Project, descrevendo os recursos utilizados e todas as suas funcionalidades. Também são descritos os novos módulos implementados nesta versão. Para ilustrar o conteúdo apresentado, são utilizadas imagens durante o decorrer da explanação. 1.4 Estrutura do trabalho Este projeto está estruturado em quatro capítulos: (i) Introdução; (ii) Fundamentação Teórica; (iii) Projeto; (iv) Desenvolvimento e (v) Conclusões. No Capítulo 1 (Introdução) são apresentadas as ideias e necessidades que motivaram o desenvolvimento deste TCC, descrevendo sucintamente alguns conceitos importantes para este trabalho. Ainda neste capítulo, são identificados os objetivos propostos e metodologia utilizada no desenvolvimento deste trabalho. No Capítulo 2 (Fundamentação Teórica) são descritos os conceitos das metodologias ágeis e processos do Scrum, além de uma análise da ferramenta Scrum Project e softwares similares. No Capítulo 3 (Projeto) são especificadas as alterações realizadas e apresentação dos requisitos incluídos, modificações na modelagem e protótipos de tela dos módulos propostos neste trabalho. No Capítulo 4 (Desenvolvimento) são descritas as funcionalidades da ferramenta desenvolvida e dos novos módulos incluídos nesta versão. 5

19 No Capítulo 5 (Conclusões), são apresentadas as conclusões obtidas durante o desenvolvimento deste Trabalho de Conclusão de Curso, bem como as dificuldades encontradas e sugestões para futuros trabalhos e pesquisas. 6

20 2 FUNDAMENTAÇÃO TEÓRICA Neste capitulo são apresentados a revisão bibliográfica da metodologia ágil Scrum e os temas relacionados. Na Seção 2.1 são descritos os conceitos básicos de metodologias ágeis e suas características mais importantes para o desenvolvimento deste trabalho. Na Seção 2.2, descreve-se a metodologia Scrum definindo conceitos, características e processos. E, por fim, na Seção 2.3 são descritas ferramentas de gerenciamento de projetos com Scrum, incluindo nesta análise, a primeira versão da ferramenta Scrum Project, objeto de estudo deste trabalho. 2.1 Metodologias Ágeis As metodologias ágeis têm sido cada vez mais utilizadas pelas empresas de desenvolvimento de software. Muitas destas empresas ainda não utilizam um método específico, mas buscam adaptar os princípios ágeis ao seu próprio modelo de desenvolvimento. Sabe-se que as metodologias tradicionais de desenvolvimento são orientadas à extensa documentação e detalhamento dos processos envolvidos. Entre outras características, essas metodologias também partem do princípio de que os requisitos do projeto podem ser definidos no início, permanecendo inalterados ao longo do desenvolvimento (SOARES, 2004). Hoje, este cenário é diferente. O mercado torna-se a cada dia mais dinâmico e os clientes mais exigentes e, por esta razão, surgiram as denominadas Metodologias Ágeis. As metodologias ágeis, diferentemente das tradicionais, buscam evitar a burocratização dos processos dando ênfase à comunicação verbal além de prezar a entrega rápida e incremental do software. Por esta razão, a participação do cliente é primordial para que o desenvolvimento possa ter como foco apenas as tarefas realmente necessárias ao invés de desperdiçar recursos com módulos e funcionalidades desnecessárias (FERREIRA; LIMA, 2008). Ao utilizar alguma metodologia tradicional, torna-se difícil para o cliente acompanhar o andamento do projeto, sem contar o fato de que, na maioria dos casos, ou o cliente percebe que sua necessidade é diferente ou o próprio mercado sofre modificações econômicas ou tecnológicas exigindo alterações no desenvolvimento do software. Além de exigir uma postura diferenciada do cliente, as metodologias ágeis exigem uma mudança de comportamento das equipes diretamente ligadas ao desenvolvimento. O principal conceito abordado nestes métodos é a colaboração, item chave para um projeto de qualidade. Os

21 integrantes das equipes, apesar de possuírem habilidades diferentes, devem ter o mesmo foco, que é entregar uma versão do software com as funcionalidades estabelecidas e no prazo estipulado. Além disso, é necessário que todos os envolvidos possuam capacidade de tomada de decisão. Cada integrante deve ter controle de suas próprias atividades e responsabilidades, comprometendo-se com o resultado geral do projeto. Apesar de todas as vantagens da utilização de uma metodologia ágil o fator que mais dificulta sua adoção em uma empresa é a própria cultura dos envolvidos. A maior parte dos indivíduos não é suscetível a mudanças até que lhe seja comprovada sua eficiência. E, mesmo que uma metodologia neste modelo seja simplesmente imposta, o preconceito sobre ela acaba desestimulando o trabalho e o nível de motivação acaba diminuindo drasticamente. Por esta razão, muitas empresas ainda estão cautelosas quando se trata deste assunto (TOMÁS, 2009). Outro fator que pode dificultar a utilização das metodologias ágeis é o desenvolvimento de software por equipes geograficamente distribuídas. De acordo com Cavalcanti, Maciel e Albuquerque (2009, apud DAMIAN; MOITRA, 2006), o desenvolvimento por equipes remotas tem crescido continuamente desde a última década. Contudo, as metodologias ágeis enfatizam a comunicação constante e a utilização de reuniões presenciais regulares, e isto se torna um fator de complicação para equipes distribuídas. Neste contexto, uma boa iniciativa é o desenvolvimento de ferramentas de apoio ao Scrum em equipes geograficamente distribuídas, de forma a reduzir os efeitos negativos da distância entre os envolvidos no processo (CAVALCANTI; MACIEL; ALBUQUERQUE, 2009 apud CRISTAL, 2008). Mesmo com estas barreiras, muitas empresas têm buscado adotar estes princípios em seu processo de desenvolvimento. As metodologias mais comuns são: Scrum, Extreme Programming (XP), Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM) e Lean Development (KLUGE, 2009). Todas elas possuem basicamente os mesmo conceitos de desenvolvimento ágil, incremental e orientado ao cliente. O Scrum é a metodologia mais adotada pelas softhouses como mostra o gráfico da Figura 1. Este Trabalho de Conclusão de Curso tem como foco esta metodologia, detalhada na Seção

22 Figura 1. Adoção de Metodologias Ágeis. Fonte: Adaptado de VersionOne (2009). 2.2 Scrum Criado em 1996 por Ken Schwaber e Jeff Sutherland (SZIMANSKY; ALBUQUERQUE; FURTADO, 2009), o Scrum é uma abordagem simples aplicada ao gerenciamento de tarefas complexas. Mais especificamente, trata-se de uma metodologia ágil de desenvolvimento de software de forma empírica, iterativa e incremental (LUDVIG; REINERT, 2007). Segundo Müller (2004), o Scrum é considerado uma metodologia de desenvolvimento de forma empírica porque os processos não são pré-definidos e por isso menor tempo é dedicado ao planejamento de tarefas e análise de requisitos, bem como leitura e criação da documentação. O Scrum é uma metodologia com foco nas pessoas, indicado para ambientes em que os requisitos surgem e mudam rapidamente, resultando em uma abordagem que reintroduz as ideias de flexibilidade, adaptabilidade e produtividade (BEEDLE; SCHAWABER, 2002 apud SZIMANSKY; ALBUQUERQUE; FURTADO, 2009). Esta metodologia é baseada em cenários de equipes reduzidas, requisitos pouco estáveis ou desconhecidos e iterações curtas Ciclo do Scrum No Scrum, como definido por Marçal et al. (2007), um projeto tem inicio com uma ideia, ou seja, uma visão do produto que será desenvolvido. Esta visão contém uma lista com as características do produto estabelecidas pelo cliente, além de algumas restrições. Em seguida, o 9

23 Product Backlog é criado contendo a lista de todos os requisitos identificados para o projeto. Cada item do Product Backlog pode também ser chamado de Estória (Story). O Product Backlog é então priorizado e dividido em releases. O fluxo de desenvolvimento do Scrum está ilustrado na Figura 2. Figura 2. Visão geral de processo do Scrum. Fonte: Marçal et al. (2007) Como descrito por Pereira, Torreão e Marçal (2007), o Scrum é baseado em um ciclo que possui uma série de iterações bem definidas, cada uma com duração de duas a quatro semanas, chamada Sprint. Schwaber (2004, apud MARÇAL et al, 2007) explica que cada Sprint começa através de uma reunião de planejamento (Sprint Planning Meeting), na qual o Product Owner e o Scrum Team decidem em conjunto quais itens do Product Backlog serão desenvolvidos na Sprint, considerando sua capacidade de produção e complexidade dos Backlog Itens. Os itens de Backlog são estimados de forma a identificar o tempo individual de desenvolvimento. Para esta finalidade é comum utilizar o Planning Poker, detalhado na Seção Na segunda parte (Sprint Planning 2), a equipe faz o planejamento de seu trabalho, definindo o Sprint Backlog, que são as tarefas necessárias para desenvolver as funcionalidades escolhidas no Product Backlog. A lista de tarefas pode ser alterada durante o andamento da Sprint pelo próprio time e podem variar entre 4 a 16 horas para a sua conclusão (MARÇAL et al, 2007). 10

24 Alguns autores definem o tempo máximo de uma tarefa em 8 horas para que possa ser executada no mesmo dia e, deste modo, facilitando o gerenciamento destas tarefas. A fase seguinte é a execução da Sprint, na qual o Scrum Team controla o andamento do desenvolvimento do projeto através das Reuniões Diárias (Daily Meeting), com até quinze minutos de duração. Ao término de cada Sprint, realiza-se uma Reunião de Revisão (Sprint Review), na qual o Scrum Team apresenta o resultado gerado na Sprint e verifica se o resultado foi atingido. Em seguida, realiza-se a Reunião de Retrospectiva (Sprint Retrospective), uma reunião de lições aprendidas, com o objetivo de melhorar o produto ou processo para a próxima Sprint (PEREIRA; TORREÃO; MARÇAL, 2007). O acompanhamento do andamento do projeto, como descreve Marçal et al. (2007), é realizado através de dois gráficos principais: Product Burndown e Sprint Burndown. Estes gráficos, detalhados mais adiante, são muito importantes porque indicam a quantidade de trabalho que ainda precisa ser realizado e permitem identificar antecipadamente se o conjunto de atividades previstas irá finalizar antes ou depois do prazo definido Fases do Scrum O Scrum possui um ciclo de vida composto por quatro fases (MARÇAL et al, 2007): Planejamento: estabelecer a visão do projeto e expectativas garantindo recursos para a sua execução. Nesta fase são criadas as versões iniciais do Product Backlog e o plano de release, arquitetura de negócio e técnica em alto nível. Stagging: avaliar as várias dimensões do projeto criando itens adicionais ao Product Backlog relacionados com o tipo do sistema, time, ambiente de desenvolvimento, tipo de aplicação. Nesta fase os times são formados e são construídos os mecanismos de comunicação e coordenação entre eles. Desenvolvimento: consiste de múltiplas Sprints para o desenvolvimento dos incrementos de funcionalidade do produto. Releasing: realizar a entrega do produto ao cliente. 11

25 2.2.3 Papéis e Responsabilidades Segundo Beedle e Schawaber (2002, apud SZIMANSKY; ALBUQUERQUE; FURTADO, 2009), o Scrum define para sua estrutura iterativa incremental três papéis principais: Scrum Master, Product Owner e o Scrum Team Scrum Master De acordo com Varaschim (2009), o Scrum Master é uma nova função de gerência introduzida pelo Scrum. Sua principal função é ser o facilitador do processo e auxiliar os envolvidos a resolver conflitos, enquanto difunde e garante a aplicação do processo dentro da organização. Para Marçal et al. (2007), o Scrum Master gerencia os processos, implementando o Scrum de modo que esteja adequado à metodologia de trabalho da organização. Ele também deve garantir que os envolvidos sigam as regras e práticas estabelecidas e é responsável por remover os impedimentos do projeto. Resumidamente, pode-se destacar quatro responsabilidades para o Scrum Master (PEREIRA; TORREÃO; MARÇAL, 2007): Garantir que a equipe esteja totalmente funcional e produtiva; Facilitar a colaboração entre as funções e áreas e eliminar os impedimentos; Proteger o time de interferências externas; e Garantir que o processo da metodologia Scrum está sendo seguida pela equipe Product Owner O Product Owner é definido como o cliente do projeto e representa os interesses dos envolvidos. Ele define os fundamentos do projeto criando requisitos iniciais e gerais (Product Backlog), retorno do investimento (ROI), objetivos e planos de entregas. O Product Owner também tem a responsabilidade de priorizar o Product Backlog a cada Sprint, de forma a garantir que as funcionalidades de maior valor tenham prioridade no projeto (MARÇAL et al, 2007). O perfil do Product Owner, segundo Varaschim (2009), está relacionado à área de produto, sendo imprescindível que ele consiga compartilhar e apresentar os objetivos do produto em 12

26 construção. Ele deve ter espírito de liderança, ser o principal motivador e possuir bom relacionamento com a equipe. Para Pereira, Torreão e Marçal (2007), o Product Owner possui as seguintes responsabilidades: Definir os requisitos do produto; Priorizar os requisitos de acordo com o seu valor de mercado; Alterar os requisitos e prioridades a cada Sprint de acordo com sua necessidade; e Aceitar ou rejeitar o resultado de cada Sprint Scrum Team O Scrum Team é o time de desenvolvedores que trabalha nas funcionalidades do produto. Ele define como transformar o Product Backlog em incremento de funcionalidades numa iteração gerenciando seu próprio trabalho e é responsável de forma coletiva pelo sucesso da iteração e, consequentemente, pelo projeto (MARÇAL et al, 2007). Para Varaschim (2009), o Scrum Team precisa ser multidisciplinar e auto-organizado, devendo possuir entre dez a quinze participantes. O perfil de conhecimento de seus integrantes deve englobar as características necessárias para a implementação. Segundo o mesmo autor, o Scrum Team deve ser autossuficiente e ter controle sobre o processo de desenvolvimento, sendo de sua responsabilidade apresentar os resultados do trabalho desenvolvido para o cliente ao fim de cada Sprint. Para o Scrum Team pode-se relacionar algumas responsabilidades destacadas por Pereira, Torreão e Marçal (2007): Selecionar, entre os itens priorizados, aqueles que serão executados durante a Sprint; Organizar o time e o trabalho entre os membros de forma participativa; Realizar as tarefas da Sprint; e Realizar uma demonstração do trabalho desenvolvido para o cliente. 13

27 2.2.4 Sprint De acordo com Ken Schwaber (SCHWABER; BEEDLE, 2002 apud VARSCHIM, 2009), a Sprint pode ser definida como um ciclo de desenvolvimento em que o time deve executar todas as estórias selecionadas do Product Backlog. Para Zhi-gen, Quan e Xi (2009) Sprint é uma série de atividades de desenvolvimento em um período limitado, incluindo atividades análise, modelagem, programação e testes. Durante a Sprint, o time deve ter autoridade para seu gerenciamento, podendo escolher quais tarefas serão executadas. Como descrito no Capítulo 2.2.1, a Sprint deve ter um tempo de execução de duas a quatro semanas. Este tempo reduzido, de acordo com Varaschim (2009), tem como objetivo fazer com que as funcionalidades sejam apresentadas pelo time e validadas pelo Product Owner. Durante a execução da Sprint, são realizadas diferentes formas de reuniões com objetivos específicos, as quais são detalhas nas seções seguintes Sprint Planning A reunião de planejamento da Sprint (Sprint Planning) é realizada em dois momentos distintos, sempre no início da execução de uma Sprint. É importante lembrar que para a execução do Sprint Planning, as estórias do Product Backlog precisam ter suas complexidades estimadas. De acordo com Varaschim (2009), esta reunião de planejamento normalmente é realizada em um dia, mas de acordo com o tamanho das Sprints, este tempo de duração pode variar. Em uma primeira etapa, o Product Owner, o Scrum Master e o Scrum Team, reúnem-se para definir quais funcionalidades do Product Backlog serão selecionadas para a Sprint. Neste momento, o Product Owner deve priorizar os itens considerados mais importantes, enquanto que o Scrum Team irá selecionar a quantidade de itens que poderá ser executada durante a Sprint. Nesta etapa, os seguintes itens são muito importantes (VARASCHIM, 2009): Deve haver um Product Owner; Possuir o Product Backlog estimado; Priorizar os itens que devem ser desenvolvidos; e 14

28 Reavaliar a complexidade dos itens priorizados de forma a identificar se estes podem ser executados dentro da Sprint. Na segunda etapa, o Scrum Team tem a responsabilidade de criar as tarefas a partir das estórias selecionadas na etapa anterior. Cada estória poderá ser desmembrada em quantas tarefas foram necessárias. Para Varaschim (2009), o objetivo desta etapa é realizar o detalhamento de todas as necessidades para desenvolver cada estória selecionada e identificar se a estimativa inicial estava de acordo com as atividades existentes. Após finalizar as estimativas, deve-se verificar se as tarefas poderão ser realizadas em apenas uma Sprint. Caso seja identificado que as tarefas não poderão ser executadas no prazo, devese conversar com o Product Owner de forma a rever as estórias que compõem a Sprint. Se ocorrer o contrário, ou seja, se for identificado que as tarefas serão finalizadas antes do prazo, deve-se identificar a possibilidade de adicionar mais estórias. De acordo com Varaschim (2009), cada tarefa criada pelo Scrum Team deve requerer no máximo um dia, para que possam ser acompanhadas no Daily Scrum Meeting. Se o tempo de execução da tarefa for maior que o período de oito horas, pode-se dividi-la em duas ou mais tarefas menores Daily Scrum Meeting A reunião diária (Daily Scrum Meeting) é um encontro rápido realizado todos os dias, na qual os participantes permanecem em pé e comentam todas as tarefas realizadas deste a última reunião, o que será realizado e quais impedimentos foram detectados (VARASCHIM, 2009). Para Paasivaara, Durasiewicz e Lassenius (2009), o uso destas reuniões diárias é considerado a prática mais importante no Scrum e deve durar aproximadamente quinze minutos. Alguns autores consideram reuniões diárias de trinta minutos. No Daily Meeting a equipe deve responder às seguintes perguntas (PEREIRA; TORREÃO; MARÇAL, 2007): O que foi feito desde ontem? O que se planeja fazer para amanhã? Existe algum impedimento? 15

29 De acordo com Ferreira et al. (2006), deve-se certificar de que estas reuniões são realizadas sempre no mesmo horário e local de modo que não se perca tempo procurando um local para realização da mesma, assim como evitar que as equipes precisem descobrir a cada dia o local e horário de execução da reunião Sprint Review A revisão de Sprint (Sprint Review) é uma reunião realizada ao término da Sprint para que a equipe possa apresentar ao Product Owner o resultado do trabalho. Para Varaschim (2009), uma boa prática na metodologia Scrum é o Product Owner acompanhar a execução da Sprint. Deste modo, na reunião de revisão, o Product Owner tem o conhecimento de praticamente todo o andamento da Sprint e sabe quais as estórias finalizadas. Após a apresentação do trabalho realizado, o Product Owner irá realizar os testes para verificar se as condições estabelecidas foram alcançadas. Qualquer problema relacionado ao prazo, alteração das Sprints e estórias não finalizadas, deve ser discutido com o Product Owner. De acordo com Varaschim (2009), o ideal é realizar esta validação das estórias em um ambiente de produção, até porque um dos princípios do Scrum é a entrega de software funcional ao final da Sprint. Entretanto, esta questão pode variar de acordo com a empresa Sprint Retrospective A reunião de retrospectiva (Sprint Retrospective) é realizada também ao final da Sprint, após o Sprint Review. Seu objetivo é corrigir os problemas encontrados pelo time durante o processo de desenvolvimento e identificar melhorias para as próximas Sprints (VARASCHIM, 2009). Para Ferreira et al. (2009), as seguintes questões devem ser respondidas durante a reunião de retrospectiva: Qual o valor acrescentado nesta Sprint? Quais estórias do Sprint Backlog foram finalizadas? Qual o retorno por parte do Product Owner? Quais os acontecimentos relevantes para o grupo durante a execução da Sprint? Qual a experiência pessoal individual? 16

30 Quais conclusões podem ser extraídas desta Sprint? Como se pode melhorar a próxima Sprint? Durante a reunião de retrospectiva, podem participar o time e o Scrum Master. Pode haver também outros participantes, mas devem ser convidados pelo time. De acordo com Varaschim (2009), esta é a ocasião em que o Scrum Master tem como responsabilidade auxiliar o time a encontrar e resolver os problemas Artefatos Nesta Seção são apresentados conceitos e técnicas utilizadas na metodologia Scrum para planejar, estimar, controlar e acompanhar os processos de um projeto. Nas subseções seguintes, são detalhados cada um destes artefatos sendo que nas seções do Planning Poker e do Task Board são apresentadas ferramentas similares para exemplificar o conteúdo descritivo Product Backlog O Product Backlog é uma lista dos requisitos, tanto funcionais como não funcionais. Em cada item desta lista é associado um valor de negócio (Business Value), pelo qual se pode medir o retorno do projeto e a priorização dos itens (LUDVIG; REINERT, 2007). Como descrito por Varaschim (2009), o valor de negócio é de responsabilidade do Product Owner e o Scrum Team tem a responsabilidade de definir a complexidade de cada item do Product Backlog. Uma das técnicas utilizadas na definição do valor de negócio é dar um valor de pontos limitado para o Product Owner distribuir entre os itens do Product Backlog. Os itens do Product Backlog são chamados de estórias (Stories). Cada estória descreve uma funcionalidade, melhoria ou correção que deverá ser implementada no sistema (VARASCHIM, 2009). A estória deve indicar uma necessidade de software e não especificar como será desenvolvida de forma que, para isto, não deve ser adotada linguagem técnica ou complexa, de forma que tanto a equipe de desenvolvimento quanto o cliente tenham conhecimento do que se trata. 17

31 Impediment Backlog O Impediment Backlog, de acordo com Pereira, Torreão e Marçal (2007), contém todos os itens que impedem o progresso do projeto e normalmente estão associados a riscos. Os itens do Impediment Backlog não possuem uma priorização, mas estão geralmente associados a algum item de Backlog do produto ou a tarefas do item. O gerenciamento desses itens é responsabilidade do Scrum Master de forma que se possa abrir caminho para a equipe executar as tarefas do projeto. Para Varaschim (2009), em grandes empresas é comum a criação de equipes de Gerentes e Diretores com objetivo de auxiliar na resolução de problemas. Entretanto, é necessário que a equipe esteja disposta a compartilhar seus problemas e impedimentos, algo não muito comum em metodologias tradicionais. De acordo com Paasivaara, Durasiewicz e Lassenius (2008), durante algum tempo após a implantação da metodologia Scrum, é bastante difícil estimular os envolvidos a comentar sobre suas atividades e impedimentos Planning Poker De acordo com Pereira, Torreão e Marçal (2007), o Planning Poker pode ser definido como um jogo realizado no Sprint Planning Meeting entre os integrantes da equipe de desenvolvimento do produto de forma a avaliar a complexidade de cada item do Product Backlog. Esta avaliação é importante para identificar quantas tarefas podem ser executadas em cada Sprint com base no tempo de desenvolvimento estimado para cada item do Backlog. O objetivo do Planning Poker é realizar a definição da complexidade de cada item de forma mais dinâmica e com a contribuição de todos os participantes (PEREIRA; TORREÃO; MARÇAL, 2007). Para demonstrar a importância do Planning Poker na metodologia Scrum, deve-se inicialmente visualizar a situação inversa, ou seja, quando não se utiliza o Planning Poker, como ilustra a Figura 3. Em uma reunião de planejamento, o Product Owner inicia questionando aos integrantes da equipe sobre quanto tempo será necessário para desenvolver determinado item do Product Backlog. No primeiro momento, cada integrante faz uma análise da estória buscando identificar sua complexidade. O integrante A, acredita que é uma tarefa simples e poderá ser finalizada rapidamente. Os integrantes B e C, por sua vez, têm uma visão diferente e acreditam que irá demandar mais tempo, enquanto que, o restante da equipe, não está prestando atenção à reunião. No momento seguinte, cada integrante precisa expressar verbalmente suas opiniões. O primeiro a 18

32 comunicar é o integrante A. Os integrantes B e C ficam surpresos com a complexidade baixa escolhida por A, sendo que os valores pensados por eles são bastante diferentes. O restante da equipe continua não dando importância à reunião (CRISP, 2010). Finalmente, no Momento 3, o Product Owner solicita que o restante da equipe informem suas respectivas opiniões. Através da Figura 3, pode-se perceber que os valores estimados pelos integrantes B e C, diferem de suas ideias iniciais e os integrantes D e E simplesmente repetiram o valor informado pelo primeiro integrante. É visível que o restante do grupo foi influenciado pela estimativa do integrante A. Este é um exemplo de como a complexidade dos itens do Product Backlog podem ser estimados de forma errônea, prejudicando o projeto como um todo (CRISP, 2010). Momento 1 Pessoal, quanto irá demorar esta estória? Momento 2 Momento 3 Figura 3. Estimando o Product Backlog sem Planning Poker. Fonte: Adaptado de Crisp (2010) 19

33 A solução para que a complexidade dos itens de Backlog seja estimada de forma apropriada, é utilizar o Planning Poker. Neste jogo, cada integrante recebe um conjunto de cartas, como mostra a Figura 4, representando um conjunto semelhante à Sequência de Fibonacci. Para Varaschim (2009), a lógica associada à utilização desta sequencia está na diferença entre cada um dos valores utilizados, o que permite ver claramente o quão complexa é cada uma das funcionalidades. Estas diferenças mapeiam melhor as incertezas associadas à avaliação. É importante ressaltar que os valores das cartas do baralho de Planning Poker podem variar de acordo com a metodologia adotada. O baralho de Planning Poker também pode conter cartas com funções especiais, como mostra a Figura 4. A carta com valor zero pode significar que a tarefa já está finalizada ou é necessário apenas alguns minutos para concluí-la. A carta com o ponto de interrogação é utilizada quando o integrante não tem nenhum conhecimento do item em discussão. Se esta carta for utilizada frequentemente, a equipe precisa discutir melhor sobre o projeto e compartilhar o conhecimento entre todos. Por fim, a carta com a xícara de café pode ser utilizada quando o participante não está em condições de refletir, e precisa de uma pequena pausa antes de prosseguir (CRISP, 2010). Figura 4. Sequência de cartas do Planning Poker. Fonte: Crisp (2010). Para estimar a complexidade de cada item do Product Backlog através do Planning Poker, pode-se utilizar o processo exemplificado na Figura 5. Para este jogo, cada integrante do grupo deve possuir um conjunto de cartas do Planning Poker. Novamente, no Momento 1, o Product Owner pergunta a equipe quanto tempo determinado item irá necessitar para ser desenvolvido. Cada integrante pensa em algum valor de acordo com a sequência determinada pelo conjunto de cartas (CRISP, 2010). Para realizar a estimativa através do Planning Poker, torna-se necessário que todos os integrantes estejam atentos. Na situação anterior, cada integrante apresentava verbalmente o valor escolhido, entretanto, a ideia deste jogo é que cada um escolha uma carta do baralho que represente o valor estimado. Isto faz com que os resultados apresentados sejam fiéis às opiniões de cada 20

34 participante e não uma influência dos valores apresentados inicialmente. Enfim, após todos escolherem suas respectivas cartas, viram-se todas simultaneamente revelando a toda equipe as cartas escolhidas (CRISP, 2010). No segundo momento, quando todos apresentam suas cartas, percebe-se que há diferentes valores escolhidos. Quando isto ocorre, deve-se discutir e buscar compreender os motivos que levaram cada integrante a escolher determinado valor. Cada opinião apresentada é importante porque a partir dela o restante da equipe pode compreender determinados fatores que os façam repensar em suas decisões. Entretanto, é importante manter o controle do jogo, sendo responsabilidade do Scrum Master, intervir caso não se chegue a um consenso, como apontado por Varaschim (2009). Neste exemplo, como ilustrado pela Figura 5, a maior diferença está entre os valores escolhidos por A e C. Através de alguns detalhes apresentados por C, o integrante A percebe que a estória pode ser mais complexa do que imagina. O integrante C, por sua vez, compreende que através das ideias de A, o desenvolvimento pode ocorrer mais rapidamente do que ele havia previsto. Após a discussão das ideias rapidamente, realiza-se uma nova rodada no Planning Poker (CRISP, 2010). Ao final, no Momento 3, as cartas são novamente apresentadas e a diferença entre os valores escolhidos agora é bem menor. Após todos mostrarem suas cartas, a equipe entra em consenso e decide atribuir o valor cinco para esta estória. Feito isso, seleciona-se o próximo item e o Planning Poker prossegue com uma nova rodada (CRISP, 2010). 21

35 Momento 1 Pessoal, quanto irá demorar esta estória? Momento 2 Momento 3 Figura 5. Estimando o Product Backlog com Planning Poker. Fonte: Adaptado de Crisp (2010) Através dos exemplos apresentados pode-se concluir que o Planning Poker tem grande importância na metodologia Scrum. Entretanto, em equipes distribuídas geograficamente, torna-se impraticável realizar este jogo da forma tradicional, ou seja, em um mesmo espaço físico e utilizando um baralho de cartas. A solução para esta questão é utilizar um Planning Poker eletrônico, de forma que o Product Backlog possa ser estimado dinamicamente apesar do distanciamento físico existente. Algumas das ferramentas apresentadas na Seção 2.3, na qual são demonstradas ferramentas de gerenciamento de projetos com a metodologia Scrum, possuem o Planning Poker integrado. A vantagem de se possuir este módulo integrado está no fato de que se torna mais fácil utilizar o cadastro de itens do Product Backlog ao invés de simplesmente avaliar individualmente a complexidade de cada um destes itens. Ao utilizar uma ferramenta externa, a equipe estaria obrigada a informar todo o Product Backlog neste sistema para, ao final da reunião de 22

36 planejamento, informar no sistema de gerenciamento de projetos os valores estimados no Planning Poker. O Planning Poker integrado às ferramentas selecionadas na Seção 2.3 é mais bem detalhado nas respectivas ferramentas. Entretanto, é importante apresentar uma ferramenta externa para que se possa realizar uma avaliação de suas funcionalidades. Disponível através da web, a ferramenta gratuita Planning Poker, desenvolvida pela Mountain Goat Software, permite que equipes distantes possam utilizar este método sem necessitar de um software específico (MONTAIN GOAT SOFTWARE, 2010). Para utilizar a ferramenta Planning Poker, basta que um usuário realize o cadastro no site e forneça ao restante do grupo o endereço eletrônico para acesso à sessão do Planning Poker. O usuário que criou a sessão deverá descrever cada estória e controlar o início e término para avaliação de cada item. Na Figura 6 é possível visualizar na parte superior, que houve uma rodada em que duas cartas foram selecionadas, entretanto se decidiu iniciar uma nova rodada para avaliação. Um dos participantes escolheu uma carta, mas ela permanece disposta de forma que não se possa visualizar seu valor. Nesta ferramenta, o usuário pode selecionar a carta que deseja através do mouse, de forma bastante interativa como mostra a Figura 6. Figura 6. Seleção da carta no Planning Poker. Fonte: Montain Goat Software (2010) 23

37 Na ferramenta Planning Poker, após todos os participantes selecionarem suas cartas, mostrase o conteúdo de todas elas. O usuário que criou a sessão, que é provavelmente o Scrum Master, deverá avaliar as cartas de cada participante. Se houver a necessidade, pode-se discutir o assunto e iniciar uma nova rodada caso os valores possuam grande diferença entre si. Caso contrário, poderá simplesmente informar o valor de complexidade da estória, como mostra a Figura 7. Para os itens seguintes do Product Backlog, segue-se o mesmo procedimento. Figura 7. Definição da complexidade do item em análise. Fonte: Montain Goat Software (2010) Apesar de a ferramenta estar disponível gratuitamente e ser bastante prática, torna-se necessária a criação de um módulo para esta finalidade no software de gerenciamento de projetos. Desta forma, evita-se a inserção desnecessária de dados já que as informações estarão previamente gravadas, sendo necessário apenas iniciar o Planning Poker. Este Trabalho de Conclusão de Curso teve como objetivo desenvolver o Planning Poker simulando o ambiente real do jogo. Cada integrante deverá conectar-se a uma sessão no mesmo horário, e avaliar cada item do Product Backlog escolhendo uma carta que corresponda à complexidade da funcionalidade a ser implementada Task Board O Scrum, assim como grande parte das metodologias ágeis, busca evitar burocratização dos processos. Entretanto, é necessário haver uma forma de acompanhar o andamento de projeto e identificar quais tarefas estão sendo realizadas e quais os desenvolvedores estão associados a estas 24

38 tarefas. Para este objetivo, utiliza-se o Task Board, definido basicamente como um quadro dividido em colunas, cada qual representando um estágio do desenvolvimento. O Task Board apresenta todas as tarefas que precisam ser executadas em uma determinada Sprint e, por este motivo, pode-se dizer que representa o Sprint Backlog (RUBART; FREYKAMP, 2009). Na Figura 8, pode-se visualizar um exemplo de Task Board. Figura 8. Task Board. Fonte: Rubart e Freykamp (2009) Cada coluna do Task Board corresponde à situação atual de uma determinada tarefa. Costuma-se realizar as mudanças das tarefas entre uma coluna e outra durante o Daily Scrum, reunião realizada no início do expediente. A primeira coluna apresenta as estórias selecionadas para a Sprint em andamento sendo que cada um destes itens pode possuir mais de uma tarefa ao mesmo tempo. A segunda, terceira e última coluna, respectivamente, correspondem às tarefas Para Fazer, Em Andamento e Concluídas. De acordo com Rubart e Freykamp (2009), uma tarefa é uma pequena unidade de trabalho identificada e estimada pelo time. É recomendável que as tarefas não ultrapassem o prazo de oito 25

39 horas (alguns autores definem que as tarefas podem possuir até dezesseis horas). Caso isto ocorra, pode ser necessário dividi-las em tarefas menores. Durante o Daily Scrum, momento no qual as tarefas são movidas entre as colunas do Task Board, pode-se identificar a necessidade de criar, dividir ou excluir determinadas tarefas. O Task Board é um artifício muito importante para projetos que utilizam Scrum como metodologia. Entretanto, quando as equipes estão geograficamente distribuídas, não há como utilizar um quadro físico. Um time distribuído necessita de uma ferramenta eletrônica que possibilite este acompanhamento de forma virtual e esteja de acordo com os princípios básicos de qualquer metodologia ágil. Para Rubart e Freykamp (2009), uma ferramenta eletrônica de Task Board deve possibilitar a criação, exclusão e alteração destes quadros virtuais. Para não haver um distanciamento muito grande do foco deste artefato, deve-se tornar a ferramenta eletrônica semelhante com a estrutura física comumente utilizada. De acordo com Perry (2008), existem muitas vantagens em se utilizar um Task Board eletrônico. A primeira delas corresponde ao fato de que uma ferramenta eletrônica disponível através da Internet, pode ser acessada em qualquer local do mundo. Isto é bastante útil quando se tem equipes distribuídas geograficamente. Em segundo lugar, possibilita uma série de integrações com outros softwares e ferramentas. E, por último, possibilita manter um histórico de todo o trabalho realizado durante o projeto para que posteriormente possam ser identificados padrões e, deste modo, encontrar formas de otimizar os projetos seguintes. Apesar das vantagens apresentadas, existem diversos fatores negativos na utilização do Task Board eletrônico, identificadas por Perry (2008). Em primeiro lugar, usando uma ferramenta eletrônica, pode-se perder o foco na interação entre pessoas e isto é contrário aos princípios da metodologia Scrum. Outra desvantagem refere-se à menor disponibilidade de acesso à ferramenta pelo fato de que depende do acesso à internet. Além disso, se ocorrerem problemas técnicos como uma queda de servidor, por exemplo, o Task Board fica indisponível. E, finalmente, o uso de ferramentas eletrônicas requer um treinamento maior para a equipe, causando um atraso inicial no desenvolvimento do projeto. Existem diversas ferramentas de gerenciamento de projetos com Scrum que possuem o módulo Task Board integrado. Algumas das ferramentas estudadas neste trabalho possuem esta funcionalidade, como apresentado no Capítulo 2.3, em que são apresentados exemplos de Task Boards integrados. Além dos softwares de gerenciamento de projetos, existem ferramentas 26

40 exclusivas para Task Board. Estas ferramentas não possuem informações relacionadas ao Product Backlog, Sprints e outros conceitos. São utilizadas apenas para gerenciar e distribuir os cartões do Task Board eletrônico. Uma das ferramentas encontradas está disponível na internet, chamada Taskboard desenvolvida pela Cognifide (COGNIFIDE, 2010), que permite a criação de Task Boards virtuais e é indicada para uso de equipes distribuídas geograficamente. Na Figura 9, pode-se visualizar um quadro de demonstração disponível na página da ferramenta, com as quatro colunas utilizadas na metodologia Scrum. Figura 9. Tela da ferramenta Taskboard. Fonte: Cognifide (2010) Esta ferramenta permite que sejam criadas quantas colunas forem necessárias e possui uma interface bastante intuitiva, de forma que o usuário possa simplesmente arrastar os cartões entre as colunas, como faria em um Task Board físico. Entretanto, para o objetivo deste trabalho, não é uma ferramenta completa pelo fato de não possuir os outros módulos importantes para o uso em desenvolvimento de software com Scrum. Apesar de a ferramenta permitir a visualização do Burndown Chart, não atende às necessidades descritas neste trabalho: fornecer à equipe Scrum todos os artefatos da metodologia, incluindo também os módulos Planning Poker e Burndown Chart. Deste modo, ao aplicar os conceitos desta ferramenta e integrá-los ao Scrum Project, pretende-se obter um resultado mais positivo devido à integração de suas funcionalidades com os outros módulos exigidos pela metodologia Scrum. 27

41 Burndown Chart Na metodologia Scrum, são utilizados artifícios para apresentar as informações à equipe, de forma que esta possa acompanhar o andamento do projeto. Para o acompanhamento da execução das atividades no projeto são utilizadas duas formas de representação gráficas semelhantes denominadas Burndown Chart. De acordo com Marçal et al. (2007), o Product Burndown representa a velocidade de entrega dos itens do Product Backlog pelo time. Seu objetivo é identificar se as funcionalidades previstas poderão ser entregues no prazo. Se for identificado que algumas das estórias não estarão finalizadas ao término do prazo, pode-se negociar a retirada de requisitos. O Sprint Burndown representa a velocidade e progresso de evolução das tarefas em uma determinada Sprint, possibilitando ao time identificar se as tarefas poderão ser finalizadas até o término da mesma. Na Figura 10, pode-se observar um exemplo de Sprint Burndown. O eixo vertical indica o total de horas necessárias para finalizar as tarefas e o eixo horizontal os dias que representam o tamanho da Sprint. Com base na quantidade de tarefas realizadas diariamente, pode-se identificar se a execução da Sprint está ocorrendo dentro do prazo. Se as estimativas estiverem erradas e o número de tarefas diárias não for cumprido, a linha mais grossa tende a subir e distanciar-se da reta de atividades diária. Este é o indicativo de que provavelmente as tarefas foram mal avaliadas ou existe algum impedimento que não permite a execução de alguma tarefa. A situação inversa ocorre quando a linha mais grossa fica abaixo da reta indicando que as tarefas foram superestimadas e a Sprint deve acabar antes do prazo esperado (VARASCHIM, 2009). Figura 10. Sprint Burndown. Fonte: Adaptado de Varaschim (2009) 28

42 Usualmente, mantêm-se o gráfico Burndown próximo ao Task Board, para que o time possa ter uma visão completa do projeto, como pode ser observado na Figura 11. Para Varaschim (2009), o acompanhamento diário desta ferramenta é muito importante para detectar tarefas estimadas de forma errada e realizar a correção para entrega das funcionalidades no prazo. As informações do Burndown são atualizadas diariamente durante o Daily Scrum e, como apontado por Srinivasan e Lundqvist (2009), é responsabilidade do Scrum Master realizar esta atualização das informações do gráfico. Figura 11. Gráfico Burndown e Task Board. Fonte: Perry (2008) Em equipes geograficamente distribuídas, torna-se inviável utilizar um gráfico Burndown comum. Para isto, é necessário utilizar outros meios que forneçam ao time os mesmos recursos. Uma solução para este problema é utilizar uma ferramenta eletrônica que forneça os gráficos Burndown Chart. Todas as ferramentas de gerenciamento de projetos estudadas neste trabalho 29

43 possuem este recurso, exceto a primeira versão do Scrum Project. A vantagem da utilização em meio eletrônico é a economia de tempo pelo fato de não ser necessário realizar a atualização manual do gráfico, visto que a ferramenta pode gerar o gráfico automaticamente com base nas informações registradas pela equipe. 2.3 Ferramentas de gerenciamento com Scrum Neste capítulo são analisadas algumas ferramentas disponíveis no mercado com o mesmo objetivo que a ferramenta proposta neste Trabalho de Conclusão de Curso. Na primeira Seção é descrito o software Scrum Project, o qual é objeto de estudo neste trabalho. Em seguida, outras ferramentas são apresentadas para identificar as características positivas nestes projetos e evitar as falhas encontradas Scrum Project O Scrum Project é uma ferramenta web para o gerenciamento de projetos através da metodologia ágil Scrum, desenvolvida para um Trabalho de Conclusão de Curso, em 2009, do curso de Ciência da Computação, da Universidade do Vale do Itajaí (UNIVALI). O requisito principal no desenvolvimento da ferramenta era sua utilização em ambiente web, para oferecer independência de plataforma e maior disponibilidade aos usuários (KLUGE, 2009). Para a produção desta ferramenta, utilizou-se o ScriptCase, um ambiente de desenvolvimento de aplicações web que permite a geração de telas e menus de forma automatizada (KLUGE, 2009). Esta ferramenta realiza a geração do código fonte, mas exige que quaisquer manutenções venham a ser feitas através do ScriptCase. O Scrum Project foi desenvolvido na linguagem PHP e se utilizou o PostgreSQL como banco de dados. O Scrum Project possui três perfis de usuário: Scrum Master, Product Owner e Scrum Team. Quando o usuário acessa o sistema, as opções disponíveis variam para cada perfil. Através da Figura 12, pode-se ter uma ideia da tela inicial apresentada pelo Scrum Project. 30

44 Figura 12. Tela inicial do Scrum Project. Fonte: Kluge (2009) O Scrum Project permite realizar o cadastro de usuários e, a partir destes usuários, cadastrar times. Para iniciar um projeto, deve-se primeiro cadastrá-lo, para em seguida definir seu Product Backlog. Por fim, pode-se selecionar os itens do Backlog que irão compor a Sprint. Para cada item do Product Backlog, pode ser informada sua prioridade, a estimativa e o fator de impedimento, se necessário. Pode-se visualizar a tela de cadastro do Product Backlog na Figura

45 Figura 13. Cadastro do Product Backlog no Scrum Project. Fonte: Kluge (2009). O Scrum Project possui ainda a possibilidade de cadastrar as diversas reuniões especificadas pelo Scrum como Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective. Para o Scrum Master também existe uma opção para geração de relatório, no qual é possível visualizar as tarefas em atividade e identificar o número de horas despendidas com o desenvolvimento (KLUGE, 2009). A ferramenta Scrum Project atende às características básicas do Scrum e está de acordo com a metodologia. Entretanto, para que possa ser utilizada por profissionais, são necessárias revisões no que se refere à interface e inclusão de novos módulos. Nas seções anteriores, percebeu-se a grande importância de um Task Board eletrônico e do Planning Poker, principalmente para equipes geograficamente distribuídas. Outra funcionalidade muito importante é o gráfico Burndown, utilizado para acompanhar o progresso do projeto. Todas estas funcionalidades não estão presentes na ferramenta, sendo proposta deste trabalho, atender a estas necessidades integrando-as ao Scrum Project. Para esta reestruturação da ferramenta também estão previstas a disponibilização da ferramenta no idioma inglês, através do uso de Internacionalização, e a revisão do processo de instalação da ferramenta e geração do banco de dados. Da forma como está atualmente, torna-se difícil iniciar o uso da ferramenta que, além do processo manual de instalação, necessita também possuir a ferramenta ScriptCase instalada. 32

46 Outra mudança necessária para esta nova versão da ferramenta, foi adoção de um framework open source de desenvolvimento, visto que o ScriptCase possui somente uma versão comercial ou Trial, com limitação de uso por vinte dias (SCRIPTCASE, 2010). Deste modo, torna-se mais difícil que estudantes e desenvolvedores possam contribuir no desenvolvimento do ScrumProject ou personalizá-lo para uso próprio, de acordo com os princípios do open source FireScrum A ideia do FireScrum ocorreu em um trabalho de dissertação de mestrado, como descrito por Cavalcanti, Maciel e Albuquerque (2009), sendo que as funcionalidades foram implementadas por cerca de sessenta pós-graduandos da disciplina de Engenharia de Software da Universidade Federal de Pernambuco. O FireScrum foi desenvolvido utilizando conceitos da Web 2.0 e de Rich Internet Applications (RIA). Para isto, utilizou-se o framework Adobe Flex, próprio para este formato de aplicação. É uma aplicação web, podendo ser utilizada em um ambiente de Internet ou Intranet, apresentando uma arquitetura modular e extensível (CAVALCANTI; MACIEL; ALBUQUERQUE, 2009). As funcionalidades do FireScrum estão organizadas em módulos integrados e independentes entre si. Existe um módulo principal chamado de Core, considerado o principal módulo da ferramenta, sendo autossuficiente para contemplar todo o ciclo de um projeto Scrum. Os demais são considerados módulos de apoio, como o Planning Poker e Task Board. O Planning Poker, como citado anteriormente, é bastante importante na avaliação da complexidade de cada estória do Product Backlog. O FireScrum possui um módulo para este jogo, sendo necessário apenas escolher um dos itens disponíveis e previamente cadastrados. Cada integrante da equipe deverá acessar o sistema e entrar em uma sessão criada pelo usuário líder. Em seguida, os participantes deverão selecionar as cartas de sua preferência e aguardar até que todos façam sua escolha, como mostra a Figura 14. Ao final, o usuário líder deverá gravar a complexidade definida através do jogo. 33

47 Figura 14. Módulo do Planning Poker no FireScrum. Além do módulo de Planning Poker, o FireScrum possui outro módulo bastante importante em uma ferramenta de gestão: o Task Board. Como explicado anteriormente, quando as equipes estão dispostas no mesmo espaço físico, torna-se possível utilizar post-its em um quadro fixado em qualquer superfície. Entretanto, para as equipes em que isto não é possível, pode-se utilizar uma ferramenta que simula um Task Board. No FireScrum, esta ferramenta existe e é bastante dinâmica, permitindo arrastar as tarefas entre as diversas colunas do quadro. E o fato mais importante nesta questão é que o quadro de tarefas está integrado ao Product Backlog e ao cadastro de Sprints tornando a utilização muito mais simplificada. Na Figura 15, pode-se visualizar o Task Board com algumas tarefas de exemplo cadastradas. 34

48 Figura 15. Módulo do Task Board no FireScrum. No FireScrum também é possível cadastrar Projetos, Sprints, Estórias e Tarefas. Na Figura 16, pode-se ter uma ideia da tela para cadastro de Sprints. Com base nestas constatações, pode-se afirmar que este é um software bastante aplicável às equipes que utilizam Scrum. 35

49 Figura 16. Tela para cadastro de Sprint no FireScrum. Outro ponto que deve ser levado em consideração na análise da ferramenta é a sua instalação e configuração. O FireScrum exige que sejam instalados softwares de terceiros como o pacote Java JDK, Apache Tomcat, Red5 e o banco de dados PostgreSQL (FIRESCRUM, 2010). Todo o processo de instalação é demorado e exige algum tempo para definir as configurações. Contudo, como isto normalmente é feito apenas uma vez, acaba não sendo um grande problema, exceto para os usuários que desejam apenas testar a ferramenta. Em contrapartida, alguns procedimentos são automáticos, como a geração das tabelas do banco de dados. Uma das grandes vantagens da ferramenta é o fato dela ser open source, que permite a colaboração de diversos desenvolvedores, de qualquer lugar do mundo VersionOne VersionOne é uma ferramenta desenvolvida pela VersionOne (VERSIONONE, 2010), sendo bastante utilizada por empresas de desenvolvimento de software, como pode ser observado no gráfico da Figura 17. Sua função é auxiliar o gerenciamento de projetos de software, sendo possível 36

50 utilizá-lo com diversas metodologias ágeis como Scrum, XP, Kanban, AgileUP, e DSDM. Esta ferramenta está disponível no idioma inglês e é oferecida como Software as a Service (SAAS). É possível escolher entre três versões do software: Team, Enterprise e Ultimate. A primeira delas é gratuita para a qual grande parte dos recursos não é disponibilizada. Figura 17. Utilização de ferramentas em empresas de desenvolvimento de software. Fonte: Adaptado de VersionOne (2009). A ferramenta VersionOne possui uma grande quantidade de cadastros dentre eles Projects, Product Backlog, Sprints, entre outros. Na Figura 18, pode-se visualizar a tela do módulo de Product Backlog. Todas as telas de cadastro possuem uma grande quantidade informações para preencher. Isto é bastante importante para poder futuramente recolher informações e estatísticas. Entretanto, muitas das tarefas simples como cadastrar um item de Backlog, podem acabar demorando mais do que o necessário, como ocorreu durante a análise da ferramenta. Esta situação acaba indo de encontro aos princípios do Scrum. 37

51 Figura 18. Tela de Product Backlog da ferramenta VersionOne. Fonte: VersionOne (2010) Outra funcionalidade existente na ferramenta VersionOne, é o Task Board, apresentado na Figura 19. Através deste módulo, pode-se cadastrar tarefas e realizar operações nas estórias. Para transferir as tarefas em uma coluna e outra, basta arrastá-las utilizando o ponteiro do mouse. Também é possível escolher um determinado usuário para que suas tarefas fiquem com uma cor diferenciada. Figura 19. Task Board da ferramenta VersionOne. Fonte: VersionOne (2010) 38

52 Esta ferramenta oferece também uma grande quantidade de relatórios e gráficos, incluindo também o Burndown Chart, como mostra a Figura 20. Entretanto, através da análise realizada, percebeu-se que a VersionOne é uma ferramenta bastante complexa e burocrática. Apesar da grande quantidade de opções disponibilizadas ao usuário, o software deixa a desejar quanto à flexibilidade e agilidade que o Scrum necessita. Apesar de essa questão depender muito da necessidade do cliente, para os objetivos deste trabalho esta ferramenta não é adequada pela grande quantidade de opções disponíveis e complexidade excessiva para executar operações básicas. Figura 20. Product Burndown da ferramenta VersionOne. Fonte: VersionOne (2010) Outro ponto negativo, de acordo com as necessidades deste trabalho, é o fato de não ser distribuído como software open source. Além do custo alto para a aquisição da ferramenta, a empresa precisa adaptar seus processos de acordo com o software. Quando é open source, é possível adaptar ou realizar melhorias para que a ferramenta esteja mais adequada aos processos internos. Entretanto, grandes empresas podem optar por comprar uma ferramenta pronta ao invés de alocar uma equipe para fazer modificações em um software open source. De qualquer forma, sempre existe a necessidade de uma ferramenta open source, principalmente para fins acadêmicos. 39

53 2.3.4 TargetProcess TargetProcess é uma ferramenta web, desenvolvida pela empresa TargetProcess (TARGETPROCESS, 2010), para gerenciamento de projetos através dos padrões da metodologia ágil. É um software bastante flexível pelo fato de poder ser utilizada com qualquer metodologia ágil já que trabalha com conceitos genéricos. É uma ferramenta distribuída no idioma inglês, oferecida como serviço ou hospedada em servidor próprio. É utilizada por grandes empresas como Intel, Sony, Epson, entre outras (TARGETPROCESS, 2010). No site da empresa, é possível solicitar uma versão de demonstração. Através da análise realizada, pôde-se perceber que a TargetProcess é uma ferramenta bastante simples de utilizar, exigindo poucas operações para realizar os primeiros cadastros. Sua interface é bastante organizada tornando fácil a identificação das informações mais importantes durante sua utilização. Como citado no parágrafo anterior, esta é uma ferramenta que pode ser utilizada em diversas metodologias ágeis e, por este motivo, muitas funcionalidades possuem uma denominação genérica. Pode-se observar, por exemplo, através da Figura 21, que o Product Backlog do Scrum é apresentado neste software como User Stories. Figura 21. Cadastro de Stories da ferramenta TargetProcess. Fonte: TargetProcess (2010) Outra funcionalidade bastante importante e citada nas seções anteriores, é o Task Board, como mostra a Figura 22. A ferramenta TargetProcess possui este módulo no qual é possível 40

54 arrastar as tarefas através do mouse entre duas colunas, a primeira correspondendo às tarefas abertas enquanto que a segunda, as tarefas finalizadas. Pode-se ainda filtrar somente as tarefas de determinado integrante da equipe, facilitando a visualização quando se tem uma grande quantidade de tarefas cadastradas. Figura 22. Task Board da ferramenta TargetProcess. Fonte: TargetProcess (2010) E por fim, a ferramenta também oferece diversas opções de relatórios e disponibiliza gráficos Burndown Chart personalizáveis para acompanhamento das tarefas, como se pode observar na Figura 23. Neste gráfico, pode-se personalizar as informações apresentadas de acordo com a necessidade do usuário. Além disso, diferentemente de algumas ferramentas, este gráfico Burndown exibe para cada dia no eixo horizontal, o número de horas produzidas e o total de horas necessárias para finalizar a iteração. 41

55 Figura 23. Burndown Chart da ferramenta TargetProcess. Fonte: TargetProcess (2010) Como resultado final da análise, tem-se uma ferramenta bastante flexível e adequada aos princípios básicos das metodologias ágeis. Para os objetivos deste trabalho, sentiu-se a necessidade do Planning Poker e ainda pelo fato de ser uma ferramenta proprietária não atende aos requisitos estabelecidos pelo presente projeto. De qualquer forma, pode-se aproveitar diversas características deste software, principalmente no que se refere ao Task Board e Burndown Chart Comparativo Nesta Seção, são apresentados comparativos entre as ferramentas similares, a primeira versão do Scrum Project e a versão proposta por este trabalho. Inicialmente, realizou-se um comparativo entre as funcionalidades apresentadas por estas ferramentas para em seguida realizar um comparativo das características técnicas. Na Tabela 1, pode-se visualizar as características presentes em cada ferramenta analisada. A única ferramenta que possui todas as três funcionalidades propostas neste trabalho (Burndown 42

56 Chart, Planning Poker e Task Board) é o FireScrum. Entretanto, pode-se perceber que o FireScrum não possui os módulos Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective, bastante necessários, principalmente quando se tem equipes geograficamente distribuídas. Deste modo, ao integrar os três módulos propostos no Scrum Project, pode-se obter uma ferramenta bastante completa. Tabela 1. Comparativo de funcionalidades. Funcionalidades FireScrum VersionOne TargetProcess Scrum Project v.1.0 Scrum Project v.2.0 Product Backlog X X X X X Sprint Backlog X X X X X Sprint Planning - X - X X Daily Scrum X X Sprint Review - X - X X Sprint Retrospective - X - X X Burndown Chart X X X - X Planning Poker X X Task Board X X X - X Em um segundo momento, tem-se a análise comparativa das características destas ferramentas, apresentadas na Tabela 2. Pelo comparativo realizado, chegou-se à conclusão de que a grande maioria dos softwares de gerenciamento está disponível para plataforma web. Outro fator analisado se refere à licença de uso do software. Apenas uma das ferramentas é open source, enquanto que os outros softwares são proprietários. Além disso, todos os softwares estão disponíveis no idioma inglês, exceto pela primeira versão do Scrum Project. Para este Trabalho de Conclusão de Curso, pretende-se disponibilizar o Scrum Project em inglês, diferentemente da primeira versão da ferramenta. Tabela 2. Comparativo técnico. Ferramenta Licença Plataforma Idioma FireScrum Open source Web Inglês VersionOne Proprietário Web Inglês TargetProcess Proprietário Web Inglês Scrum Project v.1.0 Open source 1 Web Português Scrum Project v.2.0 Open Source Web Inglês 1 Apesar de ser open source, o código gerado pelo ScriptCase é tão complexo que se torna quase impossível fazer alterações diretamente no seu código fonte. 43

57 3 PROJETO Durante a fase de Projeto, realizou-se uma análise dos requisitos funcionais, não funcionais e regras de negócio definidos por Kluge (2009). A modelagem de software da primeira versão da ferramenta também foi revisada e modificada para atender às necessidades deste trabalho de reescrever o software e incluir novos módulos. 3.1 Análise de Requisitos Durante a etapa de análise de requisitos foram avaliadas todas as necessidades deste trabalho, partindo da proposta de implementação dos novos módulos. Em seguida, buscou-se estudar e avaliar os requisitos definidos por Kluge (2009) de modo que pudesse ser realizada a inclusão de novos requisitos e a modificação dos requisitos originais Requisitos Funcionais Como descrito por Sommerville (2008), os requisitos funcionais descrevem como o sistema deve se comportar em determinadas situações e como deve reagir à interações específicas com o usuário. Os requisitos funcionais estão agrupados em seis módulos originais, mantendo organização criada por Kluge (2009). Entretanto, buscando organizar os novos requisitos inseridos e as modificações realizadas, decidiu-se criar os seguintes módulos: Projeto, Tarefa e Planning Poker. Os requisitos funcionais deste trabalho são apresentados abaixo: Módulo 01 - Time e Usuário RF 01.01: O sistema deverá permitir ao Scrum Master alocar ou liberar usuários de um projeto; RF 01.02: O sistema deverá permitir ao Scrum Master cadastrar, alterar e inativar usuários; RF 01.03: O sistema deverá permitir ao Scrum Master definir papéis para os usuários (Scrum Team e Product Owner); RF 01.04: O sistema deverá permitir a todos os papéis alterar os próprios dados de usuário; 44

58 RF 01.05: O sistema deverá permitir a todos os papéis visualizar as informações de todos os usuários; e RF 01.06: O sistema deverá permitir a qualquer usuário cadastrado se autenticar no sistema. Módulo 02 - Projeto RF 02.01: O sistema deverá permitir a todos os papéis cadastrar um novo projeto; RF 02.02: O sistema deverá permitir ao Scrum Master alterar e inativar um projeto; e RF 02.03: O sistema deverá permitir a todos os papéis visualizar os dados do projeto no qual estão alocados. Módulo 03 - Product Backlog RF 03.01: O sistema deverá permitir ao Product Owner e Scrum Master cadastrar, alterar e excluir itens em um Product Backlog; RF 03.02: O sistema deverá permitir ao Product Owner e Scrum Master priorizar os itens de um Product Backlog; RF 03.03: O sistema deverá permitir ao Scrum Master e Scrum Team estimar os itens de um Product Backlog; e RF 03.04: O sistema deverá permitir a todos os papéis visualizar os dados de um item do Product Backlog. Módulo 04 - Sprint RF 04.01: O sistema deverá permitir ao Scrum Master cadastrar, alterar e excluir uma Sprint para um projeto; RF 04.02: O sistema deverá permitir ao Scrum Master inserir informações sobre a reunião de planejamento; 45

59 RF 04.03: O sistema deverá permitir ao Scrum Master e Scrum Team inserir informações sobre a reunião diária; RF 04.04: O sistema deverá permitir a todos os papéis inserir informações sobre a reunião de revisão em cada Sprint; RF 04.05: O sistema deverá permitir a todos os papéis inserir informações sobre a reunião de retrospectiva ao término de cada Sprint; RF 04.06: O sistema deverá permitir a todos os papéis visualizar o gráfico Sprint Burndown; e RF O sistema deverá permitir ao Scrum Master selecionar os itens do Product Backlog que irão compor a Sprint. Módulo 05 - Tarefa RF 05.01: O sistema deverá permitir ao Scrum Team cadastrar, alterar e excluir tarefas para um Backlog Item; RF 05.02: O sistema deverá permitir ao Scrum Team a alocação de tarefas; RF 05.03: O sistema deverá permitir ao Scrum Team informar o tempo de duração de cada tarefa; RF 05.04: O sistema deverá permitir ao Scrum Team alterar o status de andamento da tarefa; RF 05.05: O sistema deverá permitir ao Scrum Team associar um impedimento à tarefa; e RF 05.06: O sistema deverá permitir ao Scrum Team informar o tempo gasto em cada tarefa. Módulo 06 - Planning Poker RF 06.01: O sistema deverá permitir ao Scrum Master criar uma sessão do Planning Poker; 46

60 RF 06.02: O sistema deverá permitir ao Scrum Master selecionar os itens de backlog que serão estimados pelo time em determinada sessão; RF 06.03: O sistema deverá possibilitar ao Scrum Team estimar a complexidade dos itens de uma sessão; e RF 06.04: O sistema deverá permitir ao Scrum Master definir a complexidade final do Backlog Item tendo como base os valores informados pelos integrantes do time Requisitos Não Funcionais Como descrito por Sommerville (2008), os requisitos não funcionais são restrições sobre os serviços ou funções oferecidas pelo sistema e aplicam-se frequentemente ao sistema como um todo. Segue abaixo a listagem dos Requisitos Não Funcionais deste trabalho: RNF01: O sistema deverá ser voltado para WEB; RNF02: O sistema deverá ser desenvolvido na linguagem PHP; RNF03: O sistema deverá ser compatível com o banco de dados MySQL; RNF04: O sistema deverá solicitar ao usuário login e senha de acesso; RNF05: O sistema deverá ser desenvolvido somente através de ferramentas gratuitas e/ou open source; RNF06: O sistema deverá ser desenvolvido em MVC (Modelo, Visão e Controle); e RNF07: O sistema deverá permitir ao Scrum Team realizar o gerenciamento das tarefas através do Task Board Regras de Negócio De acordo com Sommerville (2008), as regras de negócio são derivadas do domínio de aplicação do sistema e podem estabelecer como determinadas ações devem ser tomadas com base nas características de domínio. 47

61 Em sequencia, são apresentadas as Regras de Negócio para o Scrum Project, utilizando-se de uma organização em pacotes semelhante à divisão realizada nos requisitos funcionais: Pacote 1 Cadastros Básicos RN 01.01: Um projeto deverá obrigatoriamente possuir as seguintes informações: nome, data de início, data de finalização, Scrum Master e Product Owner; RN 01.02: Um projeto deverá conter obrigatoriamente um Scrum Master e um Product Owner; RN 01.03: A data de finalização do projeto deve ser maior que a data de início; RN 01.04: Não poderá ser selecionado o mesmo usuário para Scrum Master e Product Owner em um mesmo projeto; RN 01.05: Um usuário deverá obrigatoriamente possuir as seguintes informações: nome, usuário e senha; RN 01.06: Não deverá haver usuários cadastros com mesmo nome de login; RN 01.07: O sistema não deverá permitir desvincular do projeto um usuário que possua informações cadastradas; RN 01.08: O Scrum Master e o Product Owner não podem ser alocados ao time do projeto; e RN 01.09: O Scrum é composto por três papéis: Product Owner, Scrum Master e Scrum Team. Pacote 2 Product Backlog RN 02.01: Uma estória deverá obrigatoriamente possuir as seguintes informações: descrição e valor de negócio; RN 02.02: Uma estória poderá ser selecionada para apenas uma Sprint; RN 02.03: Uma estória não pode ser excluída caso ela possua tarefas cadastradas; e 48

62 RN 02.04: Uma estória finalizada não pode ser alterada ou excluída. Pacote 3 Sprint RN 03.01: Uma Sprint deverá obrigatoriamente possuir as seguintes informações: descrição, data de início e data de finalização; RN 03.02: A data de finalização da Sprint não pode ser menor que a data de início; RN 03.03: A data de finalização da Sprint não pode ser maior que a data de finalização do Projeto; RN 03.04: Não pode ser excluída uma Sprint que possua estórias alocadas a ela; RN 03.05: Não pode ser excluída uma Sprint finalizada; RN 03.06: O cadastro da Reunião de Planejamento deverá obrigatoriamente possuir a seguinte informação: descrição; RN 03.07: O cadastro da Reunião de Diária deverá obrigatoriamente possuir as seguintes informações: data da reunião, o trabalho realizado, as dificuldades e o que ainda deve ser feito; RN 03.08: O cadastro da Reunião de Revisão deverá obrigatoriamente possuir a seguinte informação: descrição; RN 03.09: O cadastro da Reunião de Retrospectiva deverá obrigatoriamente possuir a seguinte informação: descrição; e RN 03.10: O gráfico Sprint Burndown deverá ter como base as seguintes escalas: no eixo Y, o total de horas estimadas para as tarefas da Sprint, e no eixo X, o intervalo em dias entre o início e fim da Sprint. Pacote 4 Tarefa RN 04.01: Uma tarefa deverá obrigatoriamente possuir as seguintes informações: nome, descrição e estimativa; 49

63 RN 04.02: Uma tarefa finalizada não pode ser alterada, excluída ou cancelada; RN 04.03: Uma tarefa iniciada não pode ser excluída; RN 04.04: Uma tarefa pode assumir os seguintes estados: A Fazer, Em Desenvolvimento, Impedida, Cancelada e Finalizada; RN 04.05: Uma tarefa iniciada pode ser alterada somente pelo usuário que está a desenvolvendo; RN 04.06: Somente tarefas com status A Fazer podem ser alocadas; RN 04.07: Não pode ser cadastrado impedimento para uma tarefa A Fazer, Concluída ou Cancelada; RN 04.08: Somente poderá ser informado o número de horas trabalhadas em uma tarefa com status Em Desenvolvimento ou Finalizada; e RN 04.09: O Task Board deverá possuir as seguintes colunas: Story (Estória), To Do (A Fazer), In Development (Em Desenvolvimento), Impeded (Impedida) e Done (Finalizada). Pacote 5 Planning Poker RN 05.01: O baralho de cartas utilizado no Planning Poker é baseado na Sequencia de Fibonacci, sendo considerados os valores 0, 1, 2, 3, 5, 8, 13, 20, 40 e 100; RN 05.02: Os usuários não poderão estimar estórias quando a sessão estiver finalizada; RN 05.03: A data de término da sessão deve ser maior que a data de início; RN 05.04: O usuário poderá estimar cada estória apenas uma vez; RN 05.05: O Scrum Master poderá definir a estimativa final da estória apenas uma vez; RN 05.06: Somente estórias não estimadas poderão ser adicionadas à sessão; e RN 05.07: Uma sessão do Planning Poker deverá obrigatoriamente possuir as seguintes informações: data de início e data de finalização. 50

64 3.2 Casos de Uso O diagrama de casos de uso é uma representação das funcionalidades que cada usuário do sistema, denominado ator, poderá executar. De acordo com Sommerville (2008), um caso de uso identifica o tipo da interação e os agentes envolvidos. Nos casos de uso descritos neste trabalho, são apresentados três atores representando os papéis definidos pela metodologia Scrum, sendo eles especializações do ator Usuário, como pode ser visualizado na Figura 24. uc Tipos de Usuários Usuário Scrum Master Product Owner Scrum Team Figura 24. Atores do sistema. Os diagramas de casos de usos foram agrupados em módulos, para melhor entendimento dos mesmos. Além disso, decidiu-se apresentar os cenários dos casos de uso no apêndice A deste documento, para uma melhor organização. 51

65 3.2.1 Módulo Acesso Este módulo representa as interações realizadas pelos usuários para acesso ao sistema, através de login e senha previamente cadastrada. Esta interação pode ser visualizada através da Figura 25. uc Pacote 1 - Acesso Usuário UC Acessar o Sistema Figura 25. Diagrama de Casos de Uso do Módulo Acesso 52

66 3.2.2 Módulo Cadastros Básicos Este módulo representa as interações realizadas pelo Scrum Master para gerenciar o cadastro de usuário e times. O ator poderá cadastrar, alterar e excluir usuários, podendo associá-los ao time do projeto, formando o Scrum Team. Este módulo também representa as interações de gerenciamento do cadastro de projetos. Qualquer usuário poderá cadastrar um novo projeto, definindo nome, descrição, data de início e término, além de definir um Scrum Master e um Product Owner. Depois de cadastrado, um projeto somente poderá ser alterado ou inativado pelo Scrum Master. Pode-se visualizar todas estas interações na Figura 26. uc Pacote 2 - Cadastros Básicos UC Manter Usuário Scrum Master UC Manter Time Usuário UC Manter Projeto Figura 26. Diagrama de Casos de Uso do Módulo Cadastros Básicos. 53

67 3.2.3 Módulo Product Backlog Este módulo representa as interações realizadas pelos usuários do sistema referente às ações permitidas para o Product Backlog. Este conjunto de interações representa as operações realizadas pelo Scrum Master e Product Owner de cadastrar, alterar e excluir estórias no Product Backlog. Além disso, apresenta a interação realizada pelo Product Owner, o qual deverá definir a prioridade de cada item cadastrado no Product Backlog. O Scrum Master poderá também alterar a complexidade de cada estória, que poderá ser realizada através do Planning Poker, apresentado em um diagrama de casos de uso exclusivo, detalhado mais adiante. Por fim, este módulo também apresenta a ação de visualização do Product Burndown. Todas estas interações são apresentadas na Figura 27. uc Pacote 3 - Product Backlog UC Manter Product Backlog Product Owner Scrum Master Figura 27. Diagrama de Casos de Uso do Módulo Product Backlog. 54

68 3.2.4 Módulo Sprint Este módulo representa as interações realizadas no sistema no que se refere às Sprints. Neste módulo o ator Usuário representa todos os papéis disponíveis no sistema de forma que os casos de uso a ele conectados representam ações disponíveis a todos. Os casos de uso apresentados neste módulo ilustram as ações de cadastro, alteração e exclusão de Sprints, além das ações de inclusão de informações para as reuniões descritas pela metodologia Scrum. Os casos de uso disponíveis neste módulo são apresentados na Figura 28. uc Pacote 4 - Sprint UC Manter Sprint UC Manter Reunião de Planejamento Scrum Master UC Manter Reunião Diária UC Manter Reunião de Rev isão Scrum Team UC Visualizar Sprint Burndown UC Manter Reunião de Retrospectiv a Usuário Figura 28. Diagrama de Casos de Uso do Módulo Sprint. 55

69 3.2.5 Módulo Tarefa Este módulo representa as interações realizadas no cadastro de tarefas para os itens do Product Backlog associados a uma Sprint. Todas as ações ilustradas nos casos de uso deste módulo são executadas apenas pelo Scrum Team. Dentre estas ações, pode-se citar o cadastro, alteração e exclusão de tarefas, a alocação destas tarefas para um determinado integrante da equipe, informar o número de horas trabalhadas, informar o status de andamento da tarefa, como mostra o Diagrama de Estados da Figura 29, e informar um impedimento para uma determinada tarefa. Início Criação da tarefa A fazer Alocação da tarefa em andamento Cadastro de impedimento Finalização da tarefa Cancelamento da tarefa Liberação da tarefa Impedida Concluida [Cancelamento da tarefa] Cancelada Final Figura 29. Diagrama de Estados do Módulo Tarefa. Na Figura 30, podem-se visualizar os casos de uso que representam estas interações. Os casos de uso UC e UC podem ser executadas de forma gráfica, através do Task Board. 56

70 uc Pacote 4 - Tarefa UC Alocar Tarefas UC Gerenciar Horas Trabalhadas UC Manter Tarefas UC Informar Status da Tarefa Scrum Team UC Cadastrar Impedimentos Figura 30. Diagrama de Casos de Uso do Módulo Tarefa Módulo Planning Poker Este módulo representa as interações realizadas durante a execução do jogo Planning Poker. Neste módulo, as ações representadas pelos casos de uso incluem a criação de uma sessão pelo Scrum Master, e escolha dos itens do Product Backlog que serão analisados pela equipe. Estas interações podem ser visualizadas no Diagrama de Atividades da Figura 31. No diagrama, pode-se visualizar claramente as ações iniciais realizadas pelo Scrum Master de cadastro e seleção das Stories que irão compor a sessão. Após o inicio do jogo, os integrantes do Scrum Team deverão realizar suas estimativas e, depois de realizada esta etapa, o Scrum Master pode definir um valor para a estimativa. Finalizada a escolha de uma estimativa, a sessão se encerra. 57

71 act Jogo Scrum Master Team Inicio Cria sessão Escolhe os itens do backlog Inicia jogo Acessa sessão do Poker Avalia estimativas Realiza a estimativa Define estimativa Fim sessão Figura 31. Diagrama de Atividades do Planning Poker. 58

72 Todas as interações descritas neste tópico também estão apresentadas no diagrama de casos de uso da Figura 32. Estes casos de uso também apresentam a interação do Scrum Master e Scrum Team, em que cada um deve informar a complexidade para cada estória do Product Backlog. Por fim, representam ainda a ação do Scrum Master informar a complexidade final de acordo com os valores informados pelos participantes. uc Pacote 5 - Planning Poker UC Gerenciar a Sessão UC Definir a Complexidade Scrum Master UC Estimar Itens de uma Sessão Scrum Team Figura 32. Diagrama de Casos de Uso do Módulo Planning Poker Módulo Task Board As interações apresentadas nos casos de uso deste módulo são também realizadas através do Módulo Tarefa, detalhado na Seção Contudo, neste módulo, as ações são realizadas através de uma interface gráfica mais dinâmica, simulando o quadro de tarefas utilizado na metodologia Scrum. Como pode ser visualizado nos casos de uso da Figura 33, entre as interações apresentadas estão a edição de tarefas, alocação das mesmas e alteração de status. 59

73 uc Pacote 7 - Task Board UC Alocar Tarefa Scrum Team UC Alterar Status Figura 33. Diagrama de Casos de Uso do Módulo Task Board. 3.3 Diagrama de Entidade Relacionamento O Diagrama de Entidade Relacionamento apresenta o relacionamento entre as tabelas do banco de dados. Para este projeto, diversas alterações foram feitas sobre o diagrama original definido por Kluge (2009), além da criação de novas tabelas para os módulos propostos neste trabalho. Para a criação deste diagrama, utilizou-se o software da Sun Microsystems, MySQL Workbench, que possibilita criar graficamente as tabelas de banco de dados e os relacionamentos entre as mesmas. O diagrama adaptado para este trabalho é apresentado na Figura 34. Uma das modificações realizadas neste trabalho está na alteração dos nomes das tabelas e campos conforme padronização de alguns frameworks de desenvolvimento PHP. Os nomes das tabelas são apresentados no plural e os nomes dos campos são formados pelo nome da tabela no singular seguidos pelo nome do campo. Esta alteração busca padronizar as nomenclaturas utilizadas no sistema de forma que outros desenvolvedores não tenham dificuldade em realizar modificações e melhorias no Scrum Project. 60

74 Scrum Master Product Owner Figura 34. Diagrama de Entidade Relacionamento. A tabela projects armazena as informações de cada projeto do sistema como, por exemplo, a data de início e data de término. Esta tabela tem dois relacionamentos com a tabela users para representar que um projeto deve possuir um Product Owner e um Scrum Master obrigatoriamente. 61

75 Cada projeto pode possuir vários usuários, armazenados na tabela users, utilizando-se de uma tabela intermediária teams, visto que o mesmo usuário pode participar de vários projetos diferentes. A tabela pokers armazena cada sessão criada para o Planning Poker, sendo que cada projeto pode ter várias sessões, mas cada sessão pode pertencer a apenas um projeto. A tabela poker_items relaciona uma sessão do Planning Poker com diversos itens do Product Backlog. Por fim, a tabela estimates armazena a complexidade definida por cada usuário e para cada item selecionado para a sessão. Cada tarefa criada para um item do Product Backlog é armazenada na tabela tasks de forma que uma tarefa pode pertencer a apenas um item, mas um item pode possuir uma ou mais tarefas. As tarefas podem possuir impedimentos, os quais são armazenados na tabela impediments. A tabela sprints armazena todas as iterações do projeto, sendo que cada sprint pode possuir informações de diversas reuniões, armazenadas nas seguintes tabelas: dailies, retrospectives, plannings e reviews. E por fim, uma sprint pode possuir diversos itens do Product Backlog, formando o Sprint Backlog. 62

76 4 DESENVOLVIMENTO Este capítulo descreve o desenvolvimento da ferramenta Scrum Project e o framework utilizado. Cada seção deste capítulo irá apresentar um módulo do sistema, detalhando suas funcionalidades através de texto e imagens. Como o objetivo deste TCC foi desenvolver um software open source, sua implementação necessitou também de ferramentas gratuitas e/ou open source, de forma que este trabalho pudesse estar acessível para futuros estudos e pesquisas. Portanto, buscou-se utilizar um framework para desenvolvimento web, gratuito, com suporte a MVC (Modelo, Visão e Controle) além de possibilitar a utilização de Internacionalização. Por estes motivos, decidiu-se utilizar o framework CakePHP, o qual é apresentado na Seção 4.1. O banco de dados utilizado pelo Scrum Project é o MySQL na versão , mas nada impede que se utilize outro banco de dados. Ainda citando as tecnologias utilizadas, o Scrum Project utiliza o servidor web Apache, com suporte ao PHP. Além do CakePHP, tornou-se necessário utilizar outras tecnologias para atender aos requisitos deste trabalho. Para a criação dos gráficos Burndown, utilizou-se a biblioteca para PHP, pchart, a qual gera os gráficos em formato de imagem (PCHART, 2010). Para o desenvolvido dos módulos Task Board e Planning Poker, foram utilizados jquery e AJAX, sendo a primeira delas para as funções gráficas com Javascript (JQUERY, 2010), e a segunda para as requisições assíncronas em banco de dados. 4.1 Implementação O desenvolvimento do Scrum Project ocorreu principalmente através do framework CakePHP, um framework de desenvolvimento rápido, na linguagem PHP, com uma arquitetura extensível e de fácil manipulação. Utiliza design patterns como o MVC e possui uma estrutura padronizada e organizada que facilita o trabalho dos desenvolvedores e permite uma maior portabilidade do código-fonte (CAKEPHP, 2010). Além disso, é distribuído sob licença do MIT (Massachusetts Institute of Technology), que permite ao usuário do framework, ter o direito de uso, modificação, cópia e venda (OSI, 2010). 63

77 Dentre as facilidades que o CakePHP oferece, pode-se citar a geração do CRUD (Create, Retrieve, Update and Delete) diretamente da estrutura de banco de dados, dispensando o desenvolvedor do trabalho manual de criar as telas de cadastro do sistema. Além disso, possui diversas bibliotecas para auxiliar no desenvolvimento de Controle de Acesso, Internacionalização, requisições AJAX, Javascript, entre outras funcionalidades (CAKEPHP, 2010). Por estes motivos citados, o CakePHP é o framework utilizado no desenvolvimento da segunda versão do Scrum Project. Além do mais, possui desenvolvedores do mundo todo trabalhando com ele e que divulgam seu conhecimento através da internet, tornando-o bastante acessível, tanto para empresas quanto para estudantes. Inicialmente, realizou-se toda a revisão da modelagem do Scrum Project, dando ênfase na reestruturação do modelo Entidade-Relacionamento através da revisão das tabelas existentes e da inclusão de novas tabelas para suportar a inclusão dos três novos módulos deste trabalho. Além disso, a estrutura de banco de dados precisou ser revista para que toda a aplicação pudesse ser gerada automaticamente através do Bake, uma ferramenta disponibilizada em conjunto com o framework CakePHP. O console de Bake, no CakePHP, é uma ferramenta fornecida para auxiliar os desenvolvedores na geração da estrutura principal do programa que está sendo desenvolvido. Deste modo, o Bake pode criar toda a estrutura principal através do banco de dados, gerando os arquivos de modelo, visão e controle (CAKEPHP, 2010). Utilizou-se esta ferramenta no desenvolvimento da segunda versão do Scrum Project para poder criar toda a estrutura básica em pouco tempo de forma que a maior parte do tempo disponível neste trabalho pudesse ser utilizada para o desenvolvimento dos novos módulos do Scrum Project. O código-fonte gerado pelo Bake é bastante simplificado e, por esta razão, executa apenas as funções básicas. Esta é uma grande vantagem quando se trata de manutenção do código, visto que quaisquer alterações no Scrum Project podem ser feitas sem a utilização do Bake, sendo necessário apenas ter conhecimento na linguagem PHP. Diferente do ScriptCase, cuja proposta é a geração do software através da interface gráfica e que dificulta a alteração direta do código-fonte, o Bake é uma ferramenta que busca auxiliar os desenvolvedores na geração da estrutura básica do projeto, permitindo concentrar os esforços nos detalhes mais específicos do software desenvolvido. 64

78 Finalizada a geração da estrutura MVC deste projeto, iniciou-se a personalização do códigofonte para atender aos requisitos e regras de negócio definidas neste trabalho. Criaram-se todas as operações básicas do Scrum como o cadastro de projetos, usuários, estórias, tarefas e reuniões. Individualmente, estes cadastros foram gerados pela ferramenta Bake, contudo a integração e adaptação dos mesmos precisaram ser realizadas manualmente. Algumas características muitos específicas como, por exemplo, a seleção de estórias para composição da Sprint, tiveram que ser desenvolvidas separadamente visto que o Bake não realizou esta tarefa. Após o desenvolvimento da estrutura básica do projeto, pode então ser iniciado o desenvolvimento do módulo Task Board. Para atender às necessidades deste trabalho, buscou-se utilizar uma ferramenta que possibilitasse o rápido desenvolvimento de uma interface interativa que possibilitasse ao usuário arrastar objetos através do mouse. Com este propósito, utilizou a jquery, uma biblioteca Javascript que simplifica o tratamento de eventos, animações, interatividade e facilita o uso de requisições AJAX (JQUERY, 2010). Como a estrutura de cadastro das tarefas estava finalizada, pôde-se integrar o código Javascript à estrutura MVC gerada pelo CakePHP. Na camada de visão, foram incluídas todas as rotinas de geração da interface visual do Task Board e o tratamento dos eventos de usuário ativados ao arrastar uma tarefa de uma coluna para outra, por exemplo. A interface é desenvolvida através de jquery que, em tempo de execução, gera todo o código HTML. Na Figura 35, pode-se visualizar o código Javascript utilizado na view do Task Board, sendo que as funções precedidas de $ pertencem à jquery. O conjunto de linhas de código apresentado na Figura 35 tem como objetivo chamar as rotinas Javascript que desenham o Task Board na tela. $(document).ready( function () { loadbacklogs($('#userid').text(), $('#sprintid').text()); } ); Figura 35. Código-fonte da view do Task Board. 65

79 Uma das funcionalidades mais importantes da jquery utilizado para o desenvolvimento do Task Board é o AJAX. A função loadbacklogs apresentada na Figura 36 executa uma sequência de funções Javascript que consultam informações no banco de dados através do AJAX para em sequencia distribuírem as tarefas na tela. A integração desta função com o CakePHP pode ser verificada no parâmetro url, que define à função ajax da jquery para realizar uma requisição ao banco de dados através da função getbacklogs que se encontra na camada de controle. function loadbacklogs(userid, sprintid){ var values = "sprintid="+sprintid; $.ajax({ type: "post", data: values, url: "/scrumproject/backlogs/getbacklogs/", datatype: "json", success: function(response) { Figura 36. Trecho de código de uma requisição AJAX. Para integrar o Task Board ao banco de dados, foram utilizados os arquivos de modelo e controle gerados para o cadastro de tarefas. Deste modo, ao ativar um determinado evento Javascript na camada de visão, a informação é enviada às rotinas da camada de controle que, consequentemente, encaminha os dados ao banco de dados e devolve o resultado novamente à camada de visão. Todas estas requisições são realizadas através de AJAX, que permite consultar e atualizar informações do banco de dados sem que o usuário do sistema possa perceber. Isto ocorre porque o AJAX trabalha com requisições assíncronas, diferentemente do PHP. O desenvolvimento do módulo Planning Poker ocorreu de forma bastante semelhante, utilizando funções da biblioteca jquery para desenhar a interface e comunicar com o banco de dados através de AJAX integrado com as funções da camada de controle. Na Figura 37, pode-se visualizar um trecho de código jquery que é executado no momento em que o usuário seleciona uma determinada carta para definir sua estimativa. Neste momento a função jquery envia à função saveestimate o valor escolhido pelo usuário, o qual é então gravado no banco de dados. 66

80 $.ajax({ url : "/scrumproject/poker_items/saveestimate", type: "POST", data: values, success: function(msg){ }}); if (msg == 'error') { showmessage('you can no longer choose an estimate.', 'error'); }else{ showmessage('estimate successfully registered.','msg'); $(obj).addclass('poker_card_selected'); } Figura 37. Trecho de código executado no Planning Poker. O trecho de código apresentado na Figura 38 está localizado na camada de controle e é responsável por receber a estimativa do usuário e gravar no banco de dados. As funções utilizadas são disponibilizadas pelo CakePHP e permitem que a informação seja gravada sem a utilização de comandos SQL pelo desenvolvedor, sendo necessário apenas criar o objeto Estimate e executar os comandos específicos do framework. $this->estimate->create(); ); $data = array( 'Estimate' => array( 'user_id' => $this->auth->user('id'),//$id, 'poker_item_id' => $_POST['poker_item_id'], 'created' => date("y-m-d H:i:s"), 'value' => $_POST['value'] ) $this->estimate->save($data); Figura 38. Trecho de código da camada de controle do Planning Poker. Por fim, no desenvolvimento do gráfico Burndown Chart houve a necessidade de integrar as funções do pchart com as rotinas do CakePHP. A biblioteca pchart fornece um conjunto de funções que permitem a criação de gráficos nos mais diversos estilos, sendo necessário apenas definir as características de formatação e os dados numéricos que permitirão a geração do gráfico. Para consultar as informações do banco de dados, utilizou-se a estrutura do CakePHP e estes dados 67

81 foram formatados para que pudessem gerar informações no formato visual. Na Figura 39, pode-se visualizar um trecho do código no qual são executas as funções fornecidas pela biblioteca pchart. Neste trecho, são definidas as características do gráfico, bem como a definição dos dados números que irão gerar o gráfico propriamente dito. E no final deste trecho de código, executa-se uma função que transforma o gráfico em uma imagem, a qual é enviada à camada de visão da aplicação. $DataSet = new pdata; $DataSet->AddPoint($taskCount, "Burndown"); $DataSet->AddSerie("Burndown"); $Chart = new pchart(840,460); $Chart->setFontProperties("Fonts/tahoma.ttf",8); $Chart->setGraphArea(45,30,800,400); $Chart->drawGraphArea(252,252,252); $Chart->drawScale($Base->GetData(), $Base->GetDataDescription(),SCALE_NORMAL,150,150,150,TRUE,45,2, FALSE); $Chart->drawGrid(2,TRUE,230,230,230,255); $Chart->drawLine(45,30,800,400,255,0,0); $Chart->drawLineGraph($DataSet->GetData(),$DataSet->GetDataDescription()); $Chart->drawPlotGraph($DataSet->GetData(), $DataSet->GetDataDescription(),3,2,255,255,255); $Chart->setFontProperties("Fonts/tahoma.ttf",10); $Chart->drawTitle(210,15, 'Sprint Burndown',50,50,50,585); $Chart->Stroke(); Figura 39. Trecho de código da geração do Burndown Chart. Inicialmente este trabalho havia proposto o uso de Internacionalização para permitir a disponibilização do aplicativo em inglês e português. Contudo, devido ao escopo extenso deste trabalho, não houve tempo para desenvolver esta funcionalidade. O CakePHP possui suporte à Internacionalização sendo necessário apenas definir marcadores no código para que o framework possa identificar o texto que deverá ser traduzido (CAKEPHP, 2010). Na Figura 40, pode-se verificar que é necessária apenas uma alteração simples para identificar uma determinada palavra ou texto da camada de visão. //código original <h2>stories</h2> //código preparado para a Internacionalização <h2><?php ('Stories')?></h2> Figura 40. Exemplo de formatação para a Internacionalização. 68

82 Após a marcação do texto, basta executar uma rotina fornecida pelo CakePHP que irá realizar a geração de arquivos com a extensão pot, os quais possuem as configurações de linguagem. Estes arquivos deverão ser alterados para extensão po, traduzidos e disponibilizados em um diretório específico do CakePHP (CAKEPHP, 2010). 4.2 Scrum Project O Scrum Project, como citado em capítulos anteriores, foi desenvolvido inicialmente por Kluge (2009), em seu Trabalho de Conclusão de Curso. O software apresentado neste trabalho, e que será detalhado mais adiante, é a segunda versão do Scrum Project, com seu código-fonte reescrito e possuindo três novos módulos: Planning Poker, Task Board e Burndown Chart. O desenvolvimento desta versão ocorreu de acordo com a modelagem iniciada na versão anterior e revisada neste trabalho. Os módulos cadastrais básicos que envolvem inclusão, alteração e exclusão, foram gerados a partir do modelo de banco de dados, que para isto, teve de ser remodelado e revisado em sua estrutura e nomenclatura de forma que o CakePHP pudesse gerar as classes corretamente. Nas seções seguintes, serão apresentadas as funcionalidades do Scrum Project, com ênfase principalmente nos módulos agregados nesta nova versão Acesso O Scrum Project possibilita o acesso a diferentes perfis de usuário, cada qual com funcionalidades definidas no sistema, as quais são detalhadas mais adiante. Inicialmente, há apenas um usuário padrão cadastrado no sistema, denominado usuário administrador. Este, deverá se encarregar de cadastrar os primeiros usuários do sistema, dentre eles, um Scrum Master e um Product Owner. Realizado o cadastro destes usuários, o Scrum Master poderá utilizar seu login e senha para acessar o sistema. Para simplificar a apresentação da ferramenta, este cadastro inicial dos primeiros usuários não será detalhado. Deste modo, parte-se do pressuposto que exista um Scrum Master e um Product Owner cadastrados no sistema. O Scrum Project por ser um aplicativo web, deverá ser acessado através de um navegador. A primeira tela exibida ao usuário apresenta uma mensagem de boas vindas e um texto explicativo 69

83 indicando que o usuário deverá clicar no menu Projects e, através de seu login e senha, acessar os projetos disponíveis, como mostra a Figura 41. Figura 41. Tela de boas vindas do Scrum Project. Ao acessar o módulo de projetos, será requisitado o usuário o login e senha de autenticação. Se ambas as informações estiverem corretas, será permitido o acesso do usuário, caso contrário uma mensagem informará que login e/ou senha estão incorretos. Para o usuário autenticado no sistema, o seu login ficará identificado no canto superior direito do sistema, acompanhado do link Logout que permite ao usuário desconectar-se do sistema Projetos Ao ser autenticado no sistema, o usuário poderá visualizar os projetos dos quais participa. Neste caso, como ainda não há nenhum projeto cadastrado, o usuário deverá realizar o cadastro de 70

84 um novo projeto. Para isto, irá preencher as informações solicitadas pelo aplicativo e, definindo nesta etapa qual será o Scrum Master e o Product Owner do mesmo, como ilustrado na Figura 42. Figura 42. Tela de cadastro do projeto. Após realizar o cadastro do projeto, o usuário será encaminhado novamente para a listagem de projetos. Como neste exemplo, o usuário autenticado definiu a si mesmo como Scrum Master, o projeto irá aparecer em sua listagem. A partir desta etapa, o Scrum Master poderá alterar, editar ou inativar projetos dos quais participa, como mostra a Figura 43. Nesta mesma listagem, qualquer usuário poderá selecionar um projeto de forma que o sistema habilite as demais funções disponíveis. Quando isto ocorrer, o nome do projeto será exibido ao lado do nome do sistema, na parte superior da tela. 71

85 Figura 43. Tela de listagem dos projetos Usuários O projeto, além do Scrum Master e Product Owner, deverá possuir usuários que irão compor o Scrum Team. Deste modo, após a criação de um projeto, deve ser realizado o cadastro dos usuários e alocação dos mesmos ao projeto. Se os usuários fizerem parte de outro projeto e, portanto, estão cadastrados no sistema, basta alocá-los ao projeto, sendo desnecessário cadastrá-los novamente. A responsabilidade de cadastrar e alocar usuários para o projeto é do Scrum Master, sendo que os outros usuários poderão somente visualizar informações de qualquer usuário e alterar seus próprios dados. Para cadastrar um usuário é necessário preencher alguns dados pessoais e definir login e senha, os quais poderão ser alterados posteriormente pelo próprio usuário. Finalizados os cadastros, o Scrum Master precisa apenas definir quais dos usuários cadastrados farão parte do projeto, como mostra a Figura

86 Figura 44. Tela do módulo de gerenciamento de usuários Product Backlog Na metodologia Scrum, todas as funcionalidades do sistema podem ser descritas de forma informal e bastante objetivas. Estas descrições compõem o Product Backlog e são chamadas de Stories (Estórias), porque podem ser descritas de forma de narrativa. É responsabilidade do Scrum Master e do Product Owner cadastrá-las para que em outra etapa estas estórias possam ser desmembradas em tarefas pelo Scrum Team. No Scrum Project o processo de cadastro das Stories é bastante simples é rápido. Ao acessar o menu Backlog são listadas todas as Stories previamente cadastradas, contudo, como neste exemplo o projeto está em sua fase inicial, ainda não há nenhuma Story cadastrada. Portanto, através do link New Story pode-se realizar o cadastro de uma nova estória, como ilustrado na Figura

87 Figura 45. Tela de cadastro das Stories. Para cadastrar uma Story, apenas uma informação é indispensável: sua descrição. Como dito anteriormente, cada Story deve possuir uma descrição sucinta e objetiva. Outra informação que pode ser definida nesta etapa é o Business Value (Valor de Negócio). O Business Value irá definir a prioridade de desenvolvimento entre as Stories que compõem o Product Backlog. Deste modo, estórias com maior prioridade deverão ser desenvolvidas primeiramente. Normalmente, esta prioridade se dá através da escolha de um valor em um intervalo pré-definido. Por exemplo, em um intervalo pré-definido de 0 a 100, as estórias com menor prioridade receberiam os valores mais próximos de zero, enquanto que as mais prioritárias receberiam os valores próximos de cem. Contudo, neste projeto decidiu-se realizar esta priorização de uma forma diferente, buscando tornar este procedimento mais ágil. Desta forma, o Business Value é definido através da escolha entre três opções pré-definidas: Low, Medium e High (Baixo, Médio e Alto). Por último, poderá ser definida a estimativa da tarefa (Effort, em inglês), normalmente calculada em horas. Contudo, este valor não precisa ser obrigatoriamente cadastrado nesta etapa, visto que estas estimativas podem ser definidas através do Planning Poker, recurso bastante 74

88 utilizado no Scrum e que será detalhado na seção Outro detalhe importante é que esta estimativa somente pode ser definida pelo Scrum Master Planning Poker O Planning Poker, como citado anteriormente, é um método bastante dinâmico utilizado na metodologia Scrum para estimar as estórias de um projeto. O Scrum Project permite que se utilize esta dinâmica através da internet, sem a necessidade de reunir fisicamente os envolvidos. Inicialmente, o Scrum Master deverá cadastrar uma sessão do jogo. Para isto, deverá informar apenas a data de início e término desta sessão. Isto permite que o jogo possa ocorrer com um prazo maior, de forma que os integrantes da equipe possam entrar na sessão a qualquer momento e realizar sua estimativa. Contudo, podem-se realizar as estimativas em tempo real, ou seja, com todos os envolvidos conectados na mesma sessão e realizando suas estimativas. Realizado o cadastro da sessão, o Scrum Master deverá incluir as estórias que irão fazer parte da sessão, como mostra a Figura 46. Se forem realizadas mais de uma sessão, podem-se escolher determinadas estórias e posteriormente criar sessões para as estórias restantes. Contudo, podem-se incluir todas as estórias em apenas uma sessão, para que possa ser realizado o jogo em tempo real. Neste exemplo, serão selecionadas todas as estórias para melhor exemplificar o processo. 75

89 Figura 46. Tela de seleção das estórias para o Planning Poker. Quando o Scrum Master finalizar a seleção das estórias, a sessão estará aberta para que todos os integrantes do Scrum Team possam acessá-la. Como ilustrado na Figura 47, o Planning Poker está divido em três seções de tela: quadro informativo, estórias que compõem a seção e um conjunto de cartas. A Seção 1 apresenta todas as interações em uma determinada estória. Por exemplo, quando um integrante da equipe escolher um valor para uma estória, será apresentada uma mensagem informando esta ação. Lembrando que apenas o Scrum Master consegue visualizar os valores estimados. A Seção 2 representa a listagem de todas as estórias que compõem determinada sessão. As informações mostradas no quadro anterior estão diretamente ligadas à estória selecionada. Deste modo, dependendo da estória selecionada, diferentes informações serão apresentadas no quadro superior, apresentando apenas suas respectivas interações. 76

90 Finalmente, a última seção desta tela apresenta um conjunto de cartas que podem ser selecionadas de acordo com o valor escolhido. Cada integrante poderá selecionar apenas uma carta por estória, exceto se a sessão for reiniciada. Os valores selecionados pelo Scrum Team permitirão ao Scrum Master selecionar um valor para a estimativa da estória Figura 47. Tela do Planning Poker. Quando todos tiverem escolhidos valores para a estória, como pode ser visualizado na Figura 48, o Scrum Master poderá decidir se os valores são suficientes ou é necessário realizar uma nova rodada. Se um determinado valor for escolhido, basta que o Scrum Master escolha a carta que corresponda ao valor em questão e, neste caso, a estimativa estará realizada. Para as outras estórias, basta repetir o processo, até que todas estejam estimadas. 77

91 Figura 48. Tela do Planning Poker com estimativas Sprint Como citado anteriormente, uma Sprint representa um ciclo, com prazo determinado, em que o Scrum Team deverá desenvolver as estórias selecionadas. A responsabilidade de cadastrar as Sprints é do Scrum Master, que deverá definir uma descrição básica e, principalmente, escolher as datas de início e término, como ilustrado na Figura 49. Normalmente, uma Sprint tem duração de duas a quatro semanas, mas isto pode variar de acordo com a metodologia adotada em cada empresa. 78

92 Figura 49. Tela de cadastro da Sprint. Realizado o cadastro da Sprint, o Scrum Master deverá adicionar as Stories que irão fazer parte da Sprint, lembrando que para isto deverá ser levado em conta a prioridade definida pelo Product Owner e pela estimativa realizada pela equipe Tasks Na metodologia Scrum, Tasks (tarefas) são divisões das Stories de forma que possa reduzir uma grande tarefa do projeto, em diversas tarefas menores para que estas possam ser distribuídas aos membros da equipe e desenvolvidas de forma gradual. A criação das tarefas e a alocação das mesmas entre os integrantes da equipe são responsabilidades do próprio Scrum Team. Nesta etapa, o Scrum Master e o Product Owner não interferem no andamento das tarefas, o Scrum Master acaba atuando apenas como um facilitador, procurando resolver os impedimentos da equipe. Para cadastrar uma tarefa, o usuário deverá informar a qual Story está vinculada e, em seguida preencher as informações necessárias, como mostra a Figura 50. As informações necessárias são o nome, uma descrição do que deverá ser realizado e uma previsão do tempo necessário, em horas, para o desenvolvimento da tarefa. Este processo deve ser realizado até que 79

93 todas as tarefas necessárias para a finalização de uma Story estejam cadastradas. Para o gerenciamento das tarefas será utilizado o Task Board, detalhado mais adiante. Figura 50. Tela de cadastro da tarefa Task Board O módulo Task Board permite que o Scrum Team possa gerenciar melhor as tarefas, através de uma ferramenta que simula um quadro físico na qual as tarefas podem ser arrastadas de uma coluna a outra. Para utilizar este módulo, as tarefas devem estar previamente cadastradas, de modo que, através do Task Board, elas possam ser alocadas para os membros da equipe. Como se pode ver na Figura 51, o Task Board possui cinco colunas, as quais serão detalhadas mais adiante. 80

94 Figura 51. Tela do Task Board. A coluna mais esquerda representa as estórias selecionadas para a Sprint. Deste modo, cada linha do quadro representa uma estória e, as células à direita apresentam suas respectivas tarefas. Na Figura 51, por exemplo, pode-se verificar que a primeira Story possui apenas uma tarefa cadastrada, a qual está disposta na coluna To Do e não está alocada a nenhum membro da equipe. As quatro colunas seguintes, representam os status que as tarefas podem assumir: To Do (A Fazer), In Development (Em Desenvolvimento), Impeded (Impedida) e Done (Finalizada). Logo após as tarefas serem cadastradas, elas assumem a posição da primeira coluna, ou seja, estão disponíveis para serem desenvolvidas e, portanto, ainda não estão alocadas a nenhum integrante do Scrum Team. Deste modo, basta arrastar uma destas tarefas para a coluna In Development que ela é 81

FireScrum: Ferramenta de apoio à gestão de projetos utilizando Scrum

FireScrum: Ferramenta de apoio à gestão de projetos utilizando Scrum C.E.S.A.R.EDU Unidade de Educação do Centro de Estudos e Sistemas Avançados do Recife Projeto de Dissertação de Mestrado FireScrum: Ferramenta de apoio à gestão de projetos utilizando Scrum Eric de Oliveira

Leia mais

Wesley Torres Galindo

Wesley Torres Galindo Qualidade, Processos e Gestão de Software Professores: Alexandre Vasconcelos e Hermano Moura Wesley Torres Galindo wesleygalindo@gmail.com User Story To Do Doing Done O que é? Como Surgiu? Estrutura Apresentar

Leia mais

Wesley Torres Galindo. wesleygalindo@gmail.com

Wesley Torres Galindo. wesleygalindo@gmail.com Wesley Torres Galindo wesleygalindo@gmail.com Wesley Galindo Graduação em Análise e Desenvolvimento de Sistemas Mestrado em Engenharia de Software Engenheiro de Software Professor Faculdade Escritor Osman

Leia mais

SCRUM. É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto.

SCRUM. É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto. SCRUM SCRUM É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto. Ken Schwaber e Jeff Sutherland Transparência A transparência garante que

Leia mais

Metodologias Ágeis. Aécio Costa

Metodologias Ágeis. Aécio Costa Metodologias Ágeis Aécio Costa Metodologias Ágeis Problema: Processo de desenvolvimento de Software Imprevisível e complicado. Empírico: Aceita imprevisibilidade, porém tem mecanismos de ação corretiva.

Leia mais

Uma introdução ao SCRUM. Evandro João Agnes evandroagnes@yahoo.com.br

Uma introdução ao SCRUM. Evandro João Agnes evandroagnes@yahoo.com.br Uma introdução ao SCRUM Evandro João Agnes evandroagnes@yahoo.com.br Agenda Projetos de Software O que é Scrum Scrum framework Estrutura do Scrum Sprints Ferramentas Projetos de software Chaos Report Standish

Leia mais

SCRUM. Fabrício Sousa fabbricio7@yahoo.com.br

SCRUM. Fabrício Sousa fabbricio7@yahoo.com.br SCRUM Fabrício Sousa fabbricio7@yahoo.com.br Introdução 2 2001 Encontro onde profissionais e acadêmicos da área de desenvolvimento de software de mostraram seu descontentamento com a maneira com que os

Leia mais

RESUMO PARA O EXAME PSM I

RESUMO PARA O EXAME PSM I RESUMO PARA O EXAME PSM I Escrito por: Larah Vidotti Blog técnico: Linkedin: http://br.linkedin.com/in/larahvidotti MSN: larah_bit@hotmail.com Referências:... 2 O Scrum... 2 Papéis... 3 Product Owner (PO)...

Leia mais

Manifesto Ágil - Princípios

Manifesto Ágil - Princípios Manifesto Ágil - Princípios Indivíduos e interações são mais importantes que processos e ferramentas. Software funcionando é mais importante do que documentação completa e detalhada. Colaboração com o

Leia mais

Quais são as características de um projeto?

Quais são as características de um projeto? Metodologias ágeis Flávio Steffens de Castro Projetos? Quais são as características de um projeto? Temporário (início e fim) Objetivo (produto, serviço e resultado) Único Recursos limitados Planejados,

Leia mais

Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática

Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática Disciplina: INF5008 Prof.: (monalessa@inf.ufes.br) Conteúdo 8. Metodologias

Leia mais

Objetivos do Módulo 3

Objetivos do Módulo 3 Objetivos do Módulo 3 Após completar este módulo você deverá ter absorvido o seguinte conhecimento: Conceitos do Scrum O que é um Sprint Decifrando um Product backlog Daily Scrum, Sprint Review, Retrospectiva

Leia mais

Por que o Scrum? o Foco na Gerência de Projetos; o Participação efetiva do Cliente.

Por que o Scrum? o Foco na Gerência de Projetos; o Participação efetiva do Cliente. Por que o Scrum? o Foco na Gerência de Projetos; o Participação efetiva do Cliente. Desenvolvido por Jeff SUTHERLAND e Ken SCHWABER ; Bastante objetivo, com papéis bem definidos; Curva de Aprendizado é

Leia mais

Manifesto Ágil e as Metodologias Ágeis (XP e SCRUM)

Manifesto Ágil e as Metodologias Ágeis (XP e SCRUM) Programação Extrema Manifesto Ágil e as Metodologias Ágeis (XP e SCRUM) Prof. Mauro Lopes Programação Extrema Prof. Mauro Lopes 1-31 45 Manifesto Ágil Formação da Aliança Ágil Manifesto Ágil: Propósito

Leia mais

METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO. Bruno Edgar Fuhr 1

METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO. Bruno Edgar Fuhr 1 METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO Bruno Edgar Fuhr 1 Resumo: O atual mercado de sistemas informatizados exige das empresas de desenvolvimento, um produto que tenha ao mesmo

Leia mais

SCRUM Gerência de Projetos Ágil. Prof. Elias Ferreira

SCRUM Gerência de Projetos Ágil. Prof. Elias Ferreira SCRUM Gerência de Projetos Ágil Prof. Elias Ferreira Métodos Ágeis + SCRUM + Introdução ao extreme Programming (XP) Manifesto Ágil Estamos descobrindo maneiras melhores de desenvolver software fazendo-o

Leia mais

Desenvolvimento Ágil de Software

Desenvolvimento Ágil de Software Desenvolvimento Ágil de Software Métodos ágeis (Sommerville) As empresas operam em um ambiente global, com mudanças rápidas. Softwares fazem parte de quase todas as operações de negócios. O desenvolvimento

Leia mais

Ferramenta para gestão ágil

Ferramenta para gestão ágil Ferramenta para gestão ágil de projetos de software Robson Ricardo Giacomozzi Orientador: Everaldo Artur Grahl Agenda Introdução Objetivos Fundamentação teórica Desenvolvimento Resultados e discussões

Leia mais

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com Processo de Desenvolvimento de Software Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo Programático desta aula Modelo Cascata (Waterfall) ou TOP DOWN. Modelo Iterativo. Metodologia Ágil.

Leia mais

Scrum. Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE

Scrum. Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE Scrum Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE scrum Ken Schwaber - Jeff Sutherland http://www.scrumalliance.org/ Scrum Uma forma ágil de gerenciar projetos. Uma abordagem baseada em equipes autoorganizadas.

Leia mais

Workshop SCRUM. Versão 5 Out 2010 RFS. rildo.santos@etecnologia.com.br

Workshop SCRUM. Versão 5 Out 2010 RFS. rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos 2006 e 2010 Objetivo: Estudo de Caso Objetivo: Apresentar um Estudo de Caso para demonstrar como aplicar as práticas do SCRUM em projeto de desenvolvimento de

Leia mais

Após completar este módulo você deverá ter absorvido o seguinte conhecimento: Uma ampla visão do framework Scrum e suas peculiaridades

Após completar este módulo você deverá ter absorvido o seguinte conhecimento: Uma ampla visão do framework Scrum e suas peculiaridades Objetivos da Aula 1 Após completar este módulo você deverá ter absorvido o seguinte conhecimento: Uma ampla visão do framework Scrum e suas peculiaridades Entendimento sobre os processos essenciais do

Leia mais

Análise da aplicação da metodologia SCRUM em uma empresa de Desenvolvimento de Software

Análise da aplicação da metodologia SCRUM em uma empresa de Desenvolvimento de Software Análise da aplicação da metodologia SCRUM em uma empresa de Desenvolvimento de Software Carolina Luiza Chamas Faculdade de Tecnologia da Zona Leste SP Brasil carolchamas@hotmail.com Leandro Colevati dos

Leia mais

Sistemas de Informação e Programação II Odorico Machado Mendizabal

Sistemas de Informação e Programação II Odorico Machado Mendizabal Sistemas de Informação e Programação II Odorico Machado Mendizabal Universidade Federal do Rio Grande FURG C3 Engenharia de Computação 16 e 23 de março de 2011 Processo de Desenvolvimento de Software Objetivos

Leia mais

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas CMP1141 Processo e qualidade de software I Prof. Me. Elias Ferreira Sala: 210 F Quarta-Feira:

Leia mais

Scrum Guia Prático. Raphael Rayro Louback Saliba Certified Scrum Master. Os papéis, eventos, artefatos e as regras do Scrum. Solutions. www.domain.

Scrum Guia Prático. Raphael Rayro Louback Saliba Certified Scrum Master. Os papéis, eventos, artefatos e as regras do Scrum. Solutions. www.domain. Scrum Guia Prático Os papéis, eventos, artefatos e as regras do Scrum Solutions www.domain.com Raphael Rayro Louback Saliba Certified Scrum Master 1 Gráfico de Utilização de Funcionalidades Utilização

Leia mais

Guia Projectlab para Métodos Agéis

Guia Projectlab para Métodos Agéis Guia Projectlab para Métodos Agéis GUIA PROJECTLAB PARA MÉTODOS ÁGEIS 2 Índice Introdução O que são métodos ágeis Breve histórico sobre métodos ágeis 03 04 04 Tipos de projetos que se beneficiam com métodos

Leia mais

UNIVERSIDADE ESTADUAL DE CAMPINAS - UNICAMP FACULDADE DE TECNOLOGIA - FT GUSTAVO ARCERITO MARIVALDO FELIPE DE MELO

UNIVERSIDADE ESTADUAL DE CAMPINAS - UNICAMP FACULDADE DE TECNOLOGIA - FT GUSTAVO ARCERITO MARIVALDO FELIPE DE MELO UNIVERSIDADE ESTADUAL DE CAMPINAS - UNICAMP FACULDADE DE TECNOLOGIA - FT GUSTAVO ARCERITO MARIVALDO FELIPE DE MELO Análise da Metodologia Ágil SCRUM no desenvolvimento de software para o agronegócio Limeira

Leia mais

Aluna: Vanessa de Mello Orientador: Everaldo Artur Grahl

Aluna: Vanessa de Mello Orientador: Everaldo Artur Grahl Ferramenta web para gerenciamento de projetos de software baseado no Scrum Aluna: Vanessa de Mello Orientador: Everaldo Artur Grahl Introdução Roteiro da apresentação Objetivos do trabalho Fundamentação

Leia mais

SCRUM: UMA DAS METODOLOGIAS ÁGEIS MAIS USADAS DO MUNDO

SCRUM: UMA DAS METODOLOGIAS ÁGEIS MAIS USADAS DO MUNDO SCRUM: UMA DAS METODOLOGIAS ÁGEIS MAIS USADAS DO MUNDO RESUMO Eleandro Lopes de Lima 1 Nielsen Alves dos Santos 2 Rodrigo Vitorino Moravia 3 Maria Renata Furtado 4 Ao propor uma alternativa para o gerenciamento

Leia mais

Géssica Talita. Márcia Verônica. Prof.: Edmilson

Géssica Talita. Márcia Verônica. Prof.: Edmilson Géssica Talita Márcia Verônica Prof.: Edmilson DESENVOLVIMENTO ÁGIL Técnicas foram criadas com o foco de terminar os projetos de software rapidamente e de forma eficaz. Este tipo de técnica foi categorizada

Leia mais

Alexandre Lima Guilherme Melo Joeldson Costa Marcelo Guedes

Alexandre Lima Guilherme Melo Joeldson Costa Marcelo Guedes Instituto Federal do Rio Grande do Norte IFRN Graduação Tecnologia em Analise e Desenvolvimento de Sistema Disciplina: Processo de Desenvolvimento de Software Scrum Alexandre Lima Guilherme Melo Joeldson

Leia mais

Ferramenta para Gerenciamento de Requisitos em Metodologias Ágeis

Ferramenta para Gerenciamento de Requisitos em Metodologias Ágeis Ferramenta para Gerenciamento de Requisitos em Metodologias Ágeis Eduardo dos Santos Gonçalves 1, Heitor Boeira dos Reis Filho 1 1 Universidade Luterana do Brasil (ULBRA) Av. Itacolomi, 3.600 Bairro São

Leia mais

SCRUM como metodologia de gestão de projetos da área administrativa Venturus: um case de sucesso RESUMO

SCRUM como metodologia de gestão de projetos da área administrativa Venturus: um case de sucesso RESUMO SCRUM como metodologia de gestão de projetos da área administrativa Venturus: um case de sucesso RESUMO Este artigo tem por objetivo apresentar a experiência do uso da metodologia Scrum para o gerenciamento

Leia mais

Análise comparativa entre a engenharia de requisitos e o método de desenvolvimento ágil: Scrum

Análise comparativa entre a engenharia de requisitos e o método de desenvolvimento ágil: Scrum Análise comparativa entre a engenharia de requisitos e o método de desenvolvimento ágil: Scrum Patrícia Bastos Girardi, Sulimar Prado, Andreia Sampaio Resumo Este trabalho tem como objetivo prover uma

Leia mais

Gestão de Projetos com Métodos Ágeis - Avançado

Gestão de Projetos com Métodos Ágeis - Avançado Gestão de Projetos com Métodos Ágeis - Avançado Caxias do Sul, 16 de Agosto 2013 Gustavo Casarotto Agenda O Scrum Planejamento da Sprint 1 Execução da Sprint 1 Revisão da Sprint 1 Retrospectiva da Sprint

Leia mais

Engenharia de Software I. Aula 15: Metodologias Ágeis. Prof. Márcio D. Puntel marcio@puntel.org

Engenharia de Software I. Aula 15: Metodologias Ágeis. Prof. Márcio D. Puntel marcio@puntel.org Engenharia de Software I Aula 15: Metodologias Ágeis Prof. Márcio D. Puntel marcio@puntel.org Março - 2008 Antes... Manifesto Mudança de contratos Foco nas premissas... 2 Algumas metodologias Extreme Programming

Leia mais

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 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

Leia mais

Scrum. Gestão ágil de projetos

Scrum. Gestão ágil de projetos Scrum Gestão ágil de projetos Apresentação feita por : Igor Macaúbas e Marcos Pereira Modificada por: Francisco Alecrim (22/01/2012) Metas para o o Metas para treinamento seminário Explicar o que é Scrum

Leia mais

METODOLOGIAS ÁGEIS - SCRUM -

METODOLOGIAS ÁGEIS - SCRUM - METODOLOGIAS ÁGEIS - SCRUM - André Roberto Ortoncelli ar_ortoncelli@hotmail.com 2010 Organização da Apresentação Introdução as Metodologias Ágeis Scrum Conceitos Básicos Artefatos Papeis Cerimônias Estórias

Leia mais

Scrum-Half: Uma Ferramenta Web de Apoio ao Scrum

Scrum-Half: Uma Ferramenta Web de Apoio ao Scrum Scrum-Half: Uma Ferramenta Web de Apoio ao Scrum Diego R. Marins 1,2, José A. Rodrigues Nt. 1, Geraldo B. Xexéo 2, Jano M. de Sousa 1 1 Programa de Engenharia de Sistemas e Computação - COPPE/UFRJ 2 Departamento

Leia mais

SCRUM. Otimizando projetos. Adilson Taub Júnior tecproit.com.br

SCRUM. Otimizando projetos. Adilson Taub Júnior tecproit.com.br SCRUM Otimizando projetos Adilson Taub Júnior tecproit.com.br Sobre mim Adilson Taub Júnior Gerente de Processos Certified ScrumMaster; ITIL Certified; Cobit Certified; 8+ anos experiência com TI Especialista

Leia mais

Agilidade parte 3/3 - Scrum. Prof. Dr. Luís Fernando Fortes Garcia luis@garcia.pro.br

Agilidade parte 3/3 - Scrum. Prof. Dr. Luís Fernando Fortes Garcia luis@garcia.pro.br Agilidade parte 3/3 - Scrum Prof. Dr. Luís Fernando Fortes Garcia luis@garcia.pro.br 1 Scrum Scrum? Jogada do Rugby Formação de muralha com 8 jogadores Trabalho em EQUIPE 2 Scrum 3 Scrum Scrum Processo

Leia mais

Ágil. Rápido. Métodos Ágeis em Engenharia de Software. Introdução. Thiago do Nascimento Ferreira. Introdução. Introdução. Introdução.

Ágil. Rápido. Métodos Ágeis em Engenharia de Software. Introdução. Thiago do Nascimento Ferreira. Introdução. Introdução. Introdução. Introdução Métodos Ágeis em Engenharia de Software Thiago do Nascimento Ferreira Desenvolvimento de software é imprevisível e complicado; Empresas operam em ambiente global com mudanças rápidas; Reconhecer

Leia mais

Módulo de projetos ágeis Scrum Módulo de Projetos Ágeis Scrum

Módulo de projetos ágeis Scrum Módulo de Projetos Ágeis Scrum Módulo de Projetos Ágeis Fevereiro 2015 Versão Módulo de Projetos Ágeis O nome vem de uma jogada ou formação do Rugby, onde 8 jogadores de cada time devem se encaixar para formar uma muralha. É muito importante

Leia mais

Engenharia de Software

Engenharia de Software Faculdade de Informática e Administração Paulista Curso de Sistemas de Informação 2º SI-T Engenharia de Software Modelo de Desenvolvimento Ágil SCRUM Hugo Cisneiros RM 60900 Moyses Santana Jacob RM 63484

Leia mais

Fundamentos do Scrum aplicados ao RTC Sergio Martins Fernandes

Fundamentos do Scrum aplicados ao RTC Sergio Martins Fernandes Workshop Scrum & Rational Team Concert (RTC) Sergio Martins Fernandes Agilidade Slide 2 Habilidade de criar e responder a mudanças, buscando agregar valor em um ambiente de negócio turbulento O Manifesto

Leia mais

Metodologia de Trabalho

Metodologia de Trabalho FUNDAMENTOS EM ENGENHARIA DE SOFTWARE Projeto Prático de Desenvolvimento de Software Metodologia de Trabalho Teresa Maciel UFRPE/DEINFO FASES DO PROJETO PLANEJAMENTO DESENVOLVIMENTO CONCLUSÃO ATIVIDADES

Leia mais

[Agile] Scrum + XP. Wagner Roberto dos Santos. Agilidade extrema. Arquiteto Java EE / Scrum Master wrsconsulting@gmail.com. Globalcode open4education

[Agile] Scrum + XP. Wagner Roberto dos Santos. Agilidade extrema. Arquiteto Java EE / Scrum Master wrsconsulting@gmail.com. Globalcode open4education [Agile] Scrum + XP Agilidade extrema Wagner Roberto dos Santos Arquiteto Java EE / Scrum Master wrsconsulting@gmail.com 1 Apresentação Arquiteto Java EE / Scrum Master Lead Editor da Queue Arquitetura

Leia mais

Engenharia de Software II: SCRUM na prática. Ricardo de Sousa Britto rbritto@ufpi.edu.br

Engenharia de Software II: SCRUM na prática. Ricardo de Sousa Britto rbritto@ufpi.edu.br Engenharia de Software II: SCRUM na prática Ricardo de Sousa Britto rbritto@ufpi.edu.br Construindo Product Backlog } O product backlog é o coração do Scrum. } É basicamente uma lista de requisitos, estórias,

Leia mais

Gerenciamento de Equipes com Scrum

Gerenciamento de Equipes com Scrum Gerenciamento de Equipes com Scrum Curso de Verão 2009 IME/USP www.agilcoop.org.br Dairton Bassi 28/Jan/2009 O que é Scrum? Processo de controle e gerenciamento Processo iterativo de inspeção e adaptação

Leia mais

Workshop. Workshop SCRUM. Rildo F Santos. rildo.santos@etecnologia.com.br. Versão 1 Ago 2010 RFS. www.etcnologia.com.br (11) 9123-5358 (11) 9962-4260

Workshop. Workshop SCRUM. Rildo F Santos. rildo.santos@etecnologia.com.br. Versão 1 Ago 2010 RFS. www.etcnologia.com.br (11) 9123-5358 (11) 9962-4260 Workshop www.etcnologia.com.br (11) 9123-5358 (11) 9962-4260 Rildo F Santos twitter: @rildosan skype: rildo.f.santos http://rildosan.blogspot.com/ Todos os direitos reservados e protegidos 2006 e 2010

Leia mais

Desenvolvimento Ágil sob a Perspectiva de um ScrumMaster

Desenvolvimento Ágil sob a Perspectiva de um ScrumMaster Desenvolvimento Ágil sob a Perspectiva de um ScrumMaster Danilo Sato e Dairton Bassi 21-05-07 IME-USP O que é Scrum? Processo empírico de controle e gerenciamento Processo iterativo de inspeção e adaptação

Leia mais

LISTA DE EXERCÍCIOS METODOLOGIAS ÁGEIS ENGENHARIA DE SOFTWARE 10/08/2013

LISTA DE EXERCÍCIOS METODOLOGIAS ÁGEIS ENGENHARIA DE SOFTWARE 10/08/2013 LISTA DE EXERCÍCIOS METODOLOGIAS ÁGEIS ENGENHARIA DE SOFTWARE 10/08/2013 Disciplina: Professor: Engenharia de Software Edison Andrade Martins Morais http://www.edison.eti.br prof@edison.eti.br Área: Metodologias

Leia mais

Processo de Desenvolvimento de Software Scrum. Prof. Antonio Almeida de Barros Jr.

Processo de Desenvolvimento de Software Scrum. Prof. Antonio Almeida de Barros Jr. Processo de Desenvolvimento de Software Scrum Manifesto da Agilidade Quatro princípios Indivíduos e interações mais que processos e ferramentas Software funcionando mais que documentação compreensiva Colaboração

Leia mais

MODELO DE DESENVOLVIMENTO ÁGIL SCRUM

MODELO DE DESENVOLVIMENTO ÁGIL SCRUM MODELO DE DESENVOLVIMENTO ÁGIL SCRUM CEETEPS CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA PAULA SOUZA FATEC DE TAUBATÉ HABILITAÇÃO: ANÁLISE E DESENVOLVIMENTO DE SISTEMAS TEMA MODELO DE DESENVOLVIMENTO ÁGIL:

Leia mais

Scrum e CMMI no C.E.S.A.R Relato de Experiência

Scrum e CMMI no C.E.S.A.R Relato de Experiência Scrum e CMMI no C.E.S.A.R Relato de Experiência Felipe Furtado Engenheiro de Qualidade Izabella Lyra Gerente de Projetos Maio/2008 Agenda Motivação Pesquisas Adaptações do Processo Projeto Piloto Considerações

Leia mais

UNIVERSIDADE FEDERAL DE PERNAMBUCO. Ferramenta para apoio à estimativa baseada em Planning Poker utilizando a metodologia Scrum

UNIVERSIDADE FEDERAL DE PERNAMBUCO. Ferramenta para apoio à estimativa baseada em Planning Poker utilizando a metodologia Scrum UNIVERSIDADE FEDERAL DE PERNAMBUCO GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO CENTRO DE INFORMÁTICA 2012.1 Ferramenta para apoio à estimativa baseada em Planning Poker utilizando a metodologia Scrum TRABALHO DE

Leia mais

Agradecimento. Adaptação do curso Scrum de Márcio Sete, ChallengeIT. Adaptação do curso The Zen of Scrum de Alexandre Magno, AdaptaWorks

Agradecimento. Adaptação do curso Scrum de Márcio Sete, ChallengeIT. Adaptação do curso The Zen of Scrum de Alexandre Magno, AdaptaWorks S C R U M Apresentação Tiago Domenici Griffo Arquiteto de Software na MCP, MCAD, MCSD, MCTS Web, Windows e TFS, ITIL Foundation Certified, MPS.BR P1 Experiência internacional e de offshoring Agradecimento

Leia mais

SCRUM: UM MÉTODO ÁGIL. Cleviton Monteiro (cleviton@gmail.com)

SCRUM: UM MÉTODO ÁGIL. Cleviton Monteiro (cleviton@gmail.com) SCRUM: UM MÉTODO ÁGIL Cleviton Monteiro (cleviton@gmail.com) Roteiro Motivação Manifesto Ágil Princípios Ciclo Papeis, cerimônias, eventos, artefatos Comunicação Product Backlog Desperdício 64% das features

Leia mais

Praticando o Scrum. Prof. Wylliams Barbosa Santos wylliamss@gmail.com Optativa IV Projetos de Sistemas Web

Praticando o Scrum. Prof. Wylliams Barbosa Santos wylliamss@gmail.com Optativa IV Projetos de Sistemas Web Praticando o Scrum Prof. Wylliams Barbosa Santos wylliamss@gmail.com Optativa IV Projetos de Sistemas Web Créditos de Conteúdo: Left (left@cesar.org.br) Certified Scrum Master Preparação Agrupar os membros

Leia mais

EXIN Agile Scrum Fundamentos

EXIN Agile Scrum Fundamentos Exame Simulado EXIN Agile Scrum Fundamentos Edição Fevereiro 2015 Copyright 2015 EXIN Todos os direitos reservados. Nenhuma parte desta publicação pode ser publicado, reproduzido, copiado ou armazenada

Leia mais

Comparativo entre Processos Ágeis. Daniel Ferreira dfs3@cin.ufpe.br

Comparativo entre Processos Ágeis. Daniel Ferreira dfs3@cin.ufpe.br Comparativo entre Processos Ágeis Daniel Ferreira dfs3@cin.ufpe.br O que discutiremos: Histórico Os Princípios Ágeis Comparação Do ponto de vista incremental Do ponto de vista funcional Vantagens e Desvantagens

Leia mais

UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU INSTITUTO A VEZ DO MESTRE

UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU INSTITUTO A VEZ DO MESTRE UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU INSTITUTO A VEZ DO MESTRE BOAS PRÁTICAS DO PMI COM OS MÉTODOS ÁGEIS Por: Sheyla Christina Bueno Ortiz Orientador Prof. Nelsom Magalhães Rio de Janeiro

Leia mais

Entendendo Scrum para Gerenciar Projetos de Forma Ágil Paulo Pereira 1 ; Paula Torreão 2, Ana Sofia Marçal 3

Entendendo Scrum para Gerenciar Projetos de Forma Ágil Paulo Pereira 1 ; Paula Torreão 2, Ana Sofia Marçal 3 Entendendo crum para Gerenciar Projetos de Forma Ágil Paulo Pereira 1 ; Paula Torreão 2, Ana ofia Marçal 3 1 Paulo Pereira 2 Paula Torreão 3 Ana ofia Marcal C.E..A.R Gerente de Projetos 1 paulo.pereira@c.e..a.r..org.br

Leia mais

Implementando maturidade e agilidade em uma fábrica de software através de Scrum e MPS.BR nível G

Implementando maturidade e agilidade em uma fábrica de software através de Scrum e MPS.BR nível G Implementando maturidade e agilidade em uma fábrica de software através de Scrum e MPS.BR nível G Fernando Szimanski 1, Jones Albuquerque 2, Felipe Furtado 2 1 CRIATIVA tecnologia - 77.410-020 - Gurupi

Leia mais

MODELO DE PROCESSO PARA MICRO E PEQUENAS EMPRESAS DE SOFTWARE COM BASE EM METODOLOGIAS ÁGEIS

MODELO DE PROCESSO PARA MICRO E PEQUENAS EMPRESAS DE SOFTWARE COM BASE EM METODOLOGIAS ÁGEIS MODELO DE PROCESSO PARA MICRO E PEQUENAS EMPRESAS DE SOFTWARE COM BASE EM METODOLOGIAS ÁGEIS MIRILIAN CARLA ARAUJO CORILLO 1, ANDREA PADOVAN JUBILEU 2. 1 Tecnóloga em Análise e Desenvolvimento de Sistemas

Leia mais

Estudo sobre Desenvolvimento de Software Utilizando o Framework Ágil Scrum

Estudo sobre Desenvolvimento de Software Utilizando o Framework Ágil Scrum Estudo sobre Desenvolvimento de Software Utilizando o Framework Ágil Scrum Andre Scarmagnani 1, Fabricio C. Mota 1, Isaac da Silva 1, Matheus de C. Madalozzo 1, Regis S. Onishi 1, Luciano S. Cardoso 1

Leia mais

Metodologia SCRUM. Moyses Santana Jacob RM 63484. Stelvio Mazza RM 63117. Tiago Pereira RM 63115. Hugo Cisneiros RM 60900

Metodologia SCRUM. Moyses Santana Jacob RM 63484. Stelvio Mazza RM 63117. Tiago Pereira RM 63115. Hugo Cisneiros RM 60900 Metodologia SCRUM Hugo Cisneiros RM 60900 Moyses Santana Jacob RM 63484 Stelvio Mazza RM 63117 Tiago Pereira RM 63115 SCRUM? O que é isso? SCRUM é um modelo de desenvolvimento ágil de software que fornece

Leia mais

ISSN 0103-9741. Monografias em Ciência da Computação n 07/09. Implantando o SCRUM em um Ambiente de Desenvolvimento de Produtos para Internet

ISSN 0103-9741. Monografias em Ciência da Computação n 07/09. Implantando o SCRUM em um Ambiente de Desenvolvimento de Produtos para Internet PUC ISSN 0103-9741 Monografias em Ciência da Computação n 07/09 Implantando o SCRUM em um Ambiente de Desenvolvimento de Produtos para Internet Jacques Douglas Varaschim Departamento de Informática PONTIFÍCIA

Leia mais

Frederico Aranha, Instrutor. Scrum 100 Lero Lero. Um curso objetivo!

Frederico Aranha, Instrutor. Scrum 100 Lero Lero. Um curso objetivo! Scrum 100 Lero Lero Um curso objetivo! Napoleãããõ blah blah blah Whiskas Sachê Sim, sou eu! Frederico de Azevedo Aranha MBA, PMP, ITIL Expert Por que 100 Lero Lero? Porque o lero lero está documentado.

Leia mais

Método Ágil em Gerenciamento de Projetos de Software

Método Ágil em Gerenciamento de Projetos de Software Fundação Getulio Vargas MBA em Gerenciamento de Projetos Método Ágil em Gerenciamento de Projetos de Software Ana Cristina Monteiro Almeida Arnaldo Lyrio Barreto (Orientador) Rio de Janeiro Outubro de

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Curso de Sistemas de Informação Karla Donato Fook karladf@ifma.edu.br DESU / DAI 2015 Desenvolvimento Rápido de Software 2 1 Para quê o Desenvolvimento Rápido de Software? Os negócios

Leia mais

Metodologias Ágeis de Desenvolvimento de Software

Metodologias Ágeis de Desenvolvimento de Software "Antes de imprimir pense em sua responsabilidade e compromisso com o MEIO AMBIENTE." Engenharia de Software de Desenvolvimento de Software Givanaldo Rocha de Souza givanaldo.rocha@ifrn.edu.br http://docente.ifrn.edu.br/givanaldorocha

Leia mais

MDMS-ANAC. Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC. Superintendência de Tecnologia da Informação - STI

MDMS-ANAC. Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC. Superintendência de Tecnologia da Informação - STI MDMS-ANAC Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC Superintendência de Tecnologia da Informação - STI Histórico de Alterações Versão Data Responsável Descrição 1.0 23/08/2010 Rodrigo

Leia mais

MANIFESTO ÁGIL. Esses conceitos aproximam-se melhor com a forma que pequenas e médias organizações trabalham e respondem à mudanças.

MANIFESTO ÁGIL. Esses conceitos aproximam-se melhor com a forma que pequenas e médias organizações trabalham e respondem à mudanças. METODOLOGIAS ÁGEIS SURGIMENTO As metodologias ágeis surgiram em resposta ao problema dos atrasos no desenvolvimento de software e aos cancelamentos, devido ao fato dos sistemas demorarem muito tempo para

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO Santa Maria, 27 de Setembro de 2013. Revisão aula anterior Desenvolvimento Ágil de Software Desenvolvimento e entrega

Leia mais

INTRODUÇÃO AOS MÉTODOS ÁGEIS

INTRODUÇÃO AOS MÉTODOS ÁGEIS WESLLEYMOURA@GMAIL.COM INTRODUÇÃO AOS MÉTODOS ÁGEIS ANÁLISE DE SISTEMAS Introdução aos métodos ágeis Metodologias tradicionais Estes tipos de metodologias dominaram a forma de desenvolvimento de software

Leia mais

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

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

Leia mais

Scrum How it works. Há quatro grupos com papéis bem definidos:

Scrum How it works. Há quatro grupos com papéis bem definidos: Scrum É um processo de desenvolvimento iterativo e incremental. É utilizado quando não se consegue predizer tudo o que irá ocorrer. Em geral, utiliza-se em projetos complexos, de difícil abordagem pela

Leia mais

Ferramenta Open Source para Apoio ao Uso do Scrum por Equipes Distribuídas

Ferramenta Open Source para Apoio ao Uso do Scrum por Equipes Distribuídas Ferramenta Open Source para Apoio ao Uso do Scrum por Equipes Distribuídas Eric Cavalcanti 34, Teresa M. de Medeiros Maciel 1234, Jones Albuquerque 134 1 Universidade Federal Rural de Pernambuco Recife,

Leia mais

Scrumming. Ferramenta Educacional para Ensino de Práticas do SCRUM

Scrumming. Ferramenta Educacional para Ensino de Práticas do SCRUM PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO GRANDE DO SUL FACULDADE DE INFORMÁTICA CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO Scrumming Ferramenta Educacional para Ensino de Práticas do SCRUM por ERASMO

Leia mais

Gerenciamento de Projetos de Software

Gerenciamento de Projetos de Software Gerenciamento de Projetos de Software Framework Ágil, Scrum Prof. Júlio Cesar da Silva Msc. 2º Encontro Ementa & Atividades Aula 1: Fundamentos do Gerenciamento de Projetos (p. 4) 30/abr (VISTO) Aula 2:

Leia mais

O Guia Passo-a-Passo para IMPLANTAR. Em seu próprio Projeto

O Guia Passo-a-Passo para IMPLANTAR. Em seu próprio Projeto O Guia Passo-a-Passo para IMPLANTAR Em seu próprio Projeto Aprenda como Agilizar seu Projeto! A grande parte dos profissionais que tomam a decisão de implantar o Scrum em seus projetos normalmente tem

Leia mais

UNIVERSIDADE SÃO FRANCISCO Curso de Engenharia da Computação RAFAEL HIDEMASA FURUKAWA

UNIVERSIDADE SÃO FRANCISCO Curso de Engenharia da Computação RAFAEL HIDEMASA FURUKAWA UNIVERSIDADE SÃO FRANCISCO Curso de Engenharia da Computação RAFAEL HIDEMASA FURUKAWA ESTUDO DE APLICAÇÃO DE PRÁTICAS DO PMBOK EM PROJETOS DE SOFTWARE BASEADOS EM SCRUM Itatiba 2012 UNIVERSIDADE SÃO FRANCISCO

Leia mais

GESTÃO DO CONHECIMENTO PARA O DESENVOLVIMENTO DE SOFTWARE COM MÉTODOS ÁGEIS

GESTÃO DO CONHECIMENTO PARA O DESENVOLVIMENTO DE SOFTWARE COM MÉTODOS ÁGEIS GESTÃO DO CONHECIMENTO PARA O DESENVOLVIMENTO DE SOFTWARE COM MÉTODOS ÁGEIS Jeandro Maiko Perceval 1 Carlos Mario Dal Col Zeve2 Anderson Ricardo Yanzer Cabral ² RESUMO Este artigo apresenta conceitos sobre

Leia mais

Com metodologias de desenvolvimento

Com metodologias de desenvolvimento Sociedade demanda grande quantidade de sistemas/aplicações software complexo, sistemas distribuídos, heterogêneos requisitos mutantes (todo ano, todo mês, todo dia) Mas, infelizmente, não há gente suficiente

Leia mais

UMA ABORDAGEM PARA VIABILIZAR A ADERÊNCIA DA METODOLOGIA SCRUM AO MODELO MPS.BR NÍVEL G.

UMA ABORDAGEM PARA VIABILIZAR A ADERÊNCIA DA METODOLOGIA SCRUM AO MODELO MPS.BR NÍVEL G. UMA ABORDAGEM PARA VIABILIZAR A ADERÊNCIA DA METODOLOGIA SCRUM AO MODELO MPS.BR NÍVEL G. Magda A. Silvério Miyashiro 1, Maurício G. V. Ferreira 2, Bruna S. P. Martins 3, Fabio Nascimento 4, Rodrigo Dias

Leia mais

Especialização em Engenharia de Software e Banco de Dados

Especialização em Engenharia de Software e Banco de Dados Especialização em Engenharia de Software e Banco de Dados Disciplina: Engenharia de Software Tópico: Metodologias Ágeis Prof. Rodolfo Miranda de Barros rodolfo@uel.br O que é agilidade? Agilidade: Rapidez,

Leia mais

Proposta. Treinamento Scrum Master Gerenciamento Ágil de Projetos. Apresentação Executiva

Proposta. Treinamento Scrum Master Gerenciamento Ágil de Projetos. Apresentação Executiva Treinamento Scrum Master Gerenciamento Ágil de Projetos Apresentação Executiva 1 O treinamento Scrum Master Gerenciamento Ágil de Projetos tem como premissa preparar profissionais para darem início às

Leia mais

SCRUM: UM GUIA PRÁTICO NO GERENCIAMENTO DE PROJETOS

SCRUM: UM GUIA PRÁTICO NO GERENCIAMENTO DE PROJETOS SCRUM: UM GUIA PRÁTICO NO GERENCIAMENTO DE PROJETOS RESUMO Salmo Roberto Da Silva Junior 1 salmo@ciandt.com Daniel Facciolo Pires 2 daniel@facef.br Silvio Carvalho Neto 3 silvio@facef.br Este trabalho

Leia mais

UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES

UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES Marcelo Augusto Lima Painka¹, Késsia Rita da Costa Marchi¹ ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil

Leia mais

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis. Profª Esp.: Maysa de Moura Gonzaga

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis. Profª Esp.: Maysa de Moura Gonzaga DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis Profª Esp.: Maysa de Moura Gonzaga 2º Semestre / 2011 Extreme Programming (XP); DAS (Desenvolvimento Adaptativo de Software)

Leia mais

Proposta de processo baseado em Scrum e Kanban para uma empresa de telecomunicações

Proposta de processo baseado em Scrum e Kanban para uma empresa de telecomunicações 79 Proposta de processo baseado em Scrum e Kanban para uma empresa de telecomunicações Luís Augusto Cândido Garcia Afonso Celso Soares Centro de Ensino Superior em Gestão, Tecnologia e Educação FAI garcialac@yahoo.com.br

Leia mais

Estudo de caso: aplicação das metodologias ágeis de desenvolvimento: Scrum e XP no desenvolvimento do sistema Unidisciplina

Estudo de caso: aplicação das metodologias ágeis de desenvolvimento: Scrum e XP no desenvolvimento do sistema Unidisciplina Perquirere, 11 (1): 113-129, jul. 2014 Centro Universitário de Patos de Minas http://perquirere.unipam.edu.br Estudo de caso: aplicação das metodologias ágeis de desenvolvimento: Scrum e XP no desenvolvimento

Leia mais

SCRUM Discussão e reflexão sobre Agilidade. Fernando Wanderley

SCRUM Discussão e reflexão sobre Agilidade. Fernando Wanderley SCRUM Discussão e reflexão sobre Agilidade Fernando Wanderley Apresentação Líder Técnico em Projetos Java (~ 9 anos) (CESAR, Imagem, CSI, Qualiti Software Process) Consultor de Processos de Desenvolvimento

Leia mais

FireScrum. Ontem, Hoje e o Futuro. Eric Cavalcanti. http://www.firescrum.com

FireScrum. Ontem, Hoje e o Futuro. Eric Cavalcanti. http://www.firescrum.com FireScrum Ontem, Hoje e o Futuro Eric Cavalcanti http://www.firescrum.com Ontem 2006 Projetos de desenvolvimentos de jogos com prazos de 3 a 4 meses Dificuldade em aplicar o processo existente Métodos

Leia mais

Versão 7 TraceGP Ágil

Versão 7 TraceGP Ágil Versão 7 Cadastro de Produtos Será possível cadastrar todos os produtos da empresa bem como descrever suas características particulares através da seleção de atributos dinâmicos para cada produto. Manutenção

Leia mais

Gestão de Projetos com Scrum

Gestão de Projetos com Scrum Gestão de Projetos com Scrum Curso de Verão - Jan / 2010 IME/USP - São Paulo Dairton Bassi dbassi@gmail.com Processo de gerenciamento de projetos. Processo iterativo de inspeção e adaptação. Usado para

Leia mais

UNIVERSIDADE DO ESTADO DE SANTA CATARINA CENTRO DE CIÊNCIAS TECNOLÓGICAS DEPARTAMENTO DE ENGENHARIA DE PRODUÇÃO E SISTEMAS VANESSA WATZKO

UNIVERSIDADE DO ESTADO DE SANTA CATARINA CENTRO DE CIÊNCIAS TECNOLÓGICAS DEPARTAMENTO DE ENGENHARIA DE PRODUÇÃO E SISTEMAS VANESSA WATZKO UNIVERSIDADE DO ESTADO DE SANTA CATARINA CENTRO DE CIÊNCIAS TECNOLÓGICAS DEPARTAMENTO DE ENGENHARIA DE PRODUÇÃO E SISTEMAS VANESSA WATZKO PROPOSTA DE MÉTODO DE GESTÃO DE PROJETOS INCORPORANDO CONCEITOS

Leia mais