Olá, sou Andrey Kucherenko, líder da equipe de desenvolvimento móvel Skyeng. Criamos aplicativos móveis para iOS e Android. Eles têm a mesma funcionalidade e a mesma interface precisas para o estilo. Mas, devido a diferentes plataformas, o desenvolvimento de aparentemente um aplicativo é bastante caro. Em busca de oportunidades de economia no desenvolvimento de plataformas cruzadas para dispositivos móveis, tentamos quatro soluções:
- Combinando desenvolvedores iOS e Android em uma equipe
- Criação de grupos de trabalho para resolver problemas complexos
- Salvando na documentação
- Escrevendo código comum
Eu tive a oportunidade de fazer vários relatórios sobre o que aconteceu; Neste artigo, coletei as principais observações e resultados.
Combinando desenvolvedores iOS e Android em uma equipe
Há dois anos, tínhamos dois aplicativos móveis separados e duas equipes de desenvolvimento, conectadas apenas por um gerente de produto comum. Muitos problemas surgiram disso: os aplicativos uns dos outros se pareciam apenas remotamente, eles funcionavam de várias maneiras, os desenvolvedores não tinham idéia de como o aplicativo vizinho era organizado, eles regularmente obtinham todos os tipos de bugs e erros na lógica. A certa altura, ficou claro que isso não poderia ser continuado, e a primeira coisa que fizemos a esse respeito foi unir os desenvolvedores do iOS e Android em uma equipe de produto, tornando comuns vários processos.
Um desses processos se tornou uma revisão técnica.
Antes de chegar ao desenvolvedor, a tarefa segue um certo caminho. Para começar, ele é formulado no formato História do usuário, esboços ou layouts são desenhados, após o qual é iniciada uma epopéia na qual o problema do usuário e sua solução são descritos. Nesta forma, a história cai no líder da equipe, se for um épico entre equipes, ou no líder de uma equipe, se estiver no mesmo time. Lá tudo é decomposto ao nível das tarefas individuais. Em cada uma dessas tarefas, se apropriado, uma solução possível é descrita, as tarefas dentro da Epic se vinculam, vários bloqueadores são afixados, o que remove muitas comunicações desnecessárias. Depois disso, uma revisão técnica ocorre diretamente, na qual a decisão final será fixada e a estimativa será colocada. Também nesta fase, a tarefa pode ser decomposta ainda mais se a estimativa for obtida por mais de dois dias.
Como economizamos na revisão técnica conjunta:
- na maioria dos casos, é a mesma solução técnica para iOS e Android. Soluções diferentes também são possíveis, isso pode ser devido à arquitetura diferente das plataformas, mas no contexto da tarefa a diferença é geralmente mínima;
- sincroniza a arquitetura e a estrutura dos dois aplicativos. Isso elimina a situação quando o produto vem com outro recurso, e avaliamos a tarefa do iOS em duas horas e o Android na semana, porque tudo terá que ser reescrito lá;
- mais frequentemente do que não, obtemos uma boa nota. Se nossas avaliações para plataformas forem muito diferentes, isso pode indicar que os desenvolvedores não entenderam a tarefa ou alguns problemas de plataforma que precisam ser abordados;
- Com essa análise, ocorre uma troca de experiências entre os desenvolvedores iOS e Android, e acredito que eles devem ter uma ideia de como a plataforma vizinha funciona. Muitas vezes acontece que uma solução de uma plataforma é bem-sucedida para outra;
- simplificação de testes manuais. Os recursos são implementados com base em uma solução técnica, se o controle de qualidade encontrar algum erro, é uma ocasião para repetir as mesmas etapas em outra plataforma. Na maioria das vezes os mesmos erros também estão lá;
- soldados universais, capazes de escrever para as duas plataformas: se forem, você pode alterná-los entre projetos, o que aumenta o fator de ônibus e facilita a transferência de férias e ausências. Não há situações em que uma plataforma avança muito durante os feriados.
Fator de barramento: o número de pessoas na equipe que o barramento deve derrubar para que o projeto não possa continuar.
Grupos de trabalho para resolver problemas complexos
Para resolver um problema, muitas vezes, além de escrever diretamente o código, precisamos realizar algumas pesquisas, realizar o design e, se a tarefa envolver interação entre equipes, dedique muito tempo à comunicação. No contexto do desenvolvimento móvel, qualquer tarefa que não exija tudo isso é algo trivial, sem envolver trabalho do back-end. Eu os chamo de "simples" e todo o resto - de "complexo".
Analisei os logs de trabalho sobre a distribuição do tempo gasto na redação, comunicação, design e pesquisa de código. Aqui está o que acontece para tarefas simples:
Tudo está claro aqui, basicamente escrevemos o código, o custo dele é de até 80% do tempo.
Muitas vezes, as tarefas exigem algum tipo de refinamento do back-end, o que automaticamente o torna entre comandos. Aqui, mais tempo é gasto em design e comunicação. O compartilhamento da escrita de código é reduzido:
Geralmente, os produtos vêm com tarefas que não se encaixam bem na arquitetura atual do aplicativo e precisamos gastar tempo para encontrar uma boa solução: talvez planeje alguma refatoração, execute-a imediatamente como parte da tarefa, etc. Nesse caso, muito tempo é gasto no design:
Finalmente, as tarefas com as quais geralmente não está claro como abordar, onde você deve primeiro pesquisar e projetar:
Se o trabalho em tarefas complexas não puder ser coordenado de forma alguma, todo o trabalho não relacionado diretamente à escrita do código será realizado duas vezes. E em tarefas complexas, isso representa 50% do tempo da solução, geralmente ainda mais.
Eu encontrei uma saída: eu apenas peguei e tranquei todas essas tarefas em mim. Consegui economizar tempo, mas fiquei sobrecarregado constantemente, não tinha tempo suficiente para prestar atenção em tarefas de baixa prioridade, os desenvolvedores tiveram que esperar por mim, tudo estava ruim. O problema surgiu novamente e já o resolvemos criando grupos de trabalho.
O grupo de trabalho é formado por alguns desenvolvedores de iOS e Android que estarão diretamente envolvidos na implementação desse recurso. Um é apontado como líder, será ele quem é responsável pelo design, pesquisa e interação com outras equipes. O resultado do seu trabalho será documentação, onde tudo está consertado; essas docas são então revisadas pelo grupo de trabalho e pelo líder da equipe, e a equipe prossegue com a implementação.
Como resultado, recebemos:
- A carga no Timlid diminuiu, enquanto ele não perde o controle sobre o andamento da tarefa. Participo de todas as principais reuniões, reviso a solução técnica, realmente controle a tarefa antes que ela entre diretamente no desenvolvimento;
- os desenvolvedores estavam muito motivados. Quando testamos essa prática, todos vieram e disseram "legal, vamos tentar novamente". Não havia pessoas que não quisessem fazer isso e prefeririam "apenas codificar". As pessoas têm mais oportunidades de desenvolvimento;
- Com o fator ônibus aumentado, a equipe se tornou mais independente, além daqueles que podem ser desenvolvidos como líderes de equipe são claramente visíveis em tais tarefas. O problema de deixar Timlida de férias está sendo resolvido.
Economize na documentação
Decidimos manter a documentação no mercado e armazená-la no repositório do github. A documentação é revisada junto com o código e a solicitação pull, portanto, excluímos situações em que algo é escrito, mas ninguém lê e, quando necessário, ninguém entende nada. A documentação com um código permite que você mergulhe no contexto, para entender o que é o pull-rikvest.
Editamos a documentação diretamente do IDE, a maioria deles é capaz de reduzir a margem, não o impede de escrever código, você não precisa entrar em confluência em algum lugar, o risco é reduzido de que o desenvolvedor simplesmente esqueça de atualizá-lo. Para quem baixou o repositório localmente, lançamos links para o Github, eles também podem ler tudo.
Finalmente, esse estilo de encaixe ajuda na integração de um novo desenvolvedor: junto com o código, ele recebe todos os estilos de código possíveis, convenções, instruções de montagem de aplicativos e entrar na equipe é muito mais fácil.
Código comum
A idéia de escrever código comum não é a mais recente; existem várias ferramentas para fazer isso. Tentamos C ++ para escrever uma biblioteca de vocabulário e temos um pequeno aplicativo escrito inteiramente em Kotlin Multiplatform. Teoricamente, ao usar uma ferramenta de desenvolvimento de plataforma cruzada, nossos custos de escrita de código devem ser reduzidos pela metade. Mas outros aparecem:
custos de inicialização. Muito tempo será gasto na coleta, lançamento, teste, teste de hipóteses e treinamento de uma equipe. Em alguns casos, esses custos são tão grandes que o lucro não é visível;
escrever código de plataforma. Pela minha própria experiência e com base em várias fontes, posso dizer que, independentemente da ferramenta escolhida, se você tiver um aplicativo bastante complicado, mais cedo ou mais tarde precisará escrever o código da plataforma. O tempo para escrevê-lo varia muito, dependendo das ferramentas selecionadas;
eliminação de defeitos. A maioria das ferramentas ainda é bastante bruta, possui bugs, você terá que lidar com alguns lançamentos que quebram a compatibilidade com versões anteriores, e também levará algum tempo para corrigir tudo isso;
contornar restrições. As ferramentas de plataforma cruzada podem ter restrições de arquitetura ou outras restrições que você pode enfrentar e gastar tempo para contorná-las. Às vezes, essas restrições são tão severas que é preciso abandonar a ferramenta por completo. Por exemplo, o Airbnb abandonou o React Native e voltou ao desenvolvimento nativo;
A complexidade do desenvolvimento. Você precisa escrever o código para duas plataformas ao mesmo tempo, o que nem todo mundo sabe, além de comunicações adicionais aparecerão. A falta de IDEs nativos também não simplifica esse desenvolvimento.
Para comparar os custos dos métodos de desenvolvimento de plataforma cruzada que tentamos, identifiquei quatro grupos principais:
- despesas iniciais
- custos gerais de escrita de código
- custos de escrita de código da plataforma
- custos de infraestrutura (que não se aplicam aos três primeiros pontos)
Ele tomou uma ordem aleatória e comparou o tempo realmente gasto no desenvolvimento de plataforma cruzada e o tempo que supostamente gastaria no desenvolvimento nativo.
Cada coluna é uma tarefa. No caso do C ++, acabou sendo um começo bastante fácil, mas os custos de infraestrutura foram significativos, a economia total - apenas 29%. O C ++ também foi abandonado porque essa linguagem reduziu o fator de barramento: nossos desenvolvedores de dispositivos móveis não conhecem C ++, eles podem suportar o código, mas ninguém na equipe teve uma experiência séria.
Arranques muito altos, mas enquanto os custos de código e infraestrutura da plataforma são baixos. Não tínhamos o suficiente para uma boa análise do número de tarefas, na posição atual economizamos 19%. Supondo que faremos muitas tarefas e descartemos os custos de inicialização, obteremos cerca de 40% de economia, a menos que, é claro, quaisquer problemas sérios ocorram no futuro. Outra vantagem é que a maioria dos desenvolvedores está familiarizada com o Kotlin.
O menos é óbvio - a complexidade dos processos. Nós escrevemos para as duas plataformas ao mesmo tempo, mas nem todas podem, ou esperamos até que alguém escreva a parte geral, depois a revisamos, depois acontece que ela não se encaixa etc. etc. Temos que estabelecer custos extras para a fase de design, para que tudo seja resolvido imediatamente.
Total:
- Você pode e deve economizar nos processos de desenvolvimento móvel e na escrita de código. Processos adequadamente construídos ajudam não apenas a salvar, mas também a resolver várias tarefas adicionais.
- Ao escolher ferramentas para o desenvolvimento móvel entre plataformas, você precisa avaliar cuidadosamente os riscos e os custos reais de mão-de-obra.