universidade do vale do itajaÍ centro de ciÊncias ...siaibib01.univali.br/pdf/felipe augusto...
TRANSCRIPT
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
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
ii
Aos meus pais, João (em memória) e Luzia,
pelo amor, carinho e amizade que sempre dedicaram a mim.
iii
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.
iv
SUMÁRIO
LISTA DE ABREVIATURAS ................................................................ vii
LISTA DE FIGURAS ............................................................................. viii
LISTA DE TABELAS ................................................................................ x
RESUMO .................................................................................................... xi
ABSTRACT .............................................................................................. xii
1 INTRODUÇÃO ...................................................................................... 1
1.1 PROBLEMATIZAÇÃO ................................................................................... 3
1.1.1 Formulação do Problema ............................................................................... 3
1.1.2 Solução Proposta ............................................................................................ 3
1.2 OBJETIVOS ..................................................................................................... 4
1.2.1 Objetivo Geral ................................................................................................ 4
1.2.2 Objetivos Específicos ...................................................................................... 4
1.3 METODOLOGIA ............................................................................................. 4
1.4 ESTRUTURA DO TRABALHO ...................................................................... 5
2 FUNDAMENTAÇÃO TEÓRICA ........................................................ 7
2.1 METODOLOGIAS ÁGEIS .............................................................................. 7
2.2 SCRUM ............................................................................................................. 9
2.2.1 Ciclo do Scrum ............................................................................................... 9
2.2.2 Fases do Scrum ............................................................................................. 11
2.2.3 Papéis e Responsabilidades .......................................................................... 12
2.2.3.1 Scrum Master ......................................................................................... 12
2.2.3.2 Product Owner ....................................................................................... 12
2.2.3.3 Scrum Team ........................................................................................... 13
2.2.4 Sprint ............................................................................................................ 14
2.2.4.1 Sprint Planning ...................................................................................... 14
2.2.4.2 Daily Scrum Meeting ............................................................................. 15
2.2.4.3 Sprint Review ......................................................................................... 16
2.2.4.4 Sprint Retrospective .............................................................................. 16
2.2.5 Artefatos ........................................................................................................ 17
2.2.5.1 Product Backlog ..................................................................................... 17
2.2.5.2 Impediment Backlog .............................................................................. 18
2.2.5.3 Planning Poker ....................................................................................... 18
2.2.5.4 Task Board ............................................................................................. 24
2.2.5.5 Burndown Chart .................................................................................... 28
2.3 FERRAMENTAS DE GERENCIAMENTO COM SCRUM ....................... 30
2.3.1 Scrum Project ............................................................................................... 30
2.3.2 FireScrum ..................................................................................................... 33
v
2.3.3 VersionOne ................................................................................................... 36
2.3.4 TargetProcess ............................................................................................... 40
2.3.5 Comparativo ................................................................................................. 42
3 PROJETO ............................................................................................. 44
3.1 ANÁLISE DE REQUISITOS ......................................................................... 44
3.1.1 Requisitos Funcionais ................................................................................... 44
3.1.2 Requisitos Não Funcionais ........................................................................... 47
3.1.3 Regras de Negócio ........................................................................................ 47
3.2 CASOS DE USO ............................................................................................. 51
3.2.1 Módulo Acesso .............................................................................................. 52
3.2.2 Módulo Cadastros Básicos ........................................................................... 53
3.2.3 Módulo Product Backlog ............................................................................. 54
3.2.4 Módulo Sprint ............................................................................................... 55
3.2.5 Módulo Tarefa .............................................................................................. 56
3.2.6 Módulo Planning Poker ............................................................................... 57
3.2.7 Módulo Task Board ...................................................................................... 59
3.3 DIAGRAMA DE ENTIDADE RELACIONAMENTO ................................ 60
4 DESENVOLVIMENTO ...................................................................... 63
4.1 IMPLEMENTAÇÃO ...................................................................................... 63
4.2 SCRUM PROJECT ........................................................................................ 69
4.2.1 Acesso ............................................................................................................ 69
4.2.2 Projetos ......................................................................................................... 70
4.2.3 Usuários ........................................................................................................ 72
4.2.4 Product Backlog ........................................................................................... 73
4.2.5 Planning Poker ............................................................................................. 75
4.2.6 Sprint ............................................................................................................ 78
4.2.7 Tasks ............................................................................................................. 79
4.2.7.1 Task Board ............................................................................................. 80
4.2.8 Burndown Chart .......................................................................................... 82
4.3 MELHORIAS ................................................................................................. 84
5 CONCLUSÃO ...................................................................................... 85
6 REFERÊNCIAS BIBLIOGRÁFICAS ............................................... 87
GLOSSÁRIO ............................................................................................. 90
A DESCRIÇÃO DOS CASOS DE USO ................................................. 93
A.1 MÓDULO ACESSO ........................................................................................ 93
UC 01.01 Acessar o Sistema ................................................................................... 93
A.2 MÓDULO CADASTROS BÁSICOS ............................................................. 94
UC 01.01 Manter Usuário ...................................................................................... 94
UC 01.02 Manter Time ........................................................................................... 96
UC 01.03 Manter Projeto ....................................................................................... 97
vi
A.3 MÓDULO PRODUCT BACKLOG ............................................................... 99
UC 03.01 Manter Product Backlog........................................................................ 99
A.4 MÓDULO SPRINT ....................................................................................... 101
UC 04.01 Manter Sprint ....................................................................................... 101
UC 04.02 Manter Reunião de Planejamento ....................................................... 104
UC 04.03 Gerenciar Reunião Diária .................................................................... 105
UC 04.04 Manter Reunião de Revisão ................................................................. 106
UC 04.05 Manter Reunião de Retrospectiva ....................................................... 107
UC 04.06 Visualizar Sprint Burndown ............................................................... 108
A.5 MÓDULO TAREFA...................................................................................... 109
UC 05.01 Manter Tarefas..................................................................................... 109
UC 05.02 Alocar Tarefa ....................................................................................... 111
UC 05.03 Gerenciar Horas Trabalhadas ............................................................. 112
UC 05.04 Informar Status da Tarefa ................................................................... 114
UC 05.05 Gerenciar Impedimentos ..................................................................... 115
A.6 MÓDULO PLANNING POKER .................................................................. 116
UC 05.01 Definir a Complexidade ....................................................................... 116
UC 06.02 Gerenciar a Sessão ............................................................................... 117
UC 06.03 Estimar Itens de uma Sessão ............................................................... 119
A.7 MÓDULO TASK BOARD ............................................................................ 121
UC 07.01 Alocar Tarefa ....................................................................................... 121
UC 07.02 Alterar Status ....................................................................................... 122
vii
LISTA DE ABREVIATURAS
AJAX Asynchronous Javascript And XML CRUD Create, Retrieve, Update and Delete DSDM Dynamic Systems Development Method ER Entidade-Relacionamento FDD Feature Driven Development HTML HyperText Markup Language MIT Massachusetts Institute of Technology PHP Hypertext Preprocessor RIA Rich Internet Applications ROI Return of Investment SAAS Software as a Service SQL Structured Query Language TCC Trabalho de Conclusão de Curso UNIVALI Universidade do Vale do Itajaí XP Extreme Programming
viii
LISTA DE FIGURAS
Figura 1. Adoção de Metodologias Ágeis. ....................................................................................... 9
Figura 2. Visão geral de processo do Scrum. ................................................................................. 10
Figura 3. Estimando o Product Backlog sem Planning Poker. ....................................................... 19
Figura 4. Sequência de cartas do Planning Poker. ......................................................................... 20
Figura 5. Estimando o Product Backlog com Planning Poker. ...................................................... 22
Figura 6. Seleção da carta no Planning Poker. .............................................................................. 23
Figura 7. Definição da complexidade do item em análise. ............................................................. 24
Figura 8. Task Board. ................................................................................................................... 25
Figura 9. Tela da ferramenta Taskboard. ....................................................................................... 27
Figura 10. Sprint Burndown. ......................................................................................................... 28
Figura 11. Gráfico Burndown e Task Board. ................................................................................. 29
Figura 12. Tela inicial do Scrum Project. ...................................................................................... 31
Figura 13. Cadastro do Product Backlog no Scrum Project. .......................................................... 32
Figura 14. Módulo do Planning Poker no FireScrum. ................................................................... 34
Figura 15. Módulo do Task Board no FireScrum. .......................................................................... 35
Figura 16. Tela para cadastro de Sprint no FireScrum. .................................................................. 36
Figura 17. Utilização de ferramentas em empresas de desenvolvimento de software. .................... 37
Figura 18. Tela de Product Backlog da ferramenta VersionOne. ................................................... 38
Figura 19. Task Board da ferramenta VersionOne ......................................................................... 38
Figura 20. Product Burndown da ferramenta VersionOne. ............................................................ 39
Figura 21. Cadastro de Stories da ferramenta TargetProcess. ........................................................ 40
Figura 22. Task Board da ferramenta TargetProcess. ..................................................................... 41
Figura 23. Burndown Chart da ferramenta TargetProcess. ............................................................ 42
Figura 24. Atores do sistema. ........................................................................................................ 51
Figura 25. Diagrama de Casos de Uso do Módulo Acesso ............................................................. 52
Figura 26. Diagrama de Casos de Uso do Módulo Cadastros Básicos. ........................................... 53
Figura 27. Diagrama de Casos de Uso do Módulo Product Backlog. ............................................. 54
Figura 28. Diagrama de Casos de Uso do Módulo Sprint. ............................................................. 55
Figura 29. Diagrama de Estados do Módulo Tarefa. ...................................................................... 56
Figura 30. Diagrama de Casos de Uso do Módulo Tarefa. ............................................................. 57
Figura 31. Diagrama de Atividades do Planning Poker. ................................................................. 58
Figura 32. Diagrama de Casos de Uso do Módulo Planning Poker. ............................................... 59
Figura 33. Diagrama de Casos de Uso do Módulo Task Board. ..................................................... 60
Figura 34. Diagrama de Entidade Relacionamento. ....................................................................... 61
Figura 35. Código-fonte da view do Task Board. ........................................................................... 65
Figura 36. Trecho de código de uma requisição AJAX. ................................................................. 66
Figura 37. Trecho de código executado no Planning Poker............................................................ 67
Figura 38. Trecho de código da camada de controle do Planning Poker. ........................................ 67
Figura 39. Trecho de código da geração do Burndown Chart. ....................................................... 68
Figura 40. Exemplo de formatação para a Internacionalização. ..................................................... 68
Figura 41. Tela de boas vindas do Scrum Project. ......................................................................... 70
Figura 42. Tela de cadastro do projeto. ......................................................................................... 71
Figura 43. Tela de listagem dos projetos. ...................................................................................... 72
Figura 44. Tela do módulo de gerenciamento de usuários. ............................................................ 73
Figura 45. Tela de cadastro das Stories. ........................................................................................ 74
Figura 46. Tela de seleção das estórias para o Planning Poker. ...................................................... 76
ix
Figura 47. Tela do Planning Poker. ............................................................................................... 77
Figura 48. Tela do Planning Poker com estimativas. ..................................................................... 78
Figura 49. Tela de cadastro da Sprint. ........................................................................................... 79
Figura 50. Tela de cadastro da tarefa. ............................................................................................ 80
Figura 51. Tela do Task Board. ..................................................................................................... 81
Figura 52. Tela do gráfico Sprint Burndown.................................................................................. 83
x
LISTA DE TABELAS
Tabela 1. Comparativo de funcionalidades. ................................................................................... 43
Tabela 2. Comparativo técnico. ..................................................................................................... 43
xi
RESUMO
CORREIA, Felipe Augusto Paterlini. Scrum Project 2.0: ferramenta de gerenciamento de projetos com Scrum. Itajaí, 2010. 136f. 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í, 2010. 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.
xii
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.
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
2
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
3
á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
1.1.1 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).
1.1.2 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.
4
1.2 OBJETIVOS
1.2.1 Objetivo Geral
Reimplementar o software Scrum Project e incluir os módulos Planning Poker, Task Board
e Burndown Chart.
1.2.2 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.
5
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.
6
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.
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
8
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 2.2.
9
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.
2.2.1 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
10
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 2.2.5.3.
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).
11
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.
2.2.2 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.
12
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.
2.2.3.1 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.
2.2.3.2 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
13
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.
2.2.3.3 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.
14
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.
2.2.4.1 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
15
• 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, deve-
se 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.
2.2.4.2 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?
16
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.
2.2.4.3 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.
2.2.4.4 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?
17
• 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.
2.2.5 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.
2.2.5.1 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.
18
2.2.5.2 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.
2.2.5.3 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
19
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
Momento 2
Momento 3
Figura 3. Estimando o Product Backlog sem Planning Poker.
Fonte: Adaptado de Crisp (2010)
Pessoal, quanto irá demorar esta estória?
20
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
21
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).
22
Momento 1
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
Pessoal, quanto irá demorar esta estória?
23
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)
24
Na ferramenta Planning Poker, após todos os participantes selecionarem suas cartas, mostra-
se 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.
2.2.5.4 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
25
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
26
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
27
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.
28
2.2.5.5 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)
29
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
30
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.
2.3.1 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.
31
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 13.
32
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.
33
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.
2.3.2 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.
34
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.
35
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.
36
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.
2.3.3 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
37
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.
38
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)
39
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.
40
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
41
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.
42
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.
2.3.5 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
43
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.
44
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.
3.1.1 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;
45
• 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;
46
• 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 04.07 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;
47
• 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.
3.1.2 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.
3.1.3 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.
48
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
49
• 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;
50
• 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.
51
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.
52
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 01.01 Acessar o
Sistema
Figura 25. Diagrama de Casos de Uso do Módulo Acesso
53
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
Scrum Master
UC 02.01 - Manter
Usuário
UC 02.02 - Manter
Time
UC 02.03 - Manter
Projeto
Usuário
Figura 26. Diagrama de Casos de Uso do Módulo Cadastros Básicos.
54
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
Scrum MasterProduct Owner
UC 03.01 - Manter
Product Backlog
Figura 27. Diagrama de Casos de Uso do Módulo Product Backlog.
55
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
Scrum Master
UC 04.01 - Manter
Sprint
Scrum Team
UC 04.02 - Manter
Reunião de
Planejamento
UC 04.03 - Manter
Reunião Diária
UC 04.06 - Visualizar
Sprint Burndown
UC 04.04 - Manter
Reunião de Rev isão
UC 04.05 - Manter
Reunião de
Retrospectiv a
Usuário
Figura 28. Diagrama de Casos de Uso do Módulo Sprint.
56
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
A fazer em andamento
Impedida Concluida
FinalCancelada
Cancelamento da tarefa
[Cancelamento da tarefa]
Finalização da tarefa
Cadastro de impedimento
Liberação da tarefa
Alocação da tarefa
Criação da tarefa
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 04.02 e UC 04.04 podem ser executadas de forma gráfica, através do Task Board.
57
uc Pacote 4 - Tarefa
Scrum Team
UC 04.01 - Manter
Tarefas
UC 04.02 - Alocar
Tarefas
UC 04.03 - Gerenciar
Horas Trabalhadas
UC 04.04 - Informar
Status da Tarefa
UC 04.05 - Cadastrar
Impedimentos
Figura 30. Diagrama de Casos de Uso do Módulo Tarefa.
3.2.6 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.
58
act Jogo
Scrum Master Team
Inicio
Cria sessão
Escolhe os itens do
backlog
Inicia jogo Acessa sessão do Poker
Realiza a estimativ aAv alia estimativ as
Define estimativ a
Fim sessão
Figura 31. Diagrama de Atividades do Planning Poker.
59
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
Scrum Master
UC 05.02 Gerenciar a
SessãoUC 05.01 Definir a
Complexidade
UC 05.03 Estimar Itens
de uma Sessão
Scrum Team
Figura 32. Diagrama de Casos de Uso do Módulo Planning Poker.
3.2.7 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 3.2.5 . 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.
60
uc Pacote 7 - Task Board
Scrum Team
UC 07.01 Alocar
Tarefa
UC 07.02 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.
61
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.
Scrum Master
Product Owner
62
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.
63
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 5.1.36, 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).
64
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.
65
Finalizada a geração da estrutura MVC deste projeto, iniciou-se a personalização do código-
fonte 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.
66
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.
67
$.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
68
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.
69
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.
4.2.1 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
70
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.
4.2.2 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
71
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.
72
Figura 43. Tela de listagem dos projetos.
4.2.3 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 44.
73
Figura 44. Tela do módulo de gerenciamento de usuários.
4.2.4 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
45.
74
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
75
utilizado no Scrum e que será detalhado na seção 4.2.5 . Outro detalhe importante é que esta
estimativa somente pode ser definida pelo Scrum Master.
4.2.5 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.
76
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.
77
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.
1
2
3
78
Figura 48. Tela do Planning Poker com estimativas.
4.2.6 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.
79
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.
4.2.7 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
80
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.
4.2.7.1 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.
81
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 é
82
alocada ao usuário que está executando a ação. Deste modo, somente o usuário que alocou a tarefa
poderá arrastá-la para as colunas seguintes.
A partir do momento que a tarefa entra em desenvolvimento, ela pode assumir outros dos
estados: impedida ou concluída. O status de impedimento pode ser utilizado quando existe algum
outro fator que impede o andamento ou conclusão desta tarefa. Quando isto ocorrer, a tarefa deverá
ser arrastada até a coluna Impeded e então o motivo do impedimento poderá ser informado.
Quando uma tarefa estiver concluída, independente dela estar impedida ou não, bastará que
o membro do Scrum Team a arraste até a última coluna, definindo-a então como finalizada. Neste
momento, poderá ser informado o número de horas gasto com a tarefa, para que posteriormente
possa ser feito um comparativo entre o prazo estimado e o realizado.
4.2.8 Burndown Chart
Os gráficos Burndown permitem acompanhar o andamento do projeto como um todo ou de
uma Sprint específica. Basicamente, o gráfico confronta o número de tarefas com o prazo da Sprint
ou projeto. Como pode ser verificado na Figura 52, o eixo Y apresenta uma escala de zero até o
total de horas estimadas para as tarefas existentes dentro de determinada Sprint, enquanto que o
eixo X representa a escala entre a data inicial e final da Sprint ou projeto.
83
Figura 52. Tela do gráfico Sprint Burndown.
Pode-se verificar no gráfico da Figura 52, que há uma linha reta que inicia no canto superior
esquerdo e termina no canto inferior direito. Esta reta representa a sequência ideal de execução das
tarefas no período. A outra linha do gráfico representa o número de horas que ainda resta para
concluir as tarefas da Sprint.
Realizando uma análise deste gráfico apresentado na Figura 52, pode se verificar duas
informações iniciais: existem cinquenta horas estimadas na Sprint sendo que esta tem início em
01/07/2010 e está prevista para finalizar em 31/07/2010. Deste modo, pode-se verificar que a ao
longo dos dias da Sprint as tarefas foram sendo finalizadas e, portanto, o número de horas restantes
era também reduzido até chegar ao valor zero no final da Sprint.
Com esta ferramenta, pode-se então acompanhar o desenvolvimento das tarefas. Se a linha
do gráfico afastar-se muito para a direita da linha ideal, isso pode significar que as estórias da Sprint
poderão não estar completas até o prazo definido. E se ocorrer o contrário, ou seja, afastar-se para a
84
esquerda, então as tarefas estão sendo finalizadas muito cedo, situação em que se pode decidir a
inclusão de uma nova estória na Sprint.
4.3 Melhorias
Durante o desenvolvimento da segunda versão do Scrum Project e após a execução dos
testes de unidade, pôde-se perceber a necessidade de algumas pequenas revisões e melhorias que
podem agregar valor a versão atual da ferramenta. Todas as necessidades citadas não impedem a
utilização do Scrum Project, mas podem facilitar o uso da ferramenta. As melhorias identificadas
para este projeto são:
• Internacionalização;
• Revisão das questões de usabilidade;
• Permitir reiniciar uma sessão no Planning Poker;
• Inclusão de um chat para permitir a interação da equipe;
• Permitir o cadastro e edição das tarefas no Task Board;
• Permitir o cadastro do impedimento no Task Board; e
• Desenvolver o gráfico Product Burndown.
85
5 CONCLUSÃO
Através da realização deste trabalho, pôde-se perceber que as metodologias ágeis têm estado
cada vez mais presentes nos processos de desenvolvimento de software. Apesar de estas
metodologias valorizarem mais a utilização de artifícios visuais não computacionais, torna-se claro
que em algum momento a utilização de ferramentas surge para preencher deficiências dentro dos
processos de desenvolvimento. Além de auxiliar durante a execução de projetos, estas ferramentas
podem ser também utilizadas quando as equipes encontram-se geograficamente distribuídas.
O desenvolvimento desta segunda versão do Scrum Project teve como propósito inicial
integrar novas funcionalidades como o Task Board, Planning Poker e Burndown Chart. Contudo,
no decorrer da análise realizada na primeira etapa deste TCC, constatou-se que a primeira versão do
Scrum Project, desenvolvida pelo ScriptCase, seria de difícil manutenção visto que há necessidade
de utilizar a ferramenta para geração e manutenção do código fonte. Deste modo, entendeu-se que
seria inviável a integração com componentes externos, impedindo a inclusão dos módulos
propostos. Além disso, o ScriptCase é uma ferramenta paga, de modo que o Scrum Project não
poderia ser considerado open source, dificultando o acesso ao trabalho desenvolvido.
Com base nos motivos citados, optou-se por reescrever todo o Scrum Project utilizando-se
de um framework open source de modo que possa ser mais facilmente compreendido e modificado
por outros alunos e profissionais. Por esta razão, o escopo inicial do projeto cresceu
consideravelmente visto que além da reimplementação da ferramenta, ainda seria necessário incluir
os módulos propostos inicialmente. Todo o conhecimento adquirido na versão anterior, integrado às
novas pesquisas realizadas nesta versão e descritos na Fundamentação Teórica puderam agregar
novos valores às funcionalidades existentes. E quanto à modelagem do software, aproveitou-se
bastante da versão anterior, havendo apenas alguns ajustes para adaptar-se aos requisitos deste
trabalho, além das modificações realizadas para inclusão dos novos módulos.
A nova versão do Scrum Project está contemplando grande parte das funcionalidades do
Scrum, sendo que esta segunda versão possui todas as funcionalidades da primeira versão, além dos
três novos módulos: Task Board, Planning Poker e Burndown Chart. Uma das grandes
preocupações deste projeto era utilizar apenas ferramentas open source de forma que pudesse ser
facilmente estudada por qualquer pessoa, sem nenhuma limitação.
86
O framework utilizado no desenvolvimento deste trabalho trouxe muitos resultados
positivos, visto que reduziu bastante o tempo de desenvolvimento e, mesmo que não tenha atendido
a todas as necessidades deste trabalho, permitiu a utilização de outras tecnologias e plug-ins. Outra
questão bastante importante deste framework é o fato dele ser open source permitindo que a
ferramenta produzida neste TCC possa servir de base para novas pesquisas e estudos.
Neste trabalho, foram realizados apenas os testes de unidade, ou seja, testes realizados pelo
próprio desenvolvedor, não sendo possível realizar testes reais de utilização da ferramenta. Para
futuras implementações, sugere-se a realização de testes mais eficazes, de forma que possam ser
identificados erros e melhorias para as novas versões do Scrum Project. Entre os mais importantes,
pode-se citar testes de usabilidade e acessibilidade.
Como trabalho futuro, pensou-se na adaptação do Scrum Project para utilizá-lo como SAAS
(Software as a Service), ou seja, um software como serviço. Esta é uma grande tendência das
grandes empresas, que buscam evitar a utilização de servidores próprios através da contratação de
serviços terceirizados. Deste modo, poderia ser realizado um estudo na ferramenta e uma revisão
em sua modelagem para que possa ser utilizada em uma estrutura de software como serviço.
6 REFERÊNCIAS BIBLIOGRÁFICAS
AGILE MANIFESTO. Manifesto for Agile Software Development. 2001. Disponível em: <http://agilemanifesto.org>. Acesso em 27 mar. 2010. BOENTE, Alfredo Nazareno P.; OLIVEIRA, Fabiano S. G. de; ALVES, João Carlos Nogueira. RUP como metodologia de desenvolvimento de software para obtenção da qualidade de software. Rio de Janeiro, 2008. Disponível em: <http://www.boente.eti.br/publica/seget2008rup.pdf>. Acesso em: 05 jul. 2010. CAKEPHP. CakePHP, 2010. Disponível em: < http://cakephp.org/>. Acesso em: 22 out. 2010. CAVALCANTI, Eric; MACIEL, Teresa M. de Medeiros; ALBUQUERQUE, Jones. Ferramenta OpenSource para apoio ao uso do Scrum por equipes distribuídas. Pernambuco, 2009. Disponível em: <http://www.lbd.dcc.ufmg.br:8080/colecoes/wdds/2009/006.pdf>. Acesso em: 24 abr. 2010. COGNIFIDE. Taskboard, 2010. Disponível em: <http://www.taskboard.cognifide.com/>. Acesso em: 22 maio 2010. CRISP. Planning Poker. 2010. Disponível em: < http://www.crisp.se/planningpoker/>. Acesso em: 15 maio 2010. FERREIRA, Décio et al. Um modelo ágil para gestão de projectos de software. Portugal, 2006. Disponível em: <http://paginas.fe.up.pt/~aaguiar/es/artigos%20finais/es_final_19.pdf>. Acesso em: 22 maio 2010. FERREIRA, Renata Bastos; LIMA, Francisco de Paula Antunes. Metodologias ágeis: um novo paradigma de desenvolvimento de software. 2008. Disponível em: <http://www.cos.ufrj.br/~handrade/woses/woses2006/pdfs/10-Artigo10WOSES-2006.pdf>. Acesso em: 08 abr. 2010. FIRESCRUM. FireScrum. 2010. Disponível em: <http://www.firescrum.com/>. Acesso em: 25 abr. 2010. JQUERY. jQuery, 2010. Disponível em: <http://jquery.com/>. Acesso em: 22 out. 2010. KLUGE, Monike Roberta. Scrum Project: ferramenta de apoio ao gerenciamento de projetos de software baseada nos princípios da metodologia ágil Scrum. 2009. 81f. Trabalho de Conclusão de Curso. (Bacharel em Ciência da Computação) – CTTMAR, Universidade do Vale do Itajaí, Itajaí, 2009. LUDVIG, Diogo; REINERT, Jonatas Davson. Estudo do uso de metodologias ágeis no desenvolvimento de uma aplicação de governo eletrônico. Santa Catarina, 2007. Disponível em: <http://projetos.inf.ufsc.br/arquivos_projetos/projeto_589/Artigo_Diogo_Jonatas.pdf>. Acesso em: 02 mai. 2010.
88
MARÇAL, Ana Sofia et al. Estendendo o SCRUM segundo as áreas de processo de gerenciamento de projetos do CMMI. 2007. Disponível em: < http://www.cesar.org.br/files/file/SCRUMxCMMI-CLEI-2007.pdf>. Acesso em: 28 fev. 2010. MONTAIN GOAT SOFTWARE. Planning Poker. 2010. Disponível em: <http://www.planningpoker.com>. Acesso em: 17 maio 2010. MÜLLER, Elias. Métodos ágeis: uma aplicação do Scrum no Simuplan. 2004. 92f. Trabalho de Conclusão de Curso. (Bacharel em Ciência da Computação) – Instituto de Ciências Exatas e Geociências, Universidade de Passo Fundo, Passo Fundo, 2004. OSI. The MIT Licence. 2010. Disponível em: <http://www.opensource.org/licenses/mit-license.php>. Acesso em 30 out. 2010. PAASIVAARA, Maria; DURASIEWICZ, Sandra; LASSENIUS, Casper. Distributed agile development: using Scrum in a large project. IEEE, 2008. ______. Using Scrum in distributed agile development: A multiple case study. Fourth IEEE International Conference on Global Software Engineering, 2009. PCHART. pChart, 2010. Disponível em: <http://pchart.sourceforge.net/>. Acesso em: 22 out. 2010. PERRY, Tom. Drifting toward invisibility: the transition to the Electronic Task Board. Agile 2008 Conference, 2008. PEREIRA, Paulo; TORREÃO, Paula; MARÇAL, Ana Sofia. Entendendo Scrum para gerenciar projetos de forma ágil. MundoPM, Recife, n.14, p.64-71, 2007. RUBART, Jessica; FREYKAMP, Frank. Supporting daily Scrum meetings with change structure. ACM, 2009. SCRIPTCASE. ScriptCase, 2010. Disponível em: <http://www.scriptcase.com.br/>. Acesso em: 22 out. 2010. SOARES, Michel dos Santos. Comparação entre metodologias ágeis e tradicionais para o desenvolvimento de software. Minas Gerais, 2004. Disponível em: <http://www.dcc.ufla.br/infocomp/artigos/v3.2/art02.pdf>. Acesso em: 23 fev. 2010. SOMMERVILLE, Ian. Engenharia de software. 8.ed. São Paulo: Pearson Addison Wesley, 2007. SZALVAY, Victor. An introduction to agile software development. nov. 2004. Disponível em: <http://www.danube.com/docs/Intro_to_Agile.pdf>. Acesso em: 18 fev. 2010. SZIMANSKY, Fernando; ALBUQUERQUE, Jones; FURTADO, Felipe. Implementando maturidade e agilidade em uma fábrica de software através de Scrum e MPS.BR nível G. 2009. Disponível em: <http://www.ulbra-to.br/eventos/encoinfo/2009/Anais/ Implementando_maturidade_e_agilidade_em_uma_fabrica_de_software_atraves_de_Scrum_e_MPS_BR_nivel_G.pdf>. Acesso em: 28 fev. 2010.
89
TARGETPROCESS. TargetProcess, 2010. Disponível em: <http://www.targetprocess.com/>. Acesso em: 22 maio 2010. TOMÁS, Mário Rui Sampaio. Métodos ágeis: características, pontos fortes e fracos e possibilidades de aplicação. 2009. Disponível em: <http://run.unl.pt/bitstream/10362/2003/1/WPSeries_09_2009Tomas.pdf>. Acesso em: 8 abr. 2010. VARASCHIM, Jacques Douglas. Implantando o SCRUM em um ambiente de desenvolvimento de produtos para Internet. Rio de Janeiro, 2009. Disponível em: <ftp://ftp.inf.puc-rio.br/pub/docs/techreports/09_07_varaschim.pdf>. Acesso em: 08 mai. 2010. VERSIONONE. State of agile Survey: the state of agile development. 2009. Disponível em: <http://www.versionone.com/pdf/3rdAnnualStateOfAgile_FullDataReport.pdf>. Acesso em: 27 mar. 2010. ______. VersionOne Enterprise. 2010. Disponível em: < http://www.versionone.com>. Acesso em: 25 abr. 2010. ZHI-GEN, Hu; QUAN, Yuan; XI, Zhang. Research on agile project management with Scrum method. IITA International Conference on Services Science, Management and Engineering, 2009.
90
GLOSSÁRIO
Burndown Chart Formato de gráfico utilizado para acompanhamento do progresso do projeto.
Business Value Valor de negócio associado à funcionalidade servindo de parâmetro na priorização dos itens do Product Backlog.
Daily Scrum Meeting Reunião realizada com a equipe, com normalmente quinze minutos, para discutir o andamento do projeto.
Impediment Backlog Conjunto de itens que impedem o desenvolvimento de alguma funcionalidade.
Planning Poker Jogo realizado, no início do projeto, entre os integrantes da equipe de desenvolvimento do produto para avaliar a complexidade de cada item do Product Backlog.
Product Backlog Lista de todos os requisitos identificados para o projeto.
Product Burndown gráfico que representa a velocidade de entrega dos itens do Product Backlog pelo time.
Product Owner É definido como o cliente do projeto e representa os interesses dos envolvidos.
Scrum Master Executa funções de gerência de projetos sendo um facilitador do processo e responsável por auxiliar os envolvidos a resolver conflitos.
Scrum Team Time de desenvolvedores que trabalha nas funcionalidades do produto.
Sprint Ciclo que possui uma série de iterações bem definidas, cada uma com duração de duas a quatro semanas, em que o time precisa desenvolver as funcionalidades destacadas.
Sprint Backlog Tarefas necessárias para desenvolver as funcionalidades escolhidas no Product Backlog.
Sprint Burndown Gráfico que representa a velocidade e progresso de evolução das tarefas em uma determinada Sprint.
Sprint Planning Reunião realizada no início de cada Sprint para definir quais estórias serão desenvolvidas na iteração e quais as tarefas serão criadas para o Scrum
Team.
Sprint Retrospective Reunião realizada no término da Sprint para identificar problemas encontrados e avaliar questões que precisam ser melhoradas.
Sprint Review Reunião de revisão realizada no término da Sprint para apresentar ao Product Owner as funcionalidades desenvolvidas.
91
Story Funcionalidade definida pelo Product Owner que compõe o Product
Backlog.
Task Board Quadro dividido em colunas que representam os estágios de desenvolvimento das tarefas, de forma que o Scrum Team precisa apenas movimentar as tarefas entre estas colunas.
92
APÊNDICES
A DESCRIÇÃO DOS CASOS DE USO
Neste apêndice são apresentadas as descrições detalhadas dos casos de uso desenvolvidos
neste trabalho.
A.1 MÓDULO ACESSO
Este módulo representa as interações de autenticação no sistema.
UC 01.01 Acessar o Sistema
Permite que qualquer usuário cadastrado possa efetuar login no sistema através de usuário e
senha.
Requisitos:
• RF 01.06: O sistema deverá permitir a qualquer usuário cadastrado se autenticar no
sistema; e
• RNF04: O sistema deverá solicitar ao usuário login e senha de acesso.
Condições:
• Pré-condição: deve haver um usuário cadastrado no sistema; e
• Pós-condição: usuário cadastrado, alterado ou inativado dependendo da ação do usuário.
Cenários:
Acessar o Sistema - Principal
1. Usuário acessa a página principal do sistema;
2. Usuário clica em Projetos;
3. Sistema solicita login e senha;
4. Usuário preenche os campos solicitados e clica em Login; e
5. Sistema libera acesso para o usuário.
94
Login e/ou Senha Incorreta - Exceção
Caso o login e/ou a senha informados pelo usuário estejam incorretos, no passo 4 do cenário
Acessar o Sistema:
1. Sistema exibe mensagem "Login e/ou senha incorreta" e retorna ao passo 3.
Usuário Não Cadastrado - Exceção
Caso o usuário informado não esteja cadastrado, no passo 4 do cenário Acessar o Sistema:
1. Sistema exibe mensagem "Usuário não cadastrado" e retorna ao passo 3.
A.2 MÓDULO CADASTROS BÁSICOS
Este módulo representa todas as interações realizadas com os cadastros de usuários, times e
projetos.
UC 01.01 Manter Usuário Permite ao usuário cadastrar, alterar ou inativar um usuário. Nessa tela os seguintes campos
podem ser informados: nome do usuário, cidade, país, telefone, e-mail, login e senha.
Requisitos:
• RF 01.02: O sistema deverá permitir ao Scrum Master cadastrar, alterar e inativar
usuários;
• RN 01.05: Um usuário deverá obrigatoriamente possuir as seguintes informações: nome,
usuário e senha; e
• RN 01.06: Não deverá haver usuários cadastros com mesmo nome de login.
Condições:
• Pré-condição: projeto selecionado pelo usuário;
• Pré-condição: usuário autenticado no sistema; e
• Pós-condição: usuário cadastrado, alterado ou inativado dependendo da ação do usuário.
95
Cenários:
Cadastrar Usuário - Principal
1. Sistema apresenta tela para cadastro de novo usuário;
2. Scrum Master preenche os campos solicitados;
3. Scrum Master clica em inserir novo registro;
4. Sistema verifica se os dados obrigatórios foram informados; e
5. Sistema salva informações no banco de dados.
Dados obrigatórios não informados – Exceção
Campos obrigatórios não preenchidos, no passo 3 do caso de uso Cadastrar Usuário:
1. Sistema exibe a mensagem "Favor preencher todos os campos obrigatórios" e retorna ao
passo 1.
Login Repetido – Exceção
O login informado já existe, no passo 3 do cenário Cadastrar Usuário:
1. Sistema exibe mensagem "Este login já está cadastrado" e retorna ao passo 1.
Alterar Usuário – Alternativo
1. Sistema apresenta tela para alteração dos dados do usuário;
2. Usuário altera as informações necessárias;
3. Usuário clica em Gravar; e
4. Sistema salva informações no banco de dados.
Inativar Usuário – Alternativo
1. Sistema apresenta listagem dos usuários cadastrados;
2. Usuário seleciona um registro e clica em Inativar; e
96
3. Sistema exclui usuário do banco de dados.
UC 01.02 Manter Time
Permite ao Scrum Master alocar ou liberar usuários em um projeto, a partir dos usuários pré-
cadastrados no sistema.
Requisitos:
• RF 01.01: O sistema deverá permitir ao Scrum Master alocar ou liberar usuários de um
projeto;
• RN 01.07: O sistema não deverá permitir desvincular do projeto um usuário que possua
informações cadastradas; e
• RN 01.08: O Scrum Master e o Product Owner não podem ser alocados ao time do
projeto.
Condições:
• Pré-condição: pelo menos um usuário cadastrado;
• Pré-condição: usuário autenticado no sistema;
• Pré-condição: projeto selecionado pelo usuário; e
• Pós-condição: usuário alocado ou liberado, dependendo da ação do usuário.
Cenários:
Alocar Usuários - Principal
1. Sistema apresenta listagem de todos os usuários cadastrados no sistema;
2. Scrum Master clica em Alocar Usuário; e
3. Sistema salva informações no banco de dados.
Usuário Não Permitido – Exceção
Caso o usuário selecionado, no passo 2 do cenário Cadastrar Times, seja um Scrum Master
ou Product Owner do projeto:
1. Sistema não permite a alocação do usuário e retorna ao passo 1.
97
Liberar Usuários - Principal
1. Sistema apresenta listagem de todos os usuários cadastrados no sistema, com a opção
Liberar disponível para os usuários alocados no projeto;
2. Scrum Master clica em Liberar Usuário; e
3. Sistema salva informações no banco de dados.
Usuário Ativo no Projeto – Exceção
Caso o usuário possua informações relacionadas ao projeto, no passo 2 do caso de uso
Liberar Usuário:
1. Sistema apresenta a mensagem "Este usuário está ativo no projeto e não pode ser
liberado" e retorna ao passo 1.
UC 01.03 Manter Projeto
Permite ao usuário cadastrar, alterar ou excluir um projeto. Para o cadastro do projeto os
seguintes campos podem ser informados: nome do projeto, descrição, data de início, data de
finalização, Scrum Master e Product Owner.
Requisitos:
• 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;
• 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; e
• RN 01.04: Não poderá ser selecionado o mesmo usuário para Scrum Master e Product
Owner em um mesmo projeto.
98
Condições:
• Pré-condição: deverá haver pelo menos dois usuários cadastrados;
• Pré-condição: o usuário deverá estar autenticado no sistema; e
• Pós-condição: projeto cadastrado, alterado ou excluído.
Cenários:
Cadastrar Projeto - Principal
1. Sistema apresenta tela para cadastro de novo projeto;
2. Usuário digita nome, descrição, data de início e fim, orçamento e responsável do projeto;
3. Usuário clica em inserir novo registro; e
4. Sistema salva informações no banco de dados.
Dados obrigatórios não informados – Exceção
Caso o usuário não informe um dado obrigatório, no passo 2 do cenário Cadastrar Projeto:
1. Sistema mostra a mensagem “Favor preencher os campos obrigatórios” e retorna ao
passo 1.
Data de Finalização – Exceção
Caso a data de finalização seja menor que a data de início, no passo 3 do caso de uso
Cadastrar Projeto:
1. O sistema exibe a mensagem "A Data de Término deve ser maior que a Data de Início" e
retorna para o passo 1.
Scrum Master e Product Owner – Exceção
Caso o mesmo usuário seja definido como Scrum Master e Product Owner, no passo 3 do
caso de uso Cadastrar Projeto:
1. O sistema exibe a mensagem "Não é possível definir o mesmo usuário como Product
Owner e Scrum Master" e retorna para o passo 1.
99
Alterar Projeto - Principal
1. Sistema apresenta tela para alteração dos dados do projeto;
2. Usuário altera as informações necessárias;
3. Usuário clica em Gravar; e
4. Sistema salva informações no banco de dados.
Excluir Projeto - Principal
1. Sistema apresenta listagem dos projetos cadastrados;
2. Usuário seleciona um projeto e clica em Excluir; e
3. Sistema exclui projeto do banco de dados.
Projeto Iniciado – Exceção
Caso o projeto possua informações cadastradas, no passo 2 do cenário Excluir Projeto:
1. Sistema apresenta a mensagem "Este projeto possui informações cadastradas" e retorna
ao passo 1.
A.3 MÓDULO PRODUCT BACKLOG
Este módulo representa todas as interações realizadas com o Product Backlog do projeto.
UC 03.01 Manter Product Backlog
Permite ao usuário cadastrar, alterar ou excluir os itens do Product Backlog do projeto.
Requisitos:
• 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;
100
• RF 03.03: O sistema deverá permitir ao Scrum Master e Scrum Team estimar os itens de
um Product Backlog;
• RN 02.01: Uma estória deverá obrigatoriamente possuir as seguintes informações:
descrição e valor de negócio;
• RN 02.03: Uma estória não pode ser excluída caso ela possua tarefas cadastradas; e
• RN 02.04: Uma estória finalizada não pode ser alterada ou excluída.
Condições:
• Pré-Condição: um projeto deverá estar selecionado;
• Pré-Condição: o usuário deverá estar autenticado no sistema; e
• Pós-Condição: estória cadastrada, alterada ou excluída dependendo da ação do usuário.
Cenários:
Cadastrar Story - Principal
1. Sistema apresenta tela para cadastro de Stories;
2. Usuário informa descrição, valor de negócio e estimativa;
3. Usuário clica em inserir novo registro; e
4. Sistema salva informações no banco de dados.
Campos Obrigatórios – Exceção
Campos obrigatórios não preenchidos, no passo 3 do caso de uso Cadastrar Story:
1. Sistema exibe mensagem "Favor preencher todos os campos obrigatórios" e retorna ao
passo 1.
Alterar Story – Alternativo
1. Sistema apresenta tela para alteração da Story;
2. Usuário altera os campos que necessita;
3. Usuário clica em atualizar;
101
4. Sistema salva as informações no banco de dados.
Excluir Story – Alternativo
1. Sistema apresenta listagem das Stories do projeto;
2. Usuário clica em excluir; e
3. Sistema exclui a Story do banco de dados.
Story com tarefa cadastrada – Exceção
Caso a Story possua alguma tarefa cadastrada, no passo 2 do cenário Excluir Story:
1. Sistema apresenta exibe a mensagem: “Não é possível excluir esta Story, pois existem
tarefas cadastradas” e retorna ao passo 1.
Story Finalizada – Exceção
Caso a Story esteja finalizada, no passo 3 do caso de uso Alterar Story ou passo 2 do caso de
uso Excluir Story:
1. Sistema exibe a mensagem "Esta Story está finalizada" e retorna ao passo 1.
A.4 MÓDULO SPRINT
Este módulo representa todas as interações realizadas com as sprints cadastradas em um
projeto.
UC 04.01 Manter Sprint
Permite ao Scrum Master cadastrar, alterar ou excluir Sprints para um projeto. Nessa tela os
seguintes campos poderão ser informados: descrição, data de início e data de finalização.
Requisitos:
• RF 04.01: O sistema deverá permitir ao Scrum Master cadastrar, alterar e excluir uma
Sprint para um projeto;
• RF 04.07: O sistema deverá permitir ao Scrum Master selecionar os itens do Product
Backlog que irão compor a Sprint;
102
• 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; e
• RN 03.05: Não pode ser excluída uma Sprint finalizada.
Condições:
• Pré-condição: um projeto deve estar selecionado;
• Pré-condição: o usuário deverá estar autenticado no sistema; e
• Pós-condição: Sprint cadastrada, alterada ou excluída dependendo da ação do usuário.
Cenários:
Cadastrar Sprint - Principal
1. Sistema apresenta tela para cadastro da Sprint;
2. Scrum Master informa descrição da Sprint, data de início e data de finalização;
3. Scrum Master clica em inserir novo registro; e
4. Sistema salva informações no banco de dados.
Campos Obrigatórios – Exceção
Campos obrigatórios não preenchidos, no passo 3 do caso de uso Cadastrar Sprint:
1. Sistema exibe mensagem "Favor preencher todos os campos obrigatórios" e retorna ao
passo 1.
103
Data de finalização menor que a data de início – Exceção
Caso o usuário informe uma data de finalização menor que a data de início, no passo 3 do
caso de uso Cadastrar Sprint:
1. Sistema apresenta a mensagem "A data de finalização deve ser maior que a data de
início" e retorna ao passo 1.
Data de término maior que a data de término do projeto – Exceção
Caso o usuário informe uma data de finalização para a Sprint maior que data de término do
projeto, no passo 3 do caso de uso Cadastrar Sprint:
1. Sistema apresenta a mensagem "A data de finalização da Sprint deve ser menor que a
data de término do projeto" e retorna ao passo 1.
Adicionar Stories – Principal
1. Scrum Master seleciona uma Sprint;
2. Scrum Master apresenta tela com as Stories disponíveis;
3. Scrum Master seleciona as Stories que deseja incluir na Sprint;
4. Scrum Master clica em gravar;
5. Sistema salva informações no banco de dados.
Alterar Sprint – Alternativo
1. Sistema apresenta tela para cadastro de Sprint Backlog;
2. Scrum Master altera os campos que necessita;
3. Scrum Master clica em atualizar;
4. Sistema salva informações no banco de dados.
104
Excluir Sprint – Alternativo
1. Sistema apresenta listagem das Sprints cadastradas no projeto;
2. Scrum Master clica em excluir; e
3. Sistema exclui Sprint do banco de dados.
Sprint com Stories alocadas – Exceção
Caso a Sprint possua Stories associadas a ela, no passo 2 do cenário Excluir Sprint:
1. Sistema apresenta exibe a mensagem: “Esta Sprint possui Stories associadas”; e
2. Sistema não exclui Sprint do banco de dados.
Sprint finalizada – Exceção
Caso a Sprint esteja finalizada, no passo 2 do cenário Excluir Sprint:
1. Sistema apresenta exibe a mensagem: “Não é possível excluir uma Sprint finalizada; e
2. Sistema não exclui Sprint do banco de dados.
UC 04.02 Manter Reunião de Planejamento
Permite ao Scrum Master a inclusão de informações sobre a reunião de planejamento da
Sprint.
Requisitos:
• RF 04.02: O sistema deverá permitir ao Scrum Master inserir informações sobre a
reunião de planejamento; e
• RN 03.06: O cadastro da Reunião de Planejamento deverá obrigatoriamente possuir a
seguinte informação: descrição.
Condições:
• Pré-condição: um projeto deve ter sido selecionado;
• Pré-condição: o usuário deverá estar autenticado no sistema;
• Pré-condição: uma Sprint deve estar cadastrada; e
105
• Pós-condição: reunião de planejamento informada.
Cenários:
Cadastrar Reunião de Planejamento – Principal
1. Sistema mostra tela Reunião de Planejamento;
2. Scrum Master informa os dados da reunião;
3. Sistema grava as informações no banco de dados.
Campos Obrigatórios – Exceção
Campos obrigatórios não preenchidos, no passo 3 do caso de uso Cadastrar Reunião de
Planejamento:
1. Sistema exibe mensagem "Favor preencher todos os campos obrigatórios" e retorna ao
passo 1.
UC 04.03 Gerenciar Reunião Diária
Permite ao Scrum Master a inclusão de informações sobre a reunião diária da Sprint.
Requisitos:
• RF 04.03: O sistema deverá permitir ao Scrum Master e Scrum Team inserir
informações sobre a reunião diária; e
• 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.
Condições:
• Pré-condição: um projeto deve ter sido selecionado;
• Pré-condição: o usuário deverá estar autenticado no sistema;
• Pré-condição: uma Sprint deve estar cadastrada; e
• Pós-condição: Reunião Diária cadastrada.
106
Cenários:
Cadastrar Reunião Diária – Principal
1. Sistema mostra a tela Reunião Diária;
2. Usuário informa os dados da reunião;
3. Sistema grava as informações no banco de dados.
Campos Obrigatórios – Exceção
Campos obrigatórios não preenchidos, no passo 3 do caso de uso Cadastrar Reunião Diária:
1. Sistema exibe mensagem "Favor preencher todos os campos obrigatórios" e retorna ao
passo 1.
UC 04.04 Manter Reunião de Revisão
Permite ao Scrum Master a inclusão de informações sobre a reunião de revisão da Sprint.
Requisitos:
• RF 04.04: O sistema deverá permitir a todos os papéis inserir informações sobre a
reunião revisão em cada Sprint; e
• RN 03.08: O cadastro da Reunião de Revisão deverá obrigatoriamente possuir a seguinte
informação: descrição.
Condições:
• Pré-condição: um projeto deve ter sido selecionado;
• Pré-condição: o usuário deverá estar autenticado no sistema;
• Pré-condição: uma Sprint deve estar cadastrada; e
• Pós-condição: Reunião de Revisão cadastrada.
107
Cenários:
Cadastrar Reunião de Revisão – Principal
1. Sistema mostra a tela Reunião de Revisão;
2. Usuário informa os dados da reunião;
3. Sistema grava as informações no banco de dados.
Campos Obrigatórios – Exceção
Campos obrigatórios não preenchidos, no passo 3 do caso de uso Cadastrar Reunião de
Revisão:
1. Sistema exibe mensagem "Favor preencher todos os campos obrigatórios" e retorna ao
passo 1.
UC 04.05 Manter Reunião de Retrospectiva
Permite aos usuários informar fatos ocorridos no desenvolvimento da Sprint.
Requisito:
• 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; e
• RN 03.09: O cadastro da Reunião de Retrospectiva deverá obrigatoriamente possuir a
seguinte informação: descrição.
Condições:
• Pré-condição: um projeto deve ter sido selecionado;
• Pré-condição: o usuário deverá estar autenticado no sistema;
• Pré-condição: uma Sprint deve estar cadastrada; e
• Pós-condição: Reunião de Revisão cadastrada.
108
Cenários:
Cadastrar Reunião de Revisão – Principal
1. Sistema mostra a tela Reunião de Retrospectiva;
2. Usuário informa os dados da reunião;
3. Sistema grava as informações no banco de dados.
Campos Obrigatórios – Exceção
Campos obrigatórios não preenchidos, no passo 3 do caso de uso Cadastrar Reunião de
Revisão:
1. Sistema exibe mensagem "Favor preencher todos os campos obrigatórios" e retorna ao
passo 1.
UC 04.06 Visualizar Sprint Burndown
Permite a todos os papéis acompanhar o andamento da Sprint de forma gráfica.
Requisitos:
• RF 04.06: O sistema deverá permitir a todos os papéis visualizar o gráfico Sprint Burndown;
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
Condições:
• Pré-condição: um projeto deverá ser selecionado;
• Pré-condição: o usuário deverá estar autenticado no sistema;
• Pré-condição: uma Sprint deve estar cadastrada;
• Pré-condição: deve haver estórias alocadas na Sprint;
109
• Pré-condição: deve haver tarefas associadas às estórias que estão alocadas na Sprint; e
• Pós-condição: o gráfico é apresentado na tela.
Cenários:
Visualizar Gráfico – Principal
1. Usuário seleciona uma Sprint;
2. Usuário clica na opção visualizar gráfico;
3. Sistema mostra gráfico Sprint Burndown.
Dados Insuficientes – Exceção
No passo 3, do cenário Visualizar Gráfico, não há informações suficientes para gerar o
gráfico:
1. Sistema exibe a mensagem “Informações insuficientes”.
A.5 MÓDULO TAREFA
Esta seção representa todas as interações relacionadas às operações de cadastro, exclusão e
alteração de tarefas bem como o cadastro de horas trabalhadas e impedimentos.
UC 05.01 Manter Tarefas
Permite ao Scrum Team cadastrar, alterar ou excluir tarefas para uma Story. Nesta tela deve-
se informar o nome da tarefa, descrição e estimativa (em horas).
Requisitos:
• RF 05.01: O sistema deverá permitir ao Scrum Team cadastrar, alterar e excluir tarefas
para um Backlog Item;
• RF 05.03: O sistema deverá permitir ao Scrum Team informar o tempo de duração de
cada tarefa;
• RN 04.01: Uma Tarefa deverá obrigatoriamente possuir as seguintes informações: nome,
descrição e estimativa;
110
• 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; e
• RN 04.05: Uma tarefa iniciada pode ser alterada somente pelo usuário que está a
desenvolvendo.
Condições:
• Pré-condição: um projeto deve ter sido selecionado;
• Pré-condição: o usuário deverá estar autenticado no sistema;
• Pré-condição: uma Sprint deve estar cadastrada;
• Pré-condição: uma Estória deve estar cadastrada; e
• Pós-condição: tarefa cadastrada, alterada ou excluída dependendo da ação do usuário.
Cenários:
Cadastrar Tarefa - Principal
1. Sistema apresenta tela para cadastro de nova tarefa;
2. Usuário preenche os campos solicitados;
3. Usuário clica em inserir novo registro;
4. Sistema verifica se os dados obrigatórios foram informados; e
5. Sistema salva informações no banco de dados.
Dados obrigatórios não informados – Exceção
Caso o usuário não informe um dado obrigatório, no passo 2 do cenário Cadastrar Tarefa:
1. Sistema mostra a mensagem “Favor informar preencher os campos obrigatórios”; e
2. Sistema somente salva informação no banco de dados após campo ser informado.
111
Alterar Tarefa – Alternativo
1. Sistema apresenta tela para edição de tarefas;
2. Usuário altera os campos que necessita;
3. Usuário clica em gravar; e
4. Sistema salva informações no banco de dados.
Tarefa alocada para outro usuário – Exceção
Caso a tarefa esteja alocada para outro usuário, no passo 3 do cenário Alterar Tarefa:
1. Sistema exibe mensagem "Não é possível alterar tarefas alocadas para outros usuários" e
retorna ao passo 1.
Excluir Tarefa – Alternativo
1. Sistema apresenta listagem das tarefas cadastradas;
2. Usuário clica em Excluir; e
3. Sistema exclui tarefa do banco de dados.
Tarefa Finalizada – Exceção
Caso a tarefa esteja finalizada, no passo 3 do cenário Alterar Tarefa ou no passo 2 do
cenário Excluir Tarefa:
1. Sistema exibe mensagem "Esta tarefa está finalizada" e retorna ao passo 1.
Tarefa Iniciada – Exceção
Caso a tarefa esteja iniciada, no passo 2 do cenário Excluir Tarefa:
1. Sistema exibe mensagem "Esta tarefa está iniciada" e retorna ao passo 1.
UC 05.02 Alocar Tarefa
Permite alocar uma tarefa a um membro do time do projeto.
112
Requisitos:
• RF 05.02: O sistema deverá permitir ao Scrum Team a alocação de tarefas; e
• RN 04.06: Somente tarefas com status A Fazer podem ser alocadas.
Condições:
• Pré-condição: um projeto deve ter sido selecionado;
• Pré-condição: o usuário deverá estar autenticado no sistema;
• Pré-condição: uma Sprint deve estar cadastrada;
• Pré-condição: uma Estória deve estar cadastrada;
• Pré-condição: uma Tarefa deve estar cadastrada; e
• Pós-condição: tarefa alocada a um membro do time do projeto.
Cenários:
Alocar Tarefa - Principal
1. Sistema apresenta tela para edição de tarefa;
2. Usuário altera o status da tarefa para Em Desenvolvimento;
3. Usuário clica em Gravar;
4. Sistema aloca tarefa para o usuário que realizou a alteração do status e grava a
informação no banco de dados.
Tarefa com status diferente de A Fazer – Exceção
Caso status da tarefa seja diferente de A Fazer, no passo 3 do caso de uso Alocar Tarefa:
1. Sistema exibe mensagem "Somente tarefas com status A Fazer podem ser alocadas" e
retorna ao passo 1.
UC 05.03 Gerenciar Horas Trabalhadas
Permite ao usuário informar a quantidade de horas trabalhadas na tarefa.
113
Requisitos:
• RF 05.06: O sistema deverá permitir ao Scrum Team informar o tempo gasto em cada
tarefa; e
• RN 04.08: Somente poderá ser informado o número de horas trabalhadas em uma tarefa
com status Em Desenvolvimento ou Finalizada.
Condições:
• Pré-condição: um projeto deve ter sido selecionado;
• Pré-condição: o usuário deverá estar autenticado no sistema;
• Pré-condição: uma Sprint deve estar cadastrada;
• Pré-condição: uma Estória deve estar cadastrada;
• Pré-condição: uma Tarefa deve estar cadastrada; e
• Pós-condição: registro de horas informado para a tarefa.
Cenários:
Informar Horas Trabalhadas - Principal
1. Sistema apresenta tela para edição de tarefa;
2. Usuário altera a quantidade de horas trabalhadas;
3. Usuário clica em Gravar
4. Sistema grava a informação no banco de dados.
Status Não Permite Registro de Horas – Exceção
Caso o status da tarefa seja diferente de Em Desenvolvimento ou Finalizada, no passo 3 do
cenário Informar Horas Trabalhadas:
1. Sistema exibe a mensagem "Somente pode ser informado o número de horas trabalhadas
para tarefas em desenvolvimento ou finalizadas" e retorna ao passo 1.
114
UC 05.04 Informar Status da Tarefa
Permite ao usuário informar o status de andamento da tarefa entre as seguintes opções: A
Fazer (To Do), Em Desenvolvimento (In Development), Impedida (Impeded), Finalizada (Finished)
e Cancelada (Canceled).
Requisitos:
• RF 05.04: O sistema deverá permitir ao Scrum Team alterar o status de andamento da
tarefa;
• RN 04.04: Uma tarefa pode assumir os seguintes estados: A Fazer, Em
Desenvolvimento, Impedida, Cancelada e Finalizada; e
• RN 04.05: Uma tarefa iniciada pode ser alterada somente pelo usuário que está a
desenvolvendo.
Condições:
• Pré-condição: um projeto deve ter sido selecionado;
• Pré-condição: o usuário deverá estar autenticado no sistema;
• Pré-condição: uma Sprint deve estar cadastrada;
• Pré-condição: uma Estória deve estar cadastrada;
• Pré-condição: uma Tarefa deve estar cadastrada; e
• Pós-condição: status da tarefa alterado.
Cenários:
Alterar Status - Principal
1. Sistema apresenta tela para edição de tarefa;
2. Usuário altera o status da tarefa;
3. Usuário clica em Gravar
4. Sistema grava a informação no banco de dados.
115
Tarefa Alocada para Outro Usuário – Exceção
Caso a tarefa esteja alocada para outro usuário, no passo 2 do cenário Alterar Status:
1. Sistema exibe a mensagem "Tarefa alocada para outro usuário" e retorna ao passo 1.
UC 05.05 Gerenciar Impedimentos
Permite ao Scrum Team cadastrar um impedimento para uma tarefa. O impedimento
representa alguma questão que não permite o andamento natural de uma tarefa.
Requisitos:
• RF 05.05: O sistema deverá permitir ao Scrum Team associar um impedimento à tarefa; e
• RN 04.07: Não pode ser cadastrado impedimento para uma tarefa A Fazer, Concluída ou
Cancelada.
Condições:
• Pré-condição: um projeto deve ter sido selecionado;
• Pré-condição: o usuário deverá estar autenticado no sistema;
• Pré-condição: uma Sprint deve estar cadastrada;
• Pré-condição: uma Estória deve estar cadastrada;
• Pré-condição: uma Tarefa deve estar cadastrada; e
• Pós-condição: o impedimento é cadastrado e associado à tarefa.
Cenários:
Cadastrar Impedimento – Principal
1. Sistema apresenta listagem com as tarefas da Sprint;
2. Usuário seleciona Cadastrar Impedimento de uma tarefa;
3. Sistema apresenta tela com campo para descrição;
4. Usuário preenche as informações e seleciona Gravar;
116
5. Sistema grava o impedimento e o associa à tarefa.
Tarefa não está em desenvolvimento – Exceção
Caso o status da tarefa seja diferente de Em Desenvolvimento, no passo 4 do cenário
Cadastrar Impedimento:
1. Sistema exibe a mensagem "Somente pode ser associado um impedimento a uma tarefa
em desenvolvimento" e retorna ao passo 1.
A.6 MÓDULO PLANNING POKER
O módulo Planning Poker representa todas as interações realizadas durante o jogo em que
são estimadas as complexidades dos itens do Product Backlog.
UC 05.01 Definir a Complexidade
Permite ao Scrum Master selecionar a complexidade do item do Product Backlog de acordo
com os valores selecionados pela equipe.
Requisitos:
• RF 06.05: O sistema deverá permitir ao Scrum Master definir a complexidade final do
Backlog Item selecionando entre um dos valores estimados pelo time;
• 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; e
• RN 05.05: O Scrum Master poderá definir a estimativa final da estória apenas uma vez.
Condições:
• Pré-condição: um projeto deve ter sido selecionado;
• Pré-condição: o usuário deverá estar autenticado no sistema;
• Pré-condição: uma Estória deve estar cadastrada;
• Pré-condição: uma Sessão deve estar cadastrada;
117
• Pós-condição: o valor da complexidade do item do Product Backlog é definido.
Cenários:
Definir a Complexidade – Principal
1. Scrum Master acessa o Planning Poker;
2. Sistema apresenta tela com as sessões cadastradas;
3. Scrum Master seleciona uma sessão;
4. Sistema apresenta os itens de Backlog selecionados para a sessão;
5. Scrum Master seleciona um dos itens;
6. Sistema apresenta tela do Planning Poker e os valores escolhidos por cada integrante da
equipe;
7. Scrum Master seleciona a complexidade final de acordo com os valores apresentados;
8. Sistema informa que o valor selecionado foi definido como complexidade da estória.
Estória Estimada Anteriormente – Exceção
Caso a estória já tenha sido estimada, no passo 7 do caso de uso Definir a Complexidade:
1. Sistema apresenta a mensagem "Esta estória não pode mais ser estimada" e retorna ao
passo 6.
UC 06.02 Gerenciar a Sessão
Permite criar uma sessão de Planning Poker, informando data de início e término, para que
o Scrum Team possa estimar os itens do Backlog.
Requisitos:
• RF 06.01: O sistema deverá permitir ao Scrum Master criar uma sessão do Planning Poker;
• 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;
118
• RN 05.03: A data de término da sessão deve ser maior que a data de início;
• 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.
Condições:
• Pré-condição: um projeto deve ter sido selecionado;
• Pré-condição: o usuário deverá estar autenticado no sistema;
• Pré-condição: uma Estória deve estar cadastrada;
• Pós-condição: a sessão é cadastrada.
Cenários:
Cadastrar Sessão – Principal
1. Scrum Master seleciona Cadastrar Sessão;
2. Sistema apresenta tela para preenchimento das informações solicitadas;
3. Scrum Master preenche os dados solicitados;
4. Scrum Master selecionar Gravar Sessão;
5. Sistema grava as informações no banco de dados.
Dados Insuficientes – Exceção
No passo 4, do cenário Cadastrar Sessão, o sistema identifica que o Scrum Master não
preencheu todos os campos:
1. Sistema exibe a mensagem “Favor preencher todas as informações da sessão” e retorna
ao passo 2.
119
Data de finalização menor que a data de início – Exceção
Caso o usuário informe uma data de finalização menor que a data de início, no passo 3 do
caso de uso Cadastrar Sessão:
1. Sistema apresenta a mensagem "A data de finalização deve ser maior que a data de início"
e retorna ao passo 2.
Adicionar Estórias – Principal
1. Sistema apresenta listagem das sessões cadastradas;
2. Usuário seleciona uma sessão e clica em Adicionar Estórias;
3. Sistema apresenta listagem das estórias não estimadas e não incluídas em outra sessão;
4. Usuário seleciona as estórias que deseja incluir na sessão;
5. Usuário seleciona Gravar; e
6. Sistema grava as informações no banco de dados.
UC 06.03 Estimar Itens de uma Sessão
Permite ao Scrum Team estimar os itens de Backlog selecionados pelo Scrum Master.
Requisitos:
• RF 06.03: O sistema deverá possibilitar ao Scrum Team estimar a complexidade de cada
item do Product Backlog;
• RF 06.04: O sistema deverá possibilitar ao Scrum Master e Scrum Team acessar uma sessão
aberta;
• 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; e
• RN 05.04: O usuário poderá estimar cada estória apenas uma vez.
120
Condições:
• Pré-condição: o usuário deverá estar autenticado no sistema;
• Pré-condição: um projeto deve ter sido selecionado;
• Pré-condição: uma Sessão deve estar cadastrada;
• Pré-condição: estórias devem ter sido adicionadas à sessão;
• Pós-condição: um valor de complexidade será associado ao item.
Cenários:
Estimar Itens – Principal
1. Usuário acessa o Planning Poker;
2. Sistema apresenta as sessões cadastradas;
3. Usuário seleciona uma sessão;
4. Sistema apresenta os itens do Product Backlog selecionados para a sessão;
5. Usuário seleciona um item;
6. Sistema apresenta tela do Planning Poker;
7. Usuário seleciona uma carta;
8. Sistema confirma a operação.
Sessão Expirada – Exceção
Caso a sessão tenha sido finalizada, no passo 7 do caso de uso Estimar Itens:
1. Sistema apresenta a mensagem "Esta sessão está finalizada" e retorna ao passo 4.
121
Estória Estimada Anteriormente – Exceção
Caso a sessão já tenha sido estimada pelo usuário, no passo 7 do caso de uso Estimar Itens:
1. Sistema apresenta a mensagem "Não possível estimar esta estória novamente" e retorna ao
passo 4.
A.7 MÓDULO TASK BOARD
Este módulo foi criado para atender à outra necessidade proposta neste trabalho. O módulo
Task Board representa todas as interações realizadas através do quadro visual. Algumas operações
também são realizadas de forma cadastral, mas para representar as interações realizadas neste
módulo, decidiu-se repetir alguns casos de uso.
UC 07.01 Alocar Tarefa
Permite alocar uma tarefa para determinado usuário de forma visual através do Task Board.
Requisitos:
• RF 05.02: O sistema deverá permitir ao Scrum Team a alocação de tarefas;
• RNF07: O sistema deverá permitir ao Scrum Team realizar o gerenciamento das tarefas
através do Task Board; e
• RN 04.06: Somente tarefas com status A Fazer podem ser alocadas.
Condições:
• Pré-condição: o usuário deverá estar autenticado no sistema;
• Pré-condição: um projeto deve ter sido selecionado;
• Pré-condição: uma Sprint deve estar cadastrada;
• Pré-condição: uma Estória deve estar cadastrada;
• Pré-condição: uma Tarefa deve estar cadastrada;
• Pós-Condição: a tarefa é alocada ao usuário.
122
Cenários:
Alocar Tarefa – Principal
1. Usuário seleciona visualizar Task Board;
2. Sistema apresenta o quadro com os itens de Backlog e as tarefas;
3. Usuário seleciona move uma tarefa para a coluna Em Andamento;
4. Sistema associa a tarefa com o usuário e grava as informações no banco de dados;
Tarefa Alocada para Outro Usuário – Exceção
Caso a tarefa possua status diferente de A Fazer, no passo 3 do cenário Alocar Tarefa:
1. Sistema exibe a mensagem "Esta tarefa está iniciada e alocada a outro usuário" e retorna
ao passo 2.
UC 07.02 Alterar Status
Permite alterar o status da tarefa de forma visual através do Task Board.
Requisitos:
• RF 05.04: O sistema deverá permitir ao Scrum Team alterar o status de andamento da tarefa;
• RNF07: O sistema deverá permitir ao Scrum Team realizar o gerenciamento das tarefas
através do Task Board;
• RN 04.02: Uma tarefa finalizada não pode ser alterada, excluída ou cancelada;
• RN 04.04: Uma tarefa pode assumir os seguintes estados: A Fazer, Em Desenvolvimento,
Impedida, Cancelada e Finalizada; e
• RN 04.05: Uma tarefa iniciada pode ser alterada somente pelo usuário que está a
desenvolvendo.
123
Condições:
• Pré-condição: o usuário deverá estar autenticado no sistema;
• Pré-condição: um projeto deve ter sido selecionado;
• Pré-condição: uma Sprint deve estar cadastrada;
• Pré-condição: uma Estória deve estar cadastrada;
• Pré-condição: uma Tarefa deve estar cadastrada;
• Pós-Condição: o status da tarefa é alterado.
Cenários:
Alterar Status – Principal
1. Usuário seleciona visualizar Task Board;
2. Sistema apresenta o quadro com os itens de Backlog e as tarefas;
3. Usuário seleciona move uma tarefa para outra coluna;
4. Sistema altera o status da tarefa de acordo com a coluna para a qual a tarefa foi movida.
Tarefa Alocada para Outro Usuário – Exceção
Tarefa está alocada para outro usuário, no passo 3 do cenário Alterar Status:
1. Sistema exibe a mensagem "Está tarefa está alocada para outro usuário" e retorna ao
passo 2.
Tarefa Finalizada – Exceção
Caso a tarefa esteja finalizada, no passo 3 do cenário Alterar Status:
1. Sistema exibe a mensagem "Não é possível mover uma tarefa finalizada" e retorna ao
passo 2.