gpoesia / cmmi-game Goto Github PK

Integrar os mini-games do nível 3 em um único nível.
Fazer seus mini-games serem dependentes.

Definir as características do nível 1.
O nível 1 representa o caos na empresa, antes de se decidir utilizar o CMMI.
Esta tarefa está alocada para @pratlucas e @althoff.

A tela conterá uma descrição do primeiro mini-game relacionado ao nível 4. Do email de discussão:

"O primeiro mini-game trata da meta "Establish Performance Baselines and Models", e é jogado na visão do próprio CEO da empresa. Nesse mini-game, o CEO vai ter que definir algumas métricas de qualidade dos projetos que, na história, vão ser estabelecidas como metas para os projetos. Pensei em ele definir:

• Número de bugs por ponto de função (máximo)
• Fração do código coberto por testes automatizados (mínimo)
• Fração do código revisado por um desenvolvedor que não escreveu o código (mínimo)
• Horas por ponto de função (máximo)
• Fração dos requisitos que precisaram de revisão (máximo)

Essa definição seria por meio de sliders (http://www.tophatstuff.co.uk/uploaded/20100220201958_hag_sliders.png). O objetivo do jogador seria definir valores que sejam coerentes entre si no menor número de tentativas. O jogador deve colocar os valores que quiser nas barrinhas e clicar em um botão para "Experimentar em um projeto", que faria com que, na história, um projeto na organização fosse conduzido com os valores informados como metas. O resultado do projeto seria então informado por meio de uma mensagem, e o jogador poderia ou passar de nível (se o projeto teve sucesso) ou rever as métricas (se o projeto falhou). Motivos de falhas, que vão ser as mensagens, vão ser do tipo:

• Que pena! O número de horas máximo por ponto de função que você determinou fez com que os programadores corressem demais. O número de bugs por ponto de função no projeto foi absurdo, e isso fez com que o custo fosse alto demais!
• Que pena! Sem uma meta alta, seus programadores não escreveram suficientes testes automatizados. Com isso, muitos bugs foram reintroduzidos depois de corrigidos, por não haver testes de regressão. Quem confiará no projeto entregue?
• Que triste. Como você não permitiu que os requisitos fossem alterados algumas vezes, os analistas medrosos realizaram dezenas de reuniões de levantamento e consolidação de requisitos com os clientes. Isso atrasou muito o início do desenvolvimento e os clientes reclamaram do tempo que gastaram com isso, além do custo alto do projeto.
• É... como você permitiu que os requisitos fossem muito alterados, eles foram muito mal escritos no início do projeto. Com isso, somente em reuniões de apresentação de entregas parciais é que vocês descobriram que o cliente queria funcionalidades muito diferentes! Isso atrasou o projeto e aumentou muito seu custo, por causa das mudanças tardias em requisitos.

E outras neste estilo. A pontuação do jogador seria inversamente proporcional ao número de tentativas que ele usou antes de conseguir um projeto de sucesso."

Ele triga alguma ação que faz com que uma excessão seja gerada

Definir as características do nível 4.
O nível 4 representa a empresa no nível 3 de maturidade, buscando alcançar o nível 4.
Esta tarefa está alocada para @gpoesia e @bolobr.

Baseado nos requisitos apresentados em #10 e em uma coleção de "módulos", que representam recursos técnicos disponíveis para a implementação (Banco de Dados, acesso remoto, etc), o jogador deverá selecionar quais recursos irão cumprir quais requisitos.

Esses recursos são da forma de caixas (com imagens nas últimas iterações do projeto) e, possivelmente, com facilidades do tipo drag 'n' drop.

O personagem responsável por essa tarefa, mais uma vez, irá depender de definições da história do jogo em si, mas a princípio teriamos um ou mais "Software Designers", de ofício ou apenas exercendo o papel, como atores da tarefa de encontrar a solução técnica para o problema levantado.

Responsáveis: @gcmgomes e @thiagorpp

Devemos salvar dados em cache que nos permitam, ao iniciar o jogo, dar ao usuário, a opção de continuar um jogo que já estava em andamento.

Este requisito pode ser ignorado, caso o prazo esteja muito perto, mas deve ser informado na apresentação final do produto.

Implementar tela em que o jogador efetivamente jogará o primeiro mini-game do nível 4. O mini-game está descrito abaixo:

"O primeiro mini-game trata da meta "Establish Performance Baselines and Models", e é jogado na visão do próprio CEO da empresa. Nesse mini-game, o CEO vai ter que definir algumas métricas de qualidade dos projetos que, na história, vão ser estabelecidas como metas para os projetos. Pensei em ele definir:

• Número de bugs por ponto de função (máximo)
• Fração do código coberto por testes automatizados (mínimo)
• Fração do código revisado por um desenvolvedor que não escreveu o código (mínimo)
• Horas por ponto de função (máximo)
• Fração dos requisitos que precisaram de revisão (máximo)

Essa definição seria por meio de sliders (http://www.tophatstuff.co.uk/uploaded/20100220201958_hag_sliders.png). O objetivo do jogador seria definir valores que sejam coerentes entre si no menor número de tentativas. O jogador deve colocar os valores que quiser nas barrinhas e clicar em um botão para "Experimentar em um projeto", que faria com que, na história, um projeto na organização fosse conduzido com os valores informados como metas. O resultado do projeto seria então informado por meio de uma mensagem, e o jogador poderia ou passar de nível (se o projeto teve sucesso) ou rever as métricas (se o projeto falhou). Motivos de falhas, que vão ser as mensagens, vão ser do tipo:

• Que pena! O número de horas máximo por ponto de função que você determinou fez com que os programadores corressem demais. O número de bugs por ponto de função no projeto foi absurdo, e isso fez com que o custo fosse alto demais!
• Que pena! Sem uma meta alta, seus programadores não escreveram suficientes testes automatizados. Com isso, muitos bugs foram reintroduzidos depois de corrigidos, por não haver testes de regressão. Quem confiará no projeto entregue?
• Que triste. Como você não permitiu que os requisitos fossem alterados algumas vezes, os analistas medrosos realizaram dezenas de reuniões de levantamento e consolidação de requisitos com os clientes. Isso atrasou muito o início do desenvolvimento e os clientes reclamaram do tempo que gastaram com isso, além do custo alto do projeto.
• É... como você permitiu que os requisitos fossem muito alterados, eles foram muito mal escritos no início do projeto. Com isso, somente em reuniões de apresentação de entregas parciais é que vocês descobriram que o cliente queria funcionalidades muito diferentes! Isso atrasou o projeto e aumentou muito seu custo, por causa das mudanças tardias em requisitos.

E outras neste estilo. A pontuação do jogador seria inversamente proporcional ao número de tentativas que ele usou antes de conseguir um projeto de sucesso."

Os sliders podem ser substituídos por outra widget caso a MelonJS não tenha sliders já implementados.

Definir as características do nível 2.
O nível dois representa a empresa no nível 1 do CMMI, buscando se certificar no vível 2.
Esta tarefa está alocada para @pratlucas e @althoff.

Menu inicial que apresenta apenas os níveis que já foram desbloqueados pelo jogo, levando em conta todos os critérios de dependência entre níveis.

Os níveis liberados serão retirados do arquivo salvo em cache.

Realizar:
-Testes manuais:
. Verificar colisões;
. Verificar/Garantir se o personagem não sai da tela de jogo;
. Verificar se a pontuação é corretamente atualizada.
Desejo:
. Criar testes automatizados

-Testes realizados por terceiros:
. Coletar feedback quanto ao "gameplay"

A tela deverá conter uma descrição do segundo mini-game do nível 4. Do email de discussão:

"O segundo mini-game seria sobre o objetivo "Quantitatively Manage the Project", assumindo que a empresa já definiu como vai gerenciar o projeto (além de eu não ter imaginado um jogo sobre isso, é mais fácil fixar isso porque senão o terceiro mini-game provavelmente seria dependente desse segundo, o que aumentaria a complexidade do jogo). Pensei em esse ser um mini-game parecido com aquele de marretar as marmotas, com base na prática específica SP 2.2 (Manage Project Performance). As marmotas seriam botões com número escrito. Cada botão estaria associado a uma das métricas que foi definida no mini-game anterior (isso deve ficar claro na interface). Quando o botão aparece, o número sobre ele é um valor para a métrica que foi medido durante o projeto. Se ele for ruim (acima do máximo ou abaixo do mínimo definido no último mini-game, dependendo se foi definido máximo ou mínimo), o usuário deve clicar nesse botão, o que representa tomar alguma atitude para melhorar a métrica. Se o usuário clicar num botão com uma métrica "boa" (dentro do limite), ele perde pontos por desperdício. Se não clicar no botão antes de ele abaixar, ele perde pontos por aumentar o custo do projeto. Senão, ele ganha pontos. O objetivo é chegar em um número X de pontos."

O jogador deverá ser capaz de distinguir os principais tipos de requisitos previamente levantados pela organização, entre uma de três categorias:

• Requisitos Desenvolvidos
• Requisitos Mal Elaborados

A decisão deve ser feita com base na descrição do requisito e nos conhecimentos previamente adquiridos pelo jogador.

O minigame será um exercício de classificação por parte do jogador, com as possíveis categorias mencionadas anteriormente. Somente ao fim do minigame que o sistema deverá reportar falhas e sucessos por parte do jogador.

Toda essa tarefa será realizada do ponto de vista de um Engenheiro de Requisitos/Desenvolvedor da empresa, sendo o cargo do mesmo dependente de definições da história do jogo, como, por exemplo, qual processo estará em vigor (se algum) durante esse periodo de vida da empresa.

Responsáveis: @gcmgomes e @thiagorpp

Integrar todos os níveis numa versão apresentável do jogo.

• Cuidar da Hierarquia e dependencia dos níveis
• Aplicar Tilesets e sprites escolhidos para o jogo

Integrar todos os mini-games em um único nível e fazer a dependência dos mini-games.

Definir as características do nível 5, o último nível do jogo.
O nível 5 representa a empresa no nível 4 de maturidade, buscando alcançar o nível 5.
Esta tarefa está alocada para @gpoesia e @bolobr.

No nível 5, o jogador terá que alinhar os ponteiros de diversos relógios, que representam a direção da organização e a do desenvolvimento de software dentro da empresa.

Inicialmente, todos os relógios estarão desalinhados. O jogador terá, então, de tomar algumas decisões na forma de um quiz de forma a alinhar os ponteiros de todos os relógios. Cada decisão será ou sobre a organização ou sobre o desenvolvimento de software, e alterará alguns dos ponteiros de acordo com a resposta. Não existe resposta certa ou errada - cada uma altera os ponteiros de formas diferentes. Ao final, o objetivo é que os ponteiros estejam todos alinhados ou quase alinhados. Caso o objetivo não tenha sido atingido, o jogador é levado a repetir o quiz.

Os "relógios" estarão identificados com as áreas do negócio que representarão, que serão as seguintes:

• Qualidade do produto
• Custo do produto
• Facilidade de manutenção e alterações futuras

Inicialmente, os ponteiros da empresa estarão apontando em alguma direção aleatória. Por exemplo, se o objetivo sorteado da empresa for "Desenvolver software de qualidade aceitável a baixo custo e sem grandes preocupações com alterações futuras", os ponteiros que representam o ponto de vista da empresa estarão em um ponto mediano no relógio de "Qualidade do produto", num ponto tendendo ao baixo em "Facilidade de manutenção e alterações futuras" e ao baixo em "Custo do produto". Inicialmente, os ponteiros do desenvolvimento de software estarão apontando em outras direções.

Cada pergunta terá um impacto diferente em algum subconjunto desses atributos. Por exemplo, uma possível pergunta:

"Uma nova linguagem de programação está na moda e permite o desenvolvimento de software do tipo que sua empresa vende com uma produtividade média maior. Um time da sua organização já domina esta linguagem. O que você deseja fazer?"

• Não adotar a linguagem (não muda os ponteiros)
• Adotar a linguagem apenas para o time que já a conhece (reduz a facilidade de manutenção e alterações futuras, já que se o time se dissolver não haverá outras pessoas para dar manutenção, mas também diminui o custo, já que o time já domina a linguagem)
• Adotar a linguagem na empresa toda, e fornecer treinamento para os funcionários (aumenta o custo instantaneamente, que é o custo do treinamento. Depois de três rodadas, o custo é reduzido, pelo efeito do treinamento. Também aumenta a facilidade de manutenção, já que todos dominarão a ferramenta e ela é mais produtiva que a anterior).

A terceira opção é um investimento a mais longo prazo que a segunda. Após três rodadas, o custos do produtos seria reduzido a um valor menor que o inicial, mostrando que a decisão compensou.

Outras perguntas serão similares a esta, no estilo de tomadas de decisão por parte da gerência da empresa.

Deve ser criado o nível 2

• Fica a critério do Par 1 definir se haverão mini-games e como serão esses mini-games.
• Deve-se cuidar também da integração entre os mini-games, caso haja.

Implementar a tela em que o segundo mini-game do nível 4 será efetivamente jogado pelo jogador. O mini-game está descrito abaixo (descrição retirada do email de discussão).

"O segundo mini-game seria sobre o objetivo "Quantitatively Manage the Project", assumindo que a empresa já definiu como vai gerenciar o projeto (além de eu não ter imaginado um jogo sobre isso, é mais fácil fixar isso porque senão o terceiro mini-game provavelmente seria dependente desse segundo, o que aumentaria a complexidade do jogo). Pensei em esse ser um mini-game parecido com aquele de marretar as marmotas, com base na prática específica SP 2.2 (Manage Project Performance). As marmotas seriam botões com número escrito. Cada botão estaria associado a uma das métricas que foi definida no mini-game anterior (isso deve ficar claro na interface). Quando o botão aparece, o número sobre ele é um valor para a métrica que foi medido durante o projeto. Se ele for ruim (acima do máximo ou abaixo do mínimo definido no último mini-game, dependendo se foi definido máximo ou mínimo), o usuário deve clicar nesse botão, o que representa tomar alguma atitude para melhorar a métrica. Se o usuário clicar num botão com uma métrica "boa" (dentro do limite), ele perde pontos por desperdício. Se não clicar no botão antes de ele abaixar, ele perde pontos por aumentar o custo do projeto. Senão, ele ganha pontos. O objetivo é chegar em um número X de pontos."

O mini-game depende de resultados de jogos anteriores. Caso a interface dos outros mini-games ainda não esteja definida quando for necessária para este mini-game, o desenvolvedor do mini-game 4.2 deve definir a interface e comunicá-la aos demais desenvolvedores.

No nível 4 (minigames 4.1 e 4.2), se apertamos "Próximo" antes de o texto acabar, ele começa a piscar.

Os mini-games do nível 5 devem ser integrados.

O jogador deverá:

• Coletar objetos que cairão da parte superior da tela. Ao impedir que esses objetos/metas toquem o chão, será atribuído ao jogador uma pontuação;
• Ao atingir uma pontuação específica será concedido ao jogar o direito de jogar o mini-game 2, que irá representar o segundo nível de maturidade do CMMI

Tempo estimado:
Estudar MelonJS: 6h
Implementar mini-game 1: 8h

Tela onde o usuário será introduzido ao jogo

• Deve ter uma animação de introdução
• O usuário deve poder escolher seu char/tipo de jogador
• Após isso, usuário será direcionado ao menu principal do jogo

Definir as características do nível 3.
O nível 3 representa a empresa no nível 2 de maturidade, buscando alcançar o nível 3.
Esta tarefa está alocada para @gcmgomes e @thiagorpp.

Definir todos os Sprites e Tilesets que serão usados em todo o jogo.
Para isso, deverá ser pesquisado pelo grupo, alguns exemplos.

O grupo deve votar e escolher o melhor.

A integração deve ser testada antes de ser apresentada.

Sugiro testes de caixa branca e caixa cinza.
Assim, poderemos resolver os bugs assim que eles forem encontrados

Um jeito coerente e natural para desenvolver o nível baseado em minigames é fazendo o link de todos eles por meio de uma historia.

Como temos uma empresa de TI em mãos, uma forma simples de cumprir essa meta é contando do desenvolvimento de um projeto pela equipe, que, depois de atingir CMMI 2 agora quer atingir o 3º, e o auditor fará as visitas justamente durante o desenrolar do projeto.

Vários pontos de vista podem ser explorados, cada um dando enfoque a áreas específicas do arcabouço (técnica, arquitetural, etc). Essa história deverá ser coerente com todos os outros níveis e transversal dentro do CMMI 3.

Responsáveis Principais: @gcmgomes e @thiagorpp.
Responsáveis Secundários: @althoff, @bolobr, @gpoesia, @pratlucas e @Tigariga.

Caso o nível 1 seja definido com vários mini-games, eles devem ser integrados e correlacionados.