Ferramenta Gamificada: mudanças entre as edições
| Linha 189: | Linha 189: | ||
*'''De Usuário''' são requisitos que formam uma função completa ou um processo elementar do sistema. | *'''De Usuário''' são requisitos que formam uma função completa ou um processo elementar do sistema. | ||
*'''Sub-Funções''' são requisitos que compoem requisitos de usuário ou seja, não são funções completas apenas partes de outras funções. | *'''Sub-Funções''' são requisitos que compoem requisitos de usuário ou seja, não são funções completas apenas partes de outras funções. | ||
O cronograma de desenvolvimento da ferramenta pode ser acompanhado pelo quadro na ferramenta Trello: | |||
[[https://trello.com/b/RNKJvhqU Quadro de tarefas]] | |||
==Referências== | ==Referências== | ||
Edição das 15h45min de 25 de agosto de 2017
Ferramenta Gamificada
Equipe
- Professore orientadores
- Estevan Brandt Braz Costa
- Alcione Benacchio
- Aluno
- Victor Hartur de Carvalho Blosquievis
- Ano
- 2017
Objetivo
Desenvolver uma gamificação e uma ferramenta para ser usada em empresas de desenvolvimento de software, aumentando o engajamento na produção de artefatos de qualidade e por consequência contribuindo no aumento da qualidade do produto final. A ferramenta visa também facilitar o feedback entre Programadores/Engenheiros de Software e Gerente de Qualidade.
Problema
O MPS-BR ou Melhoria de Processos do Software Brasileiro, é um modelo de qualidade de processo criado em 2003 pela Softex (Associação para Promoção da Excelência do Software Brasileiro) para melhorar a capacidade de desenvolvimento de software nas empresas brasileiras. Para a definição do MPS-BR levou em consideração normas e modelos internacionalmente reconhecidos como CMMI (Capability Maturity Model Integration), e nas normas ISO/IEC 12207 e ISO/IEC 15504 e na realidade do mercado brasileiro de software.
Os níveis de maturidade no modelo MPS-BR estabelecem patamares de evolução dos processos. O nível de maturidade em que se encontra uma organização permite prever o seu desempenho futuro ao executar um ou mais processos. O modelo define sete níveis de maturidade:
- A (Em Otimização);
- B (Gerenciado Quantitativamente);
- C (Definido);
- D (Largamente Definido);
- E (Parcialmente Definido);
- F (Gerenciado);
- G (Parcialmente Gerenciado).
Sendo o nível G o primeiro a ser implementado e o nível A o nível máximo que a empresa poderá atingir.[1]
O objetivo da ferramenta é aumentar o engajamento na produção de alguns artefatos que são requeridos em um determinado nível do MPS-BR, pois, observou-se que por ser um trabalho repetitivo e maçante gera um certo descontentamento e negligência na produção desses artefatos.
Proposta
A proposta é desenvolver uma gamificação (Estrutura) que, por meio de recompensas virtuais e reais estimule os colaboradores a produzir os artefatos de qualidade. Por consequência da maior produção de artefatos, existe a possibilidade de que os colaboradores tenham maior ciencia a respeito de erros/bugs no produto final e dessa forma procurem soluções no momento oportuno, aumentando a qualidade do produto final. Também será desenvolvida uma ferramenta que irá implementar a gamificação para auxiliar na obtenção de dados e oferecer feedback sobre o progresso dos jogadores.
Project Canvas
http://app.projectcanvas.online/#/board/IScYajFwysxQCBF1QyyGFOFJtWIh1hl5xxpQZJ7fM8=/public
Protótipos de baixa fidelidade
Público Alvo
Empresas de desenvolvimento de software que implementam algum processo de qualidade envolvendo produção de artefatos (Arquivos, Checklists...), em especial empresas que implementam o MPS-BR.
Será utilizado como modelo uma empresa que funciona como fábrica de software certificada com MPS-BR nível F, localizada em Foz do Iguaçu, Paraná, Brasil, com aproximadamente 30 colaboradores sendo aproximadamente 15 da área operacional da fabrica, responsáveis pela produção da maior parte dos artefatos de qualidade.
Principais Funcionalidades
- Monitoramento e gerenciamento de commits
- Gerenciamento de usuários
- Gerenciamento de projetos e ciclos
- Feedback de progresso dos jogadores
- Ranking de jogadores
- Badges/Medalhas (Recompensas virtuais)
Cronologia
Gamificação
A gamificação foi estruturada da seguinte maneira:
Mecânicas
Foram selecionadas algumas mecânicas de gamificação de acordo com os seguintes critérios:
- Perfil de jogador indicado (Levando em conta os perfis presentes na fabrica usada como base)
- Relação com o problema (O quanto a mecanica auxilia na resolução do problema)
- Dificuldade de implementação
As mecânicas selecionadas foram as seguintes [2]:
- Tutorials
- Progress
- Flow
- Consequences
- Social Status
- Social Discovery
- Level
- Learning
- Light Touch
- Points
- Physical Rewards
- Leaderboards
- Badges
Ações Relevantes
As ações relevantes são ações executadas no sistema que oferecem pontuação para os jogadores. Após estudos foram elicitadas as seguintes açõess relevantes:
- Commit
- Artefato avaliado sem erros
- Ciclo completo
- Projeto completo
- Não conformidade
- Reporte de Bug
- Commit incorreto
Depois de testes foi estipulado uma pontuação para cada ação relevante, a relação de ação e pontuação final foi a seguinte:
| Ação relevante | Pontuação |
|---|---|
| Commit | 50 |
| Artefato avaliado sem erros | 100 |
| Sprint completa com todos artefatos | 400 |
| Sprint completa com todos artefatos sem erros | 500 |
| Projeto completo com todos artefatos | 600 |
| Projeto completo com todos artefatos sem erros | 800 |
| Não conformidade | -25 |
| Finalizar sprint faltando artefatos | -100 Por artefato |
| Bug reportado por cliente e validado | -200 Por Bug |
| Envio incorreto (Com tag mas faltando artefatos) | -500 |
Níveis
Após os testes com a pontuação chegou-se a conclusão que o melhor seria fazer a evolução com valores fixos de pontuação e não progressivos. A relação de níveis e pontuações se encontra na tabela a baixo:
| Nível | Pontuação |
|---|---|
| Nível 1 | 0-99 |
| Nível 2 | 100-499 |
| Nível 3 | 500-999 |
| Nível 4 | 1000-1499 |
| ... | ... |
A partir do nível 4 o jogador sobe 1 nível a cada 500 pontos.
Caso o jogador tenha sua pontuação reduzida a baixo do mínimo necessário para o nível ele tem seu nível rebaixado. Ex:
Jogador nível 5 tem 1500 pontos e perdeu 100 pontos, sua pontuação é rebaixada para 1400 e ele retorna para o nível 4.
Medalhas
Foram criadas algumas medalhas que serão usadas como recompensa virtual, a relação de medalhas está na tabela a seguir:
| Medalha | Icone |
|---|---|
| Primeiro Envio | * |
| 10 Envios | * |
| 25 Envios | * |
| 50 Envios | * |
| 5 envios consecutivos sem NCs* | * |
| 10 envios consecutivos sem NCs* | * |
| 20 envios consecutivos sem NCs* | * |
| Nível 5 | * |
| Nível 10 | * |
| Nível 20 | * |
| Nível 50 | * |
O Jogador nunca perderá suas medalhas, uma vez obtida ela é vinculada ao seu perfil por tempo indeterminado.
Ferramenta
A arquitetura da ferramenta será composta pelo framework Angular 2[3] em sua versão 4.3.2, também será utilizada a plataforma Firebase[4] para persistencia de dados em banco de dados tempo real e autenticação de usuários.
Como o framework Angular 2 é baseado em webcomponents serão utlizados alguns sets de componentes, são eles:
Para a integração entre o framework Angular 2 e a plataforma Firebase será utilizado o plugin oficial angularfire2[7] desenvolvido pela própria Firebase na versão 4.0.0-rc.1 e a biblioteca firebase[8] também desenvolvido pela empresa detentora da plataforma na versão 4.2.0, para desenvolvimento será utilizado um servidor node.js[9] na versão 8.1.0, o assistente angular-cli[10] na versão 1.2.6, a linguagem typescript[11] na versão 2.4.1 e o editor de texto Visual Studio Code[12] em sua versão 1.14.2.
Todas as ferramentas utilizadas são grátis ou opensource e estão em desenvolvimento, ou seja, estão recebendo atualizações constantes, portanto algumas versões poderão ser alteradas até o fim do projeto.
Os requisitos serão elicitados em 3 níveis, Agregadores, de Usuário e Sub-Função onde:
- Agregadores são requisitos que englobam requisitos de usuários.
- De Usuário são requisitos que formam uma função completa ou um processo elementar do sistema.
- Sub-Funções são requisitos que compoem requisitos de usuário ou seja, não são funções completas apenas partes de outras funções.
O cronograma de desenvolvimento da ferramenta pode ser acompanhado pelo quadro na ferramenta Trello: [Quadro de tarefas]
Referências
- ↑ Blog da Qualidade, O que é o MPS-BR?, ([blogdaqualidade.com.br])
- ↑ Gamified.uk,52 Gamification Mechanics and Elements, [gamified.uk]
- ↑ Angular 2, Angular 2, [angular.io]
- ↑ Firebase, Firebase, [firebase.google.com]
- ↑ Angular Material 2, Angular Material, [material.angular.io]
- ↑ Teradata Covalent, Teradata Covalent, [teradata.github.io/covalent]
- ↑ Angular Fire 2, Angular Fire 2, [github.com/angular/angularfire2]
- ↑ Firebase, Firebase JS SDK, [github.com/firebase/firebase-js-sdk]
- ↑ Node.Js, Node.Js, [Node.Js]
- ↑ Angular CLI, Angular CLI, [cli.angular.io]
- ↑ Typescript, Typescript, [typescriptlang.org]
- ↑ Visual Studio Code, VSCode, [code.visualstudio.com]
