Jogo Sério para Aprendizagem de Estimação em Projetos de Software

Para Apreciação por Júri FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO Jogo Sério para Aprendizagem de Estimação em Projetos de Software Nuno Filipe Dinis Cruz Mestrado Integrado em Engenharia Informática e Computação Orientador: Nuno Honório Rodrigues Flores 27 de Junho de 2016 Jogo Sério para Aprendizagem de Estimação em Projetos de Software Nuno Filipe Dinis Cruz Mestrado Integrado em Engenharia Informática e Computação 27 de Junho de 2016 Resumo A Engenharia de Software é um campo de estudo bastante extenso, sendo que a sua aprendizagem requer a abordagem ao tópico em questão. Para a aprendizagem ser efetiva é normalmente necessário a simulação de situações do mundo real para verdadeiramente conseguir aprender e aplicar os diferentes conceitos. Neste contexto pretende-se fazer a demonstração da eficiência de Jogos Sérios para o ensino de tópicos de Engenharia de Software, através do design e desenvolvimento de um Jogo Sério para Estimação de Projetos Software, um tópico específico. Este tipo de jogos apresenta as condições ideais para a sua aprendizagem, pois permitem ao utilizador experienciar situações semelhantes à realidade e divertir-se, tudo isso enquanto está a aprender. A fase inicial passa por uma abordagem e pesquisa às técnicas de aprendizagem ideais para o jogo sério dado o contexto em que se insere, sendo também importante o estudo de Game Design Patterns (Elementos de Jogo) a implementar, que vão auxiliar na fase de design. Após o planeamento veio a implementação do jogo, que foi submetido a validação através de testes de aprendizagem por estudantes de Engenharia Informática ainda sem conhecimentos de Engenharia de Software . Palavras-chave: jogo sério, engenharia de software, aprendizagem, estimação, projetos de software i ii Abstract Software Engineering is a vast and broad field, and specific learning outcomes depend on the topic to be addressed. For the learning to be effective and to truly learn the different concepts, it is necessary to have practical training in principles, methods and procedures under conditions similar to developing real software products. In this context, the aim of this dissertation is to demonstrate the efficiency of Serious Games for learning Software Engineering topics, by designing and developing a serious game for learning Software Project Estimation. This game type gathers the needed conditions to the learning of these topics, allowing the user to experience real life situations and have fun, all while gaining new knowledge. The initial phase is a research of learning techniques as well as Game Design Patterns to help in the design and concept of the game. After the planning phase, the game was developed and it was validated by learning tests whose subjects were Computer Science students with no prior knowledge of Software Engineering topics. Keywords: serious game, software engineering, learning, software project, estimation iii iv Agradecimentos Quero agradecer ao orientador desta dissertação, Nuno Honório Flores, pelo apoio e dedicação prestados, tendo seguido o progresso do trabalho e contribuído com várias sugestões na conceção deste. Agradeço também à minha família e aos meus colegas de faculdade que me acompanharam e me apoiaram ao longo desta jornada. Nuno Cruz v LISTA DE TABELAS xii Abreviaturas e Símbolos 2D Bidimensional 3D Tridimensional US User Story xiii Capítulo 1 Introdução2 1.1 Contexto/Enquadramento4 O desenvolvimento de jogos para a educação é uma área em crescimento. Apesar de jogos para educação estarem normalmente associados a jogos para crianças, existem também jogos para6 treinar ou passar conhecimentos a adultos. Estes são chamados de jogos sérios. A Engenharia de Software é um campo de estudo bastante vasto, sendo que necessita de casos práticos semelhantes8 ao desenvolvimento de software na vida real para a sua aprendizagem ser eficaz. Num contexto de ensino muitas vezes isto não é possível por restrições de tempo, havendo apenas uma abordagem10 teórica. Os jogos sérios fornecem uma solução para as necessidades da aprendizagem de tópicos da Engenharia de Software.12 1.2 Motivação e Objetivos O objetivo principal desta dissertação é o de contribuir para a aprendizagem de tópicos de14 Engenharia de Software com um método de ensino complementar. Isto é feito através do desenvolvimento e implementação de um jogo sério, para demonstrar a sua eficácia na aprendizagem.16 Este jogo sério é sobre o tópico Estimação em projetos de Software, sendo feita uma validação do jogo através de uma experiência com estudantes de Engenharia Informática, apenas com noções18 básicas sobre Engenharia de Software. 1.3 Estrutura da Dissertação20 Para além da introdução, esta dissertação contém mais 5 capítulos. No capítulo 2é descrito o estado da arte, são apresentados trabalhos relacionados e são analisadas ferramentas de desenvol-22 vimentos de jogos. No capítulo 3é feito um sumário do problema que se pretende resolver e da solução proposta. De seguida, é descrita no capítulo 4a conceção e implementação do jogo sério24 1 Introdução desenvolvido. No capítulo 5são explicados alguns detalhes relevantes do motor de regras do jogo. No capítulo 6é feita a validação do jogo através de uma experiência com estudantes e uma análise 2 de resultados. Por fim, são feitas as conclusões no capítulo 7. 2 Capítulo 2 Revisão Bibliográfica2 Neste capítulo é descrita a revisão bibliográfica efetuada, sendo abordados os seguintes concei-4 tos: engenharia de software, metodologias de desenvolvimento, estimação e técnicas de estimação, e jogos sérios. Também são apresentados trabalhos relacionados para mostrar o que existe neste6 domínio, e discutidos alguns motores de jogo. 2.1 Engenharia de Software8 A Engenharia de Software é o estudo da aplicação de Engenharia ao desenho, desenvolvimento e manutenção de Software, através da "aplicação de abordagens sistemáticas, disciplinadas10 e quantificáveis"[BF14]. Este campo de estudo abrange as diversas áreas associadas ao processo de desenvolvimento de um projeto de Software como Requisitos, Desenho, Implementação, Teste12 e Manutenção. Na parte de Requisitos, é feito um processo de elicitação, análise, especificação e validação14 dos requisitos para o projeto. Um requisito pode ser definido como uma necessidade funcional que vem resolver um dado problema. É nesta fase que uma metodologia Agile (secção 2.1.1), faz16 a elicitação de User Stories. O Desenho de software é o ciclo de vida no qual os requisitos são analisados de forma a18 gerar uma descrição da estrutura interna do produto. Isto inclui vários diagramas e modelos que demonstram a arquitetura e os componentes de Software existentes.20 A parte da Implementação é a criação de software funcional, através da criação e verificação de código. Esta verificação inclui testes unitários e de integração. Esta parte de construção de22 software tem uma relação com a parte de Desenho e de Testes. O Teste do software consiste na verificação dinâmica do comportamento de um programa. São24 criados casos de teste para verificar que o comportamento do programa é o expectável. 3 Revisão Bibliográfica A Manutenção de software é a o acompanhamento das mudanças e evolução que um produto requer. Isto inclui a correção de erros, implementação de novos requisitos ou uma mudança das 2 condições de operação. 2.1.1 Metodologias de Desenvolvimento de Projetos de Software 4 Existem 2 metodologias principais de desenvolvimento [Gha16][Boe02]: Tradicionais (planbased) e Agile. A Metodologia Tradicional aposta na previsibilidade do projeto, através de plane6 amento compreensivo e de documentação extensiva. Esta Metodologia é mais usada em equipas de grande dimensão. 8 Agile tem como princípio "A maior prioridade é satisfazer o cliente através de entregas de Software cedo e de maneira contínua", ou seja, tem como objetivo produzir software desde cedo 10 dando resultados ao cliente, e evitar perder tempo a fazer planeamentos elaborados. Nesta metodologia aposta-se numa adaptação às mudanças em vez de seguir um plano, e software funcional 12 tem prioridade sobre a documentação. Esta metodologia tem mais sucesso em equipas de tamanho pequeno-médio. O foco desta dissertação irá ser sobre este método. 14 Processos de Desenvolvimento de Software 16 Figura 2.1: Processo do Modelo em Cascata Dentro de cada uma destas metodologias existem vários processos de desenvolvimento de Software [AI13], que consistem na divisão das diferentes partes de desenvolvimento de software 18 em fases. Um exemplo de uma metodologia tradicional é o processo Waterfall (imagem 2.1). Este é um processo sequencial, que segue a seguinte ordem de fases: Requisitos, Desenho, Implemen20 tação, Testes e Manutenção. Os processos da metodologia Agile têm vindo a crescer e a ganhar popularidade [DD08][SA08]. 22 Nesta metodologia os processos existentes são caracterizados por ter ciclos de vida mais curtos, repetidos de forma iterativa (imagem 2.2). Ao contrário dos métodos tradicionais, isto permite 24 4 Revisão Bibliográfica uma maior liberdade para o cliente, podendo este mudar de ideias e alterar requisitos sem causar transtorno no desenvolvimento do projeto. Alguns dos processos populares são Extreme Program-2 ming eScrum. 4 Scrum No método Scrum, após o levantamento inicial de requisitos, estes são agregados no Product6 Backlog. O Product Backlog é a listagem de tarefas existentes, sob a forma de User Stories. Estas são tarefas descritas do ponto de vista do utilizador final, sendo que apartir destas, um programador8 consegue perceber o esforço e complexidade inerentes a implementar essa funcionalidade. Os ciclos de desenvolvimento são chamados de sprints, sendo estes períodos de tempo durante10 o qual são implementadas as funcionalidades descritas nas USs. Isto permite à equipa de desenvolvimento escolher a quantidade de trabalho que vai realizar, criando um ambiente mais flexível.12 Em cada sprint há uma reunião para discutir o progresso do projeto e definir o que vai ser feito de seguida.14 Neste processo existem papéis como o Scrum Master e o Product Owner. O Scrum Master é considerado o líder da equipa, que gere cada incremento do projeto. O Product Owner é alguém16 que representa os interesses do cliente, sendo responsável por transmitir a sua ideia do produto final.18 Figura 2.2: Processos da metodologia Agile 2.1.2 Aprendizagem Dada a extensividade deste campo de estudo, o seu ensinamento apresenta algumas dificulda-20 des. Numa faculdade, em que o número de conceitos a passar é tão elevado, muitas vezes é apenas possível uma abordagem teórica, não havendo possibilidade de uma componente prática [Sha00].22 Isto nem sempre permite uma aprendizagem eficaz da Engenharia de Software, pois são necessários casos práticos para melhor consolidar e aplicar os conceitos aprendidos. Além disto, um24 estudante de Engenharia de Software precisa de alguns requisitos como ser proficiente em design e programação de software, resolver possíveis problemas e comparar alternativas, e considerar o26 ponto de vista do utilizador. 5 Revisão Bibliográfica 2.2 Estimação em Projetos de Software A Estimação é uma sub-área da Engenharia de Software, associada à parte da Gestão. Esta 2 consiste em fazer estimativas do tempo e custo de cada tarefa de um Projeto de maneira a conseguir controlar o seu desenvolvimento para satisfazer os seus objetivos. McConnel [McC06] diz "O 4 objetivo principal da estimação não é o de prever o estado final de um projeto; é o de determinar se as suas metas são suficientemente realistas para que o projeto seja controlado de forma a ir ao 6 encontro destas". Este processo é iterativo, ou seja, são feitas estimativas ao longo do projeto à medida que novos requisitos vão sendo introduzidos ou anteriores são alterados, e tendo em conta 8 o progresso efetuado. Existem consequências tanto para estimativas exageradas (que estimam um tempo maior do 10 que o necessário) como para estimativas otimistas (que estimam um tempo menor do que o necessário) [HIW+04]. Uma estimativa exagerada pode levar a uma baixa produtividade por parte 12 da equipa, ao desperdício de recursos de uma empresa e a exceder o orçamento, assim como a perda de oportunidades de negócio. Por outro lado, uma estimativa demasiado otimista pode afe14 tar a qualidade do produto final, causando atrasos na sua entrega, que como consequência também poderá ter menos funcionalidades. 16 A Estimação é um processo bastante susceptível a erros [Fai92] pois além do juízo humano não ser perfeito, existem algumas dificuldades comuns. Estas podem ser: estimativas prematuras, 18 em que estamos a estimar algo que ainda não entendemos completamente ou que não percebemos a sua complexidade; e falta de dados de histórico para comparação, pois uma estimação absoluta 20 é sempre de maior dificuldade do que uma relativa. Para além de fazer estimativas de tempo e esforço, a estimação também lida com características como dimensão do produto, competências 22 pessoais da equipa de desenvolvimento e orçamento. 2.2.1 Abordagens de Estimação 24 Existem várias categorias de Estimação de Projetos de Software [JS07]. As 3 principais abordagens são Estimação por Juízo de Especialistas, Modelos de Estimação Formais (ou Modelos 26 Paramétricos) ou por combinação de diferentes métodos. A Estimação por Modelos, também conhecida como regression-based estimation, consiste na construção de modelos através da análise 28 de dados de projetos anteriores, com funções e equações matemáticas que relacionam as diferentes variáveis de interesse para a estimação. A Estimação por Especialistas baseia-se na opinião de 30 Especialistas da Área, podendo ser feita por apenas uma pessoa ou por um grupo. O foco desta dissertação irá ser sobre esta última. 32 2.2.1.1 Estimação por Juízo de Especialistas A Estimação baseada em Especialistas é a técnica dominante de estimação [Jor04]. Apesar 34 do crescimento e das vantagens das técnicas baseadas em modelos, a Estimação por Especialistas 6 Revisão Bibliográfica continua a ser a mais usada, sendo também a que oferece maior precisão. Esta técnica é particularmente útil quando não existem dados estatísticos para considerar ou quando o problema a estimar2 é complexo ou abstrato [FM12]. Técnicas de Estimação4 Existem duas técnicas predominantes neste tipo de Estimação [CP14]: Delphi Wideband e Planning Poker. Estas são técnicas de estimação em grupo, que geralmente obtêm uma maior6 precisão em relação a estimativas individuais. Apesar de estas não serem exclusivas de nenhuma Metodologia de Desenvolvimento, são maioritariamente usadas em Agile.8 No Delphi Wideband há um coordenador que começa por explicar a tarefa a ser estimada, e o grupo discute sobre possíveis problemas ou variáveis que a execução dessa tarefa possa ter. Se10 não houver muita discussão, o coordenador atribui alguém para suscitar o brainstorming. Após discussão, cada especialista faz a sua estimativa anonimamente. O coordenador mostra ao grupo os12 resultados e discute as possíveis discrepâncias entre as estimativas. Se houver variações, o grupo vota anonimamente se quer aceitar a estimativa média resultante e em caso negativo, volta-se ao14 passo inicial de discussão sobre a tarefa. No Planning Poker cada membro da equipa tem cartas com números que representam o tempo16 e esforço, sendo comum ter os números da sequência de Fibonacci ou uma sequência de números com 1 e potências de 2 (1, 2, 4, 8, etc). No início um membro da equipa (preferencialmente18 o cliente ou o product owner) anuncia uma tarefa, e a equipa faz perguntas e discute sobre o âmbito e dimensão dessa tarefa. Cada pessoa seleciona a sua carta individualmente, e quando20 todos estiverem prontos as cartas são viradas ao mesmo tempo. Isto é importante para evitar ser influenciado pela opinião dos colegas de equipa. Se houver consenso, passa-se à proxima tarefa22 ou funcionalidade, senão discutem-se os números mais distantes e há uma nova ronda de avaliação do tempo e esforço.24 2.3 Jogos Sérios Os jogos sérios têm vindo a crescer consideravelmente, e têm-se vindo a provar como uma fer-26 ramenta motivante e eficaz de ensino [BKL+13]. Um Jogo Sério é um jogo com o fim de treinar ou educar o seu utilizador. Pode ser visto como um jogo cujo objetivo principal não é o entrete-28 nimento [LES14], apesar de esta ser uma componente também bastante importante. Este tipo de jogos tem vindo a crescer exponencialmente e são usados em várias áreas, como saúde, educação,30 planeamento de situações de emergência, treino militar ou simplesmente treinar um trabalhador a executar determinada tarefa, e até para publicitar (os advergames). Os Jogos Sérios "aproveitam o32 poder dos vídeojogos para cativar e atrair os jogadores para um objetivo específico como aprender novas habilidades ou conhecimento"[CK14]. Estes apresentam várias vantagens [GMGP15]: per-34 mitem aos utilizadores experienciar situações do mundo real que de outra maneira seriam difíceis em termos de custo e tempo, e são mais eficazes que os meios de ensino tradicionais em termos de36 treino de habilidades cognitivas. Lamaarti acredita que o termo "sério"vem da intenção dos jogos 7 Aprendizagem de Estimação de Software com um Jogo Sério 14 Capítulo 4 Conceito e Implementação do Jogo2 Neste capítulo é apresentado o jogo desenvolvido. Para tal, são detalhados aspetos da sua im-4 plementação como o seu design, os objetivos de aprendizagem e as suas mecânicas. Na primeira secção é feita uma descrição geral do jogo e são mostrados os objetivos de aprendizagem. A seguir6 é explicada a história do jogo e o seu objetivo principal para o jogador. A terceira secção descreve os diferentes cenários de jogo existentes e o seu gameplay, falando também das personagens exis-8 tentes. De seguida são referidos os controlos do jogo, e as suas métricas e pontuação. Por fim, fala-se dos padrões de desenho considerados na implementação do jogo.10 4.1 Introdução Foi desenvolvido um jogo sério, cujo objetivo principal é o de fornecer um método comple-12 mentar de aprendizagem para a Estimação de Software. Para o seu desenvolvimento foi usada a ferramenta de produção de jogos Unity3D, devido às características referidas na revisão bibliográ-14 fica. Na fase de conceção do jogo, o foco escolhido foi a estimação Agile com ênfase na técnica do Planning Poker. Esta escolha deveu-se à popularidade e adesão que esta metodologia e técnica16 têm. A ideia de jogo estabelecida foi a de simular um ambiente de trabalho real em que o utilizador18 desempenha um papel com foco na parte de estimação. Com isto pretende-se que o utilizador aprenda diferentes conceitos enquanto está a desfrutar de uma jogabilidade interessante. No jogo,20 o utilizador é o estimador de uma equipa de desenvolvimento, cuja equipa de programadores vai desenvolver um projeto de software. Neste, o jogador terá de fazer a estimação do esforço e22 complexidade das diferentes tarefas e ver as consequências das suas escolhas. 15 Conceito e Implementação do Jogo 4.1.1 Objetivos da Aprendizagem No final do jogo, espera-se que o utilizador adquira vários conceitos e conhecimentos sobre a 2 Estimação de Software. De forma geral, os conceitos a passar são: •Estimação de Software: o que é e para que serve; vários conceitos como sprint euser stories;4 •Planning Poker: como funciona esta técnica de estimação; •Scrum: conceitos gerais desta metodologia de desenvolvimento; quais os diferentes papéis 6 existentes; 4.2 História e Objetivos 8 O jogador acabou de ser contratado pela empresa EEEE (Expert and Efficient Estimators Enterprise), uma companhia de desenvolvimento de software. Nesta, ele irá desempenhar o cargo de 10 “Estimador de Software Júnior”, um cargo fictício e especializado na parte da estimação de software. Em conjunto com uma equipa de 4 software developers, vai ser desenvolvido um projeto 12 que consiste numa aplicação local para lojas físicas. Nesta aplicação, um cliente da loja poderá fazer operações como pesquisar, consultar, comentar e classificar produtos e um gerente poderá 14 gerir o inventário, assim como os produtos e as contas de utilizador. Todas estas funcionalidades são apresentadas sob a forma de User Stories, tarefas para os programadores implementarem. 16 O objetivo principal do utilizador é o de entregar o projeto completo e a tempo. Para isso, ele terá de completar os diferentes sprints que constituiem o projeto. Estes sprints semanais são 18 períodos de tempo durante o qual a equipa de programadores vai implementar as USs escolhidas para essa semana. Em cada sprint há uma reunião para falar do que vai ser feito. É nessa reunião, 20 no início de cada sprint, que o utilizador irá fazer a estimação do esforço e complexidade das diferentes USs. Isto tem impacto na importância e dedicação que os programadores vão dar a essa 22 tarefa. 4.3 Cenas de jogo e gameplay 24 No início do jogo é apresentado um ecrã de criação do personagem do jogador, com nome e avatar. Após criação do personagem é feita uma introdução do jogo, que explica ao utilizador 26 o âmbito deste. Feita a introdução, existem 2 cenas principais de jogo: a sala de reunião onde é feita a estimação das USs usando Planning Poker, e o escritório onde se podem consultar diversas 28 informações acerca do projeto. Estas cenas são descritas nas secções seguintes, sendo possível consultar mais algumas capturas de ecrã em anexo. 30 16 Conceito e Implementação do Jogo 4.3.1 Cena de Introdução Figura 4.1: Imagem da introdução do jogo No início do jogo é feita uma introdução ao jogador (imagem 4.1). Nesta é explicado o ambi-2 ente do jogo: a empresa, qual o projeto a desenvolver e o que ele terá de fazer para isso. São dados alguns conceitos iniciais de Scrum, como US e sprint, e qual o propósito e benefícios de fazer esti-4 mação de software. É feita também a apresentação dos constituintes da sua equipa, nomeadamente os software developers, o Scrum Master e a Product Owner (imagem 4.2).6 4.3.1.1 Personagens No jogo existem 7 personagens, cada uma com o seu papel. O Guru Master é o sábio mestre8 da estimação, responsável por integrar e introduzir o jogador ao jogo. É ele que faz a narração inicial e que dá ajuda ao jogador com uma explicação breve do que é necessário fazer em cada10 fase do Planning Poker. John, o Scrum Master, é descrito como o líder da equipa: ele é responsável por gerir o projeto12 e garantir que está tudo a correr bem. Ele sabe o que tem de ser feito e tem boas capacidades de comunicação. No jogo, ele serve como mediador da reunião semanal.14 Natalie, a Product Owner serve como intermediária entre a equipa e o cliente que encomendou o produto. Ela tem a sua visão do estado final do produto e o seu objetivo é passar isso à equipa.16 Também é responsável por definir e prioritizar as USs e é ela quem valida e aceita as tarefas completadas. No jogo, o seu papel é o de responder às perguntas do utilizador.18 17 Conceito e Implementação do Jogo Figura 4.2: Imagem da introdução do jogo - Colegas de equipa Existem 4 team developers, cada um com os seus níveis de conhecimento, que influenciam a sua capacidade de dar estimativas. O Peter é o back-end developer, o Adam é o front-end 2 developer, a Sarah tem alguns conhecimentos de integração e de front-end e o Barry é o novato da equipa, não tendo conhecimentos aprofundados em nenhuma das áreas. 4 4.3.2 Sala de reunião O jogador começa por participar numa reunião semanal de Planning Poker. Nesta, o Scrum 6 Master começa por anunciar uma User Story. Uma US é uma funcionalidade descrita do ponto de vista do utilizador final, como por exemplo “Como cliente da loja, quero poder avaliar e dar a 8 minha opinião sobre os produtos existentes, para os outros utilizadores poderem obter informação adicional”. A partir desta, um software developer rapidamente percebe "quem", o "quê"e "para 10 quê", conseguindo perceber o esforço e complexidade inerentes a uma US. Para cada US existem duas fases: fase de questões e fase de estimação. 12 Na fase de questões o jogador escolhe uma pergunta a fazer à Product Owner (imagem 4.3), com o objetivo de recolher o máximo de informação útil acerca dessa tarefa. Uma escolha acertada 14 aumenta também o conhecimento dos colegas da equipa sobre a US, aumentando a probabilidade de eles estimarem corretamente. Com esta fase pretende-se que o jogador consiga reconhecer 16 perguntas relevantes que sejam importantes para a compreensão da US, distinguindo também perguntas que possam não fazer tanto sentido. 18 18 Conceito e Implementação do Jogo Figura 4.3: Planning poker - pergunta à Product Owner Na fase de estimação (Planning Poker), o jogador e a equipa vão então fazer a estimação da US. A estimação consiste na atribuição de um valor representativo da complexidade e esforço que2 implementar essa tarefa envolve, sendo estes valores denominados de User Points. É usada uma escala de 4 valores: 1, 2, 4 e 8 (muito fácil, fácil, moderado e difícil). Nesta fase, cada programador4 da equipa e o jogador vão mostrar uma carta com o valor que acham correto, sendo depois iniciada uma discussão de maneira a chegar a um acordo. O jogador começa por selecionar uma das 4 cartas6 disponíveis, assistindo depois à discussão dos colegas da equipa, como é possível ver na imagem 4.4. Nesta parte, cada programador da equipa dá uma justificação da sua estimativa. No final, se8 a estimativa do jogador tiver sido diferente da estimativa para a qual os colegas convergiram, ele pode escolher aceitar a opinião dos colegas ou forçar a estimativa dele.10 Todo este processo é repetido com diferentes USs até a soma total dos valor estimados ser maior ou igual a 10. Quando isso acontece, a reunião é terminada e o jogo passa para a seguinte12 cena: o escritório. Existe ainda um botão de ajuda no canto superior direito, cuja função é a de pedir ajuda ao14 Guru Estimator. Quando clicado, dependendo da fase em que se está, este explica brevemente o que o utilizador tem de fazer.16 19 Conceito e Implementação do Jogo Figura 4.4: Planning Poker - Discussão das estimativas 4.3.3 O Escritório Terminando a reunião semanal, o jogador está no escritório (imagem 4.5). Neste ele consegue 2 consultar várias informações sobre o projeto, os colegas de equipa e sobre ele mesmo: •Perfil de Jogador - nível de experiência, cargo atual, número de questões corretas e número 4 de estimações acertadas; •Projeto - progresso do projeto (número de USs completas), sprint atual, número de sprints 6 restantes, conteúdo de cada sprint: as USs existentes e o progresso destas; •Equipa - informação acerca das personagens do jogo e o papel destas; 8 •Base de Conhecimento - contém alguns conceitos que vão sendo aprendidos ao longo do jogo, tendo também alguns conhecimentos novos. 10 Além da consulta de informação, é no escritório que o utilizador consegue passar para a próxima reunião semanal, sendo simulada uma semana de trabalho. Antes da reunião são mostrados 12 os resultados do trabalho conseguido. 20 Conceito e Implementação do Jogo Figura 4.5: Imagem do Escritório 4.3.3.1 Resultados do sprint Após 1 semana de trabalho, são mostrados os resultados do sprint (4.6). Aqui é possível ver as2 USs constituintes do sprint, a estimativa dada pela equipa e o seu progresso. Este progresso pode ser "Terminada", "Não começada"ou "Em Progresso". É ainda possível consultar o Tempo Inativo4 e o Valor para o Cliente. O valor para o cliente é a soma dos User Points efetivos das diferentes USs que foram termi-6 nadas. Este valor representa a qualidade do sprint do ponto de vista do cliente que encomendou o produto. Se for um valor baixo, o utilizador poderá ter estimado abaixo do correto, não havendo8 tempo para terminar todas as tarefas. Idealmente este valor deverá ser 10 (valor da Team Velocity), mas é possível haver uma US em progresso que não vai contar para o Valor do sprint atual por10 não ter sido terminada. O tempo inativo é o tempo que a equipa esteve parada, acontecendo quando um utilizador12 estima acima do suposto: foi usado menos tempo do que o previsto, sobrando algum. Apesar de num caso real o mais provável ser um programador pegar na próxima US, no jogo esta medida é14 usada para passar o conceito de sobrestimação. Olhando para os resultados, o utilizador consegue ter uma avaliação geral das suas estimativas16 da última reunião, e o impacto que estas tiveram no desenvolvimento do projeto. 21 Conceito e Implementação do Jogo Figura 4.6: Resultados do sprint 4.4 Final de Jogo Terminando todas as USs existentes no projeto, o jogador pode entregar o produto. No ecrã de 2 final de jogo (4.7) são mostradas as estatísticas do jogador. A pontuação final é uma combinação de diferentes métricas do jogador: total de experiência adquirida, node questões e estimativas 4 corretas, e o número total de sprints que foi necessário para terminar o projeto. É também mostrada uma avaliação geral qualitativa que pode ser "Boa", "Ok"ou "Não tão boa". 6 4.5 Controlos A interação com o jogo é feita com o rato. Este é usado para abrir e fechar os diferentes menus, 8 e para escolher opções como a pergunta a fazer e a carta de estimação a mostrar. Serve também para continuar a ler os diálogos do jogo. 10 4.6 Métricas do Utilizador Existem 2 métricas principais de performance do utilizador: número de questões e de estima12 ções corretas. Estas vão sendo adquiridas nas reuniões semanais e contribuem para a pontuação final. 14 22 Conceito e Implementação do Jogo Figura 4.7: Ecrã de final de jogo A Experiência do jogador é adquirida ao fazer as questões certas e a estimar o valor certo. O jogador poderá ser promovido para "Estimador de Software Sénior"após chegar a um certo2 nível de experiência. Neste cargo, a forma de estimar nas sessões semanais muda: primeiro os programadores da equipa dão a sua opinião, depois o utilizador escolhe o valor a atribuir à US4 sem saber o valor dado pelos colegas, aumentando ao mesmo tempo a autonomia e a dificuldade do processo. É também desbloqueado o acesso ao menu da base de conhecimento no escritório.6 Para o projeto, no final de cada sprint, além das USs completas são mostradas 2 métricas: Valor para o Cliente, e Tempo Inativo. No final de jogo, é atribuída uma pontuação final.8 4.7 Elementos de Jogo (Design Patterns) No desenvolvimento do jogo foram considerados alguns dos padrões de desenho referidos na10 revisão bibliográfica [LPF15], por serem específicos para a aprendizagem de tópicos de Engenharia de Software. Estes padrões de desenho ajudam na conceção do jogo, contribuindo para a12 obtenção de um ensino eficaz: •Eventos imprevistos: no final do sprint, visto a estimativa real das USs ser oculta, há uma14 imprevisibilidade nos resultados; 23 Motor de Regras 30 Capítulo 6 Validação2 Neste capítulo é feita a validação do jogo implementado. Primeiro descreve-se os aspetos da experiência conduzida, sendo depois apresentados os resultados obtidos e feita uma análise destes.4 6.1 Experiência Empírica Para a validação da efetividade do jogo sério implementado para a aprendizagem de conceitos6 da Estimação de Software foi conduzida uma experiência empírica. Esta foi feita a 1 conjunto de 20 alunos do MIEIC na FEUP. Como requisitos prévios para realizar a experiência os participantes8 deveriam ter um mínimo de experiência em programação e não ter conhecimentos consideráveis sobre a área em questão, de maneira a conseguir avaliar a sua aprendizagem. Com isso em atenção,10 os testes foram feitos usando como participantes alunos do 2oano, que já tiveram algum contacto com programação e ainda não tiveram a Unidade Curricular de Engenharia de Software.12 6.1.1 Protocolo Figura 6.1: Diagrama da Experiência De maneira a conseguir comparar a aprendizagem obtida pelo jogo, foi feita a divisão dos14 alunos em 2 grupos de 10 pessoas. O primeiro, grupo de controlo, não participa na sessão de jogo, respondendo apenas aos questionários. O segundo, o grupo principal, faz a experiência completa16 que consiste em 3 partes: resposta a um questionário de background, ter uma sessão de jogo, e 31 Validação resposta a um questionário de avaliação de conhecimento e de satisfação. Cada parte é descrita nos capítulos seguintes, estando os questionários completos em anexo. 2 6.1.2 Questionário de background (BG) O questionário de background foi respondido simultaneamente pelos 2 grupos, tendo sido feito 4 para determinar os conhecimentos prévios que cada grupo tinha acerca de Estimação de Software e de experiência a programar. Cada questão permite uma resposta em escala de 1 a 5, sendo que 1 6 é "Discordo Completamente"e 5 é "Concordo Completamente". Seguem-se as questões do questionário e a sua justificação, sendo que o conteúdo integral do questionário pode ser visto em anexo. 8 BG1 - Eu tenho experiência em programação de software.10 Com esta questão abrangente pretende-se aferir o nível de experiência do utilizador, para garantir que têm conhecimentos mínimos para conseguir perceber o jogo. 12 BG2 - Tenho experiência considerável a usar... Java/SQL/Swing/HTML. 14 Esta questão tem o mesmo objetivo da anterior, sendo um pouco mais específica. Estas linguagens foram escolhidas tendo em conta o que é ensinado no curso dos participantes até ao momento 16 e também por serem importantes para a compreensão de alguns aspetos do jogo, nomeadamente a divisão e complexidade de uma tarefa e as suas diferentes componentes (front-end, integração e 18 back-end). 20 BG3 - Tenho conhecimentos moderados na área de Engenharia de Software. / 4 - Já desenvolvi projetos usando a metodologia Scrum. 22 Com estas questões pretende-se confirmar que os participantes não têm conhecimentos prévios significantes na área de Engenharia de Software e também da metodologia de desenvolvimento de 24 projetos de software Scrum. Apesar de esta última não ser especificamente referida no jogo, é um dos conceitos sobre o qual o jogo assenta. 26 BG5 - Sei o que é o Planning Poker e já joguei. 28 Esta pergunta tem objetivos semelhantes à anterior, falando agora de uma técnica de estimação em específico. É importante o participante não conhecer pois o Planning Poker é um dos principais 30 conceitos do jogo. 6.1.3 Questionário de avaliação de conhecimento e satisfação 32 Este questionário tem 2 versões: a primeira para o grupo de controlo, contendo apenas a secção de avaliação de conhecimento; a segunda versão, a ser respondida pelo grupo principal após 34 a sessão de jogo, contém ainda secções de satisfação geral do jogo e da experiência, de avaliação de fatores externos que a possam condicionar e uma secção livre de comentários ou sugestões. O 36 32 Validação grupo de controlo respondeu ao questionário imediatamente a seguir ao de background. Seguemse as questões existentes em cada secção e uma justificação para terem sido feitas.2 Avaliação de Conhecimento (KNW)4 Esta secção do questionário contém afirmações sobre vários conceitos da Engenharia e da Estimação de Software às quais os utilizadores respondem com uma escala de concordância de 1 a 5.6 O objetivo é o de averiguar o conhecimento obtido, através da comparação dos resultados obtidos entre os dois grupos. Seguem-se as suas questões divididas em grupos.8 Com a primeira pergunta pretende-se ter a sensação final de cada utilizador acerca do seu10 conhecimento sobre a matéria. KNW1 - Sinto-me familiar com a Estimação de Software e as suas aplicações.12 As seguintes questões são demonstradas indiretamente no jogo, sendo as duas primeiras pos-14 sível induzir pelo diálogo existente que o conhecimento dos programadores da equipa influencia a precisão e confiança de uma estimativa, e que é possível estimar usando USs prévias semelhantes16 como comparação. A última verifica-se pela existência de vários sprints com um Valor para o Cliente.18 KNW3 - Uma estimativa é mais precisa conforme o conhecimento que uma pessoa tem20 sobre a matéria. KNW4 - Uma estimativa pode ser absoluta ou relativa (comparando com USs prévias22 semelhantes). KNW18 - Na metodologia Scrum há entregas sucessivas de software desde o início do24 projeto. 26 O próximo conjunto de questões são afirmações verdadeiras, que servem para aferir a aquisição28 de conceitos que se vai dando ao longo do jogo, sendo que alguns destes se situavam apenas na base de conhecimento.30 KNW2 - A Estimação de Software permite controlar o desenvolvimento de um projeto de32 maneira a ir ao encontro das suas metas. KNW6 - Um Sprint é um intervalo de tempo pré-definido durante o qual existe trabalho34 específico para ser completado. KNW7 - No Planning Poker as estimativas são mostradas ao mesmo tempo para evitar36 ser influenciado pelas opiniões de outras pessoas. KNW8 - No Planning Poker a fase de discussão vem após dar uma estimativa.38 KNW9 - Uma User Story é uma frase na qual uma funcionalidade é descrita. 33 Validação KNW13 - Entregas tardias e atrasos de tempo imprevistos são uma consequência de subestimar. 2 KNW14 - Um uso de recursos ineficiente e uma equipa com baixa produtividade podem ser consequências de sobrestimar. 4 KNW15 - O objetivo principal do Product Owner é partilhar a sua visão com a equipa de desenvolvimento, participando também nas reuniões de sprint para esclarecer dúvidas. 6 8 Existe também um conjunto de afirmações falsas. Estas servem para despistar ou causar alguma dúvida. Alguns dos conceitos têm 2 afirmações: uma verdadeira e uma falsa. 10 KNW5 - Um Sprint é o curto espaço de tempo antes de uma entrega durante o qual uma 12 equipa trabalha muito mais. KNW10 - Uma User Story não segue um template.14 KNW11 - Sequências de números como Fibonacci(1,2,3,5,8) ou tamanhos de T-shirt(1,2,4,8) representam o número de horas necessárias para completar uma User Story.16 KNW12 - Uma Épica é uma User Story que é demasiado grande, sendo descartada. KNW16 - O Product Owner também dá estimativas. 18 KNW17 - O Scrum Master é o líder da equipa de desenvolvimento de software, e pode forçar uma estimativa. 20 22 Fatores Externos (EF) Esta secção do questionário tem como objetivo obter dados relativos ao ambiente da experiên24 cia, para garantir que não houveram influências externas que pudessem condicionar a experiência. As questões são sobre os seguintes fatores: 26 •Intimidação. Dada a formalidade e seriedade do teste realizado, estas podem ter um impacto negativo na experiência de algumas pessoas, fazendo-as sentir intimidadas. Pretende28 se observar se isso aconteceu. •Jogar em equipa. Com isto pretende-se obter a satisfação dos participantes em ter jogado 30 em conjunto com uma outra pessoa. •Ruído. Outro fator externo que pode ser condicionar a concentração dos participantes é o 32 ruído causado por outros colegas na sala. 34 Validação Satisfação (OVS) Esta secção teve como objetivo avaliar a satisfação da sessão de jogo. Nesta, as afirmações2 existentes pretendem obter o grau de satisfação em relação a várias partes do jogo: •Divertimento (OVS1, OVS5);4 •Quantidade de informação passada (OVS2, OVS3); •Habilidade de experienciar situações do mundo real (OVS4);6 •Sentimento de aprendizagem (OVS6); •Método de ensino (OVS7, OVS8);8 •Concentração (OVS9); •Duração da sessão (OVS15);10 •Elementos de jogo como: claridade de objetivos, feedback, predictibilidade, informação e ajuda existentes (OVS10-14).12 6.1.4 Sessão de Jogo Esta parte da experiência foi feita após o final da experiência para o grupo de controlo, que14 saiu da sala. Tendo respondido ao primeiro questionário, o grupo principal participou numa sessão de jogo. Esta sessão teve uma duração de 30 minutos, durante a qual os participantes puderam16 experimentar o jogo em grupos de 2 alunos. Esta escolha foi feita por já estarem habituados a trabalhar desta forma, e de maneira a suscitar alguma discussão e reflexão dos conceitos existentes18 no jogo. O projeto dentro do jogo tem 12 USs a ser estimadas, sendo suficiente para o utilizador desbloquear a Base de Conhecimento, que contém algumas definições para consolidar o que está20 a ser aprendido. 6.2 Resultados obtidos22 Nesta secção são mostrados os resultados dos testes de usabilidade, sendo feita uma análise e interpretação dos questionários. Os resultados podem ser consultados na íntegra em anexo.24 6.2.1 Questionário de background (BG) Como requisito para a efetividade da avaliação dos conhecimentos obtidos através do jogo, os26 participantes não devem ter experiência com o Planning Poker. Na questão 5, verificou-se que um dos participantes não cumpriu este requisito. Como tal, os seus resultados para o questionário de28 conhecimento e satisfação não foram considerados, ficando o grupo principal com uma amostra de 9 pessoas.30 35 Validação No figura C.6 podemos ver a média de respostas entre os dois grupos, sendo observável a proximidade entre eles. Destaca-se no entanto 1 diferença relevante: na pergunta 1 o grupo de 2 controlo considerou ter mais experiência de programação do que o grupo principal. Figura 6.2: Gráfico de média das respostas do questionário de background Análise dos Resultados 4 Para confirmar a semelhança estatística dos resultados deste questionário entre os dois grupos, foi feito um teste não paramétrico de Mann-Whitney[Nac08] para duas amostras independentes, 6 observável na tabela 6.1. O resultado foi de um U de Mann-whitney de 40 com uma significância média de 41%, sendo um valor bastante aceitável para concluir a similaridade estatística dos dois 8 grupos. Questão U de Mann-Whitney Significância (Bilateral) BG1 27,50 0,062 BG2.1 40,00 0,276 BG2.2 35,00 0,218 BG2.3 41,00 0,463 BG2.4 37,50 0,313 BG3 43,00 0,546 BG4 42,00 0,451 BG5 49,50 0,942 Média Total 40,50 0,409 Tabela 6.1: Teste de Mann-Whitney para similaridade estatística de grupos. 36 Validação 6.2.2 Questionário de avaliação de conhecimento e satisfação Nesta secção são mostrados e analisados os resultados do questionário de avaliação de conhe-2 cimento e satisfação, estando este capítulo dividido nas suas partes constituintes: fatores externos, avaliação de conhecimento e satisfação geral.4 Análise de fatores externos (EF)6 É possível observar na tabela 6.2 os resultados desta parte de fatores externos do questionário final. As questões eram as seguintes:8 EF1 - Achei intimidante o ambiente da experiência. EF2 - Jogava outra vez com o meu colega.10 EF3 - Fui várias vezes distraído por colegas fora do meu grupo. 12 Pergunta Média (1-5) Valor ideal Distância ao valor ideal Desvio Padr˘ ao EF1 2 1 1 0,94 EF2 4,1 5 0,9 0,57 EF3 1,7 1 0,7 0,82 Tabela 6.2: Tabeça de resultados de fatores externos da experiência. Observando os valores da tabela é possível ver que as médias das respostas estão próximas do valor suposto, podendo concluir que as condições da experiência foram próximas do ideal, não14 havendo um ambiente intimidante ou ruído de fundo que pudesse ter um impacto significante na experiência geral dos participantes. Jogar em grupo também foi bem aceite pelos participantes.16 Análise da avaliação do conhecimento (KNW)18 Antes de analisar as diferenças entre grupos para cada questão, foi realizado um teste de MannWhitney para verificar se os resultados entre grupos têm uma diferença estatística significante (ta-20 bela 6.3). Obteve-se um U de Mann-Whitney de 23,5 com uma significância média de 13,5%. Este valor de significância não é suficientemente baixo para se considerar uma heterogeneidade22 relevante entre os grupos. No entanto, analisando os valores da tabela individualmente é possível observar diferenças significantes nas seguintes perguntas: pergunta 1, obteve-se um grau de24 confiança ρ= 99%; nas perguntas 4, 5, 6, 7, 8, 9, 10, 14, 16, 17 e 18 houve uma diferença estatística com grau de confiança de ρ= 95%. Com isto é possível inferir que houve efetivamente26 uma diferença de conhecimento entre os participantes do grupo que não jogou e o dos que jogou. No entanto nem todas estas diferenças são positivas, o que é possível ver de seguida na análise28 individual dos resultados. 37 Validação Questão U de Mann-Whitney Significância KNW1 8,500 0,001 KNW2 34,000 0,289 KNW3 42,000 0,785 KNW4 15,500 0,008 KNW5 12,000 0,005 KNW6 21,000 0,036 KNW7 17,000 0,014 KNW8 18,500 0,016 KNW9 15,000 0,002 KNW10 25,000 0,022 KNW11 35,000 0,321 KNW12 35,000 0,252 KNW13 30,000 0,159 KNW14 21,000 0,017 KNW15 37,000 0,425 KNW16 12,500 0,006 KNW17 25,000 0,045 KNW18 20,000 0,025 Média Total 23,556 0,135 Tabela 6.3: Teste de Mann-Whitney Na seguinte análise das perguntas, são usados gráficos com a média da distância à resposta considerada correta ou ideal, sendo que um menor valor representa uma média de respostas mais 2 próxima do correto. Como a escala usada nos questionários foi com valores entre 1 e 5, a distância à resposta correta tem como extremos 0 (totalmente certa) e 4 (totalmente errada). 4 KNW1 - Sinto-me familiar com a Estimação de Software e as suas aplicações. 6 Figura 6.3: Gráfico de distâncias à resposta correta da pergunta 1. Com uma diferença de 1,09 entre os dois grupos para a pergunta 1, observa-se um grande aumento da sensação de familiaridade com a Estimação de Software e as suas aplicações para o 8 38 Validação grupo principal. 2 KNW2 - A Estimação de Software permite controlar o desenvolvimento de um projeto de maneira a ir ao encontro das suas metas.4 Figura 6.4: Gráfico de distâncias à resposta correta da pergunta 2. Nesta questão verificou-se uma diferença positiva, apesar de não ser muito significativa. Concluise que os participantes aprenderam moderadamente qual o objetivo da Estimação de Software.6 KNW3 - Uma estimativa é mais precisa conforme o conhecimento que uma pessoa tem8 sobre a matéria. Figura 6.5: Gráfico de distâncias à resposta correta da pergunta 3. Na pergunta 3, a diferença, apesar de negativa, foi quase insignificante. Os valores de distância10 à resposta correta foram extremamente baixos nos dois grupos (0,70 e 0,78), observando-se que esta questão era compreensível mesmo sem ter jogado, não tendo o jogo um impacto relevante12 sobre este conceito. 14 KNW4 - Uma estimativa pode ser absoluta ou relativa (comparando com User Stories prévias semelhantes).16 Figura 6.6: Gráfico de distâncias à resposta correta da pergunta 4. 39 Validação Pergunta Média(1-5) Valor ideal Distância ao valor ideal Desvio Padrão OVS1 3,89 5 1,11 0,60 OVS2 3,33 1 2,33 1,12 OVS3 2,56 1 1,56 1,33 OVS4 3,78 5 1,22 0,67 OVS5 3,89 5 1,11 0,60 OVS6 4,33 5 0,67 0,50 OVS7 4,11 5 0,89 0,60 OVS8 4,11 5 0,89 0,60 OVS9 3,67 5 1,33 0,50 OVS10 4,00 5 1,00 0,87 OVS11 3,56 5 1,44 1,01 OVS12 2,78 1 1,78 0,67 OVS13 3,67 5 1,33 0,87 OVS14 3,78 5 1,22 0,67 OVS15 2,67 1 1,67 0,87 Tabela 6.4: Tabela de resultados de satisfação geral da experiência OVS10 - O objetivo do jogo foi claro. Com uma média de 4, os participantes acharam claro qual o objetivo final do jogo. 2 OVS11 - O jogo tinha bom feedback sobre a minha performance. A maioria dos partici4 pantes achou que o jogo tinha informações suficientes sobre a performance do jogador. 6 OVS12 - Achei o jogo demasiado previsível. Com uma média de 2,78, observa-se que os participantes acharam que o jogo tinha alguma previsibilidade. 8 OVS13 - A informação mostrada no ecrã foi suficiente. Com uma média de 3,67, conclui-se 10 que a informação mostrada no ecrã foi maioritariamente suficiente. 12 OVS14 - O jogo ajudou-me a perceber o que tinha de fazer. Os participantes sentiram que a ajuda providenciada pelo jogo foi suficiente, com uma média relativamente alta de 3,78. 14 OVS15 - A sessão de jogo foi demasiado longa. Com uma média de 2,67, a duração da 16 sessão de jogo terá sido um pouco acima do ideal. Durante a experiência observou-se que os participantes demoraram algum tempo a discutir conceitos do jogo entre si. Enquanto que isto é um 18 bom resultado, a duração da sessão foi um pouco mais alta do previsto. Para resolver esta situação, bastaria diminuir o número de USs constituintes do projeto dentro do jogo. 20 46 Validação Elementos de jogo As questões 10 até à 14 eram relativas a alguns dos elementos de jogo implementados, já2 referidos no início deste capítulo e também no capítulo da implementação. Os resultados destas questões mostram que estes padrões de desenho foram implementados com sucesso, tendo como4 exceção fatores surpresa/previsibilidade do jogo (OVS12). A inclusão no jogo de alguns acontecimentos imprevistos poderia melhorar este caso. Um exemplo seria a possibilidade de surgirem6 acontecimentos fora do controlo do utilizador durante a semana de trabalho, como um colega de equipa não ter disponibilidade para trabalhar, ou surgir algum imprevisto que diminuísse/aumen-8 tasse a capacidade de trabalho da equipa. 10 Comentário e sugestões Na parte livre do questionário de comentários houveram 3 sugestões. A primeira foi em relação12 à repetibilidade do jogo, assunto esse já abordado na última secção. A segunda foi em relação aos resultados de cada sprint: acharam que por vezes era necessário mais feedback para cada US para14 o caso de ter sobrestimado ou subestimado. As métricas já existentes, o valor para o cliente e o tempo inativo, cobrem precisamente isso, sendo possivelmente necessário explicar um pouco16 melhor estas dentro do jogo. A última sugestão foi a possibilidade de voltar a ler a resposta da Product Owner à questão do utilizador.18 6.3 Conclusões Neste capítulo foi feita a validação do jogo desenvolvido. Na primeira secção descreveu-se20 a experiência conduzida, que consistiu na divisão de 20 alunos em 2 grupos. O primeiro grupo, grupo de controlo apenas responde aos questionários de background e de conhecimento. O outro,22 grupo principal, participa numa sessão de jogo antes de responder ao questionário de conhecimento. Para este grupo, o questionário de conhecimento contém ainda secções de satisfação geral24 e de fatores externos da experiência. O questionário de background tem como objetivo aferir os conhecimentos prévios dos par-26 ticipantes nos tópicos relativos a Engenharia de Software e de programação. O questionário de conhecimento serve para medir a aprendizagem obtida pelo jogo através da comparação dos resul-28 tados entre os dois grupos. Na análise de resultados do questionário de background verificou-se que os dois grupos tinham30 conhecimentos prévios semelhantes. No questionário de conhecimento e satisfação geral começou-se por verificar as respostas32 relativas a fatores externos, como a existência de um ambiente intimidante ou ruído de fundo. Verificou-se que estes não foram fatores que tivessem um impacto relevante na experiência. De34 seguida comparou-se a parte do conhecimento entre grupos, vendo as diferenças para os conceitos apreendidos pelos participantes. De modo geral, notaram-se diferenças relevantes entre o grupo36 principal e o grupo de controlo. Apesar de haver algumas questões em que o resultado não foi 47 Validação positivo, a maioria dos conceitos a passar foram bem sucedidos podendo concluir que o jogo permitiu ao grupo principal a aquisição de novos conhecimentos e de familiaridade com a Estimação 2 de Software. Por fim, foi analisada a parte de satisfação em relação ao jogo. Observou-se que os partici4 pantes gostaram de jogar o jogo e o acharam divertido. A quantidade de informação passada foi um pouco acima do ideal, assim como a duração da sessão de jogo que foi um pouco longa. Os 6 participantes sentiram que aprenderam novos conceitos, gostaram desta forma de aprendizagem e mostraram interesse em aprender outros tópicos desta maneira. Em relação aos padrões de dese8 nho, estes foram implementados com sucesso com exceção da previsibilidade e fatores surpresa. Estes elementos contribuíram para uma transmissão de conhecimento bem sucedida. 10 48 Capítulo 7 Conclusões e Trabalho Futuro2 A aprendizagem de áreas da Engenharia de Software tem algumas particularidades: é neces-4 sário experimentar e aplicar os conceitos aprendidos para efetivamente aprender. Num âmbito académico isto é precisamente o que acontece, mas dada a extensividade deste campo de estudo,6 muitas vezes apenas é possível abordar de uma maneira prática alguns dos conceitos relevantes. Uma solução é o uso de jogos sérios para o treino e transmissão de conhecimentos, assunto este8 que tem vindo a ser cada vez mais usado tanto na área de Engenharia Informática como noutras. Enquanto que o objetivo principal de um jogo sério é o de ensinar algo, isto não impede que a10 aprendizagem seja feita de maneira divertida: a jogar um jogo! No entanto, o desenvolvimento deste tipo de jogos apresenta algumas dificuldades: é preciso conseguir balancear a componente12 de ensino com a componente divertida, não querendo um jogo que seja demasiado maçudo nem um jogo que transmita muito pouco conhecimento.14 Neste sentido, pretendeu-se contribuir para o ensino de um tópico de Engenharia de Software: a Estimação. Isto foi feito através do desenvolvimento de um jogo sério, pretendendo demons-16 trar a eficácia deste método de aprendizagem. Começou-se por fazer uma revisão bibliográfica para a área em questão, tendo-se falado do campo da Engenharia de Software em geral e da sua18 aprendizagem, da Estimação de Software, e de jogos sérios e o seu desenvolvimento. De seguida foi apresentado o conceito e implementação do jogo, explicando a ideia por detrás deste, os seus20 objetivos de aprendizagem e detalhando aspetos relativos ao seu design: história, cenas de jogo, personagens, métricas e outros. Foram ainda explicados alguns detalhes do motor de jogo de mais22 baixo nível. Para fazer a validação do jogo implementado, foi conduzida uma experiência a um grupo de 2024 alunos do curso MIEIC da FEUP. Nesta experiência os participantes foram divididos em 2 grupos, havendo um grupo principal que responde aos questionários participando numa sessão de jogo, e26 um grupo de controlo que apenas responde aos questionários. 49 Conclusões e Trabalho Futuro 7.1 Satisfação dos Objetivos Após uma análise dos resultados da experiência, foi possível verificar uma diferença de conhe2 cimento entre os dois grupos de participantes. Apesar de haver alguns conceitos que não chegaram inteiramente aos participantes, a transmissão de conhecimento foi bem sucedida para a maioria dos 4 conceitos. Na parte de satisfação em relação ao jogo verificou-se que a sessão foi um pouco longa e a quantidade de informação passada pelo jogo foi um pouco acima do ideal. No entanto, os par6 ticipantes gostaram do jogo, sentiram que adquiriram novo conhecimento, gostaram deste método de aprendizagem e teriam interesse em aprender outras matérias desta forma. 8 O jogo teve um bom resultado, sendo relativamente eficaz na passagem de conhecimento e moderadamente divertido na sua jogabilidade. Sendo assim, é possível concluir que os objeti10 vos desta dissertação foram alcançados, tendo-se contribuído com um método complementar de aprendizagem para os alunos interessados na Estimação de Software.12 7.2 Trabalho Futuro Para continuação como trabalho futuro há algumas funcionalidades que seriam interessantes 14 adicionar. O próximo passo seria um novo cargo para o utilizador que iria introduzir traços de personalidade nos programadores da equipa. Eles poderiam ser otimista/pessimista, individualis16 ta/team player ou calmo/impaciente. Isto teria impacto tanto nas estimativas que eles dão como no decorrer do trabalho. Uma possibilidade seria o utilizador ter de fazer a alocação das tarefas 18 tendo em conta estes traços. Uma outra funcionalidade seria incluir outras técnicas de estimação como a estimação por afinidade [Aff]. 20 Por fim, também seria interessante a possibilidade do utilizador, neste caso o professor, poder configurar aspetos do jogo como as User Stories, tamanho do sprint, os papéis existentes, os níveis 22 de conhecimento dos programadores da equipa e o número destes. 50 Referências [Aff] Affinity Estimating: A How-To. http://www.gettingagile.com/2008/07/2 04/affinity-estimating-a-how-to/. Accessed: 2016-02-12. [AI13] Ashley Aitken e Vishnu Ilango. A Comparative Analysis of Traditional Software En-4 gineering and Agile Software Development. 2013 46th Hawaii International Conference on System Sciences, pages 4751–4760, 2013. doi:10.1109/HICSS.2013.31.6 [BF14] Pierre Bourque e Richard E. Fairley. Guide to the Software Engineering - Body of Knowledge. 2014. URL: www.swebok.org.8 [BH04] Staffan Bjork e Jussi Holopainen. Patterns in game design (game development series). 2004.10 [BKL+13] Francesco Bellotti, Bill Kapralos, Kiju Lee, Pablo Moreno-Ger e Riccardo Berta. Assessment in and of serious games: An overview. Adv. in Hum.-Comp. Int.,12 2013:1:1–1:1, January 2013. doi:10.1155/2013/136864. [Boe02] Barry Boehm. Get ready for agile methods, with care. Computer, 35(1):64–69,14 2002. [CK14] Brent Cowan e Bill Kapralos. A Survey of Frameworks and Game Engines for Seri-16 ous Game Development. In 2014 IEEE 14th International Conference on Advanced Learning Technologies, pages 662–664. IEEE Computer Society, Los Alamitos, CA,18 USA, jul 2014. doi:10.1109/ICALT.2014.194. [CP14] Ricardo Colomo-Palacios. Agile Estimation Techniques and Innovative Approaches20 to Software Process Improvement. IGI Global, 2014. [CvWF+15] Rafael Oliveira Chaves, Christiane Gresse von Wangenheim, Julio Cezar Costa22 Furtado, Sandro Ronaldo Bezerra Oliveira, Alex Santos e Eloi Luiz Favero. Experimental Evaluation of a Serious Game for Teaching Software Pro-24 cess Modeling. IEEE Transactions on Education, 58(4):289–296, nov 2015. doi:10.1109/TE.2015.2411573.26 [DBW04] Alexandre Dantas, Márcio Barros e Cláudia Werner. A Simulation-Based Game for Project Management Experiential Learning. Proceedings of the Sixteenth Interna-28 tional Conference on Software Engineering & Knowledge Engineering, (February 2016):19–24, 2004. doi:10.1109/ICEIT.2010.5607538.30 [DD08] Tore Dybå e Torgeir Dingsøyr. Empirical studies of agile software development: A systematic review. Information and Software Technology, 50(9-10):833–859, 2008.32 51 REFERÊNCIAS [DL00] A. Drappa e J. Ludewig. Simulation in software engineering training. Proceedings of the 2000 International Conference on Software Engineering. ICSE 2000 the New 2 Millennium, pages 199–208, 2000. doi:10.1109/ICSE.2000.870411. [Fai92] R.E. Fairley. Recent Advances In Software Estimation Techniques. International 4 Conference on Software Engineering, (14):382–391, 1992. [FM12] Pedro Faria e Eduardo Miranda. Expert judgment in software estimation during the 6 bid phase of a project - An exploratory survey. Proceedings of the 2012 Joint Conf. of the 22nd Int. Workshop on Software Measurement and the 2012 7th Int. Conf. on 8 Software Process and Product Measurement, IWSM-MENSURA 2012, pages 126– 131, 2012. 10 [FS10] J. M. Fernandes e S. M. Sousa. Playscrum - a card game to learn the scrum agile method. In Games and Virtual Worlds for Serious Applications (VS-GAMES), 2010 12 Second International Conference on, pages 52–59, March 2010. doi:10.1109/VSGAMES.2010.24. 14 [Gha16] Imran Ghani. Emerging Innovations in Agile Software Development. IGI Global, 2016. 16 [GMGP15] L. García-Mundo, M. Genero e M. Piattini. Towards a Construction and Validation of a Serious Game Product Quality Model. 2015 7th International Conference on 18 Games and Virtual Worlds for Serious Applications (VS-Games), page 8 pp., 2015. doi:10.1109/VS-GAMES.2015.7295790. 20 [HIW+04] Bob Hughes, Roger Ireland, Brian West, Norman Smith e David I Shepherd. Project Management for IT-related Projects: Textbook for the ISEB Foundation Certificate 22 in IS Project Management. BCS, The Chartered Institute, 2004. [Jor04] M. Jorgensen. A review of studies on expert estimation of software development 24 effort. Journal of Systems and Software, 70(1-2):37–60, 2004. [JS07] Magne Jorgensen e Martin Shepperd. A Systematic Review of Software Deve26 lopment Cost Estimation Studies. IEEE Transactions on Software Engineering, 33(1):33–53, 2007. 28 [LES14] Fedwa Laamarti, Mohamad Eid e Abdulmotaleb El Saddik. An Overview of Serious Games. International Journal of Computer Games Technology, 2014:1–15, 2014. 30 [LPF15] Pedro Letra, Ana C. R. Paiva e Nuno Flores. Game Design Techniques for Software Engineering Management Education. 2015 IEEE 18th International Conference on 32 Computational Science and Engineering, pages 192–199, 2015. [McC06] Steve McConnell. Software Estimation: Demystifying the Black Art. 2006. 34 [Nac08] Nadim Nachar. The mann-whitney u: A test for assessing whether two independent samples come from the same distribution. Tutorials in Quantitative Methods for 36 Psychology, 4(1):13–20, 2008. [PPRP12] Daniela C. C. Peixoto, Rodrigo M. Possa, Rodolfo F. Resende e Clarindo Isaias 38 P. S. Padua. Challenges and issues in the development of a Software Engineering simulation game. 2012 Frontiers in Education Conference Proceedings, pages 1–6, 40 2012. doi:10.1109/FIE.2012.6462318. 52 REFERÊNCIAS [SA08] O. Salo e Pekka Abrahamsson. Agile methods in European embedded software development organisations: a survey on the actual use and usefulness of Extreme2 Programming and Scrum. Software, IET, 2(1):58–64, 2008. arXiv:1307.3356, doi:10.1049/iet-sen.4 [SD05] Katherine Shaw e Julian Dermoudy. Engendering an Empathy for Software Engineering BT - Seventh Australasian Computing Education Conference (ACE2005).6 42(c):135–144, 2005. [Sha00] Mary Shaw. Software Engineering Education: A Roadmap. Proceedings of the8 conference on The future of Software engineering - ICSE ’00, pages 371–380, 2000. [Sim] SimSE Online. www.ics.uci.edu/~emilyo/SimSE/. Accessed: 2016-02-12.10 [Uni] Unity - Game Engine. https://unity3d.com/pt. Accessed: 2016-02-12. [Unr] Unreal Engine. www.unrealengine.com/what-is-unreal-engine-4. Ac-12 cessed: 2016-02-12. [VPC+09] K. Vega, A. Pereira, G. Carvalho, A. Raposo e H. Fuks. Prototyping games for14 training and education in Second Life: Time2Play and TREG. SBGAMES2009 - 8th Brazilian Symposium on Games and Digital Entertainment, pages 1–8, 2009.16 doi:10.1109/SBGAMES.2009.9. [VU15] V.B. Vasudevamurt e A. Uskov. Serious game engines: analysis and applications.18 2015 IEEE International Conference on Electro/Information Technology (EIT). Proceedings, 2015. doi:10.1109/EIT.2015.7293381.20 53 REFERÊNCIAS 54 Anexo A Questionários2 55 1 Empirical Studies in Software Engineering TENFOGS05 May 2016 Post-Questionnaire We now ask you to answer this brief questionnaire that won’t take you more than 5 minutes. Each question relates to issues regarding your knowledge about Software Estimation. Each question has an identifier (for easy processing later on) and may have either a single answer, or a list of possible answers. Each answer should be rated as follows: 1 (Strongly Disagree), 2 (Somewhat Disagree), 3 (Neither Agree nor Disagree), 4 (Somewhat Agree), 5 (Strongly Agree). You should rate with an ‘X’ every answer as best it resembles your opinion as possible. ID: ______________ Questionnaire Knowledge 1 2 3 4 5 KNW1. I feel I am acquainted with Software Estimation and its applications. KNW2. Software Estimation allows to control a project development in order to meet its goals. KNW3. An estimation is as accurate as the person’s knowledge on the matter. KNW4. An estimation can be absolute or relative (comparing it with previous similar User Stories). KNW5. A Sprint is the short time before a deadline where a developer team works extra hard. KNW6. A Sprint is a pre-defined time interval during which there is specific work to be completed. KNW7. In Planning Poker the estimates are shown at the same time to avoid being influenced by others’ opinions. KNW8. In Planning Poker the discussion phase comes after giving an estimate. KNW9. A User Story is a sentence where a functionality is described. KNW10. A User Story does not follow a template. 2 1 2 3 4 5 KNW11. Number sequences like Fibonacci (1,2,3,5,8) or T-Shirt sizes (1,2,4,8) represent the number of hours needed to complete a User Story. KNW12. An Epic is a User Story that is too big, being discarded. KNW13. Late deliveries and unexpected time delays are a consequence of underestimating. KNW14. An inefficient resource usage and a low productivity team may be consequences of overestimating. KNW15. The Product Owner main goal is to share his vision with the development team, while also participating in Sprint Meetings to clarify any doubts. KNW16. The Product Owner also gives estimates. KNW17. The Scrum Master is the leader of the software development team, and can override an estimate. KNW18. In Scrum methodology there are successive software deliveries since the start of the project. Questionários 64 Anexo B Tabelas de resultados dos questionários2 B.1 Questionário de background Participante no12345678910 BG1 534444354 5 BG2.1 434434434 4 BG2.2 332423233 3 BG2.3 431114320 1 BG2.4 112211310 2 BG3 432234333 3 BG4 121111311 1 BG5 111211111 1 Tabela B.1: Resultados do Grupo de Controlo Participante no12345678910 BG1 334444343 3 BG2.1 444444344 4 BG2.2 344343243 2 BG2.3 322332330 3 BG2.4 142113330 1 BG3 334334143 3 BG4 122111121 2 BG5 114111111 1 Tabela B.2: Resultados do Grupo Principal 65 Tabelas de resultados dos questionários Participante no12345678910 KNW1 233334313 3 KNW2 444434334 3 KNW3 455455434 4 KNW4 324424233 3 KNW5 445434433 4 KNW6 231432333 4 KNW7 333533333 3 KNW8 333433333 3 KNW9 333333333 3 KNW10 333333333 3 KNW11 333333333 3 KNW12 333333333 3 KNW13 545544445 5 KNW14 424423434 4 KNW15 445444534 3 KNW16 134332334 4 KNW17 333333333 3 KNW18 333333333 3 Tabela B.3: Resultados do Grupo de Controlo - avaliação de conhecimento Participante no123456789 KNW1 434444444 KNW2 434434454 KNW3 444545354 KNW4 443444544 KNW5 432233131 KNW6 344433535 KNW7 444444552 KNW8 434444452 KNW9 434444334 KNW10 333112331 KNW11 244233543 KNW12 341133233 KNW13 444444355 KNW14 444444455 KNW15 444444545 KNW16 132222111 KNW17 344343244 KNW18 444244245 Tabela B.4: Resultados do Grupo Principal - avaliação de conhecimento 66 Tabelas de resultados dos questionários Participante no12345678910 EF1 222213121 4 EF2 444443455 4 EF3 322123111 1 Tabela B.5: Resultados do Grupo Principal - fatores externos B.2 Questionário de avaliação de conhecimento Participante no123456789 OVS1 434443454 OVS2 442522344 OVS3 442314311 OVS4 444442444 OVS5 434443454 OVS6 444544554 OVS7 434444554 OVS8 434444554 OVS9 334443444 OVS10 445445442 OVS11 534442244 OVS12 333234232 OVS13 444443253 OVS14 334443454 OVS15 242232342 Tabela B.6: Resultados do Grupo Principal - satisfação geral 67 Tabelas de resultados dos questionários 68 Anexo C Capturas de ecrã do jogo2 Figura C.1: Planning Poker - escolher carta 69 Capturas de ecrã do jogo Figura C.2: Resposta da Product Owner e balão de experiência Figura C.3: Menus - Perfil de Jogador 70 Capturas de ecrã do jogo Figura C.4: Menus - Vista do projeto Figura C.5: Menus - Descrição da equipa 71