ambiente web para gerenciamento de...
TRANSCRIPT
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE CIÊNCIAS DA COMPUTAÇÃO – BACHARELADO
AMBIENTE WEB PARA GERENCIAMENTO DE PROCESSO
DE SOFTWARE BASEADO NO SCRUM
JHONY ALCEU PEREIRA
BLUMENAU 2005
2005/1-28
JHONY ALCEU PEREIRA
AMBIENTE WEB PARA GERENCIAMENTO DE PROCESSO
DE SOFTWARE BASEADO NO SCRUM
Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Ciências da Computação — Bacharelado.
Prof. Everaldo Artur Grahl - Orientador
BLUMENAU 2005
2005/1-28
AMBIENTE WEB PARA GERENCIAMENTO DE PROCESSO
DE SOFTWARE BASEADO NO SCRUM
Por
JHONY ALCEU PEREIRA
Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por:
______________________________________________________ Presidente: Prof. Everaldo Artur Grahl, Mestre – Orientador, FURB
______________________________________________________ Membro: Prof. Fabiane Barreto Vavassori Benitti, Doutora – FURB
______________________________________________________ Membro: Prof. Marcel Hugo, Mestre – FURB
Blumenau, 19 de julho de 2005
Dedico este trabalho a todos que de certa forma ajudaram para a realização do mesmo, principalmente aos meus pais, Alceu e Rosi, que sempre me deram todo carinho e apoio ao qual necessitei.
AGRADECIMENTOS
À Deus, por estar sempre do meu lado me guiando pelo caminho certo.
À minha família, que mesmo longe, sempre esteve presente e me deram muita força
para continuar lutando.
Aos amigos pelo apoio e gentilezas prestadas nas horas de necessidade.
Ao meu orientador por ter acreditado na conclusão deste trabalho e auxiliado para que
isto aconteça.
“Quem disser que estamos fora, não nos conhece.”
Michael Schumacher
RESUMO
A indústria do software é, em sua maioria, formada por pequenas empresas de software, onde essas empresas, por começarem com uma ou duas pessoas acabam por não adotar um processo de software adequado, tornando custosa a adoção de uma metodologia tradicional de gerência de processo. As metodologias ágeis surgiram para suprir as necessidades dessas empresas, onde priorizam as pessoas e os prazos e onde a reescrita do código é uma tarefa simples e rotineira. A metodologia Scrum se destaca das outras metodologias ágeis por seu enfoque no planejamento e visão geral do processo de software. Este trabalho mostra a adaptação de uma ferramenta web de gerenciamento de projeto conhecida como dotProject para atender os artefatos baseados na metodologia Scrum. Para o realização deste ambiente foram utilizados Personal Home Page (PHP) e MySQL. O ambiente desenvolvido apóia as técnicas adotadas pela metodologia ágil Scrum facilitando no manejo de seus artefatos.
Palavras-chave: Scrum. Metodologia ágil. Processo de software.
ABSTRACT
The software industry is, in his majority, formed by small software companies, where those companies, by will begin with one or two peoples end up do not adopt an adequate software process, turning costly the adoption of a process traditional management methodology. The agile methodologies arose for supply the needs of those companies, where prefer the persons and the terms and where it rewritten of the code is a routine and simple task. To Scrum methodology is detached of the other agile methodologies by his approach in the planning and general vision of software process. This work shows a web project management tool adaptation of known as dotProject for attend the devices based in the Scrum methodology. For the environment realization are utilized Personal Home Page (PHP) and MySQL. The developed environment support the techniques adopted by the Scrum methodology facilitating in the management yours devices.
Key-Words: Scrum. Agile methodology. Software process.
LISTA DE ILUSTRAÇÕES
Figura 1 - Modelo de processo baseado em Scrum..................................................................19
Figura 2 - Gráfico de Burn-Down.............................................................................................25
Figura 3 - Tela de seleção de módulos do dotProject...............................................................26
Figura 4 - Framework do dotProject ........................................................................................29
Figura 5 - Representação dos diretórios include e classes com seus arquivos.........................30
Figura 6 - Representação da estrutura de um módulo do dotProject........................................31
Figura 7 - Diagrama de casos de uso do Scrum .......................................................................38
Figura 8 - Diagrama de casos de uso do módulo Product Backlog..........................................39
Figura 9 - Diagrama de casos de uso do módulo Sprint Backlog.............................................40
Figura 10 - Diagrama de casos de uso do módulo Daily Scrum..............................................41
Figura 11 - Diagrama de classe do ambiente dotProject adaptado para Scrum .......................43
Figura 12 - DER lógico do ambiente dotProject adaptado para Scrum....................................44
Figura 13 - Acesso ao sistema ..................................................................................................49
Figura 14 - Página principal do usuário Product Owner..........................................................50
Figura 15 - Página de listagem de empresas.............................................................................51
Figura 16 - Página de formulário para cadastro de empresas...................................................51
Figura 17 - Página de visualização dos dados da empresa.......................................................52
Figura 18 - Página de listagem de projetos...............................................................................52
Figura 19 - Página de formulário para inclusão de projetos.....................................................53
Figura 20 - Página para visualização do projeto ......................................................................53
Figura 21 - Pagina de Product Backlog....................................................................................54
Figura 22 - Página de Product Backlog com projeto selecionado............................................54
Figura 23 - Página de formulário de item do Product Backlog................................................55
Figura 24 - Página de visualização do Product Backlog..........................................................55
Figura 25 - Página de Sprint Backlog.......................................................................................56
Figura 26 - Página de formulário de Sprint Backlog................................................................57
Figura 27 - Página de visualização de Sprint Backlog .............................................................57
Figura 28 - Página inicial do módulo de Daily Scrum.............................................................58
Figura 29 - Página de formulário de registro das Daily Scrum................................................58
Figura 30 - Página de avaliação do Product Backlog...............................................................59
Figura 31 - Página de avaliação do Sprint Backlog..................................................................60
Figura 32 - Página de administração do ambiente....................................................................61
Figura 33 - Página de administração de usuários .....................................................................61
LISTA DE QUADROS
Quadro 1 - Variáveis globais/comumente usadas no dotProject ..............................................32
Quadro 2 - Definições das funções e métodos globais do dotProject ......................................33
Quadro 3 - Métodos da classe CDpObject ...............................................................................34
Quadro 4 - Script para instalação do módulo no framework do dotProject .............................46
Quadro 5 - Script de especificação da classe CSprintBacklog.................................................47
Quadro 6 - Estudo de caso "Controle de Pesca".......................................................................49
LISTA DE SIGLAS
AM – Agile Modeling
ASD – Adaptative Software Development
CSS – Cascading Style Sheets
DER – Diagrama de Entidades e Relacionamentos
DOM – Document Object Model
DSDM – Dynamic Systems Development Method
FURB – Fundação Universidade Regional de Blumenau
HTML – HyperText Markup Language
IDE – Integrated Development Environment
JUDE – Java/UML Object-Oriented Design Tool
PEAR – PHP Extension and Application Repository
PERT – Program Evaluation and Review Technique
PHP – Personal Home Page
SGBD – Sistema Gerenciador de Banco de Dados
SQL – Structured Query Language
TI – Tecnologia da Informação
UML – Unified Modeling Language
XHTML – eXtensible HyperText Markup Language
XP – eXtreme Programming
SUMÁRIO
1 INTRODUÇÃO..................................................................................................................14
1.1 OBJETIVOS DO TRABALHO ........................................................................................15
1.2 ESTRUTURA DO TRABALHO......................................................................................15
2 PROCESSO DE SOFTWARE .........................................................................................17
2.1 METODOLOGIA ÁGIL...................................................................................................17
2.2 SCRUM.............................................................................................................................19
2.2.1 PAPÉIS DO SCRUM......................................................................................................20
2.2.2 ATIVIDADES DO SCRUM...........................................................................................20
2.2.3 ARTEFATOS DO SCRUM............................................................................................21
2.2.3.1 Product Backlog............................................................................................................22
2.2.3.2 Sprint Backlog ..............................................................................................................23
2.2.3.3 Daily Scrum..................................................................................................................24
2.2.3.4 Release Backlog............................................................................................................24
2.2.4 Avaliações do Scrum.......................................................................................................25
2.3 DOTPROJECT..................................................................................................................26
2.3.1 A Arquitetura do dotProject ............................................................................................26
2.3.2 Framework do dotProject................................................................................................28
2.3.2.1 Arquivos e diretórios ....................................................................................................29
2.3.2.2 Variáveis globais/comumente usadas ...........................................................................31
2.3.2.3 Funções e métodos globais sem classe específica ........................................................32
2.3.2.4 A Classe CDpObject.....................................................................................................33
2.4 TRABALHOS CORRELATOS........................................................................................34
3 DESENVOLVIMENTO DO TRABALHO.....................................................................36
3.1 REQUISITOS PRINCIPAIS DO PROBLEMA ...............................................................36
3.2 ESPECIFICAÇÃO ............................................................................................................37
3.2.1 Módulo Product Backlog................................................................................................38
3.2.2 Módulo Sprint Backlog...................................................................................................40
3.2.3 Módulo Daily Scrum.......................................................................................................41
3.3 IMPLEMENTAÇÃO ........................................................................................................45
3.3.1 Técnicas e ferramentas utilizadas....................................................................................46
3.3.2 Operacionalidade da implementação ..............................................................................48
3.3.2.1 Usuário Product Owner ................................................................................................49
3.3.2.2 Usuário Scrum Team ....................................................................................................55
3.3.2.3 Usuário Scrum Master ..................................................................................................58
3.3.2.4 Outros Usuários ............................................................................................................60
3.4 RESULTADOS E DISCUSSÃO ......................................................................................61
4 CONCLUSÕES..................................................................................................................63
4.1 EXTENSÕES ....................................................................................................................63
REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................65
APÊNDICE A – Dicionário de dados das principais entidades utilizadas pelo ambiente ...
..................................................................................................................................67
14
1 INTRODUÇÃO
O uso de um processo de desenvolvimento de software melhora a qualidade desse
software significativamente (SOARES, 2004). Com ele é possível medir desempenho, fazer
estimativas e organizar o caos que é o desenvolvimento de software em muitas empresas. O
fato complica-se quando os modelos tradicionais não são aplicáveis a pequenas empresas que
na sua maioria priorizam o prazo como fator de maior importância, além de sofrerem com a
falta de recursos. Para as empresas que trabalham neste contexto, o ideal é um modelo de
processo que seja ágil, sem muita burocracia e que seja voltada a todas as pessoas envolvidas
nesse processo.
Um desses modelos de processo ágil é conhecido como Scrum. De acordo com
Schwaber e Beedle (2002, p. 1), o Scrum é um processo interativo incremental de
desenvolvimento de software, e um modelo empírico de desenvolvimento de software. Utiliza
técnicas simples unidas ao senso comum e a uma base de experiências passadas, já testadas e
aprovadas. O uso do Scrum vai ao encontro com a necessidade das pequenas empresas de
software pelo fato de ser simples, ágil e sem muita burocracia.
O uso de uma metodologia deve ser facilitado através de uma ferramenta que dê o
apoio necessário nas atividades envolvidas por este processo. Esta necessidade vem ao
encontro de uma lista de atividades e documentos que devem ser gerados no decorrer do
processo e mantidos para uma posterior avaliação, seja de processo ou do software em
questão.
Uma ferramenta disponível para este fim, desenvolvida sob a filosofia OpenSource é o
dotProject. Esta ferramenta contém uma estrutura básica para gerência de processos de
software, porém não se preocupa com a metodologia aplicada. As funcionalidades do
dotProject são desenvolvidas através de módulos para o mesmo, onde esses módulos seguem
15
padrões de desenvolvimento ditados pela própria ferramenta, ou seja, um framework já
definido pelo próprio ambiente. Dentre os módulos que já acompanham o dotProject,
encontram-se módulos para gerência de clientes/empresas, contatos, projetos, tarefas, fórum,
calendário, arquivos, atendimento ao cliente (helpdesk), suporte a várias línguas e controle de
permissão de usuários por módulo (DOTPROJECT..., 2005).
1.1 OBJETIVOS DO TRABALHO
O objetivo deste trabalho é desenvolver um ambiente web para gerenciamento de
processo de software baseado na metodologia ágil conhecida como Scrum.
Os objetivos específicos do trabalho são:
a) estender e adaptar o ambiente dotProject para se adequar a metodologia ágil
Scrum;
b) aprofundar os conhecimentos na metodologia Scrum e difundir como alternativa
de processo para as pequenas organizações de software.
1.2 ESTRUTURA DO TRABALHO
O trabalho está dividido em quatro capítulos distintos, cuja a descrição de cada um
deles segue.
O primeiro capítulo apresenta uma introdução ao tema do trabalho, apresentando os
objetivos e a estrutura do trabalho.
O segundo capítulo apresenta uma fundamentação teórica descrevendo os temas
centrais do trabalho: Processo de Software, Metodologias Ágeis, Scrum e dotProject.
O terceiro capítulo trata da especificação e implementação do ambiente resultado do
16
trabalho. Este é demonstrado através de seus requisitos, diagramas de casos de uso, descrição
dos casos de uso, arquitetura do software, diagramas de entidade relacionamento (DER) e
dicionário de dados. Neste capítulo ainda são demonstradas algumas telas do ambiente com
suas devidas considerações.
Por fim, na conclusão deste trabalho, são descritas as considerações finais, tais como
dificuldades enfrentadas, os resultados alcançados, limitações do ambiente e sugestões para
novas implementações.
17
2 PROCESSO DE SOFTWARE
De acordo com Reis (2003, p. 5), “Processo de Software é um conjunto de atividades
realizadas para construir software, levando em consideração os produtos sendo construídos, as
pessoas envolvidas, e as ferramentas com as quais trabalham.” Desta forma pode-se
considerar Processo de Software todas as atividades, pessoas e ferramentas utilizadas para se
construir um Software.
2.1 METODOLOGIA ÁGIL
As metodologias ágeis foram concretizadas através de um manifesto realizado por
dezessete representantes das diversas metodologias ágeis, entre eles Ken Schwaber, Mike
Beedle, Martin Fowler, Kent Beck e Alistair Cockburn, que em uma reunião realizada em
fevereiro de 2001 procuravam, além de outras coisas, algo em comum. Desta reunião
originou-se o Manifesto for Agile Software Development (AGILE ALIANCE, 2005). Neste
manifesto foram decididos os valores e os princípios que as metodologias ágeis devem ter,
para assim serem classificadas. Tais valores são:
a) indivíduos e interações em vez de processos e ferramentas;
b) software funcional em vez de extensa documentação;
c) colaboração com o cliente em vez de renegociação de contrato;
d) aceitação das mudanças em vez de obediência cega a um plano.
De acordo com Santos, Martins e Leal (2003) as duas principais motivações para a
criação das metodologias ágeis, sendo a primeira o foco no objetivo primário de um projeto
de software que é o próprio software e não grande conjunto de documentação sobre ele, e a
segunda que um artefato é criado primordialmente para permitir a troca de informações e a
18
comunicação entre a equipe para assim permitir as discussões e aprimoramentos no modelo
do software.
Conforme Soares (2004, p. 1) processos tradicionais (orientados a planejamento,
documentação) são pesados e inadequados para pequenas organizações, que em sua maioria
acabam por não utilizar nenhum processo. Isto é ruim, visto que ao final, torna-se desastroso
para a qualidade final do produto apresentado. Por esta razão as chamadas metodologias ágeis
despertam cada vez mais as atenções da comunidade científica, e principalmente dessas
pequenas organizações. Os projetos realizados por essas organizações normalmente tem muita
mudança, os requisitos são passíveis de alterações, o custo do código a ser reescrito não é
elevado, as equipes são pequenas, são curtas as datas de entrega dos resultados, necessitando
de um desenvolvimento ágil, necessitando assim de uma metodologia ágil que se adapte a este
ambiente dinâmico das pequenas organizações.
Dentre os princípios das metodologias ágeis, tem-se bastante destaque para a
simplicidade e a velocidade com que os resultados são apresentados. Diferentes das
metodologias tradicionais, que tem seus requisitos inteiramente descritos e congelados, as
metodologias ágeis respondem melhor as mudanças no decorrer do processo, e esta talvez seja
a característica que mais chama a atenção das empresas que buscam soluções rápidas, e que
nem sempre tem seus requisitos fixos (ABRAHAMSSON et al., 2004).
O mercado de metodologias ágeis cresceu muito nos últimos anos, apresentando
diversas soluções para problemas distintos, mas na sua maioria, essas metodologias não
passaram de meras propostas. Porém, outras metodologias no mesmo contexto, estão se
fixando e chamando a atenção tanto da comunidade acadêmica, quanto das empresas de
software. Dentre as metodologias ágeis conhecidas pode-se citar o eXtreming Programming
(XP), Adaptative Software Development (ASD), Agile Modeling (AM), Dynamic Systems
Development Method (DSDM) e o Scrum.
19
O Scrum se destaca das outras metodologias ágeis por apresentar fatores e artefatos
visíveis para a gerência do processo como gerência de requisitos, manutenção de tarefas,
planos e métricas bem distintos. Toda a abordagem da metodologia Scrum é descrita a seguir.
2.2 SCRUM
Schwaber e Beedle (2002, p. 1) afirmam que o Scrum é uma metodologia ágil de
desenvolvimento de software empírica, significando que ela é voltada às experiências
passadas da equipe e de outras experiências para argumentar seus métodos.
Esta metodologia trata os papéis a serem desempenhados no decorrer do projeto como
sendo apenas três: Product Owner, Scrum Manager e Scrum Team. As responsabilidades de
todas as atividades do projeto são divididas entre esses três papéis. As atividades do Scrum
podem ser resumidas como mostra a Figura 1.
Fonte: adaptado de Control Chaos (2005).
Figura 1 - Modelo de processo baseado em Scrum
20
2.2.1 PAPÉIS DO SCRUM
De acordo com Schwaber (2004, p. 6-7), o Product Owner é o responsável por
representar os interesses de todos envolvidos com o software, e demonstra esses interesses no
Product Backlog, onde ele classifica por ordem de importância os requisitos apresentados. O
Product Owner é o responsável por conseguir os requisitos iniciais do projeto, bem como os
objetivos de retorno de investimento e o plano de liberação. Isto é conseguido com uma
constante atualização e priorização dos itens do Product Backlog. Já o Scrum Team tem a
função de desenvolver o software, sendo este auto-suficiente de suas funções, ou seja, o
Scrum Team se organiza internamente para distribuir as tarefas entre seus membros, bem
como apresentar os resultados, sendo um desses resultados o Sprint Backlog (o documento
que visa mostrar os resultados do desenvolvimento, conforme solicitado no Product Backlog).
E, por fim, o Scrum Master tem a função de manter o processo do Scrum, educar os
participantes do processo na metodologia Scrum e adaptá-lo a cultura da organização. Este
último ainda é responsável por mensurar todo o processo e verificar melhoras a serem feitas.
2.2.2 ATIVIDADES DO SCRUM
Schwaber (2004, p. 7-9) afirma que um projeto Scrum inicia com uma visão macro do
sistema a ser desenvolvido, onde esta visão pode ser vaga no início e tende a ser mais voltada
às regras de negócio do que às implementações do sistema. É de responsabilidade do Product
Owner passar esta visão aos outros membros do projeto e um dos meios de se fazer isto é
utilizando o Product Backlog. O Product Backlog é a lista dos requisitos funcionais e não
funcionais do sistema. Após a priorização do Product Backlog e a definição das futuras
releases é que o trabalho de desenvolvimento é feito. Este trabalho é feito através de Sprints,
21
que são ciclos de desenvolvimento de trinta dias consecutivos de um calendário. O Sprint
inicia com uma reunião de planejamento de Sprint, onde o Product Owner indica para o
Scrum Team quais as prioridades e este decide o quanto pode ser feito no próximo Sprint de
acordo com a priorização do Product Backlog. Dessa reunião é gerado o Sprint Backlog, que
acompanhará o Scrum Team no decorrer do ciclo de desenvolvimento. O Sprint sempre
termina com uma nova funcionalidade do sistema.
Todos os dias o Scrum Team faz uma reunião de quinze minutos denominada Daily
Scrum, onde os membros do Scrum Team respondem a três questões: O que você fez neste
projeto desde a última Daily Scrum? O que você pretende fazer entre agora e a próxima
reunião de Daily Scrum? Quais obstáculos você encontrou desde a última reunião de Daily
Scrum?
Após o final do Sprint, é realizada uma reunião de revisão do Sprint. Todos os
interessados no projeto participam desta reunião, incluindo o Product Owner e outros
stakeholders. Esta reunião informal serve para demonstrar as novas funcionalidades do
software.
Por fim, após a revisão do Sprint e antes da próxima reunião de planejamento de
Sprint, o Scrum Manager realiza uma reunião de retrospectiva do Sprint com o Scrum Team.
Nessa reunião o Scrum Manager encoraja o Scrum Team a revisar as técnicas utilizadas, com
as práticas do Scrum, assim, constituindo-se numa inspeção empírica e adaptativa das práticas
do Scrum.
2.2.3 ARTEFATOS DO SCRUM
Schwaber (2004, p. 9-14) diz que o Scrum introduz alguns artefatos novos. Dentre
esses artefatos encontra-se o Product Backlog. Nele encontram-se os requisitos do sistema
22
definido pelo Product Owner, separado por Sprints e Releases informando aos Scrum Teams
como (em grau de importância) eles devem desenvolver esses requisitos. Para um melhor
acompanhamento do processo, ainda no Product Backlog, encontram-se as estimativas de
tempo para término do requisito. O Product Backlog é dinâmico, alterado a qualquer
momento de acordo com o que o produto necessita.
Outro documento importante do Scrum é o Sprint Backlog, onde os Scrum Teams
podem fazer as suas estimativas particulares através do que é decidido na reunião de
planejamento do Sprint. Ele contém os requisitos que serão desenvolvidos no decorrer do
Sprint, quem originou este requisito, o responsável do requisito e um contador decrescente de
quanto tempo falta para o requisito ficar pronto em horas.
Outros documentos são gerados pelo Scrum, alguns já conhecidos, outros um pouco
menos, como o gráfico de Burn-Down, que representa a quantidade de requisitos atendida por
Sprint, para uma avaliação do processo e seus desvios com relação às estimativas. Tanto
esses, quanto os demais artefatos da metodologia Scrum estão descritos a seguir.
2.2.3.1 Product Backlog
“O Product Backlog é uma lista progressiva, priorizada de regras de negócio e
funcionalidades técnicas que precisam ser desenvolvidas dentro do sistema.” (SCHAWBER e
BEEDLE, 2002). É no Product Backlog que se encontram todos os requisitos,
funcionalidades, tecnologias, avanços e correções de erros existentes no sistema, que ainda
não foram implementados. Desta forma, o Product Backlog é a lista de todo o trabalho que
precisa ser feito.
O primeiro Product Backlog pode ser feito através de uma sessão de brainstorming,
onde vários interessados no projeto se reúnem e jogam idéias que poderiam ser usadas no
23
desenvolvimento do sistema. Estas idéias são estudadas e vistas a viabilidade delas estarem
contidas no projeto. Outras fontes ainda podem existir tanto de maneira formal, quanto de
maneira informal. A princípio o primeiro Product Backlog não é completo, ele apenas precisa
representar os princípios do sistema para uma primeira iteração (Sprint) do processo.
Após o primeiro Product Backlog criado, ele não é concretizado, muito pelo contrário,
ele pode ser modificado ou estendido a qualquer momento, se tornando assim, uma lista
dinâmica de requisitos do sistema.
A única pessoa responsável pela manutenção do Product Backlog é o Product Owner.
Este não pode ser uma comissão de pessoas, mas sim uma única pessoa responsável por tudo
que é desenvolvido no sistema. Esta pessoa não apenas pode como deve sofrer influências de
outras comissões de pessoas ou departamentos para ter uma melhor visão do que deve ser
desenvolvido no sistema.
As estimativas feitas no Product Backlog são feitas também de maneira dinâmica. Elas
não querem dizer quanto tempo, exatamente, a funcionalidade vai ficar pronta, mas sim ser
um ponto de partida para a previsão de término das tarefas no Sprint e um medidor para o
Scrum Team decidir o que pode ser feito no próximo Sprint.
2.2.3.2 Sprint Backlog
De acordo com Schawber e Beedle (2002, p. 71), o Sprint Backlog consiste nas tarefas
que o Scrum Team cria para uma iteração do processo (Sprint). Toda tarefa descrita no Sprint
Backlog tem uma referência dos requisitos apresentados no Product Backlog. Através de uma
reunião feita antes do início do Sprint o Sprint Backlog é gerado, contendo as tarefas que
serão realizadas durante o período do Sprint. As estimativas de tempo são decididas durante
esta reunião denominada Sprint Backlog Meeting. Todas as tarefas, preferencialmente,
24
deverão ser finalizadas até o final do Sprint, sendo que, tarefas não finalizadas devem se
tornar parte do próximo Sprint Backlog.
O Scrum Team é o único responsável por manter o Sprint Backlog, gerando a lista de
tarefas a serem desenvolvidas durante o Sprint, e atualizando as estimativas de tempo,
gerando um histórico de Sprints e tornando a gerência de processo baseado em Scrum, uma
metodologia empírica de desenvolvimento de software, por se basear em experiências
passadas para a geração de novos itens e estatísticas apresentados.
Ao finalizar uma tarefa antecipadamente, o responsável pela tarefa, pertencente ao
Scrum Team, deve continuar atualizando as estimativas de tempo com hora zero (0),
demonstrando assim uma tarefa terminada antes do final do ciclo.
2.2.3.3 Daily Scrum
Durante a Daily Scrum são discutidos diversos assuntos, dificuldades e soluções de
relevância para o projeto atual. Porém, esses assuntos, dificuldades e soluções podem ser
utilizados tanto adiante no mesmo projeto como pode ser utilizado por outros projetos. Desta
forma, o registro dessas reuniões é de altíssima importância, já que, ao estar registrando essas
reuniões, o Scrum Team, estará realizando um histórico de soluções possíveis para diversos
problemas que poderão surgir em projetos futuros.
2.2.3.4 Release Backlog
Sucessor do Product Backlog. Demonstra as funcionalidades, requisitos, tecnologias,
avanços e correções de erros já desenvolvidos na aplicação. São gerados após a finalização do
Sprint. No Release Backlog os requisitos atendidos dentro do Sprint corrente são
25
transformados em Release Backlog e os não atendidos já são automaticamente enviados para
o próximo Sprint.
2.2.4 Avaliações do Scrum
O Scrum tem diversas formas de avaliar até onde está sendo cumprido as exigências e
práticas aconselhadas pelo Scrum. Uma dessas formas é através do gráfico de Burn-Down
(Figura 2), onde se mostra a quantidade de tarefas atendidas num determinado período do
processo, podendo ser uma iteração (Sprint) ou mais dias a ser definidos pelo Scrum Master.
É função do Scrum Master gerenciar o processo e verificar onde estão as falhas e adaptar o
Scrum para que essas falhas sejam corrigidas.
12
34
0
10
20
30
40
50
60
70
80
Ho
ras
Fal
tan
tes
Semana da Sprint
Fonte: adaptado de ControlChaos (2005) Figura 2 - Gráfico de Burn-Down
O Scrum Master se baseia muito no Sprint Backlog juntamente com o Product Backlog
para verificar como está o entendimento entre as duas partes do processo, a que decide o que
vai conter o sistema e a que vai desenvolver o que vai conter o sistema. Através desta análise
o Scrum Master toma as decisões necessárias para discutir entre Scrum Team e Product
Owner, fazendo melhorias e adaptando o Scrum para melhor atender a organização.
26
2.3 DOTPROJECT
O dotProject é um ambiente para gerenciamento de processo de software desenvolvido
sob a filosofia opensource. Este ambiente conta hoje com diversos módulos que auxiliam de
forma genérica as empresas a gerenciar o processo de software sem se preocupar com a
metodologia aplicada para tal.
“O dotProject [...] é um ambiente de gerência de projetos bastante completo, contando
com interface em português, customizável.” (BRASIL, 2004, p. 68). Na Figura 3 pode-se ver
uma tela do dotProject, na administração do sistema, onde o usuário Administrador pode optar
por incluir ou excluir um módulo do sistema ou ainda alternar a ordem de como esses
módulos são vistos no sistema.
Figura 3 - Tela de seleção de módulos do dotProject
O dotProject ainda trabalha com sistema de skins o que ajuda a personalizar o
ambiente, modificando o visual dele sem trocar as funcionalidades dos módulos.
2.3.1 A Arquitetura do dotProject
De acordo com o site do dotProject (2005), assim como diversos outros sistemas de
Tecnologia da Informação (TI), a arquitetura do sistema é a parte mais considerável do
27
sistema. E como dotProject não é diferente, ele utiliza o sistema de múltiplas camadas. A
arquitetura de múltiplas camadas do dotProject conta com cinco camadas bem distintas para
desenvolvimento do ambiente. Estas camadas são definidas, quanto ao seu escopo, como
global, quando o módulo é independente e utilizado por todo o sistema, e local, quando a
camada é específica para cada módulo utilizado.
A primeira camada do dotProject é a camada de persistência. Ela é a camada de mais
baixo nível do ambiente, pois é onde são gravados os dados utilizados por todo o sistema.
Utiliza-se nesta camada Sistema Gerenciador de Banco de Dados (SGBD) MySQL, podendo
ser trocado para PostgreSQL caso este seja preferido. Também se utiliza de arquivos do
sistema, tanto para armazenar os dados, como para controle de versão e manutenção de
arquivos. Seu escopo é global.
A segunda camada, de server-side, é provavelmente a mais importante. Ela é quem
promove o acesso aos serviços do servidor web, bem como os serviços do banco de dados.
Ela promove uma abstração de banco de dados utilizando tecnologia ADOdb, que é um
conjunto de classes escritas em PHP para abstração de banco de dados. Nesta camada também
se encontram os serviços de internacionalização, bem como de validações de formulários,
requisições e parâmetros do servidor web. Utiliza para estes serviços tecnologia PHP e PHP
Extension and Applicxation Repository (PEAR) (um conjunto de funções complementares ao
PHP distribuído pela própria comunidade PHP). Seu escopo é global.
A terceira camada, a de lógica de negócios, define as regras de negócio utilizadas pelo
sistema, auxiliando a camada dois a manter os dados coerentes, para que não ocorram
problemas de inconsistência dos dados. Também é nesta camada que se definem os modelos
de base de dados, assim como as restrições a estes dados (constraints). Dentre as
responsabilidades desta camada está a especialização das classes, produção de formulários,
computação dos dados e preparação para comunicação com a quarta e quinta camadas. O
28
escopo desta camada é local.
A quarta camada, de estrutura de apresentação, gera a estrutura para os conteúdos
através de scripts processados no servidor, em PHP. Para geração da estrutura lógica da
informação é utilizada tecnologia Smart (sistema de templates para PHP) e para
documentação lógica e abstração de formato de telas utiliza tecnologia eXtensible HyperText
Markup Language (XHTML) 1.0. O escopo desta camada é local.
A quinta e última camada trata da interface com o usuário. Ela é responsável pelas
adaptações do front-end com o usuário do sistema, adicionando facilidades e interatividade
com o usuário final. Para tratar das cores, posicionamento e fontes do sistema esta camada
utiliza tecnologia Cascading Style Sheets (CSS). Esta tecnologia permite desenvolver a
interface com o usuário sem se preocupar com a compatibilidade do ambiente com o
navegador utilizado pelo cliente, já que a maioria dos navegadores tem esta tecnologia
embutida. Também se encontram nesta camada validações de formulário executados na
máquina cliente (client-side), interatividade e controle de eventos, tudo através de outras
tecnologias como JavaScript e Document Object Model (DOM). Esta camada é local, porém
pode ser considerada em parte global, pelos padrões utilizados em todo o sistema.
2.3.2 Framework do dotProject
Neste tópico são mostrados os elementos mais importantes do framework do
dotProject, sua disposição e funcionalidade no ambiente conforme demonstrado no site do
dotProject (2005).
29
2.3.2.1 Arquivos e diretórios
A Figura 4 mostra de maneira macro os principais componentes desse framework de
acordo com o site do dotProject (2005), onde seus componentes se apresentam em forma de
arquivos e diretórios. Os três únicos arquivos que ficam na pasta raiz de instalação do
ambiente são os arquivos ChangeLog, que serve de histórico do sistema para respectivas
trocas de versões; fileviewer.php, que é um script para visualização de arquivos utilizado por
todo o sistema; e por último, porém mais importante de todos, o index.php que é o arquivo
principal do ambiente que controla as mensagens de erro, instância dos objetos das classes
base, carregamentos das variáveis principais e das definições de tela, além de buscar a
linguagem a ser utilizada no ambiente.
Figura 4 - Framework do dotProject
Dos diretórios encontrados no framework básico do dotProject, destacam-se dois
diretórios globais que se pode ver na Figura 5: o diretório classes, onde se localizam todas as
classes principais do ambiente utilizadas de forma global, e o diretório include, utilizado para
30
armazenar todos os arquivos importantes como arquivo de permissões, configuração da base
de dados, configurações do ambiente e do script de email.
Figura 5 - Representação dos diretórios include e classes com seus arquivos
Os diretórios misc, locales e style, servem respectivamente para armazenar arquivos de
funções gerais, traduções para outras línguas e estilos de telas para o ambiente dotProject.
No diretório lib encontram-se todas as classes e bibliotecas utilizadas pelo ambiente
que não foram desenvolvidas pela equipe do dotProject. Dentre essas bibliotecas encontram-
se as utilizadas para geração de gráficos, documentos em pdf e acesso a base de dados.
Outros diretórios como db e docs são diretórios que servem para armazenar arquivos
utilizados na instalação ou atualização do ambiente, como arquivos de ajuda e scripts de
banco de dados. O diretório functions serve para armazenar funções dos módulos básicos do
dotProject.
Também existem os diretórios images e files que são utilizados respectivamente para
armazenar as imagens do ambiente (que são utilizadas por vários módulos) e os arquivos que
são adicionados pelos usuários ao ambiente para destacar uma funcionalidade ou tarefa
realizada.
Desses diretórios o mais importante deles é o diretório modules, que mantém todos os
módulos do dotProject em forma de diretórios. Estes diretórios têm por nome, o nome do
próprio módulo e dentro de cada diretório tem os arquivos necessários para o funcionamento
do módulo, além das classes globais. A Figura 6 demonstra a estrutura básica dos arquivos
dentro de cada módulo. O primeiro desses arquivos é o [mod].class.php, onde [mod] é o nome
31
do módulo do ambiente, utilizado para desenvolver a classe base do módulo. O arquivo
addedit[obj].php serve exclusivamente para a criação dos formulários para inclusão/exclusão
dos objetos do módulo, sendo que cada módulo pode ter diversos objetos. O arquivo
do_[obj]_aed.php realiza os procedimentos do banco de dados para inclusão, alteração e
exclusão dos objetos do módulo. O módulo ainda pode conter um diretório chamado images
para armazenar as imagens específicas desse módulo. Além desses arquivos, mais dois são
utilizados para a criação de um módulo. O arquivo index.php é utilizado para preencher a
página inicial do módulo e utiliza o arquivo w_[prop]_[obj].php para definir diversas
visualizações de propriedades ou objetos diferentes.
Figura 6 - Representação da estrutura de um módulo do dotProject
2.3.2.2 Variáveis globais/comumente usadas
O dotProject trabalha com um conjunto de variáveis de ambiente distintas que servem
para auxiliar no manejo dos dados com relação a interação com os usuário. O Quadro 1
mostra essas variáveis e a funcionalidade de cada uma delas.
32
string $m Contém o nome do módulo atual, onde o usuário se encontra. bool $canRead Usada de forma global no sistema para verificar permissão de leitura nos módulos. bool $canEdit Usada de forma global no sistema para verificar permissão de escrita nos módulos. array $dPconfig Lista das variáveis de configuração do dotProject que se encontram no arquivo
config.php dentro do diretório includes. array $perms Lista de permissões string $sql Comumente usado para armazenar os comandos enviados ao banco de dados. Fonte: adaptado de DOTPROJECT (2005).
Quadro 1 - Variáveis globais/comumente usadas no dotProject
2.3.2.3 Funções e métodos globais sem classe específica
O dotProject tem um conjunto de funções e métodos que são utilizados para auxiliar os
módulos com funções de escopo global. Essas funções na verdade são chamadas a outros
métodos e funções que acabam chamando outros métodos e funções até as bibliotecas de mais
baixo nível do dotProject. Desta forma, não serão demonstrados esses métodos e funções de
mais baixo nível, mas sim, os métodos e funções de interesse para se construir um novo
módulo. O Quadro 2 tem a definição dessas funções, o arquivo que se encontram e a
descrição do que faz cada uma dessas funções ou métodos.
33
bool getDenyEdit( string $m, int $item_id )
config.php Retorna verdadeiro quando o usuário tem direito de escrita no módulo $m ou no $item_id respectivo, caso contrário retorna falso.
bool getDenyRead( string $m, int $item_id )
config.php Mesmo que anterior, porém, apenas para leitura.
db_bindHashToObject( array $hash, object $object, string $prefix, bool $checkslashes, bool $bindAll )
db_connect.php Liga o conteúdo de $hash com as propriedades do objeto $object.
db_delete( string $table, string $keyName, mixed $keyValue )
db_connect.php Exclui as linhas da tabela $table onde $keyName tem o valor $keyValue
array db_loadList(string $sql, int $maxrows )
db_connect.php Retorna um array associativo da sentença SQL, limitada por $maxrows
array db_loadObject( string $sql, object &$object, bool $bindAll )
db_connect.php Liga o conteúdo da primeira linha da sentença SQL com o objeto $object.
string addHistory( string $description, int $project_id, int $module_id )
main_functions.php Adiciona uma entrada no histórico para mudanças de percurso marcadas.
string defVal(mixed $var, mixed $def )
main_functions.php Retorna o valor padrão $def se a variável $var não esta setada.
string dPformSafe( string $txt, bool $deslash )
main_functions.php Converte $txt para uma string com aspas duplas no início e no final.
string dPgetParam( array &$arr, string $name, mixed $def )
main_functions.php Retorna o valor de um array nomeado, ou o valor padrão $def.
string arraySelect( array &$arr, string $select_name, array $select_attribs, string $selected, bool $translate = false)
main_functions.php Retorna um formulário HiperText Markup Language (HTML) baseado na chave do primeiro array, traduzido, caso $translate for igual a verdadeiro.
Fonte: adaptado de DOTPROJECT (2005).
Quadro 2 - Definições das funções e métodos globais do dotProject
2.3.2.4 A Classe CDpObject
A Classe CDpObject está contida no arquivo dp.class.php e é responsável pelo acesso
a base de dados com abstração de banco de dados. Através desta classe as outras classes são
extendidas para fornecer acesso à base de dados. Dentre as suas propriedades estão a $_tbl,
que é a responsável por armazenar o nome da tabela na base de dados, a $_tbl_key, que se
responsabiliza pelo nome da chave primária da tabela na base de dados e por fim a
propriedade $_error que armazena a mensagem de erro.
Os métodos que se encontram na classe CDpObject são demonstrados no Quadro 3
com suas funcionalidades.
34
bind( $hash ) Preenche os dados contidos em $hash no objeto. load( $oid=null, $strip=true ) Carrega os dados do banco de dados baseados no $oid utilizando a chave
primária do banco. store( $updateNulls=false) Realiza as inclusões e alterações no banco de dados baseado no conteúdo
do Objeto. canDelete( string &$msg, $oid=null, $joins=null )
Verifica a dependência dos dados com relação a outros módulos.
delete( $oid = null ) Exclui dados do banco de dados baseado no valor de $oid. Fonte: adaptado de DOTPROJECT (2005).
Quadro 3 - Métodos da classe CDpObject
2.4 TRABALHOS CORRELATOS
Não foi possível encontrar um trabalho correlato do desenvolvimento ou estudo de
uma ferramenta ou ambiente que desse suporte ao Scrum. Encontra-se muito mais material
sobre eXtreming Programming (XP) do que sobre Scrum. Sendo assim, descreve-se o
trabalho realizado por Pohren (2004) utilizando XP. O trabalho trata de uma ferramenta de
gerência de processos baseado no XP, o XPManager. O trabalho ainda defende as
metodologias ágeis como solução para projetos com requisitos instáveis e equipes de trabalho
realmente pequenas. Neste mesmo trabalho são mostradas as dificuldades de se encontrar
ferramentas que dê apoio a este tipo de metodologia, sendo que, acima de tudo estas
ferramentas devem ter as mesmas características desse tipo de metodologia, devem ser
práticas, sem muita burocracia e ágeis.
Outros trabalhos auxiliaram em partes específicas deste trabalho. Como o trabalho
realizado por Marquardt (2004), que mostra a realização de um ambiente web para gerência
de requisitos.
Um artigo apresentado por Soares (2004) mostra as metodologias ágeis no
desenvolvimento de software. Fala sobre o XP e o Scrum como alternativas às metodologias
tradicionais orientadas a documentação, deixando o desenvolvimento do software uma tarefa
muito menos burocrática. Este artigo ainda mostra que as metodologias ágeis em geral estão
35
sendo bem aceitas na indústria de software, havendo assim, cada vez mais interesse deste
público por essas metodologias.
36
3 DESENVOLVIMENTO DO TRABALHO
Este capítulo demonstra o desenvolvimento do ambiente web. São apresentados
requisitos, especificação e implementação do protótipo do ambiente.
3.1 REQUISITOS PRINCIPAIS DO PROBLEMA
O ambiente deverá atender aos integrantes do processo de Scrum para facilitar no
manejo dos artefatos gerados pelo mesmo. Por se utilizar de um outro ambiente, o novo
ambiente deve apresentar claramente o desenvolvimento dos novos módulos. Os principais
requisitos do ambiente são:
a) framework: o ambiente deverá ser desenvolvido sob o framework do dotProject,
utilizando os padrões e instruções utilizadas para a criação de módulos para o
mesmo;
b) classificação dos usuários: o ambiente deverá permitir uma classificação dos
usuários em Product Owner, Scrum Master e Scrum Team. Como padrão, o
dotProject mantém sempre um usuário Administrador, desta forma, manter este
nível como no original do ambiente. Para efeito de visualização deve-se contar
com mais um usuário conhecido como Stakeholder que não interage no
desenvolvimento, mas participa do processo influenciando o Product Owner sobre
o que deve ser feito no sistema;
c) adaptação do ambiente: o ambiente deverá se adaptar ao nível de usuário para
apresentar as opções de maior relevância a cada um dos usuários, modificando
menus e acessos a módulos específicos de cada um dos tipos de usuário;
d) Product Backlog: o ambiente deverá contar com um módulo para gerência do
37
Product Backlog. Este deverá contar com uma lista de requisitos do sistema, onde
o usuário poderá ordenar esta lista em grau de importância, assim como definir
expectativa de prazos para cada uma das funcionalidades do sistema e definir
planos de sprints e releases;
e) Sprint Backlog: o ambiente deverá contar com um módulo para gerência do Sprint
Backlog. Este deverá conter uma lista das tarefas a serem realizadas, bem como
expectativas de tempo definidas pelo próprio Scrum Team;
f) Release Backlog: o ambiente deverá apresentar as funcionalidades solicitadas pelo
Product Owner que já foram desenvolvidas separadamente das já desenvolvidas
classificando-as como Release Backlog;
g) Daily Scrum: o ambiente deverá conter um módulo para registro das Daily Scrum,
onde os integrantes dessa reunião deverão reportar o que farão até a próxima
reunião, o que foi desenvolvido desde a última reunião e quais as dificuldades
encontradas e soluções possíveis para estas dificuldades apresentadas pelo outros
integrantes do grupo ou descobertas;
h) avaliações: o ambiente deverá apresentar gráficos de Burn-Down para que o Scrum
Master possa avaliar o processo, tanto da visão do Product Backlog, quanto da
visão do Sprint Backlog;
i) tradução: o ambiente deverá ser desenvolvido na língua nativa do dotProject
(inglês) e traduzido para o português através dos arquivos de configuração de
linguagem adotados pelo dotProject.
3.2 ESPECIFICAÇÃO
Para a especificação do ambiente foi utilizada a ferramenta Java/UML Object-Oriented
38
Design Tool (JUDE) Communit, que é uma ferramenta freeware para desenvolvimento de
diagramas Unified Modeling Language (UML). Para o Diagrama Entidade Relacionamento
(DER) foi utilizado o DBDesigner 4 que é também uma ferramenta freeware para edição
desse tipo de diagramas. Para um melhor entendimento cada módulo desenvolvido foi
descrito separadamente.
Na Figura 7 é mostrado o diagrama de casos de uso geral do Scrum agrupando os
artefatos por suas funcionalidades em pacotes. Estas funcionalidades foram desenvolvidas no
ambiente como módulos para o dotProject e cada um desses pacotes é descrito em detalhes a
seguir.
Figura 7 - Diagrama de casos de uso do Scrum
3.2.1 Módulo Product Backlog
Neste módulo o usuário representado no diagrama (Figura 8) como Product Owner é o
único usuário de acesso para manter módulo, fazendo inclusão, alteração e exclusão dos itens
deste módulo. Os outros níveis de usuário podem apenas visualizar. O usuário representado
39
no diagrama como Scrum Master é o único que tem acesso ao caso de uso Verificar requisitos
X prazos.
Figura 8 - Diagrama de casos de uso do módulo Product Backlog
A seguir são descritos brevemente os casos de uso deste módulo:
a) manter Product Backlog: o Product Owner deve selecionar o item Product
Backlog do menu do ambiente e após isso, selecionar o projeto para visualizar os
itens já cadastrados e então clicar no item inserir para adicionar um novo item, ou
clicar sobre o item para alterar, ou ainda clicar no botão excluir para eliminar um
item do Product Backlog. O Product Owner deve informar dentre os dados do
Product Backlog a prioridade, release, sprint, descrição e estimativa em horas do
item. A estimativa de tempo informada pelo Product Owner deve ser ajustada para
informar uma estimativa média de tempo. O índice de ajuste da estimativa é
informado pelo Scrum Master nas propriedades do sistema.
b) verificar requisitos X prazos: o Scrum Master deve selecionar o item Product
Backlog do menu do ambiente e após isso, selecionar o projeto para visualizar os
itens já cadastrados só então selecionar a guia Avaliação. O sistema apresenta um
gráfico de Burn-Down apresentando do eixo “Y” os requisitos atendidos e no eixo
40
“X” o tempo decorrido do projeto.
c) priorizar Product Backlog: o Product Owner deve selecionar o item Product
Backlog do menu do ambiente e após isso selecionar o projeto para visualizar os
itens cadastrados e então clicar nas setas acima e abaixo que estão ao lado do item
para poder alterar a prioridade dele, ou clicar sobre o item e alterar a prioridade
pelo campo prioridade.
3.2.2 Módulo Sprint Backlog
Neste módulo o usuário é representado no diagrama (Figura 9) pelo Scrum Team que é
o único responsável por manter o Sprint Backlog. Desta forma nenhum outro usuário tem
acesso de edição neste módulo, apenas leitura. O usuário representado pelo Scrum Master é o
único com acesso ao caso de uso Verificar tarefas X prazos.
Figura 9 - Diagrama de casos de uso do módulo Sprint Backlog
A seguir são descritos brevemente os casos de uso deste módulo:
a) manter Sprint Backlog: o Scrum Team deve selecionar o item Sprint Backlog no
menu do ambiente e após isso selecionar o projeto para visualizar os itens
cadastrados. A tela deve habilitar a visualização do Sprint atual com todos os itens
do mesmo. Após isso o Scrum Team deve clicar no item inserir para incluir novos
itens, ou selecionar o item para ser editado, ou ainda clicar sobre excluir para
41
remover um item do Sprint Backlog. Dentre os dados que o Scrum Team deve
informar, encontram-se o item do Product Backlog que este item está atendendo, a
descrição, uma estimativa de tempo para o item ficar pronto e o status do item
(não iniciado, em progresso ou concluído). A cada semana o Scrum Team deve
informar quantas horas ainda faltam para terminar o item do Sprint Backlog, e caso
concluído, informar com zero o valor da hora e trocar o status do item.
b) verificar tarefas X prazos: o Scrum Master deve selecionar o item Sprint Backlog
no menu do ambiente e após isso selecionar o projeto para visualizar os item
cadastrados, em seguida selecionar a guia Avaliação. O sistema apresenta um
gráfico de Burn-Down apresentando no eixo “Y” as tarefas cumpridas e no eixo
“X” o tempo decorrido do projeto.
3.2.3 Módulo Daily Scrum
Neste módulo o usuário classificado como Scrum Team (Figura 10) registra após cada
uma das Daily Scrum o que foi feito, o que ele irá fazer e quais as dificuldades encontradas e
soluções possíveis encontradas, discutidas durante a reunião.
Figura 10 - Diagrama de casos de uso do módulo Daily Scrum
A seguir são descritos os casos de uso desse módulo:
a) registrar Daily Scrum: o Scrum Team deve selecionar o item Daily Scrum no menu
do ambiente para visualizar a tela de procura. Após isso, o Scrum Team deve
42
selecionar o item inserir para registrar um novo item do Daily Scrum. Os valores
de entrada para um novo item são as três perguntas chaves da Daily Scrum: “O que
você fez desde a última Daily Scrum?”, “O que você fará até a próxima Daily
Scrum?” e “Quais problemas, dúvidas e soluções encontrados desde a última Daily
Scrum?”.
b) consultar Daily Scrum: o Scrum Team deve selecionar o item Daily Scrum no
menu do ambiente para visualizar a tela de procura. O Scrum Team deve escrever
uma ou mais palavras chaves para então clicar no item Busca da tela. Os resultados
são apresentados na mesma tela filtrados pelas palavras chaves do usuário, no caso
o Scrum Team.
Para uma melhor compreensão do que foi feito, na Figura 11 apresenta-se um
diagrama de classes onde se tem as principais classes do ambiente desenvolvido. As classes
que pertencem ao ambiente dotProject estão preenchidas com uma cor escura, enquanto que
as classes novas estão preenchidas com a cor branca.
As classes CProductBacklog, CSprintBacklog e CDailyScrum, que são as três classes
principais que servem aos requisitos do Scrum, são estendidas/especializadas da classe
CDpObject que é a classe que faz a comunicação com a camada de persistência do ambiente.
No dotProject não existe uma classe específica que cuide dos usuários do ambiente,
este processo é distribuído entre as classes da interface do ambiente (CAppUI) e a classe de
sistema (CSystem) que não é apresentada no diagrama, por ser uma classe global ao qual não
se faz chamadas diretas a ela.
43
Figura 11 - Diagrama de classe do ambiente dotProject adaptado para Scrum
Há uma dependência da classe de empresas (CCompany) e a classe de projetos
(CProject), esta se dá no ambiente de forma que não se pode criar um projeto sem associá-lo a
uma empresa, sendo que esta característica é do próprio ambiente dotProject e não foi
alterada. Uma dependência da classe de projetos é feita na classe de Product Backlog
(CProductBacklog) desta forma, também na se pode ter um Product Backlog sem associá-lo a
um projeto. Da mesma forma é feito com a classe de Sprint Backlog (CSprintBacklog) que
depende da classe de Product Backlog.
44
Complementando o diagrama a classe CAppUI é a responsável por toda a integração
dos módulos, verificação de acesso dos usuários, criação das telas e personalização através de
Templates.
Para uma melhor compreensão do armazenamento dos dados e da estrutura que será
aproveitada do dotProject, a Figura 12 mostra um Diagrama de Entidade e Relacionamento
(DER) lógico das principais entidades utilizadas na adaptação do ambiente. O modelo mostra
as novas entidades voltadas para o Scrum juntamente com as entidades já existentes no
dotProject. Os relacionamentos apresentados não estão fisicamente na base de dados, mas são
definidos na segunda camada do dotProject.
Figura 12 - DER lógico do ambiente dotProject adaptado para Scrum
As três entidades criadas para apoiar as funcionalidades do Scrum são:
45
a) product_backlog: utilizada para armazenar os dados do Product Backlog incluídos
pelo Product Owner;
b) sprint_backlog: utilizada para armazenar os dados do Sprint Backlog incluídos
pelo Scrum Team;
c) daily_scrum: utilizada para armazenar os dados do Daily Scrum registrando todos
os dias pelo Scrum Team.
As outras entidades encontradas no diagrama já são parte integrante do dotProject e
foram utilizadas para apoiar o processo. Estas entidades são:
a) projects: guarda os dados referentes ao projeto;
b) companies: guarda os dados referente as empresas cadastradas no sistema
separando por categoria (cliente, fornecedor, interno, etc.);
c) users: guarda os dados referentes aos usuários do sistema incluindo sua categoria
(administrador, product owner, scrum team, scrum master e stakeholder).
Complementando o DER lógico, no Apêndice A está o dicionário de dados com a
descrição dos atributos.
3.3 IMPLEMENTAÇÃO
Para implementação do ambiente foram utilizados apenas softwares livres, desde
servidor web (Apache), sistema gerenciador de banco de dados (MySQL), linguagem de
scripts do servidor Personal Home Page (PHP), o framework de trabalho (dotProject),
inclusive a Integrated Development Environment (IDE) para edição dos códigos, onde foi
utilizado Eclipse com a extensão (plug-in) para edição de código PHP. No framework do
dotProject ainda são utilizados Hyper Text Markup Language (HTML) e JavaScript para
interação com o usuário e validação das informações, além de outras tecnologias já
46
comentadas (ver arquitetura do dotProject).
A implementação é feita sobre a forma de módulos para o ambiente dotProject que já
disponibiliza todo conjunto de classes e variáveis de ambiente para esta programação.
3.3.1 Técnicas e ferramentas utilizadas
A criação de um módulo do dotProject inicia com a criação de um arquivo de
setup.php para a instalação, atualização, exclusão e configuração do módulo. O Quadro 4
mostra o exemplo deste arquivo para a criação do módulo Product Backlog.
<?php $config = array(); $config['mod_name'] = 'Product Backlog'; $config['mod_version'] = '1.0.0'; $config['mod_directory'] = 'productbacklog'; $config['mod_setup_class'] = 'CSetupProduct'; $config['mod_type'] = 'user'; $config['mod_ui_name'] = 'Product Backlog'; $config['mod_ui_icon'] = 'product.gif'; $config['mod_description'] = 'Módulo para gerência da Product Backlog'; $config['mod_config'] = true; if (@$a == 'setup') echo dPshowModuleConfig( $confi g ); class CSetupProduct { function configure() { global $AppUI; $AppUI->redirect( 'm=productbacklog&a=configure' ); return true; } function remove() { db_exec( "DROP TABLE product_backlog ;" ); return null; } function upgrade( $old_version ) { return false; } function install() { $sql = "CREATE TABLE product_backlog ( " . " product_backlog_id INTEGER UNSIGNED NOT NULL AU TO_INCREMENT". ",project_id INTEGER(11) NOT NULL" . ",product_backlog_nm VARCHAR(256) NOT NULLL" . ",product_backlog_ds TEXT NULL" . ",hour_est INTEGER UNSIGNED NULL" . ",prior_id INTEGER UNSIGNED NULL" . ",sprint_id INTEGER UNSIGNED NULL" . ",release_id INTEGER UNSIGNED NULL" . ",product_backlog_st CHAR NULL" . ",PRIMARY KEY (product_backlog_id)" . ",UNIQUE KEY product_backlog_id (product_backlog_ id)" . ",INDEX product_backlog_project_fk(project_id)" . ");"; db_exec( $sql ); db_error(); return null; } } ?>
Quadro 4 - Script para instalação do módulo no framework do dotProject
Como se pode conferir, este arquivo inicia com a declaração de um array com as
47
configurações do módulo (nome, versão, tipo, etc.) e em seguida há a declaração da classe de
configuração para o módulo específico. Esta classe conta com quatro funções que servem para
configuração, instalação, atualização e exclusão do módulo no sistema.
Além do arquivo de instalação de módulo, é necessário um arquivo para
implementação da classe do módulo. Este deve ter no seu nome o nome do módulo e o sufixo
.class e a extensão .php. No Quadro 5 é apresentado o exemplo deste arquivo para o módulo
Sprint Backlog (sprintbacklog.class.php)
<?php require_once( $AppUI->getSystemClass ('dp' ) ); class CSprintBacklog extends CDpObject { var $sprint_backlog_id = NULL; var $product_backlog_id = NULL; var $sprint_backlog_nm = NULL; var $sprint_backlog_ds = NULL; var $sprint_backlog_st = NULL; var $requisitor_id = NULL; var $user_id = NULL; var $hours_1 = NULL; var $hours_2 = NULL; var $hours_3 = NULL; var $hours_4 = NULL; function CSprintBacklog() { $this->CDpObject( 'sprint_backlog', 'sprint_backl og_id' ); } } ?>
Quadro 5 - Script de especificação da classe CSprintBacklog
Neste arquivo é feita uma requisição do módulo global dp onde fica localizada a
declaração da classe CDpObject, que é estendida pela classe CSprintBacklog para acessar a
tabela sprint_backlog da base de dados. Todos os atributos da tabela são colocados como
atributos da classe para haver a comunicação entre as duas entidades. O único método escrito
na classe CSprintBacklog é o método construtor, que informa para a classe qual o nome da
tabela e da chave primária na base de dados. Os outros métodos para edição, exclusão, etc.
são herdados da classe CDpObject.
Há ainda mais três arquivos necessários para o desenvolvimento do módulo. Um deles
é utilizado para fazer os scripts de comunicação com a base de dados, responsável pela
inserção, alteração e exclusão dos registros do módulo (do_modulo_aed.php). Os dois últimos
48
são utilizados para desenho da interface com o usuário, sendo um deles o formulário de
inserção/alteração de registros (addedit.php), e o outro como interface inicial do módulo para
listagem, filtros, etc (index.php).
Outros arquivos ainda podem fazer parte do módulo, porém estes são a base para a
construção de um módulo.
3.3.2 Operacionalidade da implementação
Para uma melhor compreensão do ambiente, é apresentado a seguir um estudo de caso
hipotético (Quadro 6) apresentado na disciplina de Requisitos de Software na Universidade
Regional de Blumenau (FURB). Este estudo de caso é utilizado para testar o ambiente e
realizar uma demonstração das telas que serão vistas á seguir.
Uma entidade ambientalista decidiu criar um banco de dados sobre as pescas realizadas na sua região de
atuação, a fim de disponibilizar dados de interesse dos pescadores, entidades de pescadores e a comunidade em
geral. Foi realizado um censo onde foram coletadas as seguintes informações: Dados sobre embarcações:
proprietário, nome da embarcação, comprimento, inscrição na capitania dos portos, ano construção. Sobre o
proprietário é cadastrado o nome, endereço, CPF, apelido e município; As embarcações podem ser para pesca
artesanal ou industrial. Quando for barco para pescaria industrial, devem ser armazenados ainda dados como a
capacidade de estocagem e se a embarcação possui tanque de isca. No caso da pesca artesanal devem ser
informados ainda o tipo de material do casco e o tipo de propulsão do barco (motor, vela, remo, etc.). Para cada
embarcação serão armazenados os diversos tipos de petrechos de pesca utilizados (rede, caniço, etc.) e também o
tipo de conservação do pescado (refrigerado, sem refrigeração, etc.). Cabe aos pesquisadores o cadastramento
das espécies de animais encontrados na área marítima considerada pelo sistema. Sobre cada espécie é anotado
código, nome científico e nome popular. Os fiscais vão informar os dados coletados sobre as pescas, que foram
anotados nos pontos de desembarque, registrando a data, hora, embarcação e para cada espécie capturada, será
registrada a quantidade em quilos obtida e o petrecho utilizado para sua captura. Sobre as pescas realizadas
(desembarques), o sistema disponibilizará aos usuários em geral dois relatórios mensais: quantidade total
pescada por espécie e embarcações com maior quantidade de pesca (quilos) utilizando rede.
49
Quadro 6 - Estudo de caso "Controle de Pesca"
A primeira página do ambiente é a de acesso ao sistema (Figura 13). Nesta deve-se
informar o Nome do usuário e senha, logo depois clicar no botão entrar para ser redirecionado
para a página principal do ambiente.
Figura 13 - Acesso ao sistema
O ambiente configura as opções de menu e outros itens através do tipo de usuário que
acessa o sistema. Por isso, é mostrado a seguir como é a operacionalidade do ambiente de
acordo com cada um dos tipos de usuário.
3.3.2.1 Usuário Product Owner
Depois de autenticado o acesso é apresentada a página inicial do ambiente (Figura 14),
os menus dos módulos que o usuário tem acesso e a tela de do primeiro módulo que, no caso
do Product Owner, é o Product Backlog. As opções disponíveis no menu são:
a) product backlog: gerencia os itens do Product Backlog (requisitos);
b) projetos: gerencia os projetos;
c) empresas: gerencia as empresas;
d) contatos: gerencia os contatos das empresas.
50
Figura 14 - Página principal do usuário Product Owner
No canto superior direito ainda encontra-se algumas opções de acesso rápido. São elas:
a) ajuda: ajuda do ambiente;
b) minhas informações: acesso rápido as configurações do usuário atual;
c) hoje: acesso rápido a agenda com a data de hoje;
d) sair: saída do sistema.
Essas opções são padrões para todos os usuários do ambiente.
Para se ter um Product Backlog o usuário deve antes ter no ambiente um projeto
cadastrado no ambiente. O dotProject exige que uma empresa seja vinculada ao projeto,
podendo ser assim a própria empresa tratada como empresa do tipo interna.
As opções de cadastro de empresas, contatos e projetos são visíveis para qualquer
usuário, exceto para o tipo stakeholder que tem acesso apenas a página de Product Backlog
somente para leitura.
O usuário deve clicar no item “empresas” para apresentar a tela de listagem de
empresas cadastradas no ambiente (Figura 15). Nesta página as empresas são separadas em
guias de acordo com os tipos que foram cadastradas no ambiente.
Para incluir uma nova empresa o usuário deve clicar no item “nova empresa” no canto
superior direito da página do ambiente. Este levará a uma outra página para ser incluído os
dados da nova empresa (Figura 16).
51
Figura 15 - Página de listagem de empresas
Figura 16 - Página de formulário para cadastro de empresas
Ainda na listagem de empresas o usuário pode escolher verificar uma empresa, ou
mesmo alterar os seus dados. Para isto basta ele clicar sobre o nome da empresa requerida e
ele será levado à tela de visualização da empresa (Figura 17) onde ele pode verificar todas as
informações da empresa bem como escolher alterar ou excluir a empresa selecionada.
52
Figura 17 - Página de visualização dos dados da empresa
Nesta tela ainda encontram-se informações adicionais nas abas de rodapé da página.
Nestas abas o usuário pode escolher visualizar os projetos ativos, projetos arquivados,
departamentos, usuários e contatos da empresa de forma rápida e prática.
Após a empresa cadastrada, já é possível cadastrar um projeto para esta empresa. Desta
forma é utilizado o item de menu “projetos”, neste item o usuário é levado a listagem de
projetos do ambiente (Figura 18). Nesta página são separados por situação e ainda podem ser
filtrados pela empresa proprietária do projeto.
Figura 18 - Página de listagem de projetos
53
No canto superior direito da página o usuário encontra o item “novo projeto” que o
leva a página de formulário para inserção de um novo projeto com todos os seus dados
(Figura 19). A mesma janela é utilizada para a edição de um projeto já cadastrado, para isso o
usuário deve selecionar o projeto na listagem de projetos e na página de visualização de
projetos (Figura 20) o usuário deve selecionar o item “editar projeto”.
Figura 19 - Página de formulário para inclusão de projetos
Ainda na página de visualização de projeto (Figura 20) o usuário pode excluir o
projeto através do item “excluir projeto” no canto superior direito da página.
Figura 20 - Página para visualização do projeto
Depois de uma empresa e um projeto cadastrado, o usuário pode então incluir um item
54
no Product Backlog. Ao entrar no sistema o usuário do tipo Product Owner já é levado à
página de Product Backlog, caso contrário este poderá escolher a opção Product Backlog no
menu de acesso. Ao acessar esta página (Figura 21) o usuário é solicitado a selecionar um
projeto na listagem de projetos.
Figura 21 - Pagina de Product Backlog
Após selecionar o projeto são apresentados os itens do Product Backlog (Figura 22)
separados por Sprint e Release, bem como em ordem de prioridade.
Figura 22 - Página de Product Backlog com projeto selecionado
Nesta página é disponibilizado ao usuário alterar a prioridade do item do Product
Backlog através dos botões de setas acima e abaixo que cada um dos registros contém. Para
adicionar um novo item de Product Backlog, o usuário deve apenas acessar o item “novo
55
Product Backlog” para ser enviado a página de formulário de novo Product Backlog (Figura
23). Neste formulário são informadas todas as informações do item do Product Backlog, e ele
pode ser usado tanto para inserção como para alteração de um item.
Figura 23 - Página de formulário de item do Product Backlog
Para poder visualizar as informações, editar ou mesmo excluir um item do Product
Backlog o usuário deve clicar sobre o item e ele será levado à página de visualização do item
de Product Backlog (Figura 24). Nesta tela o usuário terá todas as informações do Product
Backlog.
Figura 24 - Página de visualização do Product Backlog
3.3.2.2 Usuário Scrum Team
Depois de autenticado o acesso o usuário é levado ao menu principal com as opções
56
disponíveis para este tipo de usuário. As opções disponíveis no menu são:
a) sprint backlog: gerencia os itens do Sprint Backlog (tarefas);
b) product backlog: gerencia os itens do Product Backlog (requisitos);
c) daily scrum: registro das reuniões de Daily Scrum;
d) projetos: gerencia os projetos;
e) empresas: gerencia as empresas;
f) contatos: gerencia os contatos das empresas.
O usuário com acesso de Scrum Team se difere do Product Owner simplesmente pelo
acesso ao Sprint Backlog e o Daily Scrum, que são respectivamente onde o Scrum Team
realiza a gerência de suas tarefas e o registro das reuniões de Scrum Daily. O acesso do Scrum
Team aos outros módulos apresentados é somente leitura, não podendo incluir, alterar ou
excluir qualquer item apresentado.
O usuário com nível de acesso definido como Scrum Team tem como página inicial no
sistema o próprio Sprint Backlog, porém ele pode ser acessado no menu pelo item Sprint
Backlog, onde o usuário é levado a página de Sprint Backlog (Figura 25).
Figura 25 - Página de Sprint Backlog
Nesta página o usuário pode incluir um item do sprint backlog através do item “novo
57
Sprint Backlog” no canto superior direito da página, dessa forma o usuário será levado à
página de formulário do Sprint Backlog para incluir um novo item (Figura 26).
Figura 26 - Página de formulário de Sprint Backlog
Clicando em um dos itens de Sprint Backlog o usuário será levado à página de
visualização do Sprint Backlog (Figura 27), onde ele pode editar ou mesmo excluir o item
selecionado.
Figura 27 - Página de visualização de Sprint Backlog
Para fazer o registro das Daily Scrum o usuário deve acessar o item “Daily Scrum” no
menu para ser levado a página de Daily Scrum (Figura 28). Esta página apresenta um
formulário para buscas de assuntos na base de Daily Scrum, sendo que para encontrar um
assunto, basta o usuário informar algumas palavras chaves e clicar no item “buscar”.
58
Figura 28 - Página inicial do módulo de Daily Scrum
Para registrar a Daily Scrum, o usuário deve acessar o item “nova Daily Scrum” no
canto superior direito da página, onde ele será levado à página de formulário de registro da
Daily Scrum (Figura 29). Nesta página o usuário do tipo Scrum Team responde as três
perguntas realizadas durante a Daily Scrum: O que você fez desde a última Daily Scrum? O
que você fará até a próxima Daily Scrum? Quais problemas e soluções surgiram desde a
última Daily Scrum?
Figura 29 - Página de formulário de registro das Daily Scrum
3.3.2.3 Usuário Scrum Master
Depois de autenticado o acesso é apresentada a página inicial do sistema com as
opções disponíveis para este tipo de usuário. As opções disponíveis no menu são:
a) sprint backlog: gerencia os itens do Sprint Backlog (tarefas);
59
b) product backlog: gerencia os itens do Product Backlog (requisitos);
c) daily scrum: registro das reuniões de Daily Scrum;
d) projetos: gerencia os projetos;
e) empresas: gerencia as empresas;
f) contatos: gerencia os contatos das empresas.
O que difere o acesso do usuário definido como Scrum Master dos demais é o acesso
total aos módulos apresentados e algumas opções de avaliação contidas dentro dos módulos.
Uma dessas opções de avaliação é dentro do módulo Product Backlog onde o Scrum Master
tem acesso a mais uma guia onde encontra o gráfico de Burn-Down para o Product Backlog
(Figura 30). O Gráfico pode ser gerado selecionando as opções de Sprint ou Release onde se
selecionado release a contagem de tempo é feita através das Sprints e se caso o usuário
selecione a opção Sprint a contagem de tempo é as quatro semanas onde é realizada a Sprint.
Figura 30 - Página de avaliação do Product Backlog
O outro item adicional para o Scrum Master é dentro do módulo de Sprint Backlog, na
guia de avaliação onde ele encontra o gráfico de Burn-Down para o Sprint Backlog (Figura
31). O usuário já inicia com o gráfico da Sprint atual podendo escolher qualquer uma das
60
outras Sprints já realizadas.
Figura 31 - Página de avaliação do Sprint Backlog
3.3.2.4 Outros Usuários
Existem ainda dois tipos de usuários que tem acesso ao sistema. Um deles é o usuário
do tipo stakeholder que tem acesso somente de leitura ao item de Product Backlog para ser
informado do que foi pedido e o que foi realizado durante um determinado Sprint.
O outro tipo de usuário não é padrão do Scrum, mas sim do próprio dotProject. O
usuário do tipo Administrador é o único que tem acesso a todos os itens de menu e mais
alguns itens adicionais que servem para gerenciar o sistema (Figura 32) e seus usuários
(Figura 33).
61
Figura 32 - Página de administração do ambiente
Figura 33 - Página de administração de usuários
3.4 RESULTADOS E DISCUSSÃO
Um resultado considerável diante deste trabalho, foi a documentação realizada sobre o
Scrum com seus artefatos, papéis e atividades na língua portuguesa. Esta documentação
possibilita a disseminação desta metodologia tanto nos meios acadêmicos, quanto no meio
profissional, onde a busca por metodologias deste tipo é cada vez maior.
62
O estudo realizado sobre a ferramenta dotProject significou muito, pois foi um estudo
que possibilitou a realização deste trabalho e colaborou com a documentação do dotProject na
língua portuguesa para desenvolvedores dessa plataforma.
O ambiente desenvolvido atende aos principais artefatos do Scrum, sendo estes
separados em três módulos do dotProject. No primeiro módulo atende-se a três desses
artefatos, sendo eles o Product Backlog, o Release Backlog e o gráfico de Burn-Down gerado
a partir dos requisitos versus o tempo decorrido. No segundo módulo se atende a mais dois
artefatos, sendo eles o Sprint Backlog e o gráfico de Burn-Down, desta vez analisando as
tarefas versus o tempo decorrido no Sprint. No terceiro e último módulo é o Daily Scrum que
atende a um artefato que não é explicitamente definido no Scrum, porém achou-se
conveniente registrar as dúvidas e soluções apresentadas durante esta reunião.
Foram realizados apenas testes funcionais ao longo da evolução do ambiente. Os
resultados apresentados demonstram o atendimento adequado aos principiais artefatos
utilizados pelo Scrum.
63
4 CONCLUSÕES
Foi desenvolvido um ambiente web para gerenciamento de processo de software
baseado na metodologia Scrum. Por se utilizar do dotProject como base de desenvolvimento,
este teve sua finalização melhor depurada por se utilizar de diversas classes e funções já
bastante testadas. A principal dificuldade com relação ao dotProject foi a sua documentação,
que é basicamente restrita ao site da comunidade dotProject.
O dotProject foi estendido e adaptado para se adequar a metodologia ágil Scrum. Para
isso foram criados três módulos adicionais (Product Backlog, Sprint Backlog e Daily Scrum).
Estes foram desenvolvidos na língua nativa do dotProject (inglês) e traduzidos para o
português através de arquivos de configuração do dotProject.
O estudo realizado na metodologia ágil Scrum poderá servir de referência para novos
estudos sobre esta metodologia. O estudo demonstrou que o Scrum por ser uma metodologia
ágil pode ser utilizado como alternativa de processo de software para pequenas e médias
empresas de software, pois é um processo pouco burocrático que visa resultados ao invés de
documentação extensa, reage a mudanças e valoriza os indivíduos que participam no processo
e a interação entre eles.
4.1 EXTENSÕES
Uma extensão para este trabalho seria a maior integração do módulo de tarefas já
existente no dotProject com o módulo Sprint Backlog criado no decorrer do trabalho para
geração de percentuais de conclusão de trabalho, bem como a contabilização das horas
trabalhadas e o custo do trabalho realizado.
Uma segunda sugestão de extensão da ferramenta é a inclusão de artefatos que não são
64
exclusivamente do Scrum, mas que podem fazer uma maior integração entre as tarefas como o
gráfico de Program Evaluation and Review Technique (PERT) que demonstra a dependência
de uma tarefa em relação à outra.
65
REFERÊNCIAS BIBLIOGRÁFICAS
ABRAHAMSSON, Pekka et al. New directions on agile methods: a comparative analysis. In: ICSE – INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING, 25., 2003, Portland. Proceedings... Portland: IEEE Computer Society, 2003. Disponível em: <http://www.informatik.uni-trier.de/~ley/db/conf/icse/icse2003.html#AbrahamssonWSR03>. Acesso em: 10 mar. 2005.
AGILE ALIANCE. Manifesto for agile software development. [S.l.], 2005. Disponível em: < http://www.agilemanifesto.org/>. Acesso em: 06 jul. 2005.
BRASIL, Secretaria de Logística e Tecnologia da Informação. Guia Livre : referência de migração para software livre do governo federal. Brasília: CISL, 2004. 233 p. Disponível em: <http://www.governoeletronico.gov.br/governoeletronico/publicacao/noticia.wsp?tmp.noticia=469&wi.redirect=RXN5BU>. Acesso em: 13 maio 2005.
CONTROL CHAOS. What is Scrum. [S.l.], 2005. Disponível em: <http://www.controlchaos.com>. Acesso em: 15 jun. 2005.
DOTPROJECT. Open source software. [S.l.], 2005. Disponível em: <http://www.dotproject.net>. Acesso em: 15 jun. 2005.
MARQUARDT, Luciano. Ferramenta web para gerenciamento de requisitos de software. 2004. 87 f. Trabalho de Conclusão de Curso (Bacharelado em Ciência da Computação) – Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.
POHREN, Daniel. XPMANAGER: uma ferramenta de gerência de projetos baseados em extreme programming. 2004. 172 f. Trabalho de Conclusão de Curso (Bacharelado em Ciência da Computação) – Instituto de Ciências Exatas e Tecnológicas, Centro Universitário Feevale, São José dos Campos.
REIS, Christian. Caracterização de um processo de software para projetos de software livre . 2003. 247 f. Dissertação (Mestrado em Ciências da Computação e Matemática Computacional) – Instituto de Ciências Matemáticas e de Computação, Universidade de São Paulo, São Carlos.
SANTOS, Alexandre Denes dos; MARTINS, Jefferson Carlos; LEAL, Manoel Flávio.Agile Modeling – Overview. Bate Byte. Curitiba, n. 131, maio 2003. Disponível em: <http://www.pr.gov.br/batebyte/edicoes/2003/bb131/index.shtml>. Acesso em: 06 jul. 2005.
SCHWABER, Ken. SCRUM Development Process: Advanced Development Methods. In: ANNUAL CONFERENCE ON OBJECT-ORIENTED PROGRAMMING SYSTEMS, LANGUAGES, AND APPLICATIONS ADDENDUM TO THE PROCEEDINGS, 10., 1995, Austin. Proceedings... Austin: ACM/SIGPLAN, 1995. Disponível em: <http://jeffsutherland.com/oopsla/oo95summary.html>. Acesso em: 15 jun. 2005.
66
SCHWABER, Ken. Agile project management with Scrum. Redmond, Wash: Microsoft Press, 2004.
SCHWABER, Ken; BEEDLE, Mike. Agile software development with Scrum. Upper Saddle River, New Jersey: Prentice Hall, 2002.
SOARES, Michel dos Santos. Metodologias ágeis extreme programming e Scrum para o desenvolvimento de software. RESI Revista Eletrônica de Sistemas de Informação. Campo Largo, v. 3, n. 1, nov. 2004. Disponível em: < http://www.presidentekennedy.br/resi/>. Acesso em: 15 jun. 2005.
67
APÊNDICE A – Dicionário de dados das principais entidades utilizadas pelo ambiente
Companies Coluna Tipo PK Descrição company_id INTEGER Sim Código da empresa company_module INTEGER Não utilizado/documentado company_name VARCHAR(100) Nome da empresa company_phone1 VARCHAR(30) Telefone principal da empresa company_phone2 VARCHAR(30) Segundo telefone da empresa company_fax VARCHAR(30) Fax da empresa company_address1 VARCHAR(50) Endereço principal da empresa company_address2 VARCHAR(50) Segundo endereço da empresa company_city VARCHAR(30) Cidade da empresa company_state VARCHAR(30) Estado da empresa company_zip VARCHAR(11) Código postal da empresa company_primary_url VARCHAR(255) Endereço eletrônico da empresa company_owner INTEGER Responsável pela empresa no ambiente company_description TEXT Descrição da empresa company_type INTEGER Tipo da empresa (Interno, Cliente, ...) company_email VARCHAR(255) Email da empresa company_custom LONGTEXT Observações sobre a empresa daily_scrum Coluna Tipo PK Descrição daily_scrum_id INTEGER Sim Código do registro de Daily Scrum user_id INTEGER Código do usuário do registro de Daily Scrum daily_scrum_qt1 TEXT Primeira questão do Daily Scrum daily_scrum_qt2 TEXT Segunda questão do Daily Scrum daily_scrum_qt3 TEXT Terceira Questão do Daily Scrum product_backlog Coluna Tipo PK Descrição product_backlog_id INTEGER Sim Código do requisito project_id INTEGER Código do projeto product_backlog_nm VARCHAR(255) Nome do requisito product_backlog_ds TEXT Descrição do requisito hour_est INTEGER Horas estimadas pelo Product Owner product_backlog_st INTEGER Status do requisito sprint_id INTEGER Identificação do ciclo do requisito release_id INTEGER Identificação do versão do requisito prior_id INTEGER Identificação de prioridade do requisito project Coluna Tipo PK Descrição project_id INTEGER Sim Código do projeto project_company INTEGER Empresa responsável do projeto project_department INTEGER Departamento do projeto
68
project_name VARCHAR(100) Nome do projeto project_short_name VARCHAR(50) Nome curto para o projeto project_owner INTEGER Usuário responsável pelo projeto project_url VARCHAR(255) Endereço eletrônico do projeto project_demo_url VARCHAR(255) Endereço eletrônico do demo do
projeto project_start_date DATETIME Data de inicio project_end_date DATETIME Data prevista para o fim project_actual_end_date DATETIME Data atual do fim project_status INTEGER Situação do projeto project_percent_complete TINYINT Percentual completo do projeto project_color_identifier VARCHAR(6) Cor de identificação do projeto project_description TEXT Descrição do projeto project_target_budget INTEGER Previsão de gastos do projeto project_actual_budget INTEGER Gastos atual project_creator INTEGER Criador do projeto project_active TINYINT Situação de projeto ativo project_private TINYINT Situação de projeto privado sprint_backlog Coluna Tipo PK Descrição sprint_backlog_id INTEGER Sim Código da tarefa product_backlog_id INTEGER Requisito que gerou a tarefa sprint_backlog_nm VARCHAR(255) Nome da tarefa sprint_backlog_ds TEXT Descrição da tarefa requisitor_id INTEGER Usuário requisitor da tarefa user_id INTEGER Usuário responsável pela tarefa
hours_1 INTEGER Previsão/trabalhado na primeira
semana hours_2 INTEGER Previsão/trabalhado na segunda semana hours_3 INTEGER Previsão/trabalhado na terceira semana hours_4 INTEGER Previsão/trabalhado na quarta semana user Coluna Tipo PK Descrição user_id INTEGER Sim Código do usuário user_username VARCHAR(20) Nome para entrada no sistema user_password VARCHAR(32) Senha para entrada no sistema user_parent INTEGER Não utilizado/documentado user_type TINYINT Tipo do usuário user_first_name VARCHAR(50) Primeiro nome do usuário user_last_name VARCHAR(50) Sobrenome do usuário user_company INTEGER Empresa do usuário user_department INTEGER Departamento do usuário user_email VARCHAR(255) Email do usuário user_phone VARCHAR(30) Telefone do usuário user_home_phone VARCHAR(30) Telefone residencial do usuário user_mobile VARCHAR(30) Telefone celular do usuário user_address1 VARCHAR(50) Endereço principal do usuário
69
user_address2 VARCHAR(50) Segundo endereço do usuário user_city VARCHAR(30) Cidade do usuário user_state VARCHAR(30) Estado do usuário user_zip VARCHAR(11) Código postal do usuário user_country VARCHAR(30) Pais do usuário user_icq VARCHAR(20) ID do icq do usuário user_aol VARCHAR(20) ID do aol do usuário user_birthday DATETIME Aniversário do usuário user_pic TEXT Foto do usuário user_owner INTEGER Responsável pelo usuário