AMBIENTE WEB PARA GERENCIAMENTO DE PROCESSO DE SOFTWARE BASEADO NO SCRUM

Transcrição

1 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 /1-28

2 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 /1-28

3 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: Membro: Membro: Prof. Everaldo Artur Grahl, Mestre Orientador, FURB Prof. Fabiane Barreto Vavassori Benitti, Doutora FURB Prof. Marcel Hugo, Mestre FURB Blumenau, 19 de julho de 2005

4 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.

5 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.

6 Quem disser que estamos fora, não nos conhece. Michael Schumacher

7 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.

8 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.

9 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

10 Figura 32 - Página de administração do ambiente...61 Figura 33 - Página de administração de usuários...61

11 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

12 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

13 SUMÁRIO 1 INTRODUÇÃO OBJETIVOS DO TRABALHO ESTRUTURA DO TRABALHO PROCESSO DE SOFTWARE METODOLOGIA ÁGIL SCRUM PAPÉIS DO SCRUM ATIVIDADES DO SCRUM ARTEFATOS DO SCRUM Product Backlog Sprint Backlog Daily Scrum Release Backlog Avaliações do Scrum DOTPROJECT A Arquitetura do dotproject Framework do dotproject Arquivos e diretórios Variáveis globais/comumente usadas Funções e métodos globais sem classe específica A Classe CDpObject TRABALHOS CORRELATOS DESENVOLVIMENTO DO TRABALHO REQUISITOS PRINCIPAIS DO PROBLEMA ESPECIFICAÇÃO Módulo Product Backlog Módulo Sprint Backlog Módulo Daily Scrum IMPLEMENTAÇÃO Técnicas e ferramentas utilizadas Operacionalidade da implementação...48

14 Usuário Product Owner Usuário Scrum Team Usuário Scrum Master Outros Usuários RESULTADOS E DISCUSSÃO CONCLUSÕES EXTENSÕES...63 REFERÊNCIAS BIBLIOGRÁFICAS...65 APÊNDICE A Dicionário de dados das principais entidades utilizadas pelo ambiente

15 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

16 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

17 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.

18 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

19 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.

20 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

21 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 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,

22 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 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

23 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 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

24 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 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,

25 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 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 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

26 25 transformados em Release Backlog e os não atendidos já são automaticamente enviados para o próximo Sprint 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 Horas Faltantes Semana da Sprint 3 4 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.

27 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 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

28 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

29 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 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).

30 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

31 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 . 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 encontramse 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

32 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 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.

33 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 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.

34 33 bool getdenyedit( string $m, int $item_id ) config.php bool getdenyread( string $m, int config.php $item_id ) db_bindhashtoobject( array $hash, db_connect.php object $object, string $prefix, bool $checkslashes, bool $bindall ) db_delete( string $table, string db_connect.php $keyname, mixed $keyvalue ) array db_loadlist(string $sql, int db_connect.php $maxrows ) array db_loadobject( string $sql, db_connect.php object &$object, bool $bindall ) string addhistory( string $description, main_functions.php int $project_id, int $module_id ) string defval(mixed $var, mixed $def main_functions.php ) string dpformsafe( string $txt, bool main_functions.php $deslash ) string dpgetparam( array &$arr, string main_functions.php $name, mixed $def ) string arrayselect( array &$arr, string main_functions.php $select_name, array $select_attribs, string $selected, bool $translate = false) Fonte: adaptado de DOTPROJECT (2005). Retorna verdadeiro quando o usuário tem direito de escrita no módulo $m ou no $item_id respectivo, caso contrário retorna falso. Mesmo que anterior, porém, apenas para leitura. Liga o conteúdo de $hash com as propriedades do objeto $object. Exclui as linhas da tabela $table onde $keyname tem o valor $keyvalue Retorna um array associativo da sentença SQL, limitada por $maxrows Liga o conteúdo da primeira linha da sentença SQL com o objeto $object. Adiciona uma entrada no histórico para mudanças de percurso marcadas. Retorna o valor padrão $def se a variável $var não esta setada. Converte $txt para uma string com aspas duplas no início e no final. Retorna o valor de um array nomeado, ou o valor padrão $def. Retorna um formulário HiperText Markup Language (HTML) baseado na chave do primeiro array, traduzido, caso $translate for igual a verdadeiro. Quadro 2 - Definições das funções e métodos globais do dotproject 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.

35 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, Verifica a dependência dos dados com relação a outros módulos. $joins=null ) 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

36 35 sendo bem aceitas na indústria de software, havendo assim, cada vez mais interesse deste público por essas metodologias.

37 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

38 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

39 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 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

40 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

41 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 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

42 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 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

43 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.

44 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.

45 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:

46 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á

47 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 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( $config ); 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 AUTO_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

48 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_backlog_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

49 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 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.

50 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 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.

51 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).

52 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.

53 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

54 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

55 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

56 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 Usuário Scrum Team Depois de autenticado o acesso o usuário é levado ao menu principal com as opções

57 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

58 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.

59 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 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);

60 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

61 60 outras Sprints já realizadas. Figura 31 - Página de avaliação do Sprint Backlog 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).

62 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.