UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE …siaibib01.univali.br/pdf/Monike Roberta Kluge.pdf ·...
81
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO SCRUM PROJECT: FERRAMENTA DE APOIO AO GERENCIAMENTO DE PROJETOS DE SOFTWARE BASEADA NOS PRINCÍPIOS DA METODOLOGIA ÁGIL SCRUM Área de Engenharia de Software por Monike Roberta Kluge Adriana Gomes Alves, M. Eng Orientadora Itajaí (SC), julho de 2009
-
Upload
duongtuyen -
Category
Documents
-
view
214 -
download
0
Transcript of UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE …siaibib01.univali.br/pdf/Monike Roberta Kluge.pdf ·...
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SCRUM PROJECT: FERRAMENTA DE APOIO AO GERENCIAMENTO DE PROJETOS DE SOFTWARE BASEADA NOS PRINCÍPIOS DA METODOLOGIA
ÁGIL SCRUM
Área de Engenharia de Software
por
Monike Roberta Kluge
Adriana Gomes Alves, M. Eng Orientadora
Itajaí (SC), julho de 2009
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SCRUM PROJECT: FERRAMENTA DE APOIO AO GERENCIAMENTO DE PROJETOS DE SOFTWARE BASEADA NOS PRINCÍPIOS DA METODOLOGIA
ÁGIL SCRUM
Área de Engenharia de Software
por
Monike Roberta Kluge Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientadora: Adriana Gomes Alves, M. Eng.
Itajaí (SC), julho de 2009
ii
SUMÁRIO
LISTA DE ABREVIATURAS.................................................................. iv
LISTA DE FIGURAS.................................................................................v
LISTA DE TABELAS...............................................................................vi RESUMO...................................................................................................vii ABSTRACT..............................................................................................viii 1 INTRODUÇÃO......................................................................................1 1.1 PROBLEMATIZAÇÃO ..................................................................................... 2 1.1.1 Formulação do Problema................................................................................. 2 1.1.2 Solução Proposta ............................................................................................... 3 1.2 OBJETIVOS ........................................................................................................ 3 1.2.1 Objetivo Geral ................................................................................................... 3 1.2.2 Objetivos Específicos ........................................................................................ 3 1.3 METODOLOGIA................................................................................................ 3 1.4 ESTRUTURA DO TRABALHO ....................................................................... 4
2 FUNDAMENTAÇÃO TEÓRICA ........................................................5 2.1 PROCESSOS DE SOFTWARE......................................................................... 5 2.2 METODOLOGIAS TRADICIONAIS .............................................................. 7 2.3 METODOLOGIAS ÁGEIS.............................................................................. 11 2.4 SCRUM............................................................................................................... 12 2.4.1 Papéis no Scrum.............................................................................................. 14 2.4.2 Estrutura do Processo Scrum ........................................................................ 16 2.4.3 Ciclo de Vida do Scrum.................................................................................. 25 2.4.4 Ferramentas..................................................................................................... 26
3 PROJETO.............................................................................................29 3.1 ANÁLISE DE REQUISITOS........................................................................... 29 3.1.1 Requisitos Funcionais ..................................................................................... 29 3.1.2 Requisitos Não Funcionais ............................................................................. 30 3.1.3 Regras de Negócio ........................................................................................... 31 3.2 DIAGRAMA DE CASOS DE USO ................................................................. 31 3.2.1 Módulo Projeto................................................................................................ 31 3.2.2 Módulo Product Backlog................................................................................ 32 3.2.3 Módulo Controle de Sprint............................................................................. 33 3.3 DIAGRAMA DE CLASSES............................................................................. 35 3.4 DIAGRAMA ENTIDADE-RELACIONAMENTO....................................... 36
4 DESENVOLVIMENTO ......................................................................37 4.1 IMPLEMENTAÇÃO DA FERRAMENTA.................................................... 37 4.1.1 Framework ScriptCase................................................................................... 38
iii
4.2 A FERRAMENTA SCRUM PROJECT ......................................................... 39 4.2.1 Acesso ao Sistema............................................................................................ 39 4.2.2 Módulo de Cadastros...................................................................................... 42 4.2.3 Módulo Projeto................................................................................................ 44 4.2.4 Módulo Product Backlog................................................................................. 45 4.2.5 Módulo Sprint Backlog ................................................................................... 46 4.2.6 Módulo Reunião de Planejamento ................................................................ 47 4.2.7 Módulo Reunião Diária .................................................................................. 48 4.2.8 Reunião de Revisão ......................................................................................... 49 4.2.9 Reunião de Retrospectiva............................................................................... 50 4.2.10 Relatórios ......................................................................................................... 51
5 CONCLUSÕES ....................................................................................53
6 REFERÊNCIAS BIBLIOGRÁFICAS...............................................54
GLOSSÁRIO.............................................................................................56
A DESCRIÇÃO DOS CASOS DE USO ................................................58 A.1 MÓDULO PROJETO....................................................................................... 58 A.2 MÓDULO PRODUCT BACKLOG ................................................................ 65 A.3 MÓDULO DE CONTROLE DE SPRINT ...................................................... 67
iv
LISTA DE ABREVIATURAS
ASD Adaptative Software Development CASE Computer Aided Software Engineering DSDM Dynamic System Development Method FDD Feature Driven Development MOSCOW Must, Should, Could, Want ROI Return on Investment RUP Rational Unified Process TCC Trabalho de Conclusão de Curso UML Unified Modeling Language UNIVALI Universidade do Vale do Itajaí XP Extreme Programming
v
LISTA DE FIGURAS
Figura 1. Camadas da Engenharia de Software....................................................................................5 Figura 2. Modelo em Cascata...............................................................................................................8 Figura 3. Fases do RUP......................................................................................................................10 Figura 4. Adoção do Scrum................................................................................................................12 Figura 5. Framework do Scrum..........................................................................................................14 Figura 6. Fluxo do Scrum...................................................................................................................16 Figura 7. Product Backlog..................................................................................................................18 Figura 8. Priorização do Product Backlog .........................................................................................18 Figura 9. Importância do Product Backlog ........................................................................................19 Figura 10. Estimando o Product Backlog através do Planning Poker...............................................20 Figura 11. Estrutura de uma Sprint ....................................................................................................21 Figura 12. Planejamento da Sprint .....................................................................................................22 Figura 13. Controle da Sprint Backlog..............................................................................................23 Figura 14. Burndown Charts – dias/horas..........................................................................................24 Figura 15. Burndown Charts – Sprint /estimativa..............................................................................24 Figura 16. Diagrama de casos de uso do módulo Projeto ..................................................................32 Figura 17. Diagrama de casos de uso do módulo Product Backlog...................................................33 Figura 18. Diagrama de casos de uso do módulo controle de Sprint .................................................34 Figura 19. Diagrama de classes de domínio.......................................................................................35 Figura 20 - Diagrama de entidade-relacionamento do banco de dados .............................................37 Figura 21 - Framework ScriptCase ....................................................................................................38 Figura 22. Tela inicial ScriptCase ......................................................................................................39 Figura 23. Tela autenticação dos usuários na ferramenta ..................................................................40 Figura 24. Menu da ferramenta Scrum Project para o perfil Scrum Master. .....................................41 Figura 25. Menu da ferramenta Scrum Project para o perfil Scrum Time. ........................................41 Figura 26. Menu da ferramenta Scrum Project para o perfil Product Owner. ...................................42 Figura 27. Cadastro de usuários .........................................................................................................43 Figura 28 - Cadastro de times ............................................................................................................44 Figura 29 - Cadastro de projetos ........................................................................................................45 Figura 30 - Cadastro de Product Backlog ..........................................................................................46 Figura 31 - Cadastro de Sprint Backlog .............................................................................................47 Figura 32 - Cadastro da Reunião de Planejamento ............................................................................48 Figura 33 - Informar reunião diária....................................................................................................49 Figura 34 - Informar reunião de revisão.............................................................................................50 Figura 35 - Informar reunião de retrospectiva ...................................................................................51 Figura 36 - Consulta Sprint Backlog..................................................................................................52
vi
LISTA DE TABELAS
Tabela 1. Funcionalidades dos Softwares Avaliados e da Ferramenta Proposta ...............................27 Tabela 2. Características Gerais dos Softwares Avaliados e da Ferramenta Proposta ......................28
vii
RESUMO
Kluge, Monike Roberta. Scrum Project: ferramenta de apoio ao gerenciamento de projetos de software baseados nos princípios da metodologia ágil Scrum. Itajaí, 2008. 81 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2009. A área de Gerenciamento de Projetos há muito tempo, vem enfrentando problemas relativos a atrasos na entrega de projetos, orçamento extrapolado e insatisfação de clientes e usuários. Visando a atingir melhores resultados, as empresas estão adotando metodologias de desenvolvimento de software flexíveis a mudanças e que propiciem maior interação entre cliente e desenvolvedor. Essas metodologias, chamadas de “ágeis”, surgiram em oposição às metodologias tradicionais, orientadas para a produção de documentação. Entre as metodologias ágeis, destaca-se o Scrum, uma metodologia que tem, por objetivo, definir um processo de desenvolvimento de software de forma iterativa incremental e que pode ser aplicado no gerenciamento de atividades e desenvolvimento de novos produtos. Este Trabalho de Conclusão de Curso (TCC) apresenta o desenvolvimento de uma ferramenta de gerenciamento de projetos, denominada Scrum Project, que implementa os artefatos do Scrum e propicia o gerenciamento de projetos de forma ágil e flexível. Palavras-chave: Gerenciamento de Projetos. Metodologias Ágeis. Scrum.
viii
ABSTRACT
Since a long time, area of Project Management has been facing problems related to delays in delivering projects, exceeded budget, and dissatisfaction of customers and users. Seeking for achieving the best results, the companies are adopting methodologies of software development, which are flexible to changes and that may provide a greater interaction between the customer and the developer. These methodologies, called "agile", emerged opposing to traditional methodologies, which are geared towards the production of documentation. Among agile methodologies, one highlight is the Scrum, a methodology which aims at defining a process for software development in an iterative, incremental way that may be applied to the activities management and the development of new products. This Final Work presents the development of a tool for the projects management, called the Scrum Project, which implements the Scrum's artifacts and makes the projects management more agile and flexible.
Keywords: Project Management. Agile Methodologies. Scrum.
1 INTRODUÇÃO
O desafio constante da área de Engenharia de Software é melhorar o processo de
desenvolvimento de software. Apesar da crescente evolução das técnicas, métodos e ferramentas, a
entrega de softwares no prazo e custo pré-estabelecidos nem sempre é possível. Vários são os
fatores que podem influenciar esse atraso, tais como: mudanças de escopo, saída de pessoas
importantes, excesso de formalização da documentação, programadores inexperientes, alta taxa de
erros, falhas de critérios de qualidade entre outros (COSTA FILHO et al, 2005).
O sucesso na entrega de softwares é algo difícil de ser realizado. Desde 1994, o Standish
Group International publica a cada dois anos um estudo nomeado de Chaos Research que
consolida as informações de uma pesquisa sobre sucessos e fracassos dos projetos de software
desenvolvidos com as mais diversas metodologias. Na última pesquisa divulgada (STANDISH,
2008) foram apontadas as seguintes conclusões:
• Em 1998, o número de projetos que terminaram no prazo, dentro do orçamento e
atendendo aos requisitos do cliente era de 26%. Em 2006, o número de projetos
aumentou para 35%;
• Em 1998 e 2008, o número de projetos finalizados e com software operacional entregue
foi mensurado em 46%, porém nesses projetos, o orçamento e o prazo ultrapassam os
limites estipulados; e
• Em 1998, o número de projetos cancelados era de 28%. Em 2008, esse número reduziu
para 19%.
Apesar do aumento significativo no número de projetos bem sucedidos, as somas da
porcentagem dos projetos fracassados e comprometidos equivalem a 65% do total de projetos. Um
aspecto que contribui para esse número é o fato de que a maior parte dos projetos desenvolvidos é
baseada em metodologias tradicionais (FOWLER, 2003; LARMAN, 2004, apud COSTA FILHO et
al, 2005). Segundo Soares (2004) os processos tradicionais, muito orientados para a produção de
documentação, podem tornar-se fatores limitadores de desenvolvimento, dado que muitas
organizações não possuem recursos e conhecimento para adotar processos complexos de produção
de software.
As metodologias tradicionais são aplicadas em situações em que os requisitos do sistema são
estáveis com evoluções futuras previsíveis. Entretanto, muitos projetos caracterizam-se por
2
requisitos dinâmicos, estando sujeitos a freqüentes mudanças resultantes da dinâmica da
organização (SOUZA NETO, 2004).
Em oposição às metodologias tradicionais surgiram as Metodologias Ágeis, que
proporcionam um desenvolvimento de software mais rápido, atendendo os requisitos do cliente, no
prazo e custo e ainda permitem modificações à medida que novas necessidades surgem (COSTA
FILHO et al, 2005). Segundo Soares (2004), ao contrário das metodologias tradicionais, as
metodologias ágeis surgiram com a proposta de aumentar o foco nas pessoas e não no processo de
desenvolvimento, além disso, existe a preocupação de gastar menos tempo com documentação e
mais na resolução de problemas de forma iterativa.
Entre as metodologias ágeis destaca-se o Scrum. Segundo Schwaber e Beedle (2002, apud
PEREIRA, 2005), o Scrum é um processo iterativo e incremental de desenvolvimento de software.
Utiliza técnicas simples unidas ao senso comum e baseadas em experiências passadas, já testadas e
aprovadas. O uso do Scrum vai de encontro com a necessidade de pequenas empresas de
desenvolvimento de software, pelo fato de ser simples, ágil e com o mínimo de burocracia.
O uso da metodologia Scrum deve ser facilitado através da utilização de uma ferramenta que
forneça o apoio necessário no desenvolvimento das atividades envolvidas nesse processo. Pelo fato
do uso de metodologias ágeis serem um assunto relativamente novo, existem poucas ferramentas
disponíveis que suportam o processo ágil de desenvolvimento utilizando Scrum. As ferramentas
existentes no mercado são desenvolvidas em inglês e algumas não contemplam todas as
funcionalidades definidas pelo Scrum.
Diante desse cenário, esse trabalho propõe o desenvolvimento de uma ferramenta de apoio
ao gerenciamento de projetos de software baseados nos princípios da metodologia ágil Scrum. Essa
ferramenta deverá auxiliar os analistas e desenvolvedores de sistemas na implantação do Scrum de
forma ágil e rápida, possibilitando ao gerente do projeto obter maior controle, integração entre
cliente e desenvolvedor, acompanhar cada fase do projeto e possibilidade de alterar o escopo no
momento em que necessite.
1.1 PROBLEMATIZAÇÃO
1.1.1 Formulação do Problema
As empresas de software estão utilizando o Scrum como metodologia para gerenciamento de
projetos, porém a inexistência de uma ferramenta que contemple os artefatos do Scrum obriga as
empresas a gerenciarem seus projetos de forma manual, através de quadros informativos
3
preenchidos com post-its. As ferramentas existentes no mercado são desenvolvidas em inglês e
algumas não contemplam todas as funcionalidades do Scrum. Já as ferramentas mais completas são
pagas.
1.1.2 Solução Proposta
A solução proposta nesse projeto é o desenvolvimento de uma ferramenta que apóie o
desenvolvimento de projetos utilizando a metodologia Scrum. Essa ferramenta foi desenvolvida em
português, baseada em software livre e de código fonte aberto para que outros desenvolvedores
possam adaptá-la e atender as necessidades de sua empresa.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
Desenvolver uma ferramenta para gerenciamento de projetos baseada na metodologia ágil
Scrum.
1.2.2 Objetivos Específicos
Os objetivos específicos desse TCC são:
• Pesquisar e compreender detalhadamente a metodologia ágil Scrum;
• Pesquisar e analisar soluções de softwares similares;
• Estudar e aprender as ferramentas computacionais necessárias à implementação do
sistema;
• Realizar a modelagem conceitual da ferramenta;
• Implementar a ferramenta;
• Testar e validar a implementação da ferramenta; e
• Documentar o desenvolvimento.
1.3 Metodologia
Para o desenvolvimento da Fundamentação Teórica foram realizadas pesquisas buscando
compreender os principais conceitos referentes às Metodologias Tradicionais, Ágeis e Scrum. Essas
4
pesquisas foram mais intensas na Metodologia Scrum, visando entender sua estrutura e fluxo de
funcionamento. Foram estudadas algumas ferramentas existentes no mercado analisando suas
características e quais artefatos do Scrum as mesmas possuem implementados. Essas pesquisas
foram realizadas através de livros, artigos científicos, sites de busca e trabalhos acadêmicos.
O desenvolvimento do Projeto foi iniciado com uma análise de todos os requisitos que a
ferramenta deveria atender. Os requisitos foram identificados com base nas informações levantadas
sobre o Scrum e no levantamento de carências das ferramentas existente. Após a identificação dos
requisitos, foi realizada a modelagem do banco de dados, representada através de um diagrama
Entidade-Relacionamento.
Por último, foi descrito a implementação da ferramenta. As telas que a mesma apresenta
suas funcionalidades e como é possível o gerenciamento de projetos através dessa ferramenta.
1.4 Estrutura do trabalho
Este projeto esta estruturado em cinco capítulos: (i) Introdução; (ii) Fundamentação Teórica;
(iii) Projeto; (iv) Desenvolvimento; e (v) Conclusões.
O Capítulo 1 (Introdução) apresentou uma visão geral sobre o projeto desenvolvido, o
problema encontrado e qual a solução proposta, os objetivos do TCC e sua metodologia de
desenvolvimento.
O Capítulo 2 (Fundamentação Teórica) apresenta conceitos dos temas necessários para o
desenvolvimento do projeto: Processos de Software, Metodologias Tradicionais, Metodologias
Ágeis, Scrum e estudo sobre as Ferramentas similares disponíveis.
O Capítulo 3 (Projeto) especifica o projeto detalhado da ferramenta desenvolvida, incluindo
requisitos elicitados, casos de uso, diagrama de classes e modelagem do banco de dados.
O Capítulo 4 (Desenvolvimento) descreve como a ferramenta foi implementa, ilustrando
suas telas e funcionalidades.
O Capítulo 5 (Conclusões) apresenta as considerações finais do trabalho desenvolvido,
dificuldades encontradas e sugestões de melhorias a serem realizadas na ferramenta com de intuito
de dar continuidade ao trabalho.
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo é apresentada a revisão bibliográfica sobre o tema base desse presente
projeto: a metodologia ágil Scrum. A seção 2.1 apresenta uma visão sobre processo de software
expondo seu conceito e a diferença entre processo e método. Na seção 2.2 é apresentada uma breve
discussão sobre metodologias tradicionais, expondo suas características, vantagens e desvantagens
do seu uso. A seção 2.3 apresenta informações sobre as metodologias ágeis, expondo suas
vantagens de utilização, crescimento de uso e principais características. Por fim, a seção 2.4
apresenta a metodologia ágil Scrum, suas características, sua relação com o Manifesto Ágil, seu
funcionamento e as ferramentas utilizadas.
2.1 Processos de Software
A engenharia de software é uma disciplina relacionada com os aspectos de produção de
software, desde os estágios iniciais de especificação do sistema até sua manutenção (HELDMAN,
2005). Segundo Pressman (2006), a engenharia de software é dividida em camadas e tem como
principal foco a qualidade do produto final gerado. A Figura 1 ilustra a divisão da engenharia de
software.
Figura 1. Camadas da Engenharia de Software
Fonte: Adaptado de Pressman (2006).
A primeira camada da engenharia de software se refere às ferramentas que fornecem apoio
automatizado ou semi-automatizado para os processos e métodos. Segundo Pressman (1995, p. 32)
“quando as ferramentas são integradas de forma que a informação criada por uma ferramenta possa
6
ser usada por outra, é estabelecido um suporte ao desenvolvimento de software chamado engenharia
de software auxiliada por computador - CASE”. As ferramentas CASE auxiliam as atividades de
engenharia de processos, desde análise de requisitos e modelagem até programação e testes.
A camada de métodos de engenharia de software é uma representação abstrata das
atividades, modelos e artefatos, “fornecem a técnica de como fazer para construir software”
(PRESSMAN, 2006, p. 18), englobando um conjunto de tarefas que inclui análise de requisitos,
projeto, construção de programas, teste e manutenção. Os métodos orientam os processos
recomendando práticas mais adequadas e atividades a serem seguidas.
O alicerce da engenharia de software é a camada de processo. O processo de engenharia de
software é um conjunto de atividades realizadas por pessoas, cujo objetivo é o desenvolvimento ou
aperfeiçoamento de um software e sua documentação (LEITE, 2008). Segundo Jacobson (apud
PRESSMAN, 2006, p.19), “um processo define quem está fazendo o quê, quando e como alcançar
um certo objetivo”.
De acordo com Sommerville (2007), existem quatro atividades fundamentais que são
comuns a todos os processos de software:
1. Especificação de software: clientes e engenheiros definem o software a ser produzido e
suas restrições;
2. Desenvolvimento de software: o software é projetado e programado;
3. Validação de software: o software é verificado para garantir que atende o que o cliente
deseja; e
4. Manutenção de software: o software é adaptado para atender as modificações do cliente
e do mercado.
Por fim, a base para todas as camadas da Engenharia de Software é o foco na qualidade do
produto final gerado. A engenharia fornece métodos, processos e ferramentas de forma que o
gerente de projeto possa garantir que o software será gerado com a qualidade desejada.
Os processos de software são complexos e dependem da visão do gerente do projeto e do
tipo de software que se deseja construir. Cada software, dependendo de sua finalidade, exige um
processo de desenvolvimento diferente e, apesar da diversidade de modelos de processos de
7
software, não existe um processo ideal, forçando as empresas a realizarem adaptações para atender
suas demandas de desenvolvimento. Alguns sistemas críticos necessitam de um processo de
desenvolvimento estruturado, ou ditos burocráticos, outros sistemas de negócio possuem requisitos
que mudam rapidamente exigindo um processo flexível e ágil (SOMMERVILLE, 2007). Dentre os
processos de softwares existentes, podem ser citadas as metodologias tradicionais, que são
orientadas a documentação, e as metodologias ágeis, que procuram desenvolver software com o
mínimo de documentação (SOARES, 2004).
2.2 Metodologias Tradicionais
As metodologias tradicionais surgiram em um contexto de desenvolvimento de software
muito diferente do atual, baseado apenas em um mainframe e terminais burros1. Na época o custo
para realizar alterações e correções em programas era muito elevado, uma vez que o acesso aos
computadores era limitado e não existiam ferramentas como depuradores e analisadores de código.
Por isso o software era planejado por inteiro, documentado e por último programado (ROYCE,
1970, apud SOARES, 2004).
A maior parte dos projetos, que utilizam metodologia tradicional, baseiam-se no modelo em
cascata. A principal característica desse modelo é a separação das fases do projeto, que consistem
em: levantamento de requisitos, modelagem, implementação, testes e implantação. Nesse modelo
uma fase só inicia quando a anterior estiver pronta (RIBEIRO, 2008). A Figura 2 ilustra as fases do
modelo em cascata e a dependência entre elas.
1 O termo terminal burro refere-se a terminais formados apenas por vídeo e teclado, que não possuem unidade de armazenamento e nem poder de processamento, ficando interconectados a um computador central, chamado de mainframe. Disponível em < http://www.versoereverso.unisinos.br/index.php?e=2&s=9&a=13 > Acesso em 10 jan. 2008.
8
Figura 2. Modelo em Cascata
Fonte: Adaptado de Sommerville (2007).
O modelo em cascata gera questionamentos com relação a sua eficácia, pois dificulta o
controle do projeto. Entre os problemas encontrados no modelo em cascata estão (PRESSMAN,
2006):
• Projetos reais dificilmente seguem o fluxo seqüencial que o modelo propõe. A natureza
linear do modelo em cascata leva a “estados de bloqueio”, nos quais alguns membros da
equipe do projeto precisam esperar que outros membros terminem as atividades
pendentes;
• Em geral, é difícil para o cliente definir todo o escopo do projeto na fase de
levantamento de requisitos. O modelo em cascata exige isso e tem dificuldade para
reagir com mudanças no escopo, pois a cada alteração é necessário retornar ao início do
projeto para modificar a documentação; e
• A versão executável do projeto somente fica disponível no final do projeto.
A vantagem do modelo em cascata é a documentação produzida em cada fase, porém esse
modelo deve ser usado em projetos onde os requisitos são bem compreendidos e haja pouca
probabilidade de mudanças durante o desenvolvimento do sistema (SOMMERVILLE, 2007).
Como proposta para solucionar os problemas do modelo em cascata surgiu o Processo
Unificado. Ivar Jacobson, Grady Booch e James Rumbaugh (apud PRESSMAN, 2006, p. 51)
9
discutem a necessidade de um processo de software “guiado por casos de uso, centrado na
arquitetura, iterativo e incremental” quando afirmam:
Hoje, a tendência em software é em direção a sistemas maiores, mais complexos. Isso se deve, em parte, ao fato de que computadores têm se tornado mais potentes a cada ano, levando os usuários a esperar mais deles. Essa tendência tem também sido influenciada pelo uso da internet, que está se expandindo, para trocar toda espécie de informação... Nosso apetite por softwares cada vez mais sofisticados cresce à medida que aprendemos de uma versão de um produto para a seguinte como o produto poderia ser aperfeiçoado. Desejamos softwares que sejam melhor adaptados às nossas necessidades, mas que, por sua vez, não torne o software somente mais complexo. Em resumo, desejamos mais.
Um produto comercial baseado no processo unificado é o RUP (Rational Unified Process).
O RUP, desenvolvido pela empresa Rational Software Corporation, é considerado um framework
genérico que engloba as melhores práticas de mercado. Segundo Sommerville (2007), o RUP “é um
exemplo de modelo de processo moderno que foi derivado do trabalho sobre a UML e do Processo
Unificado de Desenvolvimento associado”. O objetivo do RUP é descrever um software usando
técnicas comerciais visando aumentar a qualidade dos softwares gerados. Está fundamentado em
três princípios básicos:
• Iterativo e Incremental;
• Guiado por casos de uso; e
• Baseado na arquitetura do sistema.
O RUP é um modelo constituído por quatro fases que compõem o processo de
desenvolvimento (FERREIRA, 2007):
1. Iniciação: nessa fase é estabelecido o escopo do projeto e suas fronteiras, determinando
os principais casos de uso do sistema. Esses casos de uso devem ser elaborados com a
precisão necessária para se proceder estimativas de prazos e custos.
2. Elaboração: o propósito nessa fase é analisar mais detalhadamente o domínio do
problema, estabelecer uma arquitetura de fundação sólida, desenvolver um plano de
projeto para o sistema a ser construído e eliminar os elementos que oferecem maior
risco. Os elementos de risco a serem analisados, nesta fase, são os riscos de requisitos,
tecnológicos, de recursos e políticos. Essa fase é a mais crítica de todas, pois ao final
dessa fase a engenharia é considerada completa e os custos para modificação do sistema
aumentam à medida que o projeto avança.
10
3. Construção: essa fase compreende a modelagem e desenvolvimento do sistema, tendo
como base a arquitetura entregue na fase anterior. Essa fase geralmente é composta por
diversas iterações, onde ao final de cada iteração tem uma parte executável do produto.
4. Transição: o objetivo dessa fase é assegurar que o software esteja disponível para a
comunidade de usuários. Os usuários testam o software e geram relatórios contendo
defeitos e modificações necessárias. Além disso, a equipe cria informações de apoio
necessárias aos usuários (manual do usuário e procedimento de instalação).
A Figura 3 ilustra as fases do desenvolvimento do RUP e as atividades desenvolvidas em
cada fase.
Figura 3. Fases do RUP
Fonte: Ferreira (2007).
No RUP as fases de desenvolvimento não ocorrem em seqüência, mas em paralelo. Isso
significa que ao mesmo tempo em que as fases de elaboração, construção e transição estão sendo
realizadas, uma nova fase de incremento de software já foi iniciada. (PRESSMAN, 2006).
Embora o RUP represente uma nova geração de processos genéricos, ele não é um processo
adequado a todos os tipos de desenvolvimento. Para projetos de software pequenos o RUP é um
processo complexo e trabalhoso devido à quantidade de documentação gerada (SOMMERVILLE,
2007).
11
2.3 Metodologias Ágeis
Atualmente os negócios operam em um ambiente global sujeito a rápidas mudanças. Eles
têm de responder rapidamente às mudanças econômicas, oportunidades de mercado e ao surgimento
de novos produtos e serviços. O software é parte integrante das operações de negócio, sendo assim,
é essencial que o software seja desenvolvido ou modificado de forma rápida e eficiente para suprir
as novas necessidades impostas pelos avanços do mercado (SOMMERVILLE, 2007).
Segundo Sommerville (2007, p.260):
Os processos de desenvolvimento de software baseados em especificações completas de requisitos, projeto, construção e teste não estão voltados para o desenvolvimento rápido de software. Quando os requisitos são alterados ou quando problemas com requisitos são descobertos, o projeto ou implementação precisa ser refeito e testado novamente. Como conseqüência, um processo em cascata ou baseado em especificações é geralmente prolongado e a versão final do software é entregue para o cliente muito tempo depois dos requisitos serem definidos, o que poderá tornar o software inútil.
Para enfrentar esses desafios encontrados pelos desenvolvedores de software, um grupo de
17 metodologistas formou a Agile Software Development Alliance, freqüentemente citada apenas
como Agile Alliance, em fevereiro de 2001. Esse grupo de pessoas definiu um manifesto com as
melhoras práticas de desenvolvimento de software e, com base nesse manifesto formulou um
conjunto de princípios que definem critérios para o desenvolvimento ágil de software, a partir
dessas definições surgiu o termo Metodologia Ágil (AGILE MANIFESTO, 2008). Os conceitos do
Manifesto Ágil são (AMBLER, 2004):
• Indivíduos e interações ao invés de processos e ferramentas;
• Software executável ao invés de documentação;
• Colaboração do cliente ao invés de negociação de contratos; e
• Respostas rápidas a mudanças ao invés de seguir planos.
O Manifesto Ágil não rejeita processos, ferramentas, documentação e planejamento, mas
mostra que eles têm importância secundária quando comparado com indivíduos e interações, com o
software estar executando corretamente, com a colaboração do cliente e as respostas rápidas a
mudanças e alterações (SOUZA NETO, 2004). O conceito de metodologia ágil é mais adequado
para a execução de projetos de curta duração em pequenas e médias empresas.
Entre os métodos ágeis existentes podem-se citar: Extreme Programming (XP), Scrum,
Dynamic System Development Method (DSDM), Adaptive Software Development (ASD), Crystal,
12
Feature Driven Development (FDD) e Lean Development. Uma pesquisa realizada sobre o estado
do desenvolvimento ágil indica que 40% dos entrevistados utilizam Scrum como metodologia base
(VERSIONONE, 2007 apud TAVARES, 2008). A Figura 4 mostra o percentual de adoção do
Scrum quando comparado com outras metodologias ágeis.
Figura 4. Adoção do Scrum
Fonte: Yoshima (2007).
Métodos, práticas e técnicas para o desenvolvimento ágil de projetos prometem aumentar a
satisfação do cliente (BOEHM, 2003) para produzir alta qualidade de software e para acelerar os
prazos de desenvolvimento de projetos. Empresas como a Rede Globo de televisão, Microsoft,
Google, Yahoo, Nokia, BBC, CESAR, Philips, adotaram o Scrum para desenvolvimento de
software e o resultado obtido foi vantajoso (BERNABO, 2007).
O Scrum é um método ágil que vem ganhando grande visibilidade nos últimos cinco anos,
em projetos de desenvolvimento de software, ressaltando benefícios como comprometimento da
equipe, motivação, colaboração, integração e compartilhamento de conhecimento, o que facilita em
muito o gerenciamento e sucesso dos projetos (SCHWABER, 2004, apud MARÇAL et al., 2007).
Por esses motivos, este método foi escolhido como objeto de estudo deste trabalho de conclusão de
curso e é melhor detalhado nos itens a seguir.
2.4 Scrum
O Scrum é uma metodologia ágil utilizada para gerenciar e controlar o desenvolvimento de
software utilizando práticas iterativas e incrementais. Baseado nas práticas de gerenciamento do
13
Extreme Programming e no RUP, o Scrum produz os benefícios do desenvolvimento ágil com a
vantagem de ser uma implementação simples (YOSHIMA, 2007).
Inicialmente o Scrum foi concebido como um estilo de gerenciamento de projetos, em
empresas de fabricação de automóveis e produtos de consumo, por Hirotaka Takeuchi e Ikujiro
Nonaka no livro “The New Product Development Game” (Harvard Business Review, 1986). Eles
notaram que projetos usando equipes pequenas e multidisciplinares produziam os melhores
resultados, e associaram estas equipes altamente eficazes à formação do Scrum no Rugby2. A
primeira experiência reconhecida do Scrum foi realizada em 1993 por Jeff Shuterland que
implementou em sua organização, a Easel Corporation, um processo baseado na formação do
Rugby e nos estudos de Nanaka e Takeuchi. Em 1995, Ken Schwaber formalizou a definição do
Scrum e ajudou a implantá-lo em desenvolvimento de software (MACEDO e DESCHAMPS,
2008).
Scrum é uma metodologia objetiva, com papéis bem definidos e de fácil adaptação. Segundo
o seu autor Schwaber (2004, apud MARÇAL et al., 2007) o Scrum “não é um processo previsível,
ele não diz exatamente o que fazer, não irá resolver todos os problemas, mas com certeza os
problemas serão mais facilmente identificados através do framework e do conjunto de práticas
oferecidos”.
O framework do Scrum é composto em papéis, cerimônias e artefatos. A Figura 5 ilustra as
atividades que compõe cada item do framework.
2 Rugby é um jogo praticado na Inglaterra, composto por oito jogadores em cada time. O Scrum é um termo utilizado no Rugby e consiste em colocar a bola em jogo novamente através do trabalho em equipe.
14
Figura 5. Framework do Scrum
Fonte: Bernabo (2007).
2.4.1 Papéis no Scrum
O Scrum, como qualquer outra metodologia, é baseado em papéis e responsabilidades,
sendo, estas mais abrangentes e direcionadas para atingir o sucesso do projeto (YOSHIMA, 2007).
A metodologia Scrum define basicamente três papéis: Product Owner, Scrum Master e Scrum
Team, apresentados a seguir (MARÇAL et al., 2007).
2.4.1.1 Product Owner
Product Owner significa dono do produto. É o cliente ou um importante interessado do
projeto, que representa os interesses de todos os envolvidos com o software. Suas principais
responsabilidades são (MARÇAL et al., 2007):
• Definir as características e funcionalidades do produto;
• Concentrar as informações vindas das pessoas envolvidas no projeto ou do mercado, de
maneira que se obtenha uma visão única dos requisitos do sistema;
• A maior responsabilidade é o ROI (Return on Investment) do projeto;
• Priorizar as funcionalidades do projeto de acordo com as necessidades dos usuários;
• Solicitar alterações a serem implementadas nas próximas iterações; e
• Aceitar ou rejeitar os resultados de cada iteração.
15
2.4.1.2 Scrum Master
O Scrum Master desempenha um papel de liderança, gerenciando os interesses do Product
Owner mediante o time. Comparando com uma abordagem tradicional de gerenciamento de
projetos, o Scrum Master seria um gerente de projetos. O Scrum Master possui como
responsabilidades (YOSHIMA, 2007):
• Promover a criatividade e conhecimento do time visando aumento de produtividade;
• Estimular uma comunicação cooperação entre as pessoas do time;
• Garantir o desenvolvimento do projeto no prazo e custo;
• Realizar reuniões de acompanhamento (Daily Scrum, Sprint, Review e Sprint
Retrospective);
• Auxiliar o Product Owner a maximizar a produtividade atingindo os seus objetivos com
o Scrum;
• Facilitar a colaboração entre as funções e áreas e eliminar os impedimentos do time;
• Proteger o time de interferências externas;
• Controlar as tarefas realizadas, em andamento, concluídas e o surgimento de novas
tarefas; e
• Atualizar o Burndown Chart.
2.4.1.3 Scrum Team
O Scrum Team é um grupo de pessoas responsável em desenvolver as funcionalidades do
projeto. Suas características são (MARÇAL et al., 2007):
• Multi-funcional e auto-organizável. O time deve ter capacidade e o conhecimento
técnico sobre todo o processo de desenvolvimento do produto;
• Entre 7 a 9 pessoas;
• Seleciona, entre os itens priorizados, os que serão executados durante cada iteração; e
• Demonstra as funcionalidades do produto e os resultados obtidos ao Product Ower.
16
2.4.2 Estrutura do Processo Scrum
O Scrum define conceitos importantes referentes à aplicação da metodologia no
desenvolvimento do projeto. Esses conceitos fundamentam práticas para definir a estratégia de
desenvolvimento do projeto e fornecem visibilidade do andamento dos trabalhos e previsibilidade
do que acontecerá. A Figura 6 ilustra o fluxo de desenvolvimento no Scrum (YOSHIMA, 2007).
O fluxo no Scrum inicia com a definição da lista de funcionalidades que deverão ser
implementadas, essa lista é chamada de Product Backlog. Para cada iteração ou Sprint, é realizada
uma reunião inicial de planejamento chamada de Sprint Planning Meeting, onde os itens desta lista
são priorizados pelo cliente, no Scrum chamado de Product Owner. A equipe define quais
funcionalidades poderão ser atendidas dentro da iteração de acordo com a capacidade da mesma.
Essa lista planejada para a iteração é chamada de Sprint Backlog (TAVARES, 2008).
Diariamente, durante a Sprint, a equipe faz uma reunião chamada Daily Meeting que ajuda a
manter a comunicação do time sobre o andamento do projeto, disseminar conhecimento e identificar
impedimentos. No final de cada Sprint, na reunião chamada Sprint Review, a equipe apresenta as
funcionalidades que foram desenvolvidas durante a Sprint. Esse ciclo se repete várias vezes até que
o Product Backlog seja atendido (TAVARES, 2008). Esses conceitos são melhor apresentados na
seções a seguir.
Figura 6. Fluxo do Scrum
Fonte: Pereira (2008).
17
2.4.2.1 Sprint
O Scrum é baseado em iterações chamadas de Sprints. As Sprints podem ter de duas a
quatro semanas de duração e, ao final desse período uma parte do projeto é demonstrada ao Scrum
Owner. Essa demonstração é importante para avaliar o andamento do projeto, verificar se os
requisitos exigidos estão sendo desenvolvidos e avaliar a produtividade da equipe (MARÇAL et al.,
2007).
2.4.2.2 Time Boxing
O Time Boxing é todo um espaço de tempo definido e cronometrado que faz com que a
equipe se concentre nas atividades importantes, sem gastar tempo com tarefas desnecessárias para o
objetivo. Por exemplo, um Sprint com período de 30 dias ou reuniões diárias de 15 minutos
representam um Time Box, ou seja, o tempo definido para execução de cada tarefa no Scrum
(YOSHIMA, 2007).
2.4.2.3 Product Backlog
O conceito mais importante no Scrum é o Backlog do produto (Product Backlog). O Product
Backlog contém uma lista de itens definidos e priorizados pelo Product Owner, que incluem os
requisitos funcionais e não funcionais de um sistema. Os itens do Product Backlog são chamados de
histórias e todos os envolvidos no projeto podem inclui-lás, porém somente o Product Owner pode
priorizá-las. Essa lista não precisa ser definida por completa no início do projeto, podendo ser
complementada com novas funcionalidades à medida que aumenta o conhecimento no produto.
Normalmente, no início do projeto, essa lista contém somente os itens necessários para o
desenvolvimento do primeiro Sprint. A ordenação da lista Product Backlog é por ordem de
prioridade, ou seja, no topo da lista estão os itens mais prioritários (TAVARES, 2008).
Outro item importante do Scrum é o Backlog de Impedimentos (Impediment Backlog), uma
lista que contém todos os itens que impedem o progresso do projeto e geralmente estão associados a
riscos. Estes itens não possuem uma priorização, mas estão associados a algum item de Backlog do
produto ou a tarefas do item. O Scrum Master deve ter controle sobre esses itens, possibilitando ao
time desenvolver o Backlog do produto sem impedimentos (MARÇAL et al., 2007).
A Figura 7 exemplifica itens do Product Backlog que deverão ser priorizados e estimados
pelo Product Owner e pela equipe do projeto respectivamente.
18
Figura 7. Product Backlog
Fonte: Albuquerque (2007).
2.4.2.4 Priorização do Product Backlog pelo Product Owner
Após o desenvolvimento do Backlog do Produto os itens devem ser priorizados. A Figura 8
ilustra um exemplo de priorização baseado na importância dos itens do Backlog para o Product
Owner. Esse método de priorização é nomeado por alguns autores como método MoSCoW – Must,
Should, Could, Want, e consiste em numerar os requisitos de acordo com sua importância
(ALBUQUERQUE, 2007).
Figura 8. Priorização do Product Backlog
Fonte: Albuquerque (2007).
19
Outra forma de priorizar os requisitos consiste em numerar os itens de acordo com a sua
importância. A Figura 9 ilustra a importância dos requisitos usados como exemplo na Figura 8 (os
itens de menor valor são os mais importantes).
Figura 9. Importância do Product Backlog
Fonte: Albuquerque (2007).
2.4.2.5 Estimativa do Product Backlog
Antes de iniciar a reunião do planejamento é preciso ter o Backlog priorizado e estimado.
Uma técnica objetiva é o Planning Poker que pode ser usada onde a estimativa pode ser feita em
horas/tamanho (MARÇAL et al., 2007).
O Planning Poker é uma forma de estimativa em conjunto, podendo ser feita como um jogo.
Todos os membros do time, inclusive o Product Owner, participam de forma democrática para
chegar a um consenso de estimativa, para cada item do Backlog.
O primeiro passo do jogo é fornecer para cada membro da equipe um conjunto de cartas
baseado na seqüência numérica de Fibonacci (1,2,3,5,8,13,..). A escolha dessa seqüência esta ligada
aos gaps que são maiores à medida que os números aumentam, ou seja, os números maiores têm
menos granularidade, deixando visível a diferença entre os itens à medida que eles se distanciam
(ALBUQUERQUE, 2007).
O jogo é iniciado selecionando o item do Backlog que o Product Owner e o time acreditam
que seja o mais fácil de implementar, e a ele é associado o menor número da seqüência. Depois o
próximo item é selecionado, e é comparando o seu grau de dificuldade com os dos itens já
estimados. Nesse momento cada membro da equipe seleciona uma carta que represente o grau de
dificuldade associado ao item e espera até que os outros participantes terminem suas seleções.
20
Quando todos terminaram as cartas são exibidas e se houver um consenso geral nas seleções
feitas, o número da carta que corresponde ao tamanho é associado ao item. Em caso de divergência,
é necessário que os participantes expliquem o motivo de sua escolha, para que todos possam
repensar e validar a sua escolha. Após a finalização dessa discussão, uma nova rodada é realizada
para que todos tenham oportunidade de reavaliar seus julgamentos. Esse processo continua até que
os membros participantes seguem em um consenso. O Scrum Master é responsável em organizar as
discussões para que sejam produtivas e organizadas. Esse ciclo é seguido até que todos os itens do
Backlog sejam estimados (MARÇAL et al., 2007).
A Figura 10 ilustra uma equipe estimando, através do Planning Poker, valores para cada
história do Product Backlog.
Figura 10. Estimando o Product Backlog através do Planning Poker
Fonte: Pereira (2008).
2.4.2.6 Sprint Backlog
É uma lista que contém as tarefas que o Scrum Team irá trabalhar durante a Sprint. Os itens
do Product Backlog, priorizados pelo Product Owner, são quebrados em tarefas que formam o
Sprint Backlog. Cada tarefa deve ser estimada pela equipe quanto ao número de horas necessário
para completá-la, normalmente as tarefas são completadas em até 16 horas. É responsabilidade da
equipe manter a lista atualizada diariamente com as tarefas concluídas, e a estimativa de tempo
necessário para a conclusão das tarefas em andamento (TAVARES, 2008).
21
2.4.2.7 Execução da Sprint
Uma Sprint inicia com um dia de planejamento que ocorre em duas partes. Nesse dia todos
os envolvidos no projeto planejam quais serão os objetivos a serem realizados nos próximos 28 dias
(caso a Sprint tenha 30 dias). Após o planejamento a equipe trabalha no desenvolvimento do
projeto. No último dia da Sprint, o produto desenvolvido pelo time é avaliado juntamente com o
Product Owner e uma reunião de Retrospectiva é realizada, com o intuito de discutir as lições
apreendidas e definir ajustes necessários ao processo. A Figura 11 ilustra a estrutura de execução
de uma Sprint e seus conceitos são discutidos a seguir (YOSHIMA, 2007).
Figura 11. Estrutura de uma Sprint
Fonte: Yoshima (2007).
2.4.2.8 Planejamento da Sprint (Sprint Planning Meeting)
A reunião de planejamento da Sprint é a primeira reunião que ocorre e acontece em duas
partes, cada uma dela com Time-Box de quatro horas. Na primeira parte da reunião de planejamento
o Scrum Master reúne-se com o Product Owner para verificar qual é o Product Backlog, focando
no ROI (Retorno sobre Investimento) do projeto. Na segunda parte do planejamento o Scrum
Master se reúne com o time e com o Product Owner para planejar o Sprint Backlog. Para escolher
os itens que irão compor o Sprint Backlog a equipe estima o Product Backlog, definindo
complexidade e prazo das tarefas (YOSHIMA, 2007). A Figura 12 ilustra a Reunião de
Planejamento da Sprint e as atividades desenvolvidas em cada parte.
22
Figura 12. Planejamento da Sprint
Fonte: Pereira (2008).
2.4.2.9 Gerenciamento da Sprint Backlog
Durante a execução da Sprint, a alocação de recursos para cada tarefa é dirigida pelo próprio
time, cada membro da equipe seleciona as tarefas que podem realizar e o time estabelece a ordem e
dependência entre elas. Um fator importante de sucesso para o time com o uso do Scrum é o
controle da disciplina. O time é considerado auto-gerenciável, e deve responder como tal. Para isto
todos os membros do time devem reportar as horas utilizadas em tarefas para que o valor de horas
restantes seja calculado corretamente e o time possa verificar o seu progresso. Para esse
acompanhamento o time usa um gráfico chamado de Sprint Burndown. O Sprint Burndown exibe o
progresso diário do time em função do total de horas estabelecido e é explicado a seguir
(YOSHIMA, 2007).
A Figura 13 mostra uma maneira de controlar a execução dos itens da Sprint Backlog
através do uso de um “quadro de trabalho”. O objetivo é organizar as atividades dos itens do Sprint
Backlog em quatro estados: para fazer, em andamento, para verificar e concluído (MARÇAL et al.,
2007).
23
Figura 13. Controle da Sprint Backlog
Fonte: Pereira (2008).
2.4.2.10 Burndown Chart
O gráfico de Burndown é o principal artefato para acompanhamento do andamento da
Sprint. Ele é gerado com base nas atualizações diárias da equipe com o status das tarefas, e no
número de horas restantes para a conclusão de cada tarefa. A soma de horas das tarefas determina a
quantidade de horas necessárias para finalizar a Sprint, e conforme as tarefas são concluídas, o
gráfico vai decrescendo até atingir o número de horas zero. O eixo Y representa o número total de
horas estimado para a Sprint e o eixo X os dias da Sprint, de acordo com o seu tamanho. As Figura
14 e 15 representam exemplos de Burndown Charts (TAVARES, 2008).
24
Figura 14. Burndown Charts – dias/horas
Fonte: Pereira (2008).
Figura 15. Burndown Charts – Sprint /estimativa
Fonte: Albuquerque (2007).
2.4.2.11 Reunião Diária (Daily Meeting)
Durante a Sprint o time controla o progresso de execução das tarefas através de reuniões
diárias. Essa reunião é rápida, não mais do que 15 minutos, e o objetivo é fazer com que cada
membro do time responda as seguintes perguntas feitas pelo Scrum Master (ALBUQUERQUE,
2007):
• O que foi feito desde ontem?;
• O que você planeja fazer para amanhã?; e
25
• Você tem algum impedimento?.
A reunião tem por objetivo auxiliar o Scrum Master na verificação do andamento do
trabalho, manter a comunicação e sincronização do status do projeto entre os membros da equipe
(YOSHIMA, 2007).
2.4.2.12 Reunião de Revisão (Sprint Review)
A Sprint Review é um importante ponto de inspeção da metodologia Scrum. Essa reunião de
fechamento ocorre no último dia da Sprint e representa o momento em que a equipe e o Scrum
Master demonstram as funcionalidades implantadas ao Product Owner. Essa reunião é importante,
pois auxilia na correção de erros do projeto antes do início da nova Sprint (YOSHIMA, 2007).
2.4.2.13 Reunião de Retrospectiva (Sprint Retrospective)
Ao final de cada Sprint acontece a reunião de revisão. O objetivo dessa reunião é entregar o
produto e realizar uma demonstração para que o Product Owner possa verificar se o produto
produzido está de acordo com suas expectativas. Nessa reunião se discute como foi o
desenvolvimento da Sprint e o que precisa ser melhorado (ALBUQUERQUE, 2007).
2.4.3 Ciclo de Vida do Scrum
O ciclo de vida do Scrum é baseado em três fases (SOUZA NETO, 2004):
1. Pré-Planejamento (pre-game phase): nessa fase os requisitos são descritos e
priorizados no Product Backlog, a estimativa de esforço para cada requisito é realizada,
definição da equipe, definição das ferramentas de desenvolvimento e estimativa de
riscos do projeto;
2. Desenvolvimento (game phase): nessa fase ocorre o desenvolvimento iterativo e
incremental das funcionalidades do produto através de múltiplas Sprints, reuniões diárias
e de revisão; e
3. Pós- Planejamento (post-game phase): após a fase de desenvolvimento são realizadas
reuniões para analisar o progresso do projeto e demonstrar o software atual para o
26
Product Owner. Nessa fase são realizadas as etapas de integração, testes e
documentação.
2.4.4 Ferramentas
O uso do Scrum é recente, por isso o mercado dispõe de poucas ferramentas. Dentre as
ferramentas encontradas destacam-se:
1. Mingle;
2. Scrinch;
3. Scrum Works; e
4. ProjectKoach.
A Mingle é uma ferramenta desenvolvida pelo grupo ThoughtWorks3, uma empresa líder em
desenvolvimento ágil. Entre suas funcionalidades pode-se destacar: planejamento do projeto,
desenvolvimento do Product Backlog e Sprint Backlog, reuniões diárias e revisões, métricas de
acompanhamento utilizando Burndown Chart, controle de velocidade de desenvolvimento,
estimativas, entre outras. O Mingle é uma ótima ferramenta para gerenciamento de projetos com
Scrum, porém é desenvolvida em inglês e o valor de sua licença varia de acordo com o tempo de
uso e o número de usuários.
O Scrinch é uma ferramenta desenvolvida em Java e distribuída pela SourceFourge4. A
ferramenta é gratuita, porém desenvolvida em inglês e com interface de difícil utilização. Suas
funcionalidades contemplam: desenvolvimento do Product Backlog e Sprint Backlog, definição do
time de desenvolvedores, definição do Time Boxing da Sprint, controle de velocidade, priorização e
estimativa do Product Backlog, entre outras.
O ScrumWorks é uma ferramenta desenvolvida pela empresa Danube5. Existem duas
versões dessa ferramenta disponíveis: ScrumWorks Pro (versão paga) e Scrum Works Basic (versão
grátis). A ferramenta paga possui as funcionalidades básicas do Scrum, porém é desenvolvida em
inglês.
3 Mingle. Disponível em <http://studios.thoughtworks.com/mingle-agile-project-management/>. Acesso em 24 out. 2008. 4 Sprinch. Disponível em < http://sourceforge.net/projects/scrinch >. Acesso em 24 out. 2008. 5 Scrum Works. Disponível em <http://danube.com/scrumworks> Acesso em 24 out. 2008.
27
A ferramenta ProjectKoach é desenvolvida pela Good Software Inc6, é gratuita e de fácil
utilização, porém seu idioma é o inglês. Entre suas funcionalidades destacam-se: planejamento de
Sprints, inclusão de tarefas, estimativa de tempo de duração de cada tarefa e definição do time. Essa
ferramenta não contempla todas as funcionalidades do Scrum, como por exemplo, Burndown Chart,
reuniões diárias, revisão e planejamento da Sprint. Essa ferramenta evidencia o controle do escopo
do projeto.
Os softwares testados foram o Scrinch, o ProjectKoach e a versão grátis do Mingle. O
ScrumWorks Basic foi instalado, mas exige certificado de licença para o funcionamento pleno. Esse
certificado foi solicitado, porém a Danube não enviou a resposta com a autorização para utilização
do aplicativo.
As Tabela 1 e 2 demonstram a análise realizada com as principais funcionalidades avaliadas
e também requisitos não funcionais. Além dos softwares avaliados, a tabelas contêm a solução
proposta pelo presente TCC. O softwares ScrumWorks está sendo avaliado de acordo com as
informações fornecidas no site do aplicativo.
Tabela 1. Funcionalidades dos Softwares Avaliados e da Ferramenta Proposta
Ferramenta Criação de Sprints
Criação Product Backlog
Criação Sprint
Backlog
Prioriza estima
Tarefas
Criação de Time
Burndown
Chart
Mingle Sim Sim Sim Sim Não Sim Scrinch Sim Não Sim Sim Sim Sim Scrum Works
Sim Sim Sim Sim Sim Não Identificado
ProjectKoach Sim Não Sim Não Sim Não Ferramenta
Proposta Sim Sim Sim Sim Sim Não
6 ProjectKoach. Disponível em <http://www.projectkoach.com/>. Acesso em 24 out. 2008.
28
Tabela 2. Características Gerais dos Softwares Avaliados e da Ferramenta Proposta
Ferramenta Software Gratuito Plataforma Web Língua Portuguesa Mingle Não Sim Não Scrinch Sim Não Não Scrum Works Sim Sim Não ProjectKoach Sim Não Não Ferramenta Proposta
Sim Sim Sim
Através do estudo das ferramentas, foi possível identificar que as ferramentas disponíveis no
mercado não contemplam todas as atividades necessárias para gerenciamento de projetos utilizando
a metodologia Scrum. A ferramenta proposta, além de conter todos os artefatos do Scrum, tem
como diferencial as seguintes características: será um software gratuito, código fonte aberto,
voltado para a web e na língua portuguesa.
29
3 PROJETO
A primeira atividade realizada durante a fase de Projeto foi a análise dos requisitos
funcionais, não funcionais e regras de negócio que devem ser atendidos pela ferramenta. Os
requisitos foram levantados com base na fundamentação teórica e no estudo das ferramentas
similares, realizada no Capítulo 2.
Em seguida, os casos de uso foram definidos com base nas principais operações
desenvolvidas pelo usuário. Por últimos os diagramas de classes e entidade-relacionamento foram
construídos.
3.1 Análise de Requisitos
Durante a etapa de modelagem, realizada no TCCI, a análise dos requisitos teve o objetivo
de identificar o escopo do projeto e definir as funcionalidades que o sistema deveria atender. Nessa
análise, os requisitos funcionais, os não funcionais e as regras de negócio foram elicitados,
documentados e analisados. Para o desenvolvimento do TCCII esses requisitos foram refinados e
implementados na ferramenta, originando operações que podem ser realizadas pelo usuário. As
seções seguintes apresentam o resultado desse trabalho.
3.1.1 Requisitos Funcionais
Os requisitos funcionais descrevem o funcionamento do sistema e abrangem as tarefas que
ele disponibilizará aos usuários. Para maior entendimento e dimensão da ferramenta, os requisitos
funcionais foram divididos em três módulos: Projeto e Time, Product Backlog e Sprint. Na etapa de
análise os seguintes requisitos funcionais foram identificados:
Projeto e Time
• RF01: O sistema deverá permitir cadastrar, alterar e excluir um projeto;
• RF02: O sistema deverá permitir cadastrar, alterar e excluir usuários; e
• RF03: O sistema deverá permitir cadastrar, alterar e excluir um time.
30
Product Backlog
• RF01: O sistema deverá permitir cadastrar, alterar e excluir itens em um Product
Backlog;
• RF02: O sistema deverá permitir priorizar os itens de um Product Backlog;
• RF03: O sistema deverá permitir estimar os itens de um Product Backlog; e
• RF04: O sistema deverá permitir cadastrar, alterar e excluir um Impediment Backlog
para um item do Product Backlog.
Sprint
• RF01: O sistema deverá permitir cadastrar e excluir uma Sprint para um projeto;
• RF02: O sistema deverá permitir informar a data de início e fim de uma Sprint;
• RF03: O sistema deverá permitir selecionar os itens do Product Backlog que irão
compor a Sprint Backlog;
• RF04: O sistema deverá permitir cadastrar, alterar e excluir tarefas em uma Sprint
Backlog;
• RF05: O sistema deverá permitir alocação de uma tarefa a um membro do time;
• RF06: O sistema deverá permitir informar a data de início e fim de cada tarefa;
• RF07: O sistema deverá permitir informar o tempo de duração de cada tarefa;
• RF08: O sistema deverá permitir informar horas trabalhadas e o status do andamento em
cada tarefa;
• RF09: O sistema deverá permitir inserir informações sobre a reunião diária;
• RF10: O sistema deverá permitir inserir informações sobre a reunião de planejamento;
• RF11: O sistema deverá permitir inserir informações sobre a reunião de revisão; e
• RF12: O sistema deverá permitir inserir informações sobre a reunião de retrospectiva.
3.1.2 Requisitos Não Funcionais
Os requisitos não funcionais especificam as características do software, neste caso, a
linguagem de programação, o banco de dados e a plataforma utilizados.
31
• RNF01: O sistema deve ser voltado para WEB;
• RNF02: O sistema deve ser desenvolvido na linguagem de programação PHP;
• RNF03: O sistema utilizará o Banco de Dados PostgreSQL; e
• RNF04: O sistema deverá solicitar ao usuário login e senha de acesso.
3.1.3 Regras de Negócio
As regras de negócio definem as particularidades do funcionamento da ferramenta:
• RN01: O Scrum é composto por três papéis: Product Owner, Scrum Master e Scrum
Team;
• RN02: As Sprints devem ter de 2 a 4 semanas de duração;
• RN03: Ao final de cada Sprint uma parte do produto deverá ser entregue; e
• RN04: A estimativa do Product Backlog será realizada baseando na seqüência numérica
de Fibonacci.
3.2 Diagrama de Casos de Uso
Os casos de uso melhoram a compreensão da análise dos requisitos, são documentos
narrativos que descrevem a seqüência de eventos de um ator que usa um sistema para completar um
processo (JACOBSON et al, 1992, apud LARMAN, 2000).
Os casos de uso do sistema desenvolvido foram organizados em três módulos, a fim de
facilitar o entendimento da modelagem. A seguir são apresentados os módulos que compõem o
sistema, sendo a descrição de cada caso de uso apresentada no Apêndice A.
3.2.1 Módulo Projeto
Esse módulo permite ao usuário gerenciar os cadastros básicos para iniciar as atividades na
ferramenta e cadastrar, alterar ou excluir um projeto. A Figura 16 mostra a interação entre o
usuário (ator) e os casos de uso que constituem esse módulo. Antes de iniciar um projeto é
necessário que os usuários, cargos dos usuários e o time do projeto estejam cadastrados.
32
uc Pacote 1 - Módulo Proj ...
Scrum Master
UC 01.03 - Manter
Projeto
UC 01.01 - Manter
Usuário
UC 01.02 - Manter
Time
Figura 16. Diagrama de casos de uso do módulo Projeto
3.2.2 Módulo Product Backlog
Esse módulo permite ao usuário o gerenciamento do Product Backlog do projeto. O Product
Owner e o Scrum Master possuem como tarefas o gerenciamento e priorização do Product Backlog
e Impediment Backlog. A estimativa do Product Backlog é realizada por todos os elementos do
grupo. A Figura 17 ilustra esse módulo e as principais atividades desenvolvidas.
33
uc Pacote 2 - Product Backlog
Scrum MasterProduct Owner
Scrum Team
UC 02.01 - Gerenciar
Product Backlog
UC 02.02 - Gerenciar
Impediment Backlog
UC 02.03 - Estimar
Product Backlog
Figura 17. Diagrama de casos de uso do módulo Product Backlog
3.2.3 Módulo Controle de Sprint
A Figura 18 mostra as atividades desenvolvidas no módulo Controle de Sprint. Os
responsáveis por esse módulo são o Scrum Master e o Scrum Team. É função do Scrum Master
gerenciar a Sprint, selecionar os itens do Product Backlog que irão compor o Sprint Backlog,
acompanhar o andamento do projeto através da visualização do gráfico Burndown e auxiliar o
Scrum Time a cadastrar as tarefas para cada item do Product Backlog. A função do Scrum Team é
gerenciar cada tarefa, ou seja, alocar a tarefa a um membro do grupo, estimar sua duração, informar
horas trabalhadas por semana e a situação da tarefa (não iniciada, em desenvolvimento, finalizada,
em testes ou pendente) e gerenciar as reuniões diárias.
34
uc Controle de Sprint
Scrum Master
UC 03.01 - Cadastrar
Sprint
UC 03.03 - Cadastrar
tarefas
Scrum Team
UC 03.04 -
AlocarTarefa
UC 03.08 - Gerenciar
Reunião Diária
UC 03.09 - Gerenciar
Reunião de Retrospectiva
UC 03.02 -
Selecionar Itens do
Product Backlog
UC 03.05 - Informar
Duração de Cada
Tarefa
UC 03.06 - Informar
Horas Trabalhadas
em Cada Tarefa
UC 03.07 - Informar
Status da Tarefa
UC 03.10 - UC 03.09 -
Gerenciar Reunião de
Rev isão
UC 03.11 - Gerenciar
Reunião de
Planejamento
Figura 18. Diagrama de casos de uso do módulo controle de Sprint
35
3.3 Diagrama de Classes
Segundo Furlan (1998), “o diagrama de classes trata-se de uma estrutura lógica estática em
uma superfície de duas dimensões mostrando uma coleção de elementos declarativos de modelo,
como classes, tipos e seus respectivos conteúdos e relações”. A Figura 19 mostra o diagrama de
classes da ferramenta proposta.
class Scrum Project
Projeto
- Nome_Projeto: varchar- Objetivo_Projeto: varchar- Data_Inicio: date- Data_Fim: date- Valor_Projeto: decimal
+ Incluir_Projeto() : void+ Atualizar_Projeto() : void+ Deletar_Projeto() : void
Time
- Descrição: varchar- Código_Usuário: int- Nome_Usuário: varchar- Nome_Cargo: varchar
+ Inclui r_Time() : void+ Atualizar_Time() : void+ Deletar_Time() : void+ Incluir_Usuario_Time() : void
Usuários
- Nome: varchar- Data_Nasc.: date- RG: varchar- CPF: varchar- Endereço: varchar- Bairro: varchar- Cidade: varchar- CEP: integer- Estado: varchar- Telefone: varchar- Celular: varchar- E-Mail: varchar- Login: varchar- Senha: varchar
+ Incluir_Usuário() : void+ Atualizar_Usuário() : void+ Deletar_Usuário() : void
Product Backlog
- Projeto: varchar- Item_Product_Backlog: varchar- Prioridade: int- Estimativa: int- Fator_Impedimento: varchar
+ Incluir_Product() : void+ Alterar_Product() : void+ Deletar_Product() : void
Sprint Backlog
- Item_Product: varchar- Tarefa: varchar- Responsavel: varchar- Data_Inicio: date- Data_Fim: date- Horas_Estimadas: int- Semana_1: int- Semana_2: int- Semana_3: int- Semana_4: int- Status: varchar
+ Cadastrar_Sprint_Back() : void+ Gerenciar_Tarefas() : void
Sprint
- Projeto: varchar- Data_Inicio: date- Data_Fim: date
+ Incluir_Sprint() : void+ Atual izar_Sprint() : void+ Deletar_Sprint() : void
Reunião Planejamento
- Projeto: varchar- Apresen_Sprint: varchar- Local_Reuniao: varchar- Duracao: int- Program_Prevista: varchar- Objetivo: vachar- Como_Atingir: varchar
+ Incluir_Dados() : void+ Alterar_Dados() : void+ Deletar_Dados() : void
Reunião Diária
- Projeto: varchar- Sprint: int- Usuario: varchar- Desenvolvimento_Ontem: varchar- Desenvolvimento_Amanhã: varchar- Impedimentos: varchar
+ Inclui r_Dados() : void+ Alterar_Dados() : void+ Deletar_Dados() : void
Reunião Retrospectiv a
- Projeto: varchar- Desenvolvimento: varchar- Pontos_Melhorar: varchar- Sugestões: varchar
+ Incluir_Dados() : void+ Alterar_Dados() : void+ Deletar_Dados() : void
Reunião Revisão
- Projeto: varchar- Erro_Encontrado: varchar- Status: varchar
+ Inclui r_Dados() : void+ Alterar_Dados() : void+ Deletar_Dados() : void
0..*
1
1
1
1
11
1..*
1
1
0..*
1
0..* 11 0..*
1
1..*
0..* 1..*1 1..*
Figura 19. Diagrama de classes de domínio
A seguir é apresentada uma breve descrição das classes do diagrama (Figura 19):
• Usuário: classe que contém os dados referentes aos usuários da ferramenta;
• Time: essa classe contém os usuários que pertencem a um time do projeto, divididos em
cargos;
• Projeto: é a principal classe da ferramenta, contém informações gerais referentes ao
projeto;
36
• Product_Backlog: essa classe contém a descrição dos itens que deverão ser
desenvolvidos no projeto;
• Impediment_Backlog: contém os itens considerados fatores de impedimento para o
desenvolvimento do projeto;
• Sprint_Backlog: essa classe contém os itens do Product Backlog quebrados em tarefas,
com prazo estimado de desenvolvimento, data de início e fim e horas informadas
semanalmente pelo desenvolvedor da tarefa;
• Sprint: guarda informações referentes às Sprints (iterações) do projeto;
• Reunião_Planejamento: armazena informações referentes a reunião de planejamento de
cada Sprint do projeto, tais como objetivo e duração da Sprint e desenvolvedores;
• Reunião_Diária: classe que armazena os dados de todas as reuniões diárias que
ocorreram durante o desenvolvimento da Sprint;
• Reunião_Retrospectiva: classe que contém informações referente a reunião de
demonstração do produto realizada no final do Sprint para o cliente;
• Reunião_Revisão: classe que armazena as informações da reunião de revisão realizada
no final do desenvolvimento de uma Sprint.
3.4 Diagrama Entidade-Relacionamento
Após a definição das classes de domínio utilizadas pela ferramenta Scrum Project, foi
construído o diagrama de Entidade-Relacionamento apresentando a estrutura do banco de dados. A
Figura 20 apresenta esse diagrama.
37
dm Scrum
USUARIO
«column»*PK CD_USUARIO: integer NM_USUARIO: varchar(50) NR_RG: varchar(12) NR_CPF: varchar(15) DT_NASCIMENTO: date DS_LOGRADOURO: varchar(100) NR_LOGRADOURO: integer NM_BAIRRO: varchar(30) NM_CIDADE: varchar(30) NR_CEP: integer DS_ESTADO: varchar(30) NR_TELEFONE: varchar(20) NR_CELULAR: varchar(20) DS_MAIL: varchar(50) LOGIN: varchar(20) SENHA: varchar(20)
«PK»+ PK_USUARIO(integer)
CARGO
«column»*PK CD_CARGO: integer NM_CARGO: varchar(30) DS_CARGO: varchar(100)
«PK»+ PK_CARGO(integer)
TIME
«column»*PK CD_TIME: integer DS_TIME: varchar(100)
«PK»+ PK_TIME(integer)
PROJETO
«column»*PK CD_PROJETO: integer FK CD_TIME: integer NM_PROJETO: varchar(50) DS_PROJETO: varchar(200) FK CD_USUARIO: integer DT_INICIO: date DT_FIM: date VL_PROJETO: decimal(10,2) DT_CRIACAO: date DT_ATUALIZACAO: date
«FK»+ FK_PROJETO_TIME(integer)+ FK_PROJETO_USUARIO(integer)
«PK»+ PK_PROJETO(integer)
USUARIO_TIME
«column»*pfK CD_TIME: integer*pfK CD_USUARIO: integer*pfK CD_CARGO: integer
«FK»+ FK_USUARIO_TIME_CARGO(integer)+ FK_USUARIO_TIME_TIME(integer)+ FK_USUARIO_TIME_USUARIO(integer)
«PK»+ PK_USUARIO_TIME(integer, integer, integer)
PRODUCT_BACKLOG
«column»*PK CD_PRODUCT: integer*FK CD_PROJETO: integer DESCRICAO_ITEM: varchar(100) NR_PRIORIDADE: integer NR_ESTIMATIVA: integer DS_IMPEDIMENTO: varchar(100) DS_STATUS: varchar(30)
«FK»+ FK_ITEM_PRODUCT_BACKLOG_PROJETO(integer)
«PK»+ PK_ITEM_PRODUCT_BACKLOG(integer)
SPRINT
«column»*PK CD_SPRINT: integer* CD_PROJETO: integer DT_INICIO: date DT_FIM: date
«PK»+ PK_SPRINT(integer)
SPRINT_BACKLOG
«column»*FK CD_SPRINT: integer FK CD_PRODUCT: integer*PK CD_ITEM_SPRINT: integer DS_TAREFA: varchar(50) NR_HORAS_EST: integer NR_HORAS_SEM_1: integer NR_HORAS_SEM_2: integer NR_HORAS_SEM_3: integer NR_HORAS_SEM_4: integer DS_STATUS: varchar(20) FK CD_USUARIO: integer DT_INICIO: date DT_FIM: date
«FK»+ FK_ITEM_SPRINT_PRODUCT_BACKLOG(integer)+ FK_ITEM_SPRINT_SPRINT(integer)+ FK_SPRINT_BACKLOG_USUARIO(integer)
«PK»+ PK_ITEM_SPRINT(integer)
REUNIAO_DIARIA
«column»*PK CD_SEQ_REUNIAO: integer FK CD_SPRINT: integer FK CD_USUARIO: integer DT_REUNIAO: date DS_ATIVIDADE_ONTEM: varchar(200) DS_ATIVIDADE_AMANHA: varchar(200) DS_IMPEDIMENTO: varchar(300)
«FK»+ FK_REUNIAO_DIARIA_SPRINT(integer)+ FK_REUNIAO_DIARIA_USUARIO(integer)
«PK»+ PK_REUNIAO_DIARIA(integer)
REUNIAO_PLANEJAMENTO
«column»*PK CD_REUNIAO: integer*FK CD_SPRINT: integer DS_OBJETIVO_SPRINT: varchar(200) DS_ATINGE_OBJETIVOS: varchar(300) DT_APRESENTACAO_SPRINT: date DS_LOCAL_REUNIAO_DIARIA: varchar(50) DS_HORARIO: varchar(50) DS_AGENDA_REUNIAO: varchar(300)
«FK»+ FK_REUNIAO_PLANEJAMENTO_SPRINT(integer)
«PK»+ PK_REUNIAO_PLANEJAMENTO(integer)
REUNIAO_RETROSPECTIVA
«column»*PK CD_REUNIAO_RETRO: integer FK CD_SPRINT: integer DS_DESENVOLVIMENTO: varchar(300) DS_SER_MELHORADO: varchar(300) DS_SUGESTAO: varchar(300)
«FK»+ FK_REUNIAO_RETROSPECTIVA_SPRINT(integer)
«PK»+ PK_REUNIAO_RETROSPECTIVA(integer)
REUNIAO_REVISAO
«column»*PK CD_REUNIAO_REV: integer FK CD_SPRINT: integer
«FK»+ FK_REUNIAO_REVISAO_SPRINT(integer)
«PK»+ PK_REUNIAO_REVISAO(integer)
ITEM_REUNIAO_REVISAO
«column»*PK CD_SEQ: integer FK CD_REUNIAO_REV: integer DS_ERRO: varchar(100) DS_STATUS: varchar(30)
«FK»+ FK_ITEM_REUNIAO_REVISAO_REUNIAO_REVISAO(integer)
«PK»+ PK_ITEM_REUNIAO_REVISAO(integer)
CD = CÓDIGODS = DESCRIÇÃODT = DATANM = NOMENR = NÚMEROVL = VALORSEM = SEMANAEST = ESTIMADA
Figura 20 - Diagrama de entidade-relacionamento do banco de dados
4 DESENVOLVIMENTO
Este capítulo descreve o desenvolvimento da ferramenta Scrum Project, apresentando o
framework utilizado para seu desenvolvimento e a apresentação das telas e funcionalidades
disponíveis.
4.1 Implementação da Ferramenta
O desenvolvimento da ferramenta foi realizado focando sua utilização em ambiente web,
objetivando independência de plataforma e maior disponibilidade aos usuários. Para isso, utilizou-
se o framework de desenvolvimento ScriptCase e o banco de dados PostgreSQL. Optou-se por esse
framework por ser uma ferramenta nacional, com documentação e suporte em português, pela
38
agilidade e redução no tempo de desenvolvimento oferecido e compatibilidade com o banco de
dados utilizado e por desenvolver os sistemas em PHP (Hypertext Preprocessor).
4.1.1 Framework ScriptCase
O ScriptCase é um ambiente de desenvolvimento de aplicações web de forma rápida e
eficiente, reduz tempo para desenvolvimento e manutenção e permite a criação de novos sistemas
utilizando formulários, consultas, relatórios e menus.
O ScriptCase suporta os bancos de dados mais usados no mercado como Oracle, DB2,
SQLServer, MySQL, PostgreSQL e Sybase. O código-fonte da aplicação é em PHP com JavaScript
e fazem uso da tecnologia Ajax para permitir a transferência de dados sem a necessidade de recarga
da interface, tornando menor o tempo de resposta das operações realizadas. As aplicações rodam
independente da ferramenta sendo compatíveis com Windows, Unix, AS/400, entre outros
(NETMAKE, 2009). A Figura 21 representa uma visão do funcionamento desse framework.
Figura 21 - Framework ScriptCase
Fonte: Netmake (2009).
O ScriptCase pode ser obtido através da internet, sob licença acadêmica ou download da
versão trial com licença para 30 dias de uso. A Figura 22 mostra a tela inicial do ScriptCase.
39
Figura 22. Tela inicial ScriptCase
Fonte: Netmake (2009).
4.2 A Ferramenta Scrum Project
A ferramenta Scrum Project foi desenvolvida de acordo com a modelagem entidade-
relacionamento apresentada na seção 3.4, tendo em vista o cumprimento dos requisitos e regras de
negócio definidos. Nas próximas seções é apresentado o resultado desse trabalho.
4.2.1 Acesso ao Sistema
O acesso dos usuários ao sistema é controlado através de autenticação de login e senha
previamente cadastrados. A Figura 23 apresenta a tela inicial do ambiente, na qual o usuário
informa seu login e senha e é feita a validação dos dados informados.
40
Figura 23. Tela autenticação dos usuários na ferramenta
Uma vez autenticado no sistema, o usuário possui acesso às suas funcionalidades. Estas
foram divididas em dez módulos e desenvolvidas de acordo com os casos de uso que foram
identificados durante a etapa de modelagem da ferramenta. A ferramenta foi desenvolvida para
trabalhar com perfis de usuário, onde cada perfil (Scrum Master, Product Owner e Scrum Time) tem
acesso a módulos específicos.
A Figura 24 apresenta o menu da ferramenta com as funcionalidades disponíveis para o
perfil Scrum Master, a Figura 25 mostra as funcionalidades disponíveis para o perfil Scrum Time e,
por fim, a Figura 26 ilustra os módulos disponíveis para o Product Owner. Cada módulo é
apresentado nas seções a seguir.
41
Figura 24. Menu da ferramenta Scrum Project para o perfil Scrum Master.
Figura 25. Menu da ferramenta Scrum Project para o perfil Scrum Time.
42
Figura 26. Menu da ferramenta Scrum Project para o perfil Product Owner.
4.2.2 Módulo de Cadastros
Associado a este módulo estão os cadastros básicos do sistema que serão utilizados nos
módulos principais. Foram desenvolvidos os cadastros de usuários e times. Esse módulo esta
disponível somente para o perfil Scrum Master.
A Figura 27 mostra a tela de cadastro de usuários. Nessa tela são informados os dados
pessoais do usuário, endereço, telefone, e-mail, login e senha para acesso a ferramenta. Foi
implementado validador de CPF, e-mail, formatação para datas e telefone, senha criptografada e um
link para o campo CEP. O framework ScriptCase possui integrado um módulo completo de pesquisa
de CEP baseado no cadastro dos Correios, permitindo ao usuário consultar o CEP da localidade
que deseja informar (UC 01.01).
43
Figura 27. Cadastro de usuários
O cadastro de times é realizado com base nos usuários cadastrados. O Scrum Master define
quem serão os integrantes do time e escolhe a função que cada membro irá desenvolver em um
determinado projeto. A Figura 28 ilustra essa tela (UC 01.02).
44
Figura 28 - Cadastro de times
4.2.3 Módulo Projeto
Após o cadastro das informações básicas, o Scrum Master pode incluir um projeto na
ferramenta. Conforme apresentado na Figura 29, na criação de um novo projeto é necessário definir
um nome e um objetivo para o mesmo, o time alocado para seu desenvolvimento, data de início e
fim e o Scrum Master responsável pelo projeto (UC 01.03).
45
Figura 29 - Cadastro de projetos
4.2.4 Módulo Product Backlog
Nesse módulo é possível inserir o Product Backlog do projeto criado. O Product Backlog,
conforme descrito na seção 2.4.2.6, é basicamente uma lista de requisitos, estórias que o cliente
deseja que sejam implementadas e as mesmas são escritas utilizando a terminologia do cliente.
Nessa tela os seguintes campos devem ser informados:
• Item Product Backlog;
• Prioridade;
• Estimativa; e
• Fator de Impedimento.
O campo Status é apenas informativo, seu estado inicial é “Não Iniciado” e, conforme os
itens do Product Backlog vão sendo desenvolvidos, o time atualiza essa informação no módulo
Sprint Backlog e a mesma é replicada na tela do Product Backlog. Os campos Item Product
46
Backlog e Prioridade são definidos pelo Product Owner e o campo Estimativa é definido pela
equipe. Quando clicado o campo Estimativa mostra uma lista contendo treze valores, destes onze
representam a série de Fibonacci (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100) e dois representam uma
opinião do usuário: o campo “?” representa que o usuário não tem a mínima idéia do valor para a
estimativa da estória e o campo “!” que dizer que o usuário quer uma pausa para descansar. O valor
“0” pode ser usado para representar que a estória já foi feita ou o tempo para seu desenvolvimento é
muito pequeno. A Figura 30 mostra a tela para cadastro do Product Backlog do projeto (UC 02. 01
a 02.04).
Figura 30 - Cadastro de Product Backlog
4.2.5 Módulo Sprint Backlog
O módulo Sprint Backlog permite inserir a lista de tarefas que o Scrum Team se compromete
a entregar em uma Sprint. As tarefas são extraídas do Product Backlog do projeto conforme a
priorização do Product Owner e a percepção da equipe sobre o tempo necessário para fazer as
implementações. Ao final de cada Sprint uma parte do produto deverá ser demonstrada ao Product
Owner.
A Figura 31 ilustra a tela desenvolvida para esse módulo. Além de inserir as tarefas que
serão desenvolvidas na Sprint, a tela permite informar quem será o membro do time responsável em
47
desenvolvê-la, a data de início e fim do desenvolvimento, a quantidade de horas estimadas para o
cumprimento da tarefa, informar horas trabalhadas semanalmente e o status da tarefa (UC 03.01 a
03.07).
Um projeto poderá ter mais de uma Sprint, dependo do tamanho do mesmo e respeitando a
definição do Scrum, que estipula que uma Sprint deverá ter no máximo 30 dias. Sendo assim, é
papel do Scrum Master e do time definir se um item do Product Backlog será desenvolvido em uma
única Sprint ou será quebrado em várias tarefas, que serão desenvolvidas em mais de uma Sprint.
Figura 31 - Cadastro de Sprint Backlog
4.2.6 Módulo Reunião de Planejamento
Esse módulo permite ao Scrum Master cadastrar as informações sobre a reunião de
planejamento da Sprint. A Figura 32 mostra essa tela.
48
Figura 32 - Cadastro da Reunião de Planejamento
4.2.7 Módulo Reunião Diária
A Figura 33 ilustra a tela onde cada membro do time deverá cadastrar as informações sobre
a reunião diária da Sprint. Somente o Scrum Master e o Scrum Time possuem acesso a essa tela.
49
Figura 33 - Informar reunião diária
4.2.8 Reunião de Revisão
Ao final de cada Sprint, é papel do Scrum Master junto ao seu time testar a ferramenta com
o cliente do projeto. Para cadastrar as informações sobre a reunião de revisão, o Scrum Master
possui acesso a tela abaixo (Figura 34).
50
Figura 34 - Informar reunião de revisão
4.2.9 Reunião de Retrospectiva
A Figura 35 mostra a tela onde o Scrum Master deve cadastrar as informações da reunião de
retrospectiva para cada Sprint desenvolvida. Essas informações servem de base para melhorar o
desenvolvimento da próxima Sprint.
51
Figura 35 - Informar reunião de retrospectiva
4.2.10 Relatórios
A Figura 36 ilustra o relatório gerado para consulta de Sprints Backlog de um projeto.
Através desse gráfico o Scrum Master consegue verificar quais tarefas estão em desenvolvimento,
horas estimadas e quantas horas já foram gastas com a implementação.
52
Figura 36 - Consulta Sprint Backlog
53
5 CONCLUSÕES
O principal objetivo desse trabalho foi o desenvolvimento de uma ferramenta para
gerenciamento de projetos baseada nos princípios da metodologia ágil Scrum. Essa ferramenta é
voltada para a web, grátis e de código fonte aberto para que outros desenvolvedores possam adapta
- lá de acordo com suas necessidades, a mesma poderá ser utilizada por gerentes para o
desenvolvimento de pequenos e médios projetos em qualquer área.
Para o desenvolvimento dessa ferramenta, foi necessário conhecer a Metodologia Ágil
Scrum. Esse conhecimento foi alcançado na primeira parte do trabalho (Fundamentação Teórica),
através da pesquisa dos conceitos referentes às Metodologias Ágeis e ao Scrum e do estudo de
algumas ferramentas existentes no mercado.
O desenvolvimento do sistema, realizado na terceira parte do trabalho, seguiu os requisitos e
a modelagem construída na etapa de projeto, com exceção do gráfico Burndown que não pode ser
construído, pois a versão utilizada do ScriptCase não possui recursos gráficos na geração de
consultas.
Com relação às tecnologias empregadas para o desenvolvimento do trabalho, o ScriptCase
permitiu agilizar o desenvolvimento do sistema, porém algumas limitações e dificuldades foram
encontradas para trabalhar com esse framework
• Dificuldade na construção de formulário mestre-detalhe devido a pouca flexibilidade
do ScriptCase; e
• Como descrito acima, a última versão do ScriptCase, utilizada para o
desenvolvimento da ferramenta, não possui recursos gráficos.
Como sugestões para trabalhos futuros, pode-se citar o desenvolvimento de uma ferramenta
auxiliar para calcular o Planning Poker do Product Backog.
54
6 REFERÊNCIAS BIBLIOGRÁFICAS
AGILE MANIFESTO. Manifesto for Agile Software Development. Disponível em < http://agilemanifesto.org/ >. Acesso em 15 out. 2008. ALBUQUERQUE, Nikolai. Entendendo o gerenciamento ágil de projetos com Scrum. 2007. Disponível em <http://www.fumsoft.softex.br/ccomp/Ententendo%20o%20Gerenciamento%20%C3%81gil%20de%20Projetos%20com%20SCRUM.pdf >. Acesso em 01 out. 2008. AMBLER, Scott W. Modelagem Ágil: práticas eficazes para a Programação Extrema e o Processo Unificado. Porto Alegre: Bookman, 2004. BERNABO, Juan. Desmistificando a gestão, desenvolvimento e melhoria ágil de processos com Scrum. Campinas, 2007. Disponível em < http://www.planoeditorial.com.br/jornada/palestras/campinas/27_11_2007/JuanBernabo.pdf >. Acesso em 02 out. 2008. BOEHM, B; TURNER, R. Balancing Agility and Discipline A Guide for the Perplexed. Boston: AddisonWesley, 2003. COSTA FILHO, Edes Garcia; PENTEADO Rosângela; SILVA, Junia Coutinho; BRAGA, Rosana. Padrões e métodos ágeis: agilidade no processo de desenvolvimento de Software. São Paulo, 2005. Disponível em: <http://sugarloafplop2005.icmc.usp.br/papers/9673.pdf>. Acesso em: 12 ago. 2008. FERREIRA, David de Almeida. RUP. Ceará, 2007. Disponível em <http://davidferreirafz.files.wordpress.com/2008/02/engenharia-de-software-rup.pdf>. Acesso em: 10 jan. 2008. FURLAN, José Davi. Modelagem de objetos através da UML. São Paulo: Makron Books. 1998. HELDMAN, K. Gerência de projetos: guia para o exame oficial PMI. 2.ed. Rio de Janeiro: Campus, 2005. LARMAN, Graig. Utilizando UML e padrões: Uma introdução à análise e ao projeto orientados a objetos. Porto Alegre: Bookman, 2000. LEITE, Jair C. Engenharia de software. Paraíba, 2008. Disponível em: <http://www.dimap.ufrn.br/~jair/ES/slides/ProcessoDeSoftware.pdf>. Acesso em: 10 nov. 2008. MACEDO, Michel Pavan; DESCHAMPS, Alexandro. Scrum. 2008. Disponível em < http://www.apicesoft.com/common/articles/Apice%20Engenharia%20de%20Software%20-%20SCRUM%20(Michel%20Pavan%20Macedo)%20-%20Fevereiro%20de%202008.pdf >. Acesso em 10 set. 2008. MARÇAL, Ana Sofia; PEREIRA, Paulo; TORREÃO, Paula. Entendendo Scrum para gerenciar projetos de forma ágil. Recife, 2007. Disponível em
55
<http://www.cesar.org.br/files/file/SCRUM_MundoPM-Abril-Maio-2007.pdf >. Acesso em 02 out. 2008. NETMAKE, Netmake. Disponível em < http://www.scriptcase.com.br>. Acesso em 10 mar. 2009. PEREIRA, Jhony Alceu. Ambiente Web para gerenciamento de processo. 2005. 70 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) – Faculdade de Ciência da Computação, Universidade Regional de Blumenau, Blumenau, 2005. PEREIRA, Paulo. Metodologias ágeis. Recife, 2008. Disponível em < http://www.cesar.edu.br/ docs/paulocaju.pdf>. Acesso em 01 out. 2008. Padrões e métodos ágeis: agilidade no processo de desenvolvimento de Software. São Paulo, 2005. Disponível em: <http://sugarloafplop2005.icmc.usp.br/papers/9673.pdf>. Acesso em: 12 ago. 2008. PRESSMAN, Roger S. Engenharia de software. São Paulo: Makron Books, 1995. PRESSMAN, Roger S. Engenharia de software. 6.ed. São Paulo: MCGrall – Hill, 2006. RIBEIRO, André Luis. Gerenciamento de projeto tradicional x gerenciamento de projeto ágil: uma análise comparativa. São Paulo, 2008. Disponível em: <http://www.erudio.com.br/downloads/doc_view-12.html>. Acesso em 10 nov. 2008. STANDISH. Chaos Research. Disponível em: <http://www.standishgroup.com/>. Acesso em: 12 ago. 2008. SOARES, Michel dos Santos. Comparação entre metodologias ágeis e tradicionais. Minas Gerais, 2004. Disponível em: < http://www.dcc.ufla.br/infocomp/artigos/v3.2/art02.pdf>. Acesso em: 11 ago. 2008. SOMMERVILLE, Ian. Engenharia de software. 8.ed. São Paulo: Pearson Addison Wesley, 2007. SOUZA NETO, Oscar Nogueira de. Análise Comparativa das Metodologias de Desenvolvimento de Softwares 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, Belém, 2004. TAVARES, Aleckssandro. Gerência de projeto com PMBOK e Scrum: um estudo de caso. 2008, 66 f. Trabalho de Conclusão de Curso (Bacharelado em Ciência da Computação) – Faculdade em Ciência da Computação, Faculdade Cenecista Nossa Senhora dos Anjos, Gravataí, 2008. YOSHIMA, Rodrigo. Gerenciamento de projetos com Scrum. 2007. Disponível em < http://www.aspercom.com.br/ead/mod/resource/view.php?id=245 >. Acesso em 05 out. 2008.
56
GLOSSÁRIO
Burndown Chart Gráfico que exibe o progresso diário do time em função do total de horas estabelecido.
Daily Meeting Reunião diária de 15 minutos para que o Scrum Master possa verificar que tarefas a sua equipe está desenvolvendo e identificar possíveis impedimentos.
Planning Meeting Primeira reunião que acontece no projeto. É uma reunião realizada para definir o Product Backlog e planejar o Sprint Backlog.
Planning Poker Método, baseado na seqüência numérica de Fibonacci para estimar o Product Backlog
Product Backlog Lista de itens definidos e priorizados pelo Product Owner, que incluem os requisitos funcionais e não funcionais de um sistema.
Product Owner Dono do projeto (cliente). Responsável por definir o escopo do projeto junto ao Scrum Master.
Scrum Master Gerente do projeto. Sua responsabilidade é desempenhar um papel de liderança, gerenciando os interesses do Product Owner mediante o time.
Scrum Team Time responsável pelo desenvolvimento do projeto.
Sprint Iterações que podem ter duração de 2 a 4 semanas.
Sprint Backlog Lista que contém as tarefas que o Scrum Team irá trabalhar durante o desenvolvimento da Sprint.
Sprint Retrospective A reunião de retrospectiva ocorre no final do projeto e seu objetivo é entregar o produto e realizar uma demonstração para que o Product Owner
possa verificar se o produto produzido está de acordo com suas expectativas.
Sprint Review Reunião de revisão que ocorre no último dia de desenvolvimento da Sprint
com o objetivo de demonstrar as funcionalidades implantadas ao Scrum
Master.
Time Boxing Espaço de tempo definido e cronometrado.
APÊNDICES
A DESCRIÇÃO DOS CASOS DE USO
Neste apêndice são apresentadas as descrições detalhadas dos casos de uso do projeto.
A.1 MÓDULO PROJETO
UC 01.01 – Manter Usuário Permite ao usuário cadastrar, alterar ou excluir um usuário (Tela Cadastrar Usuários). Nessa
tela os seguintes campos podem ser informados:
1. Nome do Usuário;
2. Data de Nascimento;
3. RG;
4. CPF;
5. Endereço (rua, bairro, cidade, CEP e estado);
6. Telefone;
7. E-mail;
8. Login; e
9. Senha.
Requisito:
• RF02: Sistema deverá permitir cadastrar, alterar e excluir usuários.
Condição:
• Pós-Condição: usuário cadastrado, alterado ou excluído dependendo da ação do usuário.
Cenários:
Cadastrar Usuário - Principal
1. Sistema apresenta tela para cadastro de novo usuário (Tela Cadastrar Usuários);
2. Usuário digita o nome, dados pessoais, endereço, e-mail, login e senha de acesso do
usuário;
59
3. Usuário clica em inserir novo registro;
4. Sistema verifica se os dados obrigatórios (nome, login e senha) foram informados; e
5. Sistema salva informações no banco de dados.
Dados obrigatórios não informados – Exceção
Caso o usuário não informe um dado obrigatório, no passo 2 do cenário Cadastrar Usuários:
1. Sistema mostra a mensagem “dado obrigatório” ao lado do campo; e
2. Sistema somente salva informação no banco de dados após campo ser informado.
Alterar Usuário – Alternativo
Caso o usuário necessite alterar alguma informação:
1. Sistema apresenta tela para cadastro de novo usuário (Tela Cadastrar Usuários);
2. Usuário altera os campos que necessita;
3. Usuário clica em atualizar;
4. Sistema verifica se os dados obrigatórios (nome, login e senha) não foram apagados; e
5. Sistema salva informações no banco de dados.
Excluir Usuário – Alternativo
1. Sistema apresenta tela para cadastro de novo usuário (Tela Cadastrar Usuários);
2. Usuário clica em excluir; e
3. Sistema exclui usuário do banco de dado.
Usuário cadastrado em um time – Exceção
Caso o usuário esteja cadastrado em um time, no passo 2 do cenário Excluir Usuário:
1. Sistema apresenta exibe a mensagem: “Não é possível excluir o usuário, pois ele esta
cadastrado em um time”; e
2. Sistema não exclui usuário do banco de dados.
60
UC 01.02 – Manter Cargo
Permite ao usuário cadastrar, alterar ou excluir um cargo (Tela Cadastrar Cargos). Nessa tela
os seguintes campos podem ser informados:
1. Nome do Cargo; e
2. Descrição;
Requisitos:
• RF03: O sistema deverá permitir cadastrar e alterar cargos para os usuários;
• RN01: O Scrum é composto por três papéis: Product Owner, Scrum Master e Scrum
Team.
Condição:
• Pré-Condição: usuários cadastrados no sistema; e
• Pós-Condição: cargo cadastrado ou alterado dependendo da ação do usuário.
Cenários:
Cadastrar Cargo - Principal
1. Sistema apresenta tela para cadastro de novo cargo (Tela Cadastrar Cargos);
2. Usuário digita o nome e a descrição do cargo;
3. Usuário clica em inserir novo registro;
4. Sistema verifica se os dados obrigatórios (nome e descrição) foram informados; e
5. Sistema salva informações no banco de dados.
Dados obrigatórios não informados – Exceção
Caso o usuário não informe um dado obrigatório, no passo 2 do cenário Cadastrar Cargos:
1. Sistema mostra a mensagem “dado obrigatório” ao lado do campo; e
2. Sistema somente salva informação no banco de dados após campo ser informado.
Alterar Cargo – Alternativo
Caso o usuário necessite alterar alguma informação:
61
1. Sistema apresenta tela para cadastro de novo cargo (Tela Cadastrar Cargos);
2. Usuário altera os campos que necessita;
3. Usuário clica em atualizar;
4. Sistema verifica se os dados obrigatórios (nome e cargo) não foram apagados; e
5. Sistema salva informações no banco de dados.
Excluir Cargo – Alternativo
1. Sistema apresenta tela para cadastro de novo cargo (Tela Cadastrar Cargos);
2. Usuário clica em excluir; e
3. Sistema exclui cargo do banco de dado.
Cargo cadastrado para um usuário em um time – Exceção
Caso o usuário esteja cadastrado em um time, no passo 2 do cenário Excluir Cargo:
1. Sistema apresenta exibe a mensagem: “Não é possível excluir o usuário, pois ele esta
cadastrado em um time”; e
2. Sistema não exclui cargo do banco de dados.
UC 01.03 – Manter Time
Permite ao usuário cadastrar ou alterar o time que irá trabalhar no desenvolvimento do
projeto e definir suas funções ou cargos (tela Cadastrar Times). Nessa tela os seguintes campos
podem ser informados:
1. Descrição do Time;
2. Usuário; e
3. Cargo do Usuário.
Requisito:
• RF04: Sistema deverá permitir criar, alterar e excluir um time.
62
Condição:
• Pré-Condição: usuários cadastrados no sistema;
• Pré-Condição: cargos cadastrados no sistema; e
• Pós-Condição: time cadastrado ou alterado dependendo da ação do usuário.
Cenários:
Cadastrar Time - Principal
1. Sistema apresenta tela para cadastro de novo time (Tela Cadastrar Times);
2. Usuário digita a descrição do time, seleciona usuários e os cargos de cada usuário;
3. Usuário clica em inserir novo registro;
4. Sistema verifica se o dado obrigatório descrição foi informado; e
5. Sistema salva informações no banco de dados.
Dados obrigatório não informado – Exceção
Caso o usuário não informe um dado obrigatório, no passo 2 do cenário Cadastrar Times:
1. Sistema mostra a mensagem “dado obrigatório” ao lado do campo; e
2. Sistema somente salva informação no banco de dados após campo ser informado.
Alterar Time – Alternativo
Caso o usuário necessite alterar alguma informação:
1. Sistema apresenta tela para cadastro de novo time (Tela Cadastrar Times);
2. Usuário altera os campos que necessita;
3. Usuário clica em atualizar;
4. Sistema verifica se o dado obrigatório descrição não foi apagado; e
5. Sistema salva informações no banco de dados.
63
Excluir Time – Alternativo
1. Sistema apresenta tela para cadastro de novo time (Tela Cadastrar Times);
2. Usuário clica em excluir; e
3. Sistema exclui time do banco de dado.
Time cadastrado para um projeto – Exceção
Caso o time esteja cadastrado em um projeto, no passo 2 do cenário Excluir Time:
1. Sistema apresenta exibe a mensagem: “Não é possível excluir o time, pois ele esta
cadastrado em um projeto”; e
2. Sistema não exclui time do banco de dados.
UC 01.04 – Manter Projeto
Permite ao usuário cadastrar, alterar ou excluir um projeto (Tela Projetos). Nessa tela os
seguintes campos podem ser informados:
1. Nome do Projeto;
2. Objetivo;
3. Time;
4. Data Início;
5. Data Fim;
6. Orçamento; e
7. Responsável.
Requisito:
• RF01: O sistema deverá permitir cadastrar, alterar ou excluir um projeto.
Condição:
• Pré-Condição: usuários cadastrados no sistema;
• Pré-Condição: time cadastrado no sistema; e
• Pós-Condição: projeto cadastrado, alterado ou excluído dependendo da ação do usuário.
64
Cenários:
Cadastrar Projeto - Principal
1. Sistema apresenta tela para cadastro de novo projeto (Tela Projetos);
2. Usuário digita nome, objetivo, time, data de início e fim, orçamento e responsável do
projeto;
3. Usuário clica em inserir novo registro;
4. Sistema verifica se os dados obrigatórios (nome, objetivo e responsável) foram
informado; e
5. Sistema salva informações no banco de dados.
Dados obrigatório não informado – Exceção
Caso o usuário não informe um dado obrigatório, no passo 2 do cenário Cadastrar Projeto:
1. Sistema mostra a mensagem “dado obrigatório” ao lado do campo; e
2. Sistema somente salva informação no banco de dados após campo ser informado.
Alterar Projeto – Alternativo
Caso o usuário necessite alterar alguma informação:
1. Sistema apresenta tela para cadastro de novo projeto (Tela Projetos);
2. Usuário altera os campos que necessita;
3. Usuário clica em atualizar;
4. Sistema verifica se os dados obrigatórios não foram apagados; e
5. Sistema salva informações no banco de dados.
Excluir Projeto – Alternativo
1. Sistema apresenta tela para cadastro de novo projeto (Tela Projetos);
2. Usuário clica em excluir; e
65
3. Sistema exclui projeto do banco de dado.
Product Backlog cadastrado para o projeto – Exceção
Caso o projeto tenha um Product Backlog cadastrado, no passo 2 do cenário Excluir Projeto:
1. Sistema apresenta exibe a mensagem: “Não é possível excluir o projeto, pois ele possui
um Product Backlog cadastrado”; e
2. Sistema não exclui projeto do banco de dados.
A.2 MÓDULO PRODUCT BACKLOG
UC 02.01 – Gerenciar Product Backlog
Permite ao usuário cadastrar, alterar ou excluir os itens do Product Backlog do projeto. (Tela
Product Backlog).
Requisitos:
• RF01: Sistema deverá permitir cadastrar, alterar e excluir itens em um Product Backlog.
Condição:
• Pré-Condição: o projeto no qual de deseja inserir informações deve estar cadastrado; e
• Pós-Condição: itens do Product Backlog cadastradas, alteradas ou excluídas dependendo
da ação do usuário.
Cenários:
Cadastrar Product Backlog - Principal
1. Sistema apresenta tela para cadastro de Product Backlog (Tela Product Backlog);
2. Usuário digita projeto, item do Product Backlog, prioridade, estimativa e fator de
impedimento;
3. Usuário clica em inserir novo registro; e
4. Sistema salva informações no banco de dados.
66
Alterar Product Backlog – Alternativo
Caso o usuário necessite alterar alguma informação:
1. Sistema apresenta tela para cadastro de Product Backlog (Tela Product Backlog);
2. Usuário altera os campos que necessita;
3. Usuário clica em atualizar;
4. Sistema salva informações no banco de dados.
Excluir Product Backlog – Alternativo
1. Sistema apresenta tela para cadastro de Product Backlog (Tela Product Backlog);
2. Usuário clica em excluir; e
3. Sistema exclui Product Backlog do banco de dado.
Tarefa cadastrado para o Product Backlog – Exceção
Caso o Product Backlog esteja associado a uma tarefa, no passo 2 do cenário Excluir
Product Backlog:
1. Sistema apresenta exibe a mensagem: “Não é possível excluir o Product Backlog, pois
ele esta associado a uma tarefa”; e
2. Sistema não exclui Product Backlog do banco de dados.
UC 02.02 – Gerenciar Impediment Backlog
Permite ao usuário cadastrar os itens que considera fatores de impedimentos para o
desenvolvimento do projeto (tela Product Backlog).
Requisito:
• RF04: O sistema deverá permitir cadastrar, alterar e excluir um Impediment Backlog
para um item do Product Backlog.
Condição:
• Pré-Condição: o item do Product Backlog, no qual se deseja inserir o fator de
impedimento deverá estar cadastrado.
67
• Pós-Condição: fator de impedimento cadastrado para o Product Backlog.
UC 02.03 – Estimar Product Backlog
Permite ao usuário estimar cada item do Product Backlog (Tela Product Backlog).
Requisitos:
• RF03: Sistema deverá permitir estimar os itens de um Product Backlog; e
• RN05: A estimativa do Product Backlog será realizada baseando-se na seqüência
numérica de Fibonacci.
Condição:
• Pré-Condição: os itens do Product Backlog deverão estar informados; e
• Pós-Condição: itens do Product Backlog estimados.
UC 02.04 – Priorizar Product Backlog
Permite ao Scrum Master e ao Product Owner priorizar os itens do Product Backlog (Tela
Product Backlog).
Requisito:
• RF02: Sistema deverá permitir priorizar os itens de um Product Backlog ;
Condição:
• Pré-Condição: os itens do Product Backlog deverão estar informados; e
• Pós-Condição: itens do Product Backlog priorizados.
A.3 MÓDULO DE CONTROLE DE SPRINT
UC 03.01 – Cadastrar Sprint
Permite ao usuário cadastrar Sprints para um projeto (Tela Manter Sprint). Nessa tela os
seguintes campos poderão ser informados:
1. Código do Projeto;
2. Data Início; e
3. Data Fim.
68
Requisitos:
• RF01: O sistema deverá permitir cadastrar e excluir uma Sprint para um projeto;
• RF02: O sistema deverá permitir informar a data de início e fim de uma Sprint;
• RN02: As Sprints devem ter de 2 a 4 semanas de duração; e
• RN03: Ao final de cada Sprint uma parte do produto deverá ser entregue.
Condição:
• Pré-Condição: o Product Backlog do projeto deve estar definido.
• Pós-Condição: Sprints Backlog cadastrada para o projeto.
Cenários:
Esse cenário representa os casos de uso UC 03.01 até 03.07:
Cadastrar Sprint Backlog - Principal
1. Sistema apresenta tela para cadastro da Sprint (Tela Sprint Backlog);
2. Usuário digita código do projeto, data de início e fim, seleciona item do Product
Backlog, digita tarefa, informar responsável, horas estimadas, horas na semana e status
da tarefa;
3. Usuário clica em inserir novo registro; e
4. Sistema salva informações no banco de dados.
Alterar Sprint Backlog – Alternativo
Caso o usuário necessite alterar alguma informação:
1. Sistema apresenta tela para cadastro de Sprint Backlog (Tela Sprint Backlog);
2. Usuário altera os campos que necessita;
3. Usuário clica em atualizar;
4. Sistema salva informações no banco de dados.
69
Excluir Sprint Backlog – Alternativo
1. Sistema apresenta tela para cadastro de Sprint Backlog (Tela Sprint Backlog);
2. Usuário clica em excluir; e
3. Sistema exclui Sprint Backlog do banco de dado.
Tarefa finalizada para um Sprint Backlog – Exceção
Caso a tarefa esteja no status “Finalizada”, no passo 2 do cenário Excluir Sprint Backlog:
1. Sistema apresenta exibe a mensagem: “Não é possível excluir uma tarefa no status
Finalizado”; e
2. Sistema não exclui tarefa do banco de dados.
Sprint Backlog finalizada para um projeto – Exceção
Caso o Sprint Backlog esteja no status “Finalizado”, no passo 2 do cenário Excluir Sprint
Backlog:
3. Sistema apresenta exibe a mensagem: “Não é possível excluir uma Sprint Backlog no
status Finalizado”; e
4. Sistema não exclui Sprint Backlog do banco de dados.
UC 03.02 – Selecionar Itens do Product Backlog
Permite ao usuário selecionar os itens do Product Backlog que serão desenvolvidos em uma
determinada Sprint, esses itens selecionados formar o Sprint Backlog (Tela Manter Sprint).
Requisito:
• RF03: O sistema deverá permitir selecionar os itens do Product Backlog que irão
compor a Sprint Backlog.
Condição:
• Pré-Condição: o Product Backlog do projeto deve estar definido;
• Pré-Condição: a Sprint do projeto deve estar criada; e
• Pós-Condição: itens do Product Backlog associados à Sprint..
70
UC 03.03 – Cadastrar Tarefas
Permite ao usuário cadastrar tarefas para cada item do Product Backlog selecionado (Tela
Manter Sprint).
Requisito:
• RF04: O sistema deverá permitir cadastrar, alterra e excluir tarefas em uma Sprint
Backlog.
Condição:
• Pré-Condição: os itens do Product Backlog devem estar selecionados.
• Pós-Condição: itens do Product Backlog quebrados em tarefas.
UC 03.04 – Alocar Tarefa
Permite alocar uma tarefa a um membro do time do projeto (Tela Manter Sprint).
Requisito:
• RF05: O sistema deverá permitir a alocação de uma tarefa a um membro do time.
Condição:
• Pré-Condição: o projeto deve estar associado a um time;
• Pré-Condição: as tarefas devem estar cadastradas no sistema; e
• Pós-Condição: tarefa alocada a um membro do time do projeto.
UC 03.05 – Informar Duração de Cada Tarefa
Permite ao usuário informar a duração estimada e as datas de início e fim de cada tarefa
(Tela Manter Sprint).
Requisitos:
• RF06: O sistema deverá permitir informar a data de início e fim de cada tarefa; e
• RF07: O sistema deverá permitir informar o tempo de duração de cada tarefa.
Condição:
• Pré-Condição: a tarefa deve estar cadastrada no sistema; e
• Pós-Condição: datas de início e fim e estimativa de horas informados para a tarefa.
71
UC 03.06 – Informar Horas Trabalhadas em Cada Tarefa
Permite ao usuário informar semanalmente a quantidade de horas trabalhadas na tarefa (Tela
Manter Sprint).
Requisito:
• RF08: O sistema deverá permitir informar horas trabalhadas em cada tarefa;
Condição:
• Pré-Condição: tarefa deve estar cadastrada no sistema; e
• Pós-Condição: horas trabalhas informadas para a tarefa.
UC 03.07 – Informar Status da Tarefa
Permite ao usuário informar o status de andamento da tarefa (Tela Manter Sprintt). Status de
uma tarefa:
1. Não Iniciada;
2. Em Desenvolvimento;
3. Em Testes;
4. Finalizada;
5. Pendente.
Requisito:
• RF09: O sistema deverá permitir selecionar o status de andamento da tarefa.
Condição:
• Pré-Condição: tarefa deve estar cadastrada no sistema; e
• Pós-Condição: status da tarefa informado.
UC 03.08 – Gerenciar Reunião Diária
Permite ao Scrum Team informar o andamento do projeto ao Scrum Master e definir as
próximas tarefas (Tela Manter Sprint).
Requisito:
• RF10: O sistema deverá permitir inserir informações sobre a reunião diária;
72
Condição:
• Pré-Condição: a Sprint do projeto deve estar cadastrada; e
• Pós-Condição: reunião diária informada.
UC 03.09 – Visualizar Gráfico Sprint Burndown
Permite ao Scrum Master acompanhar o desenvolvimento do projeto (Tela Visualizar Sprint
Burndown).
Requisito:
• RF11: O sistema deverá permitir visualizar o gráfico Sprint Burndow;
Condição:
• Pré-Condição: a Sprint do projeto dever estar cadastrada.
