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)

Primeira postagem - CRUD para sempre

Processo de Desenvolvimento

Framework

O framework de desenvolvimento escolhido pelo grupo foi o Scrum, que  é um framework para gerenciamento e organização de projetos ágeis, tais como projetos de desenvolvimento de software. A base fundamental do Scrum (Imagem 1) é composta por: papéis principais, atividades básicas e seus artefatos.

Escolhemos esse framework devido à sua transparência, seu fácil monitoramento e adaptação. Além disso, uma das principais características do Scrum é facilitar o desenvolvimento de produtos complexos de maneira incremental e iterativa. Dessa forma, pretendemos decompor nosso projeto, em pequenos subprodutos mais simples, mais rápidos e mais fáceis de serem desenvolvidos e entregues.

Uma vez que a equipe possui 12 membros relativamente independentes (incluindo o dono do produto e o mestre do scrum), além de prazos bem curtos de entrega, as características encontradas no Scrum serão cruciais para o sucesso do projeto.

Imagem 1. Base fundamental do Scrum

Cronograma

O cronograma a ser seguido (Tabela 1) foi criado a partir das atividades básicas do Scrum e seus artefatos. Foi decidido que cada iteração (sprint) vai ter a duração fixa de 2 semanas, de modo que a equipe realize 3 entregas de software. Durante esse processo de desenvolvimento, serão realizados scrums diários, podendo ser pessoalmente ou por meio de videoconferência, facebook, etc.

Para estimar o tamanho de cada item da reserva de requisitos do produto, o time irá utilizar pontuação de histórias, que deverão ser votados e consentidos por todos os integrantes do time de desenvolvimento através do planning poker. Feito isso, cabe ao proprietário do produto priorizá-los.

Datas	Eventos	Artefatos
15/09	Planejamento do produto e das iterações	Reserva de requisitos da corrida e do produto
29/09	Revisão da iteração e planejamento de uma próxima iteração	Reserva de requisitos da corrida
13/10	Revisão da iteração e planejamento de uma próxima iteração	Reserva de requisitos da corrida
27/10	Revisão da iteração	Produto final

Tabela 1. Cronograma de entregas

Divisão do grupo

Escolhido o processo de desenvolvido, o grupo definiu uma forma de organização de forma que os papéis a serem desempenhados por cada integrante sejam aderentes ao processo de desenvolvimento escolhido, Scrum. Sendo assim, dividimos o grupo em três papéis principais:

Papel	Participante(s)	Funções
Dono do produto	Rafael Libânio Solli	É o “dono do projeto”. Ele representa os interesses da equipe, concretiza a visão do produto e gerencia a reserva de requisitos do produto
Mestre do Scrum	Thiago Silva Martins	É o coach (mentor ou treinador) da equipe, que é responsável por orientar, proteger e manter a equipe focada
Time de Desenvolvimento	Amanda Cristina Castro dos Santos, Ana Karolina Madeira Vilhena, Guilherme Resende Borges, Guilherme Vieira Leobas, Gustavo Roscoe de Assumpção, Junio Cezar Ribeiro da Silva, Marcelo Anselmo Gomes, Marcos Paulo Quintão Fernandes, Mariana de Oliveira Santos Silva e Rômulo Nogueira Coutinho	É auto-gerenciado e auto-conduzido. O time possui habilidades multifuncionais e é o responsável pela entrega do produto

Além da divisão acima, optamos por não determinar ainda o papel de cada desenvolvedor para, assim, manter a característica dinâmica do processo, apesar de ser evidente o fato de que alguns membros possuem certas habilidades que outros não possuem.

Detalhes do jogo

O jogo será desenvolvido utilizando o motor de jogo Unity, de modo que poderá ser executado em diferentes plataformas, como Windows, Linux e Mac. Também deverá ser utilizado o ambiente de desenvolvimento MonoDevelop, o editor de texto padrão da Unity.

O sistema de controle de versões Git foi escolhido como CVS, por meio do serviço de hospedagem gratuito GitHub, o qual todos os membros da equipe já estão familiarizados. Além disso, ele oferece suporte para desenvolvimento não linear e distribuído, é compatível com protocolos existentes (HTTP, FTP, rsync),  eficiente e escalável.

Como sistema de gerência de tarefas e iterações, será utilizado o aplicativo de gerenciamento de projetos Trello, pelo fato de disponibilizar diversos recursos úteis em sua versão gratuita. Além disso, para armazenar os artefatos, foi criado um diretório compartilhado no Google Drive.

A coordenação dos testes de unidade será realizada por meio do serviço de integração contínua ao GitHub, Travis CI, como foi sugerido por um dos integrantes. E para a criação artística, deverão ser utilizadas diversas ferramentas como Photoshop, Illustrator, Blender, CorelDraw, etc.