Bonjour, je suis Andrey Kucherenko, chef d'équipe du développement mobile Skyeng. Nous créons des applications mobiles pour iOS et Android. Ils ont la même fonctionnalité et la même interface précise au style. Mais en raison de plates-formes différentes, le développement d'une application apparemment coûteuse est assez coûteux. À la recherche d'opportunités pour économiser sur le développement multiplateforme mobile, nous avons essayé quatre solutions:
- Combiner les développeurs iOS et Android en une seule équipe
- Création de groupes de travail pour résoudre des problèmes complexes
- Économiser sur la documentation
- Écrire du code commun
J'ai eu l'occasion de faire plusieurs rapports sur ce qui en est sorti; Dans cet article, j'ai rassemblé les principales observations et résultats.
Combiner les développeurs iOS et Android en une seule équipe
Il y a deux ans, nous avions deux applications mobiles distinctes et deux équipes de développement, connectées uniquement par un chef de produit commun. De nombreux problèmes sont nés de cela: les applications les unes des autres ne ressemblaient à l'extérieur que de manière distante, elles fonctionnaient de nombreuses façons, les développeurs n'avaient aucune idée de la façon dont l'application voisine était organisée, ils corrigeaient régulièrement toutes sortes de bugs et d'erreurs dans la logique. À un certain moment, il est devenu clair que cela ne pouvait pas se poursuivre, et la première chose que nous avons faite à cet égard a été de réunir les développeurs d'iOS et d'Android en une seule équipe de produits, ce qui rend un certain nombre de processus communs.
L'un de ces processus est devenu une revue technique.
Avant d'arriver au développeur, la tâche va dans un certain sens. Pour commencer, il est formulé au format User Story, des croquis ou des mises en page sont dessinés dessus, après quoi une épopée est lancée dans laquelle le problème de l'utilisateur et sa solution sont décrits. Sous cette forme, l'histoire tombe en tête d'équipe s'il s'agit d'une épopée inter-équipes ou en une seule équipe si elle appartient à la même équipe. Là, tout est décomposé au niveau des tâches individuelles. Dans chacune de ces tâches, le cas échéant, une solution possible est décrite, les tâches à l'intérieur d'Epic se lient les unes aux autres, divers bloqueurs sont apposés, ce qui supprime de nombreuses communications inutiles. Après cela, un examen technique a lieu directement, sur lequel la décision finale sera fixée et le devis sera mis. À ce stade également, la tâche peut être encore décomposée si l'estimation est obtenue pour plus de deux jours.
Comment nous économisons sur l'examen technique conjoint:
- dans la plupart des cas, il s'avère la même solution technique pour iOS et Android. Différentes solutions sont également possibles, cela peut être dû à l'architecture différente des plates-formes, mais dans le contexte de la tâche, la différence est le plus souvent minime;
- synchronise l'architecture et la structure des deux applications. Cela élimine la situation lorsque le produit est livré avec une autre fonctionnalité, et nous évaluons la tâche iOS à deux heures, et Android à la semaine, car tout devra y être réécrit;
- le plus souvent, nous obtenons une bonne note. Si nos évaluations des plates-formes sont très différentes, cela peut indiquer soit que les développeurs n'ont pas compris la tâche, soit certains problèmes de plate-forme qui doivent être résolus;
- Avec cette revue, un échange d'expérience a lieu entre les développeurs iOS et Android, et je pense qu'ils devraient avoir une idée du fonctionnement de la plateforme voisine. Il s'avère souvent qu'une solution d'une plate-forme réussit pour une autre;
- simplification des tests manuels. Les fonctionnalités sont implémentées sur la base d'une solution technique, si QA trouve des bugs, alors c'est l'occasion de répéter les mêmes étapes sur une autre plateforme. Le plus souvent, les mêmes bogues sont également présents;
- soldats universels, capables d'écrire pour les deux plates-formes: s'ils le sont, vous pouvez les basculer entre les projets, ce qui augmente le facteur de bus et facilite le transfert des vacances et des absences. Il n'y a aucune situation où une plate-forme est très en avance pendant les vacances.
Facteur de bus: le nombre de personnes dans l'équipe que le bus doit faire tomber pour que le projet ne puisse pas continuer.
Groupes de travail pour résoudre des problèmes complexes
Pour résoudre un problème, très souvent, en plus d'écrire directement le code, nous devons effectuer des recherches, effectuer la conception et si la tâche implique une interaction inter-équipes, consacrer beaucoup de temps à la communication. Dans le contexte du développement mobile, toutes les tâches qui ne nécessitent pas tout cela sont quelque chose de trivial, n'impliquant pas de travail depuis le backend. Je les appelle «simples» et tout le reste - «complexes».
J'ai analysé les journaux de travail concernant la répartition du temps consacré à la rédaction de code, à la communication, à la conception et à la recherche. Voici ce qui se passe pour les tâches simples:
Tout est clair ici, fondamentalement, nous écrivons le code, le coût est jusqu'à 80% du temps.
Très souvent, les tâches nécessitent une sorte de raffinement de la part du backend, ce qui en fait automatiquement des inter-commandes. Ici, plus de temps est consacré à la conception et à la communication. La part de l'écriture de code est réduite:
Souvent, les produits sont livrés avec des tâches qui ne correspondent pas bien à l'architecture actuelle de l'application, et nous devons consacrer du temps à trouver une bonne solution: peut-être planifier une sorte de refactoring, l'exécuter immédiatement dans le cadre de la tâche, etc. Dans ce cas, beaucoup de temps est consacré à la conception:
Enfin, les tâches avec lesquelles il n'est généralement pas clair comment aborder, où vous devez d'abord rechercher et concevoir:
Si le travail sur des tâches complexes ne peut être coordonné de quelque manière que ce soit, alors tout le travail non directement lié à l'écriture de code sera effectué deux fois. Et dans les tâches complexes, cela représente 50% du temps de résolution, souvent même plus.
J'ai trouvé un moyen de sortir: je viens de prendre et de verrouiller toutes ces tâches sur moi-même. J'ai réussi à gagner du temps, mais je suis devenu constamment surchargé, je n'ai pas eu assez de temps pour faire attention aux tâches peu prioritaires, les développeurs ont dû m'attendre, tout était mauvais. Le problème est revenu et nous l'avons déjà résolu en créant des groupes de travail.
Le groupe de travail est composé de quelques développeurs iOS et Android qui seront directement impliqués dans la mise en œuvre de cette fonctionnalité. L'un est désigné comme leader, ce sera lui qui sera responsable de la conception, de la recherche, de l'interaction avec les autres équipes. Le résultat de son travail sera la documentation, où tout est fixé; ces quais sont ensuite examinés par le groupe de travail et le chef d'équipe, et l'équipe procède à la mise en œuvre.
En conséquence, nous avons reçu:
- La charge sur le Timlid a diminué, alors qu'il ne perd pas le contrôle de l'avancement de la tâche. Je participe à toutes les réunions clés, je passe en revue la solution technique, je contrôle réellement la tâche avant qu'elle n'entre directement dans le développement;
- les développeurs étaient très motivés. Lorsque nous avons testé cette pratique, tout le monde est venu et a dit "cool, réessayons." Il n'y avait personne qui ne voudrait pas faire cela et préférerait «juste le codage». Les gens ont plus d'opportunités de développement;
- le facteur bus a augmenté, l'équipe est devenue plus indépendante, et ceux qui peuvent être développés en chefs d'équipe sont clairement visibles sur ces tâches. Le problème de quitter Timlida en vacances est en train d'être résolu.
Économisez sur la documentation
Nous avons décidé de conserver la documentation sur le marché et de la stocker dans le référentiel github. La documentation est révisée avec le code et la demande de tirage, ainsi nous excluons les situations où quelque chose est écrit, mais personne ne l'a lu, et quand c'était nécessaire, personne ne comprend rien. La documentation avec un code vous permet de plonger dans le contexte, de comprendre en quoi consiste pull-rikvest.
Nous éditons la documentation directement depuis l'EDI, la plupart d'entre eux sont capables de rendre le démarque, cela ne vous empêche pas d'écrire du code, vous n'avez pas à entrer en confluence quelque part, le risque est réduit que le développeur oublie simplement de le mettre à jour. Pour ceux qui ont téléchargé le référentiel localement, nous jetons des liens vers Github, ils peuvent également tout lire.
Enfin, ce style d'ancrage aide à l'intégration d'un nouveau développeur: avec le code, il reçoit tous les styles de code possibles, les conventions, les instructions d'assemblage d'application, et entrer dans l'équipe est beaucoup plus facile.
Code commun
L'idée d'écrire du code commun n'est pas la plus récente; il existe un tas d'outils pour le faire. Nous avons essayé C ++ pour écrire une bibliothèque de vocabulaire, et nous avons une petite application entièrement écrite en Kotlin Multiplatform. Théoriquement, lorsque vous utilisez un outil de développement multiplateforme, nos coûts d'écriture de code devraient être divisés par deux. Mais d'autres apparaissent:
frais de démarrage. Il faudra consacrer beaucoup de temps à la collecte, au lancement, aux tests, aux tests d'hypothèses et à la formation d'une équipe. Dans certains cas, ces coûts sont si importants que le profit n'est pas visible du tout;
écrire du code de plate-forme. D'après ma propre expérience et sur la base d'un certain nombre de sources, je peux dire que peu importe l'outil que vous choisissez, si vous avez une application assez compliquée, vous devrez tôt ou tard écrire du code de plateforme. Le temps de l'écrire varie considérablement en fonction des outils sélectionnés;
élimination des défauts. La plupart des outils sont encore assez bruts, ils ont des bogues, vous devrez faire face à certaines versions qui cassent la compatibilité descendante, et cela prendra un certain temps pour corriger tout cela aussi;
contournement des restrictions. Les outils multiplateformes peuvent avoir des restrictions architecturales ou d'autres restrictions que vous pouvez rencontrer et passer du temps à les contourner. Parfois, ces restrictions s'avèrent si sévères qu'il faut abandonner complètement l'outil. Par exemple, Airbnb a abandonné React Native et est revenu au développement natif;
La complexité du développement. Vous devez soit écrire du code pour deux plates-formes à la fois, ce que tout le monde ne sait pas, plus des communications supplémentaires apparaîtront. L'absence d'IDE natifs ne simplifie pas non plus ce développement.
Pour comparer les coûts des méthodes de développement multiplateforme que nous avons essayées, j'ai identifié quatre groupes principaux:
- frais de départ
- frais généraux d'écriture de code
- coûts d'écriture de code de plateforme
- les coûts d'infrastructure (qui ne s'appliquent pas aux trois premiers points)
Il a pris un remaniement et a comparé le temps réellement consacré au développement multiplateforme et le temps que nous consacrerions censément au développement natif.
Chaque colonne est une tâche. Dans le cas du C ++, cela s'est avéré être un début assez facile, mais les coûts d'infrastructure se sont avérés importants, les économies totales - seulement 29%. Le C ++ a également été abandonné car ce langage a réduit le facteur bus: nos développeurs mobiles ne connaissent pas le C ++, ils peuvent supporter le code, mais personne dans l'équipe n'avait une expérience sérieuse.
Démarrages très élevés, mais alors que les coûts du code de la plate-forme et de l'infrastructure sont faibles. Nous n'avions pas assez pour une bonne analyse du nombre de tâches, au poste actuel économisé 19%. En supposant que nous ferons beaucoup de tâches et éliminerons les coûts de démarrage, nous obtiendrons environ 40% d'économies, à moins, bien sûr, que de graves problèmes ne surviennent à l'avenir. Un autre avantage est que la plupart des développeurs connaissent Kotlin.
Le moins est évident - la complexité des processus. Soit nous écrivons pour les deux plates-formes à la fois, mais pas toutes, soit nous attendons que quelqu'un écrive la partie générale, puis nous la révisons, puis il s'avère qu'elle ne correspond pas, etc. etc. Nous devons prévoir des coûts supplémentaires pour la phase de conception, afin que tout soit probablement terminé immédiatement.
Total:
- Vous pouvez et devez économiser sur les processus de développement mobile et l'écriture de code. Des processus correctement construits permettent non seulement d'économiser, mais également de résoudre un certain nombre de tâches supplémentaires.
- Lorsque vous choisissez des outils pour le développement mobile multiplateforme, vous devez évaluer soigneusement les risques et les coûts de main-d'œuvre réels.