En prévision d'AppsConf 2018, nous avons interviewé des spécialistes de grandes entreprises sur les caractéristiques et les processus distinctifs des grandes équipes impliquées dans le développement d'applications mobiles. Quelles approches du travail sont utilisées, quels pièges attendent les rameurs arrivant dans une immense cuisine. Si l'origine étrangère de l'entreprise laisse une empreinte sur les processus de travail - lisez tout à ce sujet sous la coupe.
Philip Uvarov, développeur Android chez Spotify. La société travaille depuis six mois - dans l'une des équipes de plate-forme qui soutiennent les autres développeurs de Spotify. Vit en Suède. Avant Spotify, il a travaillé dans une startup suédoise, et même plus tôt chez Avito.
Artyom Olkov, développeur IOS principal chez Odnoklassniki. Il dirige actuellement le développement iOS de l'un des produits. En plus du développement lui-même, il est responsable de l'architecture, de la conception, de la distribution des tâches, de la coordination avec la conception, des API backend, etc. Au total, Odnoklassniki compte désormais une soixantaine d'ingénieurs mobiles répartis en équipes plus petites. L'équipe d'Artem - 11 personnes.
Maxim Efimov, ingénieur logiciel senior chez Uber. Il travaille dans l'entreprise depuis deux ans, il est engagé dans le développement Android. Il fait partie de l'équipe de paiement des coureurs, qui traite tout ce qui concerne les paiements dans l'application passager Uber. Avant cela, il a développé pour Android dans d'autres entreprises - principalement sur commande, et même plus tôt - il a écrit en C ++ (solutions serveur pour systèmes SCADA). À Uber, dans le cadre du service de paiement, il existe plusieurs équipes similaires pour d'autres applications, ainsi que des équipes d'infrastructure - un total de plusieurs dizaines d'équipes.
Evgeny Suvorov, responsable du développement des unités mobiles chez Avito: il développe des applications mobiles depuis environ huit ans. J'ai essayé des jeux, en freelance, travaillé dans des sociétés d'externalisation, dans une grande entreprise, après quoi je suis passé au développement de produits.
Commençons par les fonctionnalités. Quelle est la différence entre le travail des équipes avec une grande équipe de développeurs dans l'entreprise?Artem Olkov (Odnoklassniki): À mon avis, les particularités ne sont pas liées à l'échelle de l'entreprise, mais à la façon dont les processus sont organisés à l'intérieur de celle-ci et au rôle que l'équipe joue dans ces processus. En gros, si votre équipe crée la plate-forme mobile sur laquelle sont basées les autres applications ou services de l'entreprise, 1000 demandes de différents coins lui parviendront et sans un bon chef de produit, le développement se noiera. Si l'équipe propose un service autonome sans intégrations complexes, le processus sera beaucoup plus simple.
Maxim Efimov (Uber): À mon avis, la caractéristique la plus caractéristique est la vitesse de travail.
Les petites équipes travaillent en principe beaucoup plus rapidement. Mais en même temps, les grandes équipes ont un produit brut final du développeur, bien sûr, car tout un groupe de personnes est engagé dans environ la même chose. Et de là découle une vision différente de la manière dont les projets sont généralement mis en œuvre.
Dans les petites entreprises, nous nous adaptons souvent en termes, conditionnellement, jusqu'à un jour ou jusqu'à une semaine. Nous pouvons tout calculer et planifier à l'avance. Dans les grandes équipes, c'est difficile à faire, car tout est lié à un grand nombre de personnes. Par conséquent, l'approche de planification est quelque peu différente. Les projets sont réalisés avec certaines tolérances en termes de temps, et la qualité et les fonctionnalités que nous créons sont primordiales. Et ce n'est qu'après cela qu'il faut s'inscrire dans les délais.
Autre point intéressant: comment les équipes s'entendent. Si cinq à dix personnes travaillent sur le projet, elles peuvent être facilement assemblées dans la salle de réunion et, après avoir passé deux à trois heures, résoudre tous les problèmes. Et vous pouvez aller plus loin pour faire le projet. Mais lorsque des centaines de personnes sont impliquées dans le projet, cela ne fonctionnera pas. Chez Uber, nous avons certains mécanismes de communication qui permettent aux équipes de ne pas interférer entre elles, de s'intégrer efficacement, etc. Dans les petites entreprises, tout cela, en principe, n'existe pas.
Philip Uvarov (Spotify) : Je pense que la principale caractéristique est que je ne connais pas tous les développeurs Android en personne. Et nous avons également des responsabilités très partagées. Cela vous permet d'être toujours dans le contexte de ce que vous faites, et assez rapidement pour livrer des produits dans votre direction.
Comment votre équipe se synchronise-t-elle avec les autres membres de l'entreprise?Evgeny Suvorov (Avito): Nos équipes sont connectées par une seule application mobile - Avito. Tous contribuent à ce produit, c'est-à -dire au point de synchronisation de notre base de code et de nos fonctionnalités.
Philip Uvarov (Spotify) : Nous avons des équipes interfonctionnelles qui traitent de problèmes spécifiques (par exemple, comment nous développons des analyses pour les clients mobiles) sont combinées en un seul grand département - nous l'appelons «tribu» (tribu). En règle générale, les équipes d'une même tribu sont assez étroitement interconnectées, elles ont un échange d'expérience actif. De plus, bien sûr, nous avons des clients - ce sont d'autres développeurs, nous soutenons donc les solutions que nous créons pour eux.
Maxim Efimov (Uber) : Nous avons de petites équipes, chacune ne comptant pas plus de 20 personnes. Ils sont unis dans des unités structurelles qui sont responsables de vastes zones, par exemple, une application mobile. Dans le même temps, les équipes elles-mêmes sont assez autonomes, car si nous réduisons tout à un seul système de contrôle avec subordination directe, nous obtiendrons un système très inefficace.
L'idée générale du produit est transmise aux équipes individuelles par le biais des chefs de produit ou des propriétaires. Il existe une structure distincte qui rassemble ces personnes et aide à mieux comprendre comment et où nous allons. À un niveau supérieur, des objectifs stratégiques tels que la protection de la sécurité des passagers peuvent être définis. Eh bien, les détails sont résolus un à deux niveaux ci-dessous. Par exemple, nous avons certains mécanismes de sécurité dans les pays où les gens utilisent principalement l'argent comptant pour payer.
Artem Olkov (Odnoklassniki): Nous sommes engagés dans un service distinct. Disons donc que nous sommes une startup au sein d'une grande entreprise. Bien sûr, nous vivons dans la même infrastructure. Et dans tout le reste, nous sommes très séparés. Même dans le cadre de l'intégration, nous utilisons souvent l'API publique de nos propres outils.
Y a-t-il des problèmes typiques des grandes équipes? À quoi devez-vous faire face?Evgeny Suvorov (Avito) : À mon avis, les processus d'une grande équipe sont principalement affectés.
Tous les gars, en règle générale, sont expérimentés, même les juniors sont capables de résoudre des problèmes techniques. Mais les problèmes de processus peuvent facilement ralentir tout le monde, il est donc préférable d'automatiser les processus.
Et cela signifie une intégration continue de haute qualité, une livraison continue, une automatisation des tests.
Philip Uvarov (Spotify) : Je pense que le plus gros problème est la diffusion des connaissances au sein de l'entreprise. Je n'ai peut-être aucune idée de ce qui se passe dans certaines équipes éloignées. Et il en va de même dans la direction opposée: de nombreuses équipes ne savent pas que nous avons une équipe d'analyse chez Spotify. C'est là que l'échelle se fait sentir.
Le deuxième point est la rapidité de prise de décisions innovantes: adaptation du même Kotlin et d'autres nouvelles technologies. C’est une chose de venir dire à cinq développeurs: «A partir d’aujourd’hui, nous écrivons sur Kotlin», mais c’est une autre chose de le dire à 100 développeurs. Il y a une énorme infrastructure qui doit être traduite, pour soutenir en quelque sorte ces innovations (CI, etc.).
Artem Olkov (Odnoklassniki): Oui, il y a vraiment deux problèmes: le transfert de connaissances et la coordination des actions, y compris la modernisation.
Les grandes entreprises disposent-elles de moyens éprouvés pour résoudre ces problèmes?Philip Uvarov (Spotify) : Pour résoudre le premier problème - le partage des connaissances - nous avons une chose telle que les guildes. Il s'agit d'un groupe de développeurs par fonction, par exemple, la guilde Android, qui organise toutes les deux semaines des événements: présentations, déjeuners, où vous pouvez discuter de problèmes urgents ou partager quelque chose, etc. Nous avons aussi, encore une fois, des guildes ont lieu des conférences internes. De plus, il y a des listes de diffusion, etc. Un problème humain simple demeure: il est difficile de suivre tout cela.
Je voudrais souligner la formation interne (formation avancée) en tant que ligne distincte. Nous avons notre propre Data University, où vous pouvez apprendre à devenir ingénieur de données. Maintenant, mes collègues envisagent de créer le même schéma pour l'apprentissage mobile.
Artem Olkov (camarades de classe): Nous n'avons pas de guildes prononcées.
D'une manière ou d'une autre, les gars unis par une tâche se croisent à différentes réunions - ils se connaissent, communiquent dans un fumoir ou au déjeuner. Il existe des salons de discussion distincts, par exemple, uniquement pour les surnoms iOS. Au sein de l'équipe, bien sûr, le problème est résolu plus facilement - nous sommes tous assis à la même "marguerite".
Si vous avez des questions, levez la main, saluez celle dont vous avez besoin - et il vous répondra. Pour transférer les connaissances, nous utilisons également des rallyes matinaux de 15 minutes, où tout le monde dit quoi, comment, pourquoi et pourquoi. Il existe encore une certaine couche de documentation où les principaux points sont pris.
Le deuxième problème - la coordination des actions - est résolu par une direction compétente.
Maxim Efimov (Uber): En fait, dans le même partage de connaissances, je ne vois pas le problème. Je vois que le mécanisme de partage lui-même est différent. Dans les petites équipes, cela se fait simplement de toute façon. Rassemblé - parlé. Et nous avons des processus pratiques qui nous permettent d'organiser tout pour que cela fonctionne. À propos, j'en parlerai dans mon
discours à AppsConf 2018. L'idée est que dans notre entreprise, presque tout le développement est assez transparent. Les gens de n'importe quelle équipe peuvent regarder ce que font les autres développeurs et utiliser une partie de cela à la maison.
Evgeny Suvorov (Avito): Nous organisons également des réunions 2 fois par semaine. Nous aimons l'automatisation, et cette tâche est également automatisée. Il existe un processus au cours duquel, pendant la semaine, les gens abordent des sujets dont ils aimeraient discuter lors d'une assemblée générale des développeurs iOS ou Android. Et s'il y a une assignation, nous allons le faire. Au cours des réunions, les équipes produit parlent des fonctionnalités qu'elles ont implémentées dans le produit, car sinon, il est difficile de suivre tout ce qui se passe.
Nous nous sommes rencontrés dès le début, mais c'est avec la croissance de l'entreprise que ces rencontres sont devenues les plus pertinentes.
De plus, il existe des salles de discussion où vous pouvez discuter de problèmes spécifiques.
Selon quel principe est-il judicieux de diviser de nombreux développeurs dans une entreprise - par plate-forme, par fonctionnalité ou d'une autre manière?Artem Olkov (Odnoklassniki): Cela dépend toujours de ce que vous faites et de la façon dont vous gagnez de l'argent.
En théorie, je peux imaginer la structure d'une entreprise d'externalisation dans laquelle une division, par exemple, fonctionnera sur une plate-forme. Mais pour une entreprise agroalimentaire, je peux difficilement imaginer une forme de division différente, sauf pour les équipes fonctionnelles.
Parce que si vous mettez tous les surnoms iOS dans un tas, y jetez des tâches, sans avoir un pont de communication très court avec la conception, le backend ou les tests, vous devrez consacrer trop de temps à la coordination.
Philip Uvarov (Spotify) : Nous partageons tous le produit. Par exemple, notre équipe est engagée dans l'analyse et comprend iOS, les développeurs backend et bien d'autres. À mon avis, il s'agit d'une division très raisonnable des équipes, ce qui entraîne également certains problèmes, mais en même temps fonctionne bien à une telle échelle.
Maxim Efimov (Uber): Il me semble que l'idée de diviser les équipes par plateforme - iOS, Android, backend - à grande échelle ne fonctionnera pas très bien. Cela sépare beaucoup les développeurs les uns des autres et, par conséquent, la synchronisation, par exemple, de deux applications mobiles pour différentes plates-formes, coûtera beaucoup plus cher. Et le bénéfice du fait que les gens de l'équipe ne voient que les gens de leur plateforme, comme il me semble, n'est pas tellement. Oui, le partage des connaissances est plus facile, mais en vaut-il la peine? Je pense que non.
De plus, l'idée que certaines équipes font des choses de base que tout le monde utilise, par exemple, certains boutons, listes, champs de saisie de texte, me semble intéressante.
Evgeny Suvorov (Avito): Je suis d'accord, une telle structure est assez réussie et nous l'avons récemment mise en œuvre dans notre Avito, du moins dans la partie épicerie de l'entreprise.
Notre équipe est devenue grande, probablement, lorsque nous avions cinq développeurs - car même avec une telle quantité, l'auto-organisation était difficile. Il est devenu plus difficile pour les gars de voir une fonctionnalité, ils ont dû les séparer, les reproduire sous différents angles, dans différentes fonctionnalités. Des désaccords ont commencé dans des domaines architecturaux et autres, et les communications sont devenues plus compliquées.
À un moment donné, Avito avait deux grandes équipes - iOS et Android-développement, 15 personnes chacune. Et à ce stade, nous avons commencé à nous diviser en équipes produits: les groupes «expérience acheteur», «expérience vendeur», messagerie instantanée, livraison, etc. se sont démarqués. Cela a résolu le problème des priorités. Auparavant, de nombreux chefs de projet venaient dans les équipes avec des demandes de fonctionnalités, et pour eux, chacune de ces fonctionnalités avait la priorité numéro un. En conséquence, nous avons 20 projets et leurs priorités transversales ne sont pas claires. Les parents devaient gérer cela manuellement. Après avoir mis en évidence des équipes multifonctionnelles, chacune disposant de son propre pipeline de développement, de ses priorités et de ses moyens, tout est devenu plus simple.
Dans le même temps, nous avons encore de petites équipes de plate-forme qui prennent, comme nous l'appelons, des décisions «horizontales» qui se déploient à toutes les équipes de produits.
Des réorganisations d'équipe ont-elles souvent lieu?Philip Uvarov (Spotify) : Une sorte de mouvement se produit chaque semaine. Dans notre entreprise, les équipes sont petites et autonomes. Si vous le souhaitez, vous pouvez très facilement passer de l'un à l'autre. La fréquence à laquelle cela se produit dépend de l'équipe et de la direction dans laquelle vous travaillez. Là où je travaille, ce n'est pas prononcé. Mais Spotify est célèbre pour le fait que nous travaillons sur Agile et à bien des égards, des choses comme OKR, etc. Par conséquent, la direction de l'entreprise n'a pas peur de changer de priorité si elle se rend soudain compte que quelque chose ne fonctionne pas. Nous passons simplement à autre chose.
Maxim Efimov (Uber): Nous avons eu des réformes à grande échelle, principalement liées à la croissance très rapide du bureau d'Amsterdam. Au cours de l'année, le nombre d'employés a presque doublé. Les équipes où des personnes ont été recrutées sont devenues très importantes et il était difficile pour un responsable de gérer une telle structure. À cet égard, les équipes étaient simplement divisées en plusieurs "sous-commandements", dont chacun était engagé dans une zone plus étroite. Il me semble que c'est un processus naturel.
Êtes-vous d'accord avec l'idée que dans une grande équipe, pour que la qualité du code ne souffre pas, cela vaut la peine d'éviter l'embauche de juniors et seniors surqualifiés?Philip Uvarov (Spotify) : Je pense que ni l'un ni l'autre. Chaque année, Spotify recrute un grand nombre de diplômés universitaires par le biais de la pratique d'été (certaines personnes après la pratique reçoivent une invitation à travailler). De même, nous prenons facilement des personnes avec plusieurs doctorats.
Les compétences techniques sont cool, mais vous pouvez les enseigner. Si une personne ne sait pas travailler en équipe, ce sera extrêmement difficile. Par conséquent, ces entreprises accordent presque plus d'attention aux compétences générales.
Et pour que la qualité ne souffre pas, nous avons besoin de bonnes interviews qui nous permettront de sélectionner des développeurs pas inférieurs à un certain niveau de base.
Maxim Efimov (Uber): Nous partons d'un principe légèrement différent. Nous avons un ratio souhaitable de développeurs expérimentés et juin. Juste pour qu'il n'y ait pas de situation quand il y a une foule de dzhuns, et qu'il n'y a personne pour les aider et leur expliquer comment travailler. Par conséquent, nous essayons de maintenir un équilibre.
Adhérer au principe de "ne pas recruter trop de seigneurs" ne voit pas l'intérêt. Trouver un seigneur est une quête assez difficile. Il existe de nombreuses entreprises sur le marché et la concurrence pour les développeurs est sévère. Les personnes ayant de l'expérience s'installent avec succès dans presque n'importe quel endroit, donc abandonner du personnel qualifié aujourd'hui et les recruter demain est quelque peu irréaliste. Ces personnes ne s'asseoiront pas et n'attendront pas que nous voulions les inviter. Et dans ma pratique, si une personne a de bonnes compétences, alors ce n'est pas un problème de lui trouver une place dans l'entreprise. Mais nous devons partir d'une situation particulière. Nous devons prendre une décision, en fonction des ambitions de chaque membre de l'équipe, examiner les projets à venir, si nous pouvons les retirer nous-mêmes, de qui nous avons besoin. Autrement dit, il est nécessaire de descendre à la planification de bas niveau.
Evgeny Suvorov (Avito): À mon avis, lors du recrutement de seniors, il ne faut pas avoir peur qu'ils aient leur propre roi dans la tête ou qu'ils n'obéissent pas.
Dans notre entreprise, les développeurs proposent eux-mêmes des moyens de résoudre certains problèmes. Et les seniors ont souvent des solutions de qualité. Ils ont de l'expérience, donc avec leur participation, les problèmes peuvent être résolus plus rapidement. Il y a un autre problème - vos tâches peuvent ne pas sembler intéressantes ou ambitieuses pour les personnes âgées.
Les juniors doivent également être approchés individuellement. Quand nous étions encore une seule équipe, de temps en temps il y avait un sentiment intuitif que l'équipe pouvait sortir un autre juin. Et à ce moment-là , il était possible de prendre un merveilleux gars ambitieux qui a rapidement grandi pour devenir ingénieur de qualité. Dans une équipe aux processus bien établis, la formation est vraiment rapide. Oui, et les jones sont différents - certains viennent après l'université avec des yeux brûlants, mais ils ne peuvent rien faire, tandis que d'autres ont sept ans d'expérience en arrière-plan derrière eux, ils sont simplement passés aux applications mobiles.
Autrement dit, nous n'avons pas peur des juniors, mais nous nous concentrons sur les sentiments de l'Ă©quipe - qu'elle en ait besoin ou non.
Planification, synchronisation, distribution des tâches
La planification et la synchronisation des développeurs au sein d'une grande entreprise (même en petites équipes) prennent-elles beaucoup d'énergie?Philip Uvarov (Spotify) : Il s'agit simplement de la division des équipes par produit et non par fonction: nous planifions uniquement notre petit produit au sein de l'entreprise et nous ne nous soucions souvent pas de ce que font les autres millions de développeurs.
Artem Olkov (Odnoklassniki): Ici, je ne peux parler que de notre équipe spécifique. Nous avons commencé le développement, et cela donne certaines indulgences - vous permet d'être plus libre. Pour le moment, nous n'avons que des rallyes quotidiens de 15 minutes sur l'état actuel et la clôture horaire de la précédente / planification du prochain sprint une fois par semaine. Tout le reste est décidé sur une base personnelle.
Maxim Efimov (Uber): Dans notre cas - pas très gros. C'est peut-être 1,5 à 2 fois plus que cela ne m'occupait lorsque je travaillais sur l'externalisation.
Certes, certains processus de l'entreprise, tels que la révision du code, entravent le développement. En gros, jusqu'à ce qu'une équipe responsable de son morceau de code examine votre commit, cela peut prendre un certain temps. Mais je ne pense pas que cela se réfère aux frais de synchronisation. Il s'agit davantage de la façon dont l'ensemble de ce système est mis en place à un niveau bas - qui révise qui, comment l'attente est organisée, etc.
Evgeny Suvorov (Avito): Nous avons initialement résolu le problème de synchronisation avec des versions fréquentes. En conséquence, la synchronisation elle-même prend maintenant un peu. Tout est presque automatisé.
Dois-je répartir les tâches d'une manière spéciale afin que la qualité du code ne souffre pas?Philip Uvarov (Spotify) : Dans les grandes équipes, il est logique de distribuer le produit par domaine de responsabilité. Ainsi, il y aura toujours des gens qui les aborderont de manière responsable car ils vivront avec elle plus tard. Leur contexte ne change pas, c'est-à -dire , ( 10 , 5 , ).
« », - , backend- .
(Avito): , code review. , backend- — Python, PHP, Go — Avito. , .. , — .
- , ?(): , . , , , — : , , , , .
(Avito): , , — , , .
, . , - , . . .
backend- , — — . , .
- / ? ?(Spotify) : . , , Gradle Bazel Teamcity , . , .
(Uber): Uber- , . , , Kotlin. , , . . . , « » : « Kotlin-». Kotlin , .
, . , - , . , .
(Avito): , . . , , ().
Technology Radar. : « , 5 , .. ». , Technology Radar, , , , - , , - , - , - . , , . , Technology Radar .
?(Uber): , . , 10 - - . . 100 , , 99. , , , .
( )?(Avito): , — , , , . — .
- , , .
. Android- — IDE early adopted preview . , .
(Spotify) : , Kotlin — - . , Java Android, Kotlin . , — Facebook — Kotlin- , , , Kotlin .
Flutter.
(): , iOS — , Apple. . , . .
, , — . Unidirectional Data Flow.
Swift?(): . Swift, 150 Objective-C, .. Swift , .
Objective-C , Swift? , , Swift — HR-PR-, , Objective-C .
(Avito): . Swift . , , , . . Swift , Objective-C, , , .
( )?(): . Apple , , Swift , open source. , . Objective-C .
( ) — — - , , . , . , — . iOS — , , .
? TDD ?(Spotify) : , Android , . , .
(): , . Unit- .
Unit- , ( ). (API, UI ..) — .
(Uber): , TDD, . , , — .
(Avito): . , , -. UI- unit- . , — , UI-.
. — . TDD.
TDD . Android- , .
AppsConf 2018 TDD.
, .
- ?(Spotify) : , . 100% - unit- .
(Uber): , . , . .
- «» ?(Spotify) : — .
, - (proof of concept ), , . , , , .
(Avito): , , QA-, , backend, frontend . . , , QA.
?(Spotify) : , code review — . CI: , code style —
AppsConf 2018.
: pull request, code style, ; , . , git-. — , : , .
(Uber): Code review — , . , . .
(Avito): code review- -. , , -, , , . -.
, . . , . , , (« ?»). , , .
. , . , , . . , - code review. , .
?(Spotify) : , .
(): , , . , «» «». — , . — — . . - .
. , Android- .
(Uber): , , — . .
build train, . - — . .
. , : . , .
(Avito): — 12 . , . , - ( , -).
-, . . . — . . , — , . , - . .
. , , . . . , , , . .
. AppsConf 2018ApplsConf 2018 . , .