UMA FERRAMENTA PARA GERENCIAMENTO SCRUM EM AMBIENTES DE DESENVOLVIMENTO GEOGRAFICAMENTE DISTRIBUÍDOS RESUMO

Transcrição

1 1 UMA FERRAMENTA PARA GERENCIAMENTO SCRUM EM AMBIENTES DE DESENVOLVIMENTO GEOGRAFICAMENTE DISTRIBUÍDOS Alex Radavelli 1 RESUMO Este artigo apresenta uma ferramenta para auxiliar no gerenciamento de projetos utilizando a metodologia ágil Scrum, aplicada em equipes de desenvolvimento geograficamente distribuídas, armazenando suas informações em nuvem, utilizando uma base centralizada de dados. Com isso, é possível planejar e acompanhar os projetos através de dispositivos móveis, permitindo que a equipe esteja sempre com visibilidade do status atual dos projetos, independentemente da localização geográfica de seus integrantes. Foram realizados testes e análise de resultados em um protótipo desenvolvido com base no modelo da ferramenta proposta, bem como comparações com pesquisas e ferramentas semelhantes, que comprovam a eficácia da ferramenta, quanto ao acompanhamento dos projetos utilizando Scrum em equipes distribuídas. Palavras-chave: Scrum. Metologias Ágeis. Aplicativos Móveis. Equipes Distribuídas. 1 INTRODUÇÃO Projetos de software estão presentes em praticamente todos os segmentos de mercado, o que implica na constante expansão da indústria de software. Este crescimento estimulou a procura por uma forma de entregar produtos de maneira mais ágil, com maior qualidade e, conseqüentemente, garantindo a satisfação dos clientes. Com isso, as empresas estão adotando metodologias ágeis como forma de acelerar a fabricação e garantir agilidade e qualidade em seus produtos. Assim como as metodologias ágeis, outro cenário em evidência nos dias atuais são os times de desenvolvimento geograficamente distribuídos, o que facilita a criação e manutenção de equipes e redução de custos com locomoção [1]. Desta forma, pode-se perceber que, tanto 1 Discente do curso Ciência da Computação do Centro Universitário La Salle Unilasalle, matriculado na disciplina de Trabalho de Conclusão II, sob orientação do Profº M.e. Eder Stone Fontoura. eder.fontoura@unilasalle.edu.br.

2 2 metodologias ágeis, quanto equipes de desenvolvimento distribuídas geograficamente são estratégias largamente utilizadas no atual cenário da indústria de software. As metodologias ágeis, no entanto, foram projetadas para utilização em equipes dispostas em um mesmo local físico de trabalho, o que facilita as freqüentes reuniões e atualizações de tarefas propostas pela metodologia. O Scrum é, dentre as diversas metodologias ágeis propostas, uma das mais utilizadas pelas empresas que produzem software [2]. Este artigo aborda uma ferramenta proposta para auxiliar no gerenciamento de projetos utilizando a metodologia Scrum em equipes de desenvolvimento geograficamente distribuídas e relata os resultados obtidos com um protótipo desenvolvido com base no modelo proposto. 2 METODOLOGIAS ÁGEIS De acordo com os métodos de desenvolvimento definidos na engenharia de software, pode-se dizer que a construção de um sistema de software é regida por um modelo de desenvolvimento de software. Durante décadas esses modelos foram sendo aprimorados e alguns deles se consolidando na área, como cascata, espiral, iterativo e incremental. Todos estes modelos de software possuem algumas características em comum, tais como a especificação, projeto e implementação, validação e evolução. Com o passar do tempo e a necessidade de atender a um mercado cada vez mais exigente e concorrido, começaram a surgir modelos que passaram a priorizar prazos e qualidade de entrega, as chamadas metodologias ágeis. Um dos pontos mais significativos para o surgimento destas metodologias é o fato de que os modelos tradicionais são muito pouco tolerantes a mudança de requisitos durante o desenvolvimento do software, porém, no atual cenário, os requisitos estão sujeitos a freqüentes modificações durante a construção e manutenção de um software [3]. As metodologias ágeis são flexíveis e adaptativas, indicadas para cenários com constante mudança de requisitos e com necessidade de entrega de resultados em curtos períodos, priorizando também a qualidade do produto ou serviço. O foco deve estar na entrega de algum valor real ao cliente [4].

3 3 3 SCRUM O objetivo da metodologia ágil Scrum é realizar entregas com qualidade em pequenos períodos de tempo previamente definidos, que vão gradativamente agregando valor real ao produto final entregue ao cliente. a) Product Backlog - A aplicação da metodologia Scrum em um projeto de software inicia a partir da definição do Product Backlog, que é basicamente uma lista de requisitos que o cliente solicita para o produto desejado. Essa lista de funcionalidades deve ser descrita utilizando preferencialmente a própria terminologia do cliente, visando facilitar a comunicação e reduzir dúvidas entre a equipe e o cliente [5]. A ideia é de que os itens definidos no backlog sejam desenvolvidos e entregues de forma incremental, agregando aos poucos valor real ao produto, de modo que, ao final do projeto, todos os itens definidos serão entregues e integrados, compondo desta forma o produto final. b) Sprint - Sprint é o período de desenvolvimento de funcionalidades do backlog que acontece entre cada uma das entregas incrementais do produto ao cliente. A duração de cada Sprint é previamente definida pela equipe (geralmente de duas a quatros semanas). Para tanto, depois da definição do Product Backlog, o time realiza o planejamento da Sprint, elencando os itens que serão entregues ao final da mesma. Cada requisito definido para Sprint deve ser desdobrado em tarefas, que irão compor o Sprint Backlog, ou seja, o quadro de tarefas da Sprint. Durante a Sprint, cada integrante da equipe deve executar uma tarefa por vez, até que todas as tarefas sejam concluídas, sempre respeitando o período de duração da Sprint. Para acompanhar o andamento das tarefas, é utilizado o quadro de tarefas, que geralmente é composto de algumas raias para identificar a situação de cada tarefa durante a Sprint. O quadro pode ter, por exemplo, uma raia para as tarefas que ainda estão no Sprint Backlog, ou seja, que ainda aguardam para entrar em execução, uma para as tarefas que já estão em execução, outra para aquelas que estão sendo validadas e, finalmente, uma para indicar as tarefas que já estão prontas para a entrega. A figura 1 representa um quadro de tarefas com quatro raias. A raia To Do contém as tarefas do backlog que estão aguardando para entrar em execução. A raia In Process possui tarefas que estão sendo executadas. A raia To Verify conta com as tarefas que estão sendo

4 4 validadas, ou seja, estão sendo testadas. E, por fim, a raia Done, contém as tarefas que estão prontas para entrega. Figura 1 - Quadro de tarefas Fonte: Mountain goat software, c) Planning Poker - Uma vez escolhidos os itens de entrega da Sprint, é realizado o Planning Poker, que consiste em uma votação feita pela equipe de modo a pontuar cada tarefa a ser realizada para que os itens da Sprint sejam entregues. A pontuação é uma unidade de medida abstrata, que serve para estimar o tempo de execução das tarefas e a velocidade da equipe no desenvolvimento dos itens. A pontuação pode ser definida como, por exemplo, as horas / homem estimadas para a execução de uma determinada tarefa, até que a mesma possa ser considerada como pronta para entrega. O Scrum é uma metodologia bastante flexível, ou seja, geralmente a maneira de conduzir um projeto utilizando Scrum pode variar bastante de uma equipe para outra, sempre respeitando as principais premissas da metodologia. Neste sentido, a forma de pontuar pode mudar de uma equipe para outra, mas, em geral, cada integrante avalia e pontua a tarefa em questão. Se houver votação diferente, cada um dos membros da equipe pode argumentar os motivos que o levaram a definir tal pontuação para a tarefa, até que se chegue a um consenso. Ao final da votação, todas as tarefas devem estar pontuadas e deste modo é possível obter o tamanho da Sprint, efetuando a soma dos pontos das tarefas. d) Daily Meeting - Para acompanhar a execução das atividades da Sprint, é realizada diariamente a Daily Meeting, uma reunião de duração máxima de 15 minutos onde cada integrante da equipe deve apontar o que foi feito no dia anterior, qual o

5 5 planejamento para o dia e também se existe algum impedimento para realização da tarefa que está em execução. Deste modo, é possível garantir os prazos e também visualizar com antecedência futuros problemas, bem como definir planos de ação para contorná-los. e) Papéis - A metodologia Scrum propõe basicamente três papéis: Scrum Master responsável por conduzir as reuniões diárias (Daily Meetings) e resolver os eventuais impedimentos durante a execução das Sprints. Product Owner representa o cliente dentro da equipe e é responsável por garantir que os itens entregues a cada Sprint, estejam de acordo com aqueles definidos no Product Backlog, com qualidade aceitável. Team analistas, desenvolvedores e testadores que trabalham na execução das tarefas do Backlog. f) Burndown - O burndown é um gráfico utilizado para acompanhar o andamento da execução da Sprint. Diariamente o gráfico é atualizado de forma a representar os itens finalizados em comparação aos itens planejados para a atual Sprint. Para tanto é elaborado um gráfico de linha, com um eixo representando a pontuação e outro o tempo de duração da Sprint. O objetivo é fazer com que a linha de pontuação chegue à zero antes ou até o último dia de execução da Sprint. A figura 2 ilustra um gráfico de burndown para acompanhamento da execução das tarefas de uma Sprint. No exemplo da figura, a Sprint tem o tamanho de 70 pontos e deve ser executada em 15 dias. Figura 2 - Exemplo de gráfico burndown. [6] Fonte: Kniberg e Skarin, 2010.

6 6 g) Restrospectiva - Ao final de cada Sprint é realizada a reunião de retrospectiva, conduzida pelo Scrum Master, com o objetivo de identificar pontos positivos e negativos da Sprint. Cada integrante da equipe deve apontar pontos positivos, pontos negativos e também o que deveria ser feito de concreto já para a próxima Sprint. A retrospectiva é uma prática que contribui para a melhoria contínua da metodologia de desenvolvimento da equipe. A figura 3 ilustra o esquema da metodologia Scrum, apontando as iterações e incrementos necessários para a conclusão das Sprints e, conseqüentemente, do projeto como um todo. Figura 3 - Esquema da metodologia Scrum. Fonte: Mountain Goat, APLICAÇÃO DO SCRUM EM EQUIPES DISTRIBUÍDAS O Scrum, assim como as demais metodologias ágeis, prega a interação entre equipes de desenvolvimento dispostas em um mesmo ambiente físico de trabalho, enfatizando a comunicação freqüente e presencial entre os membros do time. No entanto, a prática de distribuir os processos de desenvolvimento entre equipes dispersas geograficamente vem sendo cada vez mais adotada pelas empresas, visando redução de custos, flexibilidade para montagem de equipes, dentre outras vantagens [1]. a) Problemas - Quando a metodologia Scrum é utilizada para gerenciar e acompanhar projetos com equipes distribuídas, algumas dificuldades se tornam evidentes. Abaixo são apresentados alguns dos principais problemas identificados na aplicação do Scrum em equipes dispostas em diferentes ambientes físicos de trabalho [7]:

7 7 Comunicação entre o time a comunicação frequente entre os integrantes da equipe é uma das premissas para o sucesso dos projetos que utilizam Scrum. No entanto, a distância física entre os integrantes dificulta a comunicação e o alinhamento de ideias entre a equipe; acompanhamento do projeto com a distância entre os integrantes da equipe, é inviável manter um quadro de tarefas ou mesmo um gráfico burndown em um único local físico, visto que as informações do projeto estão sempre evoluindo e um integrante pode não ter como saber o status atual do projeto; atualização de tarefas não é viável para um integrante atualizar o andamento de sua tarefa em um local em que toda a equipe visualize de imediato a evolução da tarefa em questão, devido a dispersão geográfica dos integrantes da equipe; resolução de impedimentos dada a dificuldade de se identificar o status atual do projeto, torna-se complicado identificar possíveis impedimentos. Com isso, a resolução destes impedimentos fica praticamente inviável, ocasionando problemas na evolução do projeto e colocando em risco o sucesso do mesmo, visto que uma das principais características do Scrum é a possibilidade de identificar futuros problemas e resolvê-los de forma antecipada. b) Soluções - Com base nos problemas identificados, formam levantadas algumas técnicas que podem ser aplicadas para viabilizar a utilização do Scrum em projetos desenvolvidos por equipes distribuídas: Armazenamento centralizado utilizando um local único para armazenar os dados do projeto, é possível centralizar o acesso às informações, possibilitando que todos os integrantes da equipe visualizem o status do projeto, além de permitir a atualização das tarefas por parte de cada um dos integrantes; controle de concorrência o armazenamento centralizado das informações, com acesso paralelo realizado pelos participantes, requer um controle de concorrência para evitar, por exemplo, que mais de um integrante realize atualizações em uma mesma informação e ao mesmo tempo. Este controle é necessário para manter a integridade dos dados e a confiabilidade das informações; acesso móvel com a evidente expansão da utilização de dispositivos móveis, uma alternativa interessante para realizar consultas e atualizações de informações é o acesso móvel. Com isso, os integrantes da equipe podem

8 8 verificar o andamento do projeto e também atualizar suas tarefas através de dispositivos móveis; ferramenta de apoio para aplicar as soluções identificadas para utilização do Scrum em equipes distribuídas, pode ser utilizada uma ferramenta de apoio, com foco no Scrum e que permita armazenamento e acesso a informações em um local centralizado e também disponibilize acesso móvel a estas informações. 5 TRABALHOS RELACIONADOS Existem algumas ferramentas desenvolvidas no intuito de viabilizar a aplicação do Scrum para o gerenciamento e acompanhamento de projetos de software. A seguir, uma breve descrição das características de algumas destas ferramentas: a) FireScrum é uma ferramenta para apoio ao planejamento e gerenciamento de projetos utilizando Scrum, com foco em equipes geograficamente distribuídas. A idéia do FireScrum surgiu através de um trabalho de dissertação de mestrado, motivado pela falta de suporte na aplicação do Scrum para equipes distribuídas em outras ferramentas similares [8]. Contudo, o FireScrum não disponibiliza uma aplicação móvel, para que os usuários consigam acesso as suas funcionalidades através de dispositivos móveis; b) ScrumWorks ferramenta focada nas características da metodologia Scrum para auxiliar no planejamento e acompanhamento de projetos. Armazena informações de forma centralizada e permite o acompanhamento de projetos executados por equipes distribuídas [9]. Porém, não disponibiliza um aplicativo móvel para que as informações do projeto possam ser acessadas fora das estações de trabalho convencionais; c) KanbanBoard aplicativo móvel que representa um quadro de tarefas baseado na metodologia Scrum. No entanto, suas raias para movimentação de tarefas são fixas e as informações não são armazenadas de maneira centralizada, possibilitando o acesso apenas no dispositivo em que a instância do aplicativo foi instalada; d) Trello Ferramenta colaborativa para auxiliar o gerenciamento de projetos baseada no uso do quadro de tarefas. Esta ferramenta armazena informações de maneira centralizada e também disponibiliza uma aplicação móvel para que os usuários tenham sempre acesso ao andamento dos projetos [10]. No entanto, o Trello, apesar

9 9 de utilizar o quadro de tarefas, não é necessariamente focado na metodologia Scrum, já que não provê suporte aos demais itens presentes na metodologia, como o gráfico de burndown e as reuniões diárias de acompanhamento do projeto. Os trabalhos e ferramentas pesquisados abordam a aplicação da metodologia Scrum, ou pelo menos algumas de suas características, seja em equipes de desenvolvimento distribuídas geograficamente ou não. Porém, nem todas as ferramentas pesquisadas permitem que os integrantes das equipes acompanhem o andamento dos projetos através de dispositivos móveis, proporcionando sempre a visibilidade do status atual dos projetos, mesmo que o membro do time não esteja em um local físico de trabalho, como por exemplo, em uma viagem de trabalho ou até mesmo em casa. Além disso, as ferramentas pesquisadas que permitem este acompanhamento em tempo real, fazendo uso de informações centralizadas, não abordam todos os pontos e características da metodologia Scrum. 6 SCRUMMOBILE Como relatado nas seções anteriores, a aplicação da metodologia Scrum em equipes de desenvolvimento geograficamente distribuídas não é uma tarefa trivial. Porém, algumas técnicas podem ser aplicadas, com o apoio de uma ferramenta, para auxiliar no acompanhamento e gerenciamento de projetos utilizando Scrum em equipes distribuídas. Conforme citado na seção V, de trabalhos relacionados, existem algumas ferramentas para apoio à utilização do Scrum. No entanto, há ainda certa carência no que diz respeito a ferramentas para auxiliar na aplicação da metodologia em um ambiente de desenvolvimento distribuído. Para a aplicação das técnicas levantadas, com o intuito de facilitar o uso do Scrum, foi desenvolvido o ScrumMobile, um modelo baseado em um conjunto de componentes para dar suporte ao uso do Scrum mesmo em equipes dispersas. 6.1 Arquitetura de Componentes A arquitetura do ScrumMobile é composta de seis componentes básicos, com responsabilidades bem definidas e que juntos compõem o modelo proposto. A seguir, serão detalhados cada um dos componentes básicos que formam arquitetura do ScrumMobile, bem como suas funcionalidades.

10 10 A figura 4 ilustra os componentes da arquitetura, bem como a relação entre os componentes utilizados no desenvolvimento do ScrumMobile para atender a proposta deste trabalho. Figura 4 - Diagrama de componentes do modelo ScrumMobile. Fonte: Autoria própria, A relação entre os componentes do ScrumMobile, se dá da seguinte maneira: o componente de consumo, utilizado pelas aplicações que compõem o componente de aplicação, aciona o componente de acesso a dados. O componente de acesso a dados realiza as operações nas informações que estão armazenadas no componente de armazenamento e, caso a operação seja uma atualização, o componente de acesso a dados aciona o componente de concorrência, para garantir que a mesma informação não será manipulada ao mesmo tempo por mais de um usuário. Neste ponto, o componente de acesso a dados retorna a execução para o componente de consumo, que disponibiliza a informação para a aplicação que está consumindo o modelo. Com estes componentes, foi elaborado um modelo onde é possível planejar e acompanhar projetos de software utilizando a metodologia Scrum, armazenando suas informações em um único local centralizado, podendo acessá-las a qualquer momento, e utilizando qualquer aplicação que faça uso dos componentes de acesso a dados, controle de concorrência e consumo, independentemente da plataforma destas aplicações e ainda garantindo a integridade das informações, mesmo que vários usuários estiverem manipulando as mesmas informações.

11 11 Um maior detalhamento sobre cada um dos componentes que compõem o modelo será apresentado a seguir: a) Componente de Armazenamento - O ScrumMobile conta com um armazenamento de informações utilizando o conceito de nuvem, ou seja, os dados são mantidos em uma base de dados centralizada, possibilitando acesso a qualquer hora, de qualquer lugar e por qualquer aplicação que esteja preparada para acessar este componente. Deste modo, tanto consultas aos dados de projetos, quanto atualizações de tarefas, são endereçados sempre para a mesma base, ou seja, estas informações estarão todas concentradas em um único local. b) Componente de Acesso a Dados - Este componente é responsável por gerenciar o acesso às informações. Esta camada do modelo disponibiliza funcionalidades necessárias para realizar consultas e atualizações nas informações que estão armazenadas no componente de armazenamento. Os componentes de armazenamento e de acesso estão separados no modelo do ScrumMobile, pois cada um destes componentes apresenta responsabilidades diferentes e bem definidas. No primeiro, é realizado apenas o armazenamento da informação. No segundo, são realizadas consultas e atualizações nestas informações. c) Componente de Controle de Concorrência - Um dos principais problemas que deve ser tratado em aplicações distribuídas é o controle de concorrência. Para tanto, o ScrumMobile possui um componente que realiza o controle de concorrência, permitindo que apenas um usuário por vez atualize as mesmas informações. Como a ideia central do modelo do ScrumMobile, é a utilização por equipes distribuídas, é muito comum que os integrantes das equipes realizem operações paralelas sobre as mesmas informações. Por exemplo, pode ocorrer a situação em que dois integrantes da equipe de um projeto estejam tentando atualizar a mesma tarefa, ao mesmo tempo. Neste caso o modelo tem de garantir que apenas uma alteração seja realizada. Por isso, este componente é muito importante para o correto funcionamento do modelo e para a integridade das informações geridas pelo mesmo. d) Componente de Consumo - Trata-se de uma Application Programming Interface (API) contendo funcionalidades voltadas para auxiliar na aplicação do Scrum em equipes de desenvolvimento geograficamente distribuídas. Esta interface pode ser utilizada por qualquer aplicação para utilizar o modelo do ScrumMobile,

12 12 independentemente de sua plataforma, ou seja, podendo ser uma aplicação web, desktop ou, até mesmo, móvel. Este componente utiliza o componente de acesso a dados para manipular os dados armazenados de forma centralizada no componente de armazenamento. Aqui, fica toda a parte de lógica de negócios desenvolvida para disponibilizar as funcionalidades necessárias para a utilização do Scrum. Abaixo são listadas as funcionalidades disponibilizadas pelo componente de consumo do ScrumMobile: Realizar o cadastro de usuários, permitindo a consulta, alteração e exclusão; realizar o cadastro de equipes, permitindo a consulta, alteração e exclusão; realizar o cadastro de projetos, permitindo a consulta, alteração e exclusão; realizar o cadastro de sprints, permitindo a consulta, alteração e exclusão; realizar o cadastro de tarefas, permitindo a consulta alteração e exclusão; listar projetos de acordo com o usuário autenticado no sistema; visualizar o quadro de tarefas das Sprints de um projeto previamente selecionado; o quadro de tarefas deve ser dinâmico, podendo variar sua estrutura de raias conforme o projeto ou Sprint; permitir a movimentação das tarefas pelo quadro de tarefas, indicando em qual raia a tarefa deverá ser posicionada; o usuário deve poder atualizar o responsável pelas tarefas; o usuário deve poder participar de vários projetos simultaneamente; as informações devem ser armazenadas em uma base de dados centralizada; não deve ser permitido que mais de um usuário altere a mesma informação ao mesmo tempo; uma informação pode ser consultada por mais de um usuário ao mesmo tempo. possibilitar a geração de gráficos de burndown por Sprint; possibilitar a realização de reuniões de acompanhamento dos projetos por vídeo conferência com a equipe do projeto em questão. Possibilitar a realização de reuniões de retrospectiva dos projetos por vídeo conferência com a equipe do projeto em questão. Na prática, a aplicação que consumir o ScrumMobile, deve fazer a chamada para a funcionalidade desejada da camada de consumo, passando as informações necessárias. A camada de consumo realiza o processamento e devolve o resultado para aplicação. Por

13 13 exemplo, para a visualização de um quadro de tarefas de uma Sprint, a aplicação faz a chamada para a funcionalidade responsável por montar a visualização do quadro de tarefas, informando a Sprint desejada. A camada de consumo processa as informações da Sprint informada e, fazendo uso do componente de acesso a dados, recupera informações da Sprint necessárias para a elaboração do quadro de tarefas e, por fim, devolve o quadro de tarefas para a aplicação que fez a chamada. e) Componente de Autenticação e Autorização - Este componente é composto de um conjunto de funcionalidades dispostas na API de funcionalidades do componente de consumo. Entretanto, as funcionalidades que compõem o componente de autenticação e autorização, foram desenvolvidas especificamente para garantir a parte de segurança do modelo. Deste modo, é possível separar estas funcionalidades, das demais da API, caracterizando um componente específico, de modo a manter a divisão de responsabilidades de cada um dos componentes do modelo. O componente de autenticação e autorização disponibiliza funcionalidades de autenticação através de credenciais informadas pelo usuário. Depois de autenticado, o usuário tem acesso somente às informações dos projetos em que o mesmo participa. Estas permissões são garantidas pelas funcionalidades de autorização do componente. As funcionalidades relativas ao componente de autenticação e autorização são listadas a seguir: Autenticar o usuário no sistema, através de suas credenciais de acesso; O usuário autenticado deve acessar somente as informações referentes aos projetos em que o mesmo participa; f) Componente de Aplicação - Este componente representa as aplicações desenvolvidas para consumir o modelo do ScrumMobile. Como o modelo do ScrumMobile não está vinculado a uma tecnologia específica, estas aplicações podem ser desenvolvidas em qualquer plataforma, desde que sejam preparadas para consumir o as funcionalidades disponibilizadas pelo modelo proposto. Com isso, este componente pode ser composto de aplicações web, desktop ou, até mesmo, móveis. Deste modo, as aplicações que fazem uso do ScrumMobile, podem usufruir de uma série de funcionalidades voltadas para a aplicação do Scrum. Abaixo, são listadas algumas destas funcionalidades: Criar e manter usuários, equipes, projetos, sprints e tarefas;

14 14 Visualizar o quadro de tarefas de uma determinada sprint; Realizar a movimentação de tarefas no quadro de tarefas; Gerar gráficos de burndown; Realizar reuniões de acompanhamento e de retrospectiva. Estas são apenas algumas das funcionalidades que podem ser utilizadas fazendo uso do modelo ScrumMobile. O modelo pode ser estendido para atender outras funcionalidades que se façam necessárias para atender requisitos específicos de cada uma das aplicações da camada de aplicação. Para tanto, é preciso adicionar as funcionalidades necessárias na camada de consumo do ScrumMobile, para que as aplicações possam utilizá-las de modo a atender estes requisitos específicos. 6.2 Comparativo Para realizar um comparativo entre o modelo proposto e os trabalhos relacionados, foram selecionados alguns critérios levando em conta a aplicação da metodologia Scrum em equipes distribuídas. A tabela 1 ilustra as características das ferramentas pesquisadas na seção V, de trabalhos relacionados, fazendo um comparativo com o modelo ScrumMobile, considerando fatores levantados para auxiliar na solução do problema da pesquisa. Quadro 1 - Comparativo entre as ferramentas pesquisadas e o modelo proposto. Foco no Scrum Acesso Móvel Dados em nuvem ScrumMobile X X X FireScrum X X ScrumWorks X X KanbanBoard X Trello X X Fonte: Autoria Própria, 2014 Com base neste comparativo, pode-se perceber as vantagens na utilização do ScrumMobile, para auxiliar na utilização do Scrum em equipes distribuídas, possibilitando armazenamento de informações em nuvem, que possam ser acessadas de uma aplicação móvel, e que disponibilize itens presentes na metodologia Scrum, como o quadro de tarefas,

15 15 visualização do gráfico burndown e suporte a reuniões, utilizando ferramentas de vídeo conferência. 7 PROTÓTIPO Para validar o modelo proposto, foi desenvolvido um protótipo, com o objetivo de colocar em prática algumas das funcionalidades previstas pelo modelo ScrumMobile para auxiliar no planejamento e acompanhamento de projetos de software desenvolvidos por equipes geograficamente distribuídas. O protótipo desenvolvido foi utilizado para realizar alguns experimentos e avaliações do modelo. 7.1 Desenvolvimento O desenvolvimento do protótipo se nas seguintes etapas: criação da base centralizada de dados, criação do pacote de entidades do projeto, desenvolvimento do módulo de acesso aos dados, desenvolvimento do controle de concorrência, desenvolvimento de uma API contendo algumas das funcionalidades dos componentes de consumo e de autenticação e autorização e, por fim, desenvolvimento de uma aplicação Android, que utiliza a API que representa o componente de consumo proposto no modelo. Para o armazenamento das informações em banco de dados foi utilizado o PostgreSQL, um sistema de gerenciamento de banco de dados desenvolvido pelo departamento de Ciência da Computação da Universidade da Califórnia, que suporta uma grande parte do padrão SQL [11]. Para auxiliar no manuseio das informações armazenadas, foi utilizada a ferramenta pgadmin, que trata-se de um software gráfico para administração do PostgreSQL [12]. O pacote de entidades, que representa a camada com as classes de modelo do protótipo, foi criado como um projeto Java, baseado em um módulo Apache Maven, uma ferramenta de código livre que serve para gerenciar, construir e empacotar projetos [13]. Este projeto Java é empacotado em um Java Archive (JAR), que é um arquivo compactado utilizado para distribuir um conjunto de classes Java, possibilitando que outros projetos possam utilizar este módulo, adicionando o arquivo gerado ao projeto que deseja utilizar o pacote de entidades. O módulo de acesso a dados é uma aplicação Java Web que roda no Apache Tomcat, um servidor de aplicações que serve para interpretar aplicações escritas em Java para Web [14]. Este módulo contém métodos de acesso aos dados da base centralizada, utilizando o Hibernate, que é a implementação da JBoss para a especificação Java Persistence API (JPA),

16 16 e serve para realizar o mapeamento objeto-relacional (ORM), ou seja, representa as tabelas de um banco de dados através de classes Java e realiza operações de persistência [15]. Os métodos do módulo de acesso a dados são disponibilizados através de serviços baseados em RESTfull, um simples webservice que utiliza métodos HTTP para a troca de mensagens entre aplicações [16]. Com isso, qualquer aplicação pode consumir os métodos disponíveis, acessando os serviços que compõem o componente de acesso a dados. Durante o acesso as informações, utilizando o módulo de acesso a dados, outro componente é acionado para realizar o controle de concorrência. Para tanto, foi utilizado o versionamento automático do Hibernate. Trata-se de um atributo mapeado que é incrementado automaticamente a cada atualização realizada em determinado objeto. Com este atributo, o Hibernate realiza o controle de concorrência otimista, ou seja, permite que um mesmo objeto persistente seja utilizado para consulta em duas sessões diferentes, porém, se ocorrer alguma modificação concorrente no objeto, será lançada uma exceção, indicando que o mesmo objeto já está sendo atualizado por outra sessão. Neste caso, fica a cargo da aplicação tratar a exceção, indicando ao usuário que o registro já está em uso. Este controle de concorrência é interessante, pois pode também ser utilizado em um ambiente de larga escala, com várias instâncias da aplicação rodando em paralelo, visto que o controle é realizado pelo Hibernate com base no valor de uma coluna de uma tabela do banco de dados. No protótipo do ScrumMobile, o controle de concorrência é realizado a nível de movimentação de cada tarefa, afim de impedir que um usuário efetue várias movimentações e, ao fim do procedimento, não consiga persistir as informações, caso alguma das tarefas movimentadas também esteja sendo manipula por um outro usuário paralelamente. Por fim, para representar no protótipo o componente de consumo, foi desenvolvida uma API composta de métodos baseados em RESTfull utilizados para acessar o módulo de acesso a dados. Esta API é utilizada por uma aplicação móvel, baseada em Android, que é uma plataforma para dispositivos móveis desenvolvida pela Open Handset Alliance, liderada pela Google. Esta aplicação utiliza o pacote de entidades e também o módulo de acesso a dados e o componente de controle de concorrência por meio da API com os métodos de consumo. A figura 5 ilustra a arquitetura utilizada para o desenvolvimento do protótipo, baseado no modelo proposto, separando suas camadas e também demonstrando o grau de relacionamento entre elas.

17 17 Figura 5 - Arquitetura utilizada para desenvolver o protótipo Fonte: Autoria própria, Funcionalidades do Protótipo Algumas funcionalidades do modelo do ScrumMobile foram elencadas para o desenvolvimento de um protótipo baseado no modelo ScrumMobile. Abaixo, são listadas as funcionalidades desenvolvidas no protótipo: Autenticar o usuário no sistema, através de suas credenciais de acesso; listar projetos de acordo com o usuário autenticado no sistema; visualizar o quadro de tarefas das Sprints de um projeto previamente selecionado; o quadro de tarefas deve ser dinâmico, podendo variar conforme o projeto ou Sprint; permitir a movimentação das tarefas pelo quadro de tarefas, indicando em qual raia a tarefa deverá ser posicionada; o usuário deve poder atualizar o responsável pelas tarefas; o usuário deve poder participar de múltiplos projetos; as informações devem ser armazenadas em uma base de dados centralizada; não deve ser permitido que mais de um usuário altere a mesma informação ao mesmo tempo;

18 18 uma informação pode ser consultada por mais de um usuário ao mesmo tempo. Para atender aos requisitos listados, foram elaborados casos de uso que especificam em detalhes e agrupam os requisitos do modelo. A figura 6 representa o diagrama de casos de uso elaborado para o desenvolvimento das funcionalidades especificadas para o protótipo, baseado no modelo proposto. Figura 6 - Diagrama de Casos de Uso do protótipo Fonte: Autoria própria, 2014 Com base nas funcionalidades levantadas para o protótipo, foi desenvolvida uma aplicação móvel, baseada na plataforma Android, que realiza o consumo dos componentes de acesso a dados e controle de concorrência propostos no modelo. A figura 7 mostra a tela da aplicação que representa o quadro de tarefas de uma Sprint em andamento. É possível visualizar as tarefas em suas respectivas raias. Cada raia representa o atual status em que a tarefa se encontra. Cada tarefa é representada por um Post-it, contendo o nome da tarefa, a pontuação e o responsável atual, se houver. O quadro de tarefas é dinâmico. Nele pode-se adicionar, alterar ou remover as raias durante o andamento da Sprint. Além disso, as informações relativas ao andamento das tarefas, como a data de início e fim, são armazenadas na base centralizada, possibilitando que seja desenvolvido um gráfico de burndown, com base nestas informações. O acesso ao quadro de tarefas é limitado aos usuários que integram a equipe responsável pelo projeto no qual o quadro de tarefas está associado. Este controle de acesso é feito através de autenticação com login e senha. No momento da autenticação, são carregados os projetos em que o usuário autenticado participa.

19 19 Figura 7 - Tela com o quadro de tarefas, conforme projeto selecionado Fonte: Autoria própria, 2014 A figura 8 apresenta a tela para movimentação de tarefas. Nesta tela é possível movimentar uma tarefa pelo quadro de tarefas, indicando quem passa a ser o responsável pela tarefa e para qual raia do quadro a tarefa deve ser posicionada. Caso a tarefa esteja concluída, deve ser movida para a raia que indica o status de tarefa finalizada e o sistema armazena a data em que a tarefa foi concluída. Quando todas as tarefas da Sprint forem movidas para a raia que representa as tarefas finalizadas, então a Sprint está concluída. Neste ponto pode ser criada uma nova Sprint, com um novo quadro de tarefas e assim por diante, até que o projeto seja concluído. Figura 8 - Tela para atualização de tarefas Fonte: Autoria própria, 2014 Ao fim do projeto, todas as informações do mesmo estarão armazenadas na base centralizada. Deste modo, é possível desenvolver funcionalidades como geração de relatórios de histórico do andamento dos projetos e visualização de gráficos burndonw das Sprints.

20 20 8 EXPERIMENTOS E RESULTADOS Nesta seção serão apresentados os procedimentos utilizados na coleta de informações e avaliação do modelo ScrumMobile, bem como a análise dos resultados obtidos. Além disso, será feita a demonstração do controle de concorrência desenvolvido no protótipo, baseado no componente de controle de concorrência do ScrumMobile. 8.1 Método de Avaliação Para a avaliação deste trabalho, foi selecionado o método qualitativo, por tratar-se de uma abordagem que enfatiza a análise de entrevistados, de modo a compreender a experiência destes em relação ao uso do protótipo, baseado no modelo do ScrumMobile [17]. O objetivo da realização das entrevistas é buscar identificar se o modelo proposto atende os objetivos da pesquisa para a utilização da metodologia Scrum em equipes de desenvolvimento distribuídas, através do protótipo desenvolvido, além de buscar sugestões de melhoria e trabalhos futuros a serem desenvolvidos junto ao modelo. 8.2 Coleta de Informações Para avaliar o modelo proposto, foram realizadas entrevistas com profissionais da área de tecnologia da informação. Os entrevistados foram submetidos a um questionário após uma breve apresentação onde foram demonstradas as funcionalidades do protótipo desenvolvido bem como as características e objetivos do modelo proposto. A coleta de informações se deu através das seguintes etapas: 1. Apresentação do problema da pesquisa ao entrevistado; 2. Apresentação do modelo ScrumMobile ao entrevistado; 3. Apresentação do protótipo desenvolvido com base no modelo proposto ao entrevistado; 4. Entrevistado é conduzido a operar o protótipo, de modo a se familiarizar com suas funcionalidades; 5. Entrevistado é convidado a responder as perguntas do questionário, listadas no Apêndice A.

21 Análise dos resultados A avaliação foi aplicada em 10 pessoas que atuam na área de tecnologia da informação. Todos os entrevistados foram apresentados ao protótipo do ScrumMobile operaram o aplicativo e responderam ao questionário. A tabela 2 apresenta os resultados da aplicação do questionário nos 10 entrevistados, quantificando as respostas das perguntas apresentadas no questionário no Apêndice A e listadas a seguir, onde a resposta deveria ser obrigatoriamente Sim ou Não. 1. Você acredita que o uso de metodologias ágeis pode ajudar de forma significativa no gerenciamento de projetos de software? 2. Você acredita que o uso de equipe de desenvolvimento geograficamente distribuída possa representar ganho de produtividade e redução nos custos de um projeto? 3. Você considera que existe uma carência de ferramentas para auxiliar a aplicação de metodologias ágeis em projetos de software desenvolvidos por equipes geograficamente distribuídas? 4. Você acredita que o ScrumMobile pode auxiliar na aplicação da metodologia Scrum para o planejamento e acompanhamento de projetos de software desenvolvidos por equipes geograficamente distribuídas? Justifique sua resposta. 5. Qual melhoria em relação ao modelo ScrumMobile você poderia sugerir, no sentido de auxiliar na aplicação do Scrum em equipes de desenvolvimento geograficamente distribuídas ou ainda no sentido de melhorar a usabilidade do modelo? Tabela 1 - Resultados da aplicação do questionário Sim Não Pergunta 1 90% 10% Pergunta 2 70% 30% Pergunta 3 100% 0% Pergunta 4 100% 0% Fonte: Autoria própria, 2014 Como pode ser visto na tabela 2, todos os entrevistados afirmaram que Sim, é possível utilizar o ScrumMobile para auxiliar no gerenciamento e acompanhamento de projetos de

22 22 software desenvolvidos por equipes geograficamente distribuídas, mostrando a aprovação dos 10 entrevistados em relação ao modelo proposto e evidenciando que o modelo pode ser tomado como solução para o problema da pesquisa. Como a avaliação utilizada foi o método qualitativo, foi possível que cada um dos entrevistados justificasse por qual razão consideraram que o ScrumMobile pode ser utilizado na aplicação do Scrum em projetos de software desenvolvidos por equipes geograficamente distribuídas. Abaixo são listadas as justificativas mais relevantes, colhidas durante o processo de avaliação com os entrevistados: Realmente as metodologias ágeis tem sido cada vez mais utilizadas para o gerenciamento de projetos de software. No entanto, de fato, existe ainda pouco suporte para sua aplicação em equipes distribuídas. Com o ScrumMobile, abre-se a possibilidade de acompanhar a evolução de projetos desenvolvidos de maneira distribuída. (Analista de Sistemas). O modelo permite a aplicação do Scrum distribuído disponibilizando funcionalidades que realmente são necessárias para o sucesso dos projetos geridos pela metodologia. Além disso, é adaptável à necessidade de diferentes equipes, visto que conta com um modelo dinâmico de quadro de tarefas. (Analista de Sistemas). A solução proposta atinge um nicho realmente carente em relação à evolução das metodologias ágeis. O fato de poder visualizar o andamento de um projeto mesmo fora de seu local de trabalho facilita muito o gerenciamento, principalmente nos casos onde o gestor coordenar vários projetos em paralelo, situação muito comum na área de desenvolvimento de software. (Gerente de Projetos). O fato de o modelo poder ser utilizado em qualquer plataforma, garante uma flexibilidade interessante para acompanhar os projetos fora de uma estação fixa de trabalho. Além disso, o controle de concorrência desenvolvido permite que se mantenha a integridade das informações dos projetos, mesmo que em ambientes distribuídos e, conseqüentemente, com alto grau de paralelismo. (Arquiteto de Software). Os entrevistados, quando abordados no sentido de indicarem melhorias para o ScrumMobile, contribuíram com uma série de sugestões. A seguir, são listadas as principais sugestões de melhorias coletadas durante a aplicação do processo de avaliação com os entrevistados: possibilitar uma forma de marcar uma tarefa como pré-requisito de outra, ou seja, para que se inicie a execução de uma tarefa, é necessário que outra esteja pronta; criar uma funcionalidade para que seja possível a troca de mensagens entre os membros de uma equipe, de modo a facilitar a comunicação, principalmente entre

23 23 aqueles que estão executando tarefas que dependam entre si, ou seja, que dependam umas das outras; criar uma funcionalidade para indicar que uma tarefa está impedida de ser executada, indicando o motivo. seria interessante aplicar alguma forma de destacar esta tarefa no quadro de tarefas, como, por exemplo, alterando a cor da mesma, e com a possibilidade de visualizar o motivo e o andamento da resolução do impedimento; possibilitar a geração de relatórios gerenciais, permitindo a visualização de métricas entre projetos, com o objetivo de produzir dados para planejamento de futuros projetos; criar um módulo de configuração do quadro de tarefas, possibilitando que cada equipe defina o padrão de pontuação das tarefas, cor de tarefas e raias, dentre outras configurações que possam ser mantidas dentro de cada equipe ou projeto. Como foi possível identificar no processo de avaliação, o ScrumMobile foi bem aceito entre os entrevistados da área de tecnologia da informação. Deste modo, é viável afirmar que o modelo realmente contribui para a solução do problema identificado neste trabalho, que remete a aplicação da metodologia Scrum em ambientes de desenvolvimento geograficamente distribuídos. 8.4 Testes de Concorrência O componente de controle de concorrência do ScrumMobile é utilizado para garantir que as tarefas não sejam alteradas por mais de um usuário ao mesmo tempo, com base na no recurso de lock otimista do hibernate. Por exemplo, quando uma tarefa é incluída no sistema, ela tem sua versão inicializada com o valor zero. Sempre que ocorre uma atualização na tarefa o valor da versão é incrementado e armazendo. Deste modo se o usuário recuperar uma tarefa para atualizar que esteja com o valor de versão igual a 2 e, antes de submeter a alteração, algum outro usuário alterar a mesma tarefa, ela passará a ter o valor de versão igual a 3. No momento da atualização, o Hibernate verifica que a versão que está sendo submetida é diferente da versão atual do banco de dados e lança um erro indicando que a tarefa já foi alterada por outro usuário. Para simular uma situação de concorrência na alteração de tarefas foi utilizado o RESTClient, um plugin do navegador Firefox que permite o acesso à métodos RESTFull. Deste modo foi possível simular a alteração de uma tarefa via navegador, acessando o método

24 24 da API de consumo responsável por atualizar tarefas. A tarefa a ser alterada foi informada utilizando o formato JavaScript Object Notation (JSON). A simulação foi realizada da seguinte maneira: Na aplicação móvel foi selecionada uma tarefa qualquer para atualização no quadro de tarefas. Em seguida, a mesma tarefa foi recuperada via RESTClient, onde é possível visualizar a versão da tarefa, conforme mostra a figura 9. Figura 9 - Recuperação da tarefa via RESTClient. Fonte: Autoria própria, Depois disso, a tarefa foi atualizada utilizando novamente o RESTClient. Foi alterado o nome da tarefa e, com isso, o mecanismo de controle de concorrência automaticamente incrementa a versão da tarefa atualizada, como pode ser visto na figura 10, que ilustra uma nova consulta na tarefa, após a atualização.

25 25 Figura 10 - Recuperação da tarefa já atualizada via RESTClient. Fonte: Autoria própria, 2014 Por fim, utilizando agora a aplicação móvel, foi feita a tentativa de atualização da tarefa. No entanto, o controle de concorrência verifica que a tarefa recuperada possui valor de versão igual a zero e no banco de dados, a mesma já foi incrementada para 1 durante a operação de atualização realizada com o RESTClient. Deste modo é lançado um erro tratado pela aplicação móvel para indicar que a tarefa foi alterada paralelamente, conforme ilustrado na figura 11. Figura 11 - Componente de concorrência detecta alteração paralela. Fonte: Autoria própria, CONSIDERAÇÕES FINAIS Com o crescimento da utilização de metodologias ágeis para o planejamento e acompanhamento de projetos de software e também considerando a tendência no uso de