Jogo Programadores e Problemas: Tradução das Cartas

Segue abaixo as traduções das cartas que me foram atribuídas. Estou usando os templates da postagem anterior.

Cartas de problemas:
cards-problems-eduardo.doc

Cartas de Conceitos:
cards-concepts-eduardo.doc

Jogo Programadores e Problemas: Template das Cartas

Estava meio perdido sobre como fazer a tradução das cartas que me foram atribuídas, então fiz templates no Word para estas cartas.

Se alguém quiser utilizar os mesmos templates para padronizar as cartas, estou disponibilizando nos seguintes endereços:

Cartas de problemas:
cards-template-problems.doc

Cartas de Conceitos:
cards-template-concepts.doc

Jogo Programadores e Problemas: Sugestões

Com o propósito principal de introduzir conceitos de evolução de software no jogo Programadores e Problemas, mas também com outros objetivos em relação à melhoria do jogo. A turma levantou algumas possíveis alterações ao jogo:

A) Definir melhor o número de pessoas. Uma sugestão foi que o jogo fosse jogado por até 9 pessoas, ou em uma faixa entre 4 e 9 pessoas. Em favor de um número maior de pessoas, se encontra o fato de que o jogo foi inicialmente proposto para ser jogado em sala de aula. Como geralmente uma turma tem muitos alunos, mais jogadores significa mais pessoas envolvidas no aprendizado. Por outro lado, um número elevado de jogadores torna o jogo demasiadamente lento.

B) Com o intuito de agilizar o jogo e melhorar sua dinâmica, foram feitas algumas propostas. Por exemplo:
(i) Jogar em equipe (dupla, por exemplo). Esta proposta além fazer com que o jogo tenha um fim mais próximo, também pode ajudar a desenvolver o espírito de coletividade dos jogadores.
(ii) Simplificação dos bugs e código ruim/bom. O jogo oferece possibilidades de simplificações sem que estas alterem seu objetivo principal (educacional). Por exemplo, os bugs poderiam ser de somente um tipo, eliminando a classificação entre “Simples”, “Normal” e “Grave”. Também, a diferenciação entre “Código Ruim” e “Código Bom” poderia ser removida.

C) Criar um catálogo bibliográfico anexo ao jogo. Este catálogo permitiria aos jogadores aumentar o conhecimento sobre determinado assunto. Por exemplo, quando aparecesse um problema relacionado à “Requisitos Unclear”, poderia haver referências que explicassem melhor a importância de uma análise de requisitos bem feita. Um problema com esta proposta é em relação a justamente a dificuldade de montar e manter um catálogo de referências. Para isto, precisaria de uma vasta – huge ;-) – revisão bibliográfica e que novas referências pudessem ser facilmente adicionadas.

D) Para introduzir o conceito de rastreabilidade de requisitos (um conceito muito importante para evolução de software) foram sugeridas cartas de rastreabilidade. Duas propostas foram feitas: (i) que estas cartas poderiam explicitamente indicar qual documentação esta relacionada à qual trecho de código; ou (ii) simplesmente existir cartas de rastreabilidade e jogadores que não às possuísse seriam penalizados.

E) Criar uma classificação para as cartas de documentação (especialmente requisitos), de tal forma que elas pudessem (i) trazer mais conceitos de Engenharia de Software e (ii) aumentar a dinâmica inicial do jogo. Por exemplo, foram sugeridas pelo menos dois novos tipos de carta de documentação: rastreabilidade e requisitos não funcionais (segurança, por exemplo). Em especial, as cartas de requisitos não funcionais poderiam alterar a forma de atuação do jogador.

F) Criar um tabuleiro de jogo para cada jogador. Esta proposta visa organizar melhor a fases do desenvolvimento e organizar a área de jogo de cada jogador. A área de jogo é apresentada na versão original deste jogo, mas não é explicitamente sugerida para os jogadores.

G) Limitar o número de problemas que podem ser jogados para cada pessoa. O número inicial seria um máximo de 3 problemas e os oponentes que sucedessem o jogador seriam responsáveis por apresentar os problemas.

Jogo Programadores e Problemas: Algumas Deficiências

Em nossa discussão na última aula, foram levantados alguns possíveis problemas com o jogo que pretendemos evoluir. São elas:

1) A dinâmica inicial do jogo (Fase de Requisitos e Fase de Projeto) não entusiasma muito o jogador. Parece um período maçante em que o jogador tem que passar até chegar à parte mais interessante (Fase de Implementação).

2) Para alguns de nós jogadores, o jogo pareceu ser muito demorado, provavelmente devido ao modelo cascata utilizado. Em nossa primeira experiência, jogando durante duas aulas e só chegamos a Fase de Implementação porque “atropelamos” um pouco as outras fases. Ou seja, não fizemos documentação adequada nas fases de requisitos e projeto.

3) O jogo não define claramente quantas pessoas devem jogar. Em nossa experiência, jogamos em 6 pessoas. Um problema relacionado a isso é que muito problemas eram lançados para cada jogador (até 5). Com este elevado número de problemas, torna-se difícil para qualquer jogador evoluir (e ganhar o jogo).

4) O jogo não fornece muitas informações (bibliografia) sobre seus fundamentos principais. Como este é um jogo educativo, acreditamos que os jogadores deveriam ser induzidos a procurar mais informações sobre conceitos de Engenharia de Software / Desenvolvimento de Software.