Comment survivre à ses coéquipiers dans une scram évolutive et maintenir le contrôle de la qualité du code

Le directeur technique de l'ivi, Evgeny Rossinsky ( eross ), connaît bien les participants à nos conférences sur les rapports sur l'aspect technique du streaming. Mais aujourd'hui, vous avez la transcription du rapport d'Eugene sur TeamLead Conf sur la façon dont la transformation Agile se reflète dans les chefs d'équipe.



Il n'y a pas si longtemps, à ivi, nous avons traversé la transformation Agile et en avons tiré un bon profit en termes de:

• entreprise
  
• vitesse de développement
  
• délai de commercialisation;
  
• d'autres mesures intéressantes.
  

Mais les conséquences de cette décision créative ont assez durement touché les chefs d'équipe. Le rapport traite uniquement de la manière de gérer cela et des outils à utiliser.

Avant la transformation

Afin de comprendre de quoi je vais parler, nous devons nous familiariser un peu avec notre produit. Ensuite, nous analyserons pourquoi nous avons un tel format de commandes et pourquoi nous avons choisi ce chemin.

Le développement dans ivi passe par cinq plates - formes principales :

• iOS
  
• Android
  
• Web
  
• Smart TV
  
• Windows + Xbox.
  

Et, bien sûr, le backend, sans lequel nulle part. Avant de décider de mener à bien la transformation, nos équipes étaient constituées de compétences.



Les gars qui connaissent, par exemple, Swift ou Objective C:

• assis dans la même pièce;
  
• recevoir des tâches des chefs de produit;
  
• travailler sur eux et produire un résultat.
  

Tout semble aller bien, mais il y a un problème - les plateformes sont très sérieusement différentes en termes de produit et de consommation de contenu par les utilisateurs.

Cela signifie que dans chaque équipe, son carnet de commandes et ses priorités ont commencé à apparaître . Par exemple, les utilisateurs d'une application Web n'aiment pas payer et le contenu est consommé via un modèle publicitaire. Les fonctionnalités nécessaires à cette plate-forme apparaissent naturellement dans le backlog. Les téléviseurs intelligents se caractérisent par le fait qu'ils sont bien achetés et que les caractéristiques d'un modèle payant se manifestent.

Il s'avère que la situation suivante: quelqu'un a eu une idée brillante sur la façon d'améliorer un produit; J'ai écrit beaucoup de tickets qui vont aux chefs de produit, chacun responsable de leur plateforme. Les managers transmettent leurs idées à travers le prisme de leur perception, ils modernisent peut-être quelque chose et l'intègrent dans leur plan de travail. Le problème ici est qu'une fonctionnalité peut être lancée sur toutes les plates-formes pendant plus d'un an, car "je crois que ce n'est pas du tout une priorité pour ma plate-forme". Et dans un an, six mois ou quelques mois, tout peut arriver au produit - par exemple, une refonte ou un changement de concept se produit, et cette fonctionnalité doit déjà être déployée, et elle est complètement différente de toutes les autres plates-formes.

En conséquence, après un certain temps, il s'est avéré que sur différentes plates-formes, nous avons des produits complètement différents avec des messages de communication et une logique métier différents. L'utilisateur dans cette situation commence à devenir confus, car il n'a pas un seul espace dans lequel il se sent en confiance. De plus, il est très difficile de construire des hypothèses , car il n'est pas toujours clair sur quelle plate-forme quelles fonctionnalités tireront le mieux. Tout dépend de la taille de l'écran, de la façon dont les gens consomment le contenu. Et tout cela ressemblait à ceci:



Le produit ingénieux apporte l'idée, et les développeurs sur différentes plates-formes la perçoivent plutôt hostile, à l'exception du backend, qui en général n'a pas d'importance quoi écrire.

Donc, comme l'entreprise avait suffisamment de compétences en ce qui concerne les méthodologies flexibles, nous avons convenu avec l'entreprise que nous devons supprimer la barrière entre:

• produit
  
• entreprise
  
• la technologie
  

interagir de manière productive et faire une chose commune.

Après transformation

Il en est résulté une architecture avec Value Stream dédié, dans laquelle chaque équipe est engagée dans un domaine d'activité spécifique.



Pour former une nouvelle structure, nous:

• organisé plusieurs formations;
  
• Déterminé quels sont les principaux domaines de notre entreprise;
  
• ils ont volontairement forcé les gens à se tourner vers la chaîne de valeur;
  
• commencé à mettre en œuvre.
  

Certes, avant cela, nous avons constitué une telle équipe, sur l'exemple de laquelle nous avons effectué des démonstrations , après avoir éliminé une fonctionnalité sur toutes les plateformes avec un excellent délai de mise sur le marché.

De plus, la fonctionnalité a été très bien choisie et a réussi sur toutes les plateformes. Nous avons donc eu un exemple qui a montré que tout peut être fait plus rapidement et mieux . Cela a permis à toute l'équipe de développement de 130 à 140 personnes de comprendre que vous pouvez travailler différemment.

Lorsque nous avons déterminé la chaîne de valeur, la question s'est posée de savoir quoi faire avec les chefs d'équipe. Auparavant, ils étaient la base de tout dans leur direction, mais maintenant il y a un flux de valeur et une plus grande influence de l'entreprise. Qu'avons-nous fait? Nous avons rassemblé des personnes de compétences différentes dans chaque chaîne de valeur, au moins une chacune:

• Développeur iOS
  
• Développeur Android
  
• Développeur JavaScript
  
• Spécialiste Smart TV
  
• concepteur de mise en page,
  
• au testeur.
  

Il s'est avéré être une équipe indépendante, mais indépendante dans les mots et sur de belles diapositives d'un coach Agile. En fait, tout le monde oublie qu'il reste quelque chose en commun entre les gens qui peuvent écrire dans le même langage de programmation - c'est leur code de programme, à travers lequel ils doivent en quelque sorte communiquer. Pour une raison quelconque, beaucoup sont silencieux à ce sujet, mais c'est vraiment un assez gros problème qui doit être rappelé.

Supposons que vous placiez des personnes dans des étages ou des pièces différents et qu'elles écrivent le même code. Il existe un cycle de publication et des fonctionnalités qui ne devraient pas interférer les uns avec les autres. Il y a beaucoup de problèmes.

Du concept

Nous avons adopté plusieurs concepts de base:



Nous avons obtenu des commandes de flux de valeur et de plate - forme . Dans le flux de valeur, les gars implémentent une fonctionnalité spécifique, et dans les plates-formes, il y a un chef d'équipe - le centre de compétences. À l'intérieur des plates-formes, certaines fonctionnalités peuvent également être développées, mais il s'agit davantage d'une vue architecturale sur le développement de logiciels.

Nous avons introduit le concept de « Guilde ». En plaçant les mêmes développeurs iOS dans différentes pièces, nous devions leur donner un signe officiel et même informel, qu'ils restaient les mêmes développeurs iOS, et pas seulement des participants à la chaîne de valeur du produit publicitaire, par exemple. Et puis avec cette guilde, vous devez faire quelque chose et apprendre aux gens à communiquer à l'intérieur.

La question suivante était de savoir quoi faire avec les cycles de publication . Sur ces plates-formes où vous pouvez déployer lorsque la fonctionnalité est prête, il n'y a pas de questions. Et dans le cas d'iOS ou d'Android, lorsque, en raison des particularités de la réception de l'approbation d'Apple, il est impossible d'envoyer l'application deux fois par jour pour publication, il est nécessaire d'accumuler certains packs.

Nous avons décidé que toutes les plateformes qui ne peuvent pas être publiées immédiatement le seront toutes les deux semaines . Ils ont mis un calendrier spécial à la disposition de tous, où l'équipe publie la date de gel et la date de sortie de la fonctionnalité. Si, étant dans le flux de valeur, vous voulez que votre tâche soit disponible pour un utilisateur réel, vous devriez être à temps pour le gel des fonctionnalités. A eu le temps - eh bien, n'a pas eu le temps - vous attendez le prochain train.

Timlid dans le nouveau schéma

Qu'est-il arrivé aux Timlids? Ils sont passés par le schéma classique de prise de conscience des problèmes qui ne peuvent pas être résolus.



Au début, nous sommes tombés sur un déni . Parce que le chef d'équipe avait construit une équipe cool pendant plusieurs années, a nourri chaque employé, a attiré quelqu'un des concurrents. Et ces spécialistes sont désormais affectés à des travaux qui ne répondent pas toujours à leurs attentes.

Bien sûr, après le déni, il y a eu de la colère .

Il y a eu de nombreux scandales, après quoi la négociation a commencé. Tout le monde est venu avec une question: "Laissez-nous tous votre propre chemin, mais je l'ai comme avant, mais je vais prendre un marqueur, écrire" Agile "dans ma maison, je vais aller dans un T-shirt avec cette inscription, mais tout sera comme avant." Ça n'a pas marché.

Mais à la fin, ce à quoi je m'attendais vraiment est arrivé - les gens ont compris pourquoi nous faisions cela. J'espère qu'ils ont compris, même s'ils ont peut-être menti. Le tout premier cas réussi a montré une réelle différence frappante entre ce qui était auparavant et comment cela peut être fait différemment. Le time-to-market réduit de moitié nous a permis d'établir une référence pour tout le monde. L'étape suivante s'est produite, qui dans le modèle classique de la psychologie est appelée le syndrome de Stockholm . Les gens qui ont adopté les nouvelles règles ont appris à exister en eux et ont commencé à propager lentement cette «religion». Je ne peux pas dire pour tous les Timlids, mais environ 30% d’entre eux sont maintenant des «prédicateurs» actifs dans ce sens.

Problèmes et difficultés

Je vais maintenant essayer d'énumérer de manière plus structurelle les difficultés que nous avons rencontrées:



Du fait que les employés étaient assis dans différents bureaux, la communication verbale a été perdue. Cela est devenu très difficile pendant un mois , car avant, il était possible de demander rapidement à un voisin, par exemple, de quoi vous devez hériter, puis d'obtenir une réponse. Et maintenant, vous êtes assis dans une pièce séparée, il y a des gens autour de vous dont vous n'aimez peut-être pas la technologie, et il n'y a personne à consulter. Pour poser une question à quelqu'un, vous devez écrire dans un chat, et la personne qui peut répondre est partie - c'est tout, vous êtes laissé à vous-même.

Nous avons immédiatement commencé à avoir des problèmes avec Code Review , qui, je pense, n'est pas un problème, mais une grande découverte. Nous avons constaté qu'un grand nombre d'employés n'étaient pas indépendants . Supposons qu'il y ait un employé qui, selon les statistiques, les problèmes de révision ont passé le maximum la deuxième fois, généralement la première fois que tout allait bien. Et quand il est parti travailler dans la chaîne de valeur, pour une raison quelconque, cela est devenu 5-6 itérations.

Ils ont commencé à comprendre, et il s'est avéré que l'opinion faisant autorité de la figure emblématique du chef d'équipe, qui contrôle, centralise tous les flux d'informations par rapport à lui-même, n'affecte pas très bien le développement des développeurs. Les gens sont paresseux , ils demandent de l'aide sur toutes les questions et reçoivent des réponses compétentes. Et donc l'examen est rapide et cool. Étant seuls avec eux-mêmes, de nombreux développeurs ont dû se développer de manière assez significative au-dessus d'eux-mêmes afin de prendre les mêmes décisions architecturales . Personne n'aime entendre cinq fois de suite que votre code n'est pas très bon. C'est frustrant, cela vous fait vous considérer comme un employé insuffisamment qualifié, cela peut même conduire à la dépression ou à la conviction que le travail est peut-être mauvais. Mais le point est que vous devez voir par vous - même pour comprendre que , dans la même opération, vous ne pensez pas à ces choses, et se développe maintenant et devrait commencer à penser à eux.

D'un autre côté, nous avons eu des choses très intéressantes qui, à mon avis, sont redondantes en ce qui concerne la révision du code. Il y avait une règle dans l'une des équipes: pour que la tâche passe l'examen, tous les membres de l'équipe doivent prendre sa décision. Lorsqu'ils se sont assis ensemble, ils ont plus ou moins réussi, et maintenant ils se sont tous assis - certains avaient une réunion de stand-up quotidienne à un moment donné, d'autres avaient d'autres affaires - et l'examen des tâches est devenu un goulot d'étranglement étroit. Rétrospectivement, ils ont appris que certaines tâches étaient en suspens pendant deux semaines et ont été forcés de changer quelque chose.

Commença alors le séparatisme, la discrimination et l'envie .

Auparavant, une personne pensait savoir ce qu'elle voulait faire. Et avec la séparation du flux de valeur et de la plate-forme, un soupçon a commencé à émerger que «le voisin a meilleur goût»: les tâches sont plus intéressantes et la croissance est plus rapide. Le deuxième problème est que lorsque tout devient centré sur les fonctionnalités , la qualité du code se détériore beaucoup. Autour de vous, des gens qui veulent obtenir rapidement le résultat, et ce n'est pas leur tâche de penser qu'il devra être pris en charge, modernisé de quelque manière que ce soit, et rien ne devrait rompre avec les collègues de la nouvelle fonctionnalité.

Des situations ont commencé à apparaître dans lesquelles une vitesse de développement élevée avait son côté opposé - un code de mauvaise qualité , qui a commencé à se multiplier en quantités inhumaines. Lorsque le chef d'équipe responsable se charge de la correction de ces erreurs et de la refactorisation, il s'avère que sa vie se transforme en poubelle pour les employés négligents. Les développeurs sont rapides à tout obtenir, tout le monde est content, et ils ne remarquent pas le travail titanesque du chef d'équipe, grâce auquel, en fait, tout fonctionne. Après environ deux mois, chaque chef d'équipe s'est dit insatisfait de la situation actuelle.

Pour résoudre ces problèmes, nous avons tenu plusieurs réunions d'abord avec les Timlids, puis avec toutes les guildes afin d'expliquer aux gens qu'il est possible de travailler différemment. Si vous voulez essayer autre chose, alors vous devez venir en tant que chef d'équipe et vous pouvez facilement changer de place. L'essentiel est de s'entendre entre eux.

La force des méthodologies flexibles est que peu importe comment tout le monde se passe, l'essentiel est que les gens soient d'accord et satisfaits.

C'est d'une part. D'un autre côté, pour qu'il y ait justice quant à savoir qui est impliqué dans le refactoring et qui fait de nouvelles fonctionnalités, les chefs d'équipe commencent à travailler avec les backlogs, j'y reviendrai un peu plus tard.

Et puis les difficultés ont commencé avec la gestion des versions . Il y a des testeurs dans le flux de valeur, des testeurs dans les plates-formes, quelque chose est automatisé, quelque chose n'est pas automatisé, vous devez réfléchir à la façon de faire une régression générale. Et il y a des termes. Nous avons volontairement décidé de libérer une fois toutes les deux semaines, et que se passe-t-il si un partenaire vient avec une demande de tout faire d'ici demain (et un sac d'argent, par exemple), lui dire d'attendre le prochain cycle? Pourtant, un compromis doit être recherché . Et puis un beau schéma avec des versions peut changer beaucoup.

Un bon exemple est la loi FZ-54, selon laquelle tous les achats sur Internet doivent être accompagnés de l'envoi de chèques électroniques aux utilisateurs et à la taxe. Vous pouvez parler à des conférences autant que vous le souhaitez et parler de méthodologies flexibles et de ce qu'il y a des réglementations, etc. De tels cas sont rares, mais il y en a. En particulier, nous avons dû faire le deuxième niveau de communication en cas de changements dans le schéma. Ce n'est pas facile, mais possible.

Le prochain problème que nous avons rencontré à la suite de la transformation est lié aux nouveaux employés . À mon avis, les débutants devraient être plongés dans un environnement aussi proche que possible de celui dans lequel il travaillera. Et là, en raison de l'environnement, il recevra rapidement les connaissances nécessaires. Mais nous avons traîné les spécialistes qui composaient cet environnement dans différents étages et pièces. La vie de débutant dans une entreprise devient une tâche managériale assez sérieuse, dont la solution doit être réfléchie.

Les outils

Voici les outils que nous utilisons.



Je vais commencer l'histoire avec une feuille de route pour un nouvel employé. Malheureusement, c'est quelque chose que nous n'avons pas encore appris à automatiser complètement et, en fait, à réfléchir séparément pour chaque employé, en fonction de ce qu'il fera.

Il y avait un exemple assez intéressant: nous devions développer un testeur universel , qui serait capable de tester absolument tous les produits pour un flux publicitaire. Ils ont beaucoup en commun, mais ils ont aussi leurs spécificités. Ce n'est un secret pour personne qu'un testeur qui sait tester une application Web sera perdu pour la première fois lors de l'utilisation d'outils, par exemple pour iOS. Pour ce testeur, notre directeur du contrôle qualité a construit une carte d'itinéraire spéciale. Sur cette carte, un nouvel employé dans chaque compétence a acquis des connaissances pendant deux semaines, a participé à des régressions, etc. Avec les développeurs, la situation avec l'implémentation est à peu près la même. Ainsi, même lors de l'entretien, nous découvrons à quoi Candida gravite et ce qui l'intéresse, et nous essayons de choisir dans quelle direction l'envoyer.

Bien sûr, la première fois qu'un nouvel employé pompe des compétences, c'est-à-dire, selon nos termes, fait partie de l'équipe de la plate-forme, puis peut déjà migrer vers la chaîne de valeur dont nous avons besoin. Soit dit en passant, les cartes d'itinéraire sont bonnes, mais leur adaptabilité n'a pas non plus besoin d'être exclue.

Ensuite, nous avons introduit Guild Sync - synchronisation des actions de guilde .

Pourquoi est-ce nécessaire? Tout le monde a écouté une conférence sur Scrum, qui a parlé de la nécessité d'une réunion de stand-up quotidienne pour vous faire savoir ce qui se passe autour. Mais notre spécialiste, par exemple, est un développeur Android, d'une part, et un membre de l'équipe produit, d'autre part. S'il doit marcher et communiquer deux fois par jour, il obtiendra une sorte de culte du fret. À ce rythme, vous pouvez passer toute votre vie en réunion. Certainement, cela ennuiera les gens.

Si nous disons que nous sommes basés sur un modèle axé sur les fonctionnalités, la réunion quotidienne de stand-up est plus importante dans son flux de valeur. Mais en même temps, vous pouvez rompre avec ce qui se passe dans la guilde. Pour ce faire, certaines guildes organisent des réunions une fois par semaine, certaines - deux fois par semaine. Et ici, le chef d'équipe réfléchit méthodiquement à ce dont il vaut la peine de parler. Cela ne doit pas se traduire par un discours vide, c'est une stratégie de développement pour l'équipe technologique, qui est la guilde. Les réunions Guild Sync sont nécessaires pour que tout le monde comprenne quelles technologies l'entreprise utilisera, quelles décisions stratégiques sont prises concernant cette plateforme. Sur celui-ci, un examen partiel des solutions architecturales a lieu.

Dans certaines équipes, nous avons plus d'un chef d'équipe. En général, la définition du chef d'équipe est très ambiguë. Il y a des leaders d'opinion qui peuvent être des chefs d'équipe et porter la solution de certains problèmes organisationnels. Il peut y avoir plusieurs leaders d'opinion ayant des compétences en gestion dans une équipe. Et puis ils peuvent s'organiser, qui est responsable de quoi. Par exemple, l'un des leaders d'opinion peut passer à la chaîne de valeur. Dans ce cas, vous devez synchroniser vos décisions architecturales qui détermineront à l'avenir la stratégie de développement de l'ensemble de la plateforme technologique.

Ensuite, nous avons commencé à réaliser des mitaps internes et externes dans certains domaines. En général, il s'agit d'un cas assez standard en partie RH, en partie un cas de team building. Pour les réunions internes, parfois un vote a lieu sur le sujet le plus intéressant, des intervenants sont recherchés soit à l'intérieur de l'entreprise, soit nous invitons quelqu'un de l'extérieur, louons une salle spéciale et discutons de divers points importants. En moyenne, nous avons deux mitaps internes par mois, mais parfois quatre. Des personnes d'autres compétences peuvent venir à ces mitaps pour écouter comment vivent les voisins et voir si elles veulent changer de spécialisation. Cela arrive aussi.

Maintenant sur le marché du travail en matière de développeurs, tout n'est pas très simple. , , . , , , . , , .

. , , Agile- , Guild Sync .

, , , . , , Guild Sync , .



, , , , , . 10 .

— . , , -. - , , , . - , , , . , - . , , , , , - .

. , . , , , , . , , , . , - , , , , , .. . , « ». , , .

Guild , . - , , .

, product owner' value stream. , 10 , - , , . , product owner' . backlog' . , , . , ( , , , , ).

— , .

Teamlead —

, , - .

, . , , , , , , — .

, , , « ». , , , . , , , , value stream. , , . , , .

Le prochain rassemblement pour l'échange de tours Timlid est prévu les 24 et 25 septembre. Nous nous réunirons à Saint-Pétersbourg à la Saint TeamLead Conf pour discuter de toutes sortes de problèmes de gestion d'équipe.

Le programme commence déjà à prendre forme, il y a plus de 40 candidatures dans la liste des rapports soumis , et jusqu'à présent, il est possible d'y ajouter votre sujet - le Comité du programme accepte les candidatures jusqu'au 10 août .