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