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




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


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


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


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?


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


O autor


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?

feed de eventos para atividades de desenvolvimento de software

Documents