Jera | Design e desenvolvimento de apps para dispositivos móveis

Retropg: Uma retrospectiva Scrum utilizando RPG

Um app antigo em sua quarta versão, com um time extremamente focado (e cansado haha) a retro final do projeto precisava ser algo divertido e que criasse um ambiente seguro para que todos pudessem falar livremente e fechar esse ciclo.

Um grande desafio surgiu: qual estrutura usar na retro? nós, facilitadores, temos dinâmicas para os mais variados contextos mas, para essa em especifico, parecia tudo muito mais do mesmo. Tinha que ser algo diferente que realmente engajasse o time (que fez um trabalho excepcional ❤).

Comecei a pensar no perfil de cada um, o que ouviam, o que liam, o que faziam no tempo livre e essa atividade foi uma grande descoberta pra mim. Lembrei que os meninos sempre almoçavam rápido para jogar RPG e.. wtfff o que é RPG? hahaha

Role-playing game, também conhecido como RPG, é um tipo de jogo em que os jogadores assumem papéis de personagens e criam narrativas colaborativamente. O progresso de um jogo se dá de acordo com um sistema de regras predeterminado, dentro das quais os jogadores podem improvisar livremente.

Depois de ler essa breve descrição fiquei extremamente entusiasmada: achei a estrutura perfeita para fazer a retro final do projeto. Sabia que o desafio seria grande então convidei o tester do projeto para me ajudar a estruturar. Se você nunca contou com um membro do time para te ajudar a planejar a retro, experimente o/ é uma experiência muito enriquecedora!

O app é uma agtech que facilita o dia-a-dia do produtor rural através de ferramentas para o manejo, gestão e proteção da lavoura. Partindo deste contexto a história começou a ganhar forma..

Era uma vez em uma terra muito, muito distante em uma vila de camponeses que plantavam soja e não tinham um agrônomo pra ajudar. Surgiu um grande mago que concedeu um artefato mágico (o app) para ajudar os camponeses

Os camponeses eram muito felizes usando o artefato mágico e isso gerou muita inveja da vizinhança que enviou um demogorgon para atacar a vila

Então, 7 bravos guerreiros deveriam lutar para salvar as terras e proteger o artefato mágico:

Cada membro do time era um personagem de RPG e tinha um poder (dano ou cura):

Conforme a história se desenrolava e o dado girava, o time deveria fazer uma das 8 ações:

Para o texto não ficar muito extenso, vocês podem conferir os slides aqui 😉

O resultado? a retro mais divertida que já facilitei hahah todos, sem exceção, falaram de forma transparente e conseguimos várias feedbacks para o crescimento do time e de cada um.

O recado que quero deixar é: passamos a maior parte do tempo no trabalho e, muitas vezes, não nos conhecemos o suficiente para extrair o melhor de cada um. Antes de organizar uma retro, reflitam profundamente sobre o time e como o melhor ambiente pode ser criado, ousem e não tenham medo de arriscar algo novo.

Texto por: Maria Fernanda Marcotti

Teste de usabilidade. O que é e como funciona?

Há algum tempo temos usado na Jera princípios e práticas de User eXperience.

Uma delas é o teste de usabilidade que tem por objetivos observar o uso de um produto e investigar questões que envolvem navegação e entendimento da interface.

Mas o que é exatamente o Teste de Usabilidade?

O teste de usabilidade é um método de avaliação da compreensão de uso de uma plataforma pelo usuário real, mas sem a necessidade de um produto finalizado, geralmente é feita com protótipos mais simples e rápidos, que podem ser descartados com menos custo de desenvolvimento.

O teste mais comum é uma avaliação com 5 usuários, onde eles recebem uma série de tarefas para serem executadas, como fazer cadastro, ou fazer uma compra online, qualquer coisa que sirva para validar as principais funções de um app. Ele é baseado nas teorias de Nielsen sobre usabilidade e testes com usuários, a amostragem de 5 pessoas tem uma porcentagem de credibilidade muito alta, e mesmo com 100 pessoas, o nível das respostas teria uma pequena variação.

Para que serve?

O teste serve primeiro para evitar retrabalho, já que um protótipo é facilmente ajustado, e um produto final tem mais trabalho e mais custo em alterações, mesmo que simples. Seus resultados são usados para correções que facilitem a navegação do usuário, projetar melhorias e funcionalidades futuras, ou até descartar funcionalidades que atrapalhem o uso.

Um teste de usabilidade ajuda a diminuir custos e focar esforços no que os usuários têm mais necessidade, com o foco no maior sucesso dos clientes e na interação deles com a plataforma.

Jornada do teste

O teste tem uma série de etapas para um resultado mais eficaz. Não necessariamente todas precisam ser feitas para um teste bem acabado, mas por padrão elas ajudam a ter respostas mais precisas. Vamos usar de exemplo um app para ver os horários e datas de jogos de futebol.

Personas

As personas são levantadas no primeiro momento do projeto, antes de ter um layout pronto, e são uma representação do nosso público alvo. No nosso exemplo seriam pessoas que acompanham constantemente jogos de futebol, torcem para algum time e sempre estão se programando para evitar passeios de família na hora do seu jogo favorito. Assim podemos entender quais são os problemas deles, e como o app vai interagir com esse mundo já estabelecido pelo usuário.

Planejamento

Já conhecendo nossos usuários, começamos a planejar o teste, sobre como recrutamos essas pessoas, quais funcionalidades serão testadas, e entender o que agrega mais valor ao nosso usuário. Aqui definimos todos esses passos e montamos um roteiro para o momento dos testes e deixamos pronto o nosso guia para montar o layout dos testes.

Recrutamento

Depois de entender o nosso público geral, precisamos filtrar um pouco as pessoas para o teste, quem seria melhor para a plataforma, um torcedor de algum time específico? Alguém que pratica o esporte regularmente mas não acompanha aos jogos se encaixa no nosso foco? Para entendermos se as pessoas atendem o nosso critério, montamos um questionário que ajuda a filtrar essas questões importantes para um público final mais alinhado às nossas expectativas.

Protótipo

Aqui vamos montar um app como um cenário de filme, parece de verdade, mas não é. O protótipo serve para analisar o fluxo dos usuários e como eles entendem as funções, não necessariamente precisamos fazer ele salvar as informações que o usuário preencher no cadastro, ou mostrar uma lista completa com todos os times de futebol do mundo no filtro, ele tem que dar uma sensação de que funciona, mesmo sem realmente ter uma programação por trás. E aqui fazemos todo o fluxo que foi planejado lá atrás para garantir que não seria esquecido algo importante.

Teste

Aqui iremos trazer nossos usuários para usar o protótipo, vamos ver como eles fazem essa navegação, se eles ficam confusos em algum momento, ou fazem um fluxo diferente do esperado, e conversamos, para entender as dúvidas, as expectativas, como ele procura esses horários de jogos hoje, por algum portal de esportes, pesquisando na internet, pelo jornal, ou qualquer outra coisa que solucione isso. Guardamos então todas essas informações organizadas para entender onde houve problemas, possíveis funcionalidades para um futuro ou até mesmo coisas que precisam ser removidas.

Análise de dados

Após realizar os testes e anotar os resultados dos 5 usuários, vamos olhar os pontos de maior atenção, para ver se em algum momento o fluxo está complexo demais ou não. Se a pessoa não conseguiu entender o filtro por times, se ela clicou no perfil achando que iria encontrar o calendário, ou qualquer outra coisa que precise de uma alteração.

Ações de melhoria

Depois de entender todos os pontos que não funcionaram como esperávamos, vamos propor as ações de melhoria, como trocar os ícones de perfil, colocar textos explicando alguma tela, e deletar a tela de filtro por torneios que ninguém usou. Aqui podemos recomeçar o processo, e testar novamente com outras pessoas para entender se nossas soluções foram viáveis, ou deixar para a validação do produto final. O importante é que aqui vamos garantir que alguns erros críticos foram corrigidos antes de frustrar os usuários.

Conclusões finais

O teste é indicado para validar qualquer plataforma antes de um gasto de desenvolvimento alto, testes ajudam a economizar esforço no desenvolvimento e dinheiro com a refatoração de algum fluxo. Protótipos são feitos pensando em ser descartados, então é o momento ideal para encontrarmos falhas críticas que possam atrapalhar usuários reais quando a plataforma estiver em ação.

Aprenda como utilizar o ContentProvider corretamente

Vocês já pararam para pensar qual é a primeira coisa que nós temos que fazer após importarmos uma lib? Inicializá-la com contexto em uma classe Application. Se você já precisou utilizar alguma lib do Firebase, você vai se perguntar: Opa, eu nunca tive que fazer isso.

Vamos para nosso estudo de caso.

Estudo de caso

Atualmente, estamos desenvolvendo um aplicativo que utiliza Koin, Stetho e PreferenceCache. Até algumas semanas tínhamos uma classe chamada AppTemplateApplication que era responsável por inicializar nossas libs e era dessa forma

class AppTemplateApplication : Application() {

    override fun onCreate() {
        super.onCreate()
        PreferencesCache.init(this)
        if(BuildConfig.DEBUG) Stetho.initializeWithDefaults(this)
        startKoin(this, appTemplateModules)
    }
}

E essa classe precisa ser declarada em nosso AndroidManifest.xml para ser executada:

<application
    android:name=".AppTemplateApplication"
   ...
>

Imagine se fossemos adicionando mais libs ao longo da execução do projeto… Teríamos que adicionar cada inicialização em nossa AppTemplateApplication. Ou seja, em nosso projeto teríamos que sobrescrever uma Application() somente para inicializar libs.

Uma bazooka para resolver um problema 🙂

Manifest-Merger

De acordo com a documentação do android:

Seu arquivo APK pode conter apenas um arquivo AndroidManifest.xml, mas o projeto do Android Studio pode conter vários - fornecidos pelo main source set, built variants e libs importadas. Portanto, ao criar seu aplicativo, a compilação do Gradle mescla todos os arquivos de manifesto em um único arquivo de manifesto que é empacotado no seu APK.
A ferramenta de merge combina todos os elementos XML de cada arquivo, seguindo algumas heurísticas de merge e obedecendo às preferências de merge que você definiu.

E o porque estamos falando de Manifest-Merger? Se dermos uma olhada em nosso AndroidManifest, iremos descobrir como algumas libs conseguem fazer sua inicialização sem a interferência do programador que irá utilizá-la…

Em nosso Estudo de caso iremos investigar como o Firebase faz essa magia. No final do nosso AndroidManifest após o processo de merge, podemos ver o import de um provider

<provider
  android:name="com.google.firebase.provider.FirebaseInitProvider"
  android:authorities="APPTEMPLATE.firebaseinitprovider"
  android:exported="false"
  android:initOrder="100" />

Se investigarmos a classe FirebaseInitProvider poderemos ver que esse provider tem acesso ao contexto da aplicação usando this.getContext()

public boolean onCreate() {
    if (FirebaseApp.initializeApp(this.getContext()) == null) {
        Log.i("FirebaseInitProvider", "FirebaseApp initialization unsuccessful");
    } else {
        Log.i("FirebaseInitProvider", "FirebaseApp initialization successful");
    }
    return false;
}

Mas se analisarmos essa classe poderemos ver que o fato dela extender a ContentProvider a obriga implementar os métodos insert, query, onCreate, update, delete, getType.

DefaultProvider

Como vimos, a necessidade de implementar todos os métodos citados acaba tornando nosso Provider longo… Para mitigarmos esse problema, utilizaremos um DefaultProvider, uma open class.

open class DefaultProvider : ContentProvider() {

    override fun insert(uri: Uri?, values: ContentValues?): Uri { TODO("not implemented") }

    override fun query(uri: Uri?, projection: Array<out String>?, selection: String?, selectionArgs: Array<out String>?, sortOrder: String?): Cursor { TODO("not implemented") }

    override fun onCreate(): Boolean { TODO("not implemented") }

    override fun update(uri: Uri?, values: ContentValues?, selection: String?, selectionArgs: Array<out String>?): Int {TODO("not implemented")}

    override fun delete(uri: Uri?, selection: String?, selectionArgs: Array<out String>?): Int { TODO("not implemented")}

    override fun getType(uri: Uri?): String { TODO("not implemented") }
}

A partir disso, iremos fazer com que nosso provider estenda-o.

KoinProvider, StethoProvider, CacheProvider

Diante do exposto, iremos construir nossos providers.

class KoinInitProvider : DefaultProvider() {
    override fun onCreate(): Boolean {
        context?.let { startKoin(it, appTemplateModules) }
        return true
    }
}

class PreferenceCacheInitProvider : DefaultProvider() {
    override fun onCreate(): Boolean {
        context?.let { PreferencesCache.init(it) }
        return true
    }
}

class StethoInitProvider : DefaultProvider() {
override fun onCreate(): Boolean {
        if (BuildConfig.DEBUG) context?.let {     Stetho.initializeWithDefaults(it) }
        return true
    }
}

e em nosso AndroidManifest.xml

<provider
 android:name=".provider.koin.KoinInitProvider"
 android:authorities=".provider.koin.KoinInitProvider" />

<provider
 android:name=".provider.cache.PreferenceCacheInitProvider"
 android:authorities=".provider.cache.PreferenceCacheInitProvider" />

<provider
 android:name=".provider.stetho.StethoInitProvider"
 android:authorities="com.facebook.stetho.StethoInitProvider" />

Conclusão

Bom, com a utilização do ContentProvider podemos eliminar a nossa classe AppTemplateApplication.class e utilizar um recurso do Android para inicializarmos as libs que o projeto utiliza.
Além da retirada da AppTemplateApplication, notamos que todos os providers utilizam o null safety do Kotlin para atribuir o contexto a inicialização das libs.

Esse artigo surgiu de um papo de dois devs paixão, valeu Matheus Kreuz Bristot pelo café e por essa abstração show.

Ps: Quer trocar uma ideia sobre o artigo ou sobre desenvolvimento mobile? Deixa um comentário show, que vai ser um prazer responde-lo.

Texto por: Caíque Minhare e Matheus Bristot

Dinâmica É, Não É, Faz, Não Faz

Recentemente fiz o workshop de Lean Inception do Paulo Caroli durante a semana ágil do Scrum Gathering Rio.
Durante o workshop nos são apresentadas várias ferramentas para facilitar o processo da lean inception.
Na Jera já fazemos o uso dessas ferramentas, uma delas é o: É, NÃO É, FAZ, NÃO FAZ, que foi criado pelo Rafael Sabbagh da K21. Nesse vídeo há uma explicação mais detalhada.

Nas vezes em que facilitei o uso dessa ferramenta, seja pra ajudar um time a identificar seu papel ou para definir um produto, percebi que algumas pessoas ficavam com dificuldade em diferenciar o que algo É e o que algo FAZ.
Pensando em ajudar no entendimento, percebi que o que É e NÃO É, poderia ser associado com o uso de substantivos. No caso de definição de um produto, poderíamos dizer por exemplo que ele É um: aplicativo, seguro, local, etc; Para o preenchimento do FAZ e NÃO FAZ, fiz a sugestão de preencher pensando em verbos, pois expressariam uma ação ao qual o produto irá realizar, por exemplo: cadastrar usuário, filtrar um resultado, buscar.
Essas analogias facilitaram o entendimento da dinâmica, pois as pessoas começaram a ver de fato uma diferenciação ao preencher o quadro.
Nesse dia do workshop, sugeri as pessoas que pensassem no preenchimento do quadro usando essas associações, e foi muito bom o resultado, pois facilitou a aplicação da dinâmica.
Encorajada pela Mayra, resolvi compartilhar via esse post como eu faço.

E aí? Como vocês rodam essa dinâmica?

Meus primeiros meses trabalhando como desenvolvedora na Jera

Texto por Larissa Marães

Quando iniciei a minha graduação em Engenharia de Computação, eu não tinha muitas expectativas profissionais e muito menos conhecia as empresas de tecnologia da capital. Até que me ingressei em um curso técnico que me trouxe uma visão do mercado de TI. Neste curso, tive a oportunidade de visitar algumas empresas, e uma delas foi a Jera. Foi amor à primeira vista. Desde então, a Jera se tornou uma das empresas em que sempre sonhei em trabalhar.

E então, em um momento perfeito da minha vida pessoal e acadêmica, encontro uma divulgação de vaga de estágio em desenvolvimento na Jera, na qual logo me inscrevi. Foram 4 etapas de processo seletivo, onde em cada uma eu me identificava cada vez mais com a empresa. Em uma das etapas, me enviaram um link onde continha o Culture Code da Jera e nele são apresentados os valores da empresa. Amor ao trabalho, foco no cliente, diálogo aberto, melhoria contínua e valorizar realizações… Ler essas palavras bonitas me pareceu encantador, mas no fundo, eu não tinha idéia de como isso funcionava.

No dia 16 de junho de 2018, iniciou-se a minha jornada na taberna. E com a mentalidade de qualquer noob, eu achava que seria moleza desenvolver software (Sabe de nada, inocente!). Logo no primeiro dia apareceram os desafios. No meio de toda apresentação aos processos da empresa, foi necessário estudar bastante e tomar muitos cafezinhos para entender a fundo como o processo de desenvolvimento de software funciona lá dentro.

Diante dos times de desenvolvimento Web, Android e iOS, eu tinha quase certeza que iria atuar em desenvolvimento Web, pois já tive experiências nessa área, além do curso técnico que fiz. Mas para a minha surpresa, fui alocada no time Android!! O sentimento de desespero tomou conta ao perceber que estava fora da minha zona de conforto. E por conta disso, me empenhei o máximo e estudei sem parar para conseguir realizar minhas entregas. E quando eu achava que já tinha aprendido o suficiente, novos desafios surgiram e eu voltava a me empenhar e estudar. Em poucas semanas aprendi coisas que eu demoraria anos para aprender na faculdade. Em tão pouco tempo me senti estimulada a entender mais essa nova área e me tornar uma desenvolvedora tão boa quantos os desenvolvedores de lá. É melhoria contínua o nome disso, né?

Como me sinto estudando e percebendo que estou melhor do que ontem.

Mas nada como o primeiro app… Primeiro projeto dentro da Jera. Ainda estava aprendendo e me adaptando à todos os processos. “Não tenham medo de errar”, eles disseram. E foi o que eu fiz. Errei MUITO! Como era nova na equipe, pensei que seria tratada como uma mera novata. E por conta disso, eu tinha vergonha (até mesmo medo) de expressar as minhas dificuldades e pedir ajuda. Com isso, aprendi da forma mais dura a importância do diálogo aberto, pois sem ele tive uma semana difícil e falhei na entrega de algumas tarefas, além de prejudicar a minha equipe. Depois disso, passei a explorar mais o diálogo aberto no meu dia-a-dia, buscando entender e expressar ideias. E com isso, criar debates construtivos para solucionar problemas.

Diferente de qualquer trabalho de faculdade, eu não estava fazendo aquilo por uma nota ou aprovação em uma disciplina. Afinal, o que eu estava desenvolvendo fazia parte de algo maior, um produto que tinha investimento de uma pessoa que acreditava na sua ideia. Demorou um tempo para eu perceber isso. E quando percebi, comecei a desenvolver aquilo como se fosse meu produto também. E o resultado disso é incrível! Pois você se sente engajado com o projeto e o time, realiza entregas de qualidade, e melhor ainda, a satisfação do cliente. #FocoNoCliente

Na Jera trabalhamos duro, mas quando comemoramos, é pra valer também! Além das reuniões diárias com o time, temos toda sexta uma retrospectiva (chamada carinhosamente de retrô) onde nos reunimos para discutir os pontos a serem melhorados e as coisas boas que aconteceram na semana. Aah… Como eu amo as retrôs! É o momento que temos para juntos fazermos barulho e comemorarmos as pequenas conquistas da semana. E então eu entendi como é bom valorizar realizações. E não apenas as suas, mas as dos outros colegas de trabalho também.

E diante de todos os valores citados, o amor ao trabalho é o meu favorito. Pois quando eu acho que finalmente entendo o que é amar o trabalho, cada dia que passa eu me surpreendo e amo cada dia mais o que faço. E não só isso, é amar o que faz e amar fazer. E na Jera, com esse ambiente de trabalho maravilhoso, fica cada dia maior o amor que sinto pelo desenvolvimento de software e por essa empresa linda que mal conheço e já considero pakas! <3