Retrospectiva 2012 e conselhos

Agora que as férias realmente começaram e o fim de ano está chegando, nada melhor do que fazer uma autoavaliação a respeito do desenvolvimento do Shadow Struggles ao longo do período letivo. Espero que possa ser de utilidade a alguém, nem que seja para evitar cair nas mesmas armadilhas que nós. Lembrando que as opiniões aqui expostas não necessariamente representam o grupo inteiro, apenas o meu (Gabriel) ponto de vista, mas os outros membros estão bem-vindos a postarem também.

A ideia

Acredito que nos saímos muito bem na etapa de concepção do projeto, principalmente por causa do entrosamento da equipe e entusiasmo com jogos. Algumas coisas que deram bastante certo:

• Brainstorming: Nada melhor do que um bom e velho brainstorming para identificar boas ideias e permitir que todos do grupo se expressem, bastando para isso uns 30-45 minutos de reunião. Há vários procedimentos que você pode adotar em uma reunião de brainstorming, mas é imprescindível anotar todas as ideias e assegurar que todos mantenham o foco.

• Conceito e protótipo: Após o brainstorming inicial e algumas conversas adicionais, fiquei responsável por tentar organizar as ideias em um conceito único e montar um protótipo. Isso foi bastante útil para a equipe ter uma visão clara do que queríamos desenvolver e acredito ter dado um ânimo a mais, já que nosso conceito estava lá, "em carne e osso", pronto para ser jogado (ainda que com vários bugs...).

• Envolvimento: Mesmo antes de termos oficialmente iniciado as atividades, os membros já estavam empenhados em fazer alguma coisa para contribuir, como testar a movimentação de sprites em Java e modelar alguns personagens de teste. É importante cultivar esse sentimento em relação ao projeto.

Planejamento

Após a aprovação das ideias iniciais pelos professores, começamos a etapa de planejamento do projeto, quando as coisas não foram tão bem assim. E o pior: as falhas nesta etapa só são observadas durante a implementação. Se você já se perguntou por que existe tanta chatice envolvida antes mesmo de começar a programar qualquer coisa, abrindo espaço a profissionais especializados como engenheiros de requisitos e engenheiros de sistemas, aí vão alguns motivos que justificam essa preocupação.

• Escolha de tecnologias: A princípio, o projeto seria desenvolvido apenas para Android, mas o libgdx foi escolhido como alternativa para que pudéssemos testar no PC ao invés do lento emulador de Android. Contudo, a performance de um PC é bem superior à de um dispositivo Android, então é fácil achar que o desempenho está bom só porque roda em plataformas desktop, quando pode acontecer de precisar de várias otimizações para se adequar a dispositivos móveis. Adicionalmente, há várias bibliotecas de desenvolvimento de jogos mais conhecidas e com um suporte maior do que libgdx, então nossa curva de aprendizado foi relativamente alta.

• Cronograma: Montar (e seguir, claro) um cronograma é essencial, mas ele deve ser planejado com base em métricas relativamente seguras e reavaliado com frequência. No nosso caso, subestimamos bastante o tempo que levaria para implementar a mecânica de jogos e outros elementos básicos por falta de experiência (com projetos em equipe longos, programação de jogos e libgdx) e falta de métricas adequadas.

• Escopo: Tivemos problemas parecidos com o escopo, novamente devido ao fato de não sabermos ao certo até onde conseguiríamos chegar, nem em quanto tempo o faríamos. Acabou realmente acontecendo de boa parte do conteúdo previsto não ter sido implementado a tempo.

Há também os problemas com o planejamento da estrutura do programa, mas isso fica para a próxima seção. De toda forma, aí vão algumas dicas para evitar esses problemas:

1. Tome um tempo para pesquisar a fundo sobre as tecnologias disponíveis, de que recursos seu projeto necessitará, qual é melhor meio de armazenamento para os dados etc. O ideal é que todos, ou ao menos os programadores, tenham experiência prática e fiquem "brincando" com as ferramentas, engines etc. enquanto a fase de implementação não se inicia, de modo que o conhecimento adquirido possa ser aplicado no projeto real e o grupo decida se o conjunto de tecnologias escolhido realmente é adequado.
2. Avalie se vale a pena aprender uma tecnologia desconhecida ou parcialmente conhecida em favor de uma tecnologia com a qual todos já estão habituados. Considere, principalmente, a quantidade de material existente na internet, disponibilidade de cursos e se os prazos permitem a dedicação aos estudos.
3. No caso de um projeto em uma área em que os membros não tenham experiência, como desenvolvimento de jogos, vale a pena perder algum tempo com livros e tutoriais especializados.
4. Monte um escopo e cronograma coerentes com as dificuldades que os membros tiveram utilizando as tecnologias. Esteja aberto a reavaliações ao longo do desenvolvimento.

Ah, mas nem tudo é negativo. Uma técnica particularmente útil foi a modelagem visual de requisitos exposta no livro "Engenharia de Sistemas para Leigos", por ser adaptável a mudanças e fácil de entender:

Requisitos funcionais de modalidade e configurabilidade. Clique para expandir.

Também nos empenhamos em fazer bons modelos de dados através de DFDs e MER, muito útil para se ter uma visão geral do sistema antes mesmo de codificar alguma coia.

Implementação

Aparentemente foi uma etapa conturbada, mas a maior parte dos problemas mais graves proveio de falhas na etapa de planejamento: questões de dificuldades de adaptação às tecnologias, quebra de prazos previstos no cronograma, entre outros. Falando de problemas puramente técnicos, destaco nossa dificuldade em organizar a lógica do programa.

Como saber o que cada carta deve fazer, como é o fluxo da partida em termos lógicos, de onde vêm os dados... Mesmo com os diagramas montados, não foi o suficiente para chegarmos a um consenso sobre como deveríamos implementar as funcionalidades. Diria que o principal problema é que estava tudo "abstrato" demais e não conseguimos colocar tudo junto em uma lógica coerente.

Por isso é que decidimos ir um pouco contra as convenções e começar de cima para baixo (conforme relatado aqui), isso é, primeiro montar as estruturas visuais e depois acoplar a lógica a elas. Pode parecer errado colocar a camada lógica em função da camada visual, mas funcionou muito bem para nós e conseguimos enfim dar vida ao projeto após muita insistência.

Minha sugestão é não ficar muito bitolado na lógica pura, tentando visualizar como tudo funciona dentro da sua cabeça. Monte protótipos, de preferência usando ferramentas que permitam um desenvolvimento rápido e visual, e tente aplicar seus algoritmos e demais abstrações para ver o que funciona de fato e o que não funciona. Acredite, você definitivamente não vai querer resolver problemas referentes à arquitetura do projeto junto com problemas relacionados às tecnologias e algoritmos ao mesmo tempo.

Também é importante perceber até que ponto as tecnologias podem ajudar no seu problema. Por exemplo, é necessário criar classes para lidar com a física ou a biblioteca utilizada já possui classes que cuidam disso de forma satisfatória? Se sim, então não perca tempo com isso e vá ao próximo problema.

Por último, lembre-se que você não é a primeira pessoa no mundo a desenvolver um aplicativo para Android, um site, loja virtual, jogo ou seja lá o que for. Pesquise em livros, artigos, fórums, grupos de desenvolvedores etc. e com certeza vai encontrar soluções a pelo menos um dos problemas que seu grupo está enfrentando ou pode enfrentar no futuro, ou maneiras mais eficientes de fazer alguma coisa.

Equipe

Não tivemos muitos problemas relacionados aos membros e suas tarefas, fora o fato de que acabei me ocupando dos gráficos e da programação também, mas isso foi mais devido a minhas tarefas principais já estarem bem encaminhadas.

Só realizamos duas reuniões mais formais, sendo a primeira de brainstorming e a segunda para decidir os rumos do projeto quando iniciamos a etapa de implementação, mas decidimos várias coisas informalmente, seja em conversas na escola ou trocas de e-mail. Se eu pudesse dar somente três conselhos sobre o que leva um projeto ao sucesso, diria: comunicação, comunicação e comunicação.

Se um dos membros não tiver claro em sua mente o que a equipe está fazendo, pode ter certeza que isso vai  voltar da pior forma possível no futuro: "uma corrente é tão forte quanto seu elo mais fraco". Assegure-se de que todos os membros possuam espaço para se comunicar uns com os outros sempre que necessário, seja via e-mail, fórum virtual, MSN/Skype etc., sem se esquecer da importância de reuniões presenciais.

Considerações finais

Gostaria também de falar sobre algumas desventuras pontuais, como problemas com o repositório da escola e algumas dificuldades do Subversion em geral, mas deixo esses assuntos para um próximo dia, se interessarem. Por hora encerro por aqui, a fim de não deixar o post muito longo.

No final de tudo, concluo que foi uma experiência bastante proveitosa e na maior parte divertida. Tive que me deparar com uma variedade de problemas que nem fazia ideia que existiam, pude exercitar ao máximo minhas habilidades e trabalhei em algo significativo para mim ao lado de pessoas com bastante potencial e igualmente imersos no que faziam.

Claro, essa não é uma mensagem de despedida, já que o projeto não morreu ainda. Então vamos seguir em frente, falhando, acertando, tropeçando, levantando e continuando a andar. Embora eu lamente ter errado, não posso dizer que estou arrependido dos meus erros, já que todos foram de alguma forma construtivos. Mesmo assim, deixo aqui relatadas as minhas experiências para os próximos aventureiros. Afinal, tolos insistem no erro, inteligentes aprendem com os próprios erros e sábios aprendem com os erros dos outros.