Feed de eventos para atividades de desenvolvimento de software
Transcript of Feed de eventos para atividades de desenvolvimento de software
Universidade Federal do Rio Grande do NorteCentro de Ciências Exatas e da Terra
Departamento de Informática e Matemática AplicadaBacharelado em Engenharia de Software
Feed de eventos para atividades dedesenvolvimento de software
Lucas Bibiano dos Santos
Natal-RN
Junho 2017
Lucas Bibiano dos Santos
Feed de eventos para atividades de desenvolvimento desoftware
Monografia de Graduação apresentada aoDepartamento de Informática e MatemáticaAplicada do Centro de Ciências Exatas e daTerra da Universidade Federal do Rio Grandedo Norte como requisito parcial para a ob-tenção do grau de bacharel em Engenhariade Software.
Orientador
Prof. Dr. Fernando Marques Figueira Filho
Universidade Federal do Rio Grande do Norte – UFRNDepartamento de Informática e Matemática Aplicada – DIMAp
Natal-RN
Junho de 2017
Catalogação da Publicação na Fonte. UFRN / SISBI / Biblioteca Setorial
Centro de Ciências Exatas e da Terra – CCET.
Santos, Lucas Bibiano dos.
Feed de eventos para atividades de desenvolvimento de software / Lucas
Bibiano dos Santos. - Natal, 2017.
34 f.: il.
Orientador: Prof. Dr. Fernando Marques Figueira Filho.
Monografia (Graduação) – Universidade Federal do Rio Grande do Norte.
Centro de Ciências Exatas e da Terra. Departamento de Informática e Matemática
Aplicada.
1. Engenharia de software – Monografia. 2. Feeds – Monografia. 3. Eventos –
Monografia. 4. Desenvolvimento de software – Monografia. I. Figueira Filho,
Fernando Marques. II. Título.
RN/UF/BSE-CCET CDU: 004.41
Monografia de Graduação sob o título Feed de eventos para atividades de desenvolvi-
mento de software apresentada por Lucas Bibiano dos Santos e aceita pelo Departamento
de Informática e Matemática Aplicada do Centro de Ciências Exatas e da Terra da Uni-
versidade Federal do Rio Grande do Norte, sendo aprovada por todos os membros da
banca examinadora abaixo especificada:
Prof. Dr. Fernando Marques Figueira FilhoOrientador
Departamento de Informática e Matemática AplicadaUFRN
Prof. Dra. Márcia Jacyntha Nunes Rodrigues LucenaDepartamento de Informática e Matemática Aplicada
UFRN
Profa. Dr. Eduardo Henrique da Silva AranhaDepartamento de Informática e Matemática Aplicada
UFRN
Natal-RN, oito de junho de dois mil e dezessete
À todos que me apoiaram nessa jornada:
Deus, nosso criador.
Minha família.
Minha amável Luadja pelo companheirismo e pela insistência em me fazer terminar isso.
Agradecimentos
Esses anos de graduação foram essenciais a minha vida. Os amigos que fiz, e as lições
aprendidas ficaram comigo ainda por um bom tempo.
Obrigado primeiramente a Deus, sem Ele nada disso seria possível.
Obrigado a minha família por me apoiar nessa jornada.
Obrigado a Igreja Batista de Nova Parnamirim pelos puxões de orelha quando neces-
sário, especialmente aos jovens da igreja.
Obrigado a minha fiel amiga e companheira, que mais me incentivou a completar o
curso.
Obrigado ao pessoal da Codeminer 42 pelo crescimento profissional que pude adquirir,
e pelo acesso aos dados do TCC.
Obrigado a todos que puderam tornar esse momento possível.
Requisitos para um feed de eventos relacionado aodesenvolvimento de software
Autor: Lucas Bibiano dos Santos
Orientador: Prof. Dr. Fernando Marques Figueira Filho
Resumo
Desenvolvedores de software trabalham com informação e precisam constantemente trocar
informações entre si. É necessário uma forma dos desenvolvedores terem acesso facilitado
a essa informação, e que ela possa ser recuperada de forma rápida no futuro.
Este trabalho propõe a construção da tal ferramenta, de forma que ao utilizá-la,
os desenvolvedores consigam ter uma visão cronológica dos eventos do desenvolvimento,
além de ter acesso as notas que forem criadas por eles mesmos ou por outros membros da
equipe. Essas notas podem servir para indexar as reuniões ocorridas, e qual o resultados
delas, facilitando futura consulta. Dessa forma o acesso às informações do time ficam
centralizadas e podem ser acessadas para facilitar o processo de desenvolvimento.
Palavras-chave: Feeds. Eventos. Desenvolvimento de Software.
A news feed for software development activity
Author: Lucas Bibiano dos Santos
Advisor: Prof. Dr. Fernando Marques Figueira Filho
Abstract
Software developers work with information and need to constantly exchange information
between them. They need a way to have easy access to that information and that the
information can be retrieved fast enough in case they want to access it.
This works proposes the development of such tool, in a way that when the tool is used,
the developers could have a chronological view of the development events, and have access
to notes that are created by them or by other team members. These notes can index the
meetings that happen, and the outcome of these meetings, aiding future consulting of the
information, centralizing it, and facilitating the development process.
Keywords : Feed. Events. Software Development.
Lista de figuras
1 Log usado na Empresa B . . . . . . . . . . . . . . . . . . . . . . . . . . p. 20
2 Listagem de itens no feed . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23
3 Listagem de itens no feed . . . . . . . . . . . . . . . . . . . . . . . . . . p. 24
4 Busca de itens no feed . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25
5 Respostas da pergunta 1 - escala . . . . . . . . . . . . . . . . . . . . . p. 26
6 Respostas da pergunta 2 - escala . . . . . . . . . . . . . . . . . . . . . p. 27
7 Respostas da pergunta 3 - escala . . . . . . . . . . . . . . . . . . . . . p. 28
8 Respostas da pergunta 4 - escala . . . . . . . . . . . . . . . . . . . . . p. 28
Sumário
1 Introdução p. 10
1.1 Exemplo de Uso da Ferramenta . . . . . . . . . . . . . . . . . . . . . . p. 11
1.2 Objetivos e Perguntas de Pesquisa . . . . . . . . . . . . . . . . . . . . . p. 11
1.3 Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 12
2 Revisão de Literatura p. 13
2.1 Gestão e recuperação de informação . . . . . . . . . . . . . . . . . . . . p. 13
2.2 Processo ágil de desenvolvimento de software . . . . . . . . . . . . . . . p. 13
2.3 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15
2.4 Feeds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18
3 Metodologia p. 19
3.1 Estudo de aplicações existentes . . . . . . . . . . . . . . . . . . . . . . p. 19
3.1.1 Github . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19
3.1.2 Trello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19
3.2 Estudo de caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19
3.2.1 Contexto e análise do documento utilizado pela Empresa B . . . p. 20
3.3 Coleta e análise de dados . . . . . . . . . . . . . . . . . . . . . . . . . . p. 21
4 Projeto de solução p. 22
4.1 Definição dos Requisitos da Ferramenta e Implementação . . . . . . . . p. 22
4.2 Funcionalidades da ferramenta . . . . . . . . . . . . . . . . . . . . . . . p. 23
4.2.1 Listagem de itens no feed . . . . . . . . . . . . . . . . . . . . . p. 23
4.2.2 Criação de um item no feed . . . . . . . . . . . . . . . . . . . . p. 24
4.2.3 Busca de itens no feed . . . . . . . . . . . . . . . . . . . . . . . p. 25
5 Análise e Discussão dos Resultados p. 26
5.1 Avaliação da ferramenta . . . . . . . . . . . . . . . . . . . . . . . . . . p. 26
5.1.1 O sistema é de uso fácil? . . . . . . . . . . . . . . . . . . . . . . p. 26
5.1.2 O quanto é possível se ter uma noção do que cada desenvolvedor
fez/está fazendo? . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27
5.1.3 É possível observar a cronologia do desenvolvimento através do
sistema? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27
5.1.4 O sistema de anotações de reunião é eficaz para armazenar/recuperar
os resultados das mesmas ao longo do desenvolvimento? . . . . . p. 27
5.1.5 Quais as vantagens da solução proposta com relação ao antigo
documento que era utilizado? . . . . . . . . . . . . . . . . . . . p. 28
5.1.6 O que poderia ser acrescentado/modificado no sistema para me-
lhorar o seu uso? . . . . . . . . . . . . . . . . . . . . . . . . . . p. 29
5.2 Conclusões Obtidas e Respostas das Perguntas de Pesquisa . . . . . . . p. 29
5.3 Limitações do estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30
6 Considerações Finais p. 31
Referências p. 32
Apêndice A -- Questionário p. 34
10
1 Introdução
Desenvolvimento de software é uma atividade colaborativa (HERBSLEB et al., 2001). O
time de desenvolvimento está constantemente interagindo entre si, trocando informações
e gerando conhecimento (KRAUT; STREETER, 1995). É necessário que haja esse conheci-
mento por parte do time de que informações estão sendo trocadas, para que a equipe esteja
alinhada quanto ao trabalho a ser desenvolvido (BOH; SLAUGHTER; ESPINOSA, 2007).
Em equipes de desenvolvimento de software, o conhecimento se dá por diversos eventos
como: reuniões (ex.: planning, retrospectiva, review, dailies), emails, mensagens em canais
de chat ou até mesmo pode ocorrer de maneira informal no caso de comunicação face a
face por exemplo (KORFHAGE, 2008).
Cada um desses eventos gera uma informação de um tipo, e de maneira diferente. A
falta de padronização das informações prejudica a recuperação dos resultados mais tarde
por parte dos desenvolvedores e interessados no desenvolvimento (ROSS; WESTERMAN,
2004).
Muitas vezes, essas informações não são registradas e podem se perder, prejudicando
assim a atividade do desenvolvimento (KO; DELINE; VENOLIA, 2007). Não é incomum
ocorrer retrabalho por causa de falhas desse tipo, onde a informação de que tal atividade
já foi executada por outro membro da equipe é perdida (GOPAL; MUKHOPADHYAY; KRISH-
NAN, 2002). Além disso, decisões tomadas em reuniões podem ser esquecidas por algum
desenvolvedor, e este seguir um caminho contrário ao resto da equipe.
É proposta uma ferramenta que possa forma de recuperar os eventos que ocorreram ao
longo do desenvolvimento, catalogá-los e indexá-los, para que a consulta aos mesmos seja
fácil e rápida entre os membros da equipe. Tal processo permite a equipe ter um histórico
do desenvolvimento, facilitando assim: a consulta de eventos importantes que ocorreram
no passado, consulta a resultados de reuniões, consciência da equipe do trabalho que cada
um está realizou e está realizando.
11
1.1 Exemplo de Uso da Ferramenta
Caso 1: cadastro de item no feed de desenvolvimento
Um determinado desenvolvedor José cadastra um novo item no feed de eventos do
seu time: um resumo do que ocorreu na última retrospectiva. José informa título, uma
descrição do item, em markdown, contendo o resumo da reunião e define reunião como
sendo o tipo do item cadastrado.
Caso 2: visualização do feed
João, gerente do projeto, deseja saber como anda o desenvolvimento. Para isso, ele
acessa o feed e visualiza os eventos que ocorreram ao longo do desenvolvimento. Lá ele
pode ver o evento cadastrado por José, bem como resultados de outras reuniões. Isso o
ajuda a extrair um relatório sobre o que foi desenvolvido pela equipe durante o período.
Caso 3: pesquisa de itens no feed
Maria deseja saber o que foi entregue no time durante um determinado período. Para
isso, ela filtra os itens do feed pelos que são do tipo delivery e assim ela tem um feed que
lista apenas as entregas executadas pelo time.
1.2 Objetivos e Perguntas de Pesquisa
Este estudo descreve a concepção e desenvolvimento de uma ferramenta cujo objetivo
é melhorar o compartilhamento e acompanhamento de eventos ocorridos ao longo do
desenvolvimento do software. Foi usado como base um modelo já utilizado pela empresa
Empresa B (assim como definido na seção da metodologia), e desenvolvido uma ferramenta
para ser comparado com tal modelo. A partir disso foram aplicados questionários que
serviram de base para a avaliação da ferramenta desenvolvida.
O objetivo geral deste trabalho é responder as seguintes perguntas:
1. Quais os benefícios que dessa ferramenta no processo de desenvolvimento do time?
2. A ferramenta supera em utilidade o modelo utilizado anteriormente pela Empresa
B?
3. Quais requisitos poderiam ser agregados a ferramenta?
12
Concluiu-se que a ferramenta acrescenta ao desenvolvimento principalmente devido a
exibição cronológica dos eventos e também da ferramenta de pesquisa. Mesmo rudimen-
tar, essa ferramenta superou em funcionalidades o modelo anteriormente usado. Algumas
melhorias para a ferramenta também foram coletadas, que serão relatadas neste trabalho.
1.3 Estrutura do Trabalho
O Capítulo 2 apresenta a revisão de literatura que está relacionada com este traba-
lhado. O Capítulo 3 explica os passos para a construção e avaliação da ferramenta. O
Capítulo 4 descreve a ferramenta desenvolvida. O Capítulo 5 mostra a análise da metodo-
logia aplicada e os seus resultados. Por fim, o Capítulo 6 discorre sobre as considerações
finais do trabalho.
13
2 Revisão de Literatura
Este capítulo descreve a revisão de literatura utilizada no trabalho. Este trabalho con-
tém conceitos de gestão e recuperação de informação para o gerenciamento dos eventos de
desenvolvimento de software; também exibe os conceitos de processo ágil de desenvolvi-
mento de software e scrum, utilizados pela Empresa B, principalmente no que diz respeito
ao incentivo a comunicação e às cerimônias propostas por esses modelos de desenvolvi-
mento; por fim, a forma utilizada para exibir esses eventos foi a forma de feed, explicada
nessa seção.
2.1 Gestão e recuperação de informação
A gestão de conhecimento visa a aquisição de novos conhecimentos, de como agir
diante do conhecimento existente para possibilitar o seu uso no futuro, passando pelas
técnicas de armazenamento e difusão, assim também definindo estratégias para outros
contextos. (BARCLAY; MURRAY, 1997)
Uma gestão de informação eficiente e a facilidade da recuperação da mesma permite
que organizações de desenvolvimento de software mantenham-se inovadoras e competiti-
vas.
Sendo assim, é importante que uma equipe de desenvolvimento que possua alguma
forma de gestão de informações pode fazer com que a comunicação seja executada de
forma mais eficiente, e que os membros da equipe saibam o andamento do projeto, e do
que é necessário para que o projeto possa continuar sendo executado.
2.2 Processo ágil de desenvolvimento de software
Processo ágil de desenvolvimento de software é um conjunto de metodologias de desen-
volvimento de software baseado no manifesto ágil. O manifesto ágil foi escrito e assinado
14
por vários nomes renomados na área de engenharia de software. A lista completa dos sig-
natários é composta por: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn,
Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron
Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff
Sutherland e Dave Thomas. Foi escrito em Fevereiro de 2001 e tem 4 pilares que visam
valorizar:
1. Indivíduos e interações mais que processos e ferramentas;
2. Software funcional mais que documentação abrangente;
3. Colaboração do cliente mais que negociação de contratos;
4. Responder a mudanças mais que seguir um plano;
Ou seja, mesmo havendo valor nos itens à direita, o manifesto valoriza mais os itens
à esquerda.
Além disso, existem 12 princípios que são estabelecidos no manifesto ágil;
1. Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada
de software com valor agregado.
2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento.
Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para
o cliente.
3. Entregar frequentemente software funcionando, de poucas semanas a poucos meses,
com preferência à menor escala de tempo.
4. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por
todo o projeto.
5. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o
suporte necessário e confie neles para fazer o trabalho.
6. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe
de desenvolvimento é através de conversa face a face.
7. Software funcionando é a medida primária de progresso.
15
8. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, de-
senvolvedores e usuários devem ser capazes de manter um ritmo constante indefini-
damente.
9. Contínua atenção à excelência técnica e bom design aumenta a agilidade.
10. Simplicidade, a arte de maximizar a quantidade de trabalho não realizado, é essen-
cial.
11. As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.
12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então
refina e ajusta seu comportamento de acordo.
No processo ágil de desenvolvimento, os requisitos e soluções estão sempre evoluindo
através do esforço colaborativo e da organização própria do time (MARTIN, 2002). Este
processo estimula o planejamento adaptativo, desenvolvimento evolucionário, entregas o
mais cedo possível e com frequência, e melhoria contínua, além de encorajar respostas
rápidas e flexíveis a mudanças. Várias metodologias de desenvolvimento surgiram a partir
desses pilares, como o Scrum.
2.3 Scrum
Scrum é uma metodologia ágil de desenvolvimento onde o time se organiza a fim
de atingir um determinado objetivo em comum. Por se tratar de uma abordagem que
estimula a flexibilidade e a auto-organização do time em face de mudanças, necessita
de uma comunicação bem executada entre os membros da equipe de desenvolvimento.
Para gerenciar essa comunicação são definidos papéis a serem realizados dentro do time,
os quais são: dono do produto, scrum master e a própria equipe de desenvolvimento.
Além disso são definidas cerimônias com o intuito de colocar a equipe num lugar comum
de conhecimento e para que todos possam opinar sobre o que está sendo feito. Essas
cerimônias são: planning, daily, review e retrospectiva. Também são gerados artefatos
como resultado do processo, como: backlog do produto, backlog do sprint e o incremento
ao produto (SCHWABER; BEEDLE, 2002).
Dentre os valores defendidos pelo Scrum, temos:
1. Comprometimento: membros do time devem se comprometer com os objetivos de
time.
16
2. Coragem: membros do time devem ter a coragem de resolver conflitos e desafios
juntos para fazer a coisa do jeito certo
3. Foco: membros do time focm apenas nos objetivos do time e no backlog do sprint;
não deve haver outro tipo de trabalho a ser realizado por eles
4. Abertura: membros do time e stakeholders devem ser transparentes acerca do seu
trabalho e dos desafios que enfrentam
5. Respeito: membros do time devem considerar uns aos outros tecnicamente capazes
de completar o trabalho e sempre assumir boas intenções dos outros membros
Sobre os papéis na equipe que executa o Scrum, temos:
1. Dono do produto: representa os stakeholders do projeto, e é responsável por garantir
que o time entregue valor ao negócio. Também é responsável por documentar o que
vai ser entregue, de uma forma focada no cliente e priorizar essas tarefas baseada
em importância e dependência entre as mesmas.
2. Scrum master: é responsável por remover os impedimentos que possam surgir e
impossibilitem ao time atingir seu objetivo. Também é responsável por garantir que
o Scrum esteja sendo seguido corretamente pela equipe. Frequentemente também
atua como facilitador nas cerimônias do Scrum.
3. Equipe de desenvolvimento: responsável por desenvolver os entregáveis ao longo do
desenvolvimento.
Além disso, o Scrum encoraja a realização de diversas cerimônias, citadas abaixo:
1. Planning
Executado no começo do Sprint, tem como objetivo:
(a) Definir o escopo de trabalho a ser feito no sprint.
(b) Selecionar os itens do product backlog que podem ser completados em um
sprint.
(c) Preparar o backlog do sprint, detalhando o trabalho necessário para que esses
itens selecionados possam ser completados.
17
2. Daily
Executada diariamente segue-se da seguinte forma: cada membro do time de desen-
volvimento responde a três perguntas:
(a) O que eu fiz ontem?
(b) O que eu farei hoje?
(c) Existe algum impedimento para a realização das atividades do sprint?
Se houverem impedimentos, é responsabilidade do Scrum master trabalhar para
resolvê-los.
3. Review
Executado ao fim do Sprint, tem como objetivo:
(a) Revisar o trabalho que foi completado e o que trabalho que foi planejado mas
não pôde ser terminado.
(b) Apresentar o trabalho realizado aos stakeholders (demo)
4. Retrospectiva
Executada também ao fim do sprint, tem por objetivo refletir sobre o sprint pas-
sado, levantando assim pontos que são bons e pontos que possam melhorar para o
desenvolvimento da atividade da equipe.
Por fim, existem os artefatos que são produzidos ao longo do desenvolvimento:
1. Product backlog: Uma lista ordenada (geralmente por prioridade) de todos os re-
quisitos a serem desenvolvidos. Nele são expressas as modificações propostas ao pro-
duto, incluindo adição de novas features, remoção de features antigas, modificação
de features existentes e resolução de bugs.
2. Spring backlog: Um subconjunto do product backlog que deve ser entregue no sprint
atual.
3. Product Increment: A soma de todos os itens do product backlog entregues desde o
primeiro sprint.
18
2.4 Feeds
Feeds são um tipo de visualização de informação no qual existe uma sequência de
eventos ordenados, geralmente cronologicamente, onde o consumidor da informação pode
visualizar cada item, após isso pulando para o próximo, até atingir o fim da informa-
ção (TSENG; CHEN; CHEN, 2012).
O consumidor se inscreve em um ou mais canais de informação e esses canais são
agregados para formar o feed. É um formato bem comum em redes sociais, justamente
pela sua característica temporal, permitindo ao consumidor da informação ter uma visão
geral em curta escala dos eventos aos quais este está monitorando, no caso das redes
sociais, pessoas e páginas (FREYNE et al., 2010).
Nesse tipo de visualização, é possível ao consumidor da informação verificar a evolução
dos dados ao longo do tempo, bem como ordená-los por relevância (PHELAN; MCCARTHY;
SMYTH, 2009). Ainda é possível filtrar os dados que interessam ao usuário, criando feeds a
partir de outros. Além disso, é bem comum a agregação de feeds, possibilitando ao usuário
o consumo de informação de fontes diferentes de dados (COLD, 2006).
Como a atividade de desenvolvimento de software se dá de forma contínua ao longo
do tempo, um feed com as atividades realizadas pelos membros da equipe podem ajudar
o time a perceber a evolução do produto desenvolvido, bem como saber as atividades de
cada membro nesse período.
19
3 Metodologia
Este trabalho tem por objetivo desenvolver uma ferramenta capaz de guardar e indexar
os eventos ocorridos durante o desenvolvimento de uma equipe de software. O capítulo a
seguir aborda as etapas do estudo de aplicações existentes e estudo de caso e análise do
documento utilizado pela Empresa B, além de como se deu a coleta e análise dos dados.
3.1 Estudo de aplicações existentes
3.1.1 Github
O Github, maior rede de compartilhamentos de código mundial, possui uma visuali-
zação de feeds de atividades de desenvolvimento. Porém esse feed não permite que seja
cadastrado um texto customizado, e é focado apenas nos eventos do próprio Github. Sendo
assim, limitado com relação a todas as atividades do desenvolvimento.
3.1.2 Trello
O Trello (e similares) permite ao time a criação de um quadro onde cartões que
representam as tarefas podem ser movidos entre colunas que definem o estado do mesmo.
É um formato muito bom para se ter uma visão atual do desenvolvimento, mas não se
tem a cronologia dos acontecimentos.
3.2 Estudo de caso
A partir da etapa anterior, foi feito um estudo para se obter os requisitos da ferramenta
proposta. O detalhamento do processo está descrito abaixo:
20
3.2.1 Contexto e análise do documento utilizado pela Empresa B
Para a elaboração da ferramenta, houve participação de 4 desenvolvedores da Empresa
A, dos quais 2 estavam trabalhando de forma terceirizada para a Empresa B, com sede
nos Estados Unidos. A Empresa A é uma empresa brasileira que atua com terceirização
de programadores para outras empresas, enquanto a Empresa B trabalha com leilões de
anúncios.
O autor do trabalho fazia parte da Empresa A, juntamente com os desenvolvedores
que trabalhavam para a Empresa B. Em uma das conversas informais do escritório, foi
exibido o log de atividades utilizado pela Empresa B para registrar suas atividades de
desenvolvimento. Percebeu-se que esse log não exibia muitas informações que poderiam
ser úteis aos gestores e desenvolvedores da empresa, então, teve-se a ideia de propor uma
solução que fosse melhor do que a que já existia.
O formato do log citado acima era um documento do google drive, na qual todos os
membros adicionavam o que faziam ou estavam fazendo como texto livre, marcando no
texto as iniciais do seu nome, para identificação do autor de atividade registrada. Um
exemplo pode ser visto abaixo:
Figura 1: Log usado na Empresa B
Fonte: O autor (2017)
Basicamente, o log consiste de várias entradas da estrutura apresentada como exemplo
acima: uma data inicial e final do sprint, as atividades que estão sendo feitas, as atividades
21
que foram concluídas, os blockers apresentados durante o desenvolvimento, novas ideias, e
finalmente, um resumo de cada atividade feita pelos membros do time em um determinado
dia.
O primeiro problema apresentado foi o tipo de formato utilizado: o google docs. Como
é um formato de texto livre, não havia uma padronização nesse documento. Além disso,
a questão cronológica do desenvolvimento não era tão bem apresentada, principalmente
nas seções de doing e done: não se sabia em que ordem tais tarefas foram feitas. Tam-
bém as notas das reuniões realizadas estavam em outros documentos, dificultando a sua
recuperação. Por fim, não existia um sistema de busca que fosse capaz de indexar esse log
para consulta futura.
Foi feita uma análise do documento modelo utilizado pela Empresa B, bem como
analisadas outras ferramentas que poderiam servir de base para esta proposta. Notou-
se que além de uma visão geral atual, era necessário uma visão cronológica dos eventos
de desenvolvimento. Para que essa visão fosse possível, a visualização de feeds foi esco-
lhida. Algumas partes da estrutura do documento usado pela Empresa B também foram
reaproveitadas.
3.3 Coleta e análise de dados
A ferramenta foi disponibilizada em um servidor para uso dos participantes da pes-
quisa de avaliação. O processo de avaliação consistiu em um questionário de seis perguntas
e se encontra nos apêndices do trabalho (Apêndice A). A ferramenta foi desenvolvida
como uma aplicação web, disponível para ser acessada em 1. Dois desenvolvedores da
Empresa B e dois desenvolvedores da Empresa A participaram do questionário, que foi
disponibilizado no mês de maio desse ano.
Foi pedido a cada um dos desenvolvedores que acessasse o sistema e o utilizasse. Havia
já dados pré-cadastrados para exemplificar a exibição da informação e o usuário poderia
cadastrar novos dados. Após o fim do período de uso pelos participantes do estudo, o autor
aplicou uma pesquisa e iniciou a análise das respostas obtidas no questionário aplicado.
Algum aspecto da ferramenta foi avaliado em cada pergunta numa escala de 1 a 5 (Escala
Likert) e um campo em texto livre servia para o usuário poder justificar a nota atribuída
ao sistema.
1https://devf33d.herokuapp.com
22
4 Projeto de solução
Após o estudo de caso, chegou-se aos requisitos da aplicação. A seguir também segue
a implentação e os requisitos implementados da ferramenta.
4.1 Definição dos Requisitos da Ferramenta e Imple-mentação
Após a análise, foi proposto um modelo para a exibição desses eventos do desenvolvi-
mento. Os pontos de atenção para a concepção da ferramenta foram:
1. Ordem cronológica dos eventos
2. Identificação do responsável pelo evento
3. Data do evento
4. Título do evento
5. Notas sobre o evento, em caso do evento ter sido uma reunião
6. Eventos do tipo done e doing, que representam se o responsável está executando ou
completou uma atividade
7. Busca de eventos
Pensando nesses pontos, o modelo de feed de notícias, similar aos das redes sociais
foi desenvolvido. Esse modelo seria capaz de abordar a exibição dos eventos de maneira
a manter a cronologia. Também foi escolhido o formato de cada item do feed: cartões.
O formato foi escolhido pela simplicidade e pela padronização das informações, além de
ser customizável para por exemplo, acomodar as notas de reuniões, sem perder o padrão.
Uma busca geral pelas informações dos eventos também foi acrescentada a ferramenta.
23
• Listagem de itens no feed (tanto para eventos, quanto para notas de reunião)
• Criação de itens no feed
• Busca de itens no feed
4.2 Funcionalidades da ferramenta
Abaixo estão listadas as funcionalidade da ferramenta desenvolvida.
4.2.1 Listagem de itens no feed
Já na primeira tela, é possível ver os itens de feed logo abaixo do formulário para
cadastro e do campo de busca:
Figura 2: Listagem de itens no feed
Fonte: O autor (2017)
24
Os itens são listados em forma de cartões. A figura acima mostra os dois tipos de
eventos que podem ocorrer: notas de reunião e eventos gerais. Notas de reunião são exi-
bidas em cartões maiores, e disponibilizam a anotação feita pelo usuário no momento do
cadastro do item. Os outros eventos apenas possuem o texto em inglês identificando que
o autor da nota está fazendo ou já concluiu a tarefa que foi inserida. Nota-se que existe
uma ordem temporal, com as notas mais antigas ficam mais abaixo no feed, e as mais
novas aparecendo mais acima.
4.2.2 Criação de um item no feed
Para cadastrar um item novo no feed, o usuário deve fornecer um título, um texto
para o item caso o tipo de item seja notes, o tipo de item a ser cadastrado e o usuário
que criou o item.
Figura 3: Listagem de itens no feed
Fonte: O autor (2017)
25
4.2.3 Busca de itens no feed
Com a busca, pode-se filtrar os resultados buscando a palavra pesquisa no nome do
usuário do item, no título ou na descrição. Assim é possível filtrar por exemplo, pelas
atividades de um certo usuário. Também é possível filtrar os itens relacionados a uma
palavra chave, como o nome de um determinado sistema por exemplo. A tela para busca
segue abaixo:
Figura 4: Busca de itens no feed
Fonte: O autor (2017)
26
5 Análise e Discussão dos Resultados
Após a aplicação de questionário, passou-se para a avaliação da ferramenta e discussão
dos resultados.
5.1 Avaliação da ferramenta
Abaixo estão descritas as análises de cada pergunta do questionário. O questionário
foi respondido de forma anônima pelos participantes.
5.1.1 O sistema é de uso fácil?
Figura 5: Respostas da pergunta 1 - escala
O autor
Foi observado que o sistema realmente é direto ao ponto com relação às suas fun-
cionalidades, porém, o nome dos campos não é intuitivo e gerou confusão entre 2 dos
participantes sobre o que cada informação representaria.
27
5.1.2 O quanto é possível se ter uma noção do que cada desen-volvedor fez/está fazendo?
Figura 6: Respostas da pergunta 2 - escala
O autor
Percebeu-se através das respostas que o sistema permite uma visualização cronológica
dos eventos de desenvolvimento de software. Um dos participantes sugeriu links nos cam-
pos onde o nome do usuário é exibido para ser usado na busca, e autocomplete de nomes
de usuário também na busca. Segundo ele, facilitaria a pesquisa pelas atividades de cada
usuário no desenvolvimento.
5.1.3 É possível observar a cronologia do desenvolvimento atravésdo sistema?
A resposta analisada da pergunta desta seção também foi sim, porém o mesmo par-
ticipante da questão anterior reforçou a sugestão dos links, pela dificuldade de se decorar
o nome das tarefas a serem pesquisadas.
5.1.4 O sistema de anotações de reunião é eficaz para armaze-nar/recuperar os resultados das mesmas ao longo do de-senvolvimento?
Nesta pergunta houve uma divisão entre os participantes. O principal problema apon-
tado foi a falta de diferenciação do que era anotação de reunião e o que era um evento do
28
Figura 7: Respostas da pergunta 3 - escala
O autor
Figura 8: Respostas da pergunta 4 - escala
O autor
desenvolvimento. Novamente o participante citado na segunda pergunta reforçou a neces-
sidade dos links. Outro participante acrescentou a falta de filtros por data, para facilitar
a pesquisa das reuniões ocorridas.
5.1.5 Quais as vantagens da solução proposta com relação ao an-tigo documento que era utilizado?
De acordo com as respostas, as vantagens foram principalmente a cronologia dos
acontecimentos, diferente de apenas uma visão atual que o modelo antigo fornecia e a
29
centralização das informações dos eventos.
5.1.6 O que poderia ser acrescentado/modificado no sistema paramelhorar o seu uso?
As melhorias sugeridas nessa pergunta foram:
1. Links para recuperar as atualizações (eventos) de pessoas ou tarefas
2. Melhor diferenciação entre as atualizações e anotações
3. Melhor identificação dos campos presentes na ferramenta, com alguma explicação
referente aos mesmos
4. Sincronização com outros tipos de ferramenta como pivotal, jira ou github
5. Filtro de data ou período
6. Indicador de sprint ou milestone
5.2 Conclusões Obtidas e Respostas das Perguntas dePesquisa
Com base nas respostas obtidas, foi possível obter respostas para as perguntas de
pesquisa inicialmente propostas.
1. Quais os benefícios que dessa ferramenta no processo de desenvolvimento do time?
Os benefícios resultantes da utilização da ferramenta segundo o questionário foram:
(a) A exibição cronológica dos eventos que ocorreram durante o desenvolvimento.
(b) Uma forma fácil de saber as atividades de cada membro, ou atividades relaci-
onadas a determinado tópico através da busca.
(c) A possibilidade de ter os eventos de desenvolvimento combinados às notas das
reuniões ao longo do desenvolvimento.
(d) Centralização das informações
30
2. A ferramenta supera em utilidade o modelo utilizado anteriormente pela Empresa
B?
Em comparação ao documento e aos desenvolvedores que utilizavam outras ferra-
mentas ou nenhuma, houve ganhos principalmente na parte da centralização dos
dados, que puderam ser recuperados de forma mais fácil, e na sequência temporal
dos eventos, que não era identificada com clareza no documento. Concluiu-se então
que sim, a ferramenta supera em utilidade o modelo usado pela empresa B.
3. Quais requisitos poderiam ser agregados a ferramenta?
(a) Adição de filtros pré-definidos, linkando certas palavras chave no texto, como
o nome de um sistema ou o nome de um desenvolvedor.
(b) Um tutorial básico exemplificando o uso da ferramenta.
(c) Diferenciação entre tarefas e atualizações.
(d) Sincronização com outros sistemas
(e) Indicador de sprint ou milestone
(f) Filtros por período de tempo.
(g) Mudança na identificação dos campos presentes na ferramenta
5.3 Limitações do estudo
1. Não houve ampla participação dos desenvolvedores da Empresa B.
2. O questionário teve apenas 4 respostas.
3. Foi utilizada uma amostra de conveniência, então os resultados não podem ser ge-
neralizados
31
6 Considerações Finais
Esse estudo teve como objetivo propor uma maneira de gerenciar os eventos ocorridos
ao longo do desenvolvimento de um software. Estes eventos podem ser tanto reuniões,
como registros de que o desenvolvedor está fazendo ou terminou uma determinada tarefa.
Como ao utilizar o Scrum, várias reuniões são feitas durante o time, uma maneira
de guardar o resultado das reuniões se fez presente. Não somente isso, mas a ferramenta
proposta permitiria ao desenvolvedor lembrar de tudo o que houve de importante, e assim
passar essas informações de forma mais completa ao seu time. Como essas informações
de reunião geralmente ficam espalhadas, ou são perdidas em meios de comunicação que
não podem ser registrados e/ ou indexados facilmente, fica clara a necessidade de uma
ferramenta que pudesse fazer esse trabalho.
Além disso, é importante se ter uma visão das tarefas de cada desenvolvedor, e isso é
possível ao se cadastrar um evento no feed.
A busca também é um fator importante já que os itens do feed são indexáveis e
podem ser buscados a qualquer momento, utilizando o critério de palavra chave explicado
no trabalho.
Depois do projeto de protótipo desenvolvido e implementado com esses requisitos,
um questionário revelou muitos pontos de otimização que poderiam ser aplicados a ferra-
menta. Dessas otimizações, surgiram requisitos que ao serem agregados a essa ferramenta,
poderiam torná-la mais útil.
Futuros estudos poderiam testar a validade desses requisitos, executando mais uma
iteração com os usuários finais da ferramenta, gerando novas otimizações e fazendo uma
melhoria contínua no produto.
32
Referências
BARCLAY, R. O.; MURRAY, P. C. What is knowledge management. Knowledge praxis,v. 19, 1997.
BOH, W. F.; SLAUGHTER, S. A.; ESPINOSA, J. A. Learning from experience insoftware development: A multilevel analysis. Management science, INFORMS, v. 53,n. 8, p. 1315–1331, 2007.
COLD, S. J. Using really simple syndication (rss) to enhance student research. ACMSIGITE Newsletter, ACM, v. 3, n. 1, p. 6–9, 2006.
FREYNE, J. et al. Social networking feeds: recommending items of interest. In: ACM.Proceedings of the fourth ACM conference on Recommender systems. [S.l.], 2010. p.277–280.
GOPAL, A.; MUKHOPADHYAY, T.; KRISHNAN, M. S. The role of software processesand communication in offshore software development. Communications of the ACM,ACM, v. 45, n. 4, p. 193–200, 2002.
HERBSLEB, J. D. et al. An empirical study of global software development: distanceand speed. In: IEEE COMPUTER SOCIETY. Proceedings of the 23rd internationalconference on software engineering. [S.l.], 2001. p. 81–90.
KO, A. J.; DELINE, R.; VENOLIA, G. Information needs in collocated softwaredevelopment teams. In: IEEE. Software Engineering, 2007. ICSE 2007. 29thInternational Conference on. [S.l.], 2007. p. 344–353.
KORFHAGE, R. R. Information storage and retrieval. Wiley, 2008.
KRAUT, R. E.; STREETER, L. A. Coordination in software development.Communications of the ACM, Association for Computing Machinery, Inc., v. 38, n. 3, p.69–82, 1995.
MARTIN, R. C. Agile software development: principles, patterns, and practices. [S.l.]:Prentice Hall, 2002.
PHELAN, O.; MCCARTHY, K.; SMYTH, B. Using twitter to recommend real-timetopical news. In: ACM. Proceedings of the third ACM conference on Recommendersystems. [S.l.], 2009. p. 385–388.
ROSS, J. W.; WESTERMAN, G. Preparing for utility computing: The role of itarchitecture and relationship management. IBM systems journal, IBM, v. 43, n. 1, p.5–19, 2004.
33
SCHWABER, K.; BEEDLE, M. Agile software development with Scrum. [S.l.]: PrenticeHall Upper Saddle River, 2002.
TSENG, C.-Y.; CHEN, Y.-J.; CHEN, M.-S. Socfeedviewer: A novel visualizationtechnique for social news feeds summarization on social network services. In: IEEE. WebServices (ICWS), 2012 IEEE 19th International Conference on. [S.l.], 2012. p. 616–617.
34
APÊNDICE A -- Questionário
1. O sistema é de uso fácil?
2. O quanto é possível se ter uma noção do que cada desenvolvedor fez/está fazendo?
3. É possível observar a cronologia do desenvolvimento através do sistema?
4. O sistema de anotações de reunião é eficaz para armazenar/recuperar os resultados
das mesmas ao longo do desenvolvimento?
5. Quais as vantagens da solução proposta com relação ao antigo documento que era
utilizado?
6. O que poderia ser acrescentado/modificado no sistema para melhorar o seu uso?