Côté sombre agile

Le lecteur attentif feuillette la bande et pose la question: "Qu'est-ce que, encore une fois, le texte sur l'agilité?". Ouais.

Cet article porte sur les processus, les aspects techniques et un peu sur la façon dont la vie agile est implémentée dans Yandex.Money. Si vous avez parcouru au moins la moitié du chemin vers une vraie agilité, certaines choses peuvent vous sembler évidentes, et c'est très bien.

Sous un chat sur les bancs d'essais, enfermer les gens dans les salles de réunion et comment gérer un département, quand tout le monde s'est dispersé autour des équipes et a apprécié la vie.

Et un lecteur attentif demandera: "Pourquoi le côté obscur? Qu'est-ce que Dark Vador?" Hélas, non, il s'agira du côté obscur de la lune, inconnu de l'humanité, jusqu'à ce que l'appareil s'envole pour le photographier et le montrer à tout le monde.

Lorsque vous implémentez agile, vous concevez un projet d'exploration lunaire, sans savoir
ce qui est de l'autre côté

Tout commence par une tentative d'introduction de nouveaux processus de développement.

Scrum, kanban, scrambana ou un autre vélo local n'est pas si important.

Les départements de développement classique sont généralement dirigés par un responsable des ressources. Il dit au monde extérieur: "Ne va pas aux développeurs, va à moi, je vais tout distribuer ici maintenant." Une fois qu'un tel gestionnaire alloue pour la première fois un flux, car un client spécial est apparu. Ensuite, il y a plus de clients de ce type à l'intérieur et à l'extérieur de l'entreprise, les conflits commencent, la lutte pour les ressources et le gestionnaire doit tout résoudre. Également par allocation de threads.

Java - gauche, JavaScript - droit

Ce jeu continue à un point critique, après quoi la société accepte l'idée que maintenant précisément agile est nécessaire. Des équipes de produits apparaissent, car pour PO il n'y a rien de plus précieux qu'une ressource dédiée et votre propre équipe. Le produit est content parce que l'équipe en direct facilite la réponse pour la fonctionnalité et supporte la responsabilité du PNL, du trafic et des autres KPI.

Cela semble correct, mais dans la vraie vie, tout va un peu mal.

Dans la plupart des départements de développement classiques, il est plus rentable de travailler avec un monolithe. Dans ce cas, tous les attributs sont attachés - cycle de libération en 3-4 semaines, longs tests et assemblage.

Parfois, un monolithe est normal

Mais les équipes sélectionnées ne fonctionnent pas comme ça. En général, le monde est venu aux microservices parce que tout le monde a commencé à passer à de petites équipes et à y travailler. Oui, cela conduit au fait que le code "se propage" et que tout devient plus difficile à contrôler.

D'un autre côté, nous accélérons la sortie du produit, déployons les versions plus souvent, mais nous rencontrons des problèmes de test. Et ils doivent également être résolus d'une manière ou d'une autre.

Tester la réforme

Si vous avez une équipe et un banc d'essai - tout est en ordre, vous ne pouvez pas vous inquiéter (ou vous inquiéter, mais pour une raison différente). Souvent, dans de tels cas, il n'est même pas considéré comme quelque chose de critique - par exemple, un outil supplémentaire comme le courrier électronique ou le chat d'entreprise. Tout le monde surveille de près la production, et ils vont bien aussi.

Si vous avez déjà volé vers la Lune Edgile, le banc d'essai est une chose qui ralentira tout le processus, et c'est pourquoi.

Histoire de vie : dans une entreprise, l'entropie autour de l'agile a commencé à croître trop rapidement. À ce stade, les testeurs sont entrés dans le calendrier du seul banc d'essai du calendrier - ils ont divisé le temps en tranches d'une demi-heure et ont essayé de contrôler le chaos.

En fait, 20 équipes devraient utiliser le stand, mais elles ne le peuvent pas, car l'une d'elles a tout cassé

À propos des bancs d'essai

Il était une fois, nous avions plusieurs monolithes, chacun avec un banc d'essai, et tout le monde était content. Une fois que nous avons fait un projet complexe pour la séparation des stands, nous avons affecté des équipes, puis il y avait 20 stands.

Il y en a maintenant 70, mais nous en visons 200 - pour que tout le monde, gratuitement, et personne ne s'en offense.

Du dialogue avec l'administrateur:
- Dites-moi, où est l'automatisation du déploiement?
- Le calcul toutes les deux semaines prend une heure, que dois-je automatiser ici?

En fait, ceci: (200 stands + production) * (50+ composants) = Beaucoup d'efforts à déployer.
Nous avons maintenant plus de 50 composants que le robot déploie. Si ce n'était pas pour lui, alors tout le monde serait mauvais.

À ce stade, la société, qui s'oriente vers l'agilité, disposera de systèmes automatisés d'assemblage et de livraison à la production, le travail d'équipe s'améliorera progressivement et les performances augmenteront également - jusqu'à 60 à 80 versions par semaine, et chaque composant sera publié 2 à 3 fois par jour .

À ce stade, tout le monde comprend que le système est devenu trop volumineux pour qu'une personne puisse le saisir

Dans toute équipe qui prend en charge le monolithe, il y a certainement quelques anciens. Ils étaient là depuis le tout début et se souviennent de tous les bugs de tous les temps, se souviennent des étranges décisions logiques que l'entreprise vendait.

Histoire de vie:
"En général, il est normal d'essayer de frapper un client 3 fois, mais ce client est spécial, et nous allons frapper 100 fois, il y a un facteur de correction, et pas besoin de le toucher, s'il vous plaît, touchez-le, ce n'est pas juste comme ça."

Tant de ressources sont consacrées au maintien du travail des peuplements que l'opération devient «dorée» - multipliez toute la ferme par le nombre de bancs d'essai, augmentez la production, bouleversez et appelez enfin les administrateurs.

Autre surveillance

Les administrateurs viendront et diront: «Tout est couvert par la surveillance chez nous». C'est bien, mais avec une précision - la surveillance serait bien d'être personnalisée.

Des métriques «de fer», la quantité de mémoire consommée par Java, la température de tous les cœurs de tous les processeurs - tout cela est utile, mais cela n'aide pas toujours en cas d'incidents avec les clients. Les statistiques commerciales seront également ignorantes si vous ne les avez pas personnalisées. Le monde est complexe - il est rare que tous les clients idéaux utilisent idéalement votre API idéale. Les gens font tout, et tout le monde doit s'adapter - parfois les clients sont pour vous, parfois vous êtes pour les clients.

Comme une centrale nucléaire

Histoire de la vie : pendant longtemps, nous avons recherché et corrigé un bug dans nos produits. Après cela, l'un des clients a interrompu plusieurs processus dans lesquels ce bogue a été pris en compte.

À de tels moments, vous devez ajouter une surveillance personnalisée, car sans isoler les situations exceptionnelles et l'agrégation, cela ne fonctionnera tout simplement pas. Par conséquent, d'ailleurs, ils parlent et écrivent souvent sur l'apprentissage automatique et les systèmes complexes qui définissent les problèmes plutôt que les personnes.

Tous les six mois, vous devez effectuer des revues de suivi, car les attentes des entreprises augmentent avec le temps. Cela se passe comme ceci - tout est construit et contrôlé dans l'entreprise, et l'entreprise amène un nouveau client qui a besoin d'un SLA d'un ordre de grandeur plus élevé. Et toute l'histoire est terminée.

Si cela est surmonté, le système fonctionnera assez bien dans tous les cas, sauf pour les projets "parapluie".

Projets parapluie

C'est, par exemple, l'introduction du 54-FZ, lorsque l'État dit: "Et restructurer tous les processus de trésorerie dans le pays." Ou lorsque le marketing payait pour le projet, le produit devait encore fonctionner et travailler, et le délai était réel, et ensuite ils le tiraient pour lui. Ou quand quelqu'un de la haute direction vient de rentrer, peu importe pour quelle raison, et il a aussi un projet avec une échéance.

Spoiler - peu de gens sur le marché savent comment les fabriquer. Vous pouvez acheter différents modules complémentaires sur Scrum et Kanban, vous pouvez lire des histoires de réussite, mais la pratique montre qu'il est plus coûteux de faire de tels projets en théorie. En outre, tous ces SAFE et LEAN sont coûteux sur le plan administratif et de ressources, et ils nécessitent également des compétences coûteuses et complexes qui ne sont pas sur le marché.

Histoire de vie: Spotify est l'une des entreprises agiles exemplaires. À un moment donné, ils ont proposé un abonnement familial, mais n'ont pas pu le réaliser en raison de la difficulté de synchronisation et de planification entre les équipes qui ont leur propre feuille de route et leurs propres plans. Un an plus tard, Google et Apple ont déployé l'abonnement familial.

Conflits de synchronisation et de planification

Le principal problème des projets-cadres est la synchronisation de toutes les équipes participantes. C'est lié au fait que les gens n'aiment pas négocier.

Cela se manifeste à bien des égards, à commencer par la mêlée, lorsque les gens ne peuvent s'entendre dans le cadre d'un service des ressources. En agile, vous devez synchroniser et coordonner tout ce qui se passe avec plusieurs équipes. Et si à un moment donné vous arrêtez d'exiger que tout le monde travaille ensemble, chaque équipe retourne dans son coin sombre préféré et travaille de manière indépendante. Cela mène à l'échec.


Life hack
S'il reste deux mois avant la prochaine loi, ou avant la campagne publicitaire, ou si le patron l'exige - prenez les gens de 4 équipes, enfermez-les dans une pièce, donnez de la nourriture et de l'eau et contrôlez. C'est impoli, mais ça marche. Parce que si vous essayez de vous lancer dans la synchronisation pendant une durée limitée, vous échouerez au projet.

En général, la synchronisation est nécessaire et sans elle, vous ne pouvez pas continuer. Cela complique la vie des projets avec un délai clair et une criticité élevée - les délais varient de 10% à 50%, ce qui est souvent inacceptable.

Comment gérer ça?

Le leader classique du département de distribution ne comprend pas quel est son rôle car on lui a enseigné le paradigme «J'ai donné des tâches à tout le monde», et je dois travailler avec «Je n'ai pas de gens du tout, pourquoi suis-je dans l'entreprise?».



Le pire, c'est pour les fous du contrôle qui ne manquent pas une seule tâche que le ministère résout, organisent des doubles révisions du code public et contrôlent littéralement tout. Lorsque les gens sont répartis en équipes, ils posent la question: «Pourquoi suis-je ici?». La réponse est que les développeurs de toutes les équipes échangent des informations, se développent de manière synchrone dans une direction et que le système ne rampe pas.

En général, lorsqu'une telle question sonne, le leader doit être changé ou enseigné.

Enseigner parce que de nombreux dirigeants (dont nous) sont issus d'ingénieurs, et personne ne leur a jamais enseigné les compétences générales. Nous pensons que cela est important, et une fois est venu aux RH et a demandé un grand cours de deux ans pour les gestionnaires - des bases à la performance et à la motivation non financière.

Culture en informatique

Il y a un autre point subtil sur l'agilité dans l'organisation des équipes. Lorsque les développeurs se mettent d'accord sur quelque chose au sein de l'équipe, ils peuvent commencer à défendre les intérêts de l'équipe, en oubliant les intérêts de l'entreprise.



Idéalement, lorsque les gens comprennent qu'il y a quelqu'un d'autre autour de leur lune Ajail - un service de sécurité avec ses propres exigences; une architecture qui n'a pas seulement été inventée; d'autres équipes dont les intérêts doivent être pris en considération. Nous nous efforçons d'identifier, d'encourager et d'encourager un tel comportement.

Agile - la pointe de l'iceberg

Ce chemin a des caractéristiques importantes.
Un long moment. Par exemple, DevOps est apparu sur le marché il y a cinq ans, et sa mise en œuvre coûtera désormais 1 à 2 ans, selon la taille de l'entreprise. Si vous commencez à vous en occuper lorsque vous avez des lignes sur les bancs d'essai, alors vous êtes assuré de six mois d'enfer, car les administrateurs seront déchirés entre tout.

Cher Vous ne pouvez implémenter Agile et suivre cette voie que si vous avez une entreprise solide et une entreprise solide, et vous comprenez qu'à l'avenir, vous devrez encore vous développer.

Il n'y a personne. Agile a besoin de nouvelles compétences, que les gens n'ont pas tellement. Il en résulte un cercle vicieux - il n'y a personne -> tout ne va pas très bien -> il n'y a pas d'argent -> il n'y a nulle part où prendre des gens.

Trois conclusions

1. Ne touchez pas aux services de développement "classiques" sans en avoir besoin. Un système hybride fonctionne dans Yandex.Money - il y a une équipe de produits, mais il y a des départements qui peuvent travailler efficacement sans agilité.
   
2. Si vous n'avez pas pour tâche de reconstruire l'ensemble de l'entreprise, mais que vous souhaitez ou devez rendre un nouveau produit plus rapide avec de nouvelles approches, il est parfois plus facile d'embaucher des sous-traitants qui travaillent sur l'agile et de donner au produit une ressource externe.
   
3. Si la transformation informatique est inévitable, il est préférable de se mettre d'accord sur tout «à terre». Il vaut la peine de conclure une sorte de «gentleman's agreement» avec la direction - qu'il y aura un budget pour le matériel, les gens (pour de nouveaux postes d'administrateurs système, de testeurs et de développeurs). Dans ce cas, il est possible de revenir périodiquement à cet accord et de discuter de ce qui a été fait et comment.
   

Tout ce qui précède a un problème. Allez jusqu'au bout! = Venez au succès. Ne le passez pas = échec garanti.

Mais si vous êtes en route - bonne chance!