UNIVERSIDADE ANHEMBI MORUMBI
ANDRÉ ONUKI DOS SANTOS
CLEUMIR DOS SANTOS DE SOUZA
TIAGO LUIZ DO NASCIMENTO
TASKBOARD DIGITAL PARA EQUIPES SCRUM
São Paulo
2011
ANDRÉ ONUKI DOS SANTOS
CLEUMIR DOS SANTOS DE SOUZA
TIAGO LUIZ DO NASCIMENTO
TASKBOARD DIGITAL PARA EQUIPES SCRUM
Trabalho de Conclusão de Curso apresentado
como exigência parcial para a obtenção do
título de Bacharel em Ciências da Computação
da Universidade Anhembi Morumbi.
Orientador: Luís Fernando Aires Branco Menegueti
São Paulo
2011
ANDRÉ ONUKI DOS SANTOS
CLEUMIR DOS SANTOS DE SOUZA
TIAGO LUIZ DO NASCIMENTO
TASKBOARD DIGITAL PARA EQUIPES SCRUM
Trabalho de Conclusão Curso apresentado
como exigência parcial para a obtenção do
título de Bacharel em Ciência da Computação
da Universidade Anhembi Morumbi, sob a
orientação do Prof. Luís Fernando Aires.
Aprovado em
Prof.
Universidade Anhembi Morumbi
Prof.
Universidade Anhembi Morumbi
Prof.
Universidade Anhembi Morumbi
RESUMO
O taskboard pode fornecer diversas informações sobre o andamento de um
sprint para a equipe Scrum. Entretanto essas informações nem sempre são
fáceis de serem retiradas do taskboard. E requerem que algum membro da
equipe fique constantemente verificando o taskboard para poder anotar as
informações e trabalhá-las. O objetivo deste trabalho é criar uma ferramenta
digital para substituir o taskboard convencional do Scrum. As principais
vantagens de um taskboard digital sobre outro comum são a possibilidade de
integração com outras ferramentas e a automatização da coleta de dados
sobre o sprint. Os dados coletados podem fornecer muitas informações sobre o
progresso do sprint e/ou gargalos no processo. Estes dados podem auxiliar o
Scrum master a tomar decisões para melhoria do processo ou mostrar com
maior antecedência que os prazos do sprint possam estar comprometidos.
Outra vantagem do taskboard digital é a possibilidade de pessoas que
trabalham em outra localidade utilizarem o mesmo taskboard.
PALAVRAS-CHAVE: Scrum. Metodologias ágeis. taskboard.
ABSTRACT
A taskboard may offer many information about the sprint’s progress for a Scrum
team. However, these information are not easily taken directly from the
taskboard and require that a member of the team is constantly checking the
taskboard to collect the data and take the information from it. The goal of this
project is to develop a digital tool to replace the conventional taskboard. The
main advantages of the digital taskboard over the conventional are the
possibility of integration with other tools and data collection automation. The
data collected this way may provide information about the sprint’s progress
and/or bottlenecks on the process. The data may help the Scrum Master to
make decisions to improve the process or show in advance that the sprint’s
deadline may not be reached. Another advantage of the digital taskboard is the
possibility of people who work remotely to share the same taskboard the other
team members use.
KEY WORDS: Scrum. Agile Methodologies. taskboard.
LISTA DE FIGURAS
Figura 1: O processo scrum. ............................................................................ 16
Figura 2: Burn down chart. ............................................................................... 18
Figura 3: Burn up chart ..................................................................................... 19
Figura 4: Cumulative flow diagram. .................................................................. 20
Figura 5: Scrum Ninja. ...................................................................................... 21
Figura 6: Green Hopper. .................................................................................. 22
Figura 7: Vip Task Manager. ............................................................................ 23
Figura 8: Padrão MVC ...................................................................................... 24
Figura 9: Casos de uso. ................................................................................... 33
Figura 10: Diagrama de classes das entidades................................................ 34
Figura 11: Diagrama de classes de controle. ................................................... 35
Figura 12: Diagrama de classes – Modelo. ...................................................... 37
Figura 13: Tela de login. ................................................................................... 37
Figura 14: Barra de ferramentas. ..................................................................... 38
Figura 15: Tela do projeto. ............................................................................... 38
Figura 16: Diagrama de classes dos diálogos. ................................................. 39
Figura 17: Diagrama de classes interface com o usuário. ................................ 39
Figura 18: Diagrama de classes criadoras de gráficos ..................................... 40
Figura 19: Diagrama de classes – DAO ........................................................... 40
Figura 20: Diagrama de classes controlador. ................................................... 41
Figura 21: Utilização do sistema. ..................................................................... 42
LISTA DE TABELAS
Tabela 1: Características das Ferramentas Existentes .................................... 23
Tabela 2: Requisitos Funcionais ...................................................................... 31
Tabela 3: Requisitos Não Funcionais ............................................................... 32
Tabela 4: Casos de Uso ................................................................................... 33
LISTA DE SIGLAS
CSS3
Cascading Style Sheets - Folhas de Estilo em Cascata
DAO
Data Access Object – Objeto de Acesso Dados
HTTP
HyperText Transfer Protocol - Protocolo de Transferência HiperTexto
JAVA
Linguagem de Programação Orientada a Objetos
JSP
Java Server Pages - Páginas de Servidor Java
RF
Requisitos Funcionais
RNF
Requisitos Não Funcionais
SQL
Structured Query Language - Linguagem de Consulta Estruturada
UML
Unified Modeling Language - Linguagem de Modelagem Unificado
XML
Extensible Markup Language - Linguagem de Marcação Extensível
SUMÁRIO
1 INTRODUÇÃO .............................................................................................. 11
1.1 Objetivos ................................................................................................. 12
1.2 Justificativa ............................................................................................. 12
1.3 Abrangência............................................................................................ 12
1.4 Estrutura do Trabalho ............................................................................. 13
2 METODOLOGIAS ÁGEIS ............................................................................. 14
2.1 Scrum ..................................................................................................... 14
2.1.1 Equipe Scrum ................................................................................... 15
2.1.2 Reuniões .......................................................................................... 15
2.1.3 Artefatos ........................................................................................... 16
2.2 Taskboard ............................................................................................... 17
2.3 Monitoramento ........................................................................................ 17
2.3.1 Burn Down Chart .............................................................................. 17
2.3.2 Burn Up Chart .................................................................................. 18
2.3.3 Cumulative Flow Diagram ................................................................ 19
3 FERRAMENTAS EXISTENTES .................................................................... 21
3.1 ScrumNinja ............................................................................................. 21
3.2 GreenHopper .......................................................................................... 22
3.3 Vip Task Manager ................................................................................... 22
3.4 Comparações de Ferramentas Existentes .............................................. 23
4 TECNOLOGIAS E PADRÕES DE DESENVOLVIMENTO ........................... 24
4.1 Padrão MVC ........................................................................................... 24
4.2 Google Web Toolkit ................................................................................ 25
4.3 PHP ........................................................................................................ 25
4.4 Struts ...................................................................................................... 26
4.5 Ruby On Rails ......................................................................................... 26
4.6 HTML5 .................................................................................................... 26
4.7 Hibernate ................................................................................................ 27
5 METODOLOGIA ........................................................................................... 28
5.1 Framework de Desenvolvimento Web .................................................... 28
5.2 Persistência de Dados ............................................................................ 29
5.3 Banco De Dados ..................................................................................... 30
5.4 Ambiente de Desenvolvimento ............................................................... 30
5.5 Ferramenta para Geração de Gráficos ................................................... 30
6 MODELAGEM DO SOFTWARE ................................................................... 31
6.1 Requisitos Funcionais e Não Funcionais ................................................ 31
6.2 Casos de Uso ......................................................................................... 32
6.3 Diagramas de Classe.............................................................................. 34
6.4 Diagramas de Sequência........................................................................ 35
7 IMPLEMENTAÇÃO DO PROJETO .............................................................. 36
7.1 Modelo .................................................................................................... 36
7.2 Visualização ............................................................................................ 37
7.3 Controlador ............................................................................................. 40
8 TESTES ........................................................................................................ 42
9 CONCLUSÃO ............................................................................................... 43
9.1 Trabalhos Futuros ................................................................................... 43
REFERÊNCIAS ................................................................................................ 45
APÊNDICE A – CASOS DE USO .................................................................... 48
APÊNDICE B – DIAGRAMAS DE SEQUÊNCIA ............................................. 60
ANEXO A - MANIFESTO ÁGIL ....................................................................... 64
11
1 INTRODUÇÃO
O Scrum é utilizado para o desenvolvimento de produtos complexos,
desde o início da década de 1990. [...] Scrum não é um processo ou técnica
para criação de produtos, mas uma estrutura na qual você pode empregar
vários processos e técnicas. O papel do Scrum é trazer à tona a eficácia
relativa de suas práticas de desenvolvimento de modo que você possa
melhorá-las enquanto fornece uma estrutura na qual produtos complexos
possam ser desenvolvidos (SCHWABER; SUTHERLAND, 2010).
O coração e esqueleto do Scrum é o processo interativo e incremental. A
saída de cada interação é um incremento no produto e durante cada interação
há uma inspeção diária onde os indivíduos inspecionam o trabalho dos outros
membros da equipe e fazem as adaptações necessárias. (SCHWABER, 2004).
A cada interação, são adicionadas ao produto novas funcionalidades,
provenientes do backlog do projeto. Um modo de visualizar tanto as
funcionalidades futuras quanto as que estão em desenvolvimento é o
taskboard.
O SCRUM, nome originário do jogo de rúgbi, teve suas raízes em
indústrias japonesas no início de 1986 por Takeuchi e Nonaka, mas começou a
ser usado nos moldes atuais apenas em 1996 por Jeff Sutherland e Ken
Schwaber. Suas técnicas enfatizam a realização de reuniões diárias, o
aumento da autonomia dos membros do time, foco nas entregas e a
flexibilidade no seguimento de processos pré-definidos (LARMAN, 2003).
Um projeto é caracterizado por possuir objetivo e requisitos claramente
definidos (Escopo), obedecer ao orçamento aprovado (Custo) e deve ser
finalizado no prazo especificado (Tempo) (SCHWALBE, 2002).
Segundo HIGHSMITH(2002) fundador da Agile Alliance e criador do
método Adaptative Software Evelopment, define os princípios básicos do
gerenciamento ágil de projeto como:
Entregar sempre algo útil ao cliente;
Manter a equipe sempre comprometida;
Construir um ambiente de liderança e colaboração;
Construir times competentes e colaborativos;
12
Aumentar a autonomia da equipe na tomada de decisões;
Usar um processo iterativo com iterações curtas para que seja possível
a entrega rápida de novas funcionalidades;
Encorajar a adaptabilidade;
Buscar sempre a excelência técnica;
Focar nas atividades de entrega e não no seguimento de processos
pré-definidos.
1.1 Objetivos
Este trabalho tem como objetivo criar um software de taskboard para
equipe Scrum, chamado dTaskboard, que prevê a retirada de estatísticas a
partir do uso do software e respectivos relatórios e terá seu código aberto.
1.2 Justificativa
Existem vários softwares para gerenciamento de projetos ágeis ou que
utilizam Scrum. Muitos são gratuitos e ou livres. Entretanto, poucos possuem
uma interface que possa substituir o taskboard de maneira satisfatória.
Alguns softwares comerciais substituem o taskboard, entretanto são
softwares proprietários. Em geral, eles possuem licenças caras ou oferecem
licenças restritas a projetos de software livre.
Entretanto, o mais importante do projeto é a retirada das estatísticas de
uso do taskboard. Esses números podem ser bastante importantes para
diagnosticar possíveis problemas no projeto.
1.3 Abrangência
O software poderá ser utilizado pela internet, para que pessoas mesmo
que em locais geograficamente separados possam compartilhar o mesmo
taskboard. O software fará autenticação e autorização de usuários, para o
controle do executor de cada tarefa.
13
Serão possíveis modificações simultâneas por diferentes usuários. A
interface com o usuário se dará exclusivamente por meio de um navegador da
internet.
Haverá uma interface de visualização de relatórios onde serão
mostradas as estatísticas disponíveis.
Não serão criadas interfaces para taskboards diferentes do Scrum, como
o taskboard do Kanban.
1.4 Estrutura do Trabalho
Este trabalho é composto de 9 capítulos, que explicam sobre o Scrum e
seu taskboard, as ferramentas já existentes para substituir o taskboard
convencional e as ferramentas para desenvolvimento de aplicações web. Então
são discutidas as decisões de ferramentas utilizadas no projeto, a modelagem
do mesmo e a fase de testes.
O capítulo 2 é uma descrição dos métodos ágeis. Neste capítulo é
descrito o Scrum, sua teoria, seus participantes e componentes. Nele também
é descrito o uso do taskboard.
No capítulo 3 é feito um levantamento das ferramentas já existentes.
Suas funcionalidades.
No capítulo 4 apresentam-se várias ferramentas e frameworks para
desenvolvimento de aplicações para web.
O capítulo 5 é dedicado à metodologia do projeto, ou seja, será
apresentado as ferramentas usadas para a elaboração do trabalho.
O capítulo 6 é destinado à modelagem do sistema, incluindo o
levantamento dos requisitos funcionais e não funcionais do sistema, os casos
de uso, diagramas de classes e de sequências.
O capítulo 7 apresenta a implementação do projeto, o qual segue o
padrão MVC.
No capítulo 8 é descrito o teste realizado na empresa Touch Tecnologia.
O capítulo 9 destina-se à conclusão do trabalho.
14
2 METODOLOGIAS ÁGEIS
Nos dias 11 a 13 de fevereiro de 2001, nas montanhas Wasatch de
Utah, Estados Unidos, 17 pessoas reuniram-se para discutir sobre a
necessidade de um processo de desenvolvimento de software alternativo aos
processos da época. Entre eles estavam representantes de Programação
Extrema, Scrum, DSDM, Desenvolvimento Adaptativo de Software, Crystal,
Desenvolvimento Dirigido por Característica, Programação Pragmática, entre
outros simpatizantes da causa. Desta reunião, emergiu o Manifesto Ágil de
Desenvolvimento de Software. (HIGHSMITH, 2001).
Segundo Abrahamsson (2002), “o aspecto focal dos métodos ágeis são
a simplicidade e a velocidade. Durante o desenvolvimento, os desenvolvedores
concentram-se em entregar as funcionalidades mais necessárias”. Entregues
estas funcionalidades, são coletados comentários sobre o que foi entregue e
reage-se à essa informação recebida.
Um processo ágil é: incremental (ciclos rápidos onde são entregues
softwares funcionais), cooperativo (clientes e desenvolvedores comunicam-se
constantemente), simples (o método é fácil de aprender, modificar e é bem
documentado) e adaptativo (capaz de fazer mudanças em último momento).
ABRAHAMSSON (2002).
2.1 Scrum
Na década de 90, Ken Schwaber e Jeff Sutherland em busca de uma
solução mais simples, ágil e eficaz para a gerência de projetos, baseando-se
em suas próprias experiências, desenvolveram um novo método para gerenciar
projetos e o chamaram de Scrum. Esta nova metodologia trouxe ao mercado a
inovação para manter a consistência, respeitar os prazos determinados e o
maior ganho de desempenho da equipe envolvida no projeto sem perder o foco
da entrega no menor tempo possível (SCHWABER; BEEDLE, 2001).
O processo Scrum define a equipe, artefatos e encontros. No Scrum,
cada iteração, chamada de sprint, dura 30 dias e no final de cada sprint é feita
uma entrega de um software funcional (SCHWABER; BEEDLE, 2001).
15
2.1.1 Equipe Scrum
A equipe Scrum é composta de 5 a 7 desenvolvedores que cuidam de
todo o desenvolvimento, análise, documentação e testes. Além dos
desenvolvedores, existe o Scrum master, cujas atividades incluem auxiliar os
desenvolvedores a manter seus níveis de produtividade no máximo, manter os
artefatos e conduzir as reuniões. Há ainda o product owner, que é o único que
prioriza os requerimentos no product backlog (SCHWABER; BEEDLE, 2001).
2.1.2 Reuniões
“O Scrum define dois tipos de reuniões: a daily Scrum e o planning
meeting” (SCHWABER; BEEDLE, 2001).
A daily Scrum é uma reunião de, no máximo, quinze minutos, realizada
diariamente preferencialmente no mesmo local e na mesma hora. Essa reunião
serve para proporcionar visibilidade do trabalho entre os membros da equipe,
promover sua comunicação, levantar quais obstáculos atrapalharam o
desenvolvimento desde a última daily scrum e servir de oportunidade para
decisões rápidas com relação ao progresso do sprint. Nessa reunião, cada
membro da equipe detalha o que ele completou desde a última daily Scrum, o
que ele pretende fazer até a próxima daily Scrum e quais obstáculos estiveram
em seu caminho (SCHWABER, 2004).
“O planning meeting consiste de duas partes. Na primeira, a equipe e o
product owner reúnem-se para definir quais requerimentos serão entregues no
final do sprint. Na segunda, a equipe define como desenvolverá esses
requerimentos” (SCHWABER; BEEDLE, 2001).
Na segunda etapa do planning meeting, os requerimentos são
transformados em tarefas menores e é estimado o tempo necessário para
executar cada tarefa. Os membros da equipe se voluntariam para fazer cada
tarefa. Deve-se levar em conta o tempo disponível de cada membro da equipe
para não sobrecarregá-los (SUTHERLAND; SCHWABER, 2011).
16
2.1.3 Artefatos
Product backlog é a lista priorizada de todos os requerimentos do
produto. Estes requerimentos podem ser funcionalidades, recursos ou
tecnologias. Sempre que uma nova funcionalidade é necessária, ela é
adicionada ao product backlog, e do mesmo modo, quando uma funcionalidade
é entregue, ela é removida do backlog (SCHWABER; BEEDLE, 2001).
“Sprint backlog são os requerimentos que a equipe concorda em
entregar no sprint atual. O sprint backlog é definido durante o planning meeting”
(SCHWABER; BEEDLE, 2001).
Sprint backlog graph, ou burn down chart, é um gráfico que mostra a
quantidade de trabalho necessário para terminar o sprint backlog por dias
trabalhados. Este gráfico é atualizado diariamente e ajuda a visualizar o
progresso do sprint (SCHWABER; BEEDLE, 2001).
A figura 1 representa o processo Scrum, desde a fase inicial até a fase
de incremento.
Figura 1: O processo scrum. Fonte: SUTHERLAND, SCHWABER (2011) (traduzida
pelos autores).
17
2.2 Taskboard
Muitas equipes fazem uso de uma ferramenta visual para monitorar as
tarefas durante o sprint. “Em geral utiliza-se um taskboard onde as tarefas,
escritas em notas auto-adesivas, migram entre as colunas: “Não Iniciada”, “Em
Progresso”, “Verificar” e “Completa”” (SUTHERLAND; SCHWABER, 2010).
O taskboard provê muitas informações por mostrar os requerimentos
distribuídos em tarefas menores. Cada nota de tarefa pode fornecer outras
informações como tipo de trabalho (codificação, testes, etc) e o número de
horas estimadas para sua execução. O taskboard também ajuda a verificar a
quantidade de horas remanescentes para o término das tarefas e com isso
produzir o burn down chart (MIRANDA; BOURQUE, 2010).
“No taskboard, como o número de tarefas que estão em codificação ou
quantas estão em testes, não são exploradas sob a assunção de que o
importante é o trabalho completo e o trabalho remanescente” (MIRANDA;
BOURQUE, 2010).
2.3 Monitoramento
O taskboard pode fornecer muitas informações visuais. Mas se os dados
de cada tarefa que nele consta forem colhidos, ele pode oferecer ainda mais
informações.
Seguem alguns dados de monitoramento que podem ser retirados do
taskboard.
2.3.1 Burn Down Chart
O burn down chart de iteração é um gráfico derivado dos dados do
taskboard. Seu público alvo são os próprios membros da equipe. Ele mostra o
número de horas de trabalho restantes ante o número de dias remanescentes
na iteração atual. Essa informação é utilizada para prever se o trabalho pode
ser concluído, ou se será necessário remanejar parte do trabalho, ou ainda
realizar horas-extras (MIRANDA; BOURQUE, 2010).
18
A figura 2 abaixo mostra o progresso geral do projeto em relação aos
sprints
do
mesmo.
“Esta
informação
pode
ser
usada
tanto
pelos
desenvolvedores quanto pelos product owners para estimar em quanto tempo o
projeto pode ser terminado” (MIRANDA; BOURQUE, 2010).
Figura 2: Burn down chart. Fonte: SUTHERLAND, SCHWABER (2011).
2.3.2 Burn Up Chart
O burn up chart é um gráfico parecido com o burn down chart. Entretanto
ele mostra a quantidade de trabalho realizado ante o dia da iteração atual. Ele
também tem as mesmas duas variedades do burn down chart, iteração e
versão.
Phil Goodwin e Russ Rufer propuseram um modelo para o burn up chart
de iteração que permite que aconteçam mudanças no escopo do projeto. Neste
modelo, há uma linha que representa o teto, ou a marca de 100%, do
progresso do projeto. Quando há alguma alteração no escopo, esta linha sobe,
ou desce, de acordo com a expectativa de aumento, ou diminuição, do trabalho
(COCKBURN, 2004).
19
A figura 3 mostra um burn up chart de iteração de acordo com o modelo
Goodwin-Rufer.
Figura 3: Burn up chart. Fonte: GREENHOPPER (2011)
2.3.3 Cumulative Flow Diagram
Cumulative flow diagram é outra representação para o acompanhamento
de progresso em um projeto ágil de software, baseado no burn up chart. Como
o burn up chart, o cumulative flow diagram retrata o número de recursos
concluídos ao longo do tempo. O cumulative flow diagram proporciona uma
visão mais detalhada do status do projeto em qualquer ponto no tempo. Ele
também permite a detecção precoce de problemas que pode facilitar a
correção dos mesmos (CABRI; GRIFFITHS, 2006).
Na Figura 4, são mostradas a parte do trabalho “Iniciado” e uma
pequena parte no estado “Em Progresso”. Em seguida aparecem os trabalhos
em fase de “Verificação” e “Completo”. No final do último sprint todo o trabalho
deve aparecer no estado “Completo”.
20
Figura 4: Cumulative flow diagram. Fonte: REINERTSEN (traduzido).
O cumulative flow diagram pode também ser utilizado para medir o
andamento de um sprint. Neste caso o eixo horizontal fará referência aos dias
e o eixo vertical à quantidade de trabalho realizada.
21
3 FERRAMENTAS EXISTENTES
O desenvolvimento de software envolve muitas técnicas como requisitos,
recursos e tecnologia, que podem mudar durante o processo. Isto torna o
processo de desenvolvimento imprevisível e complexo, requerendo flexibilidade
para acompanhar as mudanças. O resultado do processo deve ser um software
que é realmente útil para o cliente (SCHWABER, 1996).
Para auxiliar a equipe SRUM na fase de produção de um software
utiliza-se o taskboard físico ou digial.
Os taskboard mais aceitos no mercado devido sua praticidade,
usabilidade, outros recursos que serão apresentados são: SrumNinja,
GreenHopper e Vip Task Manager.
3.1 ScrumNinja
O ScrumNinja foi desenvolvida por dois especialistas de Sênior de
tecnologia e Certificados como Scrum Masters que são eles: Rodney Carvalho
e Lowenfels David.
Como principal objetivo o software foi projetado com total integridade
conceitual, ele mantém a simplicidade intuitiva do quadro de tarefa comum,
fornecendo o benefício de atualizações em tempo real, grande variedade de
cores, armazenamento de dados (comentários, observações e imagens) e
reforça as melhores práticas para novas equipes para Scrum (SCRUMNINJA,
2011).
Figura 5: Screenshot da ferramenta ScrumNinja
Fonte: (SCRUMNINJA SCREENSHOT, 2011).
22
3.2 GreenHopper
Este taskboard foi desenvolvido pela Atlassian uma empresa australiana
que atua no ramo de desenvolvimento de software para gerenciamento de
projetos.
O GreenHopper é uma ferramenta ideal para auxiliar o scrum master no
gerenciamento de tarefas, planejamentos de sprints, compartilhamento dos
dados e acompanhamento de processos do projeto. É um software que tem
como característica: edição online, tela de gráficos e fácil usabilidade
(GREENHOPPER, 2011).
Figura 6: Screenshot da ferramenta GreenHopper
Fonte: (GREENHOPPER SCREENSHOT, 2011).
3.3 Vip Task Manager
O Vip Task Manager está entre os softwares de taskboard mais
completo para gerenciamento de tarefas para equipes Scrum.
Ele viabiliza o aumento do desempenho da empresa, a eficácia e a
maior
produtividade.
Dispões
de
recursos
para
planejar,
programar,
compartilhar, controlar tarefas, agendar compromissos da equipe, e exibir fase
do processo entre outras funcionalidades (VIP QUALITY SOFTWARE, 2010).
23
Figura 7: Screenshot da ferramenta Vip Task Manager
Fonte: (VIP TASK MANAGER SCREENSHOT, 2011).
3.4 Comparações de Ferramentas Existentes
A figura abaixo aborda os nomes das ferramentas e suas características
mais importantes e também contém as funcionalidades contidas em cada
ferramenta existente.
Tabela1: Características das Ferramentas Existentes
Fonte: Os Autores (2011).
24
4 TECNOLOGIAS E PADRÕES DE DESENVOLVIMENTO
Das páginas estáticas do passado, aos sistemas dinâmicos atuais, a
programação para a Web vem avançando em ritmo acelerado. Com este
crescimento, cada vez mais é necessário à utilização de ferramentas para
aumentar a produtividade. Tanto as ferramentas de desenvolvimento quanto as
linguagens de programação vêm sendo aprimoradas para atender essa nova
demanda (LOVATTO, 2007).
A seguir são apresentadas algumas ferramentas para programação para
web que embasaram na escolha da ferramenta escolhida para o trabalho.
4.1 Padrão MVC
Segundo MAGELA (2006), o padrão MVC foi implementado por Jim
Althoff. Onde se descreve da seguinte maneira:
Modelo: Camada responsável pelos dados que contém a lógica dos
negócios de forma separada.
Visão: Responsável pela a saída dos dados, lógica de apresentação dos
dados ao usuário.
Controle: Responsável por fazer o elo entre o Modelo e a Visão, recebe
e interpreta as entradas de dados dos usuários.
A figura abaixo exemplifica a ligação entre as camadas do padrão MVC.
Figura 8: Padrão MVC fonte: REENSKAUG(2003, traduzida)
25
4.2 Google Web Toolkit
Durante a conferência JavaOne de 2006, o Google apresentou sua nova
ferramenta para desenvolvimento de aplicações web, o Google Web Toolkit
(GWT). Com o GWT, pode-se programar tanto a parte cliente da aplicação,
quanto a parte servidor, utilizando-se a linguagem Java e um mínimo de HTML.
Todo código JavaScript é gerado a partir do código Java, e o GWT cuida das
diferenças entres os diferentes navegadores (OLSON, 2007).
Com o GWT pode-se escrever toda a aplicação utilizando conceitos de
orientação a objetos mesmo que o Javascript não possua todos os recursos de
orientação a objetos, pois o código é escrito em Java. Outra vantagem são as
bibliotecas que são adicionadas ao GWT tanto pelo Google quanto por
terceiros (PERRY, 2006).
4.3 PHP
Concebido em 1994 por Rasmus Lerdorf, o PHP é uma linguagem de
script orientada a objetos utilizada para a programação de páginas da web. O
PHP permite que coloquem programas dentro de uma página HTML. O código
do programa será executado toda vez que alguém pedir para ver essa página.
O PHP é gratuito e tem seu código aberto. Em janeiro de 2001,
aproximadamente 5 milhões de domínios por todo o mundo utilizavam PHP
(WELLING; THOMSON, 2008).
O PHP possui bom desempenho, um único servidor pode responder a
milhões de pedidos por dia. Se for necessário ainda mais performance, o PHP
é facilmente escalável adicionando outros servidores em estrutura horizontal.
Ele possui integração com tipos de bancos de dados e possui numerosas
bibliotecas para tarefas relacionadas à internet, como envio de emails, criação
dinâmica de imagens, geração de PDF, e análise de arquivos XML (WELLING;
THOMSON, 2008).
26
4.4 Struts
O objetivo do Struts2 é facilitar o desenvolvimento web para os
programadores. Para tal, ele automatiza muitas tarefas comuns, como
converter dados de formulários para serem utilizados nas classes Java.
Também utiliza convenção sobre configuração e anotações do Java para
diminuir a quantidade de arquivos de configuração (BROWN, DAVIS,
STANLICK, 2008).
O Struts2 segue o padrão MVC. No Struts2 não há necessidade de se
implementar o controller, mas ele pode ser configurado por arquivos XML. O
model, onde fica toda a lógica de domínio da aplicação é implementado pelo
programador em Java. O view pode ser implementado com páginas JSP ou
ferramentas de template como Velocity e FreeMarker (BROWN; DAVIS;
STANLICK, 2008).
4.5 Ruby On Rails
Ruby on Rails (Rails) é um framework para facilitar o desenvolvimento,
construção e manutenção de aplicações web. O Rails extende Ruby de uma
maneira para facilitar o trabalho dos desenvolvedores e diminuir o tamanho dos
programas e aumentar sua legibilidade (RUBY; THOMAS; HANSSON, 2011).
As aplicações Rails são escritas em Ruby, que é uma linguagem de
script orientada a objetos. O Rails segue o padrão MVC e também utiliza o
conceito de convenção sobre configuração (RUBY; THOMAS; HANSSON,
2011).
Todas as aplicações Rails têm suporte a testes embutido no próprio
framework. Sempre que uma nova funcionalidade é adicionada, o Rails cria um
método para que o desenvolvedor escreva o teste para esta funcionalidade
(RUBY; THOMAS; HANSSON, 2011).
4.6 HTML5
HTML5 é a nova geração do HTML. Ele provê novos recursos
necessários para aplicações web modernas. Também padroniza recursos
27
utilizados por anos, mas que nunca foram formalmente documentados. Ele foi
concebido para ser multi-plataforma, necessitando apenas de um navegador
moderno para utilizar seus recursos (PILGRIM, 2010).
O HTML5 traz melhorias para as interfaces, utilizando CSS3 para
customizar o estilo dos elementos das páginas, e melhorias para os
formulários, como os novos componentes de seleção de datas (HOGAN, 2010).
4.7 Hibernate
Persistência de dados é um requisito comum de muitas aplicações. Essa
persistência na maior parte das vezes envolve o uso de SQL e sistemas
gerenciadores de bancos de dados relacionais. Entretanto, a representação
tabular dos dados é bem diferente da representação utilizada na orientação a
objetos (BAUER; KING, 2005).
O mapeamento objeto relacional é o nome dado às soluções de
automação do trabalho de converter entre essas duas representações. O
Hibernate é uma dessas ferramentas, desenvolvida desde 2001, e enfatiza
produtividade e liderança técnica. O Hibernate já é utilizado em milhares de
aplicações, por dezenas de milhares de usuários (Bauer; King, 2005).
28
5 METODOLOGIA
O
sistema
será
desenvolvido
para
substituir
os
taskboards
convencionais. Ele terá uma interface que se assemelhará a um taskboard
convencional.
Além de mostrar os dados como um taskboard convencional, ele
também gerará os gráficos de monitoramento vistos no capítulo 2.
O sistema deve possibilitar a utilização de múltiplos usuários
simultaneamente pela internet. Haverá diferenciação dos usuários por papéis
que cada usuário pode assumir. Todos os dados serão salvos em um banco de
dados relacional.
Para desenvolver o projeto, serão utilizadas algumas das tecnologias
apresentadas no capítulo 4. Segue uma breve discussão sobre os motivos da
seleção das ferramentas.
5.1 Framework de Desenvolvimento Web
A maior parte das linguagens e frameworks para programação para web
utilizam o padrão MVC. E na maior parte das vezes, a parte de view é feita em
um arquivo de formato diferente dos outros utilizados para as outras partes do
sistema, e este arquivo quase nunca é compilado. Por este motivo é muitas
vezes difícil encontrar erros nestes arquivos, como uma variável que não foi
declarada, e estes erros se manifestam apenas quando o programa está sendo
executado. No GWT todos os arquivos são compilados, inclusive os que fazem
parte da View. Portanto erros deste tipo podem ser encontrados em tempo de
compilação.
Os principais editores gratuitos, Eclipse e Netbeans, têm plugins para
Ruby, PHP. Entretanto o nível de maturidade desses plugins é inferior ao
tratamento nativo que esses editores dão ao Java. Como o GWT utiliza apenas
código Java, é mais fácil escrever os programas em GWT nesses editores do
que nas outras linguagens.
Os criadores do GWT também disponibilizam um plugin para a IDE
Eclipse. Este plugin se encarrega de compilar a aplicação e de implantar em
29
um servidor de testes Tomcat. O plugin para Eclipse pode também implantar a
aplicação num servidor do Google, para que esta fique disponível na Internet.
Os criadores do GWT disponibilizam a configuração para Ant# para
auxiliar a compilação e instalação da aplicação. Também há um plugin para
Maven# com o mesmo intuito. Entretanto esse plugin para Maven não tem
suporte oficial.
O GWT foi feito para rodar no servidor Tomcat, que é uma
implementação das tecnologias JavaServer Pages (JSP) e Java Servlets. O
Tomcat é gratuito e tem seu código fonte aberto.
Para hospedagem remota existem hospedeiros que fornecem o Tomcat,
entretanto, eles em geral cobram mais caro que os outros servidores de HTTP.
Existe também a hospedagem no Google em seu Appengine. Neste caso, a
hospedagem é gratuita até que se utilize sua quota de processamento e/ou
banda. Quando a quota é estourada, ou o site é desligado, ou é cobrada uma
taxa.
Foi decidido utilizar o framework GWT para fazer a parte prática do
projeto.
Todos
os
frameworks
possuem
boas
ferramentas
para
desenvolvimento e instalação das aplicações. O fato de o GWT ter
interoperabilidade entre navegadores, as vantagens de se utilizar o Java tanto
para o desenvolvimento da parte servidor quanto da parte cliente são grandes
vantagens sobre os outros frameworks.
O projeto não utilizará o HTML5 por ser uma tecnologia muito nova que
não está disponível em todos os navegadores.
5.2 Persistência de Dados
Para realizar a persistência dos dados, e respectiva busca, será utilizado
o Hibernate. O Hibernate é uma das mais antigas e mais estabelecidas
ferramentas de mapeamento objeto relacional para Java.
30
5.3 Banco de Dados
Para facilitar o trabalho de instalar um sistema gerenciador de banco de
dados, foi decidido utilizar o HyperSQL, que é uma implementação de um
banco de dados feita em Java, ele suporta a maior parte do padrão SQL
(HSQL, 2011).
Outra vantagem do HyperSQL é que ele pode ser embutido na
aplicação. Deste modo, o banco de dados sobe automaticamente com a
aplicação, sem a necessidade de se instalar outro servidor externo.
5.4 Ambiente de Desenvolvimento
Para facilitar a programação do aplicativo será utilizado o IDE Eclipse,
pois já existe um plugin específico do GWT para este IDE.
5.5 Ferramenta para Geração de Gráficos
Para gerar os gráficos foi utilizada a ferramenta Google Chart Tools e
seu plugin Google API Libraries for Google Web Toolkit. Ambos desenvolvidos
pelo próprio Google fazem que seja extremamente fácil adicionar gráficos a um
projeto que utiliza o GWT.
31
6 MODELAGEM DO SOFTWARE
Ao iniciar a modelagem foram analisados todos os requisitos funcionais
e não funcionais do software de acordo com a proposta do trabalho. A partir
disso, foram criados os casos de uso, diagrama de classe e os diagramas de
sequência. Os diagramas foram criados na ferramenta Astah-UML. Através das
definições dos diagramas será possível ter uma visão geral da implementação
do software.
6.1 Requisitos Funcionais e Não Funcionais
Com o intuito de criar uma ferramenta consistente e funcional, foram
feitas as análises e as especificações das funcionalidades do dTaskboard,
onde, foram definidos os requisitos funcionais e não funcionais da ferramenta.
Requisitos Funcionais são declarações detalhadas das funções que o
sistema deve executar e como deve ser seu comportamento diante de entradas
e situações específicas (SOMMERVILLE, 2003)
A tabela 2 representa os requisitos funcionais, ou seja, representa as
atividades que poderão ser executadas no dTaskboard.
Tabela 2: Requisitos Funcionais
Fonte: Os Atores (2011)
32
Requisitos não Funcionais são as restrições sobre as funções que serão
oferecidas pelo sistema. Eles também podem ser a respeito de requisitos
relacionados ao processo utilizado para o desenvolvimento do software, como
especificações dos padrões de qualidade. Os Requisitos não Funcionais
surgem em razão do usuário, do orçamento disponível, das políticas
organizacionais ou até mesmo de necessidades externas, como necessidades
legais ou de segurança (SOMMERVILLE, 2003)
A tabela 3 representa os Requisitos não Funcionais do sistema.
Tabela 3: Requisitos Não Funcionais
Fonte: Os Atores (2011)
6.2 Casos de Uso
Para
ajudar
a
determinar
as
funcionalidades
que
devem
ser
implementadas no sistema, foram feitos os casos de uso indicando os
principais fluxos de trabalho dos usuários do sistema.
O sistema possuirá quatro tipos de atores, o administrador que poderá
criar projetos; os gerentes de projetos que poderão criar sprints, histórias e
também poderão dar permissão de acesso aos seus projetos a outros usuários.
Existem os usuários que têm permissão de utilizar pelo menos um dos projetos
e modificar as tarefas desse projeto, e temos ainda os visitantes, que podem
apenas ver os projetos.
A tabela 4 mostra uma listagem dos atores e dos requisitos que
compõem o sistema.
33
Tabela 4: Casos de Uso
Fonte: Os Autores (2011)
Na Figura 9 é possível visualizar a maneira que cada ator (Usuário, Gerente de
projeto e Administrador) interage com o sistema.
Figura 9: Casos de uso. Fonte: Os Autores (2011).
Para melhor visualização, a descrição dos casos de uso encontra-se no
APÊNDICE A.
34
6.3 Diagramas de Classes
Nos diagramas de classe é possível visualizar as diferentes classes que
compõem o sistema e a maneira de como elas se relacionam. As classes são
representadas com seus respectivos nomes e atributos.
A Figura 10 mostra o diagrama das classes que serão persistidas no
sistema e através da imagem é possível analisar a maneira que elas se
relacionam.
Figura 10: Diagrama de classes das entidades. Fonte: Os autores (2011).
A Figura 11 mostra as classes que tem acesso às informações contidas
no banco de dados. Essas classes compõem o modelo e nelas estão contidas
todas as lógicas de negócio da aplicação.
35
Figura 11: Diagrama de classes de controle. Fonte: Os autores (2011).
6.4 Diagramas de Sequência
Devido à complexidade de um determinado sistema com diferentes
métodos e classes é difícil determinar a sequência de eventos do sistema. A
criação do diagrama de sequência é feita para minimizar esta complexidade.
Os diagramas são feitos com base nos casos de usos e nos diagramas de
classe.
Os diagramas de sequência foram criados de acordo com o escopo do
trabalho. Para melhor visualização os diagramas encontram-se no APÊNDICE
B.
36
7 IMPLEMENTAÇÃO DO PROJETO
A implementação do projeto segue o padrão MVC. O projeto foi então
dividido entre três pacotes: dtaskboard.client representado a visualização da
aplicação, dtaskboard.server representando a de lógica de negócios e o pacote
dtaskboard.entities representando o modelo.
A seguir são descritas cada uma dessas partes da aplicação.
7.1 Modelo
O relacionamento entre as classes do modelo pode ser verificado na
Figura 12.
O pacote dtaskboard.entities possui todas as classes que são as
entidades do mundo real, o model, e que são persistidas no banco de dados.
As classes Project, Sprint, History e Task representam as respectivas
entidades de um taskboard. Tanto o Sprint quanto o Task possuem seus
estados, definidos respectivamente pelas enumerações SprintStatus e
TaskStatus. Estas enumerações se encontram em outro pacote para serem
utilizados também pela visualização.
As classes Project, Sprint e Task guardam dados de horas previstas e
cumpridas para o cálculo das métricas e confecção dos gráficos de burndown e
burnup.
Para realizar a autenticação, foram criadas as classes User, Role e a
enumeração RoleClass. Cada usuário possui um respectivo objeto da classe
User que possui os dados do login e senha do usuário. A enumeração
RoleClass possui os diferentes tipos de papéis que um usuário pode ter no
sistema: administrador, gerente de um projeto ou usuário de um projeto.
Finalizando as classes de autenticação, a classe Role faz o
relacionamento dos dados do usuário e quais papéis ele tem em cada projeto.
Conforme a Figura 12 abaixo.
37
Figura 12: Diagrama de classes – Modelo. Fonte: Os Autores (2011).
7.2 Visualização
O pacote dtaskboard.client possui todas as classes que fazem parte da
view, todas as telas, formulários e pontos de interação com o usuário ficam
nele. Este pacote possui diversos outros sub pacotes para melhor organizar o
projeto.
A
tela
de
autenticação
dtaskboar.client.login.LoginPage.
Esta
é
representada
página
mostra
o
pela
classe
formulário
de
autenticação, como na Figura 13.
Figura 13: Tela de login. Fonte: Os Autores (2011).
Depois de se autenticar, o usuário entra na tela que mostra a barra de
ferramentas desse usuário, e de administrador caso esse usuário seja um
38
administrador. Essa barra de ferramentas é representada pela classe
dtaskboard.client.toolbar.Toolbar. Esta tela pode ser vista na figura 14.
Na barra de ferramentas do usuário, ao se clicar em qualquer uma das
entradas, aparece um Menu onde o usuário pode realizar algumas funções.
Clicando em seu nome de usuário (admin no caso da figura 14) aparecem as
ações: “Trocar Senha” e “Sair do sistema”. Em projetos o usuário pode
selecionar o projeto que deseja ver.
Figura 14: Barra de ferramentas. Fonte: Os Autores (2011).
Em Administração pode-se criar um novo usuário, adicionar um papel a
um usuário e criar um novo projeto. O item administração só aparece para
administradores.
Estas ações, com a exceção de sair do sistema, abrem caixas de
diálogo modal onde o usuário deve preencher dados para executar a ação.
Esses diálogos são implementados pelas classes AddRoleToUserDialog,
ChangePasswordDialog, CreateProjectDialog e CreateUserDialog, que estão
no mesmo pacote da classe Toolbar.
Quando um usuário seleciona o projeto que deseja ver, abre-se a barra
de ferramentas do projeto logo abaixo da barra de ferramentas do usuário e
também o taskboard com o sprint atual do projeto, como na figura 15.
Figura 15: Tela do projeto. Fonte: Os Autores (2011).
39
Na barra de ferramentas do projeto, se o usuário for um gerente do
projeto ele pode editar o projeto, criar um novo sprint e encerrar o sprint atual.
Estas ações também abrem diálogos e são implementadas pelas respectivas
classes de diálogo. As classes que geram a barra de ferramentas do projeto e
a tabela do projeto encontram-se no pacote dtaskboard.client.project. As
classes dos diálogos estão no pacote dtaskboard.client.project.dialog.
No taskboard o usuário pode criar tarefas e histórias, se for o gerente, e
pode mover as tarefas entre as colunas.
Todos os diálogos são subclasses de Dialog, a classe de diálogos
fornecida pelo GWT, como pode ser visto na figura 16. A classe Toolbar e
ProjectToolbar são subclasses de MenuBar, que é a classe fornecida pelo
GWT para fornecer barras de menu. Além dessas classes existem também a
LoginPage e a ProjectPage que podem ser vistas na figura 17.
Figura 16: Diagrama de classes dos diálogos. Fonte: Os Autores (2011).
Figura 17: Diagrama de classes interface com o usuário. Fonte: Os Autores (2011).
A figura 18 mostra as classes que foram implementadas para mostrar os
gráficos no sistema. Elas implementam um método e devolvem um
componente que pode ser adicionado diretamente na tela e renderiza um
gráfico. Para isso estas classes utilizam a biblioteca Google Chart Tools.
40
Figura 18: Diagrama de classes criadoras de gráficos. Fonte: Os Autores (2011).
7.3 Controlador
Por último o pacote dtaskboard.server possui todas as lógicas de
negócio e manipulação das entidades, o controlador. Quando o usuário
executa uma ação na view, ela é enviada para o controlador e então
processada.
Para tratar a persistência e recuperação dos dados foi utilizado o padrão
DAO (Data Access Object), onde uma classe é responsável por fazer a
persistência dos dados sem expor as especificidades do banco de dados.
Os DAOs estão no pacote dtaskboard.server.dao e há uma classe
GenericDao que implementa os métodos de criação, remoção, recuperação e
listagem de entidades. Existem subclasses de GenericDao para cada entidade
e cada subclasse precisa apenas implementar os métodos que são
necessários para essa entidade. O diagrama de classes do pacote
dtaskboard.server.dao pode ser visto na figura 19.
Figura 19: Diagrama de classes – DAO. Fonte: Os Autores (2011).
41
A figura 20 mostra as classes com as lógicas de negócio. O
ProjectServiceImpl possui todas as lógicas que tratam do projeto, criar e
atualizar projetos, sprints e tarefas além de tratar das mudanças de estados
das tarefas.
O LoginServiceImpl trata das funções administrativas de criar usuários e
papéis para eles, e também da autenticação.
Figura 20: Diagrama de classes controlador. Fonte: Os Autores (2011).
42
8 TESTES
O sistema foi implantado em um projeto da Touch Tecnologia. Este
projeto conta com 12 desenvolvedores divididos em 3 grupos. Apesar de não
haver tempo suficiente para uma coleta profunda de dados o projeto teve
grande aceitação inicial.
Ele ajudou consideravelmente na comunicação entre membros de
projeto. O projeto possui um taskboard físico, um dos grupos encontra-se em
andar diferente do prédio. Com o novo sistema todos compartilham o mesmo
taskboard. O fato de criar os gráficos dinamicamente também foi apreciado.
A figura 21 mostra a situação do projeto durante um sprint. Os nomes
das histórias, das tarefas e do próprio projeto foram modificados para manter a
confidencialidade das informações.
Figura 21: Utilização do sistema. Fonte: Os Autores (2011).
43
9 CONCLUSÃO
Analisando o cenário de desenvolvimento de software o fator mais
importante é cumprir o prazo estabelecido de entrega e a maior dificuldade
encontrada pelas equipes de desenvolvimento é criar um software funcional no
período especificado. Ao assumir o comprometimento de entrega em um
período específico, a maioria das empresas adotam uma metodologia ágil. De
acordo com a proposta do trabalho, utilizamos a metodologia Scrum.
Buscou-se neste trabalho, disponibilizar uma ferramenta no idioma
português e de código aberto para auxiliar a equipe Scrum no processo de
desenvolvimento de software, desde a fase inicial até a fase de conclusão. De
acordo com o objetivo proposto no trabalho essa ferramenta automatiza o
processo de geração de gráficos e as retiradas de estatísticas para o
acompanhamento do desenvolvimento do software. O código fonte está
disponível em: http://code.google.com/p/dtaskboard/source/checkout.
Portanto, adequando o software ao método Scrum os resultados foram
obtidos com sucesso. É possível gerar os gráficos e as estatísticas necessárias
da fase de desenvolvimento dos Sprints que são elas: a fazer, em processo,
verificando e feito.
9.1 Trabalhos Futuros
Ao desenvolver a ferramenta dTaskboard, foram identificados recursos
que poderiam ser incluídos como melhorias na ferramenta desenvolvida, mas
estes recursos identificados estão além do escopo do projeto. Portanto, serão
descritos a seguir como propostas de trabalhos futuros e tem como objetivo
tornar o dTaskboard mais simples e dinâmico.
Para tornar o software mais útil e manter o foco no que é importante a
ferramenta deve:
Gerar outros relatórios em tempo real dos sprints e do projeto
como um todo, para que assim o Scrum Master e os integrantes
da equipe tenham uma visão aprofundada do desenvolvimento e
do projeto em geral.
44
Após concluir a reunião diária os sprints definidos devem ser
enviados automaticamente por email para seus respectivos
desenvolvedores, com isso a equipe teria um ganho significativo,
pois, durante as reuniões os desenvolvedores não perderiam
tempo anotando informações, é muito útil também se caso algum
integrante da equipe não estivesse presente.
Fazer teste de usabilidade com todos os níveis usuários e fazer
os devidos ajustes de acordo com o feedback.
45
REFERÊNCIAS
ABRAHAMSSON, Pekka et al. Agile software development methods: review
and analysis. Finland: VTT Publications, 2002.
BAUER, Christian; King, Gavin. Hibernate in action. Greenwich: Manning,
2005.
BECK, Kent et al. Manifesto for agile software development. 2001. Disponível
em: <http://agilemanifesto.org>. Acesso em: 24 abr. 2011.
BROWN, Donald; DAVIS, Chad Michael; STANLICK, Scott. Struts2 in action.
Greenwich: Manning, 2008.
CABRI, Anthony; GRIFFITHS, Mike. Earned value and agile reporting.
In: AGILE 2006, 2006, Minneapolis, Minnesota.
COCKBURN, Alistair. Crystal clear: a human-powered methodology for small
teams. Indianapolis, Indiana: Addison-Wesley Professional, 2004.
GREENHOPPER, Atlassian. 1 de junho de 2011. Disponível
em: <http://www.atlassian.com/software/greenhopper>. Acesso em 31 de maio
de 2011.
HIGHSMITH, Jim, Agile Project Management: Principles and Tools. Cutter
Consortium Executive Report, 2002.
HIGHSMITH, Jim. History: the agile manifesto. 2001. Disponível em:
<http://agilemanifesto.org/history.html>. Acesso em: 24 abr. 2011.
HOGAN, Brian P. HTML5 & CSS3. Develop with Tomorrow's Standards Today.
The Pragmatic Programmers, 2010.
LARMAN, C., Agile and Iterative Development: A Manager's Guide. Addison
Wesley, 2003.
LOVATTO, Cheferson Washington. Comparando ambientes de
desenvolvimento Java e Ruby on Rails. Porto Alegre: UFRGS, 2007.
MAGELA, R. Engenharia de Software Aplicada: Fundamentos. Rio de Janeiro:
Alta Books, 2006.
MIRANDA, Eduardo; BOURQUE, Pierre. Agile monitoring using the line of
balance. The journal of systems and software, Amsterdam, v. 83, p. 12051215, 2010.
OLSON, Steven Douglas. Ajax on Java. Califórnia: O’Reilly, 2007.
46
PERRY, Bruce. Google web toolkit for Ajax. Califórnia: O’Reilly, 2006.
PILGRIM, Mark. HTML5 up and running. California: O'Reilly, 2010
REENSKAUG, T. The Model-View-Controller(MVC): Postado em 20 de Agosto
de 2003. Disponível em: <http://heim.ifi.uio.no/~trygver/2003/javazonejaoo/MVC_pattern.pdf>. Acesso em 15/10/2011
REINERTSEN, Donald G., Managing the Design Factory - A Product
Developer's Toolkit, Free Press, New York NY, 1997
RUBY, Sam; THOMAS, Dave; HANSSON, David Heinemeier. Agile web
development with Rails. Texas: The Pragmatic Bookshelf, 2011.
SCHWABER, Ken. Agile project management with scrum. Redmond:
Microsoft Press, 2004.
SCHWABER, Ken; BEEDLE, Mike. Agile software development with scrum.
New Jersey: Prentice-Hall Inc., 2001.
SCHWALBE, Kathy., Information Technology Project Management.
Cambridge, MA, USA, 2002.
SCHWABER, Ken; SCRUM Development Process. Burlington. MA, USA,
1996
SCRUMNINJA, ScrumNinja Software. 25 de abril de 2011. Disponível em:
<http://www.scrumninja.com/scrum-software>. Acesso em 28 de maio de 2011.
SOMMERVILLE, Ian. Engenharia de Software. 6° ed. Tradução Maurício de
Andrade. São Paulo: Ed. Pearson Addison Wesley,2003. p.79 - 123.
SUTHERLAND, Jeff; SCHWABER, Ken. The scrum papers: nuts, bolts, and
origins of an agile process. s.l, 2011. Disponível em:
<http://jeffsutherland.com/ScrumPapers.pdf>. Acesso em: 28 ago. 2011.
VIP QUALITY SOFTWARE, Vip Task Manager. 4 de Outubro de 2010.
Disponível em: <http://www.vip-qualitysoft.com/products/task-manager>.
Acessado em 4 de jun. de 2011.
WELLING, Luke; THOMSON, Laura. PHP and MySQL Web Development.
Indiana: Sams, 2008.
SCRUMNINJA SCREENSHOT, ScrumNinja Software. 25 de abril de 2011.
Disponível em: <http://www.scrumninja.com/projects/9998/stories>. Acesso em:
13 de dezembro de 2011.
47
GREENHOPPER SCREENSHOT, Atlassian. 1 de junho de 2011. Disponível
em: <http://www.atlassian.com/software/greenhopper/overview/tour/screenshottour>. Acesso em: 13 de dezembro de 2011.
VIP TASK MANAGER SCREENSHOT, Vip Task Manager. 4 de Outubro de
2010.
Disponível
em:
<http://www.taskmanagementsoft.com/upload/iblock/ec6/ec6bb078e4ea2351a6
e94e487680aa8b.png>. Acesso em: 13 de dezembro de 2011.
48
APÊNDICE A – CASOS DE USO
Caso de Uso: UC 01 - Entrar no sistema
Descrição Resumida: O usuário deseja se autenticar no sistema.
Ator Primário: Usuário (qualquer nível)
Pré-Condições: O usuário não deve estar autenticado no sistema.
Fluxo Principal:
1. O usuário entra na página do sistema.
2. O sistema mostra a página de entrada.
3. O usuário fornece seu nome de usuário, sua senha e clica no botão
“Entrar”.
4. O sistema valida o par.
5. O usuário está autenticado no sistema e o caso de uso se encerra.
Fluxos de Exceção:
4a. O usuário forneceu o par nome de usuário e senha errados.
4a1. O sistema mostra mensagem indicando que o par nome de usuário
e senha estavam incorretos e retorna-se ao passo 2 do fluxo principal.
49
Caso de Uso: UC 02 - Gerenciar usuários
Descrição Resumida: Deseja-se adicionar ou remover um usuário do sistema.
Ator Primário: Administrador
Pré-Condições: O administrador deve estar autenticado no sistema e na
página de administração.
Fluxo Principal:
1. O administrador clica no botão “Adicionar usuário”.
2. O sistema mostra a tela de adicionar usuário.
3. O administrador preenche o nome do usuário e a senha inicial e clica
no botão “Adicionar”.
4. O sistema cadastra o novo usuário, mostra uma mensagem de
confirmação e o caso de uso se encerra.
Fluxos Alternativos:
1a. O administrador clica no botão “Remover usuário” referente ao
usuário que deseja-se remover.
1a1. O sistema mostra uma tela pedindo a confirmação da ação.
1a2. O administrador clica em “Confirmar”.
1a3. O sistema remove o usuário e encerra-se o caso de uso.
Fluxos de Exceção:
4a. O nome de usuário já está cadastrado no sistema.
4a1. O sistema exibe uma mensagem de erro e retorna-se ao passo 2
do fluxo principal.
50
Caso de Uso: UC 03 - Criar Projeto
Descrição Resumida: Deseja-se criar um novo projeto.
Ator Primário: Administrador
Pré-Condições: O administrador deve estar autenticado no sistema e na
página de administração.
Fluxo Principal:
1. O administrador clica no botão “Criar projeto”.
2. O sistema mostra a tela de criação de projeto.
3. O administrador preenche o nome do projeto, seleciona um gerente
para esse projeto e clica no botão “Criar”.
4. O sistema verifica se o nome do projeto é válido, cria o projeto, e
adiciona o gerente a ele e encerra-se o caso de uso.
Fluxos de Exceção:
4a. O nome do projeto já existe.
4a1. O sistema mostra uma mensagem de erro e retorna-se ao passo 2
do fluxo principal.
51
Caso de Uso: UC 04 - Criar sprint
Descrição Resumida: Deseja-se criar um novo sprint para um projeto.
Ator Primário: Gerente do projeto
Pré-Condições: O gerente do projeto deve estar autenticado no sistema e
deve estar na página do projeto.
Fluxo Principal:
1. O gerente cria no botão “Criar sprint”.
2. O sistema mostra a tela de criação de sprint.
3. O gerente preenche a data inicial, a data de término, a quantidade de
trabalho planejada para este sprint e preenche o campo de atualização de
tempo total estimado do projeto se necessário e clica no botão “Criar”.
4. O sistema verifica se as datas do sprint não batem com datas de
outros sprints neste mesmo projeto, cria o sprint e mostra uma mensagem para
o gerente e encerra-se o caso de uso.
Fluxos de Exceção:
4a. Há intersecção entre as datas deste sprint e as datas de outro sprint.
4a1. O sistema exibe uma mensagem de erro e retorna-se ao passo 2
do fluxo principal.
52
Caso de Uso: UC 05 - Criar história
Descrição Resumida: Deseja-se criar uma história em um sprint.
Ator Primário: Gerente do projeto
Pré-Condições: O gerente do projeto deve estar autenticado no sistema e
deve estar na página do respectivo sprint.
Fluxo Principal:
1. O gerente clica no botão “Criar história”.
2. O sistema mostra a tela de criação de história.
3. O gerente preenche a sigla da história, respectiva descrição e clica no
botão “Criar”.
4. O sistema verifica se a sigla da história já foi utilizada neste sprint, cria
a história, mostra uma mensagem de sucesso e encerra-se o caso de uso.
Fluxos de Exceção:
4a. A sigla da história já foi utilizada neste sprint.
4a1. O sistema mostra uma mensagem de erro e retorna-se para o
passo 2 do fluxo principal.
53
Caso de Uso: UC 06 - Criar tarefa
Descrição Resumida: Deseja-se criar uma nova tarefa para uma história.
Ator Primário: Gerente do projeto
Pré-Condições: O gerente do projeto deve estar autenticado no sistema e
deve estar na página do respectivo sprint.
Fluxo Principal:
1. O gerente clica no botão “Criar tarefa” da respectiva história.
2. O sistema mostra a tela de criação de tarefa.
3. O gerente informa a descrição e o trabalho estimado da tarefa e clica
no botão “Criar”.
4. O sistema cria a tarefa, mostra uma mensagem de sucesso e encerrase o caso de uso.
54
Caso de Uso: UC 07 - Modificar estado de tarefa
Descrição Resumida: Deseja-se mudar o estado de uma tarefa.
Ator Primário: Um usuário que tenha acesso ao projeto
Pré-Condições: O usuário deve estar autenticado no sistema e deve estar na
página do respectivo sprint.
Fluxo Principal:
1. O usuário clica no botão para avançar ou retroceder o estado da caixa
da tarefa.
2. O sistema salva a mudança e encerra-se o caso de uso.
55
Caso de Uso: UC 08 - Gerenciar usuários do projeto
Descrição Resumida: Deseja-se adicionar ou remover um usuário do projeto
Ator Primário: Gerente do projeto
Pré-Condições: O gerente do projeto deve estar autenticado no sistema e
deve estar na página do respectivo projeto.
Fluxo Principal:
1. O gerente clica no botão “Adicionar usuário”.
2. O sistema mostra a tela para adicionar um usuário ao projeto.
3. O gerente informa o usuário.
4. O sistema salva a informação, mostra uma mensagem de sucesso e
encerra-se o caso de uso.
Fluxos Alternativos:
1a. O gerente do projeto clica no botão “Remover usuário” referente ao
usuário que deseja-se remover.
1a1. O sistema mostra uma tela pedindo a confirmação da ação.
1a2. O administrador clica em “Confirmar”.
1a3. O sistema remove o usuário do projeto e encerra-se o caso de uso.
Fluxo de Exceção:
4a. O usuário informado já possui acesso ao projeto.
4a1. O sistema mostra uma mensagem de aviso e retorna-se ao passo 2
do fluxo principal.
56
Caso de Uso: UC 09 - Encerrar projeto
Descrição Resumida: Deseja-se encerrar o projeto.
Ator Primário: Gerente do projeto
Pré-Condições: O gerente do projeto deve estar autenticado no sistema e na
tela do projeto.
Fluxo Principal:
1. O gerente clica no botão “Encerrar projeto”.
2. O sistema exibe uma mensagem pedindo a confirmação da ação.
3. O gerente clica em “Confirmar”.
4. O sistema encerra o projeto e encerra-se o caso de uso.
57
Caso de Uso: UC 10 - Alterar gerente do projeto
Descrição Resumida: Caso algum gerente não possa gerenciar um projeto,
deve ser possível trocar o gerente do projeto.
Ator Primário: Administrador
Pré-Condições: O gerente do projeto deve estar autenticado no sistema e na
tela do projeto.
Fluxo Principal:
1. O administrador clica no botão “Alterar gerente” do respectivo projeto.
2. O sistema mostra uma caixa de diálogo com a listagem de usuários.
3. O administrador seleciona o usuário desejado e clica em “Selecionar”.
4. O sistema atualiza a configuração do projeto e encerra-se o caso de
uso.
58
Caso de Uso: UC 11 - Alterar senha
Descrição Resumida: Deseja-se alterar a senha do usuário.
Ator Primário: Usuário (qualquer nível)
Pré-Condições: O usuário deve estar autenticado no sistema.
Fluxo Principal:
1. O usuário clica em “Alterar senha”.
2. O sistema mostra o diálogo de alterar senha.
3. O usuário informa sua senha atual, nova senha, confirmação da nova
senha e clica em “Alterar senha”.
4. O sistema verifica a senha atual do usuário, verifica a nova senha e a
confirmação, atualiza a senha do usuário e encerra-se o caso de uso.
Fluxo de Exceção:
4a. O usuário forneceu a senha atual errada.
4a1. O sistema mostra uma mensagem informando que a senha atual
está incorreta e retorna-se para o passo 2 do fluxo principal.
4b. O usuário forneceu a confirmação da nova senha diferente da nova
senha.
4b1. O sistema mostra uma mensagem informando que a confirmação
da nova senha é diferente da nova senha e retorna-se para o passo 2 do fluxo
principal.
59
Caso de Uso: UC 12 - Gerar estatísticas
Descrição Resumida: Deseja-se gerar alguma estatística do projeto.
Ator Primário: Gerente do projeto
Pré-Condições: O gerente do projeto deve estar autenticado no sistema e na
tela do projeto.
Fluxo Principal:
1. O gerente do projeto clica em “Estatísticas”, em seguida clica na
estatística que deseja gerar.
2. O sistema gera as estatísticas, mostra na tela e encerra-se o caso de
uso.
60
APÊNDICE B – DIAGRAMAS DE SEQUÊNCIA
A seguir os diagramas de sequência, onde, são mostradas as classes e
suas respectivas ações.
61
62
63
64
ANEXO A - MANIFESTO ÁGIL
Estamos descobrindo novas maneiras de desenvolver software por fazêlo e ajudar outros a fazê-lo. Por este trabalho começamos a valorizar:
Indivíduos e interações sobre processos e ferramentas
Software funcionando sobre documentação abrangente
Colaboração com o cliente sobre negociação de contrato
Responder a mudança sobre seguir um plano
Isto é, enquanto há valor nos itens da direita, valorizamos mais os itens
da esquerda.
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas