Des monolithes aux équipes modulaires

Les grandes entreprises pleurent souvent le problème de l'adaptabilité et de la manœuvrabilité. Plus précisément, presque de l'absence totale des deux.

Imaginez: toutes les équipes de plate-forme sont occupées par une seule fonctionnalité, et l'entreprise a un besoin urgent de faire autre chose ou d'ajuster la fonctionnalité qui est déjà en cours de développement. Et à ce moment, le travail sur une fonction s'arrête et le travail sur une autre commence. Au moment suivant, de nouvelles exigences de l'entreprise apparaissent et la fonctionnalité reste inachevée. Les développeurs sont offensés et l'entreprise souffre.



Voici une autre situation: l'API est en train de changer, vous devez courir de toute urgence au département backend pour connaître les détails, puis revenir aux fronts (iOS / Android / web). De plus, après avoir discuté de vos corrections avec les fronts, vous devez revenir en arrière et parler de nos exigences. C'était très épuisant, a perdu le temps des équipes, un développeur individuel et les nerfs de toutes les personnes intéressées.

Je m'appelle Valery, notre équipe était engagée dans QIWI Wallet pour iOS. Mais il était toujours nécessaire de maintenir la communication avec les autres équipes, sinon une désynchronisation complète en résulterait. Quant à nos inconvénients, l'entreprise va toujours de l'avant et laisse la liberté à l'expérimentation. Par conséquent, la question s'est posée de changer la structure existante. Un environnement favorable pour tester nos idées de changement a été la mêlée. Toutes les deux semaines, nous, à l'intérieur de la plate-forme, pouvions modifier le cours afin qu'il soit au moins en quelque sorte coordonné avec d'autres équipes. Il a fallu beaucoup de temps pour tester les théories. D'un mois à six mois. Quelles options avons-nous essayées:

Oouner vedette

Une personne de l'équipe a été nommée responsable du long métrage pour le prochain sprint. Cette personne a passé une partie de son temps avec des concepteurs et avec une fonctionnalité d'une autre équipe de première ligne (le remplaçant a décidé de ne pas utiliser la fonctionnalité), découvrant les pièges et les subtilités du travail à venir, il était d'accord avec le backend sur le contrat. Il a également surveillé tous les changements apportés au backend et aux activités. Et tout semble aller bien. Personne ne court dans la panique, à part cette personne qui prend sur elle le coup d'un environnement changeant. Tout le monde s'est calmé un instant.

Mais le bonheur a continué exactement jusqu'à ce que la caractéristique du OUNER tombe malade juste avant son sprint. Et toute l'illusion d'apaisement s'est dissoute, et nous sommes retournés là où nous avons commencé.

Toilettage général

Des représentants de différentes plateformes ont été invités à former une équipe de plateformes. C'est devenu un peu mieux, mais les gars n'aimaient pas (du mot du tout) s'asseoir à plusieurs réunions d'affilée. Mais la raison principale est la variabilité des API et des contrats, la modification des objectifs de sprint, et c'est bien si cela ne change que le premier jour du sprint. Mais généralement, les changements ont chuté au cours des deux semaines. En bout de ligne - les objectifs ne sont pas atteints, les gars sont en train de traiter, l'entreprise souffre.

Chats

L'une des options non standard était la création de chats. Un chat séparé a été créé pour chaque fonctionnalité. De plus, il y avait aussi des forums de discussion des équipes où les problèmes étaient discutés. Et aussi un chat général spécifiquement pour les problèmes où toutes les équipes étaient. Au début, le problème semblait résolu.

Mais les conversations se sont rapidement multipliées et, vous savez, c'est devenu un fardeau. Lorsqu'un problème est apparu, il est devenu difficile de savoir où chercher des informations - soit dans la discussion sur la section de profil, soit dans la discussion sur la refactorisation du client réseau ou le remplacement du module d'informations utilisateur. En conséquence, il est devenu encore plus confus. Encore une fois, j'ai dû courir entre les départements.

Feature-tim

Puis une épicerie est venue et a proposé d'essayer le format long métrage. Qu'est-ce que cela signifie: deux développeurs sont issus de chaque plateforme (iOS, Android, web, backend) et deux testeurs) et une nouvelle équipe est formée.

Cette approche était censée résoudre plusieurs problèmes majeurs, en plus de la cohérence et de la rapidité de publication des versions:

Autonomie
Une équipe qui se rend aux réunions ensemble est aussi indépendante que possible des autres. Le lien principal des dépendances externes est le produit.

Test de théorie rapide
Après tout, avant que toute l'équipe du portefeuille n'ait fait de nouvelles fonctionnalités et il est arrivé que cette fonctionnalité très cool n'ait pas pénétré les utilisateurs. Il s'avère que l'ensemble du développement a vu des choses inutiles et le budget est allé nulle part.

Toute l'équipe comprend ce qu'est le «développement de produits»
Des fonctionnalités sont créées ou des exigences commerciales arrivent, et le développeur ne comprend pas toujours pourquoi, pourquoi et qui en a besoin.

Toute l'équipe affecte le produit. Jusqu'à l'invention de nouvelles fonctionnalités
En conséquence, tout le monde a aimé cette approche, et nous avons actuellement 3 équipes indépendantes qui sont engagées dans leurs tâches de produit. Maintenant, lorsque vous modifiez le contrat, vous n'avez pas besoin de parcourir les départements et de rechercher des responsables, il n'y a pas non plus besoin d'un tas de conversations déroutantes, il suffit de pousser un développeur assis à proximité. Des réunions ont lieu toutes les vedettes, où les représentants de toutes les plateformes et QA sont immédiatement présents.

Les questions sont résolues avec des mots en quelques minutes et personne ne ressent la même douleur. De plus, un autre grand avantage pour l'entreprise est que si la fonctionnalité n'a pas atteint les utilisateurs, alors une seule fonctionnalité de l'équipe (pour le moment sur trois) sera dépensée, et non le développement entier, comme c'était le cas auparavant.

En conséquence, nous avons réussi à obtenir les avantages suivants:

• Autonomie par rapport aux autres équipes.
• Le développement flexible maximum, nous pouvons changer de cap en toute sécurité, si le logiciel l'exige.
• Résolution rapide et facile des problèmes.
• Un test rapide des théories des fonctionnalités.

J'espère que cet exemple vous aidera à résoudre les problèmes de communication entre les équipes. Si vous avez d'autres options intéressantes, alors j'attends des commentaires).

Je vous remercie

Et nous aurons bientôt un mitap pour les développeurs iOS.