Pedro Fellipe Passos Cortez Vinicius Bastos Bittencourt. aplicativos para ios

Transcrição

1 Pedro Fellipe Passos Cortez Vinicius Bastos Bittencourt Aceleração da Validação de Hipóteses em aplicativos para ios Rio de Janeiro, Brasil 25 de novembro de 2014

2 Pedro Fellipe Passos Cortez Vinicius Bastos Bittencourt Aceleração da Validação de Hipóteses em aplicativos para ios Monografia apresentada para obtenção do Grau de Bacharel em Ciência da Computação pela Universidade Federal do Rio de Janeiro. Orientador: Prof. PhD. Rodrigo Penteado R. de Toledo Curso de Bacharelado em Ciência da Computação Universidade Federal do Rio de Janeiro Rio de Janeiro, Brasil 25 de novembro de 2014

3 Aceleração da Validação de Hipóteses em aplicativos para ios Pedro Fellipe Passos Cortez Vinicius Bastos Bittencourt Projeto Final de Curso submetido ao Departamento de Ciência da Computação do Instituto de Matemática da Universidade Federal do Rio de Janeiro como parte dos requisitos necessários para obtenção do grau de Bacharel em Ciência da Computação. Autores do Trabalho: Pedro Fellipe Passos Cortez Vinicius Bastos Bittencourt Aprovado por: Prof. Rodrigo Penteado R. de Toledo, Ph.D. Universidade Federal do Rio de Janeiro Orientador Prof a. Jonice de Oliveira Sampaio, D.Sc. Universidade Federal do Rio de Janeiro Prof. Geraldo Bonorino Xexéo, D.Sc. Universidade Federal do Rio de Janeiro

4 Resumo Aceleração da Validação de Hipóteses em aplicativos para ios Pedro Fellipe Passos Cortez Vinicius Bastos Bittencourt A aceleração de validação de hipóteses é muito importante no contexto de startups, pois são empresas inovadoras que vivem em um cenário de muitas incertezas. Desenvolver um grande produto sem antes validar suas ideias pode levar a um desperdício de tempo e dinheiro. O Manifesto Ágil introduz a Entrega Contínua de software útil e funcional como um dos princípios mais importantes para reduzir a espera pelo feedback e assim reavaliar decisões e otimizar o processo. O Teste A/B permite verificar se uma modificação irá melhorar a experiência do usuário ou não através da análise de métricas obtidas. Combinadas, essas técnicas aceleram a validação de hipóteses. O processo de publicação de aplicativos para ios na AppStore envolve uma análise criteriosa e demorada por parte da Apple, o que atrapalha a utilização plena dos métodos ágeis em seu desenvolvimento. Neste projeto foram avaliadas formas alternativas de desenvolver software para ios de modo a acelerar a validação de hipóteses. Um Quadro de Validação foi usado para um melhor acompanhamento da evolução de ideias. Após pivotar a ideia inicial, um aplicativo foi desenvolvido contornando essas dificuldades, apesar da Apple ter concluído que não estava de acordo com suas diretrizes.

5 Abstract Acceleration of Hypothesis Validation in ios apps Pedro Fellipe Passos Cortez Vinicius Bastos Bittencourt Accelerating the validation of hypotheses is very important in the Startup Business context since they are innovative companies that grow in an environment with significant uncertainties. Developing a great product without putting in prior ideas to validate can lead to a waste of time and money. The Agile Manifesto introduces the Continuous Delivery of useful and functional software as one of the most important principles to reduce the waiting time for feedback and hence re-evaluate decisions and optimize the process. The A/B Testing allows to check whether a modification in the product would improve the user experience or not by analyzing collected metrics. These techniques combined accelerate the validation of hypotheses. The process of publishing apps in the AppStore involves a careful and time consuming review by Apple, what hinders the full use of agile methods during the product development. In this project, alternative ways to develop ios Apps were assessed in order to speed up the validation of assumptions. A Validation Board was used to better monitor the evolution of ideas and pivots. After pivoting the initial idea, an App was developed bypassing these difficulties, although Apple have concluded that it was not in accordance with its guidelines. Keywords: Lean Startup, ios, Continuous Delivery, HTML5, Validation Board

6 Agradecimentos - Pedro Cortez Os meus agradecimentos são a todos aqueles que estiveram comigo nessa longa caminhada que foi a graduação e todos aqueles que contribuíram e me incentivaram a nunca desistir. Gostaria de agradecer aos meus pais, à minha namorada Mara, que me fez levar a faculdade mais a sério; aos meus tios Regina e Gabriel que sempre me ajudaram quando eu precisei; e às minhas irmãs Natália e Priscilla. Agradeço aos meus amigos de sempre Rodrigo, Fernando, Boche, Mara, Bernardo, Conrado, Francis por sempre estarem ao meu lado me aturando. Ao Rodrigo de Toledo por toda sua paciência, suporte, ideias e orientação ao longo desse projeto. Ao meu amigo Luiz Felipe Dias por inspirar a ideia dos mini-games que foi tão importante para o projeto. E a todos do Departamento de Ciência da Computação da UFRJ por todos esses anos de aprendizado.

7 Agradecimentos - Vinícius Bittencourt Os agradecimentos são a todos aqueles que de alguma forma contribuíram para que eu chegasse onde estou. Em primeiro lugar, gostaria de agradecer à minha família, especialmente aos meus pais Jorge e Valéria, aos meus irmãos Lucas e Júlia, e ao meu primo Fábio, que sempre estiveram presentes para me apoiar e incentivar. Agradeço aos meus amigos da vida toda, que sempre estiveram ao meu lado proporcionando bons momentos, incluindo Fernando, Mário, Pereira, Fernanda, Saraiva, dentre muitos outros. Muito obrigado pela inspiração e companheirismo. A todos que estiveram comigo durante essa longa jornada que foi a graduação: Macoli e Diego, com os quais fiz os mais divertidos trabalhos em grupo; Taísa, Roberta, Marquinho, André Gustavo, Nati, Matheus, Dick e tantos outros. A Rodrigo de Toledo por todo o suporte e orientação no desenvolvimento desse trabalho. A todos os demais professores do Departamento de Ciência da Computação da UFRJ com os quais eu tanto aprendi. A todos que não foram listados acima, certamente não por falta de importância.

8 Lista de Figuras 1 Exemplo de Preenchimento do Quadro de Validação: caso de uma startup baseada no design de interfaces p Diagrama exemplificando um Teste A/B p Ambiente de Desenvolvimento XCode p Mapa de validações p Respostas dos desenvolvedores sobre Teste A/B p Exemplo de página em HTML5 com aparência e comportamento iguais aos de um aplicativo nativo p Primeira Iteração (Pesquisa com Desenvolvedores) p Respostas dos desenvolvedores sobre processo de aprovação da Apple. p Tempo Médio de Aprovação na AppStore p Segunda Iteração do Quadro de Validação p Tela de Eventos do Construct p Primeiro jogo desenvolvido no Construct p Downloads do App Minigamestorm ao longo do tempo de acordo com o itunes Connect, acessado em 22/09/ p Célula da lista do Minigamestorm p Tela Principal do Minigamestorm p Ícone do Minigamestorm p. 56

9 Lista de Tabelas 1 Endereços de arquivos no projeto e no pacote gerado pelo XCode... p Metadados do nosso aplicativo na AppStore p Histórico do Status na AppStore da versão p Histórico do Status na AppStore da versão p. 58

10 Sumário 1 Introdução p Estrutura do texto p Conceitos p Lean Startup p Quadro de Validação p Pivotar p Hipótese de Cliente p Hipótese de Problema p Hipótese de Solução p Principais Suposições p Suposição de Maior Risco p Método de Validação p Critério Mínimo de Sucesso p Results - Get out of the building p Entrega Contínua p Teste A/B p Funcionamento do Teste A/B p Tecnologias Relacionadas ao Projeto p HTML p Jogos em HTML p CSS p. 24

11 2.5.4 jquery p Web Design Responsivo p Minigame p MVP - Minimum Viable Product p Desenvolvimento para iphone p O ambiente XCode e a linguagem Objective-C p A ferramenta Construct p Sequência de Validação de Hipóteses do Projeto p Pesquisando sobre Teste A/B na plataforma ios p Utilização do método pelos desenvolvedores p Viabilidade Técnica p Aplicativos HTML p Loja Virtual de Aplicativos p Segunda Ideia: Minigames p Validando se jogos em HTML5 podem rodar localmente..... p Validando se usuários finais gostam de Minigames p Usando MVP para validar se as pessoas gostam de iniciar novos jogos frequentemente p Versão Reprovada pela Apple p Desenvolvimento p Estrutura do Código p Procedimentos da MainViewController p Procedimentos da GameViewController p Bibliotecas Utilizadas p Interface do Aplicativo p Ícone p. 56

12 4.4 Inserção na AppStore p Resultados p Aprendizados sobre o processo de inclusão de aplicativos na loja da Apple p Sobre a quantidade de downloads p Aprendizados sobre a capacidade do HTML p Aprendizados sobre o uso do Validation Board p Conclusão p. 62 Referências p. 63

13 12 1 Introdução O mercado das startups no Brasil está crescendo a passos largos. Uma startup é uma empresa diferente de uma empresa tradicional porque ela utiliza, geralmente, tecnologia e modelos de negocio diferenciados, que fazem com que ela cresça numa velocidade muito acima de uma velocidade normal de mercado (PACHECO, 2014). Isso acontece porque ela usa modelos inovadores para vender e comercializar esse produto (GITAHY, 2010). De acordo com um levantamento feito pelo site de empregos Adzuna (EMPREGOS..., 2013), a área mais demandada pelas startups é a Tecnologia da Informação. Ocupando a primeira posição, estão as vagas para desenvolvedor web e mobile (Android e ios). O Brasil é um dos mais importantes mercados na área de Tecnologia da Informação. No caso das startups de desenvolvimento de software, a Entrega Contínua e o Teste A/B são práticas ágeis muito usadas para validar hipóteses na construção de seus produtos com base no feedback dos clientes. Ao longo deste projeto falamos amplamente sobre ambas. Uma dificuldade associada ao modelo de negócios das startups é que ele envolve muitas incertezas (RIES, 2010). Por exemplo, não sabemos se existem clientes para o produto ou serviço, se o modelo é realmente lucrativo ou se é possível executar o modelo. Por este motivo, as startups comumente se concentram em algum tipo de inovação e são consideradas empreendimentos de alto risco. Em um artigo recente, o especialista Will Whitney (WHITNEY, 2013) afirma que quando se está criando um novo produto, o mantra do movimento Lean Startup coloque o produto no ar e faça iterações é a melhor solução. Ninguém sabe o quão complexas são as necessidades e expectativas dos usuários até que eles tenham o produto nas mãos. O Android, comparado ao ios, é uma plataforma muito mais fácil para que as startups validem suas ideias. Testar a primeira versão do seu aplicativo no hardware é tão fácil quanto clicar em executar, enquanto que na Apple é necessário passar por um burocrático processo. Para testar um aplicativo em seu dispositivo ios é necessário ter uma

14 1.1 Estrutura do texto 13 conta paga de desenvolvedor na Apple e para inserir um aplicativo na loja AppStore há um processo de aprovação onde o mesmo é avaliado e isso pode levar dias. Esse processo inviabiliza a Entrega Contínua e o Teste A/B na plataforma da Apple. Neste projeto procuramos formas alternativas de desenvolver software para ios, usando principalmente HTML5, de modo que o usuário tenha acesso a novas versões dos aplicativos de forma instantânea, sem ter que passar pelo burocrático e demorado processo de aprovação da Apple, acelerando a validação de hipóteses. Isso supostamente traria muitas facilidades para as startups que desenvolvem softwares para dispositivos móveis. Entretanto, conforme citamos anteriormente, o mercado de startups é baseado em incertezas e desenvolver um grande produto sem antes validar nossas ideias poderia ser um desperdício de tempo e dinheiro. Exploramos como lidar com incertezas, colocando em prática a utilização de um Quadro de Validação, um método desenvolvido para validar se nossas hipóteses estão corretas e evitar o desperdício de tempo e de esforço. 1.1 Estrutura do texto Para o entendimento do trabalho, são necessários alguns conceitos prévios, os quais são explicados no Capítulo 2. O Capítulo 3 descreve como o projeto foi desenvolvido, mostrando cronologicamente as iterações do nosso Quadro de Validação. As tecnologias adotadas e detalhes técnicos interessantes sobre o desenvolvimento do aplicativo que criamos são abordados no Capítulo 4. O Capítulo 5 traz os resultados e aprendizados que tiramos deste projeto. As conclusões e observações finais estão no Capítulo 6.

15 14 2 Conceitos Neste capítulo explicaremos os métodos e alguns conceitos básicos que utilizamos para desenvolver o projeto. 2.1 Lean Startup Lean Startup (RIES, 2011) é um conjunto de processos usados por empreendedores para desenvolver produtos e mercados, combinando desenvolvimento ágil de software, desenvolvimento de clientela e plataformas existentes de software. O conceito foi introduzido por Eric Ries, que defende a eliminação de práticas de desperdício e o aumento de práticas de produção de valor durante a fase de desenvolvimento do produto. Para isso, é necessário a criação de protótipos rápidos, projetados para validar suposições de mercado e uso de feedback dos clientes para envolvê-los muito mais rapidamente do que através de práticas de desenvolvimento de software mais tradicionais. É comum ver lean startups colocando novas versões de seus produtos em produção mais de uma vez ao dia, fazendo testes A/B e entrega contínua de código de alta qualidade. 2.2 Quadro de Validação O Quadro de Validação, ou Validation Board, desenvolvido pelo Lean Startup Machine (LSM) 1, é uma ferramenta simples e gratuita para testar suas ideias. Ele é baseado na metodologia Lean Startup (RIES, 2011). A elaboração do quadro envolveu o estudo dos processos de mais de 500 startups (WEBER, 2014). Segundo Eric Ries, uma startup é uma instituição humana desenhada para criar um novo produto ou serviço em condições de extrema incerteza. 1 O movimento Lean Startup Machine (LSM) (LEAN..., 2014), formado por empreendedores de todo o mundo, promove workshops e oferece ferramentas para aprimorar o processo de criação de novos produtos em startups.

16 2.2 Quadro de Validação 15 O Validation Board consiste em criar hipóteses sobre o problema e o cliente e definir experimentos a serem feitos, como exemplificado na Figura 1. O objetivo é gerar aprendizado, testando iterativamente cada um dos experimentos, os quais são suposições que caso sejam invalidadas, podem quebrar a empresa ou arruinar a ideia. Ao final de cada iteração obtém-se o resultado sobre a validação ou invalidação da hipótese e, com isso, é possível tomar a ação desejada. Sendo assim, o resultado consiste em supor um cliente e um problema, nos quais são definidas as suposições principais em que, caso alguma delas seja invalidada, o seu negocio irá quebrar. Após criadas as principais suposições, uma delas é escolhida, especificamente a de maior risco ao seu negocio. Nisso, define-se um método de avaliação (Exploration, Pitch ou Concierge) e o seu mínimo critério de sucesso. Por último, executa-se a etapa conhecida como Get out of the building, cujo significado é ir pra rua e realizar as tarefas necessárias para validar ou invalidar a ideia. Caso ela seja invalidada, a suposição estava errada e deve-se pivotar, definindo novas hipóteses de clientes ou problema que queremos solucionar. No entanto, caso ela seja validada, a próxima suposição de maior risco é escolhida e o ciclo é reiniciado. Na parte de cima do Validation Board, em Track Pivots, mapeamos as hipóteses de cada pivot. Os projetos de uma lean startup podem sofrer transformações ao longo do tempo, conforme as ideias são validadas ou invalidas e essa parte do quadro relata um histórico das transformações. Já nas partes de baixo, em Design experiment e Results, encontram-se os experimentos, nos quais colocamos as ideias a serem testadas e o histórico do que foi validado ou invalidado. As subseções a seguir apresentam detalhes sobre como usar o quadro, começando pelo conceito de pivotar e em seguida o modo de preenchimento de cada campo Pivotar Pivotar é um termo derivado do inglês to pivot (mudar ou girar) e designa uma mudança no rumo do negócio. No Validation Board, o pivot é feito quando alguma hipótese é invalidada, isto é, o que foi suposto pela equipe não condiz com a realidade. Nesse caso, diversas ações podem ser tomadas; como por exemplo mudar o segmento, a estratégia, a plataforma e/ou os clientes.

17 2.2 Quadro de Validação 16 Figura 1: Exemplo de Preenchimento do Quadro de Validação: caso de uma startup baseada no design de interfaces

18 2.2 Quadro de Validação 17 As principais maneiras de pivotar, de acordo com a VentureOne (VENTUREONE, 2014), uma aceleradora de startups, são os seguintes: Zoom-in pivot. Neste caso, o que anteriormente foi considerado uma única parte ou característica de um produto torna-se todo o produto. Isso significa desenvolver um MVP com aquela parte ou característica e realizar entregas rápidas e eficientes. Zoom out-pivot. Às vezes, um único recurso é insuficiente para suportar um conjunto de clientes. Neste tipo de pivotamento, o que foi considerado a totalidade do produto torna-se uma única característica de um produto muito maior. Pivotar Segmento de Clientes. Seu produto pode atrair clientes reais, mas não os da visão original. Em outras palavras, ele resolve um problema real, mas precisa ser posicionado em um segmento de clientes para qual seu produto está mais aderente. Pivotar o Que o Cliente Precisa. O feedback do cliente inicial pode indicar que sua solução não é o que ele precisa ou que o próprio não está disposto a usar ou pagar por ela. Isso significa mudar o posicionamento estratégico do seu produto ou um produto completamente novo para encontrar um problema que vale a pena resolver. Pivotar Arquitetura de Negócios. Existem duas arquiteturas de negócios principais: Alta margem, Volume baixo (modelo de sistemas complexos), ou Baixa margem, Alto volume (modelo de operações volume). Não é possível fazer as duas coisas ao mesmo tempo. Pivotar Modelo de Receita. Refere-se à monetização ou modelo de receita. Mudanças na forma de gerar receita podem ser um dos fatores de sucesso de uma startup. Nem sempre há problema com o produto desenvolvido e a solução proposta, as vezes o problema pode ser a forma que o usuário está sendo cobrado pelo uso do produto/serviço oferecido pela startup. Pivotar Tecnologia. Às vezes, uma startup descobre uma maneira de conseguir a mesma solução, usando uma tecnologia completamente diferente. Isso é relevante se a nova tecnologia pode oferecer um melhor preço e/ou desempenho para melhorar o grau de competitividade da startup no mercado em que ela atua.

19 2.2 Quadro de Validação Hipótese de Cliente A Hipótese de Cliente, ou Customer Hyphotesis, é a parte do quadro no qual colocase, a cada pivot, o suposto cliente. Por exemplo, ao desenvolver um produto que tem como objetivo resolver um problema para desendolvedores mobile, esses são colocados em Hipótese de Cliente. Caso a ideia inicial seja invalidada, o produto deverá ser pivotado e, dependendo do caso, ter uma Hipótese de Cliente diferente Hipótese de Problema A Hipótese de Problema, ou Problem Hyphotesis, é uma suposição de problema possuído pelo suposto cliente, cujo o produto poderá resolver. Por exemplo, acreditase que o tempo que um aplicativo leva para ser atualizado é um problema que afeta os desenvolvedores mobile e objetiva-se desenvolver uma solução para acelerar esse processo. Em virtude disso, coloca-se essa demora na atualização como Hipótese de Problema. Em caso de ser pivotado essa Hipótese de Problema pode mudar, assim como a Hipótese de Cliente. Vale ressaltar que a Hipótese de Problema deve ser específica do Cliente. Por exemplo, declarações como: As pessoas não estão fazendo reciclagem, não seria uma definição válida para esse campo, pois não é um problema que uma pessoa possui e sim um comportamento geral da sociedade. Outra declaração como: Esquecer o dia da coleta de lixo, seria um problema válido, pois é um problema que pode afetar um indivíduo. Ambos são demonstrações de declarações similares, porém com problemas distintos Hipótese de Solução A Hipótese de Solução, ou Solution Hypothesis, é o que acredita-se solucionar o problema proposto. Aconselha-se não definir uma Hipótese de Solução antes de validar a Hipótese de Problema, pois não se deve perder tempo e esforço para encontrar uma solução que possa ser invalida após feitos os experimentos Principais Suposições Os itens colocados em Suposições Principais, ou Core Assumptions, são as suposições que deve-se validar através dos experimentos e caso sejam inválidas podem obrigar a pivotar.

20 2.2 Quadro de Validação Suposição de Maior Risco Escolhemos para testar a cada iteração a suposição que possui o maior risco para o nosso negócio dentre as Suposições Principais que restam ser validadas. Chamamos essa de Suposição de Maior Risco, ou Riskiest Assumption. Em outras palavras, é aquele pensamento que se for confirmado através de experimentos que não corresponde ao que supomos ser verdade, tem maiores chances de quebrar nosso negócio e termos que pivotar a ideia. Esse campo fica propositalmente destacado no quadro, com um fundo amarelo, para chamar bastante atenção, já que a validação de seu conteúdo é o passo mais importante dessa iteração Método de Validação O Método de Validação, ou Validation Method, é a forma de validar a Suposição de Maior Risco. O movimento Lean Startup Machine define três métodos para validar as suposições: Exploração O principal objetivo da Exploração, ou Exploration é coletar uma grande quantidade de dados sobre um determinado setor ou cliente. Essa é a fase que aprende-se sobre o negocio, os clientes e a solução da ideia. Para alcançar um dos objetivos deve-se fazer uma pesquisa exploratória no mercado para verificar a sua validade. Pode ser através de enquetes ou entrevistas, obtendo a opinião dos supostos clientes sobre o assunto para tentar descobrir se concordam com a suposição a validar. Caso consigamos obter uma quantidade positiva de opiniões maior ou igual ao mínimo estabelecido, a ideia é validada. Caso contrário, é invalidada. Pitch Seu principal objetivo é validar o cliente. Nessa fase já se tem uma ideia de como solucionar o problema e queremos descobrir como os clientes podem ou querem pagar por isso.

21 2.3 Entrega Contínua 20 O pitch consiste em expor a ideia proposta pra solucionar o suposto problema e obter feedback dos clientes, pode ser através de um video (geralmente entre 1 e 5 minutos) ou uma apresentação. Concierge Seu principal objetivo é confirmar o segmento de clientes e aprender exatamente como a sua solução pode ajudá-los. Entrega-se um produto com os mínimos requisitos para conseguir obter a experiência desejada e coletar dados sobre o comportamento do cliente. Nessa fase já se tem uma boa ideia do segmento do cliente, mas não se tem tanta certeza como ajuda-los Critério Mínimo de Sucesso O Critério Mínimo de Sucesso, ou Minimum Success Criterion, é o valor mínimo que devemos obter no experimento para considerarmos válido. Pode ser, por exemplo, uma porcentagem de usuários que concordaram com a ideia ou uma quantidade de downloads. Pré-determiná-lo evita que haja uma auto-sabotagem Results - Get out of the building Após definir os três itens anteriores, devemos sair do prédio e fazer os experimentos necessários para validar as ideias. A cada iteração, esses itens serão avaliados e dependendo do resultado serão movidos para os espaços destinados a ideias validadas ou invalidadas. As informações de qual o critério de validação e o critério mínimo de sucesso deixam de ser tão importantes depois que a suposição já está testada e por isso, em cada um desses espaços para colocar a ideia relacionada no histórico do quadro, são colocados os três post-its, um em cima do outro, mantendo a descrição da ideia no topo. Desta forma, os três campos do passo anterior passam a ocupar um espaço só, dando destaque apenas à informação mais importante. 2.3 Entrega Contínua A Entrega Contínua é um dos princípios mais abordados em nosso estudo e é de fundamental importância compreendê-lo antes de seguir à diante.

22 2.3 Entrega Contínua 21 O Manifesto Ágil (BECK et al., 2001), documento elaborado em 2001 originalmente por 18 signatários, lista os princípios do desenvolvimento ágil de software, declarando em seu primeiro princípio: Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor. A Entrega Contínua é uma das filosofias que fundamenta o movimento lean. Tratase da criação de um processo repetível ciclicamente para entregar software útil e funcional ao usuário, onde obtemos um retorno sobre o investimento a cada entrega (HUMBLE; FARLEY, 2014). A velocidade em que uma entrega é executada é algo essencial visto que há um custo de oportunidade associado à não entrega do software. Quanto mais reduzido for o tempo de ciclo do processo, mais rápido virá o feedback do cliente, o que nos permite reavaliar nossas decisões para otimizar o retorno. No movimento lean startup, não trabalhamos com requisitos mas sim com hipóteses de que determinadas funções seriam úteis de ser implementadas. Ao avaliar o feedback, podemos identificar quais dessas funções estão de fato sendo úteis ao usuário, validando as nossas hipóteses. Assim, saberemos o que é necessário alterar, incrementar e até mesmo - caso a hipótese seja invalidada - remover em nossa próxima versão. Lembramos que sempre devemos entregar software com qualidade suficiente para gerar valor aos seus usuários. O fato de minimizar o tempo entre as entregas não significa que isso deve ser feito a qualquer custo; deve haver um bom-senso para que as versões entregues estejam sempre dentro de um nível apropriado de qualidade. De acordo com o autor Marcos Valtas (VALTAS, 2011), membro da empresa de consultoria em engenharia de software ThoughtWorks Brasil, para agilizarmos a entrega de novas versões de um software, devemos sempre automatizar tudo que for possível e as pessoas devem se ocupar com tarefas de alto valor. Um analista não deve perder seu tempo testando manualmente seu produto, clicando em botões para ver se estão funcionando ou executando uma sequência de passos repetitivos para colocar uma nova versão no ar.

23 2.4 Teste A/B Teste A/B No desenvolvimento ágil de um software é muito importante experimentar e aprimorar o produto de modo que obtenhamos maior satisfação do cliente. Às vezes é preciso verificarmos se uma determinada alteração irá mudar para melhor ou para pior a experiência do usuário. O Teste A/B (OS..., 2014) consiste em uma metodologia para fazer essas verificações e consequentemente descobrir se nossas suposições são válidas. Assim, mudamos nosso pensamento de nós supomos para nós sabemos que tal alteração no software será bem-vinda pelos usuários. Isso é fundamental para tomarmos as decisões que mais agregam valor ao nosso produto Funcionamento do Teste A/B Figura 2: Diagrama exemplificando um Teste A/B O Teste A/B consiste em disponibilizar duas versões da mesma aplicação aos usuários: uma versão A, a principal; e uma versão B, aquela que contem a variação que desejamos testar. A partir daí, usa-se ferramentas para colher métricas e analisar qual das duas versões está cumprindo seu objetivo com maior eficiência. O conteúdo da variação pode ser o posicionamento de um elemento de interface, uma palavra, um texto, um estilo visual, dentre outros. É importante, no entanto, que cada variação

24 2.5 Tecnologias Relacionadas ao Projeto 23 testada seja a menor e mais unitária possível, para que possamos, repetindo-se o processo com outros elementos, chegar ao resultado ótimo. Quando a quantidade de feedbacks chegar a um número grande o suficiente para se tornar significativo dentro do objetivo estabelecido para o teste em questão, podemos decidir qual das versões é a vencedora e torná-la padrão para todos os usuários. Na Figura 2 o funcionamento do Teste A/B é exemplificado através de um diagrama. 2.5 Tecnologias Relacionadas ao Projeto HTML5 HTML (Hypertext Markup Language, ou Linguagem de Marcação de Hipertexto), versão 5, é uma linguagem para estruturação e apresentação de conteúdo para a Internet. É uma evolução da linguagem HTML, criada em Se diferencia das versões anteriores pelo seu amplo suporte a novas tecnologias multimídias, além da legibilidade do código, que fica muito mais fácil de ser interpretado tanto pelos desenvolvedores quanto pelos parsers dos navegadores (W3C..., 2014). Essas novas facilidades introduzidas pelo HTML5 permitem escrever programas grandes e complexos em formato de aplicação web, tornando a linguagem uma ótima opção para aqueles que desejam desenvolver softwares que operem em múltiplas plataformas ao mesmo tempo. O HTML5 ganhou destaque em 2010, depois que o CEO da Apple Inc., Steve Jobs emitiu uma carta pública intitulada Reflexões sobre o Adobe Flash (KAPLAN, 2010), onde ele conclui que o desenvolvimento do HTML5 tornaria o Adobe Flash não mais necessário, tanto para assistir vídeo ou mesmo exibir qualquer conteúdo web. Isso provocou um debate entre os desenvolvedores Web, onde muitos sugeriram que, enquanto o HTML5 proporcionasse uma melhor funcionalidade, a variedade de navegadores existentes exibiria páginas diferentes, tendo um resultado diferente em cada navegador e não se conseguiria de fato chegar a um padrão. No início de novembro de 2011 a Adobe (ADOBE, 2011) anunciou que iria interromper o desenvolvimento de Flash para dispositivos móveis e redirecionar seus esforços para o desenvolvimento de ferramentas utilizando HTML5.

25 2.5 Tecnologias Relacionadas ao Projeto Jogos em HTML Hoje em dia, através dessa linguagem, que no passado era usada apenas para criação de websites, podemos desenvolver conteúdo com animações, sons, música e vídeo, que anteriormente só eram possíveis com outras ferramentas específicas, como o Adobe Flash, que tem um alto custo para o desenvolvedor em questões de licenciamento, consumo de recursos do sistema operacional, além de outros problemas práticos. Existem muitas ferramentas que permitem desenvolver jogos e exportar o projeto para HTML5, de forma que este poderá ser executado em qualquer navegador CSS CSS (Cascading Style Sheets) é uma linguagem para estruturar folhas de estilo usadas pelas páginas HTML5 (CSS..., 2014). Com o CSS, não é mais necessário definir a formatação de cada elemento em cada página; apenas é especificado a que classe pertence cada elemento e no cabeçalho da página referenciamos que arquivos de folha de estilo iremos ler. Com isso, todas as ocorrências de um elemento definido com cada uma das classes usará o respectivo estilo definido na folha, ou seja, se desejarmos alterar qualquer coisa no estilo de uma determinada classe que é usada por diversas páginas, basta alterar apenas uma vez no arquivo CSS. Os navegadores procuram sempre interpretar de maneira igual as folhas de estilo, de modo que independente do navegador de preferência do usuário, as páginas são exibidas da mesma maneira. Atualmente, o CSS encontra-se em sua terceira versão jquery jquery (JQUERY..., 2014b) é uma biblioteca JavaScript projetada para funcionar igualmente em diferentes navegadores web, com o objetivo simplificar os scripts client side que interagem com o HTML. Possui código aberto, e faz uso da Licença MIT e da GNU General Public License versão 2 (JQUERY..., 2014a). A sintaxe do jquery foi desenvolvida para tornar mais simples a navegação do documento HTML, criar animações de alta qualidade, manipular eventos e desenvolver aplicações web.

26 2.6 Minigame Web Design Responsivo Web Design Responsivo é uma abordagem de web design destinada a elaborar sites para fornecer uma melhor experiência de visualização, fácil leitura e navegação com um mínimo de redimensionamento e visionamento, para uma ampla gama de dispositivos (de monitores de computador a telefones celulares). Em um website responsivo as dimensões dos elementos são definidos por unidade relativas como percentagem, em vez de unidades absolutas como pixels ou pontos. Imagens flexíveis são as que também têm suas dimensões em unidades relativas, de modo a prevenir que escapem de dentro de seu elemento HTML (PETTIT, 2012). Media queries permitem que a página use diferentes regras de estilo CSS com base nas características do dispositivo onde o website está sendo exibido, sendo mais comum a largura de visualização do navegador web. Para o desenvolvimento do nosso projeto, essas técnicas foram muito utilizadas, visto que as aplicações HTML5 que desenvolvemos precisavam rodar bem e se ajustar às dimensões das telas de diferentes iphones e ipads. 2.6 Minigame Diferentemente das definições supracitadas, Minigame é uma definição criada propriamente para o desenvolvimento deste projeto. Um Minigame no contexto do aplicativo desenvolvido é um jogo com as seguintes características: Funciona em navegador com suporte a HTML5; Possui contagem de pontos e possibilidade de gravar recorde; Possui apenas 3 telas: uma com as boas vindas e instruções; outra com o jogo em si; e outra para mostrar a pontuação final; A duração do jogo é rápida, tendo aproximadamente 1 minuto. Extremamente simples de jogar, podendo ter 1 ou 2 comandos simples. 2.7 MVP - Minimum Viable Product Em empreendedorismo, principalmente no contexto de startups, um MVP (Produto viável mínimo) (RIES, 2011) é a versão mais simples de um produto que pode ser

27 2.8 Desenvolvimento para iphone 26 lançada com uma quantidade mínima de esforço e tempo de desenvolvimento. Um MVP ajuda os empreendedores a iniciarem o processo de aprender da forma mais rápida possível, pois poupa tempo e esforços. Porém, ele não é necessariamente o menor produto imaginável. Ao contrário do desenvolvimento tradicional de produtos, que geralmente envolve um longo e pensativo período de incubação, em busca da perfeição do produto, o objetivo do MVP é começar o processo de aprendizagem, e não finaliza-lo. Diferentemente de um teste de protótipo ou conceito, um MVP foi concebido não apenas para responder design de produto ou questões técnicas. Seu objetivo é testar hipóteses fundamentais ao negócio. 2.8 Desenvolvimento para iphone O ambiente XCode e a linguagem Objective-C Figura 3: Ambiente de Desenvolvimento XCode 5 Para desenvolver o aplicativo resultante deste projeto, usamos o ambiente de desenvolvimento XCode (APPLE, 2014b), obrigatório para desenvolver aplicativos nativos ios e submetê-los à AppStore. A Figura 3 mostra a interface do XCode 5. A linguagem usada pelo XCode é o Objective-C (APPLE, 2014a), criada sobre o C. O Objective-C é orientado a objeto e constitui uma das duas únicas linguagens para desenvolvimento de aplicativos nativos para plataformas da Apple, como o Mac OS X e ios. A outra linguagem existente é o Swift, lançada esse ano. Uma das grandes facilidades promovidas pelo XCode é o Storyboard, que nos permite desenvolver uma interface gráfica arrastando os objetos desejados para dentro

28 2.8 Desenvolvimento para iphone 27 da tela. A conexão entre os elementos de interface e o código é feito através de outlets, que são criados simplesmente segurando a tecla control, clicando no elemento e arrastando para o código A ferramenta Construct2 Construct2 (SCIRRA, 2014) é um software desenvolvido pela Scirra, que funciona em plataforma Windows e permite o desenvolvimento de jogos avançados sem necessidade de fazer programação por código. Essa ferramenta permite exportar seus projetos para HTML5 e para frameworks como PhoneGap, Ejecta, CocoonJS, dentre outros, os quais permitem compilar como jogo nativo de ios, Android e Windows Phone.

29 28 3 Sequência de Validação de Hipóteses do Projeto Neste capítulo explicaremos as validações de hipóteses que foram realizadas ao longo do desenvolvimento do projeto. A Figura 4 mostra um mapa com as validações realizadas organizadas de acordo como elas são citadas nas seções e subseções deste capítulo. 3.1 Pesquisando sobre Teste A/B na plataforma ios Utilização do método pelos desenvolvedores O primeiro fator estudado foi a utilização de Teste A/B por desenvolvedores de aplicativos para ios. Por meio de enquetes realizadas nos grupos ios Dev BR e ios Developers, ambos especializados nesse assunto no Facebook e no grupo de alunos e ex-alunos de Ciência da Computação da Universidade Federal do Rio de Janeiro. Esses grupos possuem usuários com o perfil jovem, sendo maioria do sexo masculino, onde a maioria já cursou ou está cursando programação em diferentes linguagens. A pesquisa foi feita entre 22/10/2013 e 04/11/2013. O resultado obtido, detalhado na Figura 5, mostrou que menos da metade dos entrevistados sabia o que era Teste A/B e que, aqueles que sabiam, nunca tinham usado a técnica para desenvolver um aplicativo móvel. O próximo passo deste estudo visa investigar por que motivos uma prática tão comum no movimento Lean Startup não é usada pelos desenvolvedores dessa categoria.

30 3.1 Pesquisando sobre Teste A/B na plataforma ios 29 Figura 4: Mapa de validações

31 3.1 Pesquisando sobre Teste A/B na plataforma ios 30 Figura 5: Respostas dos desenvolvedores sobre Teste A/B Viabilidade Técnica Não existe definição formal para os possíveis graus de flexibilidade de Testes A/B na plataforma ios. Entretanto, ter conhecimento do quanto essa técnica pode ser aprofundada é fundamental para o estudo. Com base nas tecnologias disponíveis, as seguintes possibilidades foram enumeradas para implementar um Teste A/B em um aplicativo ios. 1. Aplicativo nativo contendo diversas versões onde uma delas é sorteada ao inicializar pela primeira vez em cada dispositivo. Deste modo o autor precisa submeter um novo aplicativo à AppStore cada vez que desejar modificar ou incluir novas versões. 2. Aplicativo nativo contendo diversas versões onde é feita uma consulta ao servidor para ver se deve usar uma determinada versão. Caso não tenha sido determinado qual versão usar, uma delas é sorteada ao inicializar pela primeira vez em cada dispositivo. Deste modo o autor precisa submeter um novo aplicativo à AppStore cada vez que desejar modificar ou incluir novas versões. 3. Aplicativo nativo com interface desenhada no próprio aplicativo que baixa um arquivo de configurações do servidor ao inicializar, contendo definições dos elementos de interface. Deste modo, o autor do aplicativo pode alterar a arrumação da interface mexendo no arquivo, sem necessidade de submeter o

32 3.1 Pesquisando sobre Teste A/B na plataforma ios 31 arquivo novamente, mas precisa submeter um novo aplicativo quando desejar incluir novos elementos que não foram previstos no momento em que as versões anteriores foram planejadas. 4. Aplicativo nativo contendo um frame UIWebView, onde uma outra aplicação, que seria a aplicação de interesse, em HTML5, é carregada. A aplicação de interesse sortearia uma das versões para exibir. Deste modo, sempre que o autor desejar incluir novos elementos ou alterar qualquer coisa presente no aplicativo, basta alterar no servidor. 5. Aplicativo web aberto no browser, desenvolvido em HTML5. Nesse caso tudo pode ser modificado diretamente no servidor. Existem algumas ferramentas que fornecem estrutura para fazer Teste A/B com maior praticidade em aplicativos nativos, mas ocorre o problema da falta de flexibilidade nessa modalidade, onde a inclusão de novas modificações a serem testadas necessitam passagem pelo processo de aprovação da Apple. Alguns exemplos dessas ferramentas são: Apptimize, disponível em Optimizely, disponível em Splitforce, disponível em Arise, disponível em O método 4 é o que melhor concilia a flexibilidade dos testes com a experiência do usuário pois além de permitir modificações instantâneas no aplicativo, pode ser submetido à AppStore e ser baixado por seus usuários. Foi verificado que a Apple não aceita aplicativos na loja que (PHONEGAP..., 2012): Não possuem uma experiência de usuário que pareça com um app Não façam com que o usuário se sinta em casa no ecossistema do ios Não ofereça nenhum diferencial em relação a um aplicativo web Esta informação teoricamente desclassificaria o item 4, já que um aplicativo com controles de interface desenhados em HTML5 e CSS3 dentro de um quadro não se comportaria como um aplicativo nativo. Deste modo, um aplicativo nativo com Teste A/B não pode ser alterado de maneira rápida e eficaz na plataforma em estudo pois qualquer atualização requer novo envio

33 3.1 Pesquisando sobre Teste A/B na plataforma ios 32 para a AppStore, passando por todo o processo de análise de inserção de um novo aplicativo. Conclui-se que um dos motivos pelo qual o Teste A/B é muito pouco usado nesse cenário é a falta de praticidade para modificar o aplicativo com base nas métricas obtidas. Se fosse possível um aplicativo desenvolvido em HTML5 se comportar como um aplicativo nativo, porém sendo na realidade uma página da Web que pudesse rodar offline como se fosse baixada para o dispositivo, então teríamos uma solução para o problema, uma vez que páginas da Web não são submetidas a nenhum processo de aprovação. A seguir, exploramos as possibilidades de fazer uma implementação seguindo esse modelo Aplicativos HTML5 A documentação do WebKit (APPLE, 2014c), no qual o navegador Safari do ios é baseado, mostra que existem tags que de fato permitem fazer com que uma página da web se comporte de maneira similar a um aplicativo. Decidimos implementar páginas com as tags definidas a seguir. apple-mobile-web-app-capable - Permite que a página seja aberta em tela cheia, sem exibir a barra de endereços e os demais controles do navegador. Fundamental para dar uma sensação de que é um aplicativo e não apenas mais um site. apple-mobile-web-app-status-bar-style - Permite altear o estilo visual da barra de status do ios. Pode inclusive, se for definido para transparent, remover a barra, como ocorre em muitos jogos de tela cheia. viewport - restringe o dimensionamento da página. Com isso, podemos impedir que o usuário dê zoom ou mova a página para os lados, como acontece em um site normal mas não em aplicativos. Os experimentos mostraram que uma página elaborada com essas tags ficam muito similares a aplicativos nativos, como mostra a Figura 6. Do desenho dos controles às animações, é possível recriar a interface do ios usando HTML5 e CSS3. Desta forma, torna-se possível construir aplicativos de modo alternativo usando HTML5. Tais aplicativos poderiam ser atualizados instantaneamente, tornando tanto o Teste A/B quanto a Entrega Contínua mais eficazes.

34 3.1 Pesquisando sobre Teste A/B na plataforma ios 33 Figura 6: Exemplo de página em HTML5 com aparência e comportamento iguais aos de um aplicativo nativo

35 3.2 Loja Virtual de Aplicativos 34 Surgiu então a ideia de construir uma loja virtual onde desenvolvedores poderiam publicar aplicativos desenvolvidos nesse modelo. Entretanto, antes de investir qualquer esforço para desenvolver algum produto com essas características, é fundamental validar se o cliente hipotético teria interesse na solução. O Quadro de Validação foi usado pela primeira vez nessa validação. 3.2 Loja Virtual de Aplicativos A ideia de uma loja virtual seguindo um modelo diferente do praticado pela loja da Apple poderia ser algo totalmente inovador e abriria muitas possibilidades para as startups. Criar um aplicativo e ter a possibilidade de vê-lo disponível online para qualquer usuário instantaneamente seria uma quebra de paradigma para o desenvolvimento em ios. Decidimos nomear a loja de Outlet, fazendo referência ao modelo de vendas a retalho (varejo), no qual os produtores vendem seus produtos diretamente ao público. As lojas de um outlet são abertas, tais como num shopping, e localizam-se nas saídas das grandes cidades ou regiões metropolitanas. Nessas lojas a redução dos custos de propaganda, manutenção, e mesmo os lucros das redes varejistas, possibilita a venda de marcas comerciais famosas a preços mais acessíveis. Nossa analogia coloca a loja da Apple como uma loja principal de uma marca, localizada no centro de uma cidade, onde os produtos mais caros e luxuosos são vendidos, enquanto nossa loja seria alternativa com produtos simples porém eficientes, disponibilizados a preços mais acessíveis. Na língua inglesa, a palavra outlet também significa tomada, fato que decidimos associar à conexão que seria feita entre o usuário e o desenvolvedor. A ideia de desenvolvolver essa loja é grandiosa e poderia levar meses de trabalho então começamos com a validação para saber se haveria público para tal. A hipótese inicial é que a velocidade da publicação de um aplicativo pode ser um problema para desenvolvedores e pequenos fabricantes de software. As seguintes suposições então deveriam ser validadas: Desenvolvedores acham processo da Apple lento Dev não se importaria em desenvolver em HTML5 Startups gostariam de começar a desenvolver para ios

36 3.2 Loja Virtual de Aplicativos 35 Processo de publicação na AppStore atrapalha Desenvolvedores Processo de publicação atrapalha processo de teste Startups apreciam selo de aprovação da Apple Colocamos então na parte de cima do nosso Validation Board a hipótese do problema e do cliente e, na parte de baixo, as suposições citadas acima. Escolhemos a suposição Processo de publicação na AppStore atrapalha Desenvolvedores para colocar na área da Suposição Mais Arriscada. O método usado para testar essa suposição foi uma pesquisa online onde o menor critério de sucesso seria se 30% dos desenvolvedores entrevistados concordassem com a ideia. A Figura 7 mostra uma parte do Validation Board que foi criado para validar a ideia. Figura 7: Primeira Iteração (Pesquisa com Desenvolvedores) As seguintes perguntas então foram feitas aos mesmos grupos do Facebook citados

37 3.2 Loja Virtual de Aplicativos 36 anteriormente: Há quanto tempo você desenvolve para dispositivos móveis? Você atualiza seu aplicativo com que frequência? Você acha que atualizaria com uma frequência maior se não tivesse que passar pelo processo de aprovação da Apple? Que nota você daria para o sistema de aprovação da Apple? Obtivemos os resultados detalhados na Figura 8. Nenhuma pessoa respondeu que atualiza seu aplicativo uma vez a cada 15 dias, todas atualizam com uma demora maior. 32% atualizam uma vez por mês; 36% atualiza uma vez a cada 3 meses; 14% a cada 6 meses e 18% levam mais de 6 meses para fazer uma atualização. 58% responderam que não atualizariam seus aplicativos com mais frequência se não tivesse que passar pelo processo de aprovação da Apple. 80% das pessoas deu nota acima de 7 para tal processo. Os resultados nos dão uma nota média de 7.3 numa escala de 1 a 10 na avaliação dos entrevistados. Além disso, a razão de avaliações positivas (de 7 a 10) sobre as negativas (1 a 4) é de 19/4 = 4,75, uma proporção muito positiva. Temos ainda a informação de que o tempo que o desenvolvedor atualiza o aplicativo é relativamente demorado, fazendo os dias de espera na AppStore se tornarem menos significativos. Nota-se então que o desenvolvedor embora gaste tempo com o processo de aprovação, não se importa em passar pelo mesmo, visto que o processo visa garantir a qualidade dos aplicativos na AppStore. Contribui para isso o fato de que o tempo de aprovação de um aplicativo na AppStore vem diminuindo nos últimos tempos (APP..., 2014), como detalhado na Figura 9, tornando cada vez mais rápido para um desenvolvedor publicar ou atualizar um aplicativo nativo. A média de cada dia nesse gráfico foi feita, segundo a fonte, pela média do tempo de publicação dos 14 dias anteriores ao dia calculado. Sendo assim, conclui-se que o desenvolvedor acha razoável esperar até os 8 dias para o aplicativo ser aceito. Com isso, nossa ideia inicial, de desenvolver uma loja de aplicativos totalmente baseados em HTML 5 com a hipótese de que o desenvolvedor poderia preferir essa alternativa para economizar tempo e utilizar com maior eficácia

38 3.2 Loja Virtual de Aplicativos 37 Figura 8: Respostas dos desenvolvedores sobre processo de aprovação da Apple os métodos de Teste A/B e Entrega Contínua, fica invalidada logo na primeira iteração do quadro.

39 3.3 Segunda Ideia: Minigames 38 Figura 9: Tempo Médio de Aprovação na AppStore Essa primeira iteração já nos mostrou como o Validation Board pode ser útil. Se tivéssemos desenvolvido a ideia antes de validar, teríamos desperdiçado um esforço enorme com algo que o cliente não quer. 3.3 Segunda Ideia: Minigames Como a suposição de maior risco da primeira iteração foi invalidada, faz-se necessário pivotar a ideia do produto. Escolhemos então seguir em outra direção, mas sem deixar de usar a ideia de Entrega Contínua no ios. Fizemos então um zoom-in nesse cenário. Decidimos tentar abordar um problema mais específico, em vez de algo tão abrangente como era a loja que teria aplicativos de todos os tipos. Assim, surgiu a ideia de uma plataforma de Minigames em HTML5. A ideia de um aplicativo de Minigames surgiu de uma discussão na turma de Métodos Ágeis de da Universidade Federal do Rio de Janeiro, onde os alunos deveriam propor ideias de aplicativos para desenvolver em grupos. Nessa discussão, foi observado que os usuários finais hoje em dia enjoam muito rápido de um jogo e é cada vez mais comum ver as pessoas jogando jogos curtos e simples, que possam ser completados em aproximadamente um minuto. Encontramos muitas ferramentas que ajudam na criação de jogos usando HTML5, CSS3 e Javascript. Decidimos usar então uma dessas ferramentas para nossos estudos, o Construct2, que dada sua simplicidade, permite que até mesmo quem não tem

40 3.3 Segunda Ideia: Minigames 39 conhecimento prévio de programação possa criar um jogo que seria razoavelmente complexo se desenvolvido pela linguagem convencional, o Objective-C. Limpamos então a parte inferior do quadro para dar espaço aos experimentos associados à nova ideia. Na parte de cima, mantivemos as hipóteses anteriores e colocamos as novas na área do primeiro pivot. A Figura 10 mostra como ficou preenchido o Quadro de Validação da segunda iteração. A nova hipótese do cliente da plataforma torna-se então gamers que gostam de diversificar jogos com frequência. A hipótese de problema é que o usuário final enjoa rapidamente de um jogo e a hipótese de solução seria uma plataforma de minigames com lançamentos constantes. Ou seja, um aplicativo para ios que sofrerá atualizações constantes, permitindo ao usuário jogar novos jogos, os quais seriam feitos e colocados diariamente em um servidor sem ter que passar pelo processo de aprovação da AppStore. Criamos algumas suposições que deveriam ser validadas, sendo elas: 1. Seria possível desenvolver e publicar um Minigame muito rápido 2. Jogos em HTML5 podem rodar localmente (sem a necessidade de Internet) 3. Usuários finais enjoam rápido de um jogo 4. Usuários finais não gostam de jogos grandes 5. Usuários finais gostam de começar a jogar novos jogos frequentemente 6. Usuários finais gostam de Minigames Foram escolhidas as suposições 1 e 2 para serem validadas pois elas eram respectivamente as mais arriscadas para o nosso negócio, pois caso não fosse possível rodar os jogos offline e criar jogos rapidamente, nossa suposição de solução seria invalidada. Elas foram validadas através de pesquisas na Internet e desenvolvimento de jogos de testes. Começamos então uma busca por uma ferramenta em que pudéssemos criar jogos com gráficos simples porém de qualidade e jogabilidade intuitiva, focando na ideia de que tal ferramenta deveria nos permitir criar um jogo inteiro num período muito curto de tempo. Se conseguirmos fazer rapidamente um jogo em HTML5 e criar uma plataforma que baixe esse jogo de nosso servidor, executando o mesmo localmente, então teríamos a nossa própria vitrine de jogos, onde a entrega de novos jogos para o usuário final seria imediata.

41 3.3 Segunda Ideia: Minigames 40 Figura 10: Segunda Iteração do Quadro de Validação Descartando o Unity3D O Unity3D, que é uma ferramenta muito popular na concepção de jogos compiláveis para todas as plataformas móveis, foi logo descartado ao verificarmos que não exporta para HTML5, mas apenas para formatos nativos, de modo que não podemos empacotar os jogos para serem baixados para dentro do nosso app. Uma consulta ao pessoal do Grupo de Desenvolvimento de Jogos da UFRJ (GDP - Game Development Project) consolidou essa decisão. A escolha do Construct2 Pesquisamos então por mais ferramentas e encontramos o Construct2, do fabricante Scirra. Na demonstração, que limita o acesso a algumas funções, conseguimos em menos de 3 horas criar um jogo de nave em 2D com cenário de fundo, som, música,

42 3.3 Segunda Ideia: Minigames 41 contador de pontos, dentre outros recursos. Esse software permite programarmos eventos (como cliques, colisões, contagem de tempo) sem necessidade de escrever nenhuma linha de código, como pode ser visto no exemplo da Figura 11. E dentre os muitos formatos de exportação suportados, está o HTML5, onde um javascript é feito com toda a programação. O arquivo HTML gerado pelo Construct2 possui um design responsivo, de modo que pode ser aberto tanto no iphone com tela de 3,5 polegadas quanto de 4 polegadas, assim como nos ipads, e o jogo sempre ficará ajustado à tela. O Construct2 é um programa que tem sua versão gratuita, com poucos recursos e algumas limitações, uma versão completa para uso pessoal e outra completa para uso empresarial. Nesses primeiros momentos, usamos a gratuita em nosso projeto. Para fazer os experimentos mais acurados decidimos criar um Minigame de exemplo com o Construct2. Desenvolvemos um jogo o qual denominamos Asteroids em que o usuário controla uma nave espacial que deve desviar e destruir asteroides. A velocidade e a frequência com que os asteroides surgem na tela aumentam com o tempo, de modo que a dificuldade máxima é atingida após cerca de um minuto de jogo. Figura 11: Tela de Eventos do Construct Validando se jogos em HTML5 podem rodar localmente Decidimos então, tendo já um jogo de exemplo feito com a ferramenta, partir para a validação da possibilidade do jogo rodar offline, caso o usuário não esteja conectado

43 3.3 Segunda Ideia: Minigames 42 na Internet. A primeira solução que tentamos foi usar os métodos de cache disponibilizados pelos próprios navegadores, que constroem o cache baseado nos arquivos de manifesto do aplicativo. Um arquivo de manifesto é associado a um HTML e informa ao servidor quais arquivos devem ser carregados e mantidos em cache quando solicitar determinada página. Em nosso caso, onde estávamos armazenando o jogo de teste num servidor Apache, configuramos o servidor para manter cada imagem, som ou script usados pelo jogo no cache do navegador do usuário. Na prática, entretanto, o resultado não foi satisfatório: a velocidade de carregamento ficou quase instantânea a partir do segundo carregamento, mas ainda assim, era necessário ter uma conexão com a Internet para iniciar a página, impedindo que o jogo fosse carregado num dispositivo completamente offline. Decidimos então verificar a viabilidade de baixar o jogo inteiro de seu servidor e armazenar dentro do aplicativo sem utilização de estruturas de cache dos navegadores. Para isso, o primeiro passo que precisamos validar foi se o jogo rodaria localmente. Para isso, fizemos uma série de verificações. 1) Se o jogo roda no navegador Safari localmente, via emulador Validar se o Safari é capaz de abrir o jogo localmente é fácil através do emulador de iphone disponível no XCode. Como os controles usados para desenvolver nossa ferramenta são baseados no núcleo do Safari (WebKit), então poderiamos inferir que: caso o jogo não rode offline no Safari, então não rodará num frame do WebKit. Abrimos o endereço da pasta local em que possuíamos o jogo salvo no computador em nosso emulador e ele carregou com sucesso. Esse resultado não quer dizer que o jogo irá funcionar bem em nossa plataforma, mas nos dá a informação de que existe essa possibilidade. 2) Se o jogo roda em um frame do WebKit (UIWebView) de uma aplicação feita no XCode Ao tentar fazer o mesmo jogo rodar, só que agora em um projeto do XCode, a chamada para o HTML que inicia o jogo abria apenas uma tela preta.

44 3.3 Segunda Ideia: Minigames 43 Fizemos diversas pesquisas por fóruns de desenvolvedores da ferramenta Construct2 e não encontramos nenhum usuário que já tenha passado por essa situação e compartilhado sua experiência ou resolução. Decidimos entrar diretamente em contato com os fabricantes do software Construct2 e explicar a situação, afim de obter uma resposta positiva ou negativa sobre ser possível ou não rodar os jogos de maneira offline em nossa plataforma. Cópia da mensagem enviada por viniciusbittencourt@me.com em 9 de abril de 2014: Dear sirs, First I would like to congratulate you for the excellent tool that created it. The ease of use and the variety of options available in Construct2 is amazing. I am a student of Computer Science at the Federal University of Rio de Janeiro and I am developing a project based on agile method for continuous delivery. My colleagues and I looked for a tool that would allow us to develop games fairly quickly and Construct2 was by far the best so far. We intend to develop an app which are listed several games created in HTML5 and the user can choose a game to play. Our idea is that when a game is chosen, it is downloaded and run on a frame of WebKit. So basically what we need is the game to be able to work locally. When developing a View in XCode and put a UIWebView inside it, could run games developed in Construct2 if they are on http. However, if we put the game folder within the project and try to open the game by the same control, the screen goes black. We wonder if some limitation of Construct that prevents games to work that way exists or if it would work in paid version (intend to buy soon). Is there any more detail that can be tweaked to work locally? We appreciate any kind of help. Our course has lots of people interested in game development and use Construct2 in our design would make a good product disclosure from you within the university. Regards, Vinicius Bittencourt.

45 3.3 Segunda Ideia: Minigames 44 Os desenvolvedores responderam prontamente. Abaixo, cópia da mensagem recebida em 10 de abril de 2014: What you are trying to do is what PhoneGap already does, and that s already an officially supported export, so you should use that instead. However the ios UIWebView tends to have very poor performance. Consider using CocoonJS, or the new Ejecta exporter, for better performing local ios games. Ashley. Acreditamos que a equipe nos respondeu com muito boa vontade, mas não respondeu explicitamente nosso ponto principal, que era se existia alguma limitação de usar localmente o jogo em HTML5 no XCode. Entretanto, as outras informações dada pela Ashley no indicam que existem ferramentas que permitem rodar localmente fora do Safari, embora não da forma que nós desejamos. Ora, se existem ferramentas que permitem rodar localmente fora do Safari, então conclui-se que essa possibilidade é real e que há uma forma de implementá-la em nossa plataforma. Decidimos então começar em passos menores para entender como o UIWebView do XCode trata as páginas carregadas por eles e os respectivos objetos referenciados. Fizemos então alguns testes: a) Uma página HTML apenas, colocada na página do projeto, escrito Hello World : a página carregou perfeitamente ao compilar e executar o projeto. b) Uma página HTML contendo uma imagem.png: a página carregou perfeitamente, juntamente com a imagem, que foi exibida, ao compilar e executar o projeto. c) Uma página HTML com Hello World e uma imagem.png dentro de uma subpasta images, onde a primeira referencia a segunda com tags HTML. Essa página carregou o texto Hello World, mas a imagem retornou como não existente. Desconfiamos nessa etapa que o XCode ao compilar o aplicativo estaria mudando a forma com que os arquivos são organizados dentro do pacote.app gerado. Os arquivos.app são como arquivos.jar, são pastas executáveis. Podemos com as ferramentas certas abrir esses arquivos e navegar por seu conteúdo. Ao fazer isso com o.app gerado pelo compilador do XCode para o nosso projeto, verificamos que, embora no projeto tivéssemos uma organização dentro de pastas, o XCode estava colocando tudo na raiz do pacote.

46 3.3 Segunda Ideia: Minigames 45 Tabela 1: Endereços de arquivos no projeto e no pacote gerado pelo XCode Endereços Objeto Local no Projeto Local no Pacote Gerado Página Inicial /Asteroids/index.html /index.html Imagem de teste /Asteroids/images/imagem.png /imagem.png Obviamente, com essa diferença nos endereços, os valores nas referências não encontraram os objetos referenciados e por isso a imagem não carregou. Isso explica pelo menos um motivo para o jogo ter carregado apenas a tela preta. Refizemos a importação do conteúdo para nosso projeto e dessa vez marcamos opções diferentes. Ao invés de marcarmos o default do XCode, que copia a pasta agrupar todos os arquivos automaticamente, marcamos a opção de copiar a pasta e criar referências para a mesma. Essa mudança aparentemente simples fez com que nosso executável.app passasse a ter uma pasta Asteroids, com o index.html dentro dela e a imagem numa subpasta images. Definindo o caminho base para dentro dessa pasta, obtivemos sucesso. A imagem foi carregada da pasta referenciada. Substituimos essa pasta por um jogo de exemplo completo em HTML5 e o jogo inteiro carregou, validando que é possível construir uma plataforma que rode jogos em HTML5 para dispositivos Apple sem a necessidade deles estarem online. Agora, para validar que seria possível desenvolver e publicar um jogo em HTML5 muito rápido, decidimos criar um MVP da plataforma contendo uma lista de jogos que seriam disponibilizados ao usuário. Decidimos que a lista de jogos disponíveis para o usuário seria disponibilizada em formato JavaScript Object Notation (JSON) pelo fato de ser mais mais simples e fácil de escrever do que um XML, por exemplo. Além disso, usando o XCode é possível ler um arquivo.json e transferir seu conteúdo para um vetor de objetos usando apenas uma linha de código (o comando NSJSONSerialization). Estrutura do nosso JSON Ao montarmos a estrutura de nosso JSON, decidimos que para cada item é necessário apenas o nome de exibição do jogo, a URL de onde pode ser baixado o jogo quando ele for escolhido para ser jogado (caso ainda não esteja disponível localmente), quais os sentidos (orientações) da tela com que o jogo é compatível e a versão, para que

47 3.3 Segunda Ideia: Minigames 46 seja possível saber se é necessário baixar atualização ou não, além do arquivo dentro do pacote que inicia o aplicativo (geralmente o index.html). Exemplo de um jogo incluido no nosso JSON: 1 name : A s t e r o i d s, 2 u r l : http : / / pf. v i n i c i u s b i t t e n c o u r t. com/ A s t e r o i d s. z i p, 3 o r i e n t a t i o n : landscape, 4 v e r s i o n : 16 Código 3.1: Formato do arquivo JSON O atributo name será usado ao mesmo tempo para identificar o jogo na lista da interface gráfica, para indicar o nome da pasta onde os arquivos do jogo estão localizados e para referenciar o arquivo de imagem contendo o ícone do jogo. Basicamente, as regras são: Quando name = Asteroids : Pasta de onde o jogo será inicializado = /Asteroids Ícone do jogo = asteroids.png E com o atributo url, temos o endereço de onde o jogo será baixado caso ainda não tenha sido armazenado localmente. O atributo orientation serve para indicar se trata-se de um jogo para ser jogado em retrato (portrait), paisagem (landscape) ou qualquer um deles (any). Dependendo da resposta nesse atributo, o aplicativo poderá forçar o uso de uma orientação de exibição na tela do dispositivo. O atributo version é um inteiro que indica a versão mais recente do jogo disponível no servidor. Sempre que a versão armazenada localmente for menor que a do servidor e o dispositivo estiver online, será baixada a nova versão. Ou seja, usando essa padronização, precisamos apenas de quatro atributos para montar nossa lista e permitir o acesso ao jogo, que já é iniciado na orientação correta. Para que a Entrega Contínua seja possível, precisamos que esse arquivo JSON seja baixado de um servidor toda vez que o usuário abrir o aplicativo e estiver conectado à Internet. Caso não esteja conectado, o arquivo carregado é o que foi baixado da última vez em que foi atualizado.

48 3.3 Segunda Ideia: Minigames 47 Ao programar esta parte, notamos que o ios bloqueia a escrita na pasta dos arquivos do programa (/var/mobile/ Applications/[hash MD5 do programa]/ Minigamestorm.app) mas é possível escrever na pasta de documentos que é criada para cada aplicativo (/var/mobile/applications /[hash MD5 do programa]/ Documents). Isso nos fez ter que alterar a pasta em que os arquivos serão baixados da ideia original que era dentro da pasta do aplicativo (como havíamos feito na validação do funcionamento offline) para a pasta de documentos. Por motivos de praticidade, optamos por armazenar o JSON no aplicativo web Dontpad, desenvolvido pelo nosso orientador Rodrigo de Toledo. Ao fazermos uma requisição de dados para a URL é retornado um arquivo de texto estruturado como JSON contendo as informações dos jogos. E usamos o NSFileManager, que é um gerenciador de arquivos que dá suporte para criação, leitura, escrita e exclusão de arquivos. No caso, vamos excluir o arquivo já existente caso o download dos dados tenha sido feito com sucesso e escrever um novo com os novos dados baixados. Baixando o jogo Os jogos são compostos de muitos arquivos. Há arquivos de imagem para os sprites, arquivos de som, bibliotecas e o código do jogo em si. Baixar arquivo por arquivo seria algo demorado para o usuário final e difícil para a nossa implementação. Decidimos então que os jogos ficariam armazenados no servidor em arquivo zipado, de modo que em um único download obtemos o jogo inteiro, além de que, pelo fato de estar compactado, baixa-se muito mais rápido. Para descompactar, inserimos em nosso projeto a biblioteca ZipArchive. Seguimos então o seguinte algoritmo: 1 Se o u s u a r i o e s t a o n l i n e 2 Se o u s u a r i o p o s s u i o jogo 3 Se nao e x i s t e versao mais r e c e n t e 4 Abrir o jogo 5 Se e x i s t e versao mais r e c e n t e 6 Baixar o jogo mais r e c e n t e 7 Descompactar o jogo 8 Abrir o jogo 9 Se o u s u a r i o nao p o s s u i o jogo

49 3.3 Segunda Ideia: Minigames Baixar o jogo 11 Descompactar o jogo 12 Abrir o jogo 13 Se o u s u a r i o e s t a o f f l i n e 14 Se o u s u a r i o p o s s u i o jogo 15 Abrir o jogo 16 Se o u s u a r i o nao p o s s u i o jogo 17 Mensagem de e r r o Código 3.2: Pseudocódigo do algoritmo para verificar atualizações Sabendo que o Construct2 permite gerar códigos em HTML, agora temos tudo o que precisamos preparado para realizar o experimento e validar se é possível testar e publicar um aplicativo muito rapidamente.

50 3.3 Segunda Ideia: Minigames 49 Primeiro jogo O primeiro jogo que usamos foi o exemplo Asteroids de que já falamos anteriormente. A Figura 12 mostra como ficou a principal tela do jogo. Figura 12: Primeiro jogo desenvolvido no Construct2 Conseguimos desenvolver o jogo proposto no Construct2 em apenas um dia, exportamos para HTML5, fizemos upload para um servidor e inserimos uma entrada no JSON do nosso aplicativo. Tentamos abrir o jogo pelo aplicativo e ele funcionou 100%. Conclusão Com isso, validamos que é possível não somente desenvolver como também publicar em uma plataforma alternativa (a nossa plataforma de Minigames) um jogo em HTML que é atualizado quando há atualização disponível e roda localmente Validando se usuários finais gostam de Minigames Para essa validação decidimos fazer uma pesquisa na loja de aplicativos GooglePlay (APLICATIVOS..., 2014) e verificar os número de downloads e a classificação dos minigames. Foram usados 3 apps de minigames com diferentes faixas de downloads e a classificação mínima que estabelecemos para que um app fosse considerado bom para os usuários foi de 3.5 (na escala de 1 a 5), que seria equivalente a uma nota 7 sobre 10. O primeiro jogo escolhido foi o Dumb Ways to Die, que possui a faixa de downloads entre e teve a média de 4.3 (DUMB..., 2014). Esse é um bom

51 3.3 Segunda Ideia: Minigames 50 exemplo de um aplicativo de minigames de sucesso, onde temos jogos pequenos (de até 10 segundos) e que os usuários adoram jogar, afinal, isso seria uma avaliação nota 8,7 sobre 10. O segundo jogo escolhido foi o MiniGame Paradise, que possui a faixa de downloads entre e teve a media de 4.5 (MINIGAME..., 2014). Possui minigames bem simples e com controles fáceis. Esse app é um exemplo de que minigames com comandos simples e curtos são bem vistos pelos usuários de jogos. O terceiro jogo escolhido foi Monster Mini-Games que possui a faixa de downloads entre e teve a média de 3.7 (MONSTER..., 2014). Os minigames desse aplicativo são maiores, da faixa de 1 minuto; e com apenas 1 ou 2 comandos. Nos três exemplos citados temos aplicativos com jogos de comandos simples, curtos e extremamente fáceis de serem jogados. Todos foram muito bem avaliados e possuem um bom número de downloads, mostrando que existe interesse dos usuários nesse tipo de aplicativo e com isso foi possível concluir que sim, as pessoas gostam de minigames; e assim validamos mais esse item Usando MVP para validar se as pessoas gostam de iniciar novos jogos frequentemente A próxima suposição mais arriscada foi a de que os usuários gostam de iniciar novos jogos frequentemente e o método escolhido para validação foi criar um MVP inicialmente com 2 jogos e o critério de sucesso seria ter 10% dos usuários ativos diariamente. Fizemos a implementação desse MVP e subtemos à AppStore, onde, após 7 dias na fila, o aplicativo foi aceito pela Apple. Nos primeiros dias, a quantidade de downloads foi baixa, conforme mostra o gráfico da Figura 13. Fizemos pesquisas sobre o que poderia ser feito para aumentar a quantidade de downloads sem grandes investimentos e vimos muitos sites que vendiam o serviço de reviews pagos, onde podemos pagar 15 dólares por 5 reviews na AppStore, falando bem do aplicativo e dando a nota máxima. Decidimos experimentar então esse método para aumentar a credibilidade do aplicativo na loja e ver se isso faria a quantidade de downloads aumentar. Contratamos o serviço do site BestReviewApp ( e em menos de 24 horas foram feitos os comentários elogiando nosso aplicativo.

52 3.3 Segunda Ideia: Minigames 51 Figura 13: Downloads do App Minigamestorm ao longo do tempo de acordo com o itunes Connect, acessado em 22/09/2014 Entretanto, esse método em nada aumentou a quantidade de downloads, de modo que pudemos concluir que a nota média e comentários positivos até podem contribuir, mas não são suficientes para que um aplicativo tenha mais downloads. Sentimos a necessidade de obter mais métricas para entender melhor o comportamento dos usuários e então fizemos uma atualização para o aplicativo Versão Reprovada pela Apple Para poder validar se os usuários que baixaram o app estavam tendo uma boa experiência e cumprindo o critério mínimo de sucesso que estabelecemos, decidimos fazer uma atualização para o aplicativo incluindo o Google Analytics. A biblioteca do Google Analytics para ios nos permite saber quanto tempo cada usuário está permanecendo dentro de cada jogo, onde ele está clicando e quaisquer outras interações com o aplicativo. Após submeter a atualização para a loja, o tempo para o aplicativo ser revisado pela Apple demorou muito mais que a média. Geralmente um aplicativo fica dias na fila, mas assim que começa a ser revisado, é aprovado ou recusado em poucas horas. Nosso aplicativo atualizado ficou 3 dias sendo revisado até que finalmente recebemos um retorno da Apple, informando que não poderia aceitar nossa aplicação na loja pois ela faz download de conteúdo executável na web. Nos informaram ainda, que o aplicativo poderia ser reavaliado se o recurso de baixar conteúdo externo fosse removido. A versão anterior, sem o Google Analytics, permaneceu no ar por mais uma semana, até recebermos uma notificação da Apple informando a remoção do aplicativo por conter essa função de baixar os jogos. Com esse acontecimento inesperado, a ideia do nosso aplicativo fica inviabilizada.