Relatório 4 - Radar SCRUM

Prévia do material em texto

RELATÓRIO 4 - RADAR SCRUM
Igor Castilho Valenciano
Joyce Aline de Oliveira Marins
1. INTRODUÇÃO
O desenvolvimento ágil é um dos paradigmas de desenvolvimento de
software, ou seja, um conjunto de práticas, regras e conclusões relacionadas, que
contribuem no desenvolvimento de sistemas. Até então, utilizando métodos
tradicionais, alguns líderes experientes passaram a perceber que a indústria de
software apresentava um alto número de fracassos e começaram a aplicar métodos
próprios em seus projetos, que se demonstraram bastante eficientes (BASSI,
Dairton). Sendo assim, constataram que seus métodos eram parecidos e se
reuniram, culminando na publicação do Manifesto Ágil, documento que contém
valores e princípios essenciais para o desenvolvimento de software (BECK et al).
A metodologia SCRUM, classificada como ágil, é um framework baseado no
empirismo e que busca ajudar pessoas, times e organizações a gerar valor através
de soluções adaptáveis para problemas complexos (SCHWABER, K.;
SUTHERLAND, J). O SCRUM divide o projeto em ciclos denominados “sprint”,
também conhecido como iteração, que geralmente acontece mensalmente. O ciclo
define termos específicos para cada atividade/função existente na operação, que é
iniciada com a definição da prioridade dos itens que constam na lista de
funcionalidades, conhecida como Product Backlog. Essa escolha de itens prioritários
é feita numa reunião denominada Sprint Planning Meeting, conduzida pelo membro
da equipe que ocupa o cargo de Product Owner.
Após as atividades terem sido priorizadas, são movidas da lista Product
Backlog para o Sprint Backlog e diariamente são realizadas reuniões que
geralmente acontecem pela manhã, nominada Daily Scrum Meeting. Quando cada
Sprint é finalizada, as funcionalidades implementadas são expostas em uma Sprint
Review Meeting e em seguida, uma nova reunião chamada Sprint Retrospective,
onde é discutido o planejamento da próxima Sprint.
Imagem 1: Sprint, o ciclo do SCRUM
Fonte: https://www.desenvolvimentoagil.com.br/scrum/. Acesso em 31/03/2021
Sendo assim, para que o ciclo do SCRUM seja acompanhado e executado o
mais rigorosamente possível, mensurar o progresso do produto e o desempenho da
equipe de desenvolvimento são uma das formas de consolidar o cumprimento dos
conceitos dessa metodologia.
2. FUNDAMENTAÇÃO TEÓRICA
2.1. SCRUM
Desde o início dos anos 1990, o SCRUM é utilizado no gerenciamento de
desenvolvimento de produtos, não limitando-se apenas à software. Para POHL e
HOF (2015), atualmente, o software está ao nosso redor, como em nossos
eletrodomésticos. Ainda, justamente pelo fato do software ser onipresente, o
surgimento de bugs evidencia a necessidade da utilização de uma metodologia ágil
no contexto de desenvolvimento de software moderno.
O framework possui como base a corrente filosófica conhecida como
empirismo, pois define que nossa estrutura cognitiva é constituída de acordo com a
nossa experiência prática e adere às características de metodologias ágeis, como
por exemplo, a abordagem incremental (SCHWABER; SUTHERLAND, 2020).
Três pilares sustentam a implementação de controle de processos utilizando
o SCRUM, sendo eles: transparência, inspeção e adaptação. A transparência
emprega que os aspectos importantes do processo sejam visíveis aos responsáveis
pelo resultado, ao longo da metodologia, artefatos do SCRUM que possuírem uma
baixa transparência podem acarretar em perdas de valor. Em seguida, a inspeção
busca detectar variações nos artefatos durante o progresso e não deve ser
frequente ao ponto de prejudicar a execução das tarefas principais. Por fim, o último
pilar, a adaptação realiza ajustes quando o aspecto de um artefato ou processo se
desvia dos limites aceitáveis, bem como se o produto resultante for inaceitável
(SCHWABER; SUTHERLAND, 2020).
O time SCRUM, além de ser responsável pelos pilares, também se
compromete a cumprir os valores do framework denominados compromisso, foco,
abertura, respeito e coragem. O time é formado por um Scrum Master, um Product
Owner e Developers, não possui hierarquias, são multifuncionais e
autogerenciáveis. Todos os integrantes do time são responsáveis por todas as
tarefas de um produto e geralmente cerca de quatro a dez pessoas formam a
equipe, realizando entregas de incrementos conhecida como Sprint (MUNDRA;
MISRA; DHAWALE, 2013).
Os Developers ou time de desenvolvimento atuam na implementação do
produto, entregando uma sprint usável ao final de cada ciclo e possuem como
característica essencial a auto-organização, por exemplo, a própria equipe decide
como transformar o Product Backlog em incrementos, sem a necessidade de auxílio
do Scrum Master (SCHWABER; SUTHERLAND, 2020). Ainda, para SCHWABER
(1997), essa equipe habitualmente possui três a seis membros, divididos em:
desenvolvedores, documentadores e equipe de controle de qualidade; selecionados
com base em seus conhecimentos e experiências de domínio.
O Product Owner desenvolve o papel do dono de produto e lida com o
desenvolvimento da meta do produto, refinamento do backlog, planejamento de
Sprints, elaborando estórias e com a garantia de entrega d e valor. Já o SCRUM
Master é a pessoa responsável por garantir que o framework seja realmente
aplicado dentro de seu time SCRUM e desempenha atividades como a de proteção
do time de interferências externas (PEREIRA, Paulo; TORREÃO, Paula; MARÇAL,
Ana Sofia). Com o Product Owner, por exemplo, o SCRUM Master auxilia na busca
de técnicas que resultem em um bom gerenciamento do Product Backlog. Na área
do desenvolvimento, uma das atividades do SCRUM Master é treinar o time de
Developers em autogerenciamento e interdisciplinaridade. Por fim, a atuação do
SCRUM Master também acontece na organização em geral, por exemplo, liderando
e treinando a corporação na adoção desse framework.
Como já mencionado anteriormente, o principal evento do SCRUM é
conhecido como Sprint. Entretanto, também existem outros eventos que fazem parte
da metodologia e compartilham a propriedade de time-boxed, ou seja, todo evento
tem uma duração máxima (FOWLER, 2018). Por exemplo, a Sprint, que é
considerada o coração do SCRUM, é composta de reuniões que acontecem
geralmente durante um mês e uma nova Sprint é iniciada após concluir a anterior.
Além disso, também é feita a entrega de um novo incremento e durante o evento,
nenhuma modificação é feita se arrisca a conclusão da meta da Sprint
(GONÇALVES, 2018).
Uma das reuniões que integram a Sprint é a Sprint Planning, momento onde
é planejada a próxima Sprint e costuma ter uma duração máxima de oito horas para
o ciclo de um mês. Esse planejamento necessita responder três perguntas definidas
pelos autores SCHWABER (2020) e SUTHERLAND (2020), sendo elas:
1. O motivo da Sprint possuir valor para o produto.
2. O que pode ser feito nessa Sprint, pois é necessário selecionar itens
do Product Backlog para serem incluídos nesse incremento.
3. Como será realizado o trabalho, ação que é planejada pelo time de
desenvolvimento.
Com o intuito de aproximar os membros do time SCRUM, melhorar a
comunicação e facilitar a tomada de decisões, todos os dias são feitos encontros
denominados Daily Scrum, seu time-boxed é de quinze minutos e geralmente
acontecem no mesmo lugar e horário. Essas reuniões diárias também servem para
ajustar o Product Backlog de acordo com o progresso da meta da Sprint atual e
definir o que será feito naquele dia, sendo o evento mais curto do framework, pois
seu objetivo é apenas expor os problemas para que posteriormente sejam
planejados e resolvidos (FOWLER, 2018).
O penúltimo evento desse período, definido como Sprint Review, trata-se de
uma revisão dos resultados entregues por meio de incrementos. O tempo máximo
são de quatro horas tomando como base uma Sprint de um mês, é recomendado
que seja focado em uma apresentação do que está pronto, o que pode ser adaptado
e nela participam toda a equipe SCRUM e os stakeholders (SCHWABER;
SUTHERLAND, 2020).
Por fim, depois da Sprint Review e antes da próxima Sprint de planejamento,acontece a Sprint Retrospective com o objetivo de avaliar o resultado como um todo
e a atuação do time na Sprint que se passou. Seu time-boxed é em média de três
horas para a Sprint de um mês e para FOWLER (2018) existem duas grandes
regras: a Sprint Retrospective deve ser feita de portas fechadas, apenas para os
membros da equipe e que não deve-se manter registros escritos da reunião com o
objetivo de incentivar discussões livres. Levando em consideração o time boxed de
uma sprint, de acordo com COBB (2015), a Sprint Retrospective por ser feita no final
de cada entrega, torna o aprendizado e a melhoria do processo muito mais rápidos
quando comparado à uma metodologia tradicional, pois existe uma grande
oportunidade de reflexão e análise dos pontos positivos e negativos que ocorreram
na SCRUM, bem como a identificação de melhorias a serem trabalhadas no próximo
período.
Como mencionado acima, um dos pilares do SCRUM é a transparência, que
é considerada fundamental nos artefatos, que representam trabalho ou valor,
gerados no decorrer da aplicação da metodologia, pois forma a base para os
próximos pilares, inspeção e adaptação. O primeiro dos três artefatos é o Product
Backlog, é dinâmico devido à possibilidade de ser refinado ao longo da Sprint e
contém a meta do produto, pois nele é listado de forma ordenada suas
características, requisitos, melhorias e funções que ele deve ter. Ainda, o
responsável por esse artefato, bem como por adicionar, alterar e excluir itens é o
apenas o Product Owner FOWLER (2018).
A meta da Sprint corresponde ao artefato Sprint Backlog em razão de
agregar os itens do Product Backlog no ciclo atual. O ator principal dessa meta é o
time de desenvolvimento, pois são eles que irão entregar o incremento ao final da
Sprint. Dessa forma, o resultado entregue através do uso do SCRUM, constitui o
artefato Definition of Done, garantindo que os novos incrementos sejam
completamente validados e que funcionem com os antigos incrementos após serem
adicionados. Ainda, o último artefato define que quando um item é classificado como
“pronto”, o time SCRUM deve entender que além dele ter sido entregue e finalizado,
também garantiu a transparência (SCHWABER; SUTHERLAND, 2020).
2.2. MÉTRICAS
Para que todo o ciclo proposto pelo SCRUM obtenha resultados satisfatórios,
agregar o uso de métricas auxilia no acompanhamento pontual do projeto, pois
métricas são representações numéricas que determinam alguma característica de
um software, projeto ou equipe. Dessa forma, as métricas listadas nesta seção
foram encontradas na literatura e se destacaram, porque apresentaram formas
práticas, como equações, para medirem um determinado aspecto ou devido terem
evidenciado o uso dessas técnicas em um estudo de caso.
RAM (2009) em seu artigo “Agile Metrics: A Seminal Approach for Calculating
Metrics in Agile Projects” faz uma crítica à mistura de métricas de processos e
projetos, bem como ao enfoque a apenas uma definição, como métricas de
qualidade. As formas de mensuração apresentadas por ele são concentradas para
medir a eficiência e o esforço da equipe e do projeto como um todo. RAM (2009) e
dapresenta oito métricas, listadas abaixo:
A. Fator de esforço da sprint: é uma métrica do projeto, deve ser distribuída de
forma uniforme entre todas as sprints e se refere ao princípio ágil da
documentação completa do software. É definido pela equação FES = (itens
da sprint atual / lista total de recursos) + [∑(solicitações de mudança em
sprints anteriores)].
B. Fator de complexidade do sprint: define a complexidade do sprint tomando
como base a quantidade de módulos x que interagem com interfaces de
módulos y. Pode ser representada pela equação FCS = (∑Q), onde Q é
justamente a quantidade mencionada anteriormente.
C. Esforço de solicitação de mudança: atua no princípio ágil de negociação do
contrato junto ao cliente e é definida pela seguinte equação: ESM = ( custo
dos novos recursos + custo para alterar recursos definidos anteriormente -
recursos financeiros liberados).
D. Linha de base da expectativa do cliente: conjunto dos recursos mínimos
entregues no sprint, que estão sendo esperados pelo cliente.
E. Impacto no orçamento: essa métrica aborda o comparativo entre o esforço da
solicitação de mudança e a linha de base da expectativa do cliente, a fim de
debater assuntos financeiros junto ao cliente. É definida pelo autor de forma
similar à métrica de esforço de solicitação de mudança.
F. Fator X de reutilização: trata-se de uma métrica do produto e quanto mais
alto, melhor. Tem como objetivo identificar mais componentes reutilizáveis
dentro do sistema. Fator X: número de componentes reutilizáveis = X
componentes adicionados à biblioteca.
G. Fator Y de reutilização: é similar ao fator X, quanto mais alto, melhor. O
objetivo é identificar a quantidade de componentes que realmente foram
reutilizados.
H. Facetime: a métrica equivale ao tempo gasto do desenvolvedor com o
cliente/empresário e a sua equipe de desenvolvimento.
No artigo “Estimating and Tracking Agile Projects”, Kane (2007) apresenta
diferentes unidades de estimativa para mensurar custo e tempo de desenvolvimento
como:
A. Story Point: relação entre as histórias do usuário, envolvendo os requisitos,
lista de recursos e os cenários de caso de uso.
B. Tempo ideal: tempo que uma tarefa leva para ser concluída sem que haja
interrupções.
C. Velocidade: mensura a quantidade de unidades de estimativa que foram
concluídas em uma única iteração.
KANE (2007) não apresenta uma aplicação das medidas sugeridas, apenas o
uso subjetivo da lista acima como unidade de estimativa, por exemplo, a indagação
de quantos story points foram estimados para serem incluídos no sprint.
O autor JOHAN (2000) classifica as métricas em três grandes áreas, havendo
para cada uma delas, uma tabela com questões a serem respondidas e
mensuradas. A abordagem sugerida é a Objetivo-Pergunta-Métrica e abaixo são
listadas as três áreas definidas por JOHAN (2000):
A. Gerenciamento de projetos e requisitos: define que o cliente deve estar
ativamente envolvido no processo, inclusive no processo de criar casos de
testes. Ainda, seguindo o desenvolvimento ágil, reforça que as sprints devem
acontecer de 2 a 8 semanas, com uma boa comunicação entre a equipe.
Nessa área, por exemplo, é possível medir o tempo de duração das reuniões
e classificá-las a partir de um tempo médio, definido pela equação TM.
TMi = (∑S) / Qi
onde:
TM = tempo médio
S = tempo de cada reunião
Q = quantidade de reuniões feitas durante o sprint
B. Desenvolvimento: estabelece que recursos e correções de bugs serão
divididos em sub tarefas menores, ou seja, uma atividade que leva cerca de
seis a dezoito horas para ser realizada. Nesse contexto, pode-se criar um
indicador que apresenta a quantidade de bugs em um sprint do product
backlog. O indicador pode ser mensurado pela seguinte forma:
Ik = (∑Sk)
onde:
Ik = indicador de bugs em um determinado sprint
Sk = bug ocorrido no sprint
C. Testes: enfatiza a importância de realizar a testagem do software,
preferencialmente utilizando testes automatizados. Com base no que é
proposto pelo autor, no âmbito dos testes, é possível criar um indicador
envolvendo a porcentagem de testes automatizados feitos com relação à
testes manuais:
TA = (A * 100) / M
onde:
TA = porcentagem de testes automatizados em relação aos testes manuais
A = quantidade de testes automatizados
M = quantidade de testes manuais
SATO (2007) classifica as métricas em dois grandes grupos e apresenta duas
formas de abordagem para realizar a medição:
A. Abordagem Objetivo-Pergunta-Métrica: proposta por Basili (1996), a
abordagem é dividida em três níveis: conceitual, operacional e quantitativa. O
nível conceitual abrange a visualização do objeto a partir de vários pontos de
vista, ou seja, assumindo diferentes papéis, o objetivo pode ser um produto,
um objeto ou recurso. No próximo ponto, no nível operacional, é o momento
da definição das perguntas como forma de avaliação, a partir de um pontode
vista escolhido no nível conceitual. Por fim, no último nível, na fase
quantitativa, as métricas surgem a partir da associação das perguntas
definidas com uma forma de respondê-las quantitativamente. Nessa
hierarquia, os três níveis se complementam, visto que a partir das perguntas
(operacional) é possível escolher as métricas (quantitativa).
B. Abordagem Lean: seu princípio geral é “otimizar um todo”, pois discerne bem
as métricas organizacionais das métricas de acompanhamento. Além disso,
propõe a utilização de métricas de acompanhamento, a fim de auxiliar a
equipe.
Para cada tipo de métrica o autor propõe diferentes implementações,
vejamos abaixo:
1. Métricas organizacionais
1.1. Funcionalidades testadas e entregues
Através dos testes de aceitação, o cliente define quando uma
funcionalidade está concluída e pronta para entrar em produção. A
expectativa é que a métrica cresça linearmente, considerando a data
de início e término do projeto e pode ser calculada pela equação:
RTF = ( TAP / QTD ) * 100
onde:
RTF: porcentagem de funcionalidades testadas e entregues
TAP: funcionalidades testadas e aceitas pelo cliente
QTD: quantidade total de funcionalidades do projeto.
1.2. Net Promoter Score (NPS)
Essa métrica tem como principal objetivo medir o grau de
satisfação dos clientes. Em uma escala de zero a dez, os clientes
avaliam o produto e os que votam entre nove e dez são denominados
clientes promotores. Já aqueles que votam entre sete e oito são
conhecidos como clientes neutros e por fim, aqueles que votam entre
zero e seis são chamados de clientes afastadores. O valor da métrica
pode variar de -100% a 100% e pode ser calculada pela seguinte
equação inferida por este autor:
NPS = [ ( P - A ) / QTD ] * 100
onde:
NPS: Net Promoter Score
P: clientes promotores
A: clientes afastadores
QTD: quantidade total de clientes
2. Métricas de acompanhamento
2.1. Fator de integração
Elaborada pelo SATO (2007), a métrica “fator de integração”
relaciona a quantidade de novas integrações e alterações feitas na
iteração, definida pela equação abaixo:
IFi = (LAi + LRi + LUi) / TCi
onde:
LAi = número total de linhas adicionadas na iteração i
LRi = número total de linhas removidas na iteração i
LUi = número total de linhas atualizadas na iteração i
TCi = número total de commits na iteração i
2.2. Fator de teste
O fator de teste proposto por SATO(2007) é a relação da
quantidade de linhas referente à códigos de teste e a quantidade de linhas
pertinente à códigos de produção. É uma métrica que pode servir como
parâmetro para avaliar área de testes de uma organização, visto que pode
impactar diretamente na qualidade do que é entregue ao cliente. É definida
pela equação:
FTi = LCTi / LCPi
onde:
FTi = fator de teste na iteração i
LCTi = quantidade de linhas de código de teste na iteração i
LCPi = quantidade de linhas de produção na iteração i
Ikoma et al (2009) apresentaram um modelo de validação com o intuito de
medir a agilidade em processos de desenvolvimento de software, o modelo também
é conhecido pela sigla V&V. O modelo é composto por estados, onde cada sprint é
validado por eles, inicia-se quando o item irá ser validado pelo estado denominado
“planejamento identificado”. A métrica sugerida no artigo também é baseada na
abordagem Objetivo-Pergunta-Métrica de Basili.
Ikoma et al (2009) definem a métrica de agilidade de desenvolvimento de um
determinado software pela seguinte equação:
A = V / U
onde:
A: agilidade do desenvolvimento
V: quantidade de funcionalidades validadas no período
U: quantidade média de funcionalidades não validadas no período
Em seu artigo, Bonfim (2013) cita boas características de boas métricas ágeis
e menciona algumas, como:
A. Quantidade de interrupções: trata-se de um indicador de tarefas
interrompidas, impactando em atrasos de entrega. Inferida por este autor, a
equação abaixo representa a métrica de quantidade de interrupções em uma
determinada sprint.
Qk = (∑Ik)
onde:
Qk = indicador de quantidade de interrupções nas tarefas do projeto
Ik = quantidade de interrupções nas tarefas do projeto
B. Pareamento: representa a quantidade de pares de programação formados
dentro do time. O autor não apresenta uma forma quantificada de
apresentação e nem de resultado.
C. Valor entregue: essa métrica apresenta o somatório do valor do negócio
entregue em cada história de usuário, podendo ser quantificado em forma de
número ou valor financeiro. Esse cálculo deve ser feito pelo Product Owner e
pode ser representada pela equação abaixo inferida por este autor:
VEi = (∑Vi)
onde:
VEi = valor entregue por sprint
Vi = valor entregue em cada história de usuário da sprint
D. Quantidade de itens não previstos: identifica a quantidade de itens
implementados durante a sprint, mas que não foram previstos no
planejamento. A métrica tem como principal objetivo identificar falhas no
planejamento e pode ser mensurada pela equação abaixo inferida por este
autor:
Qi = (∑INPi)
onde:
Qi = quantidade de itens não previstos na sprint
INPi = itens não previstos durante o planejamento
2.3. QLIK SENSE
< COLOCAR AQUI CONCEITOS DE BI E DO QLIK SENSE>
Apesar da empresa Gartner Group originar o termo Business Intelligence (BI)
em meados da década de 90, o conceito de BI foi sendo construído desde os anos
70, iniciando com relatórios fixos e não dinâmicos até a década de 80, onde, por
exemplo, surgiram relatórios do tipo dinâmicos multidimensionais, prognósticos e
análise de tendência (PEREIRA, 2020). De acordo com PHAN e VOGEL (2010), o
cenário empresarial passou a ser cada vez mais competitivo conforme a aplicação
de tecnologias de informação crescia na sociedade e dessa forma, o BI é utilizado
como um auxílio em tomadas de decisão e pesquisas de mercado.
Do ponto de vista técnico, o BI se refere ao processo de extrair, transformar e
analisar os dados de uma organização ou negócio. Em grandes conjuntos de dados,
conhecidos como data warehouse, esse processo possui cinco estágios principais:
(NEGASH; GRAY, 2008)
1. Data sourcing
O estágio de extração define que os dados podem ser extraídos de múltiplas
fontes e diferentes unidades do negócio, como por exemplo, recursos humanos e
marketing.
2. Data Analysis
Nesse momento, os dados brutos são transformados em informação
utilizando variadas formas de análise de dados, com o objetivo de alcançar uma
melhor compreensão do ambiente para auxiliar os dirigentes da organização na
tomada de decisão.
3. Situation Awareness
Esse estágio é um pré-requisito para a tomada de decisão, pois é uma
compreensão profunda fundamentada nos resultados da análise de dados.
4. Risk Assessment
A fase de avaliação de risco atua em previsões sobre o futuro, identificando
ameaças e oportunidades com o objetivo de diminuir os riscos externos e internos
de um negócio.
5. Decision Support
O objetivo final do BI, após todos os estágios, é fornecer um suporte na
tomada de decisões, sempre baseadas nos dados atuais do negócio.
Adentrando o mundo do BI, existem inúmeras ferramentas do gênero, dentre
elas, o Qlik Sense. A empresa Qlik é líder de mercado na área de Business
Discovery, cuja referência é um tipo de BI, orientado ao usuário e que auxilia no
processo de tomada de decisão através de várias fontes de percepções: dados,
pessoas e lugares (Biggdata, 2021).
De acordo com HAND e KHARPATE (2015), o Business Intelligence passou
por uma mudança de paradigma a partir de 2013, aumentando o nível de
compreensão de mercado e aprendizado com as experiências dos clientes. Ainda,
os autores definem o Qlik Sense, que foi apresentado em meados de 2014, como
uma plataforma de visualização de dados de autoatendimento, onde permite aos
usuários criarem seus próprios aplicativos arrastando e soltando.
O Qlik Sense é classificado como uma plataforma de self service, que
possibilita uma autonomia a seus usuários para gerarem suas próprias análises e
oferece duas versões: desktop disponível para download e web (GEORG, 2017).
O software possui um mecanismo de análise queajuda o usuário a classificar
seus dados e escolher o que vai ser analisado de acordo com o seu interesse. Para
auxiliar nessa tarefa, o Qlik Sense oferece mais de quinze gráficos, por exemplo,
gráficos de barras e de dispersão (SALAS e BRUCE, 2020).
De acordo com MANZONE (2021), a empresa Qlik, que nasceu através de
um projeto de dois professores universitários suecos, se tornou uma das maiores
multinacionais e seu aplicativo Qlik Sense se destaca no mercado por conta do seu
motor associativo de dados. Essa técnica permite carregar todos seus dados e
relacioná-los, mesmo que tenham diferentes granularidades e cardinalidades.
texto
3. MÉTODO
Um dos objetivos do convênio entre a UFMT e o TCE-MT é promover o
aperfeiçoamento e inovação dos sistemas e tecnologias utilizadas no TCE-MT.
Sendo assim, para desenvolver um estudo de caso, foi empregado o uso de uma
pesquisa explicativa, cujo propósito é identificar os fatores que determinam ou que
contribuem para a ocorrência dos fenômenos, aprofundando o conhecimento da
realidade [GIL 2002].
Considerando que a equipe de desenvolvimento da instituição adota o
Redmine - software livre para gerenciar projetos - foi possível, por meio de uma
integração com o Qlik Sense, extrair dados com a finalidade de organizá-los e
ordená-los, gerando uma fonte de informação que transmita significado e
compreensão sobre o contexto do TCE-MT. Vale ressaltar que a amostra de dados
mencionada e que foi implementada no Qlik Sense se refere ao projeto denominado
Conex-e - sistema de controle eletrônico externo - devido o mesmo possuir uma
documentação mais abrangente dentro do Redmine em relação aos outros que
estão disponibilizados.
4. RESULTADOS E DISCUSSÃO
<COLOCAR AQUI AS TELAS E EXPLICAÇÃO COM TODAS AS MÉTRICAS IMPLEMENTADAS>
Com o objetivo de aplicar o uso das métricas elencadas na seção 2.2, a fonte
de dados utilizada no Qlik Sense foi extraída do sistema Redmine do TCE/MT. A
instituição possui um vasto catálogo de projetos, dentre eles, o Conex-e - sistema
de controle externo eletrônico - cujos dados foram selecionados para serem
empregados nessa ferramenta de BI devido sua documentação ser mais
abrangente.
A extração mencionada foi feita de forma manual, entretanto, vale ressaltar
que o Qlik permite conexões à fonte de dados externas, como por exemplo: Amazon
S3, Facebook Insights, bancos de dados, etc. Nesse caso de uso, a importação será
de dados manuais provenientes de um arquivo .xlsx e após concluir essa etapa, o
qlik sense exibe um overview de seus dados e permite aplicar edições, como a
seleção de colunas da sua fonte de dados, ilustrado na figura abaixo:
Imagem 2: seleção dos dados dentro do Qlik Sense
Fonte: elaborado pelo autor
Concluído o carregamento dos dados, a ferramenta exibe o dashboard de
sua pasta, onde é possível construir a visualização dos seus dados para o usuário,
arrastando os componentes - que podem ser campos, gráficos, itens mestre ou
objetos personalizados - para o grid da pasta, exemplificado na imagem 3:
Imagem 3: edição de pasta
Fonte: elaborado pelo autor
Com o objetivo de facilitar a construção de gráficos ou outro componente
visual, o qlik oferece o recurso de itens mestres, subdividindo em dimensões e
medidas. A dimensão se refere ao agrupamento dos dados na visualização, sendo
assim, no estudo fictício, o campo “lista de sprints” foi definido como uma dimensão,
para que o usuário analise os dados de todo o projeto ou apenas os dados de uma
sprint em específico.
Imagem 4: criação de uma dimensão
Fonte: elaborado pelo autor
As medidas do Qlik Sense, no contexto do artigo, representam o ponto
chave: o cálculo e apresentação das métricas do SCRUM. Sendo assim, para criar
uma medida é necessário definir um nome, descrição e a expressão, onde que
dentro do editor de expressões, inserimos as equações referentes à cada métrica.
Imagem 5: criação de uma medida
Fonte: elaborado pelo autor
No campo expressão, dentro do editor, é possível selecionar campos da sua
fonte de dados para incorporar o cálculo da métrica, representada pela medida.
Ainda, o qlik sense permite que esses campos sejam submetidos a funções de
agregação, por exemplo: sum, count, avg, etc.
Imagem 6: editor de expressões
Fonte: elaborado pelo autor
Concluída a criação da medida, a ferramenta já permite que o componente
novo seja arrastado para o grid, mas sem criar um gráfico, exibindo apenas o valor
calculado (imagem 8). Para plotar um gráfico, o qlik sense oferece modelos prontos
que, após arrastar o desejado, necessita que seja definido uma dimensão e medida
(imagem 7).
Imagem 7: adicionando um gráfico de barras
Fonte: elaborado pelo autor
Imagem 8: visualização direta sem gráfico
Fonte: elaborado pelo autor
Como exemplo, a dimensão selecionada corresponde à lista de sprints e a
medida à métrica de quantidade de itens não previstos. O design escolhido foi o de
gráfico de barras e definido um título através das propriedades do componente
visual.
Imagem 9: adicionando e editando componente gráfico
Fonte: elaborado pelo autor
Partilhando da mesma lógica apresentada no exemplo e utilizando os dados
providos do cenário de caso de uso mencionado no início da seção, foram criadas
duas pastas - devido à limitação da ferramenta - para exibir graficamente seis dentre
as dezoito métricas discutidas no artigo. Abaixo, na sequência de imagens, é
apresentada a visualização desses dados e cálculo das métricas utilizando o qlik
sense.
Imagem 10: pasta radar SCRUM
Fonte: elaborado pelo autor
Imagem 11: pasta radar SCRUM 2
Fonte: elaborado pelo autor
É válido ressaltar que os valores que constam nos gráficos acima são
absolutos, ou seja, o somatório de todas as sprints. O qlik sense permite de uma
forma muito interativa filtrar os dados de acordo com a sua dimensão, que nesse
estudo de caso, corresponde à lista de sprints. Dessa forma, clicando sobre algum
ponto correspondente à alguma sprint ou clicando e arrastando o mouse para
selecionar um conjunto de dados, a ferramenta implementa o filtro para todos os
gráficos da pasta, de acordo com a seleção. Abaixo, é exemplificado a seleção
múltipla e em seguida a seleção unitária de uma sprint.
Imagem 12: filtro de seleção múltipla
Fonte: elaborado pelo autor
Imagem 13: filtro de seleção unitária
<Para discussão faremos uma reunião com Aline para saber quais foram (ou serão) as melhorias
obtidas com a implementação das métricas>
5. Considerações finais
<Fazer um comparativo entre artigos semelhantes e seu artigo, destacar a
relevância deste artigo, destacar os benefícios gerais da mensuração de projetos de
scrum no TCE e como poderão ser generalizados para outras organizações.>
Referências bibliográficas
BONFIM, M. A importância das métricas para equipes agéis. 2013. Disponível
em:
<http://www.devmedia.com.br/a-importancia-das-metricas-para-equipes-ageis/28542
#ixzz2idwKEJhi>.
Acesso em 17 de março de 2021.
RAM, P. .Agile Metrics: A seminal approach for calculating Metrics in Agile Projects,
2009. Disponível em
<https://www.projectsmart.co.uk/agile-metrics-a-seminal-approach-for-calculating-me
trics-in-agile-projects.php>. Acesso em 17 de março de 2021.
KANE, B. Estimating and Tracking Agile Projects, 2007. Disponível em:
<https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.104.8139&rep=rep1&typ
e=pdf>. Acesso em 17 de março de 2021.
JOHAN, P. Quantitative Approach for Lightweight Agile Process Assessment, 2000.
Disponível em:
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.609.210&rep=rep1&type
=pdf>. Acesso em 17 de março de 2021.
SATO, D. T.. Uso eficaz de métricas em métodos ágeis de desenvolvimento de
software. São Paulo, 2007. Disponível em:
<http://ccsl.ime.usp.br/agilcoop/files/dissertacao.pdf>. Acesso em 17 de março de
2021.
SATO, D. T. Métricas de acompanhamento para metodologias ágeis. 2009.
Disponível em: <
http://www.devmedia.com.br/artigo-engenharia-de-software-12-metricas-de-acompa
nhamento-
para-metodologias-ageis/12562 >. Acesso em 17 de marçode 2021.
IKOMA, M.; OOSHIMA, M.; TANIDA,T.; OBA, M.; SAKAI, S. Using a Validation
Model to Measure the
Agility of Software Development in a Large Software Development Organization.
Disponível em: <https://ieeexplore.ieee.org/abstract/document/5070967>
Desenvolvimento ágil: o que é, princípios e como aplicar. FIA, 2019. Disponível em:
<https://fia.com.br/blog/desenvolvimento-agil/>. Acesso em 23/03/2021.
Introdução ao Desenvolvimento Ágil. Devmedia, 2007. Disponível em:
<https://www.devmedia.com.br/introducao-ao-desenvolvimento-agil/5916>. Acesso
em 23/03/2021.
ANDRADE, Marcio Roberto. Metodologia Scrum: o que é, métodos ágeis e guia
prático, 2019. Disponível em: <https://blog.contaazul.com/metodologia-scrum>.
Acesso em 23/03/2021.
Scrum: A Metodologia Ágil Explicada de forma Definitiva. Disponível em:
<https://mindmaster.com.br/scrum/>. Acesso em 23/03/2021.
Scrum: O que é?. Project Builder, 2020. Disponível em
<https://www.projectbuilder.com.br/blog/o-que-e-scrum/>. Acesso em 30/03/2021
SCHWABER, K.; SUTHERLAND, J. Guia do Scrum - Um guia definitivo para o
Scrum: As regras do jogo. 2013. Disponível em:
<https://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf
>. Acesso em: 20/04/2021.
SCHWABER, K.; SUTHERLAND, J. Guia do Scrum – Um guia definitivo para o
Scrum: As regras do jogo. 2020. Disponível em:
<https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-PortugueseBR
.pdf>. Acesso em: 20/04/2021.
SUTHERLAND, J. Scrum: a arte de fazer o dobro do trabalho na metade do tempo.
São Paulo; Leya, 2014.
BECK, K. S. K. S. J. E. A.; Manifesto for agile software development. Disponível em:
<http://agilemanifesto.org/>. Acesso em 19/05/2021
PEREIRA, Paulo; TORREÃO, Paula; MARÇAL, Ana Sofia. Entendendo Scrum para
Gerenciar Projetos de Forma Ágil, 2007. Disponível em:
<https://www.academia.edu/download/49393858/EntendendoScrumparaGerenciarPr
ojetosdeFormaAgil.pdf>. Acesso em 20/05/2021
COBB, Charles G. The project manager's guide to mastering Agile: Principles and
practices for an adaptive approach. USA: John Wiley & Sons, 2015.
PEREIRA, Leonardo Viana. Business Intelligence como apoio a tomada de decisão:
um estudo de caso na At Hand Tecnologia. Trabalho de Conclusão de Curso. Centro
Universitário Unidade de Ensino Superior Dom Bosco. São Luís, p. 73. 2020
https://www.projectbuilder.com.br/blog/o-que-e-scrum/
PHAN, Dian. D.; VOGEL, Doug. A model of customer relationship management and
business intelligence systems for catalogue and online retailers. Information &
Management, Vol.47. 2010.
NEGASH, Solomon. GRAY, Paul. Business Intelligence. In: Handbook on Decision
Support Systems 2, 2008. International Handbooks Information System. Springer,
Berlin, Heidelberg. https://doi.org/10.1007/978-3-540-48716-6_9
Biggdata. Qlik Sense Business Discovery, 2021. Disponível em:
<http://www.biggdata.com.br/social-business-discovery>. Acesso em 11/06/2021.
HAND, Philip. KHARPATE, Neeraj. Qlik Sense® Cookbook. Packt Publishing, 2015.
SALAS, Nicolás. BRUCE, Niklas. Making Sense of Multivariate Data: An Iterative
Design of the Visualization and Interactions with Parallel Coordinates, 2020.
Master Thesis. Lundi University. Lundi.
GEORG, Juliana. 2017. Business Intelligence para gestão de vendas do setor
de E-Commerce utilizando Qlik Sense. Trabalho de Conclusão de Curso.
Universidade Regional de Blumenau. Blumenau.
POHL, Christoph. HOF,Hans-Joachim. Secure Scrum: Development of Secure
Software with Scrum, 2015. Disponível em: <https://arxiv.org/pdf/1507.02992.pdf>.
Acesso em 16/06/2021.
MUNDRA, Ashish. MISRA, Sanjay. DHAWALE, Chitra A. Practical Scrum-Scrum
Team: Way to Produce Successful and Quality Software, 2013. 13th International
Conference on Computational Science and Its Applications.
GONÇALVES, Luis. Scrum, 2018. Control Manag Rev 62, 40–42. Disponível em:
<https://doi.org/10.1007/s12176-018-0020-3>. Acesso em 18/06/2021.
FOWLER, Frederik M. Scrum Events. In: Navigating Hybrid Scrum Environments,
2018. Apress, Berkeley, CA. Disponível em:
<https://doi.org/10.1007/978-1-4842-4164-6_11>. Acesso em 18/06/2021.
MANZONE, Valentina. Business Intelligence tramite piattaforma Qlik Sense: un caso
di studio, 2021. Politecnico di Torino, dissertação de mestrado. Disponível em:
<https://webthesis.biblio.polito.it/17347/1/tesi.pdf>. Acesso em 21/06/2021.
GIL, A. C. Como elaborar projetos de pesquisa. 4.ed. S�o Paulo: Atlas, 2002.
links interessantes:
https://medium.com/produto-di%C3%A1rio/o-que-%C3%A9-um-product-owner-c44b
b29a9f66