La Russie est irrationnelle. Il y a des pratiques correctes, il y a cent fois un rake ressenti, mais quand même, quelque chose d'épique se produit avec une constance enviable. Parfois pour la raison: "Eh bien, ça va certainement me faire exploser", parfois: "Toujours et travaillé", parfois juste à cause d'erreurs. Peut-être dans les gènes.
Le premier exemple vivant de jeu incroyable (les détails sont légèrement modifiés à la demande des agents de sécurité). Le client est engagé dans la construction d'immobilisations. J'ai commandé un système il y a plusieurs années à un entrepreneur qui gère tout cela (notamment les travaux estimés). Le système a été installé sur une douzaine d'objets assez gros, et a été introduit. Du coup, le client a décidé de lui demander de lui donner le code source. Il s'est avéré que leur entrepreneur actuel avait prévu de développer le logiciel et de vendre le résultat en tant que SaaS sur le marché. Le contrat ne dit rien sur le code. Nous nous sommes battus.
Quand ils nous ont appelés à comprendre, il y avait environ 10 versions différentes de logiciels (versions 0.9 à 2.4). Il existe 1,5 sources, cette version a été collectée une fois auprès d'eux. Pas de documentation. Et le système doit être développé et développé. Ils ont compté "tout réécrire" et "finaliser 1.5" et se sont installés sur le deuxième - TtM trois à quatre mois contre l'année. Ils nous ont appris comment collecter les spécialistes du support, corrigé les sources, réduit les bases de code, réalisé l'infrastructure, organisé un "casting", où la source est reçue, collectée et distribuée là-bas. Cela nous a coûté, ainsi qu'au client, beaucoup d'hémorroïdes.
Entrez, je vais vous montrer un peu plus sur la façon dont vous pouvez faire une erreur avec le processus de développement, et quelles conséquences intéressantes cela entraîne.
Un autre exemple
Le client - également une grande entreprise - lance les versions ERP. Et la blague est que le système est si sain qu'il n'y a nulle part où le tester sur une base complète ou quelque chose de similaire. Il n'y a tout simplement pas d'infrastructure. Plus précisément, il existe, mais il est impossible de faire un test de charge, seules les petites choses locales sont vérifiées. La libération augmente - et personne ne sait comment il se comportera dans la pratique. Une fois, tout est tombé sensiblement alors quand la sortie ne s'est pas comportée comme elle le voulait. Finalement, ils nous ont invités à regarder ce qui peut être fait. Nous avons discuté de leur souhait de voir le HP Performance Center, de créer un pilote, puis de l'intégrer, de le former et de le livrer. Libère maintenant à travers elle. Ces opérations normalisées sont testées, un résumé des opérations SLA.
Ou bien, le client d'État est venu importer la substitution. Les affaires viennent à nous et disent: nos spécialistes en informatique nous ont dit qu'il était très difficile de remplacer la base Oracle par Postgress. Nous ne les croyons pas, consultez. Deux semaines de procédure - et le résultat: «Eh bien, oui, changer de base est facile. À ce moment, vous devez réécrire tout le niveau de l'application. Un peu. Environ 90%. Vous avez d'énormes packages, vous devez transférer la couche de logique métier - et venez. Les développeurs qui ont écrit le noyau sont introuvables, car le système a huit ans. " Ils ont cru l'équipe informatique. Il s'est avéré qu'ils se sont tout simplement disputés de manière insuffisamment claire.
Nous regardons quelque part la sécurité,
voici un exemple épique . Heureusement, celui-ci est toujours simple, personne n'a rien fait depuis cinq ans et l'entreprise n'est pas à l'échelle fédérale.
L'exemple suivant. Nous mettons la même histoire avec l'acceptation des versions. Situation idéale: un entrepreneur tiers écrit le code, le passe pour les tests, réussit les tests, le met tout dans le référentiel, et à partir de là, il le collecte et le distribue. C'est beau? Sympa. Nous vivons au sein de notre entreprise depuis trois ans sans exception (avant cela, il n'y avait pas tous les départements et équipes). Mais le client dispose d'un «fonds d'algorithmes et de programmes». Là, chaque artiste envoie un blanc ou une liste du code source. Ils y couvent. Comme il s'est avéré lors de l'audit, l'anime a été enregistré sur un disque en général. Et même s'il y a un code de fait dans le fonds, cela n'a aucun sens.
Un autre client similaire. Ils ont une douleur typique - de nombreux entrepreneurs. Ils ont fait un intégrateur intra-industrie, ils vérifient que l'entrepreneur apporte le bon logiciel. Il y avait des problèmes dans la mesure où il existe des droits de tiers (bibliothèques open source avec des licences virales ouvertes, par exemple) - des entrepreneurs sans scrupules peuvent fournir tout cela sans licence dans l'ordre. Dans le cas de l'open source, vous pouvez toujours faire face au problème, mais parfois des bibliothèques commerciales se présentent. Coupable de qui sera - devinez trois fois. Puis l'un de leurs sous-traitants a fait faillite et le client a vécu avec ce code. De telles situations doivent être détectées à un stade précoce. Nous avons aidé à configurer correctement le processus. Nous avons une solution telle que l'automatisation d'un fonds d'algorithmes et de programmes. Documentation technique, versions, codes sources, contrats et tous les liens vers les offres. Avec une durée de vie moyenne des DSI de deux à trois ans, cela aide vraiment le suivant à le comprendre immédiatement.
Nous introduisons également l'agilité en Russie. Je ne ris pas du cirque maintenant. Presque chaque fois que cela commence comme une histoire à la mode sur la numérisation des entreprises. L'essentiel est que tout le monde essaie de comprendre ce que sont ces mots. Mais personne ne comprend. Concepts ordonner, embaucher des gens étranges. Ils disent les mots «il semble», «hypothèse», les startups sont invitées, l'accélération est brouillée, les smoothies se boivent - en général, tout cela a les signes extérieurs d'une sorte de vallée. Agile commence alors à postuler, mais il ne décolle pas. Si vous créez un système sérieux, vous devez le vérifier longtemps. Si vous ne mettez pas les processus, les sprints seront longs (un mois ou deux), si vous définissez les processus, vous devez commencer par l'infrastructure de test, devoops, faire le pipeline de livraison, les processus de travail entre les équipes et au sein des équipes. Et tout cela est généralement oublié. Si les processus des Anciens Croyants sont à 98%, cela le projet ne sera pas fait. Finalement, nous ratissons et courons. En général, on ne se plaint pas: du pain aussi. Mais parfois, je veux simplement expliquer, ou quoi, que l'informatique est d'abord une infrastructure, puis un TtM rapide. Et pas l'inverse.
Qu'est-ce qui se passe généralement mal? Ensemble d'exemples
Mes collègues et moi avons réuni ici un ensemble de problèmes en suspens qui ne sont pas très objectifs, mais décrivent très bien la situation. Bien sûr, nous n'allons que dans des endroits où c'est mauvais, et il n'est pas nécessaire de l'extrapoler à l'état de l'industrie. Mais je suis sûr que vous apprendrez quelque chose de votre entreprise. Une petite partie. En général, tout est décrit par les mots: "inefficacité des processus, employés démotivés, outils médiocres ou outils mal utilisés". Eh bien, maintenant - des exemples.
1. Pénalité pour les erreurs de logiciel apportées par les développeurs.Je ne sais même pas comment le décrire rationnellement. Juste une amende pour les bogues identifiés. Vivez maintenant avec cette connaissance. Naturellement, toute version (même petite) est publiée dix fois plus lentement qu'elle ne le pourrait.
2. Réunions du matin au soir.Le développeur doit y assister. Il est silencieux et hoche la tête vers le téléphone. Ce sont les mêmes réunions lorsque toute l'équipe du projet est nécessaire lors de la réunion, plus le chef de département à contrôler. Il est impossible de ne pas venir. Mais cela n'a presque aucun sens de participer. C'est l'erreur traditionnelle du chef de projet, appelée «contrôle excessif».
3. Le culte du fret. Nous adoptons des méthodologies flexibles et les mettons en œuvre de manière rigide.Le meilleur que j'ai vu: implémenté de manière agile, mais fonctionnant comme avant. Ils ont juste fait venir les développeurs au stand-up quotidien. Ils sont construits et disent: je n'ai rien fait. Cela arrive tous les jours.
4. Outils: nous mettons en œuvre pour signaler que mis en œuvre.«Nous avons un serveur d'intégration continue et seul un administrateur peut ajouter une tâche.» "Nous avons implémenté un référentiel d'assembly binaire, et il y a un très petit disque, vous devez supprimer les anciens, et il n'y a que les trois dernières versions." Ou ici: un système de gestion des tâches dans un ex-fichier sur un disque partagé. Le backlog est donc souvent en tête même dans les grandes entreprises, malgré le fait qu'il existe Jira. Dans ce cas, jusqu'à ce que la tâche tombe dans ce fichier, personne ne le fera. Il est officiel.
Une autre entreprise possède une base de connaissances interne, mais tout est stocké directement dans le système de contrôle de version: c'est plus pratique pour le manager. Des distributions de systèmes d'exploitation y sont même ajoutées. Lorsqu'aucune personne n'est responsable du système de contrôle de version, les gestionnaires peuvent placer des fichiers gigaoctets pour les transférer à la contrepartie, car dans Dropbox, l'emplacement est épuisé.
5. Normes de codage: écrites sans compréhension ou non mises à jour depuis 10 ans.Juste quelques exemples: nous avons besoin d'une couverture à 100% du code avec des tests et de la documentation. En particulier, toutes les bibliothèques tierces. L'inconvénient est le manque de tests standard. Récemment, j'ai vu comment un ingénieur a déployé le système et l'utilisateur ne peut pas se connecter, car la clé du test au prod n'a pas été modifiée.
Une fois de plus, j'ai vu comment le leader a écrit le code dans Notepad.exe, puis l'a jeté dans le compilateur sans erreur. Il étudiait toujours avec des cartes perforées. Une telle compétence mérite certainement le respect. Mais seulement jusqu'à ce que cette déformation professionnelle commence à influencer les normes pour le reste du département de développement.
6. Erreurs de réglementation.Par exemple, une heure de déjeuner fixe, qui est entièrement parcourue. Ceci est un symptôme. Je demande pourquoi. Ils expliquent: si vous êtes assis sur le lieu de travail au déjeuner, alors vous êtes la cible. Doit répondre aux lettres en cinq minutes et ainsi de suite.
Bureaucratisation excessive: souvent en suivant des procédures documentées qui conduisent à une pile de papier. Les mêmes plans de test pour chaque éternuement. Et ceci est une description de chaque filtre, y compris les types de données dans chaque champ d'interface, la longueur du champ, etc. Ceci est généralement résolu par des exemples, et non par des détails complets.
Dans une entreprise, il n'y avait aucune personne responsable de la version actuelle, parfois les délais de libération des produits pendant deux semaines étaient dépassés.
Communications: quelque chose vient du client par la poste. De plus, il écrit à celui qui lui a parlé pour la dernière fois. Même si vous voulez le faire, les commentaires sur la tâche peuvent être à différents endroits, y compris les messageries instantanées. Puis quelqu'un est parti, quelqu'un est venu, quelqu'un a supprimé le courrier - c'est tout.
7. Combattre les gardes de sécurité.Cela inclut les mises à jour manuelles de tous les systèmes (et vous devez les renverser automatiquement, cela fait gagner beaucoup de temps), des solutions de contournement physiques avec un lecteur flash sur les nœuds du réseau, l'allocation des ports pendant trois semaines, etc.
8. La communication entre les développeurs et les analystes n'est pas établie.C'est un tel montant qui se répète tous les cinq projets. C'est juste que l'analyste a écrit ce qui était nécessaire, le développeur l'a développé et un mois plus tard l'a montré prêt. L'analyste s'exécute avec horreur parce qu'il ne voulait pas dire cela. Pendant trois semaines ce mois-ci, le développeur a travaillé en vain, bien qu'il puisse montrer une partie du projet, et l'analyste pourrait demander comment les choses se passent. Il existe des méthodologies qui clôturent simplement cela, mais le problème est que dans cette situation, les deux parties ne comprennent pas pourquoi le projet est nécessaire et comment il se déroule.
9. Développement piloté par les conférences.Le leader a vu quelque chose de cool à la conférence, et ils l'ont présenté sans laisser de trace. Trois mois plus tard, répété. En conséquence, le rapport est beau, mais le travail en vaut la peine.
En raison de conférences internes, il est toujours possible d'apporter le résultat selon le schéma «Toujours prêt à 80%». Sur les rapports publics - «Presque terminé», et c'est sans fin. Porter à 100% n'arrive jamais. Pourquoi? Eh bien, par exemple, voir le point 1.
Par ailleurs, je note le sous-examen des systèmes tiers. Vous avez lu l'article - wow, cool, utilisons-le, puis apprenez comment. Et vous rencontrez beaucoup de restrictions, car le vendeur n'a versé du miel dans ses oreilles que lors des deux premières réunions. Nous avons nous-mêmes marché sur un râteau. Il y avait une mise en œuvre interne d'un système pour les magasins en ligne de documentation sur la conception des infrastructures, incl. Centres de données pour des objets très intéressants. Un cas de limitation du coût des marchandises de 100 millions a été découvert. L'astuce est que dans le domaine, le prix unitaire du document est plus élevé. Et là, le système a dû pelleter l'index pour rechercher, et nous avons des investissements de 1 gigaoctet dans les documents. Et le temps d'indexation attendu est d'un mois. Le vendeur ne l'a pas averti.
10. Effrayant de faire des changements.Il y a un tel état du projet: il faut refactoriser, revenir dans un mois. Mais il n'y a pas de tests, pas de documents, rien. Et les développeurs sont assis: "Nous avons peur de faire des changements, nous avons peur de tout casser."
J'ai également vu comment une entreprise a développé l'intégration avec un système qui ne peut pas être déployé du côté du développeur, car c'est très difficile. Les testeurs testent le transfert de données par le service (dans la mesure du possible). Sortie sur les stands du client avant la livraison - et encore deux semaines d'améliorations, car le modèle de transaction était incorrect. Il est recommandé de créer un talon pour ce système qui renvoie une sorte de réponse. En conséquence, ils l'ont fait, il est devenu plus facile de tester et d'accepter.
Un autre client peut rédiger des descriptions économiques dans sa langue habituelle. Sur ce projet, nous avons donné une sorte de constructeur de pseudo-langage (un ensemble de normes), qui est ensuite converti en données d'analyste. Dans l'esprit de "Si Vanya est en arrêt maladie, il ne pourra pas aller en production".
Et l'accord final. Quelqu'un d'autre dans une entreprise code directement sur la prod. "Il y a un petit violon, je sais ce que je fais." Merci, cher homme, mais si je te trouve, je ne sais même pas quoi faire de toi.
En général, s'est prononcé. Si vous découvrez vos problèmes, écrivez à oeremeev@croc.ru. Pour les grandes entreprises, nous avons des pilotes presque gratuits avec des diagnostics express (recherches de goulots d'étranglement en 3-5 jours). Si quelqu'un de votre entreprise a besoin d'expliquer qu'il est impossible de supporter une dette technique, - écrivez aussi, nous pouvons compter cela normalement.