O uso de método Scrum em empresas de
Transcrição
O uso de método Scrum em empresas de
O uso de método Scrum em empresas de desenvolvimento de software de jogos Martin Fabichak o N USP: 5726857 Instituto de Matemática e Estatística - USP Orientador: Alfredo Goldman 29 de novembro de 2009 Resumo A indústria de jogos tem se tornado cada vez mais importante, inclusive economicamente. Em 2007, este ramo arrecadou mais do que a indústria de lmes e música, faturando cerca de US$18 bilhões de dólares apenas nos Estados Unidos. Com a tendência de crescer, as empresas deste ramo estão enfrentando diculdades em criar jogos com a mais alta tecnologia de uma forma ordenada. Assim, como a indústria de software vivencia este problema, analisar-se-á como uma metodologia comumente utilizada nesta área pode ser utilizada em jogos. Neste trabalho, será discutida uma abordagem de gerenciar os projetos de jogos digitais utilizando Scrum, demonstrando como foi a experiência em um projeto brasileiro: Ludo Park. Sumário 1 Introdução 4 2 Trabalhos Relacionados 5 3 Como funciona uma empresa de jogos digitais 6 3.1 3.2 3.3 3.4 Equipe . . . . . . . . . . . . . . . . 3.1.1 Game Designers . . . . . . 3.1.2 Programadores . . . . . . . 3.1.3 Artistas . . . . . . . . . . . 3.1.4 Testadores . . . . . . . . . . 3.1.5 Sound Designers . . . . . . 3.1.6 Produtores . . . . . . . . . 3.1.7 Líderes . . . . . . . . . . . . Mercado . . . . . . . . . . . . . . . 3.2.1 Publicadores de jogos . . . 3.2.2 Outros exemplos . . . . . . Game Design Document . . . . . . Processos clássicos de produção em . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . jogos 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . digitais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6 6 7 7 8 8 8 8 8 9 9 9 4 Breve descrição do Scrum 4.1 4.2 4.3 Papéis . . . . . . . . . . . . 4.1.1 Product Owner . . . 4.1.2 Scrum Master . . . 4.1.3 Equipe . . . . . . . . 4.1.4 Acionistas . . . . . . Artefatos . . . . . . . . . . 4.2.1 Backlog do produto . 4.2.2 Backlog do sprint . . 4.2.3 Grácos . . . . . . . Processo . . . . . . . . . . . 4.3.1 Sprint . . . . . . . . 4.3.2 Sprint Planning . . . 4.3.3 Daily Scrum . . . . 4.3.4 Sprint Review . . . . 4.3.5 Sprint Retrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Impressões iniciais da aplicação do Scrum para empresas de jogos digitais 5.1 5.2 5.3 5.4 5.5 5.6 5.7 Jogo digital é software? . . . . . . . . . Relação entre GDD e backlog do produto Como estimar . . . . . . . . . . . . . . . Comunicação entre as áreas . . . . . . . Prototipação . . . . . . . . . . . . . . . Escrita das histórias . . . . . . . . . . . Relacionamento com o publicador . . . . 6 Ludo Park 6.1 6.2 6.3 6.4 6.5 6.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Projetos anteriores . . . . . . . . . . . . . . . . . . . . . . . . . . . Conceito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Problemas iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . Por que o Scrum foi escolhido e como foi implementado? . . . . . . Erros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5.1 O método de implementação . . . . . . . . . . . . . . . . . 6.5.2 Scrum Master inexperiente em jogos . . . . . . . . . . . . . 6.5.3 Scrum Master designado como chefe . . . . . . . . . . . . . 6.5.4 Grande tempo de planejamento . . . . . . . . . . . . . . . . 6.5.5 Grande tempo de sprint review . . . . . . . . . . . . . . . . 6.5.6 Product Owner ausente . . . . . . . . . . . . . . . . . . . . 6.5.7 Mudança nas atividades mas não no pensamento . . . . . . 6.5.8 Arquitetura de software não respondia a mudanças . . . . . 6.5.9 Diculdade de testes . . . . . . . . . . . . . . . . . . . . . . 6.5.10 Relacionamento entre o Scrum Master e a equipe . . . . . . 6.5.11 Diversas ferramentas para a manutenção do product backlog 6.5.12 Fase de testes tardia no ciclo de desenvolvimento . . . . . . 6.5.13 Fases nais do projeto sem planejamento . . . . . . . . . . . 6.5.14 Retrospectivas . . . . . . . . . . . . . . . . . . . . . . . . . 6.5.15 Escolha da tecnologia . . . . . . . . . . . . . . . . . . . . . Aprendizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10 10 10 11 11 11 11 11 12 12 12 13 13 13 13 14 14 14 14 15 15 15 16 17 17 17 18 18 19 19 19 19 20 20 20 21 21 21 21 22 22 22 22 23 23 6.7 6.6.1 Planejamentos caram melhores e mais rápidos 6.6.2 Melhora contínua no Daily Scrum . . . . . . . 6.6.3 Scrum e o comprometimento da equipe . . . . . 6.6.4 Estudo contínuo . . . . . . . . . . . . . . . . . 6.6.5 Atraso do projeto . . . . . . . . . . . . . . . . . 6.6.6 Coordenação com pessoas externas . . . . . . . 6.6.7 Visibilidade . . . . . . . . . . . . . . . . . . . . 6.6.8 Metodologia da empresa . . . . . . . . . . . . . Conclusão do uso do Scrum neste projeto . . . . . . . 7 O uso de Scrum em grandes projetos 7.1 7.2 7.3 7.4 Comunicação . . . . . . . . . Impedimentos . . . . . . . . . Desenvolvimento Incremental GDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Conclusão 9 Apêndice A - Game 9.1 9.2 9.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 23 23 24 24 24 24 24 25 25 25 25 26 26 26 Engine 27 PopCap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Unity 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Unreal engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 10 Apêndice B - Design de projeto 28 11 Glossário 28 12 Referências Bibliográcas 29 3 1 Introdução Jassie Scanlon cita que, com base na pesquisa de mercado da empresa PricewaterhouseCoopers : ... video games [is] the third fastest growing segment of the entertainment and media market...[30], ultrapassando até a indústria do cinema e da música. Apenas nos Estados Unidos, um dos maiores mercados de entretenimento, em 2007 esta indústria arrecadou mais de US$18 bilhões de dólares, contra US$10 bilhões do nicho de música e US$9 bilhões do de lmes [6]. Com a tendência de crescer, as empresas deste ramo estão enfrentando diculdades em criar jogos com a mais alta tecnologia de uma forma ordenada. Todos os grandes projetos, e até mesmo os pequenos, já não conseguem ser feitos com poucos prossionais, como no começo dos anos 90. Um retrato disso é o gráco abaixo, um panorama entre tamanho de equipe e gastos de um projeto ao longo do tempo, que foi apresentado na Game Developer Conference de 2006, pela empresa Factor 5 em uma palestra, uma das primeiras empresas a produzir um jogo multi-milionário para um console de próxima geração: Figura 1: Tamanho da equipe pelo gasto de um projeto Pode-se observar que em menos de duas décadas, desde a criação dos jogos 16-bit até agora, o custo dos projetos aumentou em quase 40 vezes, sendo que o tamanho da equipe aumentou mais de 20 vezes. Isso deve-se basicamente ao fato da tecnologia empregada em jogos ter evoluído muito e também ao aumento da importância econômica deste ramo. Clinton Keith arma que a indústria de jogos não foi a primeira a ter problemas deste tipo [22]. Grandes projetos de software que necessitam de centenas de pessoas existem a décadas. Esta indústria pode usar ideias das empresas de software para lidar com grandes equipes e incerteza. Estas, já com diversos problemas. Segundo o Chaos Report de 2009, apenas 32% dos projetos são um sucesso, enquanto 44% têm problemas e 24% são cancelados. Em 1994, apenas 16% tiveram sucesso, enquanto 53% tiveram problemas e 31% foram cancelados [16]. Isso demonstra que houve uma evolução nos 4 últimos 15 anos. As empresas de jogos podem utilizar algumas das mudanças destes anos para também aumentar sua taxa de sucesso. O uso de metodologias ágeis foi uma dessas. Neste trabalho, discutiremos as diferenças principais entre estes dois ramos e exemplicaremos a aplicação de Scrum em um projeto brasileiro de jogo digital. Na primeira seção, Como funciona uma empresa de jogos digitais, analisaremos a estrutura de uma empresa de jogos, do ponto de vista de produção e de mercado, e iremos correlacionar esta análise com uma empresa de software. Posteriormente, conheceremos melhor a metodologia Scrum, vendo, logo após isso, a sua aplicação no projeto Ludo Park. 2 Trabalhos Relacionados A bibliograa de metodologias ágeis para indústria de jogos é praticamente inexistente. De fato, poucos autores dedicam-se apenas a este tema, enquanto que, para software, diversas empresas e autores consagrados existem. A High Moon Studios [1], situada nos Estados Unidos, é famosa pela utilização do Scrum em seus projetos, e posteriormente, por apresentar os resultados na Game Developer Conference de 2006 e 2007. Em 2006 [19], o apresentador da palestra, então CTO da empresa, Clinton Keith, apresentou a base de como Scrum funciona, desde seus princípios até o uso na empresa. Ele também aponta a utilização de Extreme Programming, outra metodologia ágil, dizendo que esta é mais fácil de começar a ser utilizada. Um dos pontos fortes desta apresentação é o fato dele indicar bons caminhos de como começar uma implementação, e também quais problemas sua equipe enfrentou ao usar a metodologia [23]. Em 2007 [21], Keith apresentou um tutorial de metodologias ágeis; ele explicou toda a base do Scrum, e inclusive convidou membros de sua equipe para explicar alguns tópicos, por exemplo, como construir um game design ágil. Tendo ganhado bastante notoriedade, em 2008, ele abandonou a indústria para se tornar consultor de metodologias ágeis para estúdios de jogos. Atualmente, escreve um livro intitulado Agile Game Development with Scrum, que será o primeiro livro inteiramente dedicado à área de jogos. Já Mike Cohn, um grande nome da indústria de software, fez uma apresentação em que demonstrou conceitos do Scrum pensados para grandes empresas [10]. Porém, nenhuma técnica especíca foi apresentada ou melhorada. O livro de Clinton Keith sairá em sua coleção de livros assinados. Um dos sites mais famosos sobre o desenvolvimento de jogos, o Gamasutra, tem diversos artigos escritos por prossionais da indústrial. Dois, sobre Scrum, apareceram no site e ganharam notoriedade. Um deles, escrito por Paul Miller miller, discute-se dez pontos do uso desta metodologia para empresas de jogos. Em outro artigo, o autor explica como é criar um design de jogo utilizando metodologias ágeis [24]. No que diz respeito à área acadêmica, existem alguns artigos e trabalhos relacionados a alguns pontos de metodologias ágeis. Mateos-Garcia e Sapsed elaboraram um interessante trabalho sobre a implementação de Scrum em três empresas de jogos com pers diferentes [14]. Neste estudo, eles apontam quais seriam os casos em que o Scrum funcionaria melhor, dado algumas variáveis como complexidade do projeto, tamanho da equipe e relacionamento com o publicador. Analisaremos melhor este estudo na seção 5.7. No Brasil, estudantes da UFPE (Universidade Federal de Pernambuco) e da Jynx Playware, empresa desenvolvedora de jogos, escreveram um short paper para a SBGAMES (Simpósio Brasileiro de Jogos Eletrônicos) de 2006 [4]; com este trabalho, empresas brasileiras adquiriram conhecimento sobre as metodologias ágeis, em especial o Scrum. 5 Este trabalho analisará empiricamente o uso do Scrum em um projeto de pequeno porte; dado o que foi apresentado tentaremos pontuar quais seriam as diferenças práticas da utilização desta metodologia em empresas dessa área, posto que um jogo é diferente de um software. 3 Como funciona uma empresa de jogos digitais Antes de explorar a diferença entre empresas de software e de jogos, é necessário entender melhor o seu funcionamento interno. 3.1 Do ponto de vista interno: a equipe Uma equipe é composta por diversos tipos de prossionais. A especidade de cada um depende do tamanho da empresa, e neste trabalho, será tomado como base desde o pequeno até o grande porte. Estudaremos, portanto, os membros mais presentes na produção: game designers, programadores, artistas, testadores, sound designers e produtores. 3.1.1 Game Designers A game designer is a person who designs gameplay, conceiving and designing the rules and structures of a game. [13]. Podemos armar que o game designer, pela denição acima, tem basicamente duas responsabilidades: denir o gameplay e as regras e a estrutura de um jogo. Gameplay, conhecido também como jogabilidade, de acordo com Ernest Adams e Andrew Rollings consiste em desaos e ações que um jogo oferece: desaos para o jogador vencer e ações para vencê-lo [12]. Os jogos também incluem ações não relacionadas ao gameplay, mas sua essência permanece na relação entre os desaos e as ações disponíveis para sobrepujálos. Também primordial neste conceito é o fator diversão, pois sua hierarquia e suas regras inuenciam nos conceitos de habilidade, estresse, diculdade e recompensa, fazendo o jogador se esforçar mais para se divertir ou se frustrar. Todo jogo provém de uma ideia ou conceito antes de se concretizar. Logo, para que sejam criadas as regras e a estrutura, o game designer estabelece suas bases em pesquisas realizadas acerca do tema do jogo e levanta dados, caso sejam necessários, ao decorrer da produção; ou seja, ao longo do projeto, ao surgirem problemas, o game designer tenta solucioná-los, procurando manter a coerência com o conceito do projeto e ao mesmo tempo respeitando as limitações orçamentárias ou tecnológicas. Há também o level designer, que se encarrega de tornar todos os recursos levantados para o jogo como interface de interação, gameplay e mecânica, em seqüências de fases ou etapas diferenciadas em que o jogador deve ultrapassar, cuidando da curva de diculdade ao decorrer delas. Não são todos os projetos que precisam de um level designer, pois nem todos os jogos têm uma estruturação denida como o conceito de fases; por exemplo, os jogos simuladores de esporte. 3.1.2 Programadores Em grandes empresas, programadores podem ser classicados em diversos tipos. Temos, basicamente, três principais: programadores de gameplay, que são responsáveis por moldar a lógica de jogabilidade; programadores de engine, que têm como objetivo fazer a estrutura básica do sistema em que o jogo funciona e programadores de ferramentas, que são responsáveis por fazer programas especícos para atender às necessidades de produção de um determinado título. 6 Segundo Je Ward, ... the concept of a game engine is fairly simple: it exists to abstract the (sometime platform-dependent) details of doing common game-related tasks, like rendering, physics, and input, so that developers (artists, designers, scripters and, yes, even other programmers) can focus on the details that make their games unique. [34]. Ou seja, o papel essencial de uma engine de jogo é simplicar a produção abstraindo tarefas fundamentais, porém complicadas. Tal conceito, no passado, era pouco utilizado pois as empresas faziam estas tarefas comuns para cada projeto, ou pelo menos para cada hardware. Hoje em dia, com o aumento da complexidade de programar para tais hardwares, sua utilização é mais comum, como arma Mark DeLoura: ... using a licensed game engine has gone from being a rarity to something common and acceptable. [11]. Projetos com custos reduzidos precisam concentrar o orçamento no propósito de tornar o jogo único. Por isso, a utilização destas engines é, por vezes, fundamental, o que torna necessário a equipe ter conhecimento sobre este recurso. Logo, tais projetos utilizam mais programadores de gameplay do que propriamente de engine. 3.1.3 Artistas Em jogos, a produção de material visual é extremamente importante e custosa. Portanto, cada artista tem uma função bem especíca dentro da equipe. Primeiramente existem artistas que conceituam visualmente o jogo, são eles que concretizam as ideias que antes só existiam no papel. Geralmente esses artistas também desempenham a função de diretor de arte. Conjuntamente existem os artistas mais ligados à produção, que dependendo da linguagem artística escolhida, dividem-se em especializações, por exemplo, caso o jogo seja em 3D, teremos modeladores, texturizadores e animadores na produção. Por m, existem artistas mais ligados à pós-produção ou nalização. Estes atuam quando a direção e a linguagem já estão estabelecidas, produzindo material de acabamento, como cinemáticas ou identidade visual. Segundo o relatório anual da ABRAGAMES, Associação Brasileira das Desenvolvedoras de Jogos Eletrônicos, o número de artistas que trabalham em empresas de jogos no Brasil corresponde ao mesmo número de programadores [2]. Isso demonstra uma enorme demanda deste tipo de prossionais, pois no começo dos anos 80, a arte era inclusive criada por programadores [20]. Artistas começaram a ser contratados em meados dos anos 90 [20], e, dez anos depois, já se equivalem ao número de programadores no Brasil. 3.1.4 Testadores Software testing is an integrated part in software development. It is directly related to software quality. [26]. A partir desta citação, concluímos que praticamente todos os softwares comerciais necessitam de testadores. Em jogos, há especialistas apenas para realizar testes, utilizando diversas técnicas para encontrar erros. Porém, em jogos são feitos dois tipos de testes: o habitual, chamado teste de estabilidade, para detectar erros de lógica e bugs do sistema, e o teste de gameplay, para vericar se o jogo tem as qualidades necessárias para ser vendido. Neste, parte dos critérios empregados no processo de averiguação são: facilidade de aprendizado e de interação com o usuário, diversão, inovabilidade, entre outros fatores. Em um programa comercial, se todas as funcionalidades são executadas com êxito e aprovadas pelo cliente, conclui-se que o software tem qualidade. Todavia, não se pode assegurar que um jogo que funciona com perfeita exatidão é efetivamente recreativo. Igualmente, não é possível consentir que este, caso apresente erros em seu funcionamento, não o é. Mas esse tema será 7 tratado com mais detalhes na seção 5.1. 3.1.5 Sound Designers A evolução crescente da indústria fonográca nas últimas décadas permitiu que os atuais computadores e consoles encerrem uma intensa capacidade de reproduzir sons em alta qualidade. Devido à importância de ambientar o jogador e contribuir para a imersão no jogo, os prossionais desta área atuam de diversas maneiras. Há músicos que colaboram com diversas composições, muitas vezes feitas especialmente para um projeto; há outros músicos e especialistas que fazem os chamados efeitos especiais, áudios que simbolizam pequenas ações dentro de um jogo. Tais prossionais, em empresas menores, têm pouco ou sequer nenhum espaço. Por exemplo, no Brasil, esta prossão nem mesmo é categorizada no relatório anual da ABRAGAMES. Já em empresas grandes, embora estes não sejam tão numerosos quanto programadores ou artistas, os sound designers representam uma parte importante para a qualidade nal de um jogo. 3.1.6 Produtores O termo produtor na área de jogos tem alguns signicados variados, apresentaremos a seguir dois notáveis. O primeiro deles é o produtor responsável apenas por tratar do conteúdo do jogo. Ele deve estar apto a visualizar como o título, que está em fase de evolução, renderá maior lucro aos investidores. Seu intento, portanto, é tornar o jogo o melhor possível para a venda. O outro papel do produtor é de responder pelos processos de desenvolvimento, pois organiza e diligencia para que a equipe possa trabalhar da melhor forma possível e cumprir os prazos e metas que foram estabelecidos. 3.1.7 Líderes de área A comunicação é extremamente complexa devido a grande quantidade de pessoas envolvidas, ou até mesmo, pela maneira empregada para se comunicar. Anal, um artista dicilmente compreende as minúcias das tarefas exercidas por um programador, e este, geralmente, apresenta diculdades para se expressar. Tendo em vista esse fato, foi necessário atribuir a cada área um líder. Estes ajudam o produtor responsável pelo desenvolvimento a organizar a equipe e manter visível seus avanços no projeto. Por vezes, do mesmo modo, cada subárea tem um líder. Como exemplo podemos citar o líder dos programadores de ferramentas. 3.2 Do ponto de vista externo: o mercado Desenvolver jogos funciona de uma forma muito similar ao processo de lançamento de um CD musical. Uma banda não é capaz de produzir o próprio CD por diversos motivos, dentre eles: a falta de equipamentos de gravação e de um estúdio e falta de aptidão para distribuir a mídia mundialmente. No entanto, todos esses itens são fornecidos pela produtora. Igualmente, um estúdio de jogos, às vezes, não possui recursos sucientes para cobrir todos os gastos nanceiros de seus projetos, e assim, como a banda necessita de uma produtora, esses estúdios necessitam de publicadores. 3.2.1 Publicadores de jogos Os publicadores podem ser responsáveis tanto pela distribuição mundial, quanto pelo marketing e também pelo investimento monetário essencial. Empresas pequenas buscam parcerias 8 com publicadores, pois para a grande parte delas, a única maneira de concluir com sucesso o lançamento de um produto é com o apoio desses investidores. O método para o lançamento de um jogo por meio de um publicador é semelhante ao de um projeto de software. Em software, o cliente busca uma desenvolvedora que possa produzir seu projeto. Este já é previamente arquitetado para resolver algum problema ou necessidade vigente do cliente. Diferente do que ocorre em jogos, pois é a desenvolvedora quem origina a ideia ou conceito de um jogo e busca uma publicadora, que neste caso, é o cliente. A publicadora avalia o projeto com o propósito de decidir se nele investirá ou não. Se for aceito, a publicadora planeja milestones, ou metas, na qual a desenvolvedora terá que mostrar o progresso do projeto. Após a conrmação do progresso, a publicadora irá satisfazer uma parte do valor acordado. Durante o projeto, as publicadoras têm prossionais que revisam o jogo e propõe melhorias para a desenvolvedora. Depois que é nalizado, há a divisão de vendas por royalties. 3.2.2 Outros exemplos Nem todos os estúdios no mundo funcionam da mesma forma. Há empresas que se autopublicam, ou seja, que patrocinam o desenvolvimento de um jogo dentro do próprio estúdio. A maioria dos jogos com orçamentos milionários fazem parte deste grupo. Grandes distribuidoras como a Eletronic Arts também são donas de desenvolvedoras pequenas. Estas desenvolvedoras trabalham apenas para a Electronic Arts e têm um grande orçamento em mãos para produzir seus projetos. Existem, da mesma forma, as empresas independentes. São empresas pequenas que também fazem o jogo com a própria verba. Em grande parte dos casos, são prossionais que trabalham em seu tempo livre para produzir o jogo. Há vários casos de empresas que iniciaram suas atividades deste modo e atualmente são de grande porte. 3.3 Game Design Document Game design document, habitualmente chamado de GDD, é um documento montado pelos game designers com o propósito de orientar a produção de um jogo: The purpose of design documentation is to express the vision for the game, describe the contents, and present a plan for implementation. [29]. Segundo Ryan, o GDD é como um guia, em que as ideias sobre o jogo serão guardadas e melhoradas, e de onde os artistas e programadores poderão tirar denições do que deve ser feito. [29] Este conceito é importante para a indústria de jogos; além de sua utilidade na produção, este documento tambem é utilizado na área comercial, pois é por meio deste documento que os publicadores ganham notícia e se interessam por um projeto, caso um protótipo não tenha sido feito. 3.4 Processos clássicos de produção em jogos digitais Clinton Keith, em seu artigo Get in the game , descreve um paralelo da evolução da tecnologia com o tamanho da equipe para produzir um jogo, desde o começo dos anos 80 [20]. Basicamente, nesta época, os jogos eram criados por equipe de uma a três pessoas, e os projetos demoravam cerca de três meses. Uma década depois, os jogos demoravam cerca de um ano de produção, com equipes de uma dúzia ou mais. Neste ponto, já havia problemas de comunicação pelo número de pessoas. Nesta época, foi introduzido o método waterfall na indústria [20], para que as empresas tentassem controlar melhor seus projetos. Porém, a iteratividade que havia quando 9 eram apenas três pessoas produzindo um jogo deixou de existir. Isto fez com que outro problema fosse introduzido, pois é difícil saber o valor de um jogo no começo do projeto. Como Keith arma: For a video game the value is fun, e Fun is very dicult to dene in a document.. [20]. Waterfall é uma metodologia comumente utilizada; ela divide o projeto em um número de fases. De acordo com Winston W. Royce [27], são eles: requisitos de sistema, requisitos de software, análise, design, codicação, teste e operação. Tudo é denido por documentações nas fases iniciais do projeto, que são seguidas até o nal. Waterfall ainda é amplamente utilizado, pois alêm de gerar uma ilusão da previsibilidade do projeto, a documentação criada tem um efeito legal relativo à entrega do software. [14] Agora analisarermos uma alternativa para esta realidade: o Scrum. Antes de vericar seu sucesso neste trabalho, serão apresentados os conceitos básicos de como esta metodologia ágil funciona. 4 O que é Scrum? Uma breve descrição Scrum é uma metodologia de gerenciamento de projetos. Inicialmente criada para ser usada no desenvolvimento de produtos de consumo, a partir de 1993 foi utilizada como uma metodologia para gerenciamento de projetos de software. Scrum addresses the complexity of software development projects by implementing the inspection, adaptation, and visibility requirements of empirical process control in a set of simple practices and rules. [32]. 4.1 Papéis Os integrantes de um projeto que utiliza Scrum são divididos em três partes: o Product Owner, o Scrum Master e a equipe. Ainda existem os acionistas, que não estão ligados diretamente ao desenvolvimento, mas estão conectados ao projeto. 4.1.1 Product Owner O Product Owner, que seria literalmente traduzido como dono do produto, segundo a denição de Schwaber, ... is responsible for representing the interests of everyone with a stake in the project and its resulting product. [32]. Todo projeto que utiliza Scrum começa com uma visão do sistema. O Product Owner é responsável por concretizar esta visão, para que haja o máximo de retorno sobre o investimento [32]. O Product Owner participa de todo o ciclo de produção, para que possa tirar dúvidas e aprovar, ou mesmo rejeitar uma funcionalidade à medida que o desenvolvimento progride. Para isso, ele utiliza o backlog do produto (seção 4.2.1) como ferramenta para documentar as funcionalidades que foram por ele denidas. 4.1.2 Scrum Master The Scrum Master is responsible for the Scrum process [32]. Ou seja, é responsável por ensinar a todos o processo e implementá-lo de forma a respeitar a cultura e métodos da empresa, certicando-se de que todos cumprirão as regras e práticas, para que o projeto seja feito da maneira mais adequada possível e para que o produto seja entregue. 10 4.1.3 Equipe The Team is responsible for developing functionality. Teams are self-managing, self-organizing, and cross-functional. [32]. A equipe precisa negociar com o Product Owner as funcionalidades que serão feitas no sprint e gerar a estratégia de implementação destas funcionalidades, além de comprometer-se a entregá-las. Veremos a denição de sprint na seção 4.3.1. Por ser auto-gerenciada, a atribuição de tarefas não é feita por uma pessoa, e sim pelo grupo. Todos participam de todas as etapas da criação de uma funcionalidade, desde criar ou colaborar na criação da arquitetura do sistema até a implementação e testes do que foi realizado. 4.1.4 Acionistas Os acionistas são todos aqueles que estão envolvidos no projeto, mas não diretamente ligados a ele. São aqueles que fundaram, ou irão utilizar, ou mesmo serão afetados pelo projeto. [31]. Por isso, não são exatamente parte do ciclo de desenvolvimento, e sim usuários que irão criar o feedback para a equipe. 4.2 Artefatos Para o processo funcionar, alguns artefatos precisam coexistir. São eles: 4.2.1 Backlog do produto Como apresentado anteriormente, um projeto com Scrum começa com uma visão do sistema. O Product Owner é responsável por concretizar esta visão para maximizar o retorno nanceiro do projeto. Para tal, ele utiliza o backlog do produto: The Product Backlog is a list of functional and non-functional requirements that, when turned into functionality, will deliver this vision. [32]. O Product Owner mantém esta lista, inserindo e removendo itens e priorizando-a, para que junto com a equipe, escolha de maneira rápida e certeira as funcionalidades que serão feitas no próximo sprint. A equipe ajuda a manter a lista, estimando as funcionalidades, a m de que o Product Owner saiba o custo/benefício de cada uma, permitindo que a priorização seja feita de um modo mais fácil. Cada item desta lista é chamado de história: uma especicação de uma funcionalidade que o sistema terá. Histórias são pequenas, para que caibam em um ciclo de desenvolvimento. Diversos outros conceitos, como teste de aceitação, são necessários para que a história seja escrita por completo [9]. Para este trabalho, é importante saber apenas que elas são escritas pelo cliente. Esta lista nunca está completa e é constantemente alterada. Este é um detalhe que exibe bem o conceito de adaptação de uma metodologia ágil. 4.2.2 Backlog do sprint Sprint, ou iteração, segundo Ken Schwaber é: One cycle within a project. [31]. Ou seja, é simplesmente um período de tempo. A importância deste termo é discutida na seção 4.3.1. Backlog do sprint é uma lista de funcionalidades que são entregues em um sprint. Ela divide as funcionalidades em tarefas para que todos possam saber quanto de trabalho ainda falta para que cada uma seja entregue. Criada na reunião de sprint planning, esta lista é considerada um plano inicial para a iteração, que vai sendo modicado: ... the tasks in the Sprint Backlog emerge as the Sprint evolves. [32]. 11 Idealmente, somente a equipe pode alterar este backlog, criando ou até mesmo retirando tarefas. Porém, as funcionalidades em si não podem ser alteradas: What the team commits to; and what the Product Owner agrees to; during sprint planning should be what is delivered [10]. 4.2.3 Grácos Um dos pilares do Scrum é a visibilidade. Para que isto realmente ocorra, alguns grácos são utilizados a m que exista uma rápida noção de alguns fatores. Para saber, por exemplo, se o projeto está progredindo na velocidade adequada, existe o gráco de Burndown. Segue abaixo um exemplo. Figura 2: Gráco burndown : trabalho produzido por sprint Há inúmeros outros grácos utilizados e muitos destes são vindos de outra metodologia denominada Programação Extrema [7], em que um membro da equipe é chamado de tracker. Ele é responsável por exibir à equipe diversos fatores com diversos grácos. 4.3 Processo O Scrum funciona por iterações, ou sprints, que começa com uma reunião de planejamento, o sprint planning, e todos os dias, é feito o Daily Scrum para que todos saibam do andamento do projeto. Ao nal, há o sprint review, que é uma apresentação para todos aqueles envolvidos no projeto (acionistas) para que a equipe receba feedbacks sobre as funcionalidades desenvolvidas. A equipe também faz a sprint retrospective, em que apontam o que foi feito de errado durante o sprint, para que estes pontos possam ser melhorados. 4.3.1 Sprint é o período de produção entre as reuniões de planejamento. Muitas empresas utilizam duas ou quatro semanas. Um projeto que utiliza Scrum funciona por sprints. A cada sprint, ou iteração, é feito todo o ciclo de reuniões que serão discutidos abaixo. O intuito disso é ter um software funcional a cada iteração, para que ele possa ser testado. Ken Schwaber descreve este processo sucintamente: ... At the start of an iteration, the team reviews what it must do. It then selects what it believes it can turn into an increment of potentially shippable functionality by the end of the iteration. (...) At the end of the iteration, the team presents the increment of functionality it built so that the stakeholdes can inspect the funcionality and timely adaptations to the project can be made. [31]. Basicamente, The heart of Scrum lies in the iteration [32]. Segundo Mike Cohn, o sprint pode ser cancelado por dois motivos: pela equipe, caso ela esteja prevendo que não irá conseguir alcançar o objetivo do sprint, ou pela área de negócios da empresa, caso as prioridades para o projeto mudem. [10]. Sprint sprint 12 4.3.2 Sprint Planning Esta reunião é dividida em duas partes. Na primeira parte, o Product Owner explica os itens que estão no topo do backlog. A equipe faz as perguntas indispensáveis para entender se estas funcionalidades são realmente a prioridade, e também para saber seu real funcionamento tendo assim uma noção da complexidade exigida. No nal desta reunião são decididas quais destas funcionalidades serão desenvolvidas no próximo sprint, isto é, o backlog do sprint. Na segunda parte da reunião, a equipe quebra as funcionalidades em tarefas e faz o planejamento da iteração. O plano criado é um plano inicial, e pode ser alterado pela equipe. 4.3.3 Daily Scrum Enquanto os planejamentos acontecem uma vez por sprint, o Daily Scrum ocorre todos os dias. É uma reunião rápida na qual a equipe, através de três perguntas, sabe se o sprint está de acordo com o plano. As três perguntas são: • O que foi feito desde a última reunião? • O que será feito até a próxima reunião? • O que o impede de fazer seu trabalho? A principal ideia desta reunião é ser o mais informativa possível, para que o próximo dia possa ser planejado com base no que foi construído no dia anterior. Ken Schwaber descreve diversas regras para tal reunião [31] . Por exemplo: • A reunião deve ocorrer sempre no mesmo horário e no mesmo lugar. • Todos os membros da equipe precisam comparecer. Se por algum motivo alguem não conseguir, outro membro da equipe precisa responder às perguntas por essa pessoa. • O Scrum Master é responsável em manter a reunião objetiva e dentro do horário, não deixando discussões paralelas acontecerem. • Membros do projeto que não são da equipe (por exemplo, o Product Owner ) podem apenas assistir à reunião, sem dar opinião ou interromper para tirar dúvidas. 4.3.4 Sprint Review Ao término do sprint, a equipe apresenta o que foi feito para o Product Owner e para possíveis interessados no projeto. Esta reunião serve para vericar se o plano inicial foi concluído com sucesso. 4.3.5 Sprint Retrospective Esta reunião acontece apenas com a equipe e o Scrum Master. Serve para revisar o sprint anterior e propor melhorias para o próximo. Não deve entrar em pauta a busca por culpados ou a discórdia entre pessoas do grupo. O sprint retrospective auxilia na melhoria da interação entre os membros e na busca de soluções para possíveis falhas da equipe no processo. Após ter examinado esta base de conhecimento, vericar-se-à, sem antes tê-lo aplicado, se há considerações a ser feitas sobre a aplicação deste conhecimento em empresas de jogos, e quais são os pontos que já sabemos em que esta metologia pode ou não ajudar, dado o diferente contexto. 13 5 Impressões iniciais da aplicação do Scrum para empresas de jogos digitais Inicialmente, tem-se a impressão de que Scrum funcionaria sim em uma empresa de jogos, caso este também seja software, porém com problemas únicos, como Mateos-Garcia e Sapsed explicam: The video game sector is a software-intensive creative area of growing economic importance where organisations have for a long time struggled to establish suitable methodologies for product development. [14], portanto esta indústria é de intensa criatividade, e, por tal fator, ainda não foi encontrada uma metodologia adequada. 5.1 Jogo digital é software? Se olharmos essa questão pelas ferramentas de desenvolvimento e de utilização do produto, claramente a resposta é armativa, anal joga-se e produz-se o jogo através de computadores. Mas, qual a importância de um jogo? A importância de um software comercial é, geralmente, de atender a uma necessidade, enquanto que a prioridade de um jogo é divertir. Quando falamos de diversão, estamos argumentando sobre um conceito abstrato e de difícil discussão. Para este trabalho, é necessário apenas questionar este fator como um enfatizador da diferença dos dois mundos aqui discutidos. Este fator é o que faz com que jogos sejam um universo diferente do universo de softwares. Por causa disso, torna-se ainda mais imprevisível o planejamento de um projeto de jogos, como armam Mateos-Garcia e Sapsed: The elusive dimension of 'fun' (which could be understood as the quality and uniqueness of the gaming experience) constitutes a key emergent variable dicult to predict at the planning and component design stages of a project. [14]. 5.2 Relação entre GDD e backlog do produto O Scrum incentiva a comunicação entre a equipe e o Product Owner, em decorrência da simplicação da documentação, porém ela não pode ser eliminada. No caso da indústria de jogos, o GDD ainda é importante para guiar o começo do projeto, para que seja documentada a ideia geral do jogo, tanto na parte de gameplay quanto na parte de conteúdo. Ao longo do projeto, tendo esta base, torna-se mais fácil discutir e detalhar as funcionalidades do jogo. Antigamente, um GDD continha todos os fatores de um jogo minuciosamente detalhados, até alguns algoritmos e parametrizações. Porém, esta era uma falsa segurança: muitos destes eram descartados no momento da implementação. Entretanto, esta ideia de documentação extensa também não é mais utilizada: Backlog spreadsheets are not a replacement for printer-friendly game design documentation. Team collaboration is not a substitute for someone putting the product design specication in writing. [25]. 5.3 Como estimar Em projetos de software, cada história é estimada em relação ao esforço para programá-la. Mas, quando se tem uma equipe multidisciplinar, como seria tal estimativa? Teríamos que tratar cada história separada por área? Ou seria o esforço de cada história a soma do esforço de cada área? Não é fácil responder essa questão. Não há, na literatura, um caminho para se seguir quando se trata de jogos. Fazer a soma por área não é, necessariamente, a melhor opção, pois se cada área atacar a mesma história ao mesmo tempo, é possível gerar ociosidade para alguém. 14 5.4 Comunicação entre as áreas Em um Daily Scrum, se todos presentes forem da mesma área de produção, todos conseguem entender o que foi produzido e qual a repercussão para aquilo que estão fazendo. Por exemplo, caso todos sejam programadores, e um deles anuncia que uma funcionalidade foi executada, alguém pode aproveitar o código feito para acelerar sua produção. Mas, e se na mesma reunião houver diferentes áreas discutindo? Provavelmente nem todas as informações trocadas servirão para todos. Será que mesmo assim devemos envolvê-los? O que deve ser apresentado? Para se chegar a uma resposta, isso vai depender muito do tamanho da equipe. Pode ser que esta reunião seja feita apenas entre membros da mesma área, caso a equipe seja grande. Posteriormente é feito o Scrum of Scrums, que será detalhado na seção 7.1, envolvendo todas as áreas, porém com poucos membros. Para pequenas equipes, é necessário todos estarem presentes, mas a qualidade da informação trocada deve ser uma constante preocupação de todos, e tópicos especícos de cada área podem ser discutidos após a reunião. 5.5 Prototipação Como apresentado na seção 5.1, jogos precisam ser divertidos e, como foi visto na seção 3.4, diversão é difícil de ser descrita em um documento. Por isso é fácil deduzir que, no desenvolvimento de um jogo, muitas mudanças são feitas. Muitas funcionalidades de gameplay podem ser alteradas diversas vezes para que possam entreter o jogador. Pode ser até que uma funcionalidade divertida tenha que ser retirada, pois não está congruente com o resto do jogo. Para isso, a necessidade de se desenvolver sistemas que sejam facilmente modicados é grande. O que pode ser feito também é a manutenção de um protótipo, escrito em alguma linguagem que seja facilmente modicada, em que uma certa funcionalidade é implementada e, caso tenha sucesso, seja implementada no sistema nal, em linguagem mais robusta, com aspectos artísticos nalizados. Algumas engines são pensadas para este caso, mas toda a arquitetura precisa ser pensada para rápidas modicações. 5.6 Escrita das histórias Na seção 3.2.1 vimos que as empresas de jogos não têm clientes como empresas de software. O usuário do jogo são os clientes nais, que não agem como product owner, e sim como acionistas, pois todos os jogos têm estudos feitos para a denição de seu público alvo. O mais próximo de um cliente seria o publicador, que por vezes nancia o projeto. Mas, eles também atuam mais como acionistas, pois indicam de que modo o jogo pode car melhor e ajudam em seu desenvolvimento. Em jogos, é simples encontrar uma relação entre o papel de product owner e diretor. Porém, este é um membro da equipe e muitas vezes tem que executar tarefas, seja de arte, programação ou game design. Então, uma pergunta pode surgir: será que é recomendável um membro da equipe escrever as histórias do projeto? E, ao mesmo tempo, será que não podemos extravasar este conceito e fazer com que todos da equipe escrevam ou indiquem histórias para o product owner ? 15 5.7 Relacionamento com o publicador Para realmente utilizar a metodologia com todas as suas práticas, é necessário a colaboração do cliente como parte do processo. No entanto, na indústria de jogos, quando há um contrato com o publicador, geralmente não é de escopo fechado, ou seja, o desenvolvedor tem o poder de modicar alguns conceitos do jogo. O fato é que o jogo tem um prazo máximo para se completar. Assim como um lme, a data de lançamento de um jogo é marcada muitos meses antes, para que a campanha de marketing possa atuar efetivamente para esta data. Há também janelas de consumo próprias para jogo, para ter uma maximização do lucro no lançamento, como, por exemplo, a época de Natal. Como trabalhar iterativamente se o projeto tem uma data exata para o lançamento? No projeto estudado, que utilizou a metodologia, geralmente o que é feito é a adequação do escopo em sprints, pensando em um melhor detalhamento nos sprints mais próximos. Ao longo do projeto, o conhecimento da equipe faz com que a certeza de se produzir ou não uma funcionalidade seja mais próxima da estimativa real. Ao nal do projeto, algumas funcionalidades podem ter sido retiradas, sem prejudicar o produto nal. Ou seja, é como se o Scrum fosse utilizado internamente para manter a produção em controle. Contratos ágeis ainda são raros neste ramo. A pesquisa de Mateos-Garcia e Sapsed, sobre o uso de metodologias ágeis em três empresas, ilustra esta armação [14]. Em uma delas, um pequeno time de doze membros, que trabalha com jogos casuais para dispositivos móveis, não é utilizado Scrum e sim Extreme Programming, outra metodologia ágil. No caso deles, os projetos são pequenos e duram cerca de seis iterações. O relacionamento com o publicador é aberto ao ponto de utilizarem contrato ágil. Na segunda empresa, que era acostumada a utilizar Scrum em algumas áreas para fazer projetos pequenos para outras empresas, agora desenvolve um projeto interno. Neste projeto, eles utilizam Scrum apenas para uma equipe do desenvolvimento, que cuida da parte fundamental do jogo. Para este caso, há um product owner que é o game designer líder. A empresa organiza os sprints e as tarefas para que caibam nos milestones sugeridos pelo publicador. A última empresa estudada utilizava Scrum para pequenos jogos. Quando conseguiram um projeto maior, começaram a ter problemas com o publicador, pois este ditava milestones na qual a empresa não conseguia cumprir. O product backlog e a auto-organização da equipe foi substituída por uma lista de tarefas e um processo de gerência top-down. Posteriormente, a empresa organizou pequenas equipes para desenvolver iterativamente algumas partes do sistema. Fizeram isso de modo a não envolver dependência entre as equipes. Os autores armam, ao analisar os três casos, que metodologias ágeis funcionam bem, tanto para o publicador quanto para o desenvolvedor, para projetos pequenos. Quando se trata de projetos grandes, a utilização de equipes ágeis para parte do projeto pode dar certo, como fez as outras empresas apresentadas. Ou seja, utilizaram a metodologia independentemente do publicador, e designaram a responsabilidade de product owner para um membro da equipe. Vericaremos se algumas destas considerações tiveram que ser feitas na prática, e onde foram percebidos os erros na implementação ou utilização da metodologia no projeto Ludo Park. 16 6 Ludo Park A ideia de usar Scrum para este jogo deu-se principalmente pelos projetos anteriores da empresa, que com apenas três anos de existência, já tentou utilizar diversas metodologias de produção, sempre com base em waterfall. Foram usados alguns artefatos diferentes para auxiliar na produção como planilhas e quadros, contudo, mesmo com este esforço, todos eles acabaram atrasando. Com o Ludo Park, isso não poderia ocorrer, pois tivemos apoio nanceiro da FINEP (Financiadora de Produtos e Projetos). Logo, não poderíamos pensar na possibilidade do projeto ser cancelado. Como a verba era xa, tivemos então que adaptar o conteúdo para que o tempo gasto no projeto não ultrapassasse o limite orçamentário. Também por ser o projeto mais complexo da empresa até o momento, tanto em conteúdo quanto em tecnologia, era necessário uma metodologia diferente das usadas anteriormente. 6.1 Projetos anteriores A empresa surgiu com o intuito de fazer jogos de entretenimento. Por causa da difícil inserção neste meio, a estratégia foi fazer em primeiro lugar os chamados serious games, que são jogos em que o foco é o ensino [3]. Nesta área foram produzidos dois jogos de ensino de empreendedorismo. O primeiro sobre as habilidades empreendedoras de um indivíduo, para que este se conheça e tente melhorar os pontos fracos, e o segundo sobre o processo de abertura de uma empresa. Para dar ainda mais um passo nesta área, foi criado o projeto que iremos estudar, o qual é relacionado ao ensino de empreendedorismo sobre o foco de gestão. 6.2 Conceito O conceito do Ludo Park é ensinar empreendedorismo sob o foco de gestão de negócios, de uma maneira lúdica. Para isso, foi escolhido a temática de um parque de diversões, onde cada jogador gerencia uma barraca que vende um dos treze produtos disponíveis. Para aumentar ainda mais a imersão na experiência, o jogo foi criado para uma partida com quarenta máquinas sincronizadas com um servidor, em que toda lógica de mercado é baseada na ação dos jogadores. Toda experiência se passa em um mês dentro do jogo, sendo que cada dia tem duração de dez minutos em tempo real, divididos em duas partes: dia e noite. 17 Durante a noite, o jogador faz a estratégia para o dia seguinte como comprar estoque, ajustar os preços, contratar ajudantes, entre outros. No dia, o jogador visualiza o parque funcionando e os consumidores entrando. Assim ele verica sua estratégia juntamente com os outros jogadores. Até o momento não conhecemos, em serious games, nenhum projeto feito com este patamar tecnológico: um business game em tempo real. Business game, denido por Ruohomaki é: A simulation game combines the features of a game (competition, cooperation, rules, participants, roles) with those of a simulation (incorporation of critical features of reality). A game is a simulation game if it's rules refer to an empirical model of reality. [28]. 6.3 Problemas iniciais Ruohomaki deniu que business game é uma junção de dois fatores: jogos e simulação [28]. A empresa tem experiência em fazer jogos, portanto, para este projeto, seria necessário complementar a equipe com a parte de simulação. Por isso, havia dois especialistas: um de empreendedorismo e o outro apenas de modelagem de mercado para business game, que caram responsáveis pelo conteúdo do jogo. Isto aumentou ainda mais a complexidade de comunicação do projeto. O mesmo aconteceu com o sound designer contratado. Ele não cava no mesmo local que os outros integrantes da equipe, limitando-se apenas a conferências ocasionais. Por último, não possuíamos total conhecimento sobre a tecnologia que pretendíamos utilizar no início do projeto, então optamos por uma estratégia de implementação. Discutiremos em breve se esta estratégia foi válida. A equipe escolhida para este projeto ainda era recém formada e sem experiência em projetos ágeis, assim como o Scrum Master. O Product Owner era, por muitas vezes, ausente, pois tinha diversas outras tarefas para fazer. 6.4 Por que o Scrum foi escolhido e como foi implementado? Os empresários da Insolita Studios - empresa desenvolvedora do Ludo Park - sabiam que o processo de desenvolvimento que estava sendo utilizado anteriormente não funcionava. Ao participarem do SBGAMES - Simpósio Brasileiro de Jogos Eletrônicos - de 2006 em Recife, eles conheceram algumas empresas que estavam utilizando Scrum e obtiveram êxito em seus projetos e por isso, decidiram usá-lo. Porém, a implementação não teria sido possível apenas com os funcionários da empresa. De fato, excetuando-se os dirigentes, nem mesmo os programadores tinham conhecimento sobre esta metodologia. Portanto, foram efetuadas duas contratações: a de um produtor, que se tornaria o Scrum Master, e a de um consultor com conhecimento na metodologia que é o autor deste trabalho. Este consultor tinha três responsabilidades: explicar ao produtor como o Scrum funcionava e dar guias de como se especializar; criar uma estratégia de implementação para a equipe; montar um plano que visava à utilização desta metologia no projeto, que já estava em fase de conceituação. Por conceituação, entende-se: os game designers criavam o GDD, os artistas conceituavam uma direção de arte e os programadores estudavam e escolhiam ferramentas que seriam necessárias para o projeto. A primeira responsabilidade teve início por meio de reuniões entre o consultor e o produtor, que estava apenas concentrado nesta atividade e, portanto, obteve êxito neste primeiro contato com metodologias ágeis. 18 Logo depois, foi montada a estratégia de implementação com a equipe. A pedido do presidente da empresa, era necessário fazê-la em pouco tempo, para que a equipe alcançasse as denições iniciais do projeto rapidamente. Portanto, foi empregada uma estratégia, que será analisada na seção 6.5.1, que era composta, basicamente, por três ações: um dia reservado para uma palestra inicial, introduzindo o funcionamento do Scrum e como ele seria utilizado; um dia posterior, na qual seria feita uma atividade lúdica; e um tempo diário nas semanas seguintes, para estudos e debates. Logo em seguida ao período inicial, o consultor acompanhou remotamente o projeto, sempre em contato com o Scrum Master, e ao nal do decorrer de três meses, começou a exercer a função de Lead Programmer, juntando-se efetivamente à equipe. 6.5 Erros Ao invés de discutir cronologicamente os eventos1 , analisar-se-ão os problemas como um todo, e estes serão temporarizados caso necessário. 6.5.1 O método de implementação Como já mencionado, a empresa não dispunha de tempo ou experiência, para introdução dos conceitos paulatinamente. Portanto, a equipe e até mesmo o Scrum Master foram inundados de conhecimentos, que, praticamente, não faziam sentido e não se interconectavam. Logo no início do projeto, todos estavam com uma falsa impressão de que os objetivos não seriam atingidos e de que possivelmente a implementação do Scrum seria inviável para este projeto. Segundo Mary Lynn Manns e Linda Rising, existem diversos métodos de inserção de ideias que poderiam ter sidos utilizadas [15]. Neste tópico em especial, poderíamos ter utilizado a estratégia de Step by Step, que consiste em implementar as práticas pouco a pouco. Como elas disseram, The most common mistake change agents make is to take on too much, too soon.. Portando o ocorrido comprova exatamente esta citação. 6.5.2 Scrum Master inexperiente em jogos O Scrum Master, que previamente era produtor, não tinha qualquer vivência relacionada a jogos, por isso não tinha conhecimento dos desaos e problemas desta área. Isto causou basicamente dois obstáculos: na comunicação e na interpretação dos problemas. A equipe não conseguia expôr questões em profundidade ao Scrum Master pois lhe faltava conteúdo, limitando assim o uxo de informações entre os integrantes da equipe e também as possibilidades de resolução do problema. 6.5.3 Scrum Master designado como chefe A empresa incumbiu o Scrum Master a esta função ao ser contratado, mas também o designou a chear a equipe. Naturalmente, o Scrum Master é um líder, mas é um líder colaborativo que guia a equipe. Pela utilização da metologia antiga, o lógico era fazer com que este produtor também cheasse a equipe, tradicionalmente: controlando horários, emitindo ordens e designando tarefas, eliminando, assim, a auto-organização em alguns casos. A principal consequência disso foi a desmotivação da equipe no que tange à utilização do Scrum, pois acreditava-se que este papel fazia parte da metodologia, quando na verdade foi uma 1 Nota: As informações aqui dispostas remetem-se somente a opiniões do autor. 19 decisão da empresa, o que levou ao afastamento pessoal do Scrum Master diminuindo, desta forma, cada vez mais a comunicação. Felizmente, desde a inserção do autor deste trabalho como Lead Programmer, foi possível conscientizar a empresa e até mesmo o Scrum Master sobre o que estava acontecendo, e, ao passar do tempo, essa função de chefe foi se diluindo até ser nalmente extinta. 6.5.4 Grande tempo de planejamento A cada sprint planning, era realizada uma reunião que se estendia por um longo tempo. Tentavase planejar todo o sprint, o que agora é visto como um erro: todas as histórias do sprint backlog já eram subdivididas em tarefas. Além de ser um processo demorado, tornava-se um trabalho desnecessário, pois às vezes alguma tarefa não era mais necessária ou não tínhamos uma visão concreta da implementação desta história. Outro erro é que estimávamos as tarefas, e não a história em si. Isso não era necessariamente ruim para o sprint em questão, mas o foi para o projeto como um todo, pois os parâmetros de diculdade mudavam e não se conseguia ter um conhecimento da velocidade de implementação. Para nalizar, sempre que íamos estimar, todos opinavam em todos os tipos de tarefas. Como havia artistas e game designers participando do projeto, as tarefas de programação também contavam com suas opiniões, o que só desperdiçava tempo, pois não eram válidas. O mesmo é verdadeiro para as tarefas das outras áreas. Ou seja, ao invés das tarefas de cada área serem estimadas simultaneamente, gastava-se mais do que o triplo do tempo necessário. Estes erros serviram como aprendizado e, nos projetos posteriores, o planejamento não foi mais executado desta forma. Cada área foi responsável pela estimação das histórias, e depois coube a todos discutir um plano de execução levando em conta as prioridades do Product Owner. Como a história geralmente tem tarefas de todas as áreas, o custo total é a soma dos custos de cada área para desenvolvê-la. 6.5.5 Grande tempo de sprint review Similarmente ao problema anterior, desperdiçava-se uma grande quantidade de tempo preparandose para o sprint review. Nesta reunião havia, na maioria das vezes, apenas o Product Owner e a equipe presente. Esta preparava uma apresentação e praticava uma demonstração do jogo. Os problemas do que já foi exposto eram: a logística, que demorava; e o fato da equipe apresentar algumas funcionalidades que o Product Owner já havia visto ou validado. Apenas uma das vezes que tal apresentação foi feita demonstrou-se útil, pois foram apresentadas diversas modicações para todos os acionistas do projeto, ou seja, os outros sócios da empresa. Novamente, antes do término do projeto isso foi detectado e feito de forma diferente, apresentando apenas as novas funcionalidade ao Product Owner e recebendo seu feedback. 6.5.6 Product Owner ausente Uma vez que o Ludo Park era um projeto interno, o Product Owner era o próprio presidente da empresa. No entanto, exercer esta função era apenas uma de suas inúmeras atividades. Dentre as reuniões que ele participava, pouco tempo podia ser alocado apenas às dúvidas e à apresentação das funcionalidades prontas. Devido a sua inacessibilidade, decisões foram tomadas sem o seu consentimento. Consequentemente, o resultado dessas decisões nem sempre eram positivos, o que constantemente levava a equipe a refazer parte signicante das tarefas já concluídas. 20 6.5.7 Mudança nas atividades mas não no pensamento A implementação do Scrum trouxe diversas normas e novas atividades: planejamentos, reuniões, criação do product backlog. Os passos do processo eram quase todos feitos e utilizando diversos artefatos. Porém, não havia o pensamento ágil. A equipe ainda se prendia em estimações a longo prazo; a comunicação era ineciente. Um reexo disso era o Daily Scrum, que não era informativo a um nível de se ajudarem para o próximo dia, prevendo problemas e impedimentos como uma equipe. Enm, não foi entendida a base do manifesto ágil: Individuals and interactions over processes and tools[18]. Teria sido mais interessante focar em melhorar as capacidades de trabalho em equipe e organização, ao invés de simplesmente seguir as práticas, sem entendê-las ou, pensar se realmente estava tudo no curso certo. Atualmente este continua a ser um dos grandes problemas a ser enfrentado pela empresa. Mas a comunicação e o pensamento estão sendo trabalhados cada vez mais, e já foi presenciado melhoras signicativas. 6.5.8 Arquitetura de software não respondia a mudanças Um dos itens do manifesto ágil é Responding to change over following a plan[18]. Então, para responder a mudanças é necessário uma arquitetura de software que possibilite isso. A empresa, o Product Owner e até mesmo a equipe aceitavam mudanças, pois elas sempre melhoravam o jogo. Porém, os programadores tinham que refazer grande parte do código, o que, em alguns casos era extremamente difícil. Por exemplo, a interface de interação com o usuário foi implementada em código, sem nenhuma ferramenta gráca. Ela precisou ser modicada pelo menos quatro vezes no projeto, e, cada vez que havia mudanças, era igualmente ou até mais difícil modicar esta parte do sistema. A empresa aprendeu com isso e sempre tentou montar os sistemas com base em rápidas modicações, utilizando o máximo de ferramentas disponíveis. 6.5.9 Diculdade de testes A premissa inicial do jogo era fazer um business game em tempo real para quarenta máquinas. Para tal, foi construído um software-servidor em que todas as máquinas se conectavam. Então, para cada teste, o servidor era executado conjuntamente ao jogo em si, em uma única máquina, o que dicultava e atrasava muito os testes. Na parte tardia do projeto, quando era necessário testar o funcionamento do jogo em situações próximas do real, precisava-se alugar salas ou pedir para utilizar salas de aula de instituições parceiras para efetuar estes testes, pois a empresa não dispunha de quarenta máquinas. Isso sempre acarretava em uma logística grande para movimentar a equipe, geralmente em momentos fora do horário comercial. 6.5.10 Relacionamento entre o Scrum Master e a equipe Como foi mencionado na seção 6.5.3, o papel do Scrum Master era dividido. Isso fez com que os integrantes da equipe não solicitassem sua ajuda para retirar os impedimentos que surgiam. Em algumas situações, o Scrum Master foi insensível em relação à equipe e, fazendo uso de sua posição hierárquica para ordenar, tomou decisões desgastantes que agravaram sua relação com a equipe, e isso consequentemente, comprometia a qualidade do produto. 21 Após alguns destes acontecimentos, pode ser obsevado o seguinte: a equipe tentava ao máximo excluir o Scrum Master do processo e tomar algumas decisões entre eles e o Product Owner diretamente. Isso tornava a situação ainda mais conitante dentro da empresa. Ao nal do projeto, foi necessária a intervenção direta dos dirigentes da empresa para encontrar uma solução da questão vigente. Inúmeras conversações aconteceram entre os membros da equipe e os dirigentes para resolver e amenizar o relacionamento com o Scrum Master. Este começou a ter algumas tarefas mais relacionadas à administração e ao marketing do projeto, enquanto a equipe se auto-gerenciava. Posteriormente, em outros projetos, esta situação tomou menores proporções e o Scrum Master perdeu o cargo de chea e começou a colaborar com a equipe. 6.5.11 Diversas ferramentas para o product backlog Ao longo do projeto, buscava-se a visualização do andandamento deste. Para isso, utilizavase ferramentas diferentes para manter o tracking das histórias. Porém, não foi encontrada de imediato uma ferramenta que exibisse os grácos sem muito trabalho do Scrum Master. Foram utilizadas desde tabelas do Excel até outras ferramentas digitais. Ao m, ainda mantivemos um sistema apenas para o gerenciamento de bugs, que cava totalmente desconexo do backlog, o que inviabilizava critérios de priorização para o Product Owner. 6.5.12 Fase de testes tardia no ciclo de desenvolvimento Como citado na seção 6.5.9, a diculdade de cada desenvolvedor em testar o software era muito grande. Um passo natural a essa observação seria a contratação de um prossional para fazer apenas esta função. Isto ocorreu em uma fase tardia do projeto, e o prossional contratado não tinha uma infraestrutura ideal para a realização dos testes, o que resultou em erros básicos do projeto a serem encontrados muito tempo depois, já fora do ciclo de desenvolvimento. 6.5.13 Fases nais do projeto sem planejamento Chegado a um determinado ponto do projeto, tudo que restava era a correção de bugs e modicações na mecânica de mercado interna do jogo. Logo, parte da equipe já estava livre, enquanto os programadores estavam com muito trabalho. Quando este fato aconteceu, não foram feitas mais reuniões de planejamento e nem reuniões diárias. Este fato atrelado ao cansaço da equipe, só trouxe malefícios e uma impressão errada do nal do projeto, que acabou sendo adiado. 6.5.14 Retrospectivas Ao longo de todo o projeto, que teve nove sprints, foram feitas apenas duas retrospectivas. Elas acabaram sendo o que justamente não deveriam ser, pois membros da equipe discutiam as falhas e procuravam culpados para elas. Talvez por este fato, a equipe não procurou ter mais retrospectivas, ao passo que a empresa não queria dispor de tempo para isto. Possivelmente este foi um erro crucial do projeto, pois não buscava-se uma melhor forma de trabalhar, nem da parte técnica, nem do processo seguido. Isto trouxe a vaga sensação de que tudo estava indo pelo caminho certo, quando todos sabiam que não estavam. 22 Quando o projeto acabou, foi feita uma reunião sobre o andamento deste e de como as coisas poderiam melhorar. Foi bastante elucidativo, mas trouxe poucas mudanças para o futuro e, nos projetos seguintes, as retrospectivas continuavam não sendo feitas. 6.5.15 Escolha da tecnologia Para o Ludo Park, foi utilizado C++ com diversas bibliotecas gratuitas. A game engine não passava de uma biblioteca muito abstrata de algumas implementações comuns em jogos, como renderização 2D e máquina de estados. Por isso, toda implementação foi extremamente demorada e custosa. Pela arquitetura do projeto, por ser multi-jogador, esse controle baixo-nível era necessário, porém demandou muito esforço na correção de bugs e principalmente em memory leaks. O que mais dicultou o processo foi a criação e manutenção da interface visual do jogador. O jogo é basicamente uma experiência gráca, e, neste ponto, os custos foram os mais altos. Posteriormente algumas engines visuais foram estudadas e percebeu-se que algumas delas poderiam ter sido usadas sem que o controle da parte multi-jogador fosse perdido. Apesar de muitos erros terem sido cometidos, o Ludo Park obteve êxito, pois foi concluído e está sendo comercializado com sucesso, além do Scrum agora estar sendo utilizado em todos os projetos. Analisaremos, então, o que foi aprendido e o que deu certo neste projeto. 6.6 Aprendizados Como já citado em diversos erros apontados, todos aprenderam com eles ao longo do projeto, já promovendo mudanças. Algumas delas foram posteriores ao projeto, o que também foi muito válido, pois os projetos tiveram que ter um controle maior, por estarem atrelados a um publicador. Examinaremos diversos pontos do processo que foram melhorados ao longo do tempo. 6.6.1 Planejamentos caram melhores e mais rápidos Como previamente citado, os planejamentos eram demorados. Apesar de não ter existido uma nova forma para fazê-los, a equipe aprendeu a coordenar melhor a escrita das tarefas e sua estimação. Ao nal, algumas histórias que dependiam de outras não eram subdivididas em tarefas logo no planejamento, então o tempo foi otimizado. 6.6.2 Melhora contínua no Daily Scrum O Daily Scrum era pouco informativo, como já foi mencionado. Mas, com o tempo, aprenderam a se policiar e a tentar mantê-lo o mais breve e informativo possível. No projeto seguinte, esta reunião diária foi, de fato, mais longa que o esperado, mas este período era aproveitado para discutir diversos problemas do projeto e para planejar o próximo dia com uma maior exatidão. 6.6.3 Scrum e o comprometimento da equipe A equipe sempre foi comprometida com os projetos anteriores da empresa. É importante salientar que, devido ao número pequeno de empresas do ramo, as pessoas que trabalham nisso são extremamente devotadas ao trabalho. Porém, mesmo com o comprometimento, não havia a noção de equipe: pessoas trabalhando para o mesmo m, prossionalmente. 23 Com o uso da metodologia e o guia do Scrum Master, as opiniões passaram a ser unitárias e os problemas internos eram discutidos bem mais prossionalmente ao invés de serem levados ao conhecimento da administração da empresa. Com isso, todos ganharam pois caram mais produtivos, mais unidos e a empresa não desperdiçava tempo na resolução de questões de cunho pessoal. 6.6.4 Estudo contínuo Desde o começo da implementação da metodologia, a empresa apoiou o aprendizado do Scrum por todos. Logo, muito tempo foi alocado para aprender a metodologia e discutí-la, principalmente após o projeto. A equipe participou de eventos e cursos, enquanto o Scrum Master e o presidente zeram o curso de certicação de Scrum Master oferecido pela Scrum Alliance. Isso demostra o comprometimento e a dedicação da empresa em implementar uma metodogia que demonstrou que funciona. Não desistiram à vista dos primeiros problemas. 6.6.5 Atraso do projeto O Ludo Park atrasou cerca de dois meses, que representa um aumento de 30% do prazo estimado. Mesmo sendo um indicativo ruim do uso da metodologia, este valor trouxe muita satisfação, pois todos os outros projetos atrasaram mais e tiveram sempre uma perspectiva de término muito pior. Todos sabiam que o primeiro projeto utilizando Scrum seria mais difícil e custoso, justamente pelo fato de aprender a utilizar a metodologia. Ao nal, todos concluíram que o projeto foi um sucesso. 6.6.6 Coordenação com pessoas externas Como citado, alguns especialistas não trabalharam no mesmo lugar que a equipe. Porém, com as iterações, conseguiu-se sincronizar o trabalho deles com o da equipe, privilegiando e alocando tempo dentro de cada sprint para reuniões, ou para vericar o que eles zeram. O especialista em business game frequentemente ia até o local da empresa, onde apresentava suas ideias, e mudanças já eram feitas no código para vericar se era possível simular o mercado da maneira que ele esperava. 6.6.7 Visibilidade Apesar das diculdades de gerar grácos por falta de uma ferramenta adequada, como citado na seção 6.5.11, ainda sim eles existiam e eram utilizados para computar os pontos de esforço total dentro de um sprint, para saber se todos conseguiriam fazer suas tarefas. Quando as estimações caram melhores, os grácos serviram de indicador de velocidade dentro da iteração, e, ao chegar a um ponto crítico do projeto, conseguiram prever o que atrasaria, havendo, então, diminuições no escopo. 6.6.8 Metodologia da empresa Com o sucesso do projeto, a empresa encarou a utilização do Scrum como uma política para os próximos projetos. Apesar de não conseguirem vender um projeto que utilizasse ocialmente a metodologia, ou seja, com contratos de tempo xo e pagamento a cada contrato, a metodologia 24 foi empregada apenas internamente para controlar o curso do projeto, fazendo mudanças de prioridades e até mesmo de escopo para chegar no melhor produto possível. Nas ocasiões posteriores ao Ludo Park, o andamento dos projetos se deram de maneira menos conturbada, em que foi possível prever muito melhor cada sprint e corrigir o curso diversas vezes. 6.7 Conclusão do uso do Scrum neste projeto Apesar de muitos erros terem sido cometidos, o curso que o projeto teve foi satisfatório e o seu êxito, tanto pelo lado comercial, quanto gerencial, instituiu uma nova metodologia. A equipe ganhou experiência no Scrum e diversos empecilhos foram resolvidos com o tempo. O principal de tudo foi que, após o projeto, quando houve tempo para discutir melhor como tudo foi produzido, conseguiu-se vericar muito bem a origem dos problemas. Tendo isto em mente, todos se tornaram mais produtivos. 7 O uso de Scrum em grandes projetos Vimos como funcionou, e onde pode melhorar, o uso de Scrum em um projeto de pequeno porte. No Ludo Park, a equipe era composta por dez pessoas,incluindo o Scrum Master, mais três consultores externos e o product owner. Como funcionaria utilizar esta metodologia em empresas com equipes de cinquenta, oitenta ou até mesmo cem pessoas, o que não é raro? Este trabalho não tem como objetivo indicar quais são as melhores ou piores práticas neste caso, mas sim tentar extrapolar os conceitos utilizados em pequenos projetos que se aplicariam, também, em maiores, e citar técnicas especícas para estes. 7.1 Comunicação Quanto maior o número de indivíduos, maior o número de interações entre eles. Logo, concluise que a comunicação seria um dos maiores fatores que o Scrum precisaria facilitar no caso de grandes equipes. Fazer um Daily Scrum com dezenas de pessoas seria duradouro e improdutivo. Para este problema, pode ser utilizado o Scrum of Scrums. The scrum of scrums meeting is an important technique in scaling Scrum to large project teams. [8]. Esta técnica consiste em fazer reuniões como a de Daily Scrum, porém em diversos níveis. Se há vários times no mesmo projeto, cada time elege uma pessoa para ir ao Scrum of Scrums. Caso seja necessário, pode haver várias reuniões deste nível, e, cada uma dessas, elege uma pessoa para fazer outra reunião. Mike Cohn defende que estas reuniões não precisam ser feitas diariamente. Por isso, com exceção das perguntas usuais de um Daily Scrum, outra pode ser feita: Sua equipe está para impedir outra de alguma forma? Esta pergunta pode resolver muitos problemas que veremos na seção 7.2. 7.2 Impedimentos Outra fato seria que as equipes, mesmo subdivididas, poderiam gerar impedimentos para outras, caso estas estejam dependendo de algo para prosseguir. Por exemplo, a área responsável pela arte precisa nalizar um personagem animado para que outra área, responsável pela programação, possa programar as ações deste personagem dentro do jogo. 25 Neste caso, a equipe precisa perceber estes impedimentos e planejar temporalmente a entrega destes itens. Uma área pode iniciar a história sem todos os itens necessários, mas pode fazer uso de objetos temporários para começar, sempre pensando em utilizar o que será produzido para quando o item nal for entregue. 7.3 Desenvolvimento Incremental O que discutimos basicamente até agora é fazer software de maneira incremental. Em jogos, isto é essencial para criar a diversão. Quando há uma grande equipe, existem muitas pessoas, com uma ideia no mínimo parcial do projeto. Como todos funcionários também jogam, o feedback da equipe é importante e pode ser utilizado. Porém, as mudanças precisam ser controladas por uma pessoa ou área, que é responsável pelas decisões e mudanças do produto, que precisa relevar se a modicação vai ser notável e se realmente vai melhorar o produto, em função do custo que será gerado. Esse assunto será mais detalhado no Apêndice B (seção 10). 7.4 GDD Em um projeto grande, com anos de duração, é importante que os membros da equipe saibam o que será o produto nal, e qual a sua parte nele. Em jogos, o GDD tem uma visão que é construída incrementalmente. Logo, em grandes projetos, é importante que com o trabalho sendo construído, todos os membros da equipe leiam ou saibam como o projeto está evoluindo, para não perder a visão do produto nal. É possível que muitas funcionalidades sejam modicadas ou retiradas ao longo do tempo. Se o resto da equipe não sabe dessas mudanças, alguns problemas podem ocorrer, como a produção de itens que seriam utilizados apenas nestas funcionalidades. Deixar algumas mudanças ou passos importantes do jogo visíveis também é importante. Há diversas empresas que utilizam todas as paredes do estúdio para este m, anexando uxogramas e conceitos que precisam ser construídos, para que toda a equipe saiba o que esperar do que estão produzindo. 8 Conclusão Com este trabalho foi possível concluir que a indústria de jogos digitais pode ser comparada à indústria de software até um determinado ponto. Diversos problemas têm a mesma dimensão, mas quando se trata da utilização da metodologia Scrum, é possível ver que alguns passos precisam ser mais cuidadosamente estudados para se enquadrar às necessidades de empresas de jogos. Um destes problemas é o fato de o cliente ser o jogador, o consumidor nal do produto. Como é impossível saber a opinião de todos os jogadores para moldar o jogo às necessidades do mercado, a empresa precisa denir quem será o product owner, e este precisa buscar feedbacks de todas as maneiras possíveis, e decidir quais mudanças serão feitas. Outro fator problemático seria o contrato legal com o publicador, que geralmente não é de escopo fechado, mas de tempo xo, para aproveitar as datas especiais de mercado. Logo, o Scrum pode ser utilizado para manter o controle do projeto internamente e pensar em mudanças de escopo quando os problemas forem detectados. Talvez um dos pilares para a inserção do Scrum nas empresas de jogos seria o fato de existir pouca literatura voltada diretamente para este ramo. Até a escrita deste trabalho, pouquíssimos 26 autores zeram textos diretamente voltados a metodologias ágeis para jogos, e nenhum destes de grande impacto quanto aos livros para indústria de software. Por m, o espírito de iteratividade das metodologias ágeis como um todo é o mesmo que sempre pairou sobre a indústria de jogos: construir sistemas iterativamente, reetindo se o que está sendo construído é divertido, agradável e fácil de utilizar pelo jogador. Unir esta indústria a esta metodologia é um passo lógico e, provavelmente com o tempo, várias empresas irão aderir a metodologias ágeis e talvez estas possam evoluir para novas metodologias especícas para esta área. 9 Apêndice A - Game Engine Discutido na seção 3.1.2, engine é um software, ou middleware, que abstrai diversos itens básicos de todo o jogo. Neste apêndice, iremos citar algumas das engines mais utilizadas no mercado. 9.1 PopCap Esta engine é, na verdade, um middleware para C++, em que se integra, a partir de uma biblioteca, diversas funcionalidades como renderização 2D, abstração de GUI (graphic user interface ), input do usuário e algumas outras facilidades mais técnicas como máquina de estados ou loop de jogo. Por se tratar de uma biblioteca, o desenvolvimento é lento e custoso. Por outro lado, por ser em C++, pode-se utilizar toda a gama de bibliotecas e APIs que já existem para esta linguagem, uma das mais utilizadas em jogos. Utilizamos esta engine no Ludo Park, e, apesar das diculdades, o controle sobre toda a parte de abstração de rede (na qual utilizamos uma biblioteca aberta chamada RakNet ) fez com que a PopCap não fosse uma escolha tão ruim. 9.2 Unity 3D Umas das engines que mais cresce, por ser relativamente barata (US$1500,00), e por exportar para web com facilidade, a Unity 3D é uma engine visual onde você pode programar utilizando scripts, com o uso de um arcabouço. Por ser totalmente visual e por ter uma arquitetura de componentes, a prototicação nela é rápida, então a velocidade de desenvolvimento desta ferramenta é bem grande. Utiliza-se ela, hoje em dia, em projetos para web e em projetos para iPhone, na qual a Unity é uma engine pioneira. Atualmente ela também esporta para Nintendo Wii, mas o preço não é divulgado para o público. Para esta plataforma, ocialmente, só há um jogo até agora. 9.3 Unreal engine Talvez a engine comercial mais utilizada em grandes projetos até hoje, esta ferramenta também é visual e possui inúmeras funcionalidades e integrações com ferramentas famosas. Esta engine exporta os jogos para qualquer console e possui alta otimização para cada uma delas. Apesar do alto custo de licenciamento, que estima-se em torno de US$700.000,00, por ser fácil de usar e altamente customizável, este custo geralmente é baixo se comparado às vendas do produto nal. Por exemplo, o sucesso Gears of War 2 para Xbox 360 vendeu mais de 5.6 milhões de unidades [33]. 27 10 Apêndice B - Design de projeto Frederick Brooks, em seu clássico livro de gerência de projetos O mítico homem-mês faz diversas armações sobre a indústria de software que são bem signicativas mesmo quase trinta e cinco anos depois de seu lançamento [17]. Comunicação, um dos tópicos mais abordados neste trabalho, é tratado por Brooks como sendo um dos fatores de aumento de complexidade de projeto. Atrelado a este fator, está a lei de Brooks: A adição de recursos humanos a um projeto de software atrasado irá atrasá-lo ainda mais. Em jogos, quando discutimos o design em um projeto, podemos estar falando em diversas esferas. Dentre elas: a arquitetura do sistema que incorpora o jogo; as decisões artísticas que foram tomadas; como o jogo é de fato jogado e como ele se desenvolve: o gameplay ; Brooks defende a ideia da integridade conceitual: um sistema que reita um conjunto de pensamentos, que omita certas funcionalidades anômalas, do que um sistema com boas ideias, mas independentes e descoordenadas [17]. Para tal, Brooks infere que esta integridade conceitual apenas é alcançada caso ela parta de uma única mente, ou um número muito pequeno de mentes concordantes. Em métodos ágeis, Agile designs are emergent, they are not dened up front[5]. Se este design é incremental, todo o time é reponsável, o que contradiz Brooks. Em jogos, o gameplay é usualmente proposto e mantido pelo diretor. Este design é incrementado e melhorado pela equipe de game designers, porém o diretor é quem concede a decisão nal sobre as mudanças que vão ocorrer no jogo. Cabe a ele vericar se a proposta do jogo será mantida coerente (aos valores de mercado e da empresa), para decidir se as funcionalidades serão implementadas. Como discutido na seção 7.3, em jogos, geralmente todos os desenvolvedores são jogadores assíduos. Logo, têm muito a contribuir com o produto. Porém, nas denições de Brooks, o diretor age como o arquiteto que mantém a integridade conceitual. Também como arma este autor, esta realidade faz com que os desenvolvedores criem um trabalho intelectual diferente. Porém, em jogos, as opiniões podem ser mais bem fundamentadas, pois os desenvolvedores geralmente têm o perl de seus consumidores nais. 11 Glossário • Gameplay Gameplay, ou Jogabilidade, consiste em desaos e ações que um jogo oferece: desaos para o jogador vencer e ações para vencê-lo. • Engine Uma Engine de jogo abstrai algumas tarefas básicas de todo o jogo (como renderização, física, inteligência articial básica) para que o desenvolvedor foque o esforço em tornar seu jogo único. • Waterfall Metodologia de gerência de projetos comumente utilizada. Consiste em diversas fases e é baseada na extensiva documentação no início do projeto. • GDD GDD, ou Game Design Document, é um documento que contém as informações de como será um jogo, desde sua idealização até detalhes de sua implementação. 28 • Sprint Período de dias de produção de um projeto que utiliza Scrum. Usualmente duas ou quatro semanas. • Business Game São jogos que simulam algum aspecto da realidade, geralmente utilizados para ensino ou aperfeiçoamento de um conceito. 12 Referências Bibliográcas Referências [1] High moon studios. Disponível em: http://www.highmoonstudios.com/. [2] ABRAGAMES. A indústria brasileira de jogos eletrônicos. Disponível em: http://www. abragames.org/docs/Abragames-Pesquisa2008.pdf, Julho 2008. [3] Clark C. Abt. Serious Game. Viking Press, 1970. [4] Artur F. Mittelbach Allan R. S. Araujo, Juliana M. Silva. Scrum: Novas regras do jogo. Disponível em: http://cin.ufpe.br/~sbgames/proceedings/files/Scrum.pdf, 2007. [5] Scott W. Ambler. Agile Modeling: Unied Process. Wiley, 2009. Eective Practices for Extreme Programming and the [6] Eric Bangeman. Growth of gaming in 2007 far outpaces movies, music. Disponível em: http://arstechnica.com/gaming/news/2008/01/ growth-of-gaming-in-2007-far-outpaces-movies-music.ars, 2008. [7] Kent Beck. Extreme Programming Explained: embrace change. Addison-Wesley, 2000. [8] Mike Cohn. Advice on conducting the scrum of scrums meeting. Disponível em: http://www.scrumalliance.org/articles/ 46-advice-on-conducting-the-scrum-of-scrums-meeting. [9] Mike Cohn. User Stories Applied. Addison Wesley, 2004. [10] Mike Cohn. Scrum for video game development. Disponível em: www. mountaingoatsoftware.com/system/presentation/file/50/AgileAustin070206.pdf, 2007. Lafayette, Colorado, Estados Unidos. [11] Mark Deloura. The engine survey. Disponível em: http://www.gamasutra.com/blogs/ MarkDeLoura/20090302/581/The_Engine_Survey_General_results.php, 2009. [12] Ernest Adams e Andrew Rollings. Game Design and Development: Design. Pearson Prentice Hall, United States of America, 2007. [13] Katie Salen e Eric Zimmerman. 2003. Fundamentals of Game Rules of Play: Game Design Fundamentals. MIT Press, [14] Juan Mateos-Garcia e Jonathan Sapsed. Adopting agile and scrum practives as organizational becoming. University of Brighton, 2008. 29 [15] Mary Lynn Manns e Linda Rising. Addison-Wesley, 2004. Fearless Change: Patterns for Introducing New Ideas. [16] Standish Group. Chaos report. Tabela disponível em: http://www.projectsmart.co.uk/ the-curious-case-of-the-chaos-report-2009.html. [17] Frederick P. Brooks Jr. O Mítico Homem-mês. Elsevier Editora, 2009. [18] A. van Bennekum A. Cockburn W. Cunningham M. Fowler J. Grenning J. Highsmith A. Hunt R. Jeries J. Kern B. Marick R. Martin S. Mellor K. Schwaber J. Sutherland D. Thomas K. Beck, M. Beedle. Agile manifesto. Disponível em: http://agilemanifesto. org/, 2001. [19] Clinton Keith. Agile methodology in game development: Year 3. Disponível em: http:// www.agilegamedevelopment.com/Articles/GDC2006/gdc2006_ClintonKeith_0323.ppt, 2006. [20] Clinton Keith. Get in the game: What others can learn from game developers. Software Magazine, 2006. Better [21] Clinton Keith. Agile game development. Disponível em: http://www. agilegamedevelopment.com/Articles/GDC2007/AGDCTutorial_2007_final.pdf, 2007. [22] Clinton Keith. Why use scrum? Disponível em: http://www.gamedev.net/reference/ business/features/whyScrum/, 2008. [23] Clinton Keith. Agile game development with scrum. Disponível em: http:// mikecohnsignatureseries.com/books/agile-game-development-with-scrum, 2010. [24] Rory McGuire. Game design with agile methodologies. Disponível em: http://www. gamasutra.com/view/feature/2742/paper_burns_game_design_with_.php?page=2, 2006. Gamasutra. [25] Paul Miller. Top 10 pitfalls using scrum methodology for video game development. Disponível em: http://www.gamasutra.com/view/feature/3724/top_10_ pitfalls_using_SCRUM_.php, 2008. Gamasutra. [26] Jintao Pan. Software testings. Disponível em: http://www.ece.cmu.edu/~koopman/des_ s99/sw_testing/, 1999. Carnegie Mellon University. [27] Winston W. Royce. Managing the development of large software systems: concepts and techniques. In 9th international conference on Software Engineering, page 329, 1987. [28] V. Ruohomaki. Simulation Games and Learning in Production Management, chapter Viewpoints on Learning and Education with Simulation Games. Chapman & Hall, 1995. [29] Tim Ryan. The anatomy of a design document, part 1. Disponível em: http://www. gamasutra.com/features/19991019/ryanz_pfv.htm, 1999. Gamasutra. [30] Jessie Scanlon. The video game industry outlook: $31.6 billion and growing. Disponível em: http://businessweek.com/innovate/content/aug2007/id20070813_120384.htm, 2007. [31] Ken Schwaber. Agile Project Management with Scrum. 30 Microsoft Press, 2004. [32] Ken Schwaber. What is scrum? download/227, 2007. Disponível em: www.scrumalliance.org/resource_ [33] VGChartz. Gears of war 2 video game sales chart. Disponível em: http://www.vgchartz. com/games/game.php?id=16548. [34] Je Ward. What is a game engine. Disponível em: http://www.gamecareerguide.com/ features/529/what_is_a_game_.php, 2008. 31
Documentos relacionados
SCRUM`ed - Um Jogo de RPG para Ensinar Scrum - GQS
6.1. Ameaças à Validade .............................................................................................................. 76 7. Conclusão .................................................
Leia mais