Embed Size (px)
Citation preview
1
UMA FERRAMENTA PARA GERENCIAMENTO SCRUM EM AMBIENTE S DE
DESENVOLVIMENTO GEOGRAFICAMENTE DISTRIBUÍDOS
Alex Radavelli1
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. E-mail [email protected].
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 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
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, 2014.
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
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
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, 2014.
4 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
− 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
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
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
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, 2014.
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
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
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
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
− 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
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
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
Figura 5 - Arquitetura utilizada para desenvolver o protótipo
Fonte: Autoria própria, 2014
7.2 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
− 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
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
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
8.3 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
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
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
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, 2014.
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
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, 2014
10 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
26
equipes de desenvolvimento distribuídas, nota-se uma carência tecnológica para oferecer
suporte na aplicação de métodos ágeis em equipes geograficamente distribuídas. Neste
sentido, foi desenvolvido o modelo ScrumMobile, com o objetivo de solucionar os problemas
identificados nesta pesquisa, ou seja, de viabilizar a aplicação da metodologia ágil Scrum,
para o acompanhamento de projetos em equipes de desenvolvimento geograficamente
distribuídas.
Conforme observado na avaliação, o modelo proposto alcançou o objetivo da pesquisa,
visto que os profissionais da área de desenvolvimento de software consideraram que o
ScrumMobile possibilita e ajuda a aplicação do Scrum em equipes dispersas, facilitando a
comunicação entre os membros da equipe, possibilitando o acompanhamento do projeto de
qualquer lugar e por qualquer aplicação que esteja preparada para consumir os recursos do
modelo. Ainda neste sentido, o modelo permite que os usuários visualizem gráficos de
burndown, realizem reuniões de acompanhamento e de retrospectiva, acompanhem o quadro
de tarefas de cada Sprint planejada para o projeto e também que os usuários atualizem suas
respectivas tarefas dentro do quadro de tarefas em questão. Com isso, as principais
funcionalidades para a aplicação da metodologia Scrum, são disponibilizadas pelo modelo
para a utilização em ambientes de desenvolvimento distribuídos.
Como sugestão de futuras melhorias, considerando a avaliação aplicada, é possível
desenvolver algumas funcionalidades com intuito de melhorar o modelo proposto, como a
criação de relatórios gerenciais que possibilitem o fornecimento de informações que possam
ser utilizadas para o planejamento de futuros projetos, criação de funcionalidades para
trabalhar o impedimento de tarefas e também a visualização das tarefas que se encontrarem
em impedimento e também desenvolver um esquema de comunicação entre os componentes
da equipe que estejam executando tarefas dentro de um mesmo contexto, como por exemplo,
no caso de um integrante do time ter realizado a análise de um caso de uso e outro integrante
for realizar o desenvolvimento deste caso de uso. Neste caso seria interessante que os dois
pudessem se comunicar a qualquer momento pela ferramenta, podendo também gerar algum
tipo de histórico das conversas para posteriores consultas.
ABSTRACT
This paper presents a tool to assist in managing projects using the Scrum agile methodology
applied in geographically distributed development teams, storing your data in the cloud, using
a centralized database. With this, you can plan and track projects using mobile devices,
27
allowing the team to always be with visibility into the current status of projects, regardless of
the geographical location of its members.
Testing and analysis of results were performed on a prototype developed on the model of
the proposed tool, as well as comparisons with similar research and tools, which prove the
effectiveness of the tool, as the monitoring of projects using Scrum in distributed teams.
REFERÊNCIAS
[1] THE STATE OF AGILE DEVELOPMENT. Annual Survey, U.SA, 3.ed., 2008, Alpharetta, GA. Disponível em: <http://www.versionone.com/pdf3rdAnnualStateOf Agile_FullDataReport.pdf>. Acesso em: 05 fev. 2014. [2] RISING, L.; JANOFF, N. S. The Scrum Software Development Process for Small Teams. IEEE Software,New York, v. 17, n. 4 jul-ago. 2000. [3] CARVALHO, B.V.; MELLO, C.H.P. Revisão, Análise e Classificação da Literatura sobre o Método de Desenvolvimento de Produtos Ágil Scrum. In: SIMPÓSIO DE ADMINISTRAÇÃO, LOGÍSTICA E OPERAÇÕES INTERNACIONAIS (SIMPOI), 12., 2009, São Paulo, SP. Anais ... São Paulo, SP, 2009. [4] KNIBERG, H. Scrum e XP direto das Trincheiras: Como nós fazemos Scrum, 2007. Disponível em: <http://www.infoq.com/br/minibooks/kanban-scrum-minibook>. Acesso em: 26 mar. 2014. [5] CARVALHO, C. E. C.; ABANTES, C. T.; CAMEIRA, R. F. Métodos Ágeis de Desenvolvimento de Software: Um Caso Prático de Aplicação do Scrum. In: ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO, 31., 2011, Belo Horizonte. Anais ..., Belo Horizonte, 2011. [6] KNIBERG, H; SKARIN, M. Kanban e Scrum: Obtendo o melhor de ambos, 2010. Disponível em: <http://www.infoq.com/br/minibooks/scrum-xp-from-thetrenches>. Acesso em: 06 mar. 2014. [7] OLIVEIRA, Eneida; LIMA, Rosangela. Estado da Arte Sobre o Uso do Scrum em Ambientes de Desenvolvimento Distribuído de Software. Revista de Sistemas e Computação, Salvador, v. 1, n. 2, p. 106 - 119, jul./dez. 2011. [8] CAVALCANTI, E.; MACIEL, T. M. M.; ALBUQUERQUE, J. Ferramenta Open-Source para Apoio ao Uso do Scrum por Equipes Distribuídas. In: WORKSHOP DE DESENVOLVIMENTO DISTRIBUÍDO DE SOFTWARE, 3., 2009, Fortaleza. 2009. p. 51 – 60. Disponível em: <http://www.ldb.dcc.ufmg. bdbcomp/servlet/Trabalho?id=7701>. Acesso em: 04 maio 2014. [9] SCRUMWORKS Pro. Disponível em : < http://www.collab.net/products/ scrumworks>. Acesso em: 05 mar. 2014.
28
[10] TRELLO. Disponível em: <http:// www.trello.com>. Acesso em: 05 mar. 2014. [11] POSTGRESQL [sistema de gerenciamento de banco de dados]. Disponível em: <http://pgdocptbr.sourceforge.net/pg80/. Acesso em: 10 maio 2014 [12] PGADMIN INTERNALS. Disponível em: <http://wiki.postgresql.org/wiki/>. Acesso em: 08 mar. 2014. [13] APACHE Maven. Disponível em: < http://maven.apache.org/>. Acesso em: 10 mar. 2014 [14] APACHE Tomcat. Disponível em: <https://tomcat.apache.org/>. Acesso em: 10 mar. 2014. [15] HIBERNTAE ORM. Disponíve em: <http://hibernate.org/orm/>. Acesso em: 10 mar. 2014. [16] RODRIGUEZ, A. RESTful Web Services: The Basics, 2008. Disponível em: <https://www.ibm.com/developerworks/webservices/library/ws-%20restful/>. Acesso em: 22 mar. 2014. [17] GOODE, William J. Métodos em pesquisa social. 3. ed. São Paulo: Ed. Nacional, 1969. [18] MOUNTAIN GOAT SOFTWARE. Topics in Scrum: Scrum Task Board. 2014. Disponível em: < http://www.mountaingoatsoftware.com/agile/scrum/task-boards >. Acesso em: mar. 2014.
29
APÊNDICE A
Questionário utilizado na avaliação do modelo ScrumMobile, aplicado na forma de
entrevistas com profissionais da área da tecnologia da informação. Abaixo são listadas as
perguntas que compõem o questionário:
1. Você acredita que o uso de metodologias ágeis pode ajudar de forma significativa o
gerenciamento de projetos de software?
( ) Sim ( ) Não
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?
( ) Sim ( ) Não
3. Você considera que existe uma carência de ferramentas para auxiliar na aplicação
de metodologias ágeis em projetos de software desenvolvidos por equipes
geograficamente distribuídas?
( ) Sim ( ) Não
4. Você acredita que o ScrumMobile pode auxiliar na aplicação da metodologia Scrum
para planejamento e acompanhamento de projetos de software desenvolvidos por
equipes geograficamente distribuídas?
( ) Sim ( ) Não.
Justifique sua resposta:
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?
