ferramenta web para gerenciamento de projetos de software...
TRANSCRIPT
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
FERRAMENTA WEB PARA GERENCIAMENTO DE
PROJETOS DE SOFTWARE BASEADO NO SCRUM
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
FERRAMENTA WEB PARA GERENCIAMENTO DE
PROJETOS DE SOFTWARE BASEADO NO SCRUM
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.
3.3 - Scrum Master altera dados.
3.4 - Sistema valida os dados.
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.
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 Sprint não preenchido
No passo 4, o sistema deve verificar se o campo "Sprint" foi preenchido. Se a
resposta for não, o sistema deve apresentar a mensagem "É necessário informar 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.
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
56
a resposta for não, o sistema deve apresentar a mensagem "É necessário informar a data
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.
4. Sistema valida os dados.
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.
3.4 - Sistema valida os 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
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
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.
4. Sistema valida os dados.
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.
3.3 - Scrum Master altera dados.
3.4 - Sistema valida os dados.
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.
3.3 - Sistema valida os dados
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".
Exceção: Campo Data Inicial não preenchido
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 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
a resposta for não, o sistema deve apresentar a mensagem "É necessário informar a data
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.
4. Sistema valida os dados.
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.
3.3 - Scrum Master altera dados.
3.4 - Sistema valida os dados.
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.
3.3 - Sistema valida os dados
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".
Exceção: Campo Pessoa não preenchido
No passo 4, o sistema deve verificar se o campo "Pessoa" foi preenchido. Se a
resposta for não, o sistema deve apresentar a mensagem "É necessário informar 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
a resposta for não, o sistema deve apresentar a mensagem "É necessário informar a data
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.
4. Sistema valida os dados.
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.
3.4 - Sistema valida os 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.
3.3 - Sistema valida os dados
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
resposta for não, o sistema deve apresentar a mensagem "É necessário informar 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
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;
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
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;
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