upGAME - As Sprints

 

Nós fizemos 4 sprints de 2 semanas cada. As tarefas definidas para cada sprint foram:

Sprint 1 - Preparação

Essa sprint foi uma sprint que resolvemos tirar para podermos definir os detalhes do restante do projeto e fazermos pesquisas sobre ferramentas, processos, exemplos de jogos que poderíamos nos basear. Aqui foram tomadas várias decisões sobre a história, as ferramentas, os processos, o escopo genérico para cada Sprint seguinte e várias outras decisões, como a separação dos pares, o meio de comunicação entre outras.

Por esse motivo, nessa Sprint não tivemos a produção de código, mas foi muito importante para podermos nos organizar para o restante do projeto

Sprint 2 - Desenvolvimento

Essa foi nossa primeira sprint de desenvolvimento. Ela foi pouco produtiva, porque por estarmos tentando criar um novo modelo de desenvolvimento, demorou um tempo até que todos pudessem se adaptar. Nela foi produzido um mini-game do nível 4 e um pouco do mini-game do nível 3. Os objetivos era que todos os pares entregassem pelo menos um mini-game pronto no fim dessa sprint. Apenas dois dos 3 grupos conseguiram. O par 1 não conseguiu fazer essa entrega por problemas pessoais. Apesar disso, eles conseguiram alguns avanços interessantes, definindo um estilo de Tilesets e Sprites com licença livre no DevianArt. Essas imagens foram usadas em todo os jogos que necessitassem de um mapa.

Essa Sprint foi parcialmente um sucesso, pois, apesar da produtividade do par 1 ter sido baixa quanto a codificação, eles conseguiram definir as artes que foram utilizadas no sistema.

Sprint 3 - Desenvolvimento

Nessa outra sprint de desenvolvimento, os objetivos era a conclusão dos níveis. Isso sobrecarregou um pouco o Par 1, porque tiveram tarefas remanescentes que tinham que ser feitas. Felizmente, essa sprint foi um sucesso, já que todas as nossas metas foram concluídas. Os mini-games de cada nível estavam funcionando isoladamente.

Sprint 4 – Integração e garantia de qualidade

Essa foi a nossa última sprint. Definimos ela como sendo a sprint que todos os níveis seriam integrados e testados. Nessa sprint resolvemos dar uma pausa e juntar toda a equipe para que testássemos os mini-games antes da integração. Com isso conseguimos remover alguns bugs, mas não todos, porque a biblioteca MelonJs, por ser bem nova, não temos bastantes opções para buscar resoluções de problemas. Assim sendo, alguns bugs da biblioteca não foram consertados. A maioria não interfere nos jogos.

Após isso, cada par integrou seu nível e fizeram testes. Quando a tarefa foi dada como pronta, todos os integrantes fizeram novamente testes para garantir que não ficassem erros de integração. Removemos os bugs e o sistema já estava pronto para a entrega final.

 Estas informações é um fragmento do nosso relatório. Veja o relatório completo em: http://goo.gl/9M0H79

upGAME - Relatório final

Para melhor entendimento do que foi nosso projeto, os processos trabalhados, a divisão de sprints e tudo mais, foi criado um relatório informando tudo que ocorreu durante o projeto. 

Esse relatório ficou muito extenso, então, quem tiver interesse, pode acessar o link para fazer o download ou mesmo para ver online. 

Link para download: http://goo.gl/9M0H79.

upGAME - Apresentação Final

A terceira apresentação do nosso grupo está disponível para o público. Vejam abaixo ou façam o download pelo link: http://goo.gl/1dnul8

CF70 - Apresentação Final e Revisão de Processo

Com o término do desenvolvimento jogo e a última apresentação realizada, disponibilizamos o produto para download:

Executavel

A apresentação final, realizada na aula de hoje, pode ser visualizada pelo link:

Apresentação

Decidimos também, nesta postagem, reafirmar alguns pontos do processo do trabalho, como revisão do trabalho feito.

Na postagem Nome do Grupo e Primeiras Decisões foi definido o processo a ser utilizado (Kanban), com uma explicação dos motivos que levaram a essa decisão.

Na postagem Decisões de Projeto e Requisitos, foram definidos os requisitos e foi apresentado um protótipo descartável do produto. 

Em Definição de Tarefas foram definidas e divididas as tarefas do desenvolvimento (com base nos requisitos). A postagem também cita que um membro do grupo ajuda os demais em suas tarefas esporadicamente, o que serve como inspeção.

A evolução dos requisitos foi especificado em Evolução dos Requisitos, mas já havia sido discutida em outras postagens, principalmente as que detalham as atualizações da planilha do Kanban(como em Atualização da Planilha e no fim de Detalhamento da 2ªApresentação e do que foi feito).

A postagem final, Conclusão e Considerações Finais, faz um breve apanhado das conclusões tomadas com relação ao processo do Kanban, e menciona os testes (caixa-preta) e o processo de validação utilizados.

Algo que não explicitamos em nenhuma postagem, mas foi dito nas apresentações, é o uso de testadores ao longo do trabalho para validação de ideias e conceitos, o que chegou a levar até mesmo a algumas refatorações do projeto.

Finalmente, os links das apresentações feitas em aula estão disponíveis em postagens anteriores, assim como versões anteriores da planilha de tarefas do processo.

Apresentação Final - esofteacher@sHoRTcut

 

Nesse último post gostaríamos de agradecer a oportunidade de nos organizar como uma fábrica de software e, assim, sermos expostos às diferentes escolhas/decisões que moldam a arquitetura de um software.

Apesar de não termos alcançado tudo que foi planejado, conseguimos atingir progressos notáveis. Durante o projeto do Esofteacher, conseguimos acompanhar a evolução do processo desde a sua concepção, até o seu amadurecimento.

A seguir, disponibilizaremos os artefatos expostos (inclusive aqueles apresentados no dia 29/05). Acessíveis na pasta pública goo.gl/T2x4XX.

1. Reserva do Produto
2. Reserva dos Requisitos da Iteração
3. Esforço da Equipe na Iteração
4. Burn Down
5. Documento de Teste
6. Lista de  Falhas
   
   Vale mencionar que nem todos os artefatos estão presentes na pasta, visto que alguns deles foram sobrescritos no decorrer do trabalho.

Outros assuntos que refletimos após a apresentação de hoje e que gostaríamos de levantar:

• Começamos com a ideia de fazer programação em par e acabamos desistindo de institui-la no processo. Por diversas vezes fizemos o exercício de Navegador e Piloto, percebendo de modo qualitativo que houve ganho no sentido de permitir detecção de defeitos (por exemplo, detectados pelo Navegador que passariam desapercebidos pelo Piloto) e ganho de produtividade pelo clichê: “duas cabeças pensam melhor que uma”. Porém, nem sempre isso ocorria como esperado.
• Foi realizada uma refatoração da cena inicial para se encaixar melhor nas cenas de apresentação das equipes.
• O integrante Luiz Byrro realizou a confecção do onesheet, além de ajudar com os testes.
• Especialização espontânea da equipe, emergindo pessoas que trabalharam mais com o processo, com apresentações, com roteiro, com desenvolvimento, etc.
• O tempo contabilizado pelos cartões no estado de executando serviram como entradas para o burndown.

           

Caso encontrem alguma dificuldade na interpretação das planilhas, pedimos que entrem em contato com o grupo.

O jogo se encontra na pasta pública:

 

goo.gl/I048UU

Atenciosamente,

sHoRTcut team

CF70 - Conclusão e Considerações Finais

Nessa semana, com a data limite de entrega do trabalho se aproximando, conseguimos finalizar o projeto, mas não iremos postá-lo aqui para não estragar a surpresa na hora da apresentação. A planilha correspondente ao final do projeto pode ser visualizada pelo link:

https://www.dropbox.com/s/bkbdxy7ysu8rmw5/kanban_2014_05_27.xlsx

Terminando a última fase, pudemos fazer uma avaliação dos processos realizados ao longo do semestre. O processso utilizado foi o Kanban e ele apresentou vantagens e desvantagens. A principal vantagem foi a modularização do projeto e a divisão de tarefas bem definidas, com cada integrante do grupo cumprindo suas tarefas em tempo hábil (ocorreram algumas dificuldades em algumas tarefas, como a integração das perguntas e dos diálogos mas, nesses casos, todo o grupo se mobilizou para resolver o problema, o que é previsto no Kanban). Um ponto negativo foi a não-definição de Sprints, o que proporcionou uma flexibilidade maior do que a necessária. Desse modo, em algumas semanas (principalmente aquelas com grande volume de provas e trabalhos) o trabalho realizado pelo grupo foi menor do que em outras. Porém, o comprometimento do grupo minimizou esses problemas, pois ao perceber que o progresso feito estava abaixo do previsto, era feito um esforço extra para compensar o tempo perdido.

Será feito um teste do jogo, com cada integrante do grupo convidando cinco pessoas para jogá-lo, e depois será feita uma estatística sobre o avanço dos jogadores na área de Engenharia de Software (com base no resultado de "testes"), para ver se o jogo cumpre o seu objetivo, que é auxiliar no aprendizado de ES.

CF70 - Evolução dos Requisitos

 

Ao longo do desenvolvimento do software, foram feitas algumas mudanças nos requisitos do jogo. Essas alterações ocorreram, de modo geral, devido à reconsideração do alinhamento das funcionalidades com os objetivos do jogo. Em particular, é interessante discorrer sobre os seguintes pontos:

Diversas fases, cada uma sobre um tema específico da engenharia de software (cmmi, xp, scrum, pmbok, etc)

 

Seguindo a validação da proposta do jogo, realizada com amigos e familiares dos desenvolvedores, foi determinado que a implementação de várias fases tornaria o jogo muito repetitivo e cansativo. Além disso, a divisão de temas em diferentes fases também limitaria a abordagem de alguns temas.

 

NPCs tem atributos que indicam o quanto eles irão ajudar ou atrapalhar o jogador

Esse requisito ia de encontro com a implementação do sistema de alinhamento dos personagens que, como explicado na apresentação, era contrário à proposta de um jogo educativo.

 

Glossário de termos descobertos ao longo do jogo

Para preencher a lacuna deixada pela remoção do sistema de alinhamento na mecânica do jogo, e ainda adicionar um componente mais educativo (como também foi sugerido durante a validação), decidimos implementar um glossário de termos relacionados a Engenharia de Software. Dessa forma, os termos mencionados nos diálogos do jogo teriam uma definição disponível para o jogador.

Outros

 

Os demais requisitos permaneceram os mesmos, de forma geral. As únicas exceções estão relacionadas ao requisito de "fases", onde as funcionalidades que variavam de uma fase para outra passaram a ser fixas (devido à remoção das mesmas).

upGAME Group - Processos

Apesar de estarmos fazendo muitas postagens mais ao estilo ágil, é importante falarmos um pouco mais sobre os processos usados e como estão sendo aplicados.


Processo utilizado e sua aplicação

Como informamos na primeira apresentação, estamos trabalhando utilizando o Scrum, porém, com o passar do tempo, resolvemos adaptar um pouco o Scrum para se alinhar com as necessidades do grupo e com as limitações da ferramenta.

As diferenças.

Em um breve resumo, nossas principais diferenças são:

• Não temos Burndown;
• Não trabalhamos com um Backlog Global;
• A comunicação presencial é mais restrita;
• Nossas tarefas contam apenas com dois estados: To Do e Done;
• Temos um membro para cuidar exclusivamente das tarefas administrativas/gerenciais.

Em nosso processo, não temos um Burndown, isso porque o Issues Trackar não nos proporciona essa funcionalidade. Assim sendo, estamos monitorando o progresso dos pares pelos commits feitos no Github.

Podemos citar também as diferenças quanto ao Backlog. Como temos um prazo máximo de entrega a ser respeitado, um grupo grande e poucas Sprints para fazer as tarefas, resolvemos, em uma reunião, definir nossas tarefas e alocá-las nas 4 sprints necessárias para concluirmos nosso trabalho, assim sendo, não fizemos um backlog global, apenas fizemos os backlogs para cada sprint, distribuindo as Tasks previamente. Apesar disso, tarefas que ficam remanescentes das sprints anteriores, são colocadas nas próximas, assim como no Scrum padrão.

Backlog para a Sprint 3 (Atual).

Backlog da Sprint 4 (Próxima e última).

A maior parte da nossa comunicação está sendo feita por meio do github. Quando uma task é atualizada, o github envia um e-mail informando a todos os colaboradores do projeto que ela foi alterada e as informações que foram adicionadas e tudo mais, assim como quando uma tarefa é criada e excluída.

Outro problema que tivemos é que no Issues Tracker não temos como classificar as tasks como To Do, In Progress ou Done. Ele possibilita apenas To Do e Done. Para sabermos o que cada par de programação está fazendo, nos reunimos após as aulas. Neste momento todos dizem em que o seu par está trabalhando a previsão de conclusão daquela tarefa

Outro diferencial para o Scrum é que, além dos programadores, temos também um membro que cuida da parte administrativa e gerencial do projeto, ficando por conta da alocação de tarefas no Issues Tracker, documentação, atualização do blog, criação das apresentações e monitoria do andamento das tarefas. Pensamos que isso ajudaria pois os outros integrantes devem apenas se preocupar em programar e em estar atento as tarefas no Github e seus prazos. Com isso evitamos a sobrecarga de funções, o que pode atrapalhar o rendimento geral do grupo.

Modelo de Pares de programação

Com a utilização de um modelo de programação em pares estamos obtendo bons resultados. Neste modelo, os dois integrantes do grupo programam funcionalidades diferentes. 

Após terem concluído suas tarefas, o outro integrante fica responsável pela análise do código de seu parceiro.

Quanto o código passa pela análise, os dois integrantes devem fazer os testes nas aplicações criadas para garantir o funcionamento.

Assim, cada par é responsável pela qualidade e a funcionalidade dos seus códigos.

Esse modelo será desfeito na sprint final, a sprint de integração, onde todos os integrantes devem integrar as funcionalidades ao sistema final e fazer os testes (testes de caixa cinza), para certificar-se de que a integração não atrapalhou no funcionamento das aplicações.

CF70 - Apresentação 08/05

Segue o link para a apresentação do dia 08/05:

Apresentação 08/05

Também segue o link para o executavel apresentado:

Protótipo do jogo

upGAME Group - Terceira Apresentação

A terceira apresentação do nosso grupo está disponível para o público. Vejam abaixo ou façam o download pelo link: http://goo.gl/3yKSH7

Reunião Semanal 11/05 esofteacher@sHoRTcut

Decidimos que, excepcionalmente que nesta semana, não haverá a reunião por hangout em virtude da prova de Engenharia de Software.

A seguir, disponibilizaremos os artefatos exposto na apresentação do dia 08/05. Decidimos criar uma pasta pública no googleDrive para compartilhá-los goo.gl/T2x4XX.

1. Reserva do Produto
2. Reserva dos Requisitos da Iteração
3. Esforço da Equipe na Iteração
4. Gráfico da “Queimação” (Burndown)
5. Documento de Teste
6. Lista de  Falhas

Além disso, reforçamos que o acompanhamento do processo pode ser feito em trello.com/b/tv9tJsM3 e da evolução do produto em github.com/mfer/sHoRTcut.

Saiu a versão de 08-05 do esfoteacher!

Endereço para download:

 

goo.gl/I048UU

CF70 - Atualização da Planilha

Na última semana, decidimos fazer algumas alterações na planilha do Kanban. As mudanças podem ser verificadas pelo link de download disponibilizado abaixo:

https://www.dropbox.com/s/csltxnb0nbgc594/kanban_2014_05_07.xlsx

A atualização se deu principalmente devido à relação de complementaridade entre algumas das etapas de desenvolvimento, as quais fazem mais sentido serem desenvolvidas ao mesmo tempo.

Na tarefa de Fases, decidiu-se avançar a sub-etapa de Implementação para o estado de "Sendo Feito", visto que a implementação dos cenários estava se mostrando necessária para o teste das demais funcionalidades.

Na tarefa de Roteiro, é clara a ligação entre Personagens e Diálogos. Logo, achamos que seria mais fácil e lógico desenvolver as duas atividades simultaneamente.

O mesmo se aplica para a tarefa Perguntas, com as etapas de Questões e Dicas.

Além disso, a etapa de Elaboração das Mecânicas de Mini-Jogos e Eventos foi finalizada, o que permitiu a inicialização de sua Implentação.

Também cancelamos o Sistema de Alinhamento pois, apesar de acharmos a ideia interessante para um jogo, acreditamos que o fornecimento de dicas erradas por alguns personagens se mostraria contraprodutivo considerando o contexto de um jogo educativo. No lugar dessa mecânica, decidimos implementar um Glossário, contendo definição de termos importantes relacionados a Engenharia de Software que são mencionados ao longo do jogo.

upGame Group - Progresso

O par  2 conseguiu finalizar o mini-game 3.1. 

Neste mini-game, o jogador deve saber bem como discernir os requisitos.

O jogador recebe uma lista com vários requisitos e tem que separá-los em duas categorias: 

• Requisitos
• Requisitos mal definidos

Para conseguir passar por este mini-game, o jogador deve separar corretamente todos os requisitos.

Vejam a baixo alguns screenshots do mini-game funcionando:

Reunião Semanal 04/05 esofteacher@sHoRTcut

Estes foram os temas discutidos por nossa equipe durante a semana e na última reunião semanal:

Devido ao feriado da semana santa, decidimos que não haveria uma reunião semanal, consequentemente não haveria uma postagem referente ao resumo da reunião.   

A seguir apresentaremos um resumo das cenas elaboradas durante as semanas:

Pontos principais (de onde vai surgir o resumo):

• O resumo será dado pelo Scrum Master.
• Planejamento da sprint
• Levantamento de requisitos do primeiro módulo

Pontos para quiz (que vão entrar apenas na cena complexa):

• Perguntar se ele sabe o que é corrida
• Sobre como é o planejamento da sprint
• Sobre se devemos abraçar as mudanças ou exigir que o contrato seja seguido

Histórias possíveis:

1. Eu, como dono da empresa, quero cadastrar um produto, seu valor e sua quantidade em estoque
2. Eu, como dono da empresa, quero cadastrar clientes [com Nome, CPF, telefone, endereço e data de nascimento [, sendo que apenas Nome e CPF são obrigatórios]].
3. Eu, como dono da empresa, quero encontrar meus clientes [com base em qualquer campo, mas principalmente por Nome e CPF].
4. [Eu, como dono da empresa, quero ser avisado de quais clientes fazem aniversário no dia].
5. Eu, como dono da empresa, gostaria de saber quais são os produtos mais vendidos
6. Eu, como dono da empresa, gostaria de saber quais são os clientes que compram mais
7. Eu, como dono da empresa, gostaria de registrar as vendas realizadas sabendo qual cliente comprou qual produto 
   
   
   Itens em colchetes representam o que é opcional na história, ou seja, representa aquilo que o jogador só vai saber dependendo do questionamento que ele fizer.

Como o professor Rodolfo solicitou que pesquisemos mais a respeito dos procedimentos relacionados com as práticas vigentes na industria de jogos, optamos por elaborar um documento que resume os propósitos do jogo para fins de publicidade. Tal documento é conhecido na industria de entretenimento como One Sheet. Como o documento ainda esta em processo de elaboração, iremos divulga-lo na apresentação.

upGAME Group - Progresso

Ontem o par 3 concluiu o mini-game 4.1 (Gabriel Poesia e Guilherme Cordeiro), fez alguns testes (Testes de caixa branca). O próximo passo a serem realizados nesse mini-game será a revisão de código e os testes de Caixa Preta. Testes de caixa cinza, serão realizados quando este mini-game for integrado ao restante do projeto.

Várias funções foram criadas usando JQuery e usando o MelonJs para controle do fluxo.

Neste mini-game temos 5 métricas que o jogador deve definir:

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

Depois de definir isso, ele clica em um botão que "simula" o uso dessas métricas em um projeto. Com isso, ele obtém uma mensagem de resultado, 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."

Ou...

• - "O projeto foi um sucesso! Os bugs registrados durante os testes foram corrigidos a tempo e o cliente ficou satisfeito com o produto entregue. O custo ficou dentro do esperado, e toda a equipe ficou muito motivada por ter um projeto de tanto sucesso. Ninguém imaginou que a definição de metas quantitativas, quando bem aplicada, pudesse ser tão efetiva! Parabéns!"

Quando ele obtém essa última mensagem, passa para o próximo mini-game.

Estamos discutindo mensagens de retorno mais legais para melhorar a experiência de usuário, além de tentar aumentar a dificuldade, pois o mini-game pode ser resolvido através de tentativa e erro, o que não está alinhado aos nossos objetivos, que é ensinar os princípios do CMMI e não se aprende muito realizando um processo de tentativa e erro para resolver problemas.

Veja abaixo alguns screenshots relativos ao mini-game 4.1:

CF70 - Logo e novas decisões

Definimos uma logomarca para nossa empresa:
 

 
Decidiu-se utilizar uma textura metálica para mostrar a força e a resistência do grupo como um todo.

Além disso, pensamos também no nome do jogo e no nome do personagem principal.

O nome do personagem principal foi decidido como Renan C. Milgram.

Seu sobrenome é uma referência ao psicólogo Stanley Milgram, responsável por conduzir o famoso estudo sobre a obediência à autoridade (cujo resultado pretendemos usar na implementação do sistema de alinhamento dos personagens do jogo).

O título do jogo será: Renan Milgram e a Aula Perdida.

As tarefas na planilha continuam a serem executadas por seus respectivos membros.
A mecânica de um dos mini-jogos está bem adiantada e pretendemos detalha-la em breve.

upGAME Group - Segunda Apresentação

A segunda apresentação do nosso grupo está disponível para o público. Vejam abaixo ou façam o download pelo link: https://docs.google.com/presentation/d/1mz6CGkXUuG9CCYJlZOuEsig-BXp2aHpiYavYmgjR1js/pub?start=false&loop=false&delayms=3000

Resumo planejamento do enredo - esofteacher@sHoRTc

Na reunião de planejamento da próxima corrida (sprint), decidimos que as histórias 3, 4 e 5 serão desenvolvidas.

Essas três histórias, principalmente a 4, são a base do nosso jogo, o enredo principal que é o objetivo e que deve interligar tudo.

---

Lista de cenas

Dividimos a história do jogo nas 21 cenas listadas abaixo.

“NaMesa”

   cm - cenaMapa: Cena que se repete, onde o jogador escolhe qual projeto vai seguir na empresa.

Ágil

   aa - cenaMestreBolo: Apresentação do projeto PadaOne e do cliente.

   a1 - cenaCorrida1: Implementação do CRUD-Client.

   ar1 - cenaResumoCorrida1: Resumo da cena cenaCorrida1.

   a2 - cenaCorrida2: Entrega do CRUD-Client e implementação do CRUD-Produto.

   ar2 - cenaResumoCorrida2: Resumo da cena cenaCorrida2.

   a3 - cenaCorrida3: Entrega do CRUD-Produto e implementação do Venda-MesclandoClienteProduto.

   ar3 - cenaResumoCorrida3: Resumo da cena cenaCorrida3.

   af - cenaFimAgil: Entrega final do projeto e parabenização pela dedicação para fazer com que o projeto que utiliza a metodologia ágil fosse um sucesso.

   arf - cenaResumoFimAgil: Resumo do final do projeto, falando que foi entregue mas não foi tão bem quanto poderia, que seria bom se o jogador tivesse conseguido se dedicar mais a ele também.

Tradicional

   ta - cenaGerente: Apresentação do projeto PadaTout e do cliente.

   t1 - cenaJad1: Início da especificação do ClientProductSales.

   tr1 - cenaResumoJad1: Resumo da cena cenaJad1.

   t2 - cenaJad2: Fim da especificação do ClientProductSales.

   tr2 - cenaResumoJad2: Resumo da cena cenaJad2.

   t3 - cenaImplementacao: Implementação do ClientProductSales.

   tr3 - cenaResumoImplementacao: Resumo da cena cenaImplementacao.

   tf - cenaFimTradicional:  Entrega do projeto e parabenização pela dedicação para fazer com que o projeto que utiliza a metodologia tradicional fosse um sucesso.

   trf - cenaResumoFimTradicional: Resumo do final do projeto, falando que foi entregue mas não foi tão bem quanto poderia, que seria bom se o jogador tivesse conseguido se dedicar mais a ele também.

OutrosFinais

   fm - cenaFimMisto: Entrega dos dois projetos. Explicação de que os dois projetos foram terminados mas não foram tão bem por falta de atenção ou de mais pessoas trabalhando dedicadas a eles. Um pouco de reclamação pelo jogador ter se dedicado a nenhum projeto.

   fd - cenaDemissao: Jogador demitido da empresa.

As cenas principais do desenvolvimento dos projetos (a1, a2, a3 e t1, t2, t3) são as cenas mais complexas, que terão ações que vão influenciar nas barras de stress.

Algumas das diferenças entre os projetos que serão abordadas:

1. Inexistência do papel de levantador de requisitos no processo ágil.
2. No tradicional o contato com o cliente é concentrado durante o levantamento de requisitos enquanto que no ágil o contato é mais frequente durante todo o projeto.
3. No ágil as entregas são mais frequentes.
4. No tradicional a documentação maior no tradicional enquanto história do usuário são rasgadas no ágil.

---

Fluxo das cenas

As cenas aa e ta, por serem de apresentação do usuário aos projetos, acontecerão no início do jogo e o usuário poderá escolher qual delas verá primeiro.

Durante o desenvolvimento dos projetos o jogador escolherá em qual time vai se dedicar a cada “turno” e  essa escolha determina qual cena ele vai ver. Serão três turnos sequenciais, formados pelos pares de cenas a1 e t1, a2 e t2, a3 e t3. Caso o jogador vá bem na cena escolhida ele ganha o direito de participar da cena do outro time do mesmo turno. Caso não vá bem ou caso não queira ver a outra cena, o jogador é conduzido a uma cena resumo do que aconteceu com a outra equipe (ar1, ar2, ar3, tr1, tr2, tr3).

Caso o jogador consiga participar de todas as três cenas de desenvolvimento de um projeto ele participa da cena final dele. A participação nas cenas a1, a2, e a3 levam à cena af e as cenas t1, t2 e t3 levam à cena tf. Caso consiga participar de apenas de uma dessas cenas finais, um resumo do final do projeto da outra equipe é exibido, cenas arf ou trf. Se o jogador conseguir ir bem ele pode chegar a ver as cenas af E at.

Caso o jogador jogue sem foco em algum dos projetos a cena fm aparece ao final.

Se for mal nos desafios nas cenas, a barra de “estresse” vai subindo e pode chegar a um ponto onde ele é demitido da empresa, aparecendo a cena fd.

Exemplo de fluxo que poderá ser seguido por um jogador abaixo. As linhas tracejadas correspondem a cenas escolhidas pelo jogador enquanto as linhas sólidas correspondem ao jogador sendo levado automaticamente a uma cena pelo sistema.