Orientações da Segunda Apresentação

Amanhã teremos a segunda apresentação do trabalho da disciplina. Como já mencionado, 40% da nota é relativa ao produto e 60% ao processo. Dessa forma, a apresentação será avaliada considerando:

Processo:

- Requisitos (20% da nota): definir os requisitos do produto e da iteração, assim como o está pronto.

- Projeto (20% da nota): evidências de projeto no nível 2 de maturidade do cmmi.

- Outros (20% da nota):
    - Organização do grupo: para cada aluno, qual foi seu papel/contribuição na iteração.
    - Decisões da iteração: decisões de implementação, decisões relativas ao processo.
    - Desafios encontrados: problemas com o produto/processo de desenvolvimento.
    - Testes: testes realizados e resultados obtidos.

Produto: funcionamento(20% da nota) e outros (20% da nota).

Product Backlog

O jogo será composto por basicamente duas telas: tela para seleção de projetos (chamada de Projects Dashboard) e a tela do projeto selecionado (que terá o nome do projeto).

Projects Dashboard

Para a tela de Projects Dashboard, temos os seguintes requisitos:

1. Na parte superior devem haver 6 barras distribuidas horizontalmente com as seguintes funções:
   1. Money: dinheiro acumulado pela empresaaté o momento
   2. Reputation: reputação acumolada pela empresa nos projetos que concluiu
   3. Done: quantidade de projetos concluidos
   4. Doing: quantidade de projetos em execução
   5. Available: quantidade de projetos os quais a empresa pode iniciar
   6. Blocked: quantidade de projetos os quais a empresa não pode iniciar
2. A empresa deve começar com uma quantia suficiente para custear um funcionário ao longo de um projeto
3. Os pontos de reputação são calculados de acordo com a conclusão de um projeto
4. A reputação é a soma dos pontos de reputação adquiridos em cada projeto
5. Os projetos nos quais a empresa pode iniciar dependem das restrições de quantidade de membros disponíveis e da reputação da empresa impostas em cada projeto
6. Cada projeto, antes de ser iniciado, deverá ter os seguintes atributos:
   1. Budget: quantidade máxima, em dinheiro, que a empresa poderá ganhar ao concluir o projeto
   2. Developers: quantidade mínima requerida de desenvolvedores para execução do projeto
   3. Features: quantidade de funcionalidades naquele projeto
   4. Difficolty: dificuldade daquele projeto
   5. Due Date: dias limite para a entrega do projeto
   6. Reputation: reputação mínimia requerida para execução do projeto
7. A quantidade de dinheiro ganha em um projeto depende da quantidade de funcionalidades entregues
8. Um projeto pode abrigar mais desenvolvedores do que o mínimo necessário
9. A dificuldade do projeto representará a quantidade de reputação ganha pela empresa ao concluir aquele projeto
10. Cada projeto, depois de ser iniciado, deverá ter os seguintes atributos:
    1. Members: funcionários presentes naquele projeto
    2. Reward: dinheiro ganho no projeto até o momento
    3. Features: barra contendo a quantidade de funcionalidades entregues até o momento
    4. Reputation: pontos de reputação que o projeto irá render se concluido naquele momento
    5. Time Left: dias restantes para a data limite de entrega do projeto
    6. Bugs: barra contendo a quantidade de bugs presentes no projeto
11. Uma vez atribuido a um projeto, um funcionário não poderá ser remanejado entre projetos, devendo concluir o projeto atual
12. Assim que uma funcionalidade é concluida, o seu valor em dinheiro é creditado na conta da empresa
13. Os pontos de reputação que o projeto irá render dependem da dificuldade e são ponderados de acordo com a quantidade de funcionalidades concluidas e da quantidade de bugs encontrados no projeto
14. O tempo restante deve ser contado a partir do início do projeto
15. No canto esquerdo, deve aparecer a equipe de funcionários da empresa:
    1. Cada funcionário possui os seguintes atributos:
       1. Custo inicial: representa o valor para sua contratação. O objetivo deste campo é evitar a rotatividade da equipe por parte do jogador uma vez que um funcionáro demitido a curto prazo incorre em custos maiores
       2. Custo por hora: representa o valor que deve ser descontado toda vez que o funcionário estiver trabalhando em uma atividade (descrita na seção de Project Name abaixo)
       3. Habilidade: destreza que o funcionário possui para escrever um código. Maior habilidade, menos bugs serão inseridos dentro de uma tarefa
       4. Produtividade: capacidade produtiva para finalização de tarefas. A produtividade deve ser atenuada pelo foco do funcionário
    2. Os funcionários devem possuir cores diferentes para identificar aqueles que estão disponíveis daqueles que estão alocados em um projeto
    3. Quando clicado sobre um funcionário, algumas informações deverão aparecer:
       1. Atributos descritos no item 15.1.4
       2. O projeto em que está alocado, se estiver
       3. A opção "fire" para dispensar aquele funcionário da empresa
    4. Ao concluir um projeto, todos os funcionários alocados devem ser dinamicamente alterados para refletir que estão disponíveis
16. No centro da tela, devem aparecer os projetos:
    1. Os projetos devem possuir cores diferentes para identificar aqueles que estão conluidos, em execução, disponíveis e indisponíveis
    2. Quando houver um clique simples em um projeto, as suas informações deverão ser exibidas de acordo com seu estado:
       1. Projetos conluidos: devem aparecer as informações finais do projeto
       2. Projetos em execução: devem aparecer as informações de acordo com o item 10
       3. Projetos disponíveis: devem aparecer as informações de acordo com o item 6
       4. Projetos indisponíveis: devem aparecer as informações de acordo com o item 6
    3. Ao concluir um projeto, a cor do projeto deve ser alterada dinamicamente refletindo que este mudou de estado
    4. Ao concluir um projeto, uma tela de pop-up deve ser exibida com as informações do projeto de acordo com o item 16.2.1
17. Quando houver um clique duplo em um projeto, deve ser redirecionado para a tela do projeto
18. No canto direito, devem aparecer os candidatos disponíveis para contratação
    1. Ao clicar sob um candidato, as seguintes informações devem ser exibidas:
       1. Atributos como custo inicial, custo por hora, habilidade e produtividade
       2. A opção "hire" para contratar aquele candidato
    2. Os candidatos devem receber um salário inicial para inibir a rotatividade de funcionários, fazendo com que não seja vantajoso contratar e demitir funcionários
    3. Candidatos cujo custo inicial superam o valor que empresa possui em caixa devem possuir cores diferentes para identificar que a sua contratação não é possível
    4. A coloração dos candidatos deve ser dinâmica de acordo com o valor em caixa da empresa
19. Na parte inferior da tela, teremos as informações como data e hora
    1. Cada minuto representa um segundo do tempo real

Project Name

Para a tela de Project Name, temos os seguintes requisitos:

1. No canto superior esquerdo deve aparecer o campo Money conforme descrito no item 1.1 dos requisitos do Projects Dashboard
2. No canto esquerdo, deve aparecer e equipe alocada para este projeto:
   1. Os funcionários devem estar coloridos de acordo com a tarefa que estão desempenhando (doing, inspecting, testing ou idle)
   2. Funcionários que estiverem envolvidos com algum compromisso (reunião ou treinamento) devem desaparecer desta lista e reaparecer assim que o compromisso for finalizado
   3. Quando um funcionário é alocado para alguma tarefa, deve ser calculado automaticamente o gasto com sua remuneração de acordo com o tempo gasto e o valor cobrado
   4. Funcionários ociosos (idle) não recebem remuneração (o restante recebe, mesmo que em reunião ou treinamento)
3. No canto superior direito, teremos um botão para retornar à tela de Projects Dashboards
4. No canto direito teremos duas listas:
   1. Lista para os funcionários em reunião:
      1. Funcionários em reunião aumentam o foco, contribuindo para o foco da equipe
      2. Maior foco, maior é a produtividade do funcionário
      3. Produtividade deve ser dada pela produtividade do funcionário multiplicada pelo foco (em percentual), ou seja, se ele estiver focado 50%, então metade de sua produtividade será comprometida
   2. Lista para os funcionários em treinamento:
      1. Funcionários em treinamento aumentam a sua habilidade, diminuindo a inserção de bugs
5. Na parte central da tela, teremos:
   1. Indicadores do projeto e da equipe:
      1. Progress: representa a quantidade de tarefas realizadas no projeto. Deve ser levado em conta o tamanho, progresso, dificuldade e bugs das tarefas para calcular este campo
      2. Time Spent: representa a quantidade de dias corridos desde o início do projeto (dias corridos/dias total do projeto)
      3. Bugs: representa a quantidade média de bugs nas tarefas
      4. Focus: representa a quantidade média de foco que a equipe possui
   2. Os estágios de produção de software serão dividios em três:
      1. Elaboração:
         1. Todas as tarefas do projeto devem aparecer inicialmnete em "To Do"
         2. Uma vez atribuido um funcionário para realizar uma tarefa, esta deve ir para "Doing"
         3. Quando a tarefa for concluida, ela deve ir para "Done"
         4. O tempo de execução de uma tarefa deve ser calculado levando em conta o tamanho da tarefa, a produtividade e o foco do funcionário que irá realizá-la
      2. Inspeção:
         1. O jogador deve selecionar quais tarefas ele deseja inspecionar, transferindo as tarefas que estiverem em "Done" e colocá-las em "To Inspect"
         2. Quando uma tarefa estiver sendo inspecionada, ela deve aprecer em "Inspecting"
         3. Assim que uma tarefa for inspecionada, ela deve automaticamente ir para o campo "Inspected"
         4. O tempo de inspeção de uma tarefa deve ser calculado de acordo com a metade do valor calculado no item 5.2.1.4, ou seja, a inspeção demora metade do tempo de execução de uma tarefa
         5. Inspeção são capazes por retirar 50% dos bugs presente naquela tarefa
      3. Testes:
         1. O jogador deve selecionar quais tarefas ele deseja testar, transferindo as tarefas que estiverem em "Done" ou em "Inspected" e colocá-las em "To Test"
         2. Quando uma tarefa estiver sendo testada, ela devem aparecer em "Testing"
         3. Assim que a tarefa for testada, ela deve automaticamente ir para o campo "Tested"
         4. O tempo de teste de uma tarefa deve ser calculado de acordo com o valor calculado no item 5.2.1.4, ou seja, o teste demora o mesmo tempo de execução de uma tarefa
         5. Testes são capazes por retirar 50% dos bugs presente naquela tarefa
   3. Cada estágio conterá tarefas. Cada tarefa terá os seguintes atributos:
      1. Size: tamanho da tarefa
      2. Progress: progresso da tarefa. Este campo começa em 0% e varia até 100% de acordo com a produtividade, o foco e o tempo gasto por um funcionário na tarefa
      3. Difficulty: dificuldade daquela tarefa e contribui com o aparecimento de bugs
      4. Bugs: bugs taquela tarefa. Este campo começa em 0% e varia até 100%
      5. Status: deve mostrar se a tarefa foi "Done", "Inspected" ou "Tested"
6. Na parte inferior da tela deve aparecer os logs do projeto como por exemplo:
   1. Funcionário F foi alocado para a tarefa T
   2. Funcionário F transferiu a tarefa T do estado E1 para o estado E2
   3. Funcionário F está ocioso
   4. Funcionário F₁, F₂, F₃ estão em reunião
   5. Além dos logs do projeto selecionado, devem aparecer logs dos outros projetos que estiverem em execução
7. Ainda na parte inferior, deve permanecer a barra de tempo conforme descrito no item 19 dos requisitos do Projects Dashboard

As prioridades seguem a ordem desse documento: primeiro, a tela do Projects Dashboard seguida da tela do Project Name. Dentro de cada tela, as prioridades devem seguir a lista de requisitos que a acompanha (1 a 19 para Projects Dashboard e 1 a 7 para Project Name).

Quaisquer dúvidas, estou à disposição.


Vitor Guilherme Ribeiro Lopes
Product Owner

Segunda Postagem - Reunião e status da primeira corrida

Situação da primeira corrida

As corridas estão todas sendo controladas e avaliadas a partir do Asana. Um controle mais simplificado e rápido também é feito por uma tabela simplificada em Excel. Essa tabela está representada abaixo. Nela estão explícitas as tarefas definidas para a primeira corrida, as pessoas responsáveis por cada tarefa e sua atual situação no projeto. Ao fim serão feitas avaliações da gerencia e do time, que incluem planejamento de tempo e execução das tarefas propostas para a primeira corrida.

Definições da Reunião do dia 28.09

Na reunião do dia 28.09, entre os programadores de front e back ficaram definidos os seguintes temas:

Decisões de projeto

A fim de resolver quaisquer problemas relativos a copyright optamos por fazer os gráficos do jogo por conta própria de forma cartunizada dando personalidade própria ao jogo.

·         Serão duas telas na fase de treinamento

·         As telas serão: Fase de treinamento – No fundo, o mar, e o mestre e o discípulo sentados em duas montanhas/pedras conversando sobre o tema a ser estudado.

·         Fase de Testes – No fundo, o mar, e à frente vários troncos finos de madeira para treinamento. O discípulo estará alternando entre tocos com uma perna só enquanto o mestre faz perguntas sobre o tema ensinado.

·         A cada pergunta acertada, o Discípulo tem seu HP máximo aumentado e ativa a animação de agachamento. No caso de um erro, o Discípulo cai no chão e o HP máximo não é alterado.

Ficou definido que os sprites de fundo e de personagens serão feitos pelo Matheus Jamil com a ajuda no bloco de desenhos do Windows 10.

Requisitos

Os requisitos do projeto estão todos sendo controlados a partir do Trello. Um resumo dos requisitos identificados importantes na última reunião está listado abaixo (todos os requisitos foram escritos em forma de história de usuário):

• Como jogador, eu quero selecionar as fases de treinamento em uma tela específica.
• Como jogador, eu quero que os ensinamentos do mestre sejam textuais.
• Como jogador, eu quero que as perguntas da fase de teste sejam do tipo V ou F.
• Como jogador, eu quero que as perguntas da fase de testes sejam aleatórias.
• Como jogador, eu quero que respostas certas correspondam a um aumento da minha pontuação máxima.
• Como jogador, eu quero que minha pontuação máxima seja exibida por meio de uma barra de XP.
• Como jogador, eu quero que existam animações do personagem na fase de teste.
• Como jogador, eu quero que o painel de seleção das fases de treinamento mostre meu desempenho nas fases concluídas no formato de 1, 2 ou 3 estrelas para pontuações mínimas, médias e máximas respectivamente.
• Como jogador, eu quero enfrentar um personagem Chefão, como uma espécie de desafio máximo.
• Como jogador, eu quero poder enfrentar o Chefão a qualquer momento fora das fases de teste, independentemente da quantidade de fases concluídas.
• Como jogador, eu quero um mecanismo para ver minha pontuação relativa ao número de acertos.
• Como jogador, eu quero um mecanismo para ver quanto tempo gastei para concluir uma fase de teste.
• Como jogador, eu quero que meu progresso no jogo possa ser salvo.
• Como jogador, eu quero obter pontos bônus ao derrotar o Chefão.

Orientações Sobre as Postagens

• O objetivo das postagens é ter um registro de como o grupo se organizou no tempo, logo, o grupo deve postar no blog sempre que houver um avanço no trabalho, ou seja, alguma atividade/esforço foi completada.

• Por exemplo:

• O grupo planejou "Tarefa 1" -> vai para o blog

• O grupo executou "Tarefa 1" -> vai para o blog

• Todas as postagens de um mesmo grupo devem apresentar o marcador do grupo. Logo, pastagens do "Grupo 1" devem apresentar o marcador "Grupo 1".

Importante

Recomenda-se registrar todos os esforços do grupo, incluindo, mas não se limitando, aos seguintes pontos:

• Requisitos: definir os requisitos do produto e da iteração, assim como o está pronto.

• Organização do grupo: para cada aluno, qual foi seu papel/contribuição na iteração.

• Decisões da iteração: decisões de implementação, decisões relativas ao processo.

• Desafios encontrados: problemas com o produto/processo de desenvolvimento.

• Testes: testes realizados e resultados obtidos.

AVISO IMPORTANTE! Direitos Autorais

Cada grupo será responsável por certificar que qualquer material usado no processo e no produto não têm restrições relacionadas a qualquer aspecto, em particular relacionadas a Direitos Autoriais. Este tipo de problema faz parte da avaliação e poderá acarretar grande impacto nas notas.

Para mais informações sobre direitos autorais em jogos, o site gamasutra.com  apresenta e discute alguns mitos sobre materiais protegidos. No caso de desenvolvimento de jogos não se pode, por exemplo, solicitar para si o direito sobre a ideia de blocos que caem e desaparecem quando estes formam uma linha[1]. Contudo, conteúdos multimídias envolvidos no jogo (música, texto, ícones, fotos, API’s, bibliotecas e etc) podem estar protegidos pelos “direitos de cópia” (copyright). Além destes, conteúdos de livros de Engenharia de Software incluindo perguntas e respostas, podem ter direitos autorais e de comercialização.

Para auxiliar no desenvolvimento dos jogos, existem repositórios que oferecem conteúdo não protegidos por direitos autorais:

• O site archive.org oferece diversos tipos de conteúdo multimídia que são de livre utilização para fins acadêmicos. Para maiores detalhes acesso Termo de Uso do site.
• Este artigo da Wikipédia apresenta diversas fontes de áudios que são de domínio público ou livre.
• Neste artigo fontes de domínio público para imagens.

Uma sugestão para todos os grupos é incluir o requisito de que o jogo tenha a funcionalidade “Créditos” em que se exibe todo o material utilizado, mesmo aqueles que são livre, durante o desenvolvimento da aplicação. Esta abordagem deve ser utilizada quando o jogo utiliza algum conteúdo para explicar determinado conceito de Engenharia de Software.

[1] http://gbgames.com/blog/articles/indie-legal-copyright-and-trademark/what-an-indie-needs-to-know-about-copyright/

Primeira postagem - Ganhando XP

Primeira Apresentação Engenharia de Software

Ganhando XP

Jogo

O jogo escolhido se baseia em uma narrativa de aventura onde um personagem irá aprender conceitos de Engenharia de Software através de um mestre. Após a fase de aprendizado, o personagem enfrentará em seu caminho um inimigo que testará seus conhecimentos em uma batalha de perguntas. Cada resposta certa do personagem corresponderá a um dano em seu oponente, bem como cada resposta errada será recebido como um dano.

Plataforma

A plataforma de desenvolvimento escolhida foi a Web devido ao maior conhecimento na área por parte dos programadores, o que poupará tempo de aprendizado na implementação, garantindo assim que o maior esforço se de no foco do trabalho: a execução do projeto seguindo o processo de produção de software escolhido.

Processos

A metodologia de gerenciamento (framework) escolhida pelo grupo foi o SCRUM. O SCRUM foi escolhido por se tratar de uma metodologia de gerenciamento dinâmico que será mais facilmente adaptado às necessidades de um projeto de tão curto prazo como o que teremos que desenvolver.

A divisão do Time do Scrum foi feita de acordo com a tabela abaixo:

Mestre do Scrum	Dono do Produto	Equipe de Desenvolvimento
Guilherme Jácome de Paula	Danilo Pacheco Lima	Matheus Jamil Alves Rachid
		Márcio Danilo Costa Júnior
		Lorena Barreto Simedo
		Danilo Pacheco Lima
		Lucas Gabriel Aeraf de Assis
		Bernardo Brescia
		Helbert Luiz Paulino
		Jota Júnior

As tarefas do projeto foram divididas de acordo com as seguintes premissas.

• Reuniões diárias de 10 a 20 minutos para definição de novos requisitos e esclarecimentos de possiveis conflitos ou correção de erros.
• Corridas de duas semanas com o objetivo de ter sempre uma entrega pronta para cada apresentação em sala
• Corridas bem definidas em que o resultado final será revisado, analizado, testado e em que erros serão documentados.
• Divisão do time de programadores em dois pares; dois programadores de front e dois programadores de back.

A equipe de desenvolvimento foi dividida da seguinte forma:

• Programadores de front: Danilo Pacheco Lima e Lucas Gabriel Aeraf de Assis
• Programadores de back: Jota Júnior e Matheus Jamil Alves Rachid
• Testes:Lorena Barreto Simedo
• Criação de Elementos Gráficos:Márcio Danilo Costa Júnior
• Enredo/Roteiro:Helbert Luiz Paulino e Lorena Barreto Simedo
• Revisor de elementos de aprendizado: Bernardo Brescia

Definição Inicial das Corridas

	2ª Semana(30 de setembro)	4ª Semana(14 de outubro)	6ª Semana(28 de outubro)	Considerações finais (até 8 de novembro)
Entrega 1	Front do produto com uma fase demo de aprendizado
Entrega 2		Front do produto com uma fase demo de batalha
Entega 3			Front das fases de jogo integradas com requisitos fundamentais implementados	Produto final com todas as funcionalidades e requisitos extras

As corridas serão mais bem definidas e detalhadas à medida que as atividades forem sendo desenvolvidas.

CMMI-DEV Nível 2 de Maturidade

Prezando pelo desenvolvimento do software seguindo os preceitos do nível 2 de maturidade do CMMI-DEV, decidimos:

• No Gerenciamento de Requisitos, fazer a especificação dos mesmo como  Histórias de Usuário, utilizando a ferramenta Trello para controle e histórico.

• No Planejamento do Projeto, será definido o cronograma de atividades, através de uma reunião entre o Mestre do Scrum (Guilherme Jácome), o Dono do Produto (Danilo Pacheco) e o restante da equipe, com o intuito de se levantar o escopo do projeto e estabelecer os primeiros requisitos a serem realizados, estimando o tempo necessário para a realização das tarefas dentro da primeira corrida.

• Para o Acompanhamento e Controle do Projeto, utilizaremos a ferramenta Asana na qual será possível o acompanhamento individual e coletivo da realização das tarefas do projeto, bem como análises gráficas de desempenho de atividades concluídas e pendentes. Manteremos sempre um diálogo aberto para incentivar a participação e a cooperação de todos os membros do grupo e, quaisquer ações e mudanças que devam ocorrer na execução das tarefas serão coordenadas pelo Mestre do Scrum.

• Por fim, como Gerência de Configuração, adotaremos o Controle de Versão utilizando um repositório privado no GIthub.

Primeira Postagem - Grupo 3

O Jogo

Inicialmente, a proposta contemplava a produção de um jogo no estilo “clicker” mas, após recomendações incisivas do professor durante a apresentação em sala, o grupo decidiu alterá-la.

A nova proposta consiste na implementação um jogo no estilo “fantasy” onde haverá um gerenciador da empresa onde o jogador recebe um projeto e deve selecionar os melhores integrantes para fazer parte de sua equipe. Cada integrante será representado por suas habilidades e também será vinculado a um custo. O objetivo do jogador é aumentar a sua pontuação visando adquirir membros mais talentosos e, por conseguinte, mais caros. Temos jogos como “Cartola FC” e “NFL Fantasy” que servem de exemplo de jogos que seguem essa filosofia.

Durante a sua jornada, o jogador irá se deparar com mini-jogos (como no formato de “quiz”, por exemplo) cuja temática será relacionada aos conceitos de Engenharia de Software e servirão para que pontos sejam acumulados, possibilitando uma evolução do nosso personagem.

Processo de Desenvolvimento

O processo escolhido para o desenvolvimento foi o SCRUM. Nele, os projetos são divididos em ciclos chamados de Sprints. Geralmente cada sprint tem um período que pode variar de poucos dias a algumas semanas. Para este trabalho, foi definido o praze de duas semanas para a realização de cada sprint. As pessoas envolvidas no processo de desenvolvimento são dividas em três papéis: o Scrum Master, o Product Owner (dono do produto) e a equipe.

O Product Owner é o maior interessado no software pois é aquele que teve (ou que representa quem teve) a necessidade do produto e por isso tem a visão do produto. Define o que deve ser feito e prioriza as funcionalidades a serem desenvolvidas, mantendo-as em um artefato chamado de product backlog (uma lista de todas as funcionalidades que devem ser implementadas e ordenadas por prioridade). É também responsabilidade do Product Owner passar toda a informação de negócio que for necessária para que a equipe possa transformar suas ideias em software.

A Equipe é composta por um número que varia de cinco a nove pessoas e possui integrantes com as mais diversas habilidades possíveis necessárias no desenvolvimento do produto final. O principal objetivo dela é implementar as funcionalidades que foram selecionadas para serem desenvolvidas na iteração e entregá-las em funcionamento ao final desse período.

O Scrum Master, também chamado de facilitador, é responsável por manter o processo em funcionamento, garantindo assim que o objetivo da iteração seja atingido. É importante ressaltar que o Scrum Master não atua como um gerente ou chefe da equipe porque a equipe é auto-organizável. O Scrum Master não determina o que cada membro da equipe deve ou não fazer: a equipe se compromete com a entrega das funcionalidades e, então, se auto-organiza, definindo por quem e em qual momento as tarefas serão realizadas.

Toda sprint começa com uma reunião de planejamento (Sprint Backlog), que é dividida em duas partes. A primeira delas tem um enfoque mais estratégico, na qual se decide o que será feito, isto é, quais funcionalidades serão implementadas e define-se uma meta para a Sprint. Para isso, o Product Owner apresenta os itens do product backlog, e a equipe obtém informações suficientes sobre cada um dos itens, dessa forma, é possível fornecer uma estimativa que expresse um tamanho ou um número de horas para o trabalho e assim seja definido quantas e quais tarefas poderão ser desenvolvidas no sprint (de acordo com a velocidade da equipe que é calculada através de dados de sprints passados).

Depois de definidas quais tarefas serão desenvolvidas no sprint, a equipe utiliza a segunda parte da reunião, que tem um enfoque mais tático, para decidir como serão feitas as tarefas. Então se analisa tarefa por tarefa com mais detalhes, mais informações de negócio são apresentadas e é possível tomar diversas decisões de negócio e decisões técnicas.

Ao fim da reunião de planejamento a equipe começa a trabalhar nas tarefas, respeitando as prioridades. Todos os dias é realizada uma reunião para que a equipe converse sobre o andamento do sprint.

Ao fim do sprint, mais duas reuniões acontecem: a reunião de revisão e a reunião de retrospectiva. Na reunião de revisão a equipe apresenta ao Product Owner o trabalho que foi desenvolvido durante a sprint, para que ele possa oferecer feedback, e aprovar ou não tudo o que foi produzido. Na reunião de retrospectiva os principais acontecimentos do sprint são apresentados e discute-se sobre as lições aprendidas e melhorias que podem ser aplicadas ao processo.

Motivos para escolha do Scrum:

• Não exige programação em pares;
• Possui papéis bem definidos;
• Mais flexível quanto às técnicas de desenvolvimento;
• Iterações bem definidas (Sprint com escopo imutável);

Tecnologia

A tecnologia alvo do projeto é a plataforma Web pois:

• Tecnologia facilmente testável;
• Maior difusão entre usuários;
• Menor dependência de softwares e bibliotecas, do ponto de vista do usuário;

Motor do Jogo

O motor gráfico escolhido foi o Unity pois:

• É uma plataforma de desenvolvimento de jogos consagrada;
• Possui tutoriais disponíveis para aprendizado da ferramenta (ex: http://unity3d.com/learn);
• Haver a possibilidade de exportar o projeto para diversas plataformas;
• Pode ser programada em C# ou Javascript;
• É uma ferramenta para desenvolvimento de jogos em 2D ou 3D;

Ambiente de Desenvolvimento

Para ambiente de desenvolvimento, usaremos o MonoDevelop por:

• Possuir integração com Unity para criar e manter arquivos de projetos;
• Haver uma facilidade no compartilhamento de código;
• Ser interface limpa e minimalista;

Controle de Versão

O GitLab foi escolhido como ferramenta de controle de versão. Ele apresenta as seguintes características:

• Servidor de repositórios Git;
• Interface amigável;
• Possui um Issue Tracker nativo;
• Permite utilizar ferramentas de CI;
• Facilita os testes;
• Permite ter macro visões do projeto;

Papéis no projeto

Os integrantes do grupo foram divididos entre os papéis de SCRUM Master, Product Owner e Equipe da seguinte maneira:

• SCRUM Master (SM):
• Gustavo Mitsuichi
• Product Owners (PO):
• Vitor Lopes
• Equipe:
• Andre Cunha
• João Penna
• Marco Antonio
• Nivaldo Teixeira
• Pedro Bernardina
• Renan Aragão
• Victor Muniz
• Wilson Carlos

Cronograma

Abaixo segue o cronograma para a execução do projeto:

Data	Descrição da Atividade
15/09	Apresentação - 1
20/09	Reunião de planejamento: enfoque estratégico e tático
22/09	Sprint Backlog - 1 Início da Sprint - 1
06/10	Final da Sprint - 1 Reunião de revisão - 1 Reunião de retrospectiva - 1 Apresentação - 2 Sprint Backlog - 2 Início da Sprint - 2
20/10	Final da Sprint - 2 Reunião de revisão - 2 Reunião de retrospectiva - 2 Sprint Backlog - 3 Início da Sprint - 3
27/10	Apresentação - 3
03/11	Final da Sprint - 3 Reunião de revisão - 3 Reunião de retrospectiva - 3
08/11	Entrega do produto Apresentação - 4 (Final)