FERRAMENTA WEB PARA GERENCIAMENTO DE PROJETOS DE SOFTWARE...

UNIVERSIDADE REGIONAL DE BLUMENAU

CENTRO DE CIÊNCIAS EXATAS E NATURAIS

CURSO DE CIÊNCIA DA COMPUTAÇÃO – BACHARELADO

FERRAMENTA WEB PARA GERENCIAMENTO DE

PROJETOS DE SOFTWARE BASEADO NO SCRUM

VANESSA DE MELLO

BLUMENAU 2010

2010/2-23

VANESSA DE MELLO



Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Ciência da Computação — Bacharelado.

Prof. Everaldo Artur Grahl - Orientador

BLUMENAU 2010

2010/2-23



Por

VANESSA DE MELLO

Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por:

______________________________________________________ Presidente: Prof. Everaldo Artur Grahl, Mestre - Orientador, FURB

______________________________________________________ Membro: Prof. Marcel Hugo – Mestre, FURB

______________________________________________________ Membro: Prof. Wilson Pedro Carli – Mestre, FURB

Blumenau, 5 de julho de 2010

Dedico este trabalho a todos que de alguma forma me apoiaram e acreditaram em mim durante o desenvolvimento do mesmo.

AGRADECIMENTOS

À minha família, que sempre investiu no meu conhecimento. Pela paciência, incentivo

e dedicação em todos os momentos.

Ao meu noivo, Ronaldo, pela ajuda, compreensão, paciência e incentivo.

Principalmente por sempre ter acreditado em mim.

Aos meus amigos, pela confiança e companheirismo.

Ao meu orientador, Everaldo, pela confiança e compreensão.

A Fácil Informática, por todo apoio e incentivo.

Pedras no caminho? Guardo todas, um dia vou construir um castelo...

Fernando Pessoa

RESUMO

O objetivo deste trabalho é o desenvolvimento de uma ferramenta web para gerenciar projetos de software baseado na metodologia ágil Scrum. Para isso, foi realizado um estudo destes conceitos e práticas utilizados nesta metodologia. A ferramenta foi desenvolvida na linguagem C# e permite o uso dos principais artefatos existentes no Scrum, tais como sprint, sprint backlog, product backlog, reunião diária, reunião de retrospectiva e reunião de revisão. Para o desenvolvimento do sistema foram utilizadas as tecnologias Silverlight, Microsoft Blend e MySql.

Palavras-chave: Gerência de projetos. Metodologia ágil. Scrum.

ABSTRACT

The objective is to develop a web tool for managing software projects based on Agile Scrum. For this, a study of these concepts and practices used in this methodology. The tool was developed in C # and allows the use of major existing Scrum artifacts such as sprint, sprint backlog, product backlog, daily meeting, meeting and retrospective review meeting. For the development of system technologies were used Silverlight, Microsoft Blend and MySql.

Key-words: Project management. Agile methodology. Scrum.

LISTA DE ILUSTRAÇÕES

Quadro 1 – Comparativo entre as abordagens .......................................................................... 17

Figura 1 – Ciclos do Scrum ...................................................................................................... 18

Figura 2 – Gráfico de Burndown .............................................................................................. 26

Figura 3 – Tela principal da ferramenta ................................................................................... 27

Figura 4 – Tela principal da ferramenta Project Koach............................................................ 27

Figura 5 – Tela da ferramenta Mingle ...................................................................................... 28

Figura 6 – Tela da ferramenta Scrum Project ........................................................................... 29

Figura 7 – Diagrama de casos de uso administrativo ............................................................... 32

Figura 8 – Diagrama de casos de uso projetos ......................................................................... 32

Figura 9 – Diagrama de atividades ........................................................................................... 33

Figura 10 – Diagrama de classes .............................................................................................. 34

Figura 11 – Diagrama de entidade-relacionamento do banco de dados ................................... 35

Figura 12 – Ferramenta Expression Blend ............................................................................... 37

Figura 13 – Código fonte de envio de e-mail ........................................................................... 38

Figura 14 – Código fonte do cadastro de pessoas utilizando web service ................................ 39

Figura 15 – Parte da classe do web service .............................................................................. 39

Figura 16 – Tela de login .......................................................................................................... 40

Figura 17 - Cadastro de pessoas ............................................................................................... 40

Figura 18 - Cadastro de empresas ............................................................................................ 41

Figura 19 - Cadastro de projetos............................................................................................... 41

Figura 20 - Cadastro de times ................................................................................................... 42

Figura 21 - Cadastro de product backlog ................................................................................. 42

Figura 22 - Cadastro de sprints................................................................................................. 43

Figura 23 - Cadastro de sprint backlog .................................................................................... 43

Figura 24 - Cadastro de reuniões diárias .................................................................................. 44

Figura 25 - Cadastro de reunião de revisão .............................................................................. 44

Figura 26 - Cadastro de reunião de retrospectiva ..................................................................... 45

Figura 27 – Envio de e-mail ..................................................................................................... 45

Figura 28 – Tela do e-mail recebido ......................................................................................... 46

Figura 29 – Tarefas pendentes do dia ....................................................................................... 46

Figura 30 – Listagem para acompanhamento das tarefas ......................................................... 47

Figura 31 – Listagem de problemas encontrados ..................................................................... 47

Quadro 2 – Comparação entre as ferramentas .......................................................................... 48

Quadro 3 – UC6 – Cadastro de projetos ................................................................................... 54

Quadro 4 – UC9 – Cadastro de sprint backlog ......................................................................... 56

Quadro 5 – UC3 – Cadastro de product backlog...................................................................... 57

Quadro 6 – UC8 – Cadastro de sprints ..................................................................................... 58

Quadro 7 – UC7 - Cadastro de times ....................................................................................... 59

Quadro 8 – UC12 - Cadastro de reunião diária ....................................................................... 61

Quadro 9 – Dicionário de dados do diagrama de entidade relacionamento ............................. 65

LISTA DE SIGLAS

PHP - Personal Home Page

XML - eXtensible Markup Language

UML - Unified Modeling Language

SUMÁRIO

1 INTRODUÇÃO .................................................................................................................. 13

1.1 OBJETIVOS DO TRABALHO ........................................................................................ 14

1.2 ESTRUTURA DO TRABALHO ...................................................................................... 14

2 FUNDAMENTAÇÃO TEÓRICA .................................................................................... 15

2.1 GERÊNCIA DE PROJETOS ............................................................................................ 15

2.2 METODOLOGIAS ÁGEIS............................................................................................... 16

2.3 SCRUM ............................................................................................................................. 17

2.3.1 Papéis do Scrum .............................................................................................................. 19

2.3.1.1 Product Owner .............................................................................................................. 19

2.3.1.2 Scrum Master ................................................................................................................ 20

2.3.1.3 Scrum Team .................................................................................................................. 20

2.3.2 Artefatos do Scrum .......................................................................................................... 21

2.3.2.1 Product Backlog ............................................................................................................ 21

2.3.2.2 Sprint ............................................................................................................................. 21

2.3.2.2.1 Planejamento da Sprint ............................................................................................ 22

2.3.2.2.2 Reunião Diária ......................................................................................................... 23

2.3.2.2.3 Reunião de Revisão da Sprint .................................................................................. 24

2.3.2.2.4 Reunião de Retrospectiva da Sprint ......................................................................... 24

2.3.2.2.5 Gráfico de Burndown ............................................................................................... 25

2.4 TRABALHOS CORRELATOS ........................................................................................ 26

2.4.1 Ambiente web para gerenciamento de processo de software baseado no Scrum ........... 26

2.4.2 Project Koach .................................................................................................................. 27

2.4.3 Mingle ............................................................................................................................. 28

2.4.4 Scrum Project .................................................................................................................. 28

3 DESENVOLVIMENTO DA FERRAMENTA ............................................................... 30

3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO ....................... 30

3.2 ESPECIFICAÇÃO ............................................................................................................ 31

3.2.1 Diagrama de casos de uso ............................................................................................... 31

3.2.2 Diagrama de atividades ................................................................................................... 33

3.2.3 Diagrama de classes ........................................................................................................ 34

3.2.4 Diagrama de entidade-relacionamento ............................................................................ 35

3.3 IMPLEMENTAÇÃO ........................................................................................................ 36

3.3.1 Técnicas e ferramentas utilizadas.................................................................................... 36

3.3.1.1 Microsoft Expression Blend ......................................................................................... 36

3.3.1.2 Microsoft Silverlight ..................................................................................................... 37

3.3.1.3 Web services ................................................................................................................. 37

3.3.1.4 Código fonte ................................................................................................................. 38

3.3.2 Operacionalidade da implementação .............................................................................. 39

3.4 RESULTADOS E DISCUSSÃO ...................................................................................... 48

4 CONCLUSÕES .................................................................................................................. 50

REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................. 51

APÊNDICE A – Detalhamento dos casos de uso ................................................................. 53

APÊNDICE B – Dicionário de dados do diagrama de entidade-relacionamento ............ 62

13

1 INTRODUÇÃO

Segundo Santos (2008, p. 38), a atual competitividade e a necessidade de inovação faz

com que as empresas de software busquem uma nova abordagem de desenvolvimento e

gerenciamento de projetos. A melhor escolha é a utilização de um método que seja flexível,

permitindo as alterações necessárias durante o desenvolvimento do projeto. Diante desta

situação, uma alternativa é a adoção de um método ágil para o desenvolvimento e

gerenciamento de projetos, como o Scrum. Apesar de suas técnicas serem divulgadas e

discutidas nas comunidades de software, é raro encontrar referências que auxiliem os gerentes

de projeto na adoção deste método. Isso ocorre pela falta de informação adequada para o nível

gerencial, principalmente nas grandes empresas.

Barcaui (2004, p. 2) afirma que a taxa de sucesso em projetos de tecnologia de

informação ainda é baixa. De 600.000 projetos analisados, apenas 34% dos iniciados

obtiveram sucesso entre os anos de 2001 e 2003. A maior parte dos projetos estava de alguma

forma apresentando problemas relacionados a prazo, escopo ou orçamento.

Os Gerentes de Projeto que atuam na área de desenvolvimento de software freqüentemente se vêem diante do desafio de liderar projetos com ciclos de entrega agressivos, constante mudança de requisitos, novas tecnologias e sistemas de informação que cada vez mais suportam a tomada de decisão e os processos-chave de negócio das empresas. Em cenários como esses, uma abordagem adaptativa para o processo de desenvolvimento e gerenciamento de projetos se torna fundamental a fim de maximizar a produtividade e não comprometer a qualidade de produto final. (SANTOS, 2008, p. 38, grifo do autor).

Além do uso de um método ágil, o gerente de projetos necessita adotar alguma

ferramenta que facilite as atividades previstas no método. O mercado possui algumas

alternativas, porém, muitas focadas nos processos tradicionais e poucas especializadas para

Scrum.

A partir deste cenário, pretendeu-se criar uma ferramenta baseada no método ágil

Scrum, permitindo aos envolvidos no projeto um maior controle sobre o mesmo, incluindo o

registro das atividades realizadas.

14

1.1 OBJETIVOS DO TRABALHO

O objetivo deste trabalho foi desenvolver uma ferramenta web para gerenciamento de

projetos de software baseado no método ágil denominado Scrum.

Os objetivos específicos do trabalho são:

a) definir as atividades básicas necessárias para um projeto baseado no Scrum;

b) definir artefatos de gerência de projetos a serem usados na ferramenta.

1.2 ESTRUTURA DO TRABALHO

Além da introdução, o trabalho é composto por mais três capítulos. O segundo capítulo

apresenta a revisão bibliográfica abordando os temas de gerenciamento de projetos, junto com

algumas ferramentas com funcionalidades semelhantes à ferramenta desenvolvida. O terceiro

capítulo apresenta os requisitos do problema tratado no presente trabalho, assim como

especificações do software desenvolvido. O quarto capítulo apresenta as conclusões do

trabalho desenvolvido.

15

2 FUNDAMENTAÇÃO TEÓRICA

Nas seções a seguir, são detalhadas as razões e vantagens para a utilização de métodos

ágeis na gerência de projetos. Primeiramente é exposta a definição de gerência de projetos.

Em seguida, são apresentadas as definições de metodologia ágil e do método ágil Scrum. Por

fim, são expostas algumas ferramentas com funcionalidades similares ao da ferramenta

proposta.

2.1 GERÊNCIA DE PROJETOS

Conforme Heldman (2006, p. 6), “o gerenciamento de projetos consiste na aplicação

de conhecimentos, competências, ferramentas e técnicas às atividades do projeto, com vista ao

cumprimento dos requisitos em pauta.” Estas técnicas e ferramentas são utilizadas pelas

pessoas envolvidas em determinado projeto para acompanhar o andamento do mesmo,

garantindo o cumprimento dos requisitos levantados.

O gerenciamento de projetos abrange uma série de atividades, incluindo planejar, colocar em ação o plano do projeto e acompanhar o progresso e o desempenho. Dentre essas atividades também estão identificação dos requisitos, definição dos objetivos, avaliação das restrições e apreciação das necessidades e expectativas dos principais stakeholders. (HELDMAN, 2006, p. 6).

Segundo Aldabó (2001, p. 18), gerenciamento de projetos inclui o planejamento, a

programação e o controle das atividades para atingir os objetivos do projeto. Entre os

principais objetivos destacam-se estabelecer metas de desempenho, custo e tempo, mantendo

o escopo do projeto no nível correto. O escopo é a importância do trabalho a ser

desenvolvido.

O controle do projeto é exercido comparando o ponto onde se está, com onde deveria

estar. Desta maneira, tomam-se medidas para corrigir os desvios encontrados. É necessário

um plano para saber estas informações. Sem isso, não há a possibilidade de exercer o

controle. Conforme Aldabó (2001, p. 24), “o controle consiste em comparar o progresso com

o desempenho planejado e então corrigir os desvios.”

As empresas que adotam as práticas de gerenciamento de projetos se beneficiam e se tornam cada vez mais competitivas, se destacam no mercado e principalmente, demonstram para os seus clientes que estão organizadas de acordo com as práticas e metodologias reconhecidas internacionalmente para realizar projetos com qualidade,

16

cumprindo o que foi prometido, dentro do que foi orçado e de acordo com o tempo previsto. (VIEIRA, 2003, p. 18).

O sucesso do projeto está diretamente relacionado ao controle exercido por sua gestão.

Dela depende a otimização dos recursos disponíveis, impactando na produtividade e

qualidade do produto final.

2.2 METODOLOGIAS ÁGEIS

Segundo Souza Neto (2004, p. 26), profissionais da indústria de software estavam

desmotivados com os processos que existiam no ano de 2001 e partiram em busca de um novo

método. Este método deveria ser capaz de fazer com que as equipes de desenvolvimento

respondessem mais rapidamente as mudanças nos requisitos, e que os projetos fossem

desenvolvidos em menos tempo.

De acordo com Ambler (2003, p. 23), eles criaram um manifesto chamado Manifesto

for Agile Software Development. Dentre os valores deste manifesto, estavam a maior

interação entre a equipe do que mais processos e ferramentas, menos documentação e mais

software funcionando, maior interação com o cliente do que contratos e estar pronto para

responder as mudanças necessárias.

Conforme Cuellar e Augustine (2008, p. 79), os métodos ágeis fazem uma troca entre

os artefatos pesados por uma comunicação contínua, uma equipe bem formada e pelo

feedback. Para que os processos ágeis tenham sucesso, eles precisam de um fluxo contínuo de

entrega de software, feedback regular com todos os envolvidos no projeto, ciclos curtos de

desenvolvimento com a mesma duração e equipes bem coordenadas.

Os métodos de desenvolvimento ágil se adaptam as necessidades do software,

incluindo alterações constantes nos requisitos. Eles incentivam o trabalho em equipe,

considerando-a como um time. O plano principal são as pessoas, e não o processo em si

(MÜLLER, 2004, p. 16).

Metodologias ágeis dividem o desenvolvimento do software em iterações, buscando redução de riscos ao projeto. Ao final de cada iteração, uma versão funcional do produto, embora restrita em funcionalidades, é liberada ao cliente. As metodologias ágeis destacam aspectos humanos no desenvolvimento do projeto, promovendo interação na equipe de desenvolvimento e o relacionamento de cooperação com o cliente. Comunicação face-a-face é preferida à documentação compreensiva. (VASCO; VITHOFT; ESTANTE, 2004, p. 2).

17

Com a utilização das metodologias ágeis, o controle do projeto não fica centralizado

no gerente do projeto. Todos os envolvidos fazem parte, e atuam como equipe, para conseguir

atingir o mesmo objetivo: um produto com qualidade, que satisfaça ao cliente. Os custos e

prazos diminuem, e o projeto fica mais flexível para mudanças que possam ocorrer durante o

desenvolvimento.

O quadro 1 apresenta um comparativo entre a abordagem realizada do modo clássico e

do modo ágil, explicando a diferença entre os dois.

Processo definido (clássico) Processo Empírico (Ágil) Permite primeiro fazer uma especificação completa para depois construir o produto ou executar o serviço.

Raramente é possível fazer uma especificação inicial que seja detalhada e permaneça imutável.

No início do projeto é possível fazer estimativas com precisão razoável.

No início é praticamente impossível estimar o projeto. À medida que os dados empíricos emergirem vai ficando mais fácil planejar e estimar.

Fornece informação sobre o estado interno do processo.

Fornece informação apenas sobre uma parte do processo, que pode ser influenciada por ações de controle.

Promove um entendimento fundamental dos trabalhos internos do processo.

Trata o processo como uma “caixa preta”.

Requer um conhecimento abrangente e acurado sobre o processo.

Não requer um conhecimento detalhado; mas um certo resultado pode ser obtido em resposta a certas mudanças.

É possível identificar, definir, agendar e sequenciar todas as atividades de forma detalhada.

No início do projeto, não é possível identificar as atividades. São necessárias tarefas de adaptação dirigidas pelos ciclos de constrói-avalia-adapta.

Adaptações devido a mudanças não previstas são raras, e a taxa de mudanças é relativamente baixa.

A regra são adaptações criativas que ocorrem devido às mudanças não previstas. A taxa de mudanças é bastante alta.

É mais adequado para processos de baixa complexidade e bem compreendido.

Normalmente é a única alternativa para processos complexos ou pouco compreendidos.

Fonte: Martins (2007, p. 56). Quadro 1 – Comparativo entre as abordagens

2.3 SCRUM

O Scrum é um método ágil que se atém ao gerenciamento e o planejamento do projeto.

Nele destaca-se o desenvolvimento baseado em times (equipes) e sua simplicidade. Entre a

equipe, mesmo que pequena, deve haver uma grande interação (MÜLLER, 2004, p. 18).

De acordo com Rodrigues e Rost (2007), o nome Scrum surgiu do jogo de rugby, que é

um jogo semelhante ao futebol. No jogo, utilizam o Scrum para reposição da bola, ou depois

18

de penalidades e faltas. Basicamente os jogadores se reúnem, e tentam ganhar a bola

trabalhando em equipe.

O Scrum foi implementado por Jeff Sutherland, John Scumniotales e Jeff McKenna em

1993, na empresa Easel Corporation. Em 1995, sua definição foi formalizada e implantada

nas empresas de software por Ken Schwaber. O Scrum utiliza métodos de gerenciamento

observados por Ikujiro Nonaka e Hirotaka Takeuchi. Eles defendem a idéia de que a equipe

deve trabalhar como uma unidade para atingir seus objetivos (SCRUM, 2008).

O Scrum parte do princípio que nem todas as características do software são

conhecidas na etapa de análise, e que os requisitos serão alterados durante a implementação.

Suas principais atividades são a inspeção e adaptação. O gerente de projetos tem que

inspecionar a execução diariamente, realizando alterações com o passar do tempo caso

necessário (CRUZ, 2008).

Müller (2004, p. 27) afirma que ao contrário dos processos tradicionais, no Scrum os

requisitos não precisam ser levantados no início do projeto, eles serão definidos com sua

evolução. Novas tarefas são definidas através de reuniões diárias. Estas reuniões servem para

identificar problemas referentes ao andamento do projeto o mais breve possível, para logo ter

uma solução. Com esta prática, diminui as consequências deste problema e evita danos

maiores ao projeto.

Na figura 1 é apresentado o funcionamento do ciclo do Scrum.

Fonte: Müller (2004, p. 32). Figura 1 – Ciclos do Scrum

O Scrum é baseado em Sprints, que são períodos, neste exemplo de 30 dias, nos quais

19

se trabalha para alcançar os objetivos bem definidos. Os objetivos são representados numa

lista de tarefas, denominada Product Backlog. Esta lista deve ser constantemente atualizada,

de acordo com as prioridades do projeto (SANCHES, 2007).

As principais características do Scrum são (SCRUM, 2008):

a) cada sprint é uma iteração do ciclo, e entrega uma parte do software pronto;

b) um backlog é um conjunto de requisitos, determinado e priorizado pelo Product

Owner;

c) há entrega de alguns itens do backlog em determinadas sprints;

d) diariamente ocorre uma breve reunião, onde todos os envolvidos falam sobre o

progresso da tarefa, a tarefa que irá fazer ou se tem algum problema impedindo de

prosseguir determinada tarefa;

e) uma sessão breve de planejamento, onde são definidos os backlogs de uma sprint;

f) um feedback, onde todos refletem sobre a sprint passada.

2.3.1 Papéis do Scrum

O Scrum trabalha com basicamente três papéis: Product Owner, Scrum Master e

Scrum Team.

2.3.1.1 Product Owner

Martins (2007, p. 255) afirma que o Product Owner é o dono do produto. É

responsável por representar o interesse de todas as pessoas envolvidas no projeto.

As principais responsabilidades do Product Owner são (SCRUM, 2008):

a) definir as funcionalidades do produto;

b) decidir a data de liberação e conteúdo de cada liberação;

c) responder pela rentabilidade do produto;

d) priorizar as funcionalidades levantadas;

e) ajustar funcionalidades e prioridades a cada sprint;

f) aceitar ou rejeitar resultados.

20

2.3.1.2 Scrum Master

O Scrum Master tem o papel de líder facilitador que gerencia os processos.

Normalmente é desempenhado por um gerente de projetos, ou um líder técnico, mas pode ser

qualquer pessoa (SCRUM, 2008). Entre as principais responsabilidades do Scrum Master

estão:

a) esclarecer o andamento do projeto;

b) difundir os valores do Scrum e suas práticas entre a equipe;

c) garantir as reuniões diárias;

d) remover obstáculos eventualmente encontrados;

e) proteger a equipe contra interferências internas;

f) conduzir os eventos realizados;

g) garantir a produtividade da equipe;

h) possibilitar uma cooperação estreita entre todos os papéis e funções.

2.3.1.3 Scrum Team

Conforme Müller (2004, p. 20), é o grupo de pessoas responsável por desenvolver o

software. Eles se organizam internamente para distribuir as tarefas entre seus membros e

mostrar os resultados alcançados. As principais características do Scrum Team são:

a) é multifuncional;

b) tem a liberdade de fazer qualquer coisa dentro das diretrizes do projeto para

alcançar os objetivos da sprint;

c) deve se auto organizar e organizar suas atividades;

d) apresenta os resultados do trabalho ao Product Owner;

e) não possuem nenhum dos papéis tradicionais da engenharia de software. Todos no

projeto trabalham juntos para finalizar a lista de atividades que eles se

comprometem a realizar.

21

2.3.2 Artefatos do Scrum

De acordo com Martins (2007, p. 278), o Scrum oferece um conjunto de artefatos que

mantém tudo claro. Isto permite que toda a equipe possa saber o que está acontecendo e

tomem as decisões necessárias para direcionar o projeto para seu rumo. Nas próximas seções

estão descritos alguns desses artefatos.

2.3.2.1 Product Backlog

Product Backlog é a lista principal de todas as funcionalidades desejadas no produto,

ou seja, é a lista inicial de requisitos. Essa lista pode ser ajustada durante o projeto pelo

Product Owner, a fim de mudar a sequência em que os itens serão realizados, adicionar ou

remover itens. Os requisitos não necessitam ser precisos nem estarem descritos de forma

completa e detalhada (SCRUM, 2008).

2.3.2.2 Sprint

De acordo com Rodrigues e Rost (2007), o Scrum trabalha com desenvolvimento

incremental, onde cada iteração é chamada de sprint. As sprints são curtas, e sua duração

depende da complexidade do produto e possuem um objetivo claro e definido, conhecido por

toda a equipe.

Ao final de cada sprint a equipe deve liberar uma versão do produto que possa ser

distribuída para o cliente. Durante sua execução são realizadas tarefas para garantir que essa

meta seja alcançada (MÜLLER, 2004, p. 29).

Conforme Martins (2007, p. 262), as principais características do sprint são:

a) o Scrum Team se compromete com os itens do product backlog durante a reunião

de planejamento da sprint. E esses itens não poderão ser alterados até o fim da

sprint;

b) caso seja verificado que a sprint seja inviável ou infactível, o Scrum Master poderá

realizar o encerramento anormal da sprint e iniciar uma nova reunião de

planejamento;

22

c) caso o Scrum Team perceba que não conseguirá finalizar os itens do product

backlog com os quais se comprometeu, ele poderá consultar o Product Owner

sobre quais itens poderiam ser removidos. Se forem muitos itens, que possam

comprometer a sprint, o Scrum Master pode encerrar anormalmente o mesmo;

d) caso o Scrum Team perceba que ela pode trabalhar em mais itens do que os

selecionados, pode consultar o Product Owner para identificar mais alguns itens

que possam ser adicionados na sprint;

e) durante a sprint, o Scrum Team pode procurar por ajuda externa, para

aconselhamento, informação e suporte;

f) o Scrum Team gerencia a si próprio. Nenhuma pessoa externa pode forçar um

direcionamento, dar instruções ou aconselhamentos a menos que seja solicitada;

g) o Scrum Team possui duas responsabilidades administrativas durante a sprint:

participar das reuniões diárias e manter o sprint backlog atualizado num diretório

onde todos do projeto possam ter acesso. Novas tarefas podem ser adicionadas ao

sprint backlog se for necessário, desde que as estimativas de quanto faltam sejam

sempre atualizadas.

2.3.2.2.1 Planejamento da Sprint

A Sprint inicia com uma reunião de planejamento de Sprint, onde o Product Owner

indica para o Scrum Team quais as prioridades e este decide o quanto pode ser feito no

próximo Sprint de acordo com a priorização do Product Backlog. Dessa reunião é gerado o

Sprint Backlog (PEREIRA, 2005, p. 21).

De acordo com Kniberg (2007, p. 25), o planejamento de sprint é uma reunião crítica,

um dos eventos mais importantes no Scrum. Um planejamento de sprint mal feito pode causar

problemas futuros na sprint. O propósito da reunião de planejamento é dar à equipe

informação suficiente para trabalharem em paz por algumas semanas, e para dar ao product

owner confiança suficiente para deixá-los fazerem isto.

Para Martins (2007, p. 266), as principais características da reunião de planejamento

são:

a) os participantes são: o Product Owner, o Scrum Master e o Scrum Team. Outras

pessoas convidadas por esses membros podem participar da reunião para fornecer

informações adicionais, tais como quanto ao domínio do negócio quanto

23

tecnologia, mas as mesmas devem se retirar após passar as informações;

b) o Product Owner precisa preparar o product backlog antes da reunião;

c) o objetivo da primeira metade da reunião, é o Scrum Team selecionar os itens que

ele acredita que poderá transformar num incremento de funcionalidade do produto.

Estas funcionalidades deverão ser demonstradas ao final do sprint, na reunião de

revisão;

d) o Scrum Team poderá dar sugestões, mas é o Product Owner que decide quais

itens serão incluídos no backlog;

e) o Product Owner deverá estar disponível para que o Scrum Team possa esclarecer

qualquer dúvida sobre os itens do backlog;

f) depende somente do Scrum Team planejar como irá converter os itens

selecionados num incremento de funcionalidade ao produto;

g) o resultado da segunda parte da reunião é a lista de itens que serão trabalhados na

sprint, chamado Sprint Backlog. A lista de tarefas pode não estar totalmente

completa, mas deve ser completa o suficiente para refletir o compromisso dos

membros da equipe.

2.3.2.2.2 Reunião Diária

Todos os dias da sprint, o Scrum Team realiza reuniões diárias. Essas reuniões

geralmente são realizadas no mesmo local e horário todos os dias. O ideal é que sejam

realizadas pela manhã, uma vez que apóia a determinar as atividades do dia (SCRUM, 2008).

Segundo Martins (2007, p. 274), as principais características da reunião diária são:

a) todos os membros da equipe devem participar. Caso a pessoa não possa

comparecer pessoalmente, pode participar por telefone, ou deixar informações com

outros membros da equipe;

b) todos os participantes devem ser pontuais. O Scrum Master deverá começar a

reunião na hora marcada, mesmo que algumas das pessoas estejam atrasadas;

c) cada pessoa deve responder a três perguntas: o que você fez desde a última

reunião, o que você fará até a próxima reunião e se existe algum problema que

esteja impedindo;

d) o Scrum Master é responsável por garantir o progresso da reunião e evitar os

desvios de assunto.

24

2.3.2.2.3 Reunião de Revisão da Sprint

Após o final da Sprint, é realizada uma reunião de revisão da Sprint. Todos os

interessados no projeto participam desta reunião, incluindo o Product Owner e outros

stakeholders. Esta reunião informal serve para demonstrar as novas funcionalidades do

software (PEREIRA, 2005, p. 21).

Para Martins (2007, p. 276), a reunião de revisão pode ser resumida nas seguintes

características:

a) o Scrum Team não deve gastar mais que uma hora para se preparar para a reunião;

b) a finalidade da reunião é permitir que o Scrum Team apresente ao Product Owner

e aos envolvidos no projeto , as funcionalidades que foram feitas;

c) a funcionalidade deve ser demonstrada num ambiente de homologação;

d) a reunião começa com o Scrum Team apresentando os objetivos da sprint, o

backlog com o qual se comprometeu e os itens que foram realizados;

e) ao final da apresentação, os envolvidos no projeto são questionados sobre suas

opiniões referentes as funcionalidades demonstradas, assim como podem

identificar quais das funcionalidades não foram realizadas.

De acordo com Kniberg (2007, p.76), a realização da reunião de revisão pode trazer

vários efeitos positivos para a equipe, tais como:

a) ganhar créditos para suas realizações;

b) outras pessoas tem conhecimento do que a equipe estava fazendo;

c) equipes diferentes podem interagir umas com as outras e discutir seu trabalho;

d) força a equipe a terminar suas tarefas e liberá-las.

2.3.2.2.4 Reunião de Retrospectiva da Sprint

Por fim, após a reunião de revisão do Sprint e antes da próxima reunião de

planejamento de Sprint, o Scrum Master realiza uma reunião de retrospectiva do Sprint com o

Scrum Team. Nessa reunião o Scrum Master encoraja o Scrum Team a revisar as técnicas

utilizadas, com as práticas do Scrum (PEREIRA, 2005, p. 21).

De acordo com Kniberg (2007, p. 79), a reunião de retrospectiva é o segundo evento

mais importante no Scrum, pois essa é a melhor chance de melhorar. Sem retrospectivas, você

25

descobrirá que a equipe continua a cometer os mesmos erros repetidamente. Uma

retrospectiva de sprint não diz respeito a apenas como uma única equipe pode fazer um bom

trabalho para o próximo sprint. Possui implicações muito maiores que isso.

Conforme Martins (2007, p. 277), entre suas principais características estão:

a) o Scrum Team, Scrum Master e Product Owner devem estar presentes nessa

reunião;

b) a reunião começa com duas perguntas: o que deu certo durante a sprint, e o que

pode ser melhorado para a próxima sprint;

c) o Scrum Master participa da reunião para descobrir novas formas de se trabalhar

no processo Scrum;

d) algumas ações podem ser deflagradas para a próxima sprint.

2.3.2.2.5 Gráfico de Burndown

Conforme Campos (2009), o gráfico de Burndown é a representação gráfica dos itens

contidos na sprint, e mostra o quanto de trabalho ainda há para fazer. À medida que o

progresso do trabalho for registrado, o gráfico mostra o quanto de trabalho precisa ser feito

até o final da iteração. Desta forma é possível perceber se a sprint será concluída dentro do

prazo ou não.

É uma excelente maneira de visualizar e correlacionar o trabalho pendente e o

progresso da equipe em reduzir esse trabalho. Com este recurso é possível fazer simulações

quanto à adição de novos itens no backlog ou da mudança de duração da sprint. A figura 2

ilustra um exemplo do gráfico, onde se pode identificar que a quantidade de testes

automatizados esperada para a sprint 1 não foi alcançada.

26

Fonte: Campos (2009).

Figura 2 – Gráfico de Burndown

2.4 TRABALHOS CORRELATOS

Algumas ferramentas disponíveis no mercado possuem algumas funcionalidades

similares ao trabalho proposto. Entre elas, citam-se o trabalho desenvolvido por Pereira

(2005), as ferramentas Project Koach e Mingle e o Scrum Project.

2.4.1 Ambiente web para gerenciamento de processo de software baseado no Scrum

De acordo com Pereira (2005, p. 15), sua ferramenta é a adaptação de outra já existente

denominada DotProject, para atender os artefatos baseados na metodologia Scrum. Para a

criação deste ambiente foram utilizados Personal Home Page (PHP) e MySQL. Um dos seus

objetivos é aprofundar os conhecimentos na metodologia Scrum e difundir como alternativa

de processo para as pequenas organizações de software.

O ambiente contém três módulos adicionais à ferramenta DotProject, que são Product

Backlog, Sprint Backlog e Daily Scrum. Estes foram desenvolvidos na língua nativa do

DotProject (inglês) e traduzidos para o português através de arquivos de configuração do

DotProject. Conforme Pereira (2005, p. 36), a ferramenta permitirá a classificação dos

usuários em Product Owner, Scrum Master e Scrum Team, permitindo desta maneira a

27

adaptação do ambiente de acordo com o nível de usuário selecionado. A figura 3 apresenta a

tela principal da ferramenta.

Fonte: Pereira (2005, p. 27).

Figura 3 – Tela principal da ferramenta

2.4.2 Project Koach

Conforme Papo (2007), Project Koach é uma ferramenta gratuita para gerência de

projetos baseado no processo OpenUp. Esta ferramenta roda localmente, permitindo acesso a

todos da equipe. Suas funcionalidades são específicas para cada papel proposto no OpenUp.

Com a ferramenta Project Koach é possível planejar projetos, medir a velocidade da

equipe, gerenciar iterações, controlar tarefas alocadas e rastrear itens de trabalho a requisitos

do projeto. A figura 4 mostra a tela principal da ferramenta.

Fonte: Papo (2007).

Figura 4 – Tela principal da ferramenta Project Koach

28

2.4.3 Mingle

De acordo com Papo (2007), Mingle é uma ferramenta para gerência de projetos,

desenvolvida pela empresa americana ThoughtWorks. É gratuita para até cinco usuários. A

partir do sexto usuário, é paga uma taxa de licenciamento.

Mingle possui as mesmas funcionalidades que a ferramenta Project Koach, entretanto é

mais completa. Um dos itens que possui a mais é a integração com ferramentas de controle de

versões e integrações de requisitos, casos de testes, defeitos e riscos. A figura 5 ilustra a tela

de controle das tarefas da ferramenta.

Fonte: Papo (2007). Figura 5 – Tela da ferramenta Mingle

2.4.4 Scrum Project

Conforme Kluge (2009, p. 2), Scrum Project é uma ferramenta web de apoio ao

gerenciamento de projetos de software baseado nos princípios da metodologia ágil Scrum. Foi

desenvolvida na linguagem de programação PHP, com banco de dados PostgreSQL, baseada

em software livre e com código fonte aberto.

A ferramenta trabalha com perfis de usuários, e de acordo com o usuário selecionado,

exibe as funcionalidades que ele tem permissão. É dividido em módulos, tais como cadastro,

projetos, Product Backlog, Sprint Backlog, reunião de planejamento, reunião diária, reunião

29

de revisão, reunião de retrospectiva e relatórios. A figura 6 exibe a tela de cadastro de Product

Backlog da ferramenta.

Fonte: Kluge (2009).

Figura 6 – Tela da ferramenta Scrum Project

30

3 DESENVOLVIMENTO DA FERRAMENTA

Este capítulo demonstra o desenvolvimento da ferramenta construída. São

apresentados requisitos, especificação e implementação da ferramenta. Estes requisitos foram

definidos a partir do estudo de ferramentas existentes, e demais pesquisas realizadas.

3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO

Para definir os artefatos e atividades básicas necessárias para um projeto baseado no

Scrum, a ferramenta foi construída a partir dos seguintes requisitos funcionais:

a) permitir ao scrum master o cadastro das pessoas envolvidas no projeto;

b) permitir ao scrum master o cadastro de empresas;

c) permitir ao scrum master o cadastro de projetos;

d) permitir ao scrum master o cadastro de sprints backlog de cada projeto, podendo

definir prioridades para os mesmos;

e) permitir ao product owner o cadastro dos requisitos do projeto (backlogs),

definindo prioridades entre os mesmos;

f) permitir o envio de e-mail a algum usuário cadastrado;

g) possuir um controle das tarefas por usuário, listando as tarefas pendentes para o

dia atual;

h) permitir ao scrum master o cadastro das sprints realizadas;

i) permitir ao scrum team a documentação dos itens levantados e discutidos nas

reuniões diárias, incluindo tarefas a fazer e problemas relatados;

j) permitir ao product owner a emissão de um relatório de acompanhamento de

tarefas pendentes, para manter o controle dos prazos;

k) permitir ao product owner acesso aos dados para acompanhar o andamento do

cronograma de um projeto;

l) permitir ao product owner a geração de um relatório sobre problemas identificados

durante o andamento do projeto;

m) permitir ao scrum master o cadastro dos times que fazem parte do projeto;

n) permitir ao scrum master o cadastro da reunião de retrospectiva;

31

o) permitir ao scrum master o cadastro da reunião de revisão;

p) permitir ao scrum team o cadastro das reuniões diárias.

A ferramenta construída atendeu os seguintes requisitos não funcionais:

a) ser desenvolvido na linguagem C#;

b) utilizar banco de dados MySQL 4.1 ou posterior;

c) o sistema deve ser compatível com o sistema operacional Windows 98 ou

posterior;

d) utilizar web service para conexão com o banco de dados;

e) o sistema deve ser desenvolvido através da ferramenta Microsoft Visual Studio

2008;

f) utilizar a ferramenta Microsoft Expression Blend para desenho das telas;

g) utilizar a ferramenta Microsoft Silverlight para auxílio no desenvolvimento.

3.2 ESPECIFICAÇÃO

A especificação foi realizada a partir da ferramenta Enterprise Architect, utilizando a

linguagem de modelagem Unified Modeling Language (UML). Para a modelagem foram

utilizados os diagramas de casos de uso, atividade e entidade-relacionamento.

3.2.1 Diagrama de casos de uso

Os diagramas de caso de uso estão divididos em módulo Administrativo e módulo

Projetos. O módulo Administrativo traz como ator o Scrum Master, responsável pelo cadastro

de pessoas, usuários e empresas. O módulo Projetos exibe uma visão geral da ferramenta,

tendo com atores o Scrum Master, o Product Owner e o Scrum Team.

A figura 7 ilustra o diagrama de casos de uso administrativo.

32

Figura 7 – Diagrama de casos de uso administrativo

A figura 8 exibe o diagrama de casos de uso Projetos.

Figura 8 – Diagrama de casos de uso projetos

O detalhamento dos principais casos de uso apresentados na figura 8 estão descritos no

Apêndice A.

33

3.2.2 Diagrama de atividades

Na figura 9 é apresentado o diagrama de atividades que representa a criação de um

projeto, desde o levantamento das informações até o encerramento do projeto, previsto no uso

da ferramenta criada.

Figura 9 – Diagrama de atividades

34

3.2.3 Diagrama de classes

Na figura 10 é exibido o diagrama de classes conceitual da ferramenta.

Figura 10 – Diagrama de classes

35

3.2.4 Diagrama de entidade-relacionamento

Na figura 11 é apresentado o diagrama de entidade-relacionamento, mostrando a

estrutura do banco de dados da ferramenta construída. A descrição de cada tabela está descrita

no Apêndice B.

Figura 11 – Diagrama de entidade-relacionamento do banco de dados

36

3.3 IMPLEMENTAÇÃO

A seguir são mostradas as técnicas e ferramentas utilizadas e a operacionalidade da

implementação.

3.3.1 Técnicas e ferramentas utilizadas

Para a implementação do trabalho foram utilizadas as seguintes ferramentas:

a) Microsoft Visual Studio 2008: ambiente para desenvolvimento das rotinas;

b) Microsoft Expression Blend: ferramenta para criação de sites;

c) Microsoft Silverlight: ferramenta de auxílio no desenvolvimento de páginas web;

d) MySQL: banco de dados. A conexão com o banco de dados foi realizado via web

service.

3.3.1.1 Microsoft Expression Blend

De acordo com Fernandes (2010), o Microsoft Expression Blend é uma ferramenta de

desenvolvimento de software, voltado para aplicações web e desktop. Com ele é possível

projetar sistemas, criar animações, estilizar elementos e adicionar interatividade nas

aplicações. O Microsoft Expression Blend foi utilizado na ferramenta desenvolvida para

melhorar a interface com usuário. Sua utilização pode ser visualizada nas próprias telas do

sistema, ilustradas na seção 3.3.2. A figura 12 exibe a principal tela da ferramenta.

37

Fonte: Fernandes (2010).

Figura 12 – Ferramenta Expression Blend

3.3.1.2 Microsoft Silverlight

O Microsoft Silverlight é um plug-in para vários navegadores e várias plataformas,

destinado a fornecer a próxima geração de experiências de mídia baseadas em .NET e

aplicativos interativos e sofisticados para a web. O Silverlight proporciona um modelo de

programação flexível e consistente, com suporte para AJAX, Python, Ruby e linguagens

.NET como Visual Basic e C#, além de integrar-se aos aplicativos web já existentes

(MICROSOFT, 2010). O Microsoft Silverlight foi utilizado juntamente com o Visual Studio,

para criação da ferramenta desenvolvida. A utilização pode ser verificada no código fonte,

conforme telas contidas na seção 3.3.1.4.

3.3.1.3 Web services

De acordo com Reckziegel (2006), web service é uma aplicação que aceita solicitações

de outros sistemas através da internet. Podem ser considerados também como serviços que

visam facilitar o processamento distribuído em sistemas heterogêneos.

O principal objetivo dos web services é proporcionar a interoperabilidade entre

sistemas distribuídos, independente da plataforma e da linguagem de programação utilizada

38

por eles, disponibilizando uma melhor interligação destas aplicações. Esta interligação tem

como princípio facilitar os processos de negócios, proporcionando a softwares isolados

passarem a funcionar de forma conjunta com os demais. Buscando a diminuição de custos,

aumento de produtividade e uma maior oportunidade de rendimento.

3.3.1.4 Código fonte

Seguem exemplos de códigos fonte de duas funcionalidades da ferramenta, e uma parte

do código fonte do web service utilizado.

O envio de e-mail foi criado utilizando um web service. Esse serviço possui toda a

lógica de envio e distribuição de e-mails, recebendo como entrada a mensagem, o assunto e

destinatário. Após ter publicado esse serviço, a aplicação Silverlight utiliza o serviço para

envio do e-mail.

Figura 13 – Código fonte de envio de e-mail

Para o cadastro de pessoas, assim como para os demais, a conexão do banco de dados

foi realizada através de web service, e todos os comandos foram realizados no mesmo. Em

cada classe foi necessário criar uma referência ao serviço publicado, e passar todas as

informações necessárias como parâmetros. A figura 14 exibe a tela de comunicação da classe

de pessoas com o web service publicado.

39

Figura 14 – Código fonte do cadastro de pessoas utilizando web service

Conforme citado anteriormente, a conexão com o banco de dados foi realizada no web

service criado. Após a publicação deste serviço, foi possível utilizar todos os recursos criados

no mesmo. Todas as rotinas como inserção, alteração, exclusão e busca de dados foram

realizadas nesse serviço. A figura 15 apresenta uma parte da classe do web service.

Figura 15 – Parte da classe do web service

3.3.2 Operacionalidade da implementação

A ferramenta foi desenvolvida através dos requisitos definidos. A seguir serão

apresentadas as telas do sistema, com explicações referentes às suas funcionalidades.

Para acessar o sistema (login), é necessário informar um login e senha. Após informar

usuário e senha, o sistema exibirá as telas de acordo com a classificação do usuário

cadastrado.

40

Para o usuário classificado como Scrum Master, serão liberadas as páginas pessoas,

empresas, projetos, times, sprints, sprint backlog, reunião de revisão, reunião de retrospectiva

e e-mail. Quando estiver classificado como Product Owner, serão liberadas as páginas

product backlog e relatórios. E caso esteja classificado como Scrum Team, terá acesso a

página de reunião diária. A página agenda será liberada para todos os usuários.

O mesmo deve ter sido previamente cadastrado por um administrador. A figura 16

exibe a tela inicial do sistema.

Figura 16 – Tela de login

Na figura 17 está ilustrada a tela de cadastro de pessoas. Possui as informações

necessárias para identificar todas as pessoas que fazem parte do projeto. O campo

classificação possui as opções Scrum Master, Scrum Team e Product Owner. Aqui pode-se

classificar qual o papel que essa pessoa terá no projeto. Esse papel define quais páginas o

usuário terá acesso. Os campos usuário e senha serão utilizados para acessar o sistema.

Figura 17 - Cadastro de pessoas

O cadastro de empresas se refere às empresas que solicitarão os projetos. A figura 18

41

exibe a tela de cadastro.

Figura 18 - Cadastro de empresas

Ao cadastrar um projeto, é necessário definir a data inicial e data final. A data final não

precisa ser exata, pode ser uma data estimada. Ao final do projeto esta data pode ser alterada.

O campo empresa lista todas as empresas cadastradas no sistema. O campo horas trabalhadas

e orçamento também podem ser alterados de acordo com o andamento do projeto. A figura 19

exibe a tela de cadastro de projetos.

Figura 19 - Cadastro de projetos

Após o cadastro do projeto, é possível o usuário montar a equipe que fará parte do

mesmo. É necessário selecionar a pessoa, e o projeto sobre qual a mesma fará parte. De

acordo com as pessoas cadastradas para o projeto selecionado, o sistema atualiza a tela com

42

todas as pessoas que fazem parte do time, conforme pode ser visualizado na figura 20.

Figura 20 - Cadastro de times

Após o cadastro do time, é necessário definir os requisitos do projeto. A cada item

cadastrado, a tela é atualizada com todos os product backlogs do projeto selecionado,

ordenados por prioridade. Mas o usuário pode escolher a ordenação por nome. A figura 21

ilustra a tela de cadastro.

Figura 21 - Cadastro de product backlog

O cadastro de sprints permite o cadastro das iterações do projeto. O campo projeto lista

todos os projetos cadastrados no sistema, e a data inicial e final devem estar entre as datas do

projeto selecionado. Cada projeto pode ter várias sprints. A figura 22 exibe a tela de cadastro

das sprints.

43

Figura 22 - Cadastro de sprints

Cada product backlog cadastrado pode ser dividido em vários sprints backlog. O

usuário pode selecionar a sprint, e qual product backlog está dividindo em tarefas. É

necessário também definir qual pessoa da equipe ficará responsável por essa tarefa. Cada item

cadastrado é atualizado na tela, conforme pode ser verificado na figura 23.

Figura 23 - Cadastro de sprint backlog

A figura 24 ilustra a tela de cadastro das reuniões diárias. É necessário que cada

usuário registre para o acompanhamento do andamento das atividades, tornando importante o

preenchimento de todos os campos.

44

Figura 24 - Cadastro de reuniões diárias

É necessário que no final de cada sprint seja realizada a reunião de revisão, para

verificar observações importantes referentes à sprint realizada, e adicionar sugestões para a

próxima. A figura 25 ilustra o cadastro das reuniões.

Figura 25 - Cadastro de reunião de revisão

A figura 26 ilustra o cadastro da reunião de retrospectiva, que ocorre após o término da

sprint. É possível adicionar melhorias para a próxima sprint.

45

Figura 26 - Cadastro de reunião de retrospectiva

O sistema permite o envio de e-mail entre os membros da equipe. Para isso, basta o

preenchimento dos campos conforme ilustrados na figura 27, e clicar em Enviar.

Figura 27 – Envio de e-mail

A figura 28 apresenta a tela do e-mail recebido na caixa de e-mail do destinatário

selecionado.

46

Figura 28 – Tela do e-mail recebido

Ao se logar no sistema, é exibido uma tela com todas as tarefas pendentes do dia, de

acordo com o usuário logado. As tarefas vêm ordenadas por prioridade. A figura 29 ilustra a

tela do sistema com as pendências.

Figura 29 – Tarefas pendentes do dia

O sistema permite a emissão de um relatório que permite aos envolvidos o

acompanhamento do desenvolvimento das tarefas (sprint backlog). O relatório traz como

informações o nome da tarefa, a pessoa que está responsável pela tarefa, e a data final. A

figura 30 exibe a tela do relatório gerado.

47

Figura 30 – Listagem para acompanhamento das tarefas

O sistema permite a emissão de um relatório que exibe aos envolvidos os problemas

encontrados durante o desenvolvimento das tarefas. O relatório traz como informações a

sprint, a pessoa que identificou o problema, e a data em que o problema foi identificado. A

figura 31 exibe o relatório gerado.

Figura 31 – Listagem de problemas encontrados

48

3.4 RESULTADOS E DISCUSSÃO

O estudo e documentação realizados sobre a metodologia ágil Scrum foram

fundamentais para a criação da ferramenta proposta. A ferramenta permite o controle da

realização das atividades básicas necessárias para controle de um projeto baseado em Scrum,

como proposto nos objetivos, tornando o processo de desenvolvimento mais ágil e menos

burocrático.

Após o estudo das ferramentas disponíveis, comparadas com a ferramenta

desenvolvida, foi identificado que a ferramenta proposta contempla os principais artefatos do

da metodologia ágil Scrum, tais como Product Backlog, Sprint Backlog, controle das reuniões

diárias, de revisão e retrospectiva, além de ser voltada para web, em língua portuguesa e

possuir uma lista de pendências por usuário. O quadro 2 mostra a comparação de algumas

funcionalidades e características entre a ferramenta proposta e os trabalhos correlatos.

Funcionalidades / Características

Ferramenta criada

Dot Project Project Koach Scrum Project Mingle

cadastro de times sim não sim sim não

cadastro do product backlog sim sim não sim sim

cadastro de sprints sim sim sim sim sim

cadastro de sprints backlog sim sim sim sim sim envio de e-mails sim não não não não

registro de reuniões diárias sim sim não sim sim registro de reuniões de retrospectiva sim não não sim não registro de reuniões de revisão sim não não sim sim relatório de tarefas pendentes sim sim não não não

relatórios estatísticos sim sim não sim não

plataforma web sim sim não sim sim

língua portuguesa sim sim não sim não

agenda de tarefas sim não não não não integração com ferramentas de controle não não não não sim gráfico de Burndown não não não não sim

Quadro 2 – Comparação entre as ferramentas

Ao analisar o quadro 2, é possível identificar que a ferramenta proposta permite a

realização das atividades básicas necessárias para controle de um projeto baseado no Scrum.

Após realização de testes funcionais durante e após o desenvolvimento da ferramenta, e a

49

comparação com os trabalhos correlatos tem-se como resultado o atendimento de todos os

objetivos propostos inicialmente. As principais limitações referem-se à falta de integração

com ferramentas de controle de versões e integrações de requisitos, casos de testes, defeitos e

riscos, e não existência do gráfico de Burndown. E como sugestão seria incluir o fechamento

do product backlog e o envio de e-mail aos envolvidos no projeto de acordo com os

acontecimentos ocorridos.

50

4 CONCLUSÕES

O mercado de metodologia ágil em gerência de projetos de software vem crescendo

nos últimos anos, apresentando diversas soluções para problemas distintos. Eles visam

aumentar a produtividade e a qualidade do projeto e garantir que estarão preparados para

qualquer mudança que possa ocorrer no andamento do projeto. Para proporcionar um maior

controle nos projetos para as empresas de software, mantendo estes benefícios, foi

desenvolvida a ferramenta, baseada na metodologia ágil Scrum.

Com esta ferramenta o cliente poderá ter acesso ao sistema, para acompanhar o

andamento do cronograma e verificar se os requisitos estão sendo implementados conforme

definidos, mas não permite validação dos requisitos pelos clientes.

Verificou-se que existem aplicações similares à ferramenta proposta. Entretanto, as

ferramentas Mingle e Project Koach não estão baseadas na metodologia ágil Scrum.

Em relação à ferramenta do Pereira (2005), pode-se afirmar que a mesma é uma

adaptação de uma ferramenta já existente, porém não possui integração com outras

ferramentas de gerência de projetos.

A ferramenta proposta incorpora os principais artefatos do Scrum, e conseguiu atingir

os objetivos propostos inicialmente. Uma das vantagens em utilizá-la é o armazenamento dos

dados de maneira segura, e com fácil acesso quando necessário.

Uma sugestão de extensão para a ferramenta proposta seria a inclusão do gráfico de

Burndown Chart, que é uma representação gráfica das tarefas (sprint backlog). O gráfico

permite o acompanhamento da evolução das tarefas, e mostra quanto do trabalho ainda

precisa ser feito.

51

REFERÊNCIAS BIBLIOGRÁFICAS

ALDABÓ, Ricardo. Gerenciamento de projetos: procedimento básico e etapas essenciais. 2. ed. São Paulo: Artliber, 2001.

AMBLER, Scott W. Modelagem ágil: práticas eficazes para a programação eXtrema e o processo unificado. Porto Alegre: Bookman, 2003.

BARCAUI, André B. O desafio do sucesso em projetos de tecnologia da informação. Rio de Janeiro, [2004?]. Disponível em: <www.bbbrothers.com.br/scripts/Artigos/Artigo%20-%20Sucesso%20em%20Projetos%20TI.pdf>. Acesso em: 03 set. 2008.

CAMPOS, Fabrício F. Scrum. [S.l.], 2009. Disponível em: <http://qualidadebr.wordpress.com/2009/07/>. Acesso em: 16 jun. 2010.

CRUZ, Leandro R. S. Desenvolvimento de software com Scrum. [S.l.], [2008?]. Disponível em: <http://cv-acolhimento.bvs.br/tiki-download_file.php?fileId=59>. Acesso em: 02 set. 2008.

CUELLAR, Roland; AUGUSTINE Sanjiv. Gerenciando equipes de desenvolvimento ágil: acertar alvos móveis é diferente. Mundo Project Management, [S.l.], v. 22, p. 77-81, ago./set. 2008.

FERNANDES, Robson. Microsoft Expression Blend – Introdução. [S.l.], 2010. Disponível em: < http://www.riasoftware.com.br/blog/?p=659>. Acesso em: 16 jun. 2010.

HELDMAN, Kim. Gerência de projetos: guia para o exame oficial do PMI. 3. ed. Tradução Luciana do Amaral Teixeira. Rio de Janeiro: Campus, 2006.

KLUGE, Monike R. Scrum project: ferramenta de apoio ao gerenciamento de projetos baseada nos princípios da metodologia ágil scrum. 2009. 81 f. Trabalho de Conclusão de Curso (Bacharelado em Ciência da Computação) – Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí.

KNIBERG, Henrik. Scrum e XP direto das trincheiras. [S.l.], 2007. Disponível em: <http://www.infoq.com/br/minibooks/scrum-xp-from-the-trenches>. Acesso em: 20 abr. 2010.

MARTINS, José C. C. Técnicas para gerenciamento de projetos de software. Rio de Janeiro: Brasport, 2007.

MICROSOFT. Aprendendo sobre o Silverlight. [S.l.], 2010. Disponível em: <http://msdn.microsoft.com/pt-br/silverlight/bb187401.aspx>. Acesso em: 16 jun. 2010.

52

MÜLLER, Elias. Métodos ágeis: uma aplicação do Scrum no SIMUPLAN. 2004. 92 f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) – Instituto de Ciências Exatas e Geociências, Universidade de Passo Fundo, Passo Fundo. Disponível em: <http://www.upf.br/computacao/download/tcs_emprestimo.pdf>. Acesso em: 03 set. 2008.

PAPO, José P. Novas ferramentas livres para gestão ágil de projetos: Mingle e ProjectKoach. [S.l.], 2007. Disponível em: <http://josepaulopapo.blogspot.com/2007_09_01_archive.html/>. Acesso em: 10 set. 2008.

PEREIRA, Jhony A. Ambiente web para gerenciamento de processo de software baseado no Scrum. 2005. 70 f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) – Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.

RECKZIEGEL, Maurício. Entendendo os WebServices. [S.l.], 2006. Disponível em: <http://imasters.uol.com.br/artigo/4245/webservices/entendendo_os_webservices/>. Acesso em: 27 abr. 2010.

RODRIGUES, Rafael; ROST, Rafael. Scrum: metodologia para o desenvolvimento ágil de software. [S.l.], 2007. Disponível em: <http://rafaelrgi.files.wordpress.com/2007/11/scrum.pdf>. Acesso em: 01 set. 2008.

SANCHES, Ivan. Scrum em dois minutos. Florianópolis, 2007. Disponível em: <http://dojofloripa.wordpress.com/2007/02/07/scrum-em-2-minutos/>. Acesso em: 21 ago. 2008.

SANTOS, Otávio A. R. dos. Gerenciamento ágil de projetos: uma abordagem adaptativa. Mundo Project Management, [S.l.], v. 22, p. 38- 42, ago./set. 2008.

SCRUM. Visão geral do scrum. [S.l.], 2008. Disponível em: <http://epf.eclipse.org/wikis/scrumpt/index.htm>. Acesso em: 21 out. 2009.

SOUZA NETO, Oscar N. de. Análise comparativa das metodologias de desenvolvimento de software tradicionais e ágeis. 2004. 74 f. Trabalho de Conclusão de Curso (Bacharelado em Ciência da Computação) - Centro de Ciências Exatas e Tecnologia, Universidade da Amazônia, Amazônia. Disponível em: <http://www.cci.unama.br/margalho/portaltcc/tcc2004/oscar.PDF>. Acesso em: 02 set. 2008.

VASCO, Carlos G.; VITHOFT, Marcelo H.; ESTANTE, Paulo R. C. Comparação entre metodologias RUP e XP. Curitiba, [2004?]. Disponível em: <http://www.ppgia.pucpr.br/~alcides/Teaching/mestrado/FundamentosEngenhariaSoftware/artigos/ResumosApresentacoes/RUPvsXP_draft.pdf>. Acesso em: 03 set. 2008.

VIEIRA, Marconi F. Gerenciamento de projetos de tecnologia da informação. Rio de Janeiro: Campus, 2003.

53

APÊNDICE A – Detalhamento dos casos de uso

Nos quadros 3 ao 8 são detalhados os principais casos de uso citados na seção 3.2.1.

UC6 - Cadastrar Projetos

Objetivo

Permite ao Scrum Master incluir, alterar e excluir o projeto.

Pré-condições

O Scrum Master deve estar logado no sistema. A empresa precisa estar

cadastrada.

Principal : Inclusão de Projeto

1. O Scrum Master solicita cadastrar novo projeto.

2. Sistema solicita nome, data inicial e final, empresa, descrição, horas

trabalhadas e orçamento.

3. Scrum Master informa dados do novo projeto.

4. Sistema valida os dados

5. Sistema grava dados do novo projeto.

Alternativo : Alterar projeto

No passo 3, caso Scrum Master deseje alterar dados do projeto.

3.1 - Scrum Master seleciona projeto que deseja alterar.

3.2 - Sistema apresenta dados atuais do projeto.

3.3 - Scrum Master altera dados.

3.4 - Sistema valida os dados.

Alternativo : Excluir projeto

No passo 3, caso o Scrum Master deseje excluir um projeto.

3.1 - Scrum Master clica sobre o projeto para exclusão.

3.2 - Scrum Master solicita para excluir o projeto.

3.3 - Sistema valida os dados

Exceção: Campo Nome não preenchido

No passo 4, o sistema deve verificar se o campo "Nome" foi preenchido. Se a

resposta for não, o sistema deve apresentar a mensagem "É necessário informar o nome

da sprint".

Exceção: Campo Empresa não preenchido

54

No passo 4, o sistema deve verificar se o campo "Empresa" foi preenchido. Se a

resposta for não, o sistema deve apresentar a mensagem "É necessário informar a

empresa"

Exceção: Campo Data inicial não preenchida

No passo 4, o sistema deve verificar se o campo "Data inicial" foi preenchido.

Se a resposta for não, o sistema deve apresentar a mensagem "É necessário informar a

data de início".

Exceção: Campo Data final não preenchida

No passo 4, o sistema deve verificar se o campo "Data final" foi preenchido. Se

a resposta for não, o sistema deve apresentar a mensagem "É necessário informar a data

final"

Exceção: Campo Data Final menor que a Data início

No passo 4, o sistema deve verificar se a data informada no campo "Data Final"

está maior que a data informada no campo "Data Inicial". Se a resposta for não, o

sistema deve apresentar a mensagem "A data final deve ser maior que a data inicial".

Pós-condições

O projeto foi criado. O projeto foi excluído. O projeto foi alterado

Quadro 3 – UC6 – Cadastro de projetos

UC9 - Cadastrar sprint backlog

Objetivo

Permitir ao Scrum Master incluir, alterar e excluir sprints backlog.

Pré-condições

O gerente de projetos deve estar logado no sistema. O projeto já deve estar

criado. A sprint já deve estar cadastrada. O product backlog deve estar cadastrado. O

responsável deve estar cadastrado.

Principal : Inclusão de Sprint Backlog

1. O Scrum Master solicita cadastrar um novo sprint backlog.

2. Sistema solicita sprint, product backlog, nome, descrição, responsável,

situação, prioridade, data inicial e final.

3. Scrum Master informa dados do novo sprint backlog.

4. Sistema valida os dados.

5. Sistema grava dados do novo sprint backlog.

55

Alternativo : Alterar sprint backlog

No passo 3, caso Scrum Master deseje alterar dados do sprint backlog.

3.1 - Scrum Master seleciona sprint backlog que deseja alterar.

3.2 - Sistema apresenta dados atuais do sprint backlog.



Alternativo : Excluir Sprint Backlog

No passo 3, caso o Scrum Master deseje excluir um sprint backlog.

3.1 - Scrum Master clica sobre o sprint backlog para exclusão.

3.2 - Scrum Master solicita para excluir o sprint backlog.





da sprint".

Exceção: Campo Sprint não preenchido

No passo 4, o sistema deve verificar se o campo "Sprint" foi preenchido. Se a


sprint"

Exceção: Campo Responsável não preenchido

No passo 4, o sistema deve verificar se o campo "Responsável" foi preenchido.

Se a resposta for não, o sistema deve apresentar a mensagem "É necessário informar o

responsável".

Exceção: Campo Product Backlog não preenchido

No passo 4, o sistema deve verificar se o campo "Product Backlog" foi

preenchido. Se a resposta for não, o sistema deve apresentar a mensagem "É necessário

informar o product backlog"

Exceção: Campo Data início não preenchida

No passo 4, o sistema deve verificar se o campo "Data inicial" foi preenchido.


data de início".

Exceção: Campo Data final não preenchida

No passo 4, o sistema deve verificar se o campo "Data final" foi preenchido. Se

56


final"

Exceção: Campo Data Inicial e Data Final fora do intervalo da data do projeto

No passo 4, o sistema deve verificar se o campo "Data Inicial" e "Data Final"

correspondem ao intervalo de data do projeto selecionado. Se a resposta for não, o

sistema deve apresentar a mensagem "A data informada deve corresponder a data do

projeto selecionado"

Pós-condições

O sprint backlog foi criado. O sprint backlog foi excluído. O sprint backlog foi

alterado

Quadro 4 – UC9 – Cadastro de sprint backlog

UC3 - Cadastrar product backlog

Objetivo

Permitir ao Product Owner incluir, alterar e excluir products backlog.

Pré-condições

O Product Owner deve estar logado no sistema. O projeto já deve estar criado.

O responsável deve estar cadastrado.

Principal : Inclusão de Product Backlog

1. O Product Owner solicita cadastrar um novo product backlog.

2. Sistema solicita nome, projeto, prioridade, horas estimadas e descrição.

3. Product Owner informa dados do novo product backlog.


5. Sistema grava dados do novo product backlog.

Alternativo : Alterar product backlog

No passo 3, caso Product Owner deseje alterar dados do product backlog.

3.1 - Product Owner seleciona product backlog que deseja alterar.

3.2 - Sistema apresenta dados atuais do product backlog.

3.3 - Product Owner altera dados.


Alternativo : Excluir Product Backlog

No passo 3, caso o Product Owner deseje excluir um product backlog.

3.1 - Product Owner clica sobre o product backlog para exclusão.

3.2 - Product Owner solicita para excluir o product backlog.

57





do product backlog".

Exceção: Campo Projeto não preenchido

No passo 4, o sistema deve verificar se o campo "Projeto" foi preenchido. Se a

resposta for não, o sistema deve apresentar a mensagem "É necessário informar o

projeto".

Pós-condições

O product backlog foi criado. O product backlog foi excluído. O product

backlog foi alterado

Quadro 5 – UC3 – Cadastro de product backlog

UC8 - Cadastrar sprint

Objetivo

Permitir ao Scrum Master incluir, alterar e excluir sprints.

Pré-condições

O Scrum Master deve estar logado no sistema. O projeto já deve estar criado.

Principal : Inclusão de Sprint

1. O Scrum Master solicita cadastrar uma nova sprint.

2. Sistema solicita projeto, data inicial e final.

3. Scrum Master informa dados da nova sprint.


5. Sistema grava dados da nova sprint.

Alternativo : Alterar sprint.

No passo 3, caso Scrum Master deseje alterar dados da sprint.

3.1 - Scrum Master seleciona sprint que deseja alterar.

3.2 - Sistema apresenta dados atuais da sprint.



Alternativo : Excluir sprint.

No passo 3, caso o Scrum Master deseje excluir uma sprint.

3.1 - Scrum Master clica sobre a sprint para exclusão.

58

3.2 - Scrum Master solicita para excluir a sprint.





projeto".

Exceção: Campo Data Inicial não preenchido

No passo 4, o sistema deve verificar se o campo "Data Inicial" foi preenchido.


data inicial da sprint".

Exceção: Campo Data Final não preenchido

No passo 4, o sistema deve verificar se o campo "Data Final" foi preenchido. Se


final da sprint".

Exceção: Campo Data Inicial e Data Final fora do intervalo da data do projeto

No passo 4, o sistema deve verificar se o campo "Data Inicial" e "Data Final"

correspondem ao intervalo de data do projeto selecionado. Se a resposta for não, o

sistema deve apresentar a mensagem "A data informada deve corresponder a data do

projeto selecionado".

Exceção: Campo Data Final menor que a Data Inicial

No passo 4, o sistema deve verificar se a data informada no campo "Data Final"

está maior que a data informada no campo "Data Inicial". Se a resposta for não, o

sistema deve apresentar a mensagem "A data final deve ser maior que a data inicial".

Pós-condições

A sprint foi criada. A sprint foi excluída. A sprint foi alterada.

Quadro 6 – UC8 – Cadastro de sprints

UC7 - Cadastrar times

Objetivo

Permitir ao Scrum Master incluir, alterar e excluir times.

Pré-condições

O Scrum Master deve estar logado no sistema

O projeto já deve estar criado.

A pessoa deve estar criada.

59

Principal : Inclusão de times

1. O Scrum Master solicita cadastrar um novo time.

2. Sistema solicita projeto e pessoa.

3. Scrum Master informa dados do novo time.


5. Sistema grava dados do novo time.

Alternativo : Alterar time.

No passo 3, caso Scrum Master deseje alterar dados do time.

3.1 - Scrum Master seleciona o time que deseja alterar.

3.2 - Sistema apresenta dados atuais do time.



Alternativo : Excluir time.

No passo 3, caso o Scrum Master deseje excluir um time.

3.1 - Scrum Master clica sobre o time desejado para exclusão.

3.2 - Scrum Master solicita para excluir o time.





projeto".

Exceção: Campo Pessoa não preenchido

No passo 4, o sistema deve verificar se o campo "Pessoa" foi preenchido. Se a


pessoa".

Exceção: Campo Data Final não preenchido

No passo 4, o sistema deve verificar se o campo "Data Final" foi preenchido. Se


final da sprint".

Pós-condições

O time foi criado.

O time foi excluído.

O time foi alterado.

Quadro 7 – UC7 - Cadastro de times

60

UC12 - Cadastrar reuniões diárias

Objetivo

Permitir ao Scrum Team incluir, alterar e excluir reuniões diárias.

Pré-condições

O Scrum Team deve estar logado no sistema

A sprint deve estar criada.

A pessoa deve estar criada.

Principal : Inclusão de reuniões diárias

1. O Scrum Team solicita cadastrar uma nova reunião diária.

2. Sistema solicita sprint, data, itens realizados ontem, itens que serão realizados

amanhã e problemas encontrados.

3. Scrum Team informa dados da nova reunião diária.


5. Sistema grava dados da nova reunião diária.

Alternativo : Alterar reunião diária

No passo 3, caso Scrum Team deseje alterar dados da reunião diária.

3.1 - Scrum Team seleciona a reunião diária que deseja alterar.

3.2 - Sistema apresenta dados atuais da reunião diária.

3.3 - Scrum Team altera dados.


Alternativo : Excluir reunião diária.

No passo 3, caso o Scrum Team deseje excluir uma reunião diária.

3.1 - Scrum Team clica sobre a reunião desejado para exclusão.

3.2 - Scrum Team solicita para excluir a reunião.


Exceção: Campo Data não preenchido

No passo 4, o sistema deve verificar se o campo "Data" foi preenchido. Se a

resposta for não, o sistema deve apresentar a mensagem "É necessário informar a data

da reunião".

Exceção: Campo Sprint não preenchido

No passo 4, o sistema deve verificar se o campo "Sprint" foi preenchido. Se a


sprint".

61

Pós-condições

A reunião diária foi criada. A reunião diária foi excluída. A reunião diária foi

alterada.

Quadro 8 – UC12 - Cadastro de reunião diária

62

APÊNDICE B – Dicionário de dados do diagrama de entidade-relacionamento

No quadro 9 são apresentadas as informações dos campos do diagrama de

entidade - relacionamento relacionados na seção 3.2.4.

pessoas

Id: número sequencial da pessoa;

Nome: nome da pessoa;

Logradouro: nome do logradouro onde a pessoa reside;

Numero: número do local onde a pessoa reside;

Complemento: complemento do logradouro onde a pessoa reside;

CEP: código de endereçamento postal de onde a pessoa reside;

Telefone: número do telefone da pessoa;

Celular: número do celular da pessoa;

Email: e-mail da pessoa;

Bairro: bairro onde a pessoa reside;

Classificacao: classificação da pessoa. Exemplo: Scrum Master, Scrum Team e

Product Owner;

Login: login da pessoa para acessar o sistema;

Senha: senha da pessoa para acessar o sistema;

PK_pessoas: nome da chave primária, referente a coluna Id.

Empresas

Id: número sequencial da empresa;

Nome: nome da empresa;

Logradouro: nome do logradouro onde a empresa se localiza;

Numero: número do local onde a empresa se localiza;

Complemento: complemento do logradouro onde a empresa se localiza;

CEP: código de endereçamento postal de onde a empresa se localiza;

Telefone: número do telefone da empresa;

Descricao: descrição da empresa;

Email: e-mail da empresa para entrar em contato;

Bairro: bairro onde a empresa se localiza;

63

CNPJ: número do cadastro nacional de pessoa jurídica da empresa;

PK_empresas: nome da chave primária, referente a coluna Id.

Projetos

Id: número sequencial de projetos;

Nome: nome do projeto;

Empresa: chave estrangeira que indica a qual empresa o projeto pertence;

DataInicio: data que indica o início do projeto;

DataFinal: data que indica o término do projeto;

Descricao: descrição do projeto;

HorasTrabalhadas: indica a quantidade de horas estimadas que serão utilizadas

para o projeto;

Orcamento: valor estimado necessário para a realização do projeto;

PK_projetos: nome da chave primária, referente a coluna Id;

FK_projetos_empresas: nome da chave estrangeira, referente a coluna empresa.

Times

Id: número sequencial de times;

Pessoa: chave estrangeira que indica a pessoa que pertence ao time;

Projeto: chave estrangeira que indica o projeto que o time pertence;

PK_times: nome da chave primária, referente a coluna Id;

FK_times_pessoas: nome da chave estrangeira, referente a coluna pessoa;

FK_times_projetos: nome da chave estrangeira, referente a coluna projeto.

Sprints

Id: número sequencial de sprints;

DataInicial: data que indica o início da sprint;

DataFinal: data que indica o término da sprint;

Projeto: chave estrangeira que indica o projeto que pertence a sprint;

PK_sprints: chave primária, referente a coluna Id;

FK_sprints_projetos: chave estrangeira, referente a coluna projeto.

64

productbacklog

Id: número sequencial de product backlog;

Nome: nome do product backlog;

Prioridade: prioridade do product backlog;

HorasTrabalhadas: estimativa das horas que serão trabalhadas nesse product

backlog;

Projeto: chave estrangeira que indica a qual projeto o product backlog pertence;

Descricao: descrição do product backlog;

PK_productbacklog: chave primária, referente a coluna id;

FK_productbacklog_projetos: chave estrangeira, referente a coluna projeto.

Sprintbacklog

Id: número sequencial de sprints backlog;

Nome: nome do sprint backlog;

Descricao: descrição do sprint backlog;

Situacao: situação do sprint backlog. Exemplo: Não iniciado, Em

Desenvolvimento, Concluído;

Prioridade: prioridade do sprint backlog;

Responsavel: chave estrangeira que indica qual a pessoa responsável pelo sprint

backlog;

DataInicio: data que indica o início do sprint backlog;

DataFinal: data que indica o término do sprint backlog;

ProductBacklog: chave estrangeira que indica a qual product backlog o sprint

backlog pertence;

Sprint: chave estrangeira que indica a qual sprint o sprint backlog pertence;

DataInicioSprint: data que indica o início da sprint. Preenchida de acordo com a

sprint selecionada;

DataFinalSprint: data que indica o término da sprint selecionada. Preenchida de

acordo com a sprint selecionada;

PK_sprintbacklog: chave primária, referente a coluna id;

FK_sprintbacklog_pessoas: chave estrangeira, referente a coluna responsavel.

FK_sprintbacklog_productbacklog: chave estrangeira, referente a coluna

product backlog;

65

FK_sprintbacklog_sprints: chave estrangeira, referente a coluna sprint.

Reuniaorevisao

Id: número sequencial de reuniões;

Sprint: chave estrangeira que indica a sprint que a reunião pertence;

Data: data da reunião. Deve corresponder ao período da sprint selecionada;

Observacoes: observações referentes à reunião;

Sugestoes: sugestões para a próxima sprint;

PK_reuniaorevisao: chave primária, referente a coluna id;

FK_reuniaorevisao_sprints: chave estrangeira, referente a coluna sprint.

reuniaoretrospectiva


Sprint: chave estrangeira, que indica a sprint que a reunião pertence;


Desenvolvimento: observações referentes ao desenvolvimento.

Melhorias: melhorias que precisam ser realizadas;

PK_reuniaoretrospectiva: chave primária, referente a coluna id;

FK_reuniaoretrospectiva_sprints: chave estrangeira, referente a coluna sprint.

Reuniaodiaria


Sprint: chave estrangeira, que indica a sprint que a reunião pertence;


RealizadoOntem: descrição dos itens que foram realizados ontem;

RealizarAmanha: descrição dos itens que serão realizados amanhã;

Problemas: descrição de problemas encontrados;

Usuário: chave estrangeira que indica a pessoa que está cadastrando a tarefa;

PK_reuniaodiaria: chave primária, referente a coluna id;

FK_reuniaodiaria_pessoas: chave estrangeira, referente a coluna usuário;

FK_reuniaodiaria_sprints: chave estrangeira, referente a coluna sprint.

Quadro 9 – Dicionário de dados do diagrama de entidade relacionamento

FERRAMENTA WEB PARA GERENCIAMENTO DE PROJETOS DE SOFTWARE...

Documents

Transcript of FERRAMENTA WEB PARA GERENCIAMENTO DE PROJETOS DE SOFTWARE...